Error ORA-01033 después de realizar un switchover en un ambiente 12.1 RAC

17 Apr 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:

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 :).