IBAnalyst ora fa parte di HQbird Standard!

IBAnalyst è uno strumento che consente a un amministratore di database di analizzare statistiche dettagliate di database Firebird o InterBase e di identificare possibili problemi di prestazioni, manutenzione del database e di come un’applicazione interagisce con il database.

Documentazione

IBAnalyst visualizza graficamente le statistiche del database Firebird (o InterBase) in modo intuitivo ed evidenzia i seguenti problemi:

frammentazione di tabelle e BLOB,
versionamento dei record,
garbage collection,
efficacia degli indici, ecc.

Inoltre, IBAnalyst può formulare automaticamente suggerimenti intelligenti per migliorare le prestazioni del database e la sua manutenzione.

IBAnalyst può ottenere statistiche dai database di produzione attivi tramite Services API (consigliato) oppure analizzare l’output testuale dei comandi gstat -a -r …. Le statistiche dei periodi di carico massimo possono fornire molte informazioni sui problemi reali di prestazioni nei database di produzione.

Come IBAnalyst può aiutare a trovare problemi nel tuo database Firebird o InterBase

Esaminiamo le funzionalità principali di IBAnalyst. Quando guardi le statistiche del tuo database in IBAnalyst per la prima volta, le cose possono non essere chiare, soprattutto se IBAnalyst mostra molti avvisi con celle colorate in rosso e giallo nelle viste Riepilogo, Tabelle e Indici. Consideriamo diversi esempi reali di statistiche.

Vista Riepilogo

La pagina Riepilogo mostra molte informazioni, ma la più preziosa è lo stato delle transazioni ( leggi la descrizione dei possibili stati delle transazioni nella guida di IBAnalyst, disponibile premendo F1 o nel menu Guida).

In questo screenshot puoi vedere che una transazione è attiva da molto tempo, “60% della media giornaliera”. IBAnalyst segna lo stato di tale transazione in rosso, perché questa transazione può impedire che le versioni accumulate vengano considerate come garbage dal server e quindi vengano raccolte. Questa è una possibile causa di rallentamento: più versioni esistono per un record, più tempo ci vorrà per leggerlo.

Per trovare questa transazione di lunga durata puoi usare il modulo MON$Logger di FBScanner, oppure eseguire una query diretta sulle tabelle MON$. Poi, per scoprire quali tabelle sono state interessate dalle transazioni di lunga durata (tabelle con molte versioni di record), devi andare alla vista “Tabelle” di IBAnalyst.

Vista Tabelle

Nella vista “Tabelle” puoi vedere le tabelle e i loro parametri importanti: numero di record, numero di versioni dei record, lunghezza dei record, numero massimo di versioni, ecc.

Puoi ordinare questa vista per trovare le tabelle più grandi. In particolare siamo interessati alle tabelle con molte versioni di record: molte versioni di record renderanno più lunga la garbage collection per le tabelle interessate. Di solito è necessario modificare gli algoritmi di aggiornamento ed eliminazione per eliminare molte versioni di record.

La riga Versioni riga mostra il numero totale di versioni per una particolare tabella, e la riga Max Vers mostra il numero massimo di versioni raggiunto da un record. Ad esempio, se guardi la tabella NAB, ci sono 11,9 milioni di record, le versioni totali sono 20932, ma un record ha 176 versioni. Leggere e analizzare tale pacchetto dal disco richiede più tempo, quindi leggere questo record è più lento che leggere gli altri.

Questa immagine mostra anche molte tabelle in cui i dati sono stati eliminati. Ma, a causa della transazione di lunga durata, il server non può eliminare queste versioni, e sono ancora sul disco, ancora indicizzate e ancora lette dal server durante la lettura dei dati.

Vista Indici

Alcuni database di produzione possono avere indici con un solo valore chiave indicizzato. Questo può accadere perché il database è stato sviluppato “per essere esteso in futuro”, oppure qualcuno ha semplicemente sperimentato con gli indici durante lo sviluppo o i test. Puoi vedere questi indici come “Inutili” in IBAnalyst:

SKIN04, SKIN05, SKOUT03, ecc., costruiti su una colonna che ha un solo valore per tutte le righe (milioni di righe). Questi indici sono davvero inutili, perché

l’ottimizzatore può usare questo indice se specifichi “where field = …”. Poiché il campo contiene un solo valore, l’uso dell’indice causerà una lettura inutile delle pagine dell’indice dal disco alla memoria, e consumerà memoria (e tempo) quando il server preparerà quali righe mostrare per quella query.
la creazione degli indici fa parte del processo di ripristino. Indici extra aggiungono tempo extra.

Naturalmente, non è tutto ciò che puoi scoprire sul tuo database in IBAnalyst. Puoi anche trovare

numero medio di transazioni al giorno
se ci sono stati rollback o connessioni perse, e quando
quanto sono grandi (in megabyte) ogni tabella e indice
tabelle che hanno record intervallati da blob, e quindi la sola lettura dei record è più lenta
tabelle vuote - semplicemente dimenticate, o vuote al momento in cui sono state prese le statistiche
indici con molte chiavi duplicate (puoi considerare la distribuzione dei valori della colonna)
indici con profondità 4 o superiore - forse devi aumentare la dimensione della pagina per accelerare

Raccomandazioni automatiche

Se sei confuso leggendo gli avvisi delle celle colorate, apri semplicemente “Rapporti\Visualizza raccomandazioni” - tutto ciò che è sufficiente per le prestazioni del database è raccolto qui. Non esitare a fare qualsiasi domanda ( [email protected])