Una Base de Datos Standby asegura alta disponibilidad,
protección de datos y recuperación de desastres para datos empresariales.
Oracle Data Guard provee un conjunto
de servicios que crean, mantienen, manejan y monitorean una o más bases de
datos standby. Data Guard mantiene esas bases de datos standby como copias
transaccionalmente consistentes de la base de datos de producción, por
lo tanto si la base de datos de producción no está disponible ya sea por un
corte planeado o no planeado, Data Guard
puede realizar un cambio entre el rol primario y el rol standby, minimizando así el
tiempo de inactividad que implica el corte. Una configuración de Data Guard está formada por lo
siguiente:
- Una base de datos de producción
- Desde una hasta nueve bases de datos Standby
La base de datos de producción puede ser sencilla o RAC.
Una base de datos Standby puede ser de dos tipos:
Physical Standby: Es una copia bloque a bloque idéntica de la base de datos primaria. Es sincronizada por medio de Redo Apply.
Logical Standby: Contiene la misma información lógica de la base de datos primaria, aunque la organización y las estructuras de los datos pueden ser diferentes. Es sincronizada por SQL Apply.
Cascaded Standby Databases: Para reducir la carga en su sistema primario, puede implementar destinos en cascada, es decir, una base de datos standby recibe datos redo desde otra base de datos standby en lugar de recibirlos directamente de la base de datos primaria.
Las configuraciones
en cascada soportadas son:
- PD-> PS-> PS
- PD-> PS-> LS
- PD ->LS ->PS
Donde: PD=Base de Datos Primaria
PS=Physical
Standby
LS=Logical
Standby
Nota: Una
base de datos Standby no puede
colocarse en cascada si su base de datos primaria es RAC. Es posible crear una base de Physical Standby a partir de una Logical Standby de una base de datos
primaria RAC,
Las configuraciones no soportadas son:
- PD ->LS ->LS
- RAC ->PS ->PS
- RAC ->PS LS
- RAC ->LS ->PS
- RAC ->LS ->LS
Una physical standby puede soportar un
máximo de nueve destinos remotos. Oracle recomienda que destinos en cascada
únicamente sean usados para reportería o para aplicaciones que no requieran
acceso a datos que estén completamente a
la fecha con el sitio primario.
Bases de datos Standby
recibiendo datos redo desde una physical standby: El
proceso para realizar un switchover o
failover es exactamente el mismo en
una configuración en cascada, porque todas las bases de datos physical standby retransmiten idénticos
datos redo de la base de datos
primaria. La única diferencia es el tiempo adicional que puede requerir la
restauración de los datos redo.
Bases de datos Standby
recibiendo datos redo desde una Logical Standby: Cualquier
base de datos que recibe datos redo en cascada desde una Logical Standby no puede participar en un en un switchover con la base de datos
primaria, únicamente bases de datos Logical
Standby que reciben
indirectamente
datos redo de la base de datos primaria.
Creación de una base de datos en cascada: Una
base de datos standby en
cascada se crea
siguiendo el proceso normal de creación de una base de datos standby ya sea logical o physical, según
sea el caso, pero la diferencia es que están entrelazadas. El siguiente ejemplo
asume que el sitio
primario tiene por
nombre “boston”, el sitio Physical
Standby (Layer 1) tiene por nombre “chicago” y el sitio Physical Standby (Layer 2) tiene por
nombre “denver”. Se requiere crear un ambiente como el siguiente:
Primero se deberá
crear una configuración Physical Standby
con el proceso normal, luego se crea otra configuración Physical Standby pero tomando como base de datos primaria la primer
Physical Standby.
A continuación los
pasos resumidos:
Creación de la primer Physical
Standby (Layer 1):
- Backup de la base de datos primaria
- Transmitir el backup al sitio standby (Layer 1)
- Configurar Oracle Net (tnsnames, listener, etc)
- Realizar Duplicate en el sitio standby (Layer 1)
Las siguientes
operaciones son sobre el sitio primario:
- Habilitar FORCE LOGGING
- Crear Password File
- Configurar un Standby redo log.
- Configurar parámetros de inicialización. Estos parámetros deben estar similar a los siguientes datos:
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3='SERVICE=chicago VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
STANDBY_ARCHIVE_DEST=/arch1/boston/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
- Habilitar Archive mode
En el sitio standby (Layer 1):
- Copiar el archivo de parámetros del sitio primario al sitio standby
- Establecer parámetros de iniciación. Los parámetros deben ser similares a los siguientes:
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2='SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3='SERVICE=boston VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
STANDBY_ARCHIVE_DEST=/arch1/chicago
- Backup de la base de datos Layer 1
- Transmitir el backup al sitio standby (Layer 2)
- Configurar Oracle Net (tnsnames, listener, etc)
- Realizar Duplicate en el sitio standby (Layer 2)
- Copiar el archivo de parámetros del sitio primario al sitio standby
- Establecer parámetros de iniciación. Los parámetros deben ser similares a los siguientes:
DB_UNIQUE_NAME=denver
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/denver/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_2='LOCATION=/arch2/denver/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
STANDBY_ARCHIVE_DEST=/arch2/denver/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
- Crear Password File.
- Iniciar la Physical Standby.
- Verificar que estén sincronizadas las bases de datos.
No hay comentarios:
Publicar un comentario