Esta es la ultima entrada que hago en blogspot, mas no significa que es la ultima entrada en mi blog , solamente me estoy mudando a rene-ace.com , en donde encontraras no solo entradas en español tambien en ingles y otras cosas a las que me dedico .
Te espero por alla :)
viernes, 21 de abril de 2017
lunes, 17 de abril de 2017
Error ORA-01033 después de realizar un switchover en un ambiente 12.1 RAC
Principalmente escribo este post para no olvidarme de este error, así que será un pequeño post. El otro día hice una switchover en un ambiente de RAC, que fue bastante fácil, pero después de hacer el switchover, en la Base de datos primaria continua recibiendo el siguiente error:
Así que fui y verifique la base de datos standby, y vi que estaba en modo de recuperación y esperando el redo log
Así que lo primero que pensé fue que el archivo de contraseña estaba incorrecto, así que los recreé y los copié desde el nodo primario a los nodos en de la base de datos en standby, pero seguí recibiendo el mismo error. Revisé el entorno con los scripts en el DOC ID 1581388.1 de MOS y todo parecía estar bien.
Me molestó que los registros no se estaban aplicando a pesar de que los registros estaban siendo enviados a la base de datos standby, por lo que tenía que ver con el archivo de contraseña, pero lo que realmente me molestó, fue que acababa de recrear el archivo de contraseña en $ORACLE_HOME/dbs y todavía seguía recibiendo el mismo error.
Así que después de un tiempo de estar buscando la solución al problema, encontré que en la nueva base de datos primaria, el archivo de contraseña residía en un ASM Diskgroup, y que eso era la principal causa de este error , así que lo que tenía que hacer era copiar el archivo de contraseña del grupo de discos ASM en el ambiente primario al ambiente standby.
Base de datos Primaria
Base de datos Standby
Una vez que lo hice, la base de datos standby comenzó a aplicar los redologs, y después de que se cerrara la brecha, el estado de switchover de la base de datos Principal era "TO STANDBY"
Base de Datos Primaria
Base de Datos Standby
Conclusión
En 12.1 se recomienda en el DOC ID 1984091.1 de MOS, tener el archivo de contraseña en los diskgroups de ASM. Así que una vez que hice esto, fui capaz de soluciónar el error ORA-01033 y poder dormir bien :).
select dest_name,status,error from gv$archive_dest_status where dest_id=2; DEST_NAME -------------------------------------------------------------------------------- STATUS ERROR --------- ----------------------------------------------------------------- LOG_ARCHIVE_DEST_2 ERROR ORA-01033: ORACLE initialization or shutdown in progress LOG_ARCHIVE_DEST_2 ERROR ORA-01033: ORACLE initialization or shutdown in progress
Así que fui y verifique la base de datos standby, y vi que estaba en modo de recuperación y esperando el redo log
PROCESS STATUS CLIENT_P CLIENT_PID THREAD# SEQUENCE# BLOCK# ACTIVE_AGENTS KNOWN_AGENTS ------- ------------ -------- ---------- ---------------- ---------------- ---------------- ---------------- ---------------- ARCH CONNECTED ARCH 44474 0 0 0 0 0 RFS IDLE ARCH 133318 0 0 0 0 0 RFS IDLE ARCH 50602 0 0 0 0 0 ARCH CLOSING ARCH 44470 1 21623 14336 0 0 ARCH CLOSING ARCH 44476 1 21624 1 0 0 ARCH CLOSING ARCH 44472 2 19221 96256 0 0 RFS IDLE LGWR 133322 1 21625 17157 0 0 RFS IDLE LGWR 50620 2 19222 36611 0 0 MRP0 WAIT_FOR_LOG N/A N/A 2 19222 36617 0 0
Así que lo primero que pensé fue que el archivo de contraseña estaba incorrecto, así que los recreé y los copié desde el nodo primario a los nodos en de la base de datos en standby, pero seguí recibiendo el mismo error. Revisé el entorno con los scripts en el DOC ID 1581388.1 de MOS y todo parecía estar bien.
Me molestó que los registros no se estaban aplicando a pesar de que los registros estaban siendo enviados a la base de datos standby, por lo que tenía que ver con el archivo de contraseña, pero lo que realmente me molestó, fue que acababa de recrear el archivo de contraseña en $ORACLE_HOME/dbs y todavía seguía recibiendo el mismo error.
Así que después de un tiempo de estar buscando la solución al problema, encontré que en la nueva base de datos primaria, el archivo de contraseña residía en un ASM Diskgroup, y que eso era la principal causa de este error , así que lo que tenía que hacer era copiar el archivo de contraseña del grupo de discos ASM en el ambiente primario al ambiente standby.
Base de datos Primaria
[oracle@localhost trace]$ srvctl config database -d renedb Database unique name: renedb Database name: Oracle home: /u01/app/oracle/product/12.1.0.2/db_1 Oracle user: oracle Spfile: +DATA1/renedb/spfilerenedb.ora Password file: +DATA1/renedb/PASSWORD/pwrenedb Domain: Start options: open Stop options: immediate Database role: PHYSICAL_STANDBY Management policy: AUTOMATIC Server pools: Disk Groups: ARCH1,DATA1,REDO Mount point paths: Services: Type: RAC Start concurrency: Stop concurrency: OSDBA group: dba OSOPER group: oper Database instances: renedb1,renedb2 Configured nodes: localhost,localhost Database is administrator managed [oracle@localhost trace]$ exit -bash-4.1$ sudo su - grid [sudo] password for pythian: [grid@localhost ~]$ . oraenv ORACLE_SID = [+ASM1] ? The Oracle base remains unchanged with value /u01/app/grid [grid@localhost ~]$ asmcmd ASMCMD> pwcopy +DATA1/renedb/PASSWORD/pwrenedb /tmp/pwrenedb copying +DATA1/renedb/PASSWORD/pwrenedb > /tmp/pwrenedb ASMCMD> exit
Base de datos Standby
[oracle@localhost dbs]$ scp 10.10.0.1:/tmp/pwrenedb /tmp/pwrenedb_stby pwrenedb_stby_phdb 100% 7680 7.5KB/s 00:00 [oracle@localhost dbs]$ exit logout [pythian@localhost ~]$ sudo su - grid [sudo] password for pythian: Last login: Fri Mar 31 21:55:53 MST 2017 [grid@localhost ~]$ . oraenv ORACLE_SID = [grid] ? +ASM1 The Oracle base has been set to /u01/app/grid [grid@localhost ~]$ asmcmd ASMCMD> mkdir DATA/RENEDB/PASSWORD ASMCMD> pwcopy /tmp/pwrenedb_stby_phdb +DATA/RENEDB/PASSWORD/pwrenedb_stby copying /tmp/pwrenedb_stby_phdb -> +DATA/RENEDB/PASSWORD/pwrenedb_stby ASMCMD> exit [grid@localhost ~]$ exit logout [pythian@localhost ~]$ sudo su - oracle Last login: Sat Apr 1 01:35:46 MST 2017 on pts/4 The Oracle base has been set to /u01/app/oracle [oracle@localhost dbs]$ srvctl modify database -d renedb_stby -pwfile +DATA/RENEDB/PASSWORD/pwrenedb_stby [oracle@localhost dbs]$ srvctl config database -d renedb_stby Database unique name: renedb_stby Database name: Oracle home: /u01/app/oracle/product/12.1.0/dbhome_1 Oracle user: oracle Spfile: /u01/app/oracle/product/12.1.0/dbhome_1/dbs/spfilerenedb_stby.ora Password file: +DATA/RENEDB/PASSWORD/pwrenedb_stby Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: Disk Groups: ARCH,DATA,REDO Mount point paths: Services: Type: RAC Start concurrency: Stop concurrency: OSDBA group: dba OSOPER group: oper Database instances: renedb_stby1,renedb_stby2 Configured nodes: *******,*********** Database is administrator managed
Una vez que lo hice, la base de datos standby comenzó a aplicar los redologs, y después de que se cerrara la brecha, el estado de switchover de la base de datos Principal era "TO STANDBY"
Base de Datos Primaria
Primary Site last generated SCN ******************************* DB_UNIQUE_NAME SWITCHOVER_STATUS CURRENT_SCN --------------- -------------------- ---------------- renedb TO STANDBY 134480468945
Base de Datos Standby
Data Guard Apply Lag ******************** NAME LAG_TIME DATUM_TIME TIME_COMPUTED ------------ -------------------- -------------------- -------------------- apply lag +00 00:00:00 04/01/2017 04:05:51 04/01/2017 04:05:52 1 row selected. Data Guard Gap Problems *********************** no rows selected PROCESS STATUS CLIENT_P CLIENT_PID THREAD# SEQUENCE# BLOCK# ACTIVE_AGENTS KNOWN_AGENTS ------- ------------ -------- ---------- ---------------- ---------------- ---------------- ---------------- ---------------- ARCH CONNECTED ARCH 44474 0 0 0 0 0 RFS IDLE ARCH 133318 0 0 0 0 0 RFS IDLE ARCH 50602 0 0 0 0 0 ARCH CLOSING ARCH 44470 1 21623 14336 0 0 ARCH CLOSING ARCH 44476 1 21624 1 0 0 ARCH CLOSING ARCH 44472 2 19221 96256 0 0 RFS IDLE LGWR 133322 1 21625 17157 0 0 RFS IDLE LGWR 50620 2 19222 36611 0 0 MRP0 APPLYING_LOG N/A N/A 2 19222 36617 33 33 9 rows selected.
Conclusión
En 12.1 se recomienda en el DOC ID 1984091.1 de MOS, tener el archivo de contraseña en los diskgroups de ASM. Así que una vez que hice esto, fui capaz de soluciónar el error ORA-01033 y poder dormir bien :).
viernes, 5 de junio de 2015
RMAN 12cR1 : Dile adios a tu respaldo cuando haces un DROP de tu PDB - Parte II
RMAN 12cR1 : Dile adios a tu respaldo cuando haces un DROP de tu PDB - Parte II
En mi última entrada en mi blog de Pythian (aquí en español) antes de unirme a Oracle, hable de lo que ocurre si intentas recuperar una BASE DE DATOS “PLUGGABLE” si haces un DROP PLUGGABLE DATABASE en 12cR1, para no hacer la historia larga , no vas a ser capaz de restaurar / recuperar tu base de datos. Ahora voy a profundizar un poco más en qué en lo que sucede en el archivo de control (controlfile), y por qué es necesario restaurar el archivo de control para que puedas recuperar tu base de datos “PLUGGABLE”.
Primero creo una base de datos llamada TESTDB
SQL> CREATE PLUGGABLE DATABASE testdb ADMIN USER testadm IDENTIFIED BY oracle ROLES=(DBA);
Pluggable database created.
Si hago un volcado del archivo de control tipo 4 , que incluye, la cabecera del archivo (datafile), la información de registro de base de datos y registros de progresos de checkpoint, los registros más antiguos y más recientes para los registros circulares reutilizables y los 4 registros más recientes de registros circulares reutilizables .
Puedo ver en el volcado del archivo de control que la base de datos “pluggable” tiene un “id” de 4 y un “Record id” de 4, que no son lo mismo, una es el PDB_ID y el otro es el registro de identificación del archivo de control , como se puede ver a continuación:
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump controlf 4;
Statement processed.
...
***************************************************************************
PLUGGABLE DATABASE RECORDS
***************************************************************************
(size = 684, compat size = 684, section max = 10, section in-use = 4,
last-recid= 13, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 540, numrecs = 10)
Pluggable DataBase record=1
id=1
dbid=2835408111
name=CDB$ROOT
first datafile link=1
pdbinc=0, pdbrdi=0, status=0x00000000, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.00000000, crescn scn: 0x0000.00000000
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=2
id=2
dbid=4092965150
name=PDB$SEED
first datafile link=7
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001dd3e3, crescn scn: 0x0000.001a4224
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=3
id=3
dbid=1554252633
name=PDBEM
first datafile link=10
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001e0a9c, crescn scn: 0x0000.001dd76b
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=4
id=4
dbid=2633748847
name=TESTDB
first datafile link=12
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000001
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001e066d, crescn scn: 0x0000.001e061c
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Ahora bien, si vemos un poco más abajo en el archivo, que voy a recortar para este ejercicio sólo mostrar el datafile 12, se puede observar que existe una relación entre este identificador, y los archivos de datos de esta base de datos “pluggable”.
...***************************************************************************
DATA FILE RECORDS
***************************************************************************
...
DATA FILE #12:
name #17: /u01/app/oracle/oradata/cdborcl/pdbs/sysaux01.dbf
creation size=87040 block size=8192 status=0x80 flg=0x5 head=17 tail=17 dup=1
pdb_id 4, tablespace 1, index=14 krfil=4 prev_file_in_ts=0 prev_file_in_pdb=11
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2 scn: 0x0000.001e066d 06/16/2014 16:09:37
Stop scn: 0x0000.001e066d 06/16/2014 16:09:37
Creation Checkpointed at scn: 0x0000.001e0620 06/16/2014 16:09:13
thread:1 rba:(0xf.54b4.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
Lo que procedo a hacer ahora, es borrar la base de datos “pluggable”
SQL> DROP PLUGGABLE DATABASE TESTDB INCLUDING DATAFILES;
Pluggable database dropped.
Y ahora hago otra volcado de mi archivo de control, puedo ver que el ID del volcado del controlfile es 0 y el “Record ID” sigue siendo 4, y ahora la relación entre los archivos de datos, que no se pierde, sigue siendo el número 4, que significa que no está relacionado con el “id” número 0, así que básicamente no hay archivos de datos relacionados con estaPDB, que mi lógica me dice que es lo que quiero, ya que acabo de borrar mi PDB.
…
***************************************************************************
PLUGGABLE DATABASE RECORDS
***************************************************************************
(size = 684, compat size = 684, section max = 10, section in-use = 4,
last-recid= 14, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 540, numrecs = 10)
Pluggable DataBase record=1
id=1
dbid=2835408111
name=CDB$ROOT
first datafile link=1
pdbinc=0, pdbrdi=0, status=0x00000000, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.00000000, crescn scn: 0x0000.00000000
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=2
id=2
dbid=4092965150
name=PDB$SEED
first datafile link=7
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001dd3e3, crescn scn: 0x0000.001a4224
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=3
id=3
dbid=1554252633
name=PDBEM
first datafile link=10
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001e0a9c, crescn scn: 0x0000.001dd76b
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=4
id=0
dbid=2633748847
name=TESTDB
first datafile link=0
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000001
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001e066d, crescn scn: 0x0000.001e061c
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
...
***************************************************************************
DATA FILE RECORDS
***************************************************************************
...
DATA FILE #12:
creation size=87040 block size=8192 status=0x88c flg=0x1 head=0 tail=0 dup=0
pdb_id 4, tablespace 1, index=14 krfil=4 prev_file_in_ts=0 prev_file_in_pdb=11
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2 scn: 0x0000.001e066d 06/16/2014 16:09:37
Stop scn: 0x0000.001e066d 06/16/2014 16:09:37
Creation Checkpointed at scn: 0x0000.001e0620 06/16/2014 16:09:13
thread:1 rba:(0xf.54b4.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
Ahora, yo no sé lo que se necesita para que el PDB_ID = 0 se retire del controlfile, pero si sigo y creo otra base de datos “pluggable”, puedo ver en el volcado del controlfile que el registro para la BD (TESTDB) se ha borrado, la nueva BD agarra el “PDB record ID” de 4 y el registro de controlfile 4, y ahora en realidad no hay registro de que alguna vez existio, haciendo imposible que RMAN pueda recuperar / restaurar su base de datos con el registro siendo 0 o si la base de datos “pluggable” no existe en la sección de “PLUGGABLE DATABASE RECORDS “.
SQL> CREATE PLUGGABLE DATABASE testdb1 ADMIN USER testadm IDENTIFIED BY oracle ROLES=(DBA);
Pluggable database created.
...
***************************************************************************
PLUGGABLE DATABASE RECORDS
***************************************************************************
(size = 684, compat size = 684, section max = 10, section in-use = 4,
last-recid= 18, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 540, numrecs = 10)
Pluggable DataBase record=1
id=1
dbid=2835408111
name=CDB$ROOT
first datafile link=1
pdbinc=0, pdbrdi=0, status=0x00000000, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.00000000, crescn scn: 0x0000.00000000
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=2
id=2
dbid=4092965150
name=PDB$SEED
first datafile link=7
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001dd3e3, crescn scn: 0x0000.001a4224
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=3
id=3
dbid=1554252633
name=PDBEM
first datafile link=10
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000000
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001e0a9c, crescn scn: 0x0000.001dd76b
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Pluggable DataBase record=4
id=4
dbid=602641775
name=TESTDB1
first datafile link=14
pdbinc=0, pdbrdi=0, status=0x00000001, flags=0x00000001
incrcv scn scn: 0x0000.00000000, clnscn scn: 0x0000.001e7a44, crescn scn: 0x0000.001e79d6
dbrls scn: 0x0000.00000000, dbrlc=0
iscn scn: 0x0000.00000000, itime=0
bscn scn: 0x0000.00000000, btime=0
escn scn: 0x0000.00000000, etime=0
Conclusión
Esto es sólo para ti y que te des una idea de lo que sucede en el archivo de control cuando se emiteDROP PLUGGABLE DATABASE, que es donde se guardan el registro de sus PDBs / Datafiles y respaldos, que es por qué al emitir ese comando, la única manera de restaurar / recuperar tu PDB es restaurar el archivo de control, la base de datos root y la PDB, esto se puede hacer en una base de datos auxiliar, si necesitas hacerlo.
Suscribirse a:
Entradas (Atom)