Treinamento Data Guard

1.533 visualizações

Publicada em

Material de treinamento de Oracle Data Guard utilizado pela Oradata Consultoria e Treinamentos em seus workshops.

Publicada em: Tecnologia
0 comentários
6 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.533
No SlideShare
0
A partir de incorporações
0
Número de incorporações
629
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Treinamento Data Guard

  1. 1. Oracle Data Guard – Implementação & Manutenção Introdução
  2. 2. Visão Geral  Este workshop destina-se a profissionais que buscam aprender e/ou aprimorar seus conhecimentos com o Oracle Data Guard.  É desejável que se tenha o mínimo de conhecimento da arquitetura de banco de dados Oracle, nas versões 11g ou 12c.  O objetivo do workshop é mostrar as principais funcionalidades do processo de Data Guard, bem como o processo de implementação, administração e manutenção. 2
  3. 3. Objetivos do Treinamento  Neste workshop você vai aprender:  Criar um ambiente de replicação com o Data Guard.  Físico.  Lógico.  Snapshot Standby  Gerenciar o Data Guard.  Executar operações de teste (switchover).  Executar operações em desastres (failover).  Recuperar cenários de desastres (failback).  Otimizar o gerenciamento com o Data Guard Broker. 3
  4. 4. Agenda 4  O Data Guard.  Data Guard Físico.  Data Guard Broker (overview).  DGMGRL (configuração).  Data Guard Físico (via OEM).  Data Guard Lógico.  Modos de Proteção.  Monitoramento.  Otimização.  Data Guard & Flashback.  Role Trasictions.  Fast Start Failover.  Snapshot Database.  Active Data Guard.  Backup & Restore.  Conectividade dos clientes.
  5. 5. Instrutor  Douglas Paiva de Sousa  Oracle Instructor – Oradata Cons. e Treinamentos  Oracle WDP Instructor – KaSolution  Oracle WDP Instructor – Grupo Impacta  http://douglasdba.wordpress.com  http://douglasdba.profissionaloracle.com.br  http://www.oradata.com.br/blog http://br.linkedin.com/in/dpsdba/ @oradatact 5 /oradata
  6. 6. Oracle Data Guard – Implementação & Manutenção Data Guard Overview
  7. 7. Neste Capítulo  Neste capítulo você vai aprender:  Arquitetura básica do Data Guard.  Diferenças entre o Data Guard físico, lógico e snapshot  Benefícios de se implementar o Data Guard. 7
  8. 8. O que é Data Guard 8
  9. 9. Tipos de Data Guard  Data Guard Físico (Physical Standby Database)  Cópia exata de um database (bloco a bloco).  Sincronizado através dos archived redologs vindos do banco de dados primário.  Pode ser usado para relatórios em paralelo com o ambiente de produção.  Data Guard Lógico (Logical Standby Database)  Compartilha as mesmas definições de schema.  Sincronizado através dos comandos SQL que são executados no ambiente primário.  Pode ser usado em paralelo com a produção para relatórios e upgrades. 9
  10. 10. Tipos de Data Guard  Snapshot Standby Database.  Banco dados standby completamente “alterável”.  Criado através da conversão de um Data Guard Físico.  Atualizações locais são descartadas, quando o banco de dados volta a ser um standby físico. 10
  11. 11. Tipos de Serviços  Data Guard oferece três tipos de serviços:  Redo transport services  Apply Services  Redo Apply  SQL Apply  Role management services. 11
  12. 12. Troca de Papeis (role trasitions) O Data Guard suporta dois tipos de “role transitions”:  Switchover:  “O primeiro vira segundo e o segundo vira primeiro”.  Para manutenções planejadas (exemplo SO, hardware).  Failover:  Usada em caso de desastres (emergências).  Situações não planejadas.  Zero ou mínima parda de dados (depende da opção escolhida).  Pode ser executada automaticamente (com o fast-start- failover). 12
  13. 13. Data Guard Broker 13
  14. 14. Ferramentas de Administração  Administração de um Data Guard pode ser feita:  Com Data Guard Broker:  DGMGRL (linha de comando).  Enterprise Manager Grid/Cloud Control.  Comandos SQL (direto no banco de dados).  Sem o Data Guard Broker:  Comandos SQL (direto no banco de dados). 14
  15. 15. Arquitetura (overview) 15 Primary database transactions Online redo logs ARC0 RFS MRP or LSP Archived redo logs ARC0 Standby database Reports Standby redo logs Archived redo logs Oraclenet LNSn (Real-time apply) LGWR Redo buffer Gap resolution
  16. 16. Data Guard Físico 16 Produção Standby
  17. 17. Data Guard Lógico 17 Redo transport Transform redo information into SQL SQL Apply Reports Produção Standby
  18. 18. Resolvendo Gaps 18 Produção Online redo logs ARC0 RFS MRP or LSP ARC0 Standby Reports Standby redo logs Backup Oraclenet LNSn (Real-time apply) LGWR Redo buffer ARCH ping Redo to resolve gap
  19. 19. Métodos de Proteção  No Data Guard você vai precisar escolher o melhor método de proteção de seus dados, baseando-se em um de três pilares “custo”, “disponibilidade” e “performance”:  Máxima Proteção.  Máxima Disponibilidade.  Máxima Performance. 19
  20. 20. SO, Hardware e Software  No Data Guard é recomendável que o servidor primário seja igual ao servidor secundário, mas caso não seja possível, alguns componentes pode ser diferentes, como:  Arquitetura de CPU.  Sistema Operacional.  Binários do sistema operacional (32-bit ou 64-bit).  Binários do banco de dados (32-bit ou 64-bit). 20
  21. 21. SO, Hardware e Software  O que deve ser igual:  O mesmo release do Oracle Database Enterprise Edition deve ser instalado nos dois servidores.  Se em algum servidor você usar ASM ou OMF, o mesmo deve ser feito no outro servidor. 21
  22. 22. Benefícios de Data Guard  Com o Data Guard você ganha:  Continuidade no negócio em caso de desastres.  Proteção contra perda e corrupção de dados.  Elimina a replicação “ativo-passivo”.  Configuração flexível de acordo com as necessidades do negócio, seja proteção ou recuperação.  Gerenciamento centralizado. 22
  23. 23. Resumo  Neste capítulo foi abordado:  Arquitetura básica do Data Guard.  Diferenças entre o Data Guard físico, lógico e snapshot  Benefícios de se implementar o Data Guard. 23
  24. 24. Oracle Data Guard – Implementação & Manutenção Data Guard Físico
  25. 25. Neste Capítulo  Neste capítulo você vai aprender:  Configurar o servidor primário juntamente com a camada de redes (Oracle Net Services) para suportar a criação do servidor standby e o processo de “role trasiction”.  Criar a instancia de banco de dados no servidor standby utilizando o RMAN. 25
  26. 26. Processo de criação Para criar um Standby Database Físico:  Prepare o servidor primário.  Defina os parâmetros no servidor Standby.  Configure a camada de redes (listener e tnsnames).  Inicialize a instancia standby.  No RMAN execute DUPLICATE TARGET DATABASE...  Inicialize o processo de transporte e aplicação dos arquivos de redo log. 26
  27. 27. Servidor Primário Pré-requisitos do servidor primário:  Habilitar o “FORCE LOGGING” na instancia.  Criar um arquivo de senhas (se necessário).  Criar os standby redo logs.  Definir os parâmetros do SPFILE.  Colocar a instancia no modo ARCHIVELOG. 27 SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT SQL> ALTER DATABASE ARCHIVELOG SQL> ALTER DATABASE OPEN
  28. 28. Servidor Primário Modo FORCE LOGGING:  Recomendado para garantir a consistência dos dados.  Força a geração de redo log, até mesmo para operações NOLOGGING.  Não “loga” tablespace temporária e seus segmentos.  É recomendado tanto para standby físico quanto logico.  Para habilitar execute o comando: 28 SQL> ALTER DATABASE FORCE LOGGING
  29. 29. Servidor Primário Standby Redo logs: 29 Redo log servidor primário RFS ARC0 Standby redo logs Archived redo logs MRP/LSP STANDBY DATABASE
  30. 30. Servidor Primário Standby Redo logs:  Criando os standby redo logs com o SQL*Plus: 30 SQL> ALTER DATABASE ADD STANDBY LOGFILE 2 '/u01/app/oracle/oradata/orcl/srl01.log' 3 SIZE 50M; Database altered. SQL> ALTER DATABASE ADD STANDBY LOGFILE 2 '/u01/app/oracle/oradata/orcl/srl02.log' 3 SIZE 50M; Database altered.
  31. 31. Servidor Primário Standby Redo logs (consultando os metadados): 31 SQL> SELECT group#, type, member FROM v$logfile 2 WHERE type = 'STANDBY'; GROUP# TYPE MEMBER ------ ------- ------------------------------------------ 4 STANDBY /u01/app/oracle/oradata/pc00prmy/srl01.log 5 STANDBY /u01/app/oracle/oradata/pc00prmy/srl02.log 6 STANDBY /u01/app/oracle/oradata/pc00prmy/srl03.log 7 STANDBY /u01/app/oracle/oradata/pc00prmy/srl04.log SQL> SELECT group#, dbid, thread#, sequence#, status 2 FROM v$standby_log; GROUP# DBID THREAD# SEQUENCE# STATUS ---------- ---------- ---------- ---------- ---------- 4 UNASSIGNED 0 0 UNASSIGNED 5 UNASSIGNED 0 0 UNASSIGNED 6 UNASSIGNED 0 0 UNASSIGNED 7 UNASSIGNED 0 0 UNASSIGNED
  32. 32. Servidor Primário Parâmetros de inicialização SPFILE: 32 Parâmetro Descrição LOG_ARCHIVE_CONFIG Recebe o db_unique_name dos bancos de dados envolvidos no Data Guard. LOG_ARCHIVE_DEST_n Controla o serviço de transporte dos redo logs. LOG_ARCHIVE_DEST_STATE_n Especifica o estado do destino dos redo logs. ARCHIVE_LAG_TARGEET Força um switch de log após um determinado período (em segundos). LOG_ARCHIVE_TRACE Controla o output dos processos de archive.
  33. 33. Servidor Primário Parâmetro LOG_ARCHIVE_CONFIG:  Neste parâmetro, informe o atributo DG_CONFIG mais o DB_UNIQUE_NAME do servidor primário e os demais DB_UNIQUE_NAME do servidor(es) standby. 33 SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIM,STBY)'
  34. 34. Servidor Primário Parâmetro LOG_ARCHIVE_DEST_n  Use este parâmetro para:  Archivelogs local (se não estiver usando a FRA).  Incluir ao menos um destes atributos:  LOCATION: Especifique um caminho válido.  SERVICE: Aliás de TNSNAMES que referencie um standby database.  Inclua um LOG_ARCHIVE_DEST_STATE_n para cada um dos LOG_ARCHIVE_DEST_n. 34 SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1= ‘SERVICE=STBY VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STBY’; SQL> LOG_ARCHIVE_DEST_STATE_1=ENABLE;
  35. 35. Servidor Primário Role Base Destinations: 35 log_archive_dest_1 = 'service=STBY async valid_for= (online_logfile, primary_role) db_unique_name=STBY' SERVIDOR PRIMÁRIO SERVIDOR STANDBY log_archive_dest_1 = 'service=PRIM async valid_for= (online_logfile, primary_role) db_unique_name=PRIM'
  36. 36. Servidor Primário Parâmetro VALID_FOR (Combinações): 36 Combinação Primário Standby Físico Standby Lógico ONLINE_LOGFILE, PRIMARY_ROLE Valid Ignored Ignored ONLINE_LOGFILE, STANDBY_ROLE Ignored Ignored Valid ONLINE_LOGFILE, ALL_ROLES Valid Ignored Valid STANDBY_LOGFILE,STANDBY_ROLE Ignored Valid Valid STANDBY_LOGFILE, ALL_ROLES Ignored Valid Valid ALL_LOGFILES, PRIMARY_ROLE Valid Ignored Ignored ALL_LOGFILES, STANDBY_ROLE Ignored Valid Valid ALL_LOGFILES, ALL_ROLES Valid Valid Valid
  37. 37. Servidor Primário Definindo o modo de transporte dos redo logs:  No parâmetro LOG_ARCHIVE_DEST_n use:  SYNC ou ASYNC  Indica se as operações de rede serão executadas de maneira síncrona ou assíncrona pelo LGWR (default ASYNC).  AFFIRM ou NOARFFIRM  Garante que o arquivo de redo log, foi escrito com sucesso no disco do servidor standby.  NOAFFIRM é o padrão quando ASYNC está em uso e AFFIRM é o padrão quando SYNC está em uso. 37
  38. 38. Servidor Primário Parâmetros de Storage:  Use estes parâmetros apenas quando as estruturas de discos entre os servidores primário e standby forem distintas. 38 Parâmetro Descrição DB_FILE_NAME_CONVERT Converte a localização dos datafiles. LOG_FILE_NAME_CONVERT Converte a localização dos arquivos de redo log. STANDBY_FILE_MANAGEMENT Controla automaticamente o gerenciamento de arquivos entre os servidores.
  39. 39. Servidor Primário DB_FILE_NAME_CONVERT  Deve ser definido quando os servidores possuem estruturas de storage diferenciadas para os datafiles.  Múltiplos pares podem ser adicionados ao mesmo parâmetro.  Usado somente em standby databases físicos.  Pode ser usado também no comando DUPLICATE do rman. 39 SQL> ALTER SYSTEM SET DB_FILE_NAME_CONVERT = (‘/disk1/oradata/prod/’, ‘/disco1/oradata/stby/’, ‘/disk2/oradata/prod/’, ‘/disco2/oradata/stby/’);
  40. 40. Servidor Primário LOG_FILE_NAME_CONVERT  Deve ser definido quando os servidores possuem estruturas de storage diferenciadas para os arquivos de redo log.  Múltiplos pares podem ser adicionados ao mesmo parâmetro.  Usado somente em standby databases físicos.  Pode ser usado também no comando DUPLICATE do rman. 40 SQL> ALTER SYSTEM SET LOG_FILE_NAME_CONVERT = (‘/disk1/oradata/logs/’, ‘/disco1/oradata/logs/’);
  41. 41. Servidor Primário STANDBY_FILE_MANAGEMENT  Usado para manter a consistência dos datafiles nos processos de manutenção do banco de dados primário (adição, remoção, movimentação e etc...).  Recebe dois possíveis valores:  MANUAL: O que o DBA fizer no servidor primário deve ser feito no servidor standby.  AUTO: O que for feito no servidor primário será automaticamente replicado para o servidor standby. 41 SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT = AUTO;
  42. 42. Servidor Primário Exemplo Completo: 42 DB_NAME=PRIM DB_UNIQUE_NAME=PRIM LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIM,STBY)' CONTROL_FILES='/u01/app/oracle/oradata/PRIM/control1.ctl', '/u01/app/oracle/oradata/PRIM/control2.ctl' LOG_ARCHIVE_DEST_1= 'SERVICE=STBY VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STBY' LOG_ARCHIVE_DEST_STATE_1=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
  43. 43. Servidor Primário Arquivo “tnsnames.ora”: 43 PRIM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = ordt-srv1.oradata.com) (PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = PRIM.oradata.com) ) )
  44. 44. Servidor Primário Arquivo “listener.ora”: Deve ter uma entrada estática. 44 SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = PRIM.oradata.com) (ORACLE_HOME = /u01/app/oracle/product/12.1.0/db_1) (SID_NAME = PRIM) ) )
  45. 45. Servidor Primário Arquivo de senha:  Copie o arquivo de senha do servidor primário para o servidor standby.  O arquivo de senha (no servidor primário) se encontra no diretório $ORACLE_HOME/dbs.  No servidor standby renomeie o arquivo para: “orapw<SID>” 45
  46. 46. Servidor Standby Crie um arquivo de parâmetros só com o DB_NAME.  Este arquivo será usado somente no inicio do processo de replicação, após isso será gerado um novo arquivo com todos os parâmetros necessários. 46 $ cd $ORACLE_HOME/dbs $ cat pfile.ora > DB_NAME=STBY
  47. 47. Servidor Standby Crie os diretórios para os arquivos de auditoria: Para armazenar os datafiles, crie os diretórios em “$ORACLE_BASE/oradata”: 47 [oracle@ordt-srv2 ~]$ cd /u01/app/oracle/admin [oracle@ordt-srv2 admin]$ ls PRIM [oracle@ordt-srv2 admin]$ mkdir STBY [oracle@ordt-srv2 admin]$ cd STBY [oracle@ordt-srv2 STBY]$ mkdir adump [oracle@ordt-srv2 oradata]$ mkdir STBY [oracle@ordt-srv2 oradata]$ ls PRIM STBY
  48. 48. Servidor Standby Inicie a instancia (no servidor standby) em modo NOMOUNT, a partir do pfile.ora criado outrora. 48 SQL> startup nomount pfile=$HOME/dbs/pfile.ora ORACLE instance started. Total System Global Area 150667264 bytes Fixed Size 1298472 bytes Variable Size 92278744 bytes Database Buffers 50331648 bytes Redo Buffers 6758400 bytes
  49. 49. Servidor Standby Parâmetros FAL_CLIENT e FAL_SERVER:  Fetch Archive Log (FAL):  Mecanismo responsável por resolver possíveis gaps de archivelogs entre os servidores.  Usado apenas para standby databases físicos.  Processo inicializado apenas quando necessários, após desliga-se automaticamente.  FAL_CLIENT: Servidor primário (o serviço)  FAL_SERVER: Servidor standby (o servidor) 49 FAL_CLIENT = ‘PRIM’ FAL_SERVER = ‘STBY’
  50. 50. Script para replicação Exemplo (via RMAN)50 run { allocate channel prmy1 type disk; allocate channel prmy2 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby from active database spfile parameter_value_convert 'PRIM', 'STBY' set db_unique_name='STBY' set db_file_name_convert='/disk1/df/','/disco1/df/' set log_file_name_convert='/disk1/log/','/disco1/log/' set control_files='/u01/app/oracle/oradata/stby.ctl' set log_archive_max_processes='5' set fal_client='STBY' set fal_server='PRIM' set standby_file_management='AUTO' set log_archive_config='dg_config=(PRIM,STBY)' set log_archive_dest_1='service=STBY ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=PRIM'; }
  51. 51. Executando a replicação Para iniciar o processo de replicação:  Entre no rman e conecte-se na instancia de produção (como “target”) e na instancia standby (como “auxiliary”).  Execute o script criado anteriormente. 51 RMAN> connect target sys/oracle RMAN> connect auxiliary sys/oracle@STBY RMAN> @create_standby
  52. 52. Real-Time Apply 52 RFS Standby redo log files MRP ARC0 Servidor Primário Servidor Standby Archived redo log files
  53. 53. Iniciando o processo de replicação online Para iniciar o processo de replicação online (pós replicação inicial):  Entre no SQL*Plus (como SYSDBA) e execute: 53 $ sqlplus / as sysdba SQL> ALTER DATABASE 2 RECOVER MANAGED STANDBY DATABASE 3 USING CURRENT LOGFILE 4 DISCONNECT FROM SESSION;
  54. 54. Resumo  Neste capítulo foi abordado:  Habilitar o FORCE LOGGING.  Criar os standby redo logs.  Definir os parâmetros de inicialização no servidor primário e standby.  Configurar a conexão entre os servidores.  Criar um standby físico com o comando DUPLICATE do rman.  Inicializar o serviço de transporte e aplicação dos redo logs. 54
  55. 55. Oracle Data Guard – Implementação & Manutenção Data Guard Broker
  56. 56. Neste Capítulo  Neste capítulo você vai aprender:  Arquitetura.  Conceitos.  Benefícios.  Configurações.  Usar o DGMGRL para gerenciar seu ambiente. 56
  57. 57. Características  O Data Guard Broker:  Framework de gerenciamento distribuído.  Automatiza e centraliza a criação, manutenção e monitoramento dos ambientes com Data Guard.  Todas as operações de gerenciamento, podem ser feitas localmente ou remotamente, com interfaces de fácil utilização:  Oracle Enterprise Manager Grid/Cloud Control  DGMGRL (linha de comando) 57
  58. 58. Componentes  O Data Guard Broker (Componentes):  No lado do cliente:  Oracle Enterprise Manager Grid/Cloud Control.  DGMGRL (linha de comando)  Do lado do servidor:  DMON (processo de background).  Arquivos de configuração. 58
  59. 59. Configurações A configuração mais apropriada para se ter um Data Guard, é ter seus servidores (primários e standby) em localizações geográficas distintas. 59 SP MG ES RJ
  60. 60. Modelo de Gerenciamento 60 Standby A Produção Data Guard Broker Standby B Standby C Standby D
  61. 61. Arquitetura 61
  62. 62. Data Guard Monitor DMON  Processo DMON  Processo de background no lado do servidor.  Presente em todas as instancias do ambiente.  Criado quando usuário inicializa o “Broker”.  Executa requisições e monitoramento dos recursos.  Atualiza arquivos de configuração.  Cria um arquivo de trace drc<SID>.  Modifica parâmetros de inicialização durante processes de “role transactions”. 62
  63. 63. Benefícios  Melhora a alta disponibilidade, proteção de dados, capacidades de recuperação de desastres, herdando as características do Data Guard automatizando as tarefas de configuração e monitoramento.  Automaticamente promove um servidor standby em um servidor primário em caso de desastres.  Fácil configuração de bancos de dados standby adicionais.  Gerenciamento fácil e centralizado.  Comunicação entre os servidores, envolvidos no Data Guard através do protocolo Oracle Net. 63
  64. 64. Comparações 64 Com DG Broker Sem DG Broker Geral Gerenciamento centralizado Instancias gerenciadas individualmente. Criação de um Standby DB Pode se utilizar wizards do OEM 12c Manualmente editando vários arquivos. Configuração e Gerenciamento Unificado através de interface única. Setup individual de cada componente em seu respectivo servidor. Monitoramento Monitoramento continuo. Status e reports automáticos Integrados com o OEM 12c Monitoramento individual nas “v$” de cada servidor envolvido na configuração. Controle Role transactions com um único comando. Vários comando e sequencia coordenada nos servidores envolvidos na configuração.
  65. 65. Interfaces  Linha de comando:  Inicializado com o comando dgmgrl em qualquer computador que tenha um client Oracle instalado.  Permite o gerenciamento e controle das configurações do Data Guard com scripts personalizados.  Oracle Enterprise Manager 11g Grid Control/12c Cloud Control:  Fornece diversos wizards para as atividades de gerenciamento e configuração do Data Guard. 65
  66. 66. Exemplo: Linha de comando 66 DGMGRL> connect sys/oracle_4U@PRIM Connected. DGMGRL> show configuration verbose Configuration Name: DGConfig1 Enabled: YES Protection Mode: MaxAvailability Databases: PRIM - Primary database STBY - Physical standby database Fast-Start Failover: DISABLED Current status for "DGConfig1": SUCCESS
  67. 67. Exemplo: OEM 12c 67
  68. 68. OEM 12c: Overview 68
  69. 69. Vantagens de OEM  Gerenciamento e configuração através de ferramentas gráficas (mais simples e produtivas).  Automatiza e simplifica operações complexas na hora de criar/gerenciar standby databases através de wizards.  Executa todas as configurações de rede necessárias para os processos de “role transaction” e transporte dos arquivos de redo log.  Checagem das operações dos serviços de transporte de redo log, para garantir que estejam com os parâmetros corretos. 69
  70. 70. Resumo  Neste capítulo foi abordado:  Arquitetura.  Conceitos.  Benefícios.  Configurações.  Usar o DGMGRL para gerenciar seu ambiente.  Linha de comando.  OEM 12c. 70
  71. 71. Oracle Data Guard – Implementação & Manutenção Criando o Data Guard Broker
  72. 72. Neste Capítulo  Neste capítulo você vai aprender:  Criar as configurações do Data Guard Broker.  Gerenciar o seu ambiente com o Data Guard Broker. 72
  73. 73. Pré Requisitos  Versão Enterprise.  Single Instance ou Oracle RAC.  Valor do parâmetro COMPATIBLE: 10.2.0.1ou mais (produção e standby).  Arquivos de configuração de rede (tnsnames e listener) precisam existir e serem configurados em ambos servidores.  Atributo GLOBAL_DATABASE_NAME (no listener) deve ter seu valor concatenado com a string “_DGMGRL.seu_dominio” 73
  74. 74. Pré Requisitos  Parâmetro DG_BROKER_START deve estar como TRUE.  Banco de dados primário deve estar em modo archivelog.  Todos os bancos de dados devem estar em modo MOUNT ou OPEN.  DG_BROKER_CONFIG_FILEn: Deve ser configurado em caso de ambientes com Oracle RAC. 74
  75. 75. Pré Requisitos: SPFILE  É obrigatório o uso do SPFILE.  Usando o SPFILE, você consegue garantir que as configurações entre os servidores mantenham-se consistentes.  Com o Data Guard Broker, você pode usar o Enterprise Manager ou o DGMGRL para atualizar parâmetros no SPFILE. 75
  76. 76. Data Guard Monitor Arquivos de configuração:  Os arquivos de configurações são:  Criados automaticamente com um nome e caminho default quando o Data Guard Broker é iniciado.  Gerenciados automaticamente pelo processo DMON.  Os arquivos de configurações são criados e gerenciados em dois locais distintos em cada um dos sites.  dr1<db_unique_name>.dat  dr2<db_unique_name>.dat  Localização default:  Unix: $ORACLE_HOME/dbs  Windows: $ORACLE_HOME/database  Use DG_BROKER_CONFIG_FILEn para sobrescrever a localização default dos arquivos em ambientes Oracle RAC. 76
  77. 77. Arquivos de log  Os arquivos de log do Data Guard Broker, contém as informações escritas pelo processo DMON.  Há um arquivo de log para cada banco de dados envolvido na configuração do Data Guard Broker.  Os arquivos de log, são criados no mesmo diretório que o alert.log da instancia de banco de dados com o nome drc<$ORACLE_SID>.log 77
  78. 78. Criando o Data Guard Broker  Entre no DGMGRL e conecte-se na instancia primária:  Defina as configurações, incluindo um profile para a instancia primária.  Adicione os bancos de dados standby para às configurações.  Habilite as configurações, incluindo os bancos de dados. 78
  79. 79. Criando o Data Guard Broker 79 $ dgmgrl DGMGRL> connect sys/oracle_4U@PRIM DGMGRL> CREATE CONFIGURATION 'DGConfig1' AS > PRIMARY DATABASE IS PRIM > CONNECT IDENTIFIER IS PRIM; Configuration "DGConfig1" created with primary database "PRIM" DGMGRL> DGMGRL> ADD DATABASE STBY AS CONNECT IDENTIFIER IS STBY; Database "STBY" added DGMGRL>
  80. 80. Habilitando a Configuração 80 DGMGRL> ENABLE CONFIGURATION; Enabled. DGMGRL> SHOW CONFIGURATION Configuration Name: DGConfig1 Enabled: YES Protection Mode: MaxPerformance Databases: PRIM - Primary database STBY - Physical standby database Fast-Start Failover: DISABLED Current status for "DGConfig1": SUCCESS
  81. 81. Editando a Configuração  Para alterar algum propriedade:  Para alterar o estado de standby database:  Para alterar o estado de um banco de dados primário: 81 DGMGRL> EDIT DATABASE PRIM SET PROPERTY > LogXptMode='SYNC'; DGMGRL> EDIT DATABASE PRIM SET STATE='APPLY-OFF'; DGMGRL> EDIT DATABASE PRIM SET STATE='TRANSPORT- OFF';
  82. 82. Serviços de Transport de Redo  Especifique as propriedades abaixo para gerenciar o serviço de transporte dos arquivos de redo log.  DGConnectIdentifier  LogXptMode  LogShipping 82
  83. 83. Identificador de Conexão  DGConnectIdentifier:  Especifica o identificador de conexão usado pelo Data Guard Broker para conectar-se ao banco de dados.  É definido quando um banco de dados é adicionado a configuração do Data Guard Broker, ou quando um valor é especificado na clausula CONECT IDENTIFIER CLAUSE (opcional), ou extraído do atributo SERVICE do parametro LOG_ARCHIVE_DEST_n.  Usado nos parametros FAL_CLIENT e FAL_SERVER  Alterando o DGConnectIdentifier, automaticamente altera-se os valores de SERVICE, FAL_CLIENT e FAL_SERVER. 83
  84. 84. Redo Transport (LogXptMode)  O serviço de transporte dos arquivos de redo log deve ser escolhido em conjunto com um modo de proteção.  LogXptMode é usado para definir o serviço de transporte dos arquivos de redo log.  ASYNC  Definie ASYNC e NOAFFIRM nos atributos do parâmetro LOG_ARCHIVE_DEST_n.  Obrigatório para o modo de máxima performance.  SYNC  Definie SYNC e AFFIRM nos atributos do parâmetro LOG_ARCHIVE_DEST_n.  Obrigatório para os modos de máxima proteção e máxima disponibilidade 84
  85. 85. LogXptMode ASYNC 85
  86. 86. LogXptMode SYNC 86
  87. 87. Redo Transport (LogShipping)  LogShipping  Controla se os archivelogs foram enviados ao servidor standby de destino.  Aplicável apenas quando o estado do banco de dados primário está como TRANSPORT-ON. 87
  88. 88. Gerenciamento da Configuração  Desabilitando o gerenciamento do Data Guard Broker:  Desabilitando o gerenciamento de um standby database específico:  Removendo um banco de dados:  Removendo a configuração: 88 DGMGRL> DISABLE CONFIGURATION; DGMGRL> DISABLE DATABASE ‘STBY’; DGMGRL> REMOVE DATABASE ‘STBY’; DGMGRL> REMOVE CONFIGURATION;
  89. 89. Resumo  Neste capítulo foi abordado:  Criar as configurações do Data Guard Broker.  Gerenciar o seu ambiente com o Data Guard Broker. 89
  90. 90. Oracle Data Guard – Implementação & Manutenção Data Guard Lógico
  91. 91. Neste Capítulo  Neste capítulo você vai aprender:  Determinar quando criar um Data Guard Lógico.  Criar um Data Guard Lógico.  Gerenciamento do SQL-Apply. 91
  92. 92. Benefícios  Uso eficiente dos recursos:  Standby aberto, ativo, independente da produção.  Índices e materialized views podem ser criados para melhora da performance.  Reduz o workload da instancia de produção:  Relatórios.  Consultas massivas.  Cálculos e etc. 92
  93. 93. Benefícios  Proteção de dados:  Corrupção na instancia primaria não são propagadas.  DRP (Disater Recovery Plan):  Switchover e Failover.  Minimiza downtimes planejados e não planejados.  Pode ser usado para upgrad do banco de dados e aplicação de patchs. 93
  94. 94. Arquitetura Geral 94
  95. 95. Arquitetura: SQL Apply 95
  96. 96. Preparação  Antes da criação de um Data Guard lógico:  Veja os data types não suportados.  Tenha ciência dos comandos DDLs não suportados.  Garantir a unicidade (PK) dos registros.  Banco de dados primário deve estar em modo archivelog. 96
  97. 97. Objetos não suportados Data Guard lógico, automaticamente exclui objetos não suportados quando aplica o conteúdo dos redo logs no banco de dados standby.  Objetos não suportados:  Tabelas e sequences do usuário SYS.  Tabelas com compressão.  Tabelas usadas em materialized views.  Global temporary tables.  Tabelas com data types não suportados (continua...) 97
  98. 98. Data types não suportados O serviço Log-Apply exclui automaticamente tabelas com data types não suportados, quando está aplicando o conteúdo dos arquivos de redo log.  Data types não suportados:  BFILE, ROWID e UROWID.  Data types definidos pelo usuário.  Data types multimídia (Spatial, Imagem, Oracle Text).  Collectios (VARRAYS e nested-tables).  LOBs  XMLType como objeto relacional.  BINARY XML 98
  99. 99. Tenho tabelas não suportadas? Para saber se seu banco de dados primário possui tabelas não suportadas no processo de Data Guard lógico, execute o select: 99 SQL> SELECT * FROM dba_logstdby_unsupported_table 2 ORDER BY owner; OWNER TABLE_NAME ------------------------------ ------------------------------ IX AQ$_STREAMS_QUEUE_TABLE_T IX AQ$_STREAMS_QUEUE_TABLE_H … OE CUSTOMERS OE WAREHOUSES PM PRINT_MEDIA PM ONLINE_MEDIA SH DIMENSION_EXCEPTIONS 20 rows selected.
  100. 100. Tenho data types não suportados? Para saber se seu banco de dados primário possui tabelas com data types não suportadas no processo de Data Guard lógico, execute o select: 100 SQL> SELECT table_name, column_name, attributes, data_type 2 FROM dba_logstdby_unsupported WHERE owner = 'OE'; TABLE_NAME COLUMN_NAME ATTRIBUTES DATA_TYPE -------------- -------------------- ------------ ---------- CUSTOMERS CUST_ADDRESS OBJECT CUSTOMERS PHONE_NUMBERS VARRAY CUSTOMERS CUST_GEO_LOCATION OBJECT WAREHOUSES WH_GEO_LOCATION OBJECT PURCHASEORDER SYS_NC_ROWINFO$ Object Table OPAQUE CATEGORIES_TAB CATEGORY_NAME Object Table VARCHAR2 CATEGORIES_TAB CATEGORY_DESCRIPTION Object Table VARCHAR2 CATEGORIES_TAB CATEGORY_ID Object Table NUMBER CATEGORIES_TAB PARENT_CATEGORY_ID Object Table NUMBER 9 rows selected.
  101. 101. Comandos proibidos no standby 101 ALTER DATABASE ALTER SESSION ALTER MATERIALIZED VIEW ALTER MATERIALIZED VIEW LOG ALTER SYSTEM CREATE CONTROL FILE CREATE DATABASE CREATE DATABASE LINK CREATE PFILE FROM SPFILE CREATE SCHEMA AUTHORIZATION CREATE MATERIALIZED VIEW CREATE MATERIALIZED VIEW LOG CREATE SPFILE FROM PFILE DROP DATABASE LINK DROP MATERIALIZED VIEW DROP MATERIALIZED VIEW LOG  EXPLAIN  LOCK TABLE  SET CONSTRAINTS  SET ROLE  SET TRANSACTION
  102. 102. Unicidade de registros (PK) Para saber se você tem tabelas sem PK (primary key – chave primária) definidas, você pode consultar a view DBA_LOGSTDBY_NOT_UNIQUE: 102 SQL> SELECT * FROM dba_logstdby_not_unique; OWNER TABLE_NAME BAD_COLUMN ------ -------------------------- ---------- HR EMP_HIST N SCOTT BONUS N SCOTT SALGRADE N SH SUPPLEMENTARY_DEMOGRAPHICS N SH COSTS N SH SALES
  103. 103. RELY Constraint Você pode adicionar uma RELY constraint para identificar as linhas como únicas dentro de uma tabela. 103 SQL> ALTER TABLE hr.employees 2 ADD PRIMARY KEY (employee_id, last_name) 3 RELY DISABLE;
  104. 104. Criando o Data Guard Lógico Para criar um Data Guard Lógico: 1. Crie um standby físico. 2. Pare o processe de redo-apply. 3. Prepare a instancia primaria para fazer parte de um ambiente com standby logico. 4. Crie um processo de LogMiner. 5. Faça a transição para o standby lógico. 6. Abra o standby lógico. 7. Verifique se tudo está executando OK. 104
  105. 105. Criando o Data Guard Lógico Criando o standby físico:  Crie um standby database físico (capitulo 02).  Garanta que seu standby database físico seja o seu servidor primário. 105
  106. 106. Criando o Data Guard Lógico Pare o processo de redo-apply no standby database:  Pelo SQL*Plus:  Ou pelo Data Guard Broker (caso esteja usando): 106 SQL> ALTER DATABASE RECOVER MANAGED STANDBY 2 DATABASE CANCEL; DGMGRL> EDIT DATABASE 'STBY' set state='apply- off'; Succeeded.
  107. 107. Criando o Data Guard Lógico Prepare o banco de dados primário para participar de um ambiente com standby database lógico:  Acerte o parâmetro LOG_ARCHIVE_DEST_n de acordo com um ambiente de Data Guard lógico:  Defina o valor do parâmetro UNDO_RETENTION para 3600. 107 LOG_ARCHIVE_DEST_2= 'LOCATION=<directory> VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME=STBY' LOG_ARCHIVE_DEST_STATE_2=enable
  108. 108. Habilitando o LogMiner  Habilite o processo do LogMiner, para que as entradas nos arquivos de redo log sejam interpretadas no servidor standby.  Automaticamente o processo supplemental logging é habilitado.  Execute este processo no servidor primário. 108 SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
  109. 109. Transição DG Físico / Lógico  Para converter o então Data Guard físico para o modelo lógico, execute o comando:  Execute um shutdown e inicialize a instancia em modo MOUNT.  Ajuste o valor dos parâmetros LOG_ARCHIVE_DEST 109 SQL> ALTER DATABASE RECOVER TO 2 LOGICAL STANDBY db_name;
  110. 110. Abrindo o DG Lógico  Abra a instancia standby com a opção RESETLOGS.  Inicie o processo de aplicação do conteúdo vindo do ambiente primário (produção). 110 SQL> ALTER DATABASE OPEN RESETLOGS; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
  111. 111. Adicionando ao Data Guard Broker  Para adicionar seu standby database lógico à configuração do Data Guar Broker, use o DGMGRL: 111 DGMGRL> ADD DATABASE 'STBY' AS > CONNECT IDENTIFIER IS STBY; Database "STBY" added DGMGRL>
  112. 112. Monitorando  Para checar se seu processo está executando 100% corretamente execute o select:  Para “forçar” o envio de informações do primário para o standby:  Consulte a view DBA_LOGSTDBY_LOG para verificar se os redo logs estão sendo registrados. 112 SQL> SELECT sequence#, first_time, next_time, 2 dict_begin, dict_end 3 FROM dba_logstdby_log ORDER BY sequence#; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
  113. 113. Monitorando  Verificando se os redo logs estão sendo aplicados:  Para ver as atividades em progresso:  Para ver o andamento de todos os processos: 113 SQL> SELECT name, value FROM v$logstdby_stats 2 WHERE name = 'coordinator state'; SQL> SELECT sid, serial#, spid, type, high_scn 2 FROM v$logstdby_process; SQL> SELECT applied_scn, latest_scn 2 FROM v$logstdby_progress;
  114. 114. Protegendo o Standby  Como o standby logico está completamente “aberto” para os usuários, uma boa ideia é protege-lo, para isso use o comando:  ALTER DATABASE GUARD ALL|STANDBY|NONE  ALL: Impede qualquer modificação no standby database.  STANDBY: Impede alteração em dados do standby só.  NONE: Segurança normal (default).  Consulte a coluna GUARD_STATUS da V$DATABASE.  Com o uso do DG Broker, automaticamente usa-se ALL.  Configuração aplicável para todos usuários exceto SYS. 114
  115. 115. Auto-Delete Redo Logs 115 DBMS_LOGSTDBY.APPLY_SET
  116. 116. Auto-Delete Redo Logs  Parâmetro LOG_AUTO_DEL_RETENTION_TARGET:  Numero de minutos que o processo de SQL-Apply vai reter as informações, após aplica-las no standby.  Aplicável somente quando LOG_AUTO_DELETE está definido como TRUE e os archives não estão sendo gerados na fast recovery área.  Valor default é de 1.440 minutos (24 horas). 116
  117. 117. DG Broker Filtros  Use os seguintes parâmetros no DGMGRL para “filtrar” transações:  LsbyASkipCfgPr: Comandos SQL explicitamente especificados serão ignorados.  LsbyASkipErrorCfgPr: Comandos SQL com erros serão ignorados.  LsbyASkipTxnCfgPr: Transações explicitamente especificadas devem ser ignoradas. 117
  118. 118. DG Broker Filtros  Use os seguintes parâmetros no DGMGRL para “deletar” comandos SQL:  LsbyDSkipCfgPr: Comandos SQL explicitamente especificados serão deletados.  LsbyDSkipErrorCfgPr: Comandos SQL com erros explicitamente especificados serão ignorados.  LsbyDSkipTxnCfgPr: Reverte ou deleta ações especificadas em LsbyDSkipCfgPr. 118
  119. 119. Veja suas configurações  Para saber as configurações ativas, consulte a view DBA_LOGSTDBY_SKIP: 119 SQL> SELECT error, statement_opt, name 2 FROM dba_logstdby_skip 3 WHERE owner='HR'; ERROR STATEMENT_OPT NAME ---------- -------------------- ---------- N DML JOBS
  120. 120. Usando DBMS_SCHEDULER  Você pode criar Jobs em seu standby lógico.  Quando um job é criado, ele por padrão ele assumirá LOCAL_ROLE.  Você pode editar o atributo DATABASE_ROLE com a DBMS_SCHEDULER.SET_ATTRIBUTE com os seguintes valores:  PRIMARY: O job executa somente quando a instancia estiver como primária.  LOGICAL STANDBY: O job executa somente quando a instancia está como logical standby. 120
  121. 121. Resumo  Neste capítulo foi abordado:  Determinar quando criar um Data Guard Lógico.  Criar um Data Guard Lógico.  Gerenciamento do SQL-Apply. 121
  122. 122. Oracle Data Guard – Implementação & Manutenção Modos de Proteção
  123. 123. Neste Capítulo  Neste capítulo você vai aprender:  Descrever e entender os modos de proteção.  Alterar os modos de proteção de sua configuração. 123
  124. 124. Modo: Proteção x Transporte  Cada modo de proteção requer um modo de transporte específico.  Um modo de transporte por si só, não define um modo de proteção. 124
  125. 125. Modo: Proteção dos Dados  Há três modos de proteção de dados:  Máxima Proteção.  Máxima Disponibilidade.  Máxima Performance.  Estes modos lhe ajudam a equilibrar seu ambiente no aspecto da disponibilidade x performance. 125
  126. 126. Máxima Proteção  Garante “zero” perda de dados caso alguma falha ocorra no banco de dados primário, na rede ou no banco de dados standby.  O banco de dados primário é desligado caso haja alguma falha que gere perda de sincronismo com o banco de dados standby.  Os dados de redo devem ser escritos nos arquivos de redo log local e nos standby redo logs obrigatoriamente.  Obrigatório: Um standby database com os valores SYNC e AFFIRM nos atributos de transporte dos arquivos de redo log. 126
  127. 127. Máxima Disponibilidade  Garante “zero” perda de dados, sem comprometer a disponibilidade do banco de dados primário.  Os dados de redo devem ser escritos nos arquivos de redo log local e nos standby redo logs obrigatoriamente.  O banco de dados primário, não será desligado enquanto houver pelo menos um standby redo log sincronizado.  Se houver perda de sincronia entre os bancos de dados, o banco de dados standby continua a operar até que tudo de restabeleça.  Obrigatório: Um standby database com os valores SYNC e AFFIRM nos atributos de transporte dos arquivos de redo log. 127
  128. 128. Máxima Performance  Modo default de proteção.  Oferece maior nível de proteção possível sem afetar a performance.  Transações que recebem commit, são rapidamente escritas no redo log local.  Redo logs são enviados ao banco de dados standby de maneira assíncrona.  Obrigatório: Obrigatório: Um standby database com os valores ASYNC e NOAFFIRM nos atributos de transporte dos arquivos de redo log. 128
  129. 129. Comparando 129 Modo Risco de Perda Transporte Se nenhuma confirmação é recebida. Máxima Proteção Zero de Perda Proteção dupla SYNC DB Primário é desligado Máxima Disponibilidade Zero de Perda SYNC Aguarda até o re-sincronismo Máxima Performance Perda mínima ASYNC Nunca aguarda um feedback do DB primários
  130. 130. Configuração DGMGRL  Configure os standby redo logs.  Configure LogXptMode (se preciso).  Máxima proteção: SYNC  Máxima Disponibilidade: SYNC  Máxima Performance: ASYNC  Defina o modo de proteção: 130 DGMGRL> EDIT DATABASE 'STBY' SET PROPERTY LogXptMode'='SYNC'; Property "LogXptMode" updated DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Succeeded.
  131. 131. Resumo  Neste capítulo foi abordado:  Descrever e entender os modos de proteção.  Alterar os modos de proteção da sua configuração. 131
  132. 132. Oracle Data Guard – Implementação & Manutenção Monitoramento Do Data Guard
  133. 133. Neste Capítulo  Neste capítulo você vai aprender:  Usar o OEM Cloud Control para monitoramento.  Usar o DGMGRL para monitoramento e status. 133
  134. 134. Enterprise Manager  Através da pagina de monitoramento você pode:  Gráfico de transporte e aplicação dos arquivos de redo log.  Informações adicionais de configuração e performance:  Informações a respeito dos archivelogs aplicados e o progresso do standby database.  Informações a respeito dos redo logs do banco de dados primário.  Verificação da performance. 134
  135. 135. Enterprise Manager 135
  136. 136. Enterprise Manager  Métricas e Alertas:  Métricas: Unidades de medidas para chegar a saúde do banco de dados.  Thresholds: Limites de valores para as métricas.  Alerta: Indicação de que um threshold foi excedido. 136
  137. 137. Enterprise Manager 137
  138. 138. Enterprise Manager 138
  139. 139. DGMGRL Diagnóstico  As informações do DG Broker são guardadas:  Alert.log das instancias.  Data Guard Broker log files.  Status e informações são coletadas com o comando SHOW DATABASE.  Você pode usar as propriedades:  StatusReport  LogXptStatus  InconsistentProperties  InconsistentLogXptProps 139 DGMGRL> SHOW DATABASE 'STBY' 'StatusReport';
  140. 140. DGMGRL Diagnóstico  Verificando o status da configuração:  Verificando o status de um banco de dados.  Verificando o status do monitoramento.  Com o comando SHOW DATABASE você pode adicionar qualquer propriedade para consulta-la exclusivamente. 140 DGMGRL> SHOW CONFIGURATION; DGMGRL> SHOW DATABASE 'PRIM'; DGMGRL> SHOW DATABASE 'PRIM' 'StatusReport';
  141. 141. DGMGRL Diagnóstico  Comando SHOW CONFIGURATION:  Fornece um resumo das configuração de seu ambiente: 141 DGMGRL> show configuration Configuration Name: DGConfig1 Enabled: YES Protection Mode: MaxPerformance Databases: PRIM - Primary database STBY - Physical standby database STBY2 - Physical standby database Fast-Start Failover: DISABLED Current status for "DGConfig1": SUCCESS
  142. 142. DGMGRL Diagnóstico  Comando SHOW DATABASE:  Fornece um resumo das configuração de um banco de dados em especifico:: 142 DGMGRL> show database STBY Database Name: STBY OEM Name: STBY.oradata.com Role: PHYSICAL STANDBY Enabled: YES Intended State: APPLY-ON Instance(s): STBY Current status for “STBY": SUCCESS
  143. 143. DGMGRL Diagnóstico  Comando SHOW DATABASE VERBOSE:  Fornece informações completas (todas propriedades) de um banco de dados: 143 DGMGRL> show database verbose STBY Database Name: STBY OEM Name: STBY.oradata.com Role: PHYSICAL STANDBY Enabled: YES Intended State: APPLY-ON Instance(s): pc00sby1 Properties: DGConnectIdentifier = 'STBY' ObserverConnectIdentifier = '' LogXptMode = 'ASYNC' …
  144. 144. SQL*Plus Diagnóstico  Informações sobre os arquivos de redo log. 144 SQL> SELECT group#, status, member 2 FROM v$logfile 3 WHERE type = 'STANDBY'; GROUP# STATUS MEMBER ------ ------ ------------------------------------------ 4 /u01/app/oracle/oradata/STBY/srl01.log 5 /u01/app/oracle/oradata/STBY/srl02.log 6 /u01/app/oracle/oradata/STBY/srl03.log 7 /u01/app/oracle/oradata/STBY/srl04.log
  145. 145. SQL*Plus Diagnóstico  Informações sobre os standby redo log. 145 SQL> SELECT group#, dbid, archived, status 2 FROM v$standby_log; GROUP# DBID ARC STATUS ---------- -------------- --- ---------- 4 UNASSIGNED NO UNASSIGNED 5 3303427449 YES ACTIVE 6 UNASSIGNED YES UNASSIGNED 7 UNASSIGNED YES UNASSIGNED
  146. 146. SQL*Plus Diagnóstico  Identificando o destino dos arquivos de redo log. 146 SQL> SELECT dest_id,valid_type,valid_role,valid_now 2 FROM v$archive_dest; DEST_ID VALID_TYPE VALID_ROLE VALID_NOW ------- --------------- ------------ -------------- 1 ALL_LOGFILES ALL_ROLES YES 2 STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE 3 ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE 4 ALL_LOGFILES ALL_ROLES UNKNOWN 5 ALL_LOGFILES ALL_ROLES UNKNOWN 6 ALL_LOGFILES ALL_ROLES UNKNOWN 7 ALL_LOGFILES ALL_ROLES UNKNOWN 8 ALL_LOGFILES ALL_ROLES UNKNOWN 9 ALL_LOGFILES ALL_ROLES UNKNOWN 10 ALL_LOGFILES ALL_ROLES UNKNOWN 11 ALL_LOGFILES ALL_ROLES YES 11 rows selected.
  147. 147. Parâmetro LOG_ARCHIVE_TRACE  Opcional, utilizado para questões de tuning.  Defina este parâmetro para um valor inteiro para ver o progresso da geração dos archivelogs dentro do seu sistema.  No banco de dados primário, será gerado um arquivo de trace contendo as informações de todos os arquivos enviados ao banco de dados standby.  No Banco de dados standby, um arquivo de trace de todos arquivos vindos do banco de dados primário.  Os arquivos são escritos no diretório do ADR, para ver o caminho consulte no spfile o parâmetro DIAGNOSTIC_DEST. 147
  148. 148. SQL*Plus Diagnóstico  Monitorando o processo de aplicação dos arquivos de redo log no banco de dados standby. 148 SQL> SELECT process, status, group#, thread#, sequence# 2 FROM v$managed_standby 3 order by process, group#, thread#, sequence#; PROCESS STATUS GROUP# THREAD# SEQUENCE# --------- ------------ ---------- ---------- ---------- ARCH CLOSING 4 1 142 ARCH CLOSING 4 1 146 ARCH CLOSING 4 1 148 ARCH CLOSING 5 1 141 ARCH CLOSING 5 1 147 MRP0 APPLYING_LOG N/A 1 149 RFS IDLE 2 1 149 RFS IDLE N/A 0 0 RFS IDLE N/A 0 0
  149. 149. SQL*Plus Diagnóstico  Verificando a diferença de tempo (quanto a aplicação dos arquivos de redo) entre as instancias. 149 SQL> SELECT name, value, time_computed 2 FROM v$dataguard_stats; NAME VALUE TIME_COMPUTED ------------------------- --------------- -------------- apply finish time +00 00:00:00.0 13-FEB-2008 02:44:21 apply lag +00 00:00:00 13-FEB-2008 02:44:21 estimated startup time 12 13-FEB-2008 02:44:21 standby has been open N 13-FEB-2008 02:44:21 transport lag +00 00:00:00 13-FEB-2008 02:44:21
  150. 150. SQL*Plus Diagnóstico  Verificando o log das operações realizadas pelo processo de Data Guard. 150 SQL> SELECT timestamp, facility, dest_id, message_num, 2 error_code, message 3 FROM v$dataguard_status 4 ORDER by timestamp; TIMESTAMP FACILITY DEST_ID MESSAGE_NUM ERROR_CODE --------- --------------- ------- ----------- ---------- MESSAGE -------------------------------------------------------- 13-FEB-08 Log Apply Servi 0 562 0 Media Recovery Waiting for thread 1 sequence 151 13-FEB-08 Remote File Ser 0 563 0 Primary database is in MAXIMUM AVAILABILITY mode 13-FEB-08 Remote File Ser 0 564 0 Standby controlfile consistent with primary 13-FEB-08 Remote File Ser 0 565 0 RFS[25]: Successfully opened standby log 5: '/u01/app/oracle/oradata/pc00sby1/srl02.log'
  151. 151. SQL*Plus Diagnóstico  Verificando informações de todas as transações ativas que estão aplicando instrução SQL no banco de dados standby.: 151 SQL> SELECT primary_xid, type, 2 mining_status, apply_status 3 FROM v$logstdby_transaction;
  152. 152. Resumo  Neste capítulo foi abordado:  Usar o OEM Cloud Control para monitoramento  Usar o DGMGRL para monitoramento e status. 152
  153. 153. Oracle Data Guard – Implementação & Manutenção Otimizando o Data Guard
  154. 154. Neste Capítulo  Neste capítulo você vai aprender:  Monitorar a performance do Data Guard.  Otimizar o transporte para melhor performance.  Otimizar a aplicação dos SQL. 154
  155. 155. Performance via OEM  Você pode monitorar a performance de seu ambiente via Enterprise Manager. 155
  156. 156. Otimizando a Performance  Para otimizar o processo de transporte dos arquivos de redo log, use as técnicas:  Transporte assíncrono com múltiplos processos de archive (parâmetro LOG_ARCHIVE_MAX_PROCESSES).  Compactando os arquivos de redo log. 156
  157. 157. Otimizando a Performance  Propriedade ReopenSecs:  Numero em segundos que o processo de archive aguarda antes de tentar acessar um destino que houve falha.  DG Broker 300 (Default).  Defina essa propriedade no Standby Database.  Também pode ser alterada no parâmetro LOG_ARCHIVE_DEST_n através do atributo REOPEN. Ou no DG Broker: 157 DGMGRL> EDIT DATABASE 'STBY' SET PROPERTY 'ReopenSecs'=600;
  158. 158. Otimizando a Performance  Propriedade NetTimeout:  Numero em segundos que o processo de log writer (LGWR) aguarda a resposta para escrever um arquivo.  DG Broker 30 (Default).  Também pode ser alterada como atributo NET_TIMEOUT no parâmetro LOG_ARCHIVE_DEST_n no banco de dados primário. 158 DGMGRL> EDIT DATABASE 'PRIM' SET PROPERTY 'NetTimeout'=20;
  159. 159. Otimizando a Performance 159 MaxConnections
  160. 160. Otimizando a Performance  Propriedade MaxConnections:  Numero de processos ARCn, que são usados para transmitir dados de um arquivo de redo log para o site remoto quando há um GAP no processo.  Broker Default: 1  Também pode ser alterada através do SPFILE no atributo MAX_CONNECTIONS no parâmetro LOG_ARCHIVE_DEST_n no banco de dados primário. 160 DGMGRL> EDIT DATABASE 'PRIM' SET PROPERTY 'MaxConnections'=5;
  161. 161. Otimizando a Performance  Propriedade RedoCompression:  Habilita a compressão dos archived redo logs, durante um processo de transmissão para resolução de algum GAP de arquivo.  Pode ser definida na propriedade COMPRESSION do parâmetro LOG_ARCHIVE_DEST_n, dentro do SPFILE.  Você pode ver se a compressão está habilitada NA view V$ARCHIVE_DEST coluna COMPRESSION. 161 DGMGRL> EDIT DATABASE 'STBY' SET PROPERTY 'RedoCompression'='ENABLE';
  162. 162. Otimizando a Performance  Delay (atraso intencional) na aplicação dos redos:  Pode ajudar a previnir:  Corrupção de dados.  Erros humanos. 162 PRIM STBY
  163. 163. Otimizando a Performance  Propriedade DelayMins:  Especifica em minutos, o tempo que um standby redo log deve aguardar antes de ser aplicado.  Broker Default: 0 (enviou aplicou).  Pode ser alterada no atributo DELAY no parâmetro do SPFILE chamado LOG_ARCHIVE_DEST_n (no banco de dados primário). 163 DGMGRL> EDIT DATABASE 'PRIM' SET PROPERTY 'DelayMins'=5;
  164. 164. Otimizando a Performance  Aplicação dos SQL.  O numero de processos pode ser ajustado como  APPLIER  PREPRARER  Modifique esses parâmetros para controlar o numero de processos que aplicam SQL.  APLLY_SERVERS: Numero de processos APPLIER.  PREPARE_SERVERS: Numero de processos PREPARER.  Para alterar esses parâmetro use a package DBMS_LOGSTDBY. 164
  165. 165. Otimizando a Performance Aplicação dos SQL (Ajustando APPLIERS).  Veja se o numero de appliers é maior que o throughoput.  Determine se os appliers estão ocupados.  Determine se há trabalho para mais appliers.  Ajuste o parâmetro MAX_SERVERS (se preciso).  Ajuste o parâmetro APPLY_SERVERS para aumentar o numero de processos appliers. 165 SQL> SELECT COUNT(*) AS IDLE_APPLIER 2 FROM V$LOGSTDBY_PROCESS 3 WHERE TYPE = 'APPLIER' and status_code = 16166; SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS 2 WHERE NAME LIKE 'transactions%';
  166. 166. Otimizando a Performance Aplicação dos SQL (Ajustando PREPARER).  Veja se o numero de preparers é o correto.  Veja se todos os preparers estão ocupados.  Determine se o numero de transações prontas para serem aplicadas é menor do que o numero de preparers disponíveis. 166 SQL> SELECT COUNT(*) AS IDLE_PREPARER 2 FROM V$LOGSTDBY_PROCESS 3 WHERE TYPE = 'PREPARER' and status_code = 16166; SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS 2 WHERE NAME LIKE 'transactions%'; SQL> SELECT COUNT(*) AS APPLIER_COUNT 2 FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';
  167. 167. Otimizando a Performance Aplicação dos SQL (Ajustando PREPARER).  Veja se há processos APPLIER como idle.  Ajuste o parâmetro MAX_SERVERS (se preciso).  Ajuste o parâmetro PREPARE_SERVERS para aumentar o numero de PREPARERS. 167 SQL> SELECT COUNT(*) AS IDLE_APPLIER 2 FROM V$LOGSTDBY_PROCESS 3 WHERE TYPE = 'APPLIER' and status_code = 16166;
  168. 168. Resumo  Neste capítulo foi abordado:  Monitorar a performance do Data Guard.  Otimizar o transporte para melhor performance.  Otimizar a aplicação dos SQL. 168
  169. 169. Oracle Data Guard – Implementação & Manutenção Flashback
  170. 170. Neste Capítulo  Neste capítulo você vai aprender:  Vantagens de Flashback com Data Guard.  Configurar o Flashback Database. 170
  171. 171. Flashback & Data Guard  Com Flashback você tem:  Uma alternativa para restaurar a instancia primaria.  Uma alternativa para um reinstate da instancia primária, no caso de um failover.  Uma alternativa de retardar a aplicação de um redo que contenha possíveis erros lógicos (de aplicação).  Flashback Database deve ser configurado usando:  Fast-Start-Failover  Snapshot Standby  Flashback Database é recomendado com o uso do DG Broker, porque ele automaticamente habilita “real-time apply”. 171
  172. 172. Flashback Database  Overview:  É como se fosse o CTRL+Z (desfaz tudo que foi feito).  Pode ser usado apenas em caso de falhas lógicas. 172
  173. 173. Flashback Database  Configuração (requisitos):  Instancia em modo archivelo.  FRA configurada.  Configuração (algoritmo):  Shutdown da instancia.  Startup em modo mount.  Definir Flashback Retention Target.  Habilitar o Flashback Database.  Abrir a instancia. 173
  174. 174. Flashback Database OEM 174
  175. 175. Flashback Database 175 RFS Standby redo log MRP ARC0 Archived redo logs PRIM STBY
  176. 176. Flashback Database 176 Redo Redo DB Primário DB Primário DB Standby DB Standby RESETLOGS Depois de um PIT Flashback
  177. 177. Flashback Database e Role Transitions  Use Flashback para recuperar a instancia para um momento antes de um switchover ou failover.  As instancias (primária e standby) mantém seus papeis quando um flashback é executado (standby físico).  É possível haver “role transitions” quando se executa um flashback em standby lógico.  Flashback database pode ser usado para reverter uma ativação indevida de um banco de dados. 177
  178. 178. Flashback Database Após um Failover178 Redo Redo DB Primário Novo DB Standby DB Standby Novo DB Primário Flashback Failover
  179. 179. Resumo  Neste capítulo foi abordado:  Vantagens de Flashback com Data Guard.  Configurar o Flashback Database. 179
  180. 180. Oracle Data Guard – Implementação & Manutenção Role Transition
  181. 181. Neste Capítulo  Neste capítulo você vai aprender:  Explicar as duas roles possíveis em um Data Guard.  Executar um switchover.  Executar um Failover. 181
  182. 182. Gerenciamento de papeis  Em um ambiente com Data Guard, é possivel se trabalhar com dois papeis (roles).  Primary Role (Produção).  Standby Role (Standby).  Com o gerenciamento de papeis, você pode inverter estas posição de maneia automática. 182
  183. 183. Switchover & Failover  Switchover:  Planejado.  Manutenção de hardware ou sistema operacional.  Manualmente executado.  Failover:  Não Planejado.  Usado emergencialmente.  Mínima ou zero perda de dados (depende do modo de proteção).  Fast-Start Failover pode ser habilitado para acontecer automaticamente. 183
  184. 184. Switchover  Troca de papel entre os servidores (primário vira standby e o standby vira primário).  Não é preciso usar OPEN RESETLOGS.  Não há perda de dados. 184
  185. 185. Switchover (Antes) 185 Leitura / Escrita Transações São Paulo Somente Leitura Relatórios Belo Horizonte Banco de Dados De Produção Banco de Dados Standby
  186. 186. Switchover (Depois) 186 Somente Leitura Relatórios São Paulo Leitura / Escrita Transações Belo Horizonte Banco de Dados De Standby Banco de Dados Produção
  187. 187. Switchover - Preparo  Para executar um switchover confira:  Há conectividade entre os servidores?  O estados das instancias TRANSPORT-ON e APPLY-ON.  As propriedades do banco de dados standby devem estar definidas no banco de dados primário.  O banco de dados, possui standby redo logs?  LogXptMode deve estar como SYNC e operante em máxima disponibilidade ou máxima proteção. 187
  188. 188. Switchover - DGMGRL  Se tudo estiver correto, execute o SWITCHOVER. 188 DGMGRL> SWITCHOVER TO 'STBY'; Performing switchover NOW, please wait... New primary database "STBY" is opening... Operation requires shutdown of instance "PRIM" on database "PRIM" Shutting down instance "PRIM"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "PRIM" on database "PRIM" Starting instance "PRIM"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "STBY"
  189. 189. Switchover – DG Lógico  Quando seu standby for lógico:  As operações deste processo não executam shutdown na instancia primária.  Não é preciso derrubar as sessões dos usuários, mas é recomendado.  O standby lógico, pode não ter todas as informações.  Invalida e desabilita todas as configurações de standby físicos e snapshot. 189
  190. 190. Switchover - Restrições  Você não pode fazer um switchover quando:  Não houver archivelogs disponíveis.  Point in Time recovery (PIT) é necessário.  O banco de dados de produção (primário) não pode ser aberto. 190
  191. 191. Failover 191 São Paulo Leitura / Escrita Transações Belo Horizonte Banco de Dados De Produção Banco de Dados Standby se torna Produção Redo log local Archivelog log local Leitura / Escrita Transações
  192. 192. Tipos de Failover  Manual (Feito pelo DBA).  Completo: Tenta aplicar todos os redo logs para minimizar a perda de dados.  Imediato: Nenhum passo adicional é executado.  Fast-Start Failover: Executado automaticamente pelo Data Guard Broker. 192
  193. 193. Failover - Considerações  O antigo banco de dados primário, não faz mais parte da configuração.  É possível haver perda de dados.  Deve ser usado apenas em casos de emergências.  Ao executar um failover você deve:  Escolher um standby físico quando possível.  Escolher o standby database mais atualizado. 193
  194. 194. Failover Manual DGMGRL  Execute o comando FAILOVER para executar a operação:  Redefina o modo de proteção (se preciso).  Reinstate o banco de dados primário como standby.  Redefina ou recrie outro standby database. 194 DGMGRL> FAILOVER TO 'STBY' [IMMEDIATE];
  195. 195. Reabilitando a Instancia Primária DGMGRL  Bancos de dados que era primários, precisam ser recriados esse processo chama-se “reinstate”  No DGMGRL use o comando REINSTATE DATABASE.  Se você não puder executar um reinstate de seu banco de dados, deve recriá-lo a partir de uma copia do banco de dados atual. E então reabilitar dentro do DGMGRL. 195 DGMGRL> REINSTATE DATABASE PRIM; DGMGRL> ENABLE DATABASE PRIM;
  196. 196. Resumo  Neste capítulo foi abordado:  Explicar as duas roles possíveis em um Data Guard.  Executar um switchover.  Perform a failover. 196
  197. 197. Oracle Data Guard – Implementação & Manutenção Fast Start Failover
  198. 198. Neste Capítulo  Neste capítulo você vai aprender:  Configurar o Fast Start Failover.  Ver as configurações do Fast Start Failover.  Gerenciar o Observer.  Role transition com Fast Start Failover.  Manual Reisntate do banco de dados primário. 198
  199. 199. Fast Start Failover 199 Banco de dados de produção Banco de dados Standby Observer
  200. 200. Fast Start Failover Quando não acontece?200 Banco de dados de produção Banco de dados Standby Observer > Threshold Fast Start Failover
  201. 201. Instalação Observer  Ferramenta cliente que fica monitorando a disponibilidade da instancia primária.  Deve ser instalado em um servidor que não seja parte do Data Guard.  Gerenciado pelo OEM e pelo DGMGRL. 201
  202. 202. FSFO – Pre requisitos  Configuração em máxima disponibilidade ou máxima performance.  Propriedade LogXptMode:  SYNC: em máxima disponibilidade  ASYN: em máxima performance  Flashback database nas instancias primária e standby.  TNSNAMES.ora no servidor do observer.  Entrada estática no listener, para que o observer possa rematamente reiniciar os serviços. 202
  203. 203. Configurações.  Especifique o standby database “target”.  Defina o modo de proteção.  Defina a propriedade FastStartFailoverThreshold.  Defina as propriedades adicionais.  Defina as condições para o Fast Start Failover.  Habilite o Fast Start Failover.  Inicie o Fast Start Failover.  Verifique as configurações. 203
  204. 204. Target Standby Database 204 Banco de dados de produção PRIM Banco de dados Standby STBY DGMGRL> EDIT DATABASE PRIM 2 SET PROPERTY FastStartFailoverTarget = STBY; DGMGRL> EDIT DATABASE STBY 2 SET PROPERTY FastStartFailoverTarget = PRIM;
  205. 205. Modo de Proteção 205 DGMGRL> EDIT DATABASE PRIM SET PROPERTY > LogXptMode=SYNC; DGMGRL> EDIT DATABASE STBY SET PROPERTY > LogXptMode=SYNC; DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS > MaxAvailability; DGMGRL> EDIT DATABASE PRIM SET PROPERTY > LogXptMode=ASYNC; DGMGRL> EDIT DATABASE STBY SET PROPERTY > LogXptMode=ASYNC; DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS > MaxPerformance;
  206. 206. Fast Start Failover - Threshold 206 EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = threshold-val; Banco de dados Standby PRIM
  207. 207. Propriedades Adicionais  FastStartFailoverLagLimit: Estabelece um tempo limite para que o banco de dados standby aplique os redo logs vindos do banco de produção.  FastStartFailoverPmyShutdown: Informa se o servidor primário será desligado, caso haja algum gap no envio dos arquivos de redo log, ou se houver perda de conectividade com o observer.  FastStartFailoverAutoReinstate: Informe se o antigo banco de dados primário vai sofrer o processo de reinstate caso um failover automático aconteça. 207
  208. 208. Lag Time Limit  O propriedade FastStartFailoverLagLimit configura um tempo máximo de tolerância para atraso no recebimento dos arquivos de redo log, no modo de máxima performance.  Destinos que recebem os arquivos de redo no modo ASYNC são aceitáveis para fast start failover.  É necessário estar usano real-time-apply. 208 DGMGRL> EDIT CONFIGURATION > SET PROPERTY FastStartFailoverLagLimit = {n};
  209. 209. Shutdown Automático  Você pode definir se o servidor primário vai sofrer um shutdown automático, caso a geração de redo pare ou atrase, ou haja perda de conectividade com o observer, além do período definido no threshold.  Acerte o valor para TRUE. 209 DGMGRL> EDIT CONFIGURATION SET PROPERTY > FastStartFailoverPmyShutdown = {TRUE|FALSE};
  210. 210. Reinstate Automático  Você pode definir se o servidor primário vai sofrer um reinstate automático, haja um failover automático por falta de comunicação com o observer, ou com o banco de dados standby.  Acerte o valor para TRUE. 210 DGMGRL> EDIT CONFIGURATION SET PROPERTY > FastStartFailoverAutoReinstate = {TRUE | FALSE};
  211. 211. Identificador de Conexão  Você pode definir um identificador de conexão para especificar como o observer deve se conectar e monitorar um standby database.  Habilitando essa propriedade, o observer usa para controlar o envio dos arquivos de redo log.  Por default ele assume o valor da propriedade já definida antes DGCOnnectIdentifier. 211 DGMGRL> EDIT DATABASE PRIM > SET PROPERTY ObserverConnectIdentifier = 'PRIM';
  212. 212. Condições de Failover  Dentro do DG Broker você pode usar propriedade ENABLE/DISABLE FAST_START_FAILOVER.  O observer iniciar o processe de monitoramento para fast start failover automaticamente.  Condições configuráveis:  Situações apontadas pelo health check.  Erros lançados pelo próprio servidor.  Use o comando SHOW FAST_START_FAILOVER para ver a lista de condições habilitadas. 212 ENABLE FAST_START FAILOVER CONDITION "value";
  213. 213. Condições de Failover  Condições adicionais para o FSFO.  Valores default: Datafile Offline, Corrupted Controlfile e Corrupted Dictionary. 213 Condição Descrição Datafile Offline Datafile off-line por erro de escrita. Corrupted Controlfile Controlfile corrompido Corrupted Dictionary Corrupção lógica de objeto importante do dicionário de dados. Inaccessible Logfile LGWR não consegue escrever devido a erros de I/O Stuck Archiver Impossibilidade de gerar archivelogs ORA-00257
  214. 214. Fast Start Failover – Enable 214 DGMGRL> ENABLE FAST_START FAILOVER; Banco de dados de produção Banco de dados Standby
  215. 215. Start Observer 215 DGMGRL> START OBSERVER; Banco de dados de produção Banco de dados Standby
  216. 216. Checando a Configuração 216 DGMGRL> show configuration verbose Configuration Name: DGConfig1 Enabled: YES Protection Mode: MaxPerformance Databases: PRIM - Primary database STBY - Physical standby database - Fast-Start Failover target Fast-Start Failover: ENABLED Threshold: 90 seconds Target: STBY Observer: ordt-srv-001 Lag Limit: 60 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Current status for "DGConfig1": SUCCESS
  217. 217. Checando a Configuração 217 DGMGRL> show fast_start failover; Fast-Start Failover: ENABLED Threshold: 90 seconds Target: STBY Observer: ordt-srv-001 Lag Limit: 60 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile NO Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: (none)
  218. 218. FSFO - Aplicação 218 PRIM Observer STBY DBMS_DG.INITIATE_FS_FAILOVER
  219. 219. FSFO - Aplicação  A package DBMS_DG, contém uma procedure de nome INITIATE_FS_FAILOVER, que pode ser utilizada para executar um failover diretamente pela aplicação.  Para que a aplicação possa usar desta característica, o usuário deve ter direitos de execução nesta package. 219 FUNCTION dbms_dg.initiate_fs_failover (condstr IN VARCHAR2) RETURN BINARY_INTEGER;
  220. 220. Checando a Configuração 220 SELECT fs_failover_status as STATUS, fs_failover_current_target as CURR_TGET, fs_failover_threshold as THRESHOLD, fs_failover_observer_present as OBS_PRES, fs_failover_observer_host as OBS_HOST FROM v$database; STATUS CURR_TGET THRESHOLD OBS_PRES ---------------------- --------- --------- -------- TARGET UNDER LAG LIMIT STBY 90 YES OBS_HOST ----------------------- Ordt-srv-001
  221. 221. Porque houve um FSFO?  Quando houver um failover e você quiser/precisar descobrir a razão, execute a query abaixo: 221 SQL> SELECT last_failover_time, last_failover_reason 2 FROM v$fs_failover_stats; LAST_FAILOVER_TIME LAST_FAILOVER_REASON -------------------- ------------------------------ 02/14/2008 22:30:12 Primary Disconnected
  222. 222. Operações Proibidas  Após habilitar o FSFO, algumas operações que podem danificar o funcionamento do ambiente se tornam proibidas, como:  Alterar a configuração para máxima proteção.  Alterar a propriedade LogXptMode.  Desabilitar a configuração do DG Broker.  Desabilitar/Remover um standby database que faça parte do FSFO.  Fazer um failover ou switchover para um servidor fora da configuração do FSFO. 222
  223. 223. Fast Start Failover – Disable 223 DGMGRL> DISABLE FAST_START FAILOVER [FORCE]; Banco de dados de produção Banco de dados Standby
  224. 224. Desabilitando Condições  Ao utilizar o FSFO, você pode (se for o caso) desabilitar algumas condições que disparam o processo. Exemplo: 224 DGMGRL> DISABLE FAST_START FAILOVER CONDITION value;
  225. 225. Opção FORCE  A opção FORCE, pode ser utilizada em algumas situações especificas como:  O ambiente está sincronizado e perde conectividade com o observer e o standby database.  Prevenir que um FSFO aconteça, explicitamente.  Um failover manual, quando o FSFO está fora de sincronia. 225
  226. 226. Parando o Observer 226 DGMGRL> STOP OBSERVER; Banco de dados de produção Banco de dados Standby
  227. 227. Manual Reinstate 227 DGMGRL> REINSTATE DATABASE PRIM; Banco de dados de produção Banco de dados Standby
  228. 228. Observer em novo host  Se precisar você pode mover seu observer para um novo host, para isso execute:  Executar o comando STOP OBSERVER, para romper a comunicação entre ele e os servidores de produção e standby.  Com o comando SHOW CONFIGURATION VERBOSE. Veja se a configuração aceitou o stop.  Inicie o observer em outro host. 228
  229. 229. Resumo  Neste capítulo foi abordado:  Configurar o Fast Start Failover.  Ver as configurações do Fast Start Failover.  Gerenciar o Observer.  Role transition com Fast Start Failover.  Manual Reisntate do banco de dados primário. 229
  230. 230. Oracle Data Guard – Implementação & Manutenção Snapshot Standby Database
  231. 231. Neste Capítulo  Neste capítulo você vai aprender:  Criar um snapshot standby database a partir de um standby database físico.  Converter um snapshot standby database de volta para um standby database físico. 231
  232. 232. Overview  Um snapshot standby database, é um banco de dados que pode ser completamente alterado após a sua criação, e depois ser convertido em um standby físico novamente.  Durante o período de snapshot standby, o archives são recebidos mas não aplicados.  Quando um standby físico é convertido para snapshot, implicitamente é criado um restore point e o Flashback Database é habilitado. 232
  233. 233. Arquitetura 233
  234. 234. Conversão Físico > Snapshot  Para criar um snapshot standby, primeiro crie um standby físico e na sequencia o converta para um standby lógico: 234 DGMGRL> CONVERT DATABASE STBY >TO SNAPSHOT STANDBY; Converting database "STBY" to a Snapshot Standby database, please wait... Database "STBY" converted successfully
  235. 235. Atenção  Potencial perda de dados com archivelogs corrompidos.  Longo tempo de conversão de um snapshot standby database para um banco de dados primário caso haja falhas no banco de dados primário original. 235
  236. 236. Restrições  Um snapshot standby database não pode ser:  O único standby database no modo de máxima proteção.  O “target” (alvo) no caso de um switchover.  O “target” (alvo) no caso de um fast start failover. 236
  237. 237. Consultando SQL*Plus  Para saber qual “role” se encontra seu servidor, você pode executar o select: 237 SQL> SELECT database_role FROM v$database; DATABASE_ROLE ---------------- SNAPSHOT STANDBY
  238. 238. Consultando DGMGRL  Para ver as informações de seu snapshot standby database pelo DGMGRL execute o comando SHOW CONFIGURATION VERBOSE: 238 DGMGRL> show configuration Configuration Name: DGConfig Enabled: YES Protection Mode: MaxPerformance Databases: PRIM - Primary database STBY - Snapshot standby database Fast-Start Failover: DISABLED Current status for "DGConfig": SUCCESS
  239. 239. Consultando DGMGRL  Para informações especificas de seu banco de dados, use SHOW DATABASE [NOME DO BANCO] 239 DGMGRL> show database pc00sby1 Database Name: pc00sby1 Role: SNAPSHOT STANDBY Enabled: YES Intended State: APPLY-OFF Instance(s): pdb1 Current status for "pc00sby1": SUCCESS
  240. 240. Voltando para Standby Físico  Para transformar seu standby snapshot de volta em um standby físico, execute o comando: 240 DGMGRL> CONVERT DATABASE STBY TO PHYSICAL STANDBY;
  241. 241. Resumo  Neste capítulo foi abordado:  Criar um snapshot standby database a partir de um standby database físico.  Converter um snapshot standby database de volta para um standby database físico. 241
  242. 242. Oracle Data Guard – Implementação & Manutenção Active Data Guard
  243. 243. Neste Capítulo  Neste capítulo você vai aprender:  Usar o Real-Time Query para acessar o standby físico.  Habilitar “block change tracking” para um standby físico. 243
  244. 244. Oracle Active Data Guard  Uma option (licenciada à parte) que nasceu na versão 11g do Oracle database.  Melhora a qualidade do serviço, eliminando a necessidade de executar relatórios “pesados” no banco de produção, a abrir o standby para leitura.  Features inclusas:  Real-Time Query  RMAN Block change trancking. 244
  245. 245. Oracle Active Data Guard 245
  246. 246. Habilitando Real-Time Apply  Pare o processo de aplicação de redo:  Abra o banco de dados:  Reinicie o processo de aplicação de redo: 246 DGMGRL> EDIT DATABASE 'STBY' set state='apply-off'; Succeeded. DGMGRL> EDIT DATABASE 'STBY' set state='apply-on'; Succeeded. SQL> ALTER DATABASE OPEN; Database Altered.
  247. 247. Desabilitando Real-Time Apply  Shutdown a instancia standby.  Reinicie a instancia standby em modo MOUNT. 247 SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
  248. 248. Block Change Tracking  É habilitado no banco de dados standby para que backups incrementais sejam executados mais rapidamente.  Toda vez que um bloco for alterado (após um backup) ele é registrado no arquivo do block change tracking.  É um arquivo binário usado pelo RMAN para registrar o endereço dos blocos com alterações. 248
  249. 249. Block Change Tracking  Otimiza o processo de backup incremental.  Registra os blocos alterados desde o ultimo backup.  É usado um arquivo binário para este procedimento.  Os blocos são gerados quando a transação gera redo.  A instancia identifica os blocos automaticamente. 249
  250. 250. Block Change Tracking  Para habilitar o block change tracking, use o SQL*Plus ou o Enterprise Manager. 250 SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING [USING FILE ......];
  251. 251. Block Change Tracking  Monitoramento: 251 SQL> SELECT filename, status, bytes 2 FROM v$block_change_tracking; SQL> SELECT file#, avg(datafile_blocks), 2 avg(blocks_read), 3 avg(blocks_read/datafile_blocks) 4 * 100 AS PCT_READ_FOR_BACKUP, 5 avg(blocks) 5 FROM v$backup_datafile 6 WHERE used_change_tracking = 'YES' 7 AND incremental_level > 0 8 GROUP BY file#;
  252. 252. Resumo  Neste capítulo foi abordado:  Usar o Real-Time Query para acessar o standby físico.  Habilitar “block change tracking” para um standby físico. 252
  253. 253. Oracle Data Guard – Implementação & Manutenção Backup & Recovery
  254. 254. Neste Capítulo  Neste capítulo você vai aprender:  Usar o RMAN para backup/restore em Data Guard  Backup Offloads no Standby Database.  Recuperar o banco de dados de produção usando um backup do banco de dados standby 254
  255. 255. RMAN e Data Guard  RMAN pode ser usado para as operações de backup, restore e recover em um ambiente com Data Guard.  Backups do standby database físico podem ser usados no banco de dados primário.  Backups de standby databases lógicos não são uteis no banco de dados primário.  O uso do catalogo do RMAN é obrigatório com o uso do Data Guard.  RMAN e Data Guard (boas práticas)  Faça backups no banco de dados primário e standby, para reduzir o MTTR.  Use backups incrementais. 255
  256. 256. RMAN e Data Guard  Backups com o RMAN de datafiles e archivelogs são completamente intercambiáveis entre os dois ambientes.  Backups de controlfile NÃO!  Banco de dados primário e standby, precisam usar o mesmo catálogo.  Não é preciso registrar o standby database no catálogo. 256
  257. 257. Importante  Seu standby database deve ser físico.  Você deve estar conectado ao catálogo quando for fazer o backup.  Você deve estar conectado ao standby físico como TARGET quando for fazer o backup. 257
  258. 258. Standby Lógico  Backup Considerações:  Use a mesma politica de backup que o banco de dados primário.  Os backups não são intercambiáveis entre as instancias.  Recovery Considerações:  Se perder arquivos individuais, faça o recovery normal como um banco de dados de produção.  Se perder todo seu standby database, recrie do “zero”.  Use uma cópia comum do controlfile para restaurá-lo em caso de perdas. 258
  259. 259. Catálogo do RMAN  Ao usar o catálogo do RMAN, é possível que o backup de um servidor possa ser restaurado no outro.  O catálogo do RMAN usa os meta dados de maneira transparentemente através das instancias na configuração do Data Guard.  Use um servidor separa para o catálogo (nem o primário nem o standby), pois em caso de algum desastre, seus backups não estarão comprometidos. 259
  260. 260. Criando o Catálogo  Crie um banco de dados.  Crie o usuário com RECOVERY_CATALOG_OWNER.  No RMAN crie o catálogo. 260
  261. 261. Criando o Catálogo  Registro o banco de dados primário no catálogo.  O standby database é registrado automaticamente, quanto o comando CONFIGURE_DB_UNIQUE_NAME é executado.  Ações do RMAN:  Cria algumas linhas em tabelas do owner do catalogo.  Copia os dados do controlfile do target database para tabelas do catálogo. 261 $ rman target / CATALOG user/pass@tns_alias RMAN> CREATE CATALOG; RMAN> REGISTER DATABASE;
  262. 262. Configurações Persistentes  No comando CONFIGURE, use uma clausula a mais para que as configurações tenham efeito no standby database: FOR DB_UNIQUE_NAME.  Você não deve conectar no standby database ou no banco de dados primário como target.  O RMAN deve estar conectado no catálogo quando qualquer alteração, configuração for feita. 262 RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON for db_unique_name STBY; new RMAN configuration parameters: CONFIGURE CONTROLFILE AUTOBACKUP ON; new RMAN configuration parameters are successfully stored.
  263. 263. Configurações Persistentes  Política de retenção:  Politica para expurgo dos archivelogs.  Identificadores de conexão: 263 RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY; RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; RMAN> CONFIGURE DB_UNIQUE_NAME PRIM CONNECT IDENTIFIER ‘PRIM’; RMAN> CONFIGURE DB_UNIQUE_NAME STBY CONNECT IDENTIFIER ‘STBY’;
  264. 264. Configurações Persistentes  Use os parâmetros para backups em bancos de dados standby físicos.  Backup automático do controlfile:  Ignore datafiles que já tenham backups recentes, para evitar duplicar backups e desperdiçar recursos.  Quando deletar os archivelogs. 264 RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN> CONFIGURE BACKUP OTIMIZATION ON; RMAN> CONFIGURE ARCHIVELOG DELETETION POLICY TO BACKED UP 1 TIMES 2> TO DEVICE TYPE DISK;
  265. 265. Configurações Persistentes  Se você optar por não fazer backup de seu standby database, é possível especificar que seus archivelogs sejam deletados imediatamente após serem aplicados: 265 RMAN> CONFIGURE ARCHIVELOG DELETETION POLICY TO APPLIED ON ALL STANDBY;
  266. 266. Backups incrementais  Você pode usar uma estratégia de backup assim:  Primeiro dia: Um backup full.  Segundo dia: Um backup incremental.  Terceiro dia: Um backup incremental. Os backups feitos no dia anterior, podem ser mesclados com o backup atual. Script exemplo: 266 RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME ALL; RMAN> RECOVER COPY OF DATABASE WITH TAG ‘DGBKP’; RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY 2> WITH TAG ‘DGBKP’ DATABASE; RMAN> BACKUP DEVICE TYPE DISK ARCHIVELOG ALL; RMAN> BACKUP BACKUPSET ALL; RMAN> DELETE ARCHIVELOG ALL;
  267. 267. Recover de Datafile Instancia Primária  Usando backups.  Usando um datafile do standby database. 267 RMAN> RESTORE DATAFILE 5; RMAN> RECOVER DATAFILE 5;
  268. 268. Recover de Datafile Entre Instancias (S x P)  Conecte no standby database como TARGET e na instancia auxiliar como AUXILIARY.  Faça o backup do datafile na instancia standby para a instancia primária, já colocando-o em seu local definitivo: 268 RMAN> BACKUP AS COPY DATAFILE 5 AUXILIARY FORMAT ‘/disk001/df005.dbf’ RMAN> CONNECT TARGET sys/oracle_4U@STBY RMAN> CONNECT AUXILIARY sys/oracle_4U@PRIM
  269. 269. Recover de Datafile Entre Instancias (S x P)  Conecte no banco de dados primário como TARGET e também no catalogo do RMAN.  Catalogue o datafile:  Faça um switch de datafile: 269 RMAN> CONNECT TARGET sys/oracle_4U@PRIM RMAN> CONNECT CATALOG rcatowner/oracle_4U@CATDB RMAN> CATALOG DATAFILECOPY ‘/disk001/df005.dbf’; RMAN> run { 2> SET NEWNAME FOR DATAFILE 5 TO ‘/disk001/df005.dbf’; 3> switch datafile 5; 4> }
  270. 270. Recover de Datafile Entre Instancias (P x S)  Se os archivelogs estiverem acessíveis:  Execute RESTORE DATAFILE.  Reinicie o processo de Redo-Apply.  Se os archivelogs não estiverem disponíveis:  Restause o datafile: RESTORE DATAFILE  Recupere o banco de dados, até o último SCN disponível.  Reinicie o processo de Redo-Apply  Use o datafile corrente do banco de dados primário. 270
  271. 271. Resumo  Neste capítulo foi abordado:  Usar o RMAN para backup/restore em Data Guard  Backup Offloads no Standby Database.  Recuperar o banco de dados de produção usando um backup do banco de dados standby 271
  272. 272. Oracle Data Guard – Implementação & Manutenção Conectividade
  273. 273. Neste Capítulo  Neste capítulo você vai aprender:  Configurar a conectividade dos clients em um ambiente com Data Guard.  Implementar os procedimentos de failover automático e redirecionamento dos clients para um novo banco de dados primário. 273
  274. 274. Entendendo  Usando Data Guard esteja ciente que:  Os bancos de dados encontram-se em diferentes hosts.  Os clients deve se conectar em:  Bancos de dados primários.  Bancos de dados Standby Físicos (Active Data Guard).  Bancos de dados Standby Lógicos.  Bancos de dados Snapshots Standby.  Se os clients enviarem conexões para um banco de dados standby (erroneamente) receberão uma mensagem de erro.  Os clients devem se reconectar automaticamente ao banco de dados correto, caso haja um failover. 274
  275. 275. Entendendo 275 PRIM STBY Listener PRIM = (DESCRIPTION = (ADDRESS=(PROTOCOL = TCP)(HOST = HOST-01)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP)(HOST = HOST-02)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = PRIM)))
  276. 276. Evitando Erros  Use “serviços” (DBMS_SERVICE) para prevenir que seus usuários conectem-se na base de dados errada.  Serviços vão funcionar como uma camada de abstração entre as instancias.  Registre os serviços no listener de cada instancia.  Conecte os clients nos serviços e não nas instancias diretamente.  Listeners podem redirecionar as conexões para a instancia correta em caso de falhas. 276
  277. 277. Serviços  Para gerenciar os serviços dentro de cada banco de dados, use a package DBMS_SERVICE.  Atributos dos serviços:  Service Name: Para administração do serviço.  Network Name: Para conexões externas.  Transparent Application Failover (TAF): Para a implementação de failovers automáticos. 277
  278. 278. Entendendo 278 PRIM STBY Listener PRIM = (DESCRIPTION = (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-01)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-02)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = PRIM))) Listener
  279. 279. Criando Serviços 279 DBMS_SERVICE.CREATE_SERVICE( - SERVICE_NAME => 'DG_PROD', - NETWORK_NAME => 'DG_PROD', - FAILOVER_METHOD => 'BASIC', - FAILOVER_TYPE => 'SELECT', - FAILOVER_RETRIES => 180, - FAILOVER_DELAY => 1); DBMS_SERVICE.CREATE_SERVICE( - SERVICE_NAME => 'DG_RTQ', - NETWORK_NAME => 'DG_RTQ'); DBMS_SERVICE.CREATE_SERVICE( - SERVICE_NAME => 'DG_LSBY', - NETWORK_NAME => 'DG_LSBY'); DBMS_SERVICE.CREATE_SERVICE( - SERVICE_NAME => 'DG_SNAP', - NETWORK_NAME => 'DG_SNAP');
  280. 280. Serviços  Use uma trigger de evento de banco de dados para garantir a conectividade no “momento certo” com o “papel certo”.  Com o banco de dados no “papel” errado, a trigger garante que nada seja acessível.  Use uma trigger para inicializar os serviços.  DG_PROD: Banco de dados primário/produção.  DG_RTQ: Standby físico no modo REAL TIME QUERY.  DG_SNAP: Snapshot Standby.  DG_LSBY: Standby lógico. 280
  281. 281. Serviços (Trigger) 281 CREATE TRIGGER MANAGE_SERVICES AFTER STARTUP ON DATABASE DECLARE ROLE VARCHAR(30); OMODE VARCHAR(30); BEGIN SELECT DATABASE_ROLE INTO ROLE FROM V$DATABASE; SELECT OPEN_MODE INTO OMODE FROM V$DATABASE; IF ROLE = 'PRIMARY' THEN DBMS_SERVICE.START_SERVICE ('DG_PROD'); ELSIF ROLE = 'PHYSICAL STANDBY' THEN IF OMODE = 'READ ONLY' THEN DBMS_SERVICE.START_SERVICE ('DG_RTQ'); END IF; ELSIF ROLE = 'LOGICAL STANDBY' THEN DBMS_SERVICE.START_SERVICE ('DG_LSBY'); ELSIF ROLE = 'SNAPSHOT STANDBY' THEN DBMS_SERVICE.START_SERVICE ('DG_SNAP'); END IF; END; /
  282. 282. Serviços (tnsnames) 282 PROD = (DESCRIPTION = (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-01)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-02)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = DG_PROD))) RTQ = (DESCRIPTION = (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-01)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-02)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = DG_RTQ))) SNAP = (DESCRIPTION = (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-01)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-02)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = DG_SNAP))) LSBY = (DESCRIPTION = (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-01)(PORT = 1521)) (ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-02) PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = DG_LSBY)))
  283. 283. Failover Automático  Realoque os serviços de banco de dados no novo banco de dados primário, como parte do seu processo de failover.  Notifique os clients que um failover ocorreu.  Redirecione os clients para o novo banco de dados primário. 283
  284. 284. Failover Automático Componentes Client  Você pode fazer uso das seguintes features no processo de failover, a fim de minimizar os impactos aos clientes.  Connect time failover.  Fast Application Notification.  Fast Connection Failover.  DB_ROLE_CHANGE Evento de sistema. 284
  285. 285. Client Failover Melhores Práticas  Use OCI e FAN OCI  AQ_HA_NOTIFICATIONS.  Configure DBC para Fast Connection Failover e FAN ONS:  ONS deamons no servidor primário e standby.  Clients JDBC usam remote subscriptions para todos os deamons.  Implemente ADDRESS_LIST transversal.  OCI OUTBOUUND_CONNECT_TIMEOUT  JDBC SQLnetDef.TCP_CONNTIMEOUT_STR 285
  286. 286. Client Failover Melhores Práticas  Na instancia de banco de dados:  Use DBMS_SERVICE.CREATE_SERVICE para criar um serviço e habilitar politicas de HA TAF e etc.  Crie uma trigger de banco de dados para que o serviço seja realocado de maneira correta, após a “role transition” do banco de dados.  Configure OCI Clients.  Use o parâmetro OCI Events para inicializar o ambiente.  Defina SQLNET.OUTBOUND_CONNECT_TIMEOUT no sqlnet.ora para um valor de 3 segundos.  Registre um event call-back. 286
  287. 287. Clients OLE DB  Na instancia de banco de dados, garanta que o data guard broker gerencie e configuração.  Execute DBMS_SERVICE.CREATE_SERVICE para criar um serviço e habilitar a HA juntamente com TAF.  Crie uma trigger de banco de dados para realocar o serviço depois da “role transition”. 287
  288. 288. Clients OLE DB  Na string de conexão, defina os atributos DBNotifications e DBNotificationPort e OraOLEDB.  No arquivo sqlnet.ora, defina o parâmetro SQLNET.OUTBOUND_CONNECT_TIMOUT para um valor de 3 segundos. 288
  289. 289. Clients JDBC  Execute DBMS_SERVICE.CREATE_SERVICE para criar um serviço e habilitar a HA juntamente com TAF.  Configure o ONS no diretório:  $ORACLE_HOME/opmn/conf  Inicie o deamon do ONS.  Crie uma trigger de banco de dados para realocar o serviço depois da “role transition”.  Crie a trigger com o evento de sistema DB_ROLE_CHANGE. 289
  290. 290. Clients JDBC  Os parâmetro a seguir devem ser definidos como TRUE:  FastConnectionFailoverEnabled.  DataSource.  Em seu data source a propriedade a seguir deve ser definida com o valor de 3 segundos.  oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR  Crie um serviço que tenha no atributo “host” o hostname do servidor de produção e de todos os servidores standby.  Configure subscrição remota no ONS para o client JDBC.  Habilite comunicações via SSL. 290
  291. 291. Resumo  Neste capítulo foi abordado:  Configurar a conectividade dos clients em um ambiente com Data Guard.  Implementar os procedimentos de failover automático e redirecionamento dos clients para um novo banco de dados primário. 291

×