Puede ocurrir que al momento de terminar una recuperación incompleta puedan tener problemas con un datafile que si bien no es parte de la recuperación, el controlfile lo posee, ya que se nos olvido o simplemente no podíamos determinar si efectivamente fue creado después del controlfile restaurado a un tiempo especifico. Sucede que este datafile no es necesario para mi recuperación, sin embargo esta contenido en el controlfile.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> SQL> 18:18:28 SQL> 18:18:28 SQL> ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01248: file 122 was created in the future of incomplete recovery
ORA-01110: data file 122: '/dev/rperf_raw053'
Solución:
Determinar si uno o más datafiles poseen un tiempo de SCN distinto. Esto se refiere a que todos los datafiles se encuentren a un tiempo de recuperación exacto.
Ejemplo:
Como determinar si están todos alineados a un mismo tiempo y SCN?
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS Tablespace_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#
;
Salida:
DF# DF_NAME TABLESPACE_NAME STATUS ERROR CHANGE# TIME
---- --------------- --------- ----------- ------- -------- -------------------
1 /dev/db_raw027 SYSTEM SYSTEM ######### 02-04-2010 23:00:00
2 /dev/db_raw001 TBS1 RECOVER ######### 02-04-2010 23:00:00
3 /dev/db_raw026 SYSAUX RECOVER ######### 02-04-2010 23:00:00
4 /dev/db_raw008 TBS1 RECOVER ######### 02-04-2010 23:00:00
5 /dev/db_raw042 TBS2 RECOVER ######### 02-04-2010 23:00:00
6 /dev/db_raw010 TBS3 RECOVER ######### 02-04-2010 23:00:00
7 /dev/db_raw146 TBS4 RECOVER ######### 02-04-2010 23:00:00
8 /dev/db_raw024 TBS5 RECOVER ######### 02-04-2010 23:00:00
9 /dev/db_raw025 TBS5 RECOVER ######### 02-04-2010 23:00:00
10 /dev/db_raw030 USERS RECOVER ######### 02-04-2010 23:00:00
11 /dev/db_raw028 TBS6 RECOVER ######### 02-04-2010 23:00:00
122/dev/db_raw053 TBS1 RECOVER ######### 15-10-2010 04:41:08
123/dev/db_raw076 TBS2 RECOVER ######### 15-10-2010 04:49:03Para este caso los datafiles 122 y 123 no pertenecen al tiempo de la recuperación; por lo tanto debemos hacer que el controlfile no los detecte nuevamente.
¿Como logramos esto?
Recreando el controlfile con la opción RESETLOGS de la siguiente manera:
Para obtener el trace del controlfile, se debe ejecutar el siguiente comando via SQL*Plus con el usuario SYS:
sqlplus / as sysdba
ALTER DATABASE BACKUP CONTOLFILE TO TRACE;Este archivo de trace sera creado en el directorio UDUMP asignado a la instancia mediante el parametro USER_DUMP_DEST.
oracle@linux[DBORA]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Fri Oct 22 08:47:37 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to an idle instance.
SQL> startup nomount
ORACLE instance started.
Total System Global Area 8.5899E+10 bytes
Fixed Size 2245832 bytes
Variable Size 1.2767E+10 bytes
Database Buffers 7.3014E+10 bytes
Redo Buffers 115191808 bytes
SQL> @control.sql
SQL> set time on
08:47:48 SQL> CREATE CONTROLFILE REUSE DATABASE "DBORA" RESETLOGS NOARCHIVELOG
08:47:48 2 MAXLOGFILES 32
08:47:48 3 MAXLOGMEMBERS 4
08:47:48 4 MAXDATAFILES 1024
08:47:48 5 MAXINSTANCES 1
08:47:48 6 MAXLOGHISTORY 23371
08:47:48 7 LOGFILE
08:47:48 8 GROUP 1 (
08:47:48 9 '/dev/db_raw163',
08:47:48 10 '/dev/db_raw164'
08:47:48 11 ) SIZE 500M,
.
.
.
08:47:48 157 '/dev/db_raw149',
08:47:48 158 '/dev/db_raw150',
08:47:48 159 '/dev/db_raw133',
08:47:48 160 '/dev/db_raw081',
08:47:48 161 '/dev/db_raw098'
08:47:48 162 CHARACTER SET AL32UTF8
08:47:48 163 ;
Control file created.
Elapsed: 00:00:00.53
08:47:49 SQL> alter database open resetlogs;
Database altered.
Elapsed: 00:00:54.83
08:48:51 SQL>
Ahora pueden seguir utilizando su base de datos sin problemas.
Viva Linux!!!!!
Atte.
Alberto Silva G.
