Archivi tag: firebird

Shrinking di un database Firebird

L’ABC dell’informatica ci ha insegnato che non esiste un solo tipo di file system. Infatti, oltre al file system utilizzato dal sistema operativo esiste anche il file system del DBMS, il network file system (ad esempio NFS e Microsoft DFS) e così via.

Bene, solitamente quando si cancellano N record da una o più tabelle del DB, il DBMS a cui l’istanza afferisce non rilascerà automaticamente al sistema operativo lo spazio appena liberato. Questo significa che il file che identifica il DB manterrà le propre dimensioni originarie, nonostante le operazioni di rimozione dei record.

Per quanto riguarda Firebird, l’unico modo per effettuare lo shrinking del database (ovvero la sua contrazione in termini di spazio occupato su disco) è eseguire il backup di quest’ultimo e successivamente ripristinarlo.

database, dbms, shrinking, disk space, restore, backup, gfix, gbak, garbage collection, firebird

Fortunatamente, Firebird ci mette a disposizione un valido strumento per tale scopo: gbak.

Per default tale applicativo effettuerà anche la garbage collection dei record duplicati (generati dai rollback delle transazioni), impiegando un certo lasso di tempo (in quanto trattasi di un’operazione abbastanza onerosa in termini computazionali). Per fare in modo che gbak non proceda con la garbage collection occorre usare la flag -G. Ad esempio:

server ~ # gbak -B nomedatabase.fdb nomedatabase.fbk
-v -y backup.log

eseguirà il backup del nostro DB, salvando le informazioni relative a tale operazione (-v -y) nel file backup.log, mentre:

server ~ # gbak -B -G nomedatabase.fdb nomedatabase.fbk
-v -y backup.log

eviterà di eseguire la garbage collection (che, solitamente, viene messa in atto automaticamente ad intervalli di tempo regolari, secondo quanto definito nel file di configurazione di Firebird).

Inoltre, è possibile effettuare la garbage collection in un secondo momento, utilizzando gfix:

server ~ # gfix -s nomedatabase.fdb

Una volta creato il file di backup (con estensione *.fbk), sarà necessario ripristinarlo. Il comando da utilizzare è il seguente:

server ~ # gbak -C nomedatabase.fbk nomedatabase.fdb
-v -y restore.log

Assegnamo i giusti permessi al file appena creato:

server ~ # chown firebird:firebird nomedatabase.fdb

riavviamo Firebird:

server ~ # /etc/init.d/firebird restart

ed abbiamo finito.

Alla prossima.

Firebird: cancellazione dei record duplicati

Potrebbe accadere che all’interno di un database siano presenti una o più tabelle non dotate di chiavi primarie. Questo significa, in soldoni, che è molto alto il rischio di ridondanza (aka duplicati) e quindi di inconsistenza.

Fortunatamente, Firebird ci mette a disposizione un metodo abbastanza semplice per la cancellazione dei duplicati. Esso si basa sull’uso di uno specifico campo (RDB$DB_KEY), il cui valore univoco viene assegnato automaticamente a ciascun record durante la fase di inserimento nel DB.

firebirdlogo.jpg

Inutile dire che preferisco di gran lunga l’uso del suddetto metodo rispetto a soluzioni alternative, in quanto esso si basa esclusivamente su di una query secca e quindi minimizza il rischio di errore. Infatti, se ad esempio avessi utilizzato le cosiddette prepared statements avvelendomi di un qualche linguaggio di alto livello che le supporta (come Java), avrei dovuto scrivere N righe di codice, incrementando la possibilità di incappare in bachi (ecco perchè preferisco sempre mettere in pratica il motto less is more).

Di seguito la query che ho utilizzato:

DELETE FROM TABLE1 t1
WHERE EXISTS (
SELECT 1 FROM TABLE1 t2
WHERE t1.COL1 = t2.COL1 and t1.COL2 = t2.COL2
AND t1.RDB$DB_KEY < t2.RDB$DB_KEY
);

Dove t1 e t2 sono gli alias associati alla medesima tabella, mentre COL1 e COL2 sono i campi che la dovrebbero identificare univocamente (la probabile chiave primaria).

Ora, per avere la certezza che tale query non cancelli più record del previsto, si dovrebbero coinvolgere tutti i campi della tabella. Però, quando il numero dei campi è piuttosto elevato (>15), risulta più conveniente identificare la presunta chiave primaria ed utilizzare solo i campi che concorrono a formarla.

In questo caso, prima di effettuare il DELETE vero e proprio è opportuno fare delle query di verifica.

Ad esempio, dapprima si contano tutti i record della tabella:

SELECT count(*) FROM TABLE1;

e successivamente si individuano i record duplicati:

SELECT COL1, COL2, count(*) FROM TABLE1 GROUP BY COL1, COL2 HAVING count(*) >= 2;

A questo punto il numero dei record a cancellazione avvenuta dovrebbe essere pari al numero restituito dalla prima query meno il numero restituito dalla seconda query.

Per avere la certezza che il numero di record rimossi sia identico alla risultante dell’operazione di differenza effettuata in precedenza si può eseguire la query:

SELECT count(*) FROM TABLE1 t1
WHERE EXISTS (
SELECT 1 FROM TABLE1 t2
WHERE t1.COL1 = t2.COL1 and t1.COL2 = t2.COL2
AND t1.RDB$DB_KEY < t2.RDB$DB_KEY
);

Se il numero di record restituiti è identico al numero dato dalla differenza, abbiamo una buona probabilità che la chiave primaria individuata sia quella giusta (almeno dal punto di vista quantitativo).

Alla prossima.

Firebird: workaround per la conversione di un campo varchar(n) in smallint

Firebird è un DBMS abbastanza potente ma soprattutto leggero e versatile. Esso, però, presenta alcune limitazioni di non poco conto. Una su tutte è l’impossibilità di convertire un campo varchar(n) in smallint, nonostante tutti i record che si riferiscono al campo in questione siano degli interi positivi di una sola cifra.

firebird,field,type conversion,varchar,int,smallint,conversion error

Per intenderci, al primo tentativo di conversione mi sono beccato un errore del tipo:

Conversion error from string

Cosa fare dunque? Nelle FAQ di Firebird esiste una procedura, ma sinceramente ho preferito fare di testa mia. Per prima cosa ho creato un nuovo campo nella tabella di interesse, mediante la seguente query:

ALTER TABLE nometabella ADD nuovocampo SMALLINT;

A questo punto ho copiato il contenuto del campo varchar(n) all’interno del campo appena creato:

UPDATE nometabella SET nuovocampo = vecchiocampo;

Ho quindi modificato la posizione di nuovocampo, portandolo a fianco di vecchiocampo:

ALTER TABLE nometabella ALTER COLUMN nuovocampo POSITION x

dove x è, ovviamente, la nuova posizione.

Per maggiore sicurezza, ho provveduto a lanciare una query di verifica, in modo da identificare eventuali discrepanze tra il contenuto di nuovocampo e quello di vecchiocampo:

SELECT * FROM nometabella WHERE nuovocampo <> vecchiocampo

Poichè la suddetta query ha restituito come risultato 0 record, mi sono tranquillizzato ed ho eseguito la query:

ALTER TABLE nometabella ALTER COLUMN vecchiocampo TO vecchiocampo_bak

e quindi:

ALTER TABLE nometabella ALTER COLUMN nuovocampo TO vecchiocampo

In soldoni, non ho fatto altro che rinominare nuovocampo in vecchiocampo, ereditando quindi il tipo di dato (smallint).

Infine, ho eliminato vecchiocampo_bak:

ALTER TABLE nometabella DROP COLUMN vecchiocampo_bak

Semplice, no?

Alla prossima.