status des groupes de redo log online

Version imprimable

Voir 40 message(s) de cette discussion en une page

21/08/2006, 18h31
coco-sup

status des groupes de redo log online

Bonjour !

J'ai une question concernant les groupes de redo log online.
Je ne comprend pas pourquoi le status de certains groupe passe à ACTIVE.
J'ai compris le status INACTIVE et CURRENT, et j'ai compris que le groupe marqué ACTIVE serait utilisé pour une eventuelle restauration. Voila mon problème... il me semble qu'avant que l'on de switch de groupe un checkpoint était initié pour que la base soit consistente, donc je ne comprend pas pourquoi le groupe précédent est marqué ACTIVE. Selon moi, le groupe CURRENTserait suffisant pour une restauration.

Exemple : mon groupe 2 est CURRENT et se remplit à fond. Un checkpoint est amorcé et tous les fichiers de données sont mise a jour avec le SCN 1000 par exemple. Oracle switch sur le groupe 3 et reprend au SCN 1001.
Admettons que l'instance crash, pourquoi le groupe 2 serait il nécessaire alors qu'il nous suffirait d'appliquer les Redo log a partir de 1001 ?

merci !! ;)
22/08/2006, 09h12
pifor

Peut-être qu'une transaction a des données redo à cheval sur 2 redo logs groups: le début sur l'ACTIVE et la fin sur le CURRENT ? Cela dépendrait de la taille de la transaction et de la gestion interne de l'espace dans un redo lo group. Ce n'est qu'une hypothèse et je sais pas si le LogMiner ou un autre outil permet d'aller à ce niveau de détail. On pourrait imaginer un test spécial en essayant de créer un redo log group le plus petit possible et une transaction avec un volume de redo très important ...
22/08/2006, 09h39
Wurlitzer

http://download-east.oracle.com/docs...htm#sthref3725

Citation:

INACTIVE - Log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived.

Tu as raison après le switch toutes les informations COMMITEs sont écrites dans les DBF. Tu n'as donc plus besoin des REDO pour une restauration d'instance (panne électrique par exemple qui fait que des informations COMMITE pourrait ne pas avoir encore été écrite dans les DBF).

Par contre tu peux en avoir besoin si tu perds un DBF (et donc ce qui est écrit dedans) et que tu veux le restaurer à partir d'une sauvegarde.

A mon tour de poser une question : Combien de temps un REDO reste au statut ACTIVE.

En Archive LOG, J'imagine que c'est jusqu'à ce que le REDO soit archivé mais en NOARCHIVELOG. Je sais pas trop.
22/08/2006, 09h55
coco-sup

merci pour ces réponses, de mon coté j'ai fais des tests et j'en ai conclu que le status ACTIVE passait a INACTIVE lors d'un checkpoint (un log_checkpoint_interval ou time_out ou fast_start_mttr_target).
Selon moi il n'y a pas de checkpoint effectué au moment d'un log switch...
22/08/2006, 10h11
bouyao

A lire: http://mbouayoun.developpez.com/fichredo/#LI.1.2
22/08/2006, 10h14
Wurlitzer

oui et non

http://www.akadia.com/services/ora_c...nt_tuning.html

Citation:

A checkpoint is realized on five types of events:

*At each switch of the redo log files
*When the delay for LOG_CHECKPOINT_TIMEOUT is reached.
*When the size in bytes corresponding to:
(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)
is written on the current redo log file.
*Directly by the ALTER SYSTEM SWITCH LOGFILE command.
*Directly with the ALTER SYSTEM CHECKPOINT command
22/08/2006, 10h16
pifor

C'est clair. D'après: http://asktom.oracle.com/pls/ask/f?p...A:283015939157

Citation:

A log switch is when we fill up one online redo log and goto the next. A log switch will always initiate a CHECKPOINT (it always starts a checkpoint going).

Vous avez peut-être des warnings lors du switch de log ou du checkpoint dans l'alert.log ?
22/08/2006, 10h33
bouyao

Citation:

Envoyé par Wurlitzer

Tu as raison après le switch toutes les informations COMMITEs sont écrites dans les DBF.

C'est Faux.

Après un COMMIT Oracle n'écrit pas automatiquement les données dans les fichiers de données. C'est pour cela que tu a un fichier redo active.
22/08/2006, 11h05
coco-sup

ok maintenant je suis sur qu'il y a un checkpoint avant le logswitch.
Donc pourquoi le groupe précédent est necessaire pour la restauration ?
je reprend mon exemple :
le groupe CURRENT est plein et le dernier SCN est a 500 par exemple.
un checkpoint est effectué (DBWR ecrit tous les dirty blocks dans les datafiles).
A ce moment la, tous les fichiers de données et le fichier de controle possède le meme SCN qui est de 500.
le logswitch est opéré et le groupe suivant devient CURRENT et reprend le SCN à 501.

Donc si je comprend bien le groupe précédent est ACTIVE pour la restauration, mais je ne vois pas pourquoi on aura besoin des SCN < 500 si l'instance crash ?!
Pour la restauration il suffira de reprendre a 501 non ?

c'est un peu tordu peut etre ;)
22/08/2006, 11h36
bouyao

Un commit ne consiste pas à écrire automatiquement les blocs modifiés dans les fichiers de données (datafiles)

Un checkpoint consiste à écrire les données dans les fichiers REDOLOG et n'ont pas dans les fichiers de données (DATAFILES) (C'est faux)

c'est le processus CKPT qui conssite à écrire les données suite à un CHECKPOINT et n'ont pas le DBWR
C'est faux : il signale seulement au DBW d'écrire dans les fichiers de données
22/08/2006, 12h05
pifor

Citation:

Un checkpoint consiste à écrire les données dans les fichiers REDOLOG et n'ont pas dans les fichiers de données (DATAFILES)

c'est le processus CKPT qui conssite à écrire les données suite à un CHECKPOINT et n'ont pas le DBWR

Ce n'est pas ce que dit le Concepts Guide http://download-uk.oracle.com/docs/c...intro.htm#3529

Citation:

Checkpoint (CKPT)
At specific times, all modified database buffers in the SGA are written to the datafiles by DBWn. This event is called a checkpoint. The checkpoint process is responsible for signaling DBWn at checkpoints and updating all the datafiles and control files of the database to indicate the most recent checkpoint.
22/08/2006, 12h08
Wurlitzer

Citation:

Envoyé par bouyao

C'est Faux.

Après un COMMIT Oracle n'écrit pas automatiquement les données dans les fichiers de données. C'est pour cela que tu a un fichier redo active.

Comment ca c'est faux ? D'apres ce que j'ai compris :

Après un COMMIT toutes les informations sont écrites dans les REDO.

Après un checkpoint Oracle synchronise les DBF avec les REDO et donc toutes les valeurs commitées dans les REDO sont écrites dans les DBF.

C'est même l'intérêt du Checkpoint. C'est a dire avoir des DBF propres qui ne nécessitent pas d'appliquer trop REDO et donc évite un temps de restauration trop important.

Citation:

Envoyé par coco-sup

Donc si je comprend bien le groupe précédent est ACTIVE pour la restauration, mais je ne vois pas pourquoi on aura besoin des SCN < 500 si l'instance crash ?!
Pour la restauration il suffira de reprendre a 501 non ?

Parce que tu peux avoir un crash d'un datafile et non pas de l'instance. Et donc meme si le DBF est bien synchronisé avec ton SCN à 501 cela ne te sert a rien puisque ton BDF est mort. Dans ce cas tu pars de la dernière sauvegarde de ton DBF (par exemple SCN 498) et tu appliques (Media Recovery) les Redo pour remonter jusqu'au SCN 501
22/08/2006, 12h26
bouyao

Citation:

Envoyé par Wurlitzer

Après un COMMIT toutes les informations sont écrites dans les REDO.

Ce que j'ai dit avant. Après un commit Oracle écrite dans les fichiers redo et n'ont pas dans les fichiers de données (DATAFILES)

Citation:

Envoyé par Wurlitzer

Après un checkpoint Oracle synchronise les DBF avec les REDO

C'est vrai, Surtout il synchronise le buffer cache avec les fichiers de données (DATAFILES)

Citation:

Envoyé par pifor

Citation:

Checkpoint (CKPT)
At specific times, all modified database buffers in the SGA are written to the datafiles by DBWn. This event is called a checkpoint. The checkpoint process is responsible for signaling DBWn at checkpoints and updating all the datafiles and control files of the database to indicate the most recent checkpoint.

CKPT signale au process DBWR d'écrire les données depuis les redo vers les datafiles

A savoir :

Le checkpoint se réalise sous quatre types d'évènements :

* Quand le delai de LOG_CHECKPOINT_TIMEOUT est atteint.
* Quand la taille en byte de (LOG_CHECKPOINT_INTERVALL * taille d'E/S des blocs OS) est écrite dans le fichier redo en cours.
* Directement par la commande ALTER SYSTEM SWITCH LOGFILE.
* Directement par la commande ALTER SYSTEM CHECKPOINT.

Le checkpoint doit être rompus dans deux cas spécifiques :

* Le DBWR écrit les tampons modifiés de la cache dans les fichiers de données.
* Le LGWR met à jours l'entête des fichiers de données et le fichier de contrôle.

Quand LGWR effectue cette tâche, il ne peut pas faire son travail normalement, qui consiste à écrire les transactions dans les fichiers redo. Un process spécifique CKPT doit être utiliser pour liberer le LGWR de cette tâche. A partir de la version Oracle8 le process CKPT démarre automatiquement.

Quand une restauration est nécessaire suite à un crash de l'instance, seulement les transactions écrites depuis le dernier checkpoint qui sont appliqués.

Il y'a deux types de checkpoints :

* Checkpoint normal
* Checkpoint incremental

Le checkpoint normal met à jours les fichiers de contrôle et les entêtes des fichiers de données

Le checkpoint incremental met à jours seulement le fichier de contrôle.
22/08/2006, 14h16
coco-sup

merci ces précisions, mais je ne suis pas d'accord avec toi Wurlitzer. Tu dis que le groupe ACTIVE sera utilisé en cas de corruption ou de perte d'un fichier... dans ce cas, pourquoi lorsque l'on fait un checkpoint (alter system checkpoint) le groupe précédent devient INACTIVE et donc inutile a la restauration ??
on peut toujours perdre un fichier et pourtant le groupe qui sera utilisé pour la restauration sera le groupe CURRENT.
22/08/2006, 16h17
coco-sup

Pendant que j'y suis, je me demandais si une transaction non commitée possédait un SCN dans les redo ?
22/08/2006, 16h34
pifor

Probablement oui puisque d'après le paragraphe Undo Records de http://download-uk.oracle.com/docs/c...ntro.htm#50859

Citation:

During database recovery, Oracle applies all changes recorded in the redo log and then uses undo information to roll back any uncommitted transactions.
22/08/2006, 16h36
coco-sup

ok merci, c'est ce que je pensais !

je boucle le sujet, j'ai mes réponse ;)
22/08/2006, 17h31
bouyao

Désolé je ne suis pas d'accord.

(En general) Tant que la transaction n'est pas commité il n y'a pas écriture dans le fichier redo log.

1. un client fait une mise à jours (UPDATE) sur une table t1.
2. le processus serveur obtient un SCN et lit les blocs de données
3. le serveur enregistre un verrou ligne sur le bloc de donnée
4. le processus serveur copie l'ancien image dans le rollback segment et modifie la donnée de la table t1.
5. le processus serveur enregistre les changements des rollback segments et le bloc de donnée dans le redo log buffer (SGA)
6. le client fait un COMMIT
7. LGWR écrit les informations redo de la transaction en entier, y compris le scn, du redo log buffer vers le fichier redo courant.
Quand l'OS confirme que l'écriture dans le fichier redo est achevé, alors la transaction est consideré comme commité.
8. le processus serveur envoie un message au client pour lui confimer le COMMIT.

dans

Citation:

During database recovery, Oracle applies all changes recorded in the redo log and then uses undo information to roll back any uncommitted transactions.

Oracle applique les changements enregistré dans le redo log (transactions commités)
22/08/2006, 18h16
pifor

D'accord pour le cas général du COMMIT. Mais que se passe-t-il lorsqu'on fait ROLLBACK ou s'il y a un crash ? Je ne sais pas exactement tout ce qui se passe en détail mais il peut bien y avoir des données de transactions qui n'ont pas encore fait COMMIT dans les redo logs puisque Oracle le documente et que Tom Kyte le confirme au moins dans le cas particulier où le volume du redo d'une transaction est supérieur à la taille du log buffer cache:

Citation:

That is one SIMPLE case -- there are lots of other reasons but that one is sufficient to understand the need to have committed and uncommitted transactions logged in the redo log files.

Voir http://asktom.oracle.com/pls/ask/f?p...:6382861028572
22/08/2006, 18h27
bouyao

J'ai dit en géneral :

Citation:

Les enregistrements redo peuvent aussi être écrits dans le fichier redo avant que la transaction correspondante soit validée. Si le buffer redo log est plein ou une autre transaction à été validée, LGWR vide toutes les entrées redo du buffer redo log dans le fichier redo, bien que certain enregistrements redo ne devrait pas être validés. Si nécessaire, oracle peut annuler ces changements.

Voir : http://mbouayoun.developpez.com/fichredo/#LI.1.1

Voir 40 message(s) de cette discussion en une page