SCN et RBA

Bonjour ,
J'ai lu avec intérêt l'article de Bouyao trés technique : Le SCN ,
Justement j'aurai voulu savoir comment à partir d'information sur le fichier trace de bases de données récupéres de quel(s) fichier(s) ils s'agit :

Citation:

---

Completed checkpoint up to RBA [0x421.2.10], SCN: 0x0000.1f74a4ce

---

Cela suite à un shutdown immediate qui n'a pu se faire.

Oracle 8174
Hp UX

Jaouad

Bonjour Jaouad,

RBA : Adresse du bloc journal (redo)

Les entrées recentes dans le redo thread d'une instance oracle ont une adresse appelé RBA (Redo Byte Adsress) qui est constitué de trois parties :

Le numéro de séquence du fichier journal (4 bits)
Le numéro du bloc du fichier journal (4 bits)
Offset de ce bloc (2 bits)

L'emplacement de chaque entrée redo log est identifié par le RBA. Ils sont tres utiles pour les blocs modifiés dans le buffer cache.

Les RBA ne sont pas nécessairement unique dans leurs thread, puisque le numéro de sequence du fichier journal peut être mis à 1 dans tous les thread si la base est ouverte avec l'option RESETLOGS.

Dans ton exemple : RBA = 421.2.10

Donc le numéro de sequence du fichier journal est 421

Il suffit de voir dans la vue V$LOG_HISTORY

Code:

---

SQL> select sequence#,first_change#,next_change#,resetlogs_change# from v$log_history;

---

Comme j'ai dit avant si il y'a un resetlog le numéro de sequence s'initialise à 1

Merci Bouyao pour cette réponse ,
j'ai donc indentifié le fichier REDO ainsi :

Code:

---

1 2	select sequence#,first_change#,next_change#, from v$log_history where sequence#=421;

---

J'ai donc obtenu le RECID et je pensais ainsi que je pourrais retrouver le fichier d'achive en question ,
mais le probléme c'est que ce fichier est antérieur (08/2005) au probléme ( hier )

Est ce que je me suis trompé dans la méthodo.


Jaouad,

Peut être le fichier log n'est pas encore archivé ou (encore dans le buffer redo log)

Essaye de voir dans le fichier log non encore archivé
c'est quoi la denière sequence des tes fichiers logs ?

Si ca date de 8/2005 veut dire que tu a fait un resetlog entre temps

Erreur de ma part :
142 est en hexa il faut le convertir en décimal

Code:

---

1 2 3 4 5 6 7

SQL> select to_number('142','xxxx') from dual;   TO_NUMBER('142','XXXX') ----------------------- 322   SQL>

---

donc numéro de sequence est 322

Oui mais le resetlogs s'accompagne de la re création de fichiers de contrôle afin de purger la vue v$archived_logs notamment .

D'ailleurs cela se vérifie si je fais :

Code:

---

1 2	SELECT COUNT (*) FROM v$archived_log WHERE SEQUENCE#=1

---

La réponse est 1 est non pas deux ou plus .

L'identifant unique est dans ce cas RECID

Code:

---

1 2 3 4 5 6 7

SQL> select to_number('421','xxxx') from dual;   TO_NUMBER('421','XXXX') ----------------------- 1057   SQL>

---

Je suis un peu fatigué aujourd'huit

DONC c'est 1057

Citation:

---

Envoyé par Jaouad

Oui mais le resetlogs s'accompagne de la re création de fichiers de contrôle afin de purger la vue v$archived_logs notamment

---

Je pense pas, car on peut faire un restlog sans recréer le fichier de contrôle

Effectivement c'est le bon fichier ,

Merci pour la réponse et :bravo:

tu voit t'es pas aussi fatigué que ca :wink:

Jaouad