De nombreux informaticiens confondent des notions logiques et physique de bases de données savamment entretenu par une utilisation de termes approximatifs dont il ne comprennent pas la sémantique… Il en est ainsi des termes dump et log… Voyons de quoi il ressort…

Log ou journal de transaction ?

Le terme fichier de log désigne généralement les journaux d’événement (comme ceux de Windows par exemple : applicatif, sécurité, os…). Ce sont des informations qui y sont écrite au fil de l’eau et qui n’ont d’autre but que de renseigner sur ce qui s’est passé…
le terme journal de transaction est le terme consacré pour enregistrer les transactions SQL, les images avant et après mise à jours des tables, et consigner la finalisation de la transaction.

Toutes les opérations de manipulation de données dans la base de données s’effectuent dans une transaction et toutes les écritures sont consignées dans le journal de transaction. Par principe, il est impossible de manipuler des données sans les journaliser… Ceci permet la reprise en cas d’incident et ne constitue nullement une collection d’information destiné à savoir qui à fait quoi dans la base de données…

En conclusion, ne parlez pas de « log » pour désigner le journal des transactions d’un SGBDR, un journal de transaction n’ayant rien à voir avec un fichier de log.

Dump ou sauvegarde ?

Le terme dump n’a rien à voir avec la sauvegarde d’une base de données. Certains SGBDR qui sont encore dans l’incapacité matérielle de générer de véritables sauvegardes (comme MySQL par exemple) vous propose pour pallier leur défaut avec une commande dump qui n’a rien à voir avec ce qu’est une véritable sauvegarde de bases de données relationnelle.

Une sauvegarde est un mécanisme de copie binaire des données d’une base qui capture les pages de données de la base ainsi que l’ensemble des transactions effectuées depuis le démarrage de la base et ce jusqu’au moment ou la sauvegarde s’arrête. Ceci est la seule méthode connue pour obtenir une sauvegarde cohérente de la base de données, alors que la base continue d’être exploitée.

En revanche un dump est étymologiquement un déversement de données (qui peuvent être incohérente) d’un espace à un autre (par exemple mémoire vers affichage), pouvant produire un fichier. En matière système, c’est généralement ce qui se passe à la suite d’une erreur grave. Pour une base de données et contrairement à une sauvegarde un dump n’assure aucune cohérence, ou s’il le permet c’est en bloquant les accès en écritures afin de se prémunir des données non intègres qui pourrait résulter du séquencement de ce vidage (par exemple l’écriture dans le fichier des données des factures avant celle des clients alors qu’entre temps un nouveau client avec une nouvelle facture est inséré).

Donc ne parlez pas de DUMP ce terme n’a pas cours dans les SGBDR. En revanche vous pouvez parler de :
* sauvegardes
* script SQL de rétro ingéniérie du schéma de la base (SQL DDL)
* script SQL de chargement de données (SQL DML)

Quelques remarques complémentaire… (pour les incrédules !)
Si vous cherchez la commande DUMP dans IBM DB2 (par exemple dans le Boulder) vous tomberez sur la définition suivante :
Dump files are created when an error occurs for which there is additional information that would be useful in diagnosing a problem…
De même sous Oracle, chercher dump dans l’aide conduit à la fonction dump_session dont la documentation dit :
Call this method to dump session storage content to an output buffer. The output of this function is intended for debugging purposes…
Pas vraiment de la sauvegarde… n’est ce pas ?

-------- 

Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/ 

Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server 

www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation 

* * * * *  Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence  * * * * *