¿Cómo recuperar un spfile perdido?

El server parameter file o spfile, es un archivo binario que contiene los parámetros de inicialización. Este archivo existe en el servidor de base de datos y ha venido a reemplazar al otrora parameter file o pfile. Antes de la aparición del spfile, todo cambio a los parámetros debíamos hacerlos permanentes mediante la edición del archivo pfile. Si olvidábamos hacerlo, con el siguiente inicio de la base de datos los cambios eran descartados. Con la aparición del spfile ya no es necesario preocuparse por esto, los cambios se registran automáticamente, sin necesidad de ediciones. El archivo spfile es leído al momento de iniciar la instancia, por lo que su ausencia lo impide, afortunadamente es bastante fácil superar su pérdida, veremos a continuación un par de formas de recuperarlo.

a) Usando el Alert.log

Cada vez que hacemos un cambio a un parámetro de inicialización, aparte de grabarse en el spfile, también se deja una constancia en el alert.log. Al iniciar la base de datos, en el alert.log se registra la relación de parámetros de inicialización con valores modificados. Luego, nuestra primera fuente para reconstruir un spfile perdido es desde luego el alert.log.

alertorcl.log:
. . .
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
  processes                = 150
  __shared_pool_size       = 125829120
  __large_pool_size        = 4194304
  __java_pool_size         = 4194304
  __streams_pool_size      = 8388608
  nls_territory            = AMERICA
  filesystemio_options     = SETALL
  sga_target               = 205520896
  control_files            = /u02/oradata/orcl/control01.ctl
  db_block_size            = 8192
  __db_cache_size          = 58720256
  compatible               = 10.2.0.4.0
  log_archive_format       = %t_%s_%r.dbf
  db_create_file_dest      = /u02/oradata
  db_recovery_file_dest    = /u01/app/oracle/flash_recovery_area
  db_recovery_file_dest_size= 4294967296
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  remote_login_passwordfile= EXCLUSIVE
  audit_sys_operations     = FALSE
  db_domain                = oracle.com
  job_queue_processes      = 10
  background_dump_dest     = /u01/app/oracle/admin/orcl/bdump
  user_dump_dest           = /u01/app/oracle/admin/orcl/udump
  core_dump_dest           = /u01/app/oracle/admin/orcl/cdump
  audit_file_dest          = /u01/app/oracle/admin/orcl/adump
  audit_trail              = XML, EXTENDED
  db_name                  = orcl
  open_cursors             = 300
  pga_aggregate_target     = 67108864
PMON started with pid=2, OS id=5963
. . .

Procedemos a extraer la relación de parámetros y los copiamos en un archivo, mismo que puede estar ubicado en cualquier directorio y tener cualquier nombre o extensión, pero que para este ejemplo llamaremos initorcl.ora. Una vez creado podemos construir un spfile tomándolo como insumo.

SYS@orcl> create spfile from pfile='/home/oracle/initorcl.ora';

File created.
SYS@orcl> startup;
ORACLE instance started.

Total System Global Area  205520896 bytes
Fixed Size                  1266608 bytes
Variable Size             142609488 bytes
Database Buffers           58720256 bytes
Redo Buffers                2924544 bytes
Database mounted.
Database opened.

Acá estamos asumiendo que la base de datos estaba abajo, pero si aún está operativa entonces tendremos que hacerlo con un paso extra.

SYS@orcl> create spfile from pfile='/home/oracle/initorcl.ora';
create spfile from pfile='/home/oracle/initorcl.ora'
*
ERROR at line 1:
ORA-32002: cannot create SPFILE already being used by the instance

SYS@orcl> create spfile='?/dbs/spfileorcl.bak' from pfile='/home/oracle/initorcl.ora';

File created.

$ mv $ORACLE_HOME/dbs/spfileorcl.bak $ORACLE_HOME/dbs/spfileorcl.ora

El resultado final es un nuevo spfile que incluye los cambios más recientes.

b) Usando backups obtenidos con RMAN

Si por alguna razón no podemos hacer uso del alert.log, nuestra siguiente alternativa es recurrir a los backups obtenidos con RMAN. Cada vez que obtenemos un backup que, de forma directa o indirecta, involucre al tablespace System, tanto el controlfile como el spfile son automáticamente respaldados. Esto también ocurre si hemos configurado RMAN con "controlfile autobackup on", en este caso no importa si el backup incluye o no al tablespace System. Asumiendo que la base de datos está operativa, el procedimiento a seguir para restaurar el spfile es:

RMAN> restore spfile to '?/dbs/spfileora.bak' from autobackup;

Starting restore at 05/11/2008 17:42:25
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=143 devtype=DISK

recovery area destination: /u01/app/oracle/flash_recovery_area
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/ORCL/autobackup/2008_11_05/o1_mf_s_670006939_4k45zd4k_.bkp
channel ORA_DISK_1: SPFILE restore from autobackup complete
Finished restore at 05/11/2008 17:42:29

$ mv $ORACLE_HOME/dbs/spfileorcl.bak $ORACLE_HOME/dbs/spfileorcl.ora

Si la base de datos está abajo, el procedimiento es algo distinto.

RMAN> startup nomount;

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora'

starting Oracle instance without parameter file for retrival of spfile
Oracle instance started

Total System Global Area     159383552 bytes

Fixed Size                     1266344 bytes
Variable Size                 54529368 bytes
Database Buffers             100663296 bytes
Redo Buffers                   2924544 bytes

RMAN> restore spfile  from autobackup
2> recovery area '/u01/app/oracle/flash_recovery_area'
3> db_name 'ORCL';

Starting restore at 05/11/2008 17:49:50
using channel ORA_DISK_1

recovery area destination: /u01/app/oracle/flash_recovery_area
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/ORCL/autobackup/2008_11_05/o1_mf_s_670006939_4k45zd4k_.bkp
channel ORA_DISK_1: SPFILE restore from autobackup complete
Finished restore at 05/11/2008 17:49:53

Observamos que RMAN es capaz de iniciar la instancia, aún cuando no existe el spfile, justamente porque asume que queremos restaurarlo de algún backup. Para lograr restaurar el spfile, debemos indicar la ubicación del Recovery Area, así como el nombre de la base de datos, con esos datos RMAN busca el backup más reciente.

En conclusión, el archivo spfile es requerido para iniciar la instancia, si lo hemos perdido podemos recurrir al alert.log o a los backups. En caso de que no podamos lograrlo, siempre queda como última alternativa el crear un pfile con el mínimo de parámetros y a partir de él un spfile, pero es una situación en la que difícilmente deberíamos caer si hemos sido suficientemente cuidadosos y precavidos.

Puedes complementar lo acá detallado, leyendo el Note 372996.1 Using RMAN to Restore and Recover a Database When the Repository and Spfile/Init.ora Files Are Also Lost.

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!