Data Guard es la verdadera tecnología de protección contra desastres de Oracle 12c. En él, tiene un mínimo de dos bases de datos, principal y en espera. Data Guard tiene opciones para múltiples sitios en espera, así como una configuración activo-activo.
Por activo-activo, significa que
ambos / todos los sitios están en funcionamiento, en funcionamiento y
accesibles. Esto se opone a los sitios que tienen una ubicación activa y las
otras deben iniciarse cuando se necesitan. Este es un ejemplo del diseño arquitectónico
general.
Arquitectura de Data Guard y Oracle 12c
Comenzar una descripción con la base de datos primaria es
fácil porque se diferencia muy poco de cualquier otra base de datos que pueda
tener. La única diferencia es lo que hace con sus registros de rehacer
archivados.
La base de datos principal escribe un conjunto de registros
de rehacer archivos en un área de recuperación de Flash o en un disco local.
Sin embargo, puede configurar uno o más destinos en un entorno de Data Guard.
El parámetro LOG_ARCHIVE_DEST_n puede tener este aspecto
para la configuración anterior:
|
LOG_ARCHIVE_DEST_10
= 'UBICACIÓN = USE_DB_RECOVERY_FILE_DEST' LOG_ARCHIVE_DEST_1 =
'SERVICIO = PHYSDBY1 ARCH' LOG_ARCHIVE_DEST_2 = 'SERVICIO = LOGSDBY1 LGWR' |
·
LOG_ARCHIVE_DEST_10
está configurado para enviar registros de rehacer archivos al Área de recuperación
de Flash local. Se requiere un destino local para todas las bases de datos en
modo de registro de archivo.
·
LOG_ARCHIVE_DEST_1
está configurado para enviar los registros de archivo a través del proceso de
archivado a un sitio remoto PHYSDBY1. El nombre del servicio para este sitio
remoto tiene una entrada en el archivo tnsnames.ora en el servidor primario.
·
LOG_ARCHIVE_DEST_2
está configurado para enviar los registros de archivo a través del proceso LGWR
a un sitio remoto llamado LOGSDBY1. El nombre del servicio para este sitio
remoto también tiene una entrada en el archivo tnsnames.ora en el servidor
primario.
¿Por qué la diferencia entre los métodos de envío ARCn y
LGWR? Eso tiene algo que ver con los modos de protección. Un entorno de Data
Guard tiene tres modos de protección.
Disponibilidad máxima
El modo de protección de máxima
disponibilidad se compromete entre el rendimiento y la disponibilidad de datos.
Funciona mediante el uso de LGWR para escribir simultáneamente para rehacer
registros en los sitios principal y en espera. La degradación del rendimiento
viene en forma de procesos que tienen que esperar a que las entradas del
registro de rehacer se escriban en varias ubicaciones.
Las sesiones que emiten
confirmaciones deben esperar hasta que se haya registrado toda la información
necesaria en al menos un registro de rehacer de la base de datos en espera. Si
una sesión se bloquea debido a su incapacidad para escribir información de
rehacer, el resto de la base de datos sigue avanzando.
Protección máxima
El modo de protección máxima es
similar a la disponibilidad máxima, excepto que si una sesión no puede
verificar que rehacer está escrito en el sitio remoto, la base de datos
principal se apaga.
|
Consejo: Configure al menos dos
sitios en espera para el modo de máxima protección. De esa manera, un sitio
en espera que deje de estar disponible no interrumpirá el servicio para toda
la aplicación. |
Este modo verifica que no se
producirá ninguna pérdida de datos en caso de desastre a costa del rendimiento.
Rendimiento máximo
El modo de protección de máximo
rendimiento separa el proceso de trasvase de registros de la base de datos
principal pasándolo al proceso de registro de archivo (ARCn). Al hacer esto,
todas las operaciones en el sitio principal pueden continuar sin esperar a que
se escriban las entradas de rehacer para rehacer los registros o rehacer el
envío.
Esto se opone a los modos de
trasvase de registros que utilizan el escritor de registros para transferir
transacciones. El uso del escritor de registros puede ralentizar el
procesamiento de la transacción porque puede verse afectado por la
disponibilidad o el rendimiento de la red.
|
El rendimiento máximo proporciona el nivel más
alto de rendimiento en el sitio principal a expensas de la divergencia de
datos. La divergencia de datos se produce cuando los datos de los dos sitios
comienzan a de sincronizarse. Los datos de rehacer del archivo no se envían
hasta que se llena todo el registro de rehacer del archivo. En el peor de los
casos, la pérdida de un sitio completo podría resultar en la pérdida de todos
los datos de un registro de rehacer de archivo (archive redo log). |
Realización de operaciones de conmutación y conmutación por error
Puede cambiar el procesamiento a
su sitio en espera de dos maneras:
·
La conmutación
(switchover) es un cambio planificado que puede ocurrir si desea realizar
mantenimiento en el sitio principal que requiere que no esté disponible. Esta
operación puede requerir unos minutos de inactividad en la aplicación, pero si
tiene que realizar un mantenimiento que dure una hora o más, el tiempo de
inactividad podría valer la pena. Esta operación se denomina cambio elegante
porque convierte el sitio principal en su sitio en espera y su sitio en espera
en el principal. Además, puede volver fácilmente al sitio principal original
sin tener que volver a crearlo desde cero.
·
La conmutación
por error (failover) ocurre cuando el sitio principal se ha visto
comprometido de alguna manera. Quizás fue una pérdida total del sitio, o quizás
descubrió daños físicos en un archivo de datos. No siempre, pero por lo general
después de una conmutación por error, debe volver a crear completamente el
sitio principal o recuperarlo de una copia de seguridad y reinstalarlo. Por lo
general, realiza una conmutación por error solo cuando ha determinado que
reparar el sitio principal llevará el tiempo suficiente para que prefiera no
tener una interrupción de la aplicación durante todo el tiempo.
Para realizar un cambio, siga
estos pasos:
1. En el primario actual, inicie sesión en SQL * Plus y escriba lo siguiente:
<alter
database commit to switchover to physical standby;>
Deberías ver esto:
< Base de datos alterada >
.
2. Apague la base de datos primaria:
Deberías ver esto::
Database closed.Database dismounted.ORACLE instance shut down.3. Inicie la base de datos primaria en modo nomount:
<startup nomount>
Debería ver algo como esto:
ORACLE instance started.
Total System Global Area 789172224 bytes
Fixed Size
2148552 bytes
Variable Size
578815800 bytes
Database Buffers
201326592 bytes
Redo Buffers
6881280 bytes
4. Monte la base de datos en espera:
<alter database mount standby database;>
Deberías ver esto:
Database
altered.
5. Iniciar la recuperación:
<recover managed standby database disconnect;>
Ves esto:
Media
recovery complete.
6. Inicie sesión en SQL * Plus en el modo de espera actual y escriba lo siguiente:
<alter database commit to switchover to physical
primary;>
Deberías ver esto:
Database
altered.
7. Apague la base de datos en espera:
Deberías ver esto:
Database closed.
Database dismounted.
ORACLE instance shut down.
8. Asegúrese de que todos los parámetros de inicialización apropiados estén configurados para que esta base de datos se comporte correctamente como primaria.
9. Empiece
normalmente:
<startup>
Debería ver algo como esto:
ORACLE instance started.
Total System Global Area 789172224 bytes
Fixed Size 2148552 bytes
Variable Size
578815800 bytes
Database Buffers
201326592 bytes
Redo Buffers
6881280 bytes
Database
mounted.
Database
opened.
