Restaurar un controlfile dañado

Un controlfile dañado se puede recuperar de una copia multiplexada o recrearlo de un backup, esto último no debe ser necesario si se ha seguido la técnica de multiplexar los control files.

Los control files se pueden recuperar a  través de SQL*Plus y el sistema operativo o a través de RMAN, de hecho si  el backup se hizo a través de backup set, RMAN es la única solución.

El control file es un archivo imprescindible para el funcionamiento de la base de datos. La pérdida de uno de estos archivos provoca  la parada de la base de datos o en el caso de que estemos intentando levantar la base de datos y el proceso SMON detecte que no existe uno de estos archivos la base de datos se quedará en estado NOMOUNT y escribirá en el alert log una entrada indicándonos cuál de los controlfile no ha sido capaz de encontrar.

Siempre que el controlfile este multiplexado, la recuperación por perdida de una de las copia es sencilla. Simplemente se debe sustituir el archivo dañado por una de las copias intactas.

Si una de los copias falla se puede quitar la referencia en el parámetro CONTROL_FILE del spfile, o lo que es más recomendable restaurar el controlfile dañado de una de las copias intactas.  

 Pasos:

  1. Si la instancia no ha caído, pararla utilizando SHUTDOWN ABORT.
  2. Copiar utilizando comandos del sistema operático uno de los controfiles no dañados, si el fallo se ha provocado por la pérdida de un disco o de una controladora, copiar el nuevo controfile en otro lugar y luego actualizar el archivos de parámetros con la nueva localización.
  3. Iniciar la base de dato.

Ejemplo:

La base de datos se ha caído, porque se ha dañado el siguiente controlfile /u02/oradata/prueba/control02.ctl .  No recordamos donde están los controlfiles.

Levantamos la instancia para consultar el archivo de parámetros

SQL>startup nomount
SQL>show parameter CONTROL_FILE
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time        integer     0
control_files                        string      /u01/oradata/prueba/control01.ctl, /u02/ora
                                                 data/prueba/control02.ctl, /u01/oradata/
                                                 prueba/control03.ctl
SQL>exit

Restauramos la copia a través del sistema operativo:

cp /u01/oradata/prueba/control01.ctl  /u01/oradata/prueba/control04.ctl
 

Si fuera necesario modificamos el spfile, recordar que si no hay spfile se tiene que editar el pfile:

sqlplus ‘/ as sysdba’
SQL> alter system set contro_file = ‘/u01/oradata/prueba/control01.ctl’, ‘/u01/oradata/prueba/control03.ctl’, ‘/u01/oradata/prueba/control04.ctl’ scope=spfile;
SQL> exit

 
Anuncios

Control files

Hoy vamos a dar un pequeño repaso a los control files, información general sobre ellos y cosas interesantes. Creo que este tipo de post me ayudan a sintetizar conceptos y siempre es interesante ahondar en el funcionamiento de oracle.

El control fiile se actualiza continuamente y debe estar disponible en todo momento. No se debe editar su contenido bajo ningún concepto solo los procesos de oracle deben hacerlo. Cuando se levanta una base de datos Oracle utiliza el control file para identificar los datafiles y los redologs y encargarse de abrirlos. La localización del control file se especifica en los parámetros de inicialización. El control file es el elemento fundamental en proceso de recuperación de una base de datos.

Los control files incluyen el siguiente contenido:

  • El nombre de la base de datos a la cual el control file pertenece, un control file solo puede pertenecer a una base de datos.
  • El time stamp de creación de la base de datos.
  • El nombre de los datafiles, dónde están situados y la información sobre su status online/offline.
  • El nombre de los archivos de redo log y dónde están situados.
  • Información sobre los redo log files.
  • El nombre de los tablespaces.
  • El último “log sequence number”, identificador único que se incrementa y se guarda cada vez que se cambia de online redo log.
  • La última información del check point
  • El comienzo y el fin de los segmentos de undo.
  • Información sobre el back up del Recovery Manager (RMAN)

El tamaño del control file lo determinan las clausulas MAX utilizadas en la creación de la base de datos:

  • MAXLOGFILES
  • MAXLOGMEMBERS
  • MAXLOGHISTORY
  • MAXDATAFILES
  • MAXINSTANCES

Oracle reserva espacio para esos máximos en el control file. Sin embargo, cuando se añade o renombra un fichero en la base de datos, el control file no cambia de tamaño.

Cuando añades un nuevo fichero en la base de datos o lo cambias de lugar un proceso de servidor automáticamente actualiza la información el control file. Es conveniente hacer una back up del control file después de cualquier cambio estructural. El proceso de log writer (LGWR) actualiza el control file con el último “log sequence number”. El CKPT actualiza el control file con la información de checkpoint más reciente. Cuando la base dad datos está en modo ARCHIVELOG, el proceso de archive (ARCn) actualiza el control file con datos como nombre de fichero de archive y numero de secuencia del log.

El control file contiene dos tipos de secciones de registros: reutilizables y no reutilizable. La información de RMAN se guarda en la sección reutilizable. Elementos como el nombre de los ficheros de backup se almacenan en esta sección, y una vez que se llena, la entradas se reutilizan de forma circular después de un número de días especificados en el parámetro de inicialización CONTROL_FILE_RECORD_KEEP_TIME.

Ya que el control file es un elemento critico en la operativa de la base de datos, es recomendable tener como mínimo dos copias.  Oracle recomienda tener al menos tres. Si tienes diferentes controladoras de disco en el servidor, por lo menos una de las copias del control file debería residir en un disco manejado por un controladora diferente.

Multiplexar un control file

Como multiplexar un control file en una base de datos en ASM. Lo primero es determinar cuántos control files tenemos y su ubicación .

SQL> column NAME format a50;
SQL> set linesize 100
SQL> select STATUS , name from v$controlfile;
STATUS NAME
------- --------------------------------------------------
+DATA/prueba/controlfile/controlfile1.ctl
 

 Después modificaremos el spfile y añadiremos el nuevo control file .

 sql> alter system set control_files='+DATA/smodb/controlfile/current.266.689333057','+DATA/smodb/controlfile/controlfile3.ctl' scope=spfile;
 

 Paramos la base de datos para levantar la instancia sin montarla y poder hacer una copia del control file inicial .

 sql> shutdown immediate
 sql> startup nomount

 Luego utilizando rman:

 $ rman nocatalog
 RMAN>connect target
 RMAN>restore controlfile to '+DATA/prueba/controlfile/controlfile1.ctl' from '+DATA/prueba/controlfile/controlfile1.ctl';

Montamos la base de datos y por fin la abrimos y podremos ver que ya ha registrado el nuevo control file:

sql> alter database mount;
sql> alter database open ;
sql> select status,name from v$controlfile;
STATUS NAME
------------ -------------------------------------------------------------
+DATA/prueba/controlfile/controlfile1.ctl
+DATA/prueba/controlfile/controlfile2.ctl