probleme de checkpoint not complete Oracle 8.1.7 [Résolu]

[sanomory]

Bonjour,
J'administre une BD Oracle 8.1.7 et ge constate ke g assez de "checkpoint not completed" dans le fichier alert. J'ai lu la doc oracle et g n'arrive pas à m'ensortir, la durée entre deux checkpoints successifs n'atteint pas 2s et meme des fois le second checkpoint commence tandis que le premier n'est pas terminé. j 'ai pensé à augmenté la taille de mon fichier redolog de 1024 k à 30 Mo en vain.
je vous communique certains parametres de mon fichier init:

open_cursors = 300
max_enabled_roles = 120
db_file_multiblock_read_count = 8

db_block_buffers = 38497
db_block_max_dirty_target = 38497
db_block_size = 8192

shared_pool_size = 105123942
shared_pool_reserved_size = 5256197

large_pool_size = 614400
java_pool_size = 0

log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800

log_checkpoints_to_alert=true
processes = 150

parallel_max_servers = 5

log_buffer = 32768

timed_statistics=true

J'espere ke ces parametres vous seront utiles. Merci d'avance

[Michel SALAIS]

Combien de fihciers redo log?
Vous dites le fichier redo log. Ceci veut dire qu'un seul fichier redo log a été agrandi?

Enlevez pour le moment le paramètre log_checkpoint_interval du fichier init.ora

[Marc Musette]

au moment où un log switch se fait, les données présent dans le redo log (qui va être écrasé par le switch), doivent être écrites dans les data files
-> c'est ce qu'on appelle un checkpoint (pas besoin de rejouer les redo antérieur à ce checkpoint en cas d'instance recovery)

une des raisons pour lesquelles le checkpoint prend du temps (et empêche donc le log switch, ce qui "freeze" la db) et bien c'est justement la taille des redo (plus il y a de redo à écrire dans le datfile , plus ça prend du temps !!!

--> il ne faut surtout pas travailler avec des redo trp grannd (mais 30mg c'est pas grand du tout )

par contre , il vous suffit d'ajouter autant de redo logs nécessaires pour que ce message disparaîsse

[Michel SALAIS]

Envoyé par Marc Musette

au moment où un log switch se fait, les données présent dans le redo log (qui va être écrasé par le switch), doivent être écrites dans les data files
-> c'est ce qu'on appelle un checkpoint (pas besoin de rejouer les redo antérieur à ce checkpoint en cas d'instance recovery)

une des raisons pour lesquelles le checkpoint prend du temps (et empêche donc le log switch, ce qui "freeze" la db) et bien c'est justement la taille des redo (plus il y a de redo à écrire dans le datfile , plus ça prend du temps !!!

--> il ne faut surtout pas travailler avec des redo trp grannd (mais 30mg c'est pas grand du tout )

par contre , il vous suffit d'ajouter autant de redo logs nécessaires pour que ce message disparaîsse

En fait, la taille des fichiers redo log est dictée par l'activité sur la base en premier lieu. Si le fihcier redo log est trop grand alors le mécanisme des checkpoints graduels, qui depuis 9i peut se faire grâce au paramètre fast_start_mttr_target, permet de régler cette question.

Si on veut être général et "correct" en même temps alors il faudrait dire :
La taille des fichiers redo log ne doit pas être très petit afin d'éviter justement le message "checkpoint not complete" ni très grand de telle sorte qu'il dure plus de 15-20 minutes lors de l'activité "normale" de la base

[sanomory]

Merci pour toutes ces precisons.
En effet, g 3 groupes contenant chacun 1 fichier redo log de 1 Mo, ce ki est fait par defaut à la créetion d'une base oracle 8i.
A propos de la durée ki doir s'ecouler entre les checkpoints successifs ki doit être entre 15 - 20 minutes, sur kel parametre du fichier init g dois utiliser afin de donner une taille acceptable à mes fichiers redo log. realtivement à la solution d'augementer le nombre de redo log, g vais experimenter ce cas et g vous apporterait les constats.

ou plus clairement, comment savoir les temps des checkpoints de ma base ds mon fichier Alert.log?
ceci permettra de faire la difference des temps de checkpoints successifs.



merci

[Marc Musette]

Michel,

je suis d'accord avec toi sur l'utilité du paramètre FAST_START_MTTR_TARGET, ainsi que la durée moyenne que doit tenir un log.

néanmoins faut-il encore mettre une valeur correcte pour ce paramètre car nous savons qu'il a un impact sur les performances

j'aime bien l'idée simple d'avoir plusieurs redo logs (on évite les checkpoint not complete, on perd moins d'activité en cas de perte du redo en cours, on se casse pas la tête pour savoir quoi mettre comme valeur dans fast_start_mtr_target ou log_checkpoint_interval etc)

[Marc Musette]

et surtout concernant fast_start_mttr_target, il n'est dispo qu'à partir de 9i (et le post fait référence à une 8i -> si tu ne veux pas utiliser les paramètres LOG_CHECKPOINTblabla, tu n'as beaucoup d'autres possibilités que de jouer sur le nombre de redo

[Michel SALAIS]

Bonjour Marc,

Mon intervention visait un point particulier qui est la taille des fichiers redo log. Je pense que cette taille dépend vraiement de l'activité sur la base en premier lieu. et du coup petit ou grand devient très relatif ...

Il y a bien sûr plein de choses à dire sur les checkpoints et les fichiers redo log ...