IBAnalyst: come ottenere le statistiche da un database InterBase/Firebird nel modo corretto

Dmitry Kuzmenko, ultimo aggiornamento 31-03-2014

Abstract

Questo documento è dedicato a suggerimenti e trucchi per la raccolta e l’analisi delle statistiche da database InterBase/Firebird con o senza IBAnalyst.

Il momento giusto, il posto giusto

Sembra strano, ma semplicemente prendere le statistiche tramite gstat o Services API non è sufficiente. Le statistiche devono essere prese nel momento giusto per mostrare come le applicazioni influenzano i dati e le transazioni nel database. Il momento peggiore per prendere le statistiche è

• Subito dopo un restore
• Dopo un backup (gbak -b db.gdb) senza l’opzione -g
• Dopo uno sweep manuale (gfix -sweep)

È anche vero che durante il lavoro ci possono essere momenti in cui il database è in uno stato corretto, ad esempio, quando le applicazioni generano un carico sul database inferiore al solito (agli avvii degli utenti, a pranzo o in base ai tempi specifici dei processi aziendali).

Come capire quando c’è qualcosa che non va nel database?

Sì, le vostre applicazioni possono essere progettate così perfettamente da lavorare sempre correttamente con transazioni e dati, senza creare gap di sweep, molte transazioni attive, snapshot di lunga durata e così via. Di solito non accade. Almeno perché alcuni sviluppatori testano le loro applicazioni con 2-3 utenti simultanei alla volta, non di più. Così, quando installano applicazioni scritte per 15 o più utenti simultanei, il database può comportarsi in modo imprevedibile. Naturalmente, la modalità multiutente può funzionare bene, perché la maggior parte dei conflitti multiutente può essere testata con 2-3 applicazioni in esecuzione contemporanea. Ma, successivamente, quando più applicazioni concorrenti saranno in esecuzione, possono sorgere problemi di garbage collection (almeno). E questo può essere rilevato se si prendono le statistiche nei momenti giusti.

Se non si verificano problemi di prestazioni periodici

Questo può accadere quando le vostre applicazioni sono progettate correttamente, c’è un basso carico sul database, o il vostro hardware è moderno e molto potente (abbastanza per gestire bene il numero attuale di utenti e dati).

L’informazione più preziosa è il carico delle transazioni e l’accumulo di versioni. Questo può essere visto solo se si imposta un salvataggio regolare delle statistiche.

InterBase non ha un task scheduler interno, quindi siete liberi di usare qualsiasi esterno, come il Task Scheduler standard (Windows) o cron (Unix).

La configurazione migliore è ottenere statistiche sulle transazioni ogni ora. Questo può essere fatto eseguendo

gstat -h db.gdb >db_stat_.txt

dove

db.gdb è il nome del vostro database,

db_stat_.txt è il file di testo dove verranno salvate le statistiche,

- data e ora corrente in cui le statistiche sono state prese.

Se si verificano problemi di prestazioni periodici

Questi problemi sono solitamente causati dall’esecuzione automatica dello sweep. Prima di tutto è necessario determinare il periodo di tempo tra questi cali di prestazioni. Successivamente, dividere questo intervallo minimamente per 4 (8, 16 e così via). Ora i sistemi informativi hanno molti utenti concorrenti, e la maggior parte dei problemi di prestazioni con server e database non configurati accade 2 o 3 volte al giorno. Ad esempio, se i cali di prestazioni avvengono ogni 3 ore, è necessario prendere

gstat -h db.gdb

statistiche ogni 30-45 minuti, e

gstat -a -r db.gdb -user SYSDBA -pass masterkey

ogni 1-1,5 ore.

Il meglio è prendere le statistiche gstat -a -r subito prima del previsto calo di prestazioni. Mostrerà dove si trova la vera spazzatura e quante versioni di record obsolete si sono accumulate.

Cosa fare con queste statistiche

Se la vostra applicazione usa esplicitamente le transazioni e le usa bene, cioè sapete cosa è read_committed e quando usarlo, le vostre transazioni snapshot non durano più del necessario, e le transazioni sono attive per una durata minima di tempo, potete regolare l’intervallo di sweep o disattivarlo, e poi preoccuparvi solo di quante update fa l’applicazione e quali tabelle devono essere meno aggiornate o richiedono attenzione per gli aggiornamenti.

Cosa significa questo, potreste chiedere? Daremo un esempio di un sistema dove i problemi di prestazioni accadevano ogni mattina per 20-30 minuti. Era molto sufficiente per le applicazioni “mattutine”, e non poteva durare più a lungo.

All’amministratore del database sono state poste le domande giuste, ed ecco il quadro:

Il lavoro quotidiano era diviso in sezioni - gli analisti lavorano al mattino, poi i dati vengono inseriti e modificati dai normali operatori, e alla fine della giornata procedure speciali avviavano la raccolta di dati che sarebbero stati usati dagli analisti il giorno successivo (almeno).

L’ultimo lavoro sul database alla fine della giornata era un sacco di update, e update di quelle tabelle che gli analisti usavano al mattino. Quindi, c’erano molte versioni di spazzatura, che cominciavano a essere raccolte dall’applicazione in esecuzione al mattino.

E la risposta a quel problema è stata trovata semplice - eseguire gfix -sweep alla fine della giornata.

Lo sweep legge tutte le tabelle nel database e cerca di raccogliere tutte le versioni di spazzatura per le transazioni committate e rollbackate. Dopo lo sweep il database diventava pulito quasi come dopo un restore.

E il “problema mattutino” è sparito.

Quindi, dovete considerare le statistiche con molti altri fattori:

1. quanti utenti concorrenti (in media) lavorano durante il giorno

2. quanto dura la giornata lavorativa (8, 12, 16, 24 ore)

3. che tipo di applicazioni girano in diversi momenti della giornata, e come influenzano i dati usati da altre applicazioni, in esecuzione nello stesso momento o successivamente. Cioè, dovete capire i processi aziendali che accadono durante l’intera giornata e l’intera settimana.

Quando il DBA non può fare nulla

Purtroppo, queste situazioni accadono. E ancora, un esempio:

Un sistema installato per ~15 utenti. Periodicamente le prestazioni sono così scarse che il DBA deve riavviare il server. Dopo il riavvio del server tutto funziona bene per un po’, poi le prestazioni peggiorano di nuovo. Le statistiche mostravano che la media giornaliera di transazioni è di circa 75.000, e ci sono transazioni attive che girano dall’inizio della giornata fino al momento in cui le prestazioni calano.

Sfortunatamente, le applicazioni erano scritte con BDE e senza l’uso di transazioni; cioè tutta la gestione delle transazioni era automatica e usata da BDE stesso. Questo causava che alcune transazioni rimanessero attive per molto tempo, e la spazzatura (versioni di record) si accumulava finché il DBA riavviava il server. Dopo il riavvio, lo sweep automatico partiva e la spazzatura veniva raccolta (eliminata).

Tutto questo era causato dalle applicazioni, perché erano state testate solo con 2-3 utenti concorrenti, e quando sono diventati ~15, le applicazioni hanno iniziato a generare un carico molto alto.

Bisogna dire che in quella configurazione il 70% degli utenti leggeva solo dati, e l’altro 30% inseriva e aggiornava alcuni (!) dati.

In questa situazione, l’unica cosa che può migliorare le prestazioni è ridisegnare completamente le applicazioni.

Avete ancora domande? Chiedeteci a [email protected]