IBAnalyst maakt nu deel uit van HQbird Standard!

IBAnalyst is een tool waarmee een databasebeheerder gedetailleerde Firebird- of InterBase-databasestatistieken kan analyseren en vervolgens mogelijke problemen kan identificeren met databaseprestaties, onderhoud en hoe een applicatie met de database communiceert.

Documentatie

IBAnalyst geeft Firebird- (of InterBase-) databasestatistieken grafisch weer op een gebruiksvriendelijke manier en benadrukt de volgende problemen:

fragmentatie van tabellen en BLOBs,
recordversiebeheer,
garbage collection,
effectiviteit van indexen, enz.

Bovendien kan IBAnalyst automatisch intelligente suggesties doen voor het verbeteren van databaseprestaties en databaseonderhoud.

IBAnalyst kan statistieken ophalen van live productiedatabases via de Services API (aanbevolen), of tekstuitvoer van gstat -a -r … -opdrachten analyseren. Statistieken van piekbelastingsperioden kunnen veel informatie opleveren over daadwerkelijke prestatieproblemen in productiedatabases.

Hoe IBAnalyst kan helpen bij het vinden van problemen in uw Firebird- of InterBase-database

Laten we de belangrijkste functies van IBAnalyst doornemen. Wanneer u voor het eerst naar uw databasestatistieken in IBAnalyst kijkt, kunnen dingen onduidelijk zijn, vooral als IBAnalyst veel waarschuwingen toont met rode en gele cellen in de weergaven Overzicht, Tabellen en Indexen. Laten we enkele praktijkvoorbeelden van statistieken bekijken.

Overzichtweergave

De overzichtspagina toont veel informatie, maar het meest waardevol is de transactiestatus ( lees de beschrijving van mogelijke transactiestatussen in de IBAnalyst-help; deze is beschikbaar door op F1 te klikken of via het menu Help).

Op deze schermafbeelding kunt u zien dat een transactie al lange tijd actief is, “60% van het dagelijkse gemiddelde”. IBAnalyst markeert de status van een dergelijke transactie in rood, omdat deze transactie kan voorkomen dat opgebouwde versies door de server als garbage worden beschouwd en dus worden opgeruimd. Dit is een mogelijke reden voor traagheid: hoe meer versies er voor een record bestaan, hoe langer het duurt om het te lezen.

Om deze langlopende transactie te vinden, kunt u de MON$Logger-module van FBScanner gebruiken of een directe query op MON$-tabellen uitvoeren. Om vervolgens te ontdekken welke tabellen zijn beïnvloed door langlopende transacties (tabellen met veel recordversies), moet u naar de weergave “Tabellen” van IBAnalyst gaan.

Tabellenweergave

In de weergave “Tabellen” kunt u tabellen en hun belangrijke parameters zien: aantal records, aantal recordversies, recordlengte, maximaal aantal versies, enz.

U kunt deze weergave sorteren om de grootste tabellen te vinden. Vooral tabellen met veel recordversies zijn interessant - veel recordversies zorgen ervoor dat garbage collection voor de betreffende tabellen langer duurt. Meestal is het nodig om update- en delete-algoritmen te wijzigen om van veel recordversies af te komen.

Rij Versies toont het totale aantal versies voor een specifieke tabel, en rij Max Vers toont het maximale aantal versies dat een record heeft bereikt. Als u bijvoorbeeld naar tabel NAB kijkt, zijn er 11,9 miljoen records, in totaal 20932 versies, maar één record heeft 176 versies. Het lezen en parseren van zo’n pakket van de schijf kost meer tijd, dus het lezen van dit record is langzamer dan het lezen van andere records.

Deze afbeelding toont ook veel tabellen waaruit gegevens zijn verwijderd. Maar vanwege de langlopende transactie kan de server deze versies niet verwijderen, en ze staan nog steeds op de schijf, zijn nog steeds geïndexeerd en worden nog steeds door de server gelezen bij het lezen van gegevens.

Indexweergave

Sommige productiedatabases kunnen indexen hebben met slechts één geïndexeerde sleutelwaarde. Dit kan gebeuren omdat de database is ontwikkeld “om in de toekomst te worden uitgebreid”, of iemand heeft gewoon geëxperimenteerd met de indexen tijdens ontwikkeling of tests. U kunt deze indexen als “Nutteloos” zien in IBAnalyst:

SKIN04, SKIN05, SKOUT03, enz., gebouwd op de kolom die slechts één waarde heeft voor alle rijen (miljoenen rijen). Deze indexen zijn echt nutteloos, omdat

de optimizer deze index kan gebruiken als u “where field = …” opgeeft. Aangezien het veld slechts één waarde bevat, veroorzaakt het gebruik van de index nutteloos lezen van indexpagina’s van schijf naar geheugen, en verbruikt het geheugen (en tijd) wanneer de server voorbereidt welke rijen voor die query moeten worden getoond.
het maken van indexen maakt deel uit van het herstelproces. Extra indexen voegen extra tijd toe.

Natuurlijk is dat niet alles wat u over uw database in IBAnalyst kunt vinden. U kunt ook vinden

gemiddeld aantal transacties per dag
of er rollbacks of verbroken verbindingen waren, en wanneer
hoe groot (in megabytes) elke tabel en index is
tabellen die records hebben afgewisseld met blobs, waardoor alleen het lezen van records langzamer is
lege tabellen - gewoon vergeten, of leeg op het moment dat de statistieken werden genomen
indexen met veel dubbele sleutels (u kunt nadenken over de verdeling van kolomwaarden)
indexen met diepte 4 en groter - misschien moet u de paginagrootte vergroten om te versnellen

Automatische aanbevelingen

Als u in de war raakt door het lezen van gekleurde celwaarschuwingen, open dan gewoon “Rapporten\Aanbevelingen bekijken” - alles wat voldoende is voor databaseprestaties is hier verzameld. Stel gerust vragen ( [email protected])