Oracle En Español: abril 2017

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&gt; 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&gt; mkdir DATA/RENEDB/PASSWORD
ASMCMD&gt; pwcopy /tmp/pwrenedb_stby_phdb +DATA/RENEDB/PASSWORD/pwrenedb_stby
copying /tmp/pwrenedb_stby_phdb -&gt; +DATA/RENEDB/PASSWORD/pwrenedb_stby
ASMCMD&gt; 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 :).

Oracle En Español

viernes, 21 de abril de 2017

Me cambie a rene-ace.com

lunes, 17 de abril de 2017

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

Buscar en este blog