“Implementación de Physical Standby con Oracle Dataguard 12cR2"
Enviado por mpalacios_pe • 8 de Abril de 2019 • Tutoriales • 2.891 Palabras (12 Páginas) • 125 Visitas
MANUAL DE PROCEDIMIENTO
“Implementación de Physical Standby con Oracle Dataguard 12cR2"
Lima, 3 de marzo del 2019
Tabla de Contenido
Contenido
1. Introducción 3
1.1. Propósito 3
1.2. Alcance 3
2. Datos Generales de Implementación 4
2.1. Configuración Dataguard 5
a. Preparación de la base de datos producción para ser PRIMARY. 5
b. Configuración de la conectividad SQL*NET. 8
c. Creación de la base de datos standby. 11
d. Validaciones Post creación STANDBY 15
Introducción
Este documento constituye un manual de referencia de implementación de Physical Standby con Oracle Dataguard 12cR2 sobre plataforma AIX
Propósito
Brindar un procedimiento referencial de implementación de Physical Standby con Oracle Dataguard 12cR2 sobre plataforma AIX
Alcance
Elaborar procedimiento referencial de implementación de Physical Standby con Oracle Dataguard 12cR2 sobre plataforma AIX.
Datos Generales de Implementación
Produccion (primary-origen) | Contingencia (standby-destino) | |||||
Hostname | DB UNQ Name | Server IP | Hostname | DB UNQ Name | Server IP | |
pivotsi01.oracle.com | orcl: orcl1 | 10.2.80.102 | pivotlm01.oracle.com bmesrvc616.oracle.com | orcl_ctg | 10.100.0.77 10.2.80.50 | |
pivotsi02.oracle.com | orcl: orcl2 | 10.2.80.103 | orcl_local |
El software es Oracle Database Enterprise Edition 12.2.0.1 tanto para primary como los standby con los PSU a abril 2018.
La arquitectura de cada solución implementación se muestra en la gráfica siguiente:
[pic 1]
Configuración Dataguard
La estrategia utilizada fue la de clonación rápida, para lo cual se utilizó ACTIVE DATABASE DUPLICATION la cual no necesita de un backup físico. El detalle en las siguientes etapas:
Preparación de la base de datos producción para ser PRIMARY.
- Configurar la base de datos en modo ARCHIVELOG
- En caso el origen Primary sea un Oracle RAC, el SHUTDOWN deberá ser realizado en todas sus instancias y cambio a modo ARCHIVELOG deberá ser realizado solo de una instancia.
En PRIMARY (10.2.80.102 y 10.2.80.103)
### Detener totalmente la base de datos (en caso sea RAC repetirlo en los demás nodos)- Al ser un entorno productivo se debe solicitar ventana de detenimiento al cliente.
su - oracle
. /home/oracle/rdbms.env
env | grep ORA
sqlplus / as sysdba
SHUTDOWN IMMEDIATE; (En caso sea RAC repetir en otros nodos)
En PRIMARY (10.2.80.102)
### Sólo realizar en una instancia de Base de datos (Nodo 1)
su – oracle
. /home/oracle/rdbms.env
env | grep ORA
sqlplus / as sysdba
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
SQL> ARCHIVE LOG LIST;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
En PRIMARY (10.2.80.102 y 10.2.80.103)
### Detener totalmente la base de datos (en caso sea RAC repetirlo en los demás nodos)
su - oracle
. /home/oracle/rdbms.env
env | grep ORA
sqlplus / as sysdba
SHUTDOWN IMMEDIATE; (En caso sea RAC repetir en otros nodos)
En PRIMARY (10.2.80.102 y 10.2.80.103)
### Iniciar totalmente la base de datos (en caso sea RAC repetirlo en los demás nodos)
su – oracle
. /home/oracle/rdbms.env
env | grep ORA
sqlplus / as sysdba
STARTUP;
SQL> ARCHIVE LOG LIST;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
- Habilitar FORCE LOGGING
En PRIMARY (10.2.80.102)
su - oracle
. /home/oracle/rdbms.env
env | grep ORA
sqlplus / as sysdba
SQL> alter database force logging;
Database altered.
SQL> select force_logging from v$database;
FORCE_LOGGING
---------------------------------------
YES
- Crear los STANDBY redo logs
Se debe crear STANDBY redo logs en PRIMARY. Se recomienda crear el mismo número de redo logs por thread más 1 y deben ser del mismo tamaño. Para este caso se agregarán 6 standby redologs, 3 por cada thread:
...