Discussion :

[sam01]

Bonjour à trous,

je dois décrire le fonctionnement d'une base de données en générale sans en citer une particulièrement et sans trop entre dans le détail non plus..
Notamment, il faut que j'explique l'utilité des log (journaux). Que se passe t'il lorsqu'il y a une insertion (alimentation des fichiers logs), le commit, le rollback, la gestion des accès concurrents.
Je cherche un schéma qui représente ce fonctionnement mas j'ai un peu de mal à trouver pour vulgariser tout ça. Si vus un lien vers un schéma explicite, je suis preneur.

Merci d'avance.

[sam01]

Merci. Peut-être qu'il existe un schéma qui représente un peu tout cela.
Voilà ce que j'ai réunis comme information mais il me manque les contentions, les accès concurrents :

==> Une base de données doit être stockées sur disque pour des raisons de taille et de persistance

==> Les données doivent impérativement être transférées en mémoires afin qu’elles puissent être traitées rapidement

==> Un critère essentiel de performance est le stockage le plus contigu possible des données

==> Le journal de transaction permet aux bases de données d’éviter de perdre des données en cas de panne ou de défaillance du sytème. Toute modifications d’un utilisateur ne sera pas perdu grâce à ce logging. En effet, ces fichiers journaux vont contenir toutes les modifications apportées à une base de données : INSERT, UPDATE et DELETE. Dans un premier temps, les données modifiées sont stockées dans la mémoire tampon, puis après un commit, elles sont stockées dans les fichiers journaux.

==> Il est possible d’activer les archives logs pour archiver les fichiers journaux.

==> Si une base de données se crache un Vendredi et que l’on a une sauvegarde uniquement le Lundi. Il sera possible de partir de la sauvegarde de Lundi en lui appliquant les modifications stockées dans les fichiers journaux jusqu’à Vendredi.

Il manque certainement des choses importantes que je n'ai pas mentionner...

[sam01]

Bonjour. il faut que j'explique le cheminement des donnėes lors d'un insert par exemple. Les données vont en mémoire vive, puis elles sont écrites dans des journaux de logs, puis après un comit elles sont écrites dans la base de données, c'est bine ça?

[SQLpro]

je ne pense pas qu'un tel schéma existe car l'implémentation des commit et rollback sont propres à chaque SGBDR c'est qu'Oracle présupposément ne gère pas ça comme le fait Microsoft Server par exemple.
Pour ce qui est de la gestion d'un commit je pense que le SGBD doit mettre en cache la ligne dans une table affectée.
Pour ce qui est des accès concurrents c'est un truc dont le principe est simple c'est que le SGBDR dans un thread séparé verrouille une ou des tables modifiées

Tous les SGBD Relationnels fonctionnent selon le même principe de gestion des transactions par journalisation dans un fichier de type WAL (Write Ahead Log) mis au point par Philip A. Bernstein et Eric Newcomer et Jim Gray dans les années 70 et leur implémentation reposent sur l'algorithme ARIES utilisé par TOUS les SGBDR actuels !
https://cs.stanford.edu/people/chris...5/rl/aries.pdf

Vous pouvez utiliser le schéma suivant :



Extrait de mon livre SQL Server 2014, à condition de mentionner :
"extrait de : Microsoft SQL Server 2014 - ed. Eyrolles - F. Brouard, C. Soutou, D. Barabarin, N. Souquet"
merci

[sam01]

Bonjour Merci SQLpro pour le schéma.
Il y a juste un point que je saisi pas bien.
Los d'une mise à jour de données, cette mise à jour est d'abord dans :
1) la mémoire cache
2) dans les fichiers de logs
puis après le COMMIT,
il y a un transfert de cette modification dans la Database ?
C'est le fait de commiter qui provoque l'écriture dans la base à partir des fichiers journaux ?

[SQLpro]

Suivez les numéros !

La commande CHECKPOINT est déclenchée de temps à autre. Soit :

• cycliquement
• sur quantité à mettre à jour
• sur pression mémoire
• ...

A +