ORACLE HIGH AVAILABILITY

ORACLE DATA GUARD

Lic. Alejandra Pazos Freire

 Qué es Oracle Data Guard?
Base de Datos Base de Datos
Primaria Transporte de Redo Standby

Oracle Net

Base de Datos Copia de la

Base de Datos
 Tipos de Bases Standby

– Standby Física
• Identica a la base primaria (a nivel de bloques)
• Sincronizada con la base primaria a través de la aplicación de
los archive log files recibidos de la misma
• Puede usarse tanto como protección como para consultas

– Standby Lógica
• Comparte la misma definición de esquema
• Sincronizada con la base primaria a través de la
transformación de los datos recibidos en los archive logs en
sentencias SQL y luego la ejecución de dichas sentencias
• Puede ser usada para protección, consultas y upgrades de la
base de datos
 Tipos de Bases Standby
– Snapshot standby
• Completamente modificable
• Creada a partir de una standby física
• Las modificaciones locales a la standby se descartan
cuando se regresa al estado de standby física.
• Puede ser usada para testing
Tipos de Servicios de Data Guard
• Data Guard provee tres tipos de servicios:
– Servicios de transporte de Redo
– Servicios de Aplicación de cambios
• Redo Apply
• SQL Apply
– Servicios de administración de roles
 Transición de Roles:
Switchover y Failover
• Oracle Data Guard soportas dos operaciones de
transición de roles:
– Switchover
• Planificado y se puede volver al rol anterior
• Usado para mantenimiento de Sistema Operativo o Hardware
– Failover
• Cambio de rol no planificado
• Usado en caso de emergencias
• Pérdida mínima o nula de datos (dependiendo de la elección
del modo de protección)
• Puede ser iniciado automáticamente cuando se habilita el fast-
start failover
Oracle Data Guard Broker Framework
Oracle
Management
Server
Repositorio

Agente Agente

Base de Datos
Base de
Primaria
Data Datos
Data
Guard Guard Standby
broker Enterprise Manager broker

Cliente de Administración
Interfaces para la administración de
la configuración del Data Guard
– Configuración del Data Guard broker:
• Interfaz de línea de comandos DGMGRL
• Enterprise Manager Grid Control
• Comandos SQL para consultar las vistas del diccionario de datos
– Configuración sin Data Guard broker:
• Comandos SQL
 Oracle Data Guard: Architecture
Primary database MRP or Standby
transactions LSP
database
LNSn RFS
Redo
buffer

LGWR (Real-time

Oracle net
apply)
Standby Backup
Online redo logs
redo
logs Reports
ARC0

ARC0 Gap resolution

Archived redo Archived redo

logs logs
 Standby Física:
Arquitectura de Aplicación de Redo
Production Physical standby
database database
Redo Redo
transport apply

Redo
stream

Backup

Primary Physical standby

database database
 Standby Lógica:
Arquitectura de Aplicación de SQL
Production Logical standby
database database
SQL Apply
Redo transport

Transform redo
information into
SQL

Reports

Primary Logical standby

database database
Detección automática y resolución de Gaps
Primary database
transactions MRP or Standby
LSP
database

LNSn RFS
Redo
buffer

LGWR (Real-time

Oracle net
apply)
Standby
Online redo logs Backup
redo
logs Reports
ARC0
ARCH ping
ARC0
Redo to
resolve gap
Archived redo Archived redo
logs logs
 Modos de Protección
• Seleccionar el modo conveniente para lograr un balance entre costo, disponibilidad, performance y
protección de datos:
– Máxima Protección
• Asegura cero pérdida de datos en caso de falla
• La base primaria se baja si no hay por lo menos una standby sincronizada
• El redo se debe escribir tanto en el redolog online local como en el standby redolog de por lo
menos una standby
• Al menos una standby debe tener standby redo logs y debe estar configurado ese destino con
SYN y AFFIRM
– Máxima Disponibilidad
• Asegura cero pérdida de datos sin comprometer la disponibilidad de la base primaria (no se
baja en caso de que no haya standby sincronizada)
• Si no hay una standby sincronizada disponible, la primaria opera en modo no-sincronizado
hasta que una standby se sincronice.
• Al menos una standby debe tener standby redo logsy debe estar configurado el destino con
SYNC y AFFIRM.
– Máxima Performance
• Nivel más alto de seguridad sin afectar la performance de la primaria
• Las transacciones se confirman en cuanto la información de redo se escribe en el redo log
online local.
• El redo es enviado a la standby en forma asincrónica .
• Al menos una sstandby debe tener standby redo logs y debe estar configuracdo el destino con
ASYNC y NOAFFIRM
 Requerimientos del Data Guard
• Hardware y Sistema Operativo
Los sistemas de la base primaria y la standby pueden
tener diferentes:
• Arquitecturas de CPU
• Sistemas Operativos
• Binarios del Sistema Operativo (32-bit o 64-bit)
• Binarios de Oracle Database (32-bit o 64-bit)

• Software de Base de Datos Oracle

• Debe estar instalado el mismo release de Oracle Database
Enterprise Edition para todas las bases de datos excepto
cuando se realiza un rolling database upgrade usando una
logical standby database.
• Si alguna de las bases usa ASM u OMF, todas las bases
deberían tener la misma combinación
 Beneficios de Implementar
Oracle Data Guard
• Oracle Data Guard provee los siguientes
beneficios:
– Servicio continuo durante fallas de datos
incapacitantes o desastrosas
– Protección de datos completa contra la pérdida o
corrupción de datos
– Eliminación de sistemas pasivo ociosos
– Configuración flexible del sistema para adecuarse a
las necesidades del negocio respecto a protección y
recuperación de datos
– Administración centralizada
Pasos para crear una Standby Física

Preparar la base de datos primaria.

Habilitar FORCE LOGGING a nivel de la base de datos.

Crear un password file si se lo necesitara.

Crear los standby redo logs.

Definir los parámetros de inicialización usados para Data Guard.

Habilitar el archiving.

Definir parámetros para la standby física.

Configurar Oracle Net Services.

Crear una entrada en el tnsnames.ora que apunte a la standby

Modificar el listener.ora para que también escuche para la standby

Iniciar la instancia de la standby database.

Duplicar la base de datos primaria para generar la standby.
Con el utilitario RMAN se facilita la operación.
duplicate target database for standby from active database
spfile parameter_value_convert

Iniciar el transporte y aplicación de la información de redo.

Creación de los Standby Redo Logs

Standby Archived
Redo from primary redo logs redo logs
database

RFS ARC0

MRP/LSP

Standby database
Parámetros asociados a Data Guard
– DB_NAME
– DB_UNIQUE_NAME
– LOG_ARCHIVE_CONFIG
– LOG_ARCHIVE_DEST_n
– LOG_ARCHIVE_DEST_STATE_n
– ARCHIVE_LAG_TARGET
– LOG_ARCHIVE_TRACE
– LOG_ARCHIVE_FORMAT
– DB_FILE_NAME_CONVERT
– LOG_FILE_NAME_CONVERT
– STANDBY_FILE_MANAGEMENT
– FAL_CLIENT
– FAL_SERVER
– DB_LOST_WRITE_PROTECT
 Especificación de Destinos
basados en Roles
Primary Standby
database database

Not used

log_archive_dest_1 = log_archive_dest_1 =
'service=pc00sby1 async 'service=pc00prmy async
valid_for= valid_for=
(online_logfile, (online_logfile,
primary_role) primary_role)
db_unique_name=pc00sby1' db_unique_name=pc00prmy'
Habilitación del Real-Time Apply
RFS

Primary MRP
database Standby
redo log
files

ARC0

Archived
redo log
Standby
files
database
 Oracle Data Guard Broker
Características
– Framework para administración distribuida del Data
Guard
– Automatiza y centraliza la creación, mantenimineto y
monitoreo de las configuraciones del Data Guard
– Se pueden realizar operaciones local o remotamente

Componentes
– En el cliente, interfaces:
• Oracle Enterprise Manager Grid Control
• DGMGRL (línea de comandos)
– En el servidor, Data Guard monitor:
• DMON process
• Archivos de Configuración
 Data Guard Broker:
Modelo de Administración
Configuración del Data Guard Broker

Standby database
Broker-controlled Standby database
databases Standby database
Standby database
Standby database
Standby database
Standby database
Standby database
Primary database Standby database

Instances
Instances
Data Guard Broker: Arquitectura
Graphical user interface
or
command-line interface
Data Guard Configuration Standby site 9
Standby site 2
Primary site Standby site 1
Configuration Configuration
files files
Standby
database
Standby Log
Primary redo logs
database apply
Online
redo logs services
Online DMON DMON
redo logs Archived
redo logs
Archived
Log redo logs Oracle
transport Net
Standby
services redo logs
Beneficios de usar Data Guard Broker
– Mejora la Alta-Disponibilidad, protección de datos y
capacidades de protección de desastres, al
automatizar tanto las tareas de configuración como
las de monitoreo
– Delinea el proceso para que cualquiera de las standby
reemplace a la primaria y entre en producción
– Habilita una fácil configuración para agregar standbys
– Provee una administración extendida, simplificada y
centralizada
– Comunica automáticamente las bases de una
configuración de Data Guard usando Oracle Net
Services
– Provee validación pre-definida para monitorear la
salud de todas las bases de datos en la configuración
Logical Standby Database: Beneficios
– Provee un uso eficiente de los recursos del sistema:
• Base de datos Abierta, Independiente y Productiva
• Se pueden crear índices adicionales y vistas materializadas para mejorar la
performance de las consultas
– Reduce la carga de trabajo en la base primaria absorbiendo algunas de
las tareas:
• Reportes
• Sumarizaciones
• Consultas
– Provee protección de datos:
• Las corrupciones en la base primaria no se propagan
– Provee capacidades de recuperación de desastres:
• Switchover y failover
• Minimiza el tiempo sin servicio de los cortes, planificados o no.
– Puede usarse para hacer un upgraqde del software de Oracle Database y
la aplicación de patch sets.
 Standby Lógica:
Arquitectura de SQL Apply
Production Logical standby
database database
SQL Apply
Redo transport

Transform redo
information into
SQL

Reports

Primary Logical standby

database database
 Standby Lógica:
Arquitectura de SQL Apply
LCR
Reader Preparer LCR Builder
:
Shared
Redo pool
Redo data from records Transaction
Logical change records not
primary database groups
Log Mining grouped into transactions

Apply processing
Applier Coordinator Analyzer

Transactions to be Transactions
applied sorted in
Data files
dependency
order
Preparación para una Standby Lógica
• Antes de crear una logical standby database:
– Revisar si hay tipos de datos no soportados:
BFILE, ROWID, User-defined types, Multimedia data types (Spatial,
Image, and Oracle Text), Collections (VARRAYS and nested tables), LOBs
stored as SecureFiles, XMLType stored as OBJECT RELATIONAL BINARY
XML
• Vista DBA_LOGSTDBY_UNSUPPORTED

– Revisar si hay Objetos no soportados:

• Tables and sequences in the SYS schema
• Tables using table compression
• Tables used to support materialized views
• Global temporary tables
– Vista DBA_LOGSTDBY_UNSUPPORTED_TABLE

– Concientizarse de las sentencias DDL no soportadas.

– Asegurarse de la unicidad de las filas.
– Vista DBA_LOGSTDBY_NOT_UNIQUE

– Verificar que la primaria esté en ARCHIVELOG.

 Creación de una Standby Lógica
usando comandos SQL
1. Crear una Standby Física.
2. Detener la aplicación de Redo en la standby física.
3. Preparar la base primaria para soportar una standby lógica.
4. Construir el Diccionario del LogMiner dentro de los datos de
redo.
5. Transformarla en una standby lógica.
6. Abrir la Standby Lógica.
- Agregar la Standby Lógica a una configuración de Data Guard existente
7. Verificar que la standby lógica está funcionando
adecuadamente
 Que los Archived log files estén registrados
 Que la primaria envíe el redo a la standby
 Que la standby aplique bien la información de redo
Securizando la Standby Lógica
– Configurar como Database Guard para controlar el
acceso de los usuarios a las tablas.
– ALTER DATABASE GUARD opciones del comando:
• ALL: Evita que los usarios hagan cambios en cualquier
dato de la base
• STANDBY: Evita que los usuarios hagan cambios en
cualquier dato mantenido por el Data Guard SQL Apply
• NONE: Seguridad normal
– Columna GUARD_STATUS en vista V$DATABASE.
– Definido automáticamente como ALL por el broker.
– Las restricciones aplican a cualquier usuario
excepto a SYS.
Eliminación Automática de los
Redo Log Files por el SQL Apply

Redo logs SQL Transform redo Logical

from Apply information into standby
primary SQL database
database

Delete redo log files

Manejo remoto de la retención de los
Archived Log Files
• El parámetro LOG_AUTO_DEL_RETENTION_TARGET:
– Es usado para especificar el número de minutos que el SQL
Apply mantiene un archived log remoto después de aplicar
completamente su contenido
– Es aplicable sólo si el LOG_AUTO_DELETE está puesto en
TRUE y la flash recovery area no está siendo usada para
almacenar archived logs remotos
– Valor default: 1440 minutos
Manejando el filtrado en SQL Apply
• Propiedades configurables para definir el filtro:
1. LsbyASkipCfgPr: SQL Apply debería ignorar
las sentencias que se especifiquen.
2. LsbyASkipErrorCfgPr: SQL Apply debería
ignorar los errores especificados.
3. LsbyASkipTxnCfgPr: SQL Apply debería
ignorar las transacciones que se especifiquen.
• Propiedades configurables para eliminar los
filtros previamente definidos:
1. LsbyDSkipCfgPr
2. LsbyDSkipErrorCfgPr
3. LsbyDSkipTxnCfgPr
Monitoreo del Data Guard
Métricas y Alertas del Enterprise Manager
– Métricas: Unidades de medida que se usan para conocer la salud del
sistema
– Thresholds: Valores límites contra los cuales se comparan las métricas
– Alertas: Indicación que se genera cuando se alcanza un threshold
 Monitoreo manual
• Data Guard Broker
– DGMGRL> SHOW CONFIGURATION;
– DGMGRL> SHOW DATABASE VERBOSE 'pc00prmy';
– DGMGRL> SHOW DATABASE 'pc00prmy' 'StatusReport';

• Vistas
– V$LOGFILE
– V$STANDBY_LOG
– V$ARCHIVE_DEST
– V$MANAGED_STANDBY
– V$DATAGUARD_STATS
– V$LOGSTDBY_TRANSACTION

• Trace
– LOG_ARCHIVE_TRACE
– DIAGNOSTIC_DEST
Uso de Flashback Database en una
Configuración Data Guard
– Flashback Database provee lo siguiente:
• Una alternativa para restaurar y recuperar la base primaria
• Una forma de reiniciar la base primaria que fue deshabilitada
después de un failover hacia una standby física
• Una alternativa a la postergación de la aplicación de redo, para
proteger contra los errores de usuarios y las corrupciones
lógicas
– Flashback Database debe estar configurado para usar las
siguientes características en el Data Guard:
• Fast-start failover
• Snapshot standby
– Flashback Database se recomienda cuando se usa el
broker porque éste habilita automáticamente el real-
time apply.
Transición de Roles: Switchover
Transición de Roles: Failover
 Transición de Roles:
Switchover y Failover
– Switchover
• Cuando se planifica volver a los roles originales
• Usado para mantenimiento de hardware o sistema operativo
• Se lo realiza manualmente
• Se cambian los roles de la base primaria y de la standby
• No requiere resetear los online redo logs de la nueva base primaria
• No se incurre en pérdida de datos

– Failover
• Cuando NO se planifica volver a los roles originales
• Usado en una emergencia
• Nula o mínima pérdida de datos (dependiendo del modo de
protección)
– Completo: Intenta minimizar la pérdida de dato aplicando en la standby
todo el redo disponible
– Inmediato: No se aplica redo adicional a la standby
• Se puede habilitar Fast-start failover para que se haga automático
Consideraciones para un Switchover
con una Standby Lógica
– El switchover no baja la base primaria.
– Si bien no es necesario terminar las sesiones de
los usuarios, se recomienda hacerlo.
– La standby lógica puede no tener todos los datos.
– El Switchover a una standby lógica invalida y
deshabilita todas las standby físicas y snapshots
de la configuración.
Consideraciones del Failover
– La vieja base primaria ya no forma parte de la
configuración.
– Es posible que haya pérdida de datos.
– Debería ser usado sólo en emergencias.
– Cuando se elige una standby para convertir en
primaria, se debería:
• Elegir una standby física cuando sea posible
• Elegir la standby más actualizada
 Fast-Start Failover

Observer
Loss of connectivity >
fast-start failover threshold

Primary Fast-start failover

database standby database
 Snapshot Standby: Architecture
Primary database
transactions Snapshot
MRP
standby
database
LGWR LNSn RFS

Transactions

Oracle net
Online
redo Standby
logs redo logs

ARC0

ARC0

Archived redo Archived redo

logs logs
Snapshot Standby: Target Restrictions

• Una snapshot standby no puede ser:

– La única standby en una configuración de máxima
protección
– El destino de un switchover
– El destino de un fast-start failover
 Oracle Active Data Guard
– Es una opción de la Oracle Database 11g Enterprise Edition
– Mejora la calidad de servicio permitiendo sacar del
ambiente productivo hacia una standby, actividades de
mucho consumo de recursos
– Incluye las siguientes características:
• Real-time query
• RMAN block change tracking en una standby física

Redo Redo
transport apply

Redo
Primary stream Physical standby Queries
database database
 Real-Time Query
Habilitar
• Detener el Redo Apply
• Abrir la base en modo read-only
• Reiniciar el Redo Apply

Deshabilitar
1. Bajar la standby
2. Reiniciar la standby en modo MOUNT
 Block Change Tracking
on a Physical Standby Database
– Habilitar el block change tracking en una standby
física para realizar backups incrementales rápidos.
– Los bloques de los datafiles que se ven afectados
por modificaciones se registran en el block change
tracking file.
– El block change tracking file es un archivo binario
usado por el RMAN para registrar los bloques
cambiados para mejorar la performance del backup
incremental.
RMAN para Back Up y Restore de Archivos
en la Configuración del Data Guard
– RMAN puede usarse para hacer backup y recovery
en una configuración de Data Guard
– Los backups de la Standby son usables para la base
de datos primaria.
– Los Backups de la standby lógica no son usables
para la base primaria.
– Cuando se usa el RMAN en Data Guard se requiere
usar catálogo.
– Buenas Prácticas de RMAN y Data Guard :
• Realizar backups en las bases standby y primaria para
reducir el tiempo de recuperación (MTTR).
• Tomar backups incrementales diariamente.
 Pasando los Backups a una
Standby Física
– Los Backups de data files y archived redo logs son
totalmente intercambiables; los backups de los
Control file backups no.
– Las bases primaria y standby deben usar el mismo
cátalogo de RMAN.
– No es necesario registrar la standby.
 Backup and Recovery
de una Standby Lógica
– Consideraciones de un Backup:
• Usar el mismo método de backup que se usa para la
base primaria.
• Los archivos no son intercambiables con la base
primaria.
– Consideraciones del Recovery:
• Si se pierden archivos individuales, realizar el recovery
como si fuera cualquier otra base.
• Re-crear la standby lógica si se pierde la base completa.
• Usar una copia binaria del control file para recuperarlo.
Evitar que los clientes se conecten
a la base equivocada
– Usar servicios de la base para evitar que los clientes se
conecten a una base equivocada en una configuración de
Data Guard.
– Los servicios actúan como una capa de abstracción entre
el cliente y las instancias de la base de datos.
– Los servicios se registran con los listeners..
– Los clientes se conectan a los servicios en lugar de
conectarse a instancias de base de datos.
– Los Listeners usan los detalles de la registración para
determinar cuál instancia soporta un servicio particular en
un momento en particular.
– Los Listeners luego dirigen los pedidos de conexión a las
instancias correctas; y si no es posible devuelven un
mensaje de error.
 Client Failover: Componentes
• Las siguientes características se usan para
implementar el failover de cliente y minimizar
el impacto de los cortes planeados o no
planeados:
– Connect time failover
– Transparent Application Failover (TAF)
– Fast Application Notification (FAN)
– Fast Connection Failover (FCF)
– DB_ROLE_CHANGE system event
Upgrading una Configuración del
Oracle Data Guard Broker
– Si se está usando el Data Guard broker, se deben hacer
algunos pasos antes de hacer un upgrade a las bases:
1.Deshabilitar la administración del broker para la configuración
2.Detener el Data Guard Broker

– After completing the upgrade:

1.Iniciar el Data Guard broker.
2.Habilitar la administración del broker para la configuración
Upgrade de una Base en una Configuración
de Data Guard con Standby Física
• Para realizar un upgrade tradicional:
1. Realizar los pasos de preparación para un upgrade.
2. Bajar la base de datos primaria.
3. Bajar la standby física.
4. Instalar el Software nuevo en el equipo donde está la
standby física.
5. Montar la standby física.
6. Iniciar la aplicación de Redo en la standby física.
7. Instalar el Software nuevo en el equipo de la base
primaria.
8. Realizar el Upgrade de la base primaria.
9. Abrir la base primaria actualizada.
Upgrade de una Base en una Configuración de
Data Guard con una Standby Lógica
• Para realizar un upgrade tradicional:
1. Realizar los pasos de preparación para un upgrade.
2. Definir el modo de protección en MAXIMUM PERFORMANCE.
3. Detener toda la actividad de los usuarios en la base primaria y
diferir el destino remoto de la standby lógica.
4. Detener el SQL Apply en la standby.
5. Instalar el software de Oracle Database en el equipo de lab ase
primaria y hacer el proceso de upgrade en ella.
6. Instalar el software de Oracle Database en el equipo de la
standby lógica y hacer el upgrade en esa base.
7. Reiniciar el SQL Apply en la standby.
8. Abrir la base primaria actualizada.
9. Volver al valor original el modo de protección, si fuera
necesario.
Usando el SQL Apply para hacer el
Upgrade en la base Oracle
– Usa una standby lógica para realizar un rolling upgrade
del software de Oracle Database 10g del patch set
release n a cualquier otro más alto o versiones mayores.
– Incurre en un mínimo tiempo fuera de servicio usando
diferente releases del Oracle Database en la primaria y
la standby lógica mientras se hace el upgrade.

SQL Apply

Primary database Standby database

Oracle Database 10g Oracle Database 11g
Usando el SQL Apply para hacer el
Upgrade en la base Oracle
– Crear una nueva standby lógica para realizar el rolling
upgrade.
– Usar una standby lógica existente para realizar el rolling
upgrade.
– Usar una standby física existente para realizar el rolling
upgrade (sólo con Oracle Database 11g).
¡ MUCHAS GRACIAS !

Lic. Alejandra Pazos Freire

Esp. en Gestión de Tecnología
[email protected]