Firebird Documentation IndexGuida rapida per Firebird 2 → Prevenire le perdite dei dati
Firebird Home Firebird Home Indietro: Operare sulle basi di datiFirebird Documentation IndexRisali: Guida rapida per Firebird 2Avanti: Dove reperire informazioni ed aiuto

Prevenire le perdite dei dati

Backup
Come rovinare una base di dati

Backup

Firebird ha due programmi di utilità per il backup ed il restore dei database: gbak e nbackup. Entrambi si trovano nel sottodirettorio bin dell'installazione di Firebird. Si può fare il backup delle basi di dati Firebird mentre gli utenti sono connessi al sistema e proseguono il loro normale lavoro. Il backup viene preso da una fotografia della base di dati presa al momento in cui inizia la copia di backup.

Backup regolari e restore occasionali dovrebero essere parte dell'attività pianificata della gestione delle basi di dati.

Avvertimento

Eccetto che nella modalità lock di nbackup, è bene non usare utilità di copia esterne proprietarie o strumenti di copia file come WinZip, tar, copy, xcopy, ecc., su un database che è in funzione. Non solo il backup sarà inaffidabile, ma il sistema di bloccaggio disco utilizzato da tali strumenti può rovinare un database funzionante.

Importante

Studiare i messaggi della successiva sezione riguardo l'attività del database durante il restore!

Più informazioni su gbak possono essere trovate sul The Firebird Book, la guida Using Firebird (una versione non molto recente in inglese è disponibile attraverso IBPhoenix, una versione aggiornata è attualmente in fase di crescita sul sito Firebird), oppure nei manuali di InterBase 6.0 combinati con le note di rilascio di Firebird 1.5 e di Firebird 2.0. Queste risorse sono indicate in Dove trovare aiuto.

Il manuale di nbackup è in:

http://www.firebirdsql.org/manual/nbackup.html

http://www.firebirdsql.org/pdfmanual/Firebird-nbackup.pdf

(entrambi al momento sono solo in inglese e sia HTML che PDF hanno lo stesso contenuto)

Come rovinare una base di dati

Le seguenti sezioni sono un elenco di cose da non fare assolutamente se volete mantenere le vostre basi di dati Firebird in buona salute.

Modificare le tabelle del metadata

Firebird memorizza e gestisce tutto il metadata per sé stesso e per gli oggetti definiti dall'utente in speciali tabelle dette tabelle di sistema o system tables, sempre nel database stesso. Gli idetificatori per queste tabelle di sistema, le loro colonne e altri tipi di oggetti di sistema iniziano tutti con i caratteri RDB$.

Poichè sono comunque degli oggetti ordinari della base di dati, possono essere interrogati (fin qui poco male) e manipolati (qui no) come altri oggetti definiti dall'utente. Tuttavia, il fatto che si può non significa che si debba farlo. Il motore di Firebird implemente un insieme ad alto livello dell'SQL(DDL) allo scopo di definire ed operare sugli oggetti del metadata, tipicamente attraverso i comandi CREATE, ALTER e DROP.

Va raccomandato fortemente di usare operazioni DDL (non quelle SQL direttamente sulle tabelle di sistema) ogni qualvolta ci sia necessità di modificare il metadata. Meglio ritardare le operazioni dirette fino a quando l'esperienza in SQL e la conoscenza del motore Firebird non siano diventate veramente avanzate. Una base dati rovinata non è granchè utile, nè facile da riparare.

Disabilitare le forced writes su Windows

L'installazione tipica di Firebird abilita per default la scrittura forzata, le c.d. «forced writes» (o anche synchronous writes cioè scritture sincrone). Significa che le modifiche ai dati e gli inserimenti sono scritti immediatamente al momento stesso della conferma del dato (nota: al momento del POST del dato, non al momento del COMMIT della transazione che è successivo).

È possibile assegnare ad un database la possibilità di utilizzare scritture dei dati asincrone, in cui i dati modificati o nuovi sono tenuti in memoria e solo periodicamente scritti su disco attraverso la gestione di I/O del sistema operativo. Di solito si attribuisce a questa configurazione il nome di forced writes off (o anche disabled). Viene talvolta utilizzato per migliorare le prestazioni temporaneamente durante lunghe operazioni di inserimento massiccio di dati.

Qui va fatta un'avvertenza grossa come una casa: bisogna assolutamente non disabilitare le «forced writes» su un server Windows. È stato osservato più volte che sulla piattaforma Windows la memoria tampone del disco non viene scaricata completamente fino a quando non viene completamente fermato il servizio Firebird. Oltre ai problemi di alimentazione, potrebbero esserci altri problemi su un server Windows. Se si blocca per un qualsiasi motivo, il sistema di I/O è fuori controllo ed il lavoro in corso degli utenti verrebbe perso facendo ripartire il sistema.

Nota

Windows 9x e Windows ME non supportano le scritture su disco differite

Disabilitare le forced writes su un server Unix e Linux

Rispetto a Windows, i server Unix e Linux sono più sicuri nel gestire le operazioni con le forced writes disabilitate. Comunque è utile avere dischi di alta qualità ed un gruppo di continuità. Nei server Unix possono essere disabilitate temporaneamente, ad esempio per il tempo utile necessario a terminare una lunga operazione di inserimento e aggiornamento. Anche in questo caso un gruppo di continuità potrebbe eliminare la necessità delle forced writes.

Avvertimento

Un problema sul kernel dei server Linux non fa funzionare per niente le forced writes. Il problema è stato risolto a partire da Firebird 2.1 RC1 in avanti. Si ribadisce che il problema è in Linux, non in Firebird: altri Unix (es. HP/UX) non dovrebbero risentire del problema.

Restore di una copia su una base di dati in uso

Una delle opzioni del programma di utilità gbak facendo il restore (gbak -rep[lace_database]) permette di recuperare una copia sopra una base di dati esistente. È possibile farlo senza nessun avviso del fatto che ci siano utenti collegati e quindi il database sia in uso: in questo caso la distruzione del database è quasi certa.

Nota

Notare che il formato abbreviato di questo comando è gbak -rep, e non gbak -r come nelle precedenti versioni di Firebird. Cosa è successo a gbak -r? Adesso è l'abbreviazione di gbak -recreate_database, che funziona come gbak -c[reate] e pertanto da un messaggio di errore se il database esiste già. Si può forzare la riscrittura del databse esistente dando anche l'opzione di o[verwrite]. Questa opzione è supportata solo con gbak -r, ma non con gbak -c.

Sono state fatte queste modifiche perchè molti utenti alle prime armi, pensando che l'opzione -r significasse restore (recupera) invece di replace (sostituisci), purtroppo scoprivano la verità solo quando ormai la frittata era fatta.

Avvertimento

Bisogna essere consci del fatto che è necessario progettare le procedure e gli strumenti di amministrazione in modo tale da prevenire che chiunque (incluso SYSDBA) possa fare il restore su un database attivo se c'è un qualsiasi utente collegato.

Se è possibile, sarebbe meglio fare il restore su uno spazio disco alternativo usando gbak -c[reate] e verificare il database appena creato usando isql o un altro strumento di amministrazione di proprio gradimento. Se il database è buono, allora fermare il server, copiare altrove il vecchio database e copiare il nuovo database sul vecchio.

Permettere agli utenti di accedere al database durante il recupero

Se non si impedisce agli utenti di accedere durante il restore fatto con gbak -rep[lace_database], questi potrebbero effettuare operazioni sui dati. Il database in questo caso verrebbe danneggiato severamente.

Indietro: Operare sulle basi di datiFirebird Documentation IndexRisali: Guida rapida per Firebird 2Avanti: Dove reperire informazioni ed aiuto
Firebird Documentation IndexGuida rapida per Firebird 2 → Prevenire le perdite dei dati