Discussion :

[orafrance]

on voit bien que le fichier de contrôle à été modifié.

mais qu'est ce qui empêcherait Oracle d'avoir implémenté la possiblilité d'écrire dans le dictionnaire si les controlfiles ne sont pas là sans planter... et d'écrire dans les controlfiles dés qu'ils sont à nouveau dispo ?

c'est pas un bug, c'est une super évolution qui permet de pouvoir récupérer les controlfiles tant que la base n'est pas arrêter

[bouyao]

mais qu'est ce qui empêcherait Oracle d'avoir implémenté la possiblilité d'écrire dans le dictionnaire si les controlfiles ne sont pas là sans planter... et d'écrire dans les controlfiles dés qu'ils sont à nouveau dispo ?

Je ne pense pas.

1. sur cetains OS sous 10g ca se plante tout de suite (j'ai donné deja une demonstration)
2. même sous Solaris ca se plante en 1h (Confirmé par LeoAnderson)

Pour moi il y a deux explications :

1. Cache Disque ou autres . Par exemple si on utilise HP StorageWorks Enterprise Virtual Array (EVA) quand je supprime des fichiers, des fois j'attends 1 heure pour que l'espace soit liberé.

2. Sous windows ca se plante et il n'utilise pas de semaphore. Alors il faut tester sur d'autres OS qui utilise les semaphores.
Chaque accès en ecriture sur un fichier de contrôle, un latch CF est imposé, si il est déja pris il va reessayer dans 15mn par defaut. Ca peut venir de la gestions des latch ou des semaphores entre la 8i et 9i/10g.

[LeoAnderson]

mais qu'est ce qui empêcherait Oracle d'avoir implémenté la possiblilité d'écrire dans le dictionnaire si les controlfiles ne sont pas là sans planter... et d'écrire dans les controlfiles dés qu'ils sont à nouveau dispo ?

c'est pas un bug, c'est une super évolution qui permet de pouvoir récupérer les controlfiles tant que la base n'est pas arrêter

Ben non, car pour restaurer les control files, tu es obligé d'avoir la base NOMOUNT !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
SQL> select * from v$controlfile;
 
STATUS
-------
NAME
--------------------------------------------------------------------------------
 
/oradata/toto/control01.ctl
 
 
/oradata/toto/control02.ctl
 
 
 
SQL> select distinct checkpoint_change# from v$datafile_header;
 
CHECKPOINT_CHANGE#
------------------
           6087785
 
SQL> !cp /oradata/toto/control01.ctl /oradata/toto/control01.ctl.ABK
 
SQL> alter system checkpoint;
 
System altered.
 
SQL> alter system switch logfile;
 
System altered.
 
SQL> alter system switch logfile;
 
System altered.
 
SQL> alter system checkpoint;
 
System altered.
 
SQL> alter system switch logfile;
 
System altered.
 
SQL> select distinct checkpoint_change# from v$datafile_header;
 
CHECKPOINT_CHANGE#
------------------
           6092384
 
SQL> !rm /oradata/toto/control01.ctl /oradata/toto/control02.ctl
 
SQL> alter system switch logfile;
 
System altered.
 
SQL> select distinct checkpoint_change# from v$datafile_header;
 
CHECKPOINT_CHANGE#
------------------
           6092391
 
SQL> !cp /oradata/toto/control01.ctl.ABK /oradata/toto/control01.ctl    
 
SQL> !cp /oradata/toto/control01.ctl.ABK /oradata/toto/control02.ctl    
 
SQL> recover database using backup controlfile until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01124: cannot recover data file 1 - file is in use or recovery
ORA-01110: data file 1: '/oradata/toto/system01.dbf'
 
 
SQL>

Donc si tu perd les control et que ta base reste open, t'es obligé de faire un shutdown abort suivi de startup mount...

[edit]
Bon là, je suis tombé sur un BUG magistral ... le doute n'est plus permis !
(pour rappel, à ce niveau, les fichiers de control existent mais ce ne sont qu'une restauration de copies physiques antérieures)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
SQL> create tablespace toto datafile '/oradata/toto/toto01.dbf' size 1M;
 
Tablespace created.
 
SQL> alter system checkpoint;
 
System altered.
 
SQL> drop tablespace toto including contents and datafiles;
 
Tablespace dropped.
 
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
 
Total System Global Area  538413768 bytes
Fixed Size                   731848 bytes
Variable Size             503316480 bytes
Database Buffers           33554432 bytes
Redo Buffers                 811008 bytes
Database mounted.
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/oradata/toto/system01.dbf'
ORA-01207: file is more recent than controlfile - old controlfile
 
 
SQL>

[bouyao]

Pour ton dernier exemple.
J’ai compris que tu a restauré des anciens fichiers de contôle avec la base démarrée.
Pour être sûre ce qui se passe sur le fichier de contôle, après la suppression du fichier de données, il faut faire un dump du fichier de contrôle et vérifie dans la section DATA FILE RECORDS si le fichier supprimé existe ou non.

[orafrance]

Ben non, car pour restaurer les control files, tu es obligé d'avoir la base NOMOUNT !

Oui mais tu peux générer le script de création des controlfiles avant le shutdown

Bon là, je suis tombé sur un BUG magistral ... le doute n'est plus permis !

si tu as copié les control files qui date d'avant les redos c'est normal non ?

[orafrance]

1. sur cetains OS sous 10g ca se plante tout de suite (j'ai donné deja une demonstration)
2. même sous Solaris ca se plante en 1h (Confirmé par LeoAnderson)

au temps pour moi, j'avais pas saisi cette subtilité

[pifor]

Que le fichier soit maintenu ouvert ou pas ne change rien à sa suppression qui elle intervient, c'est sûr.

Oui et non et à mon avis plutôt non: je cite une des références "Advanced Programming in the Unix Environement" de Richard Stevens qui dit explicitement à propos de l'appel système unlink qui sert à supprimer un fichier:

other conditions prevents the contents of a file from being deleted - as long as some process has the file open, its content will not be deleted. When a file is closed the kernel first checks the count of the number of processes that have the file open. If this count has reached 0 then the kernel checks the link count, and if it is 0, the file's contents are deleted".

Le fichier peut être supprimé mais toujours reste toujours accessible tant qu'un processus qui l'avait ouvert avant la suppression y accède: le fichier est supprimé et en même temps, il continue d'exister pour certains processus: c'est paradoxal mais cela semble normal sous Unix.

La différence de comportement entre Oracle 8i et 9i/10g peut venir d'un changement d'algorithme dans le code qui accède aux control files: il y avait peut-être plus de open/close pour les fichiers en 8i qu'en 9i/10g ? On pourrait éventuellement le vérifier en traçant les appels systèmes...

[orafrance]

alors là c'est bien vu... ça tient bien la route cette hypothése

[remi4444]

La différence de comportement entre Oracle 8i et 9i/10g peut venir d'un changement d'algorithme dans le code qui accède aux control files: il y avait peut-être plus de open/close pour les fichiers en 8i qu'en 9i/10g ? On pourrait éventuellement le vérifier en traçant les appels systèmes...

D'où le programme en C que j'avais proposé plus haut pour vérifier cette hypothèse...

[LeoAnderson]

D'où le programme en C que j'avais proposé plus haut pour vérifier cette hypothèse...

Il semblerait que ce soit cela mais le support refuse d'admettre que ne de pas fermer le fichier de contrôle (ce qui provoque cette abération dangereuse !) soit une anomalie ou un bug des versions 9i et 10g !

Solution de contournement : aucune