10 dic 2009

Por que los Archived logs estan tambien en mi Flash recovery area !!!

En este post dejo el problema que nació cuando el alertlog marcaba lo siguiente:
>Sun Dec  6 22:21:51 2009
Errors in file $ORACLE_BASE/admin/SID/bdump/SID_arc0_21083.trc:
ORA-19815: Message 19815 not found; No message file for product=RDBMS, facility=ORA; arguments: [db_recovery_file_dest_size] [2147483648] [100.00] [0]
Sun Dec  6 22:21:51 2009
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
Sun Dec  6 22:21:51 2009
Errors in file /u01/app/oracle/admin/rpi10g2/bdump/SID_arc0_21083.trc:
ORA-19809: Message 19809 not found; No message file for product=RDBMS, facility=ORA
ORA-19804: Message 19804 not found; No message file for product=RDBMS, facility=ORA; arguments: [43593728] [2147483648]
ARC0: Error 19809 Creating archive log file to '$ORACLE_BASE/flash_recovery_area/SID/archivelog/2009_12_06/o1_mf_1_482_0_.arc'
Investigando un poco me encontré que el área de flash_recovery estaba llena por lo que decidi agrandarla pasa solucionar el problema momentaneamente.
SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE= 3000M;
Al no haber setado ninguna politica de RMAN debia encontrar a que se debia esto
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;



FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG 60.16 0 62
BACKUPPIECE 0 0 0
IMAGECOPY 0 0 0
FLASHBACKLOG 0 0 0


Efectivamente RMAN estaba backpeando los arclogs. Esto se refleja en LOG_ARCHIVE_DEST_10.

select dest_name,destination from V$ARCHIVE_DEST
where status ='VALID'

LOG_ARCHIVE_DEST_1 $ORACLE_BASE/backup/arc
LOG_ARCHIVE_DEST_10 USE_DB_RECOVERY_FILE_DEST
Para resolver esta situación solo hay que setear lo siguiente:

SQL> alter system set log_archive_dest_10='' scope=spfile;

Como el alcance es el spfile debemos reiniciar la base para que tome el cambio. Una vez reiniciada veremos que el  log_archive_dest_10 es vacio y que los arclog se guardan en la unibicacion que seteamos en el  log_archive_dest. 
Esto no es todo, ¿ como libero el area de flash_recovery que ya ha sido utilizada?
Pues asi:

#>rman target sys/password@SID

RMAN> delete noprompt archivelog all;

Si hemos borrado archivos desde el sistema operativo de la area flash_recovery RMAN nos avisara que no puede borrar estos ya que no existe. Para sincronizar lo que hay en el filesystem con RMAN procedemos asi:
RMAN> crosscheck archivelog all;

Una vez realizado este paso vemos los resultados:

SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;

FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE
     0
0
0
ONLINELOG      0 0
0
ARCHIVELOG
     0
0
0
BACKUPPIECE      0 0
0
IMAGECOPY
     0
0
0
FLASHBACKLOG
     0
0
0

6 rows selected.
Y listo problema resuelto.






Referencias:


Oracle Comunidad Hispana

Archived Redo Log Creation in the Flash Recovery Area































5 dic 2009

EM database console not start

Acabo de trasladar una base de datos de un server virtual (Vmware) a uno fisico, por el problema de hora que comentaba mi post anterior. Como siempre, estas cosas son a las apuradas, por lo que solo instale el motor base de datos Oracle10g con todas las opciones necesarias y me traje todos los datafiles , controfiles, arclogs de la otra base. Si, a lo mejor no es el mejor método perooo funciona, copy y paste a full. La base funciona de maravillas pero, siempre hay peros, me olvide de cambiar el hostname del serve. Cuando corrijo el mismo y quiero iniciar el DBControl (EM) me figura lo siguiente.

[oracle@servidor]$ emctl start dbconsole

TZ set to Chile/Continental
OC4J Configuration issue. $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_servidor_10g2 not found.

La solución es simple debemos reconstruir el repositorio para el nuevo hostname, para lo cual de antemano deberemos saber las password de los usuarios SYS,SYSMAN y DBSNMP. Con esos datos hacemos:

[oracle@servidor]$ emca -config dbcontrol db -repos recreate

Vamos contestando las preguntas que nos va suministrando y esperamos un par de minutitos y nuestro repositorio se vuelve a crear para el nuevo hostname.

Espero que sirva.