Índice do fórum Treinamentos Avançados Treinamento Oracle Data Guard Data Guard inativo...

Data Guard inativo...

Dúvidas, dicas e atualizações sobre o Treinamento Oracle Data Guard.

Mensagem Ter Mai 05, 2015 1:08 pm

Mensagens: 0
Localização: Santos/SP

Eu criei uma instância Physical Standby para uma base de produção em um ambiente onde costumam haver quedas de energia. Só que este ambiente ficou sem poder prosseguir nos serviços de monitoramento e demais providências, enquanto eram tratadas as questões contratuais para este tipo de prestação de serviços (de consultoria). Mas como houveram outros problemas neste meio-tempo, foi necessário efetuar algumas manutenções específicas/emergenciais para resolver outros problemas que surgiram, de modo que eu aproveitei para checar o status do ambiente destinado ao D&R, constatando que o ambiente estivera desativado por um período mais longo que o previsto. Ao tentar reativar os procedimentos de D&R, constatei que os problemas passaram a ser outros, conforme descrito a seguir:

C:\Oradiag>dgmgrl sys/xyz123@prod
DGMGRL for 64-bit Windows: Version 11.2.0.3.0 - 64bit Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected.

DGMGRL> show configuration;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
prod - Primary database
Error: ORA-16810: vários erros ou advertências detectadas para o banco de dados

prod2 - Physical standby database
Error: ORA-16766: A Aplicação de Redo foi interrompida

Fast-Start Failover: DISABLED

Configuration Status:
ERROR

DGMGRL> show database prod

Database - prod

Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
prod
Error: ORA-16737: o serviço de transporte de redo para banco de dados stand-by "prod2" tem um erro

Database Error(s):
ORA-16783: não é possível resolver o intervalo do banco de dados prod2

Database Status:
ERROR

DGMGRL> show database prod2

Database - prod2

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 52 days 13 hours 14 minutes 16 seconds
Apply Lag: (unknown)
Real Time Query: OFF
Instance(s):
prod2

Database Error(s):
ORA-16766: A Aplicação de Redo foi interrompida

Database Status:
ERROR

DGMGRL> enable configuration;
Enabled.

DGMGRL> show configuration;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
prod - Primary database
Error: ORA-16724: não é possível resolver o intervalo de um ou mais bancos de dados stand-by

prod2 - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
ERROR

DGMGRL> show database prod;

Database - prod

Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
prod

Database Error(s):
ORA-16783: não é possível resolver o intervalo do banco de dados prod2

Database Status:
ERROR

DGMGRL> show database prod2;

Database - prod2

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 52 days 13 hours 16 minutes 22 seconds
Apply Lag: (unknown)
Real Time Query: ON
Instance(s):
prod2

Database Status:
SUCCESS

DGMGRL> exit

Pergunto: haveria alguma forma de resolver isto (via recover após copiar os archivelogs para o servidor D&R) ou seria mais apropriado reconstruir o ambiente D&R a partir de um restore via RMAN, de modo a recriar o Physical Standby ?

Agradeço desde já se puder(em) comentar...
Anexos
Registrando a situação da instância de produção no servidor BDORACLEDR após a checagem para reativação do ambiente para operar como D&R em 01052015.jpg
Registrando a situação da instância de produção no servidor BDORACLEDR após a checagem para reativação do ambiente para operar como D&R em 01052015
Registrando a situação da instância de produção no servidor BDORACLEDR após a checagem para reativação do ambiente para operar como D&R em 01052015.jpg (223.73 KiB) Exibido 14927 vezes

Mensagem Ter Mai 05, 2015 3:08 pm

Mensagens: 0
Localização: Santos/SP

Olá,

Só acrescentando um detalhe importante, à respeito:

...
Tue May 05 11:26:11 2015
MRP0 started with pid=31, OS id=2468
started logmerger process
Tue May 05 11:26:16 2015
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 32 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Completed: alter database recover managed standby database disconnect from session
Media Recovery Waiting for thread 1 sequence 12378
Fetching gap sequence in thread 1, gap sequence 12378-12381
Tue May 05 11:28:13 2015
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 12378-12381
DBID 261139838 branch 849301504
FAL[client]: All defined FAL servers have been attempted.
------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that's sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
------------------------------------------------------------
Tue May 05 11:49:59 2015
Archived Log entry 5289 added for thread 1 sequence 28572 rlc 849301504 ID 0xf90a27e dest 2:
RFS[62]: No standby redo logfiles available for thread 1
RFS[62]: Opened log for thread 1 sequence 28573 dbid 261139838 branch 849301504
...

SQL> select sequence#, archived, applied from v$archived_log;

SEQUENCE# ARC APPLIED
---------- --- ---------
...
12376 YES YES
12377 YES YES <---
12392 YES NO
12382 YES NO
12383 YES NO
12385 YES NO
12419 YES NO
27295 YES NO
27301 YES NO
27302 YES NO
...

E, como não disponho mais desta sequência de archivelogs, creio que não me resta outra alternativa senão reconstruir o Physical Standby, de novo...

Att.

Mensagem Qua Mai 06, 2015 12:21 pm
portilho Site Admin

Mensagens: 482
Olá.

Mesmo sem os Archives, talvez não seja necessário recriar o Standby (que seria restaurar um Backup RMAN do banco de Produção no Standby).

1 - Verifique qual o SCN atual do STANDBY:
SQL> SELECT CURRENT_SCN FROM V$DATABASE;

2 - Na Produção, execute um BACKUP INCREMENTAL FROM SCN, utilizando neste comando o SCN retornado no passo anterior:
RMAN> BACKUP INCREMENTAL FROM SCN 1234567 DATABASE;

3 - Na Produção, crie um no STANDBY CONTROLFILE:
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/home/oracle/STB.ctl';

4 - Copie o STANDBY CONTROLFILE e o BACKUP INCREMENTAL para o Standby.

5 - Coloque o STANDBY em NOMOUNT, e sobrescreva seus CONTROLFILEs utilizando o STANDBY CONTROLFILE copiado.

6 - Coloque o STANDBY em MOUNT, e catalogue o BACKUP INCREMENTAL copiado:
RMAN> CATALOG START WITH '/home/oracle/';

7 - Execute RECOVER pleo RMAN:
RMAN> RECOVER DATABASE;

8 - Inicie novamente o RECOVER de STANDBY:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DISCONNECT FROM SESSION;

A vantagem deste procedimento é que dependendo da proporção "Tamanho do Banco" x "Tamanho das Alterações", o BACKUP INCREMENTAL será menor do que um BACKUP completo.

Mensagem Qua Mai 06, 2015 8:54 pm

Mensagens: 0
Localização: Santos/SP

Olá, Portilho,

> Mesmo sem os Archives, talvez não seja necessário recirar o Standby (que seria restaurar um Backup RMAN do banco de Produção no Standby).

Grato por comentar. Aproveito para saber como configurar para que o procedimento de backup via RMAN no produção (primary) indique para o standby que os archivelogs já aplicados possam ser removidos (na conclusão do job), uma vez que sendo realizado na base de produção, mantinha disponíveis somente os 3 últimos dias enquanto que no stanby iam sendo acumulados, sem serem removidos os já aplicados:

RMAN config for primary   <--- https://community.oracle.com/thread/2436900

## keep all backups for at least 7 days
rman> configuration retention policy to recovery window of 7 days;

## chose one of the following depending on when you want the archives to be deleted after shipping or after being applied
rman> configure archivelog deletion policy to shipped to all standby;
rman> configure archivelog deletion policy to applied to all standby;

## configure the connect identifiers for all datbases
rman> configure db_unique_name prod1 connect identifier 'prod1';
rman> configure db_unique_name prod1dr connect identifier 'prod1dr';
rman> list db_unique_name of database;

RMAN config for standby     

## enable automatic backups of the control file and server parameters
rman> configure controlfile autobackup on;

## skip backing up datafiles which a valid backup alrady exists with the same checkpoint
rman> configure backup optimization;

## configure tape or disk channels as required by the media software
rman> configure channel device type sbt params '<channel parameters>';

## Since the logs are backed up at the standby you can specify none
rman> configure deletion policy to none;

## delete the archive logs once they have been applied
rman> configure archivelog deletion policy to applied to standby;


Segue abaixo a minha configuração, tanto no de produção quanto no de Standby:

C:\Oradiag>set ORACLE_SID=prod

C:\Oradiag>rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Ter Mai 5 13:50:55 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD (DBID=261139838)

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name PROD are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'E:\APP\ORA11G\PRODUCT\11.2.0\DBHOME_1\DATABASE\SNCFPROD.ORA'; # default

RMAN> exit

Recovery Manager complete.

...

C:\Oradiag>set ORACLE_SID=prod2

C:\Oradiag>rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Ter Mai 5 13:17:57 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD (DBID=261139838)

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name PROD2 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'E:\APP\ORA11G\PRODUCT\11.2.0\DBHOME_1\DATABASE\SNCFPROD2.ORA'; # default

RMAN> exit

Recovery Manager complete.


Agradeço desde já se puder comentar à respeito, porque não compreendi se ao configurar no RMAN da base de produção a diretiva "CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;" fará com que os archivelogs sejam descartados após terem sido aplicados, após o backup (via RMAN) ter sido realizado no de produção. Tal configuração precisa ser aplicada (via RMAN) no Physical Standby, também ? Seria o caso então de também deixar programado o job de backup (via RMAN) no Standby ?

Abs,
Sven

Mensagem Qui Mai 07, 2015 2:38 am

Mensagens: 0
Localização: Santos/SP

Portilho,

Seria apropriado acrescentar o comando abaixo entre os passos 5 e 6 no STANDBY, pois sem isso aparece um ORA-19573 durante o RECOVER DATABASE:

SQL> alter database recover managed standby database cancel;

Foi somente após efetuar o comando acima no STANDBY que o RECOVER DATABASE pode ser realizado.

Ats,
Sven

Mensagem Qui Mai 07, 2015 10:44 am
portilho Site Admin

Mensagens: 482
Olá.
Eu não coloquei o comando do CANCEL, pois a instância tinha que ter sido desligada para restaurar o CONTROLFILE, o que executaria o CANCEL implicitamente.

Mensagem Qui Mai 07, 2015 10:49 am
portilho Site Admin

Mensagens: 482
Sobre a remoção dos Backups, deve ser adicionada a ordem apra apaga-los também somente após o Backup:

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DEVICE TYPE DISK;

Estes comandos devem ser executados em Produção, e influenciam os Archived Redo Logs de Produção.

No Standby, deve ser criuado uma rotina a parte para remoção dos Archived Redo Logs.

Mensagem Qui Mai 07, 2015 11:39 am

Mensagens: 0
Localização: Santos/SP

portilho escreveu:
Eu não coloquei o comando do CANCEL, pois a instância tinha que ter sido desligada para restaurar o CONTROLFILE, o que executaria o CANCEL implicitamente.


Bem, para colocar esta instância Standby em modo MOUNT eu acabei desligando via shutdown immediate e parando inclusive os serviços durante as tentativas para resolver o problema, mas somente após este comando foi possível prosseguir no recover database...

Abs,
Sven

Mensagem Qui Mai 07, 2015 11:42 am

Mensagens: 0
Localização: Santos/SP

portilho escreveu:
Sobre a remoção dos Backups, deve ser adicionada a ordem apra apaga-los também somente após o Backup:

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DEVICE TYPE DISK;

Estes comandos devem ser executados em Produção, e influenciam os Archived Redo Logs de Produção.

No Standby, deve ser criuado uma rotina a parte para remoção dos Archived Redo Logs.


> Estes comandos devem ser executados em Produção, e influenciam os Archived Redo Logs de Produção.
> No Standby, deve ser criuado uma rotina a parte para remoção dos Archived Redo Logs.

Grato por comentar, pois imaginei que haveria alguma configuração no RMAN para que mantivesse sob controle a quantidade e espaço consumido pelos archivelogs no próprio Standby, tal como ocorre na base de produção...

Mensagem Sex Mai 08, 2015 10:17 am
portilho Site Admin

Mensagens: 482
Ok! Infelizmente, não conheço uma configuração para isto.


Voltar para Treinamento Oracle Data Guard

cron