Contacto

CONTACTAR EN CASO DE EMERGENCIAS Móvil +56963679637 - MAIL : CONSULTADBABLOCK@GMAIL.COM
- SOPORTE REMOTO EN BASE DE DATOS ORACLE - ORACLE LINUX - ORACLE VM SERVER - ORACLE RAC - ORACLE DATA GUARD
- UPGRADES - CAPACITACION
Showing posts with label RMAN. Show all posts
Showing posts with label RMAN. Show all posts

Friday, June 10, 2016

Hands-ON Oracle Recovery Manager - RMAN

Hola Amigos, Hace un tiempo construí este manual de RMAN avanzado de 11gR2. Acá existen ejemplos reales de situaciones que ocurren en un día normal de operación o frente a una consultoría técnica.

En esta presentación se incluyeron los siguientes tópicos para estudiar:


  • INTRODUCCIÓN RECOVERY MANAGER 
  • CONCEPTOS DE RESPALDO Y RECUPERACIÓN 
  • ARQUITECTURA EL PROCESO LOG WRITTER 
  • EL PROCESO ARCHIVER
  • ESTRUCTURAS FÍSICAS DE BASES DE DATOS UTILIZADAS EN RECUPERACIÓN 
  • TIPOS DE RESPALDOS TIPOS DE RECUPERACIÓN
  • CONFIGURANDO EL AMBIENTE RMAN
  • MULANDO UNA SUPER DLT A DISCO
  • CONFIGURANDO TIPOS DE DISPOSITIVOS 
  • CATÁLOGO DE RECUPERACIÓN 
  • RECOVERY MANAGER EJERCICIOS DE RESPALDO, RECUPERACION, FLASHBACK, ASM METADATA


Viva Linux!!!! Alberto Silva Gallardo

Friday, October 22, 2010

RMAN - Comandos Rapidos y Tips

Acá les dejo algunos comandos básicos de RMAN que nos ayudan a realizar ciertas tareas automatizadas.

1.- Como restaurar ArchiveLogs dentro de un rango de secuencias a un directorio determinado:

run
{
allocate channel CN01 type 'SBT_TAPE' parms 'BLKSIZE=100000,ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/test.opt)';
allocate channel CN02 type 'SBT_TAPE' parms 'BLKSIZE=100000,ENV=
set archivelog destination to '/archive/DBORA';
restore archivelog from sequence 100 until sequence 2000;
release channel CN01;
release channel CN02;
}

2.- Como listar los ArchiveLogs necesarios para una recuperación dentro de un rango de fechas.

list backup of archivelog from time "TO_DATE('27-05-2010 06:00:00','DD-MM-YYYY HH24:MI:SS')" until time "TO_DATE('31-05-2010 15:00:00','DD-MM-YYYY HH24:MI:SS')";

3.- Como identificar la fecha de los Backup Piece que esta utilizando RMAN para realizar un restore:

SQL> select
b.NAME,
a.COMPLETION_TIME,
a.MEDIA,
a.STATUS,
a.HANDLE
from
rc_backup_piece a,
rc_database b
where a.DB_KEY = b.DB_KEY
and HANDLE in
('uala0om3_1_1', ----> Backup Piece
'ucla0om3_1_1',
'ubla0om3_1_1',
'ukla0pqi_1_1',
'ufla0p2p_1_1',
'uela0p2a_1_1',
'unla0q5r_1_1',
'udla0p0t_1_1',
'ugla0p8i_1_1',
'uila0pem_1_1',
'uhla0pel_1_1',
'urla0qi7_1_1')
order by max(COMPLETION_TIME);

DBORA 05-06-2010 08:00:58 2680 A uala0om3_1_1
DBORA 05-06-2010 08:01:43 2703 A ucla0om3_1_1
DBORA 05-06-2010 08:01:56 2684 A ubla0om3_1_1
DBORA 05-06-2010 08:05:01 2680 A udla0p0t_1_1
DBORA 05-06-2010 08:08:19 2684 A ufla0p2p_1_1
DBORA 05-06-2010 08:08:21 2703 A uela0p2a_1_1
DBORA 05-06-2010 08:10:34 2680 A ugla0p8i_1_1
DBORA 05-06-2010 08:14:39 2703 A uhla0pel_1_1
DBORA 05-06-2010 08:14:41 2684 A uila0pem_1_1
DBORA 05-06-2010 08:20:42 2684 A ukla0pqi_1_1
DBORA 05-06-2010 08:27:18 2707 A unla0q5r_1_1
DBORA 05-06-2010 08:34:08 2707 A urla0qi7_1_1

Por ejemplo con estos datos podemos determinar desde que SCN inicial puedo comenzar a restaurar los Archivelogs para una recuperación.

Viva Linux!!!!
Alberto Silva G.

Recuperando una base de datos - Error ORA-01248

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:03


Para 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.

Thursday, August 27, 2009

Emulando una Super DLT a Disco

Descubriendo Oracle Test Disk API

En mi búsqueda para encontrar ambientes que puedan emular tecnología muy costosa, me encontré con un problema cuando respalde el Flash Recovery Area. El error ORA-6747 indica que no es posible respaldar a disco la (FRA) y debe ser asignado una canal SBT. La verdad que si no tengo cintas estoy "frito" y no puedo respaldar en caso de alguna catástrofe.

Respaldando Flash Recovery Area con RMAN

Al configurar el (FRA) con RMAN, sera posible mantener los respaldos realizados sin tener que ser llevados a cinta. Esto aumenta la disponibilidad de respaldos en caso de alguna falla y disminuye el MTTR.

MTTR 'Mean Time to Recover'
Este término significa el tiempo promedio que se demora al recuperar un sistema. En este caso, es tiempo que demora recuperar la base de datos.


Para revisar el espacio disponible en el (FRA), se puede consultar la siguiente vista:

SQL> select SPACE_RECLAIMABLE from V$RECOVERY_FILE_DEST;

SPACE_RECLAIMABLE
-----------------
43008

El valor de esta columna se incrementa cada vez que se realiza un respaldo, si esta definido en el flash recovery area.

API oracle.disksbt

El oracle.disksbt es un API que nos provee Oracle para poder testear procedimientos de respaldo que utilizan dispositivos SBT. En este caso se define como un pseudo dispositivo de cinta que en definitiva esta configurado contra un filesystem ó directorio definido para almacenar ahí los respaldos realizados con esta API. Finalmente, RMAN asume que tiene una cinta y que el dispositivo SBT esta disponible cada vez que necesita consultar, respaldar o recuperar. Es importante generar una configuración persistente mediante la definición del parámetro con el comando CONFIGURE.

1.- Crear un directorio donde el usuario dueño del motor Oracle pueda escribir.
ejemplo : mkdir /oracle/tape_backup

2.- Llamando a la API desde RMAN

Ej: run {
allocate channel DR1 device type 'SBT_TAPE' PARMS="SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=/oracle/type_backup)";
backup as compressed backupset database plus archivelog;
backup current controlfile;
backup spfile tag=FULL_DB
}

allocated channel: DR1
channel DR1: sid=134 devtype=SBT_TAPE
channel DR1: WARNING: Oracle Test Disk API


Starting backup at 27-AUG-09
current log archived
channel DR1: starting compressed archive log backupset
channel DR1: specifying archive log(s) in backup set
input archive log thread=1 sequence=17 recid=17 stamp=695996692
input archive log thread=1 sequence=18 recid=18 stamp=695996761
input archive log thread=1 sequence=19 recid=19 stamp=695997028
channel DR1: starting piece 1 at 27-AUG-09
channel DR1: finished piece 1 at 27-AUG-09
piece handle=2skno4j5_1_1 tag=TAG20090827T123029 comment=API Version 2.0,MMS Version 8.1.3.0
channel DR1: backup set complete, elapsed time: 00:00:02
Finished backup at 27-AUG-09

Starting backup at 27-AUG-09
channel DR1: starting compressed full datafile backupset
channel DR1: specifying datafile(s) in backupset
input datafile fno=00001 name=/oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/system01.dbf
input datafile fno=00003 name=/oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/sysaux01.dbf
input datafile fno=00002 name=/oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/undotbs01.dbf
input datafile fno=00004 name=/oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/users01.dbf
channel DR1: starting piece 1 at 27-AUG-09
channel DR1: finished piece 1 at 27-AUG-09
piece handle=2tkno4j8_1_1 tag=TAG20090827T123031 comment=API Version 2.0,MMS Version 8.1.3.0
channel DR1: backup set complete, elapsed time: 00:01:25
Finished backup at 27-AUG-09

Starting backup at 27-AUG-09
current log archived
channel DR1: starting compressed archive log backupset
channel DR1: specifying archive log(s) in backup set
input archive log thread=1 sequence=20 recid=20 stamp=695997117
channel DR1: starting piece 1 at 27-AUG-09
channel DR1: finished piece 1 at 27-AUG-09
piece handle=2ukno4lv_1_1 tag=TAG20090827T123159 comment=API Version 2.0,MMS Version 8.1.3.0
channel DR1: backup set complete, elapsed time: 00:00:02
Finished backup at 27-AUG-09

Starting backup at 27-AUG-09
channel DR1: starting full datafile backupset
channel DR1: specifying datafile(s) in backupset
including current control file in backupset
channel DR1: starting piece 1 at 27-AUG-09
channel DR1: finished piece 1 at 27-AUG-09
piece handle=2vkno4m2_1_1 tag=TAG20090827T123202 comment=API Version 2.0,MMS Version 8.1.3.0
channel DR1: backup set complete, elapsed time: 00:00:02
Finished backup at 27-AUG-09

Starting backup at 27-AUG-09
channel DR1: starting full datafile backupset
channel DR1: specifying datafile(s) in backupset
including current SPFILE in backupset
channel DR1: starting piece 1 at 27-AUG-09
channel DR1: finished piece 1 at 27-AUG-09
piece handle=30kno4m5_1_1 tag=FULL_DB comment=API Version 2.0,MMS Version 8.1.3.0
channel DR1: backup set complete, elapsed time: 00:00:02
Finished backup at 27-AUG-09

Starting Control File and SPFILE Autobackup at 27-AUG-09
piece handle=c-3301411538-20090827-09 comment=API Version 2.0,MMS Version 8.1.3.0
Finished Control File and SPFILE Autobackup at 27-AUG-09
released channel: DR1

RMAN> list backup;


List of Backup Sets
===================

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
4452 256.00K SBT_TAPE 00:00:01 27-AUG-09
BP Key: 4454 Status: AVAILABLE Compressed: YES Tag: TAG20090827T123029
Handle: 2skno4j5_1_1 Media:

List of Archived Logs in backup set 4452
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 17 490207 27-AUG-09 490569 27-AUG-09
1 18 490569 27-AUG-09 490612 27-AUG-09
1 19 490612 27-AUG-09 490799 27-AUG-09

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4453 Full 95.00M SBT_TAPE 00:01:22 27-AUG-09
BP Key: 4455 Status: AVAILABLE Compressed: YES Tag: TAG20090827T123031
Handle: 2tkno4j8_1_1 Media:
List of Datafiles in backup set 4453
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 490809 27-AUG-09 /oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/system01.dbf
2 Full 490809 27-AUG-09 /oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/undotbs01.dbf
3 Full 490809 27-AUG-09 /oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/sysaux01.dbf
4 Full 490809 27-AUG-09 /oracle/product/10.2.0/oradata/BIZPR1/BIZPR1/users01.dbf

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
4468 256.00K SBT_TAPE 00:00:01 27-AUG-09
BP Key: 4473 Status: AVAILABLE Compressed: YES Tag: TAG20090827T123159
Handle: 2ukno4lv_1_1 Media:

List of Archived Logs in backup set 4468
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 20 490799 27-AUG-09 490843 27-AUG-09

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4481 Full 7.00M SBT_TAPE 00:00:01 27-AUG-09
BP Key: 4483 Status: AVAILABLE Compressed: NO Tag: TAG20090827T123202
Handle: 2vkno4m2_1_1 Media:
Control File Included: Ckp SCN: 490863 Ckp time: 27-AUG-09

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4493 Full 256.00K SBT_TAPE 00:00:01 27-AUG-09
BP Key: 4495 Status: AVAILABLE Compressed: NO Tag: FULL_DB
Handle: 30kno4m5_1_1 Media:
SPFILE Included: Modification time: 27-AUG-09

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4505 Full 7.25M SBT_TAPE 00:00:01 27-AUG-09
BP Key: 4507 Status: AVAILABLE Compressed: NO Tag: TAG20090827T123209
Handle: c-3301411538-20090827-09 Media:
Control File Included: Ckp SCN: 490886 Ckp time: 27-AUG-09
SPFILE Included: Modification time: 27-AUG-09

Y ahora podemos respaldar el Flash Recovery Area:

RMAN> backup recovery area;

Starting backup at 27-AUG-09
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=134 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
specification does not match any datafile copy in the repository
specification does not match any backupset in the repository
skipping archive log file /oracle/product/10.2.0/db_1/flash_recovery_area/BIZPR1/archivelog/2009_08_27/o1_mf_1_17_59fdtmw0_.arc; already backed up 1 time(s)
skipping archive log file /oracle/product/10.2.0/db_1/flash_recovery_area/BIZPR1/archivelog/2009_08_27/o1_mf_1_18_59fdws7p_.arc; already backed up 1 time(s)
skipping archive log file /oracle/product/10.2.0/db_1/flash_recovery_area/BIZPR1/archivelog/2009_08_27/o1_mf_1_19_59ff54nn_.arc; already backed up 1 time(s)
skipping archive log file /oracle/product/10.2.0/db_1/flash_recovery_area/BIZPR1/archivelog/2009_08_27/o1_mf_1_20_59ff7xl3_.arc; already backed up 1 time(s)
Finished backup at 27-AUG-09


Un Abrazo.
Alberto Silva

Monday, March 23, 2009

RMAN

1. Recuperación de Tablespace Point-in-time (TSPIRT) en una Instancia Auxiliar

La herramienta Recovery Manager RMAN automatiza el procedimiento (TSPIRT) habilitándolo rápidamente en la recuperación de uno o más tablespaces en un tiempo diferente del resto de la base de datos.

RMAN TSPIRT es utilizado para recobrar lo siguiente:

.- Un error producido por el estamento drop table o truncate table

.- Una tabla lógicamente corrupta

.- Un Job ejecutado incorrectamente u otro estamento DML que a afectado un subconjunto de la base de datos

.- Un esquema a un punto diferente del resto de la base de datos física, cuando múltiples esquemas existen en tablespaces separados en la base de datos

Como un export de tabla, RMAN TSPITR habilita la recuperación de un conjunto de datos consistente; sin embargo, más que un objeto, el conjunto de datos está enteramente contenido en el tablespace.

2. Tareas Automáticas realizadas por RMAN

1. Restaurar el backup de un tablespace específico

2. Recobra el tablespace especificado

3. Exportar la metadata desde la instancia Auxiliar para Transportable Tablespace


4. Direcciona el control file de la base de datos Target a los nuevos datafiles recobrados

5. Importa la metadata en la base de datos Target


3. Realizando TSPITR sin catálogo de recuperación

Este procedimiento puede ser realizado con o sin catálogo de recuperación. Si no se utiliza catálogo de recuperación, existen las siguientes restricciones:

.- El Rollback o los Undo Segments son necesarios al momento de realizar el TSPITR en la instancia AUXILIARY. Por que RMAN no posee registros históricos del UNDO en el Control File, RMAN asume que el actual UNDO segments se encuentran presente en el mismo segmento y en el tiempo cuando la recuperación es realizada. Si el Undo Segments han cambiado desde esa vez, entonces TSPITR falla cuando la recuperación intenta escribir a un archivo no existente.

.- Si TSPITR se recupera de un respaldo muy antiguo, este puede no resultar exitoso, si Oracle rehúsa los registros del control file por necesidad de copias o backups.

.- Asumir que ejecutar TSPITR en un tablespace y colocar el tablespace online en tiempo t.
Ejecutar el proceso de TSPITR en un tablespace involucra colocar este en modo Online en el tiempo T0.
El Backup del tablespace creados antes del tiempo T0, no son completamente utilizados para la recuperación con un control file actual. Así, no puedes ejecutar TSPITR otra vez en este tablespace para recuperar este a cualquier tiempo menor que ò igual al tiempo T0, ni puedes utilizar el control file actual para recobrar la base de datos a cualquier tiempo menor o igual a t0.
La razón para restricciones adicionales en el modo nocatalog es debido a que el control file actual no posee registros de la Incarnation más antigua del tablespace recuperado. Sí recuperamos con un control file actual, esto implica que el tablespace no puede ser usado con un respaldo tomado anterior al tiempo T0. Sin embargo, si restauramos un control file respaldado anteriormente en t0, entonces puedes realizar la recuperación incompleta entera de la base de datos a cualquier tiempo menor o igual a t0.


4. Comprendiendo las restricciones generales

.- Ejecutar el TARGET y la base datos AUXILIARY en nodos separados. Sin embargo, el TARGET y la base de datos AUXILIARY pueden ser una configuración de Cluster que utiliza discos compartidos.

.- Recobrar tablespaces borrados

.- Recobrar un tablespace que ha sido borrado y recreado con el mismo nombre

.- Remover un datafile que ha sido agregado a un tablespace. Si el archivo fue agregado después del punto al cual RMAN se esta recuperando, entonces el archivo todavía es parte del tablespace (y debería ser vacío) después del RMAN TSPITR es completado.

.- Utilizar estamentos DML en la instancia auxiliary – La instancia auxiliary es una instancia temporal usada solamente para recuperación.

.- Asumir que realizas TSPITR en un tablespace cuando se conecta a un catálogo de recuperación, y entonces vuelve el tablespace online en tiempo t0. Puedes usar backups creados antes de time t para recobrar cualquier tablespace ò completamente la base de datos hasta time t0, pero más adelante. Por lo tanto, puedes inmediatamente respaldar el tablespace después de realizar TSPITR.

.- Recuperación de estadísticas del optimizador para objetos que poseen estadísticas, se deben calcular después de realizar TSPITR.

5. Colocar objetos dentro del Recovery Set

.- Replicado de tablas maestras

.- Tablas parciales. (por ejemplo, si se realiza RMAN TSPITR en tablas particionadas y sus particiones se encuentran distribuidas en múltiples tablespaces, entonces RMAN retorna un mensaje de error durante la fase de export.

.- Tablas sin sus constraints o constrainst sin sus tablas.

.- Tablas con columnas del tipo VARRAY.

.- Tablas con tablas anidadas.

.- Tablas con archivos externos.

.- Snapshot logs y tablas snapshot.

.- Tablespaces que contengan UNDO.

.- Objetos que el dueño sea el SYS (Incluyendo Undo Segments)

6. Manejando relaciones de datos

TSPITR provee vistas que pueden detectar cualquier relación de datos entre objetos en el recovery set y objetos en el resto de la base de datos. TSPITR no se completa exitosamente a menos que estas relaciones sean manejadas, cualquier relación suspendida o removida o que incluya objetos relacionados en el recovery set.

7. Determinando objetos que pueden ser perdidos

Cuando RMAN TSPITR es realizado en un tablespace, cualquier objeto creado después del tiempo de recuperación es perdido. Para revisar cuales son los objetos que pueden ser perdidos, podemos consultar la vista TS_PITR_OBJECT_TO_BE_DROPPED en la base de datos primaria.


Descripción de la tabla TS_PITR_OBJECTS_TO_BE_DROPPED

Column Name Meaning
OWNER Owner of the object to be dropped.
NAME The name of the object that will be lost as a result of undergoing TSPITR
CREATION_TIME Creation timestamp for the object.
TABLESPACE_NAME Name of the tablespace containing the object.

Al consultar esta vista, provee todos los elementos del campo fecha, si no es utilizado el default. También, utilice las funciones TO_CHAR y TO_DATE. Por ejemplo, un recovery set que contenga el tablespace USERS y TOOLS, y un punto de recuperación en el tiempo de '2007-02-02:07:03:11', pudiendo utilizar el siguiente estamento:

SELECT OWNER, NAME, TABLESPACE_NAME, TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS')
FROM TS_PITR_OBJECTS_TO_BE_DROPPED
WHERE TABLESPACE_NAME IN ('USERS','TOOLS')
AND CREATION_TIME > TO_DATE('07-JUN-02:07:03:11','YY-MON-DD:HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;

8. Buscando y resolviendo dependencias en la base de datos Primaria

Consultar la vista TS_PITR_CHECK para identificar relaciones entre objetos que traslapan el dominio del recovery set. Si esta vista retorna filas cuando es consultada, entonces investigar y corregir el problema. Proceder con TSPITR solo cuando la vista TS_PITR_CHECK no retorna filas para el tablespaces no esta en el recovery set. Provee un predicado de cuatro líneas detallado el recover set del tablespace para consultar la vista TS_PITR_CHECK.

Por ejemplo, un recover set que consiste del tablespace TOOLS y USERS, el estamento SELECT contra la vista TS_PITR_CHECK puede ser hecho de la siguiente manera:

Select *
FROM SYS.TS_PITR_CHECK
WHERE (
TS1_NAME IN ('USERS','TOOLS')
AND TS2_NAME NOT IN ('USERS','TOOLS')
)
OR (
TS1_NAME NOT IN ('USERS','TOOLS')
AND TS2_NAME IN ('USERS','TOOLS')
);



Para ejecutar completamente TSPITR revise en todos los tablespaces en la base de datos (no justamente el tablespace en el recovery set), ejecutando la siguiente consulta:

SELECT *
FROM SYS.TS_PITR_CHECK
WHERE (
'SYSTEM' IN (TS1_NAME, TS2_NAME)
AND TS1_NAME <> TS2_NAME
AND TS2_NAME <> '-1'
)
OR (
TS1_NAME <> 'SYSTEM'
AND TS2_NAME = '-1'
);



Por el número y el largo de las columnas en la vista TS_PITR_CHECK, puedes formatear la salida de la consulta:

SET LINESIZE 120
COLUMN OBJ1_OWNER HEADING "own1"
COLUMN OBJ1_OWNER FORMAT a6
COLUMN OBJ1_NAME HEADING "name1"
COLUMN OBJ1_NAME FORMAT a5
COLUMN OBJ1_SUBNAME HEADING "subname1"
COLUMN OBJ1_SUBNAME FORMAT a8
COLUMN OBJ1_TYPE HEADING "obj1type"
COLUMN OBJ1_TYPE FORMAT a8 word_wrapped
COLUMN TS1_NAME HEADING "ts1_name"
COLUMN TS1_NAME FORMAT a6
COLUMN OBJ2_NAME HEADING "name2"
COLUMN OBJ2_NAME FORMAT a5
COLUMN OBJ2_SUBNAME HEADING "subname2"
COLUMN OBJ2_SUBNAME FORMAT a8
COLUMN OBJ2_TYPE HEADING "obj2type"
COLUMN OBJ2_TYPE FORMAT a8 word_wrapped
COLUMN OBJ2_OWNER HEADING "own2"
COLUMN OBJ2_OWNER FORMAT a6
COLUMN TS2_NAME HEADING "ts2_name"
COLUMN TS2_NAME FORMAT a6
COLUMN CONSTRAINT_NAME HEADING "cname"
COLUMN CONSTRAINT_NAME FORMAT a5
COLUMN REASON HEADING "reason"
COLUMN REASON FORMAT a25 word_wrapped

Se asume un caso en que la tabla particionada tp tiene dos particiones, p1 y p2, estas existen en el tablespace USERS y TOOLS respectivamente. También se asume que un índice particionado llamado tpind es definido en tp, y que el índice tiene dos particiones id1 e id2 (este existe en tablespaces id1 e id2 respectivamente). En este caso, puedes desplegar el siguiente output cuando la vista TS_PITR_CHECK es consultada contra el tablespace USERS y TOOLS:

own1 name1 subname1 obj1type ts1_name name2 subname2 obj2type own2 ts2_name cname reason
--- ---- ----- ------ ------- ---- ------ -------- --- -------- --- ------
SYSTEM TP P1 TABLE USER TPIND IP1 INDEX PARTITION PARTITION SYS
ID1 Partitioned Objects not fully contained in the recovery set
SYSTEM TP P2 TABLE TOOLS TPIND IP2 INDEX PARTITION PARTITION SYS
ID2 Partitioned Objects not fully contained in the recovery set

La tabla SYSTEM.tp posee un índice particionado tpind este consiste de la particiones, ip1 en el tablespace id1 e ip2 en el tablespace id2. Elimine tpind o incluya id1 e id2 en el recovery set.

9. Renombrando archivos en la AUXILIARY y Recovery Sets

Antes de comenzar ajustando la instancia Auxiliary para realizar el TSPITR, puedes decidir utilizar el método para nombrar datafiles en el Auxiliary Set. Si los nombres para los archivos en el Auxiliary Set no son diferentes desde el filenames en uso por el TARGET database, entonces RMAN envía una señal de error durante el TSPITR y termina la ejecución.

Por ejemplo, se esta creando la base de datos Auxiliary en el directorio /tmp, entonces el nombre absoluto de la ruta de los datafiles auxiliares deben ser prefijados al /tmp. Estos archivos auxiliares son previstos “solo” para realizar el TSPITR. Si los filenames no son convertidos en el Auxiliary Set, entonces el RMAN envía una señal de error durante el TSPITR y termina la ejecución.

Opcionalmente, puedes también elegir renombrar los datafiles en el Recovery Set Tablespaces en el TARGET (no en la AUXILIARY). Por ejemplo, si estas realizando TSPITR en el datafile ?/oradata/trgt/users01.dbf del tablespace USERS, puedes decidir renombrarlo al destino /disk2/datafiles/users01.dbf. Esta operación es equivalente al comando ALTER DATABASE RENAME FILE para especificar archivos en el TARGET database.

La siguiente tabla describe los comandos y parámetros usados para nombrar datafiles en la AUXILIARY y Recovery Sets durante el TSPITR. El orden de precedencia en la siguiente tabla es desde arriba hacia abajo, también el SET NEWNAME toma precedencia sobre CONFIGURE AUXNAME y el DB_FILE_NAME_CONVERT.

Order of Precedence Command/Parameter Can Name Files in Auxiliary Set? Can Rename Files in Recovery Set?
1 SET NEWNAME Yes Yes
2 CONFIGURE AUXNAME Yes Yes
3 DB_FILE_NAME_CONVERT Yes No

10. Usando SET NEWNAME para renombrar archivos en la AUXILIARY y Recover Sets

Puedes especificar un nuevo nombre para cualquier datafile en el Auxiliary Set en RMAN con el comando SET NEWNAME. RMAN utiliza este nuevo nombre como la ubicación temporal en donde va a restaurar y recuperar el datafile. Este nuevo nombre también elimina el ajuste del parámetro de inicialización DB_FILE_NAME_CONVERT, si este parámetro ha sido definido.

Puedes también usar SET NEWNAME para renombrar datafiles en el Recovery Set del Tablespace. Si especificas un nuevo nombre, entonces el nuevo nombre de archivo reemplaza al original en el TARGET control file. Cuando ajustamos nuevos nombres de archivos, RMAN no chequea conflictos entre nombres de datafiles en la AUXILIARY y la base de datos TARGET. Cualquier conflicto resulta en RMAN un error durante el TSPITR.

10. Utilización de SET NEWNAME para nombrar archivos

Por ejemplo, asume que el Auxiliary Set contiene los siguientes datafiles:

?/oradata/trgt/system01.dbf of the SYSTEM tablespace

?/oradata/trgt/undotbs01.dbf of the undotbs tablespace


El Recovery Set contiene los siguientes datafiles:

?/oradata/trgt/users01.dbf of the users tablespace

?/oradata/trgt/tools01.dbf of the tools tablespace


Necesitas crear la AUXILIARY en el directorio /tmp. También, decides renombrar el datafile tools a /private1/tools01.dbf, el datafile en el tablespace users con su nombre original.
En este caso, puedes utilizar el siguiente comando para ejecutar TSPITR en tools y users, causando que ?/oradata/trgt/tools01.dbf sea renombrado a ?/dbs/tools01.dbf en la base de datos TARGET:

RUN
{
SET NEWNAME FOR DATAFILE '?/oradata/trgt/system01.dbf' TO '/tmp/system01.dbf';
SET NEWNAME FOR DATAFILE '?/oradata/trgt/undotbs01.dbf' TO '/tmp/undotbs01.dbf';
SET NEWNAME FOR DATAFILE '?/oradata/trgt/tools01.dbf' TO '/disk1/tools01.dbf';
RECOVER TABLESPACE tools, users UNTIL SEQUENCE 1034 THREAD 1;
}


11. Usando copias de datafiles en la Auxiliary y Recover Sets

Usando una copia de datafile en disco es mucho más rápida la restauración de un datafile. Por lo tanto, puedes necesitar usar una copia apropiada de un datafile en la recuperación o en el Auxiliary Set en lugar de restaurar y recobrar un datafile.

RMAN TSPITR puede usar una copia de datafile, si cumple las siguientes condiciones:

El nombre del datafile copiado es registrado en el catálogo de recuperación como el nombre auxiliar del correspondiente datafile con los siguientes comandos (donde el filename es el nombre del datafile o el número, y aux_datafile_name es el nombre del datafile auxiliar):

CONFIGURE AUXNAME FOR DATAFILE FILENAME TO auxiliary_datafile_name;

La copia del datafile fue realizada antes del tiempo especificado en la cláusula UNTIL con el siguiente comando de RMAN (Donde ‘filename’ es el nombre del datafile):

COPY DATAFILE 'filename' TO AUXNAME;

Si RMAN utiliza una copia de datafile y el TSPITR es completado exitosamente, entonces el auxiliary_datafile_name es removido desde el catálogo de recuperación, y actualizado al estatus DELETED en el control file. El datafile original en el TARGET es reemplazado por esta copia del datafile después que se ha completado RMAN TSPITR.

Importante:
RMAN no usara una copia de datafile si usas SET NEWNAME para el mismo datafile.



12. Utilizando CONFIGURE AUXNAME para nombrar archivos

Por ejemplo, asumimos que el Auxiliary Set contiene los siguientes datafiles:

?/oradata/trgt/system01.dbf del tablespace SYSTEM

?/oradata/trgt/undotbs01.dbf del tablespace undotbs


El Recovery Set contiene los siguientes datafiles:

?/oradata/trgt/users01.dbf del tablespace users

?/oradata/trgt/tools01.dbf del tablespace tools

También, se asume que ejecutas el siguiente comando antes del TSPITR:

CONFIGURE AUXNAME FOR DATAFILE '?/oradata/trgt/system01.dbf' TO '/copy/system01.dbf';
CONFIGURE AUXNAME FOR DATAFILE '?/oradata/trgt/undotbs01.dbf' TO '/copy/undotbs01.dbf';
CONFIGURE AUXNAME FOR DATAFILE '?/oradata/trgt/tools01.dbf' TO '?/dbs/tools01.dbf';

COPY DATAFILE '?/oradata/trgt/system01.dbf' TO AUXNAME;
COPY DATAFILE '?/oradata/trgt/undotbs01.dbf' TO AUXNAME;
COPY DATAFILE '?/oradata/trgt/tools01.dbf' TO AUXNAME;


En este caso, podemos ejecutar el siguiente comando para ejecutar TSPITR con respecto a los tablespace tools y users, causando que el archivo ?/oradata/trgt/tools01.dbf sea renombrado a ?/dbs/tools01.dbf en el TARGET database:

RECOVER TABLESPACE tools, users UNTIL SEQUENCE 1034 THREAD 1;

13. Preparando el ambiente para realizar TSPITR

Para el siguiente ejemplo asumiremos que la base de datos TARGET será SCTIRT y la base de datos Auxiliary tendrá por nombre SCTIRT2

14. Crear archivo de password

Se debe crear el archivo de password para la instancia Auxiliary de la siguiente manera:

$ cd $ORACLE_HOME/dbs
$ export ORACLE_SID=SCTIRT2
$ orapwd file=orapwSCTIRT2 password=secret entries=5


15. Preparando archivo de parámetros

Es necesario copiar el archivo spfile$SID.ora al directorio $ORACLE_HOME/dbs. Luego de haber copiado este archivo se deben reemplazar valores y agregar ciertos parámetros para completar la configuración.

DB_NAME=SCTIRT

Este parámetro tendrá el mismo nombre de la base de datos TARGET

LOCK_NAME_SPACE=SCTIRT2

Se debe utilizar un nombre diferente al nombre de la base de datos TARGET, este parámetro permitirá tener 2 bases de datos con el mismo nombre iniciadas en el mismo nodo.

CONTROL_FILES= /tmp/control01.ctl
El controlfile se define para la instancia AUXILIARY

DB_FILE_NAME_CONVERT=('/oracle/oradata/SCTIRT/','/tmp/')

Patrones para convertir filenames para los datafiles de la base de datos Auxiliary. Puedes utilizar este parámetro para generar filenames para esos archivos que no fueron nombrados con SET NEWNAME o CONFIGURE AUXNAME. Obtener los nombres de los datafiles consultando la columna name de la vista V$DATAFILE, y asegurar que la conversión de los patrones correspondan al formato del nombre de archivo desplegado en la vista.

LOG_FILE_NAME_CONVERT=('/oracle/oradata/SCTIRT/','/tmp/')

Patrones para convertir filenames para los online redo logs de la base de datos Auxiliary. Obtener el nombre de los online redo logs consultando la columna MEMBER de la vista V$LOGFILE, y asegurar que la conversión de los patrones correspondan al formato del nombre de archivo desplegado en la vista.

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

Ajustar el valor a EXCLUIVE para conectarse a la instancia AUXILIARY por medio del archivo de password

COMPATIBLE=”9.2.0.x”
El mismo valor que posee la base de datos TARGET.

DB_BLOCK_SIZE=8192
Si este parámetro esta configurado en la base de datos TARGET, entonces este debe tener el mismo valor para la instancia AUXILIARY.

15. Asegurar conectividad mediante Oracle Net a la instancia Auxiliary

La instancia Auxiliary debe tener un nombre de servicio válido. Antes de proceder, utilice SQL*Plus para asegurar que puedes establecer una conexión con la instancia Auxiliary.

16. Iniciando la instancia AUXILIARY

Antes de comenzar RMAN TSPITR, utilice SQL*Plus para conectarse a la instancia Auxiliary e iniciar en modo NOMOUNT (especificar el archivo de parámetros si es necesario)

SQL> CONNECT SYS/oracle@SCTIRT2 AS SYSDBA
SQL> STARTUP NOMOUNT PFILE='/tmp/spfileSCTIRT2.ora'




IMPORTANTE:
La instancia AUXILIARY no tiene un control file, solamente iniciar la instancia en modo NOMOUNT. No cree un control file e intente montar o abrir la instancia AUXILIARY para TSPITR.


15. Realizando TSPITR con RMAN

La base de datos AUXILIARY debe encontrarse con el estado NOMOUNT y la base de datos TARGET puede encontrarse montada o abierta para realizar TSPITR. Los pasos en RMAN TSPITR son los siguientes:

Conectarse a la instancia AUXILIARY
Conectarse a la base de datos TARGET
Conectarse al catálogo de recuperación (opcional)
Recobrar el tablespace TBSRIT


$ export ORACLE_SID=SCTIRT2 (instancia auxiliar)
$rman nocatalog
Recovery Manager: Release 9.2.0.6.0 - 64bit Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

RMAN> connect auxiliary /

connected to auxiliary database: SCTIRT (not mounted)

RMAN> connect target sys/secret@SCTIRT

connected to target database: SCTIRT (DBID=2066758420)
using target database controlfile instead of recovery catalog

RMAN> recover tablespace TBSRIT until sequence 21 thread 1;

Starting recover at 17-JAN-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=16 devtype=DISK

printing stored script: Memory Script
{
# set the until clause
set until logseq 21 thread 1;
# restore the controlfile
restore clone controlfile to clone_cf;
# replicate the controlfile
replicate clone controlfile from clone_cf;
# mount the controlfile
sql clone 'alter database mount clone database';
# archive current online log for tspitr to a resent until time
sql 'alter system archive log current';
# avoid unnecessary autobackups for structural changes during TSPITR
sql 'begin dbms_backup_restore.AutoBackupFlag(FALSE); end;';
}

executing script: Memory Script

executing command: SET until clause

Starting restore at 17-JAN-07

allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=13 devtype=DISK
channel ORA_AUX_DISK_1: starting datafile backupset restore
channel ORA_AUX_DISK_1: restoring controlfile
output filename=/usr03/oracle/respaldo/BASES/SCTIRT2/control/control01.ctl
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/usr03/oracle/respaldo/BASES/SCTIRT2/backup/df_t611946029_s11_p1 tag=TAG20070115T170029 params=NULL
channel ORA_AUX_DISK_1: restore complete
Finished restore at 17-JAN-07

replicating controlfile
input filename=/usr03/oracle/respaldo/BASES/SCTIRT2/control/control01.ctl
output filename=/usr03/oracle/respaldo/BASES/SCTIRT2/control/control02.ctl
output filename=/usr03/oracle/respaldo/BASES/SCTIRT2/control/control03.ctl

sql statement: alter database mount clone database

sql statement: alter system archive log current

sql statement: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;

printing stored script: Memory Script
{
# generated tablespace point-in-time recovery script
# set the until clause
set until logseq 21 thread 1;
plsql <<<-- tspitr_2
declare
sqlstatement varchar2(512);
offline_not_needed exception;
pragma exception_init(offline_not_needed, -01539);
begin
sqlstatement := 'alter tablespace '|| 'TBSRIT' ||' offline for recover';
krmicd.writeMsg(6162, sqlstatement);
krmicd.execSql(sqlstatement);
exception
when offline_not_needed then
null;
end; >>>;
# set a destination filename for restore
set newname for datafile 1 to
"/usr03/oracle/respaldo/BASES/SCTIRT2/backup/system01.dbf";
# set a destination filename for restore
set newname for datafile 2 to
"/usr03/oracle/respaldo/BASES/SCTIRT2/backup/undots01.dbf";
# set a destination filename for restore
set newname for datafile 3 to
"/usr03/oracle/respaldo/BASES/SCTIRT/tab/tbsrit01.dbf";
# restore the tablespaces in the recovery set plus the auxilliary tablespaces
restore clone datafile 1, 2, 3;
switch clone datafile all;
#online the datafiles restored or flipped
sql clone "alter database datafile 1 online";
#online the datafiles restored or flipped
sql clone "alter database datafile 2 online";
#online the datafiles restored or flipped
sql clone "alter database datafile 3 online";
# make the controlfile point at the restored datafiles, then recover them
recover clone database tablespace "TBSRIT", "SYSTEM", "UNDOTS";
alter clone database open resetlogs;
# PLUG HERE the creation of a temporary tablespace if export fails due to lack
# of temporary space.
# For example in Unix these two lines would do that:
#sql clone "create tablespace aux_tspitr_tmp
# datafile ''/tmp/aux_tspitr_tmp.dbf'' size 500K";
}

executing script: Memory Script

executing command: SET until clause

sql statement: alter tablespace TBSRIT offline for recover

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting restore at 17-JAN-07

using channel ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: starting datafile backupset restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /usr03/oracle/respaldo/BASES/SCTIRT2/backup/system01.dbf
restoring datafile 00002 to /usr03/oracle/respaldo/BASES/SCTIRT2/backup/undots01.dbf
restoring datafile 00003 to /usr03/oracle/respaldo/BASES/SCTIRT/tab/tbsrit01.dbf
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/usr03/oracle/respaldo/BASES/SCTIRT2/backup/df_t611946029_s11_p1 tag=TAG20070115T170029 params=NULL
channel ORA_AUX_DISK_1: restore complete
Finished restore at 17-JAN-07

datafile 1 switched to datafile copy
input datafilecopy recid=7 stamp=612142225 filename=/usr03/oracle/respaldo/BASES/SCTIRT2/backup/system01.dbf
datafile 2 switched to datafile copy
input datafilecopy recid=8 stamp=612142225 filename=/usr03/oracle/respaldo/BASES/SCTIRT2/backup/undots01.dbf
datafile 3 switched to datafile copy
input datafilecopy recid=9 stamp=612142225 filename=/usr03/oracle/respaldo/BASES/SCTIRT/tab/tbsrit01.dbf

sql statement: alter database datafile 1 online

sql statement: alter database datafile 2 online

sql statement: alter database datafile 3 online

Starting recover at 17-JAN-07
using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 20 is already on disk as file /app9/oracle/admin/SCTIRT/arch/arch_1_20.arc
archive log filename=/app9/oracle/admin/SCTIRT/arch/arch_1_20.arc thread=1 sequence=20
media recovery complete
Finished recover at 17-JAN-07

database opened

printing stored script: Memory Script
{
# export the tablespaces in the recovery set
host 'exp userid =\"/@ as sysdba\" point_in_time_recover=y tablespaces=
TBSRIT file=
tspitr_a.dmp';
# shutdown clone before import
shutdown clone immediate
# import the tablespaces in the recovery set
host 'imp userid =\"sys/massif@SCTIRT as sysdba\" point_in_time_recover=y file=
tspitr_a.dmp';
# online/offline the tablespace imported
sql "alter tablespace TBSRIT online";
sql "alter tablespace TBSRIT offline";
# enable autobackups in case user does open resetlogs from RMAN after TSPITR
sql 'begin dbms_backup_restore.AutoBackupFlag(TRUE); end;';
}

executing script: Memory Script


Export: Release 9.2.0.6.0 - Production on Wed Jan 17 23:30:29 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the OLAP option
JServer Release 9.2.0.6.0 - Production
Export done in WE8ISO8859P9 character set and AL16UTF16 NCHAR character set
server uses WE8ISO8859P1 character set (possible charset conversion)
Note: table data (rows) will not be exported

About to export Tablespace Point-in-time Recovery objects...
For tablespace TBSRIT ...
. exporting cluster definitions
. exporting table definitions
. . exporting table PRUEBA
. exporting referential integrity constraints
. exporting triggers
. end point-in-time recovery
Export terminated successfully without warnings.
host command complete

database closed
database dismounted
Oracle instance shut down


Import: Release 9.2.0.6.0 - Production on Wed Jan 17 23:30:38 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the OLAP option
JServer Release 9.2.0.6.0 - Production

Export file created by EXPORT:V09.02.00 via conventional path
About to import Tablespace Point-in-time Recovery objects...
import done in WE8ISO8859P9 character set and AL16UTF16 NCHAR character set
import server uses WE8ISO8859P1 character set (possible charset conversion)
. importing JBROWN's objects into JBROWN
. . importing table "PRUEBA"
. importing SYS's objects into SYS
Import terminated successfully without warnings.
host command complete

sql statement: alter tablespace TBSRIT online

sql statement: alter tablespace TBSRIT offline

sql statement: begin dbms_backup_restore.AutoBackupFlag(TRUE); end;
Finished recover at 17-JAN-07



17. Conclusión

Se ha creado un esquema llamado JBROWN el cual contiene una tabla con x cantidad de datos de nombre prueba. Esta tabla fue truncada después de realizar el respaldo full y se ha recuperado el tablespace TBSRIT conteniendo la tabla completa con x datos. Es importante recordar que el tablespace fue llevado a un tiempo distinto al recuperarlo sin afectar el funcionamiento de la base de datos TARGET. La instancia AUXILIARY debe encontrarse en el mismo nodo donde reside la base de datos TARGET para realizar TSPITR. Para efecto de este ejercicio el objetivo se ha cumplido y recuperamos completamente la data hasta la secuencia 21.

18. Tareas automáticas realizadas por RMAN durante TSPITR

1. Toma el tablespace a recobrar como offline
2. Restaura el datafile en la instancia Auxiliary
3. Recobra el datafile restaurado al tiempo especificado
4. Abre la base de dato AUXILIARY con la opción RESETLOGS
5. Exporta la metadata del diccionario acerca de los objetos en el tablespace recobrado – El DDL crea los objetos apuntando a las ubicaciones físicas de los datafiles recobrados – a la base de datos TARGET
6. Baja la instancia AUXILIARY
7. Utiliza el comando SWITCH de modo que el TARGET control file ahora apunta a los datafiles en el recovery set donde acaba de ser recuperada en la base de datos AUXILIARY
8. Importa la metadata del diccionario que fue exportada desde la instancia AUXILIARY, permitiendo que los objetos recobrados sean accedidos
16. Preparando el TARGET después de RMAN TSPITR
Todos los tablespaces recobrados están OFFLINE en la base de datos TARGET después de la ejecución exitosa del comando RECOVER. Si el comando RECOVER falla, entonces después de resolver el error puedes re-ejecutar el comando.
Si el import falla por espacio del temporary, se puede recrear el tablespace temporary. Busca el tspitr_7 en /oracle/rdbms/admin/recover.bsq y revisar los comentarios para crear el tablespace temporary.
Si el import falla por que las tablas de import no existen, puedes ejecutar el script CATEXP.SQL en la base de datos TARGET para crear el esquema de importación.


$ export ORACLE_SID=SCTIRT (TARGET)
$ rman nocatalog

Recovery Manager: Release 9.2.0.6.0 - 64bit Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

RMAN> connect target sys/secret@SCTIRT

RMAN> backup tablespace TBSRIT;


RMAN> SQL ‘alter tablespace TBSRIT ONLINE’;

Importante: Si ejecutas en modo NOCATALOG, entonces no puedes realizar TSPITR en un tablespace y entonces nuevamente realizarlo sobre el mismo tablespace a un tiempo igual a o antes del tiempo de TSPITR. Por eso, después de completar TSPITR, se debe hacer un nuevo backup del tablespace, pudiendo realizar TSPITR en el tablespace en cualquier momento después del backup.



19. Limpiando la instancia AUXILIARY

La instancia AUXILIARY no es posible utilizarla después de completar exitosamente el TSPITR. La instancia debe ser limpiada usando los siguientes cambios:

Conectarse a la instancia Auxiliar

$ export ORACLE_SID= SCTIRT2
$ rman nocatalog
Recovery Manager: Release 9.2.0.6.0 - 64bit Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN> connect auxiliary sys/secret@SCTIRT2
- Montar la base de datos usando 'ALTER DATABASE MOUNT CLONE DATABASE'
- Elimine los archivos temporales restaurados por RMAN cuando se realizo TSPITR,

ejecutando las siguientes consultas:
SELECT d.name
FROM v$datafile d, v$tablespace t
WHERE d.ts#=t.ts# AND status in ('SYSTEM', 'ONLINE')
AND t.name !=’TBSRIT’;
SELECT member FROM v$logfile;

SELECT name FROM v$controlfile;
Baje la instancia con SHUTDOWN IMMEDIATE y elimine todos los archivos entregados por las consultas anteriores. Además también borrar el archivo de password asociado a la instancia AUXILIARY.

Espero que sirva este procedimiento completo para recuperar tablespaces en el tiempo en una instancia Auxiliar.

Saludos,
Alberto Silva