Version imprimable
Bonjour à tous,
J'ai un problème sur une base 9.2.0.7 (Red Hat 4).
La BD est en mode ARCHIVELOG, elle génére habituellement 3 à 4 Go d'archive par semaine et depuis 3 ou 4 semaines je me retrouve avec plus de 20 Go / semaine.
A ma connaissance, aucune modification sur la structure de la BD, le volume d'activité est faible, les connexions peu nombreuses.
Je ne vois pas ce qui peut générer autant de redo.
Quelqu'un a t'il déjà rencontré ce problème ?
Par avance, merci pour les réponses.
si tu as autant d'archive log autant s'en servir :) http://helyos.developpez.com/logminer/
je vois pas trop le rapport avec la question initiale ?Citation:
Envoyé par couak
pour ma part je pense tout de même qu'un paramétre de l'instance à été modifié tel que :
log_checkpoint_interval
tu devrais augmenter cette valeur pour avoir un switch log régulier
dans la documentation Oracle recommande 30 min pour la grande majorité mais cela peut différer par rapport à ta base
tu peux arriver à des points de reprise toutes les 2H si tes fichiers de journalisation sont volumineux et que tu n'observent pas d'attentes particulières ou des pbs de checkpoint incomplete
sinon un autre paramétre a pu etre modifié, il s'agit de fast_start_mttr_target
si une valeur très faible de recouvrement après un restart à été fixée alors oracle va ajuster l'intervalle des switch logs et d'autres choses d'ailleurs
BonjourCitation:
Envoyé par PpPool
A mon avis, la suggestion de Couak est conceptuellement plus pertinente que les vôtres vis à vis de la question posée.
Pour savoir ce qui a généré tant d'archives, rien de mieux que de regarder dedans, mais ça peut être spécialement fastidieux.
En revanche, les paramètres LOG_CHECKPOINT_INTERVAL ou FAST_START_MTTR_TARGET n'ont aucune influence sur le volume d'archives généré, ni d'ailleurs sur la fréquence de rotation des journaux REDO.
L'un comme l'autre vont conduire à des points de synchronisation (checkpoint), c'est à dire des écritures dans les fichiers de données, plus ou moins fréquents.
En outre, même si un paramètre quelconque provoquait des SWITCH LOGFILE plus fréquents, cela n'aurait aucune incidence sur le volume, car un fichier d'archives n'occupe que l'espace utile. Si on a des REDO de 100 M et qu'on provoque un switch avant qu'il ne soit plein, l'archive ne fera pas 100 M, mais juste le volume utile compte-tenu du remplissage du REDO.
Une piste à explorer : la journalisation étendue.
Il est possible qu'on ait passé sur la base une commande du type
Il existe différentes colonnes SUPPLEMENTAL_LOG_xxx dans V$DATABASE pour le vérifier.Code:ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Par exemple :
Code:select supplemental_log_data_min from v$database;
J'ai connu un cas similaire, une application s'est mise à générer beaucoup d'erreur de violation de clé unique , le nombre et la taille des archivelog avaient considérablement augmenté pendant cette période.
Bonjour à tous,
De retour aprés quelques jours d'abscence.
Merci pour vos réponses.
Aprés analyse sous Logminer, beaucoup d'activité sur une table par une application. Demande de contrôle du bon fonctionnement de l'application.
Je vous informerai de la suite.
Merci encore.
Bonjour,
Est-ce que par hasard il n'y aurait pas des tablespaces restées en 'begin backup' ?
Cordialement,Code:select * from v$backup where status ='ACTIVE';
Franck.
Bonjour à tous,
J'ai trouvé l'origine du problème aprés examen, il est vrai fastidieux, avec logminer.
Une application clientèle essaye d'insérer toutes les minutes des milliers de lignes dans une table mais certaines contraintes ne sont pas respéctées donc rejet.
Merci pour votre aide, je clôture.
Est ce que quelqu'un sait pourquoi un insert qui échoue génére plus de redo qu'un insert qui reussi ?
Ou alors est ce juste les applications, globalement mal concues, qui s'entêtent à toujours tenter d'insérer les lignes eronées, générant ainsi une infinité de requêtes/transactions ?
Bonjour,
Merci pour le feedback.
Effectivement, le rejet de milliers d'insert est très couteux:
- les modifications sont effectuées -> generation de redo
- les modifications sont rollbackées -> génération de redo
- en plus chaque exception va lire le dictionnaire pour récupérer le nom de la contrainte
Cordialement,
Franck.