ORACLE SG PDF

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
D87097
Edio 1.0
D81250BP10
Junho de 2014
Guia do Aluno
Oracle Database 12c:
Administrao do RAC
Oracle University and Error : You are not a Valid Partner use only
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Autores Copyright 2014, Oracle e/ou suas empresas afiliadas. Todos os direitos reservados.
Jim Womack Iseno de Responsabilidade

Dominique Jeunot Este documento contm informaes de propriedade da Oracle Corporation e est protegido
pela legislao de direitos autorais e outras leis de propriedade intelectual, podendo ser
copiado e impresso somente para uso individual em um curso de treinamento Oracle. O
Revisores e documento no pode ser modificado nem alterado de forma alguma. Exceto em situaes
Colaboradores que constituam uso justo de acordo com a legislao de direitos autorais, no ser permitido
Tcnicos utilizar, compartilhar, descarregar, carregar, copiar, imprimir, executar, reproduzir, publicar,
licenciar, divulgar, transmitir nem distribuir este documento total ou parcialmente sem a
Allan Graves expressa autorizao da Oracle.
Gerlinde Frenzen As informaes contidas neste documento esto sujeitas a alteraes sem aviso prvio. Se
Branislav Valny voc encontrar algum problema no documento, envie Oracle Corporation ou Oracle do
Brasil Sistemas Ltda. uma descrio de tal problema por escrito. Oracle University, 500
Herbert Bradbury Oracle Parkway, Redwood Shores, California 94065 USA.
Ira Singer A Oracle Corporation e a Oracle do Brasil Sistemas Ltda. no garantem que este documento
esteja isento de erros.
Harald Van Breederode
Aviso de Direitos Restritos
Joel Goodman
Sean Kim Se esta documentao for entregue/distribuda ao Governo dos Estados Unidos ou a
qualquer outra parte que a licencie ou utilize em nome daquele governo, a seguinte legenda
Andy Fortunak ser aplicvel:
Al Flournoy
U.S. GOVERNMENT RIGHTS
Markus Michalewicz The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose
these training materials are restricted by the terms of the applicable Oracle license agreement
Maria Billings
and/or the applicable U.S. Government contract.
Mark Scardina
Aviso de Marca Registrada
Ron Soltani
Oracle e Java so marcas comerciais registradas da Oracle e/ou de suas afiliadas. Outros
nomes podem ser marcas comerciais de seus respectivos proprietrios.
Editores
Anwesha Ray
Raj Kumar
Designer Grfico
Divya Thallap
Publicadores
Syed Imtiaz Ali
Pavithran Adka
Sumrio
1 Viso Geral do Grid Infrastructure
Objetivos 1-2
O que Cluster? 1-3
O que Clusterware? 1-4
Oracle Clusterware 1-5
Oracle Flex Clusters 1-6
Escalabilidade dos Flex Clusters 1-7
Arquitetura e Servios de Cluster do Clusterware 1-8
Obletivos quanto ao Oracle Clusterware 1-9
Rede do Oracle Clusterware 1-10
Inicializao do Oracle Clusterware 1-12
Arquitetura do GPnP: Viso Geral 1-13
Como o GPnP Funciona: Inicializao do N do Cluster 1-15
Grid Naming Service (GNS) 1-16
Nome de Acesso de Cliente nico 1-17
Conexes do Banco de Dados de Clientes 1-19
O que Oracle ASM? 1-20
ASM CloudFS e ACFS 1-21
Oracle Flex ASM 1-23
Recursos e Vantagens do ASM 1-24
Questionrio 1-25
Resumo 1-27
Exerccio 1: Viso Geral 1-28
2 Viso Geral e Arquitetura dos Bancos de Dados do RAC

Objetivos 2-2
Viso Geral do Oracle RAC 2-3
Arquitetura Tpica do Oracle RAC 2-5
Alta Disponibilidade de Instncia nica do RAC One Node 2-6
Oracle RAC One Node 2-7
Oracle RAC One Node e Oracle Clusterware 2-8
Solues de Armazenamento "Cluster-Aware" 2-9
Oracle Cluster File System 2-10
Oracle RAC e Conectividade de Rede 2-11
Vantagens da Utilizao do RAC 2-12
iii
Clusters e Escalabilidade 2-13

Nveis de Escalabilidade 2-14
Escalabilidade e Agilizao 2-15
Agilizao/Escalabilidade e Cargas de Trabalho 2-16
Throughput de Entrada/Sada Balanceado: Exemplo 2-17
A Necessidade de Recursos Globais 2-18
Requisito de Memria Adicional para RAC 2-19
Execuo Paralela com RAC 2-20
Resumo 2-22
3 Instalando e Configurando o Oracle RAC

Objetivos 3-2
Instalando o Software do Banco de Dados Oracle 3-3
Criando o Banco de Dados Clusterizado 3-8
Seleo do Tipo do Banco de Dados 3-9
Identificao do Banco de Dados 3-11
Opes de Gerenciamento de Bancos de Dados Clusterizados 3-12
Senhas para Proprietrios de Esquemas de Banco de Dados 3-13
Locais de Armazenamento 3-14
Contedo do Banco de Dados 3-15
Parmetros de Inicializao 3-16
Criar o Banco de Dados 3-17
Monitorando o Andamento 3-18
Tarefas de Ps-Instalao 3-19
Processos de Background Especficos ao Oracle RAC 3-20
Converso de Instncia nica em RAC 3-22
Consideraes sobre a Converso de Bancos de Dados de Instncia nica em
Oracle RAC 3-23
Converso de Instncia nica Usando DBCA 3-24
Etapas de Converso 3-25
Converso de Instncia nica Usando rconfig 3-28
Questionrio 3-29
Resumo 3-31
4 Oracle RAC Administration

Objetivos 4-2
Home Page Cluster Database 4-3
Home Page Cluster Database Instance 4-5
Home Page Cluster 4-6
Topology Viewer 4-7
iv
Alertas do Enterprise Manager e RAC 4-8

Mtricas do Enterprise Manager e RAC 4-9
Blecautes do Enterprise Manager e RAC 4-10
Arquivos de Redo Log e RAC 4-11
Gerenciamento Automtico de Undo e RAC 4-13
Iniciando e Interrompendo Instncias do RAC 4-14
Iniciando e Interrompendo Instncias do RAC com o srvctl 4-15
Iniciando e Interrompendo Instncias do RAC com o SQL*Plus 4-16
Iniciando e Interrompendo Bancos de Dados Plugveis no Oracle RAC 4-17
Alternar entre as Polticas Automticas e Manuais 4-19
Arquivos de Parmetros de Inicializao do Ambiente RAC 4-21
Valores de Parmetros do SPFILE e o Ambiente RAC 4-22
Ordem de Pesquisa do Arquivo de Parmetros no Oracle RAC 4-23
EM e os Valores dos Parmetros de SPFILE 4-24
Parmetros de Inicializao do Ambiente RAC 4-26
Parmetros que Exigem Definies Idnticas 4-28
Parmetros que Exigem Definies Exclusivas 4-29
Indisponibilizando Bancos de Dados RAC com o Comando Quiesce 4-31
Encerrando Sesses em uma Instncia Especfica 4-32
Como os Comandos SQL*Plus Afetam as Instncias 4-33
Transparent Data Encryption e Keystores no RAC 4-34
Questionrio 4-36
Resumo 4-38
5 Gerenciando Operaes de Backup e Recuperao no Ambiente RAC

Objetivos 5-2
Recuperao de Instncia e RAC 5-3
Recuperao de Instncia e Disponibilidade do Banco de Dados 5-5
Recuperao de Instncia e RAC 5-6
Proteo contra Falha de Mdia 5-8
Recuperao de Mdia no Oracle RAC 5-9
Recuperao Paralela no Ambiente RAC 5-10
RAC e rea de Recuperao Rpida 5-11
Backup e Recuperao do Ambiente RAC com o EM 5-12
Configurando as Definies de Recuperao do Ambiente RAC com o EM 5-13
Convenes de Arquivos de Redo Arquivados no RAC 5-14
Configurando as Definies de Backup do Ambiente RAC com o EM 5-15
Oracle Recovery Manager 5-16
Configurando o Local do Arquivo de Controle de Snapshot no RMAN 5-17
Configurando o Backup Automtico do Arquivo de Controle e do SPFILE 5-18
v
Efetuando a Verificao Cruzada em Vrios Ns de Clusters em um

Ambiente RAC 5-19
Conexes de Canais com Instncias do Cluster 5-20
Suporte ao Canal do RMAN para o Grid 5-21
Localizao Automtica Default do RMAN 5-22
Distribuio de Backups 5-23
Gerenciando Redo Logs Arquivados com o RMAN 5-24
Esquema de Arquivamento Local do Sistema de Arquivos No-clusterizado 5-25
Configurando Arquivamento Local No-clusterizado 5-26
Esquema de Arquivamento do Sistema de Arquivos Clusterizados e do ASM 5-27
Configurando o Esquema de Arquivamento do CFS 5-28
Restaurando e Recuperando 5-29
Questionrio 5-30
Resumo 5-32
6. Conceitos do Gerenciamento de Recursos Globais

Objetivos 6-2
Necessidade de Controle da Concorrncia Global 6-3
GRD (Global Resource Directory) 6-4
Gerenciamento de Recursos Globais 6-5
Remastering de Recursos Globais 6-6
Recuperao de Recursos Globais 6-7
Processos de Background dos Recursos Globais 6-8
Coordenao do Acesso aos Recursos Globais 6-10
Enfileiramentos Globais 6-11
Bloqueios de Instncia 6-12
Gerenciamento do Cache Global: Viso Geral 6-13
Componentes do Gerenciamento do Cache Global 6-14
Estados do Buffer de Cache Global 6-15
Cenrios de Gerenciamento do Cache Global para Leituras de Bloco nico 6-16
Cenrios do Cache Global: Viso Geral 6-17
Cenrio 1: Leitura do Disco 6-18
Cenrio 2: Operao de Leitura-Gravao de Cache Fusion 6-22
Cenrio 3: Operao de Gravao-Gravao de Cache Fusion 6-26
Cenrio 4: Operao de Leitura-Gravao de Cache Fusion 6-30
Cenrios de Gerenciamento do Cache Global para Leituras de Vrios Blocos 6-34
Views teis do Gerenciamento de Recursos Globais 6-35
Questionrio 6-36
Resumo 6-37
vi
7 Monitoramento e Ajuste do Banco de Dados RAC

Objetivos 7-2
CPU e Dimenses de Ajuste de Tempo de Espera 7-3
Ajuste Especfico para RAC 7-4
Analisando o Impacto do Cache Fusion em Sistemas RAC 7-5
Latncias Tpicas de Operaes em Sistemas RAC 7-6
Eventos de Espera para Sistemas RAC 7-7
Views de Eventos de Espera 7-8
Eventos de Espera do Cache Global: Viso Geral 7-9
Esperas de Enfileiramentos Globais 7-11
Estatsticas de Sesso e Sistema 7-12
Dicas Mais Comuns para Ajuste do Ambiente RAC 7-13
Disputa por Blocos de ndice: Consideraes 7-15
Sequncias Oracle e Disputa por ndice 7-16
Consideraes sobre Blocos de Undo 7-17
Consideraes sobre HWM (High-Water Mark) 7-18
Chamadas Concorrentes de Vrias Instncias: Consideraes 7-19
Monitorando o Desempenho do Banco de Dados RAC e do Cluster 7-20
Pgina de Desempenho do Banco de Dados de Cluster 7-21
Determinando a Mdia de Carga do Host do Cluster 7-22
Determinando a Latncia de Acesso aos Blocos do Cache Global 7-23
Determinando Sesses Mdias Ativas 7-24
Determinando o Throughput do Banco de Dados 7-25
Acessando a Pgina Cluster Cache Coherency 7-27
Exibindo a Pgina Database Locks 7-29
Snapshots do AWR no Ambiente RAC 7-30
Relatrios do AWR e Ambientes RAC: Viso Geral 7-31
Relatrios de Histrico de Sesses Ativas para o Ambiente RAC 7-33
Automatic Database Diagnostic Monitor para RAC 7-35
O que o ADDM Diagnostica para o RAC? 7-37
Suporte do EM para ADDM for RAC 7-38
Questionrio 7-39
Resumo 7-41
8 Gerenciando a Alta Disponibilidade de Servios

Objetivos 8-2
Oracle Services 8-3
Uso do Servio em um Banco de Dados Oracle RAC 8-4
Operaes e Servios Paralelos 8-5
Caractersticas do Servio 8-6
vii
Conexes de Servio Default 8-8

Registro de Servio Restrito 8-9
Criando um Servio com o Enterprise Manager 8-10
Criando Servios com SRVCTL 8-11
Gerenciando Servios com o Enterprise Manager 8-12
Gerenciando Servios com o EM 8-13
Gerenciando Servios com srvctl 8-14
Usando Servios com Aplicaes Clientes 8-15
Servios e Balanceamento de Carga de Conexes 8-16
Servios e o Transparent Application Failover 8-17
Usando Servios com o Resource Manager 8-18
Servios e Resource Manager com o EM 8-19
Usando Servios com o Scheduler 8-20
Servios e o Scheduler com o EM 8-21
Usando Transaes Distribudas com o Ambiente RAC 8-23
Servios e Transaes Distribudas 8-24
Limites de Servios e Alertas 8-26
Limites de Servios e Alertas: Exemplo 8-27
Agregao de Servios e Rastreamento 8-28
Pgina Top Services Performance 8-29
Configurao da Agregao de Servios 8-30
Monitoramento de Servios, Mdulos e Aes 8-31
Views de Desempenho dos Servios 8-33
Questionrio 8-34
Resumo 8-36
9 Alta Disponibilidade para Conexes e Aplicativos

Objetivos 9-3
Tipos de Distribuio de Carga de Trabalho 9-4
Balanceamento de Carga por Tempo de Conexo do Cliente 9-5
Recurso FAN (Fast Application Notification): Viso Geral 9-6
Recurso FAN (Fast Application Notification): Vantagens 9-7
Implementando Eventos FAN 9-8
FAN e Clientes Oracle Integrados 9-9
Tipos de Eventos Suportados pela FAN 9-11
Motivos dos Eventos FAN 9-12
Status de Eventos FAN 9-13
Formato de Eventos FAN 9-14
Load Balancing Advisory: Evento FAN 9-15
Implementao de Callouts do Servidor 9-16
viii
Parse de Callouts do Servidor: Exemplo 9-17

Filtro de Callout do Servidor: Exemplo 9-18
ONS do Servidor 9-19
Configurando o ONS no Cliente (Opcional) 9-20
Failover de Conexo Rpida do JDBC do UCP: Viso Geral 9-21
Vantagens do FCF JDBC/ODP.NET 9-22
Load Balancing Advisory 9-23
Balanceamento de Carga de Conexes de Runtime do JDBC do
UCP/ODP.NET: Viso Geral 9-24
Balanceamento de Carga de Conexes no Ambiente RAC 9-25
Monitorando Eventos FAN LBA 9-26
TAF (Transparent Application Failover): Viso Geral 9-27
Configurao Bsica do TAF no Servidor: Exemplo 9-28
Configurao Bsica do TAF no Cliente: Exemplo 9-29
Configurao do Mtodo Preconnect do TAF: Exemplo 9-30
Verificao do TAF 9-31
Consideraes sobre Pools de Conexes FAN e TAF 9-32
Questionrio 9-33
Resumo 9-34
Objetivos 9-36
A Situao Anterior ao Recurso Application Continuity 9-37
Introduzindo os Recursos Transaction Guard e Application Continuity 9-38
RAC e Application Continuity 9-39
Principais Conceitos do Application Continuity 9-40
Fluxo de Trabalho de uma Solicitao ao Banco de Dados 9-42
O que Transaction Guard? 9-43
Como o Transaction Guard Funciona 9-44
Usando o Transaction Guard 9-45
Benefcios do Transaction Guard 9-46
O que Application Continuity? 9-47
Como o Application Continuity Funciona? 9-48
Usando o Application Continuity 9-49
Fases de Processamento do Application Continuity 9-50
Restries 9-52
Possveis Efeitos Colaterais 9-53
Aes que Desabilitam o Application Continuity 9-54
Quando o Application Continuity Transparente? 9-55
Benefcios do Application Continuity 9-56
Avaliao de Aplicaes para Uso do Application Continuity 9-57
Lidando com Limites da Solicitao 9-59
Desabilitando a Reproduo por Meio da API disableReplay 9-60
ix
Opes de Inicializao de Conexes 9-61

Objetos Mutveis e o Application Continuity 9-63
Mantendo Objetos Mutveis para Reproduo 9-64
Configurando a Fonte de Dados de Reproduo JDBC 9-65
Criando Servios para o Application Continuity 9-66
Criando Servios para o Transaction Guard 9-68
Requisitos de Recursos para o Application Continuity 9-69
Questionrio 9-70
Resumo 9-73
Viso Geral do Exerccio 9: Usando o Application Continuity 9-74
10 Fazendo o Upgrade e Aplicando Patches ao Oracle RAC

Objetivos 10-2
Viso Geral dos Patches e Conjuntos de Patches 10-3
Tipos de Patches 10-4
Configurando a Biblioteca de Software 10-5
Obtendo Patches para o Oracle RAC 10-6
Fazendo o Download de Patches 10-9
Instalao de Patches com Indisponibilidade Reduzida para Ambientes
de Cluster 10-10
Patches Dinmicos 10-11
Upgrades de Banco de Dados Fora do Local 10-12
Upgrade de Banco de Dados Fora do Local com o OUI 10-13
OPatch: Viso Geral 10-14
OPatch: Uso Geral 10-15
Antes de Aplicar Patches com o OPatch 10-16
Arquivos de Log e Rastreamento do OPatch 10-20
Queryable Patch Inventory 10-21
Questionrio 10-22
Resumo 10-23
11 Oracle RAC One Node

Objetivos 11-2
Oracle RAC One Node 11-3
Criando um Banco de Dados Oracle RAC One Node 11-4
Verificando um Banco de Dados RAC One Node Existente 11-6
Migrao On-line do Oracle RAC One Node 11-7
Consideraes sobre a Migrao On-line 11-8
Executando uma Migrao On-line 11-9
Ilustrao da Migrao On-line 11-10
Manuteno On-line: Patches Dinmicos 11-13
x
Adicionando um Banco de Dados Oracle RAC One Node a um Cluster

Existente 11-15
Convertendo um Banco de Dados RAC One Node em RAC 11-16
Convertendo um Banco de Dados de Instncia nica em um RAC One Node 11-18
Convertendo um Banco de Dados RAC em RAC One Node 11-19
Questionrio 11-20
Resumo 11-22
12 Gerenciamento de Qualidade do Servio

Objetivos 12-2
Background do Gerenciamento de Qualidade de Servio 12-3
Viso Geral do Gerenciamento de Qualidade de Servio 12-4
Gerenciamento de Qualidade de Servio e Exadata Database Machine 12-5
Foco do Gerenciamento de Qualidade de Servio 12-6
Vantagens do Gerenciamento de Qualidade de Servio 12-7
Viso Geral da Funcionalidade do Gerenciamento de Qualidade de Servio 12-9
Conjuntos de Polticas de Gerenciamento de Qualidade de Servio 12-11
Pools de Servidores 12-12
Classes de Desempenho 12-14
Classificao e Tagging 12-16
Polticas de Desempenho 12-17
Classificaes das Classes de Desempenho 12-18
Objetivos de Desempenho 12-19
Mtricas de Atendimento de Desempenho 12-20
Substituies de Diretivas de Pools de Servidores 12-21
Viso Geral de Mtricas 12-22
Arquitetura do Gerenciamento de Qualidade de Servio 12-24
Recomendaes do Gerenciamento de Qualidade de Servio 12-25
Implementando Recomendaes 12-27
Questionrio 12-29
Resumo 12-31
Demonstraes da Lio 12 12-32
13 Arquitetura Multilocatrio e RAC

Objetivos 13-2
Arquitetura No CDB 13-3
Arquitetura Multilocatria: Vantagens 13-4
CDB em um Ambiente no RAC 13-6
Contineres 13-7
Terminologia 13-8
xi
Views de Dicionrio de Dados 13-9

Conexo a um CDB no RAC 13-10
Alternando Conexes 13-12
Configurao do Oracle RAC e de Multilocatrios 13-13
Arquitetura do Oracle RAC e de Multilocatrios 13-14
Criando um CDB RAC 13-15
Criando um CDB RAC incluindo PDBs 13-16
Hospedando um CDB RAC nos Pools de Servidores 13-17
Aps a Criao do CDB 13-18
Conectando com os Servios de CDB/PDB 13-19
Abrindo um PDB em um CDB RAC 13-20
Fechando um PDB em um CDB RAC 13-22
Tipos de Servios 13-23
Gerenciando Servios 13-24
Criando Afinidades entre os Servios do PDB e os Pools de Servidores 13-25
Adicionando um PDB em um CDB RAC 13-26
Eliminando um PDB de um CDB RAC 13-27
Questionrio 13-28
Resumo 13-29
xii
Viso Geral do Grid Infrastructure
Copyright 2014, Oracle e/ou suas empresas afiliadas. Todos os direitos reservados.
Objetivos
Aps concluir esta lio, voc ser capaz de:

Explicar os princpios e as finalidades dos clusters
Descrever a arquitetura do Oracle Clusterware
Descrever como o Grid Plug and Play afeta o Clusterware
Oracle Database 12c: Administrao do RAC 1 - 2

O Que Cluster?
Um grupo de computadores independentes, mas

interconectados, que atuam como um nico sistema
Em geral, implantado para
aumentar a disponibilidade
e o desempenho ou
equilibrar uma carga de
trabalho que se altera
de forma dinmica
Um cluster compreende um grupo de computadores independentes, mas interconectados, cujos

recursos combinados podem ser aplicados a uma tarefa de processamento. Um recurso comum
de um cluster que uma aplicao deve v-lo como um nico servidor. A maioria das
arquiteturas de cluster usa uma rede dedicada (interconexo de cluster) para comunicao e
coordenao entre ns de cluster.
Uma arquitetura comum de clusters para transaes e computaes com muitos dados criada
ao redor de armazenamento em disco compartilhado. Os clusters sem nada compartilhado usam
uma arquitetura alternativa na qual o armazenamento no compartilhado, e os dados devem
ser replicados ou segmentados no cluster. Em geral, os clusters sem nada compartilhado so
usados para cargas de trabalho que podem ser divididas, com facilidade e de modo previsvel,
em pequenas unidades, que podem ser distribudas pelo cluster paralelamente. Os clusters de
disco compartilhado podem executar essas tarefas, mas tambm oferecem maior flexibilidade
para cargas de trabalho variveis. Clusters de balanceamento de carga permitem que um nico
aplicativo equilibre sua carga de trabalho pelo cluster. Opcionalmente, em um cluster de failover,
alguns ns podem ser designados como o host principal de um aplicativo, enquanto outros agem
como o host principal de diferentes aplicativos. Em um cluster de failover, a falha de um n
requer que os aplicativos suportados por ele sejam movidos para um n sobrevivente. Os
clusters de balanceamento de carga podem oferecer recursos de failover, mas tambm podem
executar um nico aplicativo em vrios ns, oferecendo maior flexibilidade para diferentes
requisitos de carga de trabalho. A Oracle suporta uma arquitetura de cluster de disco
compartilhado, oferecendo recursos de failover e balanceamento de carga. Em um cluster
Oracle, todos os ns devem compartilhar a mesma arquitetura de processador e executar o
mesmo sistema operacional. Com a release do Oracle Database 12c, o Flex ASM permite que os
ns no cluster acessem o compartilhamento armazenado indiretamente, por meio de uma
instncia do ASM ou outro n no cluster.
O Que Clusterware?
um software que fornece vrias interfaces e servios a

um cluster.
Em geral, isso inclui recursos que:
Permitem ao cluster ser gerenciado como um todo
Protegem a integridade do cluster
Mantm um registro dos recursos pelo cluster
Lidam com alteraes no cluster
Fornecem uma view comum de recursos
Clusterware um termo usado para descrever o software que fornece interfaces e servios
que ativam e suportam um cluster.
Diferentes arquiteturas de cluster requerem clusterware que fornea diferentes servios. Por
exemplo, em um cluster de failover simples, o clusterware poder monitorar a disponibilidade
de aplicativos e executar uma operao de failover caso um n de cluster se torne
indisponvel. Em um cluster de balanceamento de carga, so necessrios diferentes servios
para suportar a concorrncia e a coordenao de cargas de trabalho.
Em geral, o clusterware inclui recursos que:
Permitem ao cluster ser gerenciado como uma nica entidade (no incluindo requisitos
de sistema operacional), se desejado
Protegem a integridade do cluster de forma que os dados sejam protegidos e o cluster
continue a funcionar mesmo se a comunicao com um n de cluster for interrompida
Mantm um registro de recursos de forma que seu local seja conhecido pelo cluster e
que as dependncias entre os recursos sejam mantidas
Lidam com alteraes no cluster, como incluses de ns, remoes ou falhas
Fornecem uma view comum de recursos, como endereos de rede e arquivos em um
sistema de arquivos

Oracle Clusterware
Oracle Clusterware :
Uma parte essencial do Oracle Grid Infrastructure
Integrado com o Oracle ASM
(Automatic Storage
Management)
A base para o Oracle
Cloud File System
Uma base para o
Oracle RAC
(Real Application Clusters)
Uma infraestrutura de
cluster generalizada para
todos os tipos de aplicaes
O Oracle Clusterware uma parte essencial do Oracle Grid Infrastructure, que tambm inclui
o ASM (Automatic Storage Management) e o Oracle Cloud File System. O Oracle
Clusterware pode usar o ASM para todos os arquivos compartilhados exigidos pelo cluster. O
Oracle Clusterware tambm um fundamento do ASM Cluster File System, um sistema de
arquivos de cluster generalizado que pode ser usado para a maioria dos dados baseados em
arquivos, como documentos, planilhas e relatrios.
A combinao do Oracle Clusterware, ASM, e ACFS oferece aos administradores uma
soluo de cluster unificada, que no apenas a base do banco de dados RAC, mas
tambm pode ser aplicada a todos os outros tipos de aplicativos. O Oracle Clusterware
tambm gerencia recursos, como endereos, bancos de dados, listeners e servios de IP
virtual (VIP), e assim por diante.
O uso do Oracle Clusterware elimina a necessidade de clusterware de fornecedores
proprietrios e fornece o benefcio de usar somente software Oracle. A Oracle fornece uma
soluo de software inteira, incluindo tudo, desde o gerenciamento de disco com o Oracle
ASM (Oracle Automatic Storage Management) ato gerenciamento de dados com o Oracle
Database e Oracle RAC. Alm disso, os recursos do Oracle Database, como Oracle
Services, fornecem funcionalidade avanada, ao serem utilizados com o framework
subjacente de alta disponibilidade do Oracle Clusterware.
Com a introduo do Oracle 12c Flex Clusters, os clusters de disco puros e compartilhados
no so o nico tipo de hardware clusterizado suportado. A arquitetura se tornou hbrida com
a introduo dos ns de hub e folhas.
Oracle Flex Clusters
Ns Folha
Ns de Hub
Armazenamento
compartilhado
As releases anteriores do Oracle Clusterware foram usadas para criar clusters de produo
de grande porte, que contm entre 32 e 64 ns. Alguns clusters com mais de 100 ns foram
implantados com xito. Com o Oracle Clusterware 12c, um novo conjunto de recursos
possibilita Flex Clusters. Nesta release, os Flex Clusters so projetados para incluir
perfeitamente at 2.000 ns.
Na release 12.1, possvel usar Flex Clusters para:
Gerenciar pools grandes de recursos de aplicativos com alta disponibilidade e proteo
de failover.
Dar suporte, com eficincia, a aplicativos e bancos de dados altamente disponveis em
execuo em um nico cluster.
Os Flex Clusters usam uma topologia hub e spoke, conforme ilustrado no slide.
O ncleo de um Flex Cluster corresponde a um grupo de Ns de Hub. O grupo
essencialmente o mesmo de um cluster da release 11.2 e pode ser dimensionado para ter o
tamanho de um cluster existente dessa release. Deve haver um, e apenas um, grupo de Ns
de Hub na implantao de um Flex Cluster, e como um cluster da release 11.2, cada N de
Hub deve ser conectado ao armazenamento, que compartilhado por todo o grupo de Ns
de Hub.
possvel conectar nenhum ou mais Ns-Folha a um Flex Cluster. Cada N-Folha
conectado ao cluster por meio de um N de Hub. Ns-Folha no requerem acesso direto ao
armazenamento compartilhado conectado aos Ns de Hub.
Escalabilidade dos Flex Clusters
A topologia hub e spoke dos Flex Clusters segmenta o cluster

em grupos de ns mais gerenciveis.
Somente os Ns de Hub requerem acesso direto ao
OCR e aos discos de votao.
So necessrias menos interaes entre os ns.
Topologia do
Flex Cluster
Topologia do
Cluster Totalmente
Interconectado
A topologia hub e spoke de duas camadas o recurso de arquitetura essencial que permite
dimensionar um Flex Cluster alm dos limites anteriores. Basicamente, a topologia hub e
spoke segmenta o cluster em grupos de ns, e cada grupo contm um nmero gerencivel
de ns. Essa segmentao tem dois impactos fundamentais:
Primeiro, ao limitar o tamanho do hub, a conteno dos principais recursos do Clusterware,
como o OCR (Oracle Cluster Registry) e os discos de votao, no aumenta de forma
significativa devido adio de Ns-Folha. Isso importante porque a conteno dos discos
de votao pode levar excluso de ns de um cluster.
Segundo, so necessrias menos interaes de rede entre ns no cluster.
Consequentemente, h menos trfego administrativo na rede, como heartbeats, entre os ns.
Essa situao ilustrada no exemplo do slide. No lado esquerdo, o Flex Cluster de 12 ns
contm 12 caminhos de interao. No lado direito, o cluster de 12 ns totalmente
interconectado contm 66 caminhos de interao possveis. Para um cluster de 1.000 ns, a
diferena seria muito mais clara. Tomando como exemplo 40 Ns de Hub, com 24 Ns-Folha
por N de Hub, um Flex Cluster contm 1.740 caminhos de interao possveis. Em
comparao, um cluster totalmente interconectado de 1.000 ns contm 499.500 caminhos
de interao.

Arquitetura e Servios de Cluster do Clusterware
Arquitetura de cluster de disco compartilhado que suporta

o balanceamento de carga de aplicativos e failover
Os servios incluem:
Gerenciamento de clusters
Monitoramento de ns
Servios de eventos
Sincronizao do tempo
Gerenciamento de rede
Alta disponibilidade
Agregao de Links de
Interconexo de Cluster
(HAIP)
O Oracle Clusterware fornece um conjunto completo de servios de cluster que suportam a

arquitetura de clusters de balanceamento de carga com disco compartilhado do banco de
dados Oracle RAC (Real Application Cluster). O Oracle Clusterware tambm pode ser usado
para fornecer servios de cluster de failover para bancos de dados Oracle de instncia nica
e outros aplicativos. Os servios fornecidos pelo Oracle Clusterware incluem:
Gerenciamento de clusters, que permite o monitoramento e o gerenciamento de
servios de cluster e recursos de aplicativo de qualquer n do cluster
Monitoramento de ns, que fornece informaes em tempo real sobre quais ns esto
atualmente disponveis e os recursos suportados por eles. A integridade dos clusters
tambm protegida pelo despejo ou isolamento de ns que no estejam respondendo.
Servios de evento, que publicam os eventos de cluster de forma que os aplicativos
detectem as alteraes no cluster
Sincronizao do tempo, que sincroniza o tempo em todos os ns do cluster
Gerenciamento de rede, que fornece e gerencia endereos VIP (IP Virtual) associados
aos ns de cluster ou recursos de aplicativo para fornecer uma identidade de rede
consistente, independentemente de quais ns esto disponveis. Alm disso, o GNS
(Grid Naming Service) gerencia a nomenclatura de rede no cluster.
Alta disponibilidade, que atende, monitora e reinicia todos os recursos, conforme
necessrio
Agregao de Links de Interconexo de Cluster (HAIP)
Objetivos Quanto ao Oracle Clusterware
Fcil instalao
Fcil gerenciamento
Integrao total contnua com o Oracle RAC
Aprimoramentos do ASM
com benefcios para todos
os aplicativos
Nenhum clusterware
adicional necessrio
O Oracle Clusterware tornou-se o clusterware necessrio para o Oracle RAC (Real

Application Clusters). O Oracle Database 12c baseia-se na integrao total entre o Oracle
Clusterware e o RAC ampliando a integrao com o ASM (Automatic Storage Management).
O resultado que, agora, todos os dados compartilhados no seu cluster podem ser
gerenciados por meio do ASM. Isso inclui os dados compartilhados necessrios para
executar o Oracle Clusterware, o Oracle RAC e todos os outros aplicativos que voc escolher
para implantar em seu cluster.
Na maioria dos casos, essa capacidade anula a necessidade de implantar clusterware
adicional de outras fontes, o que tambm remove a possibilidade de problemas na
integrao, causados pela execuo de vrias pilhas de software de clusterware. Tambm
aperfeioa o gerenciamento geral do cluster.
Embora a maioria dos aprimoramentos do ASM seja assunto das prximas aulas, a prxima
parte desta aula examina uma srie de recursos adicionais do Oracle Clusterware e os
benefcios que eles proporcionam.

Rede do Oracle Clusterware

Cada n deve ter pelo menos dois adaptadores de rede.
Cada adaptador de rede pblica deve suportar TCP/IP.
O adaptador de interconexo deve suportar:
UDP (User Datagram Protocol) ou RDS (Reliable Data Socket)
para UNIX e Linux para comunicao com o banco de dados
TCP para plataformas Windows para comunicao com o banco
de dados
Todas as plataformas usam GIPc (Grid Interprocess Communication).
Rede pblica
NIC1 NIC1
NIC2 NIC2
NIC1
NIC2 Interconexo: Rede privada
Cada n deve ter, pelo menos, dois adaptadores de rede: um para a interface de rede pblica
e outro para a interface de rede privada ou interconexo. Alm disso, os nomes de interface
associados aos adaptadores de cada rede devem ser iguais em todos os ns. Por exemplo,
em um cluster de dois ns, voc no pode configurar os adaptadores de rede no n 1 com
eth0 como a interface pblica, mas no n 2 ter eth1 como a interface pblica. Os nomes de
interface pblica devem ser os mesmos, ento, necessrio configurar eth0 como pblica
nos dois ns. Voc tambm deve configurar as interfaces privadas nos mesmos adaptadores
de rede. Se eth1 for a interface privada para o n 1, ento, eth1 dever ser a interface
privada para o n 2.
Antes de iniciar a instalao, em cada n, necessrio ter, pelo menos, duas interfaces a
serem configuradas para os endereos IP pblico e privado. possvel configurar os
endereos IP com uma destas opes:
O Oracle GNS (Grid Naming Service) usando um endereo esttico definido durante a
instalao, que aloca os endereos VIP de forma dinmica usando o DHCP (Dynamic
Host Configuration Protocol), que dever estar em execuo na rede. necessrio
selecionar a opo de instalao avanada do Oracle Clusterware para usar o GNS.
Endereos estticos que os administradores de rede atribuem em um DNS (servidor de
nome de domnio de rede) ou em cada n. Para usar a opo de instalao tpica do
Oracle Clusterware, necessrio usar endereos estticos.

Para a rede pblica, todos os adaptadores de rede devem suportar TCP/IP.

Para a rede privada, a interconexo dever suportar UDP ou RDS (TCP para Windows) para
comunicaes com o banco de dados. A GIPc (Grid Interprocess Communication) usada
para a comunicao entre processos do Grid (Clusterware). A GIPC uma nova
infraestrutura de comunicaes comuns, que substitui a CLSC/NS. Ela oferece controle total
da pilha de comunicaes do sistema operacional at qualquer biblioteca de cliente que ele
use. A dependncia dos NS (servios de rede) antes da verso 11.2 foi removida, mas ainda
h compatibilidade com os clientes CLSC existentes (principalmente da verso 11.1). A GIPC
pode suportar vrios tipos de comunicao: CLSC, TCP, UDP, IPC e, naturalmente, o tipo de
comunicao GIPC.
Use adaptadores de rede de alta velocidade para as interconexes e switches que suportam
TCP/IP. recomendvel Gigabit Ethernet ou um equivalente.
Se voc tiver diversas interfaces de rede disponveis, a Oracle recomenda que use o recurso
Redundant Interconnect Usage para fazer uso das vrias interfaces da rede privada.
Entretanto, voc tambm pode usar tecnologias de terceiros para fornecer redundncia para
a rede privada.
Observao: no h suporte para cabos cruzados para uso com interconexes do Oracle
Clusterware.

Inicializao do Oracle Clusterware

O Oracle Clusterware iniciado pelo daemon do SO init que
chama o script de inicializao /etc/init.d/init.ohasd.
No OL5, a instalao do Oracle Clusterware modifica o
/etc/inittab para reiniciar o ohasd no caso de uma falha.
# cat /etc/inittab
..
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
No OL6, a inicializao do Clusterware controlada pelo

Upstart via arquivo /etc/init/oracle-ohasd.conf.
# cat /etc/init/oracle-ohasd.conf
# Oracle OHASD startup
start on runlevel [35]

stop on runlevel [!35]
respawn
exec /etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
Nos sistemas OL5, o comportamento de inicializao e falha do Clusterware administrada

pelo init com base em uma entrada no arquivo /etc/inittab. Nos sistemas OL6, o
comportamento de inicializao e falha de Clusterware ainda administrado pelo init,
porm o /etc/inittab somente define o nvel de execuo padro desse n. A
inicializao do servio controlada pelo servio de inicializao Upstart com base nos
arquivos de definio de servio localizados no diretrio /etc/init. A vantagem principal
do Upstart sobre o mtodo init tradicional do System V a velocidade de inicializao. Ao
contrrio do init do System V, que inicia os servios serialmente, o Upstart orientado por
eventos. Os servios so iniciados apenas quando so necessrios.

Arquitetura do GPnP: Viso Geral

Resoluo VIP Nome do host ao qual direcionar a resoluo
Resoluo do nome do
VIP e do nome do host
Obtm os trs VIPs do SCAN
DNS GNS Registrar o VIP do n e o VIP do SCAN

VIP Esttico do GNS
Usar 1 VIP do SCAN
Um nome que
resolvido para trs VIPs
Balanceamento
SL SL SL
de carga
remote_listener
LL LL LL LL LL
Cliente local_listener
Varredura+porta+servio N 1 N 2 N 3 N 4 Nn
Obter o VIP do N Agentes
profile.xml
N
obtidos por orarootagent
e o VIP do SCAN do N e
Endereos VIP dinmicos
menos
carregado do VIP do
para SCAN
servio orarootagent
DHCP
GPnP GPnP GPnP GPnP GPnP Replicao
do perfil
Descoberta
do GPnPd
mDNS mDNS mDNS mDNS mDNS
Servio GPnP
O servio GPnP fornecido coletivamente por todos os agentes do GPnP. Trata-se de um
mtodo distribudo de replicao de perfis. O servio instanciado em cada n do domnio
como um agente do GPnP. O servio peer-to-peer; no h processo-mestre. Isso permite
alta disponibilidade porque pode ocorrer falha em qualquer agente do GPnP e, ainda assim,
os ns sero atendidos. O GPnP requer protocolo multicast IP padro (fornecido por mDNS)
para localizar servios peer. Ao usar descoberta multicast, o GPnP localiza peers sem
configurao. dessa forma que um agente do GPnP em um novo n localiza outro agente
que pode ter um perfil que ele deve usar.
Resoluo de Nomes
Um nome definido em um domnio GPnP pode ser resolvido nos seguintes casos:
Hosts dentro do domnio GPnP usam DNS normal para resolver os nomes de hosts fora
do domnio do GPnP. Eles entram em contato com o servio DNS regular e do
prosseguimento. Eles podem obter o endereo do servidor DNS pela configurao
global ou pelo DHCP.
No domnio GPnP, os nomes de hosts so resolvidos com mDNS. Isso requer um
respondente mDNS em cada n que saiba os nomes e os endereos usados por esse
n, e que a biblioteca de clientes do sistema operacional suporte a resoluo de nomes
com esse protocolo multicast. Fornecido um nome, um cliente executa
gethostbyname, resultando em uma consulta mDNS. Se o nome existir, o
respondente no n que tiver o nome responder com o endereo IP.
O software cliente poder armazenar em cache a resoluo para o valor time-to-live
fornecido.
As mquinas fora do domnio GPnP no podem resolver nomes no domnio GPnP usando
multicast. Para resolver esses nomes, elas usam seu DNS regular. A autoridade de
provisionamento organiza o DNS global para delegar um subdomnio (zona) a um
endereo conhecido que esteja no domnio GPnP. O GPnP cria um servio denominado
GNS para resolver os nomes do GPnP nesses endereos fixos.
O n no qual o servidor GNS est em execuo faz listening das solicitaes do DNS. No
recebimento, eles fazem a converso e encaminham ao mDNS, coletam respostas, fazem
converso e enviam para o cliente externo. O GNS "virtual" porque stateless.
Qualquer n no domnio multicast pode hospedar o servidor. A nica configurao do
GNS global:
- O endereo no qual fazer listening na porta 53 padro do DNS
- O(s) nome(s) dos domnios a ser(em) atendido(s)
Pode haver quantas entidades GNS que forem necessrias por razes de disponibilidade.
O GNS fornecido pela Oracle pode usar CRS para garantir disponibilidade de um nico
provedor de GNS.
SCAN e Listeners Locais
Quando um cliente envia uma solicitao de conexo, o listener do SCAN faz listening em um
endereo IP do SCAN, e a porta do SCAN contatada em nome do cliente. Como todos os
servios no cluster so registrados com o listener do SCAN, este responde com o endereo do
listener local no n menos carregado onde o servio est sendo oferecido no momento.
Finalmente, o cliente estabelece conexo com o servio por meio do listener no n onde o
servio oferecido. Todas essas aes ocorrem de forma transparente para o cliente, sem que
nenhuma configurao explcita seja necessria no cliente.
Durante a instalao, listeners so criados em ns para os endereos IP do SCAN. O Oracle
Net Services direciona as solicitaes de aplicaes para a instncia menos carregada que
esteja fornecendo o servio. Como os endereos SCAN so resolvidos para o cluster, e no
para um endereo de um n no cluster, possvel adicionar ou remover ns do cluster sem
afetar a configurao dos endereos SCAN.

Como o GPnP Funciona:

Inicializao do N do Cluster
1. Os endereos IP so negociados para interfaces pblicas
usando DHCP:
VIPs de N
VIPs do SCAN
2. Um agente do GPnP iniciado a partir do home dos ns do
Clusterware.
3. O agente do GPnP obtm seu perfil localmente ou de um
dos agentes do GPnP peer que responda.
4. O armazenamento compartilhado configurado para
corresponder aos requisitos de perfil.
5. A inicializao do servio especificada no perfil, que inclui:
Grid Naming Service para resoluo de nomes externos
Listener do SCAN (Single Client Access Name)
Quando um n iniciado em um ambiente GPnP:

Os endereos IP so negociados para todas as interfaces usando DHCP
O software Clusterware no n inicial inicia um agente do GPnP
O agente do GPnP no n inicial obtm seu perfil localmente ou usa RD (descoberta de
recursos) para descobrir os agentes peer do GPnP no Grid. Se for usado RD, ele obter
o perfil do peer do GPnP que responder.
O agente do GPnP adquire a configurao de rede desejada do perfil. Isso inclui a
criao de nomes de host razoveis. Se houver configuraes estticas, elas sero
usadas em vez dos mecanismos dinmicos. As interfaces de rede podem ser
reconfiguradas para corresponder aos requisitos de perfil.
O armazenamento compartilhado configurado para corresponder aos requisitos de
perfil
A inicializao de sistemas e servios feita conforme a configurao na imagem. No
caso do RAC, os sistemas CSS e CRS sero iniciados, que formaro o cluster e
ativaro instncias de banco de dados apropriadas. A inicializao de servios poder
executar seus prprios valores de marcador de espao ou negociar valores
dinamicamente em vez de depender de configuraes fixas. Um dos servios que
provavelmente ser iniciado em algum local o sistema GNS para resoluo de nomes
externos. Outro servio que provavelmente ser iniciado um listener do Oracle SCAN.

Grid Naming Service (GNS)

O nico endereo IP esttico necessrio ao cluster o endereo
IP virtual do GNS.
O subdomnio do cluster definido como um domnio delegado.
[root@my-dns-server ~]# cat /etc/named.conf
// Default initial "Caching Only" name server configuration
...
# Delegate to gns on cluster01
cluster01.example.com #cluster sub-domain# NS cluster01-gns.example.com
# Let the world know to go to the GNS vip
cluster01-gns.example.com 192.0.2.155 #cluster GNS Address
Uma solicitao para resolver cluster01-
scan.cluster01.example.com seria encaminhada para o GNS em
192.0.2.155.
Cada n do cluster executa um processo mDNS (DNS multicast).
Voc no pode usar o GNS com outro DNS multicast.
Se quiser usar o GNS, desative os daemons de mDNS de terceiros
no seu sistema.
Com o uso de GNS (Grid Naming Service), supe-se que haja um servidor DHCP em
execuo na rede pblica com endereos suficientes para atribuir aos VIPs e aos VIPs de
SCAN (nome de acesso de cliente nico). Com o GNS, apenas um endereo IP esttico
necessrio ao cluster, o endereo IP virtual do GNS. Esse endereo deve ser definido no
domnio DNS. O GNS configura um mDNS (DNS multicast) no cluster, que resolve nomes no
cluster sem a configurao esttica do servidor DNS para outros endereos IP de ns.
O servidor mDNS funciona da seguinte maneira: No GNS, os nomes de ns so resolvidos
usando LLMNR (resoluo de nomes multicast locais de link). Ele faz isso convertendo o
domnio ".local" da LLMNR usado pela resoluo multicast no subdomnio especificado na
consulta DNS. Quando o GNS selecionado, um servidor mDNS configurado em cada host
do cluster. A LLMNR baseia-se no mDNS gerenciado pelo Oracle Clusterware para resolver
nomes fornecidos pelo host em questo.
Para usar o GNS, antes da instalao, o administrador do DNS dever estabelecer a
delegao de domnio para o subdomnio do cluster. As consultas para o cluster so
enviadas ao listener do GNS no endereo IP virtual do GNS. Quando uma solicitao
recebida no domnio, o GNS a resolve usando seu mDNS interno e responde consulta.
Observao: Voc no pode usar o GNS com outro DNS multicast. Se quiser usar o GNS,
desative os daemons de mDNS de terceiros no seu sistema.

Nome de Acesso de Cliente nico

SCAN (nome de acesso de cliente nico) o endereo usado
pelos clientes que se conectam ao cluster.
O SCAN um nome de host totalmente qualificado localizado
no subdomnio do GNS registrado nos trs endereos IP.
$ nslookup cluster01-scan.cluster01.example.com
Server: 192.0.2.1
Address: 192.0.2.1#53
Non-authoritative answer:
Name: cluster01-scan.cluster01.example.com
Address: 192.0.2.243
Address: 192.0.2.244
Address: 192.0.2.245
O SCAN fornece um nome estvel e altamente disponvel

para uso pelos clientes, independente dos ns que compem
o cluster.
O SCAN (nome de acesso de cliente nico) o endereo usado pelos clientes que se
conectam ao cluster. O SCAN um nome de host totalmente qualificado (nome de host +
domnio) registrado nos trs endereos IP. Se voc usar o GNS e tiver suporte a DHCP, o
GNS atribuir endereos de forma dinmica ao SCAN.
Se voc no usar GNS, o SCAN dever ser definido no DNS para resoluo nos trs
endereos atribudos ao nome em questo. Isso dever ser feito antes da instalao do
Oracle Grid Infrastructure. O SCAN e seus endereos IP associados fornecem um nome
estvel a ser usado pelos clientes para conexes, independente dos ns que compem o
cluster.
Os SCANs funcionam da mesma forma que um apelido de cluster. No entanto, os SCANs
so resolvidos em qualquer n do cluster, portanto, diferentemente de um endereo VIP para
um n, os clientes que se conectarem ao SCAN no precisaro mais de endereos VIP
atualizados medida que os ns forem adicionados ao cluster ou removidos dele. Como os
endereos SCAN so resolvidos para o cluster, e no para um endereo de um n no cluster,
possvel adicionar ou remover ns do cluster sem afetar a configurao dos endereos
SCAN.
Durante a instalao, listeners so criados em cada n para os endereos IP SCAN. O
Oracle Clusterware direciona as solicitaes de aplicativos ao SCAN do cluster para a
instncia menos carregada que esteja fornecendo o servio.

Os listeners de SCAN podem ser executados em qualquer n do cluster. Os SCANs

oferecem independncia de local aos bancos de dados. Dessa forma, a configurao do
cliente no precisa depender de quais ns so executados em um banco de dados
especfico.
As instncias se registram com listeners do SCAN somente como listeners remotos. Bancos
de dados atualizados so registrados em listeners de SCAN como listeners remotos e
tambm continuam a ser registrados em outros listeners.
Se voc especificar um domnio de GNS durante a instalao, o padro do SCAN ser
clustername-scan.GNS_domain. Se voc no especificar um domnio de GNS na
instalao, o padro do SCAN ser clustername-scan.current_domain.

Conexes do Banco de Dados de Clientes

GNS
DNS
Cliente
do banco
de dados Listener 1
Listener
do SCAN
Listener Listener 2
do SCAN
Conexo do cliente
redirecionada Listener Listener 3
do SCAN
Em um ambiente GPnP, o cliente do banco de dados no precisa mais usar o endereo TNS
para entrar em contato com o listener em um n de destino. Em vez disso, ele pode usar o
mtodo EZConnect para estabelecer conexo com o banco de dados. Ao resolver o
endereo listado na string de conexo, o DNS encaminhar a solicitao de resoluo ao
GNS com o endereo VIP do SCAN para o listener do SCAN escolhido e o nome do servio
de banco de dados desejado. Na sintaxe do EZConnect, isso ter a seguinte aparncia:
scan-name.cluster-name.company.com/ServiceName, em que o nome do servio
pode ser o nome do banco de dados. O GNS responder ao servidor DNS com o endereo
IP correspondente ao nome fornecido; esse endereo , ento, usado pelo cliente para entrar
em contato com o listener do SCAN. O listener do SCAN usa o seu sistema de
balanceamento de carga de conexo para selecionar um listener apropriado, cujo nome ele
retorna ao cliente em uma mensagem do OracleNet Redirect. O cliente restabelece conexo
com o listener selecionado, resolvendo o nome por meio de uma chamada ao GNS.
Os listeners do SCAN devem ser conhecidos a todos os ns e clientes do listener do banco
de dados. Os ns de instncia de banco de dados fazem o registro cruzado somente com
listeners do SCAN conhecidos, tambm enviando a eles as mtricas de conexo por servio.
O SCAN conhecido aos servidores de banco de dados pode ser de dados do perfil ou
armazenado em OCR.

O que Oracle ASM?
Aplicao Aplicao
Sistema de arquivos
ASM
Logical Volume Manager
Sistema operacional Sistema operacional
Hardware Hardware
Oracle ASM um gerenciador de volumes e um sistema de arquivos para os arquivos do

Oracle Database, que suporta configuraes de uma nica instncia do Oracle Database e
do Oracle RAC (Oracle Real Application Clusters). O Oracle ASM a soluo de
gerenciamento recomendada de armazenamento que fornece uma alternativa para os
gerentes de volume, sistemas de arquivos e dispositivos brutos convencionais.
A combinao de funes de gerenciamento de volumes com um sistema de arquivos
possibilita um nvel de integrao e eficincia que, de outra forma, no seria possvel. Por
exemplo, o ASM capaz de evitar o overhead associado a um sistema de arquivos
convencional e obtm um desempenho equivalente ao de um disco bruto nativo para os
arquivos de dados do Oracle e outros tipos de arquivos suportados pelo ASM.
O ASM projetado para funcionar de maneira eficiente em ambientes clusterizados e no
clusterizados.
Os arquivos do Oracle ASM podem coexistir com outras opes de gerenciamento de
armazenamento, como discos brutos e sistemas de arquivos de terceiros. Este recurso
simplifica a integrao do Oracle ASM a ambientes preexistentes.

CloudFS e ACFS do ASM
O ASM gerencia
arquivos do banco
Oracle RAC Aplicao Aplicao
de dados Oracle.
O ACFS gerencia
outros arquivos.
Arquivos FS de
Distribui os dados do Oracle ACFS terceiros
ASM para
entre discos para o Oracle
balanceamento Database ASM/ADVM
de carga
Sistema operacional
Permite o
espelhamento Oracle ASM
integrado entre discos
O Oracle CloudFS (Oracle Cloud File System) projetado para ajudar as empresas a
implantar seus aplicativos, bancos de dados e armazenamento em nuvens privadas. Ele
entrega uma infraestrutura de nuvem que fornece acesso rede, elasticidade rpida e
provisionamento para recursos de armazenamento em pool que so os requisitos chaves
para a computao em nuvem. Os clientes podem usar o Oracle CloudFS para gerenciar e
armazenar todos os tipos de arquivos de bancos de dados, incluindo arquivos de propsito
geral. O Oracle CloudFS inclui o Oracle ACFS (Oracle Automatic Storage Management
Cluster File System) e o Oracle ADVM (Oracle ASM Dynamic Volume Manager).
O Oracle ACFS (Oracle Automatic Storage Management Cluster File System) um sistema
de arquivos escalvel e multiplataforma, e tecnologia de gerenciamento de armazenamento
que amplia a funcionalidade do Oracle ASM (Oracle Automatic Storage Management) para
suportar todos os arquivos do cliente. O Oracle ACFS suporta arquivos do Oracle Database e
arquivos de aplicativos, incluindo executveis, arquivos de dados do banco de dados,
arquivos de rastreamento de banco de dados, logs de alerta de banco de dados, relatrios de
aplicativos, BFILEs e arquivos de configurao. Outros arquivos com suporte so de vdeo,
udio, texto, imagens, desenhos de engenharia e outros dados de arquivos de aplicativos de
propsito geral. O Oracle ACFS compatvel com os padres POSIX para Linux e UNIX, e
com os padres Windows para Windows.
Um sistema de arquivos do Oracle ACFS se comunica com o Oracle ASM e est configurado
com o armazenamento do Oracle ASM, conforme exibido acima. O Oracle ACFS alavanca a
funcionalidade do Oracle ASM que permite:
Redimensionamento dinmico do sistema de arquivos do Oracle ACFS
Desempenho maximizado por meio do acesso direto ao armazenamento em grupo de
discos do Oracle ASM
Distribuio equilibrada do Oracle ACFS no armazenamento em grupo de discos do
Oracle ASM para um maior paralelismo de entrada/sada
Confiabilidade dos dados por meio dos mecanismos de proteo de espelhamento do
Oracle ASM
O Oracle ACFS fortemente integrado tecnologia do Oracle Clusterware, participando
diretamente das transies de estado de membro do cluster do Clusterware e do
gerenciamento HA (de alta disponibilidade) baseado em recursos do Oracle Clusterware. Alm
disso, as ferramentas de instalao, configurao, verificao e gerenciamento do Oracle foram
atualizadas para suportar o Oracle ACFS.

Oracle Flex ASM
O Oracle Flex ASM permite que uma instncia do Oracle ASM

seja executada em um servidor fsico separado dos servidores
do banco de dados.
Os clusters maiores de instncias do ASM podem suportar
mais clientes ao mesmo tempo que reduzem o consumo do
ASM por todo o sistema geral.
Com o Flex ASM, voc pode consolidar todos os requisitos de
armazenamento em um nico conjunto de grupos de discos.
Esses grupos de discos so montados e gerenciados por um
pequeno conjunto de instncias do Oracle ASM executadas em
um nico cluster.
Os clientes do ASM podem ser configurados com acesso
direto ao armazenamento ou as entradas/sadas podem ser
enviadas por meio de um pool de servidores de entrada/sada.
O Oracle Flex ASM permite que uma instncia do Oracle ASM seja executada em um
servidor fsico separado dos servidores do banco de dados. Com esta implantao, os
clusters maiores de instncias do Oracle ASM podem suportar mais clientes de banco de
dados ao mesmo tempo em que reduzem o consumo do ASM por todo o sistema geral.
Com o Oracle Flex ASM, voc pode consolidar todos os requisitos de armazenamento em
um nico conjunto de grupos de discos. Esses grupos de discos so montados e gerenciados
por um pequeno conjunto de instncias do Oracle ASM executadas em um nico cluster.
Voc pode especificar o nmero de instncias do Oracle ASM em um conjunto de
cardinalidade. O padro so trs instncias.
Ao usar o Oracle Flex ASM, voc pode configurar os clientes do Oracle ASM com acesso
direto ao armazenamento ou as entradas/sadas podem ser enviadas por meio de um pool de
servidores de entrada/sada.
Um cluster um conjunto de ns que fornecem servios de associao como membro de
grupos. Cada cluster tem um nome exclusivo globalmente. Todo cluster tem um ou mais ns
de Hub. Os ns de Hub tm acesso aos discos do Oracle ASM. Todo cluster tem pelo menos
uma rede privada e uma rede pblica. Se o cluster for usar o Oracle ASM para
armazenamento, tem pelo menos uma rede do Oracle ASM. Uma nica rede pode ser usada
igualmente como rede privada e rede do Oracle ASM. Por motivos de segurana, uma rede
do Oracle ASM nunca deve ser pblica. Somente pode haver uma configurao do Oracle
Flex ASM sendo executada em um cluster.
Recursos e Benefcios do ASM
Faz o striping de arquivos, e no de volumes lgicos

Fornece redundncia para cada arquivo
Permite rebalanceamento dinmico e reconfigurao
on-line de discos
Reduz o tempo de forma significativa para ressincronizar
uma falha temporria rastreando alteraes enquanto o
disco est off-line
Agiliza o rebalanceamento ajustvel
cluster-aware
Suporta a leitura de uma cpia espelhada no lugar da
cpia principal para clusters estendidos
instalado automaticamente como parte do Grid
Infrastructure
O ASM fornece striping e espelhamento sem que seja necessrio comprar um Gerenciador
de Volumes Lgicos de terceiros. O ASM divide um arquivo em partes e as distribui
igualmente entre todos os discos. O ASM usa uma tcnica de ndice para rastrear o
posicionamento de cada parte. As tcnicas de striping tradicionais usam funes
matemticas para fazer o striping de volumes lgicos completos. Uma vantagem exclusiva do
ASM que o espelhamento aplicado por arquivo, e no por volume. Portanto, o mesmo
grupo de discos pode conter uma combinao de arquivos protegidos por espelhamento ou
uma combinao de arquivos sem qualquer proteo.
Quando sua capacidade de armazenamento alterada, o ASM no faz um novo striping em
todos os dados. No entanto, em uma operao on-line, o ASM move os dados proporcionais
ao volume de armazenamento adicionado ou removido para redistribuir uniformemente os
arquivos e manter uma carga de entrada/sada balanceada entre os discos. Voc pode
ajustar a velocidade de operaes de rebalanceamento para aumentar ou diminuir a
velocidade e ajustar o impacto no subsistema de entrada/sada. Esse recurso tambm
permite a rpida ressincronizao de discos que podem sofrer uma falha temporria.
O ASM suporta todos os tipos de arquivos do banco de dados Oracle. O ASM suporta RAC
(Real Application Clusters) e elimina a necessidade de um Gerenciador de Volumes Lgicos
de clusters ou de um sistema de arquivos clusterizados. Em clusters estendidos, voc pode
definir uma cpia de leitura preferencial.
O ASM includo na instalao do Grid Infrastructure. Ele est disponvel nas instalaes
Enterprise Edition e Standard Edition.
Questionrio
Qual das seguintes afirmaes sobre o Grid Naming Service

no verdadeira?
a. O GNS um componente integrante do Grid Plug and
Play.
b. Cada n do cluster executa um processo mDNS (DNS
multicast).
c. O endereo IP virtual do GNS deve ser atribudo pelo
DHCP.
d. O subdomnio do cluster definido como um domnio
delegado.
Resposta: c
A afirmao c no est correta. O endereo VIP do GNS deve ser definido estaticamente.

Questionrio
O adaptador Ethernet pblico de cada n de cluster deve

suportar UDP ou RDS.
a. Verdadeiro
b. Falso
Resposta: b
Esta afirmao falsa. Na verdade, o adaptador Ethernet pblico de cada n de cluster deve
suportar TCP/IP. O adaptador privado deve suportar UDP ou RDS.

Sumrio
Nesta lio, voc aprendeu a:

Explicar os princpios e as finalidades dos clusters
Descrever a arquitetura do Oracle Clusterware
Descrever como o Grid Plug and Play afeta o Clusterware

Exerccio 1: Viso Geral
Este exerccio abrange a instalao do Oracle Grid

Infrastructure.

de Dados do RAC
Viso Geral e Arquitetura dos Bancos
Objetivos

Descrever as vantagens do Oracle RAC
Explicar a necessidade de recursos globais
Descrever a coordenao do cache global

Viso Geral do Oracle RAC
Um cluster compreende vrios servidores interconectados que

aparecem como um servidor aos usurios finais e aplicativos.
Com o Oracle Clusterware, o Oracle RAC permite clusterizar o
banco de dados Oracle.
O Oracle Clusterware permite que bancos de dados RAC e no
clusterizados usem a infraestrutura de alta disponibilidade Oracle.
O Oracle Clusterware permite criar um pool de armazenamento
clusterizado a ser usado por qualquer combinao de bancos de
dados Oracle RAC e no clusterizados.
Os bancos de dados Oracle no clusterizados tm um
relacionamento um para um entre o banco de dados e a instncia.
Os ambientes Oracle RAC tm um relacionamento um para um
entre o banco de dados e as instncias.
Um banco de dados Oracle RAC pode ter at 100 instncias.
Um cluster compreende vrios computadores ou servidores interconectados que aparecem

como um servidor aos usurios finais e aplicativos. O Oracle RAC permite clusterizar o banco
de dados Oracle. O Oracle RAC usa o Oracle Clusterware a fim de que a infraestrutura
vincule vrios servidores para que funcionem como um nico sistema.
O Oracle Clusterware uma soluo de gerenciamento de clusters porttil, integrada ao
Oracle Database. O Oracle Clusterware tambm um componente necessrio para usar o
Oracle RAC. Alm disso, o Oracle Clusterware permite que bancos de dados Oracle no
clusterizados e Oracle RAC usem a infraestrutura de alta disponibilidade Oracle. O Oracle
Clusterware permite criar um pool de armazenamento clusterizado a ser usado por qualquer
combinao de bancos de dados Oracle RAC e no clusterizados.
O Oracle Clusterware o nico clusterware de que voc precisa para a maioria das
plataformas nas quais o Oracle RAC funciona. Voc tambm poder usar clusterware de
outros fornecedores, caso seja certificado para Oracle RAC.
Os bancos de dados Oracle no clusterizados tm um relacionamento um para um entre o
banco de dados Oracle e a instncia. No entanto, os ambientes Oracle RAC tm um
relacionamento um para muitos entre o banco de dados e as instncias. Um banco de dados
Oracle RAC pode ter at 100 instncias, e todas acessam um banco de dados. Todas as
instncias de banco de dados devem usar a mesma interconexo, que tambm pode ser
usada pelo Oracle Clusterware.

Em termos estruturais, os bancos de dados Oracle RAC diferem dos bancos de dados Oracle
no clusterizados no sentido de que a instncia do banco de dados Oracle RAC tambm tem:
Pelo menos, um thread adicional de redo para cada instncia
Um tablespace de undo especfico instncia
O poder de processamento combinado dos vrios servidores pode fornecer mais throughput
e escalabilidade do Oracle RAC do que um nico servidor.

Arquitetura Tpica do Oracle RAC
Servidores de Aplicaes/Web
RH RH RH
Vendas Vendas Vendas
Call Center Call Center Call Center
Acesso ao Cliente do Oracle Net Services
Servio de RH Servio de Vendas Servio do Call Center
N 1 N 2 N 3
Instncia 1 Instncia 2 Instncia 3
O grfico no slide mostra como o Oracle RAC a opo do Oracle Database que fornece
uma nica imagem do sistema para vrios servidores acessarem um banco de dados Oracle.
No Oracle RAC, cada instncia do Oracle deve ser executada em um servidor separado.
Tradicionalmente, um ambiente do Oracle RAC est situado em um data center. Entretanto,
voc pode configurar o Oracle RAC em um cluster de distncia estendida, que uma
arquitetura que fornece recuperao extremamente rpida da falha em um llocal e permite
que todos os ns, em todos os locais, processem ativamente as transaes como parte de
um nico cluster do banco de dados. Em um cluster estendido, os ns no cluster so
normalmente dispersos, geograficamente, como entre duas clulas de incndio, entre duas
salas ou edifcios, ou entre dois data centers ou duas cidades diferentes. Por motivos de
disponibilidade, os dados devem ser localizados em ambos os locais, dessa forma
requerendo a implementao da tecnologia de espelhamento de disco para o
armazenamento.
Se voc preferir implementar esta arquitetura, deve avalisar se ela uma boa soluo para a
sua empresa, levando em considerao, especialmente, a distncia, latncia e o grau de
proteo que fornece. O Oracle RAC em clusters estendidos fornece maior disponibilidade do
que possvel com as configuraes locais do Oracle RAC, porm um cluster estendido
pode no preencher todos os requisitos de recuperao de desastres estipulados pela sua
empresa. Uma separao vivel fornece grande proteo contra alguns desastres (por
exemplo, falta de energia local ou inundao na sala dos servidores), porm no pode
fornecer proteo contra todos os tipos de paralisao. Para uma proteo abrangente contra
os desastres, incluindo a proteo contra danos e desastres regionais, a Oracle recomenda o
uso do Oracle Data Guard com o Oracle RAC.
RAC One Node

Alta Disponibilidade de Instncia nica
A opo Oracle RAC One Node uma instncia nica do
Oracle RAC em execuo em um n de um cluster.
Essa opo aumenta a flexibilidade oferecida pela Oracle
para consolidao.
Muitos bancos de dados podem ser consolidados em um
nico cluster com o mnimo de overhead, fornecendo, ao
mesmo tempo:
Benefcios de alta disponibilidade de proteo contra falhas
Aplicao dinmica de patches on-line
Upgrades dinmicos para o sistema operacional e o Oracle
Clusterware.
O Oracle RAC One Node suportado em todas as
plataformas nas quais o Oracle RAC certificado.
O Oracle RAC One Node uma opo da Oracle Database Enterprise Edition, disponvel
desde a Oracle Database 11g release 2 (11.2). O Oracle RAC One Node uma instncia nica
do Oracle RAC em execuo em um n de um cluster. Essa opo aumenta a flexibilidade
oferecida pela Oracle para consolidao. Muitos bancos de dados podem ser consolidados em
um nico cluster, com o mnimo de overhead, fornecendo, ao mesmo tempo, os benefcios de
alta disponibilidade de proteo contra falhas, aplicao dinmica de patches on-line, bem
como upgrades dinmicos para o sistema operacional e o Oracle Clusterware.
O Oracle RAC One Node suportado em todas as plataformas nas quais o Oracle RAC
certificado. O Oracle RAC One Node certificado na Mquina Virtual Oracle (VM Oracle). O
Oracle RAC One Node oferece estas vantagens:
Servios sempre disponveis do banco de dados de instncia nica
Failover de cluster incorporado para alta disponibilidade
Migrao de instncias em tempo real entre servidores
Aplicao dinmica de patches on-line e upgrades dinmicos para bancos de dados de
instncia nica
Upgrade on-line do Oracle RAC de instncia nica para o Oracle RAC de vrias instncias
Melhor consolidao de servidores de banco de dados
Virtualizao de servidor aperfeioada
Desenvolvimento de baixo custo e plataforma de teste para o Oracle RAC completo
Oracle RAC One Node
Com o reposicionamento de banco de dados on-line, uma

instncia RAC One Node pode ser reposicionada em outro
servidor. Isso poder ser til se:
O servidor atual estiver com poucos recursos
O servidor atual exigir operaes de manuteno, como
patches do sistema operacional
A mesma tcnica pode ser usada para reposicionar instncias
RAC One Node em servidores de alta capacidade a fim de
acomodar alteraes na carga de trabalho.
O SCAN (Single Client Access Name) permite que clientes se
conectem ao banco de dados, seja qual for o local do servio
Um banco de dados Oracle RAC One pode ser facilmente
dimensionado para um banco de dados Oracle RAC completo
se as condies o exigirem.
Usando o banco de dados on-line Oracle RAC One Node, voc pode reposicionar a instncia
Oracle RAC One Node em outro servidor, caso o servidor atual esteja com poucos recursos
ou requeira operaes de manuteno, como patches do sistema operacional. possvel
usar a mesma tcnica para reposicionar instncias Oracle RAC One Node em servidores de
alta capacidade (por exemplo, para acomodar alteraes na carga de trabalho), dependendo
dos recursos disponveis no cluster. Alm disso, o Resource Manager Instance Caging ou os
parmetros de otimizao de memria podem ser definidos dinamicamente para otimizar
ainda mais o posicionamento da instncia Oracle RAC One Node no novo servidor.
Usando o SCAN (Single Client Access Name) para estabelecer conexo com o banco de
dados, os clientes podem localizar o servio independentemente do n no qual ele esteja em
execuo. Dessa forma, o reposicionamento de uma instncia Oracle RAC One Node fica
ainda mais transparente ao cliente, dependendo da sua conexo.
Em bancos de dados do Oracle RAC One Node gerenciados por polticas, voc deve garantir
que os pools de servidor estejam configurados de forma que um servidor fique disponvel
para o banco de dados como fail over, no caso de seu n atual ficar indisponvel. Neste caso,
o n de destino para a relocao do banco de dados on-line deve estar situado no pool de
servidores no qual o banco de dados est situado. De outra forma, voc pode usar um pool
de servidores de tamanho 1 (um servidor no pool de servidores), configurando o tamanho
mnimo para 1 e a importncia alta o suficinete em relao a todos os outros pools de
servidor usados no cluster, a fim de garantir que, ao ocorrer falha de um servidor usado no
pool de servidores, um novo servidor de outro pool de servidores ou o pool de servidores
Livres seja realocado no pool de servidores, conforme necessrio.
Oracle RAC One Node e Oracle Clusterware
Por ser intimamente relacionado ao Oracle RAC, o Oracle

RAC One Node requer o Oracle Clusterware.
Voc pode criar um banco de dados do Oracle RAC One
Node com DBCA.
Voc pode criar bancos de dados do Oracle RAC One Node usando o DBCA (Database
Configuration Assistant), assim como qualquer outro banco de dados Oracle (os scripts
criados manualmente tambm so uma alternativa vlida). Os bancos de dados do Oracle
RAC One Node podem tambm ser o resultado de uma converso de um banco de dados
Oracle de uma nica instncia (usando rconfig, por exemplo) ou um banco de dados do
Oracle RAC. Normalmente, as ferramentas fornecidas pela Oracle registram o banco de
dados do Oracle RAC One Node com o Oracle Clusterware.
Nos bancos de dados com Oracle RAC One Node, voc deve configurar pelo menos um
servio dinmico de banco de dados (alm e oposto ao servio padro de banco de dados).
Ao usar um banco de dados com Oracle RAC One Node gerenciado por administrador, o
registro do servio executado assim como qualquer outro banco de dados com Oracle
RAC. Quando voc adiciona servios a um banco de dados Oracle RAC One Node
gerenciado por polticas, o SRVCTL no aceita informaes de posicionamento. Em vez
disso, ele configura esses servios usando o valor do atributo SERVER_POOLS.

Solues de Armazenamento "Cluster-Aware"
Os bancos de dados RAC usam uma

arquitetura com tudo compartilhado e
requerem um armazenamento
"cluster-aware" para todos os arquivos
de banco de dados.
O software do banco de dados Oracle RAC
gerencia o acesso ao disco e certificado para uso em uma
variedade de arquiteturas de armazenamento.
O Oracle Database oferece as seguintes opes de
armazenamento de arquivos para o Oracle RAC:
Oracle Automatic Storage Management
Oracle Cluster File System e OCFS2 (Linux)
Sistema de arquivos clusterizados certificados ou
gerenciador de volumes "cluster-aware"
Servidores de arquivos NFS certificados
Um banco de dados Oracle RAC um banco de dados com tudo compartilhado. Todos os
arquivos de dados, arquivos de controle, PFILEs e arquivos de redo log em ambientes Oracle
RAC devem residir em discos compartilhados "cluster-aware", de forma que todas as
instncias de banco de dados de clusters possam acessar esses componentes de
armazenamento. Como os bancos de dados Oracle RAC usam uma arquitetura com tudo
compartilhado, o Oracle RAC requer um armazenamento "cluster-aware" para todos os
arquivos de banco de dados.
No Oracle RAC, o software do Oracle Database gerencia o acesso ao disco e certificado
para uso em uma variedade de arquiteturas de armazenamento. Fica a seu critrio a forma
de configurao do seu armazenamento, mas voc deve usar uma soluo de
armazenamento "cluster-aware" suportada. O Oracle Database oferece as seguintes opes
de armazenamento de arquivos para o Oracle RAC:
Oracle ASM (Automatic Storage Management). A Oracle recomenda essa soluo para
gerenciar seu armazenamento.
Um sistema de arquivos clusterizados certificados, incluindo Oracle OCFS2 (Linux
somente) e IBM GPFS (IBM AIX somente).
Servidores de arquivos NFS (sistema de arquivos de rede) certificados

Oracle Cluster File System
um sistema de arquivos clusterizados de disco

compartilhado para Linux e Windows (OCFS2).
Oferece uma soluo aberta para o lado do sistema
operacional
O OCFS2 est disponvel para download na OTN:
http://oss.oracle.com/projects/ocfs2/ (Linux)
OCFS2 1.6 a verso mais recente e encontra-se
disponvel agora com o Oracle Linux 5.
Com esta release, h trs releases suportadas do sistema
de arquivos:
OCFS2 1.2
OCFS2 1.4
OCFS2 1.6
O OCFS2 um sistema de arquivos clusterizados de disco compartilhado, de finalidade

geral, para Linux, capaz de fornecer igualmente alto desempenho e alta disponibilidade. J
que ele fornece semntica de sistema de arquivos locais, pode ser usado com praticamente
todos os aplicativos. Os aplicativos cluster-aware podem fazer uso de entradas/sadas
paralelas de cache coerente a partir de mltiplos ns, a fim de dimensionar os aplicativos
com facilidade. Outros aplicativos podem fazer uso das facilidades do sistema de arquivos
para o aplicativo de execuo de fail-over, no caso da falha de um n.
O sistema de arquivos est sendo usado atualmente na virtualizao (Oracle VM) igualmente
no domnio de gerenciamento, para hospedar imagens de mquina virtual, e no domnio de
convidado, para permitir que os convidados do Linux compartilhem um sistema de arquivos.
Ele tambm est sendo usado em clusters de bancos de dados (Oracle RAC), clusters de
middleware (Oracle E-Business Suite), appliances (Business Intelligence Accelerator da
SAP), etc.
O OCFS2 1.6 a verso mais recente e agora est disponvel com o Oracle Linux 5. Ele
fornecido no pacote do Unbreakable Enterprise Kernel da Oracle. Com esta release, h trs
releases suportadas do sistema de arquivos, viz., OCFS2 1.2, OCFS2 1.4 e OCFS2 1.6.
O OCFS2 1.2 est disponvel com o Oracle Linux 4, OCFS2 1.4 com o Oracle Linux 5 (Kernel
Padro) e OCFS2 1.6 com o Oracle Linux 5 (Unbreakable Enterprise Kernel). O OCFS2 1.6
totalmente compatvel com OCFS2 1.4. Os usurios podem atualizar o cluster para a nova
release com um n por vez (upgrade dinmico).
Oracle RAC e Conectividade de Rede
Todos os ns em um ambiente RAC devem se conectar a,

pelo menos, uma Rede Local, denominada como rede
pblica.
O RAC requer conectividade de rede privada usada
exclusivamente para a comunicao entre os ns do
cluster.
A rede de interconexo uma rede privada que conecta
todos os servidores no cluster.
Voc deve configurar UDP para a interconexo de cluster
em plataformas Linux e Unix. Os clusters do Windows
usam TCP.
Todos os ns em um ambiente Oracle RAC devem ser conectar a, pelo menos, uma Local
Area Network (LAN) (normalmente denominada como a rede pblica) para permitir que os
usurios e aplicativos acessem o banco de dados. Alm da rede pblica, o Oracle RAC
requer conectividade de rede privada usada exclusivamente para a comunicao entre os
ns e as instncias de banco de dados em execuo nesses ns. Esta rede normalmente
denominada como a interconexo.
A rede de interconexo uma rede privada que conecta todos os servidores no cluster. A
rede de interconexo deve usar pelo menos um switch e um adaptador Gigabit Ethernet.
Voc deve configurar o UDP (User Datagram Protocol) para a interconexo do cluster, exceto
em um cluster do Windows. Os clusters do Windows usam o protocolo TCP. Em sistemas
Linux e UNIX, voc pode configurar o Oracle RAC para usar os protocolos UDP ou RDS
(Reliable Data Socket) para a comunicao entre instncias na interconexo. O Oracle
Clusterware usa a mesma interconexo do protocolo UDP, porm no pode ser configurado
para usar o RDS.
Uma conectividade de rede adicional necessria ao usar o NAS (Network Attached
Storage). O network attached storage pode ser tpico de dispositivos NAS, como filers NFS,
ou pode ser armazenamento conectado por meio de Fibre Channel sobre IP, por exemplo.
Este canal adicional de comunicao da rede deve ser independente dos outros canais de
comunicao usados pelo Oracle RAC (a comunicao da rede pblica e privada). Se a
comunicao de rede de armazenamento precisar ser convergida com um dos outros canais
de comunicao da rede, voc deve garantir que a comunicao relacionada ao
armazenamento receba a maior prioridade.
Vantagens da Utilizao do RAC
Alta disponibilidade: N sobrevivente e falhas em

instncias
Escalabilidade: adicione mais ns quando precisar
posteriormente.
Pague medida que as suas necessidades aumentam:
pague somente o que necessita hoje
Recursos avanados de computao em grade:
Crescimento e perda sob demanda
Adio de servidores por meio de operaes simplificadas
Gerenciamento automtico da carga de trabalho dos
servios
O Oracle RAC (Real Application Clusters) permite a alta utilizao de um cluster de

servidores modulares padro de baixo custo, como blades.
O ambiente RAC oferece gerenciamento automtico da carga de trabalho dos servios. Os
servios so grupos ou classificaes de aplicaes que compreendem business
components correspondentes a cargas de trabalho de aplicaes. No ambiente RAC, os
servios possibilitam operaes contnuas e ininterruptas do banco de dados e permitem
suporte a vrios servios em vrias instncias. Voc designa os servios para serem
executados em uma ou mais instncias, e instncias alternativas podem funcionar como
instncias de backup. Se uma instncia principal falhar, o Clusterware move os servios da
instncia com falha para uma instncia alternativa sobrevivente. Ele tambm far
automaticamente o balanceamento da carga das conexes entre as instncias que
hospedam um servio.
O RAC permite que vrios computadores de baixo custo funcionem como um nico
computador robusto para processamento de bancos de dados, proporcionando a nica
alternativa vivel a SMP de larga escala para todos os tipos de aplicaes.
O ambiente RAC, que baseado em uma arquitetura de discos compartilhados, pode crescer
ou diminuir conforme a demanda, sem a necessidade de particionar dados artificialmente
entre os servidores do cluster. O RAC tambm permite adicionar servidores a um cluster por
meio de uma operao muito simples. Portanto, possvel incluir um servidor em um banco
de dados ou remov-lo do banco de dados com facilidade.
Clusters e Escalabilidade
Modelo SMP Modelo RAC
Armazenamento
Memria
compartilhado
Cache Cache SGA SGA
CPU CPU CPU CPU BGP BGP BGP BGP
Coerncia de cache Cache fusion
BGP (processo de background)
Se a sua aplicao tiver uma escalabilidade transparente em mquinas SMP, provvel que
ela tenha boa escalabilidade no RAC, sem que necessrio fazer alteraes no cdigo da
aplicao.
O ambiente RAC elimina a instncia do banco de dados, e o prprio n, como um nico
ponto de falha e assegura a integridade do banco de dados no caso de falhas.
Aqui temos alguns exemplos de escalabilidade:
Permitir mais processos batch simultneos.
Permitir graus maiores de paralelismo e mais execues paralelas.
Permitir grandes aumentos no nmero de usurios conectados em sistemas OLTP
(Online Transaction Processing).
Com o Oracle RAC, voc pode construir um cluster que atenda s suas necessidades, seja o
cluster composto de servidores onde cada servidor seja um servidor padro com duas CPUs
ou clusters em que os servidores tenham 32 ou 64 CPUs em cada servidor. O recurso de
execuo paralela do Oracle permite que uma nica instruo SQL seja dividida em vrios
processos, sendo que cada processo conclui um subconjunto do trabalho. Em um ambiente
Oracle RAC, voc pode definir os processos paralelos para que ocorram somente na
instncia em que o usurio estiver conectado ou para que sejam executados em vrias
instncias no cluster.

Nveis de Escalabilidade
Hardware: operaes de entrada/sada em disco

Comunicao entre os ns: alta largura de banda e baixa
latncia
Sistema operacional: nmero de CPUs
Sistema de gerenciamento de bancos de dados:
sincronizao
Aplicao: design
A implementao bem-sucedida de bancos de dados de cluster requer uma escalabilidade ideal

em quatro nveis:
Escalabilidade de hardware: a interconectividade a chave para a escalabilidade de
hardware, que depende muito de uma alta largura de banda e de uma baixa latncia.
Escalabilidade do sistema operacional: os mtodos de sincronizao no sistema
operacional podem determinar a escalabilidade do sistema. Em alguns casos, a
escalabilidade potencial do hardware perdida por causa da incapacidade de o sistema
operacional tratar vrias solicitaes de recursos simultaneamente.
Escalabilidade do sistema de gerenciamento de bancos de dados: um fator importante
nas arquiteturas paralelas determinar se o paralelismo ser afetado internamente ou por
processos externos. A resposta para essa questo afeta o mecanismo de sincronizao.
Escalabilidade da aplicao: as aplicaes devem ser especificamente projetadas para
serem escalveis. Gargalos ocorrem em sistemas em que todas as sesses atualizam os
mesmos dados na maior parte do tempo. Observe que esse procedimento no especfico
do ambiente RAC e tambm ocorre em sistema de uma instncia nica.
importante lembrar que, se qualquer uma das reas acima no for escalvel (no importa o
quanto as outras reas sejam escalveis), o processamento em paralelo do cluster talvez no
seja bem-sucedido. Uma causa tpica de falta de escalabilidade um recurso comum
compartilhado que precisa ser acessado com frequncia.
Isso faz com que as operaes que deveriam ser paralelas passem a ser seriais por causa
desse gargalo. Uma alta latncia na sincronizao aumenta o custo da sincronizao,
contrapondo-se, assim, s vantagens da paralelizao. Essa uma limitao geral, e no uma
limitao especfica do ambiente RAC.
Escalabilidade e Agilizao
Sistema original
Hardware Horrio 100% das tarefas
Escalabilidade do sistema de cluster Agilizao do sistema de clusters
Hardware Horrio At
200% Hardware
das At
100%
Hardware tarefas 300% das tarefas
Horrio das
Hardware
tarefas Horrio/2
Hardware
Horrio
Escalabilidade a capacidade de sustentar os mesmos nveis de desempenho (tempo de

resposta) quando a carga de trabalho e os recursos aumentam proporcionalmente:
Escalabilidade =(volume paralelo) / (volume original)
Por exemplo, se 30 usurios consomem cerca de 100% da CPU durante o processamento
normal, a adio de mais usurios causaria uma lentido no sistema em decorrncia da
disputa por ciclos limitados da CPU. No entanto, adicionando CPUs, possvel suportar
usurios extras sem prejudicar o desempenho.
A agilizao o efeito de aplicar um nmero cada vez maior de recursos a um volume fixo de
trabalho para conseguir uma reduo proporcional nos tempos de execuo:
Agilizao = (tempo original) / (tempo paralelo)
A agilizao resulta na disponibilidade de recursos para outras tarefas. Por exemplo, se as
consultas normalmente levam dez minutos para serem processadas e a execuo em
paralelo reduz o tempo para cinco minutos, as consultas adicionais podem ser executadas
sem introduzir a disputa que ocorreria se elas precisassem ser executadas simultaneamente.

Agilizao/Escalabilidade e Cargas de Trabalho
Carga de trabalho Agilizao Escalabilidade
OLTP e Internet No Sim
DSS com consulta paralela Sim Sim
Batch (misto) Possvel Sim
O tipo de carga de trabalho determina se a escalabilidade ou a agilizao pode ser obtida

com processamento paralelo.
Os ambientes de aplicao OLTP (Online Transaction Processing) e a Internet so
caracterizados por transaes curtas que no podem ser fragmentadas e, portanto, no
possvel obter agilizao. Contudo, disponibilizando mais recursos, possvel suportar um
volume maior de transaes sem comprometer a resposta.
DDSs (Decision Support Systems) e opes de consultas paralelas podem obter agilizao,
bem como escalabilidade, porque suportam tarefas grandes sem causar conflitos na
demanda por recursos. A capacidade de consulta paralela no banco de dados Oracle pode
ser aproveitada para diminuir o tempo total de processamento de consultas de longa
durao e para aumentar o nmero de consultas que podem ter execuo simultnea.
Em um ambiente com carga mista de trabalho de DSS, OLTP e aplicaes de gerao de
relatrios, a escalabilidade pode ser obtida executando-se diferentes programas em
diferentes componentes de hardware. A agilizao possvel em um ambiente batch, mas
talvez seja necessrio recriar os programas para que seja possvel usar os recursos de
processamento paralelo.

Throughput de Entrada/Sada Balanceado: Exemplo
Cada mquina tem 2 CPUs:

2 200 MB/s 4 = 1600 MB/s
Cada mquina tem 2 HBAs:
HBA1
HBA2
HBA1
HBA2
HBA1
HBA2
HBA1
HBA2
8 200 MB/s = 1600 MB/s
Cada switch precisa suportar 800 MB/s

Switch de FC para garantir um throughput total do sistema
de 1600 MB/s.
Cada array de disco

Array de Array de Array de Array de Array de Array de Array de Array de tem uma controladora
disco 1 disco 2 disco 3 disco 4 disco 5 disco 6 disco 7 disco 8 de 2 Gb:
8 200 MB/s =
1600 MB/s
Para garantir que um sistema fornea a demanda de entrada/sada necessria, todos os

seus componentes de sistema no caminho de entrada/sada precisaro ser coordenados
para funcionarem juntos.
O link mais frgil determina o throughput de entrada/sada.
esquerda, voc v uma figura de alto nvel de um sistema. Esse um sistema com quatro
ns, dois HBAs (Adaptadores de Barramento do Host) por n, dois switches de Fibre
Channel conectados a quatro arrays de discos cada um. Os componentes no caminho de
entrada/sada so HBAs, cabos, switches e arrays de discos. O desempenho depender do
nmero e da velocidade dos HBAs, da velocidade do switch, da quantidade de controladoras
e da velocidade dos discos. Se algum desses componentes for subdimensionado, o
throughput do sistema ser determinado por esse componente. Supondo que voc tenha um
HBA de 2 Gb, os ns podero ler aproximadamente 8 200 MB/s = 1,6 GBytes/s.
Entretanto, supondo que cada array de discos tenha uma controladora, todos os 8 arrays
tambm podero fazer 8 200 MB/s = 1,6 GBytes/s. Portanto, cada switch de Fibre Channel
tambm precisar fornecer, no mnimo, 2 GBit/s por porta, para um throughput total de 800
MB/s. Os dois switches fornecero, portanto, os 1,6 GBytes/s necessrios.
Observao: ao dimensionar um sistema, leve em considerao tambm os limites do
sistema. Por exemplo, o nmero de slots de barramento por n limitado e talvez precise ser
compartilhado entre os HBAs e as placas de rede. Em alguns casos, placas de portas duais
estaro disponveis se o nmero de slots estiver esgotado. O nmero de HBAs por n
determina o nmero mximo de switches de Fibre Channel. E o nmero total de portas em
um switch limita o nmero de HBAs e controladoras de disco.
A Necessidade de Recursos Globais

SGA1 SGA2 SGA1 SGA2
1008
1008 1008
1 2
SGA1 SGA2 SGA1 SGA2

1009 1008 1009
Atualizaes
perdidas!
1008 1008
4 3
Em ambientes com uma nica instncia, o bloqueio coordena o acesso a um recurso comum,
como uma linha de uma tabela. O bloqueio impede que dois processos alterem o mesmo
recurso (ou linha) ao mesmo tempo.
Em ambientes RAC, a sincronizao entre ns fundamental porque ela mantm a
coordenao adequada entre os processos nos diferentes ns, impedindo que eles alterem o
mesmo recurso ao mesmo tempo. A sincronizao entre ns assegura que cada instncia
veja a verso mais recente de um bloco no seu cache de buffer.
O slide mostra o que pode acontecer na ausncia da coordenao de caches. O RAC
impede esse problema. A coordenao de recursos executada pelo cache do buffer, o
cache da biblioteca, o cache da linha e o cache de resultados, e ser explorada em lies
posteriores.

Requisito de Memria Adicional para RAC

Heurstica para casos de escalabilidade:
15% a mais para shared pool
10% a mais para cache de buffer
Cache de buffer menor por instncia para a distribuio
da carga de trabalho de uma nica instncia entre vrias
outras
Valores atuais:
SELECT resource_name,
current_utilization,max_utilization
FROM v$resource_limit
WHERE resource_name like 'g%s_%';
SELECT * FROM v$sgastat
WHERE name like 'g_s%' or name like 'KCL%';
A memria especfica para RAC alocada em sua maior parte no shared pool no momento
da criao da SGA. Como os blocos podem estar armazenados no cache das instncias,
voc dever considerar os caches de buffer maiores.
Portanto, ao migrar o Oracle Database de uma nica instncia para o RAC, mantenha os
requisitos de carga de trabalho por instncia iguais situao em que h uma instncia
nica; sero necessrios cerca de 10% de espao a mais para cache de buffer e 15% a mais
para shared pool durante a execuo em um ambiente RAC. Esses valores so heursticos,
baseados na experincia com o dimensionamento do ambiente RAC. Contudo, esses valores
so, na maioria, os limites mais altos.
Se usar o recurso recomendado para gerenciamento automtico de memria como ponto de
partida, voc poder adotar esses valores no parmetro de inicializao SGA_TARGET.
Entretanto, lembre-se de que os requisitos de memria por instncia so menores quando a
mesma populao de usurios distribuda entre vrios ns.
O uso de recursos pode ser monitorado por meio de consulta s entradas GCS e GES nas
colunas CURRENT_UTILIZATION e MAX_UTILIZATION da view V$RESOURCE_LIMIT de
cada instncia. Voc poder monitorar o uso exato dos recursos da memria especfica para
RAC do shared pool consultando V$SGASTAT conforme mostrado no slide.

Execuo Paralela com RAC
Em um ambiente RAC, uma instruo SQL executada

paralelamente pode ser executada em todos os ns do cluster.
Para a execuo paralela efetiva entre ns, a interconexo deve
ser dimensionada de forma apropriada.
A execuo paralela entre ns pode aumentar o trfego da
interconexo
Se a largura de banda da interconexo for menor do que o
subsistema de disco, a execuo paralela deve se limitar a um
conjunto menor de ns.
O parmetro PARALLEL_FORCE_LOCAL usado apra limitar a
execuo paralela entre ns.
Ao serem definidos como TRUE, os processos paralelos do servidor
podem ser executados no mesmo n em que a instruo SQL foi
iniciada.
Os servios podem ser usados para limitar o nmero de
instncias que participam de uma operao SQL paralela.
Por default, em um ambiente Oracle RAC, uma instruo SQL executada paralelamente pode
ser executada em todos os ns do cluster. Para que esta execuo paralela entre ns ou por
todos os ns seja realizada, a interconexo no ambiente Oracle RAC deve ser dimensionada
da forma apropriada, pois a execuo paralela enre ns pode resultar em muito trfego
interconexo. Se a interconexo tiver uma largura de banda consideravelmente menor em
comparao com a largura de banda de entrada/sada desde o servidor at o subsistema de
armazenamento, pode ser melhor restringir a execuo paralela para um nico n ou para
um nmero limitado de ns. A execuo paralela entre ns no dimensionada com uma
interconexo subdimensionada.
Para limitar a execuo paralela entre ns, voc pode controlar a execuo paralela em um
ambiente Oracle RAC usando o parmetro de inicializao PARALLEL_FORCE_LOCAL.
Definindo este parmetro como TRUE, os processos do servidor paralelo somente podem ser
executados no mesmo n do Oracle RAC em que a instruo SQL foi iniciada.
No Oracle Real Application Clusters, os servios so usados para limitar o nmero de
instncias que participam de uma operao SQL paralela. O servio padro inclui todas as
instncias disponveis. Voc pode criar qualquer nmero de servios, cada qual consistindo
em uma ou mais instncias. Os servidores de execuo paralela devem ser usados apenas
em instncias que sejam membros do servio especificado. Quando o parmetro
PARALLEL_DEGREE_POLICY definido como AUTO, o Oracle Database automaticamente
decide se uma instruo deve ser executada em paralelo ou no, e qual grau de paralelismo
(DOP) deve usar.

O Oracle Database tambm determina se a instruo pode ser executada imediatamente ou
se enfileirada at que mais recursos do sistema estejam disponveis. Finalmente, o Oracle
Database decide se a instruo pode tirar partido ou no da memria agregada do cluster.

Sumrio

Descrever as vantagens do Oracle RAC
Explicar a necessidade de recursos globais
Descrever a coordenao do cache global

Instalando e Configurando o Oracle RAC
Objetivos

Instalar o software do banco de dados Oracle
Criar um banco de dados clusterizado
Executar tarefas posteriores criao do banco de dados
Converter um banco de dados Oracle de instncia nica
em RAC

Instalando o Software do Oracle Database

$ /stage/database/Disk1/runInstaller
O Oracle OUI (Universal Installer) usado para instalar o software Oracle Database 12c.
Inicie o OUI executando o comando runInstaller no diretrio-raiz do CD-ROM do
Oracle Database 12c ou na rea de preparao do software. Voc pode usar a janela
Configure Security Updates para especificar um endereo de e-mail e receber atualizaes
de segurana diretamente do Oracle Support medida que elas ocorrem. Tambm
possvel optar por no receber esses alertas. Se desejar receb-los, fornea seu endereo
de e-mail e a senha do Oracle Support e clique em Next.
A pgina Download Software Updates permite a voc incluir atualizaes ou patches do
software do banco de dados na instalao. A pgina permite efetuar o download deles
diretamente ou usar atualizaes baixadas anteriormente. Tambm possvel optar por
ignorar totalmente atualizaes do software.
A janela Select Installation Option permite criar e configurar um banco de dados, instalar
somente o software do banco de dados ou fazer o upgrade de um banco de dados existente.
Selecione a opo "Install database software only" e clique em Next.

Na janela Grid Installation Options, selecione "Real Application Clusters database installation"
e todos os ns do cluster no qual o software deve ser instalado, na pgina Select List of
Nodes. Se o SSH do usurio oracle no tiver sido configurado, clique em SSH Connectivity
e, em seguida, fornea a senha do usurio oracle e clique em Setup. Se o SSH j tiver sido
configurado, clique em Test. Quando terminar, clique em Next para continuar. Na janela
"Select product languages", selecione os idiomas desejados na lista Available Languages e
clique na seta para a direita para promov-los para a lista Selected Languages. Clique em
Next para continuar.
Na janela "Select database edition" (no mostrada no slide), voc determina se ser
instalada a Enterprise Edition ou a Standard Edition. Selecione a opo Enterprise Edition e
clique em Next para continuar.

Na pgina Select Database edition, voc pode optar por instalar a Enterprise Edition ou a
Standard Edition. Clique em Next para continuar.
Na janela Specify Installation Location, se ainda no tiver feito, fornea um valor para
ORACLE_BASE. O local da ORACLE_BASE padro /u01/app/oracle, desde que o
software RDBMS esteja sendo instalado pela conta oracle. A seo Software Location da
janela permite especificar um valor para o local ORACLE_HOME. O local da ORACLE_HOME
padro /u01/app/oracle/product/12.1.0/dbhome_1. Aceite o caminho sugerido ou
informe o seu prprio local. Aps digitar as informaes, verifique se elas esto corretas e
clique no boto Next para continuar. Na janela "Privileged operating system groups",
selecione o grupo de sistema operacional que atuar como o grupo OSDBA e o grupo que
agir como o grupo OSOPER. Alm disso, voc pode designar grupos do sistema operacional
para o grupo de backup e recuperao do banco de dados, o grupo administrativo Data
Guard e o grupo administrativo de gerenciamento de chaves de criptografia. Clique em Next
para continuar.

A janela "Perform Prerequisite Checks" verifica os requisitos do sistema operacional para que
a instalao seja bem-sucedida. Esses requisitos incluem:
Verificao do sistema operacional certificado
Parmetros do kernel de acordo com as necessidades do software do Oracle Database
Packages e revises de correo necessrios para o sistema operacional
Aps cada verificao bem-sucedida, o Status da verificao em questo indicar
Succeeded. Os testes que falharem tambm sero informados nessa rea. Se ocorrerem
falhas em qualquer um dos testes, clique no boto "Fix & Check Again". O Installer gerar
scripts de correo para corrigir as deficincias do sistema, se possvel. Execute os scripts
de acordo com as instrues do Installer. Os testes sero executados novamente aps a
concluso da execuo dos scripts. Quando todos os testes forem bem-sucedidos, clique no
boto Next para continuar. Na janela Summary, verifique as configuraes globais e clique
em Finish.

Ao final da instalao, o OUI exibir outra janela, solicitando que voc execute os scripts
root.sh nos ns escolhidos para a instalao. Siga as instrues para executar os scripts.
Quando terminar, clique no boto OK para fechar a janela Execute Configuration Scripts e
retorne para a janela Finish. Clique em Close para terminar a instalao e fechar o OUI.

Criando o Banco de Dados Clusterizado
$ cd /u01/app/oracle/product/12.1.0/dbhome_1/bin
$ ./dbca
Para criar o banco de dados clusterizado, altere o diretrio para $ORACLE_HOME/bin no n

de instalao e execute o DBCA (utilitrio assistente de configurao de banco de dados) da
seguinte forma:
$ cd /u01/app/oracle/product/12.1.0/dbhome_1/bin
$ ./dbca
A janela Database Operation ser exibida primeiro. Voc deve selecionar a operao do
banco de dados a ser realizada Selecione Create Database e clique em Next. A janela
Creation Mode ser exibida. Voc pode optar por criar um banco de dados usando a
configurao padro ou pode optar por Advanced Mode. Selecione Advanced Mode e clique
em Next para continuar.

Seleo do Tipo de Banco de Dados
Em seguida, a tela Database Templates exibida. O menu pull-down Database Type

permite escolher trs opes: criar um banco de dados Oracle RAC, um banco de dados
Oracle RAC One Node ou um banco de dados com uma nica instncia. O menu pull-down
Configuration Type permite escolher as configuraes de banco de dados Policy Managed ou
Administration Managed.
Os bancos de dados RAC gerenciados por administrador especificam uma lista de ns de
cluster nos quais as instncias do RAC sero executadas. Os servios tambm podem ser
especificados e associados a ns alternativos ou de preferncia. H uma associao
explcita entre os servios e instncias do banco de dados e os ns de cluster.
Policy-based management elimina a associao explcita entre os servios, as instncias e
os ns de cluster. Ele introduz o conceito de pools de servidores, que so divises lgicas de
um cluster dinamicamente posicionadas com base na importncia relativa. Os servios de
banco de dados so associados a pools de servidores, e as instncias do RAC so
automaticamente iniciadas para atender ao servio para associaes de pools de servidores.
Especifique em qual pool de servidores o recurso de banco de dados ser executado e o
nmero de instncias necessrias (cardinalidade). O Oracle Clusterware responsvel por
colocar o recurso do banco de dados em um servidor. Pools de servidores so divises
lgicas de um cluster em pools de servidores, alocadas em bancos de dados host ou outros
aplicativos. Os pools de servidores so gerenciados com os comandos crsctl e srvctl.
Os nomes devem ser exclusivos nos recursos definidos para o cluster.
A ferramenta DBCA oferece vrios tipos de banco de dados predefinidos para a sua escolha,
dependendo das suas necessidades. Os modelos incluem:
General Purpose or Transaction Processing
Custom Database
Data Warehouse
No exemplo do slide, a opo "General Purpose or Transaction Processing" est escolhida.
Clique em Next para continuar.

Identificao do Banco de Dados
Na janela Database Identification, voc deve escolher o nome do banco de dados global. O
nome de banco de dados global pode ter at 30 caracteres e deve comear com um
caractere alfabtico. O nome do banco de dados global tem o formato
database_name.database_domain. Alm disso, voc pode optar por criar um banco de
dados continer clusterizado, marcando a caixa de seleo Create as a Container Database.
Pode optar por criar um banco de dados continer vazio ou cri-lo com um ou mais bancos
de dados plugveis. Se preferir criar um banco de dados plugvel, ter que fornecer um
nome de servio exclusivo. Quando terminar, clique em Next para continuar.
Na pgina Database Placement, pode optar por criar um novo nome do pool de servidores
para o seu banco de dados ou pode preferir usar um pool existente para colocar o banco de
dados. Se voc criar um novo pool de servidores, ter que definir a cardinalidade. Clique em
Next para continuar.

Opes de Gerenciamento de
Bancos de Dados Clusterizado
A janela Management Options exibida. Em ambientes clusterizados pequenos, voc pode

preferir gerenciar seu cluster com Enterprise Manager Database Express. Para fazer isto,
marque a caixa de seleo "Configure Enterprise Manager (EM) database Express". Voc
tambm pode optar por executar verificaes de CVU periodicamente.
Se o Grid Control estiver instalado na sua rede, voc poder selecionar a opo "Register
with Enterprise Manager (EM) Cloud Control". O EM Cloud Control pode simplificar o
gerenciamento de bancos de dados em grandes disponibilizaes empresariais. Se voc
selecionar Enterprise Manager, ter que fornecer o nome de host do OMS e o nmero da
porta do OMS. Voc tambm deve fornecer credenciais de login para o usurio administrativo
do EM.
Se desejar usar o Grid Control para gerenciar seu banco de dados e ainda no tiver instalado
nem configurado um servidor do Grid Control, no clique em nenhum mtodo de
gerenciamento. Quando terminar de fazer as selees, clique em Next para continuar.

Senhas para Proprietrios de

Esquemas de Banco de Dados
Em seguida, a janela Database Credentials exibida. Ao configurar o banco de dados, voc

deve fornecer senhas para as contas de usurio criadas pelo DBCA. Voc pode usar a
mesma senha para todas essas contas privilegiadas selecionando a opo "Use the Same
Administrative Password for All Accounts". Digite a senha no campo Password e digite-a
novamente no campo Confirm Password.
Como alternativa, voc pode optar por definir senhas distintas para os usurios privilegiados.
Para isso, selecione a opo "Use Different Administrative Passwords", digite a senha no
campo Password e, em seguida, digite-a novamente no campo Confirm Password. Repita
essa operao para cada usurio listado na coluna User Name. Clique em Next para
continuar.

Locais de Armazenamento
Na janela Database File Locations, indique onde os arquivos do banco de dados sero
armazenados. possvel selecionar o tipo de armazenamento na lista drop-down. Os tipos
de armazenamento compartilhados e detectados (e suportados) esto disponveis aqui. Voc
pode optar por usar um modelo-padro para a localizao dos arquivos, pode usar um local
comum ou o OMF (Oracle Managed Files). Este banco de dados clusterizado usa arquivos
gerenciados pelo Oracle e ASM. Portanto, selecione a opo Use Oracle-Managed Files e
digite o nome do grupo de discos no campo Database Area. Como alternativa, voc pode
clicar no boto Browse para indicar o local onde sero criados os arquivos do banco de
dados.
Na janela Recovery Related Files, voc pode selecionar o arquivamento de redo log
marcando Enable Archiving. Se estiver usando armazenamentos ASM ou CFS, voc tambm
poder selecionar o tamanho para rea de recuperao flash. O tamanho padro da rea
5025 MB, mas voc poder alterar esse nmero caso no atenda s suas necessidades. Se
voc estiver usando o ASM e um nico grupo de discos, o grupo de discos ASM ser o
padro para a rea de recuperao rpida. Se mais de um grupo de discos tiver sido criado,
voc poder especificar isso aqui. Quando acabar, clique em Next, e a janela Database
Content ser exibida.

Contedo do Banco de Dados
Na janela Database Content, voc poder optar por instalar os Exemplos de Esquemas
includos na distribuio do banco de dados. Na seo Custom Scripts, voc poder optar
por executar os seus prprios scripts como parte do processo de criao do banco de dados.
Clique na tab Database Vault & Label Security para configurar esses itens. Se preferir
configur-los, ter que fornecer credenciais de login para o proprietrio do Database Vault.
Tambm poder optar por criar um gerenciador de contas separadas aqui. Marque a caixa de
seleo Configure Label Security para configurar Label Security. Quando terminar, clique em
Next para continuar para a prxima janela.

Parmetros de Inicializao
Na janela Initialization Parameters, possvel definir parmetros importantes para o banco de

dados. Os parmetros so agrupados em quatro tabs:
Memory
Sizing
Character Sets
Connection Mode
Na pgina com a tab Memory, voc pode definir parmetros relacionados a alocao de
memria, incluindo shared pool, cache de buffer, Java pool, large pool e tamanho da PGA. O
Automatic Memory Management o mtodo de gerenciamento de memria preferencial e
pode ser selecionado aqui. Na pgina com a tab Sizing, voc pode ajustar o tamanho do
bloco de banco de dados. Alm disso, possvel definir o nmero de processos que podem
ser simultaneamente conectados com o banco de dados.
Clique na tab Character Sets para alterar o conjunto de caracteres do banco de dados. Voc
tambm pode selecionar o idioma default e o formato de data. Na pgina com a tab
Connection Mode, possvel escolher o tipo de conexo usado pelos clientes para
estabelecer conexo com o banco de dados. O tipo default Dedicated Server Mode. Se
quiser usar a opo Oracle Shared Server, clique no boto Shared Server Mode. Se quiser
verificar os parmetros que no fazem parte dessas quatro tabs, clique no boto All
Initialization Parameters. Clique no boto Use Automatic Memory Management e clique no
boto Next para continuar.
Criar o Banco de Dados
A janela Creation Options ser exibida. Voc pode optar por criar o banco de dados ou salvar
a sesso do DBCA como um script de criao de banco de dados marcando a caixa de
seleo correspondente. Marque a caixa de seleo Create Database e clique no boto
Finish. O DBCA exibir a tela Summary. Essa ltima oportunidade para voc verificar todas
as opes, parmetros, etc. escolhidos para criar o banco de dados.
Verifique esses dados. Quando estiver pronto para continuar, feche a janela Summary
clicando no boto OK.

Monitorando o Andamento
A janela Progress Monitor ser exibida em seguida. Alm de mostrar a velocidade da criao
do banco de dados, essa pgina mantm voc informado, em tempo real, sobre tarefas
especficas executadas pelo DBCA. Quando o andamento da criao do banco de dados
atingir 100%, o DBCA exibir uma caixa de dilogo anunciando a concluso do processo de
criao. O DBCA mostrar a localizao do arquivo de log da instalao, a localizao do
arquivo de parmetros e o URL do Enterprise Manager. Clique no boto Password
Management para gerenciar as contas do banco de dados criadas pelo DBCA.

Tarefas de Ps-Instalao
Fazer download e instalar as atualizaes necessrias
de patches.
Verificar a configurao do banco de dados clusterizado.
$ srvctl config database -db orcl
Database unique name: orcl
Database name: orcl
Oracle home: /u01/app/oracle/product/12.1.0/dbhome_1
Oracle user: oracle
Spfile: +DATA/orcl/spfileorcl.ora
Password file: +DATA/orcl/orapworcl
Domain: cluster01.example.com
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: orcldb
Database instances:
Disk Groups:
Mount point paths:
Services:
Type: RAC
Start concurrency:
Stop concurrency:
Database is policy managed
Aps a criao bem-sucedida do banco de dados clusterizado, execute o seguinte comando

para verificar a configurao do Oracle Cluster Registry no ambiente RAC recm-instalado:
$ srvctl config database -db db_name

Processos de Background Especficos ao Oracle RAC
ACMS: arquivo de Controle Atmico para o Servio de Memria

GTX[0-j]: processo Global Transaction
LMON: Monitor do Servio de Enfileiramento Global
LMD: daemon do Servio de Enfileiramento Global
LMS: processo Global Cache Service
LCK0: processo Instance Enqueue
LMHB: monitor de Heartbeat do Servio de
Enfileiramento/Cache Global
PING: processo Interconnect Latency Measurement
RCBG: processo Result Cache Background
RMSn: processo Oracle RAC Management
RSMN: processo Remote Slave Monitor
Um banco de dados Oracle RAC tem os mesmos processos e estruturas de memria que um
banco de dados Oracle de instncia nica e processos e estruturas de memria adicionais
especficos ao Oracle RAC. O servio de cache global e os processos do servio de
enfileiramento global, bem como o GRD (Global Resource Directory) colaboram para ativar o
cache fusion. Os processos do Oracle RAC e seus identificadores so os seguintes:
Atomic Control File to Memory Service (ACMS): em um ambiente RAC, o processo
por instncia do ACMS um agente que contribui para garantir que uma atualizao da
memria SGA distribuda seja globalmente confirmada em caso de xito ou cancelada
globalmente em caso de falha.
Global Transaction Process (GTX[0-j]): os processos GTX[0-j] fornecem suporte
transparente a transaes globais XA em um ambiente RAC. O banco de dados ajusta
automaticamente o nmero desses processos com base na carga de trabalho das
transaes XA globais.
Global Enqueue Service Monitor (LMON): o processo LMON monitora os
enfileiramentos e recursos globais no cluster e executa operaes de recuperao de
enfileiramentos globais.
Global Enqueue Service Daemon (LMD): o processo LMD gerencia solicitaes de
recursos remotos de chegada em cada instncia.

Global Cache Service Process (LMS): o processo LMS mantm registros dos status
dos arquivos de dados e de cada bloco em cache registrando informaes no GRD.
O processo LMS tambm controla o fluxo de mensagens para instncias remotas,
gerencia o acesso a blocos de dados globais e transmite imagens de blocos entre os
caches de buffer de instncias diferentes. Esse processamento faz parte do recurso
cache fusion.
Instance Enqueue Process (LCK0): o processo LCK0 gerencia solicitaes do
recurso noncache fusion como solicitaes de cache de linha e de biblioteca.
Global Cache/Enqueue Service Heartbeat Monitor (LMHB): o LMHB monitora os
processos LMON, LMD e LMSn para garantir que eles sejam executados normalmente,
sem bloqueios nem esperas.
Processo Interconnect Latency Measurement (PING): a cada alguns segundos, o
processo em uma instncia envia mensagens a todas as instncias. A mensagem
recebida pelo PING na instncia de destino. O tempo para o acesso medido e
coletado.
Result Cache Background Process (RCBG): este processo usado para tratar
mensagens de invalidao e outras mensagens geradas pelos processos do servidor
ligados a outras instncias do Oracle RAC.
Processos Oracle RAC Management (RMSn): os processos RMSn executam tarefas
de gerenciabilidade para o Oracle RAC. As tarefas executadas por um processo RMSn
incluem a criao de recursos relacionados ao Oracle RAC quando novas instncias
so adicionadas aos clusters.
Remote Slave Monitor (RSMN): o processo RSMN gerencia a criao e a comunicao
do processo escravo de background em instncias remotas. Esses processos escravos
de background executam tarefas em nome de um processo de coordenao em
execuo em outra instncia.

Converso de Instncia nica em RAC
Os bancos de dados de instncia

nica podem ser convertidos em
RAC usando:
Banco de dados de
DBCA instncia nica
Enterprise Manager
Utilitrio RCONFIG
O DBCA automatiza a maioria das
tarefas de converso. Banco de dados RAC
Antes da converso, certifique-se
de que:
O seu hardware e o seu sistema
operacional sejam suportados
Os ns do cluster tenham acesso
ao armazenamento compartilhado
Voc pode usar o DBCA (Database Configuration Assistant) para converter bancos de dados
Oracle de instncia nica em RAC. O DBCA automatiza a configurao dos atributos do
arquivo de controle, cria os tablespaces de undo e os redo logs e gera as entradas dos
arquivos de parmetros de inicializao para ambientes habilitados para cluster. Ele tambm
configura o Oracle Net Services, os recursos do Oracle Clusterware e a configurao de
gerenciamento do banco de dados RAC para uso pelo Oracle Enterprise Manager ou pelo
utilitrio srvctl.
Antes de usar o DBCA para converter um banco de dados de instncia nica em um banco
de dados RAC, certifique-se de que o seu sistema atenda s seguintes condies:
Tenha uma configurao de hardware e sistema operacional suportada.
Tenha armazenamento compartilhado. O Oracle Cluster File System suportado, uma
montagem NFS ou o ASM estar disponvel e acessvel em todos os ns.
Suas aplicaes no devero ter qualquer caracterstica de projeto que impea o uso
delas com o processamento do banco de dados clusterizado.
Voc tambm pode usar o Enterprise Manager e o utilitrio rconfig para executar a
converso de um banco de dados de instncia nica em RAC.

Consideraes sobre a Converso de Bancos de

Dados de Instncia nica em Oracle RAC
Os procedures de backup devem estar disponveis antes
da converso.
O arquivamento em ambientes Oracle RAC requer um
nmero de thread no formato de arquivo archive.
Os logs arquivados de todas as instncias de um banco
de dados Oracle RAC so necessrios para a
recuperao de mdia.
Por padro, todos os arquivos de banco de dados so
migrados para o OMF (Oracle Managed Files).
Qualquer que seja o mtodo escolhido para a converso, observe as seguintes

consideraes administrativas antes de converter bancos de dados de instncia nica em
Oracle RAC:
Os procedures de backup devem estar disponveis antes da converso de um banco de
dados Oracle de instncia nica em Oracle RAC. Para arquivamento em ambientes
Oracle RAC, o formato de arquivo requer um nmero de thread.
Os logs arquivados de todas as instncias de um banco de dados Oracle RAC so
necessrios para a recuperao de mdia. Por essa razo, se voc fizer o arquivamento
em um arquivo e no usar um sistema de arquivos clusterizados ou outro meio para
fornecer sistemas de arquivos compartilhados, voc precisar de um mtodo para
acessar os logs de arquivo de todos os ns nos quais o banco de dados clusterizado
tenha instncias.
Por padro, todos os arquivos de banco de dados so migrados para o OMF (Oracle
Managed Files). Esse recurso simplifica a criao de tablespaces, garante a
consistncia do local dos arquivos de dados e a conformidade com as regras da OFA,
alm de reduzir o erro humano no gerenciamento de arquivos de dados.

Converso de Instncia nica Usando DBCA
Etapas de converso de um banco de dados de instncia nica

em um hardware no clusterizado:
1. Fazer backup do banco de dados original de instncia
nica.
2. Concluir a instalao do Oracle Grid Infrastructure.
3. Validar o cluster.
4. Copiar a imagem pr-configurada do banco de dados.
5. Instalar o software Oracle Database 12c com o RAC.
Voc pode usar o DBCA para converter bancos de dados Oracle de instncia nica em
Oracle RAC ou Oracle RAC One Node. O DBCA automatiza a configurao dos atributos do
arquivo de controle, cria os tablespaces de undo e os redo logs e gera as entradas dos
arquivos de parmetros de inicializao para ambientes habilitados para cluster. Ele tambm
configura o Oracle Net Services, os recursos do Oracle Clusterware e a configurao de
gerenciamento do banco de dados Oracle RAC para uso pelo Oracle Enterprise Manager ou
pelo utilitrio SRVCTL (Server Control).
Para fazer a converso de um banco de dados Oracle de instncia nica, localizado em um
computador no clusterizado, em um banco de dados RAC, execute as etapas descritas a
seguir:
1. Fazer backup do banco de dados original de instncia nica.
2. Concluir a instalao do Oracle Grid Infrastructure.
3. Validar o cluster.

Etapas da Converso
1. Fazer backup do banco de dados original de instncia nica.
1. Fazer Backup do Banco de Dados Original de Instncia nica.

Use o DBCA para criar uma imagem pr-configurada do seu banco de dados de instncia
nica executando o procedimento a seguir:
1. Navegue at o diretrio bin no $ORACLE_HOME e inicie o DBCA.
2. Na janela Welcome, clique em Next.
3. Na tela Operations, selecione Manage Templates e clique em Next.
4. Na tela Template Management, selecione o modelo "Create a database" e "From an
existing database (structure as well as data)" e, em seguida, clique em Next.
5. Na tela Source Database, digite o nome do banco de dados no campo Database
instance e clique em Next.
6. Na tela Template Properties, digite um nome de modelo no campo Name. Por default,
os arquivos de modelo so gerados em
$ORACLE_HOME/assistants/dbca/templates. Digite uma descrio do arquivo
no campo Description e, se desejar, altere a localizao do arquivo de modelo no
campo Template data file. Quando terminar, clique em Next.
7. Na janela Location of Database Related Files, selecione "Maintain the file locations",
para poder restaurar o banco de dados para a estrutura de diretrios atual, e clique em
Finish. O DBCA gera dois arquivos: um arquivo de estrutura do banco de dados
(template_name.dbc) e um arquivo da imagem pr-configurada do banco de dados
(template_name.dfb).

Etapas da Converso
2. Executar as etapas de pr-instalao.

As tarefas incluem configurao dos parmetros de kernel,
configurao do hardware, configurao da rede e configurao
do armazenamento compartilhado.
3. Configurar e validar o cluster.
Crie um cluster com o nmero necessrio de ns de acordo com
a documentao do seu fornecedor de hardware.
Valide os componentes do cluster antes da instalao.
Instale o Oracle Clusterware.
Valide a instalao concluda do cluster usando cluvfy.
O arquivo *.dbc de estrutura do banco de dados
O arquivo *.dfb da imagem pr-configurada do banco de dados
2. Executar as Etapas de Pr-instalao.

Conclua a instalao do Oracle Clusterware, conforme descrito no Oracle Grid Infrastructure
Installation Guide para a sua plataforma.
3. Configurar e Validar o Cluster.
Crie um cluster com o nmero necessrio de ns de acordo com as necessidades da sua
empresa. Aps configurar todos os ns do cluster, valide os componentes do cluster com o
Cluster Verification Utility e instale o Oracle Clusterware. Aps a instalao do clusterware,
valide a configurao e a instalao concluda do cluster com o Cluster Verification Utility.
4. Copiar a Imagem Pr-configurada do Banco de Dados.
Esse procedimento inclui a cpia do arquivo *.dbc da estrutura do banco de dados e do
arquivo *.dfb da imagem pr-configurada do banco de dados criados pelo DBCA na etapa
um (Fazer Backup do Banco de Dados Original de Instncia nica) para um local temporrio
no n do cluster a partir do qual deseja executar o DBCA.

1. Execute o OUI para realizar uma instalao do banco de dados Oracle com RAC.
Selecione Cluster Installation Mode e os ns a serem includos no seu banco de dados
RAC.
2. Na pgina Oracle Universal Installer Database Configuration Types, selecione o tipo de
instalao Advanced. Aps a instalao do software, o OUI executar as ferramentas de
ps-instalao, como o NETCA, o DBCA etc.
3. Na janela DBCA Template Selection, use o modelo que voc copiou para um local
temporrio na etapa "Copiar a Imagem Pr-configurada do Banco de Dados". Use a
opo Browse para selecionar a localizao do modelo.
4. Aps a criao do banco de dados RAC, o DBCA exibir a janela Password Management
na qual voc dever alterar as senhas dos usurios privilegiados do banco de dados. O
processo de converso estar concludo aps a sada do DBCA.

Converso de Instncia nica Usando rconfig
1. Localize o arquivo apropriado .xml localizado no diretrio

$ORACLE_HOME/assistants/rconfig/sampleXMLs.
2. Modifique o arquivo
ConvertToRAC_AdminManaged.xml ou
ConvertToRAC_PolicyManaged.xml conforme
exigido pelo seu sistema.
3. Salve o arquivo com outro nome.
$ cd $ORACLE_HOME/assistants/rconfig/sampleXMLs
$ vi ConvertToRAC_PolicyManaged.xml
... Saved as my_rac_conversion.xml
$ rconfig my_rac_conversion.xml
Use o utilitrio de linha de comandos rconfig para converter um banco de dados de

instncia nica em RAC. Para usar esse recurso, execute as seguintes etapas:
1. V para o diretrio $ORACLE_HOME/assistants/rconfig/sampleXMLs como o
usurio oracle e abra o arquivo ConvertToRAC.xml usando um editor de texto,
como vi.
2. Verifique o arquivo XML e modifique os parmetros conforme necessrio ao seu
sistema. O arquivo XML de exemplo contm linhas de comentrio que fornecem
instrues sobre como configurar o arquivo. Concludas as alteraes, salve o arquivo
com a sintaxe filename.xml. Anote o nome selecionado.
3. Considerando que voc tenha salvo o arquivo XML como my_rac_conversion.xml,
navegue at o diretrio $ORACLE_HOME/bin e use a seguinte sintaxe para executar o
comando rconfig:
$ ./rconfig my_rac_conversion.xml
Observao: A opo Convert verify no arquivo .xml tem trs opes:
Convert verify="YES": rconfig executa verificaes para assegurar que os pr-
requisitos para converso da instncia nica em RAC tenham sido atendidos antes do
incio da converso.
Convert verify="NO": rconfig no executa verificaes de pr-requisitos e inicia
a converso.
Convert verify="ONLY": rconfig executa somente verificaes de pr-requisitos;
ele no iniciar a converso aps concluir essas verificaes.
Questionrio
A instalao do software do banco de dados RAC iniciada

com a execuo do runInstaller a partir do diretrio-raiz do
CD-ROM do Oracle Database 12c ou do local de preparao
do software.
a. Verdadeiro
b. Falso
Resposta: a
A afirmao verdadeira.

Questionrio
Um banco de dados de instncia nica pode ser convertido em

um banco de dados RAC usando (escolha as opes corretas):
a. rconfig
b. netca
c. dbca
Resposta: a, c
As opes a e c esto corretas.

Sumrio

Instalar o software do banco de dados Oracle
Criar um banco de dados clusterizado
Executar tarefas posteriores criao do banco de dados
Converter um banco de dados Oracle de instncia nica
em RAC

Este exerccio aborda os seguintes tpicos:

Instalando o software do banco de dados Oracle
Criando um banco de dados RAC

Administrao do Oracle RAC
Objetivos

Usar pginas de Banco de Dados Clusterizado do
Enterprise Manager
Definir arquivos de redo log em um ambiente RAC
Definir tablespaces de undo em um ambiente RAC
Iniciar e interromper bancos de dados e instncias RAC
Modificar os parmetros de inicializao em um
ambiente RAC

Home Page Cluster Database
A home page Cluster Database funciona como uma central para gerenciar e monitorar todos
os aspectos do banco de dados RAC. Nessa pgina, voc encontra as sees Summary,
Performance, Diagnostics, Compliance, Instances e Incidents para obter informaes
relativas ao banco de dados do cluster como um todo. Aqui, voc pode ver a seo Summary
exibindo o nmero de instncias em funcionamento, tempo de atividade, verso do software,
etc. Abaixo, localize o painel Diagnostics com um link para os resultados de ADDM mais
recentes. Na seo Performance, voc pode percorrer as estatsticas da sesso por servio
ou instncia. Na seo Resources, voc pode visualizar o uso de recursos agrupado por
Database ou Instance. A seo SQL Monitor fornece um resumo do desempenho das
instrues SQL executadas na ltima hora.
A tabela Incidents and Problems mostra todos os alertas recentes abertos. Clique na
mensagem de alerta na coluna Message para obter mais informaes sobre o alerta. Quando
um alerta acionado, o nome da mtrica para a qual o alerta foi acionado exibido na
coluna Name.

Home Page Cluster Database
Percorrendo mais para baixo a home page cluster database, o nmero de instncias
exibido no banco de dados RAC, alm do seu status. Um banco de dados RAC
considerado ativo quando pelo menos uma instncia o mantm aberto. Se o seu banco de
dados clusterizado usar o ASM para armazenamento compartilhado, as instncias do ASM
sero listadas tambm. Fazer drill-down em qualquer um dos links da instncia permitir que
voc acesse as informaes do resumo somente nessa instncia Clicar nos links do nome do
host exibir as informaes do resumo como CPU, memory, sistema de arquivos e utilizao
da rede. Um resumo da configurao do hardware para o host selecionado tambm
exibido.
Um resumo de compliance exibido no painel esquerdo da home page cluster database.
Abaixo dessa seo, temos um resumo de Jobs Running, permitindo que voc monitore os
jobs em execuo em uma rpida olhada.

Home Page Cluster Database Instance
A home page Cluster Database Instance permite que voc verifique o estado atual da
instncia, exibindo uma srie de mtricas que descrevem seu estado geral. Essa pgina
usada como ponto de partida para verificar o desempenho, a administrao e a manuteno
do ambiente da instncia.
Voc pode acessar a home page Cluster Database Instance clicando em um nome de
instncia na seo Instances da home page Cluster Database. Essa pgina tem basicamente
as mesmas sees da home page Cluster Database. A diferena que as tarefas e as
atividades monitoradas nessas pginas se aplicam basicamente a uma instncia especfica.

Home Page Cluster
O slide mostra a home page Cluster, que pode ser acessada com um clique no link Cluster
localizado no menu pull-down Targets. Mesmo se o banco de dados estiver desativado, a
pgina Cluster estar disponvel para o gerenciamento dos recursos. O cluster
representado como um alvo composto de ns e bancos de dados do cluster. Um resumo
geral do cluster apresentado aqui. A home page Cluster exibe vrias sees, incluindo
General, Status Summary, Diagnostic Summary, Cluster Databases, Incidents e Hosts. A
seo General apresenta uma viso rpida do status do cluster, fornecendo informaes
bsicas, como Status (atual), Availability, Up nodes, Clusterware Version e Oracle Home.
A tabela Cluster Databases exibe os bancos de dados clusterizados (opcionalmente
associados aos servios correspondentes) associados ao cluster, sua disponibilidade e
qualquer alerta nesses bancos de dados. A tabela Incidents fornece informaes sobre os
alertas que foram emitidos juntamente com a gravidade de cada um.
A tabela Hosts exibe os hosts para o cluster, a disponibilidade, alertas correspondentes e
percentual de utilizao de memria e CPU.

Topology Viewer
O Topology Viewer permite que voc visualize os relacionamentos entre os tipos de alvo
para cada host do seu banco de dados clusterizado. Voc poder aplicar mais ou menos
zoom, obter uma panormica e ver detalhes da seleo. Essas views tambm podero ser
usadas para acionar vrias funes de administrao.
O Topology Viewer preenche os cones segundo a configurao do sistema. Se um listener
estiver atendendo a uma instncia, uma linha conectar o cone do listener ao cone da
instncia. Os tipos de alvo possveis so:
Interface
Listener
Instncia ASM
Instncia de Banco de Dados
Voc pode clicar em um cone e, em seguida, clicar com o boto direito do mouse para exibir
um menu das aes disponveis.

Alertas do Enterprise Manager e RAC
Voc pode usar o Enterprise Manager para administrar alertas em ambientes RAC. Em
ambientes RAC, o Enterprise Manager faz a distino entre alertas no nvel do banco de
dados e no nvel da instncia.
O Enterprise Manager tambm responde a mtricas do banco de dados RAC inteiro e publica
alertas quando os limites so excedidos. O Enterprise Manager interpreta mtricas
predefinidas e personalizadas. Voc tambm pode copiar mtricas personalizadas de uma
instncia do banco de dados do cluster para outra, ou de um banco de dados RAC para
outro. Na home page Cluster Database, h um resumo dos alertas recentes. Observe que os
alertas so ordenados pelo horrio relativo e nome do alvo (target).

Mtricas do Enterprise Manager e RAC
Os limites de alertas no nvel da instncia, como alertas de log de arquivamento, podem ser
definidos no nvel de alvo da instncia. Isso permite que voc receba alertas da instncia
especfica se o desempenho exceder o limite. Voc tambm pode configurar alertas no nvel
do banco de dados, como a definio de alertas para tablespaces. Isso impede que voc
receba alertas duplicados em cada instncia.

Blecautes do Enterprise Manager e RAC
Voc pode usar o Enterprise Manager com o objetivo de definir blecautes para todos os alvos
gerenciados do banco de dados RAC e impedir o registro de alertas. Os blecautes so teis
durante a realizao de operaes de manuteno programada ou no programada ou de
outras tarefas que possam acionar eventos indevidos ou indesejados. Voc pode definir
blecautes para um banco de dados de cluster inteiro ou para instncias especficas do banco
de dados do cluster.
Para criar um evento de blecaute, selecione Control e Create Blackouts no menu pull-down
Cluster Database. Clique no boto Create. A pgina Create Blackout: Properties ser exibida.
Informe um nome ou uma tag no campo Name. Se quiser, voc tambm poder digitar um
comentrio descritivo no campo Comments. Esse parmetro opcional. Informe um motivo
para o blecaute no campo Reason.
Na rea Targets da pgina Properties, escolha um tipo de alvo na lista drop-down Type.
Clique no banco de dados de cluster na lista Available Targets e clique no boto Move para
mover sua opo para a lista Selected Targets. Clique no boto Next para continuar.
A pgina Member Targets ser exibida em seguida. Expanda a rvore Selected Composite
Targets e verifique se todos os alvos que devem ser includos esto sendo exibidos na lista.
Continue e defina sua programao de acordo com suas necessidades.

Arquivos de Redo Log e RAC
N1 N2
RAC01 RAC02
Armazenamento
compartilhado
Grupo 1 SPFILE
Grupo 4
Grupo 2 RAC01.THREAD=1
Grupo 5
RAC02.THREAD=2
Grupo 3
Thread 2
Thread 1
Em um banco de dados Oracle RAC, cada instncia deve ter pelo menos dois grupos de
arquivos redo log. necessrio alocar os grupos de redo log antes de ativar uma nova
instncia com o comando ALTER DATABASE ENABLE INSTANCE instance_name.
Quando voc usa o DBCA para criar o banco de dados, o DBCA aloca os arquivos de redo
log s instncias, conforme requerido, automaticamente. Voc pode alterar o nmero de
grupos de redo log e o tamanho dos arquivos de redo log conforme necessrio, seja durante
a criao do banco de dados inicial ou como uma etapa ps-criao.
Quando o grupo atual for preenchido, uma instncia comear a gravar no prximo grupo de
arquivos de log. Se o seu banco de dados estiver no modo ARCHIVELOG, cada instncia
dever salvar grupos de log on-line completos como arquivos de redo log arquivados que so
rastreados no arquivo de controle. Durante a recuperao do banco de dados, todas as
instncias ativadas so verificadas com a finalidade de determinar se a recuperao
necessria. Se voc remover uma instncia de seu banco de dados Oracle RAC, ento deve
desativar o thread de redo da instncia, de forma que o Oracle no tenha que verificar o
thread durante a recuperao do banco de dados.

O gerenciamento de redo log deve ser considerado quando o nmero de instncias para um
banco de dados Oracle RAC de produo particular for alterado. Por exemplo, se voc
aumentar a cardinalidade de um pool de servidores em um banco de dados gerenciado por
poltica, e um novo servidor for alocado no pool de servidores, se voc tiver o OMF (Oracle
Managed Files) ativado, o Oracle Clusterware iniciar uma instncia no novo servidor. Se a
instncia for iniciada e no houver thread nem arquivo de redo log disponvel, o Oracle
Clusterware automaticamente ativar um thread de redo e alocar os arquivos de redo log e
undo associados se o banco de dados usar o Oracle ASM ou qualquer sistema de arquivos
clusterizados.
Para os bancos de dados gerenciados pelo administrador, cada instncia tem seus prprios
grupos de redo log on-line. Crie esses grupos de redo log e estabelea membros dos grupos.
Para adicionar um grupo de redo log a uma determinada instncia, especifique a clusula
INSTANCE na instruo ALTER DATABASE ADD LOGFILE. Se voc no especificar a
instncia ao adicionar o grupo de redo log, ele ser adicionado instncia qual voc estiver
conectado no momento.
Cada instncia dever ter, pelo menos, dois grupos de arquivos de redo log. necessrio
alocar os grupos de redo log antes de ativar uma nova instncia com o comando ALTER
DATABASE ENABLE INSTANCE instance_name. Quando o grupo atual for preenchido,
uma instncia comear a gravar no prximo grupo de arquivos de log. Se o seu banco de
dados estiver no modo ARCHIVELOG, cada instncia dever salvar grupos de log on-line
completos como arquivos de redo log arquivados que so rastreados no arquivo de controle.
Durante a recuperao do banco de dados, todas as instncias ativadas so verificadas com
a finalidade de determinar se a recuperao necessria. Se voc remover uma instncia de
seu banco de dados Oracle RAC, ento deve desativar o thread de redo da instncia, de
forma que o Oracle no tenha que verificar o thread durante a recuperao do banco de
dados.

Gerenciamento Automtico de Undos e RAC

Off-line N1 N2
pendente
RAC01 RAC02
Leituras consistentes
Recuperao de transaes
Armazenamento
compartilhado
SPFILE
undotbs3
RAC01.UNDO_TABLESPACE=undotbs1
RAC02.UNDO_TABLESPACE=undotbs2
undotbs1 undotbs2

ALTER SYSTEM SET UNDO_TABLESPACE=undotbs3 SID='RAC01';
O banco de dados Oracle gerencia automaticamente os segmentos de undo de um tablespace

de undo especfico designado a uma instncia. Em circunstncias normais, apenas a instncia
designada ao tablespace de undo pode modificar o contedo desse tablespace. Entretanto,
todas as instncias sempre podem ler todos os blocos de undo para fins de consistncia de
leitura. Alm disso, qualquer instncia pode atualizar tablespaces de undo durante a
recuperao de transaes, contanto que esse tablespace de undo no esteja sendo usado por
outra instncia para a gerao de undo ou para a recuperao de transaes.
Para designar tablespaces de undo no banco de dados gerenciado pelo administrador Oracle
RAC, especifique um valor distinto para o parmetro UNDO_TABLESPACE de cada instncia no
SPFILE ou em PFILEs individuais. Para bancos de dados gerenciados por poltica, o Oracle
aloca automaticamente o tablespace de undo quando a instncia iniciada, caso voc tenha o
OMF ativado. No possvel usar simultaneamente o AUM (Automatic Undo Management) e o
gerenciamento manual de undo em um banco de dados Oracle RAC. Em outras palavras, todas
as instncias de um banco de dados Oracle RAC devem operar no mesmo modo undo.
Voc pode alternar dinamicamente as atribuies do tablespace de undo, executando a
instruo ALTER SYSTEM SET UNDO_TABLESPACE. possvel executar esse comando em
qualquer instncia. No exemplo do slide, o tablespace de undo usado anteriormente e
designado instncia RAC01 permanece designado a ela at que a ltima transao ativa da
instncia RAC01seja submetida a commit. O tablespace pendente off-line poder permanecer
indisponvel para as outras instncias at que todas as transaes referentes a ele sejam
submetidas a commit. No possvel usar simultaneamente o AUM (Automatic Undo
Management) e o gerenciamento manual de undo em um banco de dados RAC.
recomendvel usar o modo AUM.
Iniciando e Interrompendo Instncias RAC
Vrias instncias podem abrir o mesmo banco de dados

simultaneamente.
O shutdown de uma instncia no interfere na execuo das
outras instncias.
A opo SHUTDOWN TRANSACTIONAL LOCAL no espera
que a execuo das transaes de outras instncias termine.
As instncias RAC podem ser iniciadas e interrompidas com:
Enterprise Manager
O utilitrio Server Control (srvctl)
SQL*Plus
Fazer shutdown de um banco de dados RAC significa fazer
shutdown de todas as instncias que esto acessando o
banco de dados.
Em um ambiente RAC, vrias instncias podem abrir o mesmo banco de dados RAC ao
mesmo tempo. Alm disso, fazer shutdown de uma instncia no interfere na operao das
outras instncias que esto em execuo.
Os procedimentos para inicializar e fazer shutdown de instncias RAC so idnticos aos
usados em bancos de dados Oracle com uma nica instncia, com a seguinte exceo:
O comando SHUTDOWN TRANSACTIONAL com a opo LOCAL utilizado para fazer shutdown
de uma instncia depois que todas as transaes ativas na instncia foram submetidas a
commit ou rollback. As transaes de outras instncias no bloqueiam essa operao. Se a
opo LOCAL for omitida, a operao esperar at que as transaes de todas as outras
instncias iniciadas antes do shutdown sejam submetidas a COMMIT ou a ROLLBACK.
. possvel inicializar ou fazer shutdown de instncias com o Enterprise Manager, o
SQL*Plus ou o Server Control (srvctl). O Enterprise Manager e o srvctl contm opes
para inicializar e fazer shutdown de todas as instncias de um banco de dados RAC em uma
nica etapa.
Fazer shutdown de um banco de dados RAC montado ou aberto por vrias instncias
significa fazer shutdown de todas as instncias que esto acessando esse banco de dados
RAC. No entanto, basta que uma nica instncia esteja acessando o banco de dados RAC
para que ele seja considerado aberto.

Iniciando e Interrompendo Instncias do

RAC com srvctl
sintaxe start/stop:
$ srvctl start instance -db db_unique_name node node_name
-instance instance_name_list[-startoption
open|mount|nomount|normal|transactional|immediate|abort]
srvctl start|stop database -db <db_name> -eval
[-startoption
open|mount|nomount|normal|transactional|immediate|abort>]
Exemplos:
$ srvctl start instance -db orcl -instance orcl1,orcl2
$ srvctl stop instance -db orcl -instance orcl1,orcl2
$ srvctl start database -db orcl -startoption open
$ srvctl start instance -db orcl -node host01

*** This command will start a Policy-Managed database****
O comando srvctl start database inicia um banco de dados clusterizado e suas

instncias e servios ativados. O comando srvctl stop database interrompe um banco de
dados, suas instncias e servios.
O comando srvctl start instance inicia instncias de um banco de dados clusterizado.
Esse comando tambm inicia todos os servios habilitados que no esto em execuo e
que tenham instncias listadas como instncias preferenciais ou disponveis.
O comando srvctl stop instance interrompe as instncias e todos os servios habilitados
e em execuo e que possuem essas instncias como as preferenciais ou disponveis.
Desabilite o objeto que dever permanecer interrompido aps a execuo do comando
srvctl stop; caso contrrio, o Oracle Clusterware poder reinici-lo como resultado de
outra operao planejada. O srvctl no suporta execues concorrentes dos comandos no
mesmo objeto. Portanto, execute apenas um comando srvctl de cada vez para cada banco
de dados, servio ou outro objeto. Para que voc possa usar as opes START ou STOP do
comando SRVCTL, o servio dever estar habilitado para Oracle Clusterware e no estar em
execuo.
Ao desativar uma instncia, o uso do comando SHUTDOWN TRANSACTIONAL com a opo
LOCAL til para desativar uma instncia particular do banco de dados Oracle RAC. As
transaes de outras instncias no bloqueiam essa operao. Se voc omitir a opo
LOCAL, ento esta operao aguarda at que as transaes em todas as outras instncias
que iniciaram antes de voc executar o comando SHUTDOWN sejam submetidas a commit ou
rollback, o que uma abordagem vlida, caso voc pretenda desativar todas as instncias de
um banco de dados Oracle RAC.
Iniciando e Interrompendo
Instncias RAC com o SQL*Plus
[host01] $ echo $ORACLE_SID
orcl1
sqlplus / as sysdba
SQL> startup
SQL> shutdown
[host02] $ echo $ORACLE_SID

orcl2
sqlplus / as sysdba
SQL> startup
SQL> shutdown
Se voc quiser iniciar ou interromper apenas uma instncia e estiver conectado ao n local,
certifique-se primeiro de que seu ambiente atual inclui o SID da instncia local. Observe que
os comandos subsequentes na sua sesso, estejam dentro ou fora de uma sesso do
SQL*Plus, esto associados ao mesmo SID.
Para inicializar ou fazer shutdown da instncia local, inicie uma sesso do SQL*Plus
conectado como SYSDBA ou SYSOPER e execute o comando necessrio (por exemplo,
STARTUP).
Com o Oracle Net Services, voc pode iniciar vrias instncias a partir de uma nica sesso
do SQL*Plus em um n. Para isso, estabelea conexo com cada instncia usando uma
string de conexo do Net Services; normalmente, essa string um apelido especfico da
instncia contido no arquivo tnsnames.ora. Por exemplo, possvel usar uma sesso do
SQL*Plus em um n local para fazer shutdown de duas instncias em ns remotos
estabelecendo conexo com cada uma delas por meio de seus apelidos.
No possvel inicializar ou fazer shutdown de mais de uma instncia de cada vez no
SQL*Plus, portanto, no possvel iniciar ou interromper todas as instncias de um banco de
dados de cluster com um nico comando do SQL*Plus. Para verificar se as instncias esto
em execuo, em qualquer n, examine V$ACTIVE_INSTANCES.
Observao: o SQL*Plus integrado ao Oracle Clusterware para garantir que os recursos
correspondentes sejam corretamente manipulados ao iniciar e fazer shut down de instncias
pelo SQL*Plus.
Iniciando e Interrompendo Bancos de

Dados Plugveis no Oracle RAC
Gerencie os PDBs do RAC gerenciando os servios,
independentemente de serem gerenciados por poltica ou
administrador.
Designe um servio de banco de dados a cada PDB para
coordenar o incio, a interrupo e a colocao dos PDBs
nas instncias.
Suponha que voc tem um PDB chamado raccont com um
PDB gerenciado por polticas chamado spark em um pool
de servidores chamado prod:
$ srvctl add service db raccont pdb spark service
plug serverpool prod
Para iniciar e interromper o PDB:
$ srvctl start service -db raccont -service plug
$ srvctl stop service -db raccont -service plug
A administrao de um CDB (banco de dados continer) multilocatrio baseado em Oracle

RAC , de alguma forma, similar administrao de um banco de dados no-continer. As
diferenas residem apenas no fato de que algumas tarefas administrativas se aplicam ao
CDB inteiro, algumas se aplicam apenas raiz, e algumas se aplicam a PDBs (bancos de
dados plugveis) especficos. A administrao de um PDB (banco de dados plugvel)
envolve um pequeno subconjunto das tarefas necessrias para administrar um banco de
dados no-continer. Neste subconjunto de tarefas, a maioria igual para um PDB e um
banco de dados no-continer. H algumas diferenas, entretanto, como quando voc
modifica o modo de abertura de um PDB. Alm disso, um administrador de PDB se limita a
gerenciar um nico PDB e no afetado por outros PDBs no CDB.
Voc gerencia PDBs em um CDB baseado em Oracle RAC gerenciando servios,
independentemente do fato de os PDBs serem gerenciados por poltica ou administrador.
Designe um servio de banco de dados dinmico a cada PDB para coordenar o incio, a
interrupo e a colocao dos PDBs nas instncias de um banco de dados continer
clusterizado.
Por exemplo, se voc tiver um CDB chamado raccont com um PDB gerenciado por
polticas chamado spark, que est em um pool de servidores chamado prod, designe um
servio chamado plug a este banco de dados usando o seguinte comando:
srvctl add service db raccont pdb spark service plug serverpool prod

O servio plug ser gerenciado de forma uniforme em todos os ns do pool de servidores. Se
voc quiser que este servio seja executado em um servio singleton no mesmo pool de
servidores, use o parmetro -cardinality singleton com o comando anterior.
Para iniciar o PDB spark, voc deve iniciar o respectivo servio, plug, como se segue:
srvctl start service -db raccont -service plug
Para interromper o PDB spark, voc deve interromper o respectivo servio, plug, como se
segue:
srvctl stop service -db raccont -service plug
Voc pode verificar o status do banco de dados usando o comando srvctl status
service.
Como os PDBs so gerenciados com o uso de servios de bancos de dados dinmicos, so
utilizadas prticas tpicas de gerenciamento baseadas no Oracle RAC. Portanto, se o servio
plug estiver no estado ONLINE quando o Oracle Clusterware for desativado em um servidor
que estiver hospedando este servio, o servio ser restaurando para seu estado original
aps o reincio do Oracle Clusterware neste servidor. Dessa forma, o incio dos PDBs
automatizado da mesma forma como qualquer outro banco de dados Oracle RAC.

Alternar entre Polticas Automticas e Manuais
$ srvctl config database -db orcl -a

Database name: orcl
Oracle user: oracle
Start options: open
Database instances:
Disk Groups:
Mount point paths:
Services:
Type: RAC
...
srvctl modify database -db orcl -policy MANUAL;
Por padro, o Oracle Clusterware controla os reincios de bancos de dados em ambientes

Oracle RAC. Em alguns casos, voc pode precisar minimizar o nvel de controle que o Oracle
Clusterware tem sobre o seu banco de dados Oracle RAC, por exemplo, durante os upgrades
do banco de dados.
Para impedir que o Clusterware reinicie seu banco de dados RAC quando voc reiniciar o
sistema, ou para evitar o reincio de instncias com falha mais de uma vez, configure uma
poltica de gerenciamento para definir o grau de controle. H duas polticas de
gerenciamento: AUTOMATIC, a padro, e MANUAL. Se a poltica de gerenciamento for
definida como AUTOMATIC, o banco de dados automaticamente restaurado para sua
condio de execuo anterior (iniciada ou interrompida) no reincio do computador host do
banco de dados. Se for MANUAL, o banco de dados nunca automaticamente reiniciado no
reincio do computador host do banco de dados. Uma configurao MANUAL no impede que
o Oracle Restart monitore o banco de dados enquanto est sendo executado e o reinicie se
ocorrer uma falha.
Use a seguinte sintaxe do comando SRVCTL para alterar a poltica atual de gerenciamento
para AUTOMATIC, MANUAL ou NORESTART:
srvctl modify database -db db_unique_name -policy [AUTOMATIC |
MANUAL | NORESTART]
Quando voc adiciona um novo banco de dados usando o comando srvctl add database,
pode usar o parmetro -policy para especificar a poltica de gerenciamento:
srvctl add database -db db_unique_name -policy [AUTOMATIC | MANUAL |
NORESTART]-oraclehome $ORACLE_HOME -dbname DATA
Esta sintaxe de comando coloca o novo banco de dados sob o controle do Oracle
Clusterware. Se voc no fornecer uma opo de poltica de gerenciamento, ento o Oracle
Database usa o valor padro automtico. Depois de voc alterar a poltica de gerenciamento,
o recurso do Oracle Clusterware registra o novo valor do banco de dados afetado.

Arquivos de Parmetros de
Inicializao do Ambiente RAC
Um SPFILE ser criado se voc usar o DBCA.
O SPFILE dever ser criado em um grupo de discos ASM
ou em um arquivo de sistema de arquivos clusterizados.
Todas as instncias usam o mesmo SPFILE.
Se o banco de dados for criado manualmente, crie um
SPFILE a partir de um PFILE.
N1 N2
RAC01 RAC02
initRAC01.ora initRAC02.ora
SPFILE= SPFILE=
SPFILE
Quando voc cria o banco de dados, o Oracle Database cria um SPFILE no local especificado
por voc. Esse local pode ser um grupo de discos Oracle ASM ou um sistema de arquivos
clusterizados. Se voc criar manualmente seu banco de dados, a Oracle recomenda que crie
um SPFILE a partir de um arquivo de parmetros de inicializao (PFILE).
Todas as instncias no banco de dados do cluster usam o mesmo SPFILE durante a
inicializao. Como o SPFILE um arquivo binrio, no edite diretamente o SPFILE com um
editor. Em vez disso, altere as definies de parmetros do SPFILE usando o Oracle
Enterprise Manager ou instrues SQL ALTER SYSTEM.
Ao criar um SPFILE, se voc incluir a clusula FROM MEMORY (por exemplo, CREATE PFILE
FROM MEMORY ou CREATE SPFILE FROM MEMORY), ento a instruo CREATE cria um
PFILE ou SPFILE usando as defini~eos de parmetro atuais do mbito do sistema. Em um
ambiente Oracle RAC, o arquivo criado contm as definies de parmetros de cada
instncia. Como a clusula FROM MEMORY requer que todas as outras instncias enviem suas
definies de parmetro para a instncia que est tentando criar o arquivo de parmetro, o
tempo de execuo total depende do nmero de instncias, o nmero de definies de
parmetro em cada instncia e a quantidade de dados para essas configuraes.
Observao: O Oracle RAC somente utilizar um PFILE tradicional se no existir um SPFILE
ou se voc especificar o PFILE no comando STARTUP. A Oracle recomenda que voc utilize
um SPFILE para simplificar a administrao, para manter a consistncia de definies dos
parmetros e para garantir a persistncia de definies dos parmetros nos eventos de
shutdown e inicializao do banco de dados.
Valores de Parmetros do SPFILE e o RAC
Voc pode alterar as definies de parmetros usando o

comando ALTER SYSTEM SET em qualquer instncia:
ALTER SYSTEM SET <dpname> SCOPE=MEMORY sid='<sid|*>';
Entradas do SPFILE como:
*.<pname> se aplicam a todas as instncias
<sid>.<pname> se aplicam apenas a <sid>
<sid>.<pname> tem precedncia sobre *.<pname>
Use as definies *.<dpname> atuais ou futuras para
<sid>:
ALTER SYSTEM RESET <dpname> SCOPE=MEMORY sid='<sid>';
Remova uma entrada do SPFILE:

ALTER SYSTEM RESET <dpname> SCOPE=SPFILE sid='<sid|*>';
Voc pode modificar os valores dos seus parmetros de inicializao usando o comando
ALTER SYSTEM SET. Isso feito de forma semelhante ao que se faz com um banco de dados
de uma nica instncia, exceto pela possibilidade de especificar a clusula SID alm da
clusula SCOPE.
.O uso da clusula SID permite que voc especifique o SID da instncia em que o valor tem
efeito. Especifique SID='*' se quiser alterar o valor do parmetro para todas as instncias.
Especifique SID='sid' se quiser alterar o valor do parmetro apenas para a instncia sid.
Essa definio tem precedncia sobre as instrues ALTER SYSTEM SET anteriores e
subsequentes que especificarem SID='*'. Quando as instncias forem inicializadas com um
SPFILE, SID='*' ser o default caso a clusula SID no seja especificada.
Quando voc especificar uma instncia que no seja a atual, uma mensagem ser enviada a
essa instncia para que o valor do parmetro seja alterado na memria caso o escopo
SPFILE no esteja sendo usado.
A combinao de SCOPE=MEMORY e SID='sid' do comando ALTER SYSTEM RESET permite
que voc sobreponha a precedncia de uma entrada <sid>.<dparam> que esteja sendo
usada. Isso permite que a entrada atual *.<dparam> seja usada ou que a prxima entrada
criada *.<dparam> seja considerada no SID em questo.
Com base no ltimo exemplo, voc pode remover uma linha de SPFILE.
Observao: quando voc inicia uma instncia com um SPFILE, o padro para o SQL*Plus
SCOPE=BOTH.
Ordem de Pesquisa do Arquivo de

Parmetros no Oracle RAC
Em plataformas Linux e UNIX, a ordem de pesquisa
a seguinte:
1. $ORACLE_HOME/dbs/spfilesid.ora
2. $ORACLE_HOME/dbs/spfile.ora
3. $ORACLE_HOME/dbs/initsid.ora
Em plataformas Windows, a ordem de pesquisa a
seguinte:
1. %ORACLE_HOME%\database\spfilesid.ora
2. %ORACLE_HOME%\database\spfile.ora
3. %ORACLE_HOME%\database\initsid.ora
O Oracle Database pesquisa o seu arquivo de parmetros em uma ordem particular

dependendo da plataforma. Nos bancos de dados Oracle RAC, voc pode facilmente
determinar o local do arquivo de parmetros usando o comando srvctl config
database.
A Oracle recomenda que voc no use os nomes padro do SPFILE j que todas as
instncias devem usar o mesmo arquivo e todas tm diferentes SIDs. Em vez disso,
armazene o SPFILE no Oracle ASM. Se voc armazenar o SPFILE em um sistema de
arquivos clusterizados, use a seguinte conveno de nomeao para o SPFILE:
$ORACLE_HOME/dbs/spfiledb_unique_name.ora. Crie um PFILE denominado
$ORACLE_HOME/dbs/initsid.ora que contenha o nome
SPFILE=ORACLE_HOME/dbs/spfiledb_unique_name.ora.

EM e os Valores dos Parmetros de SPFILE
SCOPE=MEMORY
Voc pode acessar a pgina Initialization Parameters na pgina Cluster Database, clicando
na tab Administration e selecionando Initialization Parameters no menu pull-down.
A pgina com a tab Current mostra os valores atuais usados pelos parmetros de
inicializao de todas as instncias que acessam o banco de dados RAC. Voc pode filtrar a
pgina Initialization Parameters para exibir apenas os parmetros que atendam aos critrios
do filtro especificado no campo Name.
A coluna Instance mostra as instncias cujos parmetros tm o valor listado na tabela. Um
asterisco (*) indica que o parmetro tem o mesmo valor para todas as outras instncias do
banco de dados clusterizado.
Escolha um parmetro na coluna Select e execute um destes procedimentos:
Clique em Add para adicionar o parmetro selecionado a outra instncia. Informe novos
nome e valor da instncia na linha criada na tabela.
Clique em Reset para redefinir o valor do parmetro selecionado. Observe que s
possvel redefinir os parmetros sem asterisco na coluna Instance. O valor da coluna
selecionada ser redefinido com o valor das outras instncias.
Observao: para os botes Add e Reset, o comando ALTER SYSTEM usa SCOPE=MEMORY.

EM e os Valores dos Parmetros de SPFILE
SCOPE=BOTH
SCOPE=SPFILE
A pgina com a tab SPFile exibe os valores atuais armazenados no seu SPFILE.
Assim como na pgina com a tab Current, voc pode adicionar ou redefinir parmetros. No
entanto, se voc marcar a caixa de seleo "Apply changes in SPFILE mode", o comando
ALTER SYSTEM usar SCOPE=BOTH. Se a caixa no tiver sido marcada, ser usado
SCOPE=SPFILE.
Clique em Apply para aceitar e gerar suas alteraes.

Parmetros de Inicializao para RAC
CLUSTER_DATABASE: Permite que um banco de dados seja iniciado em modo de cluster.

Defina como TRUE.
CLUSTER_DATABASE_INSTANCES: Define o nmero de instncias do ambiente RAC. Uma
definio apropriada para esse parmetro pode otimizar a utilizao da memria.
CLUSTER_INTERCONNECTS: Especifica a interconexo do cluster quando h mais de uma
interconexo. Consulte a documentao da sua plataforma Oracle para obter informaes
sobre esse parmetro, sua sintaxe e seu comportamento. Normalmente, voc no precisar
definir o parmetro CLUSTER_INTERCONNECTS. Por exemplo, no defina esse parmetro
para as seguintes configuraes comuns:
Se houver apenas uma interconexo de cluster
Se a interconexo de cluster default atender aos requisitos de largura de banda do
banco de dados RAC, o que normalmente o padro.
Se voc estiver usando NIC bonding para a interconexo
Quando a configurao global de OIFCFG puder especificar as interconexes corretas
de cluster. Ele apenas precisar ser especificado como uma sobreposio de OIFCFG.
DB_NAME: Se voc definir um valor para DB_NAME nos arquivos de parmetros de
determinada instncia, a definio dever ser idntica para todas as instncias.
DISPATCHERS: Defina esse parmetro para permitir uma configurao de servidor
compartilhado, isto , um servidor configurado para permitir que vrios processos de usurios
compartilhem poucos processos de servidor.
Com configuraes de servidor compartilhado, muitos processos de usurios podem ser
conectados ao dispatcher. O parmetro DISPATCHERS pode conter muitos atributos. A
Oracle recomenda que voc configure pelo menos os atributos PROTOCOL e LISTENER.
PROTOCOL especifica o protocolo de rede para o qual o processo do dispatcher gera um
ponto final para listening. LISTENER especifica um apelido para os listeners do Oracle Net
Services. Defina o apelido como um nome que resolvido por meio de um mtodo de
nomeao, como o arquivo tnsnames.ora. Outros parmetros que podem afetar as
configuraes do banco de dados RAC incluem:
ACTIVE_INSTANCE_COUNT: Este parmetro de inicializao foi descontinuado no
Oracle RAC 11.2. Em vez disso, use um servio com uma instncia preferida e uma
disponvel.
GCS_SERVER_PROCESSES: Esse parmetro esttico especifica o nmero inicial de
processos de servidor para o CGC (Global Cache Service) de uma instncia do Oracle
RAC. Os processos GCS gerenciam o roteamento do trfego entre instncias do Oracle
RAC. O nmero padro de processos GCS do servidor calculado com base nos
recursos do sistema com uma definio mnima de 2. Em sistemas com uma CPU, h
um processo GCS no servidor. Para sistemas com duas a oito CPUs, h dois processos
de servidor GCS. Para sistemas com mais de oito CPUs, o nmero de processos de
servidor GCS equivale ao nmero de CPUs dividido por 4, descartando todas as
fraes. Por exemplo, se voc tiver 10 CPUs, ento 10 dividido por 4 significa que seu
sistema tem 2 processos GCS. Voc pode definir esse parmetro como diferentes
valores em instncias distintas.
INSTANCE_NAME: O SID da instncia. O SID identifica a memria compartilhada da
instncia em um host. Qualquer caractere alfanumrico pode ser usado. O valor para
esse parmetro automaticamente definido como o nome exclusivo do banco de dados
seguido por um nmero de incremento durante a criao do banco de dados com o uso
de DBCA.
RESULT_CACHE_MAX_SIZE: Em um banco de dados clusterizado, voc pode defini-lo
como 0 em toda instncia para desativar o cache de resultados, ou usar um valor
diferente de zero em toda instncia para ativar o cache de resultados.
SERVICE_NAMES: Quando voc usa os servios, a Oracle recomenda que voc no
defina um valor para o parmetro SERVICE_NAMES mas, em vez disso, crie servios
gerenciados de cluster por meio da pgina Cluster Managed Services em EM Cloud
Control. Isto porque o Oracle Clusterware controla a definio deste parmetro para os
servios que voc cria e para o servio padro de banco de dados.
SPFILE: Quando um SPFILE for usado, todas as instncias do banco de dados Oracle
RAC devero usar o SPFILE e o arquivo dever estar na rea de armazenamento
compartilhado.
THREAD:O parmetro THREAD especifica o nmero de redo threads a ser usado por
uma instncia. possvel especificar o nmero de um redo thread que esteja
disponvel, contanto que esse nmero esteja habilitado e no esteja sendo utilizado.
Se especificado, esse parmetro dever ter valores exclusivos em todas as instncias.
O melhor a fazer usar o parmetro INSTANCE_NAME para especificar os grupos de
redo log.

Parmetros Que Exigem Definies Idnticas
COMPATIBLE
CLUSTER_DATABASE
CONTROL_FILES
DB_BLOCK_SIZE
DB_DOMAIN
DB_FILES
DB_NAME
DB_RECOVERY_FILE_DEST
DB_RECOVERY_FILE_DEST_SIZE
DB_UNIQUE_NAME
INSTANCE_TYPE (RDBMS ou ASM)
PARALLEL_EXECUTION_MESSAGE_SIZE
REMOTE_LOGIN_PASSWORDFILE
UNDO_MANAGEMENT
Determinados parmetros de inicializao que so crticos durante a criao de um banco de

dados ou que afetam determinadas operaes do banco de dados devem ter o mesmo valor
em cada instncia do ambiente Oracle RAC. Especifique esses valores de parmetros no
SPFILE ou nos PFILEs individuais para cada instncia. A lista no slide acima contm os
parmetros que devem ser idnticos em todas as instncias:
Observao: A definio de DML_LOCKS e RESULT_CACHE_MAX_SIZE s dever ser idntica em
todas as instncias se for igual a zero. A desativao do cache de resultados em algumas
instncias pode originar resultados incorretos.

Parmetros Que Exigem Definies Exclusivas
Definies da instncia:
INSTANCE_NAME
INSTANCE_NUMBER
UNDO_TABLESPACE
CLUSTER_INTERCONNECTS
ROLLBACK_SEGMENTS
Quando for necessrio definir parmetros com definies exclusivas em um banco de dados
gerenciado por polticas, voc pode garantir que as instncias sempre usem o mesmo nome
em ns particulares executando o comando srvctl modify instance -n node -i
instance_name em cada servidor que for designado para o pool de servidores do banco de
dados. Ento, um valor exclusivo do parmetro pode ser especificado para o
instance_name usado sempre que o banco de dados for executado em node_name.
Especifique a varivel de ambiente ORACLE_SID, que composta pelo nome do banco de
dados e pelo nmero do INSTANCE_NAME designado instncia. Use o parmetro
CLUSTER_INTERCONNECTS para especificar uma interconexo alternativa para o Oracle
Clusterware que estiver usando a rede privada. Cada instncia do banco de dados RAC
recebe um valor exclusivo quando se define o parmetro de inicializao
CLUSTER_INTERCONNECTS.
O Oracle Database usa o parmetro INSTANCE_NUMBER para distinguir entre instncias na
inicializao e o parmetro INSTANCE_NAME para designar grupos de redo log para instncias
especficas. O nome da instncia pode assumir o formato
db_unique_name_instance_number e quando tiver este formato de nome e nmero separado
por um caractere de sublinhado, o nmero aps o caractere de sublinhado usado como o
INSTANCE_NUMBER. Quando UNDO_TABLESPACE for especificado com o gerenciamento
automtico de undo habilitado, defina esse parmetro com um nome exclusivo de tablespace
de undo para cada instncia.
Se voc usar os parmetros ROLLBACK_SEGMENTS, a Oracle recomenda definir valores
exclusivos para eles usando o identificador SID no SPFILE. Todavia, defina um valor
exclusivo para INSTANCE_NUMBER em cada instncia e no use o valor padro.

Indisponibilizando Bancos de Dados RAC

com o Comando Quiesce
Use a instruo ALTER SYSTEM QUIESCE RESTRICTED
em uma nica instncia:
SQL> ALTER SYSTEM QUIESCE RESTRICTED;
necessrio que o Database Resource Manager esteja
ativado para emitir essa instruo.
O banco de dados no poder ser aberto por outras
instncias aps o incio da instruo ALTER SYSTEM
QUIESCE.
As instrues ALTER SYSTEM QUIESCE RESTRICTED e
ALTER SYSTEM UNQUIESCE afetam todas as instncias
de um ambiente RAC.
Backups com shutdown no podero ser feitos quando o
banco de dados estiver indisponvel pelo comando Quiesce.
Para indisponibilizar um banco de dados RAC com o comando quiesce, execute a instruo
ALTER SYSTEM QUIESCE RESTRICTED em uma instncia. No ser possvel abrir o banco de
dados em qualquer instncia enquanto ele estiver sendo indisponibilizado pelo comando
quiesce em outra instncia. Depois que todas as sesses no-DBA se tornarem inativas, a
instruo ALTER SYSTEM QUIESCE RESTRICTED ser executada e o banco de dados ser
considerado indisponibilizado. Em um ambiente RAC, essa instruo afeta todas as instncias.
Para executar a instruo ALTER SYSTEM QUIESCE RESTRICTED em um ambiente RAC,
necessrio ter o recurso Database Resource Manager ativado em todas as instncias do banco
de dados desde a inicializao da instncia. por meio do Database Resource Manager que
evitamos que sesses no-DBA se tornem ativas. As seguintes condies se aplicam a
ambientes RAC:
Se voc tiver executado a instruo ALTER SYSTEM QUIESCE RESTRICTED, mas o servidor
Oracle no tiver terminado de process-la, no ser possvel abrir o banco de dados.
Voc no poder abrir o banco de dados se ele j tiver sido indisponibilizado pelo
comando quiesce.
As instrues ALTER SYSTEM QUIESCE RESTRICTED e ALTER SYSTEM UNQUIESCE afetam
todas as instncias de um ambiente RAC, e no apenas a instncia que executa o
comando.
Backups com shutdown no podero ser realizados quando o banco de dados estiver
indisponvel pelo comando Quiesce. Isso impedir que os processos Oracle de background
faam atualizaes internas durante esse perodo. Alm disso, os cabealhos de arquivos de
dados on-line continuaro a ser exibidos como se estivessem sendo acessados. Eles tero uma
aparncia diferente da que teriam caso um shutdown simples tivesse sido feito.
Encerrando Sesses em uma Instncia Especfica

SQL> SELECT SID, SERIAL#, INST_ID
2 FROM GV$SESSION WHERE USERNAME='JMW';
SID SERIAL# INST_ID
---------- ---------- ----------
140 3340 2
SQL> ALTER SYSTEM KILL SESSION '140,3340,@2';
System altered.
SQL>
ALTER SYSTEM KILL SESSION '140,3340,@2'

*
ERROR at line 1:
ORA-00031: session marked for kill
Voc pode usar a instruo ALTER SYSTEM KILL SESSION para encerrar uma sesso em uma
instncia especfica. O slide acima ilustra isso encerrando uma sesso iniciada em uma
instncia diferente da que foi usada para encerrar a sesso problemtica.
Se a sesso estiver executando alguma atividade que deve ser concluda, por exemplo,
aguardando uma resposta de um banco de dados remoto ou fazendo um rollback de uma
transao, o Oracle Database aguardar a concluso dessa atividade, marcar a sesso
como terminada e devolver o controle para voc. Se a espera durar um minuto, o Oracle
Database marcar a sesso para ser encerrada e devolver o controle para voc com uma
mensagem informando que a sesso est marcada para ser encerrada. Em seguida, o
processo de background PMON marca a sesso como encerrada quando a atividade
concluda.
O exemplo acima supe que a continuidade do aplicativo no foi configurada. Se a
continuidade do aplicativo tiver sido configurada e voc desejar encerrar a sesso sem que
ela seja reproduzida, use a opo noreplay :
alter system kill session 'sid, serial#, @inst' noreplay;
ou
alter system disconnect session 'sid, serial#, @inst' noreplay

Como os Comandos SQL*Plus

Afetam as Instncias
Comando do SQL*Plus Instncia Associada

ARCHIVE LOG Em geral, afeta a instncia atual
CONNECT Afeta a instncia default se nenhuma instncia
for especificada no comando CONNECT
RECOVER No afeta uma instncia especfica, mas o
banco de dados inteiro
SHOW PARAMETER e Mostra o parmetro da instncia atual e
SHOW SGA informaes SGA
STARTUP e Afetam a instncia atual
SHUTDOWN
SHOW INSTANCE Exibe informaes sobre a instncia atual
A maioria das instrues SQL afeta a instncia atual. O SQL*Plus pode ser usado para iniciar
e interromper instncias do banco de dados Oracle RAC. Voc no precisa executar
comandos SQL*Plus como o usurio root em sistemas Linux e UNIX ou como o usurio
Administrator em sistemas Windows. Voc s precisa da conta de banco de dados
apropriada com os privilgios usados normalmente para administrao de banco de dados
Oracle no-clusterizado. Estes so alguns exemplos de como os comandos SQL*Plus afetam
as instncias:
ALTER SYSTEM CHECKPOINT LOCAL afeta a instncia atual.
ALTER SYSTEM CHECKPOINT ou ALTER SYSTEM CHECKPOINT GLOBAL afeta todas
as instncias de um banco de dados de cluster.
ALTER SYSTEM SWITCH LOGFILE afeta apenas a instncia atual.
- Para impor uma alternncia de log global, use a instruo ALTER SYSTEM
ARCHIVE LOG CURRENT.
- A opo INSTANCE de ALTER SYSTEM ARCHIVE LOG permite armazenar cada
arquivo de redo log on-line de uma instncia especfica.
A opo INSTANCE de ALTER SYSTEM ARCHIVE LOG permite armazenar cada
arquivo de redo log on-line de uma instncia especfica.

Transparent Data Encryption e

Keystores no ambiente RAC
Uma wallet compartilhada por todas as instncias no
armazenamento compartilhado:
No so necessrias tarefas de administrao adicionais.
Uma cpia da keystore em cada armazenamento local:
As cpias locais precisaro ser sincronizadas sempre que a
chave mestra for alterada.
ALTER SYSTEM SET ENCRYPTION KEY 1
keystore keystore keystore

Cpia
Chaves manual
Chave mestra Chave mestra
mestras
2
N1 N2 Nn
Cpia manual
O Oracle Database permite que os ns de RAC compartilhem o keystore (wallet). Isto elimina
a necessidade de copiar e sincronizar manualmente o keystore em todos os ns. A Oracle
recomenda que voc crie o keystore em um sistema de arquivos compartilhados. Isto permite
que todas as instncias acessem o mesmo keystore compartilhado. O Oracle RAC usa
keystores nas seguintes formas:
1. Qualquer operao de keystore, como abertura ou fechamento do keystore, executada
em alguma instncia do Oracle RAC vlida em todas as outras instncias do Oracle
RAC. Isto significa que quando voc abre e fecha o keystore em uma instncia, ento o
keystore aberto e fechado em todas as instncias do Oracle RAC.
2. Ao usar um sistema de arquivos compartilhados, certifique-se de que o parmetro
ENCRYPTION_WALLET_LOCATION em todas as instncias do Oracle RAC apontem
para o mesmo local do keystore compartilhado. O administrador de segurana tambm
deve garantir a segurana do keystore compartilhado designando permisses
apropriadas ao diretrio.
3. Uma redefinio de chave mestra executada em uma instncia se aplica em todas as
instncias. Quando um novo n do Oracle RAC surge, est a par do status atual de
abertura ou fechamento do keystore.
4. No emita nenhuma instruo SQL de keystore ADMINISTER KEY MANAGEMENT SET
KEYSTORE OPEN ou CLOSE enquanto estiver configurando ou alterando a chave
mestra.
As implantaes em que o armazenamento compartilhado no exista para o keystore
requerem que cada n do Oracle RAC mantenha um keystore local. Depois que voc cria e
provisiona um keystore em um nico n, deve copiar o keystore e torn-lo disponvel em
todos os outros ns, como se segue:
Em sistemas que usam Transparent Data Encryption com keystores criptografados,
voc pode usar qualquer protocolo de transporte de arquivos padro, embora a Oracle
recomende usar um transporte de arquivos protegido.
Para sistemas que usam Transparent Data Encryption com keystores de login
automtico, convm usar o transporte de arquivos por meio de um canal seguro.
Para especificar o diretrio no qual o keystore ir residir, defina o parmetro
ENCRYPTION_WALLET_LOCATION no arquivo sqlnet.ora. As cpias locais do keystore
no precisaro ser sincronizadas durante o uso de Transparent Data Encryption at que a
chave do servidor seja redefinida usando a instruo SQL ADMINISTER KEY MANAGEMENT
SET KEY SQL. Sempre que executar a instruo ADMINISTER KEY MANAGEMENT SET
KEY em uma instncia do banco de dados, voc dever copiar novamente o keystore
residente nesse n e disponibiliz-lo a todos os outros ns. Em seguida, dever fechar e
reabrir o keystore em cada um dos ns. Para evitar um overhead administrativo
desnecessrio, reserve a redefinio para casos excepcionais em que tiver certeza do
comprometimento da chave mestra do servidor e que sua no-redefinio causar um srio
problema de segurana.
Observao: Se o Oracle ACFS (Oracle Automatic Storage Management Cluster File
System) estiver disponvel para o seu sistema operacional, a Oracle recomenda que voc
armazene o keystore no Oracle ACFS.

Questionrio
Se uma instncia for iniciada em um ambiente RAC gerenciado

por poltica e no houver thread nem arquivo de redo log
disponvel, o Oracle Clusterware automaticamente ativar um
thread de redo e alocar os arquivos de redo log e undo se o
banco de dados usar o Oracle ASM ou qualquer sistema de
arquivos clusterizados e o OMF estiver ativado.
a. Verdadeiro
b. Falso
Resposta: a

Questionrio
Qual das seguintes afirmaes no verdadeira?

a. Vrias instncias podem abrir o mesmo banco de dados
simultaneamente.
b. O shutdown de uma instncia no interfere na execuo
das outras instncias.
c. A opo SHUTDOWN TRANSACTIONAL LOCAL no
esperar que a execuo das transaes de outras
instncias termine.
d. Fazer shutdown de um banco de dados RAC significa
fazer shutdown de todas as instncias que esto
acessando o banco de dados.
Resposta: c

Sumrio

Usar pginas de Banco de Dados Clusterizado do
Enterprise Manager
Definir arquivos de redo log em um ambiente RAC
Definir tablespaces de undo em um ambiente RAC
Iniciar e interromper bancos de dados e instncias RAC
Modificar os parmetros de inicializao em um
ambiente RAC


Usando conexes autenticadas pelo arquivo de senhas e
pelo sistema operacional
Usando conexes autenticadas pelo Oracle Database
Interrompendo uma pilha completa de componentes
ORACLE_HOME

e Recuperao no Ambiente RAC

Gerenciando Operaes de Backup
Objetivos
Aps concluir esta lio, voc ser capaz de configurar:

O banco de dados RAC para usar o modo ARCHIVELOG
e a rea de recuperao rpida
O RMAN para o ambiente RAC

Recuperao de Instncia e RAC
Usar informaes
Remastering para outros caches
de recursos O LMS
enfileirados Remastering recupera
1 de recursos o GRD
do cache
2
Criar conjunto
O SMON de recuperao
recupera Reivindicao
de recurso
o banco 3
4 Roll forward do
de dados Agrupar redo
conjunto de recuperao
threads com falha
Tempo de recuperao
Quando uma instncia falha, e a falha detectada por outra instncia, a segunda instncia
executa o seguinte procedimento de recuperao:
1. Durante a primeira fase da recuperao, o GES (Global Enqueue Services) faz o
remastering dos enfileiramentos.
2. O GCS (Global Cache Services) faz o remastering dos recursos. O GCS faz o
remastering apenas dos recursos que perderam seus mestres. Durante esse perodo,
todas as solicitaes de recursos e de gravao do GCS so temporariamente
suspensas. No entanto, as transaes podem continuar e modificar blocos de dados,
contanto que j tenham adquirido os recursos necessrios.
3. Quando os enfileiramentos so reconfigurados, uma das instncias sobreviventes pode
obter a fila de recuperao da instncia. Portanto, enquanto feito o remastering dos
recursos do GCS, o SMON determina os blocos que necessitam de recuperao. Esse
conjunto de blocos chamado de conjunto de recuperao. Com o Cache Fusion, uma
instncia envia o contedo de seus blocos instncia solicitante sem gravar os blocos
no disco; portanto, a verso dos blocos armazenada no disco talvez no contenha as
alteraes feitas por cada instncia. Como consequncia, o SMON precisa agrupar o
contedo de todos os redo logs on-line de cada instncia com falha para determinar o
conjunto de recuperao. Isso ocorre porque um thread com falha pode no conter
informaes no redo que precisa ser aplicado a determinado bloco. Portanto, os redo
threads de instncias com falha no podem ser aplicados serialmente. Alm disso, os
threads de redo das instncias sobreviventes no so necessrios para a recuperao
porque o SMON pode usar imagens antigas ou atuais dos caches de buffer
correspondentes.
4. O espao de buffer para recuperao alocado, e os recursos que foram identificados na
leitura anterior dos redo logs so reivindicados como recursos de recuperao. Isso
feito para evitar que outras instncias acessem esses recursos.
5. Todos os recursos necessrios para o processamento subsequente so obtidos e o GRD
(Global Resource Directory) liberado. Todos os blocos de dados que no estiverem na
recuperao podero ser acessados. Observe que o sistema j est parcialmente
disponvel.
Em seguida, considerando que existam imagens antigas ou atuais dos blocos a serem
recuperadas em outros caches do banco de dados clusterizado, a imagem mais recente
ser o ponto de partida para a recuperao desses blocos especficos. Se os buffers de
imagens antigas e o buffer atual de um bloco de dados no estiverem nos caches das
instncias sobreviventes, o SMON intercalar os logs das instncias com falhas. O SMON
recupera e grava cada bloco identificado na etapa 3, liberando os recursos imediatamente
aps a recuperao do bloco para que mais blocos estejam disponveis no decorrer da
recuperao.
Depois que todos os blocos forem recuperados e os recursos de recuperao forem liberados,
o sistema estar de novo totalmente disponvel.
Resumindo, o banco de dados recuperado ou partes recuperadas do banco de dados so
disponibilizados antes da concluso da sequncia de recuperao inteira. Isso disponibiliza o
sistema mais cedo e torna a recuperao mais escalvel.
Observao: o overhead de desempenho de uma intercalao de logs proporcional ao
nmero de instncias com falha e ao tamanho do redo gravado nos redo logs de cada
instncia.

Recuperao de Instncia e Disponibilidade do

Banco de Dados
Integral A G H
5
Disponibilidade do
banco de dados
Parcial B F
2 4
1 3
Nenhum C D E
Tempo decorrido
O grfico ilustra o grau de disponibilidade do banco de dados durante cada etapa da

recuperao de uma instncia Oracle:
A. O sistema Real Application Clusters est sendo executado em vrios ns.
B. detectada uma falha em um n.
C. A parte enfileirada do GRD reconfigurada; o gerenciamento de recursos
redistribudo entre os ns sobreviventes. Essa operao relativamente rpida.
D. A parte de cache do GRD reconfigurada e o SMON l o redo log da instncia com
falha para identificar os blocos do banco de dados que precisam ser recuperados.
E. O SMON envia as solicitaes do GRD para obter os blocos do banco de dados
necessrios para a recuperao. Aps a concluso das solicitaes, todos os outros
blocos estaro acessveis.
F. O Oracle executa uma recuperao rollforward. Os redo logs dos threads com falha so
aplicados no banco de dados, e os blocos tornam-se disponveis logo aps a concluso
da recuperao.
G. O servidor Oracle executa uma recuperao rollback. Os blocos de undo so aplicados
no banco de dados para todas as transaes no submetidas a commit.
H. A recuperao da instncia concluda e todos os dados esto acessveis.
Observao: a linha tracejada representa os blocos identificados na etapa 2 do slide
anterior. As etapas identificadas no slide anterior so as que esto pontilhadas.
Inicializao da instncia
Falha de + Instncia
instncia recuperao aps falha aberta
FAST_START_MTTR_TARGET
Instncia
inicializada
Trmino
Recuperao de do roll
instncia forward
Falha de
instncia first pass + lock claim

FAST_START_MTTR_TARGET
Incio da
recuperao V$INSTANCE_RECOVERY.ESTD_CLUSTER_AVAILABLE_TIME
da instncia
Em um ambiente com uma nica instncia, a inicializao da instncia combinada com o

tempo para recuperao aps a falha controlado pela definio do parmetro de
inicializao FAST_START_MTTR_TARGET. Voc poder definir seu valor se desejar que o
checkpoint incremental seja mais agressivo que o checkpoint de autoajuste. Entretanto, isso
resultar em um overhead muito maior de entrada/sada.
Em um ambiente RAC, intil incluir o tempo de inicializao da instncia nesse caso, pois
uma das instncias sobreviventes estar executando a recuperao.
Em um ambiente RAC, possvel monitorar o limite de durao estimado, em segundos, a
partir do incio da recuperao da instncia at o momento de abertura de GCD para
solicitaes de bloqueio no caso dos blocos desnecessrios para recuperao. Essa
estimativa publicada na view V$INSTANCE_RECOVERY pela coluna
ESTD_CLUSTER_AVAILABLE_TIME. Basicamente, voc pode controlar o tempo de
congelamento do seu cluster durante as situaes de recuperao de instncia.
Em um ambiente RAC, o parmetro de inicializao FAST_START_MTTR_TARGET usado para
associar o tempo de recuperao de toda a instncia, supondo-se que seja uma recuperao
em caso de interrupo de uma nica instncia.
Observao: se realmente desejar definir um tempo de recuperao de instncia menor
para FAST_START_MTTR_TARGET, voc poder ignorar, com segurana, as mensagens de log
de alerta que indicam para aumentar o valor.

Use a recuperao paralela de instncias.

Defina PARALLEL_MIN_SERVERS.
Use entrada/sada assncrona.
Aumente o tamanho do cache de buffer default.
Veja a seguir algumas diretrizes que voc poder seguir para garantir uma recuperao mais
rpida de instncias em seu ambiente RAC:
Use a recuperao paralela de instncias definindo RECOVERY_PARALLISM.
Defina PARALLEL_MIN_SERVERS como CPU_COUNT-1. Isso pr-criar os escravos de
recuperao durante a inicializao.
Se ocorrer uma falha no sistema quando houver transaes DML ou DDL paralelas no
submetidas a commit, voc poder agilizar a recuperao das transaes durante a
inicializao definindo o parmetro FAST_START_PARALLEL_ROLLBACK.
O uso de entrada/sada assncrona um dos fatores mais cruciais no momento da
recuperao. A leitura de primeira passagem do log usa entrada/sada assncrona.
A recuperao de instncia usa 50% do cache de buffer default para buffers de
recuperao. Se isso no for suficiente, algumas etapas da recuperao de instncia
sero executadas em vrias passagens. Para identificar essas situaes, examine o
arquivo alert.log. Se for necessrio, aumente o tamanho do seu cache de buffer
default.

Proteo contra Falha de Mdia
Arquivos de log Arquivos de log
arquivados arquivados
Backups de
Discos banco de dados
espelhados
Embora o ambiente RAC fornea mtodos para evitar ou reduzir o perodo de

indisponibilidade decorrente de uma falha de uma ou mais instncias (mas no de todas),
voc precisa proteger o prprio banco de dados, que ser compartilhado por todas as
instncias. Isso significa que voc precisa considerar as estratgias de backup e recuperao
de disco tanto para um banco de dados clusterizado quanto para um banco de dados no
clusterizado.
Para minimizar a possibilidade de perda de dados resultante de falhas em discos, voc pode
usar a tecnologia de espelhamento de disco (disponibilizada pelo fornecedor do servidor ou
do disco). Assim como nos bancos de dados no clusterizados, voc poder ter mais de um
espelho, se o fornecedor permitir, para ajudar a reduzir o potencial de perda de dados e
oferecer estratgias de backup alternativas. Por exemplo, com o banco de dados no modo
ARCHIVELOG e com trs cpias dos discos, voc pode remover uma cpia-espelho e
executar o backup a partir dessa cpia, enquanto as duas cpias-espelho restantes
continuam a proteger a atividade contnua nos discos. Para executar esse procedimento
corretamente, primeiro coloque os tablespaces no modo de backup e, em seguida, caso seja
exigido pelo fornecedor de cluster ou disco, interrompa temporariamente as operaes no
disco executando o comando ALTER SYSTEM SUSPEND. Depois que a instruo for
concluda, para interromper o espelhamento e retomar as operaes normais, execute o
comando ALTER SYSTEM RESUME e retire os tablespaces do modo de backup.

Recuperao de Mdia no Oracle RAC
A recuperao de mdia deve ser iniciada pelo usurio por

meio de um aplicativo cliente.
Nessas situaes, use o RMAN para restaurar backups
dos arquivos de dados e, em seguida, recuperar o banco
de dados.
Os procedures de recuperao de mdia com o RMAN para
RAC no diferem de forma significativa dos procedures para
ambientes de instncia nica.
O n que executa a recuperao deve ser capaz de restaurar
todos os arquivos de dados necessrios.
Esse n tambm dever ser capaz de ler todos os redo logs
arquivados necessrios no disco ou restaur-los de backups.
Durante a recuperao de um banco de dados com
tablespaces criptografados, a Oracle Wallet dever ser aberta
aps a montagem e antes da abertura do banco de dados.
A recuperao de mdia deve ser iniciada pelo usurio por meio de um aplicativo cliente, na
qual a recuperao da instncia automaticamente executada pelo banco de dados. Nessas
situaes, use o RMAN para restaurar backups dos arquivos de dados e, em seguida,
recuperar o banco de dados. Os procedures de recuperao de mdia com o RMAN em
ambientes Oracle RAC no diferem de forma significativa dos procedures para ambientes de
instncia nica.
O n que executa a recuperao deve ser capaz de restaurar todos os arquivos de dados
necessrios. Esse n tambm dever ser capaz de ler todos os redo logs arquivados
necessrios no disco para restaur-los de backups. Cada instncia gera seus prprios logs
de arquivamento, que so cpias de seus threads de grupo de redo logs dedicados.
recomendvel que o ASM (Automatic Storage Management) ou um sistema de arquivos
clusterizados seja usado para consolidar esses arquivos.
Durante a recuperao de um banco de dados com tablespaces criptografados (por exemplo,
aps um SHUTDOWN ABORT ou um erro catastrfico que desative a instncia do banco de
dados), necessrio abrir a Oracle Wallet aps a montagem e antes da abertura do banco
de dados, de forma que o processo de recuperao possa descriptografar blocos de dados e
redo.

Recuperao Paralela no Ambiente RAC
O Oracle Database seleciona automaticamente o grau ideal

de paralelismo para:
Recuperao da instncia
Recuperao aps falha
Redo logs arquivados so aplicados usando um nmero ideal
de processos paralelos com base na disponibilidade de CPUs.
Com os comandos RESTORE e RECOVER do RMAN, as trs
fases de recuperao a seguir podem usar paralelismo:
Restaurao de arquivos de dados
Aplicao de backups incrementais
Aplicao de redo logs arquivados
Para desativar a recuperao paralela de instncias e falhas,
defina o parmetro RECOVERY_PARALLELISM como 0.
O Oracle Database seleciona automaticamente o grau ideal de paralelismo para a

recuperao de instncias e falhas. O Oracle Database aplica redo logs arquivados usando
um nmero ideal de processos paralelos com base na disponibilidade de CPUs. Com os
comandos RESTORE e RECOVER do RMAN, o Oracle Database usa automaticamente o
paralelismo para as trs fases de recuperao a seguir:
Restaurao de Arquivos de Dados: durante a restaurao de arquivos de dados, o
nmero de canais alocados no script de recuperao do RMAN define efetivamente o
paralelismo usado pelo RMAN. Por exemplo, se voc alocar cinco canais, poder ter
at cinco fluxos paralelos restaurando arquivos de dados.
Aplicao de Backups Incrementais: de forma similar, quando voc estiver aplicando
backups incrementais, o nmero de canais alocados determinar o paralelismo em
potencial.
Aplicao de Redo Logs Arquivados com o RMAN: o Oracle Database seleciona
automaticamente o grau ideal de paralelismo com base nos recursos de CPU
disponveis.
Para desativar a recuperao paralela de instncias e falhas em um sistema com vrias
CPUs, defina o parmetro RECOVERY_PARALLELISM como 0 ou 1.
Use a clusula NOPARALLEL do comando RECOVER do RMAN ou a instruo ALTER
DATABASE RECOVER para forar o banco de dados RAC a usar a recuperao de mdia no
paralela.
RAC e rea de Recuperao Rpida
rea de
recuperao
rpida
Sistema de arquivos Diretrio para

clusterizados NFS certificado
ASM
Para usar uma rea de recuperao rpida no ambiente RAC, coloque-a em um grupo de
discos ASM, em um sistema de arquivos clusterizados ou em um diretrio compartilhado que
seja configurado atravs do NFS certificado para cada instncia RAC. Isso significa que
preciso compartilhar a rea de recuperao rpida entre todas as instncias de um banco de
dados RAC. Alm disso, defina o mesmo valor para o parmetro DB_RECOVERY_FILE_DEST
em todas as instncias.
O Oracle Enterprise Manager permite configurar uma rea de recuperao rpida. Para usar
esse recurso:
1. Na home page Cluster Database, clique no menu pull-down Availability.
2. Selecione Backup and Recovery > Recovery Settings.
3. Especifique seus requisitos na seo Flash Recovery Area da pgina.

Backup e Recuperao do Ambiente RAC com o EM
Para acessar as tarefas relacionadas a backup e recuperao do Cluster Database, clique na

tab Availability localizada na home page Cluster Database. Na pgina com a tab Availability,
voc pode executar vrias operaes de backup e recuperao com o RMAN, como
programar backups, executar uma recuperao quando necessrio e configurar definies de
backup e recuperao. Alm disso, h links relacionados ao gerenciamento do Oracle
Secure Backup and Service.

Configurando as Definies de Recuperao do

Ambiente RAC com o EM
possvel usar o Enterprise Manager para configurar importantes definies de recuperao

do banco de dados clusterizado. Na home page Database, clique na tab Availability e, em
seguida, clique no link Recovery Settings. Nesse local, voc poder verificar se o banco de
dados est no modo ARCHIVELOG e configurar as definies da recuperao flash.
Com um banco de dados RAC, se a definio Archive Log Destination no for a mesma para
todas as instncias, o campo aparecer em branco, com uma mensagem indicando que as
instncias tm definies diferentes para esse campo. Nesse caso, a especificao de um
local nesse campo definir a localizao do log de arquivamento para todas as instncias do
banco de dados. Na pgina Initialization Parameters, voc pode designar valores especficos
instncia para um destino de log de arquivamento.
Observao: voc poder executar a instruo SQL ALTER DATABASE para alterar o modo
de arquivamento no ambiente RAC, contanto que o banco de dados seja montado pela
instncia local, mas no seja aberto em nenhuma instncia. Para executar essa instruo,
voc no precisar modificar as definies de parmetro. Defina o mesmo valor para os
parmetros de inicializao DB_RECOVERY_FILE_DEST e
DB_RECOVERY_FILE_DEST_SIZE em todas as instncias, o que configurar uma rea de
recuperao rpida em um ambiente RAC.

Convenes de Arquivos de Redo

Arquivados no Ambiente RAC
Varivel Descrio Exemplo
%t Nmero do thread, no preenchido log_1
Nmero do thread, preenchido
%T log_0001
esquerda com zeros
Nmero da sequncia do log, no
%s log_251
preenchido
Nmero da sequncia de log,
%S log_0000000251
preenchido esquerda com zeros
%r Identificador resetlogs log_23452345
%R Identificador resetlogs preenchido log_0023452345
%t_%s_%r Usando diversas variveis log_1_251_23452345
Para qualquer configurao de redo log arquivado, identifique exclusivamente os redo logs
arquivados com o parmetro LOG_ARCHIVE_FORMAT. O formato desse parmetro
especfico ao sistema operacional e pode incluir strings de texto, uma ou mais variveis e
uma extenso de nome de arquivo.
Todos os parmetros de thread, em maisculas ou minsculas, so obrigatrios para o
ambiente RAC. Isso permite que o banco de dados Oracle crie nomes exclusivos para logs
de arquivamento em vrias verses. Esse requisito estar em vigor quando o parmetro
COMPATIBLE for definido como 10.0 ou um valor mais alto. Use o parmetro %R ou %r para
incluir o identificador resetlogs, evitando a sobregravao dos logs de uma verso anterior.
Se voc no especificar um formato de log, o default ser especfico do sistema operacional
e incluir %t, %s e %r.
Por exemplo, se a instncia associada ao nmero do thread de redo 1 definir
LOG_ARCHIVE_FORMAT como log_%t_%s_%r.arc, seus arquivos de redo log arquivados
sero denominados desta forma:
log_1_1000_23435343.arc
log_1_1001_23452345.arc
log_1_1002_23452345.arc
...
Observao: o parmetro LOG_ARCHIVE_FORMAT no entrar em vigor se o OMF (Oracle
Managed Files) tiver sido implementado para o banco de dados Oracle RAC.
Configurando as Definies de Backup do

Ambiente RAC com o EM
possvel configurar definies de backup persistentes no Enterprise Manager. Na home

page Cluster Database, clique na tab Availability, selecione Backup and Recovery e, em
seguida, clique no link Backup Settings. Voc pode configurar as definies do disco, como a
localizao do diretrio de backups do disco e o nvel de paralelismo. Voc tambm pode
escolher o tipo de backup default:
Conjunto de backup
Conjunto de backup compactado
Cpia-imagem
Alm disso, voc pode especificar definies importantes relacionadas a fitas, como o
nmero de drives de fita disponveis e os parmetros de gerenciamento de mdia especficos
do fornecedor e o domnio do Oracle Secure Backup.

Oracle Recovery Manager
O RMAN oferece as seguintes

Recovery vantagens para o ambiente
Manager Real Application Clusters:
Catlogo de Pode ler arquivos
recuperao
Arquivos clusterizados ou do
Processo
de log
do servidor
ASM sem alteraes
arquivados de configurao
Oracle
Scripts
Armaze- Pode acessar vrios
nados destinos de log de
arquivamento
Banco de dados
Oracle
Armazena-
mento de Arquivo de
backup controle de
snapshot
O Oracle Database fornece o RMAN para backup e restaurao do banco de dados. O

RMAN permite fazer backup, restaurao e recuperao de arquivos de dados, arquivos de
controle, SPFILEs e redo logs arquivados. possvel executar o RMAN a partir da linha de
comandos ou us-lo no Backup Manager no Enterprise Manager. Alm disso, o RMAN a
ferramenta recomendada para backup e recuperao se voc estiver usando ASM. O RMAN
pode usar scripts armazenados, scripts interativos ou um front-end de GUI interativa. Ao usar
o RMAN com o banco de dados RAC, utilize scripts armazenados para iniciar os processos
de backup e recuperao no n mais adequado.
Se voc usar diferentes Oracle Homes para as instncias RAC em cada um dos ns, crie um
arquivo de controle de snapshot em um local que exista em todos os seus ns. O arquivo de
controle de snapshot somente necessrio nos ns em que o RMAN executa operaes de
backup.
Voc pode usar um arquivo de cluster ou um diretrio local existente em cada n do cluster.
Este um exemplo:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE TO
'/oracle/db_files/snaps/snap_prod1.cf';
Para a recuperao, certifique-se de que cada n de recuperao possa acessar os arquivos
de log de arquivamento de todas as instncias usando um dos esquemas de arquivamento
discutidos anteriormente, ou disponibilize os logs arquivados para a instncia de recuperao
copiando esses logs de outro local.
Configurando a Localizao do Arquivo de

Controle de Snapshot no RMAN
O caminho do arquivo de controle de snapshot deve ser
vlido em todos os ns a partir dos quais for possvel
iniciar um backup do RMAN.
Configure a localizao do arquivo de controle de
snapshot no RMAN.
Determine a localizao atual:
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
'/u01/app/oracle/product/12.1.0/dbhome_1/dbs/snapcf_orcl_3.f'
Voc poder usar o ASM ou um local compartilhado no

sistema de arquivos:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'+FRA/SNAP/snap_prod.cf';
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/ocfs2/oradata/dbs/scf/snap_prod.cf';
O arquivo de controle de snapshot uma cpia de um arquivo de controle de banco de

dados criado pelo RMAN em um local especfico ao sistema operacional. O RMAN cria o
arquivo de controle de snapshot para ter uma verso consistente de um arquivo de controle
para uso durante a ressincronizao do catlogo de recuperao ou backup do arquivo de
controle. Voc tambm pode criar um arquivo de controle de snapshot inserindo o seguinte
comando no prompt do RMAN: DUPLICATE FROM ACTIVE. possvel especificar um
sistema de arquivos clusterizados ou um destino de grupo de discos ASM para o local de seu
arquivo de controle de snapshot. Esse arquivo compartilhado entre todos os ns do cluster
e dever ser acessvel a todos os seus ns.
possvel alterar a localizao configurada do arquivo de controle de snapshot. Por
exemplo, em sistemas Linux e UNIX, voc pode alterar o local do arquivo de controle de
snapshot usando o comando CONFIGURE SNAPSHOT CONTROLFILE NAME do RMAN.
Esse comando define a configurao da localizao do arquivo de controle de snapshot para
todas as instncias do banco de dados clusterizado. Portanto, verifique se o local
especificado existe em todos os ns que executam backups. O comando CONFIGURE cria
definies persistentes nas sesses do RMAN. Dessa forma, voc no precisa executar esse
comando novamente, a menos que deseje alterar a localizao do arquivo de controle de
snapshot. Para excluir um arquivo de controle de snapshot, necessrio primeiro alterar a
sua localizao e, em seguida, excluir o arquivo na localizao antiga, da seguinte forma:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'new_name';
DELETE COPY OF CONTROLFILE;
Configurando o Backup Automtico do Arquivo

de Controle e do SPFILE
O RMAN cria automaticamente backups do arquivo de
controle e do SPFILE aps o comando BACKUP ou COPY:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Altere a localizao default:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR
DEVICE TYPE DISK TO '+DATA';
O local deve estar disponvel para todos os ns do banco

de dados RAC.
Se voc definir CONFIGURE CONTROLFILE AUTOBACKUP como ON, o RMAN criar

automaticamente backups do arquivo de controle e do SPFILE aps a execuo do comando
BACKUP ou COPY. O RMAN tambm poder restaurar automaticamente um SPFILE se isso for
necessrio para iniciar uma instncia e fazer a recuperao. Isso significa que a localizao
default do SPFILE deve estar disponvel para todos os ns do banco de dados RAC.
Esses recursos so importantes na recuperao aps acidentes, pois o RMAN poder
restaurar o arquivo de controle at mesmo sem um catlogo de recuperao. O RMAN
poder restaurar um arquivo de controle do backup automtico at mesmo aps a perda do
catlogo de recuperao e do arquivo de controle atual.
Para alterar o nome default atribudo a esse arquivo pelo RMAN, use o comando CONFIGURE
CONTROLFILE AUTOBACKUP FORMAT. Se voc especificar um nome de caminho absoluto
nesse comando, esse caminho dever existir de forma idntica em todos os ns que
estiverem participando das operaes de backup.
O RMAN executa o backup automtico dos arquivos de controle no primeiro canal alocado.
Portanto, quando voc alocar vrios canais com parmetros diferentes (especialmente se
alocar um canal com o comando CONNECT, determine qual canal executar o backup
automtico do arquivo de controle. Aloque sempre o canal para este n primeiro. Alm de
usar o arquivo de controle do RMAN, voc tambm pode usar o Oracle Enterprise Manager
para empregar os recursos do RMAN.

Efetuando a Verificao Cruzada em Vrios Ns

de Clusters em um Ambiente RAC
Ao efetuar a verificao cruzada em vrios ns, certifique-se
de que todos os backups possam ser acessados por todos os
ns do cluster.
Esse procedimento permite alocar canais em cada n do
cluster durante as operaes de restaurao ou
verificao cruzada.
Caso contrrio, ser necessrio alocar canais em vrios
ns fornecendo a opo CONNECT ao comando
CONFIGURE CHANNEL.
Se os backups no estiverem acessveis porque no foi
configurado nenhum canal no n que possa acessar esses
backups, eles sero marcados como EXPIRED.
Ao efetuar a verificao cruzada em vrios ns do RAC, configure o cluster de forma que

todos os backups possam ser acessados por todos os ns, independentemente de qual n
tenha criado o backup. Quando o cluster configurado dessa forma, voc pode alocar canais
em qualquer n do cluster durante operaes de restaurao ou verificao cruzada.
Se voc no puder configurar o cluster de forma que todos os ns possam acessar todos os
backups, durante as operaes de restaurao ou verificao cruzada, voc dever alocar
canais em vrios ns fornecendo a opo CONNECT ao comando CONFIGURE CHANNEL, de
forma que cada backup possa ser acessado por pelo menos um n. Se alguns backups no
estiverem acessveis durante a verificao cruzada porque no foi configurado nenhum canal
no n que possa acessar esses backups, eles sero marcados como EXPIRED no repositrio
do RMAN aps a verificao cruzada.
Por exemplo, voc pode usar CONFIGURE CHANNEL ... CONNECT em uma configurao
do Oracle RAC em que backups em fita forem criados em vrios ns do cluster e todos os
backups possam ser acessados somente no n em que foram criados.

Conexes de Canais com Instncias do Cluster

Durante o backup, cada canal alocado pode estabelecer
conexo com uma instncia especfica do cluster.
As instncias com as quais os canais estabelecem
conexo devero estar todas montadas ou abertas.
Ao decidir o canal a ser usado, o RMAN d preferncia
aos ns com acesso mais rpido aos arquivos de dados
para backup.
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT='sys/rac@orcl_1';
OU
CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT='sys/rac@bkp_serv';
Nos backups em paralelo, os canais do RMAN podem estabelecer conexo com outra
instncia do cluster. Os exemplos do slide ilustram duas configuraes possveis:
Se desejar dedicar canais a instncias especficas, voc poder controlar a instncia na
qual os canais esto alocados usando strings de conexo separadas para cada
configurao de canal, conforme mostrado no primeiro exemplo.
Se definir um servio especial para seus jobs de backup e recuperao, voc poder
usar o segundo exemplo mostrado no slide. Se voc configurar esse servio com o
balanceamento de carga ativado, os canais sero alocados em um n, conforme
decidido pelo algoritmo de balanceamento de carga.
Em um backup, as instncias com quais os canais estabelecem conexo devero estar todas
montadas ou abertas. Por exemplo, se o banco de dados estiver montado para a instncia
orcl_1 e aberto para as instncias orcl_2 e orcl_3, ocorrer uma falha de backup.
Em algumas configuraes de banco de dados RAC, alguns ns do cluster tm acesso mais
rpido a determinados arquivos de dados do que a outros. O RMAN detecta isso
automaticamente, conhecido como percepo da afinidade do n. Ao decidir o canal a ser
usado para executar o backup de um determinado arquivo de dados, o RMAN d preferncia
aos ns com acesso mais rpido aos arquivos de dados para backup.

Suporte ao Canal do RMAN para o Grid
O ambiente RAC permite o uso de strings de conexo no

deterministas.
O RMAN pode usar strings de conexo que no sejam
vinculadas a uma instncia especfica do ambiente do
Grid.
Ele simplifica o uso de paralelismo com o RMAN em um
ambiente RAC.
Ele usa as caractersticas de balanceamento de carga do
ambiente do Grid.
Os canais estabelecem conexo com as instncias RAC
menos carregadas.
O ambiente RAC permite o uso de strings de conexo no deterministas capazes de

estabelecer conexo com diferentes instncias com base nos recursos do ambiente RAC,
como balanceamento de carga. Portanto, para suportar o ambiente RAC, o mecanismo de
polling do RMAN no depende mais das strings de conexo deterministas e permite usar
RMAN com strings de conexo no associadas a uma instncia especfica no ambiente do
Grid. Anteriormente, se quisesse usar o paralelismo de RMAN e distribuir um job entre vrias
instncias, voc tinha que alocar manualmente um canal do RMAN para cada instncia. Para
usar a alocao dinmica de canais, voc no precisa mais de instrues CONFIGURE
CHANNEL CONNECT separadas. Voc s precisa definir o grau de paralelismo usando um
comando, como CONFIGURE DEVICE TYPE disk PARALLELISM, e, em seguida, dever
executar o comando de backup ou restaurao. Depois disso, o RMAN se conectar
automaticamente a diferentes instncias e executar o job em paralelo. O ambiente do Grid
seleciona as instncias para a conexo do RMAN com base no balanceamento de carga.
Como resultado, a configurao do paralelismo de RMAN em um ambiente RAC passa a ser
to simples como sua configurao em um ambiente no-RAC. Com a configurao do
paralelismo no procedimento de backup ou recuperao de um banco de dados RAC, os
canais do RMAN so dinamicamente alocados em todas as instncias RAC.
Observao: o RMAN no tem controle sobre a seleo das instncias. Se precisar de uma
conexo garantida com uma instncia, fornea uma string de conexo que possa estabelecer
conexo apenas com a instncia necessria.

Localizao Automtica Default do RMAN
O Recovery Manager determina automaticamente a

localizao dos seguintes arquivos:
Componentes de backup
Redo logs arquivados durante o backup
Cpias de arquivos de dados ou de controle
Se for usado arquivamento local, um n somente poder
ler os logs arquivados que foram gerados nele.
Na restaurao, um canal conectado a um n especfico
restaura apenas os arquivos submetidos a backup no n.
O Recovery Manager detecta automaticamente quais ns de uma configurao RAC podem

acessar os arquivos cujo backup ou restaurao voc deseja executar. O Recovery Manager
determina automaticamente a localizao dos seguintes arquivos:
Componentes de backup durante um backup ou uma restaurao
Redo logs arquivados durante o backup
Cpias de arquivos de dados ou de controle durante o backup ou a restaurao
Se voc usar um esquema de arquivamento local do sistema de arquivos no clusterizados,
um n somente poder ler os redo logs arquivados que foram gerados por uma instncia
nesse n. O RMAN nunca tenta fazer backup dos redo logs arquivados localizados em um
canal que ele no consiga ler.
Durante uma operao de restaurao, o RMAN executa automaticamente a localizao dos
backups. Um canal conectado a um n especfico tenta restaurar somente os arquivos
submetidos a backup no n. Por exemplo, suponha que tenha sido feito backup da sequncia
de log 1001 no drive conectado ao n 1, ao passo que o backup do log 1002 tenha sido feito
no drive conectado ao n 2. Se voc depois alocar canais que estabeleam conexo com
cada n, o canal conectado ao n 1 poder restaurar o log 1001 (mas no o 1002), e o canal
conectado ao n 2 poder restaurar o log 1002 (mas no o 1001).

Distribuio de Backups
H algumas possveis configuraes de backup para o

ambiente RAC:
Um servidor de backup dedicado executa e gerencia
backups do cluster e do banco de dados do cluster.
Um n tem acesso a um dispositivo de backup local,
executa e gerencia backups para o banco de dados do
cluster.
Cada n tem acesso a um dispositivo de backup local e
pode gravar dados na prpria mdia de backup local.
Ao configurar as opes de backup para o ambiente RAC, voc tem algumas possveis
configuraes:
Servidor de backup de rede: Um servidor de backup dedicado executa e gerencia
backups do cluster e do banco de dados do cluster. Nenhum dos ns tem um
dispositivo de backup local.
Um drive local: Um n tem acesso a um dispositivo de backup local, executa e
gerencia backups para o banco de dados do cluster. Todos os ns do cluster devero
estar em um sistema de arquivos clusterizados para poderem ler todos os arquivos de
dados, redo logs arquivados e SPFILEs. No use o esquema de arquivamento do
sistema de arquivos no clusterizados se a mdia de backup estiver em apenas um
drive local.
Vrios drives: Cada n tem acesso a um dispositivo de backup local e pode gravar
dados na prpria mdia de backup local.
No esquema de sistema de arquivos clusterizados, qualquer n pode acessar todos os
arquivos de dados, redo logs arquivados e SPFILEs. No esquema de sistema de arquivos
no clusterizados, crie o script de backup de modo que o backup seja distribudo para o drive
e o caminho corretos de cada n. Por exemplo, o n 1 pode fazer backup dos redo logs
arquivados cujos caminhos comecem com /arc_dest_1; o n 2 pode fazer backup dos
redo logs arquivados cujos caminhos comecem com /arc_dest_2, e o n 3 pode fazer
backup dos redo logs arquivados cujos caminhos comecem com /arc_dest_3.
Gerenciando Redo Logs Arquivados com o RMAN
Quando um redo log arquivado gerado, o Oracle registra

o nome do log no arquivo de controle do banco de dados
de destino.
Se um catlogo de recuperao for usado, o RMAN
registra os nomes de redo log arquivados no catlogo
quando ocorrer uma ressincronizao.
A estratgia de backup e recuperao que for escolhida
depende de como os destinos de arquivamento forem
configurados.
Quando um n gera um redo log arquivado, o Oracle Database sempre registra o nome de
arquivo do log no arquivo de conrole do banco de dados de destino. Se voc estiver usando
um catlogo de recuperao, o RMAN tambm registra os nomes do arquivo de redo log
arquivados no catlogo de recuperao, quando ocorrer uma ressincronizao.
O esquema de nomeao do redo log arquivado que voc usar importante, pois quando um
n grava em um log com um nome de arquivo especfico no sistema de arquivos, o arquivo
deve ser legvel por qualquer n que tenha que acessar este redo log arquivado. Por
exemplo, se o node1 arquivar um log em /oracle/arc_dest/log_1_100_23452345.arc,
ento o n2 pode efetuar o backup deste redo log arquivado somente se puder ler
/oracle/arc_dest/log_1_100_23452345.arc no seu prprio sistema de arquivos.
A estratgia de backup e recuperao que for escolhida depende de como os destinos de
arquivamento forem configurados em cada n. Independentemente de apenas um n ou
todos os ns executarem backps de redo log arquivados, voc deve garantir que haja o
backup de todos os redo logs arquivados. Se voc usar o paralelismo do RMAN durante a
recuperao, ento o n que executar a recuperao deve ter acesso de leitura a todos os
redo logs arquivados no seu cluster.
Mltiplos ns podem restaurar logs arquivados de forma paralela. Entretanto, durante a
recuperao, somente um n aplica os logs arquivados. Portanto, o n que estiver realizando
a recuperao deve poder acessar todos os logs arquivados que forem necessrios para a
operao de recuperao. Por padro, o banco de dados determina o nmero ideal de
threads paralelos a usar durante a operao de recuperao. Voc pode usar a clusula
PARALLEL no comando RECOVER para alterar o nmero de threads paralelos.
Esquema de Arquivamento Local do Sistema de

Arquivos No-clusterizado
Ao se arquivar localmente em um sistema de arquivos
no-clusterizados, cada n arquiva em um diretrio local
nomeado exclusivamente.
Se for necessria a recuperao, configure o n de
recuperao para que ele possa acessar diretrios nos
outros ns remotamente.
Use NFS em computadores com Linux e UNIX.
Use drives mapeados em sistemas com Windows.
Cada n grava em um destino local, mas pode ler arquivos
de redo log arquivados em diretrios remotos em outros ns.
Se o arquivamento local no-clusterizado for usado para
recuperao de mdia, configure o n que estiver executando
a recuperao para acesso remoto.
Ao se arquivar localmente em um sistema de arquivos no-clusterizados, cada n arquiva em

um diretrio local nomeado exclusivamente. Se for necessria a recuperao, configure o n
de recuperao para que ele possa acessar diretrios nos outros ns remotamente. Por
exemplo, use NFS em computadores Linux e UNIX, ou unidades de disco mapeadas em
sistemas Windows. Portanto, cada n grava somente em um destino local, mas pode ler
arquivos de redo log arquivados em diretrios remotos nos outros ns.
Se voc usa o arquivamento local do sistema de arquivos no-clusterizados para
recuperao de mdia, ento deve configurar o n que estiver executando a recuperao
para o acesso remoto aos outros ns, de forma que possa ler os arquivos de redo log
arquivados nos diretrios de arquivamento nos outros ns. Alm disso, se voc estiver
executando a recuperao e no tiver todos os logs de arquivamento disponveis, ento ter
que executar uma recuperao incompleta at o primeiro nmero ausente da sequncia de
redo log arquivado. Voc no tem que usar uma configurao especfica para este esquema.
Entretanto, para distribuir o processamento de backup em vrios ns, o mtodo mais fcil
configurar canais.
Observao: Como diferentes sistemas de arquivos so usados em um caso no-
clusterizado, os diretrios de log de arquivamento devem ser exclusivos em cada n. Por
exemplo, /arc_dest_1 somente est disponvel no n1, /arc_dest_2 apenas
diretamente montado no n2 e assim por diante. Ento, o n1 monta /arc_dest_2 a partir
do n2 e /arc_dest_3 a partir do n3 por meio do NFS.
Configurando Arquivamento
Local No-clusterizado
Defina o parmetro SID.LOG_ARCH_DEST para cada
instncia usando o designador SID:
sid1.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_1"
Em bancos de dados gerenciados por polticas, crie uma

vinculao de n e instncia para garantir que sid1 sempre
seja executado no mesmo n:
$ srvctl modify database -d mydb -n node1 -i sid1
Voc pode definir os valores de destino do arquivamento como se segue no arquivo do

parmetro de inicializao em bancos de dados gerenciados por polticas ou administrador.
Defina o parmetro SID.LOG_ARCH_DEST para cada instncia que utiliza o designador SID,
conforme mostrado no seguinte exemplo:
Em bancos de dados gerenciados por polticas, crie manualmente uma vinculao de n e
instncia para garantir que sid1 sempre seja executado no mesmo n, como se segue:
A lista a seguir mostra as possveis entradas de redo log arquivados no arquivo de controle
do banco de dados. Observe que qualquer n pode ler redo logs arquivados a partir de
qualquer um dos threads, o que deve acontecer a fim de que o banco de dados se recupere
aps uma falha.
/arc_dest_1/log_1_1000_23435343.arc
/arc_dest_2/log_1_1001_23452345.arc <- thread 1 archived in node2
/arc_dest_2/log_2_754_23452345.arc
/arc_dest_3/log_3_1564_23452345.arc
Esquema de Arquivamento do Sistema de

Arquivos Clusterizados e do ASM
A configurao preferencial para o RAC usar o grupo de
discos do ASM para uma rea de recuperao para o
conjunto de recuperao que for diferente do grupo de
discos usados para os arquivos de dados.
Quando voc usa o ASM, ele usa um formato de nomeao
do OMF.
De outra forma, pode ser usado um esquema de
arquivamento do sistema de arquivos clusterizados.
Cada n grava em um nico local no sistema de arquivos
clusterizados ao arquivar os arquivos de redo log.
Cada n pode ler os arquivos de redo log arquivados dos
outros ns.
A vantagem deste esquema que nenhum dos ns usa a
rede para arquivar os logs.
A configurao preferencial para o Oracle RAC usar o ASM para uma rea de recuperao,
usando um disco de grupos para o conjunto de recuperao que for diferente do grupo de
discos usados para os arquivos de dados. Quando voc usa o Oracle ASM, ele usa um
formato de nomeao do Oracle Managed Files.
De outra forma, voc pode usar um esquema de arquivamento do sistema de arquivos
clusterizados. Se voc usar um sistema de arquivos clusterizados, ento cada n grava em
um nico local no sistema de arquivos clusterizados ao arquivar os arquivos de redo log.
Cada n pode ler os arquivos de redo log arquivados dos outros ns. Por exemplo, se o N 1
arquivar um arquivo de redo log em /arc_dest/log_1_100_23452345.arc no sistema de
arquivos clusterizados, ento qualquer outro n no cluster tambm pode ler este arquivo.
Se voc no usar um sistema de arquivos clusterizados, ento os arquivos de redo log
arquivados no podem ficar em dispositivos brutos. Isto ocorre pois os dispositivos brutos
no permitem a gravao sequencial de arquivos de log de arquivamento consecutivos. A
vantagem deste esquema que nenhum dos ns usa a rede para arquivar os logs. Como o
nome do arquivo gravado por um n pode ser lido por qualquer n no cluster, o RMAN pode
efetuar o backup de todos os logs a partir de qualquer n no cluster. Os scripts de backup e
restaurao so simplificados pois cada n tem acesso a todos os logs de redo arquivados.

Configurando o Esquema de Arquivamento do CFS
No esquema do CFS, cada n arquiva em um diretrio com o

mesmo nome em todas as instncias no banco de dados.
Para configurar este diretrio, defina os valores para o
parmetro LOG_ARCH_DEST_1:
*.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
A lista abaixo mostra os exemplos de entrada de redo logs
arquivados que seriam exibidos no catlogo do RMAN ou no
arquivo de controle:
/arc_dest/log_1_999_23452345.arc
/arc_dest/log_1_1000_23435343.arc
/arc_dest/log_1_1001_23452345.arc <- thread 1 archived in node3
Cada n pode ler os logs gravados por ele mesmo e por
qualquer outro n.
No esquema do sistema de arquivos clusterizados, cada n arquiva em um diretrio

identificado com o mesmo nome em todas as instncias dentro do banco de dados
clusterizado (/arc_dest, no exemplo a seguir). Para configurar este diretrio, defina os
valores para o parmetro LOG_ARCH_DEST_1, conforme mostrado no seguinte exemplo:
*.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
A lista abaixo mostra os exemplos de entrada de redo logs arquivados que seriam exibidos
no catlogo do RMAN ou no arquivo de controle baseado no exemplo anterior. Observe que
qualquer n pode arquivar logs usando qualquer um dos threads:
/arc_dest/log_1_1000_23435343.arc
/arc_dest/log_3_1564_23452345.arc
Como o sistema de arquivos compartilhado e como cada n est gravando seus logs de
redo arquivados no diretrio /arc_dest no sistema de arquivos clusterizados, cada n pode
ler os logs gravados por ele mesmo e por qualquer outro n.

Restaurando e Recuperando
A recuperao de mdia pode requerer um ou mais

arquivos de log armazenados para cada thread.
O comando RMAN RECOVER restaura e aplica
automaticamente os logs arquivados necessrios.
possvel restaurar logs de arquivamento para qualquer
n que esteja executando a operao de restaurao e
recuperao.
Dever ser possvel ler os logs a partir do n que executa
a atividade de restaurao e recuperao.
Os processos de recuperao solicitam threads adicionais
ativados durante o perodo de recuperao.
Os processos de recuperao emitem notificaes sobre
os threads que no so mais necessrios porque foram
desativados.
A recuperao de mdia de um banco de dados que acessado pelo ambiente RAC pode
requerer pelo menos um arquivo de log armazenado para cada thread. No entanto, se o redo
log on-line de um thread contiver informaes de recuperao suficientes, no ser
necessrio restaurar os arquivos de log arquivados para os threads.
Com o uso do RMAN para a recuperao de mdia e o compartilhamento de diretrios de log
de arquivamento, voc pode alterar o destino da restaurao automtica dos logs de
arquivamento com a clusula SET a fim de restaurar os arquivos em um diretrio local do n
no qual a recuperao teve incio. Se voc tiver feito backup dos logs de arquivamento de
cada n sem usar um sistema central de gerenciamento de mdia, restaure primeiro todos os
arquivos de log dos ns remotos e mova-os para o host a partir do qual iniciar a
recuperao com o RMAN. No entanto, se tiver feito backup dos arquivos de log de cada n
usando um sistema central de gerenciamento de mdia, voc poder usar o recurso
AUTOLOCATE do RMAN. Ele permite recuperar um banco de dados usando o drive de fita
local do n remoto.
Se a recuperao chegar a um momento em que um thread adicional foi ativado, o processo
de recuperao solicitar o arquivo de log armazenado para esse thread. Se voc estiver
usando um arquivo de controle de backup, quando todos os arquivos de log arquivados
estiverem esgotados, talvez seja necessrio redirecionar o processo de recuperao para os
arquivos de redo log on-line a fim de concluir a recuperao. Se a recuperao chegar a um
momento em que um thread foi desativado, o processo informar que o arquivo de log
referente a esse thread no mais necessrio.
Questionrio
Qual das seguintes afirmaes sobre recuperao de mdia no

RAC no verdadeira?
a. A recuperao de mdia deve ser iniciada pelo usurio por
meio de um aplicativo cliente.
b. Os procedures de recuperao de mdia com o RMAN
para RAC so muito diferentes dos procedures para
ambientes de instncia nica.
c. O n que executa a recuperao deve ser capaz de
restaurar todos os arquivos de dados necessrios.
d. O n de recuperao tambm dever ser capaz de ler
todos os redo logs arquivados necessrios no disco ou
restaur-los de backups.
Resposta: b

Questionrio
Para usar a rea de recuperao rpida no ambiente RAC,

coloque-a em um grupo de discos ASM, em um sistema de
arquivos clusterizados ou em um diretrio compartilhado que
seja configurado atravs do NFS certificado para cada
instncia RAC.
a. Verdadeiro
b. Falso
Resposta: a

Sumrio
Nesta lio, voc aprendeu a configurar:

O banco de dados RAC para usar o modo
ARCHIVELOG e a rea de recuperao rpida
O RMAN para o ambiente RAC


Configurando o modo de log de arquivamento
Configurando strings de conexo especficas instncia
Configurando o RMAN e executando backups paralelos

de Recursos Globais
Conceitos do Gerenciamento
Objetivos
Ao concluir esta lio, voc ser capaz de descrever:

A necessidade de controle da concorrncia global
O Global Resource Directory
Como os recursos globais so gerenciados
A coordenao do acesso aos recursos globais do RAC
O enfileiramento global e o gerenciamento de
bloqueios de instncia
O gerenciamento do cache de buffer global

Necessidade de Controle da Concorrncia Global
A Oracle requer controle da concorrncia porque se trata de um

sistema de vrios usurios.
O Oracle de uma nica instncia permite o controle da
concorrncia:
Latches ou mutexes para estruturas de memria
Enfileiramentos para controle de recursos
Pins de cache de buffer para o gerenciamento de cache
No RAC, possvel acessar ou modificar estruturas e recursos
por meio de uma sesso em execuo em qualquer instncia do
banco de dados.
Dessa forma, o RAC requer controles da concorrncia adicionais
para mediar o acesso entre instncias.
Os bloqueios globais controlam o acesso ao cache de linha e de
biblioteca.
Os enfileiramentos globais controlam o acesso aos recursos.
O cache fusion controla o acesso ao cache de buffer.
Os latches e os mutexes s podero proteger o acesso s estruturas da memria se forem

acessados por processos da mesma instncia.
No RAC, latches e mutexes ainda so usados, mas para o controle da concorrncia, so
utilizados alguns enfileiramentos globais adicionais que oferecem proteo entre as
instncias.

Global Resource Directory (GRD)
Um objeto sob controle da concorrncia global

denominado um recurso.
Os metadados de recursos so mantidos no Global
Resource Directory (GRD).
Recursos de enfileiramento global so usados para
enfileiramentos e bloqueios.
Recursos de cache global so usados para o controle do
cache de buffer.
O GRD distribudo entre todas as instncias ativas de
cada banco de dados ou ambiente ASM.
Cada GRD atualmente gerenciado tem:
Uma estrutura de metadados-mestre
Uma ou mais estruturas de metadados sombra
O GRD usa memria do shared pool.
Uma estrutura de metadados-mestre contm informaes sobre o estado do recurso

relacionado para cada instncia na qual reside o recurso em questo. Uma estrutura de
metadados sombra contm apenas informaes sobre o estado do recurso relacionado na
instncia que contm os metadados sombra.

Gerenciamento de Recursos Globais
Aps o primeiro acesso de uma entidade globalmente

gerenciada por qualquer instncia, um recurso global
alocado.
Um algoritmo interno usado para decidir qual instncia
dever conter a estrutura de metadados-mestre para a
entidade em questo.
Essa instncia conhecida como o mestre de recursos.
A instncia-mestre de recursos pode ser qualquer instncia
ativa do banco de dados ou do ambiente ASM.
O acesso subsequente a qualquer entidade de outra
instncia para a qual haja metadados-mestre de recursos
faz com que os metadados de recurso sombra sejam
alocados na instncia solicitante. Alm disso, causa
atualizaes nos metadados-mestre.
A instncia-mestre de recursos a instncia que contm os metadados-mestre usados para

gerenciar o controle da concorrncia de uma entidade especfica.
Cada instncia ser o mestre de recursos para algumas entidades do banco de dados.
A instncia de recurso sombra qualquer instncia que contm metadados sombra usados
para gerenciar o controle da concorrncia de uma entidade especfica. Cada instncia
conter recursos sombra para entidades acessadas por ela e para as quais ela no seja o
mestre de recursos.

Remastering de Recursos Globais
Remastering o processo de alocao de controle dos

metadados-mestre de uma entidade especfica para outra
instncia.
O remastering lento ou no nvel da instncia ocorre quando:
Uma nova instncia do mesmo banco de dados ou do ASM
iniciada
Uma instncia atual desativada normalmente
O remastering de afinidade de arquivos ocorre quando:
H, com frequncia, solicitaes para acessar blocos em um
arquivo de dados a partir de uma instncia, e, em geral, os mestres
de recursos dos blocos so mantidos por outras instncias
O remastering de afinidade de objetos ocorre quando:
H, com frequncia, solicitaes para acessar blocos em um objeto
de dados a partir de uma instncia, e, em geral, os mestres de
recursos dos blocos so mantidos por outras instncias
Quando uma nova instncia iniciada, o remastering no efetuado imediatamente. Em vez

disso, ele realizado gradualmente, com base nas instncias que esto acessando
determinados recursos (por isso, o termo "lento").
Quando uma instncia desativada normalmente, o que significa uma desativao normal,
imediata ou transacional, os recursos controlados pela instncia encerrada so entregues s
instncias sobreviventes, por meio de um algoritmo interno otimizado, que foi projetado para
minimizar o remastering e os overheads de controle da concorrncia subsequentes.
A deciso de realizar o remastering de afinidade de arquivos ou de objetos tomada
automaticamente quando um limite interno atingido.

Global Resource Directory
Quando ocorrem falhas em uma ou mais instncias, mas no

em todas:
Os mestres de recursos da(s) instncia(s) com falha so
perdidos
Todos os mestres de recursos que tinham uma sombra em
uma instncia sobrevivente devem ser recuperados
As instncias sobreviventes podem recriar os metadados-
mestre de um recurso especfico, por meio da agregao de
detalhes dos metadados sombra sobreviventes do mesmo
recurso.
Os bloqueios globais e os metadados de enfileiramento so
efetuados primeiro e, em seguida, os metadados do cache
global.
A recriao faz com que cada instncia sobrevivente controle
alguns dos metadados-mestre dos recursos recuperados.
Os enfileiramentos so efetuados primeiro porque a Oracle precisa saber quem tem acesso a
qual recurso para que a recuperao continue. O log de alerta do banco de dados RAC
mostra a atividade dos recursos globais durante a recuperao da instncia:
...
Reconfiguration started (old inc 0, new inc 6)
List of instances:
1 2 3 (myinst: 3)
Global Resource Directory frozen
* allocate domain 0, invalid = TRUE
Communication channels reestablished
* domain 0 valid = 0 according to instance 1
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
Set master node info
Submitted all remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
Submitted all GCS remote-cache requests
Fix write in gcs resources
Reconfiguration complete (total time 0.5 secs)
...

Processos de Background dos Recursos Globais
ACMS: arquivo de Controle Atmico para o Servio de

Memria
LMHB: monitora os processos LMON, LMD e LMSn
LMD0: solicita enfileiramentos globais e bloqueios de
instncia
LMON: emite heartbeats e efetua a recuperao
LMSn: processa solicitaes do global cache fusion
LCK0: est envolvido no bloqueio do cache de linha e de
biblioteca
RCBG: processa invalidaes do Global Result Cache
Observao: h outros processos de background do RAC, mas esta lio se concentra

apenas no Controle da Concorrncia Global.
Arquivo de Controle Atmico para o Servio de Memria (ACMS): no ambiente RAC,
o processo por instncia do ACMS um agente que contribui para garantir que uma
atualizao da memria SGA distribuda seja globalmente confirmada em caso de xito
ou cancelada globalmente em caso de falha.
Global Enqueue Service Monitor (LMON): o processo LMON monitora os
enfileiramentos e recursos globais no cluster e executa operaes de recuperao de
enfileiramentos globais.
Global Enqueue Service Daemon (LMD): o processo LMD gerencia solicitaes de
recursos remotos de chegada em cada instncia.
Global Cache Service Process (LMS): o processo LMS mantm registros dos status
dos arquivos de dados e de cada bloco em cache registrando informaes no GRD. O
processo LMS tambm controla o fluxo de mensagens para instncias remotas,
gerencia o acesso a blocos de dados globais e transmite imagens de blocos entre os
caches de buffer de instncias diferentes. Esse processamento faz parte do recurso
cache fusion.

Instance Enqueue Process (LCK0): o processo LCK0 gerencia solicitaes do
recurso noncache fusion como solicitaes de cache de linha e de biblioteca.
Global Cache/Enqueue Service Heartbeat Monitor (LMHB): o LMHB monitora os
processos LMON, LMD e LMSn para garantir que eles sejam executados normalmente,
sem bloqueios nem esperas.
Result Cache Background Process (RCBG): este processo usado para tratar
mensagens de invalidao e outras mensagens geradas pelos processos do servidor
ligados a outras instncias do Oracle RAC.

Coordenao do Acesso aos Recursos Globais
H dois tipos de coordenao de recursos globais.

Gerenciamento de enfileiramentos globais, que usado
para:
Enfileiramentos globais
Bloqueios de instncias globais
Cache do buffer global, que:
Tambm conhecido como cache fusion ou cache global
um cache de buffer lgico que abrange todas as instncias
Coordena o acesso a imagens de blocos no cache global
Suporta o recurso Parallel Query no cache global
Os enfileiramentos globais so usados para controlar o acesso aos recursos, nos quais o(s)
proprietrio(s) ou, se houver, o(s) waiter(s) ou o(s) conversor(es), ou ambos, podem ser
sesses da mesma instncia ou de instncias diferentes. Alguns enfileiramentos globais
servem ao mesmo propsito que serviriam em uma instncia nica. Por exemplo,
enfileiramentos de manipulao de tabelas (TM), enfileiramentos de transaes (TX),
enfileiramentos de arquivos de controle (CF), enfileiramentos de marca d'gua alta (HW),
reabastecimento de cache de sequncia (SQ) e enfileiramentos de threads de redo (RT)
servem todos ao mesmo propsito que serviriam em uma instncia nica. No entanto,
conforme descrito anteriormente nesta lio, h estruturas de metadados-mestre e sombra
no GRD, e a instncia-mestre monitorar os waiters e os conversores.
Bloqueios de instncia so enfileiramentos que representam recursos do cache de linha ou
de biblioteca, que so protegidos em cada instncia por pins, mutexes ou latches. Para o
controle da concorrncia entre instncias, usado um enfileiramento, cujo(s) proprietrio(s)
(so) a(s) instncia(s) que (so) a "origem da verdade" em relao ao estado atual do
recurso em questo. O processo LCK0 atua como o proprietrio, o waiter ou o conversor do
enfileiramento como um processo "proxy" que representa a instncia. Esses enfileiramentos
so conhecidos como bloqueios de instncia.

Enfileiramentos Globais
O processamento iniciado na instncia solicitante da seguinte maneira:

1. Uma solicitao de enfileiramento global efetuada por uma sesso.
2. A solicitao transmitida ao LMD0 na instncia solicitante.
3. O foreground aguarda a solicitao no evento.
4. O LMD0 determina a instncia-mestre.
5. Se necessrio, o LMD0 encaminha a solicitao para a instncia-
mestre.
6. Se necessrio, a instncia-mestre adiciona um novo recurso-mestre.
O processo transformado em proprietrio, waiter ou conversor,
conforme apropriado.
Assim que for possvel conceder o recurso ao solicitante, o LMD0
na instncia-mestre notificar o LMD0 na instncia solicitante.
7. Quando o recurso est disponvel, o foreground publicado pelo
LMD0 na instncia solicitante.
Se as instncias solicitantes e mestre forem as mesmas, o LMD0 no precisar encaminhar a

solicitao pela interconexo. O LMD0 na instncia-mestre notifica imediatamente o LMD0 na
instncia solicitante sobre o status do recurso, ou seja, se ele est ou no disponvel.
Se uma solicitao de desenfileiramento for transmitida instncia-mestre, o LMD0 notificar
os processos LMD0 sobre todos os waiters ou conversores que precisarem ser retomados, e
eles sero publicados pelo LMD0 em suas prprias instncias.

Bloqueios de Instncia
Os bloqueios de instncia so usados para representar a(s)

instncia(s) que tem(tm) controle sobre uma estrutura no
mbito da instncia:
Entradas do cache de linha
Entradas do cache de biblioteca
Entradas do cache de resultados
O proprietrio, o waiter ou o conversor em um bloqueio de
instncia o processo LCK0.
Desde que o bloqueio em um recurso especfico pertena ao
processo LCK0 local de uma instncia, qualquer sesso dessa
instncia poder usar os metadados em cache, pois eles so
considerados atuais.
Se o bloqueio no pertencer instncia local, ser necessrio
efetuar uma solicitao para o bloqueio, e o foreground
aguardar o evento de espera DFS Lock Handle.
Os bloqueios de instncia usam estruturas de enfileiramento, mas o escopo diferente. O

LCK0 atua como o proprietrio ou o waiter nessas situaes. O proprietrio de um bloqueio
de instncia representa a instncia que tem permisso para acessar a entidade relacionada
no cache de linha ou de biblioteca. Supondo-se que o bloqueio pertena a uma instncia, os
latches, os pins ou os mutexes habituais proporcionam normalmente o controle da
concorrncia na instncia.

Gerenciamento do Cache Global: Viso Geral
O gerenciamento do cache global oferece:

Um mecanismo de concorrncia para vrios caches de
buffer
Uma otimizao do acesso ao bloco para leituras
Uma otimizao de gravaes para buffers sujos
Um mecanismo para otimizar consultas paralelas
O controle da concorrncia trata situaes nas quais o mesmo bloco tem vrias imagens no
mesmo cache de buffer ou em caches de buffer diferentes.
A reduo das entradas/sadas fsicas obtida por meio de uma viso global dos recursos do
cache de buffer e pelo atendimento potencial das solicitaes de entradas/sadas de
qualquer cache de instncias, em vez de efetuar a leitura do disco ou vrias gravaes do
mesmo buffer no disco de diferentes caches de buffer
As consultas paralelas podem resultar no armazenamento de partes de uma tabela em cada
cache de buffer e no uso do cache fusion para evitar leituras diretas repetidas do mesmo
disco. Isso conhecido como "Consulta Paralela na Memria". Partes da tabela so
armazenadas em caches de buffer separados em vez de os blocos serem armazenados
vrias vezes em caches diferentes devido transferncia de blocos do cache fusion. Os
servidores de execuo paralela nas diferentes instncias apresentam resultados pela
interconexo para a parte da tabela em seus respectivos caches de instncia.

Componentes do Gerenciamento do Cache Global
Os processos LMSn
Buffers
Cabealhos de buffer
Recursos-Mestre do Cache Global
Recursos Sombra do Cache Global
Vrios processos LMS podem ser usados pelo Oracle RAC, dependendo do tamanho da
carga de trabalho. H cabealhos para cada buffer em cada cache de buffer. Pode haver
vrias imagens do mesmo bloco do banco de dados no mesmo cache de buffer ou em
caches de buffer diferentes.
A instncia-mestre de um bloco do banco de dados especfico ter metadados-mestre no
GRD, mantidos pelo LMSn, que descrevem todas as imagens de blocos e especificam a
instncia e o estado de cada imagem. Os metadados sombra no GRD so mantidos pelo
LMSn na mesma instncia, contendo as informaes de cada bloco no cache de buffer no
controlado localmente.

Estados do Buffer de Cache Global
Os estados de buffer so visveis em V$BH.STATUS.

Os estados de buffer importantes so:
Atual Compartilhado: SCUR
Atual Exclusivo: XCUR
Leitura Consistente: CR
Incorporado na Instncia
Enviado pelo cache fusion
Convertido de SCUR ou de PI
Imagem Antiga: PI
Convertido de XCUR
No gravado normalmente
Convertido em CR depois que a imagem de XCUR gravada
Podem existir vrias imagens de PI para o mesmo bloco em
caches de buffer diferentes.
Os estados de buffer importantes para o cache fusion em V$BH.STATUS so:

Atual Compartilhado: o buffer contm uma imagem do bloco que corresponde contida no
disco. Uma ou mais instncias podem ter imagens para o mesmo bloco no estado SCUR.
Quando h uma imagem nesse estado em uma instncia, caso outra instncia leia o mesmo
bloco para fins de leitura, o cache fusion utilizado.
Atual Exclusivo: o buffer contm uma imagem do bloco que est prestes a ser atualizada ou
j foi atualizada. Ela pode ou no ter sido gravada pelo database writer. Somente uma
instncia pode ter uma imagem XCUR correspondente a um bloco
Leitura Consistente: o buffer contm uma imagem do bloco que consistente com um
determinado momento anterior. Essa imagem pode ter sido criada da mesma forma que em
bancos de dados de uma nica instncia, mas copiando um bloco em um buffer disponvel e
usando undo para fazer rollback das alteraes a fim de criar a imagem mais antiga. Ela
tambm pode ter sido criada convertendo uma imagem do bloco de SCUR ou de PI.
Imagem Antiga: o buffer contm uma imagem do bloco XCUR mas que, em seguida, foi
enviada para outra instncia usando cache fusion. Agora, existe uma imagem posterior desse
bloco em outro cache de buffer. Assim que o DBWn grava a imagem posterior em um disco da
outra instncia, a imagem PI transforma-se em CR.

Cenrios de Gerenciamento do Cache Global

para Leituras de Bloco nico
H vrios cenrios para leituras de bloco nico:
Leitura do Disco
Leitura Leitura
Leitura Gravao
Gravao Gravao
Gravao Leitura
Gravao no Disco
Leitura do Disco: ocorre quando surge uma solicitao de entradas/sadas para um bloco
que no tem imagens em nenhum cache de buffer
Leitura Leitura: ocorre quando h uma imagem do bloco em, pelo menos, um cache de
buffer em estado atual compartilhado (SCUR), e outra instncia deseja acessar o bloco para
leitura
Leitura Gravao: ocorre quando h uma imagem do bloco em, pelo menos, um cache de
buffer em estado atual compartilhado (SCUR), e outra instncia deseja acessar o bloco para
atualizao (XCUR)
Gravao Gravao: ocorre quando h uma imagem do bloco em um cache de buffer em
estado atual exclusivo (XCUR), e outra instncia deseja acessar o mesmo bloco para
gravao no estado atual exclusivo (XCUR)
Gravao Leitura: ocorre quando h uma imagem do bloco em um cache de buffer em
estado atual exclusivo (XCUR), e outra instncia deseja acessar o bloco para leitura. A
instncia que efetua a leitura pode faz-la em CR ou em SCUR, conforme descrito
posteriormente.
Gravao no Disco: ocorre quando o DBWn grava um buffer sujo no disco. Se o bloco tiver
sido modificado em vrias instncias, somente a imagem mais recente ser gravada. Essa
imagem ser (XCUR). Todas as imagens sujas mais antigas do mesmo bloco sero imagens
antigas (PI).
Cenrios do Cache Global: Viso Geral
Instncia A Instncia B
Instncia C
Mestre de
recursos 1008
Instncia D
Nos slides a seguir, um banco de dados de quatro instncias usado para demonstrar vrios
cenrios que envolvem o processamento do cache fusion para um nico bloco.
A instncia-mestre desse bloco a D, e o bloco no banco de dados est em SCN 1008 no
disco, mas no h imagens em nenhum cache de buffer.
Observe que o status listado nas caixas que representam as instncias na coluna de status
so dos metadados V$BH e no do GRD, que tm seus prprios status.

Cenrio 1: Leitura do Disco
Solicitao para Instncia C
obter um recurso
compartilhado em C
Mestre de
recursos 1008
Instncia D
A instncia C deseja ler um bloco no modo compartilhado. O processo de foreground

transmite a solicitao para um processo LMS local, que a transmite pela interconexo a um
processo LMS na instncia-mestre do bloco em questo.
No momento, no h buffer que contenha uma imagem do bloco no cache de buffer na
instncia C, nem em nenhuma outra instncia.

Instncia C
1 SCUR
A solicitao
Mestre de atendida, e a instncia
recursos solicitante informada. 1008
2
Instncia D
O processo LMS da instncia-mestre atualiza os metadados-mestre na instncia D e emite

uma "concesso" ao LMS na instncia C solicitante, que cria um recurso de metadados
sombra e notifica o foreground.
A coluna de status do cabealho de buffer mostra SCUR, que significa atual compartilhado.

Instncia C
SCUR
1
Mestre de
recursos
2 Solicitao 1008
de leitura 3
Instncia D
Em seguida, o processo de foreground na instncia C obtm um buffer disponvel e emite a

solicitao de entrada/sada.

Instncia C
SCUR Imagem de
4 bloco entregue
1008
1
Mestre de 2
recursos 1008
3
Instncia D
O status dessa imagem do bloco aps a concluso da entrada/sada ser SCUR, embora,
atualmente, a instncia C seja a nica que tem uma imagem desse bloco.
Se outras instncias desejarem ler o mesmo bloco para acesso de leitura, a imagem do bloco
poder ser enviada a elas por meio do cache fusion, e duas ou mais instncias podero ter
imagens do mesmo bloco em seus caches de buffer. Se isso ocorrer, elas estaro no status
SCUR.
Observe que o SCN da imagem do bloco na instncia C corresponde ao status SCN do bloco
no disco.

Cenrio 2: Operao de Leitura-Gravao de

Cache Fusion
Instncia A Solicitao para obter Instncia B
um recurso exclusivo na
instncia B
1
Instncia C
SCUR
1008
Mestre de
recursos 1008
Instncia D
Agora, a instncia B deseja ler o mesmo bloco. O processo do servidor transmite a

solicitao para um processo LMS, que a transmite pela interconexo a um processo LMS na
instncia-mestre do bloco em questo.
No momento, no h buffer no cache de buffer na instncia B que contenha uma imagem do
bloco, e no h metadados sombra para esse bloco no GRD na instncia B.


Cache Fusion
1
Instncia C
SCUR
1008
Mestre de Instruo para transferir

recursos
2 o bloco para B para 1008
acesso exclusivo
Instncia D
A instncia-mestre tem metadados-mestre, o que indica que a instncia C tem uma imagem
SCUR do bloco que pode ser enviada instncia B solicitante.
Dessa forma, o LMS na instncia D envia uma solicitao ao LMS na instncia C, para enviar
uma imagem do bloco para a instncia B pela interconexo.
Observe que a instncia escolhida para fornecer a imagem do bloco ser determinada
internamente se duas ou mais instncias tiverem imagens SCUR do mesmo bloco.


Cache Fusion
1008
1
A instncia C envia a
Instncia C imagem do bloco
SCUR>CR instncia B
3
1008
Mestre de 2
recursos 1008
Instncia D
Agora, a instncia C envia uma imagem do bloco instncia B pela interconexo. Os

metadados sombra no GRD na instncia C so alterados para CR, para evidenciar que a
imagem do bloco no mais compartilhada.
Observe que, se duas ou mais instncias tiverem imagens SCUR do mesmo bloco, elas
recebero uma mensagem para fazer o downgrade delas para CR do LMS na instncia D-
mestre.
As duas imagens mostram um status SCN de 1008, mas isso ser alterado quando a imagem
do bloco for atualizada na instncia B.


Cache Fusion
Pr-requisitos de recursos
Instncia A 4 Instncia B
e mensagem de status
XCUR
1009
1
Instncia C
CR
3
1008
Mestre de 2
recursos 1008
Instncia D
Agora, o LMS na instncia B envia uma mensagem de status instncia D-mestre pela
interconexo. Os metadados sombra no GRD na instncia B demonstram que a imagem do
bloco de propriedade exclusiva.
A instncia-mestre pode atualizar os metadados-mestre porque haver duas imagens do
bloco em diferentes instncias e em estados distintos.
A imagem na instncia B ser exclusiva do ponto de vista do GRD, e a imagem contida na
instncia C ser nula, porque imagens CR no representam blocos que residem no disco
atualmente nem que sero gravados no disco. Elas so usadas apenas para fins de
consistncia de leitura.
Agora, o LMS na instncia B publica o processo de foreground, e o bloco atualizado. O SCN
1009 na instncia B, mas ainda 1008 na instncia C.

Cenrio 3: Operao de Gravao-Gravao de

Cache Fusion
XCUR
1009
1
Instncia C
Solicitao para CR
obter um recurso
no modo exclusivo 1008
Mestre de
recursos 1008
Instncia D
Agora, um processo de foreground na instncia A solicita que o LMS local na mesma

instncia acesse o bloco para gravao.
O LMS na instncia A envia uma solicitao ao LMS na instncia D-mestre para acessar o
bloco no modo exclusivo.


Cache Fusion
XCUR
1009
1
Instncia C
CR
1008
Mestre de 2 Solicitao para transferir

recursos um recurso exclusivo 1008
para a instncia A
Instncia D
O LMS na instncia D-mestre examina os metadados-mestre no GRD, o que indica que a

instncia B tem propriedade exclusiva do recurso para o bloco em questo.
Em seguida, o LMS na instncia D-mestre envia uma solicitao ao LMS na instncia B,
solicitando que a imagem XCUR do bloco seja enviada ao LMS na instncia A, mantendo, no
entanto, a imagem antiga (PI) do bloco.
Antes de enviar a imagem do bloco pela interconexo, a instncia B dever descarregar redo
buffers, se ainda no tiverem sido gravados, que contenham os vetores de alterao com as
descries das alteraes feitas nesse bloco. Isso no aparece no slide, que mostra apenas
o cache fusion. Para fins de recuperao, o envio da imagem para outra instncia tratado
da mesma forma que a gravao do bloco no disco, e o buffer de log dever ser gravado
para que a recuperao funcione.


Cache Fusion
Manter cpia XCUR>PI
3 exclusiva do buffer
1009 1009
1
Instncia C
CR
1008
Mestre de 2
recursos 1008
Instncia D
Em seguida, o LMS na instncia B envia a imagem do bloco ao LMS na instncia A, mas

retm a imagem PI em seu prprio cache de buffer. A imagem antiga do bloco mantida at
a ocorrncia de uma das seguintes situaes:
Uma verso XCUR posterior do bloco ser gravada pelo DBWn a partir de uma instncia,
momento em que a imagem PI se transforma em CR.
O LMS instruir o DBWn na instncia B a gravar a imagem PI, devido recuperao da
instncia. Aps o trmino da recuperao, a imagem PI transforma-se em CR.
Observe que no momento, o SCN correspondente s imagens do bloco nas instncias A e B
1009, mas isso mudar quando a transao na instncia A atualizar a imagem do bloco


Cache Fusion
XCUR PI
3
1013 1009
1 4
Instncia C
Pr-requisitos
CR
de recursos
e mensagem 1008
de status
Mestre de 2
recursos 1008
Instncia D
Agora, o LMS na instncia A envia uma mensagem de status instncia D-mestre pela
interconexo.
O LMS na instncia A atualiza os metadados sombra e publica o processo de foreground. O
status definido como XCUR no cabealho de buffer, na instncia A.
O foreground atualiza o bloco, e o SCN alterado para 1013.
Observe que esse processo poder ser repetido de forma encadeada em daisy-chain,
resultando em uma imagem XCUR em uma instncia e em duas ou mais imagens PI do
mesmo bloco em outras instncias, em momentos diferentes.

Cenrio 4: Operao de Gravao-Leitura de

Cache Fusion
XCUR PI
1013 1009
Instncia C
Solicitao para obter
um recurso no modo
compartilhado 1
Mestre de
recursos 1008
Instncia D
Agora, um processo de foreground na instncia C solicita que o LMS local na mesma

instncia acesse o bloco para leitura. O LMS na instncia C envia uma solicitao ao LMS na
instncia D-mestre para acessar o bloco no modo compartilhado.
Observe que, a essa altura, a imagem PI na instncia B pode ou no ter sido eliminada. Isso
depende do fato de o DBWn na instncia A ter ou no gravado a imagem XCUR no disco. Se a
imagem XCUR do bloco na instncia A ou uma imagem XCUR posterior do mesmo bloco em
qualquer instncia for gravada pelo DBWn, a imagem do bloco PI ser transformada em CR e
poder ser eliminada do cache devido presso na lista de reposio para buffers
disponveis. Essa transio controlada pelos processos LMSn nas instncias afetadas que
se comunicam com o processo LMSn na instncia-mestre de recursos.
Observao: para simplificar o slide, a imagem CR na instncia C foi eliminada do cache de
buffer, portanto, no est presente.


Cache Fusion
XCUR PI
1013 1009
2
Instncia C
Instruo para
transferir o recurso
compartilhado 1
para C
Mestre de
recursos 1008
Instncia D
O LMS na instncia D-mestre examina os metadados-mestre no GRD, o que indica que a

instncia A tem propriedade exclusiva do recurso para o bloco em questo.
Em seguida, o LMS na instncia D-mestre envia uma solicitao ao LMS na instncia A,
solicitando que uma imagem do bloco que atenda ao SCN da consulta na instncia C seja
enviada para esta.


Cache Fusion
XCUR Manter cpia PI
3
compartilhada do buffer
1013 1009
2
Instncia C
1
1013
Mestre de
recursos 1008
Instncia D
Normalmente, o LMS na instncia A cria uma imagem CR utilizando undo e a envia

instncia C. Em seguida, o buffer permanece XCUR no cache de buffer na instncia A,
mesmo se a imagem XCUR atender aos requisitos de consistncia de leitura. Dessa forma, se
ocorrer outra atualizao na instncia A, no ser necessrio fazer downgrade para SCUR e
obter a imagem em XCUR novamente.
No entanto, se o bloco tambm tiver imagens PI causadas por vrias atualizaes no
mesmo bloco a partir de instncias diferentes, podero ser necessrios diversos rollbacks de
undo para criar uma imagem de leitura consistente que atenda solicitao. Nesse caso,
possvel que a instncia-mestre solicite que outra instncia crie a imagem CR.
Observe que neste slide, o SCN correspondente ao bloco de imagens nas instncias A e C
igualmente de 1013 porque, neste exemplo, a imagem XCUR no exigiu o rollback para uma
verso anterior do bloco.
Observe tambm que a imagem CR antiga desse bloco ainda poder estar no cache de buffer
da instncia C, se ainda no tiver sido eliminada devido presso na lista de reposio.


Cache Fusion
XCUR ou SCUR PI
3
1013 1009
2
Instncia C
CR ou SCUR
1 1013
Informao de
Mestre de pr-requisitos
recursos 4 de recursos 1008
Instncia D
Agora, o LMS na instncia C envia uma mensagem de status instncia D-mestre pela
interconexo, o que atualiza os metadados-mestre.
O LMS na instncia C atualiza os metadados sombra e publica o processo de foreground.
Se no ocorrer nenhum downgrade, o status ser definido como CR no cabealho de buffer
da instncia C e permanecer XCUR na instncia A.
Observe que as imagens CR podero ser eliminadas dos caches de buffer, e se o bloco
permanecer XCUR na instncia A, podero ocorrer solicitaes repetidas de cache fusion,
resultando em criao e envio repetidos de imagens CR a outras instncias para o mesmo
bloco. Quando essas solicitaes ocorrem em nmero suficiente, o LMS na instncia D-
mestre solicita que a instncia A faa downgrade da propriedade do bloco para SCUR e envie
a imagem (s) outra(s) instncia(s). O bloco tambm ser SCUR nas outras instncias.

Cenrios de Gerenciamento do Cache Global

para Leituras de Vrios Blocos
Quando ocorrem solicitaes de leitura de vrios blocos:
A instncia que efetua as entradas/sadas dever adquirir
recursos para cada bloco no estado correto
Isso feito pela coordenao de LMSn da instncia solicitante
com o LMSn na(s) instncia(s)-mestre
Diferentes blocos na mesma leitura de vrios blocos podero
ter instncias-mestre distintas
O remastering dinmico, descrito anteriormente, poder ajudar
a reduzir o overhead no desempenho
H alguns cenrios para leituras de vrios blocos:
No existem mestres de recursos para nenhum bloco.
Os mestres de recursos para algum(alguns) bloco(s) so
todos SCUR.
Os mestres de recursos para algum(alguns) bloco(s) so XCUR.
Nenhum mestre de recursos para nenhum bloco em uma solicitao especfica de leitura de
vrios blocos: nesse caso, feita uma solicitao instncia-mestre especfica para cada
bloco da leitura de vrios blocos e, aps a concesso da permisso pelo LMSn, o processo
do servidor efetua a leitura de vrios blocos a partir do disco.
Existem mestres de recursos para, ao menos, um bloco em uma solicitao especfica de
leitura de vrios blocos, mas ele ou eles esto no estado Atual Compartilhado (SCUR): isso
significa que o bloco no foi modificado. Nesse caso, feita uma solicitao instncia-
mestre especfica para cada bloco da leitura de vrios blocos e, aps a concesso, o
processamento efetua a leitura a partir do disco.
H mestres de recursos para, ao menos, um bloco em uma solicitao especfica de leitura
de vrios blocos, mas pelo menos um est no estado Atual Exclusivo (XCUR) e, portanto,
poder existir em um cache de buffer em uma verso mais recente do que a verso contida
no disco. Nesse caso, feita uma solicitao instncia-mestre especfica para cada bloco
da leitura de vrios blocos e, aps a concesso, as imagens XCUR so transferidas pelo
cache fusion, conforme descrito anteriormente, e as imagens restantes so lidas do disco em
leituras de vrios blocos menores.

Views teis do Gerenciamento de Recursos

Globais
GV$SESSION_WAIT
GV$SYSSTAT

GV$GES_STATISTICS
V$RESOURCE_LIMIT
V$BH
V$CR_BLOCK_SERVER
V$CURRENT_BLOCK_SERVER
V$INSTANCE_CACHE_TRANSFER
V$DYNAMIC_REMASTER_STATS
V$GCSPFMASTER_INFO

Questionrio
Qual afirmao sobre o Global Resource Directory no

verdadeira?
a. Os metadados de recursos so mantidos no Global
Resource Directory (GRD).
b. Um objeto sob controle da concorrncia global
denominado um ativo.
c. Recursos de enfileiramento global so usados para
enfileiramentos e bloqueios.
d. Recursos de cache global so usados para o controle do
cache de buffer.
e. O GRD distribudo entre todas as instncias ativas de
cada banco de dados ou ambiente ASM.
Resposta: b
A afirmao b est incorreta.

Sumrio
Nesta lio, voc aprendeu a descrever:

A necessidade de controle da concorrncia global
O Global Resource Directory
Como os recursos globais so gerenciados
A coordenao do acesso aos recursos globais do RAC
O enfileiramento global e o gerenciamento de bloqueios de
instncia
O gerenciamento do cache de buffer global

Monitoramento e Ajuste do Banco de Dados RAC
Objetivos

Determinar os componentes de ajuste especficos de
sistemas RAC
Determinar as estatsticas do sistema, os enfileiramentos
globais e os eventos de espera especficos de sistemas RAC
Implementar as dicas de ajuste mais comuns em sistemas
RAC
Usar as pginas de desempenho de banco de dados de
cluster
Usar o AWR (Automatic Workload Repository) no Ambiente
RAC
Usar o ADDM (Automatic Database Diagnostic Monitor) no
Ambiente RAC

Dimenses de Ajuste de
Tempo de CPU e de Espera
Tempo
de CPU
Possivelmente Aplicao
precisa de ajuste escalvel
de SQL
Precisa de
Aplicao Nenhum ganho
ajuste de
obtido com a
escalvel instncia/ adio de CPUs/ns
RAC
Tempo de
espera
Ao ajustar o sistema, importante comparar o tempo de CPU com o tempo de espera do

sistema. Essa comparao ajuda a determinar o tempo de resposta necessrio em tarefas
teis e na espera por recursos possivelmente mantidos por outros processos.
Como regra geral, os sistemas nos quais predomina o tempo de CPU precisam de menos
ajuste do que aqueles em que predomina o tempo de espera. Opcionalmente, instrues
SQL escritas incorretamente podem causar o uso excessivo de CPU.
Embora a proporo entre o tempo de CPU e o tempo de espera sempre tenda a diminuir
com o aumento da carga do sistema, aumentos acentuados no tempo de espera sinalizam
disputa e precisam ser resolvidos para proporcionar uma boa escalabilidade.
A adio de mais CPUs a um n ou de mais ns a um cluster oferece vantagens muito
limitadas em caso de disputa. Por outro lado, um sistema em que a proporo do tempo de
CPU e tempo de espera no diminui significativamente com o aumento da carga pode ter
melhor escalabilidade e oferecer possveis vantagens com a adio de CPUs ou de
instncias RAC (Real Application Clusters) se necessrio.

Ajuste Especfico para RAC
Primeiro, deve ser feito o ajuste de uma nica instncia.

Ajuste para RAC:
Recuperao da instncia
Trfego de interconexo
Problemas de serializao podem ser agravados.
Ferramentas de ajuste reativo para RAC:
Eventos especficos de espera Algumas combinaes so
caractersticas de situaes
Estatsticas do sistema e de enfileiramento de ajuste j conhecidas.
Pginas de desempenho do Enterprise Manager
Relatrios do Statspack e do AWR
Ferramentas de ajuste pr-ativo para RAC:
Snapshots do AWR
Relatrios do ADDM
Embora existam reas de ajuste especficas para RAC, como a recuperao de instncia e o
trfego de interconexo, voc obtm mais vantagens ajustando o sistema como se ele
tivesse uma nica instncia. Pelo menos, esse deve ser o ponto de partida.
bvio que, se voc tiver problemas de serializao em um ambiente com uma nica
instncia, esses problemas sero agravados com um ambiente RAC.
Como mostrado no slide, voc tem basicamente as mesmas ferramentas de ajuste para RAC
e em um sistema com uma nica instncia. No entanto, algumas combinaes de estatsticas
e eventos de espera especficos so situaes de ajuste j conhecidas em ambientes RAC.
Nesta lio, voc ver algumas dessas combinaes e as informaes especficas para RAC
que podem ser obtidas nas pginas de desempenho do Enterprise Manager e nos relatrios
do Statspack e do AWR. Por fim, voc ter acesso a informaes especficas para RAC
obtidas no ADDM (Automatic Database Diagnostic Monitor).

Analisando o Impacto do Cache Fusion em

Sistemas RAC
O custo do acesso a blocos e da coerncia de cache
representado por:
Estatsticas dos Servios de Cache Global
Eventos de espera dos Servios de Cache Global
O tempo de resposta para as transferncias de cache
fusion determinado por:
Overhead de componentes de interconexo fsica
Protocolo IPC
Protocolo GCS
Em geral, fatores de entrada/sada de disco no afetam o
tempo de resposta.
O efeito do acesso a blocos no cache global e da manuteno da coerncia do cache

representado por:
Estatsticas dos Servios de Cache Global para os blocos atuais e crpor exemplo, gc
current blocks received, gc cr blocks received e assim por diante.
Eventos de espera dos Servios de Cache Global para gc current block 3-way, gc cr
grant 2-way, etc.
O tempo de resposta para as transferncias de cache fusion determinado pelo tempo de
envio de mensagens e pelo tempo de processamento impostos pelos componentes de
interconexo fsica, bem como pelos protocolos IPC e GCS. Esse tempo no afetado por
fatores de entrada/sada alm de gravaes ocasionais em logs. O protocolo de cache fusion
no requer operaes de entrada/sada em arquivos de dados para garantir a coerncia do
cache. Inerentemente, o sistema RAC no causa mais trfego de entrada/sada em disco que
uma instncia no clusterizada.

Latncias Tpicas de Operaes em Sistemas RAC
Relatrio do AWR: Nome da Latncia Limite Tpico Limite

Inferior Superior
Tempo mdio de processamento das solicitaes 0.1 1 10
de blocos cr
Avg global cache cr block receive time (ms) 0.3 4 12
Tempo mdio de processamento das solicitaes 0.1 3 23
de blocos atuais
Avg global cache current block receive time(ms) 0.3 8 30
Em um relatrio do AWR para RAC, h uma tabela na seo RAC Statistics com os tempos
mdios (latncias) de algumas operaes dos Servios de Cache Global e dos Servios de
Enfileiramento Global. Essa tabela, mostrada no slide, chamada de "Global Cache and
Enqueue Services: Workload Characteristics". necessrio monitorar essas latncias com o
decorrer do tempo e investigar os aumentos significativos de valores. A tabela apresenta
alguns valores tpicos baseados em observaes empricas. Os fatores que podem causar
variaes dessas latncias incluem:
Utilizao do protocolo IPC. Os protocolos IPC no modo de usurio so mais rpidos,
mas somente o RDG do Tru64 recomendvel para uso.
Atrasos, quando o sistema submetido a alta utilizao de CPU
Descarga de logs para os blocos que esto sendo atendidos
Outras latncias do sistema RAC em relatrios do AWR so derivadas principalmente da
view V$GES_STATISTICS, podem ser teis para depurao e no requerem monitoramento
frequente.
Observao: O tempo de processamento de solicitaes de blocos CR (consistent read) no
cache corresponde a (build time + flush time + send time) e o tempo de
processamento de solicitaes do bloco atual no cache corresponde a (pin time +
flush time + send time).

Eventos de Espera para Sistemas RAC
Os eventos de espera ajudam a analisar quais sesses

esto em status de espera.
Os tempos de espera so atribudos a elementos que
refletem o resultado de uma solicitao:
Placeholders durante a espera
Eventos precisos aps a espera
As esperas do cache global so resumidas em uma
categoria mais ampla denominada Cluster Wait Class.
Esses eventos de espera so usados no ADDM para
possibilitar diagnsticos de cache fusion.
A anlise das sesses que esto em espera um mtodo importante para determinar como
o tempo utilizado. Em sistemas RAC, o tempo de espera atribudo a um evento que
reflete o resultado exato de uma solicitao. Por exemplo, quando uma sesso de uma
instncia est procurando por um bloco no cache global, ela no sabe se receber os dados
armazenados no cache por outra instncia ou se receber uma mensagem para ler no disco.
Os eventos de espera do cache global contm informaes precisas; esses eventos
aguardam mensagens e blocos do cache global. Eles so categorizados principalmente da
seguinte forma:
Resumidos em uma categoria mais ampla denominada Cluster Wait Class
Representados temporariamente por um evento placeholder que permanece ativo
enquanto aguarda um bloco
Atribudos a eventos precisos quando o resultado da solicitao conhecido
Os eventos de espera para RAC contm informaes valiosas para a anlise do
desempenho. Eles so usados no ADDM para possibilitar diagnsticos precisos do impacto
do cache fusion.

Views de Eventos de Espera
Total de esperas por um evento V$SYSTEM_EVENT
Esperas de uma sesso

V$SESSION_WAIT_CLASS
por uma classe de eventos
Esperas de uma sesso
V$SESSION_EVENT
por um evento
Atividade de sesses
V$ACTIVE_SESSION_HISTORY
ativas recentes
10 ltimos eventos de espera
V$SESSION_WAIT_HISTORY
de cada sesso ativa
Eventos que as sesses
ativas aguardam V$SESSION_WAIT
Identifica as instrues SQL afetadas V$SQLSTATS

por latncias de interconexo
Quando a aquisio de recursos demora um pouco por causa da distncia total a ser
percorrida e da latncia das solicitaes, os processos permanecem em repouso para evitar
esperas durante perodos indeterminados. Quando o processo decide aguardar, ele ativado
depois que um valor especificado para o timer expira (timeout) ou quando o evento que ele
est aguardando ocorre. Os eventos de espera so registrados e agregados nas views
mostradas no slide. Os trs primeiros so agregaes de tempos de espera, de timeouts e do
nmero de vezes em que um evento especfico foi aguardado, enquanto os restantes
permitem monitorar as sesses em espera em tempo real, incluindo um histrico de eventos
recentes aguardados.
Os eventos se diferenciam pelo nome e pelos parmetros que aceitam. Para a maioria dos
eventos de espera do cache global, os parmetros incluem o nmero do arquivo, o nmero
do bloco, a classe do bloco e as disposies de modo de acesso, tais como o modo que est
sendo mantido e o solicitado. Os tempos de espera por eventos apresentados e agregados
nessas views so muito teis na depurao de problemas de desempenho causados por
tempo de resposta. Observe que o tempo de espera cumulativo e que o evento com os
valores mais altos no necessariamente um problema. No entanto, se no for possvel
maximizar a capacidade de CPU disponvel ou se os tempos de resposta para uma aplicao
forem muito longos, os principais eventos de espera fornecero importantes diagnsticos de
desempenho.
Observao: Use a coluna CLUSTER_WAIT_TIME da view V$SQLSTATS para identificar as
instrues SQL afetadas por latncias de interconexo ou para executar um relatrio do
ADDM sobre o snapshot do AWR correspondente.
Eventos de Espera do Cache Global: Viso Geral
Solicitado h pouco gc [current/cr] [multiblock] request

tempo (placeholder)
gc [current/cr] block [2/3]-way gc [current/cr] block busy
Recebido depois de dois ou trs hops da Recebido mas no enviado imediatamente
rede, imediatamente aps a solicitao
gc [current/cr] grant 2-way gc current grant busy

No recebido e no controlado localmente. No recebido e no controlado localmente.
Grant recebido imediatamente. Grant recebido com atraso.
gc [current/cr] [block/grant] congested gc [current/cr] [failure/retry]

Bloco ou grant recebido com atraso No recebido como consequncia de falha
por falta de memria ou CPU
gc buffer busy
Tempo de chegada do bloco menor
que o tempo de pin no buffer
Os principais eventos de espera do cache global so descritos resumidamente no slide:

gc current/cr request: Esses eventos de espera s so relevantes enquanto
uma solicitao gc para um buffer de bloco ou atual cr est em andamento. Eles
funcionam como placeholders at a concluso da solicitao.
gc [current/cr] block [2/3]-way: Um bloco atual ou cr solicitado e recebido
depois de dois ou trs hops da rede. A solicitao processada imediatamente; o bloco
no est ocupado nem congestionado.
gc [current/cr] block busy: Um bloco atual ou cr solicitado e recebido, mas
no enviado imediatamente pelo LMS, pois foi detectada uma condio especial que
atrasou o envio.
gc [current/cr] grant 2-way: Um bloco atual ou cr solicitado e uma
mensagem de grant recebida. O grant feito sem atrasos significativos. Se o bloco
no estiver no cache local, um grant atual ou cr ser acompanhado de uma leitura de
disco na instncia solicitante.
gc current grant busy: Um bloco atual solicitado e uma mensagem de grant
recebida. A hint "busy" implica o bloqueio da solicitao porque h outras antes dela ou
porque no possvel trat-la imediatamente.
Observao: para o remastering dinmico, dois eventos so da mxima importncia: gc
remaster e gc quiesce. Eles so sintomas do impacto do remastering nos processos em
execuo.
gc [current/cr] [block/grant] congested: Um bloco atual ou cr solicitado
e uma mensagem de grant ou um bloco recebido. "Congested" implica a permanncia
da solicitao em filas internas por mais de 1 minuto.
gc [current/cr] [failure/retry]: Um bloco solicitado e um status de falha
recebido ou ocorreu outro evento excepcional.
gc buffer busy: Se o tempo entre os acessos ao buffer for menor que o tempo de
reteno do buffer na memria, o buffer que contm um bloco ser considerado
ocupado e, como resultado, os usurios interessados talvez precisem esperar at a sua
liberao.
Observao: para obter mais informaes, consulte o Oracle Database Reference.

Esperas por Enfileiramento Global
Os enfileiramentos so sncronos.
Os enfileiramentos so recursos globais em sistemas RAC.
As esperas mais frequentes se referem a:
As esperas podem constituir pontos de serializao graves.
Uma espera por enfileiramento no especfica de sistemas RAC, mas envolve uma operao
de bloqueio global quando o ambiente RAC est ativado. Em sua maioria, as solicitaes
globais de enfileiramento so sncronas e so aguardadas por processos de foreground.
Portanto, a disputa por enfileiramentos em sistemas RAC mais visvel que em ambientes com
uma nica instncia. A maioria das esperas ocorre para enfileiramentos dos seguintes tipos:
TX: Enfileiramento de transaes; usado para a demarcao e o rastreamento de
transaes
TM: Enfileiramento de tabelas ou parties; usado para proteger definies de tabelas
durante operaes DML
HW: Enfileiramento de marca dgua superior; adquirido para sincronizar a operao de um
novo bloco
SQ: Enfileiramento de sequncias; usado para serializar o incremento de um nmero de
sequncia Oracle
US: Enfileiramento de segmentos de undo; usado principalmente pelo recurso AUM
(Automatic Undo Management)
TA: Enfileiramento usado principalmente para a recuperao de transaes como parte da
recuperao de uma instncia
Em todos os casos anteriores, as esperas so sncronas e podem constituir pontos de
serializao que podem ser agravados em um ambiente RAC.
Observao: os eventos de espera por enfileiramento especificam o nome do recurso e um
motivo para a espera por exemplo, "TX Enqueue index block split". Essa caracterstica
facilita o diagnstico de esperas por enfileiramento.
Estatsticas de Sesso e Sistema
Use a view V$SYSSTAT para caracterizar a carga de trabalho.

Use a view V$SESSTAT para monitorar sesses importantes.
A view V$SEGMENT_STATISTICS inclui estatsticas do
ambiente RAC.
Os grupos de estatsticas relevantes para o ambiente RAC so:
Estatsticas do Servio de Cache Global
Estatsticas dos Servios de Enfileiramento Global
Estatsticas de mensagens enviadas
A view V$ENQUEUE_STATISTICS determina o enfileiramento
com o maior impacto.
A view V$INSTANCE_CACHE_TRANSFER decompe as
estatsticas do servio de cache global em classes de bloco.
As estatsticas do sistema derivadas da view V$SYSSTAT permitem caracterizar a atividade do

banco de dados com base em valores mdios. Elas so a base para vrias mtricas e relaes
usadas em diversos mtodos e ferramentas, como AWR, Statspack e Database Control.
Para fazer drill-down de sesses individuais ou agrupadas, a view V$SESSTAT til quando os
identificadores de sesses importantes para o monitoramento so conhecidos. Sua utilidade
ser ainda maior se uma aplicao preencher as colunas MODULE e ACTION da view
V$SESSION.
A view V$SEGMENT_STATISTICS til para sistemas RAC porque tambm rastreia o nmero
de blocos atuais e CR recebidos pelo objeto.
possvel agrupar estatsticas relevantes para o ambiente RAC em:
Estatsticas dos Servios de Cache Global: gc cr blocks received, gc cr block receive
time, etc.
Estatsticas dos Servios de Enfileiramento Global: global enqueue gets, etc.
Estatsticas de mensagens enviadas: gcs messages sent e ges messages sent
Consulte a view V$ENQUEUE_STATISTICS para determinar qual enfileiramento tem o maior
impacto nos tempos de servio do banco de dados e, consequentemente, nos tempos de
resposta.
A view V$INSTANCE_CACHE_TRANSFER indica quantos blocos atuais e CR por classe de
bloco so recebidos de cada instncia, incluindo quantas transferncias incorreram em atraso.
Observao: para obter mais informaes sobre estatsticas consulte Oracle Database
Reference.
Dicas Mais Comuns para Ajuste do Ambiente RAC
O ajuste de aplicaes normalmente o mais vantajoso.

Reduza longas varreduras integrais de tabelas em
sistemas OLTP.
Use o ASSM (Automatic Segment Space Management).
Aumente caches de sequncias.
Use o particionamento para reduzir o trfego entre
instncias.
Evite parses desnecessrios.
Minimize o uso de bloqueios.
Remova ndices no seletivos.
Configure a interconexo adequadamente.
Em qualquer sistema de banco de dados, RAC ou com uma nica instncia, os ganhos de
desempenho mais significativos geralmente so obtidos por meio de tcnicas tradicionais de
ajuste de aplicaes. As vantagens dessas tcnicas so ainda mais importantes em um
banco de dados RAC. Alm do ajuste tradicional de aplicaes, algumas das tcnicas
especialmente importantes para o ambiente RAC incluem:
Tentar evitar varreduras integrais de tabelas longas para minimizar as solicitaes do
sistema de cache global. As solicitaes globais de CR nesse cenrio causam
overhead porque, quando as consultas resultam em cache misses locais, primeiro
feita uma tentativa de localizar os dados em outro cache com base na suposio muito
provvel de que outra instncia tenha armazenado o bloco no cache.
O recurso de Gerenciamento Automtico do Espao em Segmentos pode fornecer a
afinidade de instncias com blocos de tabelas.
O aumento dos caches de sequncias melhora a afinidade de instncias com chaves
de ndice que derivam os prprios valores das sequncias. Essa tcnica pode resultar
em ganhos significativos de desempenho para aplicaes de muitas inseres em
vrias instncias.
Se for possvel direcionar a carga de trabalho para modificar uma faixa especfica de
valores de determinada instncia, o particionamento por faixa ou lista poder ser muito
eficiente quando conjugado ao roteamento dependente de dados.

O particionamento por hash pode ajudar a reduzir a disputa por buffer ocupado tornando
os padres de distribuio do acesso ao buffer mais dispersos, o que permite
disponibilizar mais buffers para acesso concorrente.
Em ambientes RAC, as operaes de cache de biblioteca e de cache de linha so
coordenadas globalmente. Portanto o excesso de parse acarreta mais trfego entre as
conexes. Os bloqueios de cache de biblioteca so muito usados, em especial por
aplicaes que utilizam PL/SQL ou Advanced Queuing. Os bloqueios de cache de
biblioteca so adquiridos no modo exclusivo sempre que necessrio recompilar um
package ou um procedure.
Como os bloqueios de transaes so coordenados globalmente, eles tambm merecem
ateno especial no ambiente RAC. Por exemplo, a utilizao de tabelas em vez de
sequncias Oracle para gerar nmeros exclusivos no recomendvel porque pode
causar um problema grave de disputa at mesmo em um sistema com uma nica
instncia.
Os ndices no seletivos no melhoram o desempenho de consultas, mas podem
prejudicar o desempenho de instrues DML. No ambiente RAC, os blocos de ndices
no seletivos podem estar sujeitos a disputa entre instncias, aumentando a frequncia
de transferncias de cache para ndices que pertencem a tabelas com muitas instrues
insert.
Verifique sempre se est usando uma rede privada para a sua interconexo e certifique-
se de que a rede privada esteja configurada corretamente. Certifique-se de que um
vnculo da rede esteja operando no modo full duplex. Verifique se a sua interface de rede
e os switches Ethernet suportam um tamanho de MTU de 9 KB. Observe que uma
interface Ethernet de um nico gigabit pode fazer scale-up de at dez mil blocos de 8 KB
por segundo antes da saturao.

Disputa por Blocos de ndice: Consideraes
Eventos de espera
Bloco
enq: TX - index
de ndice
contention
Diviso em
gc buffer busy
andamento
gc current block busy
gc current split
Estatsticas do sistema
Leaf node splits
Branch node splits
Exchange deadlocks
gcs refuse xid
gcs ast xid
Service ITL waits RAC01 RAC02
Em sistemas de aplicaes nos quais a carga ou o processamento batch de dados uma

funo importante para os negcios, talvez ocorram problemas de desempenho que afetem
os tempos de resposta em funo do alto volume de dados inserido nos ndices.
Dependendo da frequncia de acesso e do nmero de processos que inserem dados
simultaneamente, os ndices podem se tornar hot spots e a disputa pode ser agravada por:
Valores-chave crescentes ordenados uniformemente no ndice (rvores que se
expandem para a direita)
Divises frequentes de blocos-folha
Pouca profundidade da rvore: Todo o acesso aos blocos-folha passa pelo bloco-raiz.
Uma diviso de um bloco-folha ou de uma ramificao de bloco poder se tornar um ponto
de serializao importante se a ramificao ou o bloco-folha especfico da rvore tiver acesso
simultneo. As tabelas no slide renem os sintomas mais comuns associados diviso de
blocos de ndice. Elas listam eventos de espera e estatsticas que geralmente apresentam
elevaes quando as divises de bloco de ndice tm prevalncia. Para atenuar o impacto no
desempenho provocado por blocos de ndice globalmente sobrecarregados e por divises de
blocos-folha, o principal objetivo deve ser uma distribuio mais uniforme e menos irregular
da concorrncia na rvore do ndice. Para atingir esse objetivo, basta:
Aplicar o particionamento por hash de ndice global
Aumentar o cache de sequncia, se o valor-chave for derivado de uma sequncia
Usar chaves naturais, em vez de chaves substitutas
Usar ndices de chave invertida
Sequncias Oracle e Disputa por ndice
Pode conter 500 linhas

150000 50001100000
CACHE 50000 NOORDER
RAC01 RAC02
Os ndices com valores-chave gerados por sequncias tendem a estar sujeitos a disputa por
blocos-folha quando a taxa de insero alta. Isso ocorre porque o bloco-folha do ndice com
o valor-chave mais alto alterado a cada linha inserida, pois os valores aumentam
uniformemente. Em sistemas RAC, essa caracterstica pode levar a uma alta taxa de blocos
atuais e CR transferidos entre ns.
Uma das tcnicas mais simples que pode ser usada para limitar esse overhead o aumento
do cache de sequncia, caso voc esteja usando sequncias Oracle. Como a diferena entre
os valores de sequncia gerados por instncias distintas aumenta, as sucessivas divises de
blocos do ndice tendem a criar afinidade entre a instncia e blocos-folha do ndice. Por
exemplo, suponha que um valor-chave de ndice seja gerado por uma sequncia CACHE
NOORDER e que cada bloco-folha de ndice possa manter 500 linhas. Se o cache de
sequncia for definido como 50000, enquanto a instncia 1 insere os valores 1, 2, 3 etc. a
instncia 2 inserir simultaneamente 50001, 50002 etc. Depois de algumas divises de
blocos, cada instncia gravar informaes em uma parte diferente da rvore de ndice.
Portanto, qual ser o valor ideal de um cache de sequncia para evitar a disputa por blocos-
folha de ndice entre instncias e, ao mesmo tempo, minimizar a ocorrncia de possveis
intervalos? Uma das principais variveis a ser considerada a taxa de insero: quanto mais
alta ela for, maior dever ser o cache de sequncia. No entanto, crie uma simulao para
avaliar os ganhos de uma configurao especfica.
Observao: por default, o valor de cache 20. Em geral, 20 muito pouco para o exemplo
acima.
Consideraes sobre Blocos de Undo
ndice Alteraes
Leituras

SGA1 SGA2
Undo Undo
Trfego adicional
de interconexo
O excesso de envio de blocos de undo para buffers de undo e de disputa por esses buffers
normalmente ocorre quando os blocos de ndice que contm transaes ativas de vrias
instncias so lidos com frequncia.
Quando uma instruo SELECT precisa ler um bloco com transaes ativas, ela tem de
desfazer as alteraes para criar uma verso CR. Se as transaes ativas no bloco
pertencerem a mais de uma instncia, ser preciso combinar as informaes de undo
remotas e locais para fazer uma leitura consistente. Dependendo da quantidade de blocos de
ndice alterados por vrias instncias e da durao das transaes, o envio de blocos de
undo poder gerar um gargalo.
Em geral, isso ocorre em aplicaes que leem os dados inseridos recentemente com muita
frequncia, mas fazem pouco commit. As tcnicas usadas para reduzir esses problemas
incluem:
Transaes menores diminuem a probabilidade de que um bloco de ndice no cache
contenha dados no submetidos a commit, reduzindo assim a necessidade de acessar
informaes de undo para fazer uma leitura consistente.
Como explicado anteriormente, o aumento dos tamanhos de caches de sequncia
reduz o acesso simultneo entre instncias aos blocos-folha do ndice. possvel gerar
verses CR de blocos de ndice modificados por apenas uma instncia sem as
informaes remotas de undo.
Observao: em sistemas RAC, o problema agravado porque necessrio obter um
subconjunto de informaes de undo das instncias remotas.

Consideraes sobre HWM (High-Water Mark)
Eventos de espera
enq: HW -
contention
gc current grant Inseres
intensas
HWM
Inseres
intensas
Nova extenso
RAC01 RAC02
Uma certa combinao de eventos de espera e estatsticas ocorre em aplicaes nas quais a
insero de dados uma funo predominante dos negcios e preciso alocar novos blocos
com frequncia para um segmento. Se forem inseridos dados em alta velocidade, talvez seja
necessrio disponibilizar novos blocos aps procuras frustradas por espao livre. Isso
precisa ocorrer ao mesmo tempo em que mantido o enfileiramento de HWM (High-Water
Mark).
Portanto, os sintomas mais comuns para esse cenrio incluem:
Um alto percentual de tempo de espera para enq: HW contention
Um alto percentual de tempo de espera para eventos gc current grant
O primeiro uma consequncia da serializao no enfileiramento de HWM, e o segundo
ocorre porque o acesso atual aos novos blocos de dados que precisam de formatao
necessrio para a nova operao dos blocos. Em um ambiente RAC, a durao dessa
operao de gerenciamento de espao proporcional ao tempo necessrio para adquirir o
enfileiramento de HWM e ao tempo necessrio para adquirir bloqueios globais para todos os
novos blocos que precisam de formatao. Esse tempo curto em circunstncias normais
porque nunca h conflito de acesso para os novos blocos. Portanto, esse cenrio pode
ocorrer em aplicaes com funes de negcios que requerem uma grande carga de dados,
e a principal recomendao para atenuar os sintomas a definio de extenses com
tamanhos grandes e uniformes para os segmentos com gerenciamento de espao local ou
automtico sujeitos a altos volumes de inseres.

Chamadas Concorrentes de Vrias Instncias:

Consideraes
Blocos
sujos
SGA1 SGA2
Tabela1 Tabela1
CKPT CKPT
Tabela2 Tabela2
1
2
3 4
Truncar Tabela1 Truncar Tabela2
Chamada de vrias instncias
Nos ambientes de data warehouse e data mart, comum ocorrerem vrias operaes
TRUNCATE. Elas ocorrem principalmente nas tabelas contendo dados temporrios.
Em um ambiente RAC, o truncamento concorrente de tabelas de diferentes instncias no
escalonado adequadamente, principalmente se, ao mesmo tempo, voc estiver usando
operaes de leitura direta, como consultas paralelas.
Conforme mostrado no slide, uma operao de truncamento requer a chamada de vrias
instncias para descarregar os blocos sujos da tabela que podem estar distribudos entre
vrias instncias. Isso constitui um problema de serializao. Portanto, enquanto o primeiro
comando TRUNCATE estiver sendo processado, o segundo dever aguardar at a concluso
do primeiro.
H diferentes tipos de chamadas de vrias instncias. Entretanto, todas usam o mesmo
mecanismo de serializao.
Por exemplo, o descarregamento do cache de uma tabela com vrias parties poder
adicionar latncia a uma consulta paralela correspondente. Isso porque cada chamada de
vrias instncias serializada no nvel de cluster, e uma chamada de vrias instncias
necessria para cada partio no incio da consulta paralela para fins de leitura direta.

Monitorando o Desempenho do
Banco de Dados RAC e do Cluster
Banco de dados
Diretamente do EM Cloud Control:
Visualize o status de cada n do cluster.
Visualize as mensagens de alerta
Instncias
agregadas entre todas as instncias.
Analise os problemas que esto afetando
todo o cluster ou cada instncia.
Monitore as estatsticas de coerncia do cache de cluster.
Determine se qualquer um dos servios para o banco de
dados clusterizado est tendo problemas de
disponibilidade.
Analise todos os alertas de interconexo pendentes do
Clusterware.
O Oracle Enterprise Manager Database Control e o Grid Control so "cluster-aware" e

fornecem uma console central para gerenciar seu banco de dados clusterizado. Na pgina
Cluster Database Home, voc pode executar todos estes procedimentos:
Visualizar o status geral do sistema, como o nmero de ns do cluster e seu status
atual. Dessa forma, no necessrio acessar cada instncia individual do banco de
dados para obter detalhes.
Visualizar as mensagens de alerta agregadas por todas as instncias, com listas da
origem de cada mensagem de alerta.
Analisar os problemas que esto afetando o cluster inteiro, bem como os que esto
afetando instncias individuais.
Monitorar as mtricas de coerncia do cache do cluster para ajud-lo a identificar
tendncias de processamento e a otimizar o desempenho do ambiente Oracle RAC. As
estatsticas de coerncia do cache medem como esto sincronizados os dados nos
caches em vrias instncias.
Determinar se qualquer um dos servios para o banco de dados clusterizado est tendo
problemas de disponibilidade. Um servio ser considerado problemtico se no estiver
em execuo em todas as instncias preferenciais, se os limites de tempo de resposta
no forem atendidos, etc.
Analise todos os alertas de interconexo pendentes do Clusterware.
Pgina de Desempenho do Banco de Dados de Cluster
A pgina Cluster Database Performance apresenta uma viso geral das estatsticas de
desempenho de um banco de dados. O Enterprise Manager acumula dados de cada
instncia por perodos especficos, denominados dados com base em conjuntos. O
Enterprise Manager tambm fornece dados atuais de cada instncia, conhecidos como
dados em tempo real.
As estatsticas so submetidas a rollup em todas as instncias do banco de dados
clusterizado. Por meio dos links ao lado dos grficos, voc pode obter informaes mais
especficas e executar qualquer uma destas tarefas:
Identificar os motivos de problemas de desempenho.
Decidir se os recursos precisaro ser adicionados ou redistribudos.
Ajustar seu plano e esquema SQL para aperfeioar a otimizao.
Resolver problemas de desempenho.
A captura de tela do slide mostra uma view parcial da pgina Cluster Database Performance.
Voc acessa esta pgina selecionando Performance Home no menu pull-down Performance,
na pgina Cluster Database Home.

Determinando a Mdia de Carga do Host do Cluster
O grfico Cluster Host Load Average da pgina Cluster Database Performance mostra os
problemas em potencial que ocorrem fora do banco de dados. Ele mostra os valores de
carga mximo, mdio e mnimo para os ns disponveis do cluster na hora anterior.
Se a mdia de carga for maior do que a mdia do nmero total de CPUs entre todos os hosts
do cluster, um nmero excessivo de processos est aguardando recursos da CPU. As
instrues SQL que no so ajustadas, em geral, causam alto uso da CPU. Compare os
valores mdios de carga com os valores exibidos em CPU Used no grfico Average Active
Sessions. Se o valor das sesses for baixo e o valor mdio de carga for alto, isso indicar
que algo mais, alm de seu banco de dados, est consumindo os recursos da CPU.
Voc pode clicar em qualquer um dos labels de valor de carga do grfico Cluster Host Load
Average para visualizar informaes mais detalhadas sobre o valor de carga. Por exemplo,
se clicar no label Average, a pgina Hosts: Average Load ser exibida, mostrando grficos
com a carga mdia do host para at quatro ns do cluster.
possvel escolher se os dados sero exibidos em um grfico resumido, combinando os
dados de cada n em uma tela ou usando grficos de mosaico, nos quais os dados de cada
ns so exibidos em seu prprio grfico. Voc pode clicar em Customize para alterar o
nmero de grficos de mosaico exibidos em cada linha ou o mtodo de ordenao dos
grficos.

Determinando a Latncia de Acesso

aos Blocos do Cache Global
O grfico Global Cache Block Access Latency mostra a latncia para cada tipo de solicitao
de bloco de dados: blocos atuais e CR (leitura consistente). Trata-se do tempo transcorrido
para localizar e transferir blocos atuais e de leitura consistente entre os caches de buffer.
Voc pode clicar em qualquer mtrica do grfico Global Cache Block Access Latency para
visualizar informaes mais detalhadas sobre o tipo de bloco em cache especfico.
Se o grfico Global Cache Block Access Latency mostrar altas latncias (longos perodos
transcorridos), a causa poder ser qualquer uma das seguintes:
Um alto nmero de solicitaes causadas por instrues SQL no ajustadas
Um grande nmero de processos na fila aguardando a CPU ou atrasos
Interconexes lentas, ocupadas ou com problemas. Nesses casos, verifique se h na
sua conexo de rede pacotes descartados, retransmisses ou erros CRC (verificao
de redundncia cclica).
A atividade de leitura e gravao concorrentes em dados compartilhados em um cluster
uma atividade que ocorre com frequncia. Dependendo dos requisitos de servio, essa
atividade normalmente no causa problemas de desempenho. No entanto, quando
solicitaes de cache global causam um problema de desempenho, a otimizao dos planos
e do esquema SQL para melhorar a frequncia na qual os blocos de dados so localizados
no cache de buffer local e a diminuio das entradas/sadas compem uma estratgia bem-
sucedida para ajustar o desempenho. Se a latncia de solicitaes de bloco atual e de leitura
consistente atingir 10 milissegundos, consulte a pgina Cluster Cache Coherency para obter
informaes mais detalhadas.
Determinando Sesses Mdias Ativas
O grfico Average Active Sessions da pgina Cluster Database Performance mostra os

problemas que podem ocorrer dentro do banco de dados. Categorias, denominadas classes
de espera, mostram quanto do banco de dados est usando um recurso, como a CPU ou
entradas/sadas do disco. A comparao do tempo de CPU com o tempo de espera ajuda a
determinar quanto do tempo de resposta consumido com trabalho til e no na espera por
recursos possivelmente retidos por outros processos.
No nvel do banco de dados clusterizado, esse grfico mostra as estatsticas de classe de
espera agregadas entre todas as instncias. Para obter uma anlise mais detalhada, clique
no cone Clipboard, na parte inferior do grfico, para visualizar a anlise ADDM para o banco
de dados durante o perodo em questo.
Se voc clicar nas legendas das classes de espera ao lado do grfico Average Active
Sessions, poder visualizar informaes no nvel da instncia armazenadas nas pginas
"Active Sessions by Instance". Voc pode usar a lista de aes Wait Class da pgina "Active
Sessions by Instance" para visualizar as diferentes classes de espera. As pginas "Active
Sessions by Instance" mostram os tempos de servio de at quatro instncias. Com o boto
Customize, voc pode selecionar as instncias que so exibidas. possvel visualizar os
dados das instncias separadamente, usando grficos de mosaico, ou combinar os dados
em um nico grfico resumido.

Determinando o Throughput do Banco de Dados
O ltimo grfico da pgina Performance monitora o uso de vrios recursos do banco de

dados. Clique na tab Throughput, na parte superior desse grfico, para visualizar o grfico
Database Throughput. Compare os picos no grfico Average Active Sessions com os
exibidos nos grficos Database Throughput. Se a disputa interna for alta e o throughput
baixo, considere ajustar o banco de dados.
Os grficos Database Throughput resumem qualquer disputa por recursos exibida no grfico
Average Active Sessions e tambm mostram a quantidade de trabalho que est sendo
executada pelo banco de dados para os usurios ou as aplicaes. A view Per Second
mostra o nmero de transaes comparado com o nmero de logons e (no mostrado aqui) o
nmero de leituras fsicas em comparao com o tamanho de redo por segundo. A view Per
Transaction mostra o nmero de leituras fsicas comparado com o tamanho de redo por
transao. Logons o nmero de usurios conectados ao banco de dados.
Para obter informaes no nvel da instncia, acesse a pgina "Database Throughput by
Instance" clicando em uma das legendas direita dos grficos. Essa pgina mostra o
detalhamento do grfico Database Throughput agregado de at quatro instncias. Voc pode
selecionar as instncias que so exibidas. possvel fazer drilldown na pgina "Database
Throughput by Instance" para ver as sesses de uma instncia que esto consumindo a
maior quantidade de recursos. Clique na legenda de nome de uma instncia abaixo do
grfico para acessar a subpgina Top Sessions da pgina Top Consumers correspondente
instncia em questo.

Determinando o Throughput do Banco de Dados
O ltimo grfico da pgina Performance monitora o uso de vrios recursos do banco de

dados. Ao clicar na tab Instances, na parte superior desse grfico, voc pode visualizar o
grfico "Active Sessions by Instance".
O grfico "Active Sessions by Instance" resume todas as disputas por recursos que
aparecem no grfico Average Active Sessions. Com esse grfico, voc pode determinar
rapidamente a quantidade de trabalho que est sendo feito em cada instncia do banco de
dados.
Tambm possvel obter informaes no nvel da instncia, clicando em uma das legendas
direita do grfico, para acessar a pgina Top Sessions. Na pgina Top Sessions, voc pode
visualizar dados em tempo real mostrando as sesses que consomem a maior quantidade de
recursos do sistema. No grfico do slide, a instncia orcl_3 aps 12:30 est mostrando, de
forma consistente, mais sesses ativas do que a instncia orcl_1.

Acessando a Pgina Cluster Cache Coherency
Global Cache Block
Access Latency
Global Cache Block

Transfer Rate
Global Cache Block

Transfers and
Physical Reads
Para acessar a pgina Cluster Cache Coherency, clique na tab Performance da pgina
Cluster Database Home, e clique em Cluster Cache Coherency na seo Additional
Monitoring Links, na parte inferior da pgina. Opcionalmente, clique em uma das legendas
direita do grfico Global Cache Block Access Latency.
A pgina Cluster Cache Coherency contm grficos resumidos de mtricas de coerncia do
cache para o cluster:
Global Cache Block Access Latency: mostra o tempo total transcorrido, ou a latncia,
de uma solicitao de bloco. Clique em uma das legendas direita do grfico para
visualizar o tempo mdio transcorrido para receber blocos de dados de cada tipo de
bloco (atual ou CR) por instncia. Na pgina "Average Block Receive Time by
Instance", voc pode clicar na legenda de uma instncia, abaixo do grfico, para
acessar a pgina "Block Transfer for Local Instance", na qual possvel identificar quais
classes de blocos, como blocos de undo, blocos de dados, etc., esto sujeitos a
atividade intensa do cache global. Essa pgina exibe as classes dos blocos que esto
sendo transferidos e quais instncias esto transferindo a maioria dos blocos. A
transferncia de cache indica quantos blocos atuais e CR para cada classe de bloco
foram recebidos de instncias remotas, incluindo a quantidade de transferncias que
incorreram em atraso (ocupado) ou em um atraso mais longo inesperado
(congestionado).

Acessando a Pgina Cluster Cache Coherency
Global Cache Block Transfer Rate: este grfico mostra o nmero total agregado de
blocos de dados recebidos por todas as instncias no cluster por meio de uma
interconexo. Clique em uma das legendas direita do grfico para acessar a pgina
"Global Cache Blocks Received by Instance" correspondente ao tipo de bloco em
questo. Nessa pgina, possvel clicar na legenda de uma instncia, abaixo do
grfico, para acessar a pgina "Segment Statistics by Instance", na qual voc pode ver
quais segmentos esto causando disputa no cache.
Global Cache Block Transfers and Physical Reads: mostra o percentual de
operaes de leitura lgica que recuperaram dados do cache de buffer de outras
instncias por meio de Direct Memory Access e do disco. Ele praticamente um perfil
do volume de trabalho executado no cache de buffer local, e no a parte das
referncias remotas e fsicas que apresentam latncias mais altas. Clique em uma das
legendas direita do grfico para acessar as pginas "Global Cache Block Transfers
vs. Logical Reads by Instance" e "Physical Reads vs. Logical Reads by Instance".
Nessa pgina, possvel clicar na legenda de uma instncia, abaixo do grfico, para
acessar a pgina "Segment Statistics by Instance", na qual voc pode ver quais
segmentos esto causando disputa no cache.

Exibindo a Pgina Database Locks
Use o link Database Locks encontrado na seo Additional Monitoring Links para determinar
se vrias instncias contm bloqueios para o mesmo objeto. A pgina mostra bloqueios de
usurio, todos os bloqueios do banco de dados ou bloqueios de outros usurios ou
aplicaes. Voc pode usar essas informaes para interromper uma sesso que esteja
bloqueando um objeto desnecessariamente.
Para acessar a pgina Database Locks, selecione Performance na pgina Cluster Database
Home e clique em Database Locks na seo Additional Monitoring Links, na parte inferior da
subpgina Performance.

Snapshots do AWR no Ambiente RAC
MMON Coordinator
Estatsticas
na memria
SYSAUX
SGA (Inst1)
Tabelas do AWR
06:00:00
09:00:00 07:00:00
08:00:00
MMON 09:00:00
Estatsticas
na memria
SGA (Instn)
O AWR gera automaticamente snapshots dos dados de desempenho uma vez por hora e
coleta as estatsticas no repositrio de carga de trabalho. Em ambientes RAC, cada snapshot
do AWR captura dados de todas as instncias ativas no cluster. Os dados de cada conjunto
de snapshots capturados para todas as instncias ativas so obtidos praticamente ao mesmo
tempo. Alm disso, os dados de cada instncia so armazenados separadamente e
identificados com um identificador de instncia. Por exemplo, as estatsticas
buffer_busy_wait mostram o nmero de esperas por buffers em cada instncia. O AWR
no armazena dados agregados do cluster inteiro. Isso significa que os dados so
armazenados para cada instncia individual.
possvel avaliar os snapshots de estatsticas gerados pelo AWR, produzindo relatrios que
exibem dados sumariados, como perfis de cluster e de carga com base em estatsticas
regulares e eventos de espera reunidos sobre cada instncia.
O AWR funciona de maneira semelhante ao Statspack. A diferena que o AWR coleta e
mantm automaticamente estatsticas de desempenho com fins de deteco de problemas e
autoajuste. Diferentemente do Statspack, no AWR s h um snapshot_id por snapshot
entre instncias.

Relatrios do AWR e Ambientes RAC: Viso Geral
As estatsticas relacionadas ao ambiente RAC em um relatrio do AWR esto listadas no

relatrio do AWR por categoria. A anlise do menu Main Report relaciona as categorias no
relatrio. As informaes disponveis incluem:
O nmero de instncias abertas no momento do snapshot inicial e do snapshot final
para indicar se houve ativao ou desativao de instncias entre os dois snapshots
O Global Activity Load Profile, que basicamente lista o nmero de mensagens e blocos
enviados e recebidos, bem como o nmero de fusion writes
Os percentuais de eficincia do cache global, que indicam o percentual de buffer que
segmentado em buffers recebidos do disco, do cache local e dos caches remotos. O
ideal que o percentual de acessos do buffer ao disco seja prximo a zero.
As Global Cache and Enqueue Workload Characteristics, que fornecem uma viso
geral das estatsticas mais importantes primeiro. Como as estatsticas de converso de
enfileiramento global foram consolidadas com as estatsticas de obteno de
enfileiramento global, o relatrio s imprime o tempo mdio de obteno de
enfileiramento global. Em seguida, so exibidos os tempos de acesso para as
transferncias de blocos atuais e CR, bem como as estatsticas de remetentes
individuais de blocos atuais e CR. Os tempos mdios de descarga de logs so
calculados dividindo-se o tempo total de descarga de logs pelo nmero real de
descargas de logs. Alm disso, o relatrio imprime o percentual de blocos atendidos
que realmente incorreram em uma descarga de logs.

Global Cache and Enqueue Messaging Statistics. A estatstica mais importante aqui a
queue time on ksxp, que um bom indicador das condies de funcionamento do IPC.
Os nmeros mdios devem ser inferiores a 1 minuto.
A seo Segment Statistics tambm inclui as informaes GC Buffer Busy Waits, CR Blocks
Received e CUR Blocks Received para os segmentos relevantes.
Nota: para obter mais informaes sobre eventos de espera e estatsticas, consulte Oracle
Database Reference.

Relatrios de Histrico de
Sesses Ativas para o Ambiente RAC
As estatsticas do relatrio ASH (Active Session History,
Histrico de Sesses Ativas) fornecem detalhes sobre a
atividade das sesses do Banco de Dados RAC.
O banco de dados registra
informaes sobre sesses
ativas de todas as
instncias ativas do RAC.
Duas seo do relatrio
ASH especficas do
Oracle RAC so
Top Cluster Events e
Top Remote Instance.
O ASH (Active Session History) uma parte integrante da estrutura de autogerenciamento do

Oracle Database e til para diagnosticar problemas de desempenho em ambientes Oracle
RAC. As estatsticas do relatrio ASH fornecem detalhes sobre a atividade das sesses do
Oracle Database. O Oracle Database registra informaes sobre sesses ativas de todas as
instncias ativas do Oracle RAC e armazena esses dados na SGA (System Global Area).
Qualquer sesso conectada ao banco de dados e que esteja usando a CPU considerada
uma sesso ativa. A exceo a essa regra so as sesses que aguardam um evento
pertencente classe de espera inativa.
Os relatrios ASH apresentam um conjunto de dados gerencivel, capturando somente
informaes sobre sesses ativas. A quantidade de dados est diretamente relacionada ao
trabalho que est sendo realizado, e no ao nmero de sesses permitidas no sistema. As
estatsticas do ASH, reunidas durante um perodo especificado, podem ser colocadas em
relatrios ASH.
Cada relatrio ASH dividido em vrias sesses, para que voc possa identificar problemas
de desempenho de curta durao que no aparecem na anlise do ADDM. Duas sees do
relatrio ASH especficas ao Oracle RAC so Top Cluster Events e Top Remote Instance.

Top Cluster Events

A seo Top Cluster Events do relatrio ASH faz parte do relatrio Top Events, que
especfico ao Oracle RAC. O relatrio Top Cluster Events relaciona eventos responsveis
pela alta porcentagem de atividade de sesso no evento de classe de espera do cluster,
juntamente com o nmero das instncias afetadas. Voc pode usar essas informaes para
identificar quais eventos e instncias causaram uma alta porcentagem de eventos de espera
do cluster.
Top Remote Instance
A seo Top Remote Instance do relatrio ASH faz parte do relatrio Top Load Profile, que
especfico ao Oracle RAC. O relatrio Top Remote Instance mostra os eventos de espera do
cluster, juntamente com os nmeros das instncias responsveis pelas altas porcentagens
de atividade de sesso. Voc pode usar essas informaes para identificar a instncia que
causou o perodo de espera estendido do cluster.

Automatic Database Diagnostic Monitor para RAC

O ADDM pode executar uma anlise:
Do cluster inteiro
De uma instncia especfica do banco de dados
Database ADDM
De um subconjunto de instncias do banco de dados
Mecanismo de autodiagnstico
Instance ADDM
AWR

Inst1 Instn
Com o ADDM (Automatic Database Diagnostic Monitor), voc pode analisar as informaes
coletadas pelo AWR relativas a possveis problemas de desempenho no seu banco de dados
Oracle. O ADDM apresenta dados de desempenho do ponto de vista do cluster, permitindo,
dessa forma, analisar o desempenho globalmente. Em um ambiente Oracle RAC, o ADDM
pode analisar o desempenho usando os dados coletados de todas as instncias e apresent-
los em diferentes nveis de granularidade, incluindo:
Anlise do cluster inteiro
Anlise de uma instncia especfica do banco de dados
Anlise de um subconjunto de instncias do banco de dados
Para realizar essas anlises, voc pode executar o ADDM Advisor no modo Database ADDM
for RAC, a fim de efetuar uma anlise do cluster inteiro, no modo Local ADDM para analisar o
desempenho de uma instncia individual, ou no modo Partial ADDM, para analisar um
subconjunto de instncias. O Database ADDM for RAC no apenas um relatrio, mas
apresenta uma anlise independente, que apropriada para o RAC. Ative a anlise do
ADDM usando o advisor framework pelo Advisor Central no Oracle Enterprise Manager, ou
pelos pacotes PL/SQL DBMS_ADVISOR e DBMS_ADDM.

Automatic Database Diagnostic Monitor para RAC
Identifica os problemas de desempenho mais crticos

do banco de dados clusterizado RAC inteiro
executado automaticamente quando so obtidos
snapshots do AWR
Executa uma anlise no mbito do banco de dados de:
Recursos globais (por exemplo, bloqueios globais e de
entradas/sadas)
SQL de alta carga e blocos sobrecarregados
Trfego de interconexo do cache global
Problemas de latncia de rede
Distoro nos tempos de resposta das instncias
usado por DBAs para analisar o desempenho do cluster
No requer a investigao de relatrios n para localizar
problemas comuns
Voc pode criar um modo de anlise de perodo para o ADDM, que analise o desempenho
de throughput de um cluster inteiro. Quando o advisor executado nesse modo, ele
denominado database ADDM. Voc pode executar o advisor para uma nica instncia, que
denominado instance ADDM.
O Database ADDM tem acesso aos dados do AWR gerados por todas as instncias,
tornando, dessa forma, a anlise dos recursos globais mais precisa. O database e o instance
ADDM so executados em perodos contnuos, que podem conter inicializao e shutdown
de instncias. No caso do database ADDM, poder haver vrias instncias submetidas a
shutdown ou iniciadas durante o perodo de anlise. No entanto, necessrio manter a
mesma verso de banco de dados pelo perodo inteiro.
O Database ADDM executado automaticamente aps a obteno de cada snapshot. Voc
tambm pode efetuar uma anlise em um subconjunto de instncias no cluster. Isso
chamado partial analysis ADDM.
A descoberta da capacidade de entradas/sadas (o sistema de entradas/sadas usado
excessivamente) uma descoberta global porque se refere a um recurso global que afeta
vrias instncias. Uma descoberta local se refere a um recurso local ou problema que afeta
uma nica instncia. Por exemplo, uma instncia de limite de CPU resulta em uma
descoberta local sobre a CPU. Embora o ADDM possa ser usado durante o desenvolvimento
de aplicaes para testar as alteraes na aplicao, no sistema de banco de dados ou nas
mquinas host, o database ADDM projetado para os DBAs.

O que o ADDM Diagnostica para o RAC?
Problemas de latncia na interconexo

Congestionamento (identificando as instncias que mais
afetam o cluster inteiro)
Disputa (buffer ocupado, principais objetos, etc.)
Os principais consumidores de solicitaes de vrios
blocos
Blocos perdidos
Fornece informaes sobre dispositivos de interconexo;
alerta sobre o uso de interfaces PBLICAS
Informa o throughput de dispositivos, o quanto usado
pelo Oracle e para qual finalidade (GC, bloqueios, PQ)
As origens de dados so:

Eventos de espera (principalmente classe de cluster e buffer ocupado)
Relatrios ASH (Active Session History)
Dados de transferncia do cache de instncias
Estatsticas de interconexo (throughput, uso pelo componente, pings)
O ADDM analisa os efeitos do RAC para o banco de dados inteiro (modo de anlise
DATABASE) e para cada instncia (modo de anlise INSTANCE).

Suporte do EM para ADDM for RAC
O Enterprise Manager exibe a anlise do ADDM na home page do Cluster Database.

Na pgina Automatic Database Diagnostic Monitor (ADDM), o grfico Database Activity (no
mostrado aqui) faz a plotagem da atividade do banco de dados durante o perodo de anlise
do ADDM. Os tipos de atividade do banco de dados esto definidos na legenda com base em
sua cor correspondente no grfico. Cada cone abaixo do grfico representa uma tarefa
diferente do ADDM que, por sua vez, corresponde a um par de snapshots individuais do
Oracle Database salvos no Workload Repository.
Na seo ADDM Performance Analysis, as descobertas do ADDM esto listadas em ordem
decrescente, do maior ao menor impacto. Para cada descoberta, a coluna Affected Instances
exibe o nmero (m de n) das instncias afetadas. Ao fazer o drilldown nas descobertas, voc
acessar a pgina Performance Findings Detail. A seo Informational Findings contm as
reas que no apresentam um impacto no desempenho e servem apenas a fins informativos.
O grfico DB Time Breakdown mostra o quanto essa instncia impactada por essas
descobertas. A exibio indica a porcentagem de impacto para cada instncia.

Questionrio
Embora existam reas de ajuste especficas para RAC, como a

recuperao de instncia e o trfego de interconexo, voc
obtm mais vantagens ajustando o sistema como se ele
tivesse uma nica instncia.
a. Verdadeiro
b. Falso
Resposta: a

Questionrio
Quais das seguintes dicas de ajuste do RAC esto corretas?

a. O ajuste de aplicaes normalmente o mais vantajoso.
b. Reduza longas varreduras integrais de tabelas em
sistemas OLTP.
c. Elimine caches de sequncias.
d. Use o particionamento para reduzir o trfego entre
instncias.
e. Configure a interconexo adequadamente.
Resposta: a, b, d, e

Sumrio

Determinar os componentes de ajuste especficos de
sistemas RAC
Determinar as estatsticas do sistema, os enfileiramentos
globais e os eventos de espera especficos de sistemas RAC
Implementar as dicas de ajuste mais comuns em sistemas
RAC
Usar as pginas de desempenho de banco de dados de
cluster
Usar o AWR (Automatic Workload Repository) no Ambiente
RAC
Usar o ADDM (Automatic Database Diagnostic Monitor) no
Ambiente RAC

Este exerccio abrange a deteco manual de problemas

de desempenho, usando as pginas de desempenho do
EM e o ADDM.

Gerenciando a Alta
Disponibilidade de Servios
Objetivos

Configurar e gerenciar servios em um ambiente RAC
Usar servios com aplicaes clientes
Usar servios com o Database Resource Manager
Usar servios com o Scheduler
Configurar a agregao e o rastreamento de servios

Oracle Services
Para gerenciar cargas de trabalho ou um grupo de

aplicaes, voc pode definir servios para uma
determinada aplicao ou um subconjunto de operaes
de uma aplicao.
Voc tambm pode trabalhar em grupo por tipo de
servios.
Por exemplo, os usurios OLTP podem usar um servio
enquanto o processamento batch pode usar outro para
conectar-se ao banco de dados.
Os usurios que compartilham um servio devem ter os
mesmos requisitos de nvel de servio.
Use srvctl ou o Enterprise Manager para gerenciar
servios, no o DBMS_SERVICE.
Para gerenciar cargas de trabalho ou um grupo de aplicaes, voc pode definir os servios
que voc atribui a uma determinada aplicao ou a um subconjunto de operaes de uma
aplicao. Voc tambm pode trabalhar em grupo por tipo de servios. Por exemplo, os
usurios on-line podem usar um servio enquanto o processamento batch pode usar outro, e
a gerao de relatrios pode usar outro servio para conectar-se ao banco de dados.
recomendvel que os usurios que compartilham um servio tenham os mesmos requisitos
de nvel de servio. Voc pode definir caractersticas especficas para os servios, e cada um
pode ser uma unidade de trabalho separada. H muitas opes que voc pode aproveitar ao
usar servios. Embora voc no precise implementar essas opes, o uso delas ajuda a
otimizar o desempenho da aplicao. possvel definir servios para bancos de dados
gerenciados por poltica e pelo administrador.
No use DBMS_SERVICE com servios gerenciados por cluster. Quando o Oracle
Clusterware inicia um servio, ele atualiza o banco de dados com os atributos armazenados
no recurso CRS. Se voc usar DBMS_SERVICE para modificar o servio e no atualizar o
recurso CRS, na prxima vez em que este for iniciado, ele substituir os atributos do banco
de dados definidos pelo DBMS_SERVICE.

Uso do Servio em um
Banco de Dados Oracle RAC
Os servios fornecem transparncia de local.
Um nome de servio pode identificar vrias instncias do
banco de dados e uma instncia pode pertencer a vrios
servios.
Os perfis de recursos so criados automaticamente
quando voc define um servio.
Um perfil de recursos descreve a forma como o Oracle
Clusterware deve gerenciar o servio.
Os perfis de recursos tambm definem as dependncias de
servio em relao instncia e ao banco de dados.
Os servios so integrados ao Resource Manager,
permitindo que voc restrinja os recursos que os usurios
utilizam a fim de se conectar a uma instncia, ao usar um
servio.
Os servios fornecem transparncia de local. Um nome de servio pode identificar vrias

instncias do banco de dados e uma instncia pode pertencer a vrios servios. Diversos
recursos de banco de dados usam dispositivos para um banco de dados Oracle RAC.
Os perfis de recursos so criados automaticamente quando voc define um servio. Um perfil
de recursos descreve como o Oracle Clusterware deve gerenciar o servio e qual instncia o
servio deve assumir como failover, caso a instncia preferida pare. Os perfis de recursos
tambm definem as dependncias de servio em relao instncia e ao banco de dados.
Devido a essas dependncias, se voc interromper um banco de dados, as instncias e os
servios so automaticamente interrompidos na ordem correta.
Os servios so integrados ao Oracle Resource Manager, permitindo que voc restrinja os
recursos que os usurios utilizam a fim de se conectar a uma instncia, ao usar um servio.
O Oracle Resource Manager permite que voc mapeie um grupo de consumidores a um
servio, de forma que os usurios que se conectam a uma instncia usando esse servio
sejam membros do grupo de consumidores especificado. O Oracle Resource Manager
funciona no nvel da instncia.
Os dados mtricos gerados pelo AWR so organizados em diversos grupos, como mtricas
de evento, de classe de evento, sesso, servio e tablespace. Normalmente, voc exibe os
dados do AWR usando relatrios do Oracle Enterprise Manager ou do AWR.
Em um ambiente Global Data Services, o modelo de servio do RAC aplicado a conjuntos
de bancos de dados distribudos globalmente. O GDS funciona com bancos de dados de
uma nica instncia ou de RAC com o uso do Data Guard, GoldenGate ou outras tecnologias
de replicao.
Operaes e Servios Paralelos
Por padro, em um ambiente Oracle RAC, uma instruo

SQL executada paralelamente pode ser executada em
todos os ns do cluster.
Para ter um bom desempenho, a interconexo deve ser
dimensionada da forma correta, j que havendo um trfego
intenso de interconexes, pode ocorrer uma execuo
paralela entre ns.
Voc pode controlar a execuo paralela em um ambiente
RAC com o parmetro de inicializao
PARALLEL_FORCE_LOCAL.
Os servidores de execuo paralela somente podem ser
executados no mesmo n do Oracle RAC onde a instruo
SQL foi iniciada.
Os servios podem ser usados para limitar o nmero de
instncias que participam de uma operao SQL paralela.
Por default, em um ambiente Oracle RAC, uma instruo SQL executada paralelamente pode
ser executada em todos os ns do cluster. Para que esta execuo paralela entre ns ou por
todos os ns seja realizada, a interconexo no ambiente Oracle RAC deve ser dimensionada
da forma apropriada, pois a execuo paralela entre ns pode resultar em muito trfego
interconexo. Para limitar a execuo paralela entre ns, voc pode controlar a execuo
paralela em um ambiente Oracle RAC usando o parmetro de inicializao
PARALLEL_FORCE_LOCAL. Definindo este parmetro como TRUE, os processos de
execuo paralela somente podem ser executados no mesmo n do Oracle RAC em que a
instruo SQL foi iniciada.
Os servios so usados para limitar o nmero de instncias que participam de uma operao
SQL paralela. Quando o servio de banco de dados padro usado, a operao paralela no
SQL pode ser executada em todas as instncias disponveis. Voc pode criar qualquer
nmero de servios, cada qual consistindo em uma ou mais instncias. Quando uma
operao SQL paralela iniciada, os servidores de execuo paralela somente so gerados
nas instncias que oferecem o servio especificado usado na conexo do banco de dados
inicial.
INSTANCE_GROUPS um parmetro do RAC que voc pode especificar somente no modo
paralelo. Usado em conjunto com o parmetro PARALLEL_INSTANCE_GROUP, ele permite a
voc restringir operaes de consultas paralelas em um nmero limitado de instncias. Para
restringir as operaes de consulta paralelas a um nmero limitado de instncias, defina o
parmetro de inicializao PARALLEL_INSTANCE_GROUP como o nome de um servio. Isto
no afeta outras operaes paralelas como a recuperao ou o processamento paralelo das
consultas GV$.
Caractersticas dos Servios
As caractersticas de um servio incluem:

Service Name
Service Edition
Service Management Policy
Database Role for a Service
Instance Preference
Server Pool Assignment
Load Balancing Advisory Goal for Run-time Connection
Load Balancing
Connection Load Balancing Goal
Ao criar novos servios para o seu banco de dados, defina as caractersticas automticas de
gerenciamento da carga de trabalho de cada servio. As caractersticas de um servio
incluem:
Service Name: O nome do servio usado pelos clientes para se conectarem a uma ou
mais instncias. O nome do servio deve ser exclusivo em todo o sistema.
Service Edition: A redefinio de objetos do banco de dados baseada na edio permite o
upgrade dos objetos de um aplicativo, enquanto os objetos estiverem em uso. Quando a
edio do servio for definida, as conexes que usam este servio usam esta edio como a
edio da sesso inicial. Se o servio no especificar o nome da edio, ento a edio da
sesso inicial a edio padro do banco de dados.
Service Management Policy: Quando voc usa o Clusterware para gerenciar seu banco de
dados, pode configurar as opes de inicializao para cada servio individual do banco de
dados quando adiciona o servio usando o comando srvctl add service com o parmetro -
policy. Se voc definir a poltica de gerenciamento para um servio como AUTOMATIC (o
padro), ento o servio iniciado automaticamente.
Database Role for a Service: Se voc configurou o Oracle Data Guard no seu ambiente,
ento pode definir uma funo para cada servio usando o SRVCTL com o parmetro -l.
Instance Preference: Ao definir um servio para um banco de dados gerenciado pelo
administrador, voc define quais instncias suportam esse servio usando o SRVCTL com o
parmetro preferred. Elas so conhecidas como instncias preferenciais.
Server Pool Assignment: Quando voc define servios para um banco de dados
gerenciado por polticas, atribui o servio a um pool de servidores no qual o banco de dados
esteja hospedado com o SRVCTL e o parmetro serverpool. possvel definir o
servio como UNIFORME (em execuo em todas as instncias no pool de servidores) ou
NICO (em execuo em apenas uma instncia no pool) usando o parmetro -
cardinality. Para servios nicos, o RAC escolhe a instncia no pool de servidores na
qual o servio est ativo. Se essa instncia falhar, ento o servio faz o failover para outra
instncia do pool de servidores. Um servio somente pode ser executado em um pool de
servidores e a Oracle recomenda que todo pool de servidores tenha, pelo menos, um servio.
Load Balancing Advisory Goal for Run-time CLB: Com o balanceamento de carga de
conexo de runtime, os aplicativos podem usar eventos load balancing advisory para
fornecer um servio melhor aos usurios. O Oracle JDBC, Oracle UCP para Java, pool de
sesses da OCI, ODP.NET e Oracle WebLogic Server Active GridLink para os clientes
Oracle RAC so automaticamente integrados para tirar partido dos eventos load balancing
advisory. Para ativar o load balancing advisory, use o SRVCTL com o parmetro -rlbgoal
ao criar ou modificar o servio. O load balancing advisory tambm recomenda a quantidade
da carga de trabalho que deve ser enviada a essa instncia. A meta determina se as
conexes so feitas no servio com base na qualidade do servio melhor (com quanta
eficincia uma nica transao concluda) ou o melhor throughput (com quanta eficincia
um job completo ou uma consulta de longa execuo concluda).
Connection Load Balancing Goal: O Oracle Net Services fornece o balanceamento de
carga de conexo para permitir que voc distribua as conexes dos usurios em todas as
instncias que estiverem suportando um servio. Em cada servio, voc pode usar o
SRVCTL para definir o mtodo que deseja que o listener use para o balanceamento de
carga, definindo a meta de balanceamento de carga de conexo, especificada com o
parmetro -clbgoal. As conexes so classificadas como LONG (como os pools de
conexo e SQL*FORMS), que informam ao listener para usar a contagem de sesses ou
SHORT, que informam ao listener para usar as estatsticas de tempo de resposta ou
throughput. Se o load balancing advisory estiver ativado, suas informaes sero usadas
para balancear as conexes; caso contrrio, a utilizao de CPU ser empregada para
equilibrar as conexes.

Conexes de Servio Padro
Seu banco de dados RAC inclui um servio do banco de

dados Oracle identificado por DB_UNIQUE_NAME, caso
seja definido.
DB_NAME ou PDB_NAME, em caso negativo.
Esse servio padro sempre est disponvel em todas as
instncias em um ambiente Oracle RAC.
Adicionalmente, o banco de dados suporta dois servios
internos:
SYS$BACKGROUND usado apenas pelos processos de
background.
SYS$USERS o servio padro para sesses de usurio no
associadas a qualquer servio de aplicao.
O seu banco de dados RAC inclui um servio do banco de dados Oracle identificado por DB_
UNIQUE_NAME, caso seja definido, ou DB_NAME ou PDB_NAME, caso no seja. Esse servio
default sempre est disponvel em todas as instncias em um ambiente Oracle RAC, a
menos que uma instncia esteja no modo restrito. No possvel alterar esse servio nem
suas propriedades. Em um ambiente multilocatrio, todo PDB tem um servio padro gerado
na criao do PDB. Adicionalmente, o banco de dados suporta os dois servios internos a
seguir:
O servio SYS$BACKGROUND usado apenas pelos processos de background.
SYS$USERS o servio default para sesses de usurio no associadas a qualquer
servio de aplicao.
Todos esses servios so usados para o gerenciamento interno. Voc no pode interromper
ou desativar qualquer um desses servios internos para fazer paralisaes planejadas ou
passar o failover para o Oracle Data Guard. No use esses servios para conexes de
clientes. Voc pode gerenciar explicitamente somente os servios que criar. Se um recurso
do banco de dados criar um servio interno, voc no poder gerenci-lo usando os mtodos
apresentados aqui.

Restricted Service Registration
O Restricted Service Registration permite o registro do listener

somente em endereos de IP local, por padro.
Ele proporciona a capacidade de configurar e atualizar um
conjunto de endereos e sub-redes dos quais solicitaes de
registro so permitidas pelo listener.
O registro de Database Instance em um listener feito com
xito somente quando a solicitao se origina de um n vlido.
O administrador da rede pode especificar uma lista de ns
vlidos e excludos ou desabilitar a verificao de ns vlidos.
O controle do registro dinmico resulta em uma maior
gerenciabilidade e segurana das implantaes do Oracle
RAC.
A verificao de ns vlidos para registro (VNCR) ativada
por padro.
Para todas as empresas, a segurana uma grande prioridade. A segurana da rede e o

acesso e o controle do banco de dados so, portanto, componentes crticos de todos os
esforos da segurana. Este recurso permite o registro do listener somente em endereos de
IP local, por padro, e fornece a capacidade de configurar e atualizar, de forma dinmica, um
conjunto de endereos IP ou sub-redes dos quais as solicitaes de registro sejam
autorizadas pelo listener. O registro de instncias de bancos de dados em um listener feito
com xito somente quando a solicitao se origina de um n vlido. O administrador da rede
pode especificar uma lista de ns vlidos e excludos ou desabilitar a verificao de ns
vlidos. A lista de ns vlidos relaciona explicitamente os ns e as sub-redes que podem se
registrar no banco de dados. A lista de ns excludos relaciona explicitamente os ns que
no podem se registrar no banco de dados. O controle do registro dinmico resulta em uma
maior gerenciabilidade e segurana das implantaes do Oracle RAC. Por padro, a
verificao de ns vlidos para registro (VNCR) est habilitada. Na configurao padro, as
solicitaes de registro somente so autorizadas a partir de ns dentro do cluster, pois so
redirecionadas sub-rede privada, e somente os ns dentro do cluster podem acessar a sub-
rede privada. Os listeners que no sejam SCAN s aceitam o registro de instncias no n
local. Voc deve incluir manualmente os ns remotos ou os ns de fora da sub-rede do
listener SCAN na lista de ns vlidos por meio do parmetro
registration_invited_nodes_alias no arquivo listener.ora ou modificando o
listener SCAN usando SRVCTL como se segue:
$ srvctl modify scan_listener -invitednodes node_list -invitedsubnets
subnet_list
Criando um Servio com o Enterprise Manager
Gerenciado por Poltica
Na home page Cluster Database, clique no link Availability e, em seguida, selecione Cluster
Managed Database Services na lista pull-down. Na pgina Cluster Managed Database
Services, clique em Create Service.
Use a pgina Create Service para configurar um novo servio no qual ser necessrio
executar as seguintes tarefas:
Selecione a poltica de servio desejada para cada instncia configurada para o banco
de dados clusterizado.
Selecione as propriedades de servio desejadas.
Se o seu banco de dados for gerenciado pela administrao, a seo High Availability
Configuration permitir que voc configure servidores preferenciais e disponveis. Se ele
empregar administrao gerenciada por poltica, voc poder configurar a cardinalidade do
servio como UNIFORM ou SINGLETON e atribuir o servio a um pool de servidores.
Tambm possvel definir a poltica de gerenciamento para um servio. Voc pode escolher
uma poltica de gerenciamento automtica ou manual.
Automatic: o servio sempre iniciado quando o banco de dados iniciado.
Manual: requer que o servio seja iniciado manualmente. Antes do Oracle RAC 11g
Release 2, todos os servios funcionavam como se tivessem sido definidos com uma
poltica de gerenciamento manual.
Observao: o Enterprise Manager agora gera as entradas correspondentes aos seus
servios nos arquivos tnsnames.ora. Basta clicar na caixa de seleo "Update local
naming parameter (tnsnames.ora) file" ao criar o servio.
Criando Servios com o SRVCTL

Para criar um servio denominado GL com a instncia
preferencial RAC02 e uma instncia disponvel RAC01:
$ srvctl add service db PROD1 service GL -preferred RAC02
-available RAC01
Para criar um servio denominado AP com a instncia
preferencial RAC01 e uma instncia disponvel RAC02:
$ srvctl add service db PROD1 service AP preferred RAC01
-available RAC02
Crie um servio SINGLETON chamado BATCH usando o pool

de servidores SP1 e um servio UNIFORM denominado ERP
usando o pool SP2:
$ srvctl add service -db PROD2 -service BATCH -serverpool
SP1 -cardinality singleton -policy manual
$ srvctl add service -db PROD2 -service ERP -serverpool

SP2 -cardinality UNIFORM -policy manual
Para o exemplo no slide, imagine um banco de dados gerenciado pela administrao, com
dois ns, denominado PROD1, com uma instncia RAC01 em um n e uma instncia RAC02
no outro. Foram criados dois servios, AP e GL, a serem gerenciados pelo Oracle
Clusterware. O servio AP definido com uma instncia preferencial de RAC01 e uma
instncia disponvel de RAC02.
Se RAC01 ficar inativa, o membro do servio AP na RAC01 ser restaurado automaticamente
na RAC02. Um cenrio semelhante se aplica ao servio GL.
Em seguida, imagine um banco de dados clusterizado, gerenciado por poltica, denominado
PROD2. So criados dois servios, um SINGLETON denominado BATCH e um UNIFORM
denominado ERP. Servios SINGLETON so executados em um dos servidores ativos, e
servios UNIFORM so executados em todos os servidores ativos do pool. As caractersticas
do pool de servidores determinam como os recursos so alocados ao servio.
Observao: quando so criados servios com o srvctl, tnsnames.ora no atualizado,
e o servio no iniciado.

Gerenciando Servios com o Enterprise Manager
Voc pode usar o Enterprise Manager para gerenciar servios em um framework de GUI. A
imagem mostrada no slide a pgina principal para administrar servios no RAC. Ela mostra
informaes bsicas de status sobre um servio definido.
Para acessar esta pgina, selecione Cluster Managed Database Services no menu pull-down
Availability.
Voc poder gerenciar tarefas simples relacionadas a servios, como ativar, desativar,
inicializar, interromper e reposicionar servios. Todas as operaes possveis so mostradas
no slide.
Se voc optar por iniciar um servio na pgina Cluster Managed Database Services, o EM
tentar iniciar o servio em todas as instncias preferenciais. A interrupo do servio vai
interromp-lo em todas as instncias em que ele est sendo executado.
Para reposicionar um servio, escolha o servio que deseja administrar, selecione a opo
Manage na lista drop-down Actions e clique em Go.
Observao: na pgina Cluster Managed Database Services, voc poder testar a conexo
para um servio.

Gerenciando Servios com o EM
Para acessar a pgina Cluster Managed Database Service para um servio individual,
escolha um servio na pgina Cluster Managed Database Services, selecione a opo
Manage na lista drop-down Actions e clique em Go.
Essa a pgina Cluster Managed Database Service para um servio individual. Ela oferece a
mesma funcionalidade que a pgina anterior, mas as aes executadas aqui se aplicam a
instncias especficas de um servio.
Essa pgina tambm oferece a funcionalidade de reposicionar um servio em uma instncia
disponvel. Reposicionar um servio de uma instncia para outra interrompe o servio na
primeira instncia e o inicia na segunda.

Criando Servios com o srvctl
Inicie um servio nomeado em todas as instncias configuradas:

$ srvctl start service db orcl service AP
Interrompa um servio:
$ srvctl stop service db orcl service AP instance orcl4
Desative um servio em uma instncia nomeada:

$ srvctl disable service db orcl service AP instance orcl4
Defina uma instncia disponvel como uma instncia preferencial:

$ srvctl modify service db orcl service AP -instance orcl5
preferred
Reposicione um servio de uma instncia para outra:
$ srvctl relocate service db orcl service AP -oldinst
orcl5 newinst orcl4
O slide demonstra algumas tarefas de gerenciamento de servios com o SRVCTL.

Suponha que um servio AP foi criado com quatro instncias preferenciais: orcl1, orcl2,
orcl3 e orcl4. Uma instncia disponvel, orcl5, tambm foi definida para AP.
No primeiro exemplo, o servio AP iniciado em todas as instncias preferenciais. Se
qualquer uma das instncias preferenciais ou disponveis que suportam o AP no estiver em
execuo mas estiver ativada, ela ser iniciada.
O comando stop interrompe o servio AP na instncia orcl4. A instncia propriamente dita
no desativada, mas permanece em execuo possivelmente suportando outros servios.
O servio AP continua a ser executado em orcl1, orcl2 e orcl_3. A inteno talvez tenha
sido fazer uma manuteno em orcl4, portanto, para impedir o reincio automtico do
servio AP, ele foi desativado nessa instncia. O OCR registra o fato de o AP estar
desativado em orcl4. Portanto, o Oracle Clusterware no executar AP em orcl4 at que o
servio seja ativado.
O ltimo comando no slide faz com que orcl5 deixe de ser uma instncia disponvel e passe
a ser uma instncia preferencial. Isso ser vantajoso se a inteno for manter sempre quatro
instncias executando o servio, pois orcl4 havia sido desativada. O ltimo exemplo
reposiciona o servio AP da instncia orcl5 para a orcl4. No execute outras operaes
de servio enquanto a modificao on-line de um servio estiver em andamento. O seguinte
comando reposiciona o servio AP do host01 para o host03 usando a sintaxe do n:
$ srvctl relocate service -db orcl -service AP -currentnode host01
-targetnode node3
Usando Servios com Aplicaes Clientes

ERP=(DESCRIPTION= ## Using SCAN ##
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=cluster01-scan)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=ERP)))
ERP=(DESCRIPTION= ## Using VIPs ##
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=1521))
url="jdbc:oracle:oci:@ERP" ## Thick JDBC ##
url="jdbc:oracle:thin:@(DESCRIPTION= ## Thin JDBC ##

(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=cluster01-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=ERP)))"
O primeiro exemplo no slide mostra o descritor de conexo TNS que pode ser usado para
acessar o servio ERP. Ele usa o SCAN (Single Client Access Name) do cluster. O SCAN
fornece aos clientes que se conectam ao Oracle RAC um nico nome que no alterado por
toda a vida do cluster, mesmo se voc adicionar ou remover ns do cluster. Os clientes que
se conectam com o SCAN podem usar uma string de conexo simples, como o URL JDBC
thin ou EZConnect, e ainda obter balanceamento de carga e failover da conexo do cliente.
O segundo exemplo usa endereos IP virtuais como nas verses anteriores do Oracle
Database.
O terceiro exemplo mostra a descrio de conexo JDBC thick usando o descritor de
conexo TNS definido anteriormente.
O terceiro exemplo mostra a descrio de conexo JDBC thin usando o mesmo descritor de
conexo TNS que o primeiro exemplo.
Observao: a clusula LOAD_BALANCE=ON usada pelo Oracle Net para acompanhar seu
andamento atravs dos endereos de protocolo do descritor de conexo. Esse recurso
chamado de balanceamento de carga de conexes do cliente.

Servios e Balanceamento de Carga de Conexes
Os dois mtodos de balanceamento de carga que voc pode

implementar so:
Balanceamento de carga do cliente: equilibra as solicitaes de
conexo nos listeners
Balanceamento de carga do servidor: o listener direciona uma
solicitao de conexo para a melhor instncia que atualmente
fornece o servio usando o LBA (load balancing advisory).
A FAN, o Fast Connection Failover, e o LBA dependem de uma
configurao de balanceamento de carga de conexo que inclui
a definio do objetivo de balanceamento de carga de conexo
para o servio.
O objetivo de balanceamento de carga para o servio pode ser:
LONG: para aplicaes que tm conexes duradouras. Em geral, se
destina a pools de conexes e sesses do SQL*Forms.
SHORT: para aplicaes que tm conexes de curta durao
srvctl modify service -service service_name -clbgoal
LONG|SHORT
O Oracle Net Services oferece a capacidade de balancear conexes de clientes pelas

instncias em uma configurao do Oracle RAC. Voc pode implementar dois tipos de
balanceamento de carga: do cliente e do servidor. O balanceamento de carga do cliente
equilibra as solicitaes de conexo nos listeners. Com o balanceamento de carga do
servidor, o listener do SCAN direciona uma solicitao de conexo para a melhor instncia
que estiver fornecendo atualmente o servio, com base nas configuraes de clbgoal e -
rlbgoal do servio. Em um banco de dados RAC, as conexes de cliente devem usar os
dois tipos de balanceamento.
A FAN, o Fast Connection Failover, e o load balancing advisory dependem de uma
configurao de balanceamento de carga de conexo precisa que inclui a definio do
objetivo de balanceamento de carga de conexo para o servio. Voc pode usar um objetivo
LONG ou SHORT para balanceamento de carga de conexo. Os objetivos tm as seguintes
caractersticas:
LONG: Use o mtodo de balanceamento de carga LONG para aplicaes que tenham
conexes duradouras. Em geral, se destina a pools de conexes e sesses do
SQL*Forms. LONG o objetivo de balanceamento de carga de conexo default.
SHORT: Use o mtodo de balanceamento de carga de conexo SHORT para aplicaes
que tenham conexes de curta durao. O exemplo a seguir modifica o servio ORDER,
usando srvctl para definir o objetivo como SHORT: srvctl modify service -s
ORDER -j SHORT

Servios e o Transparent Application Failover
Os servios simplificam a implantao do TAF

(Transparent Application Failover).
possvel definir uma poltica de TAF para um servio, e
todas as conexes que o usam tero automaticamente o
TAF habilitado.
A definio de TAF em um servio pode ser NONE, BASIC
ou PRECONNECT e substitui qualquer definio de TAF na
definio de conexo de cliente.
Para definir uma poltica de TAF para um servio, o
utilitrio srvctl pode ser usado da seguinte forma:
srvctl modify service -db crm -service GL
-failovermethod BASIC -failovertype SELECT
-failoverretry 10 -failoverdelay 30
Quando o Oracle Net Services estabelece conexo com uma instncia, ela permanece
aberta at que o cliente encerre a conexo, seja feito shutdown da instncia ou haja uma
falha. Se voc configurar o TAF para a conexo, na ocorrncia de uma interrupo, o Oracle
Database mover a sesso para uma instncia sobrevivente.
O TAF pode reiniciar uma consulta aps o trmino do failover, mas para outros tipos de
transaes, como INSERT, UPDATE ou DELETE, a aplicao dever fazer rollback da
transao com falha e reenvi-la. necessrio executar novamente todas as
personalizaes da sesso, em outras palavras, ALTER SESSION (alterar as instrues da
sesso) aps a ocorrncia do failover. No entanto, com o TAF, uma conexo no ser
movida durante o processamento normal, mesmo se a carga de trabalho for alterada com o
tempo.
Os servios simplificam a implantao do TAF. possvel definir uma poltica de TAF para
um servio, e todas as conexes que o usam tero automaticamente o TAF habilitado. Isso
no requer nenhuma alterao no lado do cliente. A definio de TAF em um servio substitui
qualquer definio de TAF na definio de conexo do cliente.
Observao: o TAF aplicado apenas a um banco de dados gerenciado pelo administrador
e no a bancos de dados gerenciados por poltica.

Usando Servios com o Resource Manager
Grupos de consumidores so designados automaticamente

a sesses com base nos servios das sesses.
O trabalho priorizado pelo servio que est dentro de
uma instncia.
AP Recursos da instncia
Conexes AP 75%
BATCH BATCH 25%
O Database Resource Manager (tambm chamado de Resource Manager) permite que voc
identifique o trabalho usando servios. Ele gerencia a prioridade relativa dos servios dentro
de uma instncia associando servios diretamente a grupos consumidores. Quando um
cliente estabelece conexo usando um servio, o grupo de consumidores designado de
modo transparente no momento da conexo. Isso permite que o Resource Manager gerencie
as solicitaes de trabalho por servio em ordem de importncia.
Por exemplo, voc define que os servios AP e BATCH sero executados na mesma
instncia, e designa AP a um grupo de consumidores de prioridade alta e BATCH a um grupo
de consumidores de baixa prioridade. As sesses que estabelecem conexo com o banco de
dados especificando o servio AP em seus respectivos descritores de conexo TNS tm
prioridade sobre aquelas que estabelecem conexo com o servio BATCH.
Isso oferece vantagens no gerenciamento de cargas de trabalho porque a prioridade dada
a funes de negcios e no s sesses que suportam essas funes de negcios.

Servios e o Resource Manager com o EM
O Enterprise Manager (EM) apresenta uma GUI na pgina Consumer Group Mapping para
mapear sesses para grupos de consumidores automaticamente. Voc pode acessar esta
pgina selecionando Resource Manager no menu pull-down Cluster Administration e, depois,
clicar no link Consumer Group Mappings.
Na pgina com a tab General da pgina Consumer Group Mapping, voc pode configurar o
mapeamento de sesses relativas a um nome de servio para grupos de consumidores,
conforme ilustrado no slide acima.
Com a capacidade de mapear sesses para grupos de consumidores por servio, mdulo e
ao, voc ter maior flexibilidade para gerenciar o desempenho da carga de trabalho de
diferentes aplicaes.
Na pgina com a tab Priorities da pgina Consumer Group Mapping, voc poder definir
prioridades para os mapeamentos configurados na pgina com a tab General. As opes de
mapeamento correspondem s colunas de V$SESSION. Quando vrias colunas do
mapeamento tiverem valores, as prioridades que voc definiu determinaro a precedncia
para designar sesses a grupos de consumidores.
Observao: voc tambm pode mapear um servio para um grupo de consumidores
diretamente da pgina Create Service, conforme mostrado na parte esquerda inferior do
slide.

Usando Servios com o Scheduler
Os servios so associados a classes do Scheduler.

Os jobs do Scheduler possuem afinidade de servios:
Alta disponibilidade
Balanceamento de carga
HOT_BATCH_SERV HOT_BATCH_SERV LOW_BATCH_SERV
Job Coordinator Job Coordinator Job Coordinator
Processos Processos Processos

escravos escravos escravos
Banco de dados
Tabela de jobs
Job1 HOT_BATCH_CLASS HOT_BATCH_SERV
Job2 HOT_BATCH_CLASS HOT_BATCH_SERV
Job3 LOW_BATCH_CLASS LOW_BATCH_SERV
Assim como em outros ambientes, o Scheduler em um ambiente RAC utiliza uma tabela de
jobs para cada banco de dados e um coordenador de jobs (processo CJQ0) para cada
instncia. Os coordenadores de jobs se comunicam entre eles para atualizar as informaes.
O Scheduler pode usar os servios e os benefcios oferecidos em um ambiente RAC. O
servio que determinada classe de job usa definido quando a classe de job criada.
Durante a execuo, os jobs so designados a classes de job e elas so executadas dentro
dos servios. A utilizao de servios com classes de job garante que o trabalho do
Scheduler seja identificado para gerenciamento de carga de trabalho e ajuste de
desempenho. Por exemplo, um job herda alertas gerados pelo servidor e os limites de
desempenho para o servio no qual executado.
Para proporcionar alta disponibilidade, o Scheduler oferece afinidade de servios em vez de
afinidade de instncias. Os jobs no so programados para serem executados em uma
instncia especfica. Eles so programados para serem executados em um servio. Portanto,
se uma instncia for desativada, o job ainda poder ser executado em qualquer outra
instncia do cluster que oferea o servio.
Observao: se voc especificar o servio no qual deseja que o job seja executado, os
coordenadores de jobs balancearo a carga do sistema para obter melhor desempenho.

Servios e o Scheduler com o EM
Para configurar a execuo de um job em um servio especfico, selecione Oracle Scheduler

no menu pull down Administration e selecione o link Job Classes. Esse procedimento abrir a
pgina Scheduler Job Classes. Na pgina Scheduler Job Classes, voc poder ver os
servios designados a classes de job.
Quando voc clicar no boto Create da pgina Scheduler Job Classes, a pgina Create Job
Class ser exibida. Nessa pgina, voc pode informar detalhes de uma nova classe de job,
inclusive em qual servio ela deve ser executada.
Observao: da mesma forma, voc pode mapear um servio para uma classe de job na
pgina Create Service conforme mostrado na parte inferior do slide.

Servios e o Scheduler com o EM
Depois que a classe de job for configurada com o servio no qual voc deseja que ela seja
executada, voc poder criar o job. Para isso, selecione Oracle Scheduler no menu pull down
Administration e selecione o link Jobs na pgina Server. Ser exibida a pgina Scheduler
Jobs na qual voc poder clicar no boto Create para criar um novo job. Quando voc clicar
no boto Create, a pgina Create Job ser exibida. Essa pgina tem tabs diferentes:
General, Schedule e Options. Use a pgina com a tab General para designar o job a uma
classe de job.
Use a pgina Options (exibida no slide) para definir o atributo Instance Stickiness para o job.
Basicamente, esse atributo faz com que o job tenha a carga balanceada entre as instncias
nas quais o servio do job est sendo executado. O job s pode ser executado em uma
instncia. Se o valor Instance Stickiness for definido como TRUE, que o valor default, o
Scheduler executar o job na instncia na qual o servio for oferecido com a carga mais leve.
Se Instance Stickiness for definido como FALSE, o job ser executado na primeira instncia
disponvel em que o servio seja oferecido.
Observao: possvel definir atributos de job, como INSTANCE_STICKINESS, usando o
procedure SET_ATTRIBUTE do package PL/SQL DBMS_SCHEDULER.

Usando Transaes Distribudas

com o Ambiente RAC
Uma transao XA pode abranger instncias do RAC,
permitindo que qualquer aplicao que use XA tire total proveito
do ambiente Oracle RAC.
As transaes XA totalmente integradas no requerem mais o
tipo especial de servios nicos (DTP).
As transaes XA so transaes suportadas de forma
transparente nos bancos de dados Oracle RAC com qualquer
tipo de configurao de servios.
No entanto, os servios DTP aperfeioaro o desempenho para
muitos cenrios de transaes distribudas.
Os servios DTP permitem direcionar todas as ramificaes de
uma transao distribuda para uma nica instncia no cluster.
Para o balanceamento de carga, melhor ter vrios grupos de
servidores de aplicaes menores com cada grupo direcionando
suas transaes para um nico servio.
Uma transao global (XA) pode abranger instncias do Oracle RAC por default, permitindo
que qualquer aplicao que use a biblioteca Oracle XA tire total proveito do ambiente Oracle
RAC, a fim de aperfeioar a disponibilidade e a escalabilidade da aplicao. Os processos em
background GTXn suportam as transaes XA em um ambiente Oracle RAC. O parmetro de
inicializao GLOBAL_TXN_PROCESSES, definido como 1 por padro, especifica o nmero
inicial de processos de background GTXn para cada instncia do Oracle RAC. Mantenha esse
parmetro no seu valor default em todo o cluster para que as transaes distribudas abranjam
vrias instncias do Oracle RAC. Isso permite que as unidades de trabalho executadas nessas
instncias do Oracle RAC compartilhem recursos e ajam como uma nica transao (ou seja,
as unidades de trabalho so totalmente integradas). Tambm permite que as solicitaes 2PC
sejam enviadas a qualquer n do cluster. As transaes XA totalmente integradas no
requerem mais que o tipo especial de servios nicos (ou seja, servios Oracle DTP
[Distributed Transaction Processing]) seja implantado no banco de dados Oracle RAC. As
transaes XA so transaes suportadas de forma transparente nos bancos de dados Oracle
RAC com qualquer tipo de configurao de servios.
Para fornecer o desempenho aprimorado das aplicaes com o DTP no ambiente RAC, voc
pode preferir tirar partido dos servios DTP ou afinidade XA. Os servios DTP permitem
direcionar todas as ramificaes de uma transao distribuda para uma nica instncia no
cluster. Para o balanceamento de carga no cluster, melhor ter vrios grupos de servidores de
aplicaes menores com cada grupo direcionando suas transaes para um nico servio, ou
conjunto de servios, do que ter um ou dois servidores de aplicaes maiores. necessrio o
DTP ou afinidade XA, caso haja a suspenso e retomada da mesma ramificao de XA
Servios e Transaes Distribudas

Para criar os servios DTP para o processamento de transaes
distribudas, execute as seguintes etapas:
1. Crie um servio nico usando EM ou SRVCTL. Em um banco
de dados gerenciado por administrador, defina somente uma
instncia como a instncia preferida:
$ srvctl add service -db crm -service xa_01.example.com
-preferred RAC01 -available RAC02,RAC03
Em um banco de dados gerenciado por polticas, especifique o
pool de servidores a usar, e defina a cardinalidade do servio
como SINGLETON:
$ srvctl add service -db crm -service xa_01.example.com
-serverpool dtp_pool -cardinality SINGLETON
2. Defina o parmetro de DTP (-dtp) para o servio como TRUE:

$ srvctl modify service -db crm -service xa_01.example.com
-dtp TRUE
Para aperfeioar o desempenho das transaes distribudas, voc pode usar servios para
gerenciar ambientes DTP. Pela definio da propriedade DTP de um servio, garantido que
o servio seja executado em uma instncia por vez, em um banco de dados Oracle RAC.
certo que todas as transaes distribudas globais executadas pelo servio DTP tenham suas
ramificaes totalmente integradas em execuo em uma instncia nica do Oracle RAC.
Estas so as vantagens:
As alteraes ficam disponveis localmente em uma instncia do Oracle RAC quando
ramificaes totalmente integradas precisam de informaes sobre alteraes feitas
entre si.
O reposicionamento e o failover de servios so totalmente suportados por DTP.
Ao usar mais servios DTP do que o nmero de instncias do Oracle RAC existentes, o
Oracle Database pode balancear a carga pelos servios em todas as instncias do
banco de dados Oracle RAC.
Para tirar proveito de todas as instncias em um cluster, crie um ou mais servios DTP para
cada instncia do Oracle RAC que hospeda transaes distribudas. Escolha um servio DTP
para uma transao distribuda. Escolha servios DTP diferentes para transaes
distribudas distintas, para balancear a carga de trabalho entre as instncias do banco de
dados Oracle RAC.
Como todas as ramificaes de uma transao distribuda esto em uma instncia, voc
pode aproveitar todas as instncias para balancear a carga de vrias transaes DTP por
meio de vrios servios nicos, maximizando, dessa forma, o throughput das aplicaes.
Um gerenciador de transaes externas, como o OraMTS, coordena as transaes DTP/XA.
No entanto, um gerenciador de transaes internas Oracle coordena transaes SQL
distribudas. As transaes DTP/XA e SQL distribudas devem usar o servio DTP no Oracle
RAC.
Para criar os servios DTP para o processamento de transaes distribudas, execute as
seguintes etapas:
1. Crie um servio nico usando o Oracle Enterprise Manager ou SRVCTL. Em um banco
de dados gerenciado por administrador, defina somente uma instncia como a instncia
preferida. Voc pode ter quantas instncias disponveis desejar. Por exemplo:
$ srvctl add service -db crm -service xa_01.example.com -
preferred RAC01 -available RAC02,RAC03
Em um banco de dados gerenciado por polticas, especifique o pool de servidores a usar, e
defina a cardinalidade do servio como SINGLETON. Por exemplo:
$ srvctl add service -db crm -service xa_01.example.com -
serverpool dtp_pool -cardinality SINGLETON
2. Defina o parmetro DTP (-dtp) para o servio como TRUE (o valor padro FALSE).
Voc pode usar o Oracle Enterprise Manager ou o SRVCTL para modificar a
propriedade DTP do servio nico. O exemplo a seguir mostra como modificar o servio
xa_01.example.com usando o SRVCTL:
$ srvctl modify service -db crm -service xa_01.example.com -dtp
TRUE

Limites de Servios e Alertas

Os limites no nvel do servio permitem comparar os nveis de
servios alcanados com os nveis mnimos necessrios aceitveis.
Voc pode especificar explicitamente dois limites de desempenho
para cada servio:
SERVICE_ELAPSED_TIME: O tempo de resposta para as
chamadas
SERVICE_CPU_TIME: O tempo de CPU para as chamadas
Os limites no nvel do servio permitem comparar os nveis de servios alcanados com os

nveis mnimos necessrios aceitveis. Isso gera responsabilidade com relao ao
fornecimento ou falta de fornecimento de um nvel de servio predefinido. O objetivo final
um sistema previsvel que atinja os nveis de servio. No h requisito para apresentar o
desempenho mais rpido possvel com o mnimo de consumo de recursos; o requisito
atender qualidade de servio.
Voc pode especificar explicitamente dois limites de desempenho para cada servio: o tempo
de resposta para chamadas ou SERVICE_ELAPSED_TIME, e o tempo de CPU para
chamadas, ou SERVICE_CPU_TIME. O objetivo de tempo de resposta indica que o tempo
transcorrido no deve exceder um determinado valor, e o tempo de resposta representa o
horrio atual. O tempo de resposta uma medida fundamental que reflete todos os atrasos e
falhas que possam estar bloqueando a execuo da chamada para o usurio. O tempo de
resposta tambm pode indicar diferenas na capacidade dos ns de um banco de dados
Oracle RAC.
O tempo de servio e o tempo de CPU so calculados como a mdia de movimentao do
tempo de chamada transcorrido do servidor. O AWR monitora o tempo de servio e o tempo
de CPU e publica alertas quando o desempenho excede os limites. Voc poder responder a
esses alertas alterando a prioridade de um job, interrompendo processos sobrecarregados ou
reposicionando, expandindo, compactando, iniciando ou interrompendo um servio. Isso
permite manter a qualidade do servio, apesar das alteraes na demanda.
Limites de Servios e Alertas: Exemplo
EXECUTE DBMS_SERVER_ALERT.SET_THRESHOLD(
METRICS_ID => DBMS_SERVER_ALERT.ELAPSED_TIME_PER_CALL
, warning_operator => DBMS_SERVER_ALERT.OPERATOR_GE ,
warning_value => '500000' , critical_operator =>
DBMS_SERVER_ALERT.OPERATOR_GE
, critical_value => '750000'
, observation_period => 30
, consecutive_occurrences => 5
, instance_name => NULL
, object_type => DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE
, object_name => 'payroll');
Para verificar os limites do servio servall service, use o relatrio do AWR. necessrio
registrar a sada do relatrio durante vrios intervalos sucessivos durante os quais o sistema
esteja em execuo em nveis ideais. Por exemplo, suponha que, para um servidor de e-mail,
o relatrio do AWR seja executado todas as segundas-feiras durante os horrios de pico de
uso, entre 10h e 2h. O relatrio do AWR conteria o tempo de resposta, ou o tempo do BD, e o
tempo de consumo de CPU, ou o tempo de CPU, das chamadas para cada servio. O
relatrio do AWR tambm forneceria um detalhamento do trabalho efetuado, bem como dos
tempos de espera que esto contribuindo com os tempos de resposta.
Usando o DBMS_SERVER_ALERT, defina um limite de aviso para o servio payroll em 0,5
segundo, e um limite crtico para o servio de folha de pagamento em 0,75 segundo.
necessrio definir esses limites em todas as instncias em um banco de dados Oracle RAC.
possvel programar aes usando jobs do Enterprise Manager para alertas ou programar
aes para que ocorram de forma programtica quando o alerta recebido. Neste exemplo,
so adicionados limites para o servio servall e so definidos conforme mostrado no slide.
Verifique a configurao de limite usando a seguinte instruo SELECT:
SELECT metrics_name, instance_name, warning_value, critical_value,
observation_period FROM dba_thresholds;

Agregao de Servio e Rastreamento
As estatsticas so sempre agregadas pelo servio a fim de

medir cargas de trabalho para o ajuste de desempenho.
As estatsticas podem ser agregadas em nveis mais detalhados:
MODULE
ACTION
Combinao de SERVICE_NAME, MODULE, ACTION
O rastreamento pode ser feito em vrios nveis:
SERVICE_NAME
MODULE
ACTION
Combinao de SERVICE_NAME, MODULE, ACTION
til para sistemas de ajuste que utilizam sesses
compartilhadas.
Por default, estatsticas e eventos de espera importantes so coletados para o trabalho

atribudo a cada servio. Uma aplicao poder qualificar um servio mais detalhadamente
com os nomes MODULE e ACTION a fim de identificar as transaes importantes em um
servio. Isso permite que voc localize exatamente as transaes de desempenho
insatisfatrio para cargas de trabalho categorizadas. Isso especialmente importante para o
monitoramento de desempenho em sistemas que usam pools de conexes ou monitores do
processamento de transaes. Nesses sistemas, as sesses so compartilhadas, o que
dificulta a identificao dos responsveis por elas.
SERVICE_NAME, MODULE e ACTION so colunas reais em V$SESSION. SERVICE_NAME
definido automaticamente para o usurio durante o login. Os nomes para MODULE e ACTION
so definidos pela aplicao por meio do package PL/SQL DBMS_APPLICATION_INFO ou de
chamadas OCI especiais. MODULE deve ser definido com um nome reconhecvel pelo usurio
para o programa que est em execuo. Da mesma forma, o valor de ACTION deve ser
definido como uma ao ou tarefa especfica que o usurio esteja executando dentro de um
mdulo (por exemplo, cadastrando um novo cliente).
Outro aspecto dessa agregao de carga de trabalho o rastreamento por servio. O mtodo
tradicional de rastrear cada sesso produz arquivos de rastreamento com comandos SQL que
podem expandir as cargas de trabalho. Isso resulta em uma estratgia de localizao de erros
ou acertos para diagnosticar comandos SQL problemticos. Com os critrios fornecidos,
(SERVICE_NAME, MODULE ou ACTION) informaes de rastreamento especficas so
capturadas em um conjunto de arquivos de rastreamento e combinadas em um nico arquivo
de rastreamento de sada. Isso permite a produo de arquivos de rastreamento que contm
comandos SQL relevantes para determinada carga de trabalho que esteja sendo feita.
Pgina Top Services Performance
Na pgina Performance, voc pode acessar a pgina Top Consumers clicando no link Top
Consumers.
A pgina Top Consumers possui vrias tabs para exibir o banco de dados como uma imagem
de um sistema nico. A pgina com a tab Overview contm quatro grficos de setores
circulares: Top Clients, Top Services, Top Modules e Top Actions. Cada grfico apresenta
uma perspectiva diferente dos principais consumidores de recursos do banco de dados.
A pgina com a tab Top Services exibe as informaes relacionadas ao desempenho dos
servios definidos no banco de dados. Nessa pgina, voc pode ativar ou desativar o
rastreamento no nvel de servio, bem como verificar o arquivo de rastreamento SQL
resultante.

Configurao da Agregao de Servios
Nvel de agregao automtica de servios de estatsticas

DBMS_MONITOR usado para proporcionar uma
granularidade mais detalhada das agregaes de servios:
SERV_MOD_ACT_STAT_ENABLE
SERV_MOD_ACT_STAT_DISABLE
Possveis nveis de agregao adicionais:
SERVICE_NAME/MODULE
SERVICE_NAME/MODULE/ACTION
Rastreando servios, mdulos e aes:
SERV_MOD_ACT_TRACE_ENABLE
SERV_MOD_ACT_TRACE_DISABLE
As definies do banco de dados persistem em
reinicializaes de instncias.
Em cada instncia, estatsticas e eventos de espera importantes so agregados e coletados

automaticamente pelo servio. Como essa configurao automtica, voc s precisa utilizar
diferentes strings de conexo ao estabelecer conexo com os servios desejados. No
entanto, para obter um nvel de granularidade mais detalhado das estatsticas coletadas para
os servios, voc deve usar o procedure SERV_MOD_ACT_STAT_ENABLE no package
DBMS_MONITOR. Esse procedure permite coletar estatsticas para possibilitar outras
combinaes hierrquicas entre SERVICE_NAME/MODULE e
SERVICE_NAME/MODULE/ACTION. O procedure SERV_MOD_ACT_STAT_DISABLE
interrompe a coleta de estatsticas que havia sido ativada.
A ativao e a desativao da agregao de estatsticas em um servio so aplicadas a
todas as instncias que acessam o banco de dados. Essas definies so persistentes nas
reinicializaes das instncias.
O procedure SERV_MOD_ACT_TRACE_ENABLE permite o rastreamento de servios com trs
possibilidades hierrquicas: SERVICE_NAME, SERVICE_NAME/MODULE e
SERVICE_NAME/MODULE/ACTION. O default rastrear todas as instncias que acessam o
banco de dados. fornecido um parmetro que restringe o rastreamento a instncias
especficas onde conhecida a existncia de desempenho insatisfatrio. Esse procedure
tambm oferece a opo de capturar esperas relevantes e valores de varivel de bind nos
arquivos de rastreamento gerados. O procedure SERV_MOD_ACT_TRACE_DISABLE desativa
o rastreamento em todas as instncias habilitadas para determinadas combinaes de
servio, mdulo e ao. Da mesma forma que a coleta de estatsticas mencionada
anteriormente, o rastreamento de servios persiste durante as reinicializaes das instncias.
Monitoramento de Servios, Mdulos e Aes
Para o servio ERP, habilite o monitoramento para a ao

de pagamento de excees no mdulo PAYROLL.
EXEC DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(
service_name => 'ERP', module_name=> 'PAYROLL',
action_name => 'EXCEPTIONS PAY')
Para o servio ERP, habilite o monitoramento para todas

as aes no mdulo PAYROLL:
EXEC DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name =>
'ERP', module_name=> 'PAYROLL', action_name => NULL);
Para o servio HOT_BATCH, habilite o monitoramento para

todas as aes no mdulo POSTING:
EXEC DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name =>
'HOT_BATCH', module_name =>'POSTING', action_name => NULL);
possvel habilitar o rastreamento de dados de desempenho para mdulos e aes

importantes em cada servio. As estatsticas de desempenho esto disponveis na view
V$SERV_MOD_ACT_STATS. Considere as seguintes aes, conforme implementadas no
slide:
Para o servio ERP, habilite o monitoramento para a ao de pagamento de excees
no mdulo.
No servio ERP, habilite o monitoramento para todas as aes no mdulo de folha de
pagamento.
No servio HOT_BATCH, habilite o monitoramento para todas as aes no mdulo de
contabilizao.
Verifique a configurao do servio, do mdulo, e da ao habilitados com a seguinte
instruo SELECT:
COLUMN AGGREGATION_TYPE FORMAT A21 TRUNCATED HEADING 'AGGREGATION'
COLUMN PRIMARY_ID FORMAT A20 TRUNCATED HEADING 'SERVICE'
COLUMN QUALIFIER_ID1 FORMAT A20 TRUNCATED HEADING 'MODULE'
COLUMN QUALIFIER_ID2 FORMAT A20 TRUNCATED HEADING 'ACTION'
SELECT * FROM DBA_ENABLED_AGGREGATIONS ;

A sada poder ter a seguinte aparncia:
AGGREGATION SERVICE MODULE ACTION
--------------------- -------------------- ---------- -------------
SERVICE_MODULE_ACTION ERP PAYROLL EXCEPTIONS
PAY
SERVICE_MODULE_ACTION ERP PAYROLL
SERVICE_MODULE_ACTION HOT_BATCH POSTING
O seguinte script de amostra do SQL*Plus fornece estatsticas de qualidade do servio
durante um intervalo de cinco segundos. Voc pode usar essas estatsticas de qualidade do
servio para monitorar a qualidade de um servio, direcionar o trabalho e balancear servios
em todas as instncias do Oracle RAC:
SET PAGESIZE 60 COLSEP '|' NUMWIDTH 8 LINESIZE 132 VERIFY OFF FEEDBACK OFF
COLUMN service_name FORMAT A20 TRUNCATED HEADING 'Service'
COLUMN begin_time HEADING 'Begin Time' FORMAT A10
COLUMN end_time HEADING 'End Time' FORMAT A10
COLUMN instance_name HEADING 'Instance' FORMAT A10
COLUMN service_time HEADING 'Service Time|mSec/Call' FORMAT 999999999
COLUMN throughput HEADING 'Calls/sec'FORMAT 99.99
BREAK ON service_name SKIP 1
SELECT
service_name
, TO_CHAR(begin_time, 'HH:MI:SS') begin_time , TO_CHAR(end_time, 'HH:MI:SS')
end_time
, instance_name
, elapsedpercall service_time
, callspersec throughput
FROM
gv$instance i , gv$active_services s
, gv$servicemetric m WHERE s.inst_id = m.inst_id AND s.name_hash =
m.service_name_hash AND i.inst_id = m.inst_id AND m.group_id = 10 ORDER BY
service_name , i.inst_id , begin_time ;
| | | |Service Time|
Service |Begin Time|End Time |Instance Sec/Call|Calls/sec
--------------------|----------|----------|-----------------|---------
BATCH.cluster01.exam|06:52:38 |06:52:43 |orcl_1 | 117| .90
ERP.cluster01.exampl|06:52:38 |06:52:43 |orcl_1 | 21| 2.00

|07:16:39 |07:16:44 |orcl_3 | 6| .90
SYS$BACKGROUND |06:52:38 |06:52:43 |orcl_1 | 655| .80

|07:16:39 |07:16:44 |orcl_3 | 782| .80
SYS$USERS |06:52:38 |06:52:43 |orcl_1 | 420| 2.20

|07:16:39 |07:16:44 |orcl_3 | 761| .60
orcl.cluster01.examp|06:52:38 |06:52:43 |orcl_1 | 0| .00

|07:16:39 |07:16:44 |orcl_3 | 0| .00
orclXDB |06:52:38 |06:52:43 |orcl_1 | 0| .00

|07:16:39 |07:16:44 |orcl_3 | 0| .00

Views de Desempenho dos Servios
Informaes sobre servio, mdulo e ao em:

V$SESSION
V$ACTIVE_SESSION_HISTORY
Desempenho do servio em:
V$SERVICE_STATS
V$SERVICE_EVENT
V$SERVICE_WAIT_CLASS
V$SERVICEMETRIC
V$SERVICEMETRIC_HISTORY
V$SERV_MOD_ACT_STATS
DBA_ENABLED_AGGREGATIONS
DBA_ENABLED_TRACES
As informaes sobre servio, mdulo e ao podem ser vistas em V$SESSION e

V$ACTIVE_SESSION_HISTORY.
Os tempos das chamadas e as estatsticas de desempenho podem ser vistos em
V$SERVICE_STATS, V$SERVICE_EVENT, V$SERVICE_WAIT_CLASS, V$SERVICEMETRIC
e V$SERVICEMETRIC_HISTORY.
Quando a coleta de estatstica para determinados mdulos e aes estiver ativada, as
medidas de desempenho de cada instncia podero ser vistas em
V$SERV_MOD_ACT_STATS.
Existem mais de 600 estatsticas relacionadas a desempenho que so rastreadas e esto
visveis em V$SYSSTAT. Dessas, 28 estatsticas so rastreadas para servios. Para ver as
estatsticas medidas para servios, execute a seguinte consulta: SELECT DISTINCT
stat_name FROM v$service_stats
Das 28 estatsticas, vale a pena mencionar DB time e DB CPU. DB time uma estatstica
que mede o tempo mdio de resposta por chamada. Ela representa o tempo decorrido para
que uma chamada seja concluda. DB CPU uma mdia do tempo de CPU necessrio por
chamada. A diferena entre o tempo de resposta e o tempo de CPU o tempo de espera do
servio. Depois que o tempo de espera for conhecido, e se ele consumir um grande
percentual do tempo de resposta, voc poder fazer um rastreamento no nvel da ao para
identificar as esperas.
Observao: DBA_ENABLED_AGGREGATIONS exibe informaes sobre a agregao de
estatsticas ativadas de acordo com as necessidades. DBA_ENABLED_TRACES exibe
informaes sobre os rastreamentos ativados no sistema.
Questionrio
Qual das seguintes afirmaes sobre o Oracle Services no

correta?
a. Voc pode trabalhar em grupo por tipo de servios.
b. Os usurios que compartilham um servio devem ter os
mesmos requisitos de nvel de servio.
c. Use DBMS_SERVICE para gerenciar servios, no o
srvctl nem o Enterprise Manager.
Resposta: c

Questionrio
A instruo a seguir, relativa aos limites de desempenho,

verdadeira ou falsa? Os dois limites de desempenho que
podem ser definidos de forma explcita para cada servio so:
(a) SERVICE_ELAPSED_TIME: O tempo de resposta para
chamadas
(b) SERVICE_CPU_TIME: O tempo de CPU para as chamadas
a. Verdadeiro
b. Falso
Resposta: a

Sumrio

Configurar e gerenciar servios em um ambiente RAC
Usar servios com aplicaes clientes
Usar servios com o Database Resource Manager
Usar servios com o Scheduler
Definir limites mtricos de desempenho para os servios
Configurar a agregao e o rastreamento de servios


Criao e gerenciamento de servios com o EM
Uso de alertas gerados pelo servidor juntamente
com servios

e Aplicativos
Alta Disponibilidade para Conexes
Parte I

Alta Disponibilidade de Conexes
Objetivos

Configurar o balanceamento de carga por tempo de
conexo do cliente
Configurar o failover por tempo de conexo do cliente
conexo do servidor
Usar o LBA (Load Balancing Advisory)
Descrever as vantagens do recurso FAN (Fast Application
Notification)
Configurar callouts do servidor
Configurar o ONS no cliente e no servidor
Configurar o TAF (Transparent Application Failover)

Tipos de Distribuio de Carga de Trabalho
O balanceamento de conexes possvel por meio da

configurao de vrios listeners em diversos ns:
Balanceamento de carga por tempo de conexo do cliente
Failover por tempo de conexo do cliente
Balanceamento de carga por tempo de conexo do servidor
O balanceamento de carga durante a conexo de runtime
possvel por meio de pools de conexes:
As solicitaes de trabalho so balanceadas
automaticamente entre o pool de conexes
Recurso nativo do Oracle UCP (Universal Connection Pool)
para Java e o pool de conexes ODP.NET
Com o ambiente RAC, possvel configurar vrios listeners em diversos ns para tratar as
solicitaes de conexes dos clientes do mesmo servio de banco de dados.
Uma configurao com vrios listeners permite aproveitar os seguintes recursos de failover e
de balanceamento de carga:
Balanceamento de carga por tempo de conexo do cliente
Failover por tempo de conexo do cliente
Balanceamento de carga por tempo de conexo do servidor
Voc pode implementar esses recursos individualmente ou em conjunto.
Alm disso, se estiver usando pools de conexes, voc poder aproveitar o balanceamento
de carga prontamente disponvel durante a conexo de runtime para distribuir as solicitaes
de trabalho dos clientes entre o pool de conexes estabelecidas pelo middle-tier. Isso
possvel por meio do recurso Oracle UCP (Universal Connection Pool) for Java bem como do
pool de conexes do Oracle ODP.NET (Oracle Data Provider for .NET).
Observao: a partir do Oracle Database 11g Release 1 (11.1.0.7), a Oracle lanou o novo
Universal Connection Pool for JDBC. Consequentemente, o pool de conexes JDBC
existente (ou seja, o Implicit Connection Cache) introduzido no Oracle Database 10g Release
1 tornou-se obsoleto.

Balanceamento de Carga por

Tempo de Conexo do Cliente
O balanceamento de carga do cliente definido em tnsnames.ora
pela definio do parmetro LOAD_BALANCE=ON.
Ao ser definido, o Oracle Database seleciona aleatoriamente um endereo
na lista de endereos, e se conecta ao listener desse n.
As conexes de clientes so balanceadas em todos os listeners disponveis
do SCAN no cluster.
ERP =
(DESCRIPTION =
(ADDRESS_LIST =
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=node1vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node2vip)(PORT=1521))
)
Se o SCAN for configurado, ento o balanceamento de carga do cliente

no relevante para os clientes que suportem o acesso ao SCAN.
Se o SCAN for usado, as conexes sero balanceadas em todos os
trs endereos IP definidos para SCAN, a menos que voc esteja
usando o EZConnect.
O balanceamento de carga do cliente definido na sua definio de conexo do cliente

(arquivo tnsnames.ora, por exemplo) atravs da configurao do parmetro
LOAD_BALANCE=ON. Quando voc define este parmetro como ON, o Oracle Database
seleciona aleatoriamente um endereo na lista de endereos, e se conecta ao listener desse
n. Isto balanceia as conexes de clientes em todos os listeners disponveis do SCAN no
cluster.
Se voc configurou o SCAN para solicitaes de conexes, o balanceamento de carga do
cliente no relevante para esses clientes que suportem o acesso do SCAN. Quando os
clientes se conectam usando o SCAN, o Oracle Net automaticamente balanceia a carga das
solicitaes de conexes de clientes em todos os trs endereos de IP definidos para o
SCAN, a menos que voc esteja usando o EZConnect.
O listener do SCAN redireciona a solicitao de conexo para o listener local da instncia
que estiver menos carregada (se -clbgoal estiver definido como SHORT) e fornece o
servio solicitado. Quando o listener recebe a solicitao de conexo, conecta o usurio a
uma instncia que o listener sabe que fornece o servio solicitado. Para ver quais servios
um listener aceita, execute o comando lsnrctl services.
Quando os clientes se conectam usando o SCAN, o Oracle Net automaticamente balanceia a
carga das solicitaes de conexes de clientes em todos os trs endereos de IP definidos
para o SCAN, a menos que voc esteja usando o EZConnect.

Recurso FAN (Fast Application Notification):

Viso Geral
O FAN usado pelo RAC para notificar outros processos sobre
informaes de configurao e de nvel de servio.
Isto inclui alteraes no status do servio como eventos UP ou DOWN.
Os eventos UP e DOWN podem ser aplicados a instncias, servios e ns.
Os drivers de clientes Oracle e os pools de conexo Oracle
respondem a eventos FAN e agem com base nisso
imediatamente.
Os pools de conexo Oracle usam o FAN para:
Detectar falhas rapidamente
Balancear conexes depois de falhas
Balancear conexes aps os componentes com falha serem
reparados
O uso de eventos FAN elimina:
Aplicaes aguardando timeouts de TCP
Tempo desperdiado no processamento do ltimo resultado do
cliente aps a ocorrncia de uma falha
O FAN um mecanismo de notificao de alta disponibilidade que o Oracle RAC usa para
notificar outros processos sobre informaes de configurao e nvel de servios que incluam
alteraes no status de servios, como eventos UP ou DOWN. Os drivers de clientes Oracle e os
pools de conexo Oracle respondem a eventos FAN e agem com base nisso imediatamente.
Os eventos FAN UP e DOWN podem ser aplicados a instncias, servios e ns.
Os pools de conexo Oracle, por exemplo, usam o FAN para receber a deteco bem rpida
de falhas, para balancear as conexes seguintes a falhas, e para balancear as conexes
novamente, aps os componentes com falha serem reparados. Portanto, quando um servio
iniciar em uma instncia, o evento FAN usado imediatamente para rotear o trabalho para
esse recurso. Quando um servio falha em uma instncia ou n, o evento FAN usado
imediatamente para interromper as aplicaes para a sua recuperao.
O uso de eventos FAN elimina a espera dos aplicativos por timeouts de TCP, tempo gasto
processando o ltimo resultado no cliente aps a ocorrncia de uma falha, e o tempo gasto
executando trabalho em ns lentos, suspensos ou inativos. Nas alteraes de configurao de
clusters, o framework de alta disponibilidade do Oracle RAC publica um evento FAN
imediatamente, quando ocorre uma alterao de estado no cluster. Em vez de aguardar que a
aplicao efetue o timeout no banco de dados e detecte um problema, as aplicaes podem
receber eventos FAN e reagir imediatamente. Com o FAN, as transaes em execuo so
imediatamente encerrradas e o cliente, notificado quando a instncia falha.
O FAN tambm publica eventos load balancing advisory. As aplicaes podem tirar partido dos
eventos FAN load balancing advisory para direcionarem solicitaes de trabalho para a
instncia no cluster que esteja atualmente fornecendo a melhor qualidade do servio.
Recurso FAN (Fast Application Notification):

Vantagens
As conexes no precisam depender de timeouts
Usado pelo Load Balancing Advisory para propagar
informaes sobre carga
Projetado para integrao entre aplicaes empresariais e
consoles de gerenciamento
Sistema distribudo confivel que:
Detecta prontamente as ocorrncias de eventos de alta
disponibilidade
Envia a notificao diretamente para as aplicaes
Totalmente integrado com:
Aplicaes Oracle JDBC que usam pools de conexes
Pool de conexes ODP.NET, pool de sesses OCI
Oracle WebLogic Server Active Gridlink para Oracle RAC
Tradicionalmente, as aplicaes cliente ou mid-tier conectadas com o banco de dados

dependiam de timeouts de conexes, de mecanismos de polling fora de faixa ou de outras
solues personalizadas para perceber que havia ocorrido uma falha em um componente do
sistema. Essa estratgia tem implicaes importantes na disponibilidade de aplicaes
porque os perodos de indisponibilidade so mais longos e evidentes.
Com a FAN, os eventos importantes de alta disponibilidade so enviados assim que so
detectados, o que resulta em um uso mais eficiente dos recursos de computao existentes e
em melhor integrao com as aplicaes empresariais, incluindo gerenciadores de conexes
de mid-tier ou consoles de gerenciamento de TI, como loggers de tickets de problemas e
servidores de correio e pagers.
A FAN , na verdade, um sistema distribudo habilitado em cada n participante. Isso o torna
muito confivel e tolerante a falhas, pois a falha de um componente detectada por outro.
Portanto, qualquer n participante pode detectar e emitir a notificao de evento.
Os eventos FAN so fortemente integrados ao Oracle JDBC Universal Connection Pool, pool
de conexes ODP.NET, pool de sesses OCI, Oracle WebLogic Server Active Gridlink para
Oracle RAC e clientes OCI e ODP.NET. Isto inclui as aplicaes que utilizam Application
Continuity ou Transaction Guard. Por exemplo, as aplicaes Oracle JDBC que gerenciam
pools de conexes no precisam do desenvolvimento de um cdigo personalizado. Elas
sero integradas automaticamente com o ONS se o cache de conexes implcitas e o failover
de conexo rpida estiverem ativados.

Implementando Eventos FAN
Voc pode tirar partido dos eventos FAN nas seguintes formas:
Sua aplicao pode usar FAN sem alteraes
programticas se voc usar um cliente Oracle integrado:
Oracle JDBC Universal Connection Pool (UCP)
Pool de conexes do ODP.NET
Oracle WebLogic Server Active Gridlink para Oracle RAC
Clientes OCI e ODP.NET
Aplicaes que podem usar o FAN de forma programtica:
Utilizando o JDBC e RAC FAN API
utilizando callbacks com OCI e ODP.NET para se inscrever
em eventos FAN
Voc pode implementar o FAN com callouts do servidor na
sua camada do banco de dados.
Voc pode tirar partido dos eventos FAN nas seguintes formas:
1. Sua aplicao pode usar FAN sem alteraes programticas se voc usar um cliente
Oracle integrado. Os clientes integrados aos eventos FAN incluem o Oracle JDBC
Universal Connection Pool, pool de conexes ODP.NET, pool de sesses OCI, Oracle
WebLogic Server Active Gridlink para Oracle RAC e clientes OCI e ODP.NET. Isto inclui
as aplicaes que utilizam Application Continuity ou Transaction Guard. Os clientes Oracle
integrados devem ser Oracle Database 10g release 2 ou posterior, a fim de tirar proveito
dos eventos de alta disponibilidade do FAN. Os clientes agrupados tambm podem tirar
proveito dos eventos FAN do load balancing advisory.
2. As aplicaes podem usar o FAN de maneira programtica, usando o JDBC e a API
(application programming interface) Oracle RAC FAN ou, ainda, utilizando callbacks com
OCI e ODP.NET para se inscrever em eventos FAN e executar aes de tratamento de
eventos aps o recebimento de um evento.
3. Voc pode implementar o FAN com callouts do servidor na sua camada do banco de
dados. Se voc usar um dos clientes integrados relacionados no item 1 da lista anterior,
ento, para os eventos DOWN, a interrupo na aplicao minimizada j que o cliente
que reconhece o FAN encerra as sesses na instncia ou no n com falha, antes de elas
serem reutilizadas. As transaes incompletas so encerradas e o usurio da aplicao
notificado imediatamente. Os usurios de aplicaes que solicitarem conexes so
direcionados para instncias disponveis somente.
Em eventos UP quando servios e instncias so iniciados, so criadas novas conexes de
forma que a aplicao possa rapidamente tirar partido dos recursos extras de hardware ou da
capacidade adicional.
FAN e Clientes Oracle Integrados

Aplic. .NET Aplic. C Aplic. C Aplic. Java Aplic. Java
ODP.NET API para API do ONS API do ONS JDBC

OCI para OCI para Java
ONS ONS
AQ*
HA
Aplic. de Eventos
ONS
proxy
HA HA
Script de CRS EMD EM CC
Eventos Eventos
callout
Exec de
callout Eventos de HA
N1
* Os streams so continuados para a compatibilidade

retroativa com releases anteriores do Oracle Database.
A FAN (Fast Application Notification) permite uma recuperao rpida ponto-a-ponto de

aplicaes e balanceamento de carga com base no desempenho de transaes reais em um
ambiente RAC. As aplicaes usam os eventos HA (de alta disponibilidade) FAN para obter a
deteco muito rpida das falhas, balanceamento dos pools de conexes seguintes a falhas
e distribuio das conexes novamente, quando os componentes com falha so reparados.
Os eventos FAN que trazem dicas sobre o balanceamento de carga ajudam os pools de
conexo a entregar, de forma consistente, conexes a instncias disponveis que forneam o
melhor servio. O FAN HA se integra a:
JDBC-thin
Drivers OCI
JDBC Universal Connection Pool (e o obsoleto Implicit Connection Cache)
Pool de sesses da OCI
Pool de conexes do ODP.NET e
Oracle WebLogic Server Active Gridlink para Oracle RAC.
Por causa da integrao FAN, os clientes integrados esto mais a par do status atual de
um cluster RAC. Isto impede que as conexes de clientes esperem ou tentem se conectar a
instncias ou servios que no estejam mais disponveis. Quando as instncias iniciam, o
Oracle RAC usa a FAN para notificar o pool de conexes para que ele possa criar conexes
instncia recm-iniciada e tire partido dos recursos adicionais que essa instncia fornece.
Os drivers de cliente Oracle que so integrados FAN podem:

Remover conexes encerradas imediatamente quando um servio for declarado DOWN
em uma instncia, e imediatamente quando os ns forem declarados DOWN
Relatar erros a clientes, imediatamente, quando o Oracle Database detectar o estado
NOT RESTARTING, em vez de fazer com que o cliente aguarde enquanto o servio
tenta, reiteradamente, reiniciar
Os pools de conexo Oracle que so integrados FAN podem:
Balancear as conexes em todas as instncias Oracle RAC quando um servio
iniciado; isto prefervel a direcionar as sesses que so definidas para o pool de
conexes primeira instncia Oracle RAC que suporta o servio
Balancear as solicitaes de trabalho durante o runtime que utilizem eventos load
balancing advisory
O uso de drivers de clientes ou pools de conexes e FAN requer que voc configure da
forma apropriada o Oracle Notification Service para entregar os eventos FAN aos clientes.
Alm disso, para o balanceamento de carga, configure o balanceamento de carga das
conexes do banco de dados em todas as instncias que fornecerem os servios usados
pelo pool de conexes. A Oracle recomenda que voc configure igualmente o
balanceamento de carga no cliente e no servidor com o Oracle Net Services. Se voc usar o
DBCA para criar seu banco de dados, ento tanto o balanceamento de carga no cliente como
no servidor so configurados por padro.
Observao: Conforme indicado no grfico do slide, os eventos FAN so publicados com o
uso de ONS Service e Oracle Streams, sendo que o ltimo mantm a continuidade para a
compatibilidade retroativa com as releases anteriores do Oracle Database.

Tipos de Eventos Suportados pela FAN
Tipo de evento Descrio

SERVICE Servio de aplicao principal
SRV_PRECONNECT Evento de servio de aplicao-espelho
(camadas intermedirias e TAF que usam uma
instncia principal e uma instncia secundria)
SERVICEMEMBER Servio de aplicao em uma instncia especfica
DATABASE Banco de dados Oracle
INSTANCE Instncia do Oracle
ASM Instncia do Oracle ASM
NODE N de cluster Oracle
SERVICEMETRICS Load Balancing Advisory
A FAN distribui eventos que pertencem lista de recursos gerenciados do cluster mostrada
no slide. A tabela descreve cada um dos recursos.
Observao: SRV_PRECONNECT e SERVICEMETRICS sero abordados posteriormente
nesta lio.

Motivos para Eventos FAN

Motivo do Evento Descrio
USER Comandos iniciados pelo usurio, como srvctl e sqlplus
FAILURE Deteco de falha durante as verificaes do polling do recurso
gerenciado
DEPENDENCY Dependncia de outro recurso gerenciado que disparou uma
condio de falha
UNKNOWN Estado da aplicao desconhecido ou interno quando o
evento disparado
AUTOSTART Primeira inicializao do cluster: O recurso gerenciado tem o
atributo de perfil AUTO_START=1 e estava off-line antes do
ltimo shutdown do Oracle Clusterware.
BOOT Primeira inicializao do cluster: O recurso gerenciado estava
em execuo antes do ltimo shutdown do Oracle Clusterware.
PUBLIC_NW_DOWN O n est ativo, mas a inatividade da rede impede a
conectividade.
MEMBER_LEAVE Um n falhou e no faz mais parte do cluster.
O status do evento de cada recurso gerenciado associado a um motivo. O motivo descreve

com detalhes o que disparou o evento. A tabela do slide mostra uma lista de possveis
motivos com uma descrio correspondente.

Status de Eventos FAN
Status de eventos Descrio

Recurso gerenciado est ativado.
UP
DOWN Recurso gerenciado est desativado.
PRECONN_UP Servio de aplicao-espelho est ativado.
PRECONN_DOWN Servio de aplicao-espelho est desativado.
NODEDOWN N gerenciado est desativado.
NOT_RESTARTING No possvel fazer o failover do recurso

gerenciado para um n remoto.
UNKNOWN Status no reconhecido.
Esta tabela descreve o status dos eventos de cada um dos recursos gerenciados do cluster
mostrados anteriormente.

Formato de Eventos FAN
<Event_Type>
VERSION=<n.n>
[service=<serviceName.dbDomainName>]
[database=<dbName>] [instance=<sid>]
[host=<hostname>]
status=<Event_Status>
reason=<Event_Reason>
[card=<n>]
timestamp=<eventDate> <eventTime>
SERVICE VERSION=1.0 service=ERP.example.com

database=ORCL status=up reason=user card=4
timestamp=16-Jul-2013 13:21:11
NODE VERSION=1.0 host=host01

status=nodedown timestamp=16-Jul-2013 11:42:05
Alm do tipo, status e motivo, um evento FAN tem outros campos de payload que descrevem
com detalhes o recurso do cluster cujo status est sendo monitorado e publicado:
A verso do payload do evento
O nome do servio principal ou de aplicao-espelho. Esse nome excludo dos
eventos NODE.
O nome do banco de dados RAC, que tambm excludo dos eventos NODE.
O nome da instncia do RAC, que excludo dos eventos SERVICE, DATABASE e
NODE.
O nome da mquina host do cluster, que excludo dos eventos SERVICE e
DATABASE.
A cardinalidade do servio, que excluda de todos os eventos, exceto de SERVICE
STATUS=UP.
A data e o horrio do servidor em que o evento foi detectado
O formato geral dos eventos FAN descrito no slide juntamente com exemplos de possveis
eventos FAN. Observe as diferenas de payload para cada tipo de evento FAN.

Load Balancing Advisory: Evento FAN
Parmetro Descrio
VERSION Verso de payload do evento
EVENT_TYPE SERVICEMETRICS
SERVICE Corresponde a DBA_SERVICES
DATABASE Nome exclusivo do BD que suporta o servio
TIMESTAMP Data e timestamp (fuso horrio local)
INSTANCE Nome da instncia que suporta o servio
PERCENT Percentual de trabalho a ser enviado para este banco de
dados e esta instncia
FLAG GOOD, VIOLATING, NO DATA, BLOCKED
O evento FAN do Load Balancing Advisory descrito no slide. Ele contm basicamente um
percentual calculado das solicitaes de trabalho que devem ser enviadas a cada instncia.
O flag indica o comportamento do servio na instncia correspondente em relao aos limites
definidos nessa instncia para o servio. A forma mais fcil de tirar partido desses eventos
usar o recurso de balanceamento de carga de conexo em runtime de um cliente integrado
Oracle, como JDBC, Universal Connection Pool, Pools de Conexo ODP.NET, pools de
sesso OCI ou Oracle WebLogic Server Active GridLink para Oracle RAC. Outras aplicaes
clientes podem tirar proveito da FAN de forma programtica usando a API Oracle RAC FAN
para se inscrever em eventos FAN e executar aes de tratamento de eventos, no
recebimento. Este um exemplo:
Notification Type: database/event/servicemetrics/prod
VERSION=1.0 database=PROD service=myServ { {instance=PROD2
percent=38 flag=GOOD aff=TRUE}{instance=PROD3 percent=62 flag=GOOD
aff=TRUE} } timestamp=2013-07-30 08:47:06
Observao: as aplicaes usando o Oracle Database 11g ou posterior e o UCP podem tirar
proveito do recurso de afinidade. Se o flag de afinidade for ativado no evento Load Balancing
Advisory, o UCP criar um Contexto de Afinidade para a sesso da Web, como ocorre
quando a sesso no obtm uma conexo a partir do pool. Nesse caso, o pool sempre tenta
fornecer uma conexo com a instncia qual se conectou na primeira vez que adquiriu uma
sesso. A escolha da instncia para a primeira conexo se baseia nas informaes atuais do
Load Balancing Advisory. A dica de afinidade automtica quando o Load Balancing
Advisory ativado por meio da definio do objetivo do servio.
Implementao de Callouts do Servidor
O diretrio de callouts:
<Grid Home>/racg/usrco
Pode armazenar mais de um callout
Concede permisso de execuo no diretrio de callouts e
nos callouts apenas para o usurio Oracle Clusterware
A ordem de execuo dos callouts no determinante.
A criao de callouts envolve:
1. Parse dos argumentos do callout: O payload do evento
2. Filtragem dos eventos FAN recebidos
3. Execuo de programas de tratamento de eventos
Cada evento de banco de dados detectado pelo framework de HA (High Availability) do RAC
resulta na execuo dos scripts ou programas executveis disponibilizados no diretrio-padro
de callouts do Oracle Clusterware. No UNIX, esse diretrio o <Grid Home>/racg/usrco A
menos que o diretrio home do Oracle Clusterware seja compartilhado pela rede, disponibilize
cada novo callout para todos os ns do ambiente RAC. A ordem na qual esses callouts so
executados no determinante. No entanto, o ambiente RAC garante que todos os callouts
sejam chamados de forma assncrona uma vez para cada evento reconhecido. Portanto,
agrupe os callouts cujas execues devam ocorrer em uma ordem especfica.
Voc pode instalar quantos programas ou scripts de callout forem necessrios para os seus
negcios, desde que os callouts no gerem operaes de alto custo que atrasem a
propagao de eventos de HA. Se forem criados vrios callouts para a execuo de diferentes
operaes baseadas no evento recebido, talvez seja mais eficiente criar um nico programa de
callout que agrupe todos os callouts.
A criao de callouts do servidor envolve as etapas mostradas no slide. Para que identifique
um evento, o callout precisa fazer o parse do payload do evento enviado pelo framework de
HA do ambiente RAC ao callout. Depois que o evento enviado for identificado, o callout poder
filtr-lo para evitar a execuo em cada notificao de evento. Em seguida, o callout dever
implementar um handler de eventos correspondente, que depender do prprio evento e do
processo de recuperao necessrio aos seus negcios.
Observao: como medida de segurana, certifique-se de que apenas o usurio do sistema
que instalou o Oracle Clusterware tenha permisses de gravao no diretrio de callouts e nos
callouts contidos nesse diretrio.
Parse de Callouts do Servidor: Exemplo
#!/bin/sh
NOTIFY_EVENTTYPE=$1
for ARGS in $*; do
PROPERTY=`echo $ARGS | $AWK -F"=" '{print $1}'`
VALUE=`echo $ARGS | $AWK -F"=" '{print $2}'`
case $PROPERTY in
VERSION|version) NOTIFY_VERSION=$VALUE ;;
SERVICE|service) NOTIFY_SERVICE=$VALUE ;;
DATABASE|database) NOTIFY_DATABASE=$VALUE ;;
INSTANCE|instance) NOTIFY_INSTANCE=$VALUE ;;
HOST|host) NOTIFY_HOST=$VALUE ;;
STATUS|status) NOTIFY_STATUS=$VALUE ;;
REASON|reason) NOTIFY_REASON=$VALUE ;;
CARD|card) NOTIFY_CARDINALITY=$VALUE ;;
TIMESTAMP|timestamp) NOTIFY_LOGDATE=$VALUE ;;
??:??:??) NOTIFY_LOGTIME=$PROPERTY ;;
esac
done
A menos que voc queira executar os callouts a cada notificao de evento, identifique
primeiro os parmetros dos eventos que so transmitidos automaticamente para o callout
durante sua execuo. O exemplo do slide mostra como efetuar parse desses argumentos
usando uma amostra de script Bourne shell.
O primeiro argumento transmitido para o callout o tipo de evento detectado. Depois,
dependendo do tipo de evento, transmitido um conjunto de strings PROPERTY=VALUE para
identificar exatamente o evento.
O script do slide identifica o tipo de evento e cada par de strings PROPERTY=VALUE. Os
dados so ento enviados em um conjunto de variveis que podem ser usadas
posteriormente no callout para filtragem.
Como mencionado no slide anterior, talvez seja aconselhvel que um nico callout faa
parse do payload do evento e, em seguida, execute uma funo ou outro programa com base
nas informaes do evento, em vez de filtrar as informaes de cada callout. Essa ao s
necessria quando preciso usar vrios callouts.
Observao: verifique se as permisses de executvel esto definidas corretamente no
script de callout.

Filtro de Callout do Servidor: Exemplo
if ((( [ $NOTIFY_EVENTTYPE = "SERVICE" ] ||

[ $NOTIFY_EVENTTYPE = "DATABASE" ] || \
[ $NOTIFY_EVENTTYPE = "NODE" ] \
) && \
( [ $NOTIFY_STATUS = "not_restarting" ] || \
[ $NOTIFY_STATUS = "restart_failed" ] \
)) && \
( [ $NOTIFY_DATABASE = "HQPROD" ] || \
[ $NOTIFY_SERVICE = "ERP" ] \
))
then
/usr/local/bin/logTicket $NOTIFY_LOGDATE \
$NOTIFY_LOGTIME \
$NOTIFY_SERVICE \
$NOTIFY_DBNAME \
$NOTIFY_HOST
fi
O exemplo do slide mostra uma forma de filtrar eventos FAN utilizando um script de callout.
Esse exemplo baseado no exemplo do slide anterior.
Agora que as caractersticas do evento esto identificadas, esse script dispara a execuo do
programa de log de problemas /usr/local/bin/logTicket somente quando o
framework de HA do RAC publica um tipo de evento SERVICE, DATABASE ou NODE, com um
status definido como not_restarting ou restart_failed, e somente para o banco de
dados HQPROD RAC de produo ou para o servio ERP.
.Supe-se que o programa logTicket j tenha sido criado e que ele use os argumentos
mostrados no slide.
Supe-se tambm que s seja registrado um ticket para os eventos not_restarting ou
restart_failed, pois eles so os nicos que excederam os timeouts monitorados
internamente e que necessitam muito de interveno humana para que uma resoluo
completa seja obtida.

ONS do servidor
usesharedinstall=true
allowgroup=true
localport=6100 # line added by Agent
remoteport=6200 # line added by Agent
nodes=host01:6200 # line added by Agent
ONS ONS
OCR
ons.config ons.config
N1 N2
O arquivo de configurao <GRID_HOME>/opmn/conf/ons.config controla a configurao do

ONS. Esse arquivo criado automaticamente durante a instalao. A partir do Oracle
Database 11g Release 2 (11.2), ele automaticamente mantido pelo agente do ONS do CRS
usando as informaes armazenadas no OCR. H trs parmetros importantes que so
sempre configurados para cada ONS:
O primeiro localport, a porta que o ONS usa para comunicao com os clientes
locais.
O segundo remoteport, a porta que o ONS usa para comunicao com outros
daemons do ONS.
O terceiro parmetro chama-se nodes. Ele especifica a lista dos outros daemons do
ONS com os quais deve ser estabelecida a comunicao. Essa lista inclui todos os
daemons do ONS do ambiente RAC e do middle-tier. Os valores dos ns so
fornecidos como nomes de host ou endereos IP seguidos de remoteport. Essas
informaes so mantidas no OCR (Oracle Cluster Registry).
No slide, supe-se que os daemons do ONS j estejam iniciados em cada n do cluster.
Essa situao deve ser o default aps uma instalao correta do ambiente RAC.

Configurando Opcionalmente o ONS no Cliente
Mid-tier1
ons.config ONS $ onsctl start 2
localport=6100
remoteport=6200 1
nodes=node1:6200,node2:6200
ONS ONS
OCR
ons.config ons.config
N1 N2
O Oracle Database 11g Release 2 apresenta um novo conjunto de APIs para os eventos
FAN (Fast Application Notification) do Oracle RAC. Essas APIs constituem uma alternativa
para tirar proveito dos recursos de HA (alta disponibilidade) do Oracle Database, caso voc
no use Universal Connection Pool nem o armazenamento da conexo do Oracle JDBC no
cache. Essas APIs no fazem parte das APIs do Oracle JDBC. Para usar o Oracle RAC Fast
Application Notification, o arquivo ons.jar deve estar presente em CLASSPATH ou um
cliente ONS (Oracle Notification Services) deve estar instalado e em execuo no sistema
cliente. Para usar o ONS no cliente, necessrio configurar todos os ns do ambiente RAC
no arquivo de configurao do ONS. Uma amostra de arquivo de configurao deve se
parecer com o exemplo mostrado no slide.
Depois de configurar o ONS, inicie o daemon do ONS com o comando onsctl start.
Cabe a voc garantir que sempre haja um daemon do ONS em execuo. Para verificar se o
daemon do ONS est ativo, execute o comando onsctl ping.
Observao: com o Oracle Database 10g Release 2 e mais recente, no h requisitos para
o uso de daemons do ONS no middle-tier ao usar o Oracle Universal Connection Pool. Para
configurar essa opo, use a propriedade OracleDataSource ou uma API de setter
setONSConfiguration (configStr). A entrada nessa API equivale ao contedo do
arquivo ons.config especificado como uma string. O arquivo ons.jar deve estar na
varivel CLASSPATH do cliente. No h daemons a serem iniciados nem gerenciados.

Failover de Conexo Rpida do JDBC do UCP:

Viso Geral
Mid-tier1
Servio Servio ou n
evento UP ONS
evento DOWN
JDBC do UCP
Handler
de eventos
Conexes Conexes
reconectadas Cache de Conexes marcadas e
removidas
Conexes Conexes
que usam Listeners que usam
nomes de nomes de
servios Balanceamento servios
de carga de
ONS conexo
ONS
N1 Nn
O Oracle UCP (Universal Connection Pool) oferece uma integrao completa com os
recursos do banco de dados Oracle RAC, como o FCF (Fast Connection Failover).
Basicamente, o FCF um cliente FAN implementado por meio do pool de conexes. O FCF
recupera, com rapidez e de forma automtica, conexes perdidas ou danificadas. Como
consequncia desse gerenciamento automtico de conexes, o daemon local do ONS, ou
um daemon remoto do ONS se o local no for usado, recebe os eventos FAN e um thread de
handler de eventos especial trata esses eventos. So suportados drivers JDBC thin e JDBC
OCI.
Portanto, se o UCP e o FCF estiverem habilitados, o programa Java se tornar
automaticamente um assinante do ONS sem precisar gerenciar os eventos FAN diretamente.
Sempre que o ONS de middle-tier recebe um evento de inatividade de um servio ou de um
n, o handler de eventos marca automaticamente as conexes correspondentes como
inativas e remove-as. Isso impede que as aplicaes que solicitam conexes do cache
recebam conexes invlidas ou incorretas.
Sempre que o ONS de middle-tier recebe um evento de atividade de um servio, o handler
de eventos recicla algumas conexes no utilizadas e as reconecta usando o nome do
servio do evento. O cache de conexes determina automaticamente o nmero de conexes
recicladas. Os listeners fazem o balanceamento da carga da conexo, portanto, as conexes
so rebalanceadas automaticamente entre as instncias preferenciais do servio sem que
seja necessrio aguardar por novas tentativas ou por solicitaes de conexo.
Para obter mais informaes, consulte o Oracle Universal Connection Pool for JDBC
Developers Guide.
Vantagens do FCF no JDBC/ODP.NET
As conexes com o banco de dados so balanceadas

entre as instncias preferenciais de acordo com o LBA.
As solicitaes de trabalho do banco de dados so
balanceadas entre as instncias preferenciais de acordo
com o LBA.
possvel prever as conexes com o banco de dados.
As falhas em conexes com o banco de dados so
detectadas e interrompidas imediatamente.
Quando o FCF habilitado, as aplicaes Java existentes que estabelecem conexo por
meio do Oracle JDBC e de servios de aplicaes, ou suas aplicaes .NET que usam pools
de conexes e servios de aplicaes do ODP.NET obtm as seguintes vantagens:
Em vez de o primeiro grupo de sesses ser roteado para a primeira instncia RAC, as
conexes com o banco de dados so balanceadas entre todas as instncias RAC que
suportam o novo nome do servio. Isso feito de acordo com o algoritmo do Load
Balancing Advisory usado (consulte o prximo slide). Os pools de conexes so
rebalanceados quando ocorrem eventos de atividade de servio, instncia ou n.
O cache de conexes comea imediatamente a alocao de conexes para uma
instncia RAC especfica quando um novo servio inicializado nessa instncia.
O cache de conexes faz o shutdown imediato das conexes desatualizadas com as
instncias RAC em que o servio interrompido ou cujo n desativado.
Sua aplicao torna-se automaticamente um assinante da FAN sem que seja
necessrio gerenciar diretamente os eventos FAN simplesmente por meio da
configurao de flags nos descritores de conexo.
gerada uma exceo assim que o status do servio alterado para not_restarting, o
que evita novas tentativas inteis de conexo com o servio.
Observao: para obter mais informaes sobre como se inscrever em eventos FAN,
consulte o Oracle Database JDBC Developers Guide e o Oracle Data Provider for .NET
Developers Guide.
Load Balancing Advisory
O LBA (Load Balancing Advisory) um advisory usado

para enviar trabalho entre as instncias do RAC.
A dica do LBA est disponvel a todas as aplicaes que
enviam trabalho:
Pools de conexes do JDBC e do ODP
Balanceamento da carga de conexo
A dica do LBA envia trabalho ao local de execuo de
servios mais eficiente e onde h recursos disponveis:
Baseia-se na eficcia do servio
Ajusta a distribuio para ns com diferentes capacidades,
cargas de trabalho com prioridade e forma distintas,
alterao de demanda
Interrompe o envio de trabalho para ns lentos, suspensos
ou que falharam
O balanceamento de carga distribui o trabalho em todas as instncias disponveis do banco

de dados RAC. As aplicaes criadas de forma adequada usam conexes persistentes que
se expandem pelas instncias do RAC ao oferecerem um servio. As conexes so
raramente criadas e duram um longo perodo. O trabalho recebido pelo sistema com alta
frequncia, pega emprestado essas conexes e existe durante um perodo relativamente
curto.
A tarefa do Load Balancing Advisory consiste em recomendar a direo do trabalho recebido
para as instncias do RAC que oferecem um alto nvel de qualidade de servio para esse
trabalho. O algoritmo do LBA usa mtricas sensveis ao desempenho atual dos servios no
sistema.
O load balancing advisory implantado com clientes chave Oracle, como listener, o pool de
conexes universais JDBC, pool de sesses OCI, Oracle WebLogic Server Active GridLink
para Oracle RAC e os Pools de Conexes ODP.NET. As aplicaes de terceiros tambm
podem se inscrever em eventos de load balancing advisory usando o JDBC e a API Oracle
RAC FAN ou usando callbacks com OCI.
O uso do Load Balancing Advisory para balanceamento de carga reconhece as diferenas de
capacidade de cada mquina, as sesses bloqueadas e em espera, as falhas que bloqueiam
o processamento, bem como os servios concorrentes de importncia distinta. O uso do
Load Balancing Advisory impede o envio de trabalho a ns sobrecarregados, suspensos ou
que falharam.
Balanceamento de Carga de Conexes de

Runtime do JDBC do UCP/ODP.NET: Viso Geral
Solicitaes de
trabalho do CRM
Cache de Conexes
10%
?
30%
60%
RAC RAC RAC

INST O CRM O CRM INST O CRM est INST
est muito no est ocupado
1 ocupado ocupado 2 3
As solicitaes de trabalho s instncias do RAC, sem o uso do Load Balancing Advisory,

so designadas aleatoriamente, o que apropriado quando o desempenho de cada instncia
uniforme. Entretanto, se uma das instncias ficar mais sobrecarregada do que as outras
devido ao volume de trabalho resultante de cada designao de conexo, o desempenho do
modelo aleatrio no ser mais ideal.
O recurso Runtime Connection Load Balancing permite a designao de conexes com base
nas informaes do Load Balancing Advisory das instncias no cluster RAC. O cache de
conexes designa conexes aos clientes com base em um nmero relativo que indica o
percentual de solicitaes de trabalho que podem ser tratadas por cada instncia.
No diagrama do slide, o feedback indica que o servio CRM em INST1 est to ocupado que
capaz de atender somente a 10% das solicitaes de trabalho do CRM; INST2 est com
pouca carga e, portanto, capaz de oferecer 60% de servio; enquanto INST3 apresenta
carga intermediria e atende a 30% das solicitaes. Observe que esses percentuais so
aplicveis, e a deciso tambm feita, por servio. Nesse exemplo, o CRM o servio em
questo.
Observao: o Runtime Connection Load Balancing um recurso dos pools de conexes
Oracle.

Balanceamento de Carga de Conexes no RAC
O balanceamento de carga de conexes permite que os listeners

distribuam as solicitaes de conexo para as melhores instncias.
Isto depende da configurao clbgoal do servio.
Para o balanceamento de carga de conexes, voc pode usar uma
meta de:
LONG: Use este mtodo de balanceamento de carga de conexes
se o balanceamento de carga de runtime no for necessrio.
(Tpico para operaes batch)
$ srvctl modify service -db orcl -service batchconn
-clbgoal LONG
SHORT: Use este mtodo para aplicaes que utilizem
balanceamento de carga de runtime ou ao usar pools de conexes
integradas ao LBA.
$ srvctl modify service -db orcl -service oltpapp
-clbgoal SHORT
O Oracle Net Services oferece a capacidade de distribuir conexes de clientes pelas instncias
em uma configurao do Oracle RAC. Com o balanceamento de carga do servidor, o listener
do SCAN direciona uma solicitao de conexo para a melhor instncia que estiver fornecendo
atualmente o servio, com base nas configuraes de clbgoal do servio.
Quando voc cria um banco de dados RAC com DBCA, ele configura e ativa automaticamente
o balanceamento de carga no servidor. Uma definio de conexo de balanceamento de carga
no cliente no arquivo tnsnames.ora do servidor tambm criada. A FAN, o Fast Connection
Failover e o load balancing advisory dependem de uma configurao precisa de
balanceamento de carga de conexo que inclua a definio da meta de balanceamento de
carga da conexo do servio. A meta pode ser LONG ou SHORT para o balanceamento de
carga da conexo. Os objetivos tm as seguintes caractersticas:
SHORT: Use o mtodo de balanceamento de carga de conexo SHORT para as aplicaes que
utilizem balanceamento de carga de runtime. Ao usar pools de conexes integrados ao Load
Balancing Advisory, estabelea a meta como SHORT.
LONG: Use o mtodo LONG se o balanceamento de carga de runtime no for necessrio. Isto
tpico para operaes batch. LONG o objetivo de balanceamento de carga de conexo
default.
Definir o objetivo de balanceamento de carga de conexo de runtime como NONE desativa o
balanceamento de carga do servio. Voc pode ver as configuraes de objetivo de um servio
no dicionrio de dados consultando as views DBA_SERVICES, V$SERVICES e
V$ACTIVE_SERVICES. Voc tambm pode examinar as configuraes de balanceamento de
carga de um servio usando o Oracle Enterprise Manager.
Monitorando Eventos FAN do LBA
SQL> SELECT TO_CHAR(enq_time, 'HH:MI:SS') Enq_time, user_data

2 FROM sys.sys$service_metrics_tab
3 ORDER BY 1 ;
ENQ_TIME USER_DATA
-------- -----------------------------------------------------
...
04:19:46 SYS$RLBTYP('MYSERV', 'VERSION=1.0 database=orcl
service=MYSERV { {instance=orcl_2 percent=50
flag=UNKNOWN}{instance=orcl_1 percent=50 flag=UNKNOWN}
} timestamp=2013-07-19 11:07:32')
04:20:16 SYS$RLBTYP('MYSERV', 'VERSION=1.0 database=orcl
service=MYSERV { {instance=orcl_2 percent=80
flag=UNKNOWN}{instance=orcl_1 percent=20 flag=UNKNOWN}
} timestamp=2013-07-19 11:08:11')
SQL>
Voc pode usar a consulta SQL mostrada no slide para monitorar os eventos FAN do Load
Balancing Advisory para cada um de seus servios.

TAF (Transparent Application Failover):

Viso Geral
Mtodo Basic do TAF 1 Mtodo Preconnect do TAF
2 2
Aplicao Aplicao
Biblioteca OCI 6 Biblioteca OCI 6
4 Net Services 4 Net Services
5 3 7 5 3
8 7
AP 3 ERP 3
7 1 3
1
AP ERP ERP_PRECONNECT
O TAF (Transparent Application Failover) um recurso de runtime do driver OCI. Ele permite
aplicao reconectar-se automaticamente com o servio caso ocorra uma falha na conexo
inicial. Durante a reconexo, embora ocorra o rollback das transaes ativas, o TAF pode
retomar opcionalmente a execuo de uma instruo SELECT que estava em andamento. O
TAF suporta dois mtodos de failover:
Com o mtodo BASIC, a reconexo estabelecida no momento do failover. Depois que o
servio tiver sido iniciado nos ns (1), a conexo inicial (2) ser estabelecida. O listener
estabelece a conexo (3), e a aplicao acessa o banco de dados (4) at que ocorra uma
falha na conexo (5) por qualquer motivo. Depois disso, a aplicao recebe um erro na
prxima vez que tenta acessar o banco de dados (6). Em seguida, o driver OCI
reconecta-se ao mesmo servio (7) e, na prxima vez que a aplicao tenta acessar o
banco de dados, ela usar de forma transparente a conexo recm-criada (8). O TAF
pode ser habilitado para receber eventos FAN com o objetivo de executar uma operao
mais rpida de failover e deteco de eventos inativos.
O mtodo PRECONNECT semelhante ao mtodo BASIC, mas, durante a criao da
conexo inicial, tambm criada uma conexo-espelho, a ser usada em caso de failover.
O TAF garante que a conexo-espelho seja sempre criada nas instncias disponveis do
servio. Para isso, um servio-espelho criado e mantido automaticamente.
Observao: como alternativa, voc pode registrar callbacks de TAF na camada do OCI.
Essas funes de callback so chamadas automaticamente durante a deteco do failover e
permitem um certo controle do processo de failover. Para obter mais informaes, consulte o
Oracle Call Interface Programmers Guide.
Configurao Bsica do TAF

no Servidor: Exemplo
$ srvctl add service -db RACDB -service APSVC
-failovermethod BASIC -failovertype SELECT
-failoverretry 10 -failoverdelay 30 -serverpool sp1
$ srvctl start service -db RACDB -service APSVC
apsvc =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = cluster01-scan)
(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = apsvc)))
$ sqlplus AP/AP@apsvc
SQL> SELECT inst_id, username, service_name, failover_type,
failover_method
FROM gv$session WHERE username='AP';
INST_ID USERNAME SERVICE_NAME FAILOVER_TYPE FAILOVER_M

------- -------- ------------ ------------- ----------
1 AP apsvc SELECT BASIC
Antes de usar o TAF (Transparent Application Failover), crie e inicie um servio que seja
usado durante as conexes. Com isso, voc aproveitar a integrao entre o TAF e os
servios. Quando desejar usar BASIC TAF com um servio, voc deve usar a opo -
failovermethod BASIC ao criar o servio (o mtodo de failover do TAF usado somente
para compatibilidade retroativa). Voc pode definir a poltica do TAF configurando o nmero
de vezes que uma sesso com falha tenta se reconectar ao servio e por quanto tempo deve
esperar entre as tentativas de reconexo usando os parmetros -failoverretry e -
failoverdelay, respectivamente. Depois da criao do servio, basta inici-lo no banco
de dados.
O TAF pode ser configurado no cliente em tnsnames.ora ou no servidor com o utilitrio
srvctl conforme mostrado acima. A configurao do TAF no servidor preferencial, pois
conveniente colocar a configurao em um nico local (o servidor).
Sua aplicao precisar estabelecer conexo com o servio usando um descritor de conexo
semelhante ao mostrado no slide. No exemplo mostrado acima, observe que o SCAN de
cluster usado no descritor. Uma vez conectado, a view GV$SESSION refletir que a
conexo habilitada para TAF. A coluna FAILOVER_METHOD e FAILOVER_TYPE reflete isso
e confirma que a configurao do TAF est correta.

Configurao Bsica do TAF no Cliente:

Exemplo
$ srvctl add service -db RACDB -service AP serverpool sp1
$ srvctl start service -db RACDB -service AP
AP =
(DESCRIPTION =(FAILOVER=ON)(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=N1VIP)(PORT=1521))
(CONNECT_DATA =
(SERVICE_NAME = AP)
(FAILOVER_MODE= (TYPE=select)
(METHOD=basic)
(RETRIES=20)
(DELAY=15))))
Para usar o TAF no cliente, crie e inicie seu servio usando SRVCTL, em seguida configure o
TAF definindo uma entrada de TNS para ele em seu arquivo tnsnames.ora, conforme
mostrado no slide.
O parmetro FAILOVER_MODE deve ser includo na seo CONNECT_DATA de um descritor
de conexo.
No exemplo do slide, se a instncia falhar aps a conexo, a aplicao do TAF faz o failover
no listener do outro n, reservando as instrues SELECT em andamento. Se a conexo de
failover falhar, o Oracle Net aguarda 15 segundos antes de tentar uma nova reconexo. O
Oracle Net tenta se reconectar at 20 vezes.

Configurao do Mtodo Preconnect do TAF:

Exemplo
$ srvctl add service -db RACDB -service ERP
-preferred I1 -available I2
-tafpolicy PRECONNECT
$ srvctl start service -db RACDB -service ERP
ERP =
(CONNECT_DATA = (SERVICE_NAME = ERP)
(FAILOVER_MODE = (BACKUP=ERP_PRECONNECT)
(TYPE=SESSION)(METHOD=PRECONNECT))))
ERP_PRECONNECT =
(CONNECT_DATA = (SERVICE_NAME = ERP_PRECONNECT)))
Para usar o modo PRECONNECT TAF, crie um servio com instncias preferidas e
disponveis. Alm disso, para que o Oracle Clusterware crie e gerencie automaticamente o
servio-espelho, defina o servio com a opo tafpolicy PRECONNECT. A especificao
da poltica do TAF se destina apenas a bancos de dados gerenciados por administrador. O
servio-espelho sempre recebe o nome de acordo com o formato
<service_name>_PRECONNECT.
Quando as definies do servio TAF so feitas somente no cliente, voc precisa configurar
um descritor de conexo especial no seu arquivo tnsnames.ora para usar o mtodo
PRECONNECT. O slide mostra um desses descritores de conexo.
As principais diferenas em relao ao exemplo anterior so a definio de METHOD como
PRECONNECT e o acrscimo de um parmetro de adio. Esse parmetro denominado
BACKUP e deve ser definido para outra entrada no arquivo tnsnames.ora que aponte para
o servio-espelho.

Verificao do TAF
SELECT machine, failover_method, failover_type,
failed_over, service_name, COUNT(*)
FROM v$session
GROUP BY machine, failover_method, failover_type,
failed_over, service_name;
MACHINE FAILOVER_M FAILOVER_T FAI SERVICE_N COUNT(*)
Primeiro ------- ---------- ---------- --- -------- --------
n node1 BASIC SESSION NO AP 1
node1 PRECONNECT SESSION NO ERP 1

Segundo
------- ---------- ---------- --- --------- --------
n
node2 NONE NONE NO ERP_PRECO 1

Segundo
------- ---------- ---------- --- -------- --------
n aps
node2 BASIC SESSION YES AP 1
node2 PRECONNECT SESSION YES ERP_PRECO 1
Para determinar se o TAF est configurado corretamente e se as conexes esto associadas

a uma opo de failover, voc pode verificar a view V$SESSION. Para obter informaes
sobre os clientes conectados e seus respectivos status no TAF, verifique as colunas
FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER e SERVICE_NAME. O exemplo inclui
uma consulta que voc pode executar para verificar se configurou o TAF corretamente. O
exemplo baseado nos servios AP e ERP configurados anteriormente e nos descritores de
conexo correspondentes.
A primeira sada no slide o resultado da execuo da consulta no primeiro n aps a
conexo de duas sesses do SQL*Plus nesse n com os servios AP e ERP,
respectivamente. A sada mostra que a conexo AP foi estabelecida com a primeira
instncia. Em funo do algoritmo de balanceamento de carga, ela pode passar para a
segunda instncia. Como alternativa, a conexo ERP deve ser estabelecida com a primeira
instncia pois ela a nica instncia preferencial.
A segunda sada o resultado da execuo da consulta no segundo n antes de uma falha
de conexo. Observe que, no momento, h uma conexo no utilizada estabelecida com o
servio ERP_PRECONNECT que iniciada automaticamente na instncia ERP disponvel.
A terceira sada a que corresponde execuo da consulta no segundo n aps a falha da
primeira instncia. Uma segunda conexo foi criada automaticamente para a conexo com o
servio AP, e a conexo ERP original agora usa a conexo pr-conectada.

Consideraes sobre Pools de

Conexes FAN e TAF
As duas tcnicas so integradas a servios e permitem o
balanceamento da carga das conexes com os servios.
Os pools de conexes que usam a FAN so sempre
pr-conectados.
O TAF poder se basear nos timeouts do sistema
operacional (SO) para detectar falhas.
A FAN nunca depende dos timeouts do sistema
operacional para detectar falhas.
Como o balanceamento de carga das conexes uma funcionalidade do listener, o FCF e o

TAF usam automaticamente esse balanceamento para os servios.
O uso do FCF dispensa o uso do TAF.
Por exemplo, voc no precisar estar pr-conectado se usar a FAN junto com pools de
conexes. O pool de conexes sempre pr-conectado.
Com as duas tcnicas, voc utiliza os VIPs automaticamente no momento da conexo. Isso
significa que a aplicao no depende de longos timeouts de conexo do sistema
operacional durante a conexo ou durante a execuo de uma instruo SQL. No entanto,
quando estiver na pilha de SQL e estiver bloqueada em uma chamada de leitura/gravao, a
aplicao dever ser integrada FAN para receber uma notificao de interrupo se um n
for desativado. Em uma situao semelhante, o TAF poder se basear nos timeouts do
sistema operacional para detectar a falha. Portanto, o failover da conexo demora muito mais
do que quando a FAN usada.

Questionrio
Quais das seguintes opes representam benefcios da

implementao da Fast Application Notification?
a. As conexes no precisam depender de timeouts
b. Usado pelo Load Balancing Advisory para propagar
informaes sobre carga de forma eficiente
c. As falhas em conexes com o banco de dados so
detectadas e interrompidas imediatamente.
d. Projetado para integrao entre aplicaes empresariais e
consoles de gerenciamento
Resposta: a, b, d

Sumrio

conexo do cliente
Configurar o failover por tempo de conexo do cliente
conexo do servidor
Usar o Load Balancing Advisory
Descrever as vantagens do recurso FAN (Fast Application
Notification)
Configurar callouts do servidor
Configurar o ONS no cliente e no servidor
Configurar o TAF (Transparent Application Failover)

Parte II
e Transaction Guard
Application Continuity

Objetivos

Descrever a finalidade dos recursos Transaction Guard e
Descrever os principais conceitos relacionados ao recurso
Descrever os efeitos colaterais e as restries
relacionados ao recurso Application Continuity
Descrever os requisitos para desenvolver aplicaes que
tirem proveito do recurso Application Continuity
Configurar o recurso Application Continuity

A Situao Anterior ao Recurso Application

Continuity
As interrupes no funcionamento do banco de dados podem
causar os seguintes problemas:
Perda do trabalho em andamento, deixando os usurios
em dvida
Os usurios precisarem reiniciar aplicaes e reinserir dados,
levando ao envio duplicado de solicitaes
Falhas adicionais, possivelmente prolongando
a interrupo do funcionamento do sistema
1. Solicitao
difcil e caro resolver problemas de Trabalho
dentro da aplicao. 4. Erros de
Aplicaes
2. Chamadas ao
Banco de Dados
A ltima
transao foi 3. Erros do
confirmada? Banco de
Dados
Para usurios finais, as interrupes das sesses do banco de dados podem levar a
resultados indesejveis:
Confuso: os usurios no sabem o que aconteceu com as transaes dos seus
aplicativos, como transferncias de fundos, pedidos, pagamentos e reservas.
Duplicao: a dvida em relao a uma transao com problemas pode levar os
usurios a reinseri-la. Isso pode resultar em uma duplicao indesejvel, causando
pagamentos, pedidos ou reservas em excesso, por exemplo.
Perda de produtividade: mesmo se a duplicao no for um problema, a produtividade
do usurio poder ser afetada negativamente, pela necessidade de reiniciar aplicaes
e reinserir dados.
Interrupes prolongadas do funcionamento do sistema: uma falha no banco de dados
pode causar bloqueios ou problemas em aplicaes relacionadas ou outra
infraestrutura, como sensores e equipamento de comunicao. Isso poder exigir que
as aplicaes e outros componentes sejam reinicializados, resultando em uma
interrupo prolongada do funcionamento do sistema.
O desenvolvimento de uma soluo para esses problemas dentro da aplicao tem sido
tradicionalmente difcil e caro pelos seguintes motivos:
necessrio considerar e tratar cada possvel exceo.
Se ocorrer uma falha durante uma confirmao, difcil determinar se ela ocorreu.
Para reproduzir, de forma legtima, o trabalho associado a uma sesso com falha, a
aplicao dever garantir que o banco de dados esteja no estado correto. Caso
contrrio, a reproduo poder ser invlida.
Introduzindo os Recursos Transaction Guard

e Application Continuity
O Oracle Database 12c introduz dois recursos fundamentais
para garantir a continuidade de aplicaes aps interrupes
de funcionamento do banco de dados:
Transaction Guard: O recurso Transaction Guard um
novo protocolo confivel e uma API que retorna o
resultado da ltima transao aps a ocorrncia de um
erro recupervel.
Application Continuity: Application Continuity um
recurso que tenta mascarar interrupes de sesses do
banco de dados, recuperando o trabalho em andamento
para solicitaes enviadas ao banco de dados.
O Oracle Database 12c introduz dois recursos fundamentais para garantir a continuidade de
aplicaes aps interrupes de funcionamento do banco de dados:
1. Uma forma inequvoca de as aplicaes saberem do resultado das transaes
2. A capacidade de mascarar interrupes de funcionamento restabelecendo a conexo
com o banco de dados e reproduzindo a carga de trabalho
Essas capacidades so fornecidas por dois novos recursos: Transaction Guard e Application
Continuity.
O Transaction Guard uma API usada pelas aplicaes no processamento de erros.
uma nova forma confivel de retornar o resultado da ltima transao aps a ocorrncia
de um erro recupervel. Isoladamente, o Transaction Guard pode aperfeioar
drasticamente a experincia do usurio final, anulando a dvida relativa confirmao
da ltima transao.
O Application Continuity um recurso que mascara as interrupes recuperveis dos
usurios finais e das aplicaes. O Application Continuity tenta reproduzir o trabalho
transacional e no transacional que constitui uma solicitao ao banco de dados.
Quando a reproduo for feita com xito, a interrupo ser exibida para o usurio final
como se a execuo estivesse levemente atrasada. Com o Application Continuity, a
experincia do usurio final aperfeioada porque ele nunca percebe que ocorreu uma
interrupo. Alm disso, o Application Continuity pode simplificar o desenvolvimento de
aplicaes, removendo a presso de ter que lidar com interrupes recuperveis.
RAC e Application Continuity
O Application Continuity reproduz, de forma transparente,

solicitaes ao banco de dados aps uma sesso com
falha.
Os usurios so protegidos contra muitos tipos de problemas.
O uso do Application Continuity com o
RAC fornece:
FAN
Proteo contra uma maior variedade Chamada Reproduo
2
de cenrios com falha
1 3
Reconexo e reproduo mais rpidas
Reproduo das solicitaes em
outra instncia do RAC RAC1 RAC2 RAC3
O Application Continuity um recurso que reproduz, de forma transparente e rpida, uma

solicitao no banco de dados aps um erro recupervel que torne a sesso do banco de
dados indisponvel. A solicitao pode conter trabalho transacional e no transacional. Com o
Application Continuity, a experincia do usurio final aperfeioada pelo mascaramento de
vrios problemas de sistema, comunicao, hardware e armazenamento do usurio final.
Quando o Application Continuity usado com o Oracle RAC, possvel reiniciar e reproduzir
rapidamente sesses com falha em outra instncia do banco de dados RAC. O uso do
Application Continuity com o Oracle RAC fornece proteo contra uma maior variedade de
possveis falhas em comparao com o Application Continuity em um banco de dados de
instncia nica. Alm disso, o uso do Application Continuity com o Oracle RAC permite uma
reproduo mais rpida em comparao com o uso do Application Continuity com o Data
Guard, porque a reconexo com outro banco de dados que j esteja em execuo pode ser
concluda em alguns segundos, enquanto a operao de failover do Data Guard pode levar
alguns minutos.

Principais Conceitos do Application Continuity
Solicitao ao Banco de Dados: unidade de trabalho enviada

da aplicao, em geral, chamadas SQL, PL/SQL, RPC
Erro Recupervel: erro decorrente de uma falha em um
sistema externo, independentemente da aplicao
Resultado da Confirmao: resultado da ltima transao,

transformado em durvel pelo Transaction Guard
Funes Mutveis: funes que alteram os resultados

sempre que so executadas
Consistncia do Estado da Sesso: descreve como a

aplicao altera o estado no transacional durante uma
solicitao ao banco de dados
O slide introduz alguns termos e conceitos que esto associados aos recursos Transaction
Guard e Application Continuity. As seguintes observaes fornecem mais informaes:
Solicitao ao Banco de Dados
Solicitao ao banco de dados uma unidade de trabalho enviada da aplicao. Geralmente,
uma solicitao ao banco de dados consiste nas instrues SQL, blocos PL/SQL, chamadas
de procedures locais e RPCs (Remote Procedure Calls) de banco de dados, em uma nica
solicitao da Web em uma s conexo do banco de dados. As solicitaes ao banco de
dados geralmente so demarcadas pelas chamadas realizadas para fazer check-out e check-
in de uma conexo ao banco de dados a partir de um pool de conexes. Para erros
recuperveis, o Application Continuity restabelece a sesso do banco de dados e repete a
solicitao com segurana.
Erro Recupervel
Erro recupervel um erro decorrente de uma falha em um sistema externo, independente
da lgica da sesso da aplicao em execuo. Os erros recuperveis ocorrem aps
interrupes planejadas e no planejadas de foregrounds, redes, ns, armazenamento e
bancos de dados. A aplicao recebe um cdigo de erro (como ORA-03113: end-of-
file on communication channel) que pode deixar a aplicao sem saber o status da
ltima operao enviada. Os erros recuperveis foram aprimorados no Oracle Database 12c
para incluir mais erros, e agora incluem uma API pblica para OCI.

O recurso Application Continuity restabelece as sesses do banco de dados e reenvia o
trabalho pendente no caso de erros recuperveis. O Application Continuity no reenvia o
trabalho aps falhas na chamada decorrentes de erros no recuperveis. Um exemplo de
erro no recupervel o envio de um valor de dados invlido, como uma data ou um valor
numrico invlido.
Resultado da Confirmao
No Oracle Database, uma transao confirmada pela atualizao de sua entrada na tabela
de transaes internas. O Oracle Database gera um registro de redo log correspondente a
essa atualizao. Depois que o registro de redo log gravado no redo log no disco, a
transao considerada confirmada no banco de dados. Do ponto de vista do cliente, a
transao confirmada quando uma mensagem de resultado da confirmao, gerada aps a
gravao desse redo, recebida pelo cliente. No entanto, a mensagem de resultado da
confirmao no durvel. Por exemplo, ser possvel perder o resultado da confirmao
caso o cliente seja desconectado do banco de dados aps o resultado da confirmao ser
gerado pelo banco de dados, mas antes de ser recebido pelo cliente. O Transaction Guard
fornece um resultado de confirmao confivel porque pode ser usado para obter o resultado
da confirmao em caso de perda aps um erro recupervel que resulte na falha de uma
sesso do banco de dados.
Funes Mutveis
So funes que podem alterar seus resultados sempre que chamadas. As funes mutveis
podem fazer com que a reproduo seja rejeitada porque os resultados visveis para a
aplicao so alterados na reproduo. Considere sequence.NEXTVAL que
frequentemente usado em valores-chave. Se uma chave primria for criada com um valor de
sequncia e, posteriormente, for usada em chaves estrangeiras ou outras associaes, na
reproduo, o mesmo resultado da funo dever ser retornado se o aplicativo a estiver
usando.
O Application Continuity fornece um valor de objeto mutvel substituto na reproduo para
que as chamadas de funo Oracle concedidas forneam consistncia de variveis de
associao opaca. Se a chamada usar funes de banco de dados mutveis,
incluindo sequence.NEXTVAL, SYSDATE, SYSTIMESTAMP e SYSGUID, os valores originais
retornados da execuo de funo sero salvos e reaplicados na reproduo. Se uma
aplicao decidir no conceder mutveis, a reproduo dessas solicitaes poder ser
rejeitada.
Consistncia do Estado da Sesso
O estado no transacional inclui definies NLS (national language support), cursores,
eventos e estados de pacotes PL/SQL globais. Aps a execuo de uma instruo COMMIT,
se o estado no transacional tiver sido alterado nessa transao, no ser possvel
reproduzir a transao para restabelecer esse estado se a sesso for perdida. Ao configurar
o recurso Application Continuity, as aplicaes sero categorizadas dependendo do estado
da sesso aps a configurao inicial, ou seja, se esttico ou dinmico, e, dessa forma, se
correto o prosseguimento aps uma operao COMMIT em uma solicitao.
Durante a configurao do recurso Application Continuity, quase todas as aplicaes devem
usar o modo DYNAMIC default. No modo DYNAMIC, a reproduo desabilitada do COMMIT
at o final da solicitao. Esse no um problema na maioria das aplicaes, porque quase
todas as solicitaes tm zero ou um commit, e quase sempre a ltima instruo em uma
solicitao ao banco de dados.

Fluxo de Trabalho de uma Solicitao

ao Banco de Dados
PoolDatasource pds = GetPoolDataSource(); A solicitao
Connection conn = getConnection(pds); iniciada.
conn.setAutoCommit(false);
ResultSet rs1 = pstmt1.executeQuery(); ...
CallableStatement cstmt = conn.prepareCall(plsql1);
cstmt.setInt(1,1);
cstmt.execute();
SQL, PL/SQL,
RPC, chamadas
PreparedStatement pstmt2 = conn.prepareStatement(query2 ... locais
ResultSet rs2 = pstmt2.executeQuery();
If (rs2!=null) {
while rs2.Next()) { ... //fetch from rs2
rs2.close(); COMMIT a ltima

pstmt2.close(); ao na maioria das
solicitaes.
conn.commit();
A solicitao
conn.close(); finalizada.
Uma solicitao ao banco de dados uma unidade de trabalho lgica.

Por exemplo:
Cada ao que o driver do cliente recebe de um ORM (Object Relational Manager)
Cada ao que voc envia no caixa eletrnico
Cada ao enviada no navegador ao navegar, fazer compras, pagar contas, etc.
Geralmente, todas as solicitaes ao banco de dados que usam JDBC, seguem um padro.
O slide contm um segmento de cdigo que mostra como as aplicaes JDBC tpicas so
codificadas:
1. Uma solicitao ao banco de dados iniciada com a chamada para getConnection
PoolDatasource.
2. A lgica da aplicao executada. Essa execuo pode incluir SQL, PL/SQL, RPC ou
chamadas de procedures locais.
3. A transao confirmada.
4. A solicitao ao banco de dados finalizada quando a conexo retornada ao pool de
conexes.

O que Transaction Guard?
Transaction Guard:
Uma ferramenta que fornece um resultado de confirmao
confivel para a ltima transao aps os erros
Uma API disponvel para JDBC Thin, C/C++ (OCI/OCCI) e
ODP.NET
Usado pelo Application
Continuity para execuo 1. Solicitao
no mximo uma vez de Trabalho
5. Confirmao
Pode ser usado de forma 2. Chamadas ao
Confivel
Resultado
independente do Banco de Dados
4. Resultado da Imposio
Sem o Transaction Guard, uma 3. Erros
nova tentativa pode causar
danos lgicos. Oracle Database 12c
O Transaction Guard um protocolo e uma API confiveis que as aplicaes usam para
fornecer um resultado de confirmao confivel. Geralmente, a API incorporada no
tratamento dos erros e deve ser chamada aps erros recuperveis. O resultado indica se a
ltima transao foi confirmada e concluda. Depois que o resultado da confirmao
retornado para a aplicao, ele persiste. Dessa forma, se o Transaction Guard retornar um
resultado confirmado ou no confirmado, o status permanecer dessa maneira. Isso permite
que a aplicao ou o usurio prossiga com confiana.
O Transaction Guard usado pelo Application Continuity e automaticamente habilitado por
ele, mas tambm pode ser habilitado de forma independente. O Transaction Guard evita que
a transao reproduzida pelo Application Continuity seja aplicada mais de uma vez. Se a
aplicao tiver implementado uma reproduo no nvel da aplicao, a integrao com o
Transaction Guard poder ser usada para garantir a idempotncia da transao, ou seja,
vrias execues da transao produziro o mesmo resultado que uma nica execuo.

Como o Transaction Guard Funciona
O Transaction Guard um protocolo e uma API confiveis que

permitem s aplicaes saber o resultado da ltima transao.
Cliente Banco de Horrio
dados
SQL, PL/SQL ou RPC
Falha na Confirmao
Confirmao
Comunicao "Confirmao
Concluda."
DBMS_APP_CONT.
GET_LTXID_OUTCOME(LTXID)
LTXID LTXID
Transaction
Nova Sesso Resultado da Guard
"Confirmao Confirmao Confivel "Confirmao
Concluda." Concluda."
No caso de confirmao padro, o banco de dados confirma uma transao e retorna uma
mensagem de xito ao cliente. Na ilustrao mostrada no slide, o cliente envia uma instruo
de confirmao e recebe uma mensagem indicando que houve problemas na comunicao.
Esse tipo de falha pode ocorrer por muitos motivos, incluindo um problema em uma instncia
do banco de dados ou interrupo da rede. Nesse cenrio, sem o Transaction Guard, o
cliente no sabe o resultado da transao.
O Oracle Database resolve o problema usando um identificador exclusivo globalmente
denominado ID de transao lgica (LTXID). Durante a execuo da aplicao, o banco de
dados e o cliente mantm o ID da transao lgica. O banco de dados fornece ao cliente um
ID de transao lgica na autenticao e em cada rodzio do driver do cliente que executa
uma ou mais operaes de confirmao.
Quando ocorre uma interrupo recupervel, o ID de transao lgica identifica, de forma
exclusiva, a ltima transao do banco de dados enviada na sesso com falha. Uma nova
interface PL/SQL (DBMS_APP_CONT.GET_LTXID_OUTCOME) retorna o resultado da
confirmao confivel. Mais detalhes sobre como usar as APIs do Transaction Guard so
fornecidos mais adiante, na lio.

Usando o Transaction Guard
Tipos de transao suportados:

Confirmao local
Confirmao automtica e Confirmao no xito
Confirmao incorporada no PL/SQL
DDL, DCL e Parallel DDL
Confirmao remota, distribuda
No suportados na release 12.1:
XA
Links de banco de dados de leitura/gravao do Active Data Guard
Configurao do servidor:
Defina o atributo de servio COMMIT_OUTCOME=TRUE
Como alternativa, defina o atributo de servio RETENTION_TIMEOUT
Clientes suportados:
JDBC Thin, OCI, OCCI e ODP.NET
O Transaction Guard suporta todos os tipos de transao listados no slide. As excluses

primrias no Oracle Database12c release 12.1 so:
O Transaction Guard no suportado para aplicaes desenvolvidas com o Oracle XA.
O Transaction Guard no ser suportado se voc estiver usando o Active Data Guard
com links de um banco de dados de leitura/gravao para outro banco de dados.
Para habilitar o Transaction Guard, defina o atributo de servio COMMIT_OUTCOME=TRUE.
Tambm possvel alterar o atributo de servio RETENTION_TIMEOUT para especificar o
tempo durante o qual o resultado da confirmao retido. O valor de timeout especificado
em segundos; o default 86400 (24 horas), e o valor mximo 2592000 (30 dias).

Benefcios do Transaction Guard
Aps as interrupes, os usurios sabem o que aconteceu

com suas transaes em andamento, como transferncias
de fundos, reservas de voos e pagamentos de contas.
O Transaction Guard proporciona um melhor desempenho
e confiabilidade do que os cdigos criados internamente
para idempotncia.
O Transaction Guard um recurso poderoso. Alguns dos benefcios so:

Para aplicaes integradas ao Transaction Guard, os usurios podem saber o que
aconteceu com o ltimo envio e prosseguir com confiana e certeza. Sem o Transaction
Guard, a dvida aps uma falha poder fazer com que o usurio reenvie uma
solicitao ao banco de dados, o que poder causar danos lgicos.
Como ele integrado ao kernel do banco de dados, o Transaction Guard proporciona
um melhor desempenho e confiabilidade do que os cdigos criados internamente para
idempotncia.

O que Application Continuity?
Reproduz o trabalho em andamento no caso de erros

recuperveis
Mascara vrios erros de hardware, software, rede,
armazenamento e interrupes, quando executado
com xito
Melhora a experincia do usurio final
1. Solicitao
de Trabalho
5. Resposta
2. Chamadas ao
Banco de Dados
4. Reproduo
3. Erros
Oracle Database 12c
Sem o Application Continuity, interrupes da rede, falhas em instncias e no hardware,

reparos, alteraes na configurao, patches, etc., podem resultar na falha de uma sesso
do usurio seguida por uma mensagem de erro de algum tipo.
O Application Continuity mascara para aplicaes e usurios vrias interrupes
recuperveis do banco de dados. Ele efetua o mascaramento restaurando a sesso do banco
de dados, a sesso completa (incluindo o estado da sesso, cursores e varveis) e, se for o
caso, a ltima transao em andamento.
Se a sesso do banco de dados se tornar indisponvel devido a um erro recupervel, o
Application Continuity tentar recriar a sesso e todas as operaes em aberto para os
estados corretos. Se a ltima transao for bem-sucedida e no precisar ser executada
novamente, o status bem-sucedido ser retornado para a aplicao. Caso contrrio, o
Application Continuity reproduzir a ltima transao em andamento.
Para ser bem-sucedida, a reproduo dever retornar para o cliente exatamente os mesmos
dados recebidos por ele anteriormente, na solicitao original. Isso garante que todas as
decises baseadas nos dados consultados anteriormente sejam cumpridas durante a
reproduo. Se a reproduo for feita com xito, a aplicao continuar com segurana, sem
duplicao.
Se no for feita com xito, o banco de dados rejeitar a reproduo, e a aplicao receber o
erro original. Isso garante que a reproduo no proceda se houver alteraes nas
circunstncias entre a solicitao original e a reproduo.
Como o Application Continuity Funciona?
1. Solicitao
6. Resposta
JDBC Thin, UCP,
WebLogic Server
2. Chamadas 5. Chamadas
4. Reproduo
3. FAN ou erro
Oracle Database 12c
O grfico do slide ilustra como o Application Continuity funciona. Veja a seguir uma descrio
de um fluxo de trabalho tpico envolvendo o Application Continuity:
1. O cliente envia uma mensagem de trabalho para a aplicao.
2. A aplicao envia as chamadas que compem a solicitao ao banco de dados usando o
driver de reproduo JDBC.
3. O driver de reproduo JDBC recebe uma notificao FAN (Fast Application Notification)
ou um erro recupervel.
4. O driver de reproduo executa as seguintes aes:
- Ele verifica se a solicitao tem a reproduo habilitada e se o timeout de iniciao do
recurso no expirou. Se tudo estiver em ordem, o driver obter uma nova sesso do
banco de dados. Se um callback for registrado, ele ser executado para inicializar a
sesso.
- Ele verificar o banco de dados para determinar se a ltima transao foi concluda.
- Se a reproduo for necessria, o driver de reproduo JDBC reenviar as chamadas
de acordo com as instrues recebidas do banco de dados para cada uma. Cada
chamada dever resultar no mesmo estado visvel para o cliente.
5. Quando a ltima chamada for reproduzida, o driver terminar a reproduo e retornar ao
modo de tempo de execuo normal.
6. Se a reproduo for feita com xito, a aplicao responder normalmente para o usurio.

Usando o Application Continuity
Operaes suportadas de banco de dados:

SQL, PL/SQL e JDBC RPC: SELECT, ALTER SESSION, DML, DDL,
COMMIT, ROLLBACK, SAVEPOINT e JDBC RPCs
Modelos de transao: Local, Paralela, Remota, Distribuda e PL/SQL
Incorporada
Funes mutveis
Transaction Guard
Funciona com:
Oracle RAC e RAC One
Oracle Active Data Guard
Acelerao de hardware em chips Intel e SPARC atuais
Clientes suportados:
Driver JDBC Thin, Universal Connection Pool e WebLogic Server
O slide exibe os principais pontos relacionados ao uso do Application Continuity. As

seguintes observaes fornecem mais informaes:
O Application Continuity recupera a solicitao ao banco de dados, inclusive qualquer
transao em andamento e os estados da sesso do banco de dados. As solicitaes
podero incluir, na maioria, chamadas SQL e PL/SQL, RPCs e JDBC locais. Observe que
no caso de transaes remotas e distribudas, todos os bancos de dados envolvidos
devero corresponder release 12.1 ou mais recente.
O Application Continuity oferece a capacidade de manter os valores originais de algumas
funes Oracle, como SEQUENCE.NEXTVAL, que alteram seus valores sempre que so
chamadas. Isso aumenta a probabilidade de que a reproduo seja bem-sucedida.
O Application Continuity usa o Transaction Guard. O Transaction Guard insere tags em
cada sesso do banco de dados com um ID de transao lgica (LTXID), de forma que o
banco de dados reconhea se uma solicitao confirmou a transao antes da
interrupo.
O Application Continuity funciona com o Oracle Real Application Clusters (Oracle RAC), o
RAC One e o Oracle Active Data Guard.
No servidor de banco de dados, a validao executada pelo Application Continuity
acelerada por meio das extenses do processador incorporadas nos chips SPARC e Intel
atuais.
O Application Continuity fornece suporte ao cliente para thin JDBC, Universal Connection
Pool e WebLogic Server.
Fases de Processamento do Application

Continuity
Tempo de Reconexo Reproduo

Execuo Normal
Demarca a solicitao ao Garante que a Reproduz as chamadas
banco de dados solicitao tenha a mantidas
Cria objetos proxy reproduo habilitada Se os resultados visveis
Mantm as chamadas Processa timeouts para o usurio
originais com validao Cria uma nova conexo coincidirem, prosseguir
com a reproduo com
Gerencia filas Valida o banco de dados base nas validaes
de destino
Prosseguir com a
Usa o Transaction solicitao
Guard para forar
o ltimo commit
A operao do Application Continuity pode ser dividida em trs fases distintas:

Tempo de execuo normal: durante o tempo de execuo normal, cada nova
solicitao ao banco de dados marcada com um incio de solicitao, fazendo check-
out do Universal Connection Pool ou do WebLogic Server Connection Pool, ou
adicionando marcadores de incio e fim de solicitao sua prpria aplicao ou pool
de conexes Java no check-out e no check-in. O driver de reproduo JDBC e o Oracle
Database 12c colaboram de forma que as chamadas na solicitao ao banco de dados
sejam mantidas nas filas, juntamente com a validao recebida do banco de dados. O
driver de reproduo JDBC mantm as chamadas at o final da solicitao ao banco de
dados ou at que a reproduo seja desabilitada. Ele responsvel por gerenciar as
filas e criar objetos proxy para manter um registro do estado no transacional,
permitindo que os objetos sejam substitudos se a reproduo for necessria.

Reconexo: a fase de reconexo do Application Continuity acionada quando ocorre
uma interrupo recupervel. Nessa fase, a solicitao verificada para ver se a
reproduo ainda est habilitada, e o timeout de incio da reproduo examinado para
garantir que no tenha expirado. Se as duas verificaes estiverem em ordem, uma
nova conexo com o banco de dados ser obtida. Como a reconexo com o banco de
dados pode demorar, talvez seja necessrio definir FAILOVER_DELAY e
FAILOVER_TIMEOUT para que o servio seja restabelecido. Depois que o driver tiver
estabelecido uma conexo com o banco de dados, ele verificar se o banco de dados
um destino vlido e se a ltima transao foi confirmada com xito. A reproduo no
ocorrer se a conexo for a um banco de dados logicamente diferente ou se for ao
mesmo banco de dados, mas as transaes tiverem sido perdidas. Por exemplo, o
banco de dados foi restaurado a um ponto anterior. O Application Continuity no
reenviar transaes confirmadas. A idempotncia forada com o Transaction Guard.
Reproduo: a fase de reproduo iniciada quando uma nova conexo com o banco
de dados obtida. Todas as chamadas mantidas nas filas so reproduzidas, e a
solicitao prossegue a partir do ponto de falha. A reproduo ser desabilitada se
houver qualquer alterao visvel para o usurio nos resultados da solicitao
reproduzida.

Restries
Globais Solicitao Banco de Dados
de Destino
No use o servio de Para streams Java, a No suporta:
banco de dados default. reproduo feita com Stand-by Lgico
A reproduo no base no "melhor esforo".
GoldenGate
suportada para uma Chamadas restritas:
fonte de dados ALTER SYSTEM
Oracle XA. ALTER DATABASE
Classes concretas Java A reproduo no
descontinuadas no so suportada para o Active
suportadas. Data Guard com links
para banco de dados
de leitura/gravao
O slide lista algumas restries e outras consideraes aplicveis ao Application Continuity.

H basicamente trs nveis de restries para o Application Continuity:
Globais: as seguintes restries impedem que o Application Continuity seja habilitado ou
usado em solicitaes.
- No use o servio default correspondente ao DB_NAME nem ao DB_UNIQUE_NAME.
O uso do servio de banco de dados no recomendado para alta disponibilidade,
porque no possvel habilitar nem desabilitar esse servio, to pouco realoc-lo
no Oracle RAC nem altern-lo com o Oracle Data Guard.
- A reproduo no suportada para aplicaes desenvolvidas com o Oracle XA.
- Para aplicaes que usam JDBC, no h suporte para classes
concretas oracle.sql descontinuadas como BLOB, CLOB, BFILE, OPAQUE, ARRAY,
STRUCT ou ORADATA.
Solicitao: As seguintes restries desabilitam o Application Continuity para parte de
uma solicitao.
- Para argumentos de stream JDBC, a reproduo feita com base no "melhor
esforo". Por exemplo, se a aplicao estiver usando endereos fsicos, o endereo
no ser mais vlido com a interrupo e no ser possvel reposicion-lo.
- A reproduo ser desabilitada se a transao executar a instruo ALTER
SYSTEM ou ALTER DATABASE.
- A reproduo no ser suportada se voc estiver usando o Active Data Guard com
links de um banco de dados de leitura/gravao para outro banco de dados.
Destino: o Application Continuity no suportado para bancos de dados diferentes em
termos de lgica (Oracle Logical Standby e Oracle GoldenGate).
Possveis Efeitos Colaterais
possvel que algumas aplicaes usem a API

disableReplay se houver solicitaes que no devam
ser reproduzidas.
Exemplos de chamadas que criam efeitos colaterais so:
Transaes autnomas
Chamadas DBMS_ALERT (e-mail ou outras notificaes)
Chamadas DBMS_FILE_TRANSFER (copiando arquivos)
Chamadas DBMS_PIPE e RPC (para fontes externas)
Chamadas UTL_FILE (gravando arquivos de texto)
Chamadas UTL_HTTP (fazendo callouts HTTP)
Chamadas UTL_MAIL (enviando e-mail)
Chamadas UTL_SMTP (enviando mensagens SMTP)
Chamadas UTL_TCP (enviando mensagens TCP)
Chamadas UTL_URL (acessando URLs)
necessrio analisar aplicaes que usam aes externas para decidir se solicitaes com
efeitos colaterais devam ser reproduzidas ou no.
O Application Continuity reproduz SQL, PL/SQL e RPCs. O Application Continuity serve para
recriar a sesso como se o envio do usurio estivesse atrasado. Quando uma sesso
recriada, tambm o so todos os estados, incluindo a nova execuo de instrues que
provocam efeitos colaterais. Esses efeitos colaterais podem ser exatamente o que
necessrio, por exemplo, gravar um relatrio, concluir alguma auditoria ou obter intervalos de
chaves primrias personalizadas. No entanto, as chamadas que so reproduzidas podem
incluir algumas chamadas que no devem ser reproduzidas. possvel que a aplicao
execute alguma ao para acomodar ou amenizar os efeitos da reproduo. Os
desenvolvedores podem optar por usar a API disableReplay para solicitaes com
chamadas que eles no desejam reproduzir.
O slide mostra algumas das aes que criam efeitos colaterais, como Transaes
autnomas, e-mail ou outras notificaes, com chamadas DBMS_ALERT, copiar arquivos com
chamadas DBMS_PIPE e RPC, gravar arquivos de texto com chamadas UTL_FILE, fazer
callouts HTTP com chamadas UTL_HTTP, enviar e-mail com chamadas UTL_MAIL, enviar
mensagens SMTP com chamadas UTL_SMTP, enviar mensagens TCP com chamadas
UTL_TCP e acessar URLs com UTL_URL.

Aes que Desabilitam o Application Continuity
Tempo de Execuo Reconexo Reproduo

Normal
Todas as chamadas na O erro no recupervel A validao detecta
mesma solicitao aps: Falha na reconexo resultados diferentes
Confirmao bem- Timeout de iniciao da
sucedida no modo reproduo
dinmico (o default) Mximo de tentativas de
Uma chamada restrita conexo
Chamada da API Mximo de tentativas por

incidente
disableReplay
O banco de dados de
destino no vlido para
reproduo
ltima chamada confirmada,
no modo dinmico
Se for desabilitado, o Application Continuity no funcionar at a prxima solicitao. Os

seguintes eventos desabilitaro a reproduo da solicitao:
Tempo de execuo normal: a captura acontece em todas as chamadas originais at
um COMMIT bem-sucedido (no modo dinmico), a menos que ele esteja desabilitado
para a solicitao.
Reconexo: a reproduo no ocorrer se o erro no for recupervel ou se:
- Os timeouts tiverem sido excedidos
- O banco de dados de destino no for o mesmo ou um antecessor
- A solicitao tiver sido confirmada
Reproduo: as chamadas devero retornar os mesmos resultados visveis para o
usurio que a aplicao tiver observado anteriormente e que possivelmente foram
usados para tomar uma deciso. Se a validao da chamada reproduzida no for
transmitida, a reproduo ser anulada, e o erro original retornado.

Quando o Application Continuity Transparente?
O Application Continuity transparente para aplicaes

J2EE que:
Usam pools de conexes JDBC e Oracle padro
No tm aes externas ou tm aes externas e a correo
preservada na reproduo
Para situaes em que o Application Continuity no
transparente, as seguintes alteraes so normalmente
necessrias:
Os limites da solicitao so especificados com as APIs do
Application Continuity.
A API disableReplay usada para interromper
seletivamente a reproduo de chamadas que nunca
devero ser reproduzidas.
O Application Continuity transparente (executado automaticamente) para aplicaes J2EE

que usam JDBC padro e pools de conexes Oracle (UCP ou WLS Active GridLink). Para
aplicaes com aes externas (por exemplo, transaes autnomas ou que usem
UTL_HTTP para emitir uma chamada SOA), o Application Continuity ainda ser transparente
apenas se a correo da aplicao for preservada na reproduo dessas chamadas externas
aps uma falha.
Para outros cenrios nos quais o Application Continuity no for transparente, sero
necessrias as seguintes alteraes na infraestrutura:
Se o pool de conexes ou o container no usar um pool de conexes Oracle, a
aplicao dever usar as APIs do Application Continuity para marcar os limites das
solicitaes. Os limites das solicitaes so necessrios para recuperar a memria
usada para manter as chamadas e estabelecer um ponto no qual retomar a gravao
aps as operaes que no podem ser reproduzidas.
Se a aplicao tiver solicitaes que no devero ser repetidas, ela poder chamar
explicitamente uma API para desabilitar a reproduo para essas solicitaes. Essas
chamadas provavelmente sero isoladas a uma ou algumas partes especializadas de
cdigo de aplicao.

Benefcios do Application Continuity
Servio de usurio ininterrupto, quando a reproduo

bem-sucedida
Pode ajudar a realocar sesses de banco de dados nos
servidores restantes para interrupes planejadas
Aumenta a produtividade do desenvolvedor mascarando
interrupes que podem ser mascaradas
Poucas ou nenhuma alterao nas aplicaes
Configurao simples
Veja a seguir alguns benefcios do Application Continuity:

O servio de usurio ininterrupto quando a reproduo da solicitao bem-sucedida.
O Application Continuity pode ser usado para migrar as sesses do banco de dados
para os servidores restantes, sem que os usurios percebam a interrupo
Mascarar interrupes que possam ser mascaradas aumenta a produtividade do
desenvolvedor. O cdigo de tratamento de erros ser invocado com menos frequncia
e possvel simplific-lo.
A reproduo quase sempre requer poucas ou nenhuma alterao nas aplicaes
O Application Continuity simples de configurar.

Avaliao de Aplicaes para

Uso do Application Continuity
Decida O que Voc Deve Fazer
Limites da Solicitao Marque os limites da solicitao caso voc no esteja
usando Oracle Pools.
Classes Concretas Substitua as classes concretas descontinuadas por

JDBC interfaces Java.
Efeitos Colaterais Use a API disable se uma solicitao ao banco de dados

tiver uma chamada externa que no deva ser reproduzida.
Callbacks Garanta que um callback seja registrado se o estado for

alterado fora de uma solicitao (rtulo WLS/UCP includo
por default).
Funes Mutveis Conceda a manuteno de valores mutveis se forem

compatveis com a sua aplicao.
Antes de usar o Application Continuity com uma aplicao, o proprietrio dela dever verificar
o seguinte:
1. Marque os limites da solicitao se a aplicao no estiver usando Oracle Pools ou no
estiver liberando conexes a estes. Os limites da solicitao marcam o incio e o final
de cada solicitao. Determine se a aplicao empresta e retorna conexes do
WebLogic Server Pool ou do Universal Connection Pool para cada solicitao, ou se as
APIs beginRequest e endRequest devem ser adicionadas ao prprio pool de
conexes da aplicao para identificar os limites da solicitao. Se voc estiver usando
Oracle Pools, mas no estiver liberando conexes, considere suas opes de faz-lo.
2. Determine se a aplicao usa classes concretas Oracle JDBC. Para usar o Application
Continuity, as classes concretas descontinuadas devem ser substitudas. Para obter
informaes sobre a descontinuao de classes concretas, inclusive aes a serem
executadas se elas forem usadas por uma aplicao, consulte a Nota 1364193.1 do My
Oracle Support.
3. Avalie o impacto das restries e os efeitos colaterais em sua aplicao. Use a API
disableReplay para todas as solicitaes que no devero ser reproduzidas. Por
exemplo, se uma solicitao fizer chamadas externas por uma das aes de
mensagens PL/SQL externas, decida se a chamada externa dever ou no ser
reproduzida.

4. Avalie se a sua aplicao define o estado fora da solicitao ao banco de dados. Se um
estado for definido quando um usurio iniciar uma solicitao e estiver fora dessa
solicitao, a reproduo precisar saber disso a fim de executar novamente as
chamadas.
Ao usar o Oracle WebLogic Server ou o Universal Connection Pool, o rtulo da conexo
recomendado. O rtulo usado para o tempo de execuo e a reproduo.
Se voc usar o prprio callback de uma aplicao, registre-o no WebLogic Admin
Console, no Universal Connection Pool ou nos nveis do driver de reproduo JDBC.
5. Decida se a aplicao pode manter mutveis na reproduo. Quando uma solicitao
reproduzida, essa funo obtm um novo valor a cada vez que chamada. Mantenha
valores mutveis quando forem compatveis com a aplicao. Mantenha os valores
originais de seq.NEXTVAL, SYSDATE, SYSTIMESTAMP e SYS_GUID durante o failover.

Lidando com Limites da Solicitao
No
Adicione
Retorna Propriedade beginRequest,
UCP/
conexes ao a ser retornada endRequest para
WLS Sim pool No ao pool No identificar limites
da solicitao
Sim Sim
Concludo Definir propriedade

Incio a ser retornada
Concludo
Concludo
Os limites da solicitao so usados para marcar o incio e o final de cada solicitao. Eles
so necessrios para retomar a gravao aps uma operao no reproduzvel e tambm
para recuperar a memria usada para manter as chamadas.
O fluxograma mostra como decidir se os limites da solicitao devem ser adicionados:
1. Determine se a aplicao empresta e retorna conexes do WebLogic Server Pool ou do
Universal Connection Pool para cada solicitao, ou se as APIs beginRequest
e endRequest devem ser adicionadas ao prprio pool de conexes da aplicao para
identificar os limites da solicitao.
2. Se voc estiver usando Oracle Pools, mas no estiver liberando conexes para o pool,
quase sempre haver uma propriedade a ser definida para liberar conexes. A
liberao de conexes dimensiona muito melhor e incorpora automaticamente os
limites da solicitao. Isso permite o suporte a failover planejado ou no planejado e um
melhor balanceamento de carga.

Desabilitando a Reproduo por Meio da API

disableReplay
Use a API disableReplay para solicitaes que no
devem ser reproduzidas.
Tome uma deciso consciente de reproduzir aes
externas.
Transaes autnomas, UTL_HTTP, UTL_URL, UTL_FILE,
UTL_FILE_TRANSFER, UTL_SMTP, UTL_TCP, UTL_MAIL,
DBMS_PIPE e DBMS_ALERT
Alm disso, considere desabilitar a reproduo quando a
aplicao:
Sincronizar sesses independentes
Usar o tempo no middle-tier em uma execuo lgica
Supor que os valores ROWID no sofram alteraes
Supor que os valores de local no sofram alteraes
Por default, o driver JDBC faz reprodues aps um erro recupervel. Se a aplicao tiver
solicitaes que no devam ser repetidas, ela poder chamar explicitamente a
API disableReplay para desabilitar a reproduo nessas solicitaes.
Os desenvolvedores das aplicaes devem tomar uma deciso consciente em relao a
permitir a reproduo de aes externas e especialmente no caso de procedimentos que
usem o pacote UTL_HTTP. Se a reproduo delas no for permitida, use a API
disableReplay.
Alm disso, recomendvel que voc considere desabilitar a reproduo quando a
aplicao:
Sincronizar sesses independentes
Usar o tempo no middle-tier em uma execuo lgica
Supor que os valores ROWID no sofram alteraes
Supor que os valores de local no sofram alteraes
A razo disso que as suposies contidas nesses cenrios podero no ser vlidas
durante a reproduo, podendo produzir resultados incorretos. Para ler uma discusso mais
aprofundada sobre esses cenrios, consulte o captulo Ensuring Application Continuity do
Oracle Database Development Guide 12c Release 1 (12.1).

Opes de Inicializao de Conexes
Nenhum callback
A aplicao cria seu prprio estado durante cada solicitao.
Rtulo da conexo
O desempenho aperfeioado evitando-se alguma inicializao.
Disponvel com UCP ou WebLogic Server
O driver de reproduo usa o Connection Labeling quando
presente.
Callback de inicializao de conexes
O driver de reproduo usa callback para definir o estado
inicial da sesso no tempo de execuo e na reproduo.
Registre no WebLogic, no UCP e no
JDBC Thin.
NTSS (Nontransactional Session State) o estado de uma sesso do banco de dados

existente fora das transaes e no protegido pela recuperao. Para aplicaes que usam
solicitaes stateful, o estado no transacional restabelecido quando a sesso
reconstruda pelo Application Continuity.
No caso de aplicaes que definem o estado somente no incio de uma solicitao ou
aplicaes stateful que obtm benefcios de desempenho por meio do uso de conexes com
um estado predefinido, escolha uma das seguintes opes de callback:
Nenhum callback: neste cenrio, a aplicao cria seu prprio estado durante cada
solicitao.
Connection Labeling: Connection Labeling um recurso de pool genrico
recomendado por seu excelente desempenho. Quando h o Connection Labeling, ele
usado pelo Application Continuity. O Connection Labeling um recurso do UCP
(Universal Connection Pool) e do Oracle WebLogic Server. A aplicao pode ser
modificada para tirar proveito do estado predefinido nas conexes. As APIs do
Connection Labeling determinam o nvel de correspondncia de uma conexo e usam o
callback de rtulo para preencher a lacuna no caso de emprstimos de conexo. Nem
todas as aplicaes podem usar o Connection Labeling, porque o recurso exige algum
grau de recodificao da aplicao.

Callback de inicializao de conexes: neste cenrio, o driver de reproduo usa um
callback de aplicao para definir o estado inicial da sesso durante o tempo de
execuo e a reproduo. O driver JDBC fornece uma interface de callback de
inicializao de conexes opcionais e mtodos para registrar e cancelar o registro dos
callbacks na interface oracle.jdbc.replay.OracleDataSource.
Quando registrado, o callback de inicializao executado em cada check-out bem-sucedido
e em cada reconexo aps um erro recupervel. Se ocorrerem falhas na invocao do
callback, a reproduo ser desabilitada nessa conexo. Use o callback de inicializao de
conexes somente quando a aplicao no tiver implementado o Connection Labeling e
precisar de informaes sobre o estado no estabelecidas na solicitao.
O registro de callback realizado por meio do WebLogic Admin Console, no UCP, ou no
driver de reproduo JDBC Thin.

Objetos Mutveis e o Application Continuity
possvel que as solicitaes que usam funes mutveis

no sejam reproduzidas corretamente se o resultado da
funo for alterado.
Quando um privilgio mutvel concedido, a reproduo
aplicada ao resultado da funo original.
Funo Mutvel Aplicao A Aplicao B Aplicao C
SYSDATE, Original Atual No Aplicvel

SYSTIMESTAMP
SEQUENCE.NEXTVAL, Original Original Atual
SEQUENCE.CURRVAL
SYS_GUID Original No Aplicvel No Aplicvel
Objeto mutvel uma funo que obtm um novo valor toda vez que chamada. Uma
chamada para a funo SYSTIMESTAMP um exemplo de funo mutvel. Quando uma
solicitao reproduzida, o tratamento desejado e o default dos objetos mutveis podem
variar. As aplicaes que usam o Application Continuity podem determinar se os valores
originais das funes mutveis sero mantidos se a solicitao for reproduzida.
O suporte para a manuteno de valores de objetos mutveis atualmente fornecido para
SYSDATE, SYSTIMESTAMP, SYS_GUID e SEQUENCE.NEXTVAL. Se os valores originais no
forem mantidos e se valores diferentes para esses objetos mutveis forem retornados ao
cliente, a reproduo ser rejeitada porque o cliente ver resultados diferentes.
A tabela exibida no slide mostra exemplos de diferentes abordagens que aplicaes distintas
podem usar para objetos mutveis. Nenhuma abordagem recomendada em detrimento da
outra. Elas so apresentadas apenas para ilustrar algumas das possibilidades que podem
existir.

Mantendo Objetos Mutveis para Reproduo
Comandos SQL:
SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] TO <user>;
SQL> REVOKE [KEEP DATE TIME | KEEP SYSGUID] FROM <user>;
SQL> GRANT KEEP SEQUENCE ON <sequence_name> TO <user>;
SQL> REVOKE KEEP SEQUENCE ON <sequence_name> FROM <user>;
SQL> CREATE SEQUENCE <sequence_name> [KEEP|NOKEEP];
SQL> ALTER SEQUENCE <sequence_name> [KEEP|NOKEEP];
Exemplos:
SQL> CREATE SEQUENCE new_seq KEEP;
SQL> ALTER SEQUENCE existing_seq KEEP;
SQL> GRANT KEEP SEQUENCE on sales.seq1 TO user2;
SQL> GRANT KEEP DATE TIME TO user2;
SQL> GRANT KEEP SYSGUID TO user2;
O slide mostra os comandos SQL que podem ser usados para configurar objetos mutveis
para reproduo. As seguintes observaes fornecem mais informaes:
O usurio do banco de dados que executa a aplicao pode ter os privilgios KEEP
DATE TIME e KEEP SYSGUID concedidos, e o privilgio de objeto KEEP SEQUENCE
em cada sequncia cujos valores devem ser mantidos. Observe que esses privilgios
no podem ser concedidos por meio de GRANT ALL ON <object>. Alm disso, no
recomendvel conceder privilgios de DBA a usurios de bancos de dados que
executam aplicativos para os quais voc deseja habilitar a reproduo. Conceda
somente os privilgios necessrios para esses usurios.
possvel definir sequncias com o atributo KEEP, que mantm os valores originais de
SEQUENCE.NEXTVAL para o proprietrio da sequncia. Observe que a especificao
de KEEP ou NOKEEP com CREATE SEQUENCE ou ALTER SEQUENCE aplicvel ao
proprietrio da sequncia.
Se os privilgios concedidos forem revogados entre o tempo de execuo e o failover,
os valores mutveis coletados no sero aplicados para reproduo.
Se os novos privilgios forem concedidos entre o tempo de execuo e o failover, os
valores mutveis no sero coletados e, portanto, no podero ser aplicados para
reproduo.

Configurando a Fonte de Dados de

Reproduo JDBC
Use a fonte de dados
oracle.jdbc.replay.OracleDataSourceImpl para
obter conexes JDBC.
Configure a fonte de dados no arquivo de propriedade
para o UCP ou o WebLogic Server.
Referencie a fonte de dados nas aplicaes JDBC Thin.
Para usar o Application Continuity para Java, necessrio usar a fonte de dados
oracle.jdbc.replay.OracleDataSourceImpl para obter conexes JDBC. Essa fonte
de dados suporta todas as propriedades e os parmetros de configurao de todas as fontes
de dados Oracle JDBC (por exemplo, oracle.jdbc.pool.OracleDataSource).
Voc pode configurar a fonte de dados de reproduo alterando a propriedade de fonte de
dados para o Universal Connection Pool ou definindo-a pelo WebLogic Console. Tambm
possvel definir a fonte de dados de reproduo para aplicaes JDBC Thin no arquivo de
propriedade ou diretamente na aplicao.

Criando Servios para o Application Continuity
Para criar um servio para o Application Continuity em

um banco de dados RAC gerenciado por polticas:
$ srvctl add service -db racdb -service app2
serverpool Srvpool1
-failovertype TRANSACTION Definies Obrigatrias
-commit_outcome TRUE para o Application Continuity
-replay_init_time 1800 -failoverretry 30 -failoverdelay 10

-retention 86400 Definies Opcionais para o Application Continuity
-notification TRUE -rlbgoal SERVICE_TIME -clbgoal SHORT
Para modificar um servio existente no Application

Continuity:
$ srvctl modify service -db racdb -service app1 -clbgoal SHORT
-rlbgoal SERVICE_TIME -failoverretry 30 -failoverdelay 10
-failovertype TRANSACTION -commit_outcome TRUE
-replay_init_time 1800 -retention 86400 -notification TRUE
Para usar o Application Continuity, defina os seguintes atributos de servio obrigatrios:

-FAILOVERTYPE=TRANSACTION para habilitar o Application Continuity
-COMMIT_OUTCOME=TRUE para habilitar o Transaction Guard
Adicionalmente, voc pode definir valores desses outros parmetros de servio para o
Application Continuity e o balanceamento de carga:
-REPLAY_INIT_TIME: essa definio especifica o nmero de segundos em que a
reproduo dever ser iniciada. Se a reproduo no for iniciada no tempo
especificado, ela ser abandonada. A Oracle recomenda que voc escolha um valor
baseado na durao de tempo que voc permitir que a reproduo seja iniciada. O
valor default 300 segundos.
-RETENTION: essa definio especifica o nmero de segundos durante os quais o
resultado da confirmao armazenado no banco de dados. O padro 86400 (24
horas), e o mximo 2592000 (30 dias).
Aps a execuo de um COMMIT, se o estado da sesso for alterado nessa transao,
ento no ser possvel reproduzir a transao para restabelecer esse estado se a
sesso for perdida. Ao configurar o recurso Application Continuity, as aplicaes sero
categorizadas dependendo do estado da sesso aps a configurao inicial, ou seja, se
esttico ou dinmico, e, dessa forma, se correto o prosseguimento aps uma
operao COMMIT em uma solicitao.

- DYNAMIC: (padro) Uma sesso tem um estado dinmico se as alteraes do
estado da sesso no forem totalmente encapsuladas pela inicializao, e no
puderem ser totalmente capturadas em um callback no failover. Assim que a
primeira transao em uma solicitao for confirmada, o failover desativado
internamente at que comece a prxima solicitao. Este o modo padro que
praticamente todos os aplicativos devem usar para as solicitaes.
- STATIC: (especialconforme solicitao) Uma sesso tem um estado esttico se
todas as alteraes dos estados da sesso, como as configuraes NLS e o estado
do pacote PL/SQL, puderem ser repetidos em um callback de inicializao. Esta
configurao usada apenas em aplicaes de diagnstico de banco de dados que
no alterem o estado da sesso. No especifique STATIC se no houver nenhuma
alterao no estado no transacional na solicitao que no puder ser restabelecida
por um callback. Se voc no tiver certeza de qual estado especificar, use
DYNAMIC.
-FAILOVERRETRY: essa definio especifica o nmero de tentativas de conexo para
cada tentativa de reproduo. Se a reproduo no for iniciada no nmero de tentativas
especificado, ela ser abandonada. A Oracle recomenda um valor de 30.
-FAILOVERDELAY: essa definio especifica o atraso em segundos entre as tentativas
de conexo. A Oracle recomenda um valor de 10.
-NOTIFICATION: A FAN altamente recomendadodefina este valor como TRUE para
habilitar a FAN em clientes OCI e ODP.Net
-CLBGOAL: No balanceamento de carga de conexes, use SHORT ao usar o
balanceamento de carga de runtime.
-RLBGOAL: No balanceamento de carga de runtime, defina para SERVICE_TIME.

Criando Servios para o Transaction Guard

Para criar um servio usando o Transaction Guard mas no
o Application Continuity:
$ srvctl add service -db racdb -service app3
serverpool Srvpool1
-commit_outcome TRUE Definies Obrigatrias para o Transaction Guard
-retention 86400 -failoverretry 30 -failoverdelay 10

notification TRUE -rlbgoal SERVICE_TIME -clbgoal SHORT
Para modificar um servio existente para ativar o

Transaction Guard:
$ srvctl modify service -db racdb -service app4
-commit_outcome TRUE -retention 86400
-notification TRUE
Para usar o Transaction Guard, um DBA deve conceder

permisso:
SQL> GRANT execute ON DBMS_APP_CONT;
Para ativar o Transaction Guard, mas no o Application Continuity, crie o servio usando
SRVCTL e defina apenas -commit_outcome como TRUE.
Voc pode usar o SRVCTL para modificar um servio existente para que ative o Transaction
Guard, similar ao seguinte comando, em que racdb o nome do seu banco de dados Oracle
RAC, e app2 o nome do servio que voc est modificando:
$ srvctl modify service -db racdb -service app2 -commit_outcome TRUE
-retention 86400 -notification TRUE
No exemplo anterior, o parmetro -retention especifica quanto tempo, em segundos
manter o histrico. Adicionalmente, o parmetro notification definido como TRUE,
ativando os eventos FAN. Para usar o Transaction Guard, um DBA deve conceder
permisso, como se segue:
GRANT EXECUTE ON DBMS_APP_CONT;

Requisitos de Recursos para o

Cliente Java
Aumenta a memria para manter as filas de reproduo.

A CPU adicional consumida para coleta de lixo e para criar

proxies.
Servidor do banco de dados
A CPU adicional necessria para validao.
O overhead de CPU mnimo em CPUs Intel e SPARC atuais,
nas quais a validao assistida no hardware.
Transaction Guard
Incorporado ao Kernel de Banco de Dados
Overhead mnimo
Excelente escalabilidade
O Application Continuity tem os seguintes requisitos de recursos:

CPU: o Application Continuity funciona no servidor de banco de dados e no cliente da
aplicao e precisa de recursos adicionais de CPU para funcionar. O Application
Continuity consome recursos de CPU no servidor de banco de dados para executar a
validao durante a reproduo. Observe que o overhead de CPU reduzido em
plataformas com CPUs Intel e SPARC atuais, nas quais a validao assistida no
hardware (por meio de CRCs [Cyclic Redundancy Checks]). No lado do cliente, o
Application Continuity usa alguns recursos de CPU acima do driver base. Os custos de
CPU adicionais so incorridos para criar objetos de proxy e coleta de lixo.
Memria: o driver de reproduo JDBC requer mais memria do que o driver base
porque as chamadas so retidas at o final de uma solicitao. Ao final da solicitao,
as chamadas so liberadas para o coletor de lixo. Essa ao difere do driver base, que
libera as chamadas encerradas.
O consumo de memria do driver de reproduo depende do nmero de chamadas por
solicitao. Se esse nmero for pequeno, o consumo de memria adicional do driver de
reproduo ser menor e comparvel ao driver base.
Para obter o melhor desempenho, defina o mesmo valor para os parmetros -Xmx e -Xms no
cliente. Isso define os tamanhos de heap inicial e mximo como o mesmo tamanho,
garantindo que o desempenho do JVM no seja afetado por tentativas que usem definies
inferiores.
Questionrio
O Application Continuity tenta mascarar interrupes

recuperveis do banco de dados de aplicaes e usurios
por meio da restaurao das sesses e da reproduo de
chamadas do banco de dados.
a. Verdadeiro
b. Falso
Resposta: a

Questionrio
Qual destas fases no do Application Continuity?

a. Tempo de Execuo
b. Reproduo
c. Reconexo
d. Restaurao
Resposta: d

Questionrio
Selecione as afirmaes aplicveis ao Application Continuity:

a. O Application Continuity suportado com os clientes thin
JDBC.
b. O banco de dados de destino da reproduo deve ter o
mesmo ID de banco de dados, antecessores e
descendentes que o banco de dados de origem.
c. A reproduo no ser suportada se a transao executar
a instruo ALTER SYSTEM ou ALTER DATABASE.
d. A reproduo suportada para aplicaes desenvolvidas
com o Oracle XA.
e. A reproduo ser suportada se voc estiver usando o
Active Data Guard com links de um banco de dados de
leitura/gravao para outro banco de dados.
Resposta: a, b, c

Sumrio

Descrever a finalidade dos recursos Transaction Guard e
Descrever os principais conceitos relacionados ao recurso
Descrever os efeitos colaterais e as restries
relacionados ao recurso Application Continuity
Descrever os requisitos para desenvolver aplicaes que
tirem proveito do recurso Application Continuity
Configurar o recurso Application Continuity

Viso Geral do Exerccio 9:

Usando o Application Continuity
Este exerccio aborda o uso do Application Continuity em um
banco de dados RAC para demonstrar como o recurso ajuda
uma aplicao a se recuperar perfeitamente aps a falha de
uma instncia do RAC.

Patches ao Oracle RAC

Fazendo o Upgrade e Aplicando
Objetivos

Descrever os tipos de patches disponveis
Planejar patches e upgrades dinmicos
Instalar um conjunto de patches com o utilitrio OUI
(Oracle Universal Installer)
Instalar um patch com o utilitrio opatch

Viso Geral dos Patches e Conjuntos de Patches
A Oracle lana correes de produtos para seu software,

denominados patches.
Os patches so associados a releases e verses
especficas dos produtos Oracle.
O ciclo de patches envolve o download, utilizao e
verificao do patch aplicado.
A elaborao de um patch requer a migrao de uma verso
do produto do software para outra, em uma release
especfica.
Quando um patch utilizado em uma instalao de software
Oracle, ele atualiza os arquivos executveis, bibliotecas e
arquivos de objetos no diretrio home do software.
O aplicativo de patch tambm pode atualizar os arquivos de
configurao e os esquemas SQL fornecidos pela Oracle.
A Oracle lana correes de produtos para seu software, denominados patches. Os patches
so associados a releases e verses especficas dos produtos Oracle. O ciclo do patch
envolve o download, a aplicao e a verificao do patch aplicado para garantir que as
correes dos erros presentes no patch sejam refletidas da forma adequada.
A elaborao de patches envolve a migrao de uma verso do produto de software para
outro, em uma release especfica, ao contrrio do upgrade que requer a mudana de uma
release de um produto para outra release mais recente do produto de software. Quando um
patch utilizado em uma instalao de software Oracle, ele atualiza os arquivos executveis,
bibliotecas e arquivos de objetos no diretrio home do software. O aplicativo de patch
tambm pode atualizar os arquivos de configurao e os esquemas SQL fornecidos pela
Oracle.

Tipos de Patches
Tipo de Patch Descrio
Patches Provisrios Lanado para corrigir um bug, ou um conjunto de bugs.
Anteriormente chamados excees de conjuntos de patches
(PSE), patches one-off (nicos) ou hot fixes (atualizaes de
reparos).
Patches Provisrios Lanados para fornecer reparos especficos para a segurana
(para correes de bugs do cliente. Anteriormente denominados como um patch de
de Segurana) teste, binrio de verificao de reparo ou e-fix.
Patches de Basicamente ajudam a diagnosticar e verificar uma correo, ou
Diagnstico um conjunto de correes de erros
Atualizaes de Conjunto cumulativo de correes para um produto ou
Pacotes de Patches componente especfico. Anteriormente denominado como
pacote de manuteno, pacote de servios, patch cumulativo,
release de atualizao ou MLR.
Atualizaes dos Pacotes de patches cumulativos que contm correes de bugs
Conjuntos de Patches comprovadas e bem testadas em questes crticas. As PSUs
(PSU) possuem novo contedo limitado e no incluem nenhuma
alterao que requeira recertificao.
Atualizaes de Um conjunto cumulativo de correes de erros de segurana
Patches de Segurana
Os patches provisrios so correes de erros disponveis para clientes em resposta a bugs

especficos. Eles demandam uma release ou conjunto de patches de base especfico,
instalado antes para que voc possa utiliz-los. Esses patches no passam por controle de
verso e, geralmente, esto disponveis em um conjunto de patches futuros bem como na
release do prximo produto. Os patches provisrios so utilizados com o Enterprise Manager
Cloud Control ou OPatch, incluso com a instalao do Oracle Database.
As atualizaes de conjuntos de patches (PSUs) e pacotes de patches so mecanismos para
entregar correes de produtos totalmente testadas e integradas. Todas as correes em um
conjunto de patches foram testadas e so certificadas para funcionar entre si. Como um
conjunto de patches inclui somente patches de baixo impacto, ele no requer que voc
certifique aplicaes ou ferramentas com o software atualizado Oracle Database. Quando
voc aplica um conjunto de patches, muitos arquivos e utilitrios so modificados. Isto resulta
em uma alterao no nmero da release do seu software Oracle. Voc utiliza o OPatch para
aplicar as PSUs e o OUI para instalar os conjuntos de patches. As PSUs so instaladas de
forma dinmica, o que no ocorre com os conjuntos de patches.

Configurando a Biblioteca de Software
Use a pgina Provisioning do Enterprise Manager.

Adicione um local para a biblioteca de software:
Para usar os recursos de patch do Enterprise Manager, configure um local para a biblioteca
de software. Voc pode ter mais de um local de biblioteca. Ele ser o diretrio no qual os
patches sero armazenados quando forem transferidos ao cluster local.
Para navegar at a pgina Provisioning a partir da home page Cluster Database:
1. Selecione Patching and Provisioning, depois Software Library no menu pull-down
Enterprise.
2. Selecione Administration no menu pull-down Actions.
3. Clique em Add na pgina Software Library: Administration ou selecione Add no menu
pull-down Actions.
Fornea um nome relevante para o local, bem como o caminho total do diretrio (Location). A
localizao do diretrio da biblioteca de software deve fazer referncia a um diretrio
existente.

Obtendo Patches para o Oracle RAC
possvel efetuar o download dos conjuntos de patches mais recentes e dos BPs
recomendados do site My Oracle Support Web, na seguinte URL:
http://support.oracle.com/
Aps fazer login no site da Web, clique na tab "Patches & Updates". Para obter os conjuntos
e pacotes de patches mais recentes, clique no link "Latest Patchsets", em Oracle Servers and
Tools. Voc pode escolher entre conjuntos de patches para pacotes de produtos ou pacotes
de patches para produtos individuais.
Se voc souber o nmero do conjunto de patches, clique no link Number/Name Sun CR ID.
Voc pode informar o nmero de um nico conjunto de patches ou uma lista separada por
vrgula. Selecione a plataforma e clique no boto Search.

Para obter uma lista completa de conjuntos de patches disponveis para a sua verso e
plataforma, clique no link Product or Family.
Aps especificar o produto, a release e a plataforma, clique no boto Search. Os resultados
da pesquisa sero exibidos.

Para localizar os conjuntos de patches recomendados, inicie na tab "Patches & Updates" e
clique no link Recommended Patch Advisor. Selecione Oracle Clusterware no menu pull-
down Product e, em seguida, o nmero da release e a plataforma. Clique no boto Search
para obter uma lista de conjuntos de patches recomendados.

Fazendo Download de Patches
Aps localizar o patch necessrio, voc poder transferi-lo por download. Clique no link do
patch, na pgina de resultados da pesquisa. Localize e clique no link Download da pgina de
resumo de patches e, em seguida, clique no link do patch, na caixa de dilogo File
Download. Clique no boto Save File e, em seguida, clique em OK. Especifique o local do
diretrio para o arquivo e, em seguida, clique em Save.

Instalao de Patches com Indisponibilidade

Reduzida para Ambientes de Cluster
possvel efetuar a instalao de patches no Oracle RAC sem
desativar o cluster inteiro.
O OPatch pode aplicar vrios patches e em diversos ns.
OPatch detecta se o esquema de banco de dados est em
um nvel de patch mais antigo do que o novo patch e
executa comandos SQL para atualizar o esquema para o
novo nvel de patch.
O OUI instala conjuntos de patches como upgrades fora
do local, reduzindo a indisponibilidade necessria para a
aplicao dos patches.
possvel efetuar a instalao de patches no Oracle RAC sem desativar o cluster inteiro. Em
muitos casos, a aplicao de patches pode ser efetuada sem nenhuma indisponibilidade.
Isso tambm permite upgrades fora do local ao software de cluster e ao Oracle Database,
reduzindo a indisponibilidade da manuteno planejada, necessria em um ambiente Oracle
RAC.
Agora, o OPatch pode aplicar vrios patches e em diversos ns. O OPatch no inicializar as
instncias que tenham um patch no dinmico aplicado se outras instncias do banco de
dados no tiverem o patch em questo. OPatch tambm detecta se o esquema de banco de
dados est em um nvel de patch mais antigo do que o novo patch e executa comandos SQL
para atualizar o esquema para o novo nvel de patch.
Como preparao para a instalao do patch, voc pode usar srvctl para fazer shutdown
do software Oracle em execuo em um Oracle home. A aplicao de patches do Oracle
Grid Infrastructure automtica entre todos os ns, e vrios patches podem ser instalados
em diversos ns.
Agora, os conjuntos de patches so instalados como upgrades fora do local ao software Grid
Infrastructure (Oracle Clusterware e Automatic Storage Management) e ao Oracle Database.
Esse procedimento reduz a indisponibilidade exigida pelas interrupes planejadas para
aplicao de patches.

Patches Dinmicos
possvel aplicar um patch dinmico a um n por vez, enquanto

outros ns continuam a fornecer servio. Isso:
Requer homes distintos de software para cada n
Permite que verses diferentes coexistam temporariamente
Pode no estar disponvel para todos os patches
Software no compartilhado Software compartilhado
ORACLE HOME HOME DO GRID N 1

ORACLE HOME
N 1 N 2 N 2
Armazenamento Armazenamento Armazenamento CFS

FS local FS local compartilhado
possvel que patches dinmicos sejam Todos os ns devem receber

permitidos, dependendo do patch. patches simultaneamente.
Um patch dinmico permite que um n receba o patch para a verso mais recente, enquanto
outros ns continuam a usar a verso mais antiga e a fornecer servio de negcios. Essa
metodologia mais adequada quando voc est aplicando patches nicos que suportam a
metodologia dinmica, mantendo a alta disponibilidade de seus destinos, de forma que, ao
aplicar o patch a um n, os outros permaneam disponveis para servio.
Os patches dinmicos so ativados por meio do uso de um sistema de arquivos localmente
acessvel e no compartilhado para armazenar os arquivos de software. No possvel
aplicar patches dinmicos quando os arquivos de software Oracle esto armazenados em um
sistema de arquivos clusterizados compartilhado no qual uma nica cpia do software
compartilhada entre todos os ns. Uma nica cpia requer muito menos espao em disco e
h apenas uma cpia para aplicar patch ou fazer upgrade. No entanto, para aplicar patch ou
fazer upgrade, necessrio interromper o software. A interrupo do software Oracle
Clusterware tambm requer a interrupo de todos os bancos de dados, aplicaes e
servios que dependem do Oracle Clusterware. Para aplicar o patch ou fazer upgrade, essa
tcnica requer uma interrupo completa do funcionamento com um perodo de
indisponibilidade (downtime).
Observao: um conjunto de patches que pode ser aplicado de forma dinmica para o
clusterware talvez no o seja para o RDBMS.

Upgrades de Banco de Dados Fora do Local

Para que seja possvel fazer upgrade do Oracle Database,
necessrio instalar o software da nova release do produto.
O software instalado em um novo Oracle Home usando o OUI.
O Database Upgrade Assistant usado para concluir o processo
de upgrade.
Instalando um Conjunto de Patches Dinmico com o OUI

Para que seja possvel fazer upgrade do Oracle Database, necessrio instalar o software
da nova release do produto. O procedimento de instalao instala o software Oracle em um
novo Oracle home. Esse procedimento denominado upgrade fora do local e diferente dos
lanamentos de conjuntos de patches para releases anteriores do Oracle, em que o patchset
sempre foi instalado no local. O novo software Oracle Database instalado por meio do
Oracle Universal Installer. O processo de upgrade concludo pelo Oracle Database
Upgrade Assistant.

Upgrade de Banco de Dados Fora do

Local com o OUI
1. Faa upgrade do Grid Infrastructure primeiro, se
necessrio.
2. Siga as instrues contidas na documentao da Oracle
especfica ao seu sistema operacional, a fim de preparar-
se para a instalao do software Oracle Database.
3. Use o OUI para instalar o software Oracle Database.
4. Execute a Pre-Upgrade Information Tool e corrija todas as
deficincias relatadas.
SQL> @NEW_ORACLE_HOME/rdbms/admin/preupgrd.sql
5. Execute o script root.sh conforme instrudo pelo OUI.

6. Conclua o processo de upgrade com o DBUA.
Se voc estiver fazendo upgrade de um banco de dados Oracle RAC, dever executar estas
etapas:
1. Faa upgrade do Grid Infrastructure em seu cluster, se necessrio.
2. Siga as instrues contidas na documentao da Oracle especfica ao seu sistema
operacional, a fim de preparar-se para a instalao do software Oracle Database.
3. Inicie o Oracle Universal Installer. Selecione "Upgrade an existing database" na pgina
Select Installation Option.
4. recomendvel que voc execute a Pre-Upgrade Information Tool antes de fazer
upgrade com o DBUA. Dessa forma, possvel visualizar os tipos de itens verificados
pelo DBUA. O OUI executar o DBUA aps a execuo dos scripts da raiz, mas voc
pode optar por executar o DBUA posteriormente. Para usar a ferramenta, inicie o
SQL*Plus, conecte-se instncia do banco de dados como um usurio com privilgios
SYSDBA e execute o script preupgrd.sql.
SQL> @NEW_ORACLE_HOME/rdbms/admin/preupgrd.sql
Se Oracle_Base estiver definido, ento os scripts e arquivos de logs gerados so
criados em Oracle_Base/cfgtoollogs/. Se Oracle_Base no estiver definido,
ento os scripts e arquivos de logs gerados so criados em
ORACLE_HOME/cfgtoollogs/.
5. Execute o script root.sh conforme instrudo pelo OUI. Se estiver pronto, use o DBUA
para concluir o processo de upgrade.
OPatch: Viso Geral
O OPatch um utilitrio que lhe orienta no processo de

aplicar patches provisrios no software Oracle.
O OPatch um utilitrio baseado em Java que permite a
aplicao e o rollback de patches temporrios.
O OPatch includo na instalao do Oracle Clusterware
12c.
Em ambientes grandes de TI, o recurso de automao de
patches do EM Cloud Control pode simplificar o processo
de utilizao de patches.
O OPatch um utilitrio fornecido pela Oracle que lhe orienta no processo de aplicar patches
provisrios no software Oracle. O Opatch um utilitrio baseado em Java que pode ser
executado em Oracle homes ou edies caseiras independentes, baseados em OUI. Ele
funciona em todos os sistemas operacionais para os quais a Oracle lana software. O
OPatch includo na instalao do Oracle Clusterware 12c.
Em ambiente de TI de larga escala, a aplicao de patches em homes individuais
GI/RAC/DB pode no ser prtico, j que a aplicao de patches em grandes quantidades de
destinos manualmente montono e pode gerar erros. Para manter e implantar patches da
Oracle em muitos destinos na sua organizao, voc pode usar o recurso de automao de
patches do Enterprise Manager Cloud Control.

OPatch: Uso Geral
Para definir o ORACLE_HOME ou a opo oh em todos os

comandos:
$ export ORACLE_HOME=/u01/app/12.1.0/grid
$ opatch command [options]
ou
$ opatch command oh /u01/app/12.1.0/grid [options]
Para obter ajuda com a sintaxe do OPatch:

$ opatch command help
Para verificar se um patch suporta a aplicao dinmica

(execute a partir do diretrio patch):
$ opatch query -all | grep i Rolling
o utilitrio opatch requer que a varivel do ambiente ORACLE_HOME seja definida ou que o
valor de ORACLE_HOME seja transmitido como um argumento na linha de comandos com a
opo oh. No caso do Oracle Clusterware, ORACLE_HOME refere-se ao diretrio de
instalao do Oracle Clusterware, no ao local em que outros produtos Oracle possam estar
instalados. Em geral, ORACLE_HOME refere-se ao home do produto a receber o patch.
A documentao do OPatch pode ser encontrada no diretrio Grid_home/OPatch/docs. O
utilitrio fornece ajuda relativa sua sintaxe. Para acess-la, use a opo help da seguinte
forma:
opatch -help
opatch apply -help
opatch lsinventory -help
opatch rollback -help
opatch prereq -help
opatch util help
Em geral, os BPs e os patches MLR do CRS podem ser aplicados de forma dinmicaou
seja, um n por vez. No entanto, ainda importante verificar se h excees a essa regra em
cada patch. Para verificar se um patch suporta aplicaes dinmicas, descompacte o patch
transferido por download em um diretrio de sua escolha e, a partir desse diretrio, execute o
seguinte comando:
$ORACLE_HOME/OPatch/opatch query -is_rolling_patch <patch_location>
Antes de Aplicar Patches com o OPatch
Verifique a definio atual da varivel ORACLE_HOME.

Faa backup do diretrio que estiver recebendo o patch
com um utilitrio do sistema operacional ou com o
Oracle Secure Backup.
Prepare o patch para cada n.
Atualize a varivel de ambiente PATH para o diretrio
OPatch.
O utilitrio de aplicao de patches da Oracle, o OPatch, verifica se a varivel de ambiente

ORACLE_HOME indica um diretrio real. Voc deve verificar se a varivel ORACLE_HOME est
definida como o Oracle home do produto ao qual voc est tentando aplicar o patch.
a melhor prtica fazer backup do diretrio do software ao qual voc est aplicando o patch
antes de executar qualquer operao de aplicao de patches. Isso se aplica aos diretrios
de instalao do software Oracle RAC, ASM ou Oracle Clusterware. O backup tambm deve
incluir o diretrio Oracle Inventory.
Se voc fizer download do patch manualmente e usar o OPatch para instal-lo, dever
preparar o patch em cada n. Se voc usar o Enterprise Manager para fazer download do
patch e tiver selecionado todos os ns do cluster como destinos do patch, ele ser
automaticamente preparado nesses ns.
O arquivo binrio opatch est localizado no diretrio $ORACLE_HOME/OPatch. Voc pode
especificar esse caminho ao executar o OPatch ou pode atualizar a varivel de ambiente
PATH para incluir o diretrio OPatch. Para alterar a varivel PATH no Linux, use:
$ export PATH=$PATH:$ORACLE_HOME/OPatch

Automao do OPatch
O OPatch automatizou a aplicao de patches aos homes do

Oracle Grid Infrastructure e do banco de dados Oracle RAC.
As configuraes existentes so consultadas, e as etapas
necessrias aplicao de patches a cada home do banco de
dados Oracle RAC da mesma verso e ao home do Grid so
automticas.
O utilitrio dever ser executado por um usurio do sistema
operacional com privilgios de raiz.
O OPatch dever ser executado em cada n do cluster se o
home do Grid ou do RAC estiver em armazenamento no
compartilhado.
Uma chamada do OPatch pode aplicar patches ao home do
Grid, a um ou mais homes do RAC ou aos homes do Grid e do
banco de dados Oracle RAC da mesma verso de release.
O OPatch automatizou a aplicao de patches aos homes do Oracle Grid Infrastructure e do

banco de dados Oracle RAC. Ele funciona consultando as configuraes existentes e
automatizando as etapas necessrias aplicao de patches a cada home do banco de
dados Oracle RAC da mesma verso e ao home do GI.
O utilitrio deve ser executado por um usurio do sistema operacional com privilgios de raiz
(em geral, o usurio root) e, se o home do Grid Infrastructure ou do banco de dados Oracle
RAC estiver em armazenamento no compartilhado, ele dever ser executado em cada n
do cluster. O utilitrio no dever ser executado paralelamente nos ns do cluster.
Dependendo das opes especificadas da linha de comandos, uma chamada do OPatch
poder aplicar patches ao home do GI, a um ou mais homes do banco de dados Oracle RAC
ou aos homes do GI e do banco de dados Oracle RAC da mesma verso de release. Voc
tambm pode fazer rollback do patch com a mesma seletividade.

Exemplos de Automao do OPatch
Para aplicar patches ao home do Grid e a todos os homes

do banco de dados Oracle RAC da mesma verso:
# opatchauto apply <UNZIPPED_PATCH_LOCATION> <Grid_home>
-ocmrf <ocm_response_file>
Para aplicar patches somente ao home do GI:

# opatchauto apply <UNZIPPED_PATCH_LOCATION> -oh
<Grid_home> -ocmrf <ocm_response_file>
Para aplicar patches a um ou mais homes do banco de

dados Oracle RAC:
# opatchauto apply <UNZIPPED_PATCH_LOCATION> -database
db1, db2 -ocmrf <ocm_response_file>
Se voc no tiver instalado o OCM (Oracle Configuration Manager), o utilitrio OPatch pedir
o seu arquivo de resposta do OCM quando ele for executado. Voc dever especificar o
caminho completo do arquivo de resposta do OCM se j o tiver criado no seu ambiente. Se
voc no tiver o arquivo de resposta do OCM (ocm.rsp), execute o comando emocmrsp
para cri-lo. Como proprietrio do home do software, execute:
$ <ORACLE_HOME>/OPatch/ocm/bin/emocmrsp
Antes de executar o OPatch, adicione o diretrio que contm o OPatch ao seu caminho:
# export PATH=$PATH:<GI_HOME>/Opatch
Para aplicar patches ao home do GI e a todos os homes do banco de dados Oracle RAC da
mesma verso:
# <Grid_home>/OPatch/opatchauto apply <Grid_home> -ocmrf <ocm_response_file>
Para aplicar patches somente ao home do GI:
# <Grid_home>/OPatch/opatchauto apply <SYSTEM_PATCH_TOP_DIR> -oh <Grid_home>
Para aplicar patches a um ou mais bancos de dados Oracle RAC e homes associadas
GI/RAC:
# opatchauto apply <UNZIPPED_PATCH_LOCATION> -database db1, db2

Para fazer rollback do patch do home do GI e de cada home do banco de dados do Oracle
RAC:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION> -ocmrf
<ocm_response_file>
Para fazer rollback do patch do home do GI:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION> -oh <Grid_home>
Para fazer rollback do patch de um ou mais homes do banco de dados Oracle RAC:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION> -database db1, db2

Arquivos de Log e Rastreamento do OPatch
O OPatch mantm logs para as operaes de aplicao,

rollback e lsinventory.
Os arquivos de Log do OPatch esto situados em
ORACLE_HOME/cfgtoollogs/opatch
Cada arquivo de log est marcado com o timestamp da
operao.
Sempre que voc executar o OPatch, um novo arquivo de
log criado.
O OPatch mantm um ndice de comandos e arquivos de
log processados no arquivo opatch_history.txt.
O registro em logs e o rastreamento representam um auxlio comum para a depurao. O

OPatch mantm logs para as operaes de aplicao, rollback e lsinventory. Os arquivos de
log do OPatch esto situados em Oracle_home/cfgtoollogs/opatch. Cada arquivo de
log est marcado com o timestamp da operao. Os arquivos de log so denominados
opatch_mm-dd-yyyy_hh-mm-ss.log, onde mm-dd-yyyy a data atual e hh-mm-ss a
hora atual. Sempre que voc executar o OPatch, um novo arquivo de log criado.
Por exemplo, se um arquivo de log for criado em 17 de maio de 2013 s 23:55, ser
nomeado assim:
opatch_05-17-2013_23-55-00.log
O OPatch tambm mantm um ndice dos comandos processados pelo OPatch e os arquivos
de log associados a ele no arquivo opatch_history.txt localizados no diretrio
Oracle_home/cfgtoollogs/opatch. Uma amostra do arquivo opatch_history.txt
a seguinte:
Date & Time : Tue Apr 26 23:00:55 PDT 2013
Oracle Home : /u01/app/oracle/product/12.1.0/dbhome_1/
OPatch Ver. : 12.1.0.0.0
Current Dir : /scratch/oui/OPatch
Command: lsinventory
Log File :
/u01/app/oracle/product/12.1.0/dbhome_1/cfgtoollogs/opatch/opatch-
2013_Apr_26_23-00-55-PDT_Tue.log
Queryable Patch Inventory
O pacote DBMS_QOPATCH fornece uma interface PL/SQL ou

SQL para exibir os patches de banco de dados que forem
instalados.
A interface fornece todas as informaes dos patches
disponveis como parte do comando do OPatch
lsinventory -xml.
O pacote acessa o inventrio de patches do OUI em tempo
real para fornecer patches e metainformaes sobre os
patches.
O pacote DBMS_QOPATCH permite aos usurios:
Consultar quais patches esto instalados no SQL*Plus
Gravar programas encapsuladores para criar relatrios e fazer
verificaes de validao em vrios ambientes
Verificar os patches instalados em ns de cluster a partir de um
nico local
Com o DBMS_QOPATCH, o Oracle Database 12c fornece uma interface PL/SQL ou SQL para
exibir os patches de banco de dados que forem instalados. A interface fornece todas as
informaes dos patches disponveis como parte do comando do OPatch lsinventory -
xml. O pacote acessa o inventrio de patches do OUI (Oracle Universal Installer) em tempo
real para fornecer patches e metainformaes sobre os patches. Usando esse recurso, os
usurios podem:
Consultar quais patches esto instalados no SQL*Plus
Gravar programas encapsuladores para criar relatrios e fazer verificaes de validao
em vrios ambientes
Verificar os patches instalados nos ns do cluster a partir de um nico local, em vez de
ter que se conectar a cada um por vez

Questionrio
Quais ferramentas podem ser usadas para instalar um

conjunto de patches?
a. Oracle Universal Installer
b. OPatch
c. Console de Banco de Dados do Enterprise Manager
d. Database Configuration Assistant
Resposta: a, c
No Oracle 12c, possvel usar o Oracle Universal Installer ou o Enterprise Manager.

Sumrio

Descrever os tipos de patches disponveis
Planejar patches e upgrades dinmicos
Instalar um conjunto de patches com o utilitrio OUI
(Oracle Universal Installer)
Instalar um patch com o utilitrio opatch

Oracle RAC One Node
Objetivos

Executar uma migrao de banco de dados on-line
Adicionar um Banco de Dados Oracle RAC One Node a
um Cluster existente
Converter um banco de dados Oracle RAC One Node em
um banco de dados RAC
Usar o DBCA para converter um banco de dados de
instncia nica em um banco de dados RAC One Node

Oracle RAC One Node
O Oracle RAC One Node uma instncia nica do banco de

dados habilitado para RAC em execuo em um n do cluster
apenas.
Isto contribui para a flexibilidade da consolidao do banco de
dados, ao mesmo tempo em que reduz o overhead no
gerenciamento ao fornecer uma implantao padro para os
bancos de dados Oracle na empresa.
O Oracle RAC One Node requer Grid Infrastructure e requer a
mesma configurao de hardware que um banco de dados RAC.
Se os aplicativos demandaram mais recursos que um nico
n possa fornecer, voc pode fazer o upgrade on-line para o
Oracle RAC.
Se o n que estiver executando o Oracle RAC One Node ficar
sobrecarregado, voc pode reposicionar a instncia em outro n.
O Oracle RAC One Node uma opo da Oracle Database Enterprise Edition disponvel desde
o Oracle Database 11g release 2. O Oracle RAC One Node uma nica instncia de um banco
de dados habilitado para Oracle RAC em execuo em um n no cluster, somente, em
operaes normais. Isto contribui para a flexibilidade que a Oracle oferece para a consolidao
do banco de dados, ao mesmo tempo em que reduz o overhead no gerenciamento ao fornecer
uma implantao padro para os bancos de dados Oracle na empresa. O banco de dados
Oracle RAC One Node requer Oracle Grid Infrastructure e, portanto, requer a mesma
configurao de hardware que um banco de dados Oracle RAC.
A Oracle suporta o Oracle RAC One Node em todas as plataformas nas quais o Oracle RAC
certificado. Semelhante ao Oracle RAC, o Oracle RAC One Node certificado na Mquina
Virtual Oracle (VM Oracle). O uso do Oracle RAC ou Oracle RAC One Node com Oracle VM
aumenta os benefcios do Oracle VM com a alta disponibilidade e escalabilidade do Oracle
RAC.
Com o Oracle RAC One Node, no h limites para a escalabilidade do servidor e, se as
aplicaes crescerem e demandarem mais recursos que um nico n pode fornecer, voc pode
atualizar suas aplicaes on-line para o Oracle RAC. Se o n que estiver executando o Oracle
RAC One Node ficar sobrecarregado, voc pode reposicionar a instncia em outro n do
cluster. Com o Oracle RAC One Node, voc pode usar o recurso Online Database Relocation
para reposicionar a instncia de banco de dados sem que haja paralisao para os usurios da
aplicao. De outra forma, voc pode limitar o consumo de CPU das instncias individuais do
banco de dados por servidor no cluster, usando o Resource Manager Instance Caging,
alterando dinamicamente esse limite, se necessrio, dependendo do cenrio da demanda.
Criando um Banco de Dados Oracle RAC One Node
Voc pode criar bancos de dados do Oracle RAC One

Node com DBCA.
Bancos de dados de uma nica instncia ou RAC podem
ser convertidos como Oracle RAC One Node.
Nos bancos de dados Oracle RAC One Node, voc deve
configurar pelo menos um servio de banco de dados
dinmico.
Ao usar um banco de dados com Oracle RAC One Node
gerenciado por administrador, o registro do servio
executado assim como qualquer outro banco de dados
com Oracle RAC.
Voc pode criar bancos de dados do Oracle RAC One Node usando o DBCA (Database
Configuration Assistant), assim como qualquer outro banco de dados Oracle (os scripts
criados manualmente tambm so uma alternativa vlida). Os bancos de dados do Oracle
RAC One Node podem tambm ser o resultado de uma converso de um banco de dados
Oracle de uma nica instncia (usando rconfig, por exemplo) ou um banco de dados do
Oracle RAC. Normalmente, as ferramentas fornecidas pela Oracle registram o banco de
dados do Oracle RAC One Node com o Oracle Clusterware. Dependendo da sua
configurao, o registro automtico de um banco de dados Oracle RAC One Node com
Oracle Clusterware talvez no tenha ocorrido. Se este for o caso, siga as etapas nesta seo
para registrar o banco de dados Oracle RAC One Node com o Oracle Clusterware.
Se o seu banco de dados Oracle RAC One Node no for registrado automaticamente com o
Clusterware, use o comando srvctl add database para adicionar um banco de dados
Oracle RAC One Node ao seu cluster. Por exemplo:
srvctl add database -dbtype RACONENODE [-server server_list] [-instance
instance_name] [-timeout timeout]
Use a opo -server e a opo -instance ao adicionar um banco de dados Oracle RAC
One Node gerenciado por um administrador.
Observao: a Oracle recomenda que voc gerencie bancos de dados Oracle RAC One
Node com SRVCTL. Voc pode executar somente determinadas operaes (como Online
Database Relocation) com o SRVCTL.

Nos bancos de dados com Oracle RAC One Node, voc deve configurar pelo menos um
servio dinmico de banco de dados (alm e oposto ao servio padro de banco de dados).
Ao usar um banco de dados com Oracle RAC One Node gerenciado por administrador, o
registro do servio executado assim como qualquer outro banco de dados com Oracle
RAC. Quando voc adiciona servios a um banco de dados Oracle RAC One Node
gerenciado por polticas, o SRVCTL no aceita informaes de posicionamento. Em vez
disso, ele configura esses servios usando o valor do atributo SERVER_POOLS.

Verificando um Banco de Dados RAC One Node

Existente
[oracle@host01 ~]$ srvctl config database -db orcl
Database name: orcl
Oracle user: oracle
Start options: open
Database instances:
Disk Groups: DATA
Mount point paths:
Services: SVC1
Type: RACOneNode
Online relocation timeout: 30 Informaes especficas
Instance name prefix: orcl ao RAC One Node
Candidate servers: host01,host02
...
A execuo do comando srvctl config database exibe os dados da configurao do

banco de dados Oracle RAC One Node. Os dados na sada especfica ao Oracle RAC One
Node incluem o Tipo, o timeout de realocao on-line e os servidores candidatos. Como voc
pode ver no exemplo do slide, o banco de dados RAC One Node orcl pode ser executado
no host01 ou no host02, e o valor de timeout de realocao on-line 30 minutos.
A execuo do comando srvctl config database sem a opo db retorna uma lista
de todos os bancos de dados registrados no Oracle Clusterware.

Migrao On-line do Oracle RAC One Node
O Oracle RAC One Node permite a realocao on-line do banco

de dados de um servidor para outro.
O perodo de migrao pode ser personalizado para at 12 horas.
Use o comando srvctl relocate database para iniciar a
realocao de um banco de dados Oracle RAC One Node:
srvctl relocate database db db_unique_name {[-node target]
[-timeout timeout_value] | -abort [-revert]} [-verbose]
-db <db_unique_name> Unique name of database to relocate

-node <target> Target node to which to relocate database
-timeout <timeout> Online relocation timeout in minutes
-abort Abort failed online relocation
-revert Remove target node of failed online relocation request
from the candidate server list of administrator-managed RAC One
Node database
-verbose Verbose output
-help Print usage
O Oracle RAC One Node permite a realocao on-line de um banco de dados Oracle RAC
One Node de um servidor para outro, o que proporciona uma maior disponibilidade para as
aplicaes baseadas em um Banco de Dados Oracle. O perodo de migrao pode ser
personalizado para at 12 horas. Agora, voc pode mover um banco de dados para
balanceamento de carga de trabalho, bem como para executar uma manuteno planejada
no servidor ou no sistema operacional ou ao aplicar patches ao software Oracle de forma
dinmica.
Somente durante uma realocao de banco de dados on-line planejada, criada uma
segunda instncia de um banco de dados Oracle RAC One Node. Dessa forma, todas as
sesses do banco de dados podem continuar em execuo enquanto o banco de dados
realocado para um novo n.
Se o seu banco de dados Oracle RAC One Node for gerenciado por um administrador, o n
de destino para o qual voc deseja realocar o banco de dados dever estar na lista de
candidatos ou no pool de servidores livres. Se o n de destino estiver no pool de servidores
livres, ele ser adicionado lista de candidatos.
Quando voc realocar uma instncia do banco de dados para um n de destino no contido
na lista de servidores candidatos do banco de dados, se estiver configurado, voc dever
copiar o arquivo de senha no n de destino.
A Oracle Corporation recomenda usar a autenticao do sistema operacional em vez de usar
o Oracle Clusterware para iniciar e interromper o banco de dados, bem como definir usurios
no dicionrio de dados para outro gerenciamento.
Consideraes sobre a Migrao On-line
Use Application Continuity e Oracle Fast Application

Notification ou Transparent Application Failover para
atenuar o impacto de uma realocao no cliente.
Se a FAN ou o TAF no for usado, todas as transaes
em execuo podero ser concludas dentro da restrio
do valor de timeout.
Se o timeout for excedido, os clientes recebero um erro
ORA-3113 quando a sesso for encerrada devido ao
shutdown da instncia.
Se o shutdown da instncia original ultrapassar o valor de
timeout, a instncia ser cancelada.
Em seguida, a nova instncia executar a recuperao para
limpar todas as transaes canceladas devido ao shutdown.
Usando o SCAN (Single Client Access Name) para estabelecer conexo com o banco de
dados, os clientes podem localizar o servio independentemente do n no qual ele esteja em
execuo. Dessa forma, o reposicionamento de uma instncia Oracle RAC One Node fica
ainda mais transparente ao cliente, dependendo da sua conexo. A Oracle recomenda usar o
Application Continuity e Oracle Fast Application Notification ou Transparent Application
Failover para atenuar o impacto de uma realocao no cliente.
Se voc no usar o Application Continuity, a FAN nem o TAF, todas as transaes em
execuo podero ser concludas, desde que dentro do perodo de timeout informado, sendo
que aps esse perodo, os clientes recebero um erro ORA-3113 quando a sesso for
encerrada devido ao shutdown da instncia do Oracle RAC One Node (ORA-3113 End of
Line no canal de comunicao). Como a nova instncia estar em execuo, o cliente poder
fazer login novamente, logo em seguida.
Se o shutdown da instncia original ultrapassar o timeout definido, essa instncia do banco
de dados ser cancelada. Em seguida, a nova instncia executar a recuperao para limpar
todas as transaes canceladas devido ao shutdown.

Executando uma Migrao On-line
[oracle@host01 ~]$ srvctl relocate database -db orcl \

-node host02 -timeout 15 -verbose
Configuration updated to two instances
Instance orcl_2 started
Services relocated
Waiting for 15 minutes for instance orcl_1 to stop.....
Instance orcl_1 stopped
Configuration updated to one instance
Execute o comando srvctl relocate database especificando o banco de dados a ser

migrado, o host para o qual ele ser migrado e, opcionalmente, um valor de timeout usado
para permitir que as conexes com transaes ativas sejam concludas. Se nenhum valor for
especificado, o default ser 30 minutos. Se voc recuperar o status do banco de dados antes
do incio da migrao, dever ver algo conforme exibido a seguir:
[oracle@host01 ~]$ srvctl status database -db orcl
Instance orcl_2 is running on node host01
Online relocation: INACTIVE
Durante a realocao:
Online relocation: ACTIVE
Source instance: orcl_1 on host01
Destination instance: orcl_2 on host02
Aps o trmino da realocao:
Online relocation: INACTIVE

Ilustrao da Migrao On-line
Conexes do cliente
Servidor 1 Servidor 2 Servidor 3
BD-A BD-B BD-C BD-D BD-E
Armazenamento
compartilhado
Cluster
nico
No exemplo de configurao do slide, voc tem cinco bancos de dados Oracle RAC One
Node de instncia nica em execuo em um cluster de trs servidores. O servidor 1 est
hospedando os bancos de dados Oracle RAC One Node BD-A (banco de dados A) e BD-B
(banco de dados B), o servidor 2 est hospedando o BD-C (banco de dados C) e o servidor
3, os bancos de dados BD-D (banco de dados D) e BD-E (banco de dados E).
Cada servidor executa um sistema operacional. Nos servidores 1 e 3, vrios bancos de
dados esto consolidados em um nico sistema operacional. Essa implantao, por si s,
oferece muitas vantagens de consolidao. No entanto, a realocao de bancos de dados
on-line, um recurso exclusivo do Oracle RAC One Node que oferece migrao em tempo real
de bancos de dados entre ns no cluster, oferece muitas vantagens adicionais.

Conexes do cliente
BD-A BD-B BD-B BD-C BD-D BD-E
Armazenamento
compartilhado
Cluster
nico
A realocao de bancos de dados on-line permite uma migrao on-line de um banco de

dados de um servidor para outro. Essa realocao tira proveito da capacidade do Oracle
Real Application Clusters de executar simultaneamente vrias instncias que atendem a um
nico banco de dados. Na figura exibida no slide, o banco de dados B, o RAC One Node, no
servidor 1 migrado para o servidor 2. O Oracle RAC One Node inicia uma segunda
instncia do BD-B no servidor 2 e, por um curto perodo, executado em uma configurao
do tipo ativa-ativa.
medida que as conexes concluem suas transaes no servidor 1, elas so migradas para
a instncia no servidor 2.

Conexes do cliente
Armazenamento
compartilhado
Cluster
nico
Uma vez migradas todas as conexes para a instncia do banco de dados B no servidor 2,
feito o shutdown da instncia no servidor 1 e a migrao concluda. Para resumir, voc
migrou o banco de dados B do servidor 1 para o 2 enquanto o banco de dados estava on-line
e em execuo. Para ampliar o exemplo, voc pode iniciar um upgrade de sistema
operacional ou patch incluindo uma reinicializao do servidor 1 simplesmente migrando o
banco de dados A (BD-A).

Manuteno On-line: Patches Dinmicos
Conexes do cliente
Patch
BD-A BD-B BD-C BD-D BD-E

Binrios
do banco
de dados
Armazenamento
compartilhado
Cluster
nico
Os administradores do RAC One Node podem fazer uma migrao on-line dos bancos de
dados do servidor para um servidor de reserva e, em seguida, executar todos os tipos de
manuteno no servidor ocioso, incluindo manuteno de hardware, upgrades e patches do
sistema operacional e patches do banco de dados. Com a realocao on-line de bancos de
dados, uma nova instncia do banco de dados criada em um novo servidor (em execuo
em outro sistema operacional), e o trabalho migrado on-line para a nova instncia. Dessa
forma, o sistema operacional e o home do banco de dados antigos permanecem no servidor
host anterior, e possvel fazer upgrade do sistema operacional e aplicar patches ao banco
de dados.
Vamos prosseguir com nosso exemplo de implantao do slide anterior. A ilustrao no slide
mostra a implantao de um RAC One Node aps o uso da realocao on-line para mover o
banco de dados B do servidor 1 para o 2. Aps a migrao, os binrios do banco de dados
que tinham hospedado a instncia anteriormente em execuo no servidor 1 permanecem
disponveis para a aplicao de patches.

Manuteno On-line: Patches Dinmicos
Armazenamento
compartilhado
Cluster
nico
Uma vez aplicado o patch aos binrios do banco de dados no servidor 1, o banco de dados B
pode ser migrado pela realocao on-line de volta para o servidor 1. Como a realocao on-
line suporta a migrao entre instncias em diferentes nveis de patch, a operao
executada completamente on-line e no exige a interrupo para os usurios finais. Nesse
caso, a migrao on-line de bancos de dados migra as conexes de volta para o servidor 1 e,
em seguida, feito shutdown da instncia no servidor 2, completando a migrao. De forma
similar, a realocao on-line pode ser usada para mover todos os bancos de dados de um n
em preparao para um upgrade on-line do sistema operacional.

Adicionando um Banco de Dados Oracle RAC

One Node a um Cluster Existente
Use o comando srvctl add database para adicionar
um banco de dados Oracle RAC One Node a um cluster
existente.
srvctl add database -dbtype RACONENODE [-server server_list]
[-instance instance_name] [-timeout timeout_value]
Ao adicionar um banco de dados Oracle RAC One Node

gerenciado por um administrador, voc tambm pode
fornecer um prefixo de instncia com a opo -instance
instance_name do comando srvctl add database.
Cada servio configurado usando o mesmo valor que o
banco de dados subjacente para o atributo SERVER_POOLS.
Quando voc adiciona servios a um banco de dados Oracle
RAC One Node, o srvctl configura esses servios usando o
valor do atributo SERVER_POOLS.
Convertendo o Oracle RAC One Node em Oracle RAC

Use o comando srvctl add database para adicionar um banco de dados Oracle RAC
One Node a um cluster existente. Por exemplo:
srvctl add database -dbtype RACONENODE [-server server_list] [-instance
instance_name] [-timeout timeout_value]
Use a opo -server e a opo -instance ao adicionar um banco de dados Oracle RAC
One Node gerenciado por um administrador.
Cada servio em um banco de dados Oracle RAC One Node configurado usando o mesmo
valor que o banco de dados subjacente para o atributo SERVER_POOLS. Quando voc
adiciona servios a um banco de dados Oracle RAC One Node, o srvctl no aceita
informaes de posicionamento. Em vez disso, ele configura esses servios usando o
mesmo valor do atributo SERVER_POOLS.
Ao adicionar um banco de dados Oracle RAC One Node gerenciado por um administrador,
voc tambm pode fornecer um prefixo de instncia com a opo -instance
instance_name do comando srvctl add database. O nome da instncia ser, ento,
instance_name_1. Se voc no especificar um prefixo de instncia, os primeiros 12
caracteres do nome exclusivo do banco de dados sero o prefixo. O nome da instncia ser
alterado para instance_name_2 durante uma realocao de banco de dados on-line e ser
revertido para instance_name_1 durante a realocao subsequente on-line do banco de
dados. O mesmo nome de instncia usado no failover.
Convertendo um Banco de Dados

RAC One Node em RAC
Para converter um banco de dados RAC One Node em RAC:
1. Execute o comando srvctl convert database.
srvctl convert database -db <db_unique_name> -dbtype RAC
[-node <node_1>]
2. Crie pools de servidores para cada servio que o banco de

dados tenha, alm do pool de servidores de banco de dados.
3. Adicione as instncias nos ns restantes com o comando
srvctl add instance.
srvctl add instance -db <db_unique_name> -instance
instance_name node <node_2>
srvctl add instance -db <db_unique_name> -instance
instance_name node <node_n>
Voc pode converter um banco de dados Oracle RAC One Node em Oracle RAC fazendo
login como o proprietrio do Oracle RAC One Node e executando o comando srvctl
convert database.
Aps executar o comando, crie pools de servidores para cada servio que o banco de dados
tenha, alm do pool de servidores de banco de dados. Os valores de SERVER_NAMES dos
pools de servidores de servios devem ser definidos como o n que voc converteu de um
Oracle RAC One Node em um n do Oracle RAC.
A converso de um banco de dados Oracle RAC One Node gerenciado por um administrador
em um banco de dados Oracle RAC define todos os servios do banco de dados de forma
que a instncia nica seja a preferencial. Aps converter o banco de dados, voc poder
adicionar instncias executando o comando srvctl add instance.
A converso de um banco de dados Oracle RAC One Node gerenciado por poltica em um
banco de dados Oracle RAC define todos os servios do banco de dados como cardinalidade
UNIFORM. Ela tambm causa a reutilizao do pool de servidores no qual o banco de dados
est em execuo no momento. A converso reconfigura o banco de dados para ser
executado em todos os ns do pool de servidores. O comando no inicia nenhuma instncia
adicional, mas a execuo do comando srvctl start database inicia o banco de dados
em todos os ns do pool de servidores.


RAC One Node em RAC
$ srvctl convert database -db orcl -dbtype RAC -node host01
$ srvctl add instance -db orcl instance orcl_2 node host02
$ srvctl start instance -db orcl -instance orcl_2
Database name: orcl
Oracle user: oracle
Domain:
Start options: open
Server pools: orcl
Database instances: orcl_1,orcl_2
Disk Groups: DATA,FRA
Services: SERV1
Type: RAC
Database is administrator managed
No exemplo do slide, o banco de dados RAC One Node ORCL convertido em um Oracle
RAC com o comando srvctl convert database. O cluster consiste em dois ns, host01
e host02. Concluda a execuo do comando srvctl convert database, a segunda
instncia, orcl_2 adicionada ao host02 com o comando srvctl add instance,
conforme ilustrado no exemplo do slide.
Uma vez adicionada a instncia ao segundo n, ela poder ser iniciada com o comando
srvctl start instance. Use o comando srvctl config database para verificar se
a converso do banco de dados e a incluso da instncia ocorreram com xito.

Convertendo um Banco de Dados de Instncia

nica em um RAC One Node
Use o DBCA para converter bancos de dados Oracle de
instncia nica em RAC One Node.
Antes de usar o DBCA para converter um banco de dados
de instncia nica em um banco de dados Oracle RAC
One Node, certifique-se de que o seu sistema atenda s
seguintes condies:
Tenha uma configurao de hardware e software de sistema
operacional suportada.
Tenha armazenamento compartilhado: o Oracle Cluster File
System ou o Oracle ASM estar disponvel e acessvel em
todos os ns.
Suas aplicaes no devero ter qualquer caracterstica de
projeto que impea o uso delas em um ambiente
clusterizado.
Voc pode usar o DBCA para converter bancos de dados Oracle de instncia nica em
Oracle RAC One Node. O DBCA automatiza a configurao dos atributos do arquivo de
controle, cria os tablespaces de undo e os redo logs e gera as entradas dos arquivos de
parmetros de inicializao para ambientes habilitados para cluster. Ele tambm configura o
Oracle Net Services, os recursos do Oracle Clusterware e a configurao de gerenciamento
do banco de dados Oracle para uso pelo Oracle Enterprise Manager ou pelo utilitrio
SRVCTL.
Antes de usar o DBCA para converter um banco de dados de instncia nica em um banco
de dados Oracle RAC One Node, certifique-se de que o seu sistema atenda s seguintes
condies:
Tenha uma configurao de hardware e software de sistema operacional suportada.
Tenha armazenamento compartilhado: o Oracle Cluster File System ou o Oracle ASM
estar disponvel e acessvel em todos os ns.
Suas aplicaes no devero ter qualquer caracterstica de projeto que impea o uso
delas em um ambiente clusterizado.
A Oracle recomenda que voc use o Oracle Universal Installer para executar uma instalao
do Oracle Database 12c que configure o Oracle home e o inventrio em um local idntico em
cada um dos ns selecionados no cluster.


RAC em RAC One Node
Ao converter um banco de dados RAC em RAC One Node,
primeiro certifique-se de que o banco de dados RAC tenha
apenas uma instncia.
Se o banco de dados RAC for gerenciado por um administrador,
altere a configurao de todos os servios para definir a instncia
preferencial como a instncia que voc deseja manter como um
banco de dados RAC One Node.
Se um servio tiver uma poltica PRECONNECT do TAF, ela dever
ser atualizada para BASIC ou NONE antes da converso.
Se o banco de dados RAC for gerenciado por poltica, altere a
configurao de todos os servios para que eles usem o mesmo
pool de servidores antes de converter o banco de dados RAC.
Use o comando srvctl convert database para converter
um banco de dados RAC em RAC One Node:
srvctl convert database -db db_unique_name -dbtype
RACONENODE [-instance instance_name -timeout timeout]
Voc pode converter um banco de dados Oracle RAC com uma instncia em um Oracle RAC
One usando o comando srvctl convert database, da seguinte forma:
srvctl convert database -db db_unique_name -dbtype RACONENODE
[-instance instance_name -timeout timeout]
Antes de converter um banco de dados Oracle RAC em um banco de dados Oracle RAC One
Node, primeiro certifique-se de que o banco de dados Oracle RAC tenha apenas uma
instncia.
Se o banco de dados Oracle RAC for gerenciado por um administrador, altere a configurao
de todos os servios para definir a instncia preferencial como a instncia que voc deseja
manter como um banco de dados Oracle RAC One Node aps a converso. Se qualquer
servio tiver uma poltica PRECONNECT do TAF, ela dever ser atualizada para BASIC ou
NONE antes de iniciar o processo de converso. Esses servios no devero ter mais
nenhuma instncia disponvel.
Se o banco de dados Oracle RAC for gerenciado por poltica, altere a configurao de todos
os servios para que eles usem o mesmo pool de servidores antes de converter o banco de
dados Oracle RAC em um Oracle RAC One Node.

Questionrio
O comando srvctl add database usado para

adicionar um banco de dados Oracle RAC One Node a um
cluster existente.
a. Verdadeiro
b. Falso
Resposta: a

Questionrio
Quais das condies a seguir devem ser atendidas para que

um banco de dados de instncia nica possa ser convertido
em um banco de dados RAC One Node? (Escolha trs)
a. Tenha uma configurao de hardware e software de
sistema operacional suportada.
b. Tenha armazenamento compartilhado: o Oracle Cluster
File System ou o Oracle ASM estar disponvel e
acessvel em todos os ns.
c. necessrio desativar o Oracle Clusterware em todos
os ns.
d. Suas aplicaes no devero ter qualquer caracterstica
de projeto que impea o uso delas em um ambiente
clusterizado.
Resposta: a, b, d

Sumrio

Executar uma migrao de banco de dados on-line
Adicionar um Banco de Dados Oracle RAC One Node a
um cluster existente
Converter um banco de dados Oracle RAC One Node em
um banco de dados RAC
Usar o DBCA para converter um banco de dados de
instncia nica em um banco de dados RAC One Node.

Os exerccios desta lio abordam os seguintes tpicos:

Criao de um Banco de Dados RAC One Node usando
DBCA
Migrao on-line do Oracle RAC One Node
Converter um banco de dados RAC One Node em um
banco de dados RAC

Gerenciamento de Qualidade do Servio
Objetivos
Ao concluir esta lio, voc ser capaz de descrever:

A finalidade do QoS (Gerenciamento de Qualidade de
Servio) no Oracle Database
As vantagens de usar o Gerenciamento de Qualidade de
Servio no Oracle Database
Os componentes do Gerenciamento de Qualidade de
O funcionamento do Gerenciamento de Qualidade de

Informaes Bsicas sobre o Gerenciamento de QoS
Nas releases anteriores do Oracle Database, era possvel usar servios para gerenciar e
isolar a carga de trabalho. Por exemplo, um grupo de servidores pode estar dedicado s
operaes de data warehouse, outro estar dedicado a uma aplicao de vendas, um terceiro
ser usado para o processamento ERP e um quarto para uma aplicao personalizada.
Usando servios, o administrador de banco de dados capaz de alocar recursos para cargas
de trabalho especficas alterando manualmente o nmero de servidores nos quais um servio
de banco de dados pode ser executado. As cargas de trabalho so isoladas umas das
outras, de modo que oscilaes de demanda, falhas e outros problemas em uma carga de
trabalho no afetam as demais. O problema desse tipo de implantao que cada de carga
de trabalho precisa ser provisionada separadamente para demanda de pico, pois os recursos
no so compartilhados.
Voc tambm pode definir servios que compartilham recursos sobrepondo alocaes de
servidor. No entanto, mesmo com essa capacidade, era necessrio gerenciar manualmente
as alocaes de servidor e cada servio era mapeado para um grupo fixo de servidores.
A partir do Oracle Database 11g, voc pode usar pools de servidores para particionar
logicamente um cluster e fornecer isolamento de cargas de trabalho. Os pools de servidores
proporcionam uma forma de alocar recursos mais dinmica e concentrada em negcios
porque as alocaes de recursos no dependem de quais servidores esto ativos. Em vez
disso, as alocaes de pools de servidores so ajustadas dinamicamente quando os
servidores entram e saem do cluster, de acordo com as prioridades definidas nas polticas de
pool de servidores.
Viso do Gerenciamento de QoS
Definir e Ativar Classificar e Medir
Conjunto de Polticas de
Gerenciamento de QoS
Poltica de
Manuteno
Poltica em
Finais de Semana
Avaliar e Arquitetura
Pools de
Servidores
Poltica Fora do
Horrio Comercial Analisar e
Reportar Orientada a Poltica em
Horrio Comercial Recomendar
Poltica
Objetivos de Desempenho
Classes de
Classificaes dos Negcios
Desempenho
Alocaes de Pools
de Servidores
Implementar e Controlar
Muitas empresas esto consolidando e padronizando os sistemas de computador de seus

centros de dados. Ao mesmo tempo, com a migrao das aplicaes para a Internet, o
gerenciamento de picos de demanda que no podem ser totalmente previstos passou a ser
um problema. Nesse tipo de ambiente, necessrio criar um pool de recursos, bem como ter
ferramentas de gerenciamento capazes de detectar e solucionar gargalos em tempo real. Os
pools de servidores gerenciados por poltica fornecem uma base para o gerenciamento de
cargas de trabalho dinmicas. No entanto, eles s podem ajustar alocaes de recursos em
resposta a alteraes na disponibilidade do servidor.
O gerenciamento de qualidade do servio um sistema WLM (workload management)
baseado em poltica e automatizado que monitora e ajusta o ambiente para atender aos
objetivos de desempenho no nvel de negcios. Com base na disponibilidade de recursos e
nas demandas das cargas de trabalho, o gerenciamento de qualidade do servio identifica os
gargalos de recursos e fornece recomendaes sobre como alivi-los. Ele pode fazer
recomendaes para que o administrador do sistema mova um servidor de um pool para
outro ou ajuste o acesso aos recursos de CPU com o Database Resource Manager, a fim de
atender aos objetivos de desempenho atuais. Com o gerenciamento de qualidade do servio,
o administrador poder garantir o seguinte:
Quando houver recursos suficientes disponveis para atender demanda, os objetivos
de desempenho no nvel de negcios de cada carga de trabalho sero atendidos,
mesmo que a carga de trabalho mude.
Quando no houver recursos suficientes disponveis para atender a todas as
demandas, o gerenciamento de qualidade do servio dar prioridade aos objetivos mais
crticos de negcios em detrimento dos menos crticos.
Gerenciamento de QoS e
Exadata Database Machine
Em sua forma inicial, o Gerenciamento de QoS uma
funcionalidade da famlia de produtos Oracle Database:
Introduzido no Oracle Database 11g release 2
Associado ao software Oracle RAC
Lanado exclusivamente no
Exadata Database Machine
Centrado em ambientes que Conjunto de Polticas de
Gerenciamento de QoS
suportam vrias cargas de Poltica de
Manuteno
trabalho OLTP Poltica em

Finais de Semana
Arquitetura
Pools de Poltica Fora do
Tecnologia no especfica Servidores Horrio Comercial
Orientada a Poltica em
Horrio Comercial
do Exadata Poltica
Classes de

Desempenho
O primeiro passo em direo a Alocaes de Pools
de Servidores
uma soluo mais abrangente
Em sua forma inicial, o gerenciamento de qualidade do servio uma funcionalidade da

famlia de produtos Oracle Database associada ao software Oracle Real Application Clusters
(RAC). Ele foi introduzido no Oracle Database 11g release 2.
O conjunto inicial de recursos e vantagens associados ao gerenciamento de qualidade do
servio est disponvel exclusivamente para os clientes do Exadata Database Machine e
mais adequado aos que usam o Database Machine predominantemente como uma
plataforma de consolidao para aplicaes OLTP.
O software Gerenciamento de Qualidade de Servio pode funcionar em ambientes que no
sejam Exadata, nos quais o Oracle Database 11g release 2 esteja disponvel. A partir da
verso 11.2.0.3, foi lanado um subconjunto de recursos de Gerenciamento de Qualidade de
Servio que permite aos usurios que no sejam do Exadata monitorar as classes de
desempenho, mas no gerar e implementar alteraes em resposta carga de trabalho
observada no momento.
Em seu formato atual, o Gerenciamento de Qualidade de Servio apresenta uma poderosa
capacidade concentrada em banco de dados que representa o primeiro passo do caminho
em direo a uma soluo mais ampla de gerenciamento de cargas de trabalho.

Foco do Gerenciamento de QoS
Desenvolvimento de Cdigo
Uso de Planejamento da Capacidade
Configurao/Implantao
Recursos
Espera por Gerenciamento de
Qualidade do Servio
Recursos
Desempenho
da Aplicao
O gerenciamento de qualidade do servio monitora o desempenho de cada solicitao de

trabalho em um sistema de destino. Medindo com preciso os dois componentes de
desempenho, o uso de recursos e a espera associada, possvel detectar rapidamente
gargalos e realocar os recursos para alivi-los, preservando ou restaurando, dessa maneira,
os nveis de servio. A alterao ou a melhora do tempo de execuo geralmente requer
alteraes no cdigo-fonte da aplicao. Dessa forma, o Gerenciamento de Qualidade de
Servio somente observa e gerencia tempos de espera.
Ele baseia suas decises nas observaes do tempo que as solicitaes de trabalho
esperam por recursos. Alguns exemplos de recursos pelos quais as solicitaes de trabalho
podem esperar incluem recursos de hardware, como ciclos de CPU, filas de entrada/sada de
disco e blocos do cache global.
Podero ocorrer outras esperas no banco de dados, como latches, bloqueios, retenes etc.
Embora essas esperas do banco de dados sejam consideradas pelo gerenciamento de
qualidade do servio, elas no so categorizadas por tipo nem gerenciadas. A reduo das
esperas no gerenciadas exige alteraes que o gerenciamento de qualidade do servio no
pode fazer, como, por exemplo, alteraes no cdigo da aplicao e otimizaes do
esquema do banco de dados. O Gerenciamento de Qualidade de Servio ainda vantajoso
nesses casos, porque a medida e a notificao de esperas no gerenciadas podem ser
usadas como ferramenta para medir o efeito das atividades de otimizao da aplicao.

Vantagens do Gerenciamento de QoS
Determina onde so necessrios recursos adicionais

Determina se possvel incluir hardware adicional para
manter um desempenho aceitvel
Reduz o nmero de interrupes de desempenho crticas
Reduz o tempo para resolver violaes de objetivos de
desempenho
Melhora a estabilidade do sistema medida que a carga
de trabalho muda
Ajuda a garantir que os SLAs sejam cumpridos
Facilita o compartilhamento eficaz dos recursos de
hardware
Estas so algumas das vantagens do gerenciamento de qualidade do servio:

Categorizando e mensurando o trabalho dos bancos de dados, o gerenciamento de
qualidade do servio pode ajudar os administradores a determinar onde so
necessrios recursos adicionais.
O Gerenciamento de Qualidade de Servio habilitado para Oracle RAC, e ele usa
essa percepo fundamental para determinar se possvel incluir hardware adicional a
fim de manter um desempenho aceitvel.
O Gerenciamento de Qualidade de Servio ajuda a reduzir o nmero de interrupes de
desempenho crticas. Caso a realocao dos recursos de runtime seja feita com base
na utilizao das aplicaes crticas de negcios mais ocupadas, ser menor a
probabilidade de ocorrerem problemas de desempenho nessas aplicaes.
O gerenciamento de qualidade do servio reduz o tempo necessrio para resolver
violaes dos objetivos de desempenho. Em vez de exigir que os administradores
compreendam e respondam s alteraes no desempenho, grande parte do trabalho
pode ser automatizada. Os administradores contam com uma interface simples para
verificar e implementar as alteraes recomendadas.
Os problemas de desempenho costumam resultar na instabilidade do sistema.
Movendo os recursos para onde eles so mais necessrios, o gerenciamento de
qualidade do servio reduz a chance de que ocorram problemas de desempenho nos
sistemas, bem como a instabilidade associada.
O gerenciamento de qualidade do servio permite que o administrador defina objetivos
de desempenho que ajudam a garantir o cumprimento dos SLAs (Service Level
Agreements, Contratos em Nvel de Servio). Uma vez definidos os objetivos, o
gerenciamento de qualidade do servio controlar o desempenho e recomendar
alteraes caso os SLAs no estejam sendo cumpridos.
medida que as necessidades de recursos mudam, o Gerenciamento de Qualidade de
Servio pode realocar recursos de hardware para garantir que as aplicaes faam um
uso mais eficaz desses recursos. Os recursos podem ser removidos das aplicaes que
no necessitam mais deles e adicionados a outra que tenha problemas de
desempenho.

Viso Geral Funcional do Gerenciamento de QoS

O Gerenciamento de QoS opera com o Oracle RAC e o Oracle
Clusterware para:
Gerenciar os recursos de CPU do servidor de banco de
dados avaliando os tempos de espera por CPU a fim de
identificar as cargas de trabalho que no esto atendendo
aos objetivos de desempenho
O Gerenciamento de QoS pode recomendar:
Ajustes no tamanho dos pools de servidores
Alteraes nos mapeamentos de grupos de consumidores
Ajustes nos recursos de CPU alocados para diferentes instncias
de banco de dados em um pool de servidores
Gerenciar a demanda de memria em decorrncia do nmero
de sesses ou de cargas de trabalho fora de controle
O Gerenciamento de Qualidade de Servio impede que novas
sesses sejam estabelecidas em servidores que estejam
sofrendo estresse de memria.
O Gerenciamento de Qualidade de Servio trabalha com o Oracle RAC, o Oracle Clusterware

e o CHM (Cluster Health Monitor) para gerenciar os recursos de banco de dados a fim de
atender aos nveis de servio e gerenciar a presso na memria dos servidores gerenciados.
Geralmente, os servios de banco de dados so usados para agrupar solicitaes de
trabalho relacionadas, bem como para medir e gerenciar o trabalho do banco de dados. Por
exemplo, uma consulta iniciada pelo usurio no banco de dados pode usar um servio
diferente de uma aplicao de gerao de relatrios. Para gerenciar os recursos usados por
um servio, possvel implantar alguns servios em vrias instncias do Oracle RAC
simultaneamente, enquanto outros podem ser implantados em apenas uma instncia. Em um
banco de dados Oracle RAC, o gerenciamento de qualidade do servio monitora os ns em
que os servios de banco de dados definidos pelo usurio so oferecidos. Os servios so
criados em um pool de servidores especficos, e o servio executado em todos os
servidores do pool. Se um servio singleton for necessrio porque no possvel o
escalonamento eficaz da aplicao em vrios servidores RAC, o servio poder ser
hospedado em um pool de servidores com tamanho mximo igual a um.

O gerenciamento de qualidade do servio avalia periodicamente os tempos de espera pela
CPU do servidor de banco de dados para identificar as cargas de trabalho que no esto
atendendo aos objetivos de desempenho. Se necessrio, ele recomendar ajustes no
tamanho dos pools de servidores ou alteraes nos mapeamentos de grupos de
consumidores do Database Resource Manager (DBRM). A partir do Oracle Database release
11.2.0.3, o gerenciamento de qualidade do servio tambm suporta a transferncia de CPUs
entre bancos de dados no mesmo pool de servidores.
O DBRM um exemplo de mecanismo de alocao de recursos; ele pode alocar partes da
CPU a uma coleo de grupos de consumidores de recursos com base em um plano de
recursos especificado por um administrador. Um plano de recursos aloca o percentual de
oportunidades de execuo na CPU. O Gerenciamento de Qualidade de Servio no ajusta
planos do DBRM; ele ativa um plano de recursos multinvel compartilhados e, em seguida, ao
implementar uma recomendao, move as cargas de trabalho para grupos especficos de
consumidores de recursos, a fim de atender aos objetivos de desempenho para todas as
diferentes cargas de trabalho.
Os servidores de banco de dados corporativos podem ficar sem memria disponvel em
decorrncia de um grande nmero de sesses abertas ou de cargas de trabalho fora de
controle. A insuficincia de memria pode resultar em falhas nas transaes ou, em casos
extremos, em uma reinicializao do servidor e perda de recursos valiosos para suas
aplicaes. O gerenciamento de qualidade do servio alivia a demanda de memria
encerrando temporariamente os servios das instncias de banco de dados em um servidor
em que h grande consumo de memria. Como resultado, as novas sesses sero
direcionadas para servidores menos sobrecarregados. O roteamento das novas sesses
protege as cargas de trabalho existentes e a disponibilidade do servidor com grande
consumo de memria.
Quando o gerenciamento de qualidade do servio est ativado e gerenciando um pool de
servidores do Oracle Clusterware, ele recebe um fluxo de mtricas do Cluster Health Monitor
com informaes em tempo real sobre os recursos de memria de um servidor, incluindo a
quantidade de memria disponvel, a quantidade de memria em uso e a quantidade de
memria da qual foi feito swap para disco em cada servidor. Se o gerenciamento de
qualidade do servio determinar que h um grande consumo de memria em um n, os
servios de banco de dados gerenciados pelo Oracle Clusterware sero interrompidos nesse
n, impedindo o estabelecimento de novas conexes. Uma vez aliviada a demanda de
memria, os servios sero reiniciados automaticamente, e o listener poder enviar novas
conexes para o servidor. possvel atenuar a presso da memria de vrias formas, por
exemplo, encerrando as sesses existentes ou pela interveno do usurio.

Conjuntos de Polticas de Gerenciamento de QoS
Conjunto de Polticas de Gerenciamento de QoS

Poltica de Manuteno
Poltica em Finais
Pools de de Semana
Servidores Poltica Fora do
Horrio Comercial
Poltica do Horrio
Comercial
Classes de Objetivos de Desempenho
Desempenho
Alocaes de Pools
de Servidores
Um conceito central do gerenciamento de qualidade do servio o conjunto de polticas. Ele

permite especificar recursos, classes de desempenho (cargas de trabalho) e um conjunto de
polticas de desempenho que determinam o objetivo de desempenho de cada classe de
desempenho, bem como definem restries para a disponibilidade de recursos. O
gerenciamento de qualidade do servio usa um conjunto de polticas em nvel do sistema que
define os objetivos de desempenho com base nas classes de trabalho e na disponibilidade de
recursos. Polticas de desempenho especficas podem ser ativadas com base na programao
de um calendrio, em janelas de tempo de manuteno, eventos etc. S poder haver uma
poltica de desempenho ativa em determinado momento.
Para manter os objetivos de desempenho atuais, o gerenciamento de qualidade do servio faz
recomendaes de realocao de recursos e prev o respectivo efeito. As recomendaes
podem ser facilmente implementadas com o clique de um nico boto.
Um conjunto de polticas consiste nos seguintes elementos:
Os pools de servidores gerenciados pelo Gerenciamento de Qualidade de Servio
Classes de desempenho, que so solicitaes de trabalho com objetivos de desempenho
semelhantes
Polticas de desempenho, que descrevem como os recursos devem ser alocados s
classes de desempenho com o uso de objetivos de desempenho e de sobreposies de
diretivas de pool de servidores. Em uma poltica de desempenho, os objetivos so
classificados com base na importncia comercial, o que possibilita ao Gerenciamento de
Qualidade de Servio se concentrar em objetivos especficos quando a poltica est ativa.
Pools de Servidores
Aplic. de Carrinho Aplic. Aplic. Apl. de
Vendas de vendas ERP de RH Batch
Servio Servio Servio

ERP de RH Batch
Servio de VENDAS
Online Server Pool (SP) BackOffice SP Batch SP Free SP

Min=3, Max=4, Min=2, Max=2, Min=1, Max=1, Min=0,
Importance=30 Importance=20 Importance=10 Imp=0
Banco de Dados SALES Banco de Dados APPS
Oracle Clusterware
Um pool de servidores uma diviso lgica de um cluster. Os pools de servidores facilitam o

isolamento da carga de trabalho em um cluster ao mesmo tempo em que mantm a agilidade
e permitem que os usurios obtenham outras vantagens associadas consolidao. Os
administradores podem definir pools de servidores que, em geral, so associados a
diferentes aplicaes e cargas de trabalho. O slide mostra um exemplo. O Gerenciamento de
Qualidade de Servio pode auxiliar no gerenciamento do tamanho de cada pool de
servidores, gerenciando a alocao de recursos em um pool.
Quando o Oracle Grid Infrastructure instalado pela primeira vez, um pool de servidores
default, chamado Free, criado. Todos os servidores so colocados inicialmente nesse pool.
Depois, pools de servidores especficos podero ser criados para cada uma das cargas de
trabalho que precisam ser gerenciadas. Quando um novo pool criado, os servidores
designados a ele so removidos automaticamente do pool Free e colocados no pool recm-
criado.
Uma vez criado um pool de servidores, poder ser configurado um banco de dados para
execuo nesse pool, e servios gerenciados por cluster podero ser estabelecidos para que
as aplicaes se conectem ao banco de dados.
Para que um banco de dados Oracle RAC aproveite a flexibilidade dos pools de servidores,
ele deve ser criado com o uso da opo de implantao gerenciada por poltica, a qual
coloca o banco de dados em um ou mais pools de servidores.

Um importante atributo do gerenciamento baseado em poltica a alocao de recursos para
pools de servidores com base na cardinalidade e na importncia.
Quando o cluster iniciado ou quando servidores so adicionados, todos os pools so
preenchidos at seus nveis mnimos em ordem de importncia. Quando os nveis mnimos
so atingidos, os pools continuam a ser preenchidos em ordem de importncia at atingirem
seus nveis mximos. Se sobrarem servidores, eles sero alocados para o pool Free.
Se os servidores sarem do cluster por qualquer motivo, poder ocorrer uma realocao de
servidores. Se houver servidores no pool livre, e outro pool ficar abaixo de seu valor mximo,
um servidor livre ser alocado ao pool afetado. Se no houver servidores livres, a realocao
de servidores s ocorrer se um pool ficar abaixo de seu nvel mnimo. Se isso ocorrer, um
servidor ser disponibilizado a partir de um dos locais a seguir, na seguinte ordem:
1. O pool de servidores com a menor importncia, que tenha mais do que seu nmero
mnimo de servidores
2. O pool de servidores com a menor importncia, que tenha, pelo menos, um servidor e
tenha menos importncia do que o pool afetado
Usando esses mecanismos, os pools de servidores podem manter um nvel ideal de recursos
com base no nmero atual de servidores disponveis.
Examine o exemplo mostrado no slide. Se um dos servidores do pool Online falhar, o
servidor existente no pool Free ser automaticamente movido para o pool Online.
Agora, se ocorrer uma falha em um dos servidores do pool BackOffice, no haver
servidores no pool Free para serem alocados. Nesse caso, o servidor que estiver atendendo
ao servidor Batch ser realocado dinamicamente para o pool BackOffice, porque o problema
faria com que o pool BackOffice ficasse abaixo de seu nvel mnimo, e ele mais importante
do que o servidor Batch.
Se um n retornar posteriormente ao cluster, ele ser alocado para o pool Batch a fim de
satisfazer ao nvel mnimo desse pool.
Quaisquer outros ns adicionados ao cluster aps esse ponto sero adicionados ao pool
livre, porque todos os outros pools estaro preenchidos at seu nvel mximo.

Classes de Desempenho
Classe de desempenho um grupo de solicitaes de

trabalho cujo nvel de servio precisa ser gerenciado.
As solicitaes de trabalho so definidas por
classificadores de desempenho que contm o nome de
servio do banco de dados e parmetros de sesso
opcionais.
Um conjunto inicial de classificadores de desempenho
automaticamente detectado e criado a partir dos servios
gerenciados pelo cluster.
Os objetivos de desempenho so definidos com base em
classes de desempenho.
As classes de desempenho so usadas para categorizar cargas de trabalho com requisitos

semelhantes de desempenho. Um conjunto de regras de classificao avaliado em relao
s solicitaes de trabalho quando elas chegam ao sistema. Essas regras permitem fazer
uma correspondncia com os valores de atributos da solicitao de trabalho; quando h uma
correspondncia entre o tipo de solicitao de trabalho e os critrios para incluso em uma
classe de desempenho, a solicitao categorizada nessa classe.
Essa classificao das solicitaes de trabalho aplica o nome definido pelo usurio, ou tag,
que identifica a classe de desempenho (PC) qual a solicitao pertence. Todas as
solicitaes de trabalho agrupadas em determinada classe tm os mesmos objetivos de
desempenho. Na verdade, a tag conecta a solicitao de trabalho ao objetivo de
desempenho aplicvel a ela. As tags so mantidas com cada solicitao de trabalho de modo
que todos os componentes do sistema possam efetuar medies e fornecer dados ao
gerenciamento de qualidade do servio para avaliao em relao aos objetivos de
desempenho aplicveis.
O gerenciamento de qualidade do servio suporta combinaes definidas pelo usurio de
parmetros de conexo denominados classificadores a fim de mapear as classes de
desempenho para as cargas de trabalho reais executadas no banco de dados.

Esses parmetros de conexo so divididos em duas classes gerais e podem ser
combinados para criar expresses booleanas detalhadas:
Parmetros de Configurao: os parmetros de configurao suportados so
SERVICE_NAME e USERNAME. Cada classificador em uma classe de desempenho
deve incluir um ou mais servios de banco de dados gerenciados por cluster. Maior
granularidade pode ser obtida com a identificao do usurio do Oracle Database que
est estabelecendo a conexo a partir de um cliente ou do middle-tier. A vantagem de
usar esses classificadores que eles no exigem alteraes no cdigo da aplicao
para definir as classes de desempenho.
Parmetros de Aplicao: os parmetros de aplicao suportados so MODULE,
ACTION e PROGRAM. Eles so parmetros opcionais definidos pela aplicao da
seguinte maneira:
- OCI: use OCI_ATTR_MODULE e OCI_ATTR_ACTION.
- ODP.NET: especifique as propriedades ModuleName e ActionName no objeto
OracleConnection.
- JDBC: defina MODULE e ACTION em SYS_CONTEXT.
O parmetro PROGRAM definido ou derivado de maneira diferente para cada plataforma e
driver de banco de dados. Consulte o guia do desenvolvedor do Oracle Database apropriado
para obter mais detalhes e exemplos.
Para gerenciar a carga de trabalho de uma aplicao, o cdigo da aplicao direciona as
conexes de banco de dados para um servio especfico. O nome do servio especificado
em um classificador, de forma que todas as solicitaes de trabalho que usam esse servio
so marcadas com uma tag como pertencendo classe de desempenho criada para essa
aplicao. Se quiser manter um controle mais preciso da carga de trabalho gerada pelas
diversas partes da aplicao, voc poder criar classes de desempenho adicionais e usar
classificadores que incluam MODULE, ACTION ou PROGRAM, alm do parmetro
SERVICE_NAME ou USERNAME.
As classes de desempenho usadas em um ambiente podem ser alteradas ao longo do
tempo. Um cenrio comum substituir um nico objetivo de desempenho por vrios objetivos
mais especficos, dividindo as solicitaes de trabalho em classes adicionais. Por exemplo,
os desenvolvedores de aplicao podem sugerir classes de desempenho para uso pelo
gerenciamento de qualidade do servio. Especificamente, um desenvolvedor de aplicao
pode definir um conjunto de classificadores de banco de dados usando os parmetros
MODULE e ACTION e, depois, coloc-los em classes de desempenho distintas, de modo
que cada tipo de solicitao de trabalho seja gerenciado de forma independente.

Classificao e Marcao com Tags
Cada sesso classificada:

A classificao determinada pela avaliao dos
parmetros da sesso em relao aos classificadores das
classes de desempenho.
A avaliao ocorre apenas quando uma sesso
estabelecida ou quando seus parmetros mudam.
Isso minimiza o overhead associado classificao.
Cada solicitao de trabalho marcada com uma tag:
A tag baseada na classificao atual da sesso.
A tag conecta a solicitao de trabalho classe de
desempenho.
Ela permite que as medidas associadas solicitao sejam
registradas na classe de desempenho apropriada.
Para ativar o gerenciamento de qualidade do servio, as solicitaes de trabalho devem ser

classificadas e marcadas com uma tag.
Quando uma sesso de banco de dados estabelecida, os parmetros da sesso so
avaliados em relao aos classificadores de classes de desempenho para determinar uma
classificao. Em seguida, o trabalho associado sesso marcado com uma tag com base
na classificao da sesso at que ela seja encerrada ou que os parmetros
correspondentes sejam alterados. Se os parmetros da sesso forem alterados, a
classificao ser reavaliada. Dessa forma, o overhead associado classificao muito
pequeno, porque ela s avaliada quando uma sesso estabelecida ou quando ocorrem
alteraes nos seus parmetros.
As tags so designadas permanentemente a cada solicitao de trabalho de modo que todas
as medies associadas solicitao podem ser registradas para a classe de desempenho
apropriada. Na verdade, a tag conecta a solicitao de trabalho a uma classe de
desempenho e ao objetivo de desempenho associado.

Polticas de Desempenho
Polticas de desempenho so conjuntos nomeados de

objetivos de desempenho e substituies de pools de
servidores com o fim de atender aos objetivos de
negcios.
possvel classificar os objetivos de desempenho de acordo
com sua importncia.
Somente uma poltica permanece ativa por vez.
Para gerenciar vrios objetivos de desempenho, o administrador do gerenciamento de

qualidade do servio define uma ou mais polticas de desempenho. Por exemplo, ele pode
definir uma poltica de desempenho para o horrio comercial normal, outra para os dias da
semana fora do horrio comercial, uma para operaes nos finais de semana e outra para
ser usada durante o processamento do fechamento financeiro trimestral. Observe que h
somente uma poltica ativa em determinado momento.
Uma poltica de desempenho contm um conjunto de objetivos de desempenho em vigor; um
ou mais para cada aplicao que est sendo gerenciada no sistema. Alguns objetivos de
desempenho so sempre mais crticos para os negcios do que outros, enquanto alguns
objetivos podem ser mais crticos em determinados momentos e menos crticos em outros. A
capacidade de definir vrias polticas de desempenho no conjunto de polticas proporciona
ao gerenciamento de qualidade do servio a flexibilidade necessria para implementar
diferentes esquemas de prioridade quando preciso.

Classificaes de Classes de Desempenho
As classificaes de classes de desempenho designam

um nvel relativo de criticalidade do negcio a cada classe
de desempenho em uma poltica de desempenho:
Highest
High
Medium
Low
Lowest
Em uma poltica de desempenho, tambm possvel classificar cada classe de desempenho.

Essa classificao designa um nvel relativo de criticalidade do negcio a cada objetivo de
desempenho. Quando no h recursos suficientes disponveis para atender a todos os
objetivos de todas as classes de desempenho, os objetivos de desempenho das classes
mais crticas devem ser atendidos em detrimento dos das classes menos crticas. As
definies de classificao disponveis so Highest, High, Medium, Low ou Lowest. Observe
que, se mais de uma classe receber determinada classificao (por exemplo, Medium), elas
sero ordenadas alfabeticamente nessa classificao.

Os objetivos de desempenho podem derivar dos SLAs.

Eles especificam:
Um requisito de negcios
A classe de desempenho qual se aplica o requisito de
negcios
O tempo de resposta mdio por chamada do banco de
dados atualmente o nico tipo de objetivo de
desempenho.
O tempo de resposta o tempo total desde a hora em que o
banco de dados recebe a solicitao at o momento em que
a resposta sai do servidor.
O tempo de resposta no inclui o tempo de trfego na rede.
Um objetivo de desempenho criado para cada classe de desempenho a fim de especificar o

nvel de desempenho desejado para essa classe. Um objetivo de desempenho especifica um
requisito de negcios e o trabalho ao qual ele se aplica (a classe de desempenho). Por
exemplo, um objetivo de desempenho poder determinar que as solicitaes de trabalho do
banco de dados que usam o servio SALES devem ter um tempo de resposta mdio inferior
a 60 milissegundos.
Cada poltica de desempenho inclui um objetivo de desempenho para cada classe de
desempenho, a menos que a classe esteja marcada como somente para medida. Nessa
release, o gerenciamento de qualidade do servio suporta apenas um tipo de objetivo de
desempenho, o tempo de resposta mdio.
O tempo de resposta se baseia nas chamadas do cliente de banco de dados do momento em
que o servidor de banco de dados recebe a solicitao na rede at a hora em que ela sai do
servidor. Ele no inclui o tempo necessrio para enviar as informaes para/do cliente na
rede. O valor mdio dos tempos de resposta referentes a todas as chamadas do cliente de
banco de dados em uma classe de desempenho calculado e apresentado como o tempo de
resposta mdio.

Mtricas de Atendimento de Desempenho
possvel comparar diferentes objetivos de desempenho

usando a PSM (Performance Satisfaction Metric, Mtrica
de Atendimento de Desempenho).
A PSM mostra rapidamente como o sistema est lidando
com o objetivo.
100%
-100%
Objetivos de desempenho diferentes so usados para medir o desempenho de cargas de

trabalho distintas. No momento, o gerenciamento de qualidade do servio suporta somente
cargas de trabalho OLTP e usa apenas o objetivo de desempenho de tempo de resposta
mdio. Ao configurar o gerenciamento de qualidade do servio, voc poder ter objetivos de
desempenho muito diferentes para cada classe de desempenho. Por exemplo, um objetivo
de desempenho poder especificar que uma chamada de check-out (Checkout call) deve ser
concluda em 1 milissegundo, enquanto outro poder especificar que uma chamada de
pesquisa (Browse call) deve ser concluda em 1 segundo. medida que mais objetivos de
desempenho forem adicionados a um sistema, poder ser difcil compar-los rapidamente.
Por esse motivo, til ter uma medida numrica comum e consistente que indique como a
carga de trabalho atual de uma classe de desempenho est se comportando em relao ao
respectivo objetivo de desempenho atual. Essa medida numrica chamada PSM
(Performance Satisfaction Metric). Portanto, a Performance Satisfaction Metric um valor
numrico normalizado (entre +100% e -100%) que indica se determinado objetivo de
desempenho est sendo atendido de forma adequada e que permite ao gerenciamento de
qualidade do servio comparar o desempenho do sistema em relao a objetivos bastante
diferentes.

Sobreposies de Diretivas
de Pool de Servidores
Poltica do Horrio Comercial
Online SP Back Office SP Batch SP
Poltica Fora do Horrio Comercial
Poltica do Final do Trimestre
Uma poltica de desempenho tambm pode conter um conjunto de sobreposies de

diretivas de pool de servidores. Uma substituio de diretiva de pool de servidores define os
nmeros mnimo e mximo de servidores e os atributos de importncia para um pool de
servidores quando a poltica de desempenho est em vigor. As substituies de diretivas de
pools de servidores atuam como restries s recomendaes propostas pelo
Gerenciamento de Qualidade de Servio, pois elas so respeitadas enquanto a poltica de
desempenho est ativa. Por exemplo, o gerenciamento de qualidade do servio nunca
recomendar a remoo de um servidor de um pool caso isso faa com que o pool fique
abaixo de sua contagem mnima de servidores.
As sobreposies de diretivas de pool de servidores podem ser usadas para definir o estado
normal dos pools de servidores em diversos momentos. O slide ilustra um exemplo. Sob
condies normais, essas definies de pool de servidores devem ser capazes de tratar da
carga de trabalho predominante. Se houver um aumento repentino das solicitaes de carga
de trabalho em uma classe de desempenho, o pool de servidores associado poder exigir
mais recursos do que o especificado na poltica de desempenho.

Viso Geral de Mtricas
O Gerenciamento de Qualidade de Servio usa um

conjunto padronizado de mtricas.
H dois tipos de mtricas:
As mtricas de desempenho, que fornecem uma viso geral
de onde o tempo est sendo gasto no sistema.
As mtricas de recursos, que medem o perodo em que as
solicitaes de trabalho usam ou aguardam um recurso.
As mtricas so usadas para identificar recursos com
gargalo e determinar a melhor ao corretiva:
No caso de uma classe de desempenho, o recurso
congestionado o que contribui para o maior tempo de
espera mdio.
O gerenciamento de qualidade do servio usa um conjunto padronizado de mtricas, que so

coletadas por todos os servidores do sistema. H dois tipos de mtricas: de desempenho e
de recursos. Essas mtricas permitem a observao direta do uso e do tempo de espera
incorridos pelas solicitaes de trabalho em cada classe de desempenho, para cada recurso
solicitado, medida que ele percorre os servidores, as redes e os dispositivos de
armazenamento que compem o sistema.
As mtricas de desempenho so coletadas no ponto de entrada para cada servidor no
sistema. Elas fornecem uma viso geral de onde o tempo gasto no sistema, bem como
permitem comparar os tempos de espera observados em todo o sistema. Os dados so
coletados periodicamente e encaminhados a um ponto central para anlise, tomada de
deciso e armazenamento histrico.
Uma mtrica de desempenho importante o tempo de resposta, ou seja, a diferena entre o
momento em que uma solicitao recebida e a hora em que uma resposta enviada. A
mdia do tempo de resposta de todas as chamadas do banco de dados em uma classe de
desempenho calculada e apresentada como o tempo de resposta mdio. Outra mtrica de
desempenho importante a taxa de chegada de solicitaes de trabalho. Ela fornece uma
medida da demanda associada a cada classe de desempenho.

H mtricas de recursos para os seguintes recursos: CPU, Entrada/Sada de
Armazenamento, Cache Global e Outros (esperas de banco de dados). Duas mtricas so
fornecidas para cada recurso:
Tempo de uso do recurso: mede quanto tempo gasto no uso do recurso
Tempo de espera pelo recurso: mede o tempo gasto aguardando o recurso
As mtricas do gerenciamento de qualidade do servio fornecem as informaes necessrias
para identificar sistematicamente gargalos de classes de desempenho no sistema. Quando
uma classe viola seu objetivo de desempenho, o gargalo correspondente o recurso que
contribui com o maior tempo de espera mdio para cada solicitao de trabalho dessa
classe.

Arquitetura do Gerenciamento de QoS
Origens de Servidor de Enterprise

Dados Gerenciamento Manager
de QoS
Oracle
RAC Interfaces Management
de Cliente JMX
Conectores de Dados e
11.2 JDBC Dashboard
Gerenciador de Dados
XML
Policy Set
Wizard
Oracle
Clusterware Policy Engine Performance
11.2 SRVM
Oracle Business Rules History
Alerts &
Sistema Actions
Operacional
CHM Persistence
Manager
O gerenciamento de qualidade do servio recupera dados de mtricas de cada instncia de

banco de dados em execuo nos pools de servidores gerenciados e correlaciona os dados
por classe de desempenho a cada 5 segundos. Os dados incluem vrias mtricas; por
exemplo, taxa de chegada de chamadas, uso de CPU, Entrada/Sada e Cache Global, alm
de tempos de espera. Os dados so combinados com a topologia atual do cluster e a
integridade dos servidores no Policy Engine para determinar o perfil de desempenho geral do
sistema em relao aos objetivos de desempenho atuais estabelecidos pela poltica de
desempenho ativa.
A avaliao do desempenho ocorre uma vez a cada minuto e resultar em uma
recomendao se uma classe de desempenho no estiver atendendo a seu objetivo. A
recomendao especifica em qual recurso h gargalos. Aes corretivas especficas so
includas, se possvel, juntamente com o impacto projetado em todas as classes de
desempenho do sistema. O slide mostra a coleta de dados de vrias origens pelo
componente de conectores de dados do gerenciamento de qualidade do servio:
O Oracle RAC 11.2 se comunica com o conector de dados usando JDBC.
O Oracle Clusterware 11.2 se comunica com o conector de dados usando o
componente SRVM do Oracle Clusterware.
O sistema operacional de servidor se comunica com o conector de dados por meio do
Cluster Health Monitor (CHM).
O Enterprise Manager exibe as informaes em uma variedade de maneiras, por exemplo,
nas pginas Management Dashboard, Policy Set Wizard, Performance History e Alerts and
Actions.
Recomendaes do Gerenciamento de QoS
Se os objetivos de desempenho no estiverem sendo atendidos,

o Gerenciamento de Qualidade de Servio far uma
recomendao.
Cada recomendao se concentra em aperfeioar a classe de
desempenho que apresente a classificao mais alta,
excedendo seu objetivo de desempenho.
As recomendaes podem incluir:
Alterar os mapeamentos de grupos de consumidores
Redefinir a prioridade do trabalho dentro dos limites dos recursos
existentes.
Mover servidores entre pools de servidores
Redefinir a prioridade dos recursos entre pools de servidores para
atender s demandas da carga de trabalho.
Mover as CPUs entre os bancos de dados em um pool de
servidores
Redefinir a prioridade dos recursos da CPU dentro dos limites dos pools
de servidores existentes.
Caso sua empresa enfrente picos de demanda peridicos, para manter os nveis de
desempenho das aplicaes, voc poder adquirir hardware adicional, o qual poder ser
disponibilizado ou permanecer ocioso, de acordo com as necessidades. Em vez de ter
servidores extras que permanecem ociosos durante a maior parte do tempo, voc poder
usar esses servidores para executar cargas de trabalho de outras aplicaes. Entretanto, se
os servidores estiverem ocupados executando outras aplicaes quando houver um pico de
demanda, suas principais aplicaes de negcios no podero ter o desempenho esperado.
O gerenciamento de qualidade do servio ajuda a gerenciar situaes desse tipo.
Quando voc implementa uma poltica de desempenho, o gerenciamento de qualidade do
servio monitora continuamente o sistema e o gerencia usando um processo iterativo.
Quando um ou mais objetivos de desempenho no esto sendo atendidos, cada iterao
procura melhorar o desempenho de um nico objetivo; o objetivo de desempenho com
classificao mais alta que no est sendo alcanado. Quando todos os objetivos de
desempenho esto sendo alcanados, o gerenciamento de qualidade do servio no faz
mais recomendaes.
As recomendaes podem incluir mover servidores entre os pools de servidores, alterar os
mapeamentos de grupos de consumidores ou mover CPUs entre os bancos de dados em um
pool de servidores.

A alterao dos mapeamentos de grupos de consumidores poder envolver a promoo de
uma carga de trabalho especfica para que ela obtenha uma parcela maior dos recursos ou o
rebaixamento de uma carga de trabalho concorrente a fim de disponibilizar mais recursos para
a classe de desempenho-alvo. Nos dois casos, uma nova prioridade atribuda s cargas de
trabalho dentro dos limites de recursos existentes.
Outra abordagem usada pelo gerenciamento de qualidade do servio mover os servidores
entre pools de servidores. Essa abordagem altera a distribuio de servidores para atender s
demandas das cargas de trabalho.
A partir do Oracle Database release 11.2.0.3, o gerenciamento de qualidade do servio
tambm pode mover recursos de CPU entre bancos de dados no mesmo pool de servidores.
Isso altera a distribuio dos recursos de CPU entre instncias de banco de dados que usam a
funcionalidade Instance Caging, bem como permite maior controle dos ambientes em que h
vrios bancos de dados consolidados no mesmo ambiente do Exadata Database Machine.

Implementando Recomendaes
Quando o gerenciamento de qualidade do servio est operando para melhorar o

desempenho de determinada classe de desempenho, ele recomenda aumentar a quantidade
do recurso com gargalo (como tempo de CPU) para essa classe ou disponibilizar esse
recurso mais rpido para as solicitaes de trabalho dessa classe.
A implementao de uma recomendao reduz a disponibilidade do recurso para outras
classes de desempenho. O impacto negativo nas classes de desempenho das quais o
recurso removido poder ser bem menor do que o impacto positivo no servio cujo acesso
melhorado, resultando em um ganho lquido para o sistema como um todo. Opcionalmente,
a classe de desempenho penalizada poder ser menos crtica para os negcios do que a
classe beneficiada.
Ao gerar recomendaes, o gerenciamento de qualidade do servio avalia o impacto no
desempenho do sistema como um todo. Se a melhoria para uma classe de desempenho for
relativamente pequena, mas o impacto negativo em outra classe for grande, o gerenciamento
de qualidade do servio poder indicar que o ganho de desempenho muito pequeno e no
recomendado. Se houver mais de uma forma de resolver o gargalo, o gerenciamento de
qualidade do servio propor a melhor recomendao geral, levando em considerao
variveis como o impacto calculado em todas as classes de desempenho, junto com a
interrupo prevista no funcionamento e o tempo de estabilizao associado ao. A
recomendao atual e as recomendaes alternativas podem ser exibidas com o Oracle
Enterprise Manager.
Os dados de desempenho so enviados ao Oracle Enterprise Manager para exibio nas
pginas QoS Management Dashboard e Performance History. So gerados alertas para
notificar que um ou mais objetivos de desempenho no esto sendo alcanados ou que um
problema est impedindo que um ou mais pools de servidores sejam gerenciados. Como
resultado dessas notificaes, o administrador poder implementar a recomendao.
Nesta release, o gerenciamento de qualidade do servio no implementa as recomendaes
automaticamente. Ele sugere uma forma de aperfeioar o desempenho que, em seguida,
dever ser implementada pelo administrador clicando no boto Implement. Aps a
implementao de uma recomendao, o sistema tem um tempo para se estabilizar antes de
novas recomendaes serem feitas. O objetivo disso garantir que dados estveis sejam
usados para avaliaes futuras, bem como evitar recomendaes que resultem em aes
oscilantes.

Questionrio
O Gerenciamento de Qualidade de Servio no Oracle

Database ajuda a manter os objetivos de desempenho,
reduzindo o uso de recursos.
a. Verdadeiro
b. Falso
Resposta: b
O gerenciamento de qualidade do servio do Oracle Database ajuda a atender aos objetivos
de desempenho gerenciando e reduzindo os tempos de espera por recursos, e no o seu
uso.

Questionrio
As recomendaes do gerenciamento de qualidade do servio

do Oracle Database podem incluir
a. Mover servidores entre pools de servidores
b. Adicionar spindles para melhorar o desempenho de
entrada/sada
c. Alterar os mapeamentos de grupos de consumidores
d. Recomendar estratgias de particionamento para
minimizar os gargalos do cache global
Resposta: a, c
O gerenciamento de qualidade do servio do Oracle Database capaz de identificar
problemas de desempenho de entrada/sada ou gargalos do cache global, mas no pode
tratar dessas questes nesta release.

Sumrio
Nesta lio, voc aprendeu a descrever:

A finalidade do Gerenciamento de Qualidade de Servio
no Oracle Database
As vantagens de usar o Gerenciamento de Qualidade de
Os componentes do Gerenciamento de Qualidade de
O funcionamento do Gerenciamento de Qualidade de

Demonstraes da Lio 12
Configurando o Gerenciamento de Qualidade do Servio

Usando o Gerenciamento de Qualidade de Servio

Arquitetura Multilocatrio e RAC
Objetivos
Ao concluir esta lio, voc ser capaz de:

Descrever a arquitetura multilocatria em um ambiente no
RAC
Descrever a arquitetura multilocatria em um ambiente RAC
Criar um banco de dados continer multilocatrio RAC (CDB)
Criar um PDB (banco de dados plugvel) em um CDB RAC
Usar servios padro de CDB e PDB
Criar servios de PDB para associ-los a pools de servidores
Eliminar um PDB (banco de dados plugvel) de um CDB
RAC
Observao: Para um entendimento completo sobre o novo recurso Oracle Multitenant e seu
uso, consulte os guias a seguir na documentao da Oracle:
Oracle Database Administrator's Guide 12c Release 1 (12.1)
Oracle Database Concepts 12c Release 1 (12.1)
Consulte outras fontes de informaes:
Na Oracle Learning Library: Demonstraes de Oracle Database 12c New Features
Demo Series:
- Arquitetura Multilocatria
- Noes Bsicas da Arquitetura do CDB e do PDB
Na Oracle Learning Library: Oracle By Example (OBE):
- Realizando Tarefas Bsicas em Bancos de Dados de Continer de Vrios
Locatrios e em Bancos de Dados Plugveis
Usando o My Oracle Support:
- Oracle Multitenant Option - 12c : Frequently Asked Questions (Doc ID 1511619.1)
Os cursos intitulados Oracle Database 12c: New Features for Administrators e Oracle
Database 12c: Managing Multitenant Architecture

Arquitetura no CDB
Instncia
System Global Area
Servidor
Estruturas de Processo
Instncia
Banco de
Dados
Banco de Dados
(Estruturas de Armazenamento)
Muitos no CDBs no compartilham nada:

Muitos processos em segundo plano
Alta memria de processo/compartilhada
Muitas cpias de metadados Oracle
No Oracle Database 12c, h duas configuraes possveis, no CDB e banco de dados

continer multilocatrio.
No banco de dados Oracle 11g, o nico tipo de banco de dados com suporte um no CDB.
Chamamos a arquitetura antiga de arquitetura no CDB o termo no CDB ser usado
como atalho para uma ocorrncia de um banco de dados pr-12.1 que usa a arquitetura pr-
12.1. Essa arquitetura exige sua prpria instncia e, portanto, seus prprios processos em
segundo plano e alocao de memria para a SGA, alm de precisar armazenar os
metadados Oracle em seu dicionrio de dados. O administrador do banco de dados ainda
pode criar no CDBs Oracle 12c com a mesma arquitetura pr-12.1. Esses bancos de dados
so no CDBs.
Se existirem vrios bancos de dados no mesmo servidor, haver uma instncia separada e
distinta para cada banco de dados, seja no CDB ou CDB. Uma instncia no pode ser
compartilhada entre um no CDB e um CDB.
Quando voc precisa administrar pequenas aplicaes de banco de dados departamentais,
necessrio criar vrios bancos de dados e aplicaes e, portanto, multiplicar o nmero de
instncias e, consequentemente, o nmero de processos em segundo plano e a alocao de
memria para as SGAs, alm de provisionar armazenamento suficiente para todos os
dicionrios de dados desses bancos de dados.
Quando necessrio atualizar suas aplicaes para uma nova verso, voc precisa atualizar
cada banco de dados, o que um processo muito demorado para o DBA.

Arquitetura Multilocatria: Vantagens
Opera vrios bancos de dados em uma plataforma

centralmente gerenciada para reduzir os custos:
Menos sobrecarga de instncias
Menos custos de armazenamento
Reduz os custos de recursos do DBA e mantm a
segurana
No h alteraes nas aplicaes
Provisionamento rpido e fcil
Economia de tempo para aplicao de patches e
atualizaes
Mantm a separao de tarefas entre:
Diferentes administradores de aplicaes
Administradores de aplicaes e o DBA
Usurios dentro da aplicao
Fornece isolamento
Consolidar vrios bancos de dados no CDB em uma nica plataforma reduz a sobrecarga
de instncias, evita cpias redundantes de dicionrios de dados e, consequentemente, a
alocao de armazenamento, alm de se beneficiar com o rpido provisionamento, as
rpidas atualizaes, a segurana reforada por meio da separao de tarefas e o
isolamento da aplicaes. A nova arquitetura multilocatria do 12c que consolida bancos de
dados um banco de dados continer multilocatrio (CDB) e um banco de dados
consolidado dentro de um CDB, um banco de dados plugvel ou PDB.
Os custos de recursos do DBA so reduzidos com:
Ausncia de alteraes nas aplicaes e um provisionamento extremamente rpido:Um
novo banco de dados pode ser provisionado rapidamente. Um clone de um banco de
dados populado pode ser criado rapidamente. Um banco de dados populado pode ser
desconectado rapidamente do seu CDB em uma plataforma e conectado rapidamente a
um CDB em uma plataforma diferente. Um no CDB pode ser conectado rapidamente
em um CDB.
Rpida atualizao e aplicao de patches da verso do Oracle Database:O custo
(tempo gasto e esforo humano necessrio) para atualizar vrios PDBs o custo de
atualizao de uma nica ocorrncia do Oracle Database. Voc tambm pode atualizar
um nico PDB desconectando-o e conectando-o a um CDB em uma verso diferente do
banco de dados Oracle.

A arquitetura de vrios locatrios mantm:
Separao segura de tarefas: O administrador de uma aplicao pode realizar todas as
tarefas necessrias criando uma conexo com o PDB especfico que implementa seu
back-end. No entanto, um usurio que se conecta a um PDB no pode ver outros
PDBs. Para gerenciar PDBs como entidades (por exemplo, para criar, descartar,
desconectar ou conectar um PDB), o administrador do sistema precisa se conectar ao
CDB. Para essas tarefas especficas, novos privilgios precisam ser concedidos.
Isolamento de aplicaes, que no pode ser obtido manualmente, a menos que o
Database Vault seja utilizado, por exemplo. Um bom exemplo de isolamento a
separao de dicionrios, permitindo que o Oracle Database gerencie os vrios PDBs
separadamente uns dos outros e do CDB propriamente dito.

CDB em um Ambiente no RAC

Instncia
Servidor
System Global Area
PDBid2 PDBid3 PDBid4 PDBid2 PDBid4
Instncia
Estruturas de Processo
Banco de
dados
continer Arquivos de dados Arquivos de Arquivos de
multilocatrio controle redo log
SYSTEM UNDO
Compartilhamentos
nicos de BD: SYSAUX TEMP
Processos de continer-raiz
segundo plano
Memria
Arquivos de dados Arquivos de dados Arquivos
compartilhada/ de dados
de processo SYSTEM SYSTEM
Metadados Oracle TEMP TEMP
Arquivos de redo log SYSAUX SYSAUX TBS2
Arquivos de controle PDB de pr-implantao PDB SALES PDB HR
Tablespace Undo
O grfico no slide mostra um CDB com quatro contineres: a raiz, o de pr-implantao e

dois PDBs.
As duas aplicaes usam uma nica instncia e so mantidas separadamente.
No nvel fsico, o CDB contm uma instncia e arquivos de banco de dados, da mesma forma
que um banco de dados no-continer.
Os arquivos de log redo so comuns para o CDB inteiro. As informaes que ele
contm so anotadas com a identidade do PDB onde ocorre uma alterao. O Oracle
GoldenGate foi aprimorado para entender o formato do redo log de um CDB. Todos os
PDBs em um CDB compartilham o modo ARCHIVELOG do CDB.
Os arquivos de controle so comuns a todo o CDB. Os arquivos de controle so
atualizados para refletir qualquer tablespace adicional e os arquivos de dados de PDBs
conectados.
O tablespace UNDO comum para todos os contineres na instncia do banco de
dados.
Um tablespace temporrio comum a todos os contineres necessrio. Porm, cada
PDB pode conter seu prprio tablespace temporrio para seus prprios usurios locais.
Cada continer tem seu prprio dicionrio de dados armazenado em seu tablespace
SYSTEM apropriado, que contm seus prprios metadados e um tablespace SYSAUX.
Os PDBs podem criar tablespaces dentro do PDB de acordo com as necessidades da
aplicao.
Cada arquivo de dados associado a um continer especfico, chamado de CON_ID.
Contineres
Dois tipos de contineres em V$CONTAINERS:

O continer raiz
O primeiro continer obrigatrio gerado na criao do CDB
Metadados e objetos comuns fornecidos pelo sistema Oracle
Funes e usurios comuns fornecidos pelo sistema Oracle
Contineres de bancos de dados plugveis (PDBs)
Um continer para uma aplicao:
Tablespaces (permanentes e temporrios)
Esquemas/Objetos/Privilgios
Criados/clonados/desconectados/conectados
PDB$SEED pr-implantado especfico: rpido provisionamento de
um novo PDB
Limite de 253 PDBs em um CDB, incluindo o de pr-implantao
Limite de 1024 servios em um CDB
Um CDB um banco de dados Oracle que contm a raiz, a pr-implantao e zero a n

PDBs.
O que um PDB em um CDB? Um PDB a parte inferior do dicionrio de dados
horizontalmente particionado, mais os dados de consumo de cota do usurio.
Um no CDB no pode conter PDBs.
A arquitetura de vrios locatrios permite que um banco de dados Oracle contenha uma
coleo porttil de esquemas, objetos de esquema e objetos de no esquema que aparece
para um cliente Oracle Net como um banco de dados separado. Para que os PDBs possam
existir e funcionar, o CDB requer um tipo especfico de continer, o continer raiz, gerado na
criao da CDB. A raiz um continer fornecido pelo sistema que armazena usurios
comuns, ou seja, usurios que podem se conectar a vrios contineres, alm de dados e
metadados fornecidos pelo sistema. Por exemplo, o cdigo-fonte para pacotes PL/SQL
fornecidos pelo sistema armazenado na raiz. Quando o continer raiz existe, voc pode
criar contineres do outro tipo, o PDB.
H apenas um PDB de pr-implantao em um CDB. O PDB de pr-implantao um
modelo fornecido pelo sistema que usado para criar novos PDBs.
Um CDB pode conter at 253 PDBs, incluindo o de pr-implantao e 252 PDBs definidos
pelo usurio podem portanto ser criados, com IDs variando de 3 a 254.
A view V$CONTAINERS mostra todos os contineres, incluindo a raiz.
Terminologia
CDB1
DBA, CDBA e PDBA View CDB_USERS root

USERNAME COMMON
Comum vs Local: SYS SIM
Usurios SYSTEM SIM
C##JIM SIM
Um usurio comum s pode ser
DBSNMP SIM
criado no continer raiz.
HR_MGR NO
Um usurio local somente pode ser SALES NO
criado e conhecido em um PDB.
Atribuies SQL> CREATE USER C##JIM
IDENTIFIED BY x CONTAINER=ALL;
Um usurio comum s pode ser
criado no continer raiz. PDB_HR
View DBA_USERS
SQL> CREATE ROLE C##manager
CONTAINER=ALL; USERNAME COMMON
SYS SIM
Um usurio local somente pode ser
SYSTEM SIM
criado e conhecido em um PDB.
C##JIM SIM
Privilgios DBSNMP SIM
HR_MGR NO
Nvel do CDB versus nvel do PDB
Existem trs tipos de administradores de bancos de dados.

Em um no CDB, o DBA responsvel por todas as tarefas administrativas no nvel do
banco de dados.
Em um CDB, h dois nveis de administrao:
Um CDBA responsvel por administrar a instncia do CDB e o continer raiz.
Um PDBA responsvel por administrar seu prprio PDB.
H uma nova terminologia para novas entidades.
Comum vs local:
- Usurios / atribuies comuns / versus usurios / atribuies locais: Um usurio comum
um usurio que possui o mesmo nome de usurio e as mesmas credenciais em
vrios PDBs, ao contrrio do usurio local, que existe em somente um PDB. Um
usurio local um usurio tradicional, criado e conhecido apenas em seu prprio PDB.
Uma atribuio criada em todos os contineres uma atribuio comum. Uma
atribuio criada em um PDB especfico local.
- Privilgios comuns versus privilgio local: Um privilgio se torna comum ou local com
base na forma como concedido. Um privilgio concedido em todos os contineres
um privilgio comum. Um privilgio concedido em um PDB especfico local.
Nvel do CDB versus nvel do PDB:
- O gerenciamento de recursos do CDB funciona no nvel do CDB, enquanto o
gerenciamento de recursos do PDB funciona no nvel do PDB.
- Podem ser criadas polticas de auditoria unificadas no nvel do CDB e no nvel do PDB.
Views de Dicionrio de Dados

CDB_xxx Todos os objetos no banco de dados continer multilocatrio
em todos os PDBs
DBA_xxx Todos os objetos em um banco de dados continer
ou em um banco de dados plugvel
ALL_xxx Objetos acessveis pelo usurio atual
USER_xxx Objetos que pertencem ao usurio atual
SQL> SELECT view_name FROM dba_views WHERE view_name like 'CDB%';
CDB_pdbs: Todos os PDBS no CDB

CDB_tablespaces: Todos os tablespaces no CDB
CDB_users: Todos os usurios dentro do CDB (comuns e locais)
Views de dicionrios DBA que fornecem informaes dentro do PDB:
SQL> SELECT table_name FROM dict WHERE table_name like 'DBA%';
Para compatibilidade com verses anteriores, as views DBA mostram os mesmos resultados
em um PDB que em um no CDB: DBA_OBJECTS mostra os objetos que existem no PDB a
partir do qual voc executa a consulta. Por sua vez, isso quer dizer que, embora o PDB e a
raiz tenham dicionrios de dados separados, cada view de dicionrio de dados em um PDB
mostra resultados obtidos de ambos esses dicionrios de dados. As views DBA_xxx na raiz
mostram, mesmo em um CDB populado, somente o sistema fornecido pela Oracle, como
pode ser visto em um no CDB recm-criado. Esta outra vantagem da nova arquitetura.
Para dar suporte s tarefas do administrador do CDB, uma nova famlia de views de
dicionrios de dados pode ser usada com nomes como CDB_xxx. Cada view DBA_xxx tem
uma contraparte de view CDB_xxx com uma coluna extra, Con_ID, que mostra de qual
continer os fatos listados so originados. Consulte as views CDB_xxx a partir da raiz e de
qualquer PDB. As views CDB_xxx so teis quando consultadas a partir da raiz, pois os
resultados de uma determinada view CDB_xxx so a unio dos resultados da contraparte da
view DBA_xxx sobre a raiz e todos os PDBs atualmente abertos. Quando uma view
CDB_xxx consultada a partir de um PDB, ela mostra apenas as informaes apresentadas
em sua contraparte da view DBA_xxx. Se voc se conectar raiz e consultar CDB_USERS,
obter a lista de usurios, comuns e locais, de cada continer. Agora, se voc consultar
DBA_USERS, receber a lista de usurios comuns (voc sabe que na raiz existem somente
usurios comuns). Agora, se voc se conectar a um PDB e consultar CDB_USERS ou
DBA_USERS, receber a mesma lista de usurios, comuns e locais, do PDB.
O mesmo princpio de compatibilidade com verses anteriores tambm se aplica a cada um
das v$views familiares.
Conexo a um CDB no RAC

CDB1
root Ferramentas
SQL*Plus
SQL*Developer
PDBtest
Listener/Servio
PDBHR
Servidor de
Aplicaes
PDBdev SQL*Plus
Ferramentas
Listener/Servio
1. Todo PDB tem um servio padro gerado na criao do PDB.

SQL> SELECT name, pdb FROM cdb_services;
2. O nome do servio deve ser exclusivo entre CDBs.

SQL> CONNECT / AS SYSDBA
SQL> CONNECT sys@"hostname:1525/CDB1" AS SYSDBA
SQL> CONNECT sys@"hostname:1525/PDBtest" AS SYSDBA
SQL> CONNECT local_user1@"hostname/PDBHR"
SQL> CONNECT common_user2@"hostname/PDBdev"
SQL> SHOW CON_NAME
Quando voc se conecta a um CDB, deseja se conectar raiz ou a um PDB especfico.

Qualquer continer em um CDB possui um nome de servio.
O nome do servio do continer raiz o nome dado ao CDB na criao do CDB,
concatenado com o nome do domnio.
Cada novo PDB recebe um nome de servio: o nome do servio o nome do PDB
especificado na criao do PDB, concatenado com o nome do domnio. Se voc criar
ou conectar um PDB PDBtest, seu nome de servio ser PDBtest concatenado com
o nome do domnio. Os nomes de servios de contineres devem ser exclusivos dentro
de um CDB, e at mesmo entre CDBs que se registram no mesmo listener.
Voc pode localizar todos os nomes de servios mantidos em um CDB e em PDBs nas
views CDB_SERVICES ou V$SERVICES. A coluna PDB mostra o PDB ao qual os
servios so vinculados.
Para se conectar raiz, use a autenticao de SO local ou o nome do servio raiz. Por
exemplo, se voc definir ORACLE_SID como o nome da instncia do CDB e usar o
comando CONNECT / AS SYSDBA, ser conectado raiz com o usurio comum SYS
que recebeu privilgios do sistema para gerenciar e manter todos os PDBs.
Com o nome do servio, voc poder usar a sintaxe do EasyConnect ou o alias de
tnsnames.ora.

Usando o EasyConnect, voc deve inserir a seguinte string de conexo:
SQL> CONNECT username@"hostname:portnumber/service_name"
SQL> CONNECT username@"localhost:portnumber/service_name"
Usando o arquivo tnsnames.ora, insira a seguinte string de conexo:
SQL> CONNECT username@"localhost:net_service_name
Para se conectar a um PDB desejado, use o Easyconnect ou o alias do arquivo
tnsnames.ora, por exemplo, conforme mostrado no slide. Nos nossos exemplos, o nome
do servio net em tnsnames.ora corresponde ao nome do servio.

Alternando Conexes
Duas maneiras possveis de alternar a
Banco de Dados Continer
Multilocatrio conexo entre contineres dentro de um CDB:
CDB1 Reconexo
root SQL> CONNECT / AS SYSDBA
SQL> CONNECT local_user1@PDBdev
PDBtest Use a instruo ALTER SESSION:
SQL> CONNECT sys@PDBtest AS SYSDBA
PDBHR
SQL> ALTER SESSION SET CONTAINER=PDBHR;
SQL> SHOW CON_NAME
PDBdev SQL> ALTER SESSION SET
CONTAINER=CDB$ROOT;
Usar CONNECT permite a conexo como um usurio comum ou local.

Usar ALTER SESSION SET CONTAINER permite conexo como um
usurio comum apenas a quem possui o novo privilgio do sistema
SET CONTAINER.
Os triggers AFTER LOGON no so acionados.
As transaes ainda ficam pendentes aps a mudana de contineres.
Um administrador de CDB pode se conectar a qualquer continer no CDB usando CONNECT

ou ALTER SESSION SET CONTAINER para alternar entre contineres. Por exemplo, o
administrador do CDB pode conectar-se raiz em uma sesso e, em seguida, na mesma
sesso, alternar para o continer PDBHR. Isso exige que ele seja um usurio comum
conhecido em ambos os contineres e tenha um privilgio do sistema SET CONTAINER.
Usar o comando CONNECT permite conexes como usurios comuns ou locais.
Usar ALTER SESSION SET CONTAINER permite conexes como um usurio comum
somente para quem possui o novo privilgio do sistema SET CONTAINER.
- Lembre-se de que os triggers AFTER LOGON no so disparados.
- Transaes no confirmadas nem revertidas no continer original ainda esto em
um estado pendente no momento em que ocorre a alternncia para outro
continer e no momento em que ocorre a alternncia de volta para o continer
original.

Configurao do Oracle RAC e de Multilocatrios
Instncia Servios
Banco de Dados no CDB
do RAC
No CDB e CDB
Configuraes
hr sale acct
Servios I1 I2 I3
do PDB
Instncia Configurao do CDB
do CDB
pdba Instncia Instncia Servios
No CDB PRODDB do RAC do PDB
pdbb
iprod
pdbc No CDB
icdb1
pdba pdbb pdbc
crac1 crac2 crac3
PDB
PDBA PDBB PDBC

CDB CDB1 PDB
PRODDB PDBA PDBB PDBC

CDB CRAC
No CDB
No Oracle Database 12c, h trs opes de configurao possveis:

No CDB: a arquitetura antiga do Oracle Database 11g
Configurao de locatrio nico: o caso especial da nova arquitetura que no requer
a opo licenciada (opo Oracle Multitenant)
Configurao de vrios locatrios: normalmente, mais de um PDB por CDB, mas
pode conter zero, um ou muitos PDBs a qualquer momento, tirando proveito de todos
os recursos da nova arquitetura, o que exige a opo Oracle Multitenant licenciada
Quais so as possveis configuraes de instncia/banco de dados no Oracle Database 12c?
Em um ambiente no RAC, cada instncia de banco de dados pode ser associada a um
e apenas um no CDB ou CDB.
Em um ambiente RAC, vrias instncias podem ser associadas a um no CDB ou CDB.
Uma instncia associada a um CDB inteiro.

Arquitetura do Oracle RAC e de Multilocatrios
Em uma arquitetura multilocatria, h:

Diversas instncias por CDB
Um tablespace UNDO por instncia do CDB
Pelo menos dois grupos de arquivos de redo log por
instncia do CDB
Cada continer exposto como
Instncia Servio
um servio: do RAC PDB
A raiz
Cada PDB pdba pdbb pdbc
CRAC1 CRAC2 CRAC3
Gerenciamento de servios:
Servios padro de banco de dados
Bancos de dados gerenciados por polticas: PDBA PDBB PDBC
nicos CRAC
Uniformes em todos os servidores em um CDB PDB

pool de servidores
Um CDB RAC, exatamente como um no CDB RAC, contm:

Um tablespace UNDO por instncia
Pelo menos dois grupos de arquivos de redo log por instncia
Servios internos no nvel do CDB: Como em um no CDB RAC, SYS$BACKGROUND
usado somente pelos processos de background. SYS$USERS o servio default para
sesses de usurio no associadas a qualquer servio de aplicao. Os dois servios
internos suportam todos os recursos de gerenciamento de carga de trabalho e nenhum
deles pode ser interrompido ou desativado. Um servio especial do CDB Oracle
criado por padro pelo CDB Oracle RAC cujo nome o nome do CDB.
Ao usar a arquitetura multilocatria, cada continer exposto como um servio. A raiz e cada
PDB recebem um servio do banco de dados, quando o continer criado.
Com os bancos de dados gerenciados por polticas do clusterware, cada servio PDB pode
ser exposto por todas as instncias do RAC ou em um subconjunto de instncias ou em uma
nica instncia (conforme mostrado no diagrama do slide). Os Servios do PDB podem ser
associados aos pools de servidores. Como qualquer servidor nos pools de servidores no
cluster pode executar qualquer um dos CDBs, voc no precisa criar e manter mapeamentos
de nome-de-instncia-para-n no CDB nem mapeamentos de nome-de-servio-para-n no
PDB.

Criando um CDB RAC
Ao criar um CDB RAC com o DBCA, defina o tipo do banco de dados, assim como ao criar
um no CDB RAC:
Um banco de dados de instncia nica Oracle
Um banco de dados Oracle Real Applications Clusters (RAC)
Um banco de dados Oracle RAC One Node
Na mesma etapa, escolha, assim como ao criar um no CDB RAC, entre dois tipos de estilo
de gerenciamento:
Gerenciado por Poltica
Gerenciado por Admin.

Criando um CDB RAC incluindo PDBs
Em seguida, marque a caixa de seleo "Create As Container Database" para criar o banco
de dados como um CDB, caso contrrio o banco de dados ser criado como um no CDB.
Fornea um nome ao PDB (banco de dados plugvel) ao usar a opo "Create a database
with default configuration". Se a opo "Advanced Mode" estiver selecionada como est no
exemplo do slide, um CDB vazio pode ser criado com apenas os continers raiz e pr-
implantado ou o CDB poder ser criado com um ou vrios PDBs. Se o CDB contiver apenas
um PDB, saiba que no deve fornecer um nome existente de outro CDB ao PDB. Se o CDB
contiver vrios PDBs, solicitado um sufixo para gerar os nomes do PDB.
No Advanced Mode, o CDB pode ser registrado com o Enterprise Manager Cloud Control
e/ou configurado para Enterprise Manager Database Express. As senhas para os usurios
SYS e SYSTEM tambm podem ser definidas.

Hospedando um CDB RAC nos Pools de Servidores
Como a configurao gerenciada por polticas foi selecionada, voc precisa definir o pool de
servidores para hospedar o novo CDB. Escolha entre usar um pool existente de servidores
ou criar um novo, e especificar os detalhes do novo pool de servidores a ser usado pelo
CDB.
As implantaes gerenciadas por polticas facilitam a consolidao. No caso da consolidao
de esquemas, em que vrias aplicaes esto sendo hospedadas em um nico banco de
dados (CDB) separadas nos PDBs, j que os pools de servidores determinam quais servios
so executados em conjunto ou separadamente, voc pode configurar e manter afinidade ou
isolamento necessrios dos servios do PDB.
O gerenciamento de um banco de dados gerido por polticas requer menos etapas de
configurao e reconfigurao do que um gerenciado por administrador, com relao
criao, dimensionamento, implantao de patches e balanceamento de carga. Alm disso,
como qualquer servidor nos pools de servidores no cluster pode executar qualquer uma das
instncia de CDB e servios do PDB, voc no precisa criar e manter mapeamentos de
nome-de-instncia-para-n no CDB nem mapeamentos de nome-de-servio-para-n do PDB.

Aps a Criao do CDB
Verifique o status das instncias do CDB.

host01 $ srvctl status database -db cdb2
Instance cdb2_1 is running on node host01
Verifique os tablespaces UNDO.

host01 $ export ORACLE_SID=cdb2_1
host01 $ sqlplus / as sysdba
SQL> SELECT tablespace_name, con_id FROM cdb_tablespaces
Verifique os arquivos de redo log.
WHERE contents='UNDO';
TABLESPACE_NAME CON_ID
------------------------------ ----------
UNDOTBS1 1
UNDOTBS2 1
UNDOTBS3 1
13 - 18 Copyright 2014, Oracle e/ou suas empresas afiliadas. Todos os direitos reservados.
Depois que o CDB for criado, use SRVCTL para verificar se h tantas instncias do CDB em
execuo no pool de servidores quanto ns definidos no pool de servidores.
Os tablespaces UNDO so criados no continer raiz e h tantos tablespaces UNDO quanto
instncias do CDB.
Os grupos de arquivos redo log so exibidos com a view V$LOGFILE:
SQL> select group#, con_id from v$logfile;
GROUP# CON_ID
---------- ----------
2 0
1 0
5 0
6 0
3 0
4 0
Observe que h seis grupos de redo log pois h trs instncias do CDB. Observe tambm
que o ID do continer 0, em referncia do CDB, ao passo que o ID do continer 1 para os
arquivos de dados dos tablespaces UNDO referentes ao continer raiz especfico.

Conectando com os Servios de CDB/PDB
Os servios para a raiz e cada PDB so iniciados em cada

n do pool de servidores: PDB2 pode ser acessado em
qualquer instncia do CDB.
host01 $ lsnrctl status

Service "pdb2" has 1 instance(s).
Instance "cdb2_3", status READY, has 1 handler(s) for this
service
Para se conectar ao continer raiz em uma das trs

instncias do CDB:
SQL> connect system@"host01/cdb2" root
Para se conectar a um PDB em uma das trs instncias

do CDB:
SQL> connect system@"host01/pdb2" PDB
Use LSNRCTL para verificar se h tantas instncias de CDB em execuo nos ns do pool
de servidores quanto ns no pool de servidores, e tantos servios no PDB quanto PDBs
gerenciados pelo CDB.
$ lsnrctl status
...
Service "cdb2" has 1 instance(s). CDB service
service... One of the three CDB instances
Service "pdb2" has 1 instance(s). PDB service

service... Attached to one of the three CDB instances
Para se conectar ao continer raiz a fim de executar tarefas administrativas do CDB, use o
servio do CDB. Para se conectar a um PDB e executar tarefas administrativas do PDB, use
um dos servios do PDB. Use uma string EasyConnect ou um nome de servio de rede
declarado no arquivo tnsnames.ora, conforme mostrado nos exemplos do slide.

Abrindo um PDB em um CDB RAC
Inicie as instncias do CDB.

host01 host02 host03
host01 $ srvctl start database -db cdb2
Instncia instncia instncia
1 Abra um PDB na instncia atual: do cdb2_1 do cdb2_2 do cdb2_3
pdb2: pdb2: pdb2:
SQL> CONNECT sys@host01/cdb2 AS SYSDBA open mounted mounted
SQL> ALTER PLUGGABLE DATABASE pdb2 OPEN; 1 3 2
open open
2 Abra um PDB em algumas instncias: pdb1: pdb1: pdb1:
mounted mounted mounted
SQL> CONNECT sys@host03/cdb2 AS SYSDBA 3 3 3
SQL> ALTER PLUGGABLE DATABASE pdb2 OPEN open open open
INSTANCES = ('cdb2_3');
3 Abra um PDB em todas as instncias:

SQL> ALTER PLUGGABLE DATABASE ALL OPEN PDB1 PDB2
INSTANCES=ALL;
cdb2
Quando o CDB iniciado com SRVCTL, ocorrem as seguintes operaes:

As instncias do CDB so iniciadas em todos os ns do pool de servidores.
Os arquivos de controle do CDB so abertos para as instncias: os contineres raiz e
do PDB so montados.
O raiz aberto no modo READ WRITE em todas as instncias, o pr-implantado
aberto no modo READ ONLY para todas as instncias e os PDBs permanecem
montados (fechados).
Para abrir um ou diversos PDBs em algumas ou todas as instncias do CDB, conecte-se
raiz em qualquer uma das instncias do CDB e emita uma instruo ALTER PLUGGABLE
DATABASE OPEN, especificando as seguintes clusulas:
A clusula INSTANCES para modificar o estado do PDB nas instncias especificadas
do Oracle RAC. Se voc omitir esta clusula, ento o estado do PDB modificado
apenas na instncia atual, j que isto mostrado no primeiro exemplo do slide em que
o PDB pdb2 aberto na instncia cdb2_1 no host01, porm permanece montado nas
outras duas instncias do CDB. Use instance_name para especificar um ou nomes de
instncias em uma lista separada por vrgulas, contida entre parnteses, para modificar
o estado do PDB nessas instncias, j que isto mostrado no segundo exemplo do
slide em que o PDB pdb2 est aberto na instncia cdb2_3 em host03, porm
permanece montado na instncia cdb2_2.

Especifique ALL para modificar o estado do PDB em todas as instncias. Especifique ALL
EXCEPT para modificar o estado do PDB em todas as instncias, exceto nas instncias
especificadas. Se o PDB j estiver aberto em uma ou mais instncias, ento pode abri-lo
em instncias adicionais, mas ele deve ser aberto no mesmo modo como nas instncias
nas quais j est aberto. Essa operao abre os arquivos de dados dos PDBs abertos e
fornece disponibilidade para os usurios.
Use a coluna open_mode na view V$PDBS para verificar se todos os PDBs esto no modo de
abertura READ WRITE exceto apr-implantao que ainda deve estar no modo de abertura
READ ONLY.
Voc tambm pode abrir um PDB enquanto estiver conectado como SYSDBA dentro do PDB.
Nesse caso, no necessrio nomear o PDB a ser aberto.

Fechando um PDB em um CDB RAC
Faa o shutdown das instncias de um CDB RAC:

host01 $ srvctl stop database -db cdb2
Todos os PDBs fechados
CDB fechado / CDB desmontado / Instncia desativada
Feche um PDB:
Somente na instncia atual:
SQL> CONNECT sys@host01/cdb2 AS SYSDBA
SQL> ALTER PLUGGABLE DATABASE pdb2 CLOSE;
Em algumas ou em todas as instncias do CDB:

SQL> ALTER PLUGGABLE DATABASE pdb2 CLOSE INSTANCES=('cdb2_3');
SQL> ALTER PLUGGABLE DATABASE pdb2 CLOSE INSTANCES = ALL;
Na instncia atual e reabra-a em outra instncia:

SQL> ALTER PLUGGABLE DATABASE pdb2 CLOSE RELOCATE TO 'cdb2_3';
Quando todas as instncias de um CDB estiverem desativadas, os arquivos de dados dos

contineres raiz e pr-implantados e todos os PDBs so fechados. Em seguida, todos os
arquivos de controle so fechados e, na ltima etapa, ocorre o shutdown das instncias.
Um PDB pode ser fechado com a clusula INSTANCES j que isto mostrado nos exemplos
do slide. No primeiro exemplo com o comando ALTER PLUGGABLE DATABASE, o PDB
fechado na instncia atual do CDB. No segundo exemplo, o PDB fechado na instncia
cdb2_3 do CDB. No ltimo exemplo, o PDB fechado em todas as instncias do CDB.
Se voc precisar fechar todos os PDBs em todas as instncias do CDB porm manter a raiz
aberta para fins de manuteno, use o seguinte comando:
ALTER PLUGGABLE DATABASE ALL CLOSE INSTANCES = ALL;
Quando o PDB for fechado em todas as instncias do CDB, os arquivos de dados do PDB
so fechados.
Para exibir o modo de abertura do PDB, use a view V$PDBS com a coluna OPEN_MODE em
cada uma das instncias do CDB. Ele pode exibir MOUNTED em algumas instncias e READ
WRITE em outras instncias.
Para instruir o banco de dados para reabrir o PDB em uma instncia diferente do Oracle
RAC, use a clusula RELOCATE. Especifique RELOCATE para reabrir o PDB em uma
instncia diferente que for selecionada pelo Oracle Database ou RELOCATE TO
'instance_name' para reabrir o PDB na instncia especificada.
Tipos de Servios
H dois tipos de servios:

Servios internos: SYS$BACKGROUND, SYS$USERS
Servios de aplicaes:
Um servio especial do Oracle CDB: criado e disponvel por
padro em todas as instncias do CDB
Servios do PDB (aplicaes): Limite de 1024 servios por CDB
SQL> SELECT name, con_id FROM cdb_services;

NAME CON_ID
------------------- ----------
SYS$BACKGROUND 1
SYS$USERS 1
cdb1XDB 1
cdb1 1
pdb1 3
H dois tipos de servios:

Servios internos: O RDBMS suporta dois servios internos. O servio
SYS$BACKGROUND usado apenas pelos processos de background. SYS$USERS o
servio default para sesses de usurio no associadas a qualquer servio de
aplicao. Os dois servios internos suportam todos os recursos de gerenciamento de
carga de trabalho e nenhum deles pode ser interrompido ou desativado.
Servios de aplicaes: servios de CDB e PDB.
- Um servio especial do Oracle CDB criado por padro para o CDB Oracle RAC.
Esse servio default sempre est disponvel em todas as instncias em um
ambiente Oracle RAC, a menos que uma instncia esteja no modo restrito. Este
servio til para a conexo em outra instncia do n e no na instncia da
sesso qual se est conectado.
- designado um servio padro a cada PDB. O nome do servio o nome do
PDB. O servio o nico mtodo para se conectar a um PDB.

Gerenciando Servios
H duas categorias de servios a gerenciar:

Servios padro do PDB: um servio por PDB
Gerados na criao do PDB
No gerenciados pelo clusterware
Iniciados na abertura do PDB
Servios dinmicos do PDB:
teis para iniciar, interromper e posicionar PDBs em todas as
instncias do CDB
Gerenciados uniformemente em todos os ns no pool de servidores
Em execuo como um servio nico no mesmo pool de servidores
Designados manualmente a PDBs com SRVCTL
Iniciados manualmente com o SRVCTL
Restaurados automaticamente para seu estado original pelo
clusterware
PDB aberto automaticamente quando o servio for iniciado
13 - 24 Copyright 2014, Oracle e/ou suas empresas afiliadas. Todos os direitos reservados.
H duas categorias de servios:

Servios padro do PDB: designado um servio padro a cada novo PDB. O nome
do servio o nome do PDB. Este servio iniciado quando o PDB for aberto. Quando
o CDB for aberto e um trigger AFTER STARTUP ON DATABASE acionar um ALTER
PLUGGABLE DATABASE ALL OPEN, os servios sero iniciados.
Servios dinmicos do PDB: Designe um servio de banco de dados dinmico a cada
PDB para coordenar o incio, a interrupo e a colocao dos PDBs nas instncias de
um CDB RAC, usando o SRVCTL. Quando um servio dinmico do PDB for iniciado
pelo clusterware, o PDB automaticamente aberto. No h nenhuma necessidade de
criar um trigger AFTER STARTUP ON DATABASE para abrir o PDB. Como os PDBs
so gerenciados com o uso de servios dinmicos, so utilizadas prticas tpicas de
gerenciamento baseadas no Oracle RAC. Portanto, se o servio do PDB estiver no
estado ONLINE quando o Oracle Clusterware for desativado em um servidor que
estiver hospedando este servio, o servio ser restaurado para seu estado original
aps o reincio do Oracle Clusterware neste servidor. Dessa forma, a abertura dos
PDBs automatizada da mesma forma como qualquer outro banco de dados Oracle
RAC.

Harmonizando os Servios do PDB

com os Pools de Servidores
Diversos servios podem ser designados a um PDB.
Cada servio do PDB pode ser exposto em algumas ou
todas as instncias do RAC nos pools de servidores.
host01$ srvctl add service -db cdb2 -pdb pdb1 service pdb1srv
-policy automatic -serverpool cdb1pool
-cardinality uniform | singleton
host01$ srvctl start service -db cdb2 -service pdb1srv
cdb1pool cdb1pool
host01 host02 host03 host01 host02 host03
pdb1 pdb2 pdb2 pdb1 pdb3 pdb2 pdb1 pdb2 pdb3

pdb3 pdb3
cdb2_1 cdb2_2 cdb2_3 pdb1 cdb2_1 cdb2_2 cdb2_3
PDB1 PDB2 PDB3 PDB1 PDB2 PDB3

CDB2 CDB2
Os bancos de dados gerenciados por polticas facilitam o gerenciamento dos servios, pois
os servios so designados a um nico pool de servidores e so executados como nicos ou
uniformes em todos os servidores do pool. Voc no precisa mais criar ou manter listas
explcitas de instncias preferidas e disponveis do CDB com cada servio do PDB. Se um
servidor passar para um pool de servidores devido a uma realocao manual ou um evento
de alta disponibilidade, todos os servios uniformes do PDB nas instncias do CDB sero
iniciadas automaticamente. Se um servidor que estiver hospedando um ou mais servios
nicos ficar inativo, esses servios sero automaticamente iniciados em um ou mais
servidores remanescentes no pool de servidores.
Para designar um servio do PDB a um CDB, use SRVCTL conforme exibido no exemplo do
slide usando o parmetro CARDINALITY UNIFORM. O servio do PDB ser gerenciado
uniformemente em todos os ns do pool de servidores, conforme mostrado no grfico
esquerda no slide. Neste caso, cada servio do PDB fica disponvel em cada uma das
instncias do CDB.
Se voc quiser que o servio do PDB seja executado como um servio nico no mesmo pool
de servidores, use o parmetro CARDINALITY SINGLETON conforme mostrado no grfico
direita do slide. Neste caso, o servio pdb1 fica disponvel em uma das instncias do CDB.
Assim que o servio do PDB for criado, inicie o servio usando SRVCTL.
Se o servio pdb1 estiver no estado ONLINE quando o Oracle Clusterware for desativado em
um servidor que estiver hospedando este servio, o servio ser restaurado para seu estado
original aps o reincio do Oracle Clusterware neste servidor.
Adicionando um PDB em um CDB RAC
Crie um novo PDB a partir da pr-implantao ou clone-o a

partir de outro PDB:
Conecte-se raiz como um usurio comum com o
privilgio do sistema CREATE PLUGGABLE DATABASE:
SQL> CREATE PLUGGABLE DATABASE pdb1
2 ADMIN USER admin1 IDENTIFIED BY p1 ROLES=(CONNECT)
3 FILE_NAME_CONVERT = ('PDB$SEEDdir', 'PDB1dir');
SQL> CREATE PLUGGABLE DATABASE pdb3 FROM pdb1;
Abra o novo PDB nas instncias do CDB

O servio padro do PDB iniciado automaticamente nas
instncias do CDB.
Para criar um novo PDB a partir da pr-implantao (o PDB de modelo), conecte-se raiz
como usurio comum com o privilgio de sistema CREATE PLUGGABLE DATABASE e
execute a instruo CREATE PLUGGABLE DATABASE conforme mostrado no primeiro
exemplo do slide. A clusula FILE_NAME_CONVERT designa primeiro o diretrio de origem
dos arquivos de dados da pr-implantao e, em seguida, o diretrio de destino para os
novos arquivos de dados do PDB.
Para criar um novo PDB a partir de outro PDB, conecte-se raiz como usurio comum com o
privilgio de sistema CREATE PLUGGABLE DATABASE e execute a instruo CREATE
PLUGGABLE DATABASE conforme mostrado no segundo exemplo do slide. Antes de
prosseguir com a instruo CREATE PLUGGABLE DATABASE, o PDB de origem precisa
estar no modo READ ONLY em todas as instncias do CDB.
Quando a instruo concluda, abra o PDB nas instncias requeridas do CDB. Isto inicia o
servio padro criado para o novo PDB nas instncias do CDB.

Eliminando um PDB em um CDB RAC
CDB1 1. Remova os servios dinmicos

Arquivos de dados/ Arquivos Arquivos
do PDB.
Arquivos de de redo
temporrios controle log host01$ srvctl remove service
Arquivo1 -db cdb1
Arquivo2
Arquivo3
-service mypdb1serv
TEMP
Arquivo4 2. Feche o PDB em todas
raiz as instncias.
Arquivos de dados
Arquivo5
SQL> ALTER PLUGGABLE DATABASE
Arquivo6 2 pdb1 CLOSE INSTANCES=ALL;
Arquivo7
PDB$SEED
3. Descarte o PDB.
Arquivos de dados
Arquivo8
Arquivo9 Descartar SQL> DROP PLUGGABLE DATABASE
Arquivo10
PDB1 PDB1 2 pdb1 [INCLUDING DATAFILES];
Arquivos de dados
PDB4
Quando voc no precisar mais dos dados em um PDB, poder descartar esse PDB.
Quando voc descartar um PDB especificando INCLUDING DATAFILES, todos os seus
arquivos de dados listados nos arquivos de controle so excludos.
Com ou sem a clusula INCLUDING DATAFILES, a instruo DROP PLUGGABLE
DATABASE modifica os arquivos de controle para eliminar todas as referncias ao PDB
descartado.
KEEP DATAFILES o procedimento padro para manter os arquivos de dados, til em
cenrios em que um PDB desconectado plugado em outro CDB ou plugado novamente no
mesmo CDB.
Como os servios dinmicos do PDB no so removidos, remova-os antes de descartar o
PDB.

Questionrio
Quais das seguintes afirmaes so verdadeiras?

a. Apenas um tablespace SYSTEM por CDB
b. Apenas uma instncia por PDB
c. Um conjunto de arquivos de redo log por PDB
d. Apenas um tablespace UNDO por instncia do CDB
e. Um tablespace SYSAUX por PDB
Resposta: d, e

Sumrio

Descrever a arquitetura multilocatria em um ambiente
no RAC
Descrever a arquitetura multilocatria em um ambiente RAC
Criar um banco de dados continer multilocatrio RAC (CDB)
Criar um PDB (banco de dados plugvel) em um CDB RAC
Usar servios padro de CDB e PDB
Criar servios do PDB
Associar servios do PDB a pools de servidores
Eliminar um PDB de um CDB RAC


Criando um CDB RAC com DBCA
Fechando um PDB em um CDB RAC
Harmonizando os servios do PDB com as instncias
do CDB
Eliminando um PDB de um CDB RAC

ORACLE SG PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

ORACLE SG PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Jim Womack Iseno de Responsabilidade

1 Viso Geral do Grid Infrastructure

2 Viso Geral e Arquitetura dos Bancos de Dados do RAC

Clusters e Escalabilidade 2-13

3 Instalando e Configurando o Oracle RAC

4 Oracle RAC Administration

Alertas do Enterprise Manager e RAC 4-8

5 Gerenciando Operaes de Backup e Recuperao no Ambiente RAC

Efetuando a Verificao Cruzada em Vrios Ns de Clusters em um

6. Conceitos do Gerenciamento de Recursos Globais

7 Monitoramento e Ajuste do Banco de Dados RAC

8 Gerenciando a Alta Disponibilidade de Servios

Conexes de Servio Default 8-8

9 Alta Disponibilidade para Conexes e Aplicativos

Parse de Callouts do Servidor: Exemplo 9-17

Opes de Inicializao de Conexes 9-61

10 Fazendo o Upgrade e Aplicando Patches ao Oracle RAC

11 Oracle RAC One Node

Adicionando um Banco de Dados Oracle RAC One Node a um Cluster

12 Gerenciamento de Qualidade do Servio

13 Arquitetura Multilocatrio e RAC

Views de Dicionrio de Dados 13-9

Viso Geral do Grid Infrastructure

Aps concluir esta lio, voc ser capaz de:

Oracle Database 12c: Administrao do RAC 1 - 2

Um grupo de computadores independentes, mas

Um cluster compreende um grupo de computadores independentes, mas interconectados, cujos

um software que fornece vrias interfaces e servios a

Oracle Database 12c: Administrao do RAC 1 - 4

Oracle Flex Clusters

Escalabilidade dos Flex Clusters

A topologia hub e spoke dos Flex Clusters segmenta o cluster

Oracle Database 12c: Administrao do RAC 1 - 7

Arquitetura e Servios de Cluster do Clusterware

Arquitetura de cluster de disco compartilhado que suporta

O Oracle Clusterware fornece um conjunto completo de servios de cluster que suportam a

Objetivos Quanto ao Oracle Clusterware

O Oracle Clusterware tornou-se o clusterware necessrio para o Oracle RAC (Real

Oracle Database 12c: Administrao do RAC 1 - 9

Rede do Oracle Clusterware

Oracle Database 12c: Administrao do RAC 1 - 10

Para a rede pblica, todos os adaptadores de rede devem suportar TCP/IP.

Oracle Database 12c: Administrao do RAC 1 - 11

Inicializao do Oracle Clusterware

No OL6, a inicializao do Clusterware controlada pelo

start on runlevel [35]

Nos sistemas OL5, o comportamento de inicializao e falha do Clusterware administrada

Oracle Database 12c: Administrao do RAC 1 - 12

Arquitetura do GPnP: Viso Geral

DNS GNS Registrar o VIP do n e o VIP do SCAN

Oracle Database 12c: Administrao do RAC 1 - 14

Como o GPnP Funciona:

Quando um n iniciado em um ambiente GPnP:

Oracle Database 12c: Administrao do RAC 1 - 15

Grid Naming Service (GNS)

Oracle Database 12c: Administrao do RAC 1 - 16

Nome de Acesso de Cliente nico

O SCAN fornece um nome estvel e altamente disponvel

Oracle Database 12c: Administrao do RAC 1 - 17

Os listeners de SCAN podem ser executados em qualquer n do cluster. Os SCANs

Oracle Database 12c: Administrao do RAC 1 - 18