Processus DBWR et Commit

Salut tout le monde j'ai encore une question bizaroide ...!!
Je suis connecté avec le compte HR et execute une instrution suivante

Code:

---

DELETE FROM employees

---

Et je n'applique pas de commit...

D'autres utilisateurs en paralélle sont entrain de faire des opérations sur ma BD, et à un moment donné, le processus DBWR ce trouve dans l'obligation d'écrire le contenu du cache de la base de données sur le disque...
(parceque mon seuil de tampon dirty est atteind... ou il y a pas assez d'espace dans le cache de base de données).
Cette écriture est-elle équivalent à un commit fait par le SGBD... :!: :!:

Car si les bloques qui contenaient les nouvelles infos de la table employées sont ecrit sur disque alors cela sigifie que mes données son dans la base... et c'est comme si j'ai appliqué un commit (bizare) :?

Merci

Citation:

---

Envoyé par blids

Salut tout le monde j'ai encore une question bizaroide ...!!
Je suis connecté avec le compte HR et execute une instrution suivante

Code:

---

DELETE FROM employees

---

Et je n'applique pas de commit...

D'autres utilisateurs en paralélle sont entrain de faire des opérations sur ma BD, et à un moment donné, le processus DBWR ce trouve dans l'obligation d'écrire le contenu du cache de la base de données sur le disque...
(parceque mon seuil de tampon dirty est atteind... ou il y a pas assez d'espace dans le cache de base de données).
Cette écriture est-elle équivalent à un commit fait par le SGBD... :!: :!:

---

Non.
Pas de validation sans commit. Tes infos sont écrites en dur dans les redos logs et eventuelement dans les archivelogs mais c'est tout

pas tout à fait... en fait l'ancienne valeur est écrite dans les rollbacks et le delete est dans les redos (c'est l'ordre DELETE et non les valeurs ;))... mais l'écriture sur le disque doit juste écrire le bloc dans la table comme libéré mais non dispo...

oui, tu as raison, je n'étais pas assez précise.
De plus, si je ne me trompe, sans commit on risque d'avoir au bout d'un certain temps une erreur car les rollbacks ne sont pas libéres (snapshot too old )

ça c'est surtout quand les données de la table doivent être modfiée alors qu'en fait elles sont déjà dans les rollbacks ;)

Mais il y a quand-même des bloques de données modifiés dans DATA BASE Buffer, si j'ai bien compris c'est comme si vous me dites que les bloques données ne seront jamais déplacés en disque du moment qu'il
y a pas de commit.. même si le cache est plein..!! :?

ben oui, mais c'est ce qui risque d'arriver si quelqu'un fait un un delete from table et que quelqu'un vaux la manipuler derriere Par exemple faire lui aussi un delete from table :fem:

Bon, expliquons en détail ce qui se passe lors du delete :

- Copie des lignes dans les rollbacks (c'est là que les autres transactions iront lire les données)
- suppression des lignes dans le tablespace -> en réalité, flagage des blocs comme libre
- si le cache est plein -> snapshoot too old -> rollback de la transaction -> écriture des rollback dans le tablespace (c'est pourquoi un rollback de delete est si long)
Sinon, on attend le commit qui supprimera les lignes du rollback ;)

D'accord.. je vois un peu....
Mais je pense que j'ai besoin de me documenter un peu plus à ce sujet...!! 8O
Merci à vous deux :wink: