D73668BP11 sg2

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2013, Oracle and/or its affiliatesฺ
le
fe rab
tra ns
n -
no
a Administração
Workshopsde
r ) ha eฺ
do ฺExadata
m b u idDatabase Machine
ฺco dent G
k o
t ei Stu
o r te@ this
ฺ s up use Guia do Aluno – Volume 2
c
(te nse t o
o
k lice
o Tei
ic
Tecn
D73668BP11
Edição 1.1
Janeiro de 2013
D80375
Autor Copyright © 2012, Oracle e/ou suas empresas afiliadas. Todos os
direitos reservados.
Peter Fusek
Isenção de Responsabilidade
Revisores e Colaboradores Técnicos Este documento contém informações de propriedade da Oracle

Corporation e está protegido pela legislação de direitos autorais e
Akshay Shah Nilesh Choudhury outras leis de propriedade intelectual, podendo ser copiado e impresso
Ravindra Dani somente para uso individual em um curso de treinamento Oracle. O
Alex Tsukerman
documento não pode ser modificado nem alterado de forma alguma.

Amit Ganesh Raymond Dutcher Exceto em situações que constituam “uso justo” de acordo com a
Andrew Babb Richard Exley legislação de direitos autorais, não será permitido utilizar, compartilhar,
descarregar, carregar, copiar, imprimir, executar, reproduzir, publicar,
Aslam Edah-Tally Robert Carlin licenciar, divulgar, transmitir nem distribuir este documento – total ou
Barb Lundhild Robert Pastijn parcialmente – sem a expressa autorização da Oracle.
Bharat Baddepudi Roger Hansen
As informações contidas neste documento estão sujeitas a alterações
Bill Hodak Sabyasachi Banerjee sem aviso prévio. Se você encontrar algum problema no documento,
Boris Erlikhman Scott Gossett envie à Oracle Corporation ou à Oracle do Brasil Sistemas Ltda.
Sriram Palapudi Uma descrição de tal problema por escrito. Oracle University, 500
Branislav Valny Oracle Parkway, Redwood Shores, California 94065 USA. A Oracle le
Bruce Kyro
Caroline Johnston
Steven Lemme
Sue Lee este documento esteja isento de erros. fe rab
Corporation e a Oracle do Brasil Sistemas Ltda. não garantem que
Christian Craft Sugam Pandey

tr a ns
Dan Norris Sumeet Lahorani
Aviso de Direitos Restritos
n -
Dave Winter Sundararaman Sridharan no
Se esta documentação for entregue/distribuída ao Governo dos
a
David Hitchcock Tim Shelter s
Estados Unidos ou a qualquer outra parte que a licencie ou utilize
a
h eฺ
em nome daquele governo, a seguinte legenda será aplicável:
Douglas Utzig Umesh Panchaksharaiah r )
ฺ Guid
b
Ed Gilowski Uwe Hesse m
U.S. GOVERNMENT RIGHTS
Eric Siglin Varun Malhotra

k o ฺco dent
The U.S. Government’s rights to use, modify, reproduce, release,
perform, display, or disclose these training materials are restricted
Georg Schmidt Vern Wagman
t ei Stuby the terms of the applicable Oracle license agreement and/or the
te@ this
applicable U.S. Government contract.
Harald van Breederode Vijay Sridharan
James He Vikram Kapooro r
up use
Aviso de Marca Comercial
Jean-Francois Verrier ฺ s
Vimala Jacob
c e to
Jia Shi ( t eDesigner Oracle e Java são marcas comerciais registradas da Oracle
ko licens Gráfico
Corporation e/ou de suas empresas afiliadas. Outros nomes
Jim Hall i podem ser marcas comerciais de seus respectivos proprietários.
Jim Spiller T e Satish Bettegowda
ic o
Jim Viscusi
ecn
Joel Goodman
T Editores
Juan Loaiza Malavika Jinka
Kam Shergill Smita Kommini
Kevin Jernigan Aju Kumar
Kodi Umamageswaran
Krishnanjani Chitta Editor
Larry Justice
Michael Sebastian Almeida
Lawrence To
Louis Nagode
Mahesh Subramaniam
Maria Billings
Mark Fuller
Mark Scardina
Mark Van de Wiel
Marshall Presser
Martin Jensen
Michael Cebulla
Michael Nowak
Sumário
1 Introdução
Objetivos do Curso 1-2
Público e Pré-Requisitos 1-3
Conteúdo do Curso 1-4
Terminologia 1-5
Recursos Adicionais 1-6
le
Visão Geral do Exercício 1: Introdução ao Ambiente de Laboratório 1-7
fe rab
tra ns
2 Visão Geral do Exadata Database Machine
n -
Objetivos 2-2
a no
Introdução ao Database Machine 2-3 a s
h eฺ
Por Que o Database Machine? 2-4 r )
ฺ Guid
b
m
Introdução ao Exadata Storage Server 2-6
o ฺco dent
Visão Geral da Arquitetura do Exadata Storage Server 2-7
k
t ei Stu
Visão Geral dos Recursos do Exadata Storage Server 2-8
r te@ this
Detalhes de Hardware do Exadata Storage Server X2-2 (Sun Fire X4270 M2) 2-10
o
s up use
Especificações do Exadata Storage Server X2-2 2-11
ฺ
( t ec se to
Database Machine X2-2 Full Rack 2-12
i ko licen
Detalhes de Hardware do Servidor de Banco de Dados X2-2 (Sun Fire
e
o T X4170 M2) 2-13
ic
Tecn Comece Pequeno e Cresça 2-14
Database Machine X2-8 Full Rack 2-15
Detalhes de Hardware do Servidor de Banco de Dados X2-8 (Sun Fire
X4800 M2) 2-16
Capacidade do Database Machine 2-17
Desempenho do Database Machine 2-18
Exadata Storage Expansion Racks 2-19
Rede InfiniBand 2-20
Visão Geral do Suporte ao Database Machine 2-21
Vantagens do Database Machine para Data Warehouse 2-22
Vantagens do Database Machine para OLTP 2-24
Questionário 2-25
Resumo 2-27
iii
3 Arquitetura do Exadata Database Machine
Objetivos 3-2
Visão Geral da Arquitetura do Database Machine 3-3
Arquitetura de Rede do Database Machine 3-5
Arquitetura da Rede InfiniBand 3-7

Topologia Leaf Switch Full Rack X2-2 3-8
Topologia Spine e Leaf 3-9
Desempenho e Capacidade Escaláveis 3-10
Cenários Típicos de Dimensionamento 3-11
Dimensionamento para Oito Racks 3-13
Dimensionamento para Mais de Oito Racks 3-14
le
rab
Interconectando Quarter Racks 3-15
Conectividade Externa da Rede InfiniBand 3-17 fe
Visão Geral da Arquitetura de Software do Database Machine 3-18
tra ns
n -
Detalhes da Arquitetura de Software do Database Machine 3-21
Entidades e Relacionamentos de Armazenamento em Disco 3-22 a no
a s
h eฺ
r )
Entidades e Relacionamentos de Armazenamento Flash 3-24
ฺ Guid
b
Configuração de Grupos de Discos 3-25 m
Questionário 3-26
k o ฺco dent
Resumo 3-30 t ei Stu
o r te@ this
ฺ s up use
Visão Geral do Exercício 3: Introdução à Arquitetura de Células do Exadata 3-32
( t ec se to
4
e i ko Recursos
Principais
l i c e n do Exadata Database Machine
T
Objetivos 4-2
o Modelo Clássico de Processamento de SQL e Entrada/Saída de Banco
ic
Tecn de Dados 4-3
Modelo do Exadata Smart Scan 4-4
Recursos de Armazenamento Inteligente do Exadata 4-5
Exemplo de Dimensionamento do Exadata Smart Scan 4-8
Visão Geral da Compressão EHCC (Exadata Hybrid Columnar Compression) 4-11
Organização de Dados da Compressão EHCC (Exadata Hybrid Columnar
Compression) 4-12
Visão Geral do Exadata Smart Flash Cache 4-13
Armazenamento em Cache Inteligente do Exadata Smart Flash Cache 4-14
Usando o Exadata Smart Flash Cache 4-15
Visão Geral do Exadata Smart Flash Log 4-17
Visão Geral do Exadata Storage Index 4-18
Exemplo de Índice de Armazenamento com Partições 4-20
Sistema de Arquivos do Banco de Dados 4-21
Visão Geral do I/O Resource Management 4-22
iv
Multiplicação de Benefícios 4-23
Questionário 4-24
Resumo 4-25
Visão Geral do Exercício 4: Introdução aos Recursos do Exadata 4-28
5 Configuração Inicial do Exadata Database Machine

Objetivos 5-2
Visão Geral da Implementação do Database Machine 5-3
Principais Documentos 5-5
Preparação do Local do Database Machine 5-6
le
rab
Visão Geral das Planilhas de Configuração 5-7
Planilha de Configuração Geral 5-8 fe
Escolhendo o Nível de Proteção Certo 5-10
tr ans
n -
Planilha de Configuração Geral de Rede 5-12
a
Planilha de Configuração da Rede de Gerenciamento 5-13
no
a s
h eฺ
r )
Exemplo de Alocação de Endereço IP da Rede de Gerenciamento 5-14
ฺ Guid
b
Planilha de Configuração da Rede de Acesso do Cliente 5-15
m
k o ฺco dent
Exemplo de Alocação de Endereço IP da Rede de Acesso do Cliente 5-16
t ei Stu
Planilhas de Configuração de Rede Opcional 5-17
o r te@ this
Planilha de Configuração de PDUs (Power Distribution Units) 5-18
ฺ s up use
Planilha de Configuração do Auto Service Request 5-19
( t ec se to
Planilhas de Configuração do Oracle Enterprise Manager Grid Control 5-20
e i ko licen
Planilha de Configuração de Envio de Alertas de Célula 5-21
o T
Etapas Posteriores às Planilhas de Configuração 5-22
ic
ecn
Visão Geral da Planilha do Configurador 5-23
T Gerando os Arquivos de Configuração 5-25
Visão Geral da Instalação do Hardware do Database Machine 5-26
Visão Geral da Configuração do Oracle Exadata Database Machine 5-27
Selecionando o Sistema Operacional do Servidor de Banco de Dados 5-28
Implantando o Solaris nos Servidores de Banco de Dados 5-29
Recuperando no Linux o Espaço em Disco Não Utilizado do Sistema
Operacional 5-30
Recuperando no Solaris o Espaço em Disco Não Utilizado do Sistema
Operacional 5-32
Executando a Configuração Inicial da Rede 5-33
Carregando as Informações de Configuração e Instalando o Software 5-35
Executando o OneCommand no Database Machine 5-36
Configuração do Armazenamento do Exadata 5-37
Resultado após a Instalação e a Configuração 5-39
Atividades de Configuração Adicionais Suportadas 5-40
v
Atividades de Configuração não Suportadas 5-41
Questionário 5-43
Resumo 5-45
6 Configuração do Exadata Storage Server

Objetivos 6-2
Visão Geral da Administração do Exadata Storage Server 6-3
Contas de Usuário Administrativo do Exadata Storage Server 6-4
Visão Geral do DCLI 6-5
Exemplos do DCLI 6-6
Testando o Desempenho do Servidor de Armazenamento com o Comando
le
rab
CALIBRATE 6-7
Exemplo do Comando CALIBRATE 6-8 fe
Configurando o Software do Exadata Cell Server 6-9
tra ns
n -
Configurando Discos de Células 6-11 a no
Iniciando e Interrompendo o Software do Exadata Cell Server 6-10
a s
h eฺ
Configurando Discos de Grade 6-12
r )
ฺ Guid
b
Discos de Grade Intercalados 6-13 m
k o ฺco dent
Discos de Grade Intercalados e ASM IDP (Intelligent Data Placement) 6-14
t ei Stu
Criando Discos de Grade Baseados em Flash 6-15
o r te@ this
Criando o Smart Flash Log 6-16
ฺ s up use
Configurando Hosts para Acessar Células do Exadata 6-17
( t ec se to
Configurando Instâncias ASM e do Banco de Dados para Acessar Células
e i ko licen
do Exadata 6-18
o T
Configurando Grupos de Discos ASM com o Armazenamento do Exadata 6-19
ic
ecn
Reconfigurando o Armazenamento do Exadata 6-20
T Tarefas de Configuração Opcionais 6-22
Visão Geral da Segurança do Armazenamento do Exadata 6-23
Implementação da Segurança do Armazenamento do Exadata 6-24
Questionário 6-26
Resumo 6-29
Visão Geral do Exercício 6: Configurando o Exadata 6-31
7 I/O Resource Management

Objetivos 7-2
Visão Geral do I/O Resource Management 7-3
Conceitos do I/O Resource Management 7-5
Planos do I/O Resource Management 7-6
Exemplo de Planos do I/O Resource Management 7-7
Arquitetura do IORM 7-10
vi
Introdução ao IORM 7-11
Definindo o Objetivo do IORM 7-12
Ativando o Gerenciamento de Recursos Dentro do Mesmo Banco de Dados 7-13
Exemplo de Plano dentro do Mesmo Banco de Dados 7-14
Ativando o IORM para Vários Bancos de Dados 7-15

Exemplo de Plano dentro do Mesmo Banco de Dados 7-16
Definindo Limites de Utilização de Entrada/Saída do Banco de Dados 7-17
Planos entre Diferentes Bancos de Dados e Atribuições de Banco de Dados 7-18
Exemplo de Plano de Categoria 7-19
Usando Métricas de Entrada/Saída de Banco de Dados 7-20
IORM e Memória Flash do Exadata Storage Server 7-21
le
rab
Exemplo Completo 7-22
Questionário 7-25 fe
Resumo 7-29
tr a ns
n -
a no
a s
8 Recomendações para Otimização do Desempenho )dehBancos e ฺ Dados
de
Objetivos 8-2 b r
ฺ Gu i d
o m
Otimizando o Desempenho 8-3
k o ฺc dent
Uso de Memória Flash 8-4 t ei Stu
Uso de Compactação 8-6rte@ his
Uso de Índice 8-8 up
o se t
Tamanho date c
Unidade
u do ASM 8-9
ฺs de tAlocação
o
( da
o Mínimo n e
sExtensão
Tamanho
e i k l i c e 8-10
T
o Questionário 8-11
i c
n Resumo 8-13
Tec Recursos Adicionais 8-14
Visão Geral do Exercício 8: Otimizando o Desempenho do Banco de Dados
com o Exadata 8-15
9 Usando o Smart Scan

Objetivos 9-2
Visão Geral do Exadata Smart Scan 9-3
Requisitos do Smart Scan 9-4
Situações que Impedem o Uso do Smart Scan 9-6
Monitorando o Smart Scan nos Planos de Execução de SQL 9-7
Exemplo de Plano de Execução do Smart Scan 9-8
Exemplo de Situação que Impede o Uso do Smart Scan 9-10
Processamento de Joins do Smart Scan com Filtros Bloom 9-11
Exemplo de Filtragem de Join do Smart Scan 9-12
Outras Situações que Afetam o Smart Scan 9-13
vii
Visão Geral das Estatísticas do Exadata Storage Server 9-14
Visão Geral dos Eventos de Espera do Exadata Storage Server 9-15
Exemplo de Estatísticas do Smart Scan 9-16
Exemplo de Eventos de Espera do Smart Scan 9-17
Exemplo de Transação Concorrente 9-18

Exemplo Extremo de Transação Concorrente 9-19
Exemplo de Linhas Migradas 9-20
Exemplo de Entrada/Saída Enviada Diretamente para o Servidor de Banco
de Dados para Balancear o Uso de CPU 9-21
Exemplo de Filtragem de Coluna 9-22
Resumo 9-23
le
rab
Questionário 9-24
Visão Geral do Exercício 9: Usando o Smart Scan 9-26 fe
tr ans
n -
10 Opções e Recomendações de Consolidação
Objetivos 10-2 a no
a s
h eฺ
Visão Geral de Consolidação 10-3
r )
ฺ Guid
b
Diferentes Tipos de Consolidação 10-4 m
k o ฺco dent
Princípios Básicos da Consolidação de Bancos de Dados 10-5
t ei Stu
Abordagem de Consolidação Recomendada 10-6
o r te@ this
Configuração de Armazenamento Recomendada para a Consolidação 10-7
ฺ s up use
Configurações de Armazenamento Alternativas 10-8
( t ec se to
Vantagens e Limitações das Configurações de Armazenamento Particionado 10-9
e i ko licen
Opções de Configuração de Cluster 10-10
o T
Recomendações de Parâmetros do Sistema Operacional 10-11
ic
ecn
Recomendações de Memória do Banco de Dados 10-13
T Recomendações sobre o Gerenciamento da CPU 10-14
Outras Recomendações 10-16
Isolando Atribuições de Gerenciamento 10-18
Recomendações para a Consolidação de Esquemas 10-20
Considerações sobre Manutenção 10-21
Questionário 10-22
Resumo 10-24
11 Migrando Bancos de Dados para o Exadata Database Machine

Objetivos 11-2
Visão Geral das Melhores Práticas de Migração 11-3
Executando o Planejamento da Capacidade 11-4
Considerações sobre a Migração do Database Machine 11-5
Escolhendo o Caminho de Migração Correto 11-6
Abordagens de Migração Lógica 11-7
viii
Abordagens de Migração Física 11-9
Reduzindo o Período de Indisponibilidade Durante a Migração com Tablespaces
Transportáveis 11-11
Outras Abordagens 11-12
Melhores Práticas de Pós-Migração 11-13

Questionário 11-14
Resumo 11-16
Visão Geral do Exercício 11: Migrando para o Database Machine com o Uso de
Tablespaces Transportáveis 11-19
le
rab
12 Carregamento de Dados em Massa Usando o Oracle DBFS
Objetivos 12-2 fe
tr
Visão Geral do Carregamento de Dados em Massa Usando o Oracle DBFS 12-3a ns
n -
Preparando os Arquivos de Dados 12-4
Testando os Arquivos de Dados 12-5 a no
a s
h eฺ
Configurando a Área de Teste 12-6
r )
ฺ Guid
b
Configurando o Banco de Dados de Destino 12-10
m
k o ฺco dent
Carregando o Banco de Dados de Destino 12-11
Questionário 12-13 t ei Stu
Resumo 12-15
o r te@ this
ฺ s up use
( t ec se to
Visão Geral do Exercício 12: Carregamento de Dados em Massa Usando o Oracle
e i ko licen
DBFS 12-17
T
n i c13o Introdução ao Monitoramento da Plataforma Exadata Database Machine
Tec Objetivos 13-2
Tecnologias e Padrões de Monitoramento 13-3
SNMP (Simple Network Management Protocol) 13-4
IPMI (Intelligent Platform Management Interface) 13-5
ILOM (Integrated Lights Out Manager) 13-6
Métricas, Limites e Alertas do Exadata Storage Server 13-7
ADR (Automatic Diagnostic Repository) 13-8
Enterprise Manager Grid Control 13-9
Enterprise Manager Database Control 13-10
Questionário 13-11
Resumo 13-12
14 Configurando o Enterprise Manager Grid Control 11g para Monitorar o Exadata

Database Machine
Objetivos 14-2
ix
Visão Geral da Arquitetura do Enterprise Manager Grid Control 14-3
Arquitetura de Monitoramento do Grid Control para o Exadata Database
Machine 14-4
Configurando o Grid Control para Monitoraro Exadata Database Machine 14-5
Implantando o Oracle Management Agent 14-6

Configurando Alvos do ASM e do Oracle Database 14-7
Visão Geral da Implantação dos Plugins de Monitoramento do Sistema 14-8
Estratégia Recomendada de Implantação de Plugins 14-9
Implantando o Plugin de Monitoramento do Sistema para o Oracle Exadata
Storage Server 14-10
Implantando o Plugin de Monitoramento do Sistema para o Oracle Exadata
le
rab
ILOM 14-12
Implantando o Plugin de Monitoramento do Sistema para o Oracle Exadata fe
InfiniBand Switch 14-13
tra ns
n -
Switch 14-14 a no
Implantando o Plugin de Monitoramento do Sistema para o Exadata Cisco
a s
h eฺ
r )
Implantando o Plugin de Monitoramento do Sistema para o Avocent MergePoint
ฺ Guid
b
Unity (KVM) Switch 14-15 m
k o ฺco dent
Implantando o Plugin de Monitoramento do Sistema para a PDU (Power
t ei Stu
Distribution Unit) do Oracle Exadata 14-16
o r te@ this
Configurando UDMs (User-Defined Metrics) para Monitoramento de Rede
Adicional 14-17
ฺ s up use
( t ec se to
Configurando o Grid Control para o Exadata Database Machine: Abordagem
e i ko licen
Alternativa 14-19
o T
Configurando os Plugins para Alta Disponibilidade 14-20
ic
ecn
Configurando um Dashboard e um Serviço Agregado do Exadata Database
T Machine 14-21
Questionário 14-23
Resumo 14-25
15 Monitorando Exadata Storage Servers

Objetivos 15-2
Visão Geral da Lição 15-3
Arquitetura de Métricas e Alertas do Exadata 15-4
Monitorando o Exadata Storage Server com Métricas 15-6
Monitorando Métricas de Célula do Exadata: Exemplos 15-8
Monitorando o Exadata Storage Server com Alertas 15-9
Monitorando Alertas de Célula e Criando Limites: Exemplos 15-11
Isolando Falhas com a Quarentena do Exadata Storage Server 15-13
Monitorando o Exadata Storage Server com Solicitações Ativas 15-15
x
Visão Geral do Monitoramento do Exadata Storage Server com o Grid
Control 15-16
Monitorando Falhas de Hardware e o Estado de Sensores 15-18
Monitorando a Disponibilidade do Exadata Storage Server 15-19
Verificando Alertas Não Entregues 15-20

Verificando Erros de Entrada/Saída de Disco 15-21
Verificando Erros de Rede 15-22
Monitorando o Espaço Livre no Sistema de Arquivos 15-23
Comparando Métricas entre Vários Servidores de Armazenamento 15-24
Monitorando Métricas em um Servidor de Armazenamento 15-25
Ferramentas de Monitoramento de Terceiros 15-26
le
rab
Questionário 15-27
Resumo 15-29 fe
tr a ns
n -
no
Visão Geral do Exercício 15: Monitorando o Exadata Storage Server 15-31
a
a s
h Database
16 Monitorando Servidores de Banco de Dados do Exadata
r ) d e ฺ Machine
Objetivos 16-2 m b
ฺ Gu i
Visão Geral do Monitoramento de Servidores
o ntde Dados 16-3
ฺc de dBanco
k o e
Monitorando o Hardware 16-4 tei tu
@ i s S
o r te th16-5
Monitorando o Sistema Operacional
Monitorando o Oracle
s u e
upGrid Infrastructure
s 16-6
Monitorandote
ฺ
c eDatabase
o Oracle t o 16-7
( s
e i ko loicOracle
Monitorando e n Management Agent 16-8
T
Questionário 16-9
c nico Resumo 16-10
T e
17 Monitorando a Rede InfiniBand
Objetivos 17-2
Visão Geral do Monitoramento da Rede InfiniBand 17-3
Monitorando Manualmente os InfiniBand Switches 17-4
Monitorando os InfiniBand Switches com o Grid Control 17-5
Monitorando as Portas dos InfiniBand Switches 17-6
Monitorando as Portas InfiniBand nos Servidores do Database Machine 17-7
Monitorando o InfiniBand Fabric: Local do Mestre do Subnet Manager 17-8
Monitorando o InfiniBand Fabric: Topologia da Rede e Status dos Links 17-9
Questionário 17-10
Resumo 17-11
xi
18 Monitorando Outros Componentes do Exadata Database Machine
Objetivos 18-2
Monitorando o Cisco Catalyst Ethernet Switch 18-3
Monitorando as Sun PDUs (Power Distribution Units) 18-4
Monitorando o Avocent MergePoint Unity KVM Switch 18-5

Questionário 18-6
Resumo 18-7
19 Outras Ferramentas Úteis de Monitoramento

Objetivos 19-2
le
rab
Visão Geral de Exachk 19-3
Executando o Exachk 19-4 fe
Saída do Exachk 19-5
tra ns
n -
Visão Geral de DiagTools 19-6
Usando o ADRCI em Exadata Storage Servers 19-7 a no
a s
h eฺ
Visão Geral de Imageinfo 19-8
r )
ฺ Guid
b
Visão Geral de Imagehistory 19-9 m
Visão Geral de OSWatcher 19-10
k o ฺco dent
Questionário 19-11 t ei Stu
Resumo 19-13
o r te@ this
ฺ s up use
( t ec se to
20 Backup
e i koe Recuperação
l i c e n
T
o Objetivos 20-2
i c
n Visão Geral de Backup e Recuperação 20-3
Tec Usando o RMAN com o Database Machine 20-4
Recomendações Gerais para o RMAN 20-5
Estratégia de Backup Baseado em Disco 20-7
Recomendações sobre o Backup Baseado em Disco 20-8
Estratégia de Backup Baseado em Fita 20-10
Arquitetura de Backup Baseado em Fita 20-11
Recomendações sobre o Backup Baseado em Fita 20-12
Conectando o Servidor de Mídia Usando a Ethernet 20-14
Recomendações sobre o Backup Baseado em Fita 20-15
Estratégia de Backup Híbrida 20-16
Recomendações de Restauração e Recuperação 20-17
Backup e Recuperação do Software do Database Machine 20-18
Questionário 20-19
Resumo 20-21
xii
Visão Geral do Exercício 20: Usando Otimizações do RMAN para o Database
Machine 20-23
21 Tarefas de Manutenção do Exadata Database Machine

Objetivos 21-2
Visão Geral da Manutenção do Database Machine 21-3
Ligando e Desligando o Database Machine 21-4
Fazendo Shutdown de um Único Exadata Storage Server com Segurança 21-5
Substituindo um Disco Físico Danificado 21-6
Substituindo uma Placa Flash Danificada 21-8
Movendo Todos os Discos de uma Célula para Outra 21-9
le
rab
Usando o Procedimento de Resgate do Software de Célula do Exadata 21-10
Questionário 21-12 fe
Resumo 21-15
tra ns
n -
22 Aplicando Patches no Exadata Database Machine a no
a s
h eฺ
Objetivos 22-2
r )
ฺ Guid
b
Visão Geral de Patches e Atualizações 22-3
m
k o ฺco dent
Mantendo o Software do Exadata Storage Server 22-4
t ei Stu
Maintendo o Software do Servidor de Banco de Dados 22-6
o r te@ this
Aplicação de Patches Assistida Usando o OPlan 22-7
ฺ s up use
Mantendo Outros Softwares 22-8
( t ec se to
Processo Recomendado de Aplicação de Patches 22-9
e i ko licen
Recomendações sobre o Sistema de Teste 22-11
o T
Questionário 22-12
ic
ecn
Resumo 22-13
T Recursos Adicionais 22-14
23 Ecossistema de Suporte Automatizado do Exadata Database Machine

Objetivos 23-2
Visão Geral do Auto Service Request 23-3
O Processo ASR 23-4
Requisitos do ASR 23-5
Configurando o ASR Manager 23-6
Configurando o Exadata Database Machine para ASR 23-7
Ativando Ativos ASR 23-8
Aprovar e Verificar Ativos ASR 23-9
Visão Geral do Oracle Configuration Manager 23-10
Configurando o Oracle Configuration Manager 23-11
Questionário 23-12
Resumo 23-15
xiii
24 Gerenciamento de Qualidade do Serviço

Objetivos da Lição 24-2
Background do Gerenciamento de Qualidade de Serviço 24-3

Visão Geral do Gerenciamento de Qualidade de Serviço 24-4
Gerenciamento de Qualidade de Serviço e Exadata Database Machine 24-5
Foco do Gerenciamento de Qualidade de Serviço 24-6
Vantagens do Gerenciamento de Qualidade de Serviço 24-7
Visão Geral da Funcionalidade do Gerenciamento de Qualidade de Serviço 24-9
Conjuntos de Políticas de Gerenciamento de Qualidade de Serviço 24-11
le
rab
Pools de Servidores 24-12
Classes de Desempenho 24-14 fe
Classificação e Tagging 24-16
tra ns
n -
Políticas de Desempenho 24-17
Classificações das Classes de Desempenho 24-18 a no
a s
h eฺ
Objetivos de Desempenho 24-19
r )
ฺ Guid
b
Métricas de Atendimento de Desempenho 24-20
m
k o ฺco dent
Substituições de Diretivas de Pools de Servidores 24-21
Visão Geral de Métricas 24-22t ei Stu
o r te@ this
Arquitetura do Gerenciamento de Qualidade de Serviço 24-24
ฺ s up use
Recomendações do Gerenciamento de Qualidade de Serviço 24-25
( t ec se to
Implementando Recomendações 24-27
e i ko licen
Questionário 24-29
o T
Resumo 24-31
ic
ecn
T
A Gerenciando o Exadata Database Machine com o Enterprise Manager Cloud
Control 12c
Objetivos A-2
Visão Geral da Lição A-3
Configurando o Exadata Database Machine como um Alvo do Enterprise
Manager A-4
Visualizando o Exadata Database Machine no Enterprise Manager A-5
Monitoramento do Exadata Storage Server A-6
Administração do Exadata Storage Server A-7
Monitoramento do Desempenho do Exadata Storage Server A-8
Monitoramento da Integridade do Exadata Storage Server A-9
Monitoramento da Rede InfiniBand do Exadata Database Machine A-10
Administração da Rede InfiniBand do Exadata Database Machine A-11
Resumo A-12
xiv
Carregamento de Dados em Massa Usando

o Oracle DBFS
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
e t oe/ou suas empresas afiliadas. Todos os direitos reservados.
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos
Após concluir esta lição, você será capaz de:

• Descrever o processo de uso do Oracle DBFS para

carregar dados em massa no Database Machine
• Descrever o processo de configuração do recurso DBFS
(Database File System) para testar os arquivos de dados
de entrada
• Usar tabelas externas com base em arquivos de dados de rable
entrada armazenados em DBFS para executar cargasnde s fe
dados de alto desempenho n - tra
o n
a
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Workshop de Administração do Exadata Database Machine 12 - 2

Visão Geral do Carregamento de Dados em
Massa Usando o Oracle DBFS
Sistema de Origem Database Machine
Banco de Dados de Destino
CREATE ... AS SELECT ...

Banco de Dados de Teste
INSERT ... SELECT ...
DBFS le
fe rab
tr a ns
Transferência de
n -
no
Arquivos da Rede
(FTP, NFS, etc.) Arquivo de dados testado
no Database File System
s a
(DBFS)
) a
h eฺ
Tabela externa
b r
ฺ Guid
baseada em
Arquivo de Dados m
dados testados pelo
k o ฺco dent DBFS

Tabelas de destino
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic
Esta lição
o Tfornece informações sobre como carregar bancos de dados no Database Machine
i c
n dados de outros sistemas usando arquivos de dados como o armazenamento
com
T e c
intermediário. A lição se concentra na abordagem recomendada para o carregamento de
dados baseados em arquivos no Oracle usando o DBFS. Essa abordagem é ilustrada no
slide. O restante desta lição descreve esse processo em mais detalhes.
Observe que o DBFS também pode ser usado como um sistema de arquivos compartilhado
genérico no Database Machine. Você pode usar o procedimento de configuração do DBFS
descrito mais adiante nesta lição a fim de configurar o DBFS para fins que não sejam testar
arquivos de dados para carregamento de dados em massa.

Preparando os Arquivos de Dados
• Os arquivos de dados podem ter qualquer formato

suportado pelo recurso de tabela externa
• Para facilitar o acesso paralelo de alto desempenho:

– O Oracle Database divide automaticamente os arquivos em
grânulos de 10 MB
— Exceções: dados compactados, dados lidos de um pipe ou uma
fita
– Se não for possível criar os grânulos: le
Cada arquivo será tratado como um grânulo fe rab
ns
—
n - ra
O número de arquivos determinará o grau máximo de tparalelismo
—
a no
É necessário usar vários arquivos para ativar manualmente o
paralelismo s ha eฺ
– Regras gerais r )
ฺb Guid
Ao usar vários arquivos, tente m
co ent com tamanhos similares
mantê-los
—
o ฺ
— Se os tamanhos dos e
t ik tvariarem
arquivos ud muito, liste-os do maior
S
para o menor na
o r te@ definição
t h isde tabela externa
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic
T
A abordagem recomendada para o carregamento de dados em massa usando o Oracle
n i co
DBFS se baseia no recurso de tabela externa do Oracle Database. Os arquivos de dados
Te c
usados para carregamento em massa podem ter qualquer formato suportado por tabelas
externas. O processo para criação de arquivos de dados está fora do escopo desta lição e
depende, em grande parte, dos recursos disponíveis no sistema de origem.
Embora os arquivos de dados sejam criados, deve-se levar em conta as observações a
seguir, a fim de facilitar o acesso paralelo de alto desempenho aos arquivos de dados
durante o carregamento:
• Quando possível, ao acessar arquivos de dados grandes por meio de tabelas externas,
o Oracle divide automaticamente os arquivos em grânulos de 10 MB. É possível
processar esses grânulos em threads separados de processamento paralelo. O Oracle
Database não pode usar essa abordagem com arquivos compactados nem dados lidos
de um pipe ou um dispositivo de fita.
• Se os grânulos não puderem ser usados, cada arquivo poderá ser tratado como um
grânulo, e o número de arquivos determinará o grau máximo de paralelismo disponível.
Você pode dividir manualmente um arquivo grande em arquivos menores separados e
usá-los para permitir o paralelismo.
• Se você estiver usando vários arquivos de dados de entrada juntamente com uma única
tabela externa, tente manter os dados com tamanhos similares. Se os tamanhos dos
arquivos variarem muito, liste-os do maior para o menor na definição de tabela externa

Testando os Arquivos de Dados
• Os arquivos de dados devem ser sempre testados no DBFS

– Não use unidades internas do servidor de banco de dados

• O DBFS permite que o banco de dados seja usado como
um sistema de arquivos
– Armazenamento compartilhado para testar ou armazenar
arquivos de dados, scripts, relatórios e outros arquivos de
aplicações
r a ble
– Os arquivos são armazenados como LOBs SecureFiles dentro
n s fe
de tabelas do banco de dados armazenadas no Exadata
n - tra
– Os arquivos são expostos aos servidores de a no de dados
banco
usando uma interface de sistema de arquivos
) h as compatível
ฺ com
POSIX r
ฺb Guid e
m
– Os arquivos são armazenados
k o ฺcocomoe n t SecureFiles dentro
LOBs
de tabelas do banco de i
tedados tud
Sarmazenadas no Exadata
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic os arquivos de dados no Database Machine usando o DBFS
Te testar
É recomendável
o
ic File System). O DBFS é um recurso do Oracle Database que permite usar o
ecn
(Database
T banco de dados como um sistema de arquivos de alto desempenho compatível com POSIX.
Não é recomendável usar o espaço disponível nas unidades de disco internas do servidor de
banco de dados para testar arquivos de dados.
No DBFS, os arquivos são armazenados como LOBs SecureFiles. Um conjunto de
procedures PL/SQL implementa as primitivas de acesso do sistema de arquivos, como abrir,
fechar, criar, etc. O utilitário dbfs_client permite a montagem de um sistema de arquivos
DBFS como um ponto de montagem nos servidores de banco de dados do Database
Machine. Ele também permite o mapeamento de operações de sistema de arquivos para
operações de banco de dados.
Observação: o procedimento descrito nesta lição se aplica à configuração do DBFS nos
servidores de banco de dados Linux. Não há suporte para o ACFS (ASM Cluster File System)
em conjunto com o Exadata.

Configurando a Área de Teste
O DBFS deve ser configurado em um banco de dados de teste
separado
• Use o DBCA para criar o banco de dados de teste

– Consulte as recomendações em My Oracle Support note
1191144.1
• Crie um tablespace bigfile para armazenamento em DBFS
SQL> CREATE BIGFILE TABLESPACE DBFS DATAFILE '+DBFS_DG'
SIZE 32G AUTOEXTEND ON NEXT 8G MAXSIZE 300G
r a ble
NOLOGGING ONLINE PERMANENT EXTENT MANAGEMENT LOCALfe
AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO; ran
s
o n -t
• Crie uma conta de usuário DBFS n
a
SQL> create user dbfs identified by dbfs
) h as ฺ
quota unlimited on DBFS;
m ฺbr Guide
SQL> grant create session, create
k o ฺco dtable, e nt create
procedure, dbfs_roleeito dbfs; tu
@ t S
r te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t oe/ou suas empresas afiliadas. Todos os direitos reservados.
t e
i k o ( ense
Emborao
e
oTDBFS seja lictotalmente funcional se for colocado no mesmo local que o banco de
e c nic de destino, é recomendável configurá-lo em um banco de dados de teste separado.
dados
T Use o DBCA (Database Configuration Assistant) para criar um banco de dados. Se você
desejar acessar o DBFS em vários servidores de banco de dados Database Machine, crie o
banco de dados de teste como RAC nos servidores desejados. Embora as definições default
sejam, em sua maior parte, adequadas para configurar o banco de dados de teste, as
seguintes recomendações são fornecidas em My Oracle Support note 1191144.1:
• Use o modelo General Purpose or Transaction Processing
• Use o recurso Oracle Managed Files e o grupo de discos DBFS_DG disk para
armazenar o banco de dados de teste
• Desmarque Specify Flash Recovery Area
• Defina Memory Size (SGA and PGA) como 8192 MB
• Desmarque Use Automatic Memory Management
• Use AL32UTF8 como o conjunto de caracteres do banco de dados
• Defina o parâmetro de inicialização PARALLEL_MAX_SERVERS como 2
Após a criação do banco de dados de teste, crie um tablespace bigfile para usar como o
armazenamento DBFS. O slide mostra um exemplo de comando CREATE TABLESPACE
que contém as opções de tablespace recomendadas. Crie também uma conta de usuário
DBFS conforme sugerido no slide.
• Configuração adicional do sistema operacional do servidor

de banco de dados:
– Adicione o proprietário ou o usuário do software Oracle que
montará o sistema de arquivos DBFS ao grupo fuse
# usermod –a –G fuse oracle
– Como root, crie /etc/fuse.conf contendo a entrada:
user_allow_other le
# echo "user_allow_other" > /etc/fuse.conf fe rab
# chmod 644 /etc/fuse.conf nstra
n -
– Crie um ponto de montagem para o DBFS com propriedade
a no e
permissões de grupo definidas para o proprietário
) h as ฺ ou o usuário
do software Oracle que montará o sistema ฺbr Gudeidarquivos e DBFS
m
# mkdir /data
k o ฺco dent
# chown oracle:dba /data
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic também é necessário executar as tarefas de configuração do
Te o DBFS,
Para configurar
o
e c nic operacional listadas no slide. Elas devem ser executadas em cada servidor de
sistema
T banco de dados onde o DBFS será montado. Os exemplos mostram uma configuração
típica usando o proprietário do software Oracle como o proprietário do ponto de montagem
DBFS. Você poderá criar e utilizar um usuário alternativo do sistema operacional se quiser
desassociar o acesso ao DBFS do proprietário do software Oracle e de seus privilégios de
administração de banco de dados. Também poderá usar o utilitário dcli para replicar as
etapas de configuração em vários servidores de banco de dados.

• Criando o armazenamento DBFS

$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus dbfs/dbfs
SQL> @dbfs_create_filesystem_advanced.sql DBFS mydbfs
nocompress nodeduplicate noencrypt non-partition
• Montando o DBFS
$ nohup $ORACLE_HOME/bin/dbfs_client dbfs@<StagingDB>
le
-o allow_other,direct_io /data < passwd.txt &
fe rab
tra
– Consulte My Oracle Support note 1054431.1 para obter ns
n -
detalhes sobre a configuração da montagem automática
no a
• Usando o DBFS a
h eฺ s
b
ฺ der ) id
– Acesse o DBFS por meio do diretório m G umontagem
– Copie os arquivos para ioko ฺco dusando
DBFS e nt métodos como FTP
e NFS @ te Stu
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de dados de teste e o término da configuração necessária do
Te do banco
Após aocriação
e c nic operacional, você pode criar o armazenamento DBFS. Use o script localizado em
sistema
T $ORACLE_HOME/rdbms/admin/dbfs_create_filesystem_advanced.sql. Ele deve
ser executado pelo usuário do banco de dados DBFS (criado anteriormente, no processo de
configuração). O script aceita vários parâmetros. No exemplo do slide, DBFS representa o
nome do tablespace criado para hospedar o armazenamento DBFS, e mydbfs representa
o nome do armazenamento DBFS. Esse nome é usado depois que o DBFS é montado para
nomear o diretório que aparece abaixo do diretório de montagem do DBFS.
Para montar o DBFS, é possível usar dbfs_client, conforme mostrado no exemplo do
slide. Observe que o exemplo faz referência a /data como o diretório de montagem do
DBFS. Observe também que a senha de usuário do DBFS está contida em um arquivo
denominado passwd.txt. O arquivo de senha somente é necessário na montagem do
DBFS, não enquanto o DBFS está sendo usado. Como opção, você pode configurar um
Oracle Wallet para que o cliente DBFS possa montar um armazenamento DBFS sem uma
senha.
My Oracle Support bulletin 1054431.1 contém um procedimento que pode ser usado para
montar automaticamente o DBFS com o Oracle Clusterware.

Após a montagem do DBFS, você pode acessá-lo por meio do diretório de montagem
(/data no exemplo do slide). No diretório de montagem, você encontrará um subdiretório
nomeado de acordo com o armazenamento DBFS; o conteúdo desse subdiretório
(/data/mydbfs no exemplo) é o mesmo que o do armazenamento DBFS.
Observe que é possível ter várias cópias de dbfs_client acessando o mesmo sistema
de arquivos compartilhado. As semânticas de armazenamento e de armazenamento no
cache são similares a NFS. Como o NFS, o modo default armazena no cache as gravações
no cliente e as descarrega após um tempo limite ou quando o arquivo que está sendo
modificado é fechado. Também como o NFS, as gravações feitas em um arquivo são visíveis
apenas a clientes que abrem o arquivo depois que o gravador o fecha. Em geral, esse
comportamento é denominado consistência do cache entre fechamento e abertura.
Para obter mais informações sobre o DBFS no Database Machine, consulte My Oracle
Support bulletin 1054431.1. Consulte também os capítulos sobre DBFS do Oracle Database
SecureFiles and Large Objects Developer's Guide 11g Release 2 (11.2).
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Configurando o Banco de Dados de Destino
• Pré-requisitos para o acesso a arquivos de dados usando
tabelas externas
– Criar um objeto de diretório Oracle que referencie o diretório da

área de teste do DBFS
– Conceder as permissões necessárias ao objeto de diretório
Oracle
– Criar as tabelas externas necessárias
• Garantir o gerenciamento eficiente do espaço
le
– Usar tablespaces bigfile
fe rab
ans
– Usar extensões iniciais de 8 MB para segmentos grandes
-t 8 MB r
—
n o n
Definir o parâmetro de armazenamento INITIAL como
Definir o parâmetro de inicialização a
has TRUE
—
CELL_PARTITION_LARGE_EXTENTS como ฺ ou ALWAYS

• Usar cotas ilimitadas para ignorar u r)
id
ฺob gerenciamento e
de cotas
o m t G
• Usar a cláusula paralela para
i k oฺcdefinir
d e no grau default de
paralelismo para as @ te de
tabelas tu
r s S destino
te thi
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Te
Após aoconfiguração
c área de teste baseada em DBFS, ela poderá ser preenchida com os
lida
e c nic de dados necessários. Para acessar os arquivos de dados usando tabelas externas,
arquivos
T é necessário:
• Criar um objeto de diretório Oracle que faça referência ao diretório da área de teste do
DBFS.
• Conceder as permissões necessárias ao objeto de diretório Oracle para que os
arquivos de dados possam ser referenciados pelos usuários do banco de dados de
destino necessário.
• Criar as tabelas externas necessárias, referenciando os arquivos de dados
armazenados no DBFS.
Você também deve preparar o banco de dados de destino de forma mais generalizada, a fim
de otimizar o processo de carga. É necessário garantir o gerenciamento eficiente do espaço
seguindo as recomendações gerais contidas no slide, para uso em conjunto com o Exadata.
Além disso, você pode otimizar o desempenho das suas cargas se ignorar o gerenciamento
de cotas de tablespace e definir um grau default padrão de paralelismo para as suas tabelas
de destino.

Carregando o Banco de Dados de Destino
• A abordagem recomendada usa tabelas externas
– Carregamento de caminho direto paralelo para alto
desempenho
– Processamento em execução usando SQL
— Transformações usando funções SQL
— Classificar dados durante o carregamento para otimizar os índices
de armazenamento Exadata
– Não há necessidade de testar novamente os dados
– Outros recursos avançados le
— Por exemplo: processamento de arquivos de entrada
fe rab
• O SQL*Loader também pode ser usado
tra ns
– O carregamento de caminho direto paralelo também - ser
onpode
obtido a n
a s
h comparação
– Menos flexibilidade de processamentor)em
d e ฺ com
tabelas externas ฺ b
m tG u i
ฺ c o
i k o udenpodem ser reutilizados
– Os scripts existentes do SQL*Loader
com facilidade te St
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic para carregamento dos arquivos de dados usa tabelas externas.
O método
o Trecomendado
ic
ecn
O carregamento de dados usando tabelas externas fornece os benefícios-chave a seguir:
T • Você pode usar o carregamento de caminho direto e o processamento paralelo para
obter um alto desempenho.
• É possível usar a flexibilidade e os recursos do SQL para processar os dados de forma
eficiente durante o carregamento. Por exemplo, você pode usar as funções SQL padrão
ou definidas pelo usuário para transformar os dados durante o carregamento e
classificar os dados carregados para otimizar os índices de armazenamento que são
mantidos automaticamente pelo Exadata Storage Server.
• Como você pode processar os dados durante o carregamento, é improvável que
necessite testá-los novamente no banco de dados de destino.
• As tabelas externas fornecem alguns recursos avançados úteis. O exemplo principal é a
capacidade de pré-processar um arquivo de dados usando um programa definido pelo
usuário, o que oferece flexibilidade adicional e recursos para processar os dados
usando rotinas fora do banco de dados.
O SQL*Loader também pode ser usado para carregar arquivos de dados. Com ele, é
possível obter um desempenho comparável, mas não o mesmo nível de flexibilidade de
processamento quando comparado a tabelas externas. O SQL*Loader continua sendo uma
boa opção quando os clientes já têm scripts baseados no SQL*Loader, que eles desejem
reutilizar em um ambiente do Database Machine.
Carregando o Banco de Dados de Destino
• Carregamento paralelo usando tabelas externas

– Uma instrução CREATE TABLE ... A instrução AS

SELECT usa automaticamente o grau definido de
paralelismo
– Uma instrução INSERT ... SELECT requer a ativação do
DML paralelo
SQL> alter session enable parallel dml;
le
• Carregamento de caminho direito usando tabelas externas fe rab
– Uma instrução CREATE TABLE ... A instrução a n s
n t r AS
-caminho
SELECT usa automaticamente o carregamento o de
direto a n
– Uma instrução INSERT ... SELECT ) h as ฺque uma dica
requer
r uide
ฺbcaminho
APPEND ative o carregamento
c m
o nt G direto
de
k ฺ
o */udinto e my_table
SQL> insert /*+ APPEND
t e i t
select * from
r t e @ his Smy_external_table;
u p o se t
c ฺs Oracletoe/ouusuas empresas afiliadas. Todos os direitos reservados.
Copyright © 2012,
e
t
o ( ense
i k ic em massa usando tabelas externas é obtido por meio de uma
Te de ldados
O carregamento
o
ic CREATE TABLE ... AS SELECT ou uma instrução INSERT ... SELECT.
ecn
instrução
T Para utilizar o processamento paralelo, é recomendável que você defina o grau default de
paralelismo para as tabelas externas usadas na carga e na tabela de destino que estiver
sendo criada ou recebendo dados. Como opção, você pode definir o paralelismo dentro da
instrução usando a dica PARALLEL.
Após a configuração do paralelismo, uma instrução CREATE TABLE ... AS SELECT
usará automaticamente o grau definido de paralelismo. Uma instrução INSERT ...
SELECT requer que o DML paralelo seja ativado para que possa ser executada em paralelo.
Para utilizar o carregamento de caminho direto a partir de tabelas externas, você deve usar
uma dica APPEND para uma instrução INSERT ... SELECT . Instruções CREATE TABLE
... AS SELECT usam automaticamente o carregamento de caminho direto.
Lembre-se de que a abordagem de carregamento de dados em massa destacada nesta lição
pode ser usada em conjunto com outras técnicas, como PEL (Partition Exchange Loading).

Questionário
Para facilitar o carregamento paralelo a partir de arquivos

simples típicos, as definições de tabelas externas devem fazer

referência a vários arquivos de dados menores, em vez de um
arquivo que contenha todos os dados:
a. Verdadeiro
b. Falso
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
c
nigeral,
T e c
Em o Oracle divide automaticamente os arquivos simples típicos em grânulos de
10 MB para facilitar o processamento paralelo. O Oracle Database não pode usar essa
abordagem com arquivos compactados nem dados lidos de um pipe ou um dispositivo de fita.

Questionário
Embora o DBFS seja totalmente funcional se for colocado

no mesmo local que o banco de dados de destino, é

recomendável configurá-lo em um banco de dados de
teste separado:
a. Verdadeiro
b. Falso
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tae
e c nic
T

Resumo
Nesta lição, você aprendeu a:

• Descrever o processo de uso do Oracle DBFS para

carregar dados em massa no Database Machine
• Descrever o processo de configuração do recurso DBFS
(Database File System) para testar os arquivos de dados
de entrada
• Usar tabelas externas com base em arquivos de dados de rable
entrada armazenados em DBFS para executar cargasnde s fe
dados de alto desempenho n - tra
o n
a
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
• Demonstrações da Lição
– Carregamento de Dados em Massa com o Database

Machine
• My Oracle Support Notes
– Configuring a Database for DBFS on Oracle Database
Machine
– Configuring DBFS on Oracle Database Machine le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral do Exercício 12: Carregamento de
Dados em Massa Usando o Oracle DBFS
Neste exercício, você executará uma carga de dados em
massa no Database Machine. Você configurará um DBFS

(Database File System) e o utilizará para testar um arquivo
formatado CSV. Em seguida, usará o recurso de tabela
externa do Oracle Database para referenciar o arquivo CSV.
Finalmente, você usará uma instrução CREATE TABLE AS
SELECT para copiar os dados do arquivo CSV em uma tabela le
do seu banco de dados. r a b
fe ns
t r a
no n-
a
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Tecn
ic
oT e i
( t
ฺ s
ko licen
o r
ec se to
t
up use
k o
te@ this
ei Stu
m b r )
ฺco dent
a s
ฺ Guid
a
h eฺ
no n - tr
a
ns fe rab
le
Introdução ao Monitoramento da Plataforma

Exadata Database Machine
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos
Após concluir esta lição, você será capaz de descrever as

principais tecnologias de infraestrutura de monitoramento

associadas ao Exadata Database Machine.
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Tecnologias e Padrões de Monitoramento
SNMP
Exadata
Storage
Server
Rede
InfiniBand
Métricas
ILOM le
Automatic fe rab
Diagnostic
tra ns
Repository n -
no a
Enterprise
a s
Manager
h Control Grid
r ) e ฺ
Alertas
m ฺb Guid
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de monitoramento incorporadas nos componentes do Exadata
Tetecnologias
Há diversas
o
e c nic Machine. Algumas se baseiam em padrões amplamente adotados, enquanto
Database
T outras são específicas do Database Machine. Esta lição apresenta as principais tecnologias
e padrões de monitoramento usados em conjunto com o Database Machine. A maioria dos
alunos deve estar familiarizada com a maior parte das informações apresentadas nesta lição,
as quais visam fornecer uma base consistente para as lições subsequentes.

SNMP (Simple Network Management Protocol)
• O que é?
– Um protocolo padrão para o gerenciamento de dispositivos

em uma rede
• O que ele faz?
– Usado principalmente para propagar informações sobre um
dispositivo para uma console de gerenciamento em algum
local da rede
— Reporta alertas sobre problemas de hardware ou software r a ble
– Pode ser usado para definir parâmetros de configuração n s
de
fe
dispositivos n - tra
• Onde é encontrado? a no
h s
aservidores
– Em todo o Database Machine, incluindo r ) d e ฺ de banco
de dados, servidores de armazenamento, m b
ฺ GuInfiniBand i
o
ฺc (Keyboard
n t
switches, Ethernet switch, i k o KVM
u d e Video and
Mouse) switch e PDUs e
t (Power t
S Distribution Units)
e @
rt e th i s
p o s empresas afiliadas. Todos os direitos reservados.
c ฺ suOracletoe/ouusuas
Copyright © 2012,
o (te nse
O SNMP T eik Network
(Simple l ice Management Protocol) é um protocolo padrão da Internet para o
n i co
gerenciamento de dispositivos em redes IP. Uma ampla variedade de dispositivos suportam o
Tec SNMP, como servidores, switches de rede, roteadores, impressoras e estações de trabalho.
O SNMP é usado principalmente em sistemas de gerenciamento de rede para monitorar
dispositivos conectados à rede no que diz respeito a condições que merecem atenção
administrativa.
Normalmente, ele é usado a fim de propagar informações sobre um dispositivo para uma
console de monitoramento ou gerenciamento localizada em algum local da rede. Para isso,
os dispositivos gerenciados executam um agente SNMP. Os agentes SNMP expõem
informações de gerenciamento sobre os sistemas gerenciados como variáveis. O protocolo
também permite tarefas de gerenciamento ativas, como a modificação e a aplicação de uma
nova configuração por meio da modificação remota dessas variáveis. Os agentes SNMP
podem ser processos separados ou incorporados em outros módulos de software ou
hardware.
O SNMP define diversas unidades de dados de protocolo (mensagens) que podem ser
trocadas entre agentes e gerenciadores. Uma das mensagens mais importantes é uma
notificação assíncrona do agente para o gerenciador conhecida como trap. As traps do
SNMP são geralmente usadas pelos dispositivos para reportar condições de alerta.
O SNMP é amplamente usado no Exadata Database Machine permitindo que os seus
diversos componentes reportem informações de monitoramento e alertas para os sistemas
de gerenciamento de rede como o Enterprise Manager Grid Control.
IPMI (Intelligent Platform Management Interface)
• O que é?
– Uma interface aberta padrão do setor para o gerenciamento

de servidores
• O que ela faz?
– Usada principalmente para executar a configuração e o
gerenciamento de servidores independentemente do
sistema operacional de servidor le
• Onde é encontrada? fe rab
tr a ns
– Servidores de banco de dados do Exadata Database
o n -
Machine e Exadata Storage Servers an
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Management Interface) é uma interface aberta padrão do setor
Te Platform
A IPMIo(Intelligent
e c nico gerenciamento de sistemas de servidor em diversos tipos de redes.

para
T Embora o SNMP e a IPMI pareçam executar essencialmente a mesma função, há duas
diferenças principais:
• A IPMI é mais centrada no gerenciamento de servidores. A funcionalidade IPMI inclui
geração de relatórios de inventário FRU (Field-Replaceable Unit), log de eventos do
sistema e recuperação do sistema (inclusive reinicializações, ativação e desativação
do sistema).
• A IPMI está associada a uma arquitetura que permite aos administradores gerenciar
remotamente um sistema na ausência de um sistema operacional ou outro software
de gerenciamento de sistema. O sistema monitorado poderá estar desligado, mas a
BMC (Baseboard Management Controller) deverá estar conectada a uma fonte de
alimentação e à mídia de monitoramento, geralmente uma conexão de rede local.
O BMC é uma minicontroladora especializada incorporada no servidor.
A IPMI prescreve somente a estrutura e o formato das interfaces como um padrão, mas as
implementações detalhadas podem variar.
No Database Machine, o suporte à IPMI é incorporado no ILOM (Integrated Lights Out
Manager), em cada servidor de banco de dados e Exadata Storage Server.

ILOM (Integrated Lights Out Manager)
• O que é?
– Hardware e software de processador de serviço integrado

• O que ele faz?
– Permite o monitoramento e o gerenciamentos de servidores
fora de banda para:
— Controlar remotamente o estado de alimentação de um servidor
— Visualizar o status de sensores e indicadores no sistema
r a ble
— Fornecer uma console de servidor remota sfe n
– Gera alertas para erros e falhas de hardware à medida
n - tra que
o
eles ocorrem an
• Onde é encontrado? ) h as ฺ
r uide
ฺbExadata
– Servidores de banco de dados
c m
o nt G Database
do
Machine e Exadata Storage k ฺ
o Servers de
t e i t u
r t e @ his S
u p o se t
Copyright © 2012,
e
t
o ( ense
i k ic Out Manager) fornece software e hardware de processador
O ILOMo Te
(Integrated lLights
ic avançados (BMC, Baseboard Management Controller) que podem ser usados
ecn
de serviço
T para gerenciar e monitorar os servidores do Database Machine. O hardware e o software
dedicados do ILOM são pré-instalados nos servidores de banco de dados e nos Exadata
Storage Servers do Database Machine. O ILOM permite gerenciar e monitorar o servidor
de forma ativa, independentemente do estado do sistema operacional (fora de banda).
Com o ILOM, é possível:
• Tomar conhecimento dos erros e das falhas de hardware à medida que eles ocorrem
• Controlar remotamente o estado da alimentação do servidor
• Visualizar e usar as consoles gráficas e não gráficas do host
• Visualizar o status atual dos sensores e indicadores no sistema
• Determinar a configuração de hardware do sistema
• Receber alertas sobre eventos importantes do sistema por meio de métodos de
notificação, como traps do SNMP e alertas por e-mail.
O ILOM é inicializado automaticamente assim que o servidor recebe alimentação. Ele fornece
uma interface Web baseada em navegador, com recursos completos, e apresenta uma CLI
(command-line interface) equivalente. Também há suporte para uma interface SNMP padrão
do setor e para a IPMI (o ILOM é compatível com a IPMI v1.5 e v2.0).

Métricas, Limites e Alertas do
Exadata Storage Server
• Quais são eles?
– As métricas, os limites e os alertas servem de base para o

monitoramento do Exadata Storage Server
• O que eles fazem?
– As métricas fornecem uma medida relacionada a algum
aspecto do status ou do desempenho do servidor de
armazenamento
r a ble
n s fe
– Os limites são níveis de métrica, os quais, se ultrapassados,
geram automaticamente uma notificação de alerta -tra
n
– Os alertas são notificações de eventos do sistemaongeradas
s a
automaticamente h a ) ฺ
b r i d e
• Onde eles são encontrados? mฺ G u
o t
– Exadata Storage Serverikoฺc den
@ te Stu
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic contém um sistema de métricas, limites e alertas que servem de
TeStorage lServer
O Exadata
o
icpara o monitoramento dos servidores de armazenamento.
ecn
base
T As métricas fornecem uma medida relacionada a algum aspecto do status ou do
desempenho do servidor de armazenamento. O Exadata Storage Server contém mais de
150 métricas, muitas das quais estão associadas a várias medidas diferentes. Por exemplo,
a temperatura atual do servidor é uma métrica de valor único. Por outro lado, o número
cumulativo de solicitações de leitura de blocos grandes de um disco de grade tem uma
medida diferente para cada disco. Assim, em uma célula típica do Exadata, essa métrica
pode estar associada a mais de 20 observações diferentes.
Os limites são definições que permitem aos administradores definir níveis de métrica, os
quais, se ultrapassados, geram automaticamente uma notificação de alerta. Os limites podem
conter dois níveis de alerta, de advertência e crítico. Por exemplo, poderia ser definido um
limite para gerar um alerta de advertência quando a utilização de memória da célula chegar
a 80%, e um alerta crítico quando ela alcançar 90%.
O Exadata Storage Server gera alertas para diversas condições do sistema. Por exemplo,
será gerado um alerta se o software de servidor da célula for encerrado inesperadamente
ou se um sensor detectar uma falha potencial iminente no disco. Alertas adicionais podem
ser gerados para eventos definidos pelo usuário com o uso de limites.
Observe que o Enterprise Manager também contém um sistema diferente de métricas, limites
e alertas. Outros softwares, como o Oracle Database, contêm suas próprias métricas e
alertas.
ADR (Automatic Diagnostic Repository)
• O que é?
– Um repositório baseado em arquivo para dados de

diagnóstico, como rastreamentos, dumps e logs
• O que ele faz?
– Fornece uma organização consistente dos dados de
diagnóstico que permite aos administradores e ao Oracle
Support correlacionar e analisar esses dados com mais le
facilidade e eficiência fe rab
• Onde é encontrado? tra ns
n -
– Servidores de banco de dados do Exadata Database
a no
Machine e Exadata Storage Servers has ฺ
ฺ b r) uide
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
O ADR o Te
(Automatic lic
Diagnostic Repository) é um repositório baseado em arquivo para
i c
n de diagnóstico, como rastreamentos, dumps, log de alertas, relatórios do Health
dados
T e c
Monitor e muito mais. Ele apresenta uma estrutura de diretório unificada em vários produtos
e instâncias. A partir da Release 11g, o banco de dados, o ASM (Automatic Storage
Management), o listener e outros produtos Oracle armazenam os dados de diagnóstico
no ADR. O Exadata Storage Server também usa a estrutura do ADR para organizar seus
dados de diagnóstico.
Cada instância de cada produto armazena os dados de diagnóstico em seu próprio diretório
home no ADR. Por exemplo, em um ambiente Oracle Real Application Clusters com
armazenamento compartilhado e o Oracle ASM, cada instância de banco de dados e cada
instância ASM tem diretórios home separados no ADR.
A estrutura unificada de diretórios do ADR, os formatos consistentes dos dados de
diagnóstico nos diversos produtos e instâncias, e um conjunto unificado de ferramentas
permitem que os clientes e o Oracle Support correlacionem e analisem esses dados com
eficiência em várias instâncias.

Enterprise Manager Grid Control
Console do
Grid Control
Agentes
e
plugins
Oracle
Management
Service le
fe rab
tr a ns
n -
no a
Oracle a
h eฺ s
Management
Repository r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licGrid Control é uma plataforma de software de gerenciamento de
Te Manager
O Enterprise
o
ic que oferece uma funcionalidade centralizada de monitoramento, administração e
ecn
sistemas
T gerenciamento do ciclo de vida para a infraestrutura de tecnologia da informação, incluindo
sistemas que executam tecnologias Oracle e não Oracle.
Quando usado com o Exadata Database Machine, o Enterprise Manager Grid Control
deve ser configurado com um conjunto de plugins específicos do sistema para permitir
o monitoramento dos diversos componentes do Database Machine. Além disso, há
recomendações das melhores práticas sobre como configurar os alvos do Database Machine
no Grid Control a fim de facilitar o monitoramento do Database Machine como uma entidade
unificada, em vez de como um conjunto de componentes separados. A próxima lição do
curso descreve como configurar o Grid Control para monitorar o Exadata Database Machine.

Enterprise Manager Database Control
Console do
Database Controle
Processos e
Repositório
do Database
Control
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licDatabase Control é um ambiente de administração de banco de dados
Te Manager
O Enterprise
o
ic
ecn
incorporado no Oracle Database. Ele é capaz de executar tarefas administrativas, como
T criação de objetos de esquema (tabelas, views, índices etc.), gerenciamento da segurança
do usuário, gerenciamento de memória e armazenamento de banco de dados, backup e
recuperação de banco de dados, e movimentação de dados em massa (exportação e
importação). Também é possível exibir informações de desempenho e status sobre o banco
de dados.
Além de suas funções básicas de administração de banco de dados, o Database Control
também oferece recursos de monitoramento e gerenciamento para os Exadata Storage
Servers. Entretanto, o Database Control não oferece os amplos recursos de monitoramento
disponíveis no Grid Control. Por esse motivo, o Grid Control é o ambiente de monitoramento
recomendado para o Exadata Database Machine. Além disso, este curso não fornece mais
detalhes sobre o Database Control.

Questionário
Quais das seguintes tecnologias de infraestrutura de

monitoramento podem ser usadas com os Exadata Storage

Servers:
a. SNMP (Simple Network Management Protocol)
b. ILOM (Integrated Lights Out Manager)
c. Métricas, limites e alertas do Exadata
d. ADR (Automatic Diagnostic Repository) r a ble
n s fe
e. Enterprise Manager Grid Control tra
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Resposta:
o Ta,e b, c, d,lice
e c nic
T

Resumo
Nesta lição, você aprendeu a descrever as principais

tecnologias de infraestrutura de monitoramento associadas ao

Exadata Database Machine.
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Configurando o Enterprise Manager Grid

Control 11g para Monitorar o Exadata
Database Machine le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos

• Descrever como a arquitetura do Enterprise Manager Grid

Control se aplica especificamente ao Exadata Database
Machine.
• Descrever o posicionamento de agentes, plugins e alvos
• Descrever a configuração recomendada para alta
disponibilidade r a ble
• Descrever os plugins associados ao Exadata Database n s fe
Machine e como eles são configurados. n - tra
a no
• Descrever como configurar um Dashboard
) h as para
ฺ o Exadata
Database Machine. ฺbr uide
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
o Te lic
ic
Tecn

Visão Geral da Arquitetura do
Enterprise Manager Grid Control
Console do
Grid Control
Agentes
e
plugins
Oracle
Management
Service le
fe rab
tr a ns
n -
no a
Oracle a
h eฺ s
Management
Repository r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licGrid Control contém quatro elementos principais:
Te Manager
O Enterprise
o
ic
Tecn1. O OMS (Oracle Management Service) é o elemento central de processamento do
sistema.
2. O Oracle Management Repository é o armazenamento persistente de informações de
monitoramento, gerenciamento e configuração.
3. A console do Grid Control fornece uma interface de gerenciamento baseada na Web.
4. Os agentes e os plugins são implantados nos alvos gerenciados para coletar
informações que são processadas pelo OMS.
Essa arquitetura fundamental não é alterada quando o Grid Control é usado para monitorar o

Arquitetura de Monitoramento do Grid Control
para o Exadata Database Machine
Oracle Exadata Database Machine Enterprise Manager
Grid Control 11g
Exadata Storage
Release 1
Servers Console do
Cisco
Sun InfiniBand Grid Control
Ethernet
Switch(es) CELLSRV MS
Switch
Traps do CellCLI
SNMP sobre SSH
Servidores de Banco de Dados Oracle
Instância de Banco Oracle
le
XML
Management
de Dados
rab
sobre
Agent 11g HTTP/
Avocent Release 1 Oracle
Instância ASM
HTTPS
fe
ns
MergePoint Management
Plugin Plugin do
Unity KVM
Listener
InfiniBand Exadata
Service
- tr a
Switch
no n
Clusterware
Plugin do
Cisco
Plugin da
PDU
s a
Sun
) a
h eฺ
Power
Informações
do Host Plugin do Plugin do
r
ฺ Guid
b Oracle
m
ฺco dent
Distribution ILOM KVM Management
Interface ILOM Repository
Units
k o
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k ic
Quando
o oTEnterprisel Manager Grid Control é usado para monitorar o Exadata Database
e c nic um Oracle Management Agent deve ser implantado em cada servidor de banco de
Machine,
T dados. O agente é usado para monitorar e manter os alvos do software Oracle no servidor de
banco de dados, incluindo instâncias de banco de dados, instâncias ASM, listeners, recursos
de clusterware e outras informações do host.
Além disso, há uma série de plugins disponíveis que estendem o Grid Control a fim de
permitir o monitoramente de outros componentes do Database Machine, como Exadata
Storage Servers, InfiniBand switches, Ethernet switch, KVM switch e PDUs (Power
Distribution Units).
Cada plugin se conecta aos respectivos alvos de monitoramento usando diferentes métodos.
Por exemplo, o plugin do Exadata Storage Server coleta dados de monitoramento das células
por meio de chamadas do CellCLI sobre SSH; entretanto, os alertas de célula do Exadata
são enviados diretamente para o agente por meio de traps do SNMP. Cada plugin é descrito
em mais detalhes mais adiante nesta lição.
Observe que alguns dos plugins suportam somente o Enterprise Manager Grid Control 11g
Release 1 (ou posterior) e o Oracle Management Agent 11g Release 1 (ou posterior).
Portanto, essas são as versões mínimas recomendadas para uso com o Database Machine.

Configurando o Grid Control para Monitorar
o Exadata Database Machine
1. Implante o Oracle Management Agent em todos os servidores
de banco de dados
2. Configure os alvos ASM e do Oracle Database
3. Implante os plugins de monitoramento do sistema para o
Database Machine
– Exadata Storage Server
– Integrated Lights Out Manager (ILOM)
– InfiniBand Switch(es) le
– Cisco Switch fe rab
– Avocent MergePoint Unity (KVM) Switch
tr a ns
– Power Distribution Units n -
4. Configure UDMs (User-Defined Metrics) para s a
monitoramento
no
de
rede adicional h a ฺ
ฺ b r) uide
ฺ c om nt G
5. Configure os plugins para alta disponibilidade
6. Configure um dashboard e um i k oserviço
u deagregado do Exadata
Database Machine t e S t
@ r te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
e
A listaodoTslide descrevelic as etapas recomendadas para configurar o Enterprise Manager Grid
e c nic para monitorar o Exadata Database Machine. O ponto de partida é considerado como
Control
T sendo após a instalação e a configuração iniciais do Database Machine e do Grid Control.
O restante desta lição descreve cada etapa em mais detalhes.
Demonstrações gravadas com um exemplo de cada etapa do processo também são
fornecidas com esta lição. Uma lista completa dessas demonstrações é apresentada
na seção de recursos adicionais no final da lição.

Implantando o Oracle Management Agent
• Onde implantar:
– Todos os servidores de banco de dados do Database

Machine
• Versão recomendada:
– 11g Release 1 (11.1) ou posterior
• Como implantar:
– Grid Control Agent Installation Wizard bl e
fe r a
– Consulte a demonstração Instalação e Configuração de n s
Agentes n - tra
o
a npoderá ser
– A instalação manual de alguns pacotes dosSO
a
necessária r) h eฺ ฺb Guid
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic o Oracle Management Agent 11g Release 1 (ou posterior) em todos
Te instalar
É recomendável
o
ic
ecn
os servidores de banco de dados do Database Machine.
T Supondo que o Enterprise Manager Grid Control 11g Release 1 já esteja em execução e haja
conectividade de rede entre ele e o Database Machine, a maneira mais fácil de implantar o
agente é usar o Grid Control Agent Installation Wizard. Um exemplo desse processo é
fornecido na demonstração Instalação e Configuração de Agentes.
Algumas versões anteriores dos servidores de banco de dados do Database Machine foram
fornecidas sem todos os pacotes necessários para o Oracle Management Agent. É aceitável
modificar esses servidores para instalar os pacotes ausentes.
Caso não seja possível instalar o Oracle Management Agent porque há pacotes ausentes,
instale os pacotes necessários e tente instalar novamente o agente. Uma lista dos pacotes
necessários para o agente é fornecida na documentação do Enterprise Manager.

Configurando Alvos do ASM e do
Oracle Database
• Os alvos de gerenciamento são descobertos
automaticamente depois que o Oracle Management Agent

é iniciado
• As instâncias ASM e os bancos de dados Oracle são
descobertos, mas são listados como não configurados
• Os administradores devem fornecer credenciais de
monitoramento para concluir a configuração
r a ble
• Os procedimentos são essencialmente os mesmos nsfe
independentemente de o Exadata Database Machine n - tra estar
ou não envolvido a no
) h as ฺ
• Consulte a demonstração Configurando
m ฺbr GAlvos
u ide do ASM e
de Banco de Dados ฺco nt
i k o ude
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Depoisoque
c
Teo OracleliManagement Agent for instalado e estiver em execução em cada
i c
n de banco de dados, os alvos de gerenciamento serão automaticamente descobertos.
servidor
T e c
Isso inclui instâncias ASM, bancos de dados do cluster, instâncias de bancos de dados,
clusters, recursos de clusterware, listeners de rede, informações do host e os próprios
agentes.
Após a fase de descoberta inicial dos alvos, as instâncias ASM e do Oracle Database são
descobertas, mas são listadas como não configuradas. Para concluir a configuração dessas
instâncias, os administradores devem fornecer as credenciais de monitoramento.
Para cada instância ASM, a conectividade entre essa instância e o Grid Control deve ser
configurada usando as credenciais de um usuário administrativo que tenha a atribuição
sysdba ou sysasm.
Para cada banco de dados, a conta de usuário dbsnmp deve ser ativada e a respectiva
senha deve ser fornecida para permitir a conectividade a partir do Grid Control. Observe que,
para ativar a conta dbsnmp, é necessário ter acesso como sysdba ao banco de dados.
Observe que o procedimento para configurar os alvos de instâncias ASM será o mesmo, quer
elas residam ou não no Exadata Database Machine. Da mesma forma, o procedimento
usado para configurar os alvos de instâncias de banco de dados no Database Machine é o
mesmo utilizado em outros ambientes de banco de dados clusterizados.
Um exemplo de como configurar os alvos do ASM e de banco de dados é fornecido na
demonstração Configurando Alvos do ASM e de Banco de Dados.

Visão Geral da Implantação
dos Plugins de Monitoramento do Sistema
• Os plugins estendem o Grid Control para permitir o
monitoramento de componentes adicionais de hardware e

software
• Cada plugin contém:
– A lógica que define como o Grid Control se comunica com o
componente e quais métricas são monitoradas
– As definições da interface do usuário que estendem a Console ble
ra
do Grid Control sfe a n
• Processo de implementação de plugins: n- t r
n o
1. Executar os pré-requisitos a
2. Importar o plugin para o ambiente do ) h asControl
Grid ฺ
b r i d e
3. Implantar o plugin em um oucmais
o mฺ agentes
t G u
4. Adicionar um alvo para i k
cadaoฺ instância
d e n
do componente
t e Stu
monitorado te@ is
o r e th
p s empresas afiliadas. Todos os direitos reservados.
suOracletoe/ouusuas
c ฺ
Copyright © 2012,
o (te nse
T
Os plugins
edeikmonitoramento
l ice do sistema estendem o Enterprise Manager Grid Control,
n i co que ele monitore tipos de componentes de hardware e software adicionais. Para o
permitindo
TecExadata Database Machine, há um pacote de plugins adequados disponível. Cada plugin
contém a lógica que permite a comunicação de um agente de gerenciamento com o tipo de
componente do sistema que está sendo monitorado. Ele também contém os elementos da
interface do usuário que estendem a Console do Grid Control e permitem que os
administradores exibam as informações associadas ao plugin.
O processo de implementação de cada plugin envolve as seguintes etapas:
1. Executar os pré-requisitos. Como os plugins se comunicam com vários componentes do
sistema de diversas maneiras, cada um deles tem pré-requisitos distintos que devem
ser configurados. Os pré-requisitos são documentados no Guia de Instalação que
acompanha cada plugin.
2. Importar o plugin. Os plugins são fornecidos como arquivos compactados Java
(arquivos jar). Para que um plugin possa ser usado, o respectivo pacote deve ser
importado para o ambiente do Grid Control.
3. Implantar o plugin. A implantação configura o plugin em um ou mais agentes. Isso
permite que o agente se comunique com o tipo de componente de hardware ou
software associado ao plugin.
4. Adicionar os alvos. Uma vez implantado um plugin, cada instância do componente
deverá ser registrada como um alvo.
Detalhes e informações adicionais de cada plugin são apresentados mais adiante nesta lição.
Estratégia Recomendada de
Implantação de Plugins
• Recomendação:
– Associe todos os alvos de plugin a um agente principal em

um dos servidores de banco de dados do Database Machine
– Configure o failover do alvo usando um agente secundário
em outro servidor de banco de dados para garantir alta
disponibilidade
• Lógica Subjacente:
– A qualquer momento, todos os alvos de plugin estão
r a ble
associados a um agente, o que simplifica o gerenciamento
n s fe
e o diagnóstico de problemas
n - tra
– O failover automático do alvo garantirá o monitoramento
a no
contínuo em caso de desativação do agente a s principal
– O impacto do monitoramento no desempenho r ) h e ฺé baixo e
b
ฺ Gu i d
limitado a um servidor de banco o m de dados
– O monitoramento do servidork o e nt
ฺc dedarmazenamento pode
t e i t u
aproveitar a interconexão
@ sInfiniBandS
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de versão e à conectividade de rede, os diversos plugins de
Sujeitos
o Te requisitos
aos
e c nic
monitoramento do Exadata podem ser implantados em quaisquer agentes de monitoramento
T associados ao ambiente do Grid Control. Por exemplo, é possível (embora não seja
recomendável) implantar o plugin do Exadata Storage Server em um agente em execução no
servidor OMS.
As melhores práticas recomendam implantar todos os plugins do Database Machine em pelo
menos dois agentes executados em servidores de banco de dados do Database Machine
diferentes. Os administradores são aconselhados a configurar todos os alvos de plugin de
forma que sejam associados inicialmente a apenas um dos agentes de gerenciamento, o
agente principal. Após a configuração dos primeiros alvos, há um processo recomendado
para configurar os plugins para alta disponibilidade. A configuração resultante migra
automaticamente todos os alvos de plugin para um agente secundário designado nos
casos em que o agente principal é desativado. O slide lista a lógica subjacente a essa
recomendação. A configuração dos plugins para garantir alta disponibilidade é descrita mais
adiante nesta lição.
Todos os exemplos e descrições de configuração de plugins fornecidos nesta lição se
baseiam na recomendação anterior. Os clientes que escolherem uma estratégia alternativa
de implantação de plugin precisarão ajustar suas configurações conforme adequado.

Implantando o Plugin de Monitoramento do
Sistema para o Oracle Exadata Storage Server
• Pré-requisitos:
– Credenciais preferenciais dos alvos do agente

– Equivalência de usuário SSH entre o usuário do agente e o
usuário cellmonitor em todas as células
• Recomendações:
– Configure um realm para permitir a geração de relatórios
agregados le
fe rab
CellCLI> alter cell realmName = <Realm Name>
tr a ns
n -
– Configure as células para enviar alertas ao a Control
Grid no
a s
usando o SNMP r) h eฺ ฺb Guid
• Demonstração: m
k o ฺco dent
– Configurando o Plugin t i Exadata
edo t u Storage Server
S
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic são necessários para implantar com êxito o Plugin de
Te pré-requisitos
Os seguintes
o
e c nic
Monitoramento do Sistema para o Oracle Exadata Storage Server:
T • As credenciais preferenciais devem ser definidas nas preferências do Grid Control. O
nome de usuário e a senha do host do usuário que está executando o Management
Agent devem ser especificados. As credenciais preferenciais devem ser definidas para
cada host de agente onde o plugin é implantado.
Observe que as Credenciais Preferenciais do Agente também são necessárias para a
implantação bem-sucedida de outros plugins de monitoramento do sistema. Em geral,
as Credenciais Preferenciais são definidas uma vez antes da implantação do primeiro
plugin e são reutilizadas para plugins subsequentes.
• O plugin do servidor de armazenamento se comunica com as células do Exadata
usando a conta de usuário cellmonitor nos Exadata Storage Servers. A equivalência
de usuário SSH deve ser configurada entre o usuário que executa o Management Agent
no host do agente (geralmente oracle) e o usuário cellmonitor em todas as células
que serão monitoradas pelo plugin. Como a conta de usuário cellmonitor tem
acesso limitado ao sistema operacional do servidor de armazenamento, um
procedimento especial é necessário para estabelecer a equivalência de usuário SSH.
Esse procedimento é documentado no Guia de Instalação que acompanha o plugin do
servidor de armazenamento. Um exemplo também é apresentado na demonstração
associada a este tópico.
Além disso, as seguintes recomendações se aplicam:
• Os Exadata Storage Servers podem ser reunidos em um grupo conhecido como realm.
O plugin do Exadata Storage Server contém vários relatórios que agregam informações
de monitoramento referentes a um realm. Geralmente, todas as células de um Exadata
Database Machine serão agrupadas em um realm, porém, isso não é um requisito
absoluto. É recomendável definir os realms com base nos agrupamentos lógicos
relevantes em seu ambiente.
• Junto com o plugin, é recomendável configurar todas as células para enviar alertas ao
Grid Control por meio do SNMP. Isso envolve ativar o método de notificação do SNMP
em cada célula, bem como adicionar o nome do host e da porta do agente como um
assinante SNMP.
Um exemplo de como implantar o plugin do servidor de armazenamento é fornecido na
demonstração Configurando o Plugin do Exadata Storage Server.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Sistema para o Oracle Exadata ILOM
• Recomendação:
– Use o plugin do ILOM somente para monitorar o ILOM nos

servidores de banco de dados do Database Machine
— Isso não é necessário para o Exadata Storage Server porque o
monitoramento do ILOM já é gerenciado pelo software desse
servidor.
le
– ipmitool versão 1.8.10.1 ou posterior
fe rab
– Credenciais de usuário do ILOM ns tra
n
o é -
— Uma conta de usuário do ILOM dedicada para onplugin
a
altamente recomendável
) h as ฺ
• Demonstração:
m ฺbr Guide
– Configurando o Plugin do oILOM
k ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic o processador de serviço ILOM em um servidor. Ele permite que
O plugin
o TdoeILOM monitora
ic de hardware e os dados de sensores sejam monitorados usando o Grid Control.
ecn
os eventos
T No caso do Database Machine, é recomendável usar o plugin do ILOM somente para o
monitoramento do processador de serviço ILOM dos servidores de banco de dados do
Database Machine. O plugin do ILOM não é necessário para monitorar os Exadata Storage
Servers uma vez que as métricas e os alertas do ILOM já são gerenciados pelo software
desses servidores.
O plugin do ILOM exige que o software ipmitool versão 1.8.10.1 ou posterior esteja
presente nos servidores que estão sendo monitorados por ele.
Embora isto não seja um requisito absoluto, é altamente recomendável criar uma conta de
usuário específica do ILOM para uso do plugin. O procedimento é documentado no Guia de
Instalação que acompanha o plugin do ILOM.
Um exemplo de como implantar o plugin do ILOM é fornecido na demonstração Configurando
o Plugin do ILOM.

Sistema para o Oracle Exadata InfiniBand Switch
– Versão 1.1.3-2 ou posterior do firmware do switch

– Configuração do SNMP:
— Ative o SNMP
— Defina o protocolo SNMP como v1 (versão 1)
— Defina a string da comunidade SNMP se planejar usar uma
string diferente da default (public)
le
• Demonstração: fe rab
– Configurando o Plugin do InfiniBand Switch tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic são necessários para a implantação bem-sucedida do Plugin de
Te pré-requisitos
Os seguintes
o
e c nic
Monitoramento do Sistema para o Oracle Exadata InfiniBand Switch:
T • O InfiniBand Switch deve estar executando a versão 1.1.3-2 ou posterior do firmware.
• O SNMP deve estar configurado no InfiniBand Switch para permitir que o plugin
obtenha suas informações. Um resumo das definições necessárias é apresentado
a seguir:
- O SNMP deve ser ativado
- O protocolo SNMP deve ser definido como v1 (versão 1)
- Se planejar usar uma string da comunidade SNMP diferente da default (public),
você deverá criar a definição apropriada e usar a mesma definição ao criar
posteriormente os alvos do InfiniBand switch.
Um exemplo de como implantar o plugin do InfiniBand switch é fornecido na demonstração
Configurando o Plugin do InfiniBand Switch.

Sistema para o Exadata Cisco Switch
– Configuração do switch:
— Permita o acesso do plugin para polling (sondagem) do switch
— Configure o switch para enviar traps do SNMP ao host do plugin
— Configure o switch para enviar somente traps do SNMP para
monitoramento do ambiente
Verifique e salve as definições
—
a b le
– Um encaminhador de traps do SNMP no host de cada plugin fe r
para capturar traps do Cisco switch e encaminhá-las rao n s
Management Agent n - ta
a no
• Demonstração:
) h as ฺ
– Configurando o Plugin do Cisco Ethernet
m ฺbr GuSwitch ide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic são necessários para a implantação bem-sucedida do Plugin de
Te pré-requisitos
Os seguintes
o
e c nic
Monitoramento do Sistema para o Exadata Cisco Switch:
T • O Cisco switch deve ser configurado para permitir comunicações SNMP entre o switch
e o plugin. O slide apresenta uma visão geral das etapas de configuração necessárias.
Observe que o Cisco Ethernet switch fornecido com o Database Machine não inclui
suporte para SSH. A Oracle recomenda que a conexão com a interface de
gerenciamento do switch seja estabelecida por meio de uma alternativa como telnet.
• O Cisco switch não tem uma forma documentada de enviar traps do SNMP para portas
diferentes da UDP 162. Entretanto, o Oracle Management Agent é executado como
o usuário oracle e não pode fazer listening nas portas UDP abaixo de 1024. Um
encaminhador de traps deve ser configurado a fim de encaminhar as traps do SNMP
geradas pelo switch para o Oracle Management Agent.
Instruções detalhadas sobre as duas tarefas de pré-requisito são fornecidas no Guia de
Instalação que acompanha o plugin. Um exemplo de como implantar o plugin do Cisco
Ethernet switch é fornecido na demonstração Configurando o Plugin do Cisco Ethernet
Switch.

Implantando o Plugin de Monitoramento do Sistema
para o Avocent MergePoint Unity (KVM) Switch
– Versão 1.2.8 ou posterior do software do switch

– Configuração do switch:
— Verifique se o SNMP está ativado no KVM switch
— Configure o switch para enviar traps do SNMP ao host do plugin
– Um encaminhador de traps do SNMP no host de cada
plugin para capturar as traps do KVM e encaminhá-las le
ao Management Agent fe rab
Mesma configuração que a necessária para o plugin dotra ns
—
n -
Cisco switch no a
• Demonstração: a s
– Configurando o Plugin do AvocentฺbKVM r) h Switch
u i d eฺ
o m t G
i k oฺc uden
@ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic são necessários para a implantação bem-sucedida do plugin do
Te pré-requisitos
Os seguintes
o
e c nicswitch:
KVM
T • É necessária a versão 1.2.8 ou posterior do software do KVM switch. Verifique se você
tem a versão necessária.
• Verifique se o SNMP está ativado no KVM switch.
• Configure o KVM switch para enviar traps do SNMP ao host onde o plugin será
implantado.
• O KVM switch envia as traps do SNMP para a porta default (UDP 162). Entretanto,
o Oracle Management Agent é executado como o usuário oracle e não pode fazer
listening nas portas UDP abaixo de 1024. Configure um encaminhador de traps para
enviar as traps do SNMP geradas pelo KVM para o Oracle Management Agent. Se você
já tiver configurado um encaminhador de traps para o plugin do Cisco switch, nenhuma
outra configuração será necessária.
Instruções detalhadas sobre todas as tarefas de pré-requisito são fornecidas no Guia de
Instalação que acompanha o plugin. Um exemplo de como implantar o plugin do KVM
switch é fornecido na demonstração Configurando o Plugin do Avocent KVM Switch.
A demonstração da implantação do plugin do Cisco switch contém um exemplo da
configuração necessária para o encaminhador de traps do SNMP.

Sistema para a PDU do Oracle Exadata
– PDU conectada e configurada para acesso à rede de gerenciamento

– Versão 1.02 ou posterior do firmware da PDU
– SNMP ativado na PDU
– PDU configurada para se comunicar com o host do plugin
– Limites de alarme da PDU definidos. As definições se baseiam em:
— Versão do Database Machine:
— Exadata Database Machine X2-2 (usando os servidores X4170 e X4275)
le
— Exadata Database Machine X2-2 (usando os servidores X4170 M2 e X4270 M2)
fe rab
—
tr a ns
Exadata Database Machine X2-8 (usando os servidores X4800 e X4270 M2)
— Tamanho do Database Machine:
n -
— Full Rack, Half Rack ou Quarter Rack no a
— Tipo de PDU:
a s
h de 15ekVA
—Monofásica de 15 kVA de baixa voltagem ̶ Trifásica
r ) d ฺ de baixa
voltagem
m b
ฺ Gu i
o
ent de 24 kVA de alta voltagem
oฺc u̶ dTrifásica
—Monofásica de 15 kVA de alta voltagem ̶ Trifásica de 15 kVA de alta voltagem
Trifásica de 24 kVA de baixaik voltagem
te St
—
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Os seguintes
o lic são necessários para a implantação bem-sucedida do Plugin de
Te pré-requisitos
e c nic
Monitoramento do Sistema para a PDU (Power Distribution Unit) do Oracle Exadata:
T • Por default, as PDUs incluídas no Exadata Database Machine não estão conectadas
fisicamente a nenhuma rede. Para monitorar as PDUs usando o plugin, conecte cada
uma delas à rede de gerenciamento e configure a porta de rede da PDU com as
informações de endereçamento IP. Observe que cada PDU deve ser conectada
diretamente à rede, e não ao Cisco Ethernet switch no rack do Database Machine. Essa
configuração ajuda a garantir que os alertas gerados pelas PDUs sejam entregues ao
Grid Control mesmo que um problema de energia cause uma falha na rede de
gerenciamento do Database Machine.
• Verifique se a versão do firmware da PDU é a 1.02 ou posterior. Para obter a versão
atual, efetue login na interface Web da PDU. Do lado esquerdo da tela, clique em
Module Info para exibir a versão do firmware da PDU.
• Verifique se o SNMP está ativado na PDU e configure-a para permitir comunicações
SNMP com o host onde o plugin da PDU será implantado.
• Configure a PDU com valores de limite de alarme. Os valores de limite apropriados
dependem da versão do Oracle Exadata Database Machine, do tamanho do Oracle
Exadata Database Machine e do tipo de PDU usado. O Oracle Exadata Database
Machine Owner's Guide contém os valores de limite recomendados para cada situação.
Consulte o Guia do Usuário e o Guia de Instalação da PDU fornecidos com o plugin da PDU
para obter mais detalhes.
Configurando UDMs (User-Defined Metrics)
para Monitoramento de Rede Adicional
• A integridade das portas da rede InfiniBand deve ser
monitorada em todos os servidores do Database Machine

– O monitoramento da rede InfiniBand é executado
automaticamente pelo MS nos servidores de
armazenamento
• Os scripts UDM (User Defined Metric) estão disponíveis
em My Oracle Support note 1110675.1: le
– emudm_ibconnect.sh monitora a conectividade da rede fe rab
a n s
InfiniBand com outros servidores do Database Machine
n -t r
– emudm_netif_state.sh monitora o estado n o
das interfaces
a
de redes Ethernet e InfiniBand
) h as ฺ
• Consulte a demonstração Configurando m ฺbr GUDMs u ide (User
Defined Metrics) para Monitoramento k o ฺco dentde Rede Adicional
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licportas InfiniBand verifica a integridade das interfaces e das portas da
Te das
O monitoramento
o
redeicInfiniBand nos servidores de banco de dados e nos Exadata Storage Servers. O
Tecnmonitoramento das portas InfiniBand nos servidores de armazenamento é executado pelo
Management Server (MS) do Exadata Storage Server. Nenhum monitoramento adicional é
necessário nesses servidores. Se uma porta não estiver funcionando corretamente, o MS
criará um alerta e o enviará ao Grid Control por meio do SNMP.
Por default, os servidores de banco de dados do Database Machine não contam com o
monitoramento incorporado de rede InfiniBand. Verificações com o uso de comandos como
ibstatus e perfquery podem ser executadas periodicamente; entretanto, esse é um
processo manual. Essas verificações podem ser automatizadas com o uso de UDMs (User
Defined Metrics) no Grid Control. Dois scripts UDM são fornecidos para servidores de banco
de dados:
• emudm_ibconnect.sh - Este script UDM monitora a conectividade da rede InfiniBand
com outros servidores de banco de dados e de armazenamento. Essa lista de
servidores de banco de dados é criada a partir da chave ocrdump
SYSTEM.crs.e2eport. A lista de células é criada a partir de cellip.ora. O script
não valida a conectividade com outros dispositivos na rede InfiniBand, como servidores
de mídia.

Observe que o comando ibhosts não é usado porque requer permissões de root. A
abordagem usada nesse script é a preferencial uma vez que o escopo é limitado aos
servidores relevantes para o Exadata Database Machine, e não à rede InfiniBand
inteira.
O uso desse script é recomendado para criar um UDM para cada servidor de banco de
dados do Database Machine.
• emudm_netif_state.sh - Este script UDM pode monitorar o estado das interfaces
de rede Ethernet ou InfiniBand. No caso das interfaces InfiniBand, ele verifica a porta,
o estado, a taxa e três contadores de erro InfiniBand subjacentes; RcvErrors,
SymbolErrors e LinkIntegrityErrors. Se a interface for a interface mestre do
acoplamento Linux, o estado das interfaces escravas será verificado. Os contadores
de erro só serão reportados se tiverem aumentado desde a última chamada do script
e somente quando LinkDowned não tiver aumentado. Os valores anteriores são
armazenados no cache do arquivo temporário
/var/tmp/ibCounterCache_<device><port>. A Oracle recomenda o uso desse le
script para criar um UDM para cada interface de rede em cada servidor de banco de
fe rab
dados do Database Machine.
tra ns
n -
Os scripts UDM estão disponíveis em My Oracle Support note 1110675.1. Um exemplo de
a no
como implantar esses scripts é fornecido na demonstração Configurando UDMs (User
Defined Metrics) para Monitoramento de Rede Adicional. a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Configurando o Grid Control para o Exadata
Database Machine: Abordagem Alternativa
• Há um método alternativo para instalar rapidamente o

Grid Control e os plugins do Exadata. Ele permite:

– Instalar o Grid Control em um servidor standalone
– Instalar o agente de gerenciamento e os plugins do Exadata em:
— Uma nova instalação do Grid Control
— Um ambiente existente do Grid Control com outros alvos existentes
– Remover o agente de gerenciamento dos servidores de bancoable
de dados s fer
n
– Remover o Grid Control de um servidor standalonen-tra
o
• A abordagem está integrada aos processos adeninstalação e
configuração inicial do Database Machine) h as ฺ
r uide
ฺbcomo
• m
Há suporte para o Linux e o Solaris
c o nt G opções de SO de
ฺ
servidor de banco de dadosiko ude te St
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Te
Há umoprocedimento licalternativo para instalar rapidamente o Grid Control e os plugins do
e c nic O procedimento está integrado ao processo de instalação e configuração inicial
Exadata.
T do Database Machine e suporta o Linux e o Solaris como opções de sistema operacional
de servidor de banco de dados. O procedimento é descrito no Oracle Exadata Database
Machine Owner's Guide atualizado e requer o patch 11852882.
Ele permite instalar um novo ambiente do Grid Control em um servidor standalone usando
um programa de instalação em uma etapa chamado setupem.sh. Além disso, com o
programa setupem.sh, é possível instalar os plugins do Exadata em uma nova instalação
ou em um ambiente existente do Grid Control que poderá já estar monitorando outros alvos.
Isso inclui executar os pré-requisitos de cada plugin, importar o plugin para o Grid Control e
implantá-lo em todos os agentes de gerenciamento do Database Machine. Também é
possível remover os plugins do Exadata e o software Grid Control.
Observe que, embora o programa setupem.sh possa implantar os plugins do Exadata, os
administradores ainda devem configurar todos os alvos do Grid Control que representam os
diversos componentes do Database Machine.

Configurando os Plugins para Alta Disponibilidade
• Normalmente o alvo de um plugin está associado a um agente
específico
– Se o agente estiver desativado, o alvo não poderá ser monitorado
• Há um procedimento para facilitar o failover do alvo para um agente

secundário
– Consulte My Oracle Support note 1110675.1
– Consulte a demonstração Configurando Plugins para Alta Disponibilidade
Oracle Exadata Database Machine

le
Servidor de Banco
de Dados A
Servidor de Banco
de Dados B
fe rab
Agente de Agente de
tr a ns
Gerenciamento Gerenciamento
n -
no
Principal Secundário
Para Para
s a
Alvos
Plugin
Plugin
Alvos
Plugin
Plugin
) h a ฺ Oracle
ฺbr Guide
Plugin Plugin Management
Plugin Plugin
Service
o m t
i k oฺc uden
@ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c
o Teum alvolimonitorado
Por default, com um plugin está associado ao agente usado durante
an i c
implantação inicial. Há um procedimento que permite mover automaticamente o
Tecmonitoramento do alvo de um plugin para um agente secundário predefinido quando o
agente principal está desativado. Para isso, cada alvo deve ser configurado com um host
default e outro de failover.
Quando o agente no host default, o agente de gerenciamento principal, torna-se indisponível
por qualquer motivo, o monitoramento dos alvos afetados é movido automaticamente para
o agente no host de failover, o agente de gerenciamento secundário. Quando o agente de
gerenciamento principal fica disponível de novo, os alvos são automaticamente movidos de
volta para ele.
Para permitir o failover e o failback de alvos, é necessário instalar o pacote PL/SQL de
extensão de failover no repositório de gerenciamento. O processo de configuração de failover
é descrito no documento Installation of plug-ins and dashboard configuration. Esse
documento e a extensão de failover estão disponíveis em My Oracle Support note
1110675.1.
Observe que, quando os plugins são configurados para alta disponibilidade, os pré-requisitos
de cada plugin devem ser atendidos nos hosts dos agentes principal e secundário. Por
exemplo, é necessário definir as Credenciais Preferenciais do Agente nos hosts dos agentes
de gerenciamento principal e secundário. Além disso, é necessário implantar os plugins em
ambos os hosts.
Um exemplo de como configurar os plugins para alta disponibilidade é fornecido na
demonstração Configurando Plugins para Alta Disponibilidade.
Configurando um Dashboard e um Serviço
Agregado do Exadata Database Machine
Instâncias
ASM
Consulte a demonstração
Hosts
Criando um Dashboard para o Database Machine
Servidores de
Armazenamento
Listeners
le
rab
Instâncias de
Banco de
Dados
fe
InfiniBand
tr a ns
Switches
n -
no a
PDUs
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k leicconfigurados todos os plugins de monitoramento do sistema do
Uma vez
o Tinstalados
n ic o Grid Control poderá ser usado para monitorar todos os componentes do Exadata
Exadata,
c
e
T Database Machine (alvos). Para um Database Machine Full-Rack, existem normalmente mais
de 60 alvos.
Naturalmente, os administradores preferem monitorar o Database Machine como uma única
entidade, em vez de como 60 componentes separados. Uma abordagem recomendada foi
desenvolvida para facilitar o monitoramento do Database Machine como uma única entidade.
Embora ela se baseie nos fundamentos das melhores práticas, há oportunidades de
personalização em algumas áreas para atender a diversas necessidades. O diagrama do
slide ilustra a hierarquia de alvos resultante no Grid Control. Uma descrição da metodologia
de alto nível envolvida é apresentada a seguir:
1. Para cada tipo de alvo do Database Machine no Grid Control, crie um conjunto
contendo todos os alvos desse tipo usando o tipo de alvo Sistema. Por exemplo, agrupe
as instâncias ASM em um Sistema, agrupe os Exadata Storage Servers em outro
Sistema e assim por diante.
2. Crie um Serviço baseado em cada um dos Sistemas criados anteriormente. Um Serviço
é uma abstração de um Sistema que pode ter métricas associadas de desempenho e
de uso definidas pelo administrador. Métricas de desempenho e de uso distintas podem
ser criadas para atender a diversas situações. Por exemplo, o administrador de um
Data Warehouse pode estar interessado no throughput de entrada/saída como uma
medida-chave de desempenho, enquanto o administrador de um banco de dados OLTP
pode estar mais interessado em um indicador de tempo de resposta médio.
3. Crie um Serviço Agregado para agrupar todos os Serviços em uma única entidade
do Grid Control. A tela do slide mostra um exemplo de home page de um Serviço
Agregado no Grid Control.
4. Crie um Dashboard de monitoramento com base no Serviço Agregado. O Dashboard
fornece uma visão geral da integridade, do desempenho e do uso do Database
Machine em uma única tela. O Dashboard pode ser personalizado de acordo com
requisitos diversos exibindo métricas diferentes de desempenho e de uso.
Mais detalhes sobre o processo descrito anteriormente são fornecidos no documento

Installation of plug-ins and dashboard configuration, disponível em My Oracle Support note
1110675.1. Um exemplo de como configurar um dashboard para o Exadata Database
Machine é fornecido na demonstração Criando um Dashboard para o Database Machine.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Questionário
Qual é a abordagem recomendada para a implementação dos

plugins de monitoramento do sistema do Exadata Database

Machine?
a. Configurar todos os alvos do plugin usando agentes
diferentes para distribuir a carga de monitoramento
b. Configurar cada alvo do plugin usando todos os agentes
disponíveis para garantir a disponibilidade máxima
r a ble
c. Configurar todos os alvos do plugin usando apenas um n s fe
agente para fins de simplicidade n - tra
a no
d. Configurar todos os alvos do plugin usando a s um agente
principal e configurar o failover do alvo
r ) hpara e
umฺ agente
b
ฺ Gu i d
secundário a fim de garantir ฺalta
o mdisponibilidade
c ent e
o
teik tud
simplificar a implantação
@ his S
r t
o se te
u p
Copyright © 2012,
e
t
o ( ense
i k lic
Resposta:
o Tde
e c nic
T

Questionário
É possível personalizar o alvo do Exadata Database Machine

no Enterprise Manager Grid Control 11g exibindo métricas

diferentes de desempenho e de uso:
a. VERDADEIRO
b. FALSO
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
e c nichá um tipo de alvo do Enterprise Manager Grid Control 11g para o Database Machine.
Não
T Em vez disso, os alvos de componentes são agregados em Sistemas e Serviços para
fornecer uma visualização consolidada do Database Machine como um todo.

Resumo

• Descrever como a arquitetura do Enterprise Manager Grid

Control se aplica especificamente ao Exadata Database
Machine.
• Descrever o posicionamento de agentes, plugins e alvos
• Descrever a configuração recomendada para alta
disponibilidade r a ble
• Descrever os plugins associados ao Exadata Database n s fe
Machine e como eles são configurados. n - tra
a no
• Descrever como configurar um Dashboard
) h as para
ฺ o Exadata
Database Machine. ฺbr uide
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
o Te lic
ic
Tecn

Recursos Adicionais
– Instalação e Configuração de Agentes

– Configurando Alvos do ASM e de Banco de Dados
– Configurando o Plugin do Exadata Storage Server
– Configurando o Plugin do ILOM
– Configurando o Plugin do InfiniBand Switch
– Configurando o Plugin do Cisco Ethernet Switch
– Configurando o Plugin do Avocent KVM Switch r a ble
s e
fde
– Configurando UDMs (User Defined Metrics) para Monitoramento
tra n
Rede Adicional n -
– Configurando Plugins para Alta Disponibilidades a
no
ha eฺ
– Criando um Dashboard para o Databaser)Machine
• My Oracle Support Notes m ฺb Guid
o ฺ co ent
– Oracle Database Machine
t k
eiMonitoringt ud Best Practices
S
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Monitorando Exadata Storage Servers
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos

• Descrever as métricas, os alertas e as solicitações ativas

do Exadata Storage Server
• Identificar as áreas de foco recomendadas para o
• Descrever como monitorar as áreas de foco
le
recomendadas do Exadata Storage Server
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral da Lição
• Arquitetura e Visão Geral de Métricas e Alertas do Exadata

• Visão Geral do Monitoramento do Exadata Storage Server

com o Grid Control
• Monitorando Falhas de Hardware e o Estado de Sensores
O Que Monitorar
• Monitorando a Disponibilidade do Exadata Storage Server
• Verificando Alertas Não Entregues
• Verificando Erros de Entrada/Saída de Disco
r a ble
• Verificando Erros de Rede
n s fe
• Monitorando o Espaço Livre no Sistema de Arquivos -tra
• Comparando Métricas entre Vários Servidores de n on
s a
Armazenamento
) a
h eฺ
• Monitorando Métricas em um Servidor b r id
ฺ de Armazenamento
u
m G
• Ferramentas de Monitoramento k o ฺcdeo Terceiros
d e n t
i te Stu
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Tsee concentra
Esta lição
o lic nas recomendações das melhores práticas para o Exadata Storage
e c nic no que diz respeito ao que deve ser monitorado de uma perspectiva administrativa
Server
T geral e como.
A lista do slide resume os tópicos contidos na lição. A área sombreada destaca as áreas
recomendadas para monitoramento.

Arquitetura de Métricas e Alertas do Exadata
MS mantém um
conjunto de valores de métricas.
Uma hora de
Métricas coletadas:
célula, discos de célula, valores de LIST METRICCURRENT
disco de grade, IORM,
Interconexão métricas
Limites
de métricas na memória
Erros
excedidos
internos
de CELLSRV
A cada hora, o MS
CELLSRV
descarrega valores de
coleta CELLSRV ADR MS métricas no disco.
métricas
le
Problemas do
fe rab
ns
ALTER CELL
software Disco
tra
Sete dias
de célula
E-mail
1 hora
métricas
o n -
Célula e/ou LISTnMETRICHISTORY
SNMP a
Problemas do
) h as ฺ LIST
alertas
ALERTHISTORY
ฺbrde G ide
hardware
de célula
Histórico
m u
Métricas
k o ฺco deeAlertas nt
t ei Stu
Admin
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c a arquitetura de métricas e alertas do Exadata Storage Server.
Tedo slideliilustra
O diagrama
o
c como CELLSRV registra periodicamente propriedades importantes de runtime,
Ele imostra
Tecnchamadas métricas, sobre componentes de células, como CPUs, discos de célula, discos de
grade, flash cache e estatísticas de IORM. Essas métricas são registradas na memória. Com
base na sua própria programação de coleta de métricas, o MS (Management Server) obtém o
conjunto de dados de métricas acumulados pelo CELLSRV. O MS mantém um subconjunto
dos valores de métricas na memória e grava um histórico em um repositório baseado em
disco interno a cada hora. Esse processo, em conceito, é similar a snapshots AWR de banco
de dados.
O período de retenção de entradas de histórico de métricas e alertas é especificado pelo
atributo de célulametricHistoryDays. É possível modificar essa definição com o comando
CellCLI ALTER CELL. Por default, é sete dias. É possível exibir o histórico de valores de
métricas usando o comando CellCLI LIST METRICHISTORY e os valores de métricas atuais
com o comando LIST METRICCURRENT.
No nível de célula do Exadata, antes da release 11.2.2.3.1 do software do Exadata Storage
Server, era possível definir limites para algumas métricas. A partir dessa release, podem ser
definidos limites para todas as métricas de célula.

Além de coletar métricas, o Exadata Storage Server pode gerar alertas. Os alertas
representam eventos importantes que ocorrem na célula, indicando, em geral, o
comprometimento de uma função da célula do Exadata. O MS gera um alerta quando
detecta:
• Problemas de hardware de célula
• Problemas de configuração ou de software de célula
• Erros internos do CELLSRV

• Métricas que excederam um limite definido na célula
É possível exibir alertas gerados anteriormente usando o comando LIST ALERTHISTORY.
Além disso, você pode configurar a célula para enviar automaticamente um e-mail e/ou
mensagens SNMP a um conjunto designado de administradores.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Monitorando o Exadata Storage
Server com Métricas
Métrica
alertState metricObjectName unit objectType metricValue metricType name …
normal número cumulative

warning % (percentage) instantaneous
critical F (fahrenheit) rate
le
rab
C (celsius) transition
fe
ns
CREATE|ALTER THRESHOLDS
IORM_CONSUMER_GROUP
IORM_DATABASE
- tra
Limites IORM_CATEGORY
no n
CELL
s a
CELLDISK
) a
h eฺ
name b
CELL_FILESYSTEM r
ฺ Guid
comparision m
critical
occurances
k o ฺco dent
GRIDDISK
observation
t ei Stu
HOST_INTERCONNECT
te@ this
warning FLASHCACHE
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
Métricas
o
e observações
Tsão lic registradas de importantes propriedades de runtime ou valores de
e c nic
instrumentação interna da célula de armazenamento e seus componentes, como discos de
T célula e de grade. As métricas são uma série de medidas calculadas e mantidas na memória
durante um período e armazenadas em um disco para criar um histórico mais permanente.
A figura no slide descreve alguns dos atributos de métrica importantes. Cada métrica:
• Tem um nome e uma descrição
• Está associada a um metricObjectName, que é o nome do objeto que está sendo
medido, como um disco de célula, um disco de grade ou um grupo de usuários
específico
• Pertence a um grupo definido por seu atributo objectType. Os grupos possíveis são
mostrados no slide.
• Tem um metricType, que é um indicador de como a estatística foi criada ou definida.
Valores possíveis e seus significados são:
- cumulative: estatísticas acumuladas desde que a métrica foi criada
- instantaneous: valor no momento em que a métrica é coletada
- rate: taxas calculadas por estatísticas de média em períodos de observação
- transition: são coletadas quando o valor das métricas é alterado e, em geral,
captam transições importantes no status de hardware
• Tem uma unit de medida. As unidades possíveis são mostradas no slide.

O entendimento a cerca da composição do nome da métrica proporciona uma boa ideia do
seu significado. O valor do atributo de nome é um composto de abreviações. O valor de
atributo se inicia com uma abreviação do tipo de objeto sobre o qual a métrica é definida:
• CL_ (célula)
• CD_ (disco de célula)
• GD_ (disco de grade)
• FC_ (flash cache)

• DB_ (banco de dados)
• CG_ (grupo de consumidores)
• CT_ (categoria)
• N_ (rede de interconexão)
Após a abreviação do tipo de objeto, muitos nomes de métricas são concluídos com uma
abreviação que corresponde à descrição da métrica. Por exemplo, CL_FANS é o número le
instantâneo de ventoinhas em funcionamento na célula. fe rab
tra
Atributos de nomes de métrica relacionados a entrada/saída continuam com uma das ns
n -
combinações a seguir, para identificar a operação:
• IO_RQ (número de solicitações)
no
a
a s
h eฺ
• IO_BY (número de MB) r )
ฺ Guid
b
• IO_TM (latência de entrada/saída) m
• IO_WT (tempo de espera de entrada/saída) k o ฺco dent
t ei ou _WS tu
Pode estar próximo ao nome _R para
r t e @leitura
h i s para gravação. Após isso, pode haver
u p o se t pequenas ou grandes, respectivamente. No final

_SM ou _LG para identificar entradas/saídas
do nome, pode haver _SEC
c ฺ s to u por segundo ou _RQ por solicitação. For example:
significando
• CD_IO_RQ_R_SM
o (te énosnúmero
e de solicitações para ler pequenos blocos em um disco de
e
célula. i k l ic e
o T
• icGD_IO_BY_W_LG_SEC é a quantidade de MB da entrada/saída de bloco grande por
c n
Te segundo em um disco de grade.
Se um valor de métrica ultrapassa um limite definido pelo usuário, um alerta é gerado. As
métricas podem ser associadas a limites de advertência e críticos. Limites se relacionam a
valores extremos na métrica, que podem indicar um problema ou outro evento de interesse
de um administrador.
Limites são suportados em métricas de contagem de erros de entrada/saída em discos de
célula e de grade (CD_IO_ERRS_MIN e GD_IO_ERRS_MIN), juntamente com métricas de
utilização da memória de célula (CL_MEMUT ) e a utilização do sistema de arquivos de célula
(CL_FSUT). Além disso, você pode definir limites para métricas relacionadas ao IORM (I/O
Resource Management). O comando CellCLI LIST ALERTDEFINITION lista as métricas
para as quais é possível definir limites.
Para obter mais detalhes sobre atributos de limites e métricas de célula do Exadata, consulte
o Oracle Exadata Storage Server Software User's Guide.

Monitorando Métricas de Célula do Exadata:
Exemplos
CellCLI> LIST METRICDEFINITION WHERE objectType ='CELL' DETAIL
name: CL_CPUT
description: "Cell CPU Utilization is the percentage of time over

the previous minute that the system CPUs were not
idle (from /proc/stat). "
metricType: Instantaneous objectType: CELL
unit: %
...
CellCLI> LIST METRICHISTORY WHERE name like 'CL_.*' –

AND collectionTime > '2009-10-11T15:28:36-07:00'
le
rab
CL_RUNQ cell03_2 6.0 2009-10-11T15:28:37-07:00
CL_CPUT cell03_2 47.6 % 2009-10-11T15:29:36-07:00
fe
CL_FANS cell03_2 1 2009-10-11T15:29:36-07:00
tr a ns
CL_TEMP cell03_2 0.0 C 2009-10-11T15:29:36-07:00
n -
CL_RUNQ
...
cell03_2 5.2 2009-10-11T15:29:37-07:00
no a
a
h eฺ s
CellCLI> LIST METRICCURRENT WHERE objectType = 'CELLDISK' r
ฺ Guid
b )
CD_IO_TM_W_SM_RQ CD_1_cell03 205.5 us/request
m
co us/request t
CD_IO_TM_W_SM_RQ CD_2_cell03 93.3
k o ฺ0.0 e n
CD_IO_TM_W_SM_RQ CD_3_cell03
... t ei Stud us/request
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k liccomandos básicos que podem ser usados para exibir informações de
Te alguns
O slideomostra
e c nic
métricas:
T • Use o comando LIST METRICDEFINITION para exibir definições de métricas da
célula. Uma definição de métrica descreve a configuração de uma métrica. O exemplo
não especifica uma métrica determinada, então, todas as métricas correspondentes à
cláusula WHERE são impressas. Além da cláusula WHERE, você também pode
especificar os atributos de definição de métrica que você deseja imprimir. Se a cláusula
ATTRIBUTES não for usada, um conjunto default de atributos é exibido. Para listar os
atributos, é possível adicionar a palavra-chave DETAIL no final do comando.
• Use o comando LIST METRICHISTORY para exibir o histórico de métrica da célula.
Um histórico de métrica descreve um conjunto de observações de métrica passadas.
Similar ao comando LIST METRICDEFINITION, você pode especificar filtros de
atributo, uma lista de atributos e a palavra-chave DETAIL do comando LIST
METRICHISTORY. O exemplo acima lista métricas com nomes que se iniciam com CL_
coletadas após o tempo especificado.
• Use o comando LIST METRICCURRENT para exibir os valores de métricas atuais da
célula. O exemplo acima lista todas as métricas de disco de célula. Os valores de
métricas mostrados no slide correspondem à latência média por solicitação de
gravação de pequenos blocos em um disco de célula. Para essa métrica, há uma
observação para cada disco de célula.
Monitorando o Exadata Storage
Server com Alertas
Alerta
alertSource severity alertType metricObjectName examinedBy metricName
name
BMC warning stateful
ADR critical stateless alertAction
Metric clear
info alertMessage
able
fe r
n s
failedMail
a
ALTER ALERTHISTORY ALL examinedBy="<administrator>" nfailedSNMP -t r
n o
a
) h as ฺ beginTime
m ฺbr 0 Guide EndTime
o t
oฺc uden2
1
t i
e Stk notificationState
r t e @ his 3 …
u p o se t
Copyright © 2012,
e
t
o ( ense
i k
e Exadata licStorage Server representam eventos importantes que ocorrem na
Tdo
Os alertas
o
n ic de armazenamento, indicando, em geral, que o funcionamento da célula está
célula
c
e
T comprometido ou há risco de falha. O administrador deve investigar alertas porque podem
exigir ação corretiva ou preventiva urgente. A notificação de alertas de célula por meio
de e-mail ou do SNMP pode ser configurada durante a configuração inicial do Database
Machine. Uma configuração existente poderá ser ajustada ou uma nova configuração
poderá ser estabelecida a qualquer momento com o comando CellCLI ALTER CELL.
Os alertas de célula podem ser stateful ou stateless. Alertas stateful representam estados de
célula observáveis que podem ser testadas novamente em seguida para detectar se o estado
foi alterado, indicando que uma condição de alerta observada anteriormente não representa
mais um problema. Os alertas stateless representam eventos pontuais que não
correspondem a uma condição persistente; eles simplesmente mostram que ocorreu algo.
Alertas podem ter uma das seguintes severidades: warning, critical, clear ou info.
Exemplos de eventos possíveis que disparam alertas são falha no disco físico, erros de
leitura/gravação em disco, temperatura da célula recomendada excedida, falha no software
de célula e latência de entrada/saída excessiva.
Métricas podem ser usadas para indicar alertas stateful usando valores de limite warning ou
critical. Quando o valor de métrica excede o valor limite, um alerta é indicado. Um alerta
com uma severidade clear indica que uma condição crítica ou de advertência anterior
voltou ao normal. Para alertas baseados em limite, um alerta clear é gerado quando o valor
medido excede novamente o valor limite.
Alertas com uma severidade info são stateless e registram condições que podem ser
informativas para um administrador, mas que não exigem nenhuma ação por parte dele.
Alertas informativos não são distribuídos por e-mail nem por notificações SNMP.
O slide ilustra alguns dos atributos de alertas importantes. Cada alerta tem os atributos a
seguir:
• name fornece um identificador para o alerta.
• alertSource fornece a origem do alerta. Algumas origens possíveis estão listadas no

slide.
• severity determina a importância do alerta. Valores possíveis são warning,
critical, clear e info.
• alertType fornece o tipo do alerta. stateful ou stateless. Alertas stateful são
limpos automaticamente na transição para normal. Alertas stateless nunca são limpos,
a menos que você os altere definindo o atributo examinedBy. Esse atributo identifica o
administrador que revisou o alerta e é o único que pode ser modificado pelo le
administrador com o comando ALTER ALERTHISTORY. fe rab
a ns
• metricObjectName é o objeto para o qual um limite de métrica causou um alerta.
tr
n -
no
• metricName fornecerá o nome da métrica se o alerta for baseado em uma métrica.
a
• alertAction é a ação recomendada para esse alerta.
a s
h eฺ
r )
• alertMessage fornece uma breve explicação do alerta.
ฺ Guid
b
m
k o ฺco dent
• failedMail é o destinatário pretendido do e-mail em caso de falha da notificação.
ei Stu
• failedSNMP é o assinante SNMP pretendido em caso de falha da notificação.
t
o r te@ this
• beginTime fornece o timestamp quando um alerta altera seu estado.
ฺ s up use
• endTime fornece o timestamp do final do período quando o alerta altera seu estado.
( t ec se to
• notificationState indica o andamento da notificação dos assinantes de
e i ko licen
mensagens de alerta:
o T
- 0: nenhuma tentativa
ic
Tecn - 1: enviado com êxito
- 2: tentando (até cinco vezes)
- 3: cinco tentativas com falha
Observação: alguns erros de entrada/saída podem fazer com que um disco ASM fique
off-line sem gerar um alerta de célula. Você deve continuar a executar o monitoramento de
entrada/saída a partir dos seus bancos de dados e ambientes ASM para identificar e corrigir
esses tipos de problemas.

Monitorando Alertas de Célula e
Criando Limites: Exemplos
CellCLI> LIST ALERTDEFINITION ATTRIBUTES name, metricName, description

ADRAlert "CELL Incident Error"
HardwareAlert "Hardware Alert"
StatefulAlert_CG_IO_RQ_LG CG_IO_RQ_LG "Threshold Based Stateful Alert"
StatefulAlert_CG_IO_RQ_LG_SEC CG_IO_RQ_LG_SEC "Threshold Based …Alert"
StatefulAlert_CG_IO_RQ_SM CG_IO_RQ_SM "Threshold Based Stateful Alert"
...
le
rab
CellCLI> LIST ALERTHISTORY WHERE severity = 'critical' -
AND examinedBy = '' DETAIL
fe
tr a ns
n -
CellCLI> ALTER ALERTHISTORY 1671443814 examinedBy="JFV" no a
a
h - eฺs
CellCLI> CREATE THRESHOLD ct_io_wt_lg_rq.interactive r )
ฺ Gu- id
b
warning=1000, critical=2000, comparison='>',
o ntm
occurrences=2, observation=5 ฺc
k o e
t ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licexemplos de comandos CellCLI que exibem informações de alertas.
Te alguns
O slideomostra
Os c
nicomandos para exibição de alertas são muito similares aos usados para exibir
T e c
informações de métricas:
• Use o comando LIST ALERTDEFINITION para exibir a definição de todos os alertas
que podem ser produzidos na célula. O exemplo no slide exibe o nome do alerta, o
nome da métrica e a descrição. O nome da métrica identifica a métrica na qual o alerta
se baseia. ADRAlert e HardwareAlert não se baseiam em nenhuma métrica. Dessa
forma, não apresentam nomes de métricas.
• Use o comando LIST ALERTHISTORY para exibir o histórico de alertas de uma célula.
O exemplo no slide lista em detalhes todos os alertas críticos não revisados pelo
administrador.
• Use o comando ALTER ALERTHISTORY para atualizar o histórico de alertas da célula.
O exemplo acima mostra como definir o atributo examinedBy como o ID de usuário
do administrador que examinou o alerta. O atributo examinedBy é o único
ALERTHISTORY que pode ser modificado. O exemplo usa o ID de sequência de alerta
para identificar o alerta. alertSequenceID fornece um número de ID de sequência
exclusivo para o alerta. Quando o estado de um alerta é alterado, outra ocorrência do
alerta é criada com o mesmo número de sequência, mas com um timestamp diferente.

• O comando CREATE THRESHOLD cria um limite que especifica as condições para
geração de um alerta de métrica. O exemplo cria um limite para a métrica
CT_IO_WT_LG_RQ associada à categoria INTERACTIVE. Essa métrica especifica
o número médio de milissegundos decorridos até que solicitações de entrada/saída
grandes emitidas pela categoria fossem programadas pelo IORM no último minuto.
Um valor alto indica que a carga de trabalho de entrada/saída dessa categoria está
excedendo a alocação especificada para ela no plano do IORM. O alerta é disparado
por duas medidas consecutivas (occurrences=2) acima dos limites: um segundo para
um alerta de advertência (warning=1000) e dois segundos para um alerta crítico
(critical=2000). O atributo observation é o número de medidas usado para
obtenção da média dos valores medidos.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Isolando Falhas com a
Quarentena do Exadata Storage Server
Quarentena
ioGridDisk ioBytes ioOffset quarantineType quarantineReason name
dbUniqueID cellsrvChecksum
dbUniqueName SQL PLAN clientPID

DISK REGION
ble
planLineID Database crashReason
Cell Offload
SQLID fe r a
remoteHostName
n
creationTime s
n - tra
rpmVersion
n o incidentID
a
comment
ALTER QUARANTINE 109 -
) h as ฺ sqlID
comment = 'Relates to Bug XYZ'
e
ฺbr GuidsqlPlanHashValue
m
LIST QUARANTINE WHERE
k o ฺco- dent
t
sqlid = '5xnjp4cutc1s8' ei Stu DETAIL
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k ic
Além de
o métricas e lalertas, quando falhas prescritas são detectadas no Exadata Storage
T
e c nic um objeto de quarentena é automaticamente criado. Esse recurso permite colocar em
Server,
T quarentena a ação que causou a falha de modo que o problema possa ser evitado no futuro.
Além de reduzir a chance de que ocorram falhas no software do servidor de armazenamento,
a quarentena aumenta a disponibilidade do armazenamento.
Por exemplo, se ocorrer uma falha na célula durante a execução do Smart Scan em uma
instrução SQL, o Exadata Storage Server colocará essa instrução em quarentena.
Posteriormente, quando a mesma instrução SQL ocorrer de novo, a célula não permitirá que
ela use o Smart Scan.
Os seguintes tipos de quarentena automática estão disponíveis:
• SQL PLAN: criado quando ocorre uma falha na célula durante a execução do Smart
Scan em uma instrução SQL. O Plano SQL da instrução SQL é colocado em
quarentena, e o Smart Scan é desativado para esse plano.
• DISK REGION: criado quando ocorre uma falha na célula durante a execução do Smart
Scan em uma região do disco. A região do disco de 1 MB que está sendo varrida é
colocada em quarentena, e o Smart Scan é desativado para essa região.
• Database: criado quando a célula detecta que determinado banco de dados causa
instabilidade. A detecção de instabilidade se baseia no número de Quarentenas do
Plano SQL para um banco de dados. O Smart Scan é desativado para o banco de
dados.
• Cell Offload: criado quando a célula detecta que um recurso de descarga causou
instabilidade. A detecção de instabilidade se baseia no número de Quarentenas de Banco
de Dados em uma célula. O Smart Scan é desativado para todos os banco de dados.
Quando uma quarentena é criada, um alerta é gerado para notificar os administradores sobre o
que foi colocado em quarentena, por que a quarentena foi criada, quando e como ela pode ser
eliminada manualmente e quando ela é eliminada de forma automática. Todas as quarentenas
são removidas automaticamente quando um upgrade ou um patch é aplicado a uma célula.
O mecanismo de quarentena do Exadata Storage Server foi projetado para ser automatizado e
autônomo. Entretanto, há comandos CellCLI disponíveis para manipular as quarentenas de
forma manual.
• Use o comando LIST QUARANTINE para mostrar as quarentenas existentes na célula no
momento.
• Use o comando ALTER QUARANTINE para definir o atributo de comentário. O atributo de
comentário é o único atributo de quarentena que pode ser modificado. le
• Use o comando DROP QUARANTINE para remover manualmente uma quarentena. Em fe rab
geral, uma quarentena poderá ser removida caso se espere que a entidade em
tra ns
n -
quarentena não venha a causar mais problemas. Consulte a mensagem de alerta
no a
associada à quarentena para obter mais detalhes antes de remover manualmente uma
quarentena. a s
h eฺ
r )
ฺ Guid
b
• Use o comando CREATE QUARANTINEpara criar manualmente um objeto de quarentena.
m
k o ฺco dent
A criação manual de quarentenas deve ser feita de forma coordenada com o Oracle
t ei Stu
Support Services. As quarentenas manuais são criadas para isolar de maneira proativa
instruções SQL que normalmente causam problemas. Veja a seguir um exemplo de
criação manual de uma quarentena: o r te@ this
CELLCLI> CREATE ฺ s se quarantineType="SQLID",
up QUARANTINE
u
( t ec se to
sqlid="5xnjp4cutc1s8"
i o
katributos e n
O slide lista os
T e l i c associados ao objeto de quarentena. Observe que o atributo
co forma, os atributos
sqlPLanHashValue
n i só é aplicável quando quarantineType está definido como SQL PLAN.
T
Da
e c mesma de entrada/saída (ioGridDisk, ioBytes e ioOffset) só se
aplicam quando quarantineType está definido como DISK REGION.

Monitorando o Exadata Storage Server
com Solicitações Ativas
Solicitação Ativa
ioGridDisk ioBytes ioOffset ioReason ioType objectNumber id name
parentID asmDiskGroupNumber
requestState asmFileIncarnation
file initialization
sessionID
read
write
asmFileNumber
able
predicate pushing
fe r
sessionSerNumber filtered backup read consumerGroupName
a n s
predicate push read
n r
-t dbName
tablespaceNumber
n o
a
sqlID
) h as instanceNumber
ฺ
b
ฺ Gur i d e
LIST ACTIVEREQUEST -
o m t
fileType
WHERE IoType = 'predicate
k o ฺc pushing'
d e n -
DETAIL i
te Stu
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Te ativalicfornece uma view centralizada no cliente ou no aplicativo de
Uma solicitação
o
e c nic
solicitações de entrada/saída que estão sendo processadas por uma célula atualmente.
T O slide mostra os atributos mais importantes de uma solicitação ativa. É possível ver que
uma solicitação ativa está caracterizada em todos os níveis: instância, banco de dados, ASM
e célula. A maioria dos atributos tem nomes explicativos. Leia a seguir uma breve explicação
de alguns atributos:
• ioReason é o motivo da atividade de entrada/saída, como uma leitura de arquivo de
controle.
• ioType identifica o tipo da solicitação ativa. Valores possíveis estão listados no slide.
• requestState identifica o estado da solicitação ativa. Valores possíveis incluem:
- Accessing Disk - Computing Result
- Network Receive - Network Send
- Queued Extent - Queued for Disk
- Queued for File Initialization - Queued for Filtered Backup Read
- Queued for Network Send - Queued for Predicate Pushing
- Queued for Read - Queued for Write
- Queued in Resource Manager
Use o comando LIST ACTIVEREQUEST para exibir detalhes de solicitações ativas para a
célula. A sintaxe é muito similar à de outros comandos LIST. Você pode especificar quais
atributos exibir ou pode exibi-los usando a cláusula DETAIL. Também é possível filtrar a
saída usando uma cláusula WHERE.
Visão Geral do Monitoramento do Exadata
Storage Server com o Grid Control
• Cada servidor de armazenamento é um alvo separado no Grid Control
– Os servidores de armazenamento podem ser agrupados em um Sistema

• No Grid Control, a maioria das métricas se baseia em métricas de
célula
• Limites adicionais podem ser definidos no Grid Control
• Os alertas gerados na célula são exibidos no Grid Control
• Alertas adicionais podem ser gerados no Grid Control
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Te StoragelicServer é monitorado como um alvo único do Grid Control, que abrange
Um Exadata
o
on
c ic
hardware, o sistema operacional e o software desse servidor. Os Exadata Storage Servers
T e são unidades independentes que são identificadas como alvos separados no Grid Control.
Entretanto, os servidores de armazenamento podem ser agrupados em um Sistema para
facilitar o monitoramento como um grupo.
Em conjunto com o plugin do Exadata Storage Server, o Grid Control utiliza e estende o
sistema de métricas e alertas em cada Exadata Storage Server.
Quando o Grid Control é usado para monitorar servidores de armazenamento, há dois tipos
diferentes de métricas relacionadas: métricas do servidor de armazenamento e do Enterprise
Manager. Na maioria dos casos, há um mapeamento de um para um entre as duas. No
Exadata Storage Server, o Management Server (MS) coleta, calcula e gerencia as métricas
de cada servidor de armazenamento. O plugin do Exadata Storage Server coleta as métricas,
geralmente a partir de todos os servidores de armazenamento do Database Machine, e as
apresenta ao usuário no Grid Control como métricas do Enterprise Manager.
Além dos limites de métrica no nível de célula, com o plugin do Exadata Storage Server
é possível definir limites do Grid Control diferentes para todas as métricas do Exadata
suportadas pelo plugin. Antes da release 11.2.2.3.1 do software do Exadata Storage Server,
os limites de célula só podiam ser definidos em um conjunto limitado de métricas de célula;
portanto, os limites do Grid Control oferecem a oportunidade de gerar automaticamente
alertas com base em uma gama maior de métricas.
Quando métricas equivalentes podem ser definidas no Grid Control ou no nível de célula, a
recomendação geral é definir o limite no nível de célula para que a definição do limite e todos
os alertas associados sejam mantidos na célula.
Todos os alertas do Exadata Storage Server são entregues pelo servidor de armazenamento
ao Grid Control por meio do protocolo SNMP (Simple Network Management Protocol). Há
dois tipos de alertas de servidor fornecidos pelo Exadata Storage Server:
• Para os componentes de hardware monitorados pelo ILOM (Integrated Lights Out

Manager), o ILOM reporta uma condição de falha ou de limite excedido como uma trap
do SNMP, a qual é recebida pelo MS. O MS processa a trap, cria um alerta para o
servidor de armazenamento e envia-o ao Grid Control por meio do SNMP.
• Para os componentes de hardware e software monitorados pelo MS, o MS processa
condição de falha ou de limite excedido, cria um alerta e envia-o ao Grid Control por
meio do SNMP.
Da perspectiva do usuário final, não há diferença entre esses dois tipos de alertas.
r a ble
Uma mensagem de alerta poderá conter uma ação corretiva que precisa ser executada
n s fe para
resolver o alerta. Por exemplo, a área destacada com um círculo na tela do slide
- t r a indica a
ação a ser tomada para o alerta especificado.
n on
a incorreto na parte
A correção para o bug 8814019 deve ser instalada para resolverso texto
Action dos alertas do Exadata Storage Server. ) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
i c oT
Tecn

Monitorando Falhas de Hardware
e o Estado de Sensores
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
CellCLI> list alerthistory t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Storage Server é monitorado pelo ILOM e pelo MS em conjunto.
Tedo Exadata
O hardware
o
ic monitora a disponibilidade e o estado dos sensores usando limites predefinidos
ecn
O ILOM
T para os componentes de hardware do Exadata Storage Server, como placa-mãe do sistema,
processadores, memória, fontes de alimentação, ventoinhas e controladores de interface de
rede. O MS monitora outros componentes de hardware diretamente, como a controladora de
disco, unidades de disco rígido, placas aceleradoras flash e HCA (host channel adapter)
InfiniBand.
Juntos, o ILOM e o MS oferecem ampla funcionalidade de alertas e monitoramento de
hardware. Quando surge um problema, um alerta é gerado automaticamente na célula e
propagado para o Grid Control (se configurado). A tela do slide mostra um exemplo de
notificação de alerta para uma falha de hardware.
Se o Grid Control ou outro gerenciador de SNMP não estiver configurado, os administradores
deverão configurar as células para enviar alertas por e-mail ou verificar periodicamente a
célula usando o comando CellCLI LIST ALERTHISTORY.

Monitorando a Disponibilidade do Exadata
Storage Server
le
fe rab
tra ns
n -
no a
a
h eฺ s
CellCLI> list cell detail r
ฺ Guid
b )
<Output Truncated>
m
cellsrvStatus: running
k o ฺco dent
msStatus:
t i
running
erunning tu
rsStatus:
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c
o Te dalidisponibilidade
O monitoramento do Exadata Storage Server é incorporado no plugin do
i c
ecn
Exadata Storage Server para o Grid Control. As telas do slide mostram exemplos de como o
T Grid Control indica se os servidores de armazenamento estão ou não disponíveis.
Em ambientes que não usam o Grid Control, a disponibilidade do servidor de
armazenamento deve ser verificada confirmando-se a conectividade de rede. Além disso, o
status dos serviços de célula devem ser verificados com o comando CellCLI LIST CELL
DETAIL. A saída referente a uma célula íntegra deve conter o seguinte:
cellsrvStatus: running
msStatus: running
rsStatus: running

Verificando Alertas Não Entregues
• Verifique periodicamente se há alertas não entregues

– Exemplo de CellCLI que verifica uma célula:

CellCLI> list alerthistory where notificationState != 1 and examinedBy = ''
1_1 2011-04-25T12:09:22-07:00 warning "The warning
threshold for the following metric has been crossed. Metric Name :
CL_MEMUT Metric Description : Percentage of total physical memory on the cell
that is currently used Object Name : exa1cel01 Current Value :
51.0 % Threshold Value : 50.0 % "
CellCLI>
able
– Exemplo de dcli que verifica todas as células listadas nons fe r
arquivo cell_group:
n - tra
a no != 1
and examinedBy = \'\'"
) h as ฺ
$ dcli -g cell_group cellcli -e "list alerthistory where notificationState
m ฺ br uide
• Se existirem alertas não entregues,
ฺ co verifique n t G a conectividade
de rede entre a célula e oeagente, o
ik tuadedisponibilidade do agente
e a configuração datecélula
t
@ his S
p r
o se t
u
ฺs Oracletoe/ouusuas empresas afiliadas. Todos os direitos reservados.
t e c
Copyright © 2012,
i k o ( ense
Para que
o lic possa ser usado com segurança para notificações de alerta, os
ToeGrid Control
e c nic devem ser propagados para ele de forma confiável. Embora isso geralmente ocorra,
alertas
T os administradores devem verificar periodicamente se há alertas não entregues.
O comando CellCLI LIST ALERTHISTORY pode ser usado para fazer essa verificação.
O primeiro exemplo do slide mostra como verificar se há alertas que não têm o status de
sucesso (1) e que não foram marcados como examinados pelo administrador. O segundo
exemplo mostra como usar o mesmo comando junto com dcli para verificar um grupo de
células de uma só vez.
Observe que um alerta poderá não ter o estado de sucesso por vários motivos e que a saída
gerada pelo comando de monitoramento no slide não se refere necessariamente a uma falha
ou configuração incorreta de uma célula. Por exemplo, é possível que um alerta não seja
propagado porque o agente não está disponível. Além disso, se a célula estiver configurada
para enviar alertas usando o SNMP ou e-mail, é possível que o alerta mostre um estado de
notificação malsucedida quando um método de entrega for bem-sucedido, mas o outro não.
Por fim, se a comunicação entre um servidor de armazenamento e o agente onde o plugin do
Exadata Storage Server está implantado for interrompida, os alertas processados pelo MS
talvez não sejam entregues ao Grid Control. Lembre-se de que o MS fará cinco tentativas de
entregar o alerta, portanto, se a comunicação for interrompida temporariamente, você poderá
observar um alerta não entregue e, instantes depois, verificar que o mesmo alerta foi
entregue.
Verificando Erros de Entrada/Saída de Disco
• Em cada célula, crie um limite de advertência usando o

seguinte comando CellCLI CREATE THRESHOLD:

CellCLI> create threshold CD_IO_ERRS_MIN comparison='>', warning=0, -
> occurrences=1, observation=1
Threshold CD_IO_ERRS_MIN successfully created
CellCLI> list threshold CD_IO_ERRS_MIN detail

name: CD_IO_ERRS_MIN
comparison: >
observation: 1
le
occurrences:
warning:
1
0.0
fe rab
tra ns
CellCLI>
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic
Te uma ldefinição
O slideomostra recomendada de limite do servidor de armazenamento que
i c
n a verificar se há erros de entrada/saída de disco. Esses erros costumam ser tratados
ajuda
T e c
automaticamente pelo software de célula do Exadata. A definição de limite recomendada faz
com que um alerta seja gerado pela célula quando um erro de entrada/saída é detectado.
Nenhuma ação é necessária para um único alerta de advertência. Entretanto, várias
advertências sobre a mesma unidade podem ser indício de uma futura falha na unidade. Da
mesma maneira, várias advertências sobre todas as unidades de uma única célula podem
indicar uma falha iminente em um controlador ou outro componente.
Se essa advertência for reportada e um alerta crítico também for gerado pelo MS para um
componente de disco, siga a ação especificada nesse alerta.

Verificando Erros de Rede
• Monitore a rede de armazenamento em busca de pacotes

eliminados:
– Usando o Grid Control
— Para as métricas-alvo do servidor de armazenamento:
— Host MB Dropped Per Sec
— Host RDMA MB Dropped Per Sec
Aplique as seguintes definições:
—
le
— Limite de advertência igual a zero
fe rab
— Programação de coleta para repetição a cada 5 minutos
tra ns
Intervalo de upload como 3 coletas n -
no
—
– Diretamente na célula s a
Monitore as Métricas de Interconexão ) de
a
h Host,eespecificamente:
ฺ
—
b
ฺ Gur i d
— N_MB_DROP_SEC
o m t
N_MB_RDMA_DROP_SECoฺc e n
—
t k
ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
e armazenamento
Uma rede
o Tde funcional é essencial para a integridade e o desempenho
i c
n do Exadata Database Machine. Com frequência, a perda de funcionalidade é indicada
gerais
T e c
pelo volume de tráfego de rede eliminado. Normalmente, esse tráfego é automaticamente
tratado no Database Machine, portanto, pacotes eliminados ocasionalmente não são motivo
de preocupação. Entretanto, um grande número de pacotes eliminados para uma única
célula pode ser indício de um futuro problema.
Para manter o controle dessas situações, é recomendável definir no Grid Control limites
para as métricas Host MB Dropped Per Sec e Host RDMA MB Dropped Per Sec, conforme
descrito no slide. Observe que as definições devem ser aplicadas a cada alvo do servidor de
armazenamento.
O monitoramento periódico das métricas de célula N_MB_DROP_SEC e
N_MB_RDMA_DROP_SEC é aconselhável em ambientes que não usam o Grid Control. O uso
de limites e alertas para monitorar essas métricas no nível de célula pode ser adotado, em
vez de definir limites do Grid Control usando o software do Exadata Storage Server release
11.2.2.3.1 e posterior.

Monitorando o Espaço Livre
do Sistema de Arquivos
• O espaço livre do sistema de arquivos nos Exadata
Storage Servers é monitorado automaticamente pelo MS:

– Nenhuma ação direta do administrador é necessária
– O MS gerará um alerta se houver pouco espaço livre
– O MS recuperará automaticamente o espaço usado
expurgando arquivos de log, arquivos de rastreamento e
dumps de falha antigos, além de outros arquivos le
desnecessários fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Storage Server monitora automaticamente a utilização do sistema de
Tedo Exadata
O software
o
ic em cada servidor de armazenamento. Não é necessário definir um limite de métrica
ecn
arquivos
T para a utilização do sistema de arquivos na célula ou no Grid Control. O MS monitora o
espaço livre desse sistema, gera alertas críticos quando há pouco espaço livre e toma
uma ação corretiva para liberar o espaço usado. Para obter informações mais detalhadas,
consulte a seção Understanding Automated Cell Maintenance do Oracle Exadata Storage
Server Software User's Guide 11g Release 2 (11.2).

Comparando Métricas entre
Vários Servidores de Armazenamento
• Compare a utilização de recursos entre vários servidores de
armazenamento usando observações de métricas de célula e

relatórios em nível de realm no Grid Control
• Desequilíbrios acentuados podem indicar um problema
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic os dados são distribuídos em um Database Machine depende de
A maneira
o Te exata como
ic fatores, incluindo o número de aplicações e bancos de dados consolidados no
ecn
vários
T ambiente, além de como o armazenamento está configurado para atender aos requisitos
de desempenho, disponibilidade, segurança entre outros.
Entretanto, em termos gerais, o trabalho realizado pelos servidores de armazenamento para
atender às solicitações de banco de dados deve ser distribuído de maneira uniforme entre
vários servidores. Um desequilíbrio acentuado na utilização de recursos ou no desempenho
de entrada/saída de um servidor de armazenamento em relação aos demais deverá ser
motivo de maior investigação.
Várias métricas de CPU, memória e utilização de entrada/saída podem ser comparadas
periodicamente entre os servidores de armazenamento para garantir que não haja
desequilíbrios indevidos. Os usuários do Grid Control podem utilizar os diversos relatórios em
nível de realm para realizar comparações de forma rápida e fácil em um grupo de servidores
de armazenamento. A tela do slide mostra um exemplo do relatório de desempenho em nível
de realm que permite uma comparação de alto nível muito útil de métricas-chave em um real
de servidores de armazenamento.

Monitorando Métricas em um Servidor de
Armazenamento
• Não há limites de métrica default para utilização de CPU,
memória ou entrada/saída
• 100% de utilização poderá ser normal em certos casos
• As observações de métricas são úteis e relevantes quando
comparadas às linhas de base capturadas anteriormente
• Metodologia sugerida:
1. Determine as métricas-chave com base nos requisitos de
aplicações e serviços r a ble
2. Registre as observações de métricas de linha de base n s fe
considerando o uso normal e de pico do sistema n - tra
o
3. Implemente limites a fim de gerar alertas para s an
observações fora
das faixas esperadas a
) h eฺ ฺbr Guid
Limites de advertência para indicar observações ligeiramente anormais
m
ฺco dent
—
o
Limites críticos para indicar situações que podem afetar os níveis de
k
ei Stu
—
serviço t
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic foi projetado como um subsistema de armazenamento
TeStorage lServer
O Exadata
o
ic
ecn
balanceado. Como resultado, os valores de métricas de CPU, memória e entrada/saída do
T Exadata Storage Server poderão ser mais altos do que os observados em um servidor de
finalidade geral ou de banco de dados típico; no entanto, eles ainda estarão dentro da faixa
operacional adequada.
Por exemplo, a CPU poderá ser 100% utilizada durante a execução de consultas de dados
com a EHCC (Exadata Hybrid Columnar Compression). Nesse caso, 100% de utilização da
CPU não representa um problema e nenhum alerta deve ser gerado.
As observações de métricas de uso de recursos em um servidor de armazenamento só serão
úteis e relevantes se forem comparadas com os valores capturados durante o período de
operação normal. O slide descreve uma metodologia sugerida para determinar métricas
importantes e implementar limites com base em observações registradas anteriormente.

Ferramentas de Monitoramento de Terceiros
• A instalação de software adicional, incluindo qualquer

agente de monitoramento de terceiros, não é suportada no

Exadata Storage Server
• O Exadata Storage Server pode ser configurado para
enviar alertas a qualquer assinante SNMP
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic adicional, incluindo agentes de monitoramento de terceiros, não é
Te de software
A instalação
o
ic no Exadata Storage Server.
ecn
permitida
T É possível configurar o Exadata Storage Server para enviar alertas a consoles de
gerenciamento de terceiros por meio do SNMP.

Questionário
Ao usar o Grid Control para monitorar Exadata Storage

Servers, onde devem ser definidos limites?

a. Somente no Grid Control
b. Somente na célula do Exadata
c. Se possível, na célula do Exadata, caso contrário, no Grid
Control
d. Tanto no Grid Control como na célula do Exadata r a ble
e s f
tra n
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tce
e c nic métricas equivalentes podem ser definidas no Grid Control ou no nível de célula, a
Quando
T recomendação geral é definir o limite no nível de célula para que a definição do limite e todos
os alertas associados sejam mantidos na célula.

Questionário
Supondo que o plugin do Exadata Storage Server esteja

configurado corretamente, quais das seguintes situações

poderão ocorrer?
a. A observação de uma métrica gera um alerta na célula,
mas nenhum alerta é visto no Grid Control
b. A observação de uma métrica gera um alerta na célula e
um alerta é visto no Grid Control
r a ble
c. A observação de uma métrica não gera qualquer alerta n s
defe
a
célula, mas um alerta é visto no Grid Control on-tr
a n
d. A observação de uma métrica resulta em a s alertas no
dois
h ฺ
Grid Control br) ide m ฺ Gu
o
ฺc dent
k o
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Resposta:
o Ta,e b, c, dlic
An
c ic
observação de uma métrica gera um alerta na célula, mas nenhum alerta é visto no Grid
T e Control: isso poderá ocorrer quando um limite baseado em célula dispara um alerta de célula,
mas ele não é propagado para o Grid Control por causa de um problema de comunicação na
rede.
A observação de uma métrica gera um alerta na célula, e um alerta é visto no Grid Control:
este é o comportamento normal e esperado. Ele ocorre quando um limite baseado em célula
dispara um alerta, e o alerta é propagado para o Grid Control.
A observação de uma métrica não gera qualquer alerta de célula, mas um alerta é visto no
Grid Control: isso ocorre quando um limite definido no Grid Control dispara um alerta e não
há um limite no nível de célula para a métrica ou esse limite é definido como um valor que
não dispara um alerta na célula.
A observação de uma métrica resulta em dois alertas no Grid Control: isso ocorre quando
são definidos um limite no nível de célula e um limite do Grid Control para a mesma métrica,
e o alerta correspondente no nível de célula é propagado para o Grid Control.

Resumo

• Descrever as métricas, os alertas e as solicitações ativas

do Exadata Storage Server
• Identificar as áreas de foco recomendadas para o
• Descrever como monitorar as áreas de foco
le
recomendadas do Exadata Storage Server
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
– Monitorando Exadata Storage Servers com o Enterprise

Manager Grid Control e o Plugin de Monitoramento do
Sistema para o Exadata Storage Server
– Gerenciando Alertas do Exadata Storage Server e
Verificando Se Há Alertas Não Entregues
– Monitoramento e Gerenciamento do Exadata Storage Server
Usando o ILOM (Integrated Lights Out Manager) r a ble
e s f
tra n
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral do Exercício 15:
Monitorando o Exadata Storage Server
Neste exercício, você monitorará o Exadata Storage Server
usando métricas, alertas e solicitações ativas.
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Tecn
ic
oT e i
( t
ฺ s
ko licen
o r
ec se to
t
up use
k o
te@ this
ei Stu
m b r )
ฺco dent
a s
ฺ Guid
a
h eฺ
no n - tr
a
ns fe rab
le
Monitorando Servidores de Banco de Dados

do Exadata Database Machine
le
fe rab
tr a ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
ec se to
Copyright © 2012, Oracle e/ou suas empresas afiliadas. Todos os direitos reservados.
( t
e i ko licen
o T
ic
Tecn
Objetivos

recomendações para o monitoramento de servidores de banco
de dados do Exadata Database Machine.
le
fe rab
tr a ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
ec se to
( t
e i ko licen
o T
ic
Tecn

Visão Geral do Monitoramento de Servidores
de Banco de Dados
• Essencialmente, o monitoramento de um servidor de

banco de dados do Exadata Database Machine é igual ao
de qualquer servidor do Oracle Database clusterizado
– Os conhecimentos e as práticas atuais podem ser
transferidos imediatamente
• A lição aborda as diferenças e as recomendações
específicas do Database Machine com ênfase no uso do
r a ble
Grid Control
n s fe
• As áreas consideradas nesta lição compreendem: n-tra
– Monitoramento do hardware n o
s a
– Monitoramento do Sistema Operacionalha ฺ
b r
ฺ Gu ) i d e
– Monitoramento do Oracle Grid Infrastructure
m
– Monitoramento do Oracle o
o
ฺc dent
Database
k
tei Management
– Monitoramento do Oracle Stu Agent
o r te@ this
ฺ s up use
ec se to
( t
e i ko ldos i c e n
o T
O monitoramento servidores de banco de dados do Exadata Database Machine é
nic
essencialmente igual ao de qualquer outro servidor do Oracle Database clusterizado.
Tec Portanto, os conhecimentos e as práticas já usados pelos Administradores do Oracle
Database podem ser imediatamente transferidos para um ambiente do Database Machine.
Há algumas diferenças e recomendações específicas associadas ao Exadata Database
Machine e ao Grid Control, as quais são o foco desta lição.

Monitorando o Hardware
le
fe rab
tr a ns
n -
a no
a
h eฺs
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
ec se to
( t
e i ko licLights
e n
o Tlimites predefinidosOut
O ILOM (Integrated Manager) monitora a disponibilidade e o estado dos sensores
c como a placa-mãe do sistema,
usando
nidados,
para os componentes de hardware dos servidores de banco de
Tec
processadores, memória, fontes de alimentação,
ventoinhas e controladoras de interface de rede. A disponibilidade e o estado dos sensores
podem ser monitorados no Grid Control com o plugin do ILOM. As seguintes recomendações
se aplicam:
• Não há limites específicos do Exadata a serem definidos para o monitoramento do
hardware dos servidores de banco de dados. As condições de falha e as definições
de limites dos componentes monitorados pelo ILOM são predefinidas no ILOM e são
suficientes para o nível necessário de monitoramento.
• Para exibir as leituras atuais dos sensores, efetue login na Console do Grid Control e
navegue até All Metrics a partir da home page do plugin. Para exibir o status atual dos
componentes, incluindo dos que têm o status Faulted, expanda a seção Sensor Alert
em All Metrics e verifique as métricas de cada sensor. Os componentes com o status
Faulted gerarão um alerta. Todos os alertas ativos ficarão visíveis na home page do
alvo do ILOM.
• Os alertas gerados pelo ILOM em um servidor de banco de dados podem ser exibidos
por meio do Grid Control da mesma forma que os alertas gerados por qualquer outro
alvo do Grid Control.
• Para exibir o histórico de alertas gerados pelo ILOM, navegue até a home page do alvo,
expanda a seção Sensor Alert em All Metrics e verifique as observações sobre cada
sensor. Um histórico do estado de cada sensor está disponível por um período de até
31 dias.
Monitorando o Sistema Operacional
• O monitoramento do sistema operacional é incorporado no

Grid Control com o uso do tipo de alvo Host:
– Não há requisitos de configuração específicos do Exadata
para monitoramento geral
– Os limites podem ser definidos ou alterados de acordo com
os requisitos específicos do local
– Lembre-se de monitorar a atividade de entrada/saída de r a ble
disco nos servidores de armazenamento e não nos n s fe
servidores de banco de dados n - tra
no pelo
– Alertas essenciais do sistema operacional sãoagerados
has default
Grid Control com base nos limites de métricas ฺr) uide
ฺ b
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
up use
ฺ s
ec se to
( t
e i ko licedo n
o T
O sistema operacional servidor de banco de dados é exibido no Grid Control como um
nic
alvo do tipo Host. As seguintes recomendações se aplicam:
Tec • Não há requisitos de configuração específicos do Exadata. As métricas e os limites
default fornecidos pelo Grid Control são suficientes para monitoramento geral.
• Os limites podem ser definidos ou alterados na página Metric and Policy Settings
do Grid Control para tratar dos requisitos específicos do local.
• Lembre-se de que entrada/saída relativa aos arquivos de dados do Oracle Database é
direcionada para os Exadata Storage Servers por meio da rede InfiniBand. Portanto, as
métricas dos servidores de banco de dados relacionadas à atividade de entrada/saída
de disco não podem ser usadas para monitorar os arquivos de dados do Oracle. A
entrada/saída relacionada a esses arquivos deve ser monitorada nos Exadata Storage
Servers.
• Alertas sobre o sistema operacional do servidor de banco de dados são gerados
automaticamente pelo Grid Control com base nos limites de métricas default do
alvo Host.

Monitorando o Oracle Grid Infrastructure
• O monitoramento do Grid Infrastructure é incorporado no Grid

Control com o uso dos tipos de alvo ASM, Listener e Cluster:
– Não há requisitos de configuração específicos do Exadata para
monitoramento geral
– Os limites podem ser definidos ou alterados de acordo com os
requisitos específicos do local
– Alertas essenciais são gerados pelo Grid Control com base nos
le
limites de métricas default
fe rab
• O monitoramento do arquivo de log do ASM para detectar ns
problemas de conectividade de células não é fornecido-tpelo
n ra
Grid Control
a no
– Verifique se o arquivo de log de alertas do ASM
) h as contém
ฺ
mensagens como a seguinte:
b r
ฺ Gu i d e
o m t
connect: ossnet: connection failed
k o ฺc dto e nserver <ipaddr>,
result=5 (login: sosstcpreadtry
t ei Stu failed)
o r te@ this
ฺ s up use
ec se to
( t
e i ko (Automatic
l i c e n
o T
O Oracle ASM Storage Management), o listener e o clusterware são exibidos no
c ic
Grid Control como alvos
nrecomendações se aplicam: ASM, Listener e Cluster, respectivamente. As seguintes
T e
• Não há requisitos de configuração específicos do Exadata. As métricas e os limites
• Os limites podem ser definidos ou alterados na página Metric and Policy Settings do
Grid Control para tratar dos requisitos específicos do local. Por exemplo, os limites
são geralmente configurados para fornecer uma advertência quando a quantidade de
espaço livre em um grupo de discos (USABLE_FREE_MB) fica abaixo da necessária
para manter a redundância em caso de perda de um grupo com falha
(REQUIRED_MIRROR_FREE_MB).
• O Grid Control gera automaticamente alertas com base nos limites de métricas default
dos alvos ASM, Listener e Cluster.
• O monitoramento do arquivo de log de alertas do ASM para detectar problemas de
conectividade de células não está integrado ao Grid Control no momento. Verifique
se esse arquivo contém mensagens como as do exemplo mostrado no slide. Essa
verificação deve ser executada a cada cinco minutos.

Monitorando o Oracle Database
• O monitoramento dos bancos de dados Oracle é incorporado no

Grid Control com o uso dos tipos de alvo Banco de Dados
Clusterizado e Instância do Banco de Dados:
– Não há requisitos de configuração específicos do Exadata para
monitoramento geral
– Os limites podem ser definidos ou alterados de acordo com os
requisitos específicos do local
– Alertas essenciais são gerados pelo Grid Control com base nos le
limites de métricas default fe rab
•
tranão
O monitoramento do arquivo de log da instância do banco de ns
n -
dados para detectar problemas de conectividade de células
o
é fornecido pelo Grid Control an
h as ฺ
– Verifique se o arquivo de log de alertas contém mensagens como a
)
seguinte:
m ฺbr Guide
connect: ossnet: connection o
k ฺco dto
failed
e t
nserver <ipaddr>,
result=5 (login: sosstcpreadtry i
te Stu failed)
r @
te this
o
up use
ฺ s
ec se to
( t
e i kdeodados
l i c e n
o T
Os bancos Oracle são exibidos no Grid Control como os tipos de alvo Banco de
c ic
Dados Clusterizado
naplicam: e Instância do Banco de Dados. As seguintes recomendações se
T e
• Não há requisitos de configuração específicos do Exadata. As métricas e os limites
Grid Control para tratar dos requisitos específicos do local.
• O Grid Control gera automaticamente alertas com base nos limites de métricas default
dos alvos Banco de Dados Clusterizado e Instância do Banco de Dados.
• O monitoramento do arquivo de log de alertas da instância do banco de dados para
detectar problemas de conectividade de células não está integrado ao Grid Control no
momento. Verifique se esse arquivo contém mensagens como as do exemplo mostrado
no slide. Essa verificação deve ser executada a cada cinco minutos.

Monitorando o Oracle Management Agent
• O monitoramento do Oracle Management Agent é

incorporado no Grid Control com o uso do tipo de alvo
Agent
– Não há requisitos de configuração específicos do Exadata
para monitoramento geral
– Os limites podem ser definidos ou alterados de acordo com
os requisitos específicos do local r a ble
– Alertas essenciais são gerados pelo Grid Control com base n s fe
a
nos limites de métricas default
n n-tr o
• Lembre-se de que a disponibilidade do agente a é
particularmente importante no caso do ) h as que
agente ฺ
b r i d e
mฺ Gu
hospeda os plugins de monitoramento
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
ec se to
( t
e i ko licenAgents são exibidos no Grid Control como alvos do tipo agente.
T
Os Oracle Management
c niAscoseguintes recomendações se aplicam:

T e • Não há requisitos de configuração específicos do Exadata. As métricas e os limites
Grid Control para tratar dos requisitos específicos do local.
• O Grid Control gera automaticamente alertas com base nos limites de métricas default.
Por default, o Grid Control gerará um alerta se um agente estiver desativado ou se
perder contato com o servidor de gerenciamento.
• Lembre-se sempre de qual agente está hospedando os plugins de monitoramento
porque a capacidade de monitorar vários componentes do Database Machine depende
da disponibilidade contínua desse agente.

Questionário
Os Administradores do Oracle Database precisam passar por

uma ampla reciclagem a fim de monitorar e manter os bancos
de dados Oracle no Exadata Database Machine:
a. VERDADEIRO
b. FALSO
le
fe rab
tr a ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
ec se to
( t
e i ko licen
i c oT
Resposta: b
Tecn

Resumo

recomendações para o monitoramento de servidores de banco
de dados do Exadata Database Machine.
le
fe rab
tr a ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
ec se to
( t
e i ko licen
o T
ic
Tecn

Monitorando a Rede InfiniBand
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos
Após concluir esta lição, você será capaz de descrever e

executar os comandos para monitorar a rede InfiniBand do

le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral do Monitoramento da Rede InfiniBand
Servidor de Servidor de Servidor de Servidor de

Banco de Banco de Banco de Banco de
Dados 1 Dados 2 Dados 3 Dados n

Porta 1 Porta 2 Porta 1 Porta 2 Porta 1 Porta 2 ... Porta 1 Porta 2
InfiniBand InfiniBand InfiniBand InfiniBand
le
fe rab
tr ans
n -
no
a
a
h eฺ s
Porta 1 Porta 2
InfiniBand
Porta 1 Porta 2
InfiniBand b
Porta 1 Porta 2
InfiniBand
r
ฺ Guid) Porta 1 Porta 2
InfiniBand
m
Servidor de Servidor de
Armazenamento Armazenamento
k o ฺco ddeent Armazenamento
Servidor
Armazenamento
Servidor de
1 2 t ei St3u ... n
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
c a rede de comunicação InfiniBand contida no Exadata Database
Tedo slideliilustra
O diagrama
ic o
ecn
Machine.
T Cada Database Machine contém pelo menos dois InfiniBand Switches que conectam os
servidores de banco de dados e de armazenamento. Eles são chamados leaf switches.
Um terceiro switch, chamado spine switch, conecta-se aos dois leaf switches nos Database
Machines Half Rack e Full Rack. O spine switch facilita a conexão de vários racks para
formar um único ambiente maior do Database Machine.
Cada servidor contém pelo menos um par de portas InfiniBand acopladas por meio do
acoplamento ativo/passivo. As conexões ativas e passivas são distribuídas entre os dois leaf
switches para fins de balanceamento de carga. Além disso, os leaf switches contidos em um
rack estão conectados entre si. O resultado é uma topologia de rede de arquitetura comutada
(switched fabric) do tipo Fat-Tree.
O monitoramento da rede InfiniBand é dividido em três áreas principais:
• Monitoramento de InfiniBand switches
• Monitoramento de portas InfiniBand
• Monitoramento do InfiniBand fabric
O restante desta lição aborda essas três áreas.

Monitorando Manualmente os InfiniBand Switches
• O monitoramento dos InfiniBand Switches verifica se há

falhas de hardware no switch e sensores que ultrapassam

os limites predefinidos
• O monitoramento manual é necessário para os switches
que executam uma versão de software anterior à 1.1.3
– Exemplo de saída esperada:
# ssh root@dm01sw-ib2
le
root@dm01sw-ib2’s password:
fe rab
[root@dm01sw-ib2 ~]# showunhealthy
tr a ns
OK - No unhealthy sensors
n -
[root@dm01sw-ib2 ~]# checkpower
no a
PSU 0 present status: OK
a
h eฺ s
PSU 1 present status: OK
r
ฺ Guid
b )
– As verificações devem ser executadas m
co ent a cada intervalo de
o ฺ
60 a 120 segundos
t e ik tud
– Use env_test para e @ coletari s Smais informações se necessário
r t
o se t h
u p
Copyright © 2012,
e
t
o ( ense
i k licInfiniBand switches fornecidos com o Oracle Exadata Database
Te dos
O monitoramento
o
ic envolve a verificação de falhas nos componentes de hardware, bem como de
ecn
Machine
T sensores que ultrapassam os limites predefinidos no switch.
Os InfiniBand switches que executam as versões de software anteriores à 1.1.3 não
oferecem suporte a SNMP. Nesses switches, o monitoramento pode ser executado por meio
do login no switch como o usuário root e da execução dos comandos showunhealthy
e checkpower. O slide mostra um exemplo. É recomendável que as verificações sejam
executadas a cada intervalo de 60 a 120 segundos. Na prática, isso significa criar um script
para executar a verificação e usar um recurso automatizado (como o UDM (User Defined
Metrics) no Grid Control) para executá-lo repetidamente.
Observe que showunhealthy não indicará que há sensores não íntegros mesmo se uma
fonte de alimentação estiver off-line; portanto, eles devem ser verificados separadamente.
Se showunhealthy ou checkpower indicar quaisquer problemas, execute o comando
env_test para obter informações de status mais detalhadas sobre todos os sensores do
switch.

Monitorando os InfiniBand Switches
com o Grid Control
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic o software do InfiniBand switch oferece suporte a SNMP. Além
A partir
o Teversão 1.1.3,
da
ic o plugin do InfiniBand Switch pode ser usado para monitorar o status do switch no
ecn
disso,
T Grid Control. A tela contida no slide mostra a home page do InfiniBand.
O monitoramento dos InfiniBand switches com o Grid Control consiste apenas em verificar
se os switches estão ativos e tratar dos alertas gerados. Quando são gerados alertas, os
comandos manuais mostrados na página anterior podem ser usados para coletar
informações adicionais.
Observe que é possível fazer upgrade dos switches com versões de software anteriores
à 1.1.3 para as versões atuais, entretanto, esse upgrade também poderá exigir upgrades
associados para outros componentes do Database Machine. Consulte o My Oracle Support
bulletin 888828.1 para obter informações detalhadas de compatibilidade de versões
relacionadas ao Exadata Database Machine.

Monitorando as Portas dos InfiniBand Switches
• Verifique se há erros nas portas dos switches com o

seguinte comando:
# ibqueryerrors.pl –s RcvSwRelayErrors,RcvRemotePhysErrors,XmtDiscards,
XmtConstraintErrors,RcvConstraintErrors,ExcBufOverrunErrors,VL15Dropped
– Compare a saída com os resultados anteriores

— SymbolErrors ou RcvErrors ou LinkIntegrityErrors
não deve aumentar sem que LinkDowned aumente
able
– A verificação pode ser executada em qualquer servidor de fe r
a n s
banco de dados ou InfiniBand switch
n -t r
– A verificação deve ser executada a cada intervalo
o
n de 60 a
a
120 segundos
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licportas InfiniBand é necessário para verificar a integridade das portas
Te das
O monitoramento
o
ic interfaces de rede InfiniBand. O procedimento recomendado é executar manualmente
ecn
e das
T o comando ibqueryerrors.pl conforme mostrado no slide.
Uma única chamada do comando ibqueryerrors.pl mostrado no slide pode ser usada
para reportar erros de portas em todos os InfiniBand switches. A saída do comando deve
ser comparada com a saída coletada anteriormente. Quando tudo está funcionando
corretamente, as contagens de SymbolErrors ou RcvErrors ou LinkIntegrityErrors
não devem aumentar sem que LinkDowned aumente. A verificação pode ser executada em
qualquer servidor de banco de dados ou InfiniBand switch. É recomendável que a verificação
seja executada a cada intervalo de 60 a 120 segundos.

Monitorando as Portas InfiniBand
nos Servidores do Database Machine
• O monitoramento das portas InfiniBand é executado
automaticamente nos Exadata Storage Servers

• Monitore manualmente as portas dos servidores de banco
de dados com os seguintes comandos:
# ibstatus
# perfquery
# ifconfig
le
# ping <Remote InfiniBand Hostname>
fe rab
# rds-ping <Remote InfiniBand Hostname>
ns tra
n -
– O monitoramento automático com o Grid Control
a nopode ser
executado por meio de scripts UDM (User
) h asDefined ฺ Metric)
disponíveis em My Oracle Supportฺbnote
m
r 1110675.1
u ide
o ฺ co ent G
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licportas InfiniBand nos servidores de armazenamento é executado pelo
Te das
O monitoramento
o
nicNenhum
MS.
ecporta
monitoramento adicional da InfiniBand é necessário nesses servidores. Se uma
InfiniBand não estiver funcionando corretamente, o MS criará um alerta e o enviará ao
T Grid Control. As mensagens de alerta normalmente contêm a ação corretiva a ser executada
para resolvê-lo.
Os servidores de banco de dados não contam com monitoramento incorporado de rede
InfiniBand. A lista a seguir descreve as verificações recomendadas para cada servidor de
banco de dados. Execute as verificações a cada intervalo de 60 a 120 segundos.
• ibstatus: verifica se cada porta mostra a seguinte saída:
state: 4: ACTIVE
phys state 5: LinkUp
rate: 40 Gb/sec (4X QDR)
• perfquery: compara a saída com os resultados coletados anteriormente.
SymbolErrors ou RcvErrors ou LinkIntegrityErrors não deve aumentar sem
que LinkDowned aumente
• ifconfig: verifica se as interfaces InfiniBand (bondib0, ib0 e ib1) estão ativadas
(UP).
• ping e rds-ping: verifica a conectividade com todos os servidores de banco de
dados e de armazenamento na rede InfiniBand.
As verificações listadas anteriormente podem ser automatizadas no Grid Control por meio de
scripts UDM (User Defined Metric) que estão disponíveis em My Oracle Support note
1110675.1.
Monitorando o InfiniBand Fabric:
Local do Mestre do Subnet Manager
• As seguintes verificações são recomendadas uma vez por dia:
– Verifique se o mestre do Subnet Manager (SM) InfiniBand está

localizado em um dos InfiniBand switches
— Exemplo:
# sminfo
sminfo: sm lid 1 sm guid 0x21283a8516a0a0, activity count 933330
priority 5 state 3 SMINFO_MASTER
le
rab
# ibswitches
Switch : 0x0021283a8516a0a0 ports 36 "Sun DCS 36 QDR switch dm01sw-ib1"
fe
enhanced port 0 lid 1 lmc 0
tr a ns
Switch : 0x0021283a8983a0a0 ports 36 "Sun DCS 36 QDR switch dm01sw-ib2"
n -
enhanced port 0 lid 4 lmc 0 no a
Switch : 0x0021283a89bda0a0 ports 36 "Sun DCS 36 QDR switch dm01sw-ib3"
a
h eฺ s
enhanced port 0 lid 3 lmc 0
r
ฺ Guid
b )
– Para redes que contêm spineฺc m
o nt verifique se o mestre do
switches,
o de switch
SM está sendo executado
t eikemSum t uspine
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te é recomendável
Diariamente, verificar se o mestre do SM (Subnet Manager) está localizado
em i c
n um dos InfiniBand switches. Em um dos servidores de banco de dados ou InfiniBand
T e c
switches, execute os comandos sminfo e ibswitches, conforme mostrado no slide.
Determine o nome de host referente ao local do mestre do SM comparando o guid reportado
por sminfo com a saída de ibswitches. Opcionalmente, o comando getmaster pode ser
usado; entretanto, observe que getmaster só está disponível nos InfiniBand switches, e
não nos servidores de banco de dados.
Em um ambiente do Database Machine Half Rack, Full Rack ou com vários racks, o mestre
do SM deve ser executado em um spine switch, o qual é um switch que tem apenas outros
switches conectados a ele. O comando a seguir identifica os spine switches.
ibnetdiscover -p | awk ‘
/^SW +[0-9]+ +[0-9]+ +0x[0-9\
a-e]+ +[0-9]+x .DR - [SW|CA].*/ {
if (spine[$4]==””) spine[$4]=”yes”
if ($8 == “CA”) spine[$4]=”no”
}
END {
for (val in spine)
if (spine[val]==”yes”)
print val
}
‘
Monitorando o InfiniBand Fabric:
Topologia da Rede e Status dos Links
• Use verify-topology para verificar o InfiniBand fabric
– Exemplo de saída esperada:

# /opt/oracle.SupportTools/ibdiagtools/verify-topology
[ DB Machine Infiniband Cabling Topology Verification Tool ]

[Version 11.2.1.3.b]
Looking at 1 rack(s).....
le
rab
Spine switch check: Are any Exadata nodes connected ..............[SUCCESS]
Spine switch check: Any inter spine switch connections............[SUCCESS]
fe
Spine switch check: Correct number of spine-leaf links............[SUCCESS]
tra ns
n
Leaf switch check: Inter-leaf link check..........................[SUCCESS]-
no
Leaf switch check: Correct number of leaf-spine connections.......[SUCCESS]
a
Check if all hosts have 2 CAs to different switches...............[SUCCESS]
a
h eฺ
Leaf switch check: cardinality and even distribution..............[SUCCESS]
s
r )
ฺ Guido status dos
b
• Use iblinkinfo.pl –Rl para m monitorar
links k o ฺco dent
t ei Stu
– Compare a saída
r @ ahcoletada
tecom is anteriormente
o
p use t
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
Além de
o T e lic do SM, é recomendável monitorar a topologia da rede InfiniBand,
verificar o mestre
e c niccomo o estado de todos os seus links.

bem
T Uma vez por dia, é recomendável executar o comando verify-topology em um dos
servidores de banco de dados do Database Machine. Esse comando realiza vários testes
no nível de topologia para verificar se os links esperados da rede de armazenamento estão
cabeados corretamente. Um exemplo da saída esperada do comando verify-topology
é mostrado no slide.
Para verificar o estado de todos os links da rede InfiniBand, execute o comando a seguir
como root em um dos servidores de banco de dados do Database Machine:
# iblinkinfo.pl –Rl
Compare a saída resultante com a coletada anteriormente quando a rede InfiniBand
estava reconhecidamente em boas condições. É recomendável executar essa verificação
frequentemente (a cada intervalo de 1 a 5 minutos).

Questionário
Qual das seguintes afirmações é verdadeira?

a. Por default, o monitoramento das portas InfiniBand é

executado automaticamente pelo MS nos Exadata Storage
Servers
b. Por default, o monitoramento das portas InfiniBand nos
servidores de banco de dados é executado pelo Grid
e
Control por meio de UDMs (User Defined Metrics) abl fe r
a n s
n - tr
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tae
c
niUDMs
T e c
Os (User Defined Metrics) podem ser usados para monitorar as portas InfiniBand
nos servidores de banco de dados, no entanto, eles não são fornecidos no Grid Control,
por default. Os UDMs devem ser definidos para cada servidor de banco de dados.

Resumo
Nesta esta lição, você aprendeu a descrever e executar os

comandos para monitorar a rede InfiniBand do Exadata

Database Machine.
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
• Demonstração da Lição
– Monitorando a rede InfiniBand do Database Machine

– Oracle Database Machine Monitoring Best Practices
– Database Machine and Exadata Storage Server 11g Release 2
(11.2) Supported Versions
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Monitorando Outros Componentes do

le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos
Após concluir esta lição, você será capaz de monitorar os

seguintes componentes adicionais do Exadata Database

Machine:
• Cisco Catalyst Ethernet Switch
• Sun PDUs (Power Distribution Units)
• Avocent MergePoint Unity KVM Switch
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Monitorando o Cisco Catalyst Ethernet Switch
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic switch não se encontra no caminho de dados crítico. Ele não
O Ciscoo Te Ethernet
Catalyst
ic da conexão dos clientes da aplicação com o banco de dados nem da conexão dos
ecn
participa
T servidores de banco de dados com os servidores de armazenamento. Entretanto, o tráfego
de monitoramento e administrativo depende da disponibilidade do Cisco switch.
O principal objetivo do monitoramento do Cisco switch é identificar falhas nos componentes
de hardware e condições ambientais que possam resultar no mau funcionamento do switch.
O switch monitora a disponibilidade e os limites dos sensores dos respectivos componentes
de hardware.
Um plugin do Grid Control facilita o monitoramento do Cisco switch. Um exemplo da home
page do Cisco switch é mostrado no slide. As métricas e os limites default fornecidos pelo
plugin são suficientes para o nível de monitoramento necessário para garantir a
disponibilidade do switch. É possível alterar ou definir limites na página Metric and Policy
Settings para atender aos requisitos específicos do local. Os alertas do switch são reportados
por meio de uma trap do SNMP que pode ser recebida e exibida pelo Grid Control.
O Cisco switch pode ser monitorado de forma manual com uma interface de linha de
comando incorporada no próprio switch. Para obter mais informações, consulte a
documentação dos Cisco Catalyst 4500 Series switches disponível em www.cisco.com.

Monitorando as Sun PDUs
(Power Distribution Units)
• Cada rack contém duas PDUs
• Monitore as PDUs para:

– Assegurar o suprimento contínuo de energia
– Medir o consumo de energia
• Opções de monitoramento:
– Inspeção física das PDUs
le
– Monitoramento remoto usando o
fe rab
plugin do Grid Control ou outro
tra ns
gerenciador de SNMP n -
Definições adequadas de limites em a no
—
cada PDU são necessárias para facilitar a s

h eฺ
r )
o monitoramento remoto ฺ b uid
om nt G
ฺ c
o ude
t e i k t
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic Database Machine contêm duas PDUs (Power Distribution Units).
TodosoosTracks do Exadata
ic fornecem uma fonte de alimentação redundante que ajuda a manter a alta
AsnPDUs
c
e
T disponibilidade do sistema. O principal objetivo do monitoramento das PDUs é assegurar o
suprimento contínuo de energia. O monitoramento das PDUs também pode medir o consumo
de energia para fins de gerenciamento do centro de dados.
Em cada PDU, a unidade de medição correspondente permite monitorar a corrente usada
pelo equipamento conectado no rack do Oracle Exadata Database Machine. É possível
monitorar o consumo de energia localmente, examinando a tela de LCD da PDU, ou
remotamente em um sistema na rede. Uma imagem do monitor de consumo de energia da
PDU é mostrada no slide.
Para permitir o monitoramento remoto, é fornecido um plugin do Grid Control. O plugin
mostra o status da PDU, bem como todos os alertas gerados por ela.
Observe que limites apropriados devem ser configurados em cada PDU para gerar
automaticamente alertas indicando um consumo de energia anormal. Os valores específicos
dos limites dependem de vários fatores, como o modelo do Database Machine, o tamanho do
Database Machine, além da voltagem e do tipo da fonte de alimentação. O Oracle Exadata
Database Machine Owner's Guide contém os valores recomendados para cada situação.

Monitorando o Avocent MergePoint Unity
KVM Switch
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licacesso via console remota aos Exadata Storage Servers e aos
O KVM o Te permite
switch
ic de banco de dados do Database Machine. Seu principal objetivo é fornecer um
ecn
servidores
T controle baseado em teclado, vídeo e mouse para facilitar diversas tarefas de administração.
O KVM switch é monitorado principalmente para garantir sua disponibilidade.
O KVM switch pode ser monitorado com o plugin do Exadata Avocent MergePoint Unity
Switch. Um exemplo de home page do KVM switch é mostrado no slide. As métricas e
os limites default fornecidos pelo plugin são suficientes para o nível de monitoramento
necessário para garantir a disponibilidade do switch. Os alertas do switch são reportados
por meio de uma trap do SNMP que pode ser recebida e exibida pelo Grid Control.
Observe que não há um KVM switch no Exadata Database Machine X2-8. Nesse modelo,
a funcionalidade de console do servidor pode ser acessada por meio do ILOM.

Questionário
Qual dos seguintes componentes é muito importante monitorar

para manter a disponibilidade geral do Database Machine?

a. Cisco Ethernet Switch
b. Sun PDUs (Power Distribution Units)
c. Avocent MergePoint Unity KVM Switch
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
e c nic
T

Resumo
Nesta lição, você aprendeu a monitorar os seguintes

componentes adicionais do Exadata Database Machine:

• Cisco Catalyst Ethernet Switch
• Sun PDUs (Power Distribution Units)
• Avocent MergePoint Unity KVM Switch
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
• Demonstração da Lição
– Monitorando o Cisco Catalyst Ethernet switch e o Avocent

MergePoint Unity KVM com o Grid Control
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Outras Ferramentas Úteis de Monitoramento
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos

seguintes ferramentas úteis:

• Exachk
• DiagTools
• ADRCI
• Imageinfo e Imagehistory
le
• OSWatcher fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral de Exachk
• O Exachk é um utilitário que:

– Coleta dados sobre as versões dos componentes do Database

Machine e as melhores práticas associadas
– Permite que os administradores verifiquem seu ambiente em
relação às melhores práticas e aos níveis de versão suportados
– Vem pré-instalado nos novos Exadata Database Machines
– Está disponível em My Oracle Support note 1070954.1
– Deve ser executado periodicamente como parte do monitoramento able
e da manutenção do Database Machine s fer
t r a n
on-
– Não altera quaisquer definições de configuração do Database
Machine
a n
– Consome poucos recursos e tem um impacto h a s
mínimo no sistema
r ) d e ฺ
• O Exachk NÃO é:
m b
ฺ Gu i
– Uma ferramenta de monitoramento
o
ฺc contínuo n t
k o ud e
– Uma substituição do Enterprise t ei SManager t
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
e dados lic relacionados às principais versões de software, hardware e firmware,
O Exachk
o Tcoleta
bemiccomo às melhores práticas de configuração específicas do Oracle Database Machine.
TecnA saída ajuda os administradores do Database Machine a revisar e comparar periodicamente
os dados atuais sobre os principais componentes do Database Machine com os níveis de
versão suportados e as melhores práticas recomendadas.
O Exachk vem pré-instalado nos novos Exadata Database Machines A versão atualizada
mais recente do exachk está disponível para download em My Oracle Support note
1070954.1. O Exachk pode ser executado conforme desejado e sua execução regular deve
fazer parte do programa de manutenção do Oracle Database Machine.
O Exachk não é um utilitário de monitoramento contínuo e não deve ser considerado como
uma substituição de outras ferramentas de monitoramento ou alerta, como o Enterprise
Manager ou o ILOM.
O Exachk não é intrusivo nem faz qualquer alteração no Database Machine, a não ser gravar
arquivos de saída e alguns arquivos temporários pequenos que são deletados após serem
usados. O Exachk também poderá configurar a equivalência de usuário SSH caso ela não
esteja configurada.
Como o Exachk consome poucos recursos, o impacto na máquina-alvo é mínimo. Em um
sistema Database Machine X2-2 Full Rack, o exachk levará normalmente pouco mais de uma
hora para ser executado.
Executando o Exachk
Como o proprietário do software do Oracle Database (usuário do SO oracle):

1. Efetue download de exachk.zip em um servidor de banco de dados

2. Descompacte exachk.zip
$ unzip exachk.zip
– Mantenha o script exachk e os arquivos de driver (collections.dat e
rules.dat) no mesmo diretório
3. Verifique se o script exachk é executável
le
$ chmod +x exachk
fe rab
4. Execute exachk
tr a ns
– Siga os prompts, leia e entenda todas as mensagens n -
– no
Forneça as senhas solicitadas, caso contrário, algumas verificações serão
a
ignoradas a
h eฺ s
5. Revise os relatórios. b r )
ฺ as tarefas idque requerem uma
– Revise o relatório resumido para identificar m G u
investigação mais profunda
k o ฺco dent
– Revise o relatório detalhado t i obterturecomendações e mais informações
epara
r t e @ his S
u p o se t
Copyright © 2012,
e
t
o ( ense
i k lic
Te o processo
O slideodescreve recomendado para instalar e executar o exachk.
i c
TecOnexecutável do exachk não requer opções de linha de comando obrigatórias porque a
ferramenta varre automaticamente o ambiente do Database Machine para coletar a maioria
das informações necessárias. Informações adicionais são obtidas por meio de prompts no
início da sessão do exachk. Uma vez coletadas as informações do administrador, o exachk
pode ser executado de forma autônoma.
As seguintes considerações sobre o uso também devem ser observadas:
• É recomendável testar e executar o exachk em um sistema de arquivos local, em um
único servidor de banco de dados, para obter o desempenho máximo.
• Para maximizar o número de verificações realizadas, execute o exachk quando os
serviços do Grid Infrastructure e pelo menos um banco de dados estiverem ativos e em
execução.
• Embora a ferramenta exachk tenha um impacto mínimo, a melhor prática é executá-lo
nos períodos em que há menor carga no sistema.
• Para evitar possíveis problemas associados à execução da ferramenta em sessões de
terminal em um computador conectado à rede, considere executá-la usando o VNC;
assim, em caso de uma interrupção na rede, a ferramenta continuará a ser executada
até ser concluída.
• Se a execução da ferramenta falhar por algum motivo, ela poderá ser executada
novamente do início; o exachk não é retomado a partir do ponto de falha.
Saída do Exachk
[oracle@exa1db01 exachk]$ ./exachk

<Output Truncated>
Summary report - /u01/pochome/exachk/exachk_exa1db01_052411_170143/exachk_summary.rep

Detailed report - /u01/pochome/exachk/exachk_exa1db01_052411_170143/exachk.rep
UPLOAD - /u01/pochome/exachk/exachk_exa1db01_052411_170143.zip
[oracle@exa1db01 exachk]$
Check:- WARNING => ASM variable sized extents are enabled [DBMV2]
Check:- WARNING => NIC bonding is NOT configured for public network (VIP)
Check:- WARNING => kernel parameter rp_filter is set to 1.
Check:- WARNING => Free space in root(/) filesystem is less than recommended. [DBMV2]
le
rab
Check:- WARNING => One or more network cables are not connected.
fe
Check:- WARNING => kernel parameter rp_filter is set to 1.
tr a ns
Additional information to resolve above problem
n -
-----------------------------------------------
no
a
As a consequence of having rp_filter set to 1, Interconnect packets may potentially be
blocked/discarded.
a
h eฺ s
To fix this problem, use following MOS note.
r
ฺ Guid
b )
TO REVIEW COLLECTED DATA :-
m
k o ฺco dent
/u01/pochome/exachk/exachk_exa1db01_052411_170143/9AA08EB2573A36C6E040E50A1EC02BD9_exa1db01
ei Stu
_report.out
t
1 Note: 1286796.1 - rp_filter for bonded private interconnects and Linux Kernel 2.6.31+ -
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Tede saídalicdo Exachk são gravados em um dirétorio com timestamp, no local de
Os arquivos
o
e c nic da ferramenta. Os principais arquivos de saída são:
instalação
T • exachk_summary.rep, que contém um resumo das informações, das advertências e
dos avisos de falha das verificações do exachk.
• exachk.rep, que contém informações mais detalhadas sobre todas as entradas do
relatório resumido. As entradas desse relatório normalmente descrevem em detalhes os
problemas, bem como fornecem recomendações de correção. Elas também poderão
conter um link para uma nota de My Oracle Support a fim de fornecer mais informações,
especialmente se as recomendações mudarem com frequência ou se não forem muito
simples.
Um exemplo de saída dos dois relatórios principais da ferramenta exachk é mostrado no
slide.
São gravados vários arquivos de log adicionais, que contêm a saída bruta das verificações
do exachk. Esses arquivos podem ser referenciados no relatório exachk.rep, conforme
mostrado no exemplo de saída no slide.
Um arquivo zip contendo todos os arquivos de saída do exachk também é gravado no
mesmo diretório que o executável da ferramenta.

Visão Geral de DiagTools
• Diagtools.zip contém dois scripts que coletam

informações de rastreamento, log e configuração:

– DbmCheck.sh coleta informações gerais de configuração
sobre todos os Exadata Storage Servers
– diagget.sh coleta arquivos de log e rastreamento do
software Oracle, além de informações do SO de todos os
servidores le
• Os scripts foram projetados para oferecer um pacote fe rab
tra
consolidado de informações para uso pelo Oracle -Support ns
n
no Support
• Diagtools.zip está disponível em My Oracle a
note 735323.1 ) h as ฺ
• Consulte a demonstração Usando m ide
ฺborDiagTools
u
o G ฺc dent
k o
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic arquivo compactado que contém dois scripts que coletam arquivos de
o Te é lum
Diagtools.zip
e c nic
rastreamento
Machine:
e de log, além de outras informações de configuração do Exadata Database
T • DbmCheck.sh estabelece conexão com todas as células de armazenamento e coleta
informações gerais de configuração, como informações sobre discos de célula, discos
de grade e flash cache.
• diagget.sh estabelece conexão com todos os servidores do Database Machine e
coleta arquivos de log e de rastreamento relacionados ao Oracle Clusterware, ao ASM
e ao banco de dados. Ele também coleta diversos detalhes do sistema operacional,
incluindo informações geradas pelo OSWatcher.
Os scripts foram projetados principalmente para ajudar os administradores a fornecer um
pacote consolidado de informações sobre o ambiente do Database Machine o qual poderá
ser usado pelos técnicos do Oracle Support no atendimento de solicitações de suporte.
DiagTools.zip está disponível em My Oracle Support note 735323.1. Os scripts utilizam
os arquivos de grupo (arquivos que listam os nomes de host de todos os servidores do
Database Machine) gerados durante a implantação inicial do Database Machine. Os scripts
devem ser instalados em /opt/oracle.SupportTools/onecommand no primeiro
servidor de banco de dados. As informações de diagnóstico coletadas pelos scripts são
gravadas em diretórios com timestamp em
/opt/oracle.SupportTools/onecommand/diagfiles.
A demonstração Usando o DiagTools fornece um exemplo de como usar os scrips de
DiagTools.
Usando o ADRCI em Exadata Storage Servers
• O software do Exadata Storage Server usa a estrutura do

ADR (Automatic Diagnostic Repository) para gerenciar

dados de diagnóstico
• Usar o ADRCI em um Exadata Storage Server é muito
semelhante a usá-lo em um servidor de banco de dados.
• O diretório Home default do ADR é:
le
/opt/oracle/cell<cell_version>/log/diag/asm/cell/<hostname>
fe rab
ns tra
n -
• Consulte a demonstração Usando o ADRCI em
a nouma
Célula de Armazenamento do Exadata as
r ) h eฺ
m ฺ Guid
b
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
O ADR o Te
(Automatic Diagnostic Repository) é um repositório baseado em arquivo que contém
i c
n de diagnóstico, como rastreamentos, dumps, logs de alertas, relatórios do Health
dados
T e c
Monitor e muito mais. O software do Exadata Storage Server usa uma estrutura do ADR que
é essencialmente a mesma usada pelo software do Oracle Database. Como o ADR do
Oracle Database, o ADR de célula pode ser gerenciado com o ADRCI; o utilitário
interpretador de comandos do ADR.
Usar o ADRCI em um Exadata Storage Server é muito semelhante a usá-lo em um servidor
de banco de dados. A principal diferença é a localização do ADR. Nos Exadata Storage
Servers, /opt/oracle/cell<cell_version>/log/diag/asm/cell/<hostname> é o
diretório Home default do ADR, onde <cell_version> é uma string que indica a versão do
software da célula e <hostname> é o nome do host da célula. Observe que cada célula do
Exadata tem um link simbólico em /opt/oracle/cell que aponta para o diretório da
versão atual do software (/opt/oracle/cell<cell_version>).
Um exemplo de como usar o ADRCI para coletar arquivos de rastreamento referentes a
determinado incidente em um Exadata Storage Server é fornecido na demonstração Usando
o ADRCI em uma Célula de Armazenamento do Exadata.

Visão Geral de Imageinfo
[root@exa1cel01 ~]# imageinfo

Kernel version: 2.6.18-194.3.1.0.3.el5 #1 SMP Tue Aug 31 22:41:13 EDT 2010 x86_64
Cell version: OSS_11.2.0.3.0_LINUX.X64_101206.2
Cell rpm version: cell-11.2.2.2.0_LINUX.X64_101206.2-1
Active image version: 11.2.2.2.0.101206.2

Active image activated: 2011-02-24 12:22:44 -0800
Active image status: success
Active system partition on device: /dev/md5
Active software partition on device: /dev/md7
le
rab
In partition rollback: Impossible
fe
Cell boot usb partition: /dev/sdac1
Cell boot usb version: 11.2.2.2.0.101206.2
tra ns
n -
Inactive image version: 11.2.2.2.1.110131 no a
Inactive
Inactive
image activated: 2011-02-23 18:30:44 -0800
image status: success a
h eฺ s
Inactive system partition on device: /dev/md6
b r
ฺ Guid)
Inactive software partition on device: /dev/md8
m
k o ฺcoundefinede n t
ud
Boot area has rollback archive for the version:
Rollback to the inactive partitions: e
t i
Impossible
t
S
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licinicialmente nos servidores de armazenamento e de banco de dados
Teé instalado
O software
o
ic
ecn
do Exadata Database Machine por meio de um processo de criação de imagem específico do
T Exadata. Pacotes de patches do Exadata Storage Server também são fornecidos como
imagens de software.
Há dois utilitários para monitorar as imagens de servidor do Database Machine:
• imageinfo exibe informações sobre as imagens instaladas no momento em um
servidor.
• imagehistory exibe informações históricas sobre todas as imagens instaladas no
servidor.
O slide mostra um exemplo da saída exibida por imageinfo. Neste exemplo, o comando
mostra informações associadas a um servidor de armazenamento.
Há um volume significativamente menor de saída associado aos servidores de banco de
dados porque não existe o conceito de imagens ativas e inativas nesses servidores, e eles
não contêm um dispositivo USB de inicialização de célula.
O comportamento e a saída de imageinfo podem ser modificados com o uso de vários
parâmetros opcionais. Execute imageinfo –h para obter uma lista das opções disponíveis.

Visão Geral de Imagehistory
[root@exa1cel01 ~]# imagehistory

Version : 11.2.2.2.0.101206.2
Image activation date : 2011-01-12 14:56:44 -0800
Imaging mode : fresh
Imaging status : success
Version : 11.2.2.2.1.110131
Image activation date : 2011-02-23 18:30:44 -0800
Imaging mode : out of partition upgrade
Upgrade logs : /var/log/cellos/patch/rollback_20
le
rab
1102242002_11.2.2.2.0.101206.2_11.2.2.2.1.110131.tar.gz
Imaging status : success
fe
tra ns
Version : 11.2.2.2.0.101206.2
n -
Image activation date :
no
2011-02-24 12:22:44 -0800
a
Imaging mode
Imaging status
:
:
out of partition rollback
success a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licinformações históricas sobre todas as imagens instaladas no servidor.
o Te exibe
imagehistory
ic
Onslide mostra um exemplo da saída exibida por imagehistory. Neste exemplo, o
c
T e comando mostra informações associadas a um servidor de armazenamento. Na saída, é
possível observar que a versão inicial do servidor de armazenamento era 11.2.2.2.0. Em
seguida, foi aplicado um patch para a versão 11.2.2.2.1. E, finalmente, o patch foi revertido, e
o servidor voltou à versão inicial do software.
Em geral, a saída associada a um servidor de banco de dados estaria relacionada somente à
imagem instalada inicialmente porque não são aplicados patches nesses servidores com o
uso de técnicas de criação de imagem.
imagehistory contém apenas três parâmetros opcionais:
-all mostra todos os atributos de imagem disponíveis.
-help mostra um comando básico usando instruções.
-version <version> gera informações relacionadas somente à versão especificada

Visão Geral de OSWatcher
• OSWatcher coleta e arquiva métricas do sistema operacional

e da rede para ajudar no diagnóstico de problemas de
desempenho
• OSWatcher coleta dados do SO regularmente, chamando
utilitários como vmstat, netstat e iostat
• OSWatcher é executado em todos os servidores do Exadata
Database Machine com as seguintes definições default:
– Snapshots de métricas são registrados a cada 15 segundos
r a ble
s
– 168 horas (7 dias) de observações de métricas arquivadasnsãofe
mantidas
n - tra
– Local de instalação: /opt/oracle.oswatcher/osw
a no
– Local de arquivamento:
) h as ฺ
/opt/oracle.oswatcher/osw/archive ฺbr uidem G
• O OSWatcher User Guide está o nt em My Oracle
ฺcdisponível
k o de
Support note 301137.1. tei S t u
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic
o Te é um lconjunto
O OSWatcher de scripts de shell UNIX projetados para coletar e arquivar
i c
ecn
métricas do sistema operacional e da rede a fim de ajudar no diagnóstico de problemas de
T desempenho. O OSWatcher opera como um conjunto de processos de background no
servidor e coleta dados do SO regularmente, chamando utilitários como vmstat, netstat e
iostat.
Por default, o OSWatcher é configurado para ser executado em todos os servidores de banco
de dados e de armazenamento do Exadata Database Machine com as seguintes definições:
• Snapshots de métricas são registrados a cada 15 segundos.
• 168 horas (7 dias) de observações de métricas arquivadas são mantidas.
O OSWatcher é instalado em /opt/oracle.oswatcher/osw. As observações de métricas
são mantidas no subdiretório archive.
O OSWatcher User Guide está disponível em My Oracle Support note 301137.1.

Questionário
O Exachk é uma alternativa ao uso do Grid Control:

a. VERDADEIRO
b. FALSO
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
e c nic
T

Questionário
Qual utilitário deve ser usado para fornecer ao Oracle Support

um pacote consolidado de informações sobre um ambiente do

Database Machine?
a. Exachk
b. DiagTools
c. ADRCI
d. Imageinfo r a ble
n s fe
e. Imagehistory tra
o n -
f. OSWatcher an
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
e c nic
T

Resumo
Nesta lição, você aprendeu a descrever as seguintes

ferramentas úteis:
• Exachk
• DiagTools
• ADRCI
• Imageinfo e Imagehistory
le
• OSWatcher fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
– Usando o DiagTools
– Usando o ADRCI em uma Célula de Armazenamento do
Exadata
– Oracle Exadata Database Machine exachk or HealthCheck
– Exadata Storage Server Diagnostic Collection Guide
r a ble
e
– OS Watcher User Guide nsf tr a
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Backup e Recuperação
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos

• Descrever como os backups do RMAN são otimizados

com o Exadata Storage Server
• Descrever as abordagens recomendadas para backups de
banco de dados baseados em disco e baseados em fita no
Database Machine.
• Descrever as melhores práticas recomendadas para r a ble
e
backup e recuperação no Database Machine. nsf tr a
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral do Backup e Recuperação
• Backup e recuperação de bancos de dados no Database

Machine
– Usar o RMAN
– Estratégias típicas:
— Backups baseados em disco
— Backups baseados em fita
— Estratégia híbrida
able
• Backup e Recuperação do Software Database Machinesfer
t r a n
– Software de servidor de banco de dados
n on-
– Software Exadata Storage Server
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
e concentralic nas recomendações de melhores práticas para backup e
Tse
Esta lição
o
e c nic
recuperação com o Database Machine. O slide lista os tópicos considerados na lição.
T

Usando o RMAN com o Database Machine
• Usar o RMAN no Database Machine é basicamente o

mesmo que usá-lo em qualquer outro local

– Os mesmos conceitos
– Os mesmos comandos
• O desempenho do backup incremental é aperfeiçoado
– A filtragem de blocos é descarregada no Exadata Storage
Server
r a ble
– Menos blocos precisam ser processados pelo RMAN
n s fe
– O processamento de descarregamento é automático
n - trea
transparente no a
• A Exadata Hybrid Columnar Compression
) h aspode ฺ ajudar a
r e
melhorar ainda mais o desempenho uid
ฺb de backups m G
ฺco resulta
– O tamanho reduzido dos dados
k o e n t em backups menores
e mais rápidos tei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lioc uso do RMAN para backup e recuperação de bancos de dados com o
A Oracle
o Trecomenda
ic Machine. Basicamente, o RMAN com o Database Machine é usado da mesma
ecn
Database
T forma que sem o Database Machine.
Para otimizar o desempenho de backups incrementais, o banco de dados pode descarregar a
filtragem de blocos no Exadata Storage Server. Essa otimização somente é possível ao
efetuar backups com o RMAN. O processamento de descarga é feito de forma transparente
sem a intervenção do usuário. Durante o processamento de descarga, o Exadata Storage
Server filtra os blocos que não são necessários para o backup incremental em andamento.
Dessa forma, somente os blocos necessários ao backup são enviados ao banco de dados.
Isso pode aperfeiçoar o desempenho de forma significativa, principalmente se a proporção de
blocos alterados for baixa.
A Exadata Hybrid Columnar Compression pode ajudar a melhorar ainda mais o desempenho
de backup. Quando um banco de dados usa a Exadata Hybrid Columnar Compression, o
número de blocos incluídos no backup é reduzido quando comparado aos mesmos dados em
um banco de dados que utiliza uma forma de compactação menos eficiente em termos de
espaço ou simplesmente nenhuma compactação. O tamanho reduzido dos dados associado
à Exadata Hybrid Columnar Compression resulta em backups menores e mais rápidos.

Recomendações Gerais para o RMAN
Use o RMAN para fazer backup e recuperar bancos de dados

no Database Machine
• Use backups incrementais do RMAN e rastreamento de
alterações em blocos
• Use um repositório externo de catálogo de recuperação do
RMAN
• Defina DB_RECOVERY_FILE_DEST_SIZE para associar o rable
e
espaço usado na Fast Recovery Area nsf tra
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k laicseguir se aplicam ao uso do RMAN com o Database Machine:
Te
As recomendações
o
ic
Tecn• Use backups incrementais do RMAN e rastreamento de alterações em blocos:
para backups incrementais rápidos, ative o rastreamento de alterações em blocos. O
rastreamento de alterações em blocos permite que o RMAN evite a varredura em
blocos que não sofreram alterações ao criar backups incrementais. Além disso, durante
a execução de backups incrementais de bancos de dados no Database Machine, uma
inspeção de blocos adicional é descarregada dos servidores de banco de dados. O
rastreamento de alterações em blocos oferece o maior benefício para bancos de dados
em que menos de 20% dos blocos foram alterados entre backups incrementais. Você
ainda pode se beneficiar do rastreamento de alterações em blocos com taxas de
alterações maiores do que 20%, mas é recomendável fazer um teste para garantir que
o tempo de backup seja reduzido.
• Use um repositório externo de catálogo de recuperação do RMAN: o catálogo de
recuperação do RMAN deve ser hospedado em um servidor fora do Database Machine.
Na prática, é comum ter um servidor que hospeda o catálogo do RMAN juntamente com
outros repositórios de gerenciamento, como o repositório do Oracle Enterprise Manager
e o catálogo do Oracle Secure Backup.

• Defina DB_RECOVERY_FILE_DEST_SIZE para limitar o espaço usado na Fast
Recovery Area: o banco de dados grava os arquivos de redo log arquivados e todos os
arquivos de recuperação adicionais na Fast Recovery Area. Isso inclui quaisquer
arquivos de backup de disco, como cópias de imagem de nível 0 e conjuntos de backup
de nível 1, bem como arquivos de log Flashback (se ativado). É importante definir o
valor desse parâmetro como menos do que o espaço livre total disponível no grupo de
discos, levando-se em conta, pelo menos, uma falha no disco e, de preferência, uma
falha no Exadata. Além disso, se vários bancos de dados compartilharem a Fast

Recovery Area, garanta que a soma do espaço alocado aos diferentes bancos de
dados seja menor do que o espaço livre disponível no grupo de discos.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Estratégia de Backup Baseado em Disco
Para backups de bancos de dados baseados em disco,

a Oracle recomenda:
• Usar uma Fast Recovery Area
• Executar um backup inicial de nível 0 (integral)
• Executar backups de nível 1 incrementais periódicos
• Atualizar seu backup de nível 0 aplicando o segundo ao
le
último backup de nível 1
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de dados baseados em disco, a Oracle recomenda backups
Te de bancos
Para backups
o
e c nic
incrementais em uma FRA (Fast Recovery Area). A estratégia recomenda está destacada no
T slide. Usando essa abordagem, é possível obter um bom equilíbrio entre o tempo e o esforço
necessários durante operações de backup e de recuperação. A abordagem também
gerencia, de forma eficiente, a quantidade de armazenamento necessária para backups.
Lembre-se de que o procedimento de configuração inicial do Database Machine cria um
grupo de discos para a FRA e que o tamanho inicial do grupo de discos é determinado pelo
método de backup escolhido na planilha de configuração.

Recomendações sobre o Backup
Baseado em Disco
• Configuração da FRA (Fast Recovery Area):
– Default: grupo de discos da FRA distribuído por striping

entre todos os Exadata Storage Servers disponíveis,
juntamente com os grupos de discos de dados
— Alta disponibilidade com o melhor throughput
– Alternativa: grupo de discos da FRA e grupos de discos de
dados em Exadata Storage Servers separados
Separação de dados e backups em detrimento do throughput le
rab
—
• Recomendações adicionais para o RMAN: fe

– Instâncias e canais:
ns tra
n -
— Inicialmente, execute o RMAN usando uma instância
a no do banco
de dados e dois canais do RMAN
) h as ฺ
— Adicione outra instância com dois canais,
ฺbr Gu seid e
necessário
Adicione mais dois canais por m
coinstância, t se necessário
—
o ฺ n
deser usado como o destino
– Configure um serviçote ik para
Oracle t u
do RMAN
r t e @ his S
u p o se t
Copyright © 2012,
e
t
o ( ense
i k lic de instalação e configuração do Database Machine produz um
Teo procedimento
Por default,
o
e c nic os
grupo
todos
de discos para a FRA (Fast Recovery Area), que é distribuído entre todos os discos de
Exadata Storage Servers. Nessa configuração, a FRA compartilha cada disco com
T grupos de discos que contêm arquivos de dados de banco de dados. Por default, todos os
grupos de discos são criados com, pelo menos, a redundância NORMAL do ASM
(espelhamento bidirecional). O resultado é que o Database Machine pode tolerar a perda de
todo um Exadata Storage Server e, ainda assim, manter a integridade total dos dados.
Quando os clientes desejam uma separação entre os arquivos de banco de dados e a FRA, a
alternativa recomendada é configurar o grupo de discos que contém a FRA em um conjunto
dedicado de Exadata Storage Servers e configurar os grupos de discos de dados
necessários em servidores de armazenamento separados. Essa configuração significa que a
entrada/saída de uma única carga de trabalho não pode mais se beneficiar da sua
distribuição em todos os servidores de armazenamento. No entanto, ela também oferece
uma proteção adicional se várias falhas simultâneas afetarem o banco de dados ou a FRA.
Várias falhas simultâneas no banco de dados e na FRA ainda podem resultar em perda de
dados.
Outra estratégia é adquirir mais Exadata Storage Servers de alta capacidade,
especificamente para armazenar a FRA. Isso permite que seus bancos de dados aproveitem
a capacidade total dos servidores de armazenamento Database Machine. Para implementar
essa estratégia, os servidores de armazenamento da FRA precisam ser hospedados em um
rack separado e ser conectados com a rede de armazenamento do Database Machine
usando as portas sobressalentes nos InfiniBand switches do Database Machine.
Além das recomendações gerais para o RMAN com o Database Machine, a Oracle
recomenda a configuração a seguir para backups baseados em disco:
• Testes demonstram que as taxas de backup ideais são obtidas com duas instâncias de
banco de dados e de dois a quatro canais do RMAN por instância. Para as duas
instâncias de banco de dados designadas como servidores de backup, menos de 10%
da CPU e menos de 40% da largura de banda de entrada/saída são utilizados. Durante
operações de backup, consultas paralelas com muitas entradas/saídas devem evitar
esses servidores de backup designados. Comece executando o RMAN em uma

instância de banco de dados usando dois canais do RMAN. Se for necessário um
throughput de backup maior, use uma segunda instância com mais dois canais.
Finalmente, se necessário, adicione mais dois canais por instância.
• Configure um Serviço Oracle para execução em instâncias de banco de dados
específicas no cluster. O serviço é usado pelo RMAN para distribuir automaticamente a
carga de backup uniformemente entre as instâncias de destino que oferecem o serviço.
le
• Para backups incrementais, use a opção FILESPERSET 1 do comando BACKUP do
fe rab
único arquivo. tra ns
RMAN. Essa opção de backup permitirá operações mais rápidas de restauração de um
n -
• Defina o parâmetro de inicialização
a no
a s
_file_size_increase_increment=2143289344 para otimizar o espaço usado
h eฺ
r )
quando backups incrementais (nível 1) são gravados na FRA.
ฺ Guid
b
m
• Para os sistemas que executam o Oracle Database release 11.2.0.1, defina o
o ฺco dent
parâmetro de inicialização _backup_ksfq_bufsz=4194304 para otimizar o
k
t ei Stu
desempenho de leitura. Não defina o parâmetro de inicialização
o r te@ this
_backup_ksfq_bufsz nos sistemas que executam o Oracle Database release
11.2.0.2 ou posterior.
ฺ s up use
( t ec se to
• Para os sistemas que executam o Oracle Database release 11.2.0.1, defina o
e i ko licen
parâmetro de inicialização _backup_ksfq_bufcnt da seguinte maneira:
o T
- Em uma configuração Quarter Rack, defina _backup_ksfq_bufcnt=32.
ic
Tecn - Em uma configuração Half Rack, Full Rack ou de vários racks, defina
_backup_ksfq_bufcnt=64.

Estratégia de Backup Baseado em Fita
Para backups de bancos de dados baseados em fita, a Oracle

recomenda:
• Usar software de gerenciamento de mídias que seja
integrado ao RMAN, como o Oracle Secure Backup
• Executar backups de bancos de dados de nível 0
(integrais) periódicos
• Executar backups de nível 1 cumulativos mais frequentes rable
e também efetuar backup do catálogo do Oracle Secure n s fe
Backup n - tra
o n
a
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de dados baseados em fita, a Oracle recomenda o uso do Oracle
Te de bancos
Para backups
o
e c nic Backup ou de outro software de gerenciamento de mídias que seja integrado ao
Secure
T RMAN. A estratégia de backup recomendada é executar backups de bancos de dados de
nível 0 (integrais) periódicos (semanais). Além disso, backups de nível 1 cumulativos mais
frequentes (diários) devem ser executados juntamente com um backup do catálogo do Oracle
Secure Backup, se este for o software de gerenciamento de mídias usado.

Arquitetura de Backup Baseado em Fita
Database Machine Sun StorageTek

SL500
Oracle Secure Backup

Administration Server
(Sun Fire X4170)
Servidores de Mídias Oracle Secure Backup
(Sun Fire X4275)

le
fe rab
Rede SAN Fiber Channel
tra ns
InfiniBand n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de referência recomendada para uma configuração de backup
Te a arquitetura
O slide ilustra
o
c ic em fita, usando o Oracle Secure Backup. As principais recomendações associadas
baseado
nconfiguração
T e à são as seguintes:
• Conecte os servidores de mídia com o Database Machine utilizando a rede InfiniBand
de alto desempenho. A conexão InfiniBand com cada servidor de mídia deve ser
acoplada para obter alta disponibilidade. Como opção, você pode usar uma rede
Gigabit Ethernet entre os servidores de mídia e o Database Machine, no entanto, se
você usar essa configuração, lembre-se que, provavelmente, a rede será um fator de
restrição ao desempenho de backup e de recuperação.
• Considere a capacidade da largura de banda da conexão InfiniBand do Database
Machine com o servidor de mídia comparada à dos links SAN entre o servidor de mídia
e a biblioteca de fitas. Testes mostram que um link InfiniBand é capaz de oferecer taxas
de dados de aproximadamente 3 GB por segundo. Portanto, é preciso fornecer o
número adequado de links SAN e configurá-los para oferecer o throughput necessário.
• Em geral, o desempenho do backup é limitado pelo throughput das unidades de fita. O
desempenho do backup é escalável quando você adiciona mais unidades de fita e
canais do RMAN. Aloque um número suficiente de unidades de fita para que os
servidores de mídia possam alcançar suas taxas máximas de backup e de restauração.
Adicione unidades de fita até que a largura de banda dos servidores de mídia seja
saturada.
• Comece com, pelo menos, dois servidores de mídia. Adicione servidores de mídia se
você tiver unidades de fita suficientes para mantê-las ocupadas sem saturar os
recursos do Database Machine.
Baseado em Fita
• Recomendação de configuração de rede do servidor de mídia
para o Database Machine:

– Use a InfiniBand para obter as melhores taxas de backup:
— Configure o acoplamento das interfaces InfiniBand do servidor de
mídia
— Atualize o OpenFabrics Enterprise Distribution no servidor de mídia
— Configure o modo conectado IP sobre InfiniBand para obter um
melhor desempenho le
— Defina o tamanho da MTU (unidade de transferência de
fe rab
mensagens) como 65520 para a interface da InfiniBand
tra ns
n -
Configure o software de gerenciamento de mídias para usar a rede
no
—
InfiniBand
a
• Recomendação de configuração da SAN) h asservidor
do ฺ de
r e
mídia: mฺb uid o G
– Configure bindings persistentes t
oฺc paraendispositivos de fita
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c ser conectados diretamente com a estrutura InfiniBand do
Tede mídialipodem
Servidores
o
e c nic Machine adicionando um adaptador de canal host QDR (InfiniBand Quad Data
Database
T Rate) com o servidor de mídia. Use a tecnologia InfiniBand a fim de obter as melhores taxas
de backup, especialmente para bancos de dados grandes que requerem taxas rápidas de
backup e baixo overhead de CPU.
Siga estas recomendações:
• Para obter alta disponibilidade, conecte o HCA a dois Infiniband leaf switches diferentes
do Database Machine para eliminar o switch como um ponto único de falha. Esse
procedimento fornecerá um failover transparente se a conectividade a uma das portas
for perdida. Configure o acoplamento das interfaces InfiniBand (IB) do servidor de
mídia. Use o acoplamento Ativo-Passivo.
• Você deve usar no servidor de mídia uma versão do OFED (OpenFabrics Enterprise
Distribution) compatível com a encontrada no Database Machine. Para obter detalhes,
consulte My Oracle Support bulletin 888828.1.
• Configure a interface InfiniBand para usar o modo conectado IP sobre InfiniBand a fim
de obter o melhor desempenho. No Linux, edite o arquivo /etc/ofed/openib.conf
para que contenha a entrada SET_IPOIB_CM=yes. Reinicialize o servidor para ativar a
definição. Para verificar a definição, examine o conteúdo de
/sys/class/net/ib0/mode e de /sys/class/net/ib1/mode. Os dois arquivos
devem conter a entrada connected.
• Defina o tamanho da MTU (unidade de transferência de mensagens) como 65520 para
a interface da InfiniBand. No Linux, edite os arquivos /etc/sysconfig/network-
scripts/ifcfg-ib* e /etc/sysconfig/network-scripts/ifcfg-bond0
para que contenham a entrada MTU=65520. Verifique a definição de MTU examinando
a saída do comando ifconfig para as interfaces InfiniBand.
• Para direcionar o tráfego de backup e de restauração pela rede InfiniBand, configure o
software de gerenciamento de mídias para favorecer a InfiniBand. Observe que cada
tipo de software de gerenciamento de mídias tem seu próprio método de ativação dessa
configuração. Por exemplo, o Oracle Secure Backup tem o conceito de uma interface
de rede preferencial, que pode ser definida no servidor de mídia para uma lista
específica de clientes. Outro software de gerenciamento de mídias pode exigir que essa
configuração seja definida na instalação. Consulte as informações de como direcionar o
tráfego por uma rede específica do software de gerenciamento de mídias.
Para dispositivos de fita conectados à SAN, configure bindings persistentes para que o
le
servidores de mídia não poderão acessar o dispositivo, a menos que você atualize a fe rab
endereço do dispositivo não seja alterado. Se o endereço do dispositivo for alterado, os
tra ns
configuração do dispositivo dentro do software do servidor de mídia. Dessa forma, é muito
n -
no
importante que o seu ambiente mantenha endereços de dispositivos consistentes.
a
a s
Os bindings persistentes fazem parte da configuração da infraestrutura SAN. Geralmente,
h eฺ
r )
eles são configurados por meio do HBA ou do sistema operacional. As etapas de
ฺ Guid
b
configuração dependem da plataforma e do fornecedor. Consulte My Oracle Support note
m
k o ฺco dent
971386.1 para obter um exemplo de criação de bindings persistentes para conexões de
dispositivos. t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Conectando o Servidor de Mídia Usando a Ethernet
• A Ethernet poderá ser usada se o throughput for

suficiente:
– GigE: espere até 120 MB/s de cada interface

– 10GigE: espere até 1 GB/s de cada interface
• Recomendações:
– Use uma rede de backup dedicada:
— Configure interfaces de rede dedicadas em cada servidor de
banco de dados do Database Machine le
– Use interfaces de rede acopladas: fe rab
Configure o LACP para throughput máximo: tra ns
—
n -
—
no
A disponibilidade ainda será mantida em caso de perda de um link
a
Configuração necessária no servidor de mídia, no switch de rede e
—
a s
r) haltaudisponibilidade,
nos servidores de banco de dados
Use o acoplamento Ativo-Passivoฺpara b i deฺ
om nt G
—
caso contrário: ฺ c
Configure os servidores i k ode banco
u ddee dados e o servidor de mídia
—
t e t
S de switch é necessária
—
r t e @ hiespecífica
Nenhuma configuração s
u p o se t
Copyright © 2012,
e
t
o ( ense
i k
Te vocêlicpoderá usar uma rede GigE (Gigabit Ethernet) ou 10GigE (10 Gigabit
Opcionalmente,
o
c n ic entre o Database Machine e os servidores de mídia se o throughput for suficiente.
Ethernet)
e
T O uso de uma rede de backup dedicada elimina qualquer impacto na rede de acesso do
cliente. Em geral, já existe uma rede de backup dedicada. O throughput máximo com a rede
GigE é de aproximadamente 120 MB/s para cada interface. Na rede 10GigE, o throughput
máximo é de aproximadamente 1 GB/s para cada interface. Portanto, um Exadata Database
Machine X2-2 Full Rack pode alcançar um throughput de até 960 MB/s usando a rede GigE
ou de 8 GB/s usando a rede 10 GigE, com uma única interface de rede dedicada em cada
servidor de banco de dados.
Um throughput mais alto poderá ser alcançado com o uso do LACP (Link Aggregation Control
Protocol‎). Esse protocolo permite que uma interface de rede acoplada use os dois canais de
rede simultaneamente. Para usar o LACP, é necessário configurar uma interface de rede
acoplada em cada servidor de banco de dados e definir o parâmetro BONDING_OPTS como
mode=4 no arquivo de configuração de acoplamento associado (ifcfg-bond1, por
exemplo). Você também deve configurar o LACP no switch de rede associado e nas
interfaces de rede do servidor de mídia. Se o LACP não for usado, use interfaces de rede
com acoplamento Ativo-Passivo para oferecer alta disponibilidade em caso de falha na
interface.
Lembre-se de que a capacidade de usar uma interface de rede acoplada dedicada para fins
de backup e recuperação depende das demais configurações do Database Machine. Por
exemplo, talvez não haja interfaces de rede suficientes disponíveis se o acoplamento
também for usado para a rede de acesso do cliente. Nesse caso, os clientes devem
balancear os requisitos concorrentes.

Baseado em Fita
• Execute o RMAN em todas as instâncias disponíveis do
banco de dados
– Crie um Serviço de Banco de Dados que seja executado no
cluster
$ srvctl add service –d <dbname> -s <service name>
-r <instance1>, ... ,<instancen>
– Use o nome do serviço e o endereço SCAN para conectar o
RMAN r a ble
e sf
r a
$ rman target sys/<passwd>@<scan_address>/<service_name>
t n
catalog ... on- n
s a
• Aloque um canal RMAN por unidade de
) h afita ฺ
b r
ฺ controlar i d e
• Configure o IORM e o DBRM para
o m G u a alocação de
recursos entre backups eikcargas oฺc udde t
entrabalho de
aplicações @ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Te adicionais:
Recomendações
o
e c n• icPara os bancos de dados RAC, configure o RMAN para ser executado em todas as
T instâncias do banco de dados. É recomendável que você crie um Serviço de Banco de
Dados para ser executado no cluster RAC. Em seguida, ao executar o RMAN, use o
nome do serviço e o endereço SCAN na string de conexão para o destino do RMAN,
conforme mostrado no slide.
• Aloque um canal RMAN por unidade de fita. Um único canal do RMAN no Database
Machine pode transmitir dados a uma taxa de aproximadamente 750 MB/s do Database
Machine para o servidor de mídia. Em geral, as taxas de backup de unidades de fita
ficam compreendidas entre 100 MB/s e 240 MB/s, dependendo do tipo de unidade e
das opções de compactação. Observe que a compactação da unidade de fita se torna
menos eficaz ao fazer backup de tabelas compactadas no nível do banco de dados.
• Se os recursos do Database Machine tiverem que ser priorizados entre cargas de
trabalho de aplicações e backups, configure o IORM (I/O Resource Manager) e o
DBRM (Database Resource Manager). É mais provável que esse procedimento seja
necessário em casos onde backups demorados de bancos de dados de grande porte
devam ser executados ao mesmo tempo em que cargas de trabalho de aplicações de
produção.

Estratégia de Backup Híbrida
• Uma estratégia de backup híbrida combina abordagens de

backup baseado em disco e em fita:

– Backups de nível 0 (integrais) são armazenados em fita
— Mídia de backup relativamente barata, que pode ser
armazenada fora do local
– Backups incrementais de nível 1 são armazenados em
disco, na FRA le
— Prontamente disponível com acesso de alto desempenho
fe rab
• Siga as recomendações para as duas abordagens-tra ns
n on
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic híbrida combina abordagens de backup baseado em disco e em
Te de backup
Uma estratégia
o
e c nicPor exemplo, uma abordagem híbrida razoável resultaria em backups de banco de dados
fita.
T de nível 0 (integrais) armazenados em fita, enquanto que backups incrementais de nível 1
seriam armazenados em disco no FRA. A abordagem híbrida também combina os benefícios
de cada tipo de armazenamento, conforme indicado no slide. Se você optar por implementar
uma abordagem de backup híbrida, deverá seguir as recomendações para backups
baseados em disco e em fita.

Recomendações de Restauração e Recuperação
• Restaure em arquivos de dados existentes, se possível

– O desempenho da restauração é melhor

– Restaure usando todas as instâncias do banco de dados
• Se não houver arquivos de dados, restaure usando até
duas instâncias do banco de dados
• Número recomendado de canais do RMAN:
le
– Para restauração baseada em disco, use de dois a oito
fe rab
canais do RMAN por instância do banco de dados
a n s
– Para restauração baseada em fita, defina o númeron r
-tde
o
canais do RMAN baseado no número totals de a nunidades de
a
fita r) h eฺ ฺb Guid
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic são obtidas quando o overhead de alocação inicial de arquivos de
Tede restauração
Altas taxas
o
e c nic é evitado. Se houver arquivos antes da restauração do banco de dados, não os delete
dados
T e execute a restauração nos arquivos existentes, a fim de aproveitar essa otimização.
Com arquivos pré-existentes, crie um serviço de restauração em todas as instâncias do
banco de dados. Se não houver arquivos de dados antes da operação de restauração, crie
um serviço de restauração somente com duas instâncias do banco de dados. Use de dois a
oito canais do RMAN por instância do banco de dados para a restauração baseada em disco.
Para restauração baseada em fita, o número de canais deve ser definido como o número de
unidades de fita

Backup e Recuperação do Software
do Database Machine
• Software de servidor de banco de dados
– Executar backup e recuperação no nível do sistema de arquivos

— Usar o seu software escolhido de gerenciamento de backup do
sistema de arquivos ou o Oracle Secure Backup
— Cópias do Oracle Cluster Registry são mantidas automaticamente no
sistema de arquivos do servidor de banco de dados e devem ser
incluídas nos respectivos backups
• Software do Exadata Storage Server able
fe r
– Backups no nível do sistema de arquivos não são recomendados
a n s
—Áreas do sistema são espelhadas n -t r
Usar comandos CellCLI para recuperação se ocorrer falha
o
n em um disco
—
a
do sistema
) h as ฺ
—Usar o Procedimento de Resgate do Software
ฺ b r udo i deExadata se ocorrer
uma falha simultânea nos dois discos m G
do sistema
couma unidade t
O procedimento de resgate k o ฺ
usa d n
e flash USB incorporada
—
t e i t u
e @ i s S
r t
o se t h
u p
Copyright © 2012,
e
t
o ( ense
i k
Te quelicvocê use técnicas de backup e recuperação do sistema de arquivos
É recomendável
o
paraicos servidores de banco de dados. Use a sua infraestrutura e o software de
Tecngerenciamento de backup do sistema de arquivos de sua escolha ou, se desejar, use o
Oracle Secure Backup. Observe que um backup do Oracle Cluster Registry, que também
contém informações do Disco Voting, é mantido automaticamente no sistema de arquivos do
primeiro servidor de banco de dados e deve ser incluído nos seus backups do sistema de
arquivos do servidor de banco de dados. O local default para o backup do Oracle Cluster
Registry é <Grid_Home>/cdata/<Cluster_Name>, em que:
• <Grid_Home> é o local do software Grid Infrastructure, conforme especificado durante
a configuração inicial do Database Machine. O local default do <Grid_Home> é
/u01/app/11.2.0/grid.
• <Cluster_Name> é o nome do seu cluster. É o mesmo que o DB Machine Prefix
especificado durante a configuração inicial do Database Machine.
Backups no nível do sistema de arquivos não são recomendados para o software de célula
do Exadata. O Exadata Storage Server mantém áreas do sistema espelhadas em discos
físicos separados. Na rara possibilidade de falha simultânea dos dois discos do sistema,
você deverá usar a funcionalidade de resgate fornecida na unidade flash USB CELLBOOT
incorporada em todos os Exadata Storage Servers.

Questionário
Para facilitar os backups baseados em disco, é possível

instalar Exadata Storage Servers de alta capacidade adicionais

no espaço disponível em um Database Machine Half Rack
baseado em discos de alto desempenho:
a. Verdadeiro
b. Falso
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:o Tbe
An
c ic
inclusão de Exadata Storage Servers no mesmo rack que um Database Machine Half Rack
T e é suportada somente usando o pacote de upgrade de Half Rack para Full Rack, e o
Database Machine Full Rack resultante só poderá utilizar um tipo de disco, ou seja, de alto
desempenho ou de alta capacidade. Para adicionar células de alta capacidade a um
Database Machine Half Rack que usa células de alto desempenho, seria necessário
adicionar um Exadata Storage Expansion Rack ou instalar as células de alta capacidade em
um rack separado e conectá-las à rede de armazenamento do Database Machine usando as
portas sobressalentes nos InfiniBand switches do Database Machine.

Questionário
Quantos canais do RMAN devem ser usados para backups

baseados em fita?
a. 2 por instância do banco de dados
b. 4 por instância do banco de dados
c. 1 por unidade de fita
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tce
e c nic
T

Resumo

• Descrever como os backups do RMAN são otimizados

com o Exadata Storage Server
• Descrever as abordagens recomendadas para backups de
banco de dados baseados em disco e baseados em fita no
Database Machine.
• Descrever as melhores práticas recomendadas para r a ble
e
backup e recuperação no Database Machine. nsf tr a
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
– Otimização do Backup Usando o RMAN e o Exadata

Storage Server
– Otimização da Recuperação Usando o RMAN e o Exadata
Storage Server
– Database Machine and Exadata Storage Server 11g
r a ble
Release 2 (11.2) Supported Versions
n s fe
n - tra on
– OSB - Create persistent bindings for device attachments
o
OEL an
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral do Exercício 20: Usando Otimizações
do RMAN para o Database Machine
Nestes exercícios, você examinará as otimizações de backup e
de recuperação ativadas quando o Oracle RMAN (Recovery

Manager) é usado juntamente com o armazenamento do
Exadata.
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Tecn
ic
oT e i
( t
ฺ s
ko licen
o r
ec se to
t
up use
k o
te@ this
ei Stu
m b r )
ฺco dent
a s
ฺ Guid
a
h eฺ
no n - tr
a
ns fe rab
le
Tarefas de Manutenção do Exadata Database Machine
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos
Após concluir esta lição, você será capaz de executar as

seguintes tarefas de manutenção do Database Machine:

• Ligar e desligar o Database Machine
• Fazer shutdown de um único Exadata Storage Server com
segurança
• Substituir um disco físico danificado em uma célula
• Substituir uma placa flash danificada em uma célula r a ble
• Mover todos os discos de uma célula para outra tran
sfe
• Usar o procedimento de resgate do software n
de
n- do
océlula
s a
Exadata h a ฺ
ฺ b r) uide
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
o Te lic
ic
Tecn

Visão Geral da Manutenção do Database Machine
• A manutenção do Database Machine é semelhante à de

qualquer outro ambiente clusterizado do Oracle Database

• Tarefas específicas do Database Machine descritas nesta
lição:
– Ligar e desligar o Database Machine
– Fazer shutdown de um único Exadata Storage Server
com segurança
– Substituir um disco físico danificado em uma célula
r a ble
– Substituir uma placa flash danificada em uma célula
n s fe
– Mover todos os discos de uma célula para outra -tra
– Usar o procedimento de resgate do software de n n
océlula
a
do Exadata as ) h eฺ
• Outras referências: r
ฺ Guid
b
m
– Oracle Exadata Database Machine
k o ฺco denOwner's t Guide
– My Oracle Support tei tu
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Teaspectos,lica manutenção do Exadata Database Machine é semelhante à de
Sob vários
o
e c nic outro ambiente clusterizado do Oracle Database. Os procedimentos para
qualquer
T manutenção do Oracle Clusterware, do Oracle ASM e do Oracle RAC são essencialmente os
mesmos no Database Machine e em outras plataformas; a principal diferença são as
referências aos objetos de célula do Exadata.
Esta lição se concentra em várias tarefas de manutenção específicas do Database Machine
que os administradores provavelmente precisarão executar. Outras tarefas de manutenção
menos comuns também estão documentadas no Oracle Exadata Database Machine Owner's
Guide. Os administradores também devem consultar as notas do My Oracle Support sobre
outras questões relacionadas à manutenção.
Observação: as diretrizes sobre patches do Exadata Database Machine são abordadas em
uma outra lição mais adiante no curso.

Ligando e Desligando o Database Machine
• Sequência de desativação:
1. Servidores de banco de dados

# <Grid_Home>/bin/crsctl stop cluster
# shutdown -h -y now
—Verifique se foi efetuado shutdown de todos os servidores de

banco de dados antes de continuar
2. Exadata Storage Servers
# shutdown -h -y now
le
Verifique se foi efetuado shutdown de todos os servidores de rab
—
armazenamento antes de continuar n s fe

a
3. Rack, incluindo switches de rede n-tr no
• Sequência de ativação: a
1. Rack, incluindo switches de rede
) h as ฺ
— Aplique energia por alguns minutos antes
m ฺbr deGcontinuar
u ide
2. Exadata Storage Servers
o ฺ co ent
— Verifique se todas as células
t k
ei estão t uemd execução antes de continuar
S
3. Servidores de banco
o r te@ de dados
t h is
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic recomendada para ligar e desligar o Database Machine.
Tea sequência
O slideolista
ic
TecAonexecutar qualquer uma das duas sequências, é importante concluir totalmente cada etapa
antes de passar para a seguinte. Se as etapas não forem executadas na ordem adequada, o
Database Machine poderá não funcionar corretamente.
Ao ligar os Exadata Storage Servers e os servidores de banco de dados, aplique energia
pressionando o botão liga/desliga na parte frontal de cada servidor ou efetuando login na
interface ILOM de cada servidor e executando o comando reset /SYS.
Para ligar ou desligar o rack, use os switches localizados nas PDUs (Power Distribution
Units) que se encontram na parte posterior do rack.

Fazendo Shutdown de um Único
Exadata Storage Server com Segurança
• Sequência de shutdown seguro:
1. Verifique se o shutdown do servidor de armazenamento não fará com que

qualquer grupo de discos ASM fique off-line
CellCLI > LIST GRIDDISK WHERE asmdeactivationoutcome != ’Yes’
2. Desative todos os discos de grade

CellCLI> ALTER GRIDDISK ALL INACTIVE
3. Verifique se todos os discos de grade estão inativos

le
rab
CellCLI> LIST GRIDDISK WHERE STATUS != 'inactive'
4. Faça shutdown do servidor de armazenamento fe

• Sequência de inicialização: tr a ns
n -
1. Inicie o servidor de armazenamento no a
— Os serviços de célula iniciam automaticamente a
h eฺ s
2. Ative todos os discos de grade r
ฺ Guid
b )
CellCLI> ALTER GRIDDISK ALL ACTIVEom
ฺc estão
ograde e n t
3. Verifique se todos os discos ide
t k
e Sname, t ud asmmodestatus
ativos
te@ this
CellCLI> LIST GRIDDISK ATTRIBUTES
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
Tecenárioslde
Em alguns ic manutenção, é necessário fazer shutdown de um único Exadata
o
e c nic Server isoladamente. Por exemplo, um componente de hardware, como uma placa
Storage
T de memória flash ou uma controladora de disco, poderá apresentar um sinal de falha
intermitente, tornando necessário fazer shutdown do servidor de armazenamento para
substituir esse componente enquanto o restante do sistema continua a suportar as
transações de negócios. Nesses casos, o resultado desejado é que o ambiente do Database
Machine continue a suportar as atividades de processamento sem que haja um impacto
significativo nos usuários do sistema.
Para fazer um shutdown seguro e normal (graceful) de um único Exadata Storage Server,
use os comandos mostrados no slide. Ao verificar se o shutdown do servidor de
armazenamento não colocará nenhum grupo de discos ASM off-line, você não deverá ver
qualquer saída do primeiro comando LIST GRIDDISK. Se uma saída for retornada, isso
indicará que não será seguro desativar o Exadata Storage Server porque a redundância
apropriada do grupo de discos Oracle ASM não será mantida. A desativação do Exadata
Storage Server quando um ou mais discos de grade se encontram nesse estado fará com
que o ASM desmonte o grupo de discos afetado, resultando no shutdown abrupto dos
bancos de dados. Nesse caso, você precisará analisar a situação e colocar outros discos de
grade on-line para continuar com segurança.
Após o Exadata Storage Server ser reiniciado e os discos de grade serem reativados, você
deverá verificar se todos os discos de grade retornam a um asmmodestatus igual a ONLINE
ou UNUSED.
Substituindo um Disco Físico Danificado
1 Determine o disco danificado.

CellCLI> LIST ALERTHISTORY -

WHERE ALERTMESSAGE LIKE "Logical drive lost.*" DETAIL
Logical drive lost. Lun:0_5. Status: normal. Physdisk: 20:5.
Celldisk on it: CD_05_cell01. Griddisks on it: data_CD_05_cell01.
The suggested action is: Refer to section Maintaining Physical Disks in
the User Guide.
le
2 Substitua o
disco físico. fe rab
tr ns
a NORMAL
ALTER PHYSICALDISK 20:5 SERVICELED ON n
LIST PHYSICALDISK -
no a
3 Monitore o ASM para confirmar a nova inclusão do)disco. a
h eฺ s
r
ฺ Guid
b
SQL> SELECT NAME, STATE FROM V$ASM_DISK om
k o ฺc dent
SQL> SELECT * FROM GV$ASM_OPERATION
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Te de umlicdisco físico devido a um problema ou falha é provavelmente a operação
A substituição
o
ic
denmanutenção de hardware mais comum exigida por um Exadata Storage Server. Supondo
Tecque você esteja usando a redundância do ASM, o procedimento para substituir um disco com
problemas é muito simples.
A primeira etapa exige que você identifique o disco com problemas. This could occur in a
number of ways:
• O monitoramento do hardware com o ILOM pode reportar um disco com problemas.
• Se ocorrer uma falha em um disco, o alerta do Exadata será gerado. The alert includes
specific instructions for replacing the disk. Se você tiver configurado o sistema para
notificações de alerta, o alerta será enviado ao endereço de e-mail designado ou ao
destino SNMP. O comando LIST ALERTHISTORY também poderá ser usado para
identificar um disco com falha.
• O comando LIST PHYSICALDISK poderá identificar um disco que apresenta um
status anormal. Mesmo que a célula ainda esteja funcionando, o problema poderá ser
um precursor de uma falha no disco.
• O comando CALIBRATE pode identificar um disco que esteja produzindo IOPS ou
throughput muito baixo. Mesmo que a célula ainda esteja funcionando, um único disco
físico com problemas poderá prejudicar o desempenho de outros discos em bom
estado. Dessa forma, você pode optar por substituir o disco identificado. Observe que a
execução de CALIBRATE enquanto a célula estiver ativa afetará o desempenho.
Você pode usar o comando ALTER PHYSICALDISK para acender um LED de serviço que
ajuda a converter corretamente o nome do disco no local do disco físico correspondente.
Quando há uma falha em um disco, os discos Oracle ASM associados aos discos de grade
no disco físico são automaticamente eliminados com a opção FORCE, e há um
rebalanceamento do Oracle ASM para restaurar a redundância dos dados. Esse processo é
conhecido como quarentena de disco proativa.
Se desejar substituir um disco com desempenho insatisfatório, mas que não foi isolado pela
quarentena de disco proativa, você deverá eliminar manualmente os discos de grade
associados usando o comando ALTER DISKGROUP ... DROP DISK.
Após identificar o disco com problema, você poderá substituí-lo. Ao remover o disco, você
obterá um alerta. Na substituição de um disco físico, ele deverá ser reconhecido pela
controladora RAID para que possa ser usado. Esse processo não é demorado, e você pode
usar o comando LIST PHYSICALDISK para monitorar o status até que ele retorne a
NORMAL.
Os discos de grade e os discos de célula existentes no disco anterior no slot serão
automaticamente le
recriados no novo disco. Se esses discos de grade faziam parte de um grupo de discos do
fe rab
tr a ns
Oracle ASM com redundância NORMAL ou HIGH, eles serão adicionados de volta ao grupo de
-
discos, e os dados serão rebalanceados com base na redundância do grupo de discos e no
n
parâmetro asm_power_limit. no
a
a s
A recriação do disco ASM e o rebalanceamento dos dados poderão levar algum tempo para
h eฺ
r )
ฺ Guid
serem concluídos. Você pode monitorar o andamento dessas operações no ASM. É possível
b
m
monitorar o status do disco conforme reportado pelo V$ASM_DISK.STATE até que ele
o ฺco dent
retorne para NORMAL. Você também pode monitorar o andamento do rebalanceamento
k
usando GV$ASM_OPERATION. t ei Stu
Analise as considerações a seguir o r teao@substituir
t h is um disco com falhas:
s p uspelo
ueliminado e ASM, e é possível que a operação de
• O disco pode ter sido ฺ
ectenha to executada com êxito. Verifique os logs de alerta do Oracle
(
rebalanceamentot e sido
s Após a substituição do disco com falha, um segundo
ASM e i
parakoconfirmar
c e nisso.
li será necessário.
o T
rebalanceamento
e c n• icO disco pode ter sido eliminado, e é possível que a operação de rebalanceamento
T ainda esteja em execução. Verifique a view GV$ASM_OPERATION para determinar se a
operação de rebalanceamento ainda está em execução. Nesse caso, a operação de
rebalanceamento após a substituição do disco será colocada na fila.
• O disco pode ter sido eliminado pelo ASM e pode ter ocorrido uma falha na operação
de rebalanceamento. Verifique GV$ASM_OPERATION.ERROR para determinar a causa
da falha na operação de rebalanceamento. Monitore a operação de rebalanceamento
após a substituição do disco para assegurar sua execução.
• Operações de rebalanceamento de vários grupos de discos poderão ser feitas em
diferentes instâncias do Oracle ASM no mesmo cluster se o disco físico que estiver
sendo substituído contiver discos de grade de vários grupos de discos. Não é possível
executar várias operações de rebalanceamento simultaneamente em apenas uma
instância do Oracle ASM. As operações serão colocadas em fila para a instância.

Substituindo uma Placa Flash Danificada
1 Determine a placa flash danificada.

CellCLI> LIST PHYSICALDISK DETAIL

name: [9:0:2:0]
diskType: FlashDisk
...
slotNumber: "PCI Slot: 1; FDOM: 2"
status: critical
le
2
Encerre
a célula. 3
Substitua a
placa flash. 4
Ative
a célula.fe rab
tra ns
n -
Se a placa continha um disco de grade baseado em flash,
no a
5 monitore o ASM para confirmar a nova inclusão do disco. a
h eฺ s
b r ) id
SQL> SELECT NAME, STATE FROM V$ASM_DISK mฺ u
SQL> SELECT * FROM GV$ASM_OPERATION ฺc
o nt G
k o e
t ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Storage Server é equipado com quatro placas de memória flash PCI.
Te Exadata
Cada servidor
o
e c nicplaca tem quatro módulos flash (FDOMs) para um total de 16 módulos flash em cada
Cada
célula.
T A identificação de um módulo flash danificado é similar à identificação de um disco físico
danificado. O monitoramento de hardware usando o ILOM ou uma diminuição do
desempenho indicado pelo comando CALIBRATE pode indicar um problema. Se um FDOM
com falhas for detectado, um alerta será gerado. A mensagem de alerta inclui um aviso sobre
a presença de discos de grade baseados em flash no módulo flash.
Como mostrado no slide, um módulo flash danificado também pode ser relatado usando o
comando LIST PHYSICALDISK DETAIL. O atributo slotNumber mostra o slot PCI e o
número de FDOM. Neste exemplo, o atributo status indica uma falha crítica.
Se não havia discos de grade no módulo flash, provavelmente o módulo estava sendo usado
para o Exadata Smart Flash Cache. Nesse caso, o módulo flash com falhas resulta em uma
quantidade menor de memória flash na célula. O desempenho da célula é afetado
proporcionalmente ao tamanho da memória flash perdida, mas o banco de dados e os
aplicativos não apresentam risco de falha.
Embora tecnicamente os slots PCI de um Exadata Storage Server contem com o recurso "hot
swap", é recomendável desativar a célula ao substituir uma placa flash danificada.
Após a substituição da placa e a ativação da célula, nenhuma etapa adicional será
necessária para recriar os discos de grade baseado em flash; entretanto, você deverá
monitorar o ASM para confirmar a nova inclusão de quaisquer discos de grade baseados em
flash e verificar se todas as operações de rebalanceamento foram concluídas com êxito.
Movendo Todos os Discos de uma
Célula para Outra
Original Novo Original Novo
1. Desative os discos de grade:

CellCLI> ALTER
CellCLI> ALTER GRIDDISK
GRIDDISK ALL INACTIVE
ALL INACTIVE
2. Faça backup dos arquivos de configuração do sistema operacional
que poderão ser alterados quando a nova célula for inicializada.
3. Mova os discos da célula original para a nova célula.
– Certifique-se de que os discos do sistema ocupem os dois primeirosrab
le
e
slots. nsf tra
4. Inicialize a nova célula.
n on-
5. Reinicialize os serviços de célula do Exadata:as a
h ฺ
CellCLI> ALTER
CellCLI> ALTER CELLCELL RESTART
RESTART
br)ALL ideALL
SERVICES
SERVICES
mฺ
6. Importe os discos de célula: ฺco dent Gu
k o
CellCLI> IMPORT
CellCLI> IMPORT teiALL SALL
CELLDISK
CELLDISK tu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic mover todas as unidades de um servidor de armazenamento para
Tenecessário
Talvezoseja
n ic Isso pode ser necessário quando há uma falha em um componente no nível do chassi
outro.
c
e
T ou quando você está solucionando um problema no hardware. Para mover as unidades,
execute as etapas a seguir:
1. Se possível, use o comando ALTER GRIDDISK ALL INACTIVE para desativar os
discos de grade.
2. Se possível, faça backup de /etc/hosts, /etc/modprobe.conf e dos arquivos em
/etc/sysconfig/network e /etc/sysconfig/network-scripts. Essa é
sobretudo uma etapa preventiva e também será útil caso você deseje mover os discos
novamente para o chassi original.
3. Faça shutdown do servidor original e mova os discos para o novo servidor.
Cuidado: verifique se os dois primeiros discos, que são os discos do sistema, estão
nos mesmos dois primeiros slots. Se esse procedimento não for executado, o Exadata
Storage Server não funcionará corretamente.
4. Inicie a célula. O sistema operacional da célula será configurado novamente de forma
automática para se ajustar ao novo hardware de servidor.
5. Reinicialize os serviços de célula usando ALTER CELL RESTART SERVICES ALL.
6. Importe os discos de célula usando IMPORT CELLDISK ALL.
Se você estiver usando a redundância do ASM e o procedimento for concluído antes do
período especificado no parâmetro DISK_REPAIR_TIME de inicialização do ASM, os discos
ASM serão automaticamente ativados e atualizados com todas as alterações feitas durante a
interrupção da célula.

Usando o Procedimento de Resgate do Software
de Célula do Exadata
• Todos os Exadata Storage Server são equipados com uma
unidade flash USB CELLBOOT para facilitar o resgate da célula

– Necessário se os dois discos do sistema falharem simultaneamente
– Siga o procedimento com extremo cuidado
• Para executar o resgate da célula:
1. Estabeleça conexão com o Exadata Storage Server usando a
console
2. Reinicialize a célula e, assim que vir a tela de abertura "Oracle
r a ble
Exadata", pressione qualquer tecla do teclado
n s fe
3. Na lista exibida de opções de inicialização, selecione a última
n - tra
alternativa, CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode,
e pressione Enter a no
4. Selecione a opção de resgate e continue ) h
com
aso procedimento
ฺ
b r i d e
ฺ seGaucélula é inicializada
5. No final do processo de resgate, o m
verifique
a partir dos discos do sistema
k o ฺc dent
tei Stu
6. Configure a célula novamente
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic mantém áreas do sistema espelhadas em discos físicos
TeStorage lServer
O Exadata
o
ic
ecn
separados. Se uma área do sistema for danificada ou ficar indisponível, a cópia espelhada
T será usada para fins de recuperação.
Na rara possibilidade de falha simultânea dos dois discos do sistema, você deverá usar a
funcionalidade de resgate fornecida na unidade flash USB CELLBOOT incorporada em todos
os Exadata Storage Servers.
É importante observar as recomendações a seguir ao usar o procedimento de resgate:
• Execute esse procedimento com extremo cuidado e preste atenção aos prompts. O
procedimento de resgate pode regravar alguns ou todos os discos da célula. Se isso
acontecer, você poderá perder de forma irrevogável o conteúdo desses discos. O ideal
é usar o procedimento somente com a assistência do Oracle Support Services.
• O procedimento de resgate não destrói o conteúdo dos discos de dados, nem o
conteúdo das partições de dados dos discos do sistema, a menos que você opte por
fazê-lo durante o procedimento.
• O procedimento de resgate restaura a mesma release do software do Exadata Storage
Server. Isso inclui qualquer patch existente na célula na última inicialização bem-
sucedida.

• Os itens a seguir não devem ser restaurados com o procedimento de resgate:
- Os rpms de suporte a kernel de falhas kernel-debuginfo-common e kernel-
debuginfo. Você precisará instalá-los novamente. Eles não podem ser
restaurados devido a limitações de espaço na unidade flash USB CELLBOOT.
- Alguns detalhes da configuração da célula, como as configurações de alertas,
informações de SMTP e o endereço de e-mail do administrador. Observe que a
configuração da rede da célula é restaurada, juntamente com as entidades SSH
da célula, e os usuários root, celladmin e cellmonitor.

- Configurações do ILOM. Em geral, as configurações do ILOM permanecem
inalteradas mesmo em caso de falhas no software do Exadata.
• O procedimento de resgate não examina nem reconstrói discos de dados nem partições
de dados nos discos do sistema. Se houver corrompimento de dados nos discos de
grade, não use o procedimento de resgate. Use procedimentos de backup e
recuperação do banco de dados.
As opções de resgate a seguir estão disponíveis para o procedimento de resgate:
le
• Recuperação de reconstrução parcial: Durante a recuperação de reconstrução parcial,
fe rab
tra ns
o processo de resgate recria partições nos discos do sistema e verifica a existência de
um sistema de arquivos nos discos. Se for descoberto um sistema de arquivos, o
n -
a no
processo tentará uma reinicialização. Se a célula for inicializada com êxito, use os
comandos CellCLI, como LIST CELL DETAIL, para verificar se a célula pode ser
a s
utilizada. Também é necessário recuperar discos de dados, conforme apropriado. Se
h eฺ
r )
ฺ Guid
houver falha na inicialização, use a opção de recuperação completa original
b
incorporada. m
o ฺco dent
• Recuperação completa original incorporada: essa opção regrava a área do sistema dos
k
t ei Stu
discos do sistema para restaurar o software do Exadata. Ela também permite apagar
o r te@ this
dados nos discos e nas partições de dados nos discos do sistema.
ฺ s up use
• Recriação da unidade flash USB CELLBOOT: essa opção é usada para fazer uma
( t ec se to
cópia da unidade flash USB CELLBOOT.
e i ko licen
Para executar um resgate usando a unidade flash USB CELLBOOT:
T
1. Estabeleça conexão com o Exadata usando a console.
o
ic
ecn
2. Reinicialize a célula e, assim que vir a tela de abertura "Oracle Exadata", pressione
T qualquer tecla do teclado. A tela de abertura permanece visível apenas por cinco
segundos.
3. Na lista exibida de opções de inicialização, vá para a última alternativa,
CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode, e pressione Enter.
4. Selecione a opção de resgate e continue com o procedimento.
5. Quando solicitado no final do processo de resgate, proceda da seguinte maneira:
a. Escolha a opção para entrar em um shell. Não escolha a opção de reinicialização
neste momento.
b. Execute o comando reboot no shell.
c. Durante a reinicialização, mas antes da exibição da tela de abertura "Oracle
Exadata", pressione F8 para acessar o menu de seleção do dispositivo de
inicialização.
d. Selecione a controladora RAID como o dispositivo de inicialização.
6. Após um resgate bem-sucedido, é necessário configurar novamente a célula para
recuperar a configuração antes da falha e reinstalar os rpms kernel-debuginfo e
kernel-debuginfo-common para usar o suporte a kernel de falhas. Se você optar
por manter os dados ao ser consultado pelo procedimento de resgate, importe os
discos de célula. Se optar por não mantê-los, crie novos discos de célula e de grade.

Questionário
Antes do shutdown de um Exadata Database Machine, é

necessário fazer shutdown dos Exadata Storage Servers:

a. Verdadeiro
b. Falso
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
e c nic
T

Questionário
É necessário fazer shutdown de um Exadata Storage Server

para substituir componentes de hardware danificados

diferentes de unidades de disco rígido:
a. Verdadeiro
b. Falso
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tae
e c nic as placas de memória flash do Exadata Storage Server contem com o recurso "hot
Embora
T swap", a Oracle recomenda fazer shutdown das células para substituir os componentes de
hardware no chassi.

Questionário
Se ocorrer falha em um disco do Exadata Storage Server,

quais das seguintes afirmações são verdadeiras?

a. Os discos de grade ASM associados serão
automaticamente eliminados e ocorrerá um
rebalanceamento do ASM para restaurar rapidamente a
redundância
b. O disco poderá ser substituído sem que seja feito
r a ble
shutdown do servidor de armazenamento n s fe
a
c. Será necessário fazer shutdown do servidor deon-tr
armazenamento para substituir o disco s a n
)
d. Várias instâncias ASM poderão participar
r ha daeoperação
ฺ de
b
ฺ Gu i d
rebalanceamento de um único m
ฺcogrupontde discos
k o ude
t e i t
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Resposta:
o Ta,e b lic
e c nic
T

Resumo
Nesta lição, você aprendeu a executar as seguintes tarefas de

manutenção do Database Machine:

• Ligar e desligar o Database Machine
• Fazer shutdown de um único Exadata Storage Server com
segurança
• Substituir um disco físico danificado em uma célula
• Substituir uma placa flash danificada em uma célula r a ble
• Mover todos os discos de uma célula para outra tran
sfe
• Usar o procedimento de resgate do software n
de
n- do
océlula
s a
Exadata h a ฺ
ฺ b r) uide
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
o Te lic
ic
Tecn

Tecn
ic
oT e i
( t
ฺ s
ko licen
o r
ec se to
t
up use
k o
te@ this
ei Stu
m b r )
ฺco dent
a s
ฺ Guid
a
h eฺ
no n - tr
a
ns fe rab
le
Aplicando Patches no Exadata Database Machine
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos

• Descrever como o software é mantido em diversos

componentes do Database Machine
• Localizar os patches recomendados para o Database
Machine
• Descrever o processo de aplicação de patches
recomendado para o Database Machine r a ble
e
nsf
• Descrever as características de um sistema de testeraeficaz
t
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral de Patches e Atualizações
• Há três categorias de software que devem ser mantidos

no Database Machine:
– Software e firmware nos Exadata Storage Servers
– Software e firmware nos servidores de banco de dados
– Software e firmware de outros componentes, como os
InfiniBand switches, por exemplo
• A compatibilidade entre esses diferentes softwares precisa able
ser mantida s fer
t r a n
• Os patches e as atualizações são essencialmente
n on-
“dinâmicos” sempre que possível s a
) a
h My eOracle
ฺ
• As informações-chave são mantidas b r em i d
ฺ Gu
Support bulletin 888828.1 ฺcom t
i k o uden
@ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de softwares que devem ser mantidos no Database Machine, ou
Há três
o Te
categorias amplas
e c nico software e o firmware dos Exadata Storage Servers, dos servidores de banco de
seja,
T dados e de outros componentes, como os InfiniBand switches. A compatibilidade entre esses
diferentes softwares é essencial ao funcionamento do Database Machine.
Sempre que possível, os patches e as atualizações do Database Machine são
essencialmente "dinâmicos". Isso significa que eles facilitam a disponibilidade contínua do
sistema, pois são aplicados de forma "dinâmica" em um servidor de cada vez no ambiente,
não afetando todos os servidores ao mesmo tempo.
Informações importantes relacionadas aos patches e às atualizações do Database Machine
são mantidas em My Oracle Support bulletin 888828.1. Esse boletim é constantemente
atualizado com novas informações. A Oracle recomenda que todos os clientes do Database
Machine assinem um alerta automático que é emitido sempre que esse boletim é alterado.
O restante desta lição destaca recomendações adicionais relacionadas aos patches e às
atualizações do Database Machine.

Mantendo o Software do Exadata Storage Server
• Patches do Exadata Storage Server:

– São imagens completas de software

– Mantêm a consistência em todos os componentes da célula
– São lançados de forma independente dos patches do Oracle
Database
– Têm dependências de outras versões de software e
firmware
• A maioria dos patches do Exadata Storage Server pode rabl
e
ser aplicada enquanto os bancos de dados estão ativos n sefe
em execução n - tra
o
• a n são
Os níveis de firmware no Exadata Storages Server
mantidos automaticamente r ) ha eฺ
• m
Não é necessário instalar software
id RPMs etc. no
ฺbadicional,
u
co t G
Exadata Storage Server ikoฺ uden
@ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Storage Server são fornecidos como imagens completas de software
Tedo Exadata
Os patches
o
e c niccontêm atualizações do sistema operacional Linux, do software de servidor de célula, do
que
T software InfiniBand e do firmware de componentes. Isso permite manter a consistência entre
todos os componentes de software e firmware do Exadata Storage Server.
Os patches do Exadata Storage Server são fornecidos de forma independente dos do Oracle
Database Server. Entretanto, os patches do Exadata Storage Server podem exigir um nível
de patch específico do Oracle Database Server ou uma versão específica do sistema
operacional ou do firmware do servidor de banco de dados. Detalhes são fornecidos na
documentação do patch e em My Oracle Support bulletin 888828.1.
Em geral, os patches do Exadata Storage Server podem ser aplicados de forma dinâmica,
durante a execução do banco de dados. Um patch dinâmico é aplicado de forma sequencial
em cada servidor de armazenamento. O processo de patch dinâmico usa a redundância do
ASM para manter a disponibilidade dos grupos de disco enquanto cada servidor de
armazenamento é atualizado e reinicializado.
Os patches também podem conter instruções para instalação paralela em vários Exadata
Storage Servers. Embora essa abordagem exija um período de indisponibilidade (downtime),
ela poderá ser a preferencial se houver uma janela de tempo de manutenção programada
para o sistema.

O Exadata Storage Server mantém automaticamente o firmware no servidor. Os níveis de
firmware são verificados periodicamente durante a execução do Exadata Storage Server, e o
firmware correto é aplicado automaticamente aos componentes durante a reinicialização do
servidor. O firmware de disco é automaticamente atualizado na substituição de um disco.
A Oracle recomenda que nenhum software adicional (RPMs ou outro) seja instalado no
Exadata Storage Server.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Mantendo o Software do Servidor de Banco de Dados
• É possível aplicar patches e fazer atualizações do

software de servidor de banco de dados como seria feito

em um servidor Oracle Database fora do Database
Machine
– Patches do Oracle Database aplicados pelo OPatch
— Verificação atenta da compatibilidade dos patches com o
Database Machine
A Oracle fornece pacotes de patches para o Database Machine
—
le
— Pacote periódico de patches de banco de dados recomendado para
fe rab
o Database Machine
– Sistema operacional e firmware atualizados por meio a
trde ns
n -
canais comuns no a InfiniBand
— os
É necessário manter a consistência com a software
(OFED) r) h eฺ
ฺ Storageu b
i Server d
• Verifique se os patches do Exadata m G
o
contêm atualizações do sistema
k ฺco operacional
d e n t e do firmware
e i
t dados t u
do servidor de banco@de sS
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic aplicar patches e fazer atualizações do software de servidor de
Te é possível
Basicamente,
o
e c nic de dados usando as mesmas técnicas e abordagens empregadas em um servidor
banco
T Oracle Database fora do Database Machine.
O OPatch é usado para aplicar e gerenciar patches do Oracle Database. É recomendável
que você crie uma Solicitação de Serviço no Oracle Support para verificar a compatibilidade
dos patches com o Database Machine. Além de patches e atualizações regulares do banco
de dados, a Oracle fornece pacotes de patches periódicos para o Database Machine. Esses
pacotes contêm uma série de patches de banco de dados recomendados para uso com o
Database Machine. A Oracle recomenda aplicar os pacotes de patches como parte de sua
rotina de aplicação de patches.
Os patches do sistema operacional e de firmware devem ser gerenciados com as práticas de
patch padrão. O My Oracle Support bulletin 888828.1 lista as restrições e os requisitos atuais
para patches de sistema operacional e de firmware. A principal consideração é garantir que
qualquer patch ou atualização mantenha consistência com a versão do software OFED que
define a rede InfiniBand.
Alguns patches do Exadata Storage Server também incluem atualizações do firmware do
servidor de banco de dados e do sistema operacional. Isso pode ocorrer, por exemplo,
quando o firmware do HCA InfiniBand é atualizado no Exadata Storage Server, e a
atualização também deve ser aplicada aos servidores de banco de dados.

Aplicação de Patches Assistida Usando o OPlan
• O OPlan é um utilitário que fornece instruções passo a

passo de patch específicas para o ambiente de destino

– É capaz de criar instruções para aplicação do patch e para
sua reversão
• O OPlan opera em conjunto com os Bundle Patches
recomendados do Exadata Database Machine
– A partir do Bundle Patch 2 release 11.2.0.2
le
• Usando o OPlan:
fe rab
– Como o proprietário do software Oracle:
tra ns
—
n n-
Efetue download do Bundle Patch em um diretórioolocal
a e execute:
Defina a variável de ambiente $ORACLE_HOME
as ฺ
—
) h
ฺbr Guide
$ORACLE_HOME/oplan/oplan generateApplySteps <bundle patch location>
m
— Localize as instruções de instalação
o ฺ co enpersonalizada
t do patch em:
t eik Stud
$ORACLE_HOME/cfgtoollogs/oplan/<TimeStamp>/InstallInstructions.txt
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic que facilita o processo de instalação de patches fornecendo
O OPlan
o Té eum utilitário
e c nic passo a passo específicas para seu ambiente. O OPlan opera em conjunto com os
instruções
T Bundle Patches recomendados do Database Machine.
Sem o OPlan, os administradores devem ler a documentação do patch e converter as
instruções genéricas de instalação em comandos específicos adequados ao ambiente de
destino. Por exemplo, as referências ao diretório Oracle Home ou ao caminho para o
diretório de patch devem ser convertidas nos caminhos de diretório apropriados. Além disso,
os administradores talvez precisem escolher uma dentre várias opções e avaliar a
configuração do ambiente a fim de gerar o conjunto correto de comandos.
O OPlan ajuda os administradores analisando automaticamente o ambiente e coletando as
informações necessárias de configuração. Usando essas informações, o OPlan gera um
conjunto de instruções e comandos personalizados especificamente para a configuração de
destino. O OPlan pode criar a instrução necessária tanto para aplicar um patch como para
revertê-lo.
O utilitário OPlan está disponível para download em My Oracle Support, com o número de
patch 11846294. O OPlan suporta todos os Bundle Patches recomendados do Exadata
Database Machine a partir do Bundle Patch 2 release 11.2.02. Consulte My Oracle Support
bulletin 1306814.1 para obter mais informações sobre o OPlan.

Mantendo Outros Softwares
• Outros componentes do Database Machine que têm

software ou firmware:
– InfiniBand switches
– PDUs (Power Distribution Units)
– KVM switch
– Cisco Ethernet switch
• Consulte sempre o My Oracle Support bulletin 888828.1 rable
e
para obter os requisitos específicos do Exadata nsf tr a
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licdo Database Machine que têm software ou firmware incluem:
Te
Outrosocomponentes
e c n• icInfiniBand switches
T • PDUs (Power Distribution Units)
• KVM (Keyboard, Video and Mouse) switch
• Cisco Ethernet switch
O software e o firmware de todos os componentes devem ser sempre mantidos de acordo
com as diretrizes publicadas em My Oracle Support bulletin 888828.1. Isso é particularmente
importante no caso dos InfiniBand switches. Para outros componentes, os requisitos poderão
ser menos específicos.

Processo Recomendado de Aplicação de Patches
1. Examine a documentação do patch (arquivo README)

– Leia e entenda todas as instruções antes de continuar

2. Valide a instalação do patch em um sistema de teste
– Execute a ferramenta exachk antes e depois da aplicação do patch
– Automatize as etapas de aplicação do patch sempre que possível
– Teste o procedimento de failback
3. Valide a funcionalidade do patch em um sistema de teste
le
– Verifique se o patch fornece a funcionalidade desejada
fe rab
– Avalie o desempenho do sistema
tr a ns
4. Aplique o patch em produção n -
no
– Execute a ferramenta exachk antes e depois daaaplicação do patch
– Verifique a integridade de todas as células
) h as de
antes ฺ aplicar o patch
b r i d e
– Avalie o desempenho do sistema mฺ Gu
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic idênticos. Essa afirmação é verdadeira quer você esteja ou não
Te dois patches
Não existem
o
e c nic o Database
usando
aplicação de patches.
Machine. Portanto, você deve seguir sempre um processo metódico de
Veja a seguir uma descrição do processo recomendado para o
T Exadata Database Machine:
1. Examine o arquivo README do patch para se informar sobre problemas conhecidos,
instruções de instalação e desinstalação do patch e observações especiais.
2. Valide a instalação do patch em um sistema de teste adequado:
- Execute a ferramenta exachk para verificar o ambiente antes e depois da
aplicação do patch.
- Quando possível, automatize as etapas para reduzir erros humanos.
- Teste os procedimentos de fallback caso o patch deva ser revertido.
3. Valide a funcionalidade do patch no sistema de teste.
- Se estiver aplicando o patch para tratar de um problema específico, verifique se o
patch fornece a funcionalidade desejada.
- Verifique se não há regressões do desempenho, da disponibilidade ou das
operações. Faça um teste usando uma carga de trabalho representativa da carga
de trabalho de produção. Compare as métricas observadas durante o teste com
as de linha de base observadas na produção. O Real Application Testing poderá
ser usado para reproduzir uma carga de trabalho de produção no sistema de
teste. O AWR (Automatic Workload Repository) e o SQL Performance Analyzer
podem ser usados para avaliar o desempenho no sistema de teste.
4. Aplique o patch no sistema de produção.
- Execute a ferramenta exachk para verificar o ambiente antes e depois da
aplicação do patch.
- Verifique se todos os Exadata Storage Servers estão funcionando corretamente.
Isso é muito importante porque uma falha do servidor de armazenamento que
passe despercebida e que aparentemente não tenha impacto nas operações do
Database Machine poderá resultar na desativação dos grupos de discos e no
encerramento abrupto dos bancos de dados quando outro servidor de

armazenamento for colocado off-line para aplicação de um patch.
- Compare as métricas capturadas antes e depois da aplicação do patch para
avaliar o desempenho do sistema. O SQL Performance Analyzer poderá ser
usado para avaliar a melhoria ou a regressão do desempenho resultante do patch.
Consulte a lição Outras Ferramentas Úteis de Monitoramento e My Oracle Support note
1070954.1 para obter detalhes sobre a ferramenta exachk. le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Recomendações sobre o Sistema de Teste
• Um sistema de teste eficaz:

– É uma réplica exata do Database Machine de produção

– Não é usado para qualquer outra finalidade durante o teste
– Contém uma cópia completa do conjunto de dados de
produção com estatísticas idênticas
– É capaz de simular a concorrência e os volumes de
transações de produção
r a ble
– É capaz de comparar as métricas de carga de trabalho e sfe
desempenho do sistema de teste com as coletadas-tno r an
sistema de produção n on
s a
– Inclui os conjuntos de testes operacionais
) a
h dee ฺ
disponibilidade usados na produçãoฺ b r i d e
u om nt G
ฺ c
o ude
t e i k t
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic as recomendações para um ambiente de teste eficaz do Database
Te descreve
A listaoa seguir
e c nic
Machine:
T • Um sistema de teste deve ser uma réplica exata do Exadata Database Machine
principal, incluindo todos os sistemas stand-by para alta disponibilidade e recuperação
de desastres.
• Quando o sistema de teste é compartilhado para outras finalidades, como
desenvolvimento, um tempo exclusivo deve ser alocado para validação do patch.
• O sistema de teste deve conter uma cópia completa do conjunto de dados de produção
com estatísticas idênticas.
• Um framework de carga de trabalho, como o Real Application Testing, deve ser usado
para simular a concorrência e os volumes de transações de produção.
• Os dados do AWR devem ser coletados do banco de dados de produção para fins de
comparação com os dados do AWR coletados no sistema de teste.
• Todos os conjuntos de testes operacionais e de disponibilidade usados na produção
também devem ser aplicados no ambiente de teste.

Questionário
Qual das afirmações a seguir fornece uma perspectiva geral da

abordagem recomendada para aplicação de patches e

atualizações do Database Machine?
a. Todas as atualizações do Database Machine são
específicas ao Database Machine e são as únicas
atualizações que devem ser aplicadas a ele
b. Use ULN (Unbreakable Linux Network) para atualizar o
r a ble
Linux nos servidores de banco de dados e nos servidores n s fe
do Exadata e aplique atualizações específicas don-banco tra
de dados e do Exadata no software restantea n
o
c. Use pacotes de atualizações específicos ) h asao Exadata
ฺ para
ฺ b r i d e
servidores Exadata e use práticas G u
om dentatualização de
ฺ c
o osudservidores
e
banco de dados normais e ipara
k de banco de
t S t
dados te@ is
o r e th
suOracletoe/ouusuas
c ฺ
Copyright © 2012,
o (te nse
T e ik lice
Resposta:
n i co c
Tec

Resumo

• Descrever como o software é mantido em diversos

componentes do Database Machine
• Localizar os patches recomendados para o Database
Machine
• Descrever o processo de aplicação de patches
recomendado para o Database Machine r a ble
e
nsf
• Descrever as características de um sistema de testeraeficaz
t
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
– Aplicação de Patches Dinâmicos do Exadata Storage Server

– Reversão de Patches do Exadata Storage Server
– Database Machine and Exadata Storage Server 11g
Release 2 (11.2) Supported Versions
– Oracle Software Patching with OPLAN
r a ble
e
nsf
– Oracle Exadata Database Machine exachk or HealthCheck
tr a
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Ecossistema de Suporte Automatizado do

le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos

• Descrever a função ASR (Auto Service Request) e como

ela está relacionada ao Exadata Database Machine
• Descrever os requisitos de implementação do ASR
• Descrever o processo de configuração do ASR
• Descrever o OCM (Oracle Configuration Manager) e como
ele está relacionado ao Exadata Database Machine r a ble
e s f
tra n
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Visão Geral de Auto Service Request
• Abre, de forma automática e segura, solicitações de serviço

na Oracle relativas a falhas comuns de hardware do
servidor
– O mínimo de dados é coletado e transmitido
– Nenhum endereço IP é transmitido
– São usadas comunicações criptografadas SSL unidirecionais
(do cliente para a Oracle)
• Permite resolver falhas de hardware com rapidez e precisão
– Disponibilidade aperfeiçoada, período de indisponibilidade rab
le
e
(downtime) menor nsf ra
• -t
Pode ser integrado às ferramentas de monitoramento
o n
existentes a n
s ha SRepor
– O ASR Manager pode enviar notificações
r ) d ฺ meio de
b i
deฺ monitoramento
traps do SNMP às ferramentasm Gu
o existentes
t
• oฺc udeeno
Incluído na garantia de hardware
i k n Oracle Premier
Support for Systems@te s St
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Te ServicelicRequest) é uma solução de software segura, escalável e instalada pelo
O ASRo(Auto
e c nic disponível como um recurso da sua garantia de hardware Oracle ou Sun; ele também
cliente,
T está disponível com o Oracle Premier Support for Systems ou com um plano de suporte
válido da Sun. O software ASR ajuda a resolver problemas com mais rapidez, usando a
geração de caso automática para sistemas de armazenamento e servidor Sun da Oracle na
ocorrência de falhas específicas de hardware.
Com o lançamento da versão 11.2.1.3.1 do software do Exadata, a funcionalidade ASR foi
ampliada para o Exadata Database Machine. O ASR abre automaticamente solicitações de
serviço (SRs) no Oracle Support quando ocorrem falhas específicas de hardware, seja nos
Exadata Storage Servers ou nos servidores de banco de dados. Observe que, no momento,
o ASR é aplicável somente às falhas de hardware detectadas nos seguintes componentes de
servidor: CPUs, controladoras de discos, discos, placas flash, módulos flash, placas
InfiniBand, módulos de memória, placas de sistema, fontes de alimentação e ventoinhas.

O Processo do ASR
Centro de Dados do Cliente Oracle Support Services

FRU substituída por

Engenheiro de Campo
Engenheiro do
Oracle Support
Engenheiro de FRU (Field

Campo da Replaceable Unit)
Oracle enviada pelo
Engenheiro de
Suporte Solicitação
de Serviço
Ocorrência direcionada
le
rab
da falha para o
Cliente Notificação enviada
e
Engenheiro
f
ao cliente por email
sobre a criação da SR
tr a ns
de Suporte
n - Sistema de
no
Gerenciamen
to de Casos
s a da Oracle
) a
h eฺ
ASR
Manager b r
ฺ Guid Solicitação de
Serviço do
Trap do SNMP enviada
m
Telemetria da
o nt
ASR
ao ASR Manager
ฺcsegura
falha transmitida
k o e
Serviço (SR) criada
eipara a Oracleud
de forma
t S t
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c o processo do ASR. Ele mostra como uma solicitação de serviço
Tedo slideliilustra
O diagrama
o
icé automaticamente aberta pelo ASR Manager depois que ele recebe uma trap do SNMP
ecn
(SR)
T disparada por uma falha de hardware. No Oracle Support Services, a solicitação de serviço
automática é confirmada via e-mail e atendida de acordo com os procedimentos normais.
Os clientes devem observar que há ocasiões em que uma SR não é registrada de forma
automática. Isso pode acontecer devido à perda de conectividade com o ASR manager, por
exemplo. A Oracle recomenda que os clientes continuem a monitorar seus sistemas em
relação a falhas e entrarem em contato com o Oracle Support se notarem uma falha, mas
não receberem uma notificação de que uma solicitação de serviço foi registrada
automaticamente.

Requisitos do ASR
• Um servidor capaz de executar o ASR Manager:

– Um ASR Manager existente (versão 2.7 ou superior) pode ser

usado para monitorar o Database Machine
– Um servidor de banco de dados do Database Machine pode ser
usado como o ASR Manager (não recomendado)
• Conectividade entre o ASR Manager e a rede de gerenciamento
do Database Machine
• Conectividade HTTPS (diretamente ou via proxy) do ASR r a ble
Manager com o Oracle Support n s fe
• Conta do My Oracle Support com informações de contato n - tra
a
atualizadas para todos os ativos do Database Machineno
• SOA (Sun Online Account) ) h as ฺ
m ฺ br uide
•
o ฺ co enout G
Software do Exadata versão 11.2.1.3.1 posterior nos
eik e nos
servidores de banco de dados udExadata Storage Servers
t S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
lic para usar o ASR com o Database Machine.
Teos requisitos
O slideolista
nic Hardware and Network Configuration Recommendations for ASR em
ecConsulte
T http://www.oracle.com/technetwork/server-storage/asr/overview/hardware-recommendations-
330108.html para obter mais detalhes sobre os requisitos de servidor do ASR Manager.
Ao verificar se o software correto do Exadata está presente nos servidores de banco de
dados do Database Machine, verifique se o seguinte arquivo existe:
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl
Se o arquivo estiver ausente, atualize os servidores de banco de dados usando o Bundle
Patch atual.
Por default, a configuração do ASR é executada pelos engenheiros da Oracle como parte da
instalação e da configuração iniciais do Exadata Database Machine. Os clientes podem optar
por não configurar o ASR, entretanto, isso não é recomendado pela Oracle. A próxima seção
desta lição descreve o processo de configuração do ASR. Esse processo pode ser usado
pelos clientes existentes do Exadata para configurar o ASR após a instalação do Exadata
Database Machine ou simplesmente como uma referência rápida para que eles entendam
melhor o processo de configuração do ASR.

Configurando o ASR Manager
1. Instale os componentes do ASR Manager:

– Oracle STP (Service Tools Bundle)

– Tags de Serviço
– Pacote SAMS
– Pacote ASR
2. Registre o ASR Manager:
le
– Como root no servidor do ASM Manager, execute:
fe rab
# asr register
tra ns
on-
Siga os prompts e forneça as informações solicitadas
an
—
– Para verificar o status do registro, execute:

as
r ) h eฺ
# asr show_reg_status
m ฺ Guid
b
– Para testar a conectividadeฺde
o co rede, e n t
execute:
# asr test_connection t k
ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licnovo servidor do ASR Manager consiste em duas tarefas principais:
Te de um
A configuração
o
ic
Tecn1. Instalar os componentes do software ASR Manager
2. Registrar o ASR Manager
O procedimento para instalação dos componentes do software ASR Manager varia
dependendo da versão do produto e da plataforma selecionada para executá-lo. Consulte a
documentação do ASR em http://www.oracle.com/technetwork/server-
storage/asr/documentation/index.html para obter um guia de instalação detalhado. Um guia
de instalação rápida chamado Oracle Exadata Quick Installation Guide for ASR também pode
ser encontrado no mesmo local.

Configurando o Exadata Database Machine
para o ASR
1. Configure os destinos de traps do SNMP:
– Como root em cada servidor de banco de dados, execute:

# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers \
> "(type=asr,host=<ASR Manager>,port=162,community=public,)"
– Como root ou celladmin em cada Exadata Storage Server,

execute:
CellCLI> alter cell snmpsubscriber = -
> ((host='<ASR Manager>', port=162, community=public, type=ASR))
le
2. Verifique os assinantes SNMP do ASR: fe rab
a ns
n-tr
– Como root em cada servidor de banco de dados, execute:
no
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -get_snmp_subscribers \ a
> -type asr
) h as ฺ
– Como root ou celladmin em cada m br uStorage
ฺExadata ide Server,
execute: o ฺ co ent G
t
CellCLI> list cell attributes snmpsubscriber eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de dados do Exadata Database Machine e Exadata Storage Server
Cada o Te de banco
servidor
e c nicser configurado para enviar traps do SNMP ao servidor do ASR Manager. Use os
deve
T comandos mostrados no slide para configurar e verificar os destinos necessários de traps do
SNMP.
Nos comandos, todas as referências a <ASR Manager> devem ser substituídas pelo nome
do host ou pelo endereço IP do servidor do ASR Manager.
Lembre-se de que a configuração de assinante SNMP é necessária para todos os servidores
de banco de dados e Exadata Storage Servers do Database Machine. Se preferir, você
poderá usar o utilitário dcli para executar a configuração simultaneamente em vários
servidores. Por exemplo, o comando a seguir poderá ser usado para executar a configuração
de assinante SNMP em todos os servidores de armazenamento listados no arquivo
cell_group:
# dcli -g cell_group -l celladmin -n "cellcli -e \
> alter cell snmpsubscriber=$\(host=<ASR Manager>, \
> port=162, community=public, type=ASR$\)"

Ativando Ativos do ASR
• Como root no servidor do ASR Manager:

– Ative o host do ASR Manager:

# asr activate_asset -i <ASR Manager IP>
– Ative o ILOM em cada servidor de banco de dados e em
cada Exadata Storage Server do Database Machine:
# asr activate_asset -i <Asset ILOM IP>
– Ative cada servidor de banco de dados e cada Exadata bl e

e r a
Storage Server do Database Machine: nsf tr a
# asr activate_exadata -i <Asset IP> \ n -
> -h <Asset hostname> -l <Asset ILOM IP> no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Te os comandos
O slideomostra necessários para ativar os ativos do ASR. Todos os comandos
i c
n executados como root no servidor do ASR Manager. A ativação do host do ASR
são
T e c
Manager é uma operação que ocorre uma única vez, enquanto os outros comandos devem
ser executados uma vez para cada servidor de banco de dados e Exadata Storage Server do
Database Machine.
Nos comandos, <ASR Manager IP> deve ser substituído pelo endereço IP do servidor do
ASR Manager, <Asset ILOM IP> deve ser substituído pelo endereço IP da interface ILOM
do servidor de banco de dados ou de armazenamento, <Asset IP> deve ser substituído
pelo endereço IP da rede de gerenciamento do servidor de banco de dados ou de
armazenamento e <Asset hostname> deve ser substituído pelo nome de host do servidor
de banco de dados ou de armazenamento.

Aprovar e Verificar Ativos do ASR
• Aprove os ativos do Database Machine em My Oracle Support:

1. Clique na tab More... e depois em Settings

2. Clique em Pending ASR Activations na seção Settings à esquerda
3. Selecione um servidor do Database Machine na lista
4. Examine a janela ASR Activation – Asset
5. Clique em Approve para concluir a ativação
6. Repita as etapas 3, 4 e 5 até todos os ativos do Database
le
Machine serem ativados rab fe
• Verifique a configuração do ASR: n s
tra
– on-
Como root em cada servidor de banco de dados, execute:
n
a
as ฺ
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -validate_snmp_subscriber \
> -type asr
) h
r uide
– Como root ou celladmin em cada m ฺbExadataG Storage Server,
o t
execute:
i k oฺc uden
CellCLI> alter cell validate snmp type=ASR
@ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Teos ativoslicde servidor do Database Machine forem ativados no ASR Manager, os
Depoisoque
e c nic serão listados em My Oracle Support como ativações pendentes do ASR. Para
servidores
T concluir o processo de ativação, os servidores devem ser aprovados em My Oracle Support
por meio do seguinte processo:
1. Na home page de My Oracle Support, clique na tab More... e depois em Settings.
2. Clique em Pending ASR Activations no painel Settings do lado esquerdo da janela.
3. Selecione um servidor do Database Machine na lista.
4. Examine a janela ASR Activation – Asset. Atualize as informações relacionadas ao
ambiente do Database Machine conforme necessário.
5. Clique em Approve para concluir a ativação.
6. Repita as etapas 3, 4 e 5 até todos os ativos do Database Machine serem ativados.
Uma vez aprovados os ativos, a configuração do ASR será concluída e o sistema será
ativado. Para testar a configuração e verificar se ela funciona corretamente, execute os
comandos mostrados no slide. Toda vez que um comando de validação é executado, o
processo completo do ASR é testado, e uma mensagem é enviada à conta de e-mail SOA
(Sun Online Account) indicando que o serviço ASR do Oracle Support recebeu a mensagem
de teste. Nenhuma solicitação de serviço é aberta para solicitações de validação.

Visão Geral do Oracle Configuration Manager
O Oracle Configuration Manager coleta informações de

configuração que serão propagadas para o Oracle Support

• As vantagens são:
– Diagnóstico mais eficiente de problemas
– Geração mais fácil de relatórios de solicitações de serviço
• As informações de configuração podem ser transferidas
por upload para a Oracle de forma automática ou manual rable
• As informações de configuração permanecem n s fe
confidenciais n - tra
a no
• s
A Oracle recomenda o uso do OCM em aconjunto
h com o
) ฺ
Exadata Database Machine ฺbr uide
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
O OCM o (Oracle lic
Te Configuration Manager) coleta automaticamente informações de
i c
ecn
configuração de seu ambiente em intervalos regulares. Essas informações podem ser
T transferidas por upload para My Oracle Support. Isso ajuda a Oracle a manter informações
atualizadas sobre o ambiente, diagnosticar problemas de suporte com mais eficiência e
oferecer sistematicamente melhor suporte. É recomendável usar o OCM em conjunto com o
A Oracle recomenda que o OCM seja configurado de modo que as informações de
configuração possam ser automaticamente coletadas e transferidas por upload para o Oracle
Customer Configuration Repository e o My Oracle Support. Opcionalmente, as informações
podem ser transferidas por upload de forma manual por um administrador.
Nenhuma informação de negócios ou pessoal é coletada e transferida por upload, com
exceção das informações de contato usadas em caso de problemas de transmissão. Todas
as informações são mantidas estritamente confidenciais.
Observe que o OCM não é uma função do Grid Control e é fornecido separadamente do Grid
Control Configuration Management Pack.

Configurando o Oracle Configuration Manager
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lico ASR, a configuração do OSM é executada pelos engenheiros da
Da mesma
o Teforma que
e c nic como parte da instalação e da configuração iniciais do Exadata Database Machine.
Oracle
T Os clientes podem optar por não configurar o OCM, entretanto, isso não é recomendado pela
Oracle.
No caso dos clientes que desejam configurar o OCM em um Database Machine existente, a
maneira mais fácil é usar os recursos disponíveis na tab Collector, em My Oracle Support. O
slide mostra a interface apresentada aos usuários para ajudá-los a começar a usar o OCM.
Observe que o OCM Collector é instalado nos servidores de banco de dados do Database
Machine. Nenhum componente do OCM é instalado nos Exadata Storage Servers. Portanto,
selecione Linux x86-64 ou Oracle Solaris on x86-64 (64-bit) na lista drop-down Select
Platform, dependendo de como o Database Machine estiver configurado.

Questionário
A Oracle recomenda que o Auto Service Request Manager

seja configurado em um dos servidores do Exadata Database

Machine:
a. Verdadeiro
b. Falso
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
ic
OnASR Manager pode ser configurado em um servidor de banco de dados do Exadata, mas
c
T e isso não é recomendado.

Questionário
O ASR criará uma solicitação de serviço para o Oracle Support

quando quais das seguintes situações ocorrerem?

a. Uma falha de disco em um servidor de armazenamento
b. Um erro ORA-600 em um servidor de banco de dados
c. Uma problema em uma fonte de alimentação de um
servidor
d. Uma falha de hardware na ventoinha de um servidor r a ble
n s fe
e. Todas as opções acima tra
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Resposta:
o Ta,e c, d lic
e c nic
T

Questionário
O Grid Control Configuration Management Pack é necessário

para usar o Oracle Configuration Manager:

a. Verdadeiro
b. Falso
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
ic
OnOracle Configuration Manager não é uma função do Grid Control e independe do Grid
c
T e Control Configuration Management Pack.

Resumo

• Descrever a função ASR (Auto Service Request) e como

ela está relacionada ao Exadata Database Machine
• Descrever os requisitos de implementação do ASR
• Descrever o processo de configuração do ASR
• Descrever o OCM (Oracle Configuration Manager) e como
ele está relacionado ao Exadata Database Machine r a ble
e s f
tra n
n on-
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
• Documentação e recomendações
– Oracle Auto Service Request User Documentation and

Product Qualification Information
– Hardware and Network Configuration Recommendations for
ASR
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Gerenciamento de Qualidade do Serviço
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos da Lição

• Descrever a finalidade do Gerenciamento de Qualidade

do Serviço (QoS) do Oracle Database
• Descrever as vantagens de usar o Gerenciamento
de Qualidade do Serviço do Oracle Database
• Descrever os componentes do Gerenciamento
de Qualidade do Serviço do Oracle Database r a ble
• Descrever a operação do Gerenciamento de Qualidade n s fe
do Serviço do Oracle Database n - tra
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Informações Básicas sobre o Gerenciamento de QoS
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic do Oracle Database, era possível usar serviços para gerenciar e
Te anteriores
Nas releases
o
e c nica carga de trabalho. Por exemplo, um grupo de servidores pode estar dedicado às
isolar
T operações de data warehouse, outro estar dedicado a uma aplicação de vendas, um terceiro
ser usado para o processamento ERP e um quarto para uma aplicação personalizada.
Usando serviços, o administrador de banco de dados é capaz de alocar recursos para cargas
de trabalho específicas alterando manualmente o número de servidores nos quais um serviço
de banco de dados pode ser executado. As cargas de trabalho são isoladas umas das
outras, de modo que oscilações de demanda, falhas e outros problemas em uma carga de
trabalho não afetam as demais. O problema desse tipo de implantação é que cada de carga
de trabalho precisa ser provisionada separadamente para demanda de pico, pois os recursos
não são compartilhados.
Também era possível definir serviços que compartilhassem recursos por meio da
sobreposição das alocações de servidor. Entretanto, mesmo com essa funcionalidade, era
necessário gerenciar manualmente as alocações de servidor, e cada serviço era mapeado
para um grupo fixo de servidores.
A partir do Oracle Database 11g, é possível usar pools de servidores para particionar
logicamente um cluster e permitir o isolamento das cargas de trabalho. Os pools de
servidores oferecem uma forma de alocação de recursos mais dinâmica e centrada em
negócios, uma vez que as alocações não dependem de quais servidores estão ativos. Em
vez disso, as alocações de pools de servidores são ajustadas dinamicamente quando os
servidores entram e saem do cluster, de acordo com as prioridades definidas nas políticas de
pool de servidores.
Visão do Gerenciamento de QoS
Definir e Ativar Classificar e Medir

Conjunto de Políticas de
Gerenciamento de QoS
Política de
Manutenção
Política em
Finais de Semana
Avaliar e Arquitetura
Pools de
Servidores
Política Fora do
Horário Comercial
Analisar e
Orientada a le
rab
Política em
Reportar Horário Comercial Recomendar
Política fe
ns
Objetivos de Desempenho
Classes
de
Desempenho
Classificações dos Negócios
- tra
Alocações de Pools de Servidores
no n
s a
) a
h eฺ
r
ฺ Guid
b
m
k o ฺco dent
t
Implementar ei e SControlar
tu
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Te estãolicconsolidando e padronizando os sistemas de computador de seus centros de
Muitas empresas
o
e c nic Ao mesmo tempo, com a migração das aplicações para a Internet, o gerenciamento de picos de
dados.
demanda que não podem ser totalmente previstos passou a ser um problema. Nesse tipo de ambiente,
T é necessário 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 política servem
de base para o gerenciamento de cargas de trabalho dinâmicas; entretanto, eles só podem ajustar as
alocações de recursos em resposta a alterações na disponibilidade dos servidores.
O gerenciamento de qualidade do serviço é um sistema WLM (workload management) baseado em
política e automatizado que monitora e ajusta o ambiente para atender aos objetivos de desempenho
no nível de negócios. Com base na disponibilidade de recursos e nas demandas das cargas de
trabalho, o gerenciamento de qualidade do serviço identifica os gargalos de recursos e fornece
recomendações sobre como aliviá-los. Ele pode fazer recomendações 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 serviço, o administrador poderá garantir o seguinte:
• Quando houver recursos suficientes disponíveis para atender à demanda, os objetivos de
desempenho no nível de negócios de cada carga de trabalho serão atendidos, mesmo que a
carga de trabalho mude.
• Quando não houver recursos suficientes disponíveis para atender a todas as demandas, o
gerenciamento de qualidade do serviço dará prioridade aos objetivos mais críticos de negócios
em detrimento dos menos críticos.

Gerenciamento de QoS e
• Em sua forma inicial, o Gerenciamento de QoS é uma
funcionalidade da família de produtos Oracle Database:

– Introduzido no Oracle Database 11g release 2
– Associado ao software Oracle RAC
– Lançado exclusivamente no
– Centrado em ambientes que suportam
r a ble
várias cargas de trabalho OLTP Conjunto de Políticas de sf
e
– Tecnologia não específica do tra
Gerenciamento de QoS n
n - Política de Manutenção
Exadata a no
Arquitetura
Pools de
Política em Finais
de Semana
Política Fora do
as ฺ
Servidores Horário Comercial
– O primeira passo em direção a

) h Orientada
e a Política em
uma solução mais abrangente ฺ b r i d

uPolítica Classes
Horário Comercial
ฺ c om nt G de
Desempenho
Classificações dos Negócios
i k o ude Alocações de Pools de Servidores
t e S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Em suao Te inicial,lico gerenciamento de qualidade do serviço é uma funcionalidade da
forma
e c nic de produtos Oracle Database associada ao software Oracle Real Application Clusters
família
T (RAC). Ele foi introduzido inicialmente no Oracle Database 11g release 2.
O conjunto inicial de recursos e vantagens associados ao gerenciamento de qualidade do
serviço está disponível exclusivamente para os clientes do Exadata Database Machine e é
mais adequado aos que usam o Database Machine predominantemente como uma
plataforma de consolidação para aplicações OLTP.
O software de gerenciamento de qualidade do serviço pode operar em ambientes diferentes
do Exadata em que o Oracle Database 11g release 2 esteja disponível. Com a versão
11.2.0.3, foi lançado um subconjunto limitado dessa funcionalidade, o qual permite que os
usuários que não utilizam o Exadata monitorem as classes de desempenho, mas não gerem
nem implementem alterações em resposta à carga de trabalho observada no momento.
Em sua forma atual, o gerenciamento de qualidade do serviço oferece uma poderosa
funcionalidade centrada em banco de dados que representa o primeiro passo em direção a
uma solução mais abrangente de gerenciamento de carga de trabalho.

Foco do Gerenciamento de QoS
Desenvolvimento de Código
Uso de Planejamento da Capacidade

Recursos Configuração/Implantação
Espera por Gerenciamento de

Recursos Qualidade do Serviço le
fe rab
tr a ns
n -
no a
Desempenho a
h eฺ s
r
ฺ Guid
b )
da Aplicação m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c
o Te deliqualidade
O gerenciamento do serviço monitora o desempenho de cada solicitação de
i c
ecn
trabalho em um sistema de destino. Medindo com precisão os dois componentes de
T desempenho, o uso de recursos e a espera associada, é possível detectar rapidamente
gargalos e realocar os recursos para aliviá-los, preservando ou restaurando, dessa maneira,
os níveis de serviço. A alteração ou a melhora do tempo de execução geralmente requer
alterações no código-fonte da aplicação. Portanto, o gerenciamento de qualidade do serviço
apenas observa e gerencia os tempos de espera.
Ele baseia suas decisões nas observações do tempo que as solicitações de trabalho
esperam por recursos. Alguns exemplos de recursos pelos quais as solicitações de trabalho
podem esperar incluem recursos de hardware, como ciclos de CPU, filas de entrada/saída de
disco e blocos do cache global.
Poderão ocorrer outras esperas no banco de dados, como latches, bloqueios, retenções etc.
Embora essas esperas do banco de dados sejam consideradas pelo gerenciamento de
qualidade do serviço, elas não são categorizadas por tipo nem gerenciadas. A redução das
esperas não gerenciadas exige alterações que o gerenciamento de qualidade do serviço não
pode fazer, como, por exemplo, alterações no código da aplicação e otimizações do
esquema do banco de dados. O gerenciamento de qualidade do serviço ainda é útil nesses
casos porque a medição e a notificação de esperas não gerenciadas podem ser usadas
como uma ferramenta para avaliar o impacto das atividades de otimização da aplicação.

Vantagens do Gerenciamento de QoS
• Determina onde são necessários recursos adicionais

• Determina se é possível adicionar mais hardware para

manter o desempenho aceitável
• Reduz o número de problemas críticos de desempenho
• Reduz o tempo necessário para resolver violações dos
objetivos de desempenho
• Melhora a estabilidade do sistema à medida que a carga erab
le
de trabalho muda n s f
n - tra
• Ajuda a garantir que os SLAs sejam cumpridos
a no
• as ฺ de
Facilita o compartilhamento eficaz dos hrecursos
)
r uide
hardware mฺb co ent G
o ฺ
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic vantagens do gerenciamento de qualidade do serviço:
Estas o sãoTalgumas das
e c n• icCategorizando e mensurando o trabalho dos bancos de dados, o gerenciamento de

T qualidade do serviço pode ajudar os administradores a determinar onde são
necessários recursos adicionais.
• O gerenciamento de qualidade do serviço reconhece o Oracle RAC e usa esse
conhecimento fundamental para determinar se é possível adicionar mais hardware para
manter o desempenho aceitável.
• O gerenciamento de qualidade do serviço ajuda a reduzir o número de problemas
críticos de desempenho. Caso a realocação dos recursos de runtime seja feita com
base na utilização das aplicações críticas de negócios mais ocupadas, será menor a
probabilidade de ocorrerem problemas de desempenho nessas aplicações.
• O gerenciamento de qualidade do serviço reduz o tempo necessário para resolver
violações dos objetivos de desempenho. Em vez de exigir que os administradores
compreendam e respondam às alterações no desempenho, grande parte do trabalho
pode ser automatizada. Os administradores contam com uma interface simples para
verificar e implementar as alterações recomendadas.
• Os problemas de desempenho costumam resultar na instabilidade do sistema.
Movendo os recursos para onde eles são mais necessários, o gerenciamento de
qualidade do serviço reduz a chance de que ocorram problemas de desempenho nos
sistemas, bem como a instabilidade associada.
• O gerenciamento de qualidade do serviço permite que o administrador defina objetivos
de desempenho que ajudam a garantir o cumprimento dos SLAs (Service Level
Agreements, Contratos em Nível de Serviço). Uma vez definidos os objetivos, o
gerenciamento de qualidade do serviço controlará o desempenho e recomendará
alterações caso os SLAs não estejam sendo cumpridos.
• À medida que as necessidades de recursos mudam, o gerenciamento de qualidade do
serviço poderá realocar os recursos de hardware a fim de garantir o seu uso mais eficaz
pelas aplicações. Os recursos podem ser removidos das aplicações que não
necessitam mais deles e adicionados a outra que tenha problemas de desempenho.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Visão 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 não estão atendendo
aos objetivos de desempenho
– O Gerenciamento de QoS pode recomendar:
Ajustes no tamanho dos pools de servidores le
rab
—
— Alterações nos mapeamentos de grupos de consumidores fe

— a ns
Ajustes nos recursos de CPU alocados para diferentes instâncias
tr
de banco de dados em um pool de servidores n -
a do número no
• Gerenciar a demanda de memória em decorrência
a s
r) h deidcontrole
de sessões ou de cargas de trabalhobfora
ฺ eฺ
u
– O Gerenciamento de QoS impede
ฺ c omo estabelecimento
n t G de novas
k o e
i quetuhádgrande consumo de
sessões nos servidoreseem
t
memória e@ is S
o rt e th
suOracletoe/ouusuas
c ฺ
Copyright © 2012,
o (te nse
T eik deliqualidade
O gerenciamento
ce do serviço opera com o Oracle RAC, o Oracle Clusterware e o
i c
Cluster
oHealth Monitor (CHM) para
n aos níveis de serviço, bem gerenciar
ecatender
os recursos de banco de dados a fim de
como para gerenciar a demanda de memória nos
T servidores gerenciados.
Geralmente, os serviços de banco de dados são usados para agrupar solicitações de
trabalho relacionadas, bem como para medir e gerenciar o trabalho do banco de dados. Por
exemplo, uma consulta iniciada pelo usuário no banco de dados poderá usar um serviço
diferente de uma aplicação de geração de relatórios. Para gerenciar os recursos usados por
um serviço, alguns serviços podem ser implantados em várias instâncias do Oracle RAC
simultaneamente, enquanto outros podem ser implantados somente em uma instância.
Em um banco de dados Oracle RAC, o gerenciamento de qualidade do serviço monitora os
nós em que os serviços de banco de dados definidos pelo usuário são oferecidos. Os
serviços são criados em um pool de servidores específicos, e o serviço é executado em
todos os servidores do pool. Se um serviço singleton for necessário porque não é possível o
escalonamento eficaz da aplicação em vários servidores RAC, o serviço poderá ser
hospedado em um pool de servidores com tamanho máximo igual a um.
O gerenciamento de qualidade do serviço avalia periodicamente os tempos de espera pela
CPU do servidor de banco de dados para identificar as cargas de trabalho que não estão
atendendo aos objetivos de desempenho. Se necessário, ele recomendará ajustes no
tamanho dos pools de servidores ou alterações 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 serviço também suporta a transferência de CPUs
entre bancos de dados no mesmo pool de servidores.
O DBRM é um exemplo de mecanismo de alocação de recursos; ele é capaz de alocar
compartilhamentos de CPU entre um conjunto de grupos de consumidores de recursos com
base em um plano de recursos especificado pelo administrador. Um plano de recursos aloca
o percentual de oportunidades de execução na CPU. O gerenciamento de qualidade do
serviço não ajusta os planos do DBRM; ele ativa um plano de recursos compartilhados de
vários níveis e, ao implementar uma recomendação, move as cargas de trabalho para um
grupo de consumidores específico a fim de atender aos objetivos de desempenho de todas
as diferentes cargas de trabalho.

Os servidores de banco de dados corporativos podem ficar sem memória disponível em
decorrência de um grande número de sessões abertas ou de cargas de trabalho fora de
controle. A falta de memória poderá resultar na falha de transações ou, em casos extremos,
na reinicialização do servidor e na perda de um recurso valioso para as aplicações. O
gerenciamento de qualidade do serviço alivia a demanda de memória encerrando
temporariamente os serviços das instâncias de banco de dados em um servidor em que há
le
rab
grande consumo de memória. Como resultado, as novas sessões serão direcionadas para
servidores menos sobrecarregados. O roteamento das novas sessões protege as cargas de fe
trabalho existentes e a disponibilidade do servidor com grande consumo de memória. ns
tra
Quando o gerenciamento de qualidade do serviço está ativado e gerenciando n -
o um pool de
servidores do Oracle Clusterware, ele recebe um fluxo de métricas ado
nCluster Health Monitor
a s
h de um
com informações em tempo real sobre os recursos de memória
r ) d e ฺservidor, incluindo a
quantidade de memória disponível, a quantidade de memória
m b i
ฺ Gemu uso e a quantidade de
memória da qual foi feito swap para disco em cada ฺ o
c ent Se o gerenciamento de
servidor.
qualidade do serviço determinar que há um k o d
i grandetuconsumo de memória em um nó, os
t epelo S
serviços de banco de dados gerenciados
r t e @ his Oracle Clusterware serão interrompidos nesse
nó, impedindo o estabelecimento
p o de novase t conexões. Uma vez aliviada a demanda de
memória, os serviços serão
ฺ u
s to u
reiniciadoss automaticamente, e o listener poderá enviar novas
c
(te nÉsepossível aliviar a demanda de memória de diversas maneiras
conexões para o servidor.
o
eik lcom
como, por exemplo,
T
do usuário.
ice o fechamento das sessões existentes ou por meio da intervenção
n i co
Tec

Conjuntos de Políticas de Gerenciamento de QoS
Conjunto de Políticas de Gerenciamento de QoS

Política de Manutenção
Política em
Pools de Finais de Semana
Servidores Política Fora do
Horário Comercial
le
Política em
fe rab
Horário Comercial ns tra
Classes de n -
a no
Desempenho
) h asdos Negócios
ฺ
b
ฺ Gur
Classificações
i d e
o m
c endet Pools de Servidores
k o ฺAlocações
t ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Te centrallidoc gerenciamento de qualidade do serviço é o conjunto de políticas. Ele
Um conceito
o
e c nic especificar
permite
políticas de desempenho
recursos, classes de desempenho (cargas de trabalho) e um conjunto de
que determinam o objetivo de desempenho de cada classe de
T desempenho, bem como definem restrições para a disponibilidade de recursos. O
gerenciamento de qualidade do serviço usa um conjunto de políticas em nível do sistema que
define os objetivos de desempenho com base nas classes de trabalho e na disponibilidade
de recursos. Políticas de desempenho específicas podem ser ativadas com base na
programação de um calendário, em janelas de tempo de manutenção, eventos etc. Só
poderá haver uma política de desempenho ativa em determinado momento.
Para manter os objetivos de desempenho atuais, o gerenciamento de qualidade do serviço
faz recomendações de realocação de recursos e prevê o respectivo efeito. As
recomendações podem ser facilmente implementadas com o clique de um único botão.
Um conjunto de políticas consiste nos seguintes elementos:
• Os pools de servidores que estão sendo gerenciados pelo gerenciamento de qualidade
do serviço.
• Classes de desempenho, que são solicitações de trabalho com objetivos de
desempenho semelhantes.
• Políticas de desempenho, que descrevem como os recursos devem ser alocados às
classes de desempenho com o uso de objetivos de desempenho e de sobreposições de
diretivas de pool de servidores. Em uma política de desempenho, os objetivos de
desempenho são classificados com base na importância dos negócios, o que permite
ao gerenciamento de qualidade do serviço se concentrar em objetivos específicos
quando a política está ativa.
Pools de Servidores
Sales Sales ERP HR Batch

App Cart App App App
Serviço Serviço Serviço

ERP HR Batch
Serviço SALES
le
fe rab
ns tra
o n -
Online Server Pool (SP)
Min=3, Max=4,
BackOffice SP
Min=2, Max=2, a
Min=1,
n
Batch SP
Max=1,
Free SP
Min=0,
Importance=30 Importance=20 a
h eฺ s
Importance=10 Imp=0
r )
ฺb Dados d
iAPPS
Banco de Dados SALES Banco m de
G u
k o ฺco dent
Oracle
t ei Clusterware
S tu
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Um pool
o Tdeeservidores lic é uma divisão lógica de um cluster. Os pools de servidores facilitam o
e c nic da carga de trabalho em um cluster ao mesmo tempo em que mantêm a agilidade
isolamento
T e permitem que os usuários obtenham outras vantagens associadas à consolidação. Os
administradores podem definir pools de servidores normalmente associados a diferentes
aplicações e cargas de trabalho. Um exemplo é ilustrado no slide. O gerenciamento de
qualidade do serviço poderá ajudar gerenciando o tamanho de cada pool de servidores, bem
como a alocação 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 são colocados inicialmente nesse pool.
Depois, pools de servidores específicos poderão ser criados para cada uma das cargas de
trabalho que precisam ser gerenciadas. Quando um novo pool é criado, os servidores
designados a ele são removidos automaticamente do pool Free e colocados no pool recém-
criado.
Uma vez criado um pool de servidores, poderá ser configurado um banco de dados para
execução nesse pool, e serviços gerenciados por cluster poderão ser estabelecidos para que
as aplicações 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 opção de implantação gerenciada por política, a qual
coloca o banco de dados em um ou mais pools de servidores.

Um importante atributo do gerenciamento baseado em política é a alocação de recursos para
pools de servidores com base na cardinalidade e na importância.
Quando o cluster é iniciado ou quando servidores são adicionados, todos os pools são
preenchidos até seus níveis mínimos em ordem de importância. Quando os níveis mínimos
são atingidos, os pools continuam a ser preenchidos em ordem de importância até atingirem
seus níveis máximos. Se sobrarem servidores, eles serão alocados para o pool Free.
Se os servidores saírem do cluster por qualquer motivo, poderá ocorrer uma realocação de
servidores. Se houver servidores no pool Free, e outro pool ficar abaixo de seu valor máximo,
um servidor livre será alocado para o pool de servidores afetado. Se não houver servidores
livres, a realocação de servidores só ocorrerá se um pool ficar abaixo de seu nível mínimo.
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 importância que contenha mais do que o seu
número mínimo de servidores. le
2. O pool de servidores com a menor importância que contenha pelo menos um servidor e
fe rab
que seja menos importante do que o pool de servidores afetado.
tra ns
-
Usando esses mecanismos, os pools de servidores podem manter um nível ideal de recursos
n
com base no número atual de servidores disponíveis.
a no
a s
Considere o exemplo mostrado no slide. Se um dos servidores do pool Online falhar, o
h eฺ
r )
servidor existente no pool Free será automaticamente movido para o pool Online.
ฺ Guid
b
m
Agora, se ocorrer uma falha em um dos servidores do pool BackOffice, não haverá
o ฺco dent
servidores no pool Free para serem alocados. Nesse caso, o servidor que está atendendo
k
t ei Stu
ao pool Batch no momento será realocado dinamicamente para o pool BackOffice, pois a
o r te@ this
falha fará com que o nível desse pool fique abaixo do seu mínimo, e ele é mais importante do
que o pool Batch.
ฺ s up use
( t ec se to
Se um nó retornar posteriormente ao cluster, ele será alocado para o pool Batch a fim de
satisfazer ao nível mínimo desse pool.
e i ko licen
Todos os outros nós acrescentados ao cluster após esse ponto serão adicionados ao pool
o T
ic
Free uma vez que todos os outros pools estão preenchidos até seu nível máximo.
Tecn

Classes de Desempenho
• Uma classe de desempenho é um grupo de solicitações

de trabalho cujo nível de serviço precisa ser gerenciado

• As solicitações de trabalho são definidas por
classificadores de desempenho que contêm o nome do
serviço de banco de dados e parâmetros de sessão
opcionais
• O conjunto inicial de classificadores de desempenho é
r a ble
descoberto automaticamente e criado a partir dos serviços n s fe
gerenciados por cluster n - tra
• Objetivos de desempenho são definidos nas a no
classes de
a s
desempenho r) h eฺ ฺb Guid
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic são usadas para categorizar cargas de trabalho com requisitos
Tede desempenho
As classes
o
ic
ecn
semelhantes de desempenho. Um conjunto de regras de classificação é avaliado em relação
T às solicitações de trabalho quando elas chegam ao sistema. Essas regras permitem fazer
uma correspondência com os valores de atributos da solicitação de trabalho; quando há uma
correspondência entre o tipo de solicitação de trabalho e os critérios para inclusão em uma
classe de desempenho, a solicitação é categorizada nessa classe.
Essa classificação das solicitações de trabalho aplica o nome definido pelo usuário, ou tag,
que identifica a classe de desempenho (PC) à qual a solicitação pertence. Todas as
solicitações de trabalho agrupadas em determinada classe têm os mesmos objetivos de
desempenho. Na verdade, a tag conecta a solicitação de trabalho ao objetivo de
desempenho aplicável a ela. As tags são mantidas com cada solicitação de trabalho de modo
que todos os componentes do sistema possam efetuar medições e fornecer dados ao
gerenciamento de qualidade do serviço para avaliação em relação aos objetivos de
desempenho aplicáveis.
O gerenciamento de qualidade do serviço suporta combinações definidas pelo usuário de
parâmetros de conexão denominados classificadores a fim de mapear as classes de
desempenho para as cargas de trabalho reais executadas no banco de dados.

Esses parâmetros de conexão são divididos em duas classes gerais e podem ser
combinados para criar expressões booleanas detalhadas:
• Parâmetros de Configuração: os parâmetros de configuração suportados são
SERVICE_NAME e USERNAME. Cada classificador em uma classe de desempenho
deve incluir um ou mais serviços de banco de dados gerenciados por cluster. Maior
granularidade pode ser obtida com a identificação do usuário do Oracle Database que
está estabelecendo a conexão a partir de um cliente ou do middle-tier. A vantagem de
usar esses classificadores é que eles não exigem alterações no código da aplicação
para definir as classes de desempenho.
• Parâmetros de Aplicação: os parâmetros de aplicação suportados são MODULE,
ACTION e PROGRAM. Eles são parâmetros opcionais definidos pela aplicação da
seguinte maneira:
- OCI: usa OCI_ATTR_MODULE e OCI_ATTR_ACTION
- ODP.NET: especifica as propriedades ModuleName e ActionName no objeto le
OracleConnection
fe rab
- JDBC: define MODULE e ACTION em SYS_CONTEXT
tra ns
n -
no
O parâmetro PROGRAM é definido ou derivado de maneira diferente para cada plataforma e
a
driver de banco de dados. Consulte o guia do desenvolvedor do Oracle Database apropriado
para obter mais detalhes e exemplos. a
h eฺs
r )
Para gerenciar a carga de trabalho de uma aplicação, m b
ฺo código daid
u aplicação direciona as
o t G
em um classificador, de forma que todas e
oฺc udede
conexões de banco de dados para um serviço específico.
asiksolicitações
nO nome do serviço é especificado
trabalho que usam esse serviço
são marcadas com uma tag como e
t S t
@ his à classe de desempenho criada para essa
aplicação. Se quiser manter p o
um
t pertencendo
rcontrole t preciso da carga de trabalho gerada pelas
mais
u u s e
e c ฺs você
diversas partes da aplicação,
t o poderá criar classes de desempenho adicionais e usar
t e
classificadores que( incluamsMODULE,
o ou USERNAME. ACTION ou PROGRAM, além do parâmetro
SERVICE_NAME i k e n
o T e lic
c n ic Um de
As classes
tempo.
desempenho usadas em um ambiente podem ser alteradas ao longo do
cenário comum é substituir um único objetivo de desempenho por vários objetivos
Te mais específicos, dividindo-se as solicitações de trabalho em classes de desempenho
adicionais. Por exemplo, os desenvolvedores de aplicação podem sugerir classes de
desempenho para uso pelo gerenciamento de qualidade do serviço. Especificamente, um
desenvolvedor de aplicação pode definir um conjunto de classificadores de banco de dados
usando os parâmetros MODULE e ACTION e, depois, colocá-los em classes de desempenho
distintas, de modo que cada tipo de solicitação de trabalho seja gerenciado de forma
independente.

Classificação e Marcação com Tags
• Cada sessão é classificada:

– A classificação é determinada com base na avaliação dos

parâmetros de sessão em relação aos classificadores de
classes de desempenho
– Ocorre somente quando uma sessão é estabelecida ou
quando os parâmetros de sessão são alterados
Isso minimiza o overhead associado à classificação
—
ble
• Cada solicitação de trabalho é marcada com uma tag: fera
– A tag se baseia na classificação da sessão atual -tra
ns
– A tag conecta a solicitação de trabalho a uma n on de
classe
s a
desempenho
) a
h eฺ
Ela permite que as medições associadas b r
ฺ Gàusolicitaçãoid de
—
o m t
trabalho sejam registradas ฺpara
apropriada i k o c uden a classe de desempenho
@ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Teo gerenciamento
Para ativar de qualidade do serviço, as solicitações de trabalho devem ser
n i c
classificadas e marcadas com uma tag.
T e c
Quando uma sessão de banco de dados é estabelecida, os parâmetros da sessão são
avaliados em relação aos classificadores de classes de desempenho para determinar uma
classificação. Em seguida, o trabalho associado à sessão é marcado com uma tag com base
na classificação da sessão até que ela seja encerrada ou que os parâmetros
correspondentes sejam alterados. Se os parâmetros da sessão forem alterados, a
classificação será reavaliada. Dessa maneira, o overhead associado à classificação é muito
pequeno, uma vez que ela é avaliada somente quando uma sessão é estabelecida ou
quando os parâmetros da sessão são alterados.
As tags são designadas permanentemente a cada solicitação de trabalho de modo que todas
as medições associadas à solicitação podem ser registradas para a classe de desempenho
apropriada. Na verdade, a tag conecta a solicitação de trabalho a uma classe de
desempenho e ao objetivo de desempenho associado.

Políticas de Desempenho
• As políticas de desempenho são conjuntos nomeados de

objetivos de desempenho e sobreposições de pool de

servidores para atender a objetivos de negócios
– Os objetivos de desempenho podem ser classificados de
acordo com a sua importância
• Há somente uma política ativa em determinado momento
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Te várioslicobjetivos de desempenho, o administrador do gerenciamento de
Para gerenciar
o
e c nic do serviço define uma ou mais políticas de desempenho. Por exemplo, ele pode
qualidade
T definir uma política de desempenho para o horário comercial normal, outra para os dias da
semana fora do horário comercial, uma para operações nos finais de semana e outra para
ser usada durante o processamento do fechamento financeiro trimestral. Observe que há
somente uma política ativa em determinado momento.
Uma política de desempenho contém um conjunto de objetivos de desempenho em vigor; um
ou mais para cada aplicação que está sendo gerenciada no sistema. Alguns objetivos de
desempenho são sempre mais críticos para os negócios do que outros, enquanto alguns
objetivos podem ser mais críticos em determinados momentos e menos críticos em outros. A
capacidade de definir várias políticas de desempenho no conjunto de políticas proporciona
ao gerenciamento de qualidade do serviço a flexibilidade necessária para implementar
diferentes esquemas de prioridade quando preciso.

Classificações de Classes de Desempenho
• As classificações de classes de desempenho designam

um nível relativo de criticalidade do negócio a cada classe

de desempenho em uma política de desempenho:
– Highest
– High
– Medium
– Low le
fe rab
– Lowest
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic
e de ldesempenho,
Em uma o Tpolítica também é possível classificar cada classe de desempenho.
i c
n classificação designa um nível relativo de criticalidade do negócio a cada objetivo de
Essa
T e c
desempenho. Quando não há recursos suficientes disponíveis para atender a todos os
objetivos de todas as classes de desempenho, os objetivos de desempenho das classes
mais críticas devem ser atendidos em detrimento dos das classes menos críticas. As
definições de classificação disponíveis são Highest, High, Medium, Low ou Lowest. Observe
que, se mais de uma classe receber determinada classificação (por exemplo, Medium), elas
serão ordenadas alfabeticamente nessa classificação.

• Os objetivos de desempenho podem derivar dos SLAs.

Eles especificam:
– Um requisito de negócios
– A classe de desempenho à qual ele se aplica
• O tempo de resposta médio por chamada de banco de
dados é o único tipo de objetivo de desempenho no
momento
r a ble
– O tempo de resposta é o intervalo total do recebimento n s
da fe
solicitação pelo banco de dados até o momento em n - ra a
tque
resposta sai do servidor a no
– O tempo de resposta não inclui o tempo ) h ados tráfegoฺ de rede
b
ฺ Gur i d e
o m
k o ฺc dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Tede desempenho
Um objetivo é criado para cada classe de desempenho a fim de especificar o
i c
n de desempenho desejado para essa classe. Um objetivo de desempenho especifica um
nível
T e c
requisito de negócios e o trabalho ao qual ele se aplica (a classe de desempenho). Por
exemplo, um objetivo de desempenho poderá determinar que as solicitações de trabalho do
banco de dados que usam o serviço SALES devem ter um tempo de resposta médio inferior
a 60 milissegundos.
Cada política 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 serviço suporta apenas um tipo de objetivo de
desempenho, o tempo de resposta médio.
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 solicitação na rede até a hora em que ela sai do
servidor. Ele não inclui o tempo necessário para enviar as informações para/do cliente na
rede. O valor médio 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 médio.

Performance Satisfaction Metrics
• Objetivos de desempenho diferentes podem ser

comparados com o uso da PSM (Performance Satisfaction

Metric)
• A PSM mostra rapidamente como o sistema está lidando
com o objetivo
100%
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco den-100% t
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic diferentes são usados para medir o desempenho de cargas de
Objetivos
o Tdee desempenho
e c nic distintas. No momento, o gerenciamento de qualidade do serviço suporta somente
trabalho
T cargas de trabalho OLTP e usa apenas o objetivo de desempenho de tempo de resposta
médio. Ao configurar o gerenciamento de qualidade do serviço, 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
concluída em 1 milissegundo, enquanto outro poderá especificar que uma chamada de
pesquisa (Browse call) deve ser concluída em 1 segundo. À medida que mais objetivos de
desempenho forem adicionados a um sistema, poderá ser difícil compará-los rapidamente.
Por esse motivo, é útil ter uma medida numérica comum e consistente que indique como a
carga de trabalho atual de uma classe de desempenho está se comportando em relação ao
respectivo objetivo de desempenho atual. Essa medida numérica é chamada PSM
(Performance Satisfaction Metric). Portanto, a Performance Satisfaction Metric é um valor
numérico 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 serviço comparar o desempenho do sistema em relação a objetivos bastante
diferentes.

Sobreposições de Diretivas de Pool de Servidores
Política do Horário Comercial

Online SP Back Office SP Batch SP
Política Fora do Horário Comercial
le
fe rab
tr ans
Online SP Back Office SP -
Batch SP
n
Política do Final do Trimestre
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t eiOfficeS tu
Online SP
r t e @ Back
h i s SP Batch SP
u p o se t
Copyright © 2012,
e
t
o ( ense
i k lic
o Te de desempenho
Uma política também pode conter um conjunto de sobreposições de
i c
n de pool de servidores. Uma sobreposição de diretiva de pool de servidores define a
diretivas
T e c
contagem mínima e máxima de servidores, bem como atributos relacionados à importância
de um pool de servidores quando a política de desempenho está em vigor. As sobreposições
de diretivas de pool de servidores servem como restrições às recomendações propostas pelo
gerenciamento de qualidade do serviço, pois são aplicadas enquanto a política de
desempenho está ativa. Por exemplo, o gerenciamento de qualidade do serviço nunca
recomendará a remoção de um servidor de um pool caso isso faça com que o pool fique
abaixo de sua contagem mínima de servidores.
As sobreposições 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
condições normais, essas definições de pool de servidores devem ser capazes de tratar da
carga de trabalho predominante. Se houver um aumento repentino das solicitações de carga
de trabalho em uma classe de desempenho, o pool de servidores associado poderá exigir
mais recursos do que o especificado na política de desempenho.

Visão Geral de Métricas
• O Gerenciamento de QoS usa um conjunto padronizado

de métricas
• Há dois tipos de métricas:
– As métricas de desempenho fornecem uma visão geral de
onde o tempo é gasto no sistema
– As métricas de recursos medem o tempo durante o qual as
solicitações de trabalho usam um recurso ou esperam por ele
r a ble
• As métricas são usadas para identificar recursos com nsfe
gargalo e determinar a melhor ação corretiva: n-tra
– Para uma classe de desempenho, o recursoacom no gargalo
é o que contribui com o maior tempo )de h s
aespera
r d e ฺ médio
m b
ฺ Gu i
o
ฺc dent
k o
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c
o Te deliqualidade
O gerenciamento do serviço usa um conjunto padronizado de métricas, que são
i c
ecn
coletadas por todos os servidores do sistema. Há dois tipos de métricas: de desempenho e
T de recursos. Essas métricas permitem uma observação direta do uso e do tempo de espera
incorridos pelas solicitações de trabalho em cada classe de desempenho, para cada recurso
solicitado, à medida que ele percorre os servidores, as redes e os dispositivos de
armazenamento no sistema.
As métricas de desempenho são coletadas no ponto de entrada para cada servidor no
sistema. Elas fornecem uma visão geral de onde o tempo é gasto no sistema, bem como
permitem comparar os tempos de espera observados em todo o sistema. Os dados são
coletados periodicamente e encaminhados a um ponto central para análise, tomada de
decisão e armazenamento histórico.
Uma métrica de desempenho importante é o tempo de resposta, ou seja, a diferença entre o
momento em que uma solicitação é recebida e a hora em que uma resposta é enviada. O
valor médio dos tempos de resposta referentes a todas as chamadas de banco de dados em
uma classe de desempenho é calculado e apresentado como o tempo de resposta médio.
Outra métrica de desempenho importante é a taxa de chegada de solicitações de trabalho.
Ela fornece uma medida da demanda associada a cada classe de desempenho.

Há métricas de recursos para os seguintes recursos: CPU, Entrada/Saída de
Armazenamento, Cache Global e Outros (esperas de banco de dados). Duas métricas são
fornecidas para cada recurso:
• Resource usage time - mede por quanto tempo o recurso é usado.
• Resource wait time - mede o tempo esperado para obter o recurso.
As métricas do gerenciamento de qualidade do serviço fornecem as informações necessárias
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 médio para cada solicitação de trabalho dessa
classe.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Arquitetura do Gerenciamento de QoS
Conectores de Dados e Gerenciador de Dados

Origens de Servidor de Enterprise
Dados Gerenciamento Manager

de QoS
Oracle
RAC Interfaces Management
11.2 JDBC de Cliente JMX Dashboard
XML
Policy Set
Wizard
Oracle
ble
Performance era
Clusterware Policy Engine
11.2 SRVM History ns
f
tra
Oracle Business Rules
n -
Sistema a Actions noAlerts &
Operacional a
h eฺ s
CHM Persistence b r
ฺ Guid)
Manager m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c
o Te deliqualidade
O gerenciamento do serviço recupera dados de métricas de cada instância de
i c
ecn
banco de dados em execução nos pools de servidores gerenciados e correlaciona os dados
T por classe de desempenho a cada 5 segundos. Os dados incluem várias métricas; por
exemplo, taxa de chegada de chamadas, uso de CPU, Entrada/Saída e Cache Global, além
de tempos de espera. Os dados são 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 relação aos objetivos de desempenho atuais estabelecidos pela política de
desempenho ativa.
A avaliação do desempenho ocorre uma vez a cada minuto e resultará em uma
recomendação se uma classe de desempenho não estiver atendendo a seu objetivo. A
recomendação especifica em qual recurso há gargalos. Ações corretivas específicas são
incluídas, se possível, juntamente com o impacto projetado em todas as classes de
desempenho do sistema. O slide mostra a coleta de dados de várias origens pelo
componente de conectores de dados do gerenciamento de qualidade do serviço:
• 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 informações de diversas maneiras, incluindo as telas
Management Dashboard, Policy Set Wizard, Performance History e Alerts and Actions.
Recomendações do Gerenciamento de QoS
• Se os objetivos de desempenho não estiverem sendo

atendidos, o gerenciamento de QoS fará uma recomendação
• Cada recomendação visa melhorar a classe de desempenho

com classificação mais alta que está excedendo seu objetivo
de desempenho
• As recomendações podem incluir:
– Alterar os mapeamentos de grupos de consumidores
Atribuir uma nova prioridade ao trabalho dentro dos limites de le
rab
—
recursos existentes fe
– Mover servidores entre pools de servidores ns tra
Atribuir uma nova prioridade aos recursos entre os n -
opools de
a n de trabalho
—
servidores a fim de atender às demandas descarga

– Mover as CPUs entre os bancos de dados r ) haemeum ฺ pool de
servidores
b
ฺ Gu i d
o m
c recursos t de CPU dentro dos
Atribuir uma nova prioridade k o ฺaos e n
ei Sexistentesud
—
limites de pools de servidorest t

o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic picos de demanda periódicos, para manter os níveis de
Caso suaTempresa enfrente
o
e c nic
desempenho
disponibilizado
das aplicações, você poderá adquirir hardware adicional, o qual poderá ser
ou permanecer ocioso, de acordo com as necessidades. Em vez de ter
T servidores extras que permanecem ociosos durante a maior parte do tempo, você poderá
usar esses servidores para executar cargas de trabalho de outras aplicações. Entretanto, se
os servidores estiverem ocupados executando outras aplicações quando houver um pico de
demanda, suas principais aplicações de negócios não poderão ter o desempenho esperado.
O gerenciamento de qualidade do serviço ajuda a gerenciar situações desse tipo.
Quando você implementa uma política de desempenho, o gerenciamento de qualidade do
serviço monitora continuamente o sistema e o gerencia usando um processo iterativo.
Quando um ou mais objetivos de desempenho não estão sendo atendidos, cada iteração
procura melhorar o desempenho de um único objetivo; o objetivo de desempenho com
classificação mais alta que não está sendo alcançado. Quando todos os objetivos de
desempenho estão sendo alcançados, o gerenciamento de qualidade do serviço não faz
mais recomendações.
As recomendações 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 alteração dos mapeamentos de grupos de consumidores poderá envolver a promoção de
uma carga de trabalho específica 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 é atribuída às
cargas de trabalho dentro dos limites de recursos existentes.
Outra abordagem usada pelo gerenciamento de qualidade do serviço é mover os servidores
entre pools de servidores. Essa abordagem altera a distribuição 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 serviço
também pode mover recursos de CPU entre bancos de dados no mesmo pool de servidores.
Isso altera a distribuição dos recursos de CPU entre instâncias de banco de dados que usam a
funcionalidade Instance Caging, bem como permite maior controle dos ambientes em que há
vários bancos de dados consolidados no mesmo ambiente do Exadata Database Machine.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Implementando Recomendações
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic de qualidade do serviço está operando para melhorar o
Quandoo oTgerenciamento
e c nic
desempenho de determinada classe de desempenho, ele recomenda aumentar a quantidade
T do recurso com gargalo (como tempo de CPU) para essa classe ou disponibilizar esse
recurso mais rápido para as solicitações de trabalho dessa classe.
A implementação de uma recomendação 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 serviço cujo acesso
é melhorado, resultando em um ganho líquido para o sistema como um todo. Opcionalmente,
a classe de desempenho penalizada poderá ser menos crítica para os negócios do que a
classe beneficiada.
Ao gerar recomendações, o gerenciamento de qualidade do serviço 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 serviço poderá indicar que o ganho de desempenho é muito pequeno e não
é recomendado. Se houver mais de uma forma de resolver o gargalo, o gerenciamento de
qualidade do serviço proporá a melhor recomendação geral, levando em consideração
variáveis como o impacto calculado em todas as classes de desempenho, junto com a
interrupção prevista no funcionamento e o tempo de estabilização associado à ação. A
recomendação atual e as recomendações alternativas podem ser exibidas com o Oracle
Enterprise Manager.
Os dados de desempenho são enviados ao Oracle Enterprise Manager para exibição nas
páginas Management Dashboard e Performance History do gerenciamento de qualidade do
serviço. São gerados alertas para notificar que um ou mais objetivos de desempenho não estão
sendo alcançados ou que um problema está impedindo que um ou mais pools de servidores
sejam gerenciados. Como resultado dessas notificações, o administrador poderá implementar a
recomendação.
Nesta release, o gerenciamento de qualidade do serviço não implementa as recomendações
automaticamente. Ele sugere uma forma de melhorar o desempenho, a qual o administrador

deverá implementar clicando no botão Implement. Após a implementação de uma
recomendação, o sistema tem um tempo para se estabilizar antes de novas recomendações
serem feitas. O objetivo disso é garantir que dados estáveis sejam usados para avaliações
futuras, bem como evitar recomendações que resultem em ações oscilantes.
le
fe rab
tra ns
n -
a no
a s
h eฺ
r )
ฺ Guid
b
m
k o ฺco dent
t ei Stu
o r te@ this
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Questionário
O gerenciamento de qualidade do serviço do Oracle Database

ajuda a atender aos objetivos de desempenho reduzindo o uso

de recursos:
a. Verdadeiro
b. Falso
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Resposta:
o Tbe
ic
Ongerenciamento de qualidade do serviço do Oracle Database ajuda a atender aos objetivos
c
T e de desempenho gerenciando e reduzindo os tempos de espera por recursos, e não o seu
uso.

Questionário
As recomendações do gerenciamento de qualidade do serviço

do Oracle Database podem incluir

a. Mover servidores entre pools de servidores
b. Adicionar spindles para melhorar o desempenho de
entrada/saída
c. Alterar os mapeamentos de grupos de consumidores
d. Recomendar estratégias de particionamento para r a ble
minimizar os gargalos do cache global n s fe
ra n -t
n o
a
) h as ฺ
m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Resposta:
o Ta,e c lic
ic
Ongerenciamento de qualidade do serviço do Oracle Database é capaz de identificar
c
T e problemas de desempenho de entrada/saída ou gargalos do cache global, mas não pode
tratar dessas questões nesta release.

Resumo

• Descrever a finalidade do Gerenciamento de Qualidade

do Serviço (QoS) do Oracle Database
• Descrever as vantagens de usar o Gerenciamento
de Qualidade do Serviço do Oracle Database
• Descrever os componentes do Gerenciamento
de Qualidade do Serviço do Oracle Database r a ble
• Descrever a operação do Gerenciamento de Qualidade n s fe
do Serviço do Oracle Database n - tra
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Recursos Adicionais
– Configurando o Gerenciamento de Qualidade do Serviço

– Usando o Gerenciamento de Qualidade do Serviço
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

Gerenciando o Exadata Database Machine

com o Enterprise Manager Cloud Control 12c
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos
Após concluir esta lição, você será capaz de descrever os

principais recursos de gerenciamento do Exadata Database

Machine incluídos no Enterprise Manager Cloud Control 12c.
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn
Workshop de Administração do Exadata Database Machine A - 2

Visão Geral da Lição
• Esta lição descreve em linhas gerais alguns dos principais

aperfeiçoamentos específicos do Exadata no Enterprise

Manager Cloud Control 12c.
• As áreas abordadas compreendem:
– Configurando o Exadata Database Machine como um alvo
do Enterprise Manager
– Visualizando o Exadata Database Machine no Enterprise
r a ble
Manager
n s fe
– Monitoramento do desempenho e gerenciamento do
n - tra
Exadata Storage Server a no
– Monitoramento e administração da redeh s
aInfiniBand do
r ) e ฺ
Exadata Database Machine mฺb uid
o ฺ co ent G
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic descrição de alguns dos aperfeiçoamentos de monitoramento e
o Tfornece
Esta lição uma
e c nic
administração específicos do Exadata incluídos no Enterprise Manager Cloud Control 12c.
T As seguintes áreas são abordadas:
• Configurando o Exadata Database Machine como um alvo do Enterprise Manager.
• Visualizando o Exadata Database Machine no Enterprise Manager.
• Monitoramento do desempenho e gerenciamento do Exadata Storage Server.
• Monitoramento e administração da rede InfiniBand do Exadata Database Machine.
O objetivo desta lição é fornecer uma descrição de algumas das principais áreas que foram
aperfeiçoadas na nova release do Enterprise Manager.

Configurando o Exadata Database Machine como
um Alvo do Enterprise Manager
• Novo tipo de alvo para o Exadata Database Machine
• Novo processo de descoberta orientado por assistente:
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Cloud Control 12c, o novo tipo de alvo Exadata Database Machine
Te Manager
No Enterprise
o
e c nic o gerenciamento do Database Machine como um todo integrado, em vez de como
viabiliza
T uma série de componentes relecionados. Esse aperfeiçoamento fundamental na arquitetura
do Enterprise Manager constitui a base de várias das melhorias de monitoramento e
gerenciamento específicas do Database Machine introduzidas nesta release.
Comparado às releases anteriores, o processo de configuração do Enterprise para gerenciar
o Exadata Database Machine foi bastante simplificado. O novo processo de descoberta
orientado por assistente torna a configuração muito mais fácil e rápida. Não é necessário
instalar plugins separados, e a descoberta dos componentes do Database Machine é feita
automaticamente pelo agente do Enterprise Manager.

Visualizando o Exadata Database Machine no
Enterprise Manager
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licCloud Control 12c introduz uma nova interface do usuário para
Te Manager
O Enterprise
o
ic
ecn
visualização do Exadata Database Machine e de seus componentes. Ela fornece uma view
T integrada dos componentes de hardware e software do Database Machine. O slide mostra
uma seleção de imagens de telas.
A imagem à esquerda mostra uma representação gráfica de um Exadata Database Machine
Full Rack. Usando essa view, os administradores podem relacionar facilmente os servidores
e os switches ao seu local físico no rack. Isso é especialmente útil quando um componente
de hardware gera um alerta, e o administrador é capaz de identificar facilmente o
componente com um alto grau de certeza.
As imagens do lado direito da tela mostram gráficos relacionados a diferentes métricas de
célula e de servidor de banco de dados. Esses layouts de tela organizados por servidor são
específicos do Database Machine, permitindo que os administradores relacionem facilmente
as informações da tela a componentes específicos do Database Machine.
Além das views do Database Machine organizadas por hardware, há várias views orientadas
ao sistema e ao software que permitem aos administradores monitorar o desempenho e a
disponibilidade, bem como o uso de recursos por bancos de dados, serviços e clusters.
Também são apresentados alertas do software referentes aos bancos de dados, aos clusters
e ao ASM. Uma view organizada por topologia dos clusters e do banco de dados do
Database Machine também é fornecida, enquanto o repositório de gerenciamento de
configuração incorporado rastreia as informações de versão associadas a todos os
componentes do Database Machine.
Monitoramento do Exadata Storage Server
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licCloud Control 12c dispõe de recursos avançados de monitoramento e
Te Manager
O Enterprise
o
ic
ecn
administração baseados em grupo. Por default, todas as células de um Database Machine
T são agrupadas em um grupo de células. Conforme mostrado na imagem da tela, recursos
consolidados de monitoramento são fornecidos para o grupo de células. Operações de
administração no nível de grupo também são fornecidas permitindo que as ações sejam
aplicadas de maneira consistente em todas as células do grupo.

Administração do Exadata Storage Server
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licCloud Control 12c permite a execução de tarefas de configuração e
Te Manager
O Enterprise
o
ic
ecn
administração de células. O slide mostra um exemplo da interface que pode ser usada para
T ativar, desativar e configurar o IORM (I/O Resource Manager). O Enterprise Manager Cloud
Control 12c também inclui inúmeras outras funções de administração de célula, como a
capacidade de iniciar e interromper serviços de célula, verificar a conectividade de células
e configurar o acesso SSH.

Monitoramento do Desempenho do Exadata
Storage Server
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic no slide mostra um exemplo dos recursos de monitoramento do
e tela contida
A imagem
o Tda
ic
ecn
desempenho do Exadata Storage Server no Enterprise Manager Cloud Control 12c. As
T informações apresentadas pelo Enterprise Manager fornecem uma view composta dos
indicadores de desempenho referentes a uma única célula ou a um grupo de células. Quando
os usuários apontam para os diversos elementos do gráfico, informações adicionais são
exibidas.

Monitoramento da Integridade do Exadata
Storage Server
le
fe rab
tr a ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic no slide mostra um exemplo dos recursos de monitoramento
e tela contida
A imagem
o Tda
ic
ecn
da integridade do Exadata Storage Server no Enterprise Manager Cloud Control 12c.
T As informações apresentadas pelo Enterprise Manager fornecem uma view composta
dos indicadores de integridade referentes a um grupo de células.
Um controle deslizante permite o exame direcionado de um período de tempo específico.
Informações mais detalhadas sobre o período selecionado também podem ser examinadas.
As informações detalhadas podem estar relacionadas a problemas como uma degradação
da resposta, desbalanceamentos da carga de entrada/saída, problemas relacionados ao
ASM, falhas de software ou de hardware nas células, problemas de configuração de células e
falhas relacionadas à rede.

Monitoramento da Rede InfiniBand do
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Cloud Control 12c, os InfiniBand switches e a rede InfiniBand do
Te Manager
No Enterprise
o
e c nic Database Machine são alvos nativos que são descobertos automaticamente durante
Exadata
T o processo de descoberta guiado. Métricas de desempenho em tempo real e histórico
relacionadas à rede InfiniBand estão disponíveis para análise dos administradores. Além
disso, o Enterprise Manager destacará as condições de alerta geradas nos InfiniBand
switches ou relacionadas aos limites mantidos no Enterprise Manager. As métricas de
configuração são usadas para detectar e notificar os administradores sobre alterações
da rede e situações que violam as recomendações das melhores práticas.

Administração da Rede InfiniBand do
le
fe rab
tra ns
n -
no a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic
Uma nova
o Te
função del administração da rede InfiniBand do Exadata Database Machine
e c nic está disponível no Enterprise Manager Cloud Control 12c. As imagens contidas
também
T no slide mostram um exemplo de algumas das telas de administração da rede InfiniBand.
As ações de administração disponíveis incluem:
• Ativar uma porta InfiniBand.
• Desativar uma porta InfiniBand.
• Limpar contadores de desempenho.
• Limpar contadores de erro.
• Ligar um LED indicador.
• Desligar um LED indicador.

Resumo
Nesta lição, você aprendeu a descrever os principais recursos

de gerenciamento do Exadata Database Machine incluídos no

Enterprise Manager Cloud Control 12c.
le
fe rab
tr ans
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
o Te
ic
Tecn

D73668BP11 sg2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

D73668BP11 sg2

Enviado por

Direitos autorais:

Formatos disponíveis

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2013, Oracle and/or its affiliatesฺ

Revisores e Colaboradores Técnicos Este documento contém informações de propriedade da Oracle

documento não pode ser modificado nem alterado de forma alguma.

Christian Craft Sugam Pandey

Eric Siglin Varun Malhotra

Arquitetura da Rede InfiniBand 3-7

Visão Geral do Exercício 4: Introdução aos Recursos do Exadata 4-28

5 Configuração Inicial do Exadata Database Machine

6 Configuração do Exadata Storage Server

7 I/O Resource Management

Ativando o IORM para Vários Bancos de Dados 7-15

9 Usando o Smart Scan

Exemplo de Transação Concorrente 9-18

11 Migrando Bancos de Dados para o Exadata Database Machine

Melhores Práticas de Pós-Migração 11-13

14 Configurando o Enterprise Manager Grid Control 11g para Monitorar o Exadata

Implantando o Oracle Management Agent 14-6

15 Monitorando Exadata Storage Servers

Verificando Alertas Não Entregues 15-20

Monitorando o Avocent MergePoint Unity KVM Switch 18-5

19 Outras Ferramentas Úteis de Monitoramento

21 Tarefas de Manutenção do Exadata Database Machine

23 Ecossistema de Suporte Automatizado do Exadata Database Machine

24 Gerenciamento de Qualidade do Serviço

Background do Gerenciamento de Qualidade de Serviço 24-3

Carregamento de Dados em Massa Usando

Após concluir esta lição, você será capaz de:

• Descrever o processo de uso do Oracle DBFS para

Workshop de Administração do Exadata Database Machine 12 - 2

Sistema de Origem Database Machine

Banco de Dados de Destino

CREATE ... AS SELECT ...

k o ฺco dent DBFS

Workshop de Administração do Exadata Database Machine 12 - 3

• Os arquivos de dados podem ter qualquer formato

• Para facilitar o acesso paralelo de alto desempenho:

Workshop de Administração do Exadata Database Machine 12 - 4

• Os arquivos de dados devem ser sempre testados no DBFS

– Não use unidades internas do servidor de banco de dados

Workshop de Administração do Exadata Database Machine 12 - 5

• Use o DBCA para criar o banco de dados de teste

• Configuração adicional do sistema operacional do servidor

Workshop de Administração do Exadata Database Machine 12 - 7

• Criando o armazenamento DBFS

Workshop de Administração do Exadata Database Machine 12 - 8

Workshop de Administração do Exadata Database Machine 12 - 9

– Criar um objeto de diretório Oracle que referencie o diretório da

CELL_PARTITION_LARGE_EXTENTS como ฺ ou ALWAYS

Workshop de Administração do Exadata Database Machine 12 - 10

• Carregamento paralelo usando tabelas externas

– Uma instrução CREATE TABLE ... A instrução AS

Workshop de Administração do Exadata Database Machine 12 - 12

Para facilitar o carregamento paralelo a partir de arquivos

simples típicos, as definições de tabelas externas devem fazer

Workshop de Administração do Exadata Database Machine 12 - 13

Embora o DBFS seja totalmente funcional se for colocado

no mesmo local que o banco de dados de destino, é

Workshop de Administração do Exadata Database Machine 12 - 14

Nesta lição, você aprendeu a:

• Descrever o processo de uso do Oracle DBFS para

Workshop de Administração do Exadata Database Machine 12 - 15

– Carregamento de Dados em Massa com o Database

Workshop de Administração do Exadata Database Machine 12 - 16