Bonjour à tous,
 
Je rencontre actuellement un probleme avec ma BDD ORACLE.
 
Un problème de taille de log.
 
Ma variable DB_RECOVERY_FILE_DEST_SIZE était défini a 50go.
 
J'ai un script batch sur le serveur qui vide les archive log superieur a 2 mois dans le dossier D:\oracle\flash_recovery_area\PGI\ARCHIVELOG
 
Jusqu'a hier tout allait bien. J'avais dans ce répertoire 5go de données. Sauf qu'a un moment problème sur ma base et impossible de la redémarrer.
 
Quand je faisais j'avais le message suivant :  
 
alter database open;
 ERROR at line 1:
ORA-16038 : Log 2 sequence# 2 cannot be archived
ORA-19809 : limit excedeed for recovery files
ORA-00312 : online log 2 thread 1: D:\ORACLE\ORADATA\PGI\REDO02.RDO
 
 
Je ne comprenais donc pas pourquoi elle ne voulais pas démarré alors que j'avais que 5go d'archive log present et que Ma variable DB_RECOVERY_FILE_DEST_SIZE était défini a 50go.
 
J'ai lu sur internet d'augmenter Ma variable DB_RECOVERY_FILE_DEST_SIZE.
 
Je l'ai donc fait et augmenter a 55go et la par magie ma base a redémarrer.
 
J'ai donc l'impression que malgré mon batch qui supprime les archives log physiquement sur la machine, il garde quelque part en mémoire l'espace occupé.
 
Ceci est génant car ca va augmenter sans jamais s'arreté...
 
Merci de votre aide si quelqu'un connais la mémoire a vider en plus de la suppresion des archives log supérieur a 2 mois.
 
 
 
 

Juste une petite remarque :  
le flashback database (qui repose sur les nouveaux paramètres DB_RECOVERY_FILE*) est une nouveauté de la 10g.
 
Là tu parles uniquement de l'espace pris par les redo logs archivés, mais la mise en place du flashback database génère également des fichiers journaux flashbacks. Ce sont peut etre eux qui, par leur volumétrie trop importante, ont explosé ton seuil de 50Go. Regarde dans ton répertoire, au même niveau que Archivelog, il doit y avoir un autre rép qui contient ces fichiers.
 
Par contre, as tu réellement besoin du flashback database ?  
Si ce n'est pas le cas, tu peux le désactiver, tu reviens alors à une gestion plus simple des redos archivés, sans utiliser les paramètres DB_RECOVERY_FILES* . Tu as juste à faire en sorte d'avoir assez de place dans ton filesystem (ou ton disque si tu es sous Win) pour accueillir tes archivelogs.
 
Au passage, je ne comprends pas ta nécessité de conserver 2 mois d'archivelogs. Tu ne fais pas des sauvegardes full régulièrement, une fois par semaine ou au moins par mois ?

+1 pour les archivelogs : si tu ne les utilises pas, désactives les
si tu les utilises, fais régulièrement une sauvegarde et purge par la suite : avec RMAN tu peux faire une purge des archivelogs après un backup

  je ne remets pas en cause l'utilisation des archivelogs, surtout si il s'agit d'une instance de production.
 
Je parlais de désactiver le flashback database si il n'est pas utilisé...

enfin bon, supprimer les archivelog qui ont plus de 2 mois sans avoir de sauvegarde sur laquelle repartir et appliquer les archivelog, c'est pas trop utile, alors tant qu'à faire autant les désactiver ca fera gagner de la place et économisera sur les scripts rustines qui gravitent autour