Olá pessoal,
Espero que estejam bem.
Um cliente me ligou há alguns dias, eles possuem um Data Guard Physical Standby rodando no modo de proteção Maximum Performance.
Um Data Guard rodando em Maximum Performance fornece o mais alto nível de proteção de dados possível sem afetar a performance do banco de dados primário (Produção). Isso é conseguido permitindo que as transações realizem o commit assim que os dados de redo gerados por essas transações são escritos no redo log online. Os dados de redo também são escritos para um ou mais bancos de dados standby, mas isso é feito de forma assíncrona, portanto, a performance do BD primário não é afetada pelo tempo necessário para enviar os dados de redo e receber o “acknowledgement” do banco de dados standby.
Importante dizer que esse modo de proteção ofrece um “pouco menos” de proteção de dados que o maximum availability.
Esse é o modo de proteção default do Data Guard.
Você pode ler mais detalhes sobre os modos de proteção do Data Guard na documentação oficial: aqui
Bom, primeiramente, vamos verificar como está o Apply Lag do banco de dados Standby:
DGMGRL> show database 'PE1STD'; Database - PE1STD Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 1 second ago) Apply Lag: 37 minutes 56 seconds (computed 0 seconds ago) Average Apply Rate: (unknown) Real Time Query: OFF Instance(s): PE1 Database Status: SUCCESS
Realmente, observamos que o Apply Lag está em quase 38 minutos, MESMO que o Transport Lag esteja em zero. Isso pode nos levar a algumas conclusões rápidas:
- Podemos ter alguma sessão aguardando por eventos de espera;
- Podemos ter alguma lentidão nos discos onde os archive logs (leitura) e os datafiles (escrita) estão armazenados;
- Podemos ter alguma configuração levando a esse comportamento.
Realizei a checagem das duas primeiras possibilidades: não havia sessões em espera, os discos aparentemente performavam bem.
Bem, nos restou checar se temos alguma configuração que leva a esse comportamento. A pergunta que vem é: existe alguma configuração que causa esse “atraso” no Apply?
Sim, existe!
No Data Guard Broker, há uma propriedade chamada DelayMins, essa propriedade também é conhecida como DELAY, caso você use o Standby na configuração manual, sem o Broker, e está configurando os valores de LOG_ARCHIVE_DEST.
Essa propriedade especifica em minutos, o quanto os serviços de log apply irão “atrasar” o início da aplicação dos archivelogs na base de standby. Quando essa propriedade está definida para 0 minutos, os serviços de log apply realizarão o apply dos dados de redo assim que possível.
Importante dizer que para realizar uma operação de switchover, essa propriedade PRECISA estar definida como 0. Ou seja, TODOS os dados precisam estar aplicados.
Você pode ler sobre essa propriedade direto da documentação oficial, aqui.
Vamos verificar o valor dessa propriedade:
DGMGRL> show database 'PE1STD' 'DelayMins'; DelayMins = '30'
A seguinte informação também estava no alert.log:
OK! Confirmado qu o DelayMins está definido como 30, ou seja, 30 minutos de Delay para o apply.
PR00 (PID:27025): Media Recovery Delayed for 30 minute(s) T-1.S-67190
Você também pode checar se o BD de Standby está com o DELAY ativado consultando o valor da coluna DELAY_MINS na view V$ARCHIVE_DEST.
Vamos agora definir o valor de DelayMins novamente para 0.
DGMGRL> edit database 'PE1STD' set property 'DelayMins' = '0'; Property "DelayMins" updated
Em menos de 3 minutos o Apply Lag zerou e a base de dados ficou pronta para o switchover, caso necessário.
DGMGRL> show database 'PE1STD'; Database - PE1STD Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 0 seconds ago) Apply Lag: 0 seconds (computed 0 seconds ago) Average Apply Rate: 58.88 MByte/s Real Time Query: OFF Instance(s): PE1 Database Status: SUCCESS
Espero que seja útil!
Um abraço,
Vinicius
