Forcer le checkpoint des redo logs

[ledub10]

Bonjour à tous ,
Je suis en version standard d'Oracle 10g et j'aimerai trouver le parametre qui permet de switcher automatiquement de logs toutes les 30 min environ

le probleme est que le parametre FAST_START_MTTR_TARGET n'a pas la meme signification qu'en version Enterprise
merci de votre aide

[ojo77]

Le paramètre LOG_CHECKPOIN_TIMEOUT doit répondre à votre souhait.

[orawiss]

Bonjour,
Sous Oracle 10g, les paramètres log_checkpoint_interval/timeout sont obsolètes, Il faut utliser le paramètre FAST_START_MTTR_TARGET. Aussi, pour jouer sur les checkpoints, vous pouvez jouer sur les tailles de groupes de redolog en ligne, c'est la taille des groupes de redolog qui imploiquent le DBWR d'ecrires les "dirty buffer blocks" sur disque.

Un autre paramètre aussi à tenir en compte est le nombre de processus DBWR, DB_WRITER_PROCESSES

[Heaven93]

c'est le paramètre ARCHIVE_LAG_TARGET qu'il convient de positionner (à 1800 pour un switch toutes les 30 minutes)

[ledub10]

Envoyé par orawiss

Bonjour,
Sous Oracle 10g, les paramètres log_checkpoint_interval/timeout sont obsolètes, Il faut utliser le paramètre FAST_START_MTTR_TARGET. Aussi, pour jouer sur les checkpoints, vous pouvez jouer sur les tailles de groupes de redolog en ligne, c'est la taille des groupes de redolog qui imploiquent le DBWR d'ecrires les "dirty buffer blocks" sur disque.

Un autre paramètre aussi à tenir en compte est le nombre de processus DBWR, DB_WRITER_PROCESSES

meme en standard ? car le fast recovery n'est pas actif en SE

[ledub10]

Envoyé par Heaven93

c'est le paramètre ARCHIVE_LAG_TARGET qu'il convient de positionner (à 1800 pour un switch toutes les 30 minutes)

oui dans le cas des archive log

[Pomalaix]

Envoyé par ledub10

Bonjour à tous ,
Je suis en version standard d'Oracle 10g et j'aimerai trouver le parametre qui permet de switcher automatiquement de logs toutes les 30 min environ

le probleme est que le parametre FAST_START_MTTR_TARGET n'a pas la meme signification qu'en version Enterprise
merci de votre aide

"Forcer le checkpoint des redo logs" ? Tout ça n'est pas très clair...
Voulez-vous réellement forcer un "checkpoint" (écriture dans les fichiers de données des blocs modifiés en mémoire) ?
Ou bien changer de fichier redo log courant ?

Et surtout, quel est l'objectif fonctionnel qui se cache là-dessous ?

[ledub10]

Envoyé par Pomalaix

"Forcer le checkpoint des redo logs" ? Tout ça n'est pas très clair...
Voulez-vous réellement forcer un "checkpoint" (écriture dans les fichiers de données des blocs modifiés en mémoire) ?
Ou bien changer de fichier redo log courant ?

Et surtout, quel est l'objectif fonctionnel qui se cache là-dessous ?

et bien actuellement nous avons des redo de 5 Mo sur toutes nos instances
certaines instances font 15 switch par h , d'autres 2 par jour
dans le cas ou l'ideal est de switcher toutes les 30 min, je cherche une solution pour le faire
je veux bien tailler les redo en fonction de l'activité mais je ne suis pas sur que ca soit suffisant
de plus , je suis en standard edition , donc l'advisor mttr ne fonctionne pas
voila , pour clarifier la situation

[Pomalaix]

Envoyé par ledub10

je veux bien tailler les redo en fonction de l'activité mais je ne suis pas sur que ca soit suffisant

Si, pas de souci ! Là pour le coup, il n'y a pas à aller chercher des paramètres alambiqués.

Par contre, quand vous dites "FAST_START_MTTR_TARGET n'a pas la meme signification qu'en version Enterprise", vous pouvez être plus précis ?

Ce paramètre définit la durée maximale souhaitée de la phase de récupération lors du redémarrage qui suit un plantage de l'instance (ou SHUTDOWN ABORT).
Cette récupération consiste à identifier le décalage de transactions entre les fichiers de données et les fichiers REDO, et à le corriger. En clair, on prend dans les fichiers REDO les informations manquantes, et on les répercute dans les fichiers de données.
Plus il y a de décalage, et plus la durée de récupération est longue.
Le décalage peut être grand si les fichiers REDO sont très gros : dans le pire des cas, les écritures dans les fichiers de données ne se font que lors d'un changement de fichier REDO, celui-ci étant plein.
Un FAST_START_MTTR_TARGET bas a pour effet de rendre plus fréquentes les écritures dans les fichiers de données, et donc de limiter le décalage potentiel.

En passant, la durée de redémarrage ne dépend pas que du temps d'application des transactions manquantes. Elle dépend aussi beaucoup de la taille des transactions. Si la base a planté en plein milieu d'une transaction monstrueuse, il y a aura une phase d'annulation qui devra se faire au redémarrage. Cette phase est incontournable et non paramétrable : FAST_START_MTTR_TARGET n'a aucun effet sur elle.