Situations de pannes de BD Oracle !

[realmadrid]

Bonjour,

Ces questions n'existent pas dans la FAQ ni dans les tutoriels, alors que c'est des cas qui peuvent etre rencontrés dans la réalité

J'ai 6 situations de pannes dontj'aimerais savoir le comportement du SGBD Oracle vis a vis de ces situations (Les deux premieres situations sont réalistes, par contre les 4 dernieres je ne sais pas qund est ce que la situation est realiste ou pas ?)

1) Situation n°1:

On dispose de la transaction de MAJ suivante:

Begin Tran // Debut de la transaction
Update Emp set sal = sal*1.2 where deptno = 10;
Update Dep set mgr = 10 where mgr = 7;
...
Update Emp set sal = sal*1.2 where deptno = 10;
Update Dep set mgr = 10 where mgr = 7;
End Tran // Fin de la transaction

Question :
supposons qu'au moment de l'execution de cette transaction (après la deuxième commande update), une coupure de courant se produit. Comment cette transaction sera traitée par le SGBD Oracle ???

-----------------------------------------------------------------------------------

2) Situation n°2:

Si on n'arrive pas a démarrer notre serveur Oracle suite a une perte d'un fichier de données. Comment peut on resoudre ce probleme dans le deux cas suivants :

a) Le fichier perdu peut-etre recuperer.
b) Le fichier est definitivement perdu.

------------------------------------------------------------------------------------
Les situations suivantes resultent d'une panne du systeme.

3) Situation n°3:

Des mises a jour provenant de transactions non encore validées ont été consignées dans les fichiers de données.

4) Situation n°4:

Certaines transactionsse sont terminées correctement (et donc validées par le SGBD), mais on ne trouve pas de trace de leurs mises a jour dans les fichiers de données.

5) Situation n°5:

Certaines transactionsse sont terminées correctement (et donc validées par le SGBD), mais on ne trouve pas de trace de leurs mises a jour dans les journaux de la base de données. La base de données étant configurée en mode NOARCHIVLOG.

6) Situation n°6:

Certaines transactions étaient encore actives (ne se sont pas terminées) au moment de la panne, mais on ne trouve pas de trace de leurs mises a jour nin dans les fichiers de données ni dans les journaux de la base d e données.

Question :

Pour les quatre situations précedentes:

a) Est ce que la situation est realiste?
b) Quel scénario peut engendrer les situations realistes ?
c) Comment le Oracle va restaurer la BD pour les situations realistes ?


------------------------------------------------------------------------------------

Merci d'avance de votre aide.

[pifor]

Il faudrait aussi lire la documentation Oracle correspondante: par exemple,
http://download-uk.oracle.com/docs/c...htm#sthref2419
pour comprendre la notion de crash recovery qui répond à la plupart de vos questions (1, 3, 4 et 6).

Le cas n°5 n'est normalement pas possible: une transaction correctement validée doit être dans le redo log (=journal des transactions de la base). Si Oracle n'arrive pas à écrire dans le redo log au moment du COMMIT, la transaction n'est pas validée et Oracle doit remonter une erreur.

Les différents scénarios du cas n°2 sont documentés à partir de:http://download-uk.oracle.com/docs/c....htm#sthref183

[bouyao]

Envoyé par realmadrid

3) Situation n°3:

Des mises a jour provenant de transactions non encore validées ont été consignées dans les fichiers de données.

Si la transaction n'est pas validé, les mises à jours ne seront pas pris en compte dans la base. (Il arrive des fois, qu'une grande mise à jours soit enregistrés directement dans les fichiers de données avant une validation, mais Oracle ne tient pas compte tant que le commit n'est pas validé)

Envoyé par realmadrid

4) Situation n°4:

Certaines transactionsse sont terminées correctement (et donc validées par le SGBD), mais on ne trouve pas de trace de leurs mises a jour dans les fichiers de données.

Dans ce cas ils seront dans le fichier de journalisation, et Oracle va les enregistrés dans les fichiers de données le temps voulus.
Par exemple, Ce cas peut être réalisé en lançant un BEGIN BACKUP pour sauvegarder un tablespace, et tous les mises à jours sur cet tablespace seront enregistrés dans les fichiers de journalisations.

Envoyé par realmadrid

5) Situation n°5:

Certaines transactionsse sont terminées correctement (et donc validées par le SGBD), mais on ne trouve pas de trace de leurs mises a jour dans les journaux de la base de données. La base de données étant configurée en mode NOARCHIVLOG.

Lorsque on utlise l'option NOLOGGING, dans ceratins cas, les données sont enregistrés directement dans les fichiers de données sans être dans les fichiers de journalisations.

Envoyé par realmadrid

6) Situation n°6:

Certaines transactions étaient encore actives (ne se sont pas terminées) au moment de la panne, mais on ne trouve pas de trace de leurs mises a jour nin dans les fichiers de données ni dans les journaux de la base d e données.

C'est rare, mais réaliste.
Si le disque contenant le fichier de journalisation est plein. Donc oracle n'écrit pas dans les fichiers de journalisation et les donnés seront toujours en memoire.