Discussion :

[coco-sup]

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 !!

[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 ...

[Wurlitzer]

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

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.

[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...

[bouyao]

A lire: http://mbouayoun.developpez.com/fichredo/#LI.1.2

[Wurlitzer]

oui et non

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

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

[pifor]

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

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 ?

[bouyao]

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.

[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

[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

[pifor]

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

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.

[Wurlitzer]

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.

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

[bouyao]

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)

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)

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.

[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.

[coco-sup]

Pendant que j'y suis, je me demandais si une transaction non commitée possédait un SCN dans les redo ?

[pifor]

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

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

[coco-sup]

ok merci, c'est ce que je pensais !

je boucle le sujet, j'ai mes réponse

[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

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)

[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:

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

[bouyao]

J'ai dit en géneral :

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