Juan Andres Mercado Oracle Blog – IT Buenos Aires

Troubleshooting daily on Oracle Systems, Linux & more !

Monthly Archives: August 2012

ORA-19802: cannot use DB_RECOVERY_FILE_DEST without DB_RECOVERY_FILE_DEST_SIZE

English: The transformation of SQL statements.

English: The transformation of SQL statements. (Photo credit: Wikipedia)

Hoy estaremos viendo el error de oracle ORA-19802:

Este error ocurre cuando no podemos utilizar (setear) el parametro DB_RECOVERY_FILE_DEST sin el parametro DB_RECOVERY_FILE_DEST_SIZE.

Veamos nuestro ejemplo:

SQL> set line 150
SQL> sho parameter recover

NAME TYPE VALUE
------------------------------------ -------------------------------- ------------------------------
db_recovery_file_dest                                         string
db_recovery_file_dest_size big integer                             0
db_unrecoverable_scn_tracking boolean                           TRUE
recovery_parallelism integer                                       0

SQL> alter system set db_recovery_file_dest='+DATA' scope=both sid='*';
alter system set db_recovery_file_dest='+DATA' scope=both sid='*'
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-19802: cannot use DB_RECOVERY_FILE_DEST without DB_RECOVERY_FILE_DEST_SIZE

Las dos principales premisas por las que puede aparacer son:

La primer causa ocurre por que el parametro DB_RECOVERY_FILE_DEST estaba en uso cuando el parametro DB_RECOVERY_FILE_DEST_SIZE no estaba seteado en los parametros de inicio. Read more of this post

Oracle RAC 11gR2 | ORA-00245: control file backup operation failed

 ORA-00245: Conociendo como ocurre el error

Oracle RAC

Oracle RAC (Photo credit: Fenng(dbanotes))

Desde la version de bases de datos oracle 11gR2 la copia de seguridad del controlfile sucede sin tener que holdear las colas de actualizacion del controlfile.

Cuando tenemos una base en single mode o mejor dicho standalone, esta situacion no cambia para nada.

Ahora si nosotros estamos trabajando en RAC (y debido a la cambios que se realizaron para las versiones de bases de datos 11gR2) provocan que cualquier instancia del cluster pueda escribir en el controlfile de manera instantanea.

Es asi que este snapshot del controlfile debe estar disponible (visible) para todas las instancias.

Por que ocurre el error ?

El snapshot del controlfile debe ser accesible para todos los nodos de una base de datos en RAC y si el snapshot no esta, o hay un error en el dispositivo compartido ocurrira que al momento de la copia de seguridad que realiza el RMAN mostrara un error.

Estos siempre ocurriran cuando tomemos un backup usando sqlplus, tengamos configurado un backup del controlfile como AUTOBACKUP o no poseamos una ubicacion compartida.

Ahora veamos unos ejemplos de errores comunes.

Ejemplo 1:

En un ambiente RAC, el controlfile autobackup falla con el error ORA-0245

Autobackup of controlfile in RMAN is failing with error:
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3009: failure of Control File and SPFILE Autobackup command on
ORA_DISK_1 channel at 10/27/2010 15:08:59
ORA-245: control file backup operation failed

Read more of this post

RMAN Querys | Monitoring backups status: COMPLETED, START_TIME, END_TIME & TIME TAKE

G RMAN

G RMAN (Photo credit: Joe Mud)

Hoy voy a compartirles un query que nos es de mucha utilidad cuando trabajamos con backups de RMAN y nos encontramos realizando reportes.

Podemos utilizarlo para conocer el tiempo que tardo cada backup segun una determinada fecha y segun el tipo de backup que tomamos.

Los mismos podrián ser DB FULL , ARCHIVELOG , INCREMENTAL , etc.

También conocer el tipo de STATUS con el que finalizo.

Ya sea COMPLETED o FAILED.

El query en cuenstion es :

set serveroutput on
set linesize 150
set pagesize 300
col time_taken_display for a9

select session_key,
input_type,
status,
to_char(start_time,'yyyy-mm-dd hh24:mi') start_time,
to_char(end_time,'yyyy-mm-dd hh24:mi') end_time,
time_taken_display
from v$rman_backup_job_details
order by session_key desc;

El query esta formado a partir de la vista v$rman_backup_job_details, siendo la misma muy útil Read more of this post

ORA-16179: incremental changes to “log_archive_dest_1” not allowed with SPFILE

En el articulo de hoy vamos a resolver un problema muy común que me consultan por diferentes medios.

ORA-16179: incremental changes to "log_archive_dest_1" not allowed with SPFILE
English: The transformation of SQL statements.

English: The transformation of SQL statements. (Photo credit: Wikipedia)

Este error aparece cuando tratamos de cambiar el ARCHIVE LOG DESTINATIONde nuestra base de datos a un nuevo path.

Aca vamos a poner un ejemplo de lo que ocurrio en un sitio donde estaba dando soporte.

La base de datos cae por que no puede escribir los logs en un filesystem local.

Al parecer nunca habian configurado los parametros correctamente y dejaron asi todos los valores por default.

SQL> sho parameter LOG_ARCHIVE_DEST_1

NAME                                 TYPE      VALUE
------------------------------------ --------- ------------------
log_archive_dest_1 string
log_archive_dest_10 string
log_archive_dest_11 string
log_archive_dest_12 string
log_archive_dest_13 string
log_archive_dest_14 string
log_archive_dest_15 string
log_archive_dest_16 string
log_archive_dest_17 string
log_archive_dest_18 string
log_archive_dest_19 string

SQL>
EL error nos aparece en el alert log de la base de datos. Read more of this post
%d bloggers like this: