Oracle 12c New Features : Restauración de tablas con RMAN



A partir de Oracle12c se agrega una funcionalidad que hace mucho la estábamos pidiendo, el poder recuperar sólo una tabla desde un respaldo RMAN.



Imagínense ustedes que yo elimino una tabla , o que se produce una corrupción lógica o simplemente borro registros y que ni siquiera con FlashBack puedo recuperar, pues ante eso puedo tomar un respaldo de mi base de datos y cargarlo completamente en una máquina y posterior a eso sacar la tabla con un expdp , pues eso es bien engorroso y muchas veces inviable, pero es lo que hay.

Desde ahora eso se hace , pero de forma automática con el comando RECOVER TABLE dentro de RMAN :)




Algunas cosas a tener en cuenta :

  • Antes de hacer una recuperación de una tabla , debe existir un respaldo full de la base con RMAN, incluído el UNDO, SYSTEM, SYSAUX y el tablespace donde reside la tabla
  • Se pueden recuperar una o más tablas desde distintos usuarios, incluso se pueden recuperar particiones de una tabla
  • Sólo se pueden recuperar tablas dentro del mismo usuario dueño, no se pueden redireccionar tablas a otros usuarios
  • Si se quiere remapear la tabla a otro tablespace, el nuevo tablespace debe estar generado
  • Las tablas y particiones de las cuales SYS es el dueño no se pueden recuperar
  • Las tablas y particiones que se encuentran en los tablespaces SYSTEM y SYSAUX , no pueden ser recuperadas desde respaldo
  • Al restaurar una tabla Oracle genera una instancia de paso, pero está última posee valores asociados a sus parámetros los cuales deben ser chequeados, por ejemplo para el tamaño de la SGA
  • Se pueden recuperar tablas y particiones desde un respaldo RMAN de una base de datos cuya versión es igual o superior a la 11gr1
  • Tablas y particiones de tables no pueden ser recuperadas en una base de datos Standby
    La base de datos debe estar en modo READ-WRITE
  • La base de datos debe estar en modo ARCHIVELOG
  • Se pueden recuperar tablas según un número de SCN , según un número de secuencia o según una fecha (TIME)
  • Se pueden hacer recuperaciones de tables en una base de datos PDB (Nuevo concepto de Cloud Oracle)


    Cuando se ejecuta el comando RECOVER TABLE se ejecutan las siguientes actividades de forma automática :

    1) Se determina de forma automática que backup es el que contiene la tabla , dado el punto en el tiempo donde deseo recuperar la tabla
    2) RMAN levanta una instancia auxiliar con un SID , con valores estandar para su archivo de inicialización
    3) Se lee el backupset que contiene la tabla
    4) Se carga el controlfile desde el respaldo a una ruta creada según el parámetro "AUXILIARY DESTINATION"
    5) Se restaura el tablespace de UNDO , SYSAUX, SYSTEM y el tablespace que contiene la data de la tabla o tablas
    6) Se aplican las transacciones desde los archives respaldados hacía la tabla
    7) Se crea un directorio para dejar un respaldo expdp de las tablas a restaurar, este directorio está bajo la ruta definida en el parámetro "DATAPUMP DESTINATION"
    8) Se realiza un expdp de las tablas a restaurar en el directorio generado en el punto anterior
    9) Se genera un impdp de la tabla que está contenida en el archivo generado en el punto anterior
    10) Se hace una bajada de la instancia temporal
    11) Se borran los datafiles temporales generados
    12) Se elimina el respaldo generado en el punto (8)


    He acá algunos ejemplos del comando RESTORE

    RECOVER TABLE prod1.objetos1
    UNTIL TIME "to_date('13-07-2013 00:40:00','dd-mm-yyyy hh24:mi:ss')"
    AUXILIARY DESTINATION 'c:\'
    DATAPUMP DESTINATION 'c:\data'
    DUMP FILE 'prod1_objetos1_exp_dump.dat'
    ;

    NOTA : Con este comando se hace una recuperación de la tabla PROD1.OBJETOS1 , se generarán los datafiles temporales en la ruta "c:\" , se generará el respaldo de export datapump en la ruta "c:\data" y desde la misma ruta se hará el import , y el nombre del archivo se llamará "prod1_objetos1_exp_dump.dat"


    RECOVER TABLE prod1.objetos1 , prod2.objetos2
    UNTIL SEQUENCE 221
    AUXILIARY DESTINATION 'c:\'
    DATAPUMP DESTINATION 'c:\data'
    DUMP FILE 'prod1_objetos1_exp_dump.dat'
    REMAP TABLE 'PROD1'.'OBJETOS1':'NUEVA_TABLA4','PROD2'.'OBJETOS2':'NUEVA_TABLA3'
    ;

    Nota : Con este comando realizamos la recuperación de las tablas PROD1.OBJETOS1 y PROD2.OBJETOS2, se realizará la recuperación de la tabla hasta la secuencia 221, se dejarán los respaldos de export datapump en el directorio "c:\data", se dejan los datafiles temporales en la ruta "c:\", la tabla original se llamaba PROD1.OBJETOS1 se llamará ahora PROD1.NUEVA_TABLA4 y la tabla llamada PROD2.OBJETOS2 se llamará NUEVA_TABLA3


    RECOVER TABLE prod1.objetos1 , prod2.objetos2
    UNTIL SEQUENCE 435
    AUXILIARY DESTINATION 'c:\'
    DATAPUMP DESTINATION 'c:\data'
    DUMP FILE 'prod1_objetos1_exp_dump.dat'
    NOTABLEIMPORT
    ;

    Nota : Con este comando realizamos la recuperación de las tablas PROD1.OBJETOS1 y PROD2.OBJETOS2, se realizará la recuperación de la tabla hasta la secuencia 435, se dejarán los respaldos de export datapump en el directorio "c:\data", se dejan los datafiles temporales en la ruta "c:\", y sólo se llevará a cabo el export de la tabla y no el import



    Claúsulas importantes :

  • AUXILIARY DESTINATION : Es la ruta donde Oracle va a dejar los datafiles recuperados (UNDO, SYSTEM, SYSAUX y los datafiles del tablespace donde estaba la tabla al momento del respaldo)
  • SET NEWNAME : Esta es la nueva ruta que se le puede asignar a cada datafile que se va a recuperar para levantar la base de datos auxiliar
  • UNTIL TIME : Fecha hasta la cual será recuperada la tabla
  • REMAP TABLE : Con esta claúsula se puede restaurar la tabla con otro nombre, pero siempre en el mismo esquema, cuando se usa esta claúsula no se restauran ni las constraints ni los índices que haya poseído la tabla
  • REMAP TABLESPACE : Con esta claúsula se puede recuperar la tabla en otro tablespace, este último tablespace debe estar generado
  • DATAPUMP DESTINATION : , si se omite está claúsula el archivo datapump generado quedará enla ruta "AUXILIARY DESTINATION" , si está última ruta no se ha generado, el archivo datapump será generado en $ORACLE_HOME/dbs
  • DUMP FILE : Este es el nombre de mi archivo export datapump, si se omite esta claúsula , Oracle le asigna un nombre propio
  • NOTABLEIMPORT : Con esta claúsula se le indica a Oracle que no importe la tabla, sólo que deje disponible en disco el archivo de expdp


    He aquí un ejemplo práctico de una recuperación de tablas en RMAN

    ** Nos conectamos con RMAN
    C:\Users\Inmetrics-Hector>rman

    Recovery Manager: Release 12.1.0.1.0 - Production on Sßb Jul 13 00:28:57 2013

    Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.

    ** Acá nos conectamos a la base de datos target con el rol SYSBACKUP
    RMAN> connect target "rmanuser/rmanuser@prod12c as sysbackup";

    connected to target database: PROD (DBID=232315537)

    ** Ejecutamos la recuperación de la tabla
    RECOVER TABLE prod1.objetos1
    UNTIL TIME "to_date('13-07-2013 00:40:00','dd-mm-yyyy hh24:mi:ss')"
    AUXILIARY DESTINATION 'c:\'
    DATAPUMP DESTINATION 'c:\'
    DUMP FILE 'prod1_objetos1_exp_dump.dat'
    ;

    Starting recover at 13/07/13
    using channel ORA_DISK_1
    RMAN-05026: WARNING: presuming following set of tablespaces applies to specified Point-in-Time

    List of tablespaces expected to have UNDO segments
    Tablespace SYSTEM
    Tablespace UNDOTBS1

    ** Se levanta la instancia de forma automática con un SID creado por Oracle
    Creating automatic instance, with SID='hkbC'

    ** Inicialización de la instancia , se muestran los parámetros
    initialization parameters used for automatic instance:
    db_name=PROD
    db_unique_name=hkbC_pitr_PROD
    compatible=12.1.0.0.0
    db_block_size=8192
    db_files=200
    sga_target=1G
    processes=80
    diagnostic_dest=C:\APP\INMETRICS-HECTOR
    db_create_file_dest=c:\
    log_archive_dest_1='location=c:\'
    #No auxiliary parameter file used

    ** Se levanta la instancia
    starting up automatic instance PROD

    Oracle instance started

    Total System Global Area 1068937216 bytes

    Fixed Size 2410864 bytes
    Variable Size 281020048 bytes
    Database Buffers 780140544 bytes
    Redo Buffers 5365760 bytes
    Automatic instance created

    contents of Memory Script:
    {
    # set requested point in time
    set until time "to_date('13-07-2013 00:40:00','dd-mm-yyyy hh24:mi:ss')";
    # restore the controlfile
    restore clone controlfile;
    # mount the controlfile
    sql clone 'alter database mount clone database';
    # archive current online log
    sql 'alter system archive log current';
    }
    executing Memory Script

    executing command: SET until clause

    ** Comienza la restauración
    Starting restore at 13/07/13
    allocated channel: ORA_AUX_DISK_1
    channel ORA_AUX_DISK_1: SID=11 device type=DISK

    channel ORA_AUX_DISK_1: starting datafile backup set restore
    channel ORA_AUX_DISK_1: restoring control file
    channel ORA_AUX_DISK_1: reading from backup piece C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\BACKUPSET\2013_07_13\O1_MF_NCSNF_TAG201307
    13T003700_8Y1PHZ61_.BKP
    channel ORA_AUX_DISK_1: piece handle=C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\BACKUPSET\2013_07_13\O1_MF_NCSNF_TAG20130713T003700_8Y1
    PHZ61_.BKP tag=TAG20130713T003700
    channel ORA_AUX_DISK_1: restored backup piece 1
    channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
    output file name=C:\PROD\CONTROLFILE\O1_MF_8Y1VL6PM_.CTL
    Finished restore at 13/07/13

    sql statement: alter database mount clone database

    sql statement: alter system archive log current

    ** Se redireccionan los nuevos datafiles a la ruta especificada en el parámetro AUXILIARY DESTINATION
    contents of Memory Script:
    {
    # set requested point in time
    set until time "to_date('13-07-2013 00:40:00','dd-mm-yyyy hh24:mi:ss')";
    # set destinations for recovery set and auxiliary set datafiles
    set newname for clone datafile 1 to new;
    set newname for clone datafile 5 to new;
    set newname for clone datafile 3 to new;
    set newname for clone tempfile 1 to new;
    # switch all tempfiles
    switch clone tempfile all;
    # restore the tablespaces in the recovery set and the auxiliary set
    restore clone datafile 1, 5, 3;
    switch clone datafile all;
    }
    executing Memory Script

    executing command: SET until clause

    executing command: SET NEWNAME

    executing command: SET NEWNAME

    executing command: SET NEWNAME

    executing command: SET NEWNAME

    renamed tempfile 1 to C:\PROD\DATAFILE\O1_MF_TEMP_%U_.TMP in control file

    Starting restore at 13/07/13
    using channel ORA_AUX_DISK_1

    channel ORA_AUX_DISK_1: starting datafile backup set restore
    channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_AUX_DISK_1: restoring datafile 00001 to C:\PROD\DATAFILE\O1_MF_SYSTEM_%U_.DBF
    channel ORA_AUX_DISK_1: restoring datafile 00005 to C:\PROD\DATAFILE\O1_MF_UNDOTBS1_%U_.DBF
    channel ORA_AUX_DISK_1: restoring datafile 00003 to C:\PROD\DATAFILE\O1_MF_SYSAUX_%U_.DBF
    channel ORA_AUX_DISK_1: reading from backup piece C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\BACKUPSET\2013_07_13\O1_MF_NNNDF_TAG201307
    13T003700_8Y1PCFB4_.BKP
    channel ORA_AUX_DISK_1: piece handle=C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\BACKUPSET\2013_07_13\O1_MF_NNNDF_TAG20130713T003700_8Y1
    PCFB4_.BKP tag=TAG20130713T003700
    channel ORA_AUX_DISK_1: restored backup piece 1
    channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:02:35
    Finished restore at 13/07/13

    datafile 1 switched to datafile copy
    input datafile copy RECID=4 STAMP=820634924 file name=C:\PROD\DATAFILE\O1_MF_SYSTEM_8Y1VLK6X_.DBF
    datafile 5 switched to datafile copy
    input datafile copy RECID=5 STAMP=820634924 file name=C:\PROD\DATAFILE\O1_MF_UNDOTBS1_8Y1VLK9F_.DBF
    datafile 3 switched to datafile copy
    input datafile copy RECID=6 STAMP=820634924 file name=C:\PROD\DATAFILE\O1_MF_SYSAUX_8Y1VLK86_.DBF

    contents of Memory Script:
    {
    # set requested point in time
    set until time "to_date('13-07-2013 00:40:00','dd-mm-yyyy hh24:mi:ss')";
    # online the datafiles restored or switched
    sql clone "alter database datafile 1 online";
    sql clone "alter database datafile 5 online";
    sql clone "alter database datafile 3 online";
    # recover and open database read only
    recover clone database tablespace "SYSTEM", "UNDOTBS1", "SYSAUX";
    sql clone 'alter database open read only';
    }
    executing Memory Script

    executing command: SET until clause

    sql statement: alter database datafile 1 online

    sql statement: alter database datafile 5 online

    sql statement: alter database datafile 3 online

    Starting recover at 13/07/13
    using channel ORA_AUX_DISK_1

    starting media recovery

    archived log for thread 1 with sequence 18 is already on disk as file C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\
    O1_MF_1_18_8Y1PJ2G8_.ARC
    archived log for thread 1 with sequence 19 is already on disk as file C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\
    O1_MF_1_19_8Y1TDNO6_.ARC
    archived log file name=C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\O1_MF_1_18_8Y1PJ2G8_.ARC thread=1 sequence=18
    archived log file name=C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\O1_MF_1_19_8Y1TDNO6_.ARC thread=1 sequence=19
    media recovery complete, elapsed time: 00:00:02
    Finished recover at 13/07/13

    sql statement: alter database open read only

    contents of Memory Script:
    {
    sql clone "create spfile from memory";
    shutdown clone immediate;
    startup clone nomount;
    sql clone "alter system set control_files =
    ''C:\PROD\CONTROLFILE\O1_MF_8Y1VL6PM_.CTL'' comment=
    ''RMAN set'' scope=spfile";
    shutdown clone immediate;
    startup clone nomount;
    # mount database
    sql clone 'alter database mount clone database';
    }
    executing Memory Script

    sql statement: create spfile from memory

    database closed
    database dismounted
    Oracle instance shut down

    connected to auxiliary database (not started)
    Oracle instance started

    Total System Global Area 1068937216 bytes

    Fixed Size 2410864 bytes
    Variable Size 285214352 bytes
    Database Buffers 775946240 bytes
    Redo Buffers 5365760 bytes

    sql statement: alter system set control_files = ''C:\PROD\CONTROLFILE\O1_MF_8Y1VL6PM_.CTL'' comment= ''RMAN set'' scope=spfile

    Oracle instance shut down

    connected to auxiliary database (not started)
    Oracle instance started

    Total System Global Area 1068937216 bytes

    Fixed Size 2410864 bytes
    Variable Size 285214352 bytes
    Database Buffers 775946240 bytes
    Redo Buffers 5365760 bytes

    sql statement: alter database mount clone database

    contents of Memory Script:
    {
    # set requested point in time
    set until time "to_date('13-07-2013 00:40:00','dd-mm-yyyy hh24:mi:ss')";
    # set destinations for recovery set and auxiliary set datafiles
    set newname for datafile 6 to new;
    # restore the tablespaces in the recovery set and the auxiliary set
    restore clone datafile 6;
    switch clone datafile all;
    }
    executing Memory Script

    executing command: SET until clause

    executing command: SET NEWNAME

    Starting restore at 13/07/13
    allocated channel: ORA_AUX_DISK_1
    channel ORA_AUX_DISK_1: SID=11 device type=DISK

    channel ORA_AUX_DISK_1: starting datafile backup set restore
    channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_AUX_DISK_1: restoring datafile 00006 to C:\HKBC_PITR_PROD\DATAFILE\O1_MF_USERS_%U_.DBF
    channel ORA_AUX_DISK_1: reading from backup piece C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\BACKUPSET\2013_07_13\O1_MF_NNNDF_TAG201307
    13T003700_8Y1PCFB4_.BKP
    channel ORA_AUX_DISK_1: piece handle=C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\BACKUPSET\2013_07_13\O1_MF_NNNDF_TAG20130713T003700_8Y1
    PCFB4_.BKP tag=TAG20130713T003700
    channel ORA_AUX_DISK_1: restored backup piece 1
    channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:07
    Finished restore at 13/07/13

    datafile 6 switched to datafile copy
    input datafile copy RECID=8 STAMP=820635020 file name=C:\HKBC_PITR_PROD\DATAFILE\O1_MF_USERS_8Y1VT5JJ_.DBF

    contents of Memory Script:
    {
    # set requested point in time
    set until time "to_date('13-07-2013 00:40:00','dd-mm-yyyy hh24:mi:ss')";
    # online the datafiles restored or switched
    sql clone "alter database datafile 6 online";
    # recover and open resetlogs
    recover clone database tablespace "USERS", "SYSTEM", "UNDOTBS1", "SYSAUX" delete archivelog;
    alter clone database open resetlogs;
    }
    executing Memory Script

    executing command: SET until clause

    sql statement: alter database datafile 6 online

    Starting recover at 13/07/13
    using channel ORA_AUX_DISK_1

    starting media recovery

    archived log for thread 1 with sequence 18 is already on disk as file C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\
    O1_MF_1_18_8Y1PJ2G8_.ARC
    archived log for thread 1 with sequence 19 is already on disk as file C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\
    O1_MF_1_19_8Y1TDNO6_.ARC
    archived log file name=C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\O1_MF_1_18_8Y1PJ2G8_.ARC thread=1 sequence=18
    archived log file name=C:\APP\INMETRICS-HECTOR\FAST_RECOVERY_AREA\PROD\ARCHIVELOG\2013_07_13\O1_MF_1_19_8Y1TDNO6_.ARC thread=1 sequence=19
    media recovery complete, elapsed time: 00:00:01
    Finished recover at 13/07/13

    database opened

    ** Una vez restaurada y abierta la base de datos se comienza con la generación del export datapump de las tablas que vamos a restaurar
    contents of Memory Script:

    ** Se crea el directorio donde irá el respaldo efectuado con export datapump, esto es dado por el DATAPUMP DESTINATION
    {
    # create directory for datapump import
    sql "create or replace directory TSPITR_DIROBJ_DPDIR as ''
    c:\''";
    # create directory for datapump export
    sql clone "create or replace directory TSPITR_DIROBJ_DPDIR as ''
    c:\''";
    }
    executing Memory Script

    sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as ''c:\''

    sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as ''c:\''

    ** Se lleva a cabo el export datapump desde las tablas que están en la base de datos auxiliar
    Performing export of tables...
    EXPDP> Iniciando "SYS"."TSPITR_EXP_hkbC_jcnA":
    EXPDP> Estimaci¾n en curso mediante el mÚtodo BLOCKS...
    EXPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA
    EXPDP> Estimaci¾n total mediante el mÚtodo BLOCKS: 13 MB
    EXPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/TABLE
    EXPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
    EXPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/STATISTICS/MARKER
    EXPDP> . . "PROD1"."OBJETOS1" 10.35 MB 90785 filas exportadas
    EXPDP> La tabla maestra "SYS"."TSPITR_EXP_hkbC_jcnA" se ha cargado/descargado correctamente
    EXPDP> ******************************************************************************
    EXPDP> El juego de archivos de volcado para SYS.TSPITR_EXP_hkbC_jcnA es:
    EXPDP> C:\PROD1_OBJETOS1_EXP_DUMP.DAT
    EXPDP> El trabajo "SYS"."TSPITR_EXP_hkbC_jcnA" ha terminado correctamente en Sßb Jul 13 02:12:52 2013 elapsed 0 00:00:44
    Export completed

    contents of Memory Script:
    {
    # shutdown clone before import
    shutdown clone abort
    }
    executing Memory Script

    Oracle instance shut down

    ** Acá se lleva a cabo el import de las tablas
    Performing import of tables...
    IMPDP> La tabla maestra "SYSBACKUP"."TSPITR_IMP_hkbC_Eykg" se ha cargado/descargado correctamente
    IMPDP> Iniciando "SYSBACKUP"."TSPITR_IMP_hkbC_Eykg":
    IMPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/TABLE
    IMPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA
    IMPDP> . . "PROD1"."OBJETOS1" 10.35 MB 90785 filas importadas
    IMPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
    IMPDP> Procesando el tipo de objeto TABLE_EXPORT/TABLE/STATISTICS/MARKER
    IMPDP> El trabajo "SYSBACKUP"."TSPITR_IMP_hkbC_Eykg" ha terminado correctamente en Sßb Jul 13 02:13:49 2013 elapsed 0 00:00:31
    Import completed

    ** Una vez que termina la restauración, se eliminan todos los datafiles temporales generados, más los respaldos de datapump
    Removing automatic instance
    Automatic instance removed
    auxiliary instance file C:\PROD\DATAFILE\O1_MF_TEMP_8Y1VQS7J_.TMP deleted
    auxiliary instance file C:\HKBC_PITR_PROD\ONLINELOG\O1_MF_3_8Y1VTP20_.LOG deleted
    auxiliary instance file C:\HKBC_PITR_PROD\ONLINELOG\O1_MF_2_8Y1VTNKX_.LOG deleted
    auxiliary instance file C:\HKBC_PITR_PROD\ONLINELOG\O1_MF_1_8Y1VTLNT_.LOG deleted
    auxiliary instance file C:\HKBC_PITR_PROD\DATAFILE\O1_MF_USERS_8Y1VT5JJ_.DBF deleted
    auxiliary instance file C:\PROD\DATAFILE\O1_MF_SYSAUX_8Y1VLK86_.DBF deleted
    auxiliary instance file C:\PROD\DATAFILE\O1_MF_UNDOTBS1_8Y1VLK9F_.DBF deleted
    auxiliary instance file C:\PROD\DATAFILE\O1_MF_SYSTEM_8Y1VLK6X_.DBF deleted
    auxiliary instance file C:\PROD\CONTROLFILE\O1_MF_8Y1VL6PM_.CTL deleted
    auxiliary instance file prod1_objetos1_exp_dump.dat deleted
    Finished recover at 13/07/13


    Espero les sirva...

  • by Ligarius
    14.07.13. 21:29:26. 3161 words, 3223 views. Categories: Oracle 12c, RMAN (Recovery Manager) ,

    Oracle 12c: Nuevas características (New Features Oracle 12c)



    Pues bien , ya que salió la nueva versión de Oracle, era obvio que mencionáramos algunas nuevas características..

    Las más interesantes


    Nota : Impresionante Milla Jovovich

    Adaptive Query Optimization
    El optimizador puede llevar a cabo una modificación de sus planes de ejecución aunque estos ya se encuentren habilitados para la sentencia SQL, simplemente el CBO para los planes en ejecución y los reanaliza para encontrar el "nuevo" mejor, está característica es invisible al usuario y se hace de forma automática.
    Lo anterior no significa que una sentencia quede a medio camino de ejecución, no... simplemente se recalcula el mejor plan , para la siguiente ejecución.

    Ejecución de comandos a nivel de prompt de RMAN
    Oracle 12c nos permite ejecutar comandos a nivel del prompt de RMAN , esto sin la necesidad de colocar la claúsula sql , además podemos ejecutar cualquier sentencia SQL que querramos, no así pre-12c que estaban limitadas. La claúsula sql sigue estando vigente.
    Para más detalles ir a la nota


    Estadísticas dinámicas
    Durante la compilación de una sentencia SQL, el optimizador puede chequear todas las estadísticas sobre las tablas de la sentencia SQL y puede decidir si las ocupa o no , si no ocupa las estadística para una tabla en partícular o alguna de esta no posee estadísticas, Oracle generará estadísticas dinámicas con el método del Sampling, estás estadísticas permanecerán hasta las subsiguientes ejecuciones de la sentencia y el optimizador las puede utilizar cuando estime conveniente.


    Estadísticas ONLINE para cargas BULK
    Cuando se hace una carga de datos mediante un INSERT SELECT , CREATE TABLES AS , para versiones anteriores de Oracle , había que tomar estadísticas de forma manual a la nueva tabla , en cambio para nuestra nueva versión 12c, las estadísticas son tomadas de forma automática, tal cual se hace para cuando se generan los índices mediante el comando CREATE INDEX o REBUILD INDEX


    Estadísticas privadas para las tablas temporales
    Las estadísticas para las tablas temporales son únicas a pesar de que por cada sesión hubiese data distinta, esto era hasta la versión 11gr2 , para la versión 12c de Oracle, cada sesión tendrá sus propias estadísticas lo cual mejora ostensiblemente los tiempos de ejecución , pues se mejora la performance al tener mejores datos estadísticos.


    Integración con Grupos de procesadores a nivel de Sistema Operativo
    Esta característica permite especificar al DBA un parámetro llamado PROCESSOR_GROUP_NAME , con lo cual se une una instancia de base de datos a un conjunto de CPUs , esto mismo se puede hacer con el comando cgroups en Linux o con un pool de recursos en Solaris.

    ¿Para qué ocupar está característica? Pues para parcelar un poco el uso de CPUs por parte de una cantidad
    X de base de datos.


    Arquitectura Multitenant
    Las arquitecturas multitenant (multi-propietario) es unafilosofía de software cada vez más ocupada para aquellas empresas que dan servicios de SaaS (Software as a Service), el principio básico de esto es el siguiente , una instancia del Software es ejecutada en un servidor y desde aquí se da el servicio a múltiples clientes . Si lo pensamos del lado de Oracle significa que cada cliente comparte un motor de datos, pero los datos de cada cliente están totalmente separados uno de otros, o sea, colocamos muchas bases de datos en un mismo lugar, todas operadas por un mismo RDBMS.

    Toda esta arquitectura multitenant , hace que sea muy fácil para los clientes hacer una consolidación de sus bases de datos y trabajar muchas como una.

    Imaginemonos una consolidación de esquemas, para ahorrar motores, recursosy demáses, pero ahora para base de datos, cada base de datos se convierte en un Pluggable Database y estás PDBs pueden ser agrupadas en contenedores (Container), con esto se pueden compartir recursos de memoria , incluso se pueden compartir procesos backgrounds, una PDBs puede ser desconectada y conectada desde y hacía cualquier contenedor de base de datos. Incluso con esta característica , se puede parchar un contenedor y con ello se parchan de inmediato múltiples PDBs.


    Oracle Datapump soporta Database Consolidation
    Dentro del soporte que da Oracle Datapump para lo que es Database Consolidation, se nombra el FULL TRANSPORTABLE, que no es más que llevarse una base de datos desde y hacía los contenedores.

    Lo anterior implica que me puedo llevar una base no-CDB (Que no pertenezca a un Container Database) hacía otra base no-CDB, o una PDB a una no-CDB, o una base no-CDB a una PDB.


    Respaldo y recuperación PDBs
    RMAN puede trabajar sobre un CDB o sobre un PDB, como siempre se puede respaldar un datafile o un tablespace, para dar soporte a todas estas nuevas características se agregan las claúsulas PLUGGABLE DATABASE a los comandos RMAN.


    PDBs Point in Time Recovery
    Se pueden hacer recuperaciones de las PDBs en algún lugar del tiempo, lo que comunmente se llama point-in-time recovery


    Resource Plans para PDBs
    Oracle Resource Manager puede manejar los recursos a nivel de CDB y a nivel de PDB, con esto el manejo se vuelve más dinámico y se pueden asignar y reasignar recursos de forma más masiva


    Exportar una vista como tabla con Oracle Datapump
    Ahora se puede exportar una vista y Oracle deja la data de una vista en una tabla, antes al exportar una vista, sólo se exportaba la definición, pero no la data.
    Para más detalles ir a la nota

    Opción de NOLOGGING con Oracle Datapump Import
    Existe un parámetro para el import con el Datapump que deshabilita el logging para cuando se está cargando data en una tabla, es la opción TRANSFORM con el valor DISABLE_ARCHIVE_LOGGING, esto hace del proceso de import un proceso muchísimo más rápido pues no se genera redolog, lo que se debe tener en cuenta es sacar un respaldo después de finalizar el import.
    Para más detalles ir a la nota


    Oracle ASM Disk Scrubbing
    Está es una nueva caracteristica que chequea las corrupciones logicas de los discos de ASM y las repara de forma automática, esto sólo sucede cuando se crean grupos de fallas, o sea, existe redundancia normal o redundancia alta.


    Amplicación de los comandos ONLINE
    A partir de Oracle 12c, los comandos que se pueden utilizar en forma ONLINE se han ampliado, por ejemplo antes para borrar un índice se tenía que esperar a que este estuviese no siendo utilizado, pues si así fuese daba el siguiente error

    ORA-00054: resource busy and acquire with NOWAIT specified

    Los comandos que se pueden ejecutar ONLINE a partir de Oracle 12c :

    - DROP INDEX ONLINE
    - DROP CONSTRAINT ONLINE
    - SET UNUSED COLUMN ONLINE
    - ALTER INDEX UNUSABLE ONLINE
    - ALTER INDEX [VISIBLE | INVISIBLE]


    Columnas invisibles
    En Oracle 12c, podemos dejar una columna como invisible mediante el comando alter table -nombre tabla- modify (-columna- invisible) , pero nosotros mismos controlamos el cuando ver esa columna , por ejemplo
    Cuando hacemos un DESCRIBE de la tabla, está columna no aparece, cuando hacemos un SELECT * FROM de la tabla está columna tampoco aparece, incluso cuando hacemos un INSERT INTO nos podemos saltar esa columna, simplemente no incluyéndola en la lista de las columnas.
    A través de SQL*Plus podemos setear el hecho de que aparezca una columna invisible, para ello utilizamos
    el seteo

    SHOW COLINVISIBLE ON|OFF

    Para más detalles ir a la nota


    Movimiento ONLINE de los datafiles
    En release anteriores, para mover un datafile este se debia dejar OFFLINE , con todos los problemas de servicio que esto podía acarrear, pues a partir de Oracle 12c, el movimiento de los datafiles puede ser efectuado en forma ONLINE, sin pérdida de servicio
    Para más detalles ir a la nota


    Creación de varios índices en las mismas columnas de una tabla
    Múltiples índices pueden ser generados para un mismo set de columnas, con esto evitamos el hecho de tener que eliminar índices en caso de haber efectuado alguna migración , por ejemplo para los campos A,B,C de una tabla se pueden crear múltiples índices, los índices pueden ser generados de acuerdo a la siguiente premisa

    - B*Tree o Bitmap
    - Unique o NoUnique
    - De acuerdo al tipo de partición en que están involucrados los campos
    La única condición es que sólo uno de ellos tiene que estar visible.


    Dataguard Broker y las CDBs (Container Databases)
    El DataGuard Broker de Oracle soporta todo lo relacionado a MULTITENANT CONTAINER DATABASES (CDBs), sólo hay que tener en cuenta ciertas cosas :

    - Cuando la base de datos primaria es una CDB , todas las bases StandBy en la configuración del broker deben ser también CDBs
    - Cuando una configuración de Broker es hecha en base a CDBs , todas las acciones del Broker deben ser efectuadas a nivel de root , no a nivel de cada PDB (Pluggable Database)
    - Para administrar un ambiente MULTITENANT se debe tener el rol CDB_DBA


    Conexiones sysdg y sysdba al Dataguard Broker
    En versiones anteriores, la conexión al Dataguard debía ser hecha con el usuario SYS/Password y la claúsula SYSDBA, pues hoy sólo se necesita indicar el usuario y password de SYS, los usuarios que se conecten a la configuración del DataGuard Broker, deben tener los privilegios de SYSDG o SYSDBA, por defecto Oracle intentará conectar con SYSDBA


    VALIDATE DATABASE a nivel de Dataguard
    Si antes existía un comando BACKUP VALIDATE DATABASE a nivel de RMAN para chequear la validez de ciertos respaldos, hoy en día existe un comando llamado VALIDATE DATABASE [VERBOSE] para la configuración hecha a través de Dataguard Broker, con esto se hace una validación más exhaustiva de los componentes que forman parte de una configuración de Dataguard Broker


    Por defecto Real-Time Apply en DataGuard
    A partir de Oracle 12c, la configuración por defecto de Oracle Dataguard Broker viene con defecto con Real-Time Apply, esto significa que las transacciones son inmediatamente aplicadas a los archivos de Standby de Redo, más que la generación de un archive y que este sea aplicado en el ambiente de StandBy


    Retoma de las operaciones de Switchover
    Cuando en Oracle 11gr2 teníamos algún problema durante el proceso de Switchover , el proceso se tenía que hacer desde el principio, chequeando cada una de las partes de nuestras bases de datos, de hecho alguna de las bases podía quedar en estado MOUNT y no recuperando , a lo mejor la nueva primaria no podía quedar abierta, etc.
    Pero a partir de Oracle 12c, las operaciones de Switchover pueden ser retomadas si se caen en algún punto intermedio


    Modificaciones al DUPLICATE DATABASE
    En Oracle 11gr2 se puede usar la claúsula SECTION SIZE al momento de respaldar una base de datos, con esto cada proceso (Channel) puede tomar una porción del tamaño especificado para un datafile , con lo cual claramente se aceleran los procesos de respaldo de una base.
    Para el caso del DUPLICATE DATABASE en Oracle 12c, se puede también declarar la clausúla SECTION SIZE, con lo cual el proceso de copia de una base también se pueden ver acelerado
    Esta claúsula de SECTION SIZE , también puede ser aplicada a los backups como IMAGE COPY y a los backups incrementales.


    Mejoras al comando RESTORE
    A partir de Oracle 12c las operaciones de RESTORE se pueden hacer en modalidad NETWORK, tal cual lo puede hacer hoy en día el comando DUPLICATE, o como lo puede hacer un expdp


    Recuperación de tablas con RMAN
    Desde Oracle 12c en adelante ahora sí podemos hacer una recuperación de una tabla :) . Con el nuevo comando RECOVER TABLE podemos restaurar y recuperar una o más tablas desde respaldos RMAN ya sea que estén en Backups o en cintas.
    Para más detalles ir a la nota


    Límites de tamaño para la PGA
    Cuando se habla de bases de datos CDBs (Containers Database) , se habla de consolidación de bases sobre un hardware limitado, esta limitación de hardware hace que tengamos que utilizar los recursos de una manera más óptima.
    Por ende desde Oracle 12c aparece un nuevo parámetro llamado PGA_AGGREGATE_LIMIT el cual limita la cantidad de PGA que una instancia puede consumir.


    Oracle RAT para Containers Database (CDB)
    El RAT de Oracle también puede ser aplicado para las PDB que están en un CDB...o dicho de otra forma, todas las bases de datos que están en un CLOUD :)

    Una vez que se han tomado los datos estadísticos, se puede hacer un Database Replay sobre el CDB y así poder medir de forma significativa los cambios hacía una nueva estructura de base de datos


    Oracle RAT con ASH
    Desde Oracle 12c, los reportes que se saquen después del Database Replay contendrán información de ASH , lo cual claramente ayuda en el análisis del testing de la nueva infraestructura de base de datos.


    Inventario consultable
    Cada vez que queríamos saber los parches de nuestra base de datos, teníamos que irnos al sistema operativo y ejecutar un opath -lsinventory , desde Oracle 12c, se adjunta un nuevo package llamado DBMS_QOPATCH, con el cual se puede consultar a través de SQL, los distintos parches aplicados a nuestra plataforma RDBMS


    Oracle Flex ASM
    Con Oracle Flex ASM se puede separar la instancia ASM desde los servidores de base de datos, con ello se puede llegar a una estructura en donde un número X de servidores con instancias ASM , puede otorgar servicio a un número N de servidores de bases de datos.


    Oracle Flex Cluster
    Esta es una nueva arquitectura que permite un poco de fliexibilidad para lo que son los nodos de un cluster, desde Oracle 12c, nace un nuevo concepto llamado Flex Cluster, en esta nueva arquitectura nacen 2 conceptos los "Hub Nodes" y los "Leaf Nodes".
    Los "Hub Nodes" son los nodos normales de un cluster, imaginense una arquitectura de un RAC en 11gr2 , con 2 nodos y un Grid Infraestructure en ejecución, pues los "Hub Nodes" son aquellos nodos que conforman el RAC y que están conectados "entre sí" mediante el Interconnect.
    Pues bien, los "Leaf Nodes" son aquellos nodos que se unen a los "Hub nodes" y que no tienen que estar conectados a un Interconnect, sólo deben tener comunicación con un "Hub Node" .
    Los "Leaf Nodes" no requieren de acceso al Storage, esto se hace mediante un "Hub Node",está arquitectura presenta un sinnúmero de ventajas ,como por ejemplo poder colocar servicios en distintos nodos y de acuerdo a su carga de trabajo, quizás un servicio no sea tan demandante, pues este se puede colocar en un "Leaf Node" o al revés, sólo colocar en los "Hub Nodes" aquellos servicios que requieran un tiempo y acceso al disco más rápido..


    Respaldo en diskgroups del OCR
    Antes de Oracle 12c, los respaldos del OCR eran llevados a cabo en el nodo master en una ruta predefinida del S.O., desde Oracle 12c, estos respaldos pueden ser llevados a cabo en Diskgroups, lo cual simplifica el trabajo de recuperación de un OCR


    Soporte para IPv6
    Los nodos del cluster pueden ser configurados con IPv6, con esto el SCAN esta posibilitado de conectarse a las IPs VIP de la Grid Infraestructure.


    Advanced Network Compression
    La transferencia de datos a través de los servicios de Oracle Net ahora pueden ser comprimidos, lo cual genera una mejora de performance, está compresión puede ser definida en los siguientes niveles

    - Connection level (connect string, URL)
    - Service level (tnsnames.ora, ldap.ora)
    - Database level (sqlnet.ora)


    Restricciones para el privilegio SELECT ANY DICTIONARY
    El privilegio "SELECT ANY DICTIONARY" ya no podrá tener accesos directos a las vistas DEFAULT_PWD$, ENC$, LINK$, USER$, USER_HISTORY$ y XS$VERIFIERS, o sea, con este cambio ya no se tendrá tan fácil acceso a password de distintos usuarios :) o password de los dblinks, por ejemplo..


    Información del último LOGIN a través de SQL*Plus
    Cada vez que ingresemos a SQL*Plus nos mostrará cual fue nuestro último login a la instancia , esto es posible debido a la información que se almacena en la tabla USER$
    Para más detalles ir a la nota


    Modificación de role RESOURCE
    Se modifica el role RESOURCE para quitarle el privilegio UNLIMITED TABLESPACE, con esto se mejora la seguridad completa de la base de datos, pues con el rol UNLIMITED TABLESPACE se pueden ocupar recursos de una manera incontrolada.


    Privilegio SYSBACKUP
    A partir de Oracle12c nace un nuevo privilegio llamado SYSBACKUP, con el se pueden hacer actividades a través del comando RMAN , sin necesidad de tener habilitado el rol SYSDBA, con esto separamos los roles desde la persona que hace la administración de la base hasta la persona que lleva a cabo los respaldos.


    Oracle user en Windows
    Desde Oracle 12c, se da soporte a un usuario distinto de Administrador para poder instalar y manejar las instancias Oracle, ¿que lindo cierto?


    Columnas autonuméricas (IDENTITY)
    Está es una característica bien agradable, tener una columna que se vaya incrementando sola a medida que vamos insertando valores, pues está columna se conoce como IDENTITY, la gracia está es que por debajo manera una secuencia Oracle, el problema, pues es bien sabido los inconvenientes que poseen las secuencias en ambientes RAC cuando se les declara como NOCACHE
    Para más detalles ir a la nota


    Aumento de largo en columnas varchar2, nvarchar2 y RAW
    Antes de Oracle12c , las columnas varchar2, nvarchar2 y RAW sólo tenían un largo hasta 4000 bytes, si queríamos columnas de un largo mayor, teníamos que por obligación ocupar columnas de tipo CLOB o BLOB, pero en Oracle 12c nace un cambio , esto se aplica mediante el parámetro MAX_STRING_SIZE, este parámetro se cambia desde un valor STANDARD a EXTENDED y la base de datos puede soportar hasta 32767 bytes para sus columnas varchar2, nvachar2 y raw. Una vez realizado el cambio no se puede revertir.
    Para más detalles ir a la nota


    Nuevo utilitario de migración de set de carácteres DMU
    Hasta Oracle 11gr2 , la manera de llevar a cabo una migración de caracteres en una base de datos Oracle era mediante las herramientas CCSCAN y CSALTER, mientras la herramienta CSSCAN analiza toda la base de datos y se le indica desde que set de caracteres hacía que set de caracteres llevó mi data, con la herramienta CSALTER llevo a cabo los cambios.

    La documentación de CSSCAN y CSALTER
    10gr2 : http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch12scanner.htm#i1005939
    11gr2 : http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch11charsetmig.htm#NLSPG011

    En Oracle 12c el utilitario DMU reemplaza al CCSCAN y CSALTER y presenta una interfaz gráfica más amigable


    Espero NOS sirva a todos

    by Ligarius
    12.07.13. 07:57:10. 3236 words, 5574 views. Categories: Oracle 12c ,

    Instalación Oracle Database 12c Stand Alone (Installing Oracle Database 12c)



    Hola

    He acá una guía muy básica y sencilla (sólo para mostrar el nuevo logo 12c) de la instalación de un motor Oracle Database 12c y de la creación de la base de datos con el DBCA



    Instalación Oracle 12c


    by Ligarius
    11.07.13. 10:20:30. 46 words, 2469 views. Categories: Oracle 12c, Instalación ,

    Oracle Database 12c para Windows 64 bits



    Bueno, ha salido recién Oracle Database 12c para Windoor...no me emociona mucho , pero al fin y al cabo ya está disponible :-/

    Si lo deseas bajar, sólo debes ir a http://otn.oracle.com



    Espero les sirva ...

    by Ligarius
    10.07.13. 13:03:17. 40 words, 1994 views. Categories: Oracle 12c, Instalación ,

    Examen de Upgrade a Oracle Database 12c disponible , bueno ... no tanto



    Como acaba de salir Oracle Database 12c , la idea es certificarse con los examenes Beta...

    Ingrese a www.pearsonvue.com y el examen se encuentra disponible :)

    1z1-060 : Upgrade to Oracle Database 12c

    Una vez que ubicamos la sede donde dar el exámen, aparece el mensaje de que aún no está disponible :(



    Incluso también está presentado en la página de Oracle donde aparecen los exámenes disponibles



    Pues bueno, tendremos que esperar su liberación :yes:


    by Ligarius
    26.06.13. 11:29:43. 80 words, 5898 views. Categories: Certificaciones, Oracle 12c ,

    << 1 ... 5 6 7 8 9 10 11 12 13 14 15 ... 44 >>