énorme Oracle Redo Logs

Question

À 22 heures chaque mardi tout d'un coup oracle génère des journaux énormes REDO jusqu'à ce que le disque manque d'espace. Mon application n'exécute pas d'énormes requêtes ou quoi que ce soit pendant cette période en fonction des journaux. La seule chose que je peux trouver est que la table dba_scheduler_job_run_details a démarré un job oracle juste à ce moment là. Je ne peux trouver aucune information sur google à propos de ce travail, donc je suis désespéré pour des idées.

Information de dba_scheduler_job_run_details:

JOB_NAME: ORA $ AT_SA_SPC_SY_254

STATUT: ARRÊTÉE

ACTUAL_START_DATE: 03/11/22 22: 00: 02,125060000 CST6CDT

RUN_DURATION 9: 4: 19,0

Answer 1

10PM est généralement le moment où commence la collecte automatique de statistiques. Bien qu'il fonctionne normalement tous les jours. Dans la collecte de statistiques 11g utilise des tâches automatiques au lieu du planificateur, essayez de rechercher le travail de statistiques avec une requête comme celle-ci: select * from dba_autotask_job_history order by window_start_time desc;

Mais même si le problème est causé par des statistiques, il semble étrange que cela causerait trop de REDO. Habituellement, la collecte de statistiques est beaucoup de lecture et une très petite quantité d'écriture. Sauf si vous avez beaucoup de petites tables qui changent tout le temps; dans ce cas, la quantité d'informations statistiques pourrait être beaucoup plus grande que les données réelles. Si c'est le cas, vous devrez peut-être rassembler les statistiques plus souvent, ou peut-être verrouiller les statistiques.

Ou peut-être que le processus de statistiques explose sur une table spécifique. Cela vous montrera quelle table a été analysée pour la dernière fois, peut-être vous donnera-t-elle un indice: select last_analyzed, dba_tables.* from dba_tables order by 1 desc nulls last;

Answer 2

Quelque chose génère un énorme REDOLOG, alors vous devez avoir une énorme activité DML. Par exemple script de nettoyage qui tente de purger certaines données, mais échoue, annule, puis essaie de faire la même tâche encore et encore et encore ...

La meilleure façon de prouver/réfuter vos doutes est le "Log outil de mineur ". Ce n'est pas trivial à utiliser, mais il vous dira quelles instructions (et par rapport à quelle table) ont généré la plus grande partie de la reprise et ce temps.