Error ORA-39127 cuando estoy haciendo un Export con Datapump

Esta entrada realmente la estoy creando para tener yo un acceso mas rapido, sin tener que pasar por MOS, en nuestro ambiente tuvimos una situacion en donde en nuestra base de datos se instalaron todos los componentes de Oracle, como OLAP y Oracle Text, como no era necesario tenerlos, se tomo la decision de removerlos, pero cuando estabamos corriendo un export , esta fallando con el siguiente error:

ORA-39127: unexpected error from call to "SYS"."DBMS_CUBE_EXP"."SCHEMA_INFO_EXP"
ORA-44002: invalid object name
ORA-06512: at "SYS.DBMS_ASSERT", line 316
ORA-06512: at "SYS.DBMS_METADATA", line 9409

Primero verificamos que ya no existen componentes de OLAP en la base de datos, en este caso, nada mas tenemos RAC y los catalogos necesarios

TESTDB1 >DBA_REGISTRY CONTENTS (VIEW DOES NOT EXISIT IN VERSIONS < 9.2.0)
TESTDB1 >================================================================
TESTDB1 >COMP_ID              COMP_NAME                                VERSION    STATUS
-------------------- ---------------------------------------- ---------- ---------------

CATALOG              Oracle Database Catalog Views            11.2.0.3.0 VALID
CATPROC              Oracle Database Packages and Types       11.2.0.3.0 VALID
RAC                  Oracle Real Application Clusters         11.2.0.3.0 VALID

Y con este query vemos que queda todavia existe informacion en el diccionario de datos refiriendose a OLAP

TESTDB1 >SELECT * FROM SYS.EXPPKGACT$ WHERE PACKAGE = 'DBMS_CUBE_EXP';

PACKAGE                        SCHEMA                              CLASS     LEVEL#

------------------------------ ------------------------------ ---------- ----------
DBMS_CUBE_EXP                  SYS                                     2       1050
DBMS_CUBE_EXP                  SYS                                     4       1050
DBMS_CUBE_EXP                  SYS                                     6       1050

La manera de resolverlo es crear primero un respaldo de la tabla SYS.EXPPKGACT$, por si algo llegara a salir mal, esto lo haces como el usuario SYS

oracle $ sqlplus

SQL*Plus: Release 11.2.0.3.0 Production on Mon Jan 27 02:46:38 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter user-name: /as sysdba

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

TESTDB1 >CREATE TABLE SYS.EXPPKGACT$_BACKUP AS SELECT * FROM SYS.EXPPKGACT$;

Table created.

Una vez que hayas creado el respaldo de la tabla, vas a borrar los datos, con el siguiente delete

TESTDB1 >DELETE FROM SYS.EXPPKGACT$ WHERE PACKAGE = 'DBMS_CUBE_EXP' AND SCHEMA= 'SYS';

3 rows deleted.

TESTDB1 >commit;

Commit complete.

Y ahora si vas a poder realizar tu respaldo con exito, esto lo puedes encontrar en el documento de MOS 1328829.1

Starting "SYSTEM"."DATAPMP__USERS":  system/******** dumpfile=node_TESTDB_users_%U.dmp logfile=node_TESTDB_users.log parfile=/mount/dba01/oracle/recover/export_dp_users.par

Processing object type SCHEMA_EXPORT/USER

Processing object type SCHEMA_EXPORT/SYSTEM_GRANT

Processing object type SCHEMA_EXPORT/ROLE_GRANT

Processing object type SCHEMA_EXPORT/DEFAULT_ROLE

Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA

Processing object type SCHEMA_EXPORT/SYNONYM/SYNONYM

Processing object type SCHEMA_EXPORT/DB_LINK

Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE

Processing object type SCHEMA_EXPORT/SEQUENCE/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC

Processing object type SCHEMA_EXPORT/PACKAGE/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type SCHEMA_EXPORT/FUNCTION/FUNCTION

Processing object type SCHEMA_EXPORT/FUNCTION/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE

Processing object type SCHEMA_EXPORT/PROCEDURE/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER_PACKAGE_SPEC

Processing object type SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION

Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE

Processing object type SCHEMA_EXPORT/VIEW/VIEW

Processing object type SCHEMA_EXPORT/VIEW/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY

Processing object type SCHEMA_EXPORT/EVENT/TRIGGER

Processing object type SCHEMA_EXPORT/POST_SCHEMA/PROCOBJ

ORA-39165: Schema TEST01 was not found.

Master table "SYSTEM"."DATAPMP_USERS" successfully loaded/unloaded

El caso curioso del datafile que "pertenecía" a dos Bases de Datos

En primer lugar quiero empezar diciendo que tengo una idea de cómo sucedió esto, pero no he sido capaz de recrear esta situación, ya que esto me fue heredado, de igual manera tuve la suerte de que el tablespace que tenía el problema era un tablespace DUMMY por lo que no causó un problema.

Ahora si a la descripción del problema, lo que pasa es que tengo una Base de Datos fuente con una ubicación de los datafiles en + DATA1/SOURCE, pero en algún momento alguien añadió una segunda ubicación para la realizar algunas pruebas en un tablespace TEST1 en +DATA2/TEST, esta base de datos fuente se duplicó a través de RMAN hacia 2 bases de datos, llameseles  a ellas DUP1 y DUP2. En el comando duplicate de RMAN , se uso el parámetro DB_FILE_NAME_CONVERT para cambiar la ubicación de los datafiles de la base de datos de origen hacia DUP1 o DUP2, pero en este parámetro solo se puso para la ubicacion de +DATA1/SOURCE y no para +DATA2/TEST .

Lo que se puso en el comando RMAN fue lo siguiente:

DB_FILE_NAME_CONVERT '+DATA1/SOURCE','DATA1/DUP1'

Como debería de haber sido:

DB_FILE_NAME_CONVERT '+DATA1/SOURCE','+DATA1/DUP1','+DATA2/TEST','+DATA1/DUP1'

Y porque el diskgroup y directorio de + DATA2/TEST existen donde DUP1 y DUP2 residiría, no causo ningún problema cuando se corrió el comando DUPLICATE, y esto es algo que todavía es  desconocido para mí, el duplicado termino con éxito para ambas bases de datos y no surgió ningún problema al abrirlas con resetlogs, como lo hace el comando.

Como probablemente ya saben, cuando se emite el comando DUPLICATE, la DBID es implicitamente cambiada, y lo que hace esto es que actualiza el controlfile con el dbid nuevo y también las cabeceras de los datafiles, de esa manera es como sabrá que estos XX datafiles pertenecen a la base de datos NN.

Una vez que ambas bases de datos estaban arriba y corriendo, corri un respaldo de las bases de datos, DUP1 termino exitosamente, el respaldo de DUP2 falló con el siguiente error :

RMAN-06169: could not read file header for datafile 148 error reason 9
RMAN-06056: could not access datafile 148

Una de las primeras cosas que hice fue correr un VALIDATE DATABASE, y me mostraba el mismo error:

RMAN> VALIDATE DATABASE;
Starting validate at 29-NOV-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=145 instance=DUP21 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=164 instance=DUP21 device type=DISK
RMAN-06169: could not read file header for datafile 148 error reason 9
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of validate command at 11/29/2012 01:40:41
RMAN-06056: could not access datafile 148

Lo siguiente que hice fue ver a donde pertenecía el datafile 148 y de igual manera el DBID de  DUP2, ya que el error de la cabecera me llevó a buscar por ahi

DUP21 >select DBID,open_mode from v$database;
 
      DBID OPEN_MODE
---------- ------------------------------------------------------------
2211912429 READ WRITE
 
DUP21 >select file_name from dba_data_files where TABLESPACE_NAME='TEST1';
 
FILE_NAME
--------------------------------------------------------------------------------
+DATA2/test/test01.dbf
 
 
DUP21 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE

Debido al error 06169 RMAN  me decía que no podía leer la cabecera del datafile, hice un volcado de la esta.

DUP21 >oradebug setmypid

Statement processed.

DUP21 >oradebug unlimit

Statement processed.

DUP21 >oradebug dump file_hdrs 3

Statement processed.

DUP21 >oradebug tracefile_name

Y en efecto vi que el DBID de test01.dbf pertenecía a DUP1, que había sido la primera de las dos bases de datos duplicadas

V10 STYLE FILE HEADER:
        Compatibility Vsn = 186646528=0xb200000
        Db ID=4005607769=0xeec0b959, Db Name='DUP1'

Así que, para nada mas estar seguro , fui a DUP1 a verificar, y sí, era el mismo que el DBID del volcado de la cabecera , y de igual manera el tablespace TEST1 estaba en línea, así como en DUP2

DUP11 >select DBID,open_mode from v$database;
 
      DBID OPEN_MODE
---------- ------------------------------------------------------------
4005607769 READ WRITE

DUP11 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE
 
DUP11 >select file_name from dba_data_files where TABLESPACE_NAME='TEST1';
 
FILE_NAME
--------------------------------------------------------------------------------
+DATA2/test/test01.dbf

DUP11 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE

Porque ese tablespace en particular era de ninguna utilidad para la aplicación, simplemente lo tire.

DUP21 >ALTER TABLESPACE TEST1 OFFLINE IMMEDIATE;

Tablespace altered.

DUP21 >DROP TABLESPACE TEST1;

Tablespace dropped.

Lo que te puedes llevar de esta entrada

Tengo que decir que esto es con un OH en 11.2.0.3 con un GI  en 11.2.0.3 en RHEL 5 x86_64, lo que te diria es que cada vez que haces un duplicado y utilizas el DB_FILE_NAME_CONVERT, asegúrate de que todos los lugares están cubiertos. Pero lo realmente me intriga es la forma en que DUP2 fue capaz de abrirse con resetlogs sin que esto fuera un problema, voy a tratar de recrear esto y actualizar este post, siempre y cuando lo logre hacer.

RAC : Opcion para verificar la "salud" de la Base de Datos en version 11.2.0.3

El otro día estaba haciendo una instalación de los binarios del Clusterware 11.2.0.3 y me tope que ahora con la herramienta cluvfy en 11.2.0.3 viene con una opción de verificar la "salud" de la Base de Datos.Para que esta opcion funcione tienes que instalar el usuario cvusys asi como el rol cvusapp , existe un script para poder hacer esto y se encuentra en el directorio CLUVFY_HOME/cv/admin.

Como el usuario oracle corre el script $CLUVFY_HOME/cv/admin/cvusys.sql para crear el usuario, el rol y los grants necesarios para que funcione. Este usuario tendra el tablespace por defacto que tiene la Base de Datos, si no quieres que tenga ese tablespace modifica este script para que lo cree en el tablespace que deseas..

oracle@servidor1.localdomain [TESTDB1] /home/oracle
oracle $ id
uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),501(vboxsf),54322(dba)

TESTDB1> @cvusys.sql

User dropped.


Role dropped.

Enter password for user cvusys 
'Creating user cvusys...'

User created.


Grant succeeded.


Role created.


Grant succeeded.

.
.
.

Una vez que hayas inicializado el ambiente para el usuario de la Base de Datos cvusys verifica que como el usuario de OS grid tengas la variable de ambiente $ORACLE_HOME con el GRID_HOME correcto.

grid@servidor1.localdomain /home/grid
oracle $ id
uid=54324(grid) gid=54321(oinstall) groups=54321(oinstall),501(vboxsf),54322(dba),54323(asmadmin),54325(asmoper)

grid@servidor1.localdomain /home/grid
oracle $ echo $ORACLE_HOME
/mount/oracle/11.2.0.3/grid

Una de las cosas que note fue que si no tienes el GRID_HOME correcto o le pasas el nombre de tu Base Datos en mayúsculas cuando el nombre de la Base de Datos es en minúsculas, te puede arrojar el error PRVG-11005, esto aunque cuando veas el log en $CLUVFY_HOME/cv/log el comando srvctl config database se esta ejecutando correctamente.

grid@servidor1.localdomain /home/grid
oracle $ cluvfy comp healthcheck -collect database -db TESTDB -deviations -save -savedir /home/grid/audit

ERROR:
PRVG-11005 : Database  "TESTDB" is not defined in this cluster


grid@servidor1.localdomain /home/grid/cv/log
root $ more cvutrace.log.0
.
.
.
[17455@servidor1.localdomain] [Worker 0] [ 2012-11-04 22:41:33.595 EST ] [VerificationCommand.execute:232]  Formatted exectask output is:
 <CV_CMD>/mount/oracle/11.2.0.3v1/rdbms/bin/srvctl config database -d TESTDB -a </CV_CMD><CV_VAL>Database unique name: TESTDB
Database name: TESTDB
Oracle home: /mount/oracle/11.2.0.3v1/rdbms
Oracle user: oracle
Spfile: +DATA/TESTDB/PARAMETERFILE/spfileTESTDB.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: TESTDB
Database instances: TESTDB1,TESTDB2
Disk Groups: DATA
Mount point paths:
Services:
Type: RAC
Database is enabled
Database is administrator managed
</CV_VAL><CV_VRES>0</CV_VRES>Exectask: runexe was successful</CV_LOG><CV_ERES>0</CV_ERES>
.
.
.

Cuando usas esta utilería , puedes correrla contra todas las Base de Datos en el cluster si no usas la opción de , lo único que si te digo es que tienes que crear el usuario cvusys en cada una de las Base de Datos del cluster. De la misma manera puedes verificar cuales son las mejores practicas recomendadas por Oracle y como tu Base de datos se desvian de estas con las opciones [-bestpractice|-mandatory] [-deviations].

En este caso , corri la utileria con el nombre de la Base de datos en minúsculas con la opción de mejores practicas (-bestpractice) y termino correctamente.

grid@servidor1.localdomain /home/grid/cv/log
root $ cluvfy comp healthcheck -collect database -db testdb -bestpractice -deviations -save -savedir /home/grid/audit/

Verifying Database "testdb"

Please specify password for user "cvusys" :

Verifying Database Best Practice for "testdb"

Verifying JVM configuration for database ...not met
Verifying Java Role Count ...not met
Verifying Duplicate SYS or SYSTEM Schema Objects ...not met
Verifying Users Granted CONNECT Role ...not met
Verifying DB Log Mode ...not met



******************************************************************************************
        Summary of environment
******************************************************************************************

Date (mm/dd/yyyy)    :  11/05/2012
Time (hh:mm:ss)      :  22:37:28
Cluster name         :  cluster-test
Clusterware version  :  11.2.0.3.0
Grid home            :  /mount/oracle/11.2.0.3/grid
Grid User            :  grid
Operating system     :  Linux2.6.18-238.el5
Database1            :  Database name     -  testdb
                        Database version  -  11.2.0.3
                        Database home     -
                        /mount/oracle/11.2.0.3v1/rdbms

******************************************************************************************
Database recommendation checks for "testdb"
******************************************************************************************
.
.
.

Ahora lo que tienes que hacer es ir al directorio donde guardaste el reporte y ver las desviaciones de las mejores practicas recomendadas por Oracle. Aquí es donde yo te diria que verifiques y tengas cuidado con las recomendaciones que te arroja, ya que una de las recomendaciones era que estaba corriendo en modo ARCHIVE_LOG vs la recomendación NOARCHIVELOG, espero que puedas ver en donde no estoy de acuerdo con este reporte, pero si no estas verificando la salud de tus Base de Datos después de una instalación nueva, esta es una gran manera de empezar y te ayudara en un futuro a ver que es lo que puedo hacer para mejorar mi ambiente.

__________________________________________________________________________________________

Verification Check        :  Duplicate SYS or SYSTEM Schema Objects                       
Verification Description  :  Checks for duplicate SYS or SYSTEM schema objects            
Verification Result       :  NOT MET                                                      
Verification Summary      :  Check for Duplicate SYS or SYSTEM Schema Objects failed      
Additional Details        :  If any duplicate objects were found in the SYS and SYSTEM    
                             schemas, refer to articles in the references section. Read   
                             the exceptions carefully before taking action.               
References (URLs/Notes)   :  https://support.oracle.com/CSP/main/article?cmd=show&type=N  
                             OT&id=1030426.6                                              

Node                Status    Expected Value                Actual Value                  
------------------------------------------------------------------------------------------

testdb              FAILED    sys_duplicate_obj = 0         sys_duplicate_obj = 4         

__________________________________________________________________________________________

Verification Check        :  INVALID objects in the application related schemas           
Verification Description  :  Checks for the presence of INVALID objects in the            
                             application related schemas (non SYS and SYSTEM)             
Verification Result       :  NOT MET                                                      
Verification Summary      :  Check for INVALID objects in the application related         
                             schemas failed                                               
Additional Details        :  Investigate invalid objects in the application related       
                             schemas (non SYS and SYSTEM).                                

Node                Status    Expected Value                Actual Value                  
------------------------------------------------------------------------------------------

testdb              FAILED    app_invalid_obj = 0           app_invalid_obj = 5           

RAC : Secuencia de Arranque del Clusterware de Oracle 11gR2

Para cualquiera que haya trabajado con la versión 11gR2 del Clusterware de Oracle se ha topado con el diagrama de arranque de esta tecnología, y la verdad desde mi punto de vista es realmente difícil de ver y entender, y no es "KISS" , Keep It Simple Stupid por sus siglas en ingles.

Luego hay un segundo diagrama, que ese esta mucho mejor, pero de igual manera, la calidad de este segundo diagrama es de muy mala calidad , y para mi muy mala vista ,no me ayuda en nada.

Si quiero mencionar que no estoy poniendo nada nuevo en este post que no puedas encontrar en el documento de MOS 1053147.1, simplemente lo estoy poniendo en un formato que sea mas legible y fácil de entender.

Dale click a la imagen para verla en su tamaño real:

Las descripciones de abajo son una traducción del mismo documento de MOS

Unix INIT manda a llamar a init.ohasd (con respwan) , que a su vez manda a llamar los procesos OHASD (Oracle High Availability Services Deamon, por sus siglas en ingles) . Este demonio genera 4 procesos:

Nivel 1 .- OHASD genera :

    cssdagent          - Agente responsable de generar  CSSD.
    orarootagent     - Agente responsable de administrar todos los recursos ohasd del usuario root.
    oraagent           - Agente responsable de administrar todos los recursos ohasd del usuario oracle o grid 
                              (Dependiendo bajo que usuario hayas instalado los binarios del clusterware).
    cssdmonitor      - Monitorea el CSSD y la "salud" del nodo (así como el agente cssdagent).

Nivel 2 .- El agente orarootagent de OHASD genera:

    CSDD (ora.cssd)        - Servicios de Sincronizacion del Cluster (Cluster Synchronization Services)
    CRSD(ora.crsd)         - Demonio primario responsable de administrar los recursos del cluster.
    CTSSD(ora.ctssd)      - Demonio de Sincronizacion de Servicios del Tiempo del Cluster
    Diskmon(ora.diskmon)
    ACFS (ASM Cluster File System) Drivers

Nivel 3 .-  CRSD genera

    orarootagent     - Agente responsable de administrar todos los recursos crsd del usuario root.
    oraagent           - Agente responsable de managing todos los recursos crsd del usuario oracle o grid.


Nivel 4 .- CRSD orarootagent genera:

    Network resource      - Para monitorear la Red Publica
    SCAN VIP(s)           - Single Client Access Name Virtual IPs
    Node VIPs               - IP Virtual del Nodo,Uno por Nodo
    ACFS Registery       - Para montar el Sistema de Archivos Cluster ASM (ASM Cluster File System
    GNS VIP (opcional) - VIP para GNS

  Nivel 4 .- CRSD oraagent spawns:

    ASM Resource   - Recurso de Instancia(s) de ASM
    Diskgroup           - Usado para administrar/monitorear grupos de discos de ASM .
    DB Resource      - Usado para administrar/monitorear las BD's y las instancias
    SCAN Listener   - Listener para SCAN, escuchando la IP Virtual del  SCAN
    Listener               - Listener del Nodo, escuchando la VIP del Nodo.
    Services              - Usado para administrar y monitorear servicios
    ONS                   - Servicio de Notificación de Oracle (Oracle Notification Service)
    eONS                 - Servicio de Notificación de Oracle Mejorado (Enhanced Oracle Notification Service)
    GSD                   - Para compatibilidad hacia atrás con 9i
    GNS (opcional)   - Servicio de Nombres de Gird (Grid Naming Service) - Realiza resolución de nombres

RMAN : Crear un respaldo consistente y un RESTORE POINT todo a la vez

Una característica que tiene RMAN en 11g es que tienes la posibilidad de crear un punto de restauración en el mismo respaldo, este método es muy útil, sobre todo cuando vas a hacer una actualización importante en tu Base de Datos y tienes que crear un respaldo antes, este es el mejor método desde mi punto de vista.

Lo primero , es que verifico que no hay un punto de restauración para mi base de datos

TESTDB> set linesize 121
TESTDB> col name format a15
TESTDB> col time format a32

TESTDB> SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size
  2  FROM gv$restore_point;

no rows selected

Ahora lo que hago es que corro un respaldo con la opción de KEEP UNTIL y RESTORE POINT

RMAN> RUN
2>  {
3> BACKUP AS COMPRESSED BACKUPSET
4>  INCREMENTAL LEVEL = 0
5>  DATABASE
6>   FORMAT '/mount/copy01/TESTDB/oracle/TESTDB/incr/%d_HOT_%M%D%Y_%p_%s' 
7>   TAG TESTDB
8>   KEEP UNTIL TIME 'SYSDATE + 5'
9>   RESTORE POINT BEFORE_UPGRADE;
10> }
Starting backup at Oct 25 2012 08:41:49
current log archived

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:50
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/mount/u01/oracle/TESTDB/data/system01.dbf
input datafile file number=00003 name=/mount/u01/oracle/TESTDB/data/undotbs1_01.dbf
input datafile file number=00004 name=/mount/u01/oracle/TESTDB/data/users01.dbf
input datafile file number=00002 name=/mount/u01/oracle/TESTDB/data/sysaux01.dbf
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:50
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:57
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_24 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:57
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:57
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:58
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_25 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01


current log archived
using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:58
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=19 RECID=19 STAMP=797589718
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:58
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:59
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_26 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:59
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:42:00
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:42:01
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_27 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at Oct 25 2012 08:42:01

Para verificar que se creo el punto de restauración corro los siguientes comandos en RMAN

RMAN> list restore point all;

SCN              RSP Time             Type       Time                 Name
---------------- -------------------- ---------- -------------------- ----
234073                                           Oct 25 2012 08:41:58 BEFORE_UPGRADE

y en Sqlplus

SQL> SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size
  2  FROM gv$restore_point;

NAME         SCN TIME        DATABASE_INCARNATION# GUA STORAGE_SIZE
--------------- ---------- -------------------------------- --------------------- --- ------------
BEFORE_UPGRADE     234073 25-OCT-12 08.41.58.000000000 AM   1 NO   0

Si te fijas, el SCN es el mismo , 234073,  que es lo que andamos buscando. En dado caso de que tengas que hacer un rollback, a este SCN seria al que regresarias.

Este respaldo de igual manera lo podemos utilizar para clonar una base de datos hasta el punto de restauración que creaste con la opción TO RESTORE POINT, no puse toda la salida, pero si te fijas abajo, esta recuperando hasta el punto de restauración que creamos en la Base de Datos TESTDB

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB] /mount/dba01/oracle/TESTCOPY/scripts
oracle $ rman target / auxiliary sys@TESTCOPY


RMAN> RUN
2> {  
3>   ALLOCATE AUXILIARY CHANNEL newdb DEVICE TYPE disk; 
4>   DUPLICATE TARGET DATABASE TO testcopy
5>     TO RESTORE POINT BEFORE_UPGRADE
6>      DB_FILE_NAME_CONVERT ('/mount/u01/oracle/TESTDB/','/mount/u01/oracle/TESTCOPY/','/mount/u02/oracle/TESTDB/','/mount/u02/oracle/TESTCOPY/')
7> LOGFILE
8>       GROUP 1 ('/mount/u01/oracle/TESTCOPY/log/redo01_1.f',
9>                '/mount/u02/oracle/TESTCOPY/log/redo01_2.f') SIZE 4M,
10>       GROUP 2 ('/mount/u01/oracle/TESTCOPY/log/redo02_1.f',
11>                '/mount/u02/oracle/TESTCOPY/log/redo02_2.f') SIZE 4M,
12>       GROUP 3 ('/mount/u01/oracle/TESTCOPY/log/redo03_1.f',
13>                '/mount/u02/oracle/TESTCOPY/log/redo03_2.f') SIZE 4M REUSE;
14> }
using target database control file instead of recovery catalog
allocated channel: newdb
channel newdb: SID=19 device type=DISK

Starting Duplicate Db at Oct 25 2012 08:50:53

contents of Memory Script:
{
   set to restore point  'BEFORE_UPGRADE';
   sql clone "alter system set  db_name = 
 ''TESTDB'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   sql clone "alter system set  db_unique_name = 
 ''TESTCOPY'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   restore clone primary controlfile;
   alter clone database mount;
}
.
.
.
contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at Oct 25 2012 08:51:57
released channel: newdb

Espero que este método te sirva en tus próximas actualizaciones.

Oracle Open World 2012 : La Experiencia

Este año tuve la oportunidad de asistir al Oracle Open World, y desde mi punto de vista es algo que todo mundo que esta relacionado en el ambiente de las tecnologias de Oracle tiene que hacer por lo menos una vez en su vida, ya que no es nada mas lo que aprendes en el evento, sino como lo dice el titulo , es toda una experiencia y en todos los sentidos.

Vas a tener la oportunidad de escuchar el rumbo que tiene la empresa y sus productos , que si estas leyendo este blog es, por que estas interesado en esta tecnologia o ya llevas varios años manejandola. Esta vez toco el anuncio de la nueva version de la Base de Datos, 12c , que como puedes imaginar la "c" es por "Cloud" (Nube en ingles).

Y viene un cambio bastante significante en lo que es el concepto que tenemos en la relacion de Base de Datos e Instancia. Ya que hasta la version 11.2.0.3, toda Base de Datos podia tener una o mas Instancias, pero una Instancia solo podia tener una Base de Datos.

Esto va a cambiar en 12c , ya que ahora va a existir un nuevo tipo de Base de Datos, llamada Base de Datos Contenedor , esta Base de Datos va a tener una instancia ( procesos y memoria) y a esta Base de Datos/Instancia le vas a "conectar" tus otras Bases de Datos, estas se llaman Bases de Datos con capacidad de Conectarse (Pluggable Databases o PDB).  

Regresando al tema del OOW, vas a tener la oportunidad de conocer, platicar y hasta hecharte un cafe o cerveza si es tu gusto con las personas mas respetadas del ambito y escuchar que tienen que decir al respecto del rumbo que esta tomando Oracle.

Ya que estas ahi vas a poder conocer una ciudad que esta llena de opciones y aventuras para todos los gustos. Asi que el proximo año toma la iniciativa y nos vemos en el OOW 2013.

Aqui otras entradas de las experiencias del Oracle Open World 2012 , estas entradas estan en ingles

Oracle OpenWorld 2012: A photographic experience

Favourite Oracle 12c database features of OpenWorld Bloggers

The Fun of Oracle OpenWorld

Oracle OpenWorld - Swim in the Bay 2012