D73668BP11 sg1

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 1
c
(te nse t o
o
k lice
o Tei
ic
Tecn
D73668BP11
Edição 1.1
Janeiro de 2013
D80374
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
Introduçã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,
e t oe/ou suas empresas afiliadas. Todos os direitos reservados.
t
o ( ense
i k lic
o Te
ic
Tecn
Objetivos do Curso
Após concluir este curso, você será capaz de:

• Descrever os principais recursos do Exadata Database
Machine
• Identificar as vantagens de usar o Exadata Database Machine
para diferentes classes de aplicações
• Descrever a arquitetura do Exadata Database Machine e sua
interação com o Oracle Database, o Oracle Clusterware e o
Oracle ASM r a ble
n s fe
• Concluir a configuração inicial do Exadata Database Machine
n - tra
• Descrever as diversas abordagens recomendadas
a no para efetuar
a migração para o Exadata Database Machine
) h as ฺ
• Configurar o I/O Resource Management
m ฺbr Guide
• Monitorar a integridade do Exadata
k o ฺco dDatabase
e nt Machine e
e i t u
otimizar o desempenho @t r
S
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t oe/ou suas empresas afiliadas. Todos os direitos reservados.
t e
i k o ( ense
o Te lic
ic
Tecn
Workshop de Administração do Exadata Database Machine 1 - 2

Público-Alvo e Pré-Requisitos
• Este curso se destina principalmente aos administradores

que configurarão e administrarão o Oracle Exadata

Database Machine
• Ele leva em consideração o prévio conhecimento e
entendimento dos seguintes itens:
– Oracle Database 11g Release 2, incluindo RAC e ASM
– Conceitos gerais de sistema operacional, rede, le
armazenamento e administração de sistemas fe rab
tra ns
• Treinamento prévio recomendado: n -
– a
Oracle Database 11g: Workshop de Administração I
no
a s
h eฺ II
– )
Oracle Database 11g: Workshop derAdministração
ฺ Guid
b
– Oracle 11g: Administração da m
co ent
Infraestrutura de Grade e RAC
o ฺ
– teik Linux
Administração do Sistema tudou Solaris
@ his S
r t
o se te
u p
c ฺs Oracletoe/ouusuas empresas afiliadas. Todos os direitos reservados.
Copyright © 2012,
e
t
o ( ense
i k
Tese destinalicprincipalmente aos administradores que configurarão e administrarão
Este curso
o
on
c ic Exadata Database Machine.
Oracle
T e Lembre-se dos pré-requisitos porque este curso não ensina todos os aspectos das
tecnologias usadas no Exadata Database Machine. Ele se concentra apenas nos tópicos
específicos ao Exadata Database Machine.
Este curso leva em consideração o conhecimento prévio e o entendimento do Oracle
Database 11g Release 2, incluindo o ASM (Automatic Storage Management) e o RAC (Real
Application Clusters). Também leva em conta um conhecimento prático do Unix/Linux,
juntamente com o domínio dos conceitos gerais de redes, armazenamento e administração
de sistemas.
Para alunos que não atendem aos pré-requisitos, o treinamento prévio recomendado inclui os
seguintes cursos:
• Oracle Database 11g: Workshop de Administração I
• Oracle Database 11g: Workshop de Administração II
• Oracle 11g: Administração da Infraestrutura de Grade e RAC
Além disso, o treinamento anterior sobre os conceitos básicos de administração do sistema
Linux ou Solaris é recomendado.

Conteúdo do Curso
1. Introdução (Esta Lição) 14. Configurando o Enterprise Manager Grid

2. Visão Geral do Exadata Database Machine Control 11g para Monitorar o Exadata
3. Arquitetura do Exadata Database Machine Database Machine

4. Principais Recursos do Exadata Database 15. Monitorando Exadata Storage Servers
Machine 16. Monitorando Servidores de Banco de
5. Configuração Inicial do Exadata Database Dados do Exadata Database Machine
Machine 17. Monitorando a Rede InfiniBand
6. Configuração do Exadata Storage Server 18. Monitorando Outros Componentes do
7. I/O Resource Management Exadata Database Machine
19. Outras Ferramentas Úteis de
8. Recomendações para Otimização do
le
rab
Desempenho de Bancos de Dados Monitoramento
20. Backup e Recuperação fe
9.
10.
Usando o Smart Scan
Opções e Recomendações de 21.
tr
Tarefas de Manutenção do Exadata ans
Database Machine n -
11.
Consolidação
Migrando Bancos de Dados para o 22.
a no
Aplicando Patches no Exadata Database
Exadata Database Machine Machine a
h eฺ s
12. Carregamento de Dados em Massa 23. r
ฺ Guid
b )
Ecossistema de Suporte Automatizado do
m Exadata Database Machine
ฺc24.o dent
Usando o Oracle DBFS
Gerenciamento de Qualidade do Serviço
13. Introdução ao Monitoramento da
k o
Plataforma Exadata Database Machine t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic das lições deste curso.
Te a ordem
O slideomostra
e c nic
T

Terminologia
• Durante todo o curso, 'Database Machine' é usado como

uma abreviação de 'Oracle Exadata Database Machine'.
– Em geral, Database Machine refere-se ao sistema completo,

incluindo hardware e software. No entanto, às vezes, há
referências específicas aos componentes de hardware ou
software do Database Machine.
• Durante todo o curso, os termos 'célula do Exadata' ou
simplesmente 'célula' podem ser usados como uma
r a ble
abreviação de 'Exadata Storage Server'. sfe a n
– Em geral, essas referências dizem respeito à combinação n- t r de
software e hardware usada no Exadata Storage n o
s a Server. No
entanto, às vezes, há referências específicas
r ) ha eao ฺ hardware
ou ao software do Exadata Storage
m ฺb Server. u id
– Este curso se refere ao Exadata ฺco dStorage G
nt Server X2-2 que se
k o e
baseia no hardware Sun. t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Te as convenções
O slideoindica usadas neste curso, para abreviar os nomes de produtos
i c
ecn
formais do Exadata Storage Server e do Oracle Exadata Database Machine.
T

Recursos Adicionais
• Demonstrações (Viewlets)
– http://www.oracle.com/technetwork/tutorials/index.html
– Acesse a Oracle Learning Library e procure demonstrações
cujo título contenha os termos Exadata ou Database
Machine.
• Home Page do Oracle Exadata
– http://www.oracle.com/exadata le
fe rab
• Home Page do Oracle Technology Network (OTN) ns
a
Exadata n-tr no
a
– http://otn.oracle.com/server-storage/engineered-
s
a
systems/exadata/index.html r) h eฺ ฺb id
• Fóruns de Discussão do OTNco m t Gu
Exadata
i k oฺ uden
– http://forums.oracle.com/forums/forum.jspa?forumID=829
@ te St
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 1:
Introdução ao Ambiente de Laboratório
Neste exercício, será apresentado a você o ambiente de
laboratório usado como apoio a todos os exercícios durante

este curso.
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
Visão Geral 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:

• Fornecer uma descrição geral do Exadata Storage Server

e das diferentes configurações do Database Machine
• Descrever as principais especificações de capacidade e
desempenho do Database Machine
• Descrever as principais vantagens associadas ao
le
Database Machine
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

Introdução ao Database Machine
• Plataforma totalmente integrada para o

Oracle Database
• Baseado na tecnologia de
armazenamento Exadata Storage Server
• Alto desempenho e alta disponibilidade
para todas as cargas de trabalho do
Oracle Database
r a ble
• Configurações de hardware n s fe
balanceadas n - tra
a no
• Perfeito como plataforma de as ฺ
) h
ฺ Guide
consolidação de bancos de dados br
m
• ฺco nt
Simples e fácil de implementar
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
TeMachinelicé uma plataforma Oracle Database totalmente integrada, baseada na
O Database
o
ic de armazenamento Exadata Storage Server. O Database Machine é uma solução
ecn
tecnologia
T de alto desempenho e altamente disponível para todas as cargas de trabalho de banco de
dados, desde aplicações de data warehouse de muitas varreduras até aplicações OLTP
altamente concorrentes.
Foi dada atenção especial para garantir que o Database Machine fosse uma plataforma
bem balanceada. Em toda a arquitetura de hardware do Database Machine, componentes
e tecnologias foram especialmente combinados para eliminar gargalos e, ao mesmo tempo,
manter uma boa utilização do hardware.
Utilizando os recursos exclusivos de gerenciamento de cargas de trabalho e clusterização
do Oracle Database, o Database Machine é excelente para consolidar vários bancos de
dados em um único Database Machine. Fornecido como um pacote completo de software,
servidores e armazenamento, o Database Machine é simples e fácil de implementar.
Observação: embora o Database Machine seja uma solução de plataforma totalmente
integrada, composta de componentes específicos de hardware e software, a Oracle oferece
esses componentes como uma série de itens adquiridos separadamente. Os clientes podem
escolher entre diferentes configurações de hardware disponíveis. O licenciamento adequado
do Oracle Database e do software de célula do Exadata também é necessário. Além disso, o
Database Machine é altamente complementado com operações paralelas e de clusterização.
Dessa forma, o Oracle Real Application Clusters e o Oracle Partitioning são opções de
software altamente recomendadas para o Database Machine.
Por Que o Database Machine?
O Database Machine foi projetado para tratar de problemas comuns:

• Problemas de Data Warehousing:

– Suportando consultas grandes e complexas
– Gerenciando bancos de dados muito grandes
• Problemas de OLTP:
– Suportando grandes populações de usuários e grandes volumes
de transações le
– Fornecendo tempos de resposta rápidos e consistentes r a b
fe ns
• Problemas de consolidação: t r a
no
– Suportando com eficiência cargas de trabalho mistas n-
a
– Priorizando cargas de trabalho as ) h eฺ
• Problemas de Configuração: b r
ฺ Guid
m
– Criando uma configuração o
k ฺco dentsem gargalos
balanceada
– Criando e mantendo um t eisistema
S turobusto operacional
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
TeMachinelicé um sistema projetado para tratar de problemas comuns enfrentados
O Database
o
pelaicmaioria dos usuários de banco de dados, especialmente à medida que o tamanho e a
Tecncomplexidade desses bancos aumentam. Durante este curso, você aprenderá sobre as
tecnologias e as práticas do Database Machine que tratam dos seguintes problemas e
requisitos:
• Problemas de Data Warehousing:
- Suportando consultas grandes e complexas:
• Obtém throughput suficiente de entrada/saída para suportar um grande número
de varreduras.
• Encaminha o throughput de entrada/saída pela rede de armazenamento.
• Evita entrada/saída não produtiva.
• Permite processamento paralelo.
- Gerenciando bancos de dados muito grandes:
• Gerencia de forma fácil e eficaz o espaço de armazenamento.
• Utiliza os recursos com eficiência ao mesmo tempo em que restringe consultas fora
de controle.
• Oferece compactação eficiente dos dados.

• Problemas de OLTP:
- Suportando grandes populações de usuários e grandes volumes de transações:
• Obtém entradas/saídas suficientes por segundo.
• Armazena no cache os dados acessados com frequência.
- Fornecendo tempos de resposta rápidos e consistentes:
• Minimiza a latência de entrada/saída.
• Permite o processamento eficiente de commit.

• Problemas de consolidação:
- Suportando com eficiência cargas de trabalho mistas:
• Suporta cargas de trabalho diferentes no mesmo sistema.
• Isola as cargas de trabalho para evitar conflito.
- Priorizando cargas de trabalho:
• Gerencia os recursos com base nas prioridades estabelecidas. le
• fe rab
Ajusta dinamicamente as alocações de recursos com base na configuração atual do
sistema e
tr a ns
em observações das cargas de trabalho. n -
• Problemas de Configuração: no
a
- Criando uma configuração balanceada sem gargalos: a s
h eฺ
b r )
ฺ Gpara ido sistema.
• Os componentes de hardware são dimensionados
m u
o ntpara os recursos de software.
• As especificações de hardware sãoฺc adequadas
k o de
- Criando e mantendo um sistema t ei robusto t uoperacional:
S firmware e software.
• Oferece compatibilidade r t e @de hardware,
h i s
p o práticase t
u
• Utiliza as melhores
ฺsde suporte. u s de configuração contribuindo para a consistência e a
c
facilidade
t e t o
( nse inteligentes de monitoramento.
• o Oferece ferramentas
e i k l ice
T
c n ico
T e

Introdução ao Exadata Storage Server
• Armazenamento de alto desempenho

Exadata Storage para o Oracle Database

Server
• Servidor Sun Fire baseado em Intel de
64 bits
• Software pré-instalado:
– Software do Exadata Storage Server
r a ble
– Oracle Linux x86_64
n s fe
– Drivers e Utilitários -tra on
• Disponível somente com o
a n
Database
s
Machine ) ha eฺ ฺbr 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 ic é altamente otimizado para uso com o Oracle Database. Ele
TeStorage lServer
O Exadata
o
ic um excelente desempenho do processamento SQL e de entradas/saídas para
ecn
oferece
T aplicações de data warehousing e OLTP (Online Transaction Processing).
O Exadata Storage Server usa um servidor Sun Fire baseado em Intel de 64 bits. A Oracle
fornece o software de servidor de armazenamento para transmitir inteligência de banco de
dados ao armazenamento e uma integração sólida com o Oracle Database e seus recursos.
Cada Exadata Storage Server vem com todos os componentes de hardware e software pré-
instalados, incluindo o respectivo software, o sistema operacional Oracle Linux x86_64 e os
drivers do protocolo InfiniBand.
O Exadata Storage Server está disponível somente para uso com o Database Machine.
Exadata Storage Servers individuais podem ser adquiridos, no entanto, eles devem ser
conectados a um Database Machine. Não há suporte para configurações personalizadas com
o uso de Exadata Storage Servers em novas instalações.

Visão Geral da Arquitetura do Exadata Storage Server
Servidores de Banco de Dados Oracle
le
fe rab
Célula do Célula do a ns
trLinux
SO Linux
n -
SO
Exadata
no
Software de Exadata Software de
célula do célula do
Exadata
s
Exadata a
) a
h eฺ
r
ฺ Guid…
b
… m
Disco
k o ฺco denDisco t
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic é uma plataforma de armazenamento “self-contained" que
TeStorage lServer
O Exadata
o
ic armazenamento em disco e executa o software do Exadata Storage Server
ecn
hospeda
T fornecido pela Oracle. Um único Exadata Storage Server também é chamado de célula.
Célula é um componente fundamental para uma grade de armazenamento. Mais células
fornecem uma maior capacidade e mais largura de banda de entrada/saída. Em geral, os
bancos de dados são implantados em várias células, e vários bancos de dados podem
compartilhar o armazenamento fornecido por uma única célula. Os bancos de dados e
as células se comunicam entre si por meio de uma rede InfiniBand de alto desempenho.
Cada célula é puramente uma plataforma de armazenamento dedicada para arquivos do
Oracle Database, embora seja possível usar o DBFS (Database File System), um recurso
do Oracle Database, para armazenar seus arquivos de negócio dentro do banco de dados.
Como outros arrays de armazenamento, cada célula é um computador com CPUs, memória,
um barramento, discos, adaptadores de rede e os outros componentes que, normalmente,
são encontrados em um servidor. Ela também executa um sistema operacional (SO) que,
no caso do Exadata Storage Server, é o Linux x86_64. O software fornecido pela Oracle
residente na célula do Exadata é executado nesse sistema operacional. É possível acessar
o SO de modo restrito para administrar e gerenciar o Exadata Storage Server.

Visão Geral dos Recursos do Exadata Storage Server
Servidores de Banco de Dados Oracle
entradas/saídas
entradas/saídas
Operações de entradas/saídas
50% de
16% de
34% de I/O Resource Management le
armazenamento
inteligente fe rab
Rede de armazenamento
tr a ns
de alto desempenho n -
a no
Smart Flash Cache a s
h eฺ Consolidação do
r )
ฺ Guid armazenamento
b
m
k o ฺco dent (Transparente para
ei Stu
bancos de dados)
t
o r e@ this de dados
tCompactação
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic recursos associados ao Exadata Storage Server:
Te os principais
O slideoilustra
ic
Tecn• Uma vantagem importante do Exadata Storage Server é a capacidade de descarregar
parte do processamento do banco de dados nos servidores de armazenamento. Com o
Exadata Storage Server, o banco de dados pode descarregar projeções e filtros de
predicados de varredura de tabela única, processamento de joins com base em filtros
"bloom", juntamente com operações de descriptografia e descompactação que
consomem muitos recursos de CPU. Essa capacidade é conhecida como Smart Scan.
Além do Smart Scan, o Exadata Storage Server conta com outros recursos de
armazenamento inteligente, incluindo a capacidade de descarregar otimizações de
backups incrementais, operações de criação de arquivos etc. Essa abordagem
proporciona uma economia substancial de CPU, memória e largura de banda de
entrada/saída no servidor de banco de dados, o que poderá resultar em melhorias
de desempenho significativas quando comparada ao armazenamento convencional.
• Mesmo para consultas que não usam o Smart Scan, o Exadata Storage Server oferece
muitas vantagens em relação ao armazenamento convencional. Ele é altamente
otimizado para rápido processamento de consultas grandes. Ele foi cuidadosamente
arquitetado para garantir que não haja gargalos na controladora nem em outros
componentes do servidor de armazenamento. Ele faz um uso inteligente da memória
flash de alto desempenho para aperfeiçoar o desempenho e também usa uma rede
InfiniBand avançada que produz um throughput muito mais elevado do que as redes
de armazenamento convencionais.
• O Exadata Storage Server inclui a compressão EHCC (Exadata Hybrid Columnar
Compression). Esse recurso oferece níveis muito altos de compactação de dados
implementada no servidor de armazenamento. A compressão EHCC (Exadata
Hybrid Columnar Compression) permite que o banco de dados reduza o número
de entradas/saídas necessárias para varrer uma tabela. Por exemplo, em geral, a
compressão EHCC (Exadata Hybrid Columnar Compression) oferece relações de
compactação de 10 para 1. Nesses casos, apenas 1 Gigabyte de entrada/saída é
necessário para varrer um conjunto de dados de 10 Gigabytes.

• O Exadata Storage Server garante que os recursos de entrada/saída sejam
disponibilizados a qualquer momento e para qualquer banco de dados que necessite
deles, com base nas prioridades e nas políticas definidas. O DBRM (Database
Resource Manager) e o IORM (I/O Resource Management) do Exadata Storage Server
operam em conjunto para gerenciar o uso de recursos de entrada/saída dentro do
mesmo banco de dados e entre diferentes bancos de dados, a fim de assegurar que
le
rab
os SLAs (Service Level Agreements, Contratos em Nível de Serviço) sejam atendidos
quando várias aplicações e bancos de dados compartilham o armazenamento do fe
Database Machine.
tra ns
n -
•
a no
O Oracle ASM (Automatic Storage Management) é usado para distribuir a carga de
armazenamento de maneira uniforme para cada banco de dados em todos os discos
a s
h eฺ
disponíveis no pool de armazenamento fornecido pelos Exadata Storage Servers. Cada
r )
ฺ Guid
b
banco de dados pode usar todos os discos disponíveis para maximizar o desempenho.
m
k o ฺco dent
O Exadata Storage Server requer o uso do Oracle Database 11g Release 2. Ele
t ei Stu
apresenta um bom desempenho tanto com bancos de dados de instância única
como com bancos de dados Oracle RAC (Real Application Clusters). Usuários e
r te@ this
administradores de banco de dados usam as mesmas ferramentas e conhecimento
o
s up use
com os quais já estão familiarizados. Como o Exadata Storage Server se baseia em
ฺ
t ec se to
componentes e tecnologias padrão do setor, sua implantação não é cara. Além disso, a
(
e i ko licen
integração justa com o conjunto completo de recursos de alta disponibilidade do Oracle
T
Database garante o atendimento das necessidades de confiabilidade e integridade de
o
ic
ecn
ambientes críticos.
T

Detalhes de Hardware do Exadata Storage Server
X2-2 (Sun Fire X4270 M2)
Processadores Dois Processadores Six-Core Intel® Xeon® L5640 (2,26 GHz)
Memória 24 GB (6 x 4 GB)
Unidades de Disco 12 SAS de Alto Desempenho de 600 GB 15K RPM

ou 12 SAS de Alta Capacidade de 3 TB 7,2K RPM
Flash 4 Placas PCle de 96 GB Sun Flash Accelerator F20 le
fe rab
Controladora de Disco Controladora de disco HBA com cache de 512 MB mantido
a n s por
bateria
n -t r
Rede Duas portas InfiniBand 4X QDR (40Gb/s) n o
(1 HCA PCIe 2.0 de porta dupla) s a
) a
h eฺ
Quatro portas Gigabit Ethernet rembutidas
m ฺ Guid
b
Gerenciamento Remoto 1 porta Ethernet (ILOM)
k o ฺco dent
Fontes de Alimentação t ei Stredundantes
2 fontes de alimentação u com "hot swap"
e @
rt e th i s
p o s empresas afiliadas. Todos os direitos reservados.
c ฺ suOracletoe/ouusuas
Copyright © 2012,
o (te nse
k ice
Tei uma ldescrição
O slideomostra do hardware do Exadata Storage Server X2-2.
n i c
T e c
Observação: todas as especificações de hardware, métricas de desempenho e métricas
de capacidade fornecidas neste curso foram atualizadas em 1º de março de 2012 e estão
sujeitas a alterações.
Planilhas de dados contendo especificações e métricas atualizadas podem ser encontradas
na home page do Oracle Exadata em http://www.oracle.com/exadata.

Especificações do Exadata Storage Server X2-2
Discos HP Discos HC
Exadata Smart Flash Cache1 384 GB 384 GB
Capacidade do Disco Bruto1 7,2 TB 36 TB
Capacidade de Dados não Compactados2 3,25 TB 16 TB
Throughput de Disco Bruto 1,8 GB/s 1,3 GB/s
Throughput de Flash 5,4 GB/s 4,9 GB/s

le
Entradas/saídas de Disco por Segundo 3.600 2.000
fe rab
(IOPS)
Entradas/saídas Flash por Segundo (IOPS) 100.000 tr
100.000 a ns
n -
no
a
1 - Capacidade bruta calculada usando 1 GB = 1000 x 1000 x 1000 bytes e 1 TB = 1000 x 1000 x
1000 x 1000 bytes. a
h eฺ s
2 - Dados do Usuário: espaço real para dados descompactados b r )
ฺ também
do usuário idfinal, adequado
calculado após
espelhamento único (redundância normal do ASM), oferecendo m G u
o falhandot disco. A capacidade realpara
espaço o
restabelecimento da proteção por espelhamento após o ฺ cuma e de
eik Stud
dados do usuário varia de acordo com a aplicação.
t
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic está disponível em duas configurações: com discos de alto
O Exadata
o TeStorage lServer
e c nic
desempenho (HP) ou com discos de alta capacidade (HC). A tabela contida no slide lista
T as principais especificações de capacidade e desempenho para as duas opções de
configuração.
Observação: essas métricas não levam em conta a compactação. Com dados compactados,
é possível atingir taxas de throughput efetivas muito mais altas. Em todo o caso, o
desempenho real variará de acordo com a aplicação.

Database Machine X2-2 Full Rack
14 Exadata Storage Servers 8 servidores de banco de

(todos de alto desempenho dados
ou alta capacidade) Sun Fire com duas CPUs
baseadas em Intel
1 Cisco Ethernet switch
(48 portas) Hardware KVM (Keyboard,
Video, Mouse)
le
3 Sun Datacenter InfiniBand e rab
2 PDUs (Power Distribution
f
Switches 36 n s
Units) na parte traseira
a
(switch QDR gerenciado de
n -t r
36 portas - 40 Gb/s) o
n Peças
Kit de
a
) h as ฺ Sobressalentes:
ฺbr Guide
•Duas unidades de disco rígido
(de alto desempenho ou alta
m
ฺco dent
capacidade)
k o •Duas placas de memória flash
t ei Stu de 96 GB
te@ this
•Cabos InfiniBand sobressalentes
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
O Database
o TeMachinelicé oferecido atualmente em quatro configurações. O conteúdo de uma
e c nic
configuração do Database Machine X2-2 Full Rack é ilustrado no slide.
T Um tour interativo do Database Machine X2-2 pode ser encontrado em
http://oracle.com.edgesuite.net/producttours/3d/exadata22/index.html

Detalhes de Hardware do Servidor de Banco de
Dados X2-2 (Sun Fire X4170 M2)
Processadores Dois Processadores Six-Core Intel® Xeon® X5675 (3,06 GHz)
Memória 96 GB (12 x 8 GB), expansível para 144 GB (18 x 8 GB)
Unidades de Disco Quatro discos SAS de 300 GB 10K RPM
Controladora de Disco Controladora de Disco HBA com cache de 512 MB mantido por
bateria le
Rede Duas portas InfiniBand QDR (40 Gb/s)
fe rab
(1 HCA PCIe 2.0 de porta dupla)
tr a ns
Quatro portas Ethernet de 1 Gb
n -
Duas portas Ethernet SFP+ de 10Gb no a
a
h eฺ s
(Uma placa de rede PCIe 2.0 de 10GbE de porta dupla baseada na
r
ฺ Guid
b )
tecnologia de Controlador Intel 82599 de 10GbE )
Gerenciamento Remoto 1 porta Ethernet (ILOM) m

k o ฺco dent
Fontes de Alimentação t ei Sturedundantes com "hot swap"
2 fontes de alimentação
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
TeMachinelicX2-2 usa hardware de servidor de banco de dados padronizado,
O Database
o
ic em servidores Sun Fire com tecnologia Intel de 64 bits.
ecn
baseado
T

Comece Pequeno e Cresça
le
fe rab
tra ns
n -
no a
a
h eฺ s
r )
ฺ Guid Full Rack
b
Quarter Half Rack m
Rack X2-2 o
X2-2
k ฺco dent X2-2
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k licMachine X2-2 Full Rack, que contém oito servidores de banco de
Além de
o T
um Database
e c nic 14 células do Exadata e três InfiniBand switches, a Oracle oferece duas outras
dados,
T configurações de Database Machine X2-2 que permitem aos clientes começarem pequenos e
crescerem:
• Um Quarter Rack contém dois servidores de banco de dados, três células do Exadata
e dois InfiniBand switches.
• Um Half Rack contém quatro servidores de banco de dados, sete células do Exadata e
três InfiniBand switches.
Todas as configurações do Database Machine X2-2 são fornecidas em um rack 42U de 19
polegadas padrão. Todas as configurações são pré-cabeadas e fornecidas com um Ethernet
switch e um KVM switch para concluir a configuração. Além disso, a Oracle oferece kits de
atualização de hardware, que permitem aos clientes fazerem o upgrade de um Quarter Rack
para um Half Rack ou de um Half Rack para um Full Rack.
O kit de peças sobressalentes que acompanha os Database Machines Half Rack e Quarter
Rack contém:
• Uma unidade de disco rígido (de alto desempenho ou alta capacidade).
• Uma placa de memória flash de 96 GB.
• Cabos InfiniBand sobressalentes.
Observe que um ambiente do Database Machine poderá ser expandido para além da
capacidade de um único rack. As configurações de vários racks são discutidas mais
adiante no curso.
Database Machine X2-8 Full Rack
14 Exadata Storage Servers

2 servidores de banco de
(todos de alto desempenho
dados
ou de alta capacidade)
Sun Fire com oito CPUs
baseadas em Intel
1 Cisco Ethernet switch
(48 portas)
le
3 Sun Datacenter InfiniBand
fe rab
2 PDUs (Power Distribution
Switches 36 ns
Units) na parte traseira
tra
(switch QDR gerenciado de
36 portas - 40 Gb/s) n -
oPeças
n
Kit de
a
h a s Sobressalentes:
r ) d e ฺ
•Duas unidades de disco rígido
m b
ฺ Gu i
(de alto desempenho ou alta
capacidade)
o
ฺc dent •Duas placas de memória flash
k o
ei Stu
de 96 GB
t •Cabos InfiniBand sobressalentes
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
e configurações
Além daso Ttrês do Database Machine X2-2, a Oracle oferece o Database
n i c
Machine X2-8, que está disponível apenas em uma configuração Full Rack. Não há
T e c
configurações menores.
Em muitos aspectos, o Database Machine X2-8 é basicamente o mesmo que o Full Rack
X2-2. Ambos contêm 14 células do Exadata X2-2, três InfiniBand switches, duas PDUs
(Power Distribution Units) e um Ethernet switch.
A principal diferença é que os oito servidores de banco de dados com duas CPUs do Full
Rack X2-2 são substituídos por dois servidores de banco de dados com oito CPUs. Cada um
dos servidores maiores contém mais RAM e é equipado com oito portas Ethernet de 10 Gb/s
para acesso de alta velocidade da rede cliente, além das portas Ethernet de 1 Gb/s que
oferecem suporte ao acesso administrativo.
O Database Machine X2-8 não é fornecido com hardware KVM.
O Database Machine X2-8 complementa os modelos X2-2. Como os modelos X2-2, foi
projetado para consolidação de bancos de dados, aplicações OLTP grandes e de data
warehouse. A configuração de memória de grande porte do Database Machine X2-8 o
transforma em uma plataforma especialmente boa para consolidação de bancos de dados.
Os clientes que atualmente executam suas aplicações em sistemas SMP de grande porte
podem ter mais conforto optando pelo Database Machine X2-8.
Um tour interativo do Database Machine X2-8 pode ser encontrado em
http://oracle.com.edgesuite.net/producttours/3d/exadata28/index.html

Detalhes de Hardware do Servidor de Banco de
Dados X2-8 (Sun Fire X4800 M2)
Processadores 8 Processadores Ten-Core Intel® Xeon® E7-8870 (2,40 GHz)
Memória 2 TB (128 x 16 GB)
Unidades de Disco Oito discos SAS de 300 GB 10K RPM
Controladora de Disco Controladora de disco HBA com cache de 512 MB mantido por bateria le
fe rab
Rede Oito portas InfiniBand 4X QDR (40 Gb/s)
(4 módulos PCE 2.0 express de porta dupla)
tr a ns
n -
oito portas Ethernet de 1GbE e ano
Dois módulos Network Express (NEM), fornecendo um total de
Oito portas Ethernet SFP+ de 10 GbE a s

h de controlador
r )
(4 Fabric Express Modules (FEM) com tecnologia
d e ฺ Intel 82599 de 10GbE)
Gerenciamento Remoto 1 porta Ethernet (ILOM) om
b
ฺ Gu i
k o ฺc dent
Fontes de alimentação
t ei S
4 fontes de alimentação u
redundantes
t com "hot swap"
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic
Te uma ldescrição
O slideomostra do hardware do servidor de banco de dados usado no
i c
ecn
Database Machine X2-8.
T

Capacidade do Database Machine
Quarter Half Full Full

Rack Rack Rack Rack

X2-2 X2-2 X2-2 X2-8
Capacidade Alto Desempenho 21 TB 50 TB 100 TB 100 TB
do Disco
Bruto1 Alta Capacidade 108 TB 252 TB 504 TB 504 TB
Capacidade do Flash1 1,1 TB 2,6 TB 5,3 TB 5,3 TB

able
Capacidade Alto Desempenho 9,5 TB 22,5 TB 45 TB 45 TB fer
de Dados do a n s
Alta Capacidade 48 TB 112 TB
r
224 TB n-t224 TB
Usuário2
a no
1 - Capacidade bruta calculada usando 1 GB = 1000 x 1000 x 1000 h
) ase 1 TBฺ = 1000 x 1000 x
bytes
1000 x 1000 bytes.
m ฺbr Guide
espelhamento único (redundância normal do ASM), o co entambém
2 - Dados do Usuário: espaço real para dados descompactados
ฺ
oferecendo
dot usuário final, calculado após
espaço adequado para o
restabelecimento da proteção por espelhamento t e i kapós t
umau d
falha do disco. A capacidade real de
dados do usuário varia de acordo com a @ aplicação.s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic algumas métricas importantes de capacidade referentes às
A tabela
o T
do slide fornece
e c nic
configurações disponíveis do Database Machine.
T

Desempenho do Database Machine
Quarter Half Full Full

Rack Rack Rack Rack
X2-2 X2-2 X2-2 X2-8

Alto Desempenho 5,4 GB/s 12,5 GB/s 25 GB/s 25 GB/s
Throughput
do Disco3 Alta Capacidade 4 GB/s 9 GB/s 18 GB/s 18 GB/s
Alto Desempenho 16 GB/s 37,5 GB/s 75 GB/s 75 GB/s

Throughput
de Flash3 Alta Capacidade 14,5 GB/s 34 GB/s 68 GB/s 68 GB/s le
fe rab
Alto Desempenho 10.800 25.000 50.000
a s
n50.000
IOPS de
n - tr
Disco4 Alta Capacidade 6.000 14.000 no
28.000
a 28.000
IOPS de Flash4 375.000 ) h as 1.500.000

750.000 ฺ 1.500.000
b
ฺ Gur i d e
o m
k o ฺc depico,
3 – Refere-se ao throughput de varredura física no horário de nt supondo que não há
compactação.
t ei baseSemtusolicitações de entrada/saída de 8 K
te@ this
4 – Entradas/saídas por segundo (IOPS) – com
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
A tabela
o T e
acima mostra licalgumas métricas de desempenho de pico para as diferentes
e c nic
configurações do Database Machine.
T Observação: essas métricas não levam em conta a compactação. Como resultado, elas são
muito conservadoras. Com dados compactados, é possível atingir taxas de throughput muito
mais altas. Em todos os casos, o desempenho real variará de acordo com a aplicação.

Exadata Storage Expansion Racks
Quarter Rack Half Full

Rack Rack
Exadata Storage Servers 4 9 18
InfiniBand Switches 2 3 3
Capacidade do Flash1 1,5 TB 3,4 TB 6,75 TB
IOPS de Flash4 425.000 950.000 1.900.000
Capacidade do Alto Desempenho 28 TB 64 TB 128 TB

Disco Bruto1
Alta Capacidade 144 TB 324 TB 648 TB
Capacidade de Alto Desempenho 13 TB 29 TB 58 TB le

Dados do Usuário2
Alta Capacidade 64 TB 144 TB 288 TB
fe rab
Throughput do Alto Desempenho 7,2 GB/s 16 GB/s
tra
32 GB/s ns
Disco3 n -
Alta Capacidade 5 GB/s 11,5 GB/s
no 23 GB/s
a 97 GB/s
Throughput de Alto Desempenho 21,5 GB/s 48,5 GB/s
a s
h44 GB/s eฺ 88 GB/s
Flash3
Alta Capacidade 19 GB/s
b r )
ฺ 18.000 id
IOPS de Disco 4 Alto Desempenho 8.000 m
o nt G u 36.000
ฺ c
o14.400ude 32.000
Alta Capacidade
t e i k t
64.000
1, 2, 3, 4 – Consulte as observaçõese @páginas

nas i s S
anteriores.
r t
o se t h
u p
Copyright © 2012,
e
t
o ( ense
e i k lic Expansion Rack foi projetado para ser a maneira mais simples,
O Oracle
o TExadata Storage
ic e eficiente de adicionar mais capacidade de armazenamento a um Exadata Database
ecn
rápida
T Machine. Uma extensão natural do Exadata Database Machine, o Exadata Storage
Expansion Rack é oferecido em três configurações. A tabela do slide descreve o conteúdo
de cada Exadata Storage Expansion Rack, junto com as principais métricas de capacidade
e desempenho.
Observe que os Exadata Storage Expansion Racks Full Rack e Half Rack são dotados de
três InfiniBand Switches QDR (40 Gb/sec) de 36 portas, o que permite interconectá-los a
vários outros Full Racks e Half Racks (Database Machine ou Storage Expansion Racks). Os
Exadata Storage Expansion Racks Quarter Rack apresentam dois InfiniBand Switches QDR
(40 Gb/sec) de 36 portas, o que permite a interconectividade em um conjunto mais limitado
de circunstâncias. Detalhes sobre a interconexão de vários racks são fornecidos mais adiante
no curso.

Rede InfiniBand
InfiniBand:
• É a estrutura de interconexão do Database Machine:

– Fornece o desempenho máximo disponível – 40 Gb/s em cada direção
– É amplamente usada em computação de alto desempenho desde 2002
• É usada para redes de armazenamento, interconexão do RAC
e conectividade externa de alto desempenho:
– Menos configurações, custo mais baixo e melhor desempenho
• Semelhante à Ethernet normal para hospedagem de software:
a b le
– Todas as ferramentas baseadas em IP operam de forma transparente – fe r
TCP/IP, UDP, SSH etc. a n s
n -t r
• Apresenta a eficiência de uma SAN: o
– Recursos de cópia zero e reserva de buffer a n
• Usa o protocolo ZDP InfiniBand de alto desempenho ) h as ฺ (RDS V3):
– Protocolo ZDP (Zero-loss Zero-copy Datagram m ฺbr Protocol)
u ide
– Software de código-fonte abertoo ฺ co entpela
desenvolvido
G Oracle
– Overhead muito baixo de CPU t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licrede de armazenamento com suporte no Database Machine devido ao
Teé a única
A InfiniBand
o
seuic
ecn
desempenho e histórico operacional comprovado na computação de alto desempenho. A
T InfiniBand é semelhante à Ethernet normal, mas é muito mais rápida. Ela tem a eficiência de
uma SAN, usando os recursos de cópia zero e reserva de buffer. Cópia zero significa que os
dados são transferidos pela rede sem cópias intermediárias do buffer nas várias camadas de
rede. A reserva do buffer é usada de forma que o hardware sabe exatamente onde colocar
buffers com antecedência. Trata-se de duas características importantes, que diferenciam a
InfiniBand da Ethernet normal.
O protocolo Zero Data loss UDP (ZDP) é usado em conjunto com a InfiniBand. O ZDP é um
software de código-fonte aberto desenvolvido pela Oracle. Ele é semelhante ao UDP, porém,
mais confiável. Seu nome técnico completo é RDS (Reliable Datagram Sockets) V3. O
protocolo ZDP apresenta um overhead de CPU muito baixo, com testes mostrando uma
utilização de apenas 2% da CPU na transferência de 1 GB/s de dados.
A InfiniBand fornece uma estrutura de rede unificada para o armazenamento do Database
Machine e a interconexão do Oracle RAC. Isso resulta em uma configuração mais fácil, bem
como em menos cabos e switches. A rede InfiniBand do Database Machine também pode ser
usada para conectividade externa de alto desempenho, como, por exemplo, para conectar
servidores de backup, servidores ETL e bibliotecas de fita. Além disso, ela é usada para
conectar o Oracle Exalogic Elastic Cloud, fornecendo conectividade de alto desempenho
entre as aplicações do middle-tier e os bancos de dados hospedados no Database Machine.
Visão Geral do Suporte ao Database Machine
Ofertas de Suporte Principais Recursos

• Incluída com o Database Machine, duração de um ano

• Acesso Web permanente, acesso por telefone em horário comercial local
Oracle Hardware
• Reposta em quatro horas durante o horário comercial normal
Warranty
• Resposta no local e troca de peças em dois dias úteis, sujeito à
disponibilidade e ao local
• Suporte ao Oracle Database e ao software de célula do Exadata
Oracle Premier • Acesso Web em qualquer horário ou acesso por telefone
Support • Aprimoramentos, correções e upgrades de software
• Ferramentas proativas, incluindo alertas e orientação sobre configuração
r a ble
• Suporte a hardware e firmware de servidor e de armazenamento; inclui
Oracle Linux n s fe o
Oracle Premier
• Acesso Web em qualquer horário ou acesso por telefone -tr
a
Support for Systems
• Resposta de hardware no local em duas horas se onDatabase o n Machine
estiver em uma área de cobertura de serviço deaduas horas
) h ascom falhasฺ
Oracle Customer Data
• Fornece substituições de unidades de
• O cliente retém as unidades de disco b
ฺ Gur disco
com i
falhasd e
and Device Retention
• Fornece segurança adicional o m
c edados
para t sensíveis
o ฺ n
t eik Stud
Consulte também http://www.oracle.com/support/policies.html
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
e umliconjuntoc
A Oracleo Tfornece completo e integrado de ofertas de suporte ao Database
n i c
Machine. Os clientes podem usar um único ponto de contato para acessar todos os serviços
T e c
de suporte destacados no slide. Também há um único ponto de responsabilidade, o que
significa que os problemas nunca permanecerão sem solução enquanto organizações de
suporte separadas aguardam o andamento entre si.
Os serviços de suporte destacados no slide são modulares, de forma que os clientes podem
escolher o nível correto de suporte para as suas necessidades. A Oracle Hardware Warranty
está incluída em cada Database Machine e é o nível mínimo de suporte. Em geral, o
Database Machine é implantado para aplicações importantes de negócio em escala
corporativa e, nesses casos, a Oracle recomenda que os clientes adquiram o Oracle Premier
Support e o Oracle Premier Support for Systems. O Oracle Customer Data and Device
Retention é recomendado quando os requisitos de segurança ou de privacidade obrigam
os clientes a garantir que dados sensíveis nunca deixem a empresa.
Além das ofertas de suporte destacadas aqui, a Oracle oferece serviços de instalação e de
configuração do Database Machine. Esses serviços são altamente recomendados para
garantir um início eficiente e sem problemas do Database Machine. Há serviços adicionais
para ajudar os clientes com upgrades de Quarter Rack para Half Rack ou de Half Rack para
Full Rack. Um serviço especializado também está disponível para os clientes que desejarem
interconectar vários racks do Database Machine.

Vantagens do Database Machine para
Data Warehousing
• Blocos modulares de células de armazenamento são organizados
em uma grade de armazenamento paralela fornecendo elevado

throughput de entrada/saída
• A rede de armazenamento InfiniBand é muito mais rápida do que
as redes de armazenamento SAN tradicionais, o que ajuda a
atingir o potencial da grade de armazenamento
• O processamento de consultas é movido para o armazenamento a
fim de reduzir drasticamente os dados enviados aos servidores e,rabl
e
ao mesmo tempo, aliviar a carga das CPUs dos servidores nsf
e
• A compressão EHCC (Exadata Hybrid Columnar Compression) n - tra
reduz o número de entradas/saídas físicas para a no
varreduras de
a s
h eฺ
tabelas grandes r )
• A consulta paralela na memória é uma m b
ฺ eficiente
u idestratégia
G
ฺco denot Exadata Storage
o
alternativa de consulta que complementa
k
Server t ei Stu
@ s r te thi
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Uma dasT
e ic
principais lvantagens do Database Machine é permitir o desempenho máximo das
i c o
aplicações de data warehousing. A maioria dos ganhos de desempenho resulta da arquitetura
e c
e
ndos recursos exclusivos associados à grade do Exadata Storage Server no Database
T Machine.
Essa grade trata de três dimensões importantes de entrada/saída de banco de dados que
podem afetar o desempenho do data warehouse:
• O Exadata Storage Server suporta inerentemente uma arquitetura paralela, que fornece
inúmeras conexões para transportar mais dados a uma velocidade maior entre os
servidores de armazenamento e os servidores de banco de dados. Cada Database
Machine contém entre três e 14 células do Exadata, cada uma com 12 discos físicos, o
que permite oferecer o elevado throughput de entrada/saída necessário para satisfazer a
consultas grandes de data warehousing.
• A rede de armazenamento do Database Machine é construída usando pipes amplos que
fornecem larguras de banda extremamente alta entre os servidores de armazenamento e
os servidores de banco de dados. O Database Machine usa a InfiniBand como a rede de
armazenamento, oferecendo um throughput de 40 Gb/s com uma latência muito baixa.
Essa largura de banda é muito maior do que a fornecida pelas redes de armazenamento
SAN tradicionais.
• O Exadata Storage Server é database-aware e é capaz de enviar apenas os dados
necessários para satisfazer às solicitações SQL, o que resulta no envio de um menor
volume de dados entre os servidores de armazenamento e os servidores de banco de
dados.
Essencialmente, a grade do Exadata Storage Server no Database Machine reduz o volume
de dados transportados e move-os com mais rapidez quando comparada a outros sistemas
baseados no armazenamento SAN tradicional.
O Exadata Storage Server fornece recursos adicionais que podem melhorar ainda mais o
desempenho do data warehouse.
A compressão EHCC (Exadata Hybrid Columnar Compression) oferece níveis muito alto
de compactação de dados implementada no Exadata Storage Server. Ela se beneficia de

varreduras de grande escala, normalmente usadas em data warehousing, varrendo, de forma
eficiente, grandes volumes de dados, com uma fração das entradas/saídas. Relações de
compactação de 10 para 1 são comuns, o que significa que uma tabela de 10 TB pode ser
varrida usando 1 TB de entradas/saídas do disco.
A total integração entre o Oracle Database e o Exadata Storage Server resulta em uma
plataforma inteligente para data warehousing. A solução completa usa uma variedade de
tecnologias para produzir o melhor resultado, não se baseia em apenas uma abordagem le
para solucionar o problema. Um exemplo disso é o novo recurso de consulta paralela na
fe rab
memória do Oracle Database 11g Release 2.
tra ns
n -
Normalmente, o Smart Scan seria usado para executar partes de uma consulta no Exadata
no
Storage Server e retornar o volume mínimo de dados para o servidor de banco de dados. Em
a
a s
alguns casos, no entanto, pode ser mais eficiente ler todos os dados solicitados na memória
h eฺ
r )
ฺ Guid
nos servidores de banco de dados e processar a consulta dessa forma.
b
m
k o ฺco defísica
A consulta paralela na memória aperfeiçoa o desempenho
ntdaadicional
consulta, minimizando ou
t e i
até mesmo eliminando completamente a entrada/saída
t u de uma consulta
específica. O Oracle Database decide,
e @de forma i s Sautomática, se um objeto acessado com
r t
o sdo
uma execução paralela se beneficiará h
tarmazenamento no cache do buffer do banco de
u
dados. A decisão de armazenar
p
s to uum
e
objeto no cache é baseada em um conjunto bem definido
c ฺ
o (te ontamanho
de heurísticas, incluindo
s e do objeto e a frequência em que ele é acessado.
A consulta e
T ik lnaicmemória
paralela e aproveita a memória agregada em todo um cluster de banco
de dados
i c o para operações paralelas, permitindo o dimensionamento, uma vez que o número
n
Tec
de nós em um cluster aumenta. Em um ambiente Oracle RAC, o Oracle Database mapeia
fragmentos do objeto em cada um dos caches do buffer, nas instâncias ativas. Com a criação
desse mapeamento, o Oracle Database sabe qual cache do buffer acessar para encontrar
uma parte ou partição específica de um objeto. Usando essas informações, o Oracle
Database evitará que várias instâncias leiam as mesmas informações do disco
repetidamente, maximizando, dessa forma, a quantidade de memória que pode ser usada
para armazenar os objetos no cache.
A consulta paralela na memória complementa muito bem o Exadata Storage Server. Com
essa combinação, algumas consultas podem ser executadas de forma eficiente com pouca
ou nenhuma entrada/saída adicional, retendo as tabelas no cache de buffer do banco de
dados, enquanto outras podem tirar proveito da funcionalidade do Smart Scan no Exadata
Storage Server.

Vantagens do Database Machine para OLTP
• Blocos modulares de células de armazenamento são

organizados em uma grade de armazenamento paralela
fornecendo elevado throughput de entrada/saída

• A rede de armazenamento InfiniBand é muito mais rápida do
que as redes de armazenamento SAN tradicionais, o que ajuda
a atingir o potencial da grade de armazenamento
• Servidores de banco de dados balanceados e eficientes com
grandes volumes de RAM ajudam a suportar grandes
populações de usuários e grandes caches de buffer de banco de r a ble
dados n s fe
n - tra
• O Exadata Smart Flash Cache fornece um cache secundário
n o de
a
alto desempenho para objetos acessados coms frequência, o que
h a ฺ
r)
é excelente para absorver consultas aleatórias drepetidas
e ฺb Gui
m
Centenas de
k o ฺco dent Dezenas de Milhares
Entradas/Saídas
t e i t u de Entradas/Saídas
por Segundo
r t e @ his S por Segundo
u p o se t
Copyright © 2012,
e
t
o ( ense
i k lic
e características
Algumas o Tdas fundamentais da arquitetura do Database Machine que são
i c
n para o data warehousing são igualmente relevantes e vantajosas para o OLTP (Online
úteis
T e c
Transaction Processing). A rede InfiniBand de alto desempenho e baixa latência, usada em
conjunto com a arquitetura intensamente paralela da grade de armazenamento do Database
Machine, é ideal para suportar milhares de usuários simultâneos.
Além disso, os servidores de banco de dados do Database Machine foram projetados para
serem eficientes e balanceados. Eles contêm volumes significativos de RAM, até 2 TB por
servidor no Database Machine X2-8, para suportar grandes números de conexões de cliente
e grandes caches de buffer, o que é vantajoso para o desempenho do OLTP.
Por fim, a introdução do Exadata Smart Flash Cache é particularmente benéfica ao
desempenho do OLTP. O Exadata Smart Flash Cache permite que cada célula do Exadata
faça transmissões de até 100.000 IOPS. Portanto, para as leituras aleatórias repetidas
frequentemente associadas às aplicações OLTP, o Exadata Smart Flash Cache fornece um
cache secundário, permitindo que lookups mais rápidos sejam executados nos dados que
não estão no cache de buffer do banco de dados. Além disso, o Oracle Database e o
Exadata Smart Flash Cache funcionam em uma sólida integração. Essa cooperação
otimiza o uso do Smart Flash Cache de forma que somente os dados acessados com
mais frequência e sensíveis ao desempenho são armazenados no cache. Os usuários
têm maior controle de quais objetos de banco de dados devem ser armazenados no cache
em detrimento de outros, e quais não devem ser armazenados no cache de forma alguma.
Questionário
Quantos Exadata Storage Servers existem em um Database

Machine Full Rack, Half Rack e Quarter Rack?

a. 16, 8, 4
b. 14, 7, 3
c. 12, 6, 3
d. 8, 4, 2
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
Quais são as três vantagens exclusivas do Exadata Storage

Server em relação aos servidores de armazenamento

tradicionais?
a. Discos maiores
b. Recursos de armazenamento inteligente
c. Maior largura de banda da rede de armazenamento
d. Maior capacidade de RAM r a ble
n s fe
e. Gerenciamento integrado de recursos de entrada/saída
tra de
n -
banco de dados 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
e c, e lic
Resposta:
o Tb,
e c nic
T

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

• Fornecer uma descrição geral do Exadata Storage Server

e das diferentes configurações do Database Machine
• Descrever as principais especificações de capacidade e
desempenho do Database Machine
• Descrever as principais vantagens associadas ao
le
Database Machine
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
Arquitetura 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

• Descrever a arquitetura de rede do Database Machine

• Descrever a arquitetura de software do Database Machine
• Descrever as entidades de armazenamento do Exadata
Storage Server e seus relacionamentos
• Descrever como vários Database Machines podem ser
interconectados 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 da Arquitetura do Database Machine
O Database Machine fornece uma plataforma de

elevado desempenho altamente disponível para

o Oracle Database, com base na arquitetura
clusterizada suportada pelo Oracle RAC. Os
principais componentes incluem:
• Armazenamento compartilhado avançado e
inteligente fornecido pelo Exadata Storage
Server
r a ble
• Espelhamento do armazenamento fornecido
n s fe
pelo ASM
n - tra
• Rede de armazenamento e interconexão de
a no
cluster de alta largura de banda e baixa has
latência baseadas na tecnologia InfiniBandr ) d e ฺ
m b
ฺ Gu i
o
c ente
• Servidores de banco de dados ฺeficientes
k o
balanceados unidos em um teiclustertud
@ his S
r t
o se te
u p
Copyright © 2012,
e
t
o ( ense
i k
TeMachinelicfornece uma plataforma resiliente de alto desempenho para
O Database
o
ic
ecn
implementações clusterizadas e não-clusterizadas do Oracle Database. A arquitetura
T fundamental subjacente ao Database Machine é a mesma arquitetura básica na qual o
software Oracle RAC (Real Application Clusters) se baseia. Os principais elementos da
arquitetura do Database Machine são apresentados a seguir e mais detalhes são fornecidos no
restante desta lição:
• Armazenamento compartilhado: o Database Machine fornece armazenamento
compartilhado inteligente e de alto desempenho para implementações de uma única
instância e RAC do Oracle Database usando a tecnologia Exadata Storage Server. O
armazenamento fornecido pelos Exadata Storage Servers é disponibilizado para os
bancos de dados Oracle por meio do recurso ASM (Automatic Storage Management) do
Oracle Database. O ASM adiciona resiliência ao armazenamento do Exadata Database
Machine fornecendo um esquema de espelhamento que pode ser usado para manter
cópias redundantes dos dados em Exadata Storage Servers separados. Isso garante
proteção contra a perda de dados em caso de perda de um servidor de armazenamento.
A proteção normal garante que duas cópias dos dados sejam mantidas em Exadata
Storage Servers separados, enquanto a proteção de alto nível mantém três cópias dos
dados em três Exadata Storage Servers distintos.

• Rede de armazenamento: o Database Machine contém uma rede de armazenamento
baseada na tecnologia InfiniBand. Isso permite acesso com alta largura de banda e
baixa latência aos Exadata Storage Servers. A tolerância a falhas é incorporada na
arquitetura de rede por meio de vários switches de rede redundantes e do acoplamento
de interfaces de rede.
• Cluster de servidores: os servidores de banco de dados do Database Machine foram
projetados para serem eficientes e balanceados de modo que não haja gargalos na
arquitetura do servidor. Eles são equipados com todos os componentes necessários

para o Oracle RAC, permitindo que os clientes implantem facilmente o Oracle RAC em
um único Database Machine. Quando os requisitos de processamento excedem a
capacidade de um único Database Machine, os clientes podem unir vários Database
Machines a fim de criar um cluster de servidores unificado.
• Interconexão de cluster: as características de alta largura de banda e baixa latência
da InfiniBand são ideais para os requisitos da interconexão de cluster. Por esse motivo,
le
o Database Machine é configurado, por default, para também usar o armazenamento
de rede InfiniBand como a interconexão de cluster. fe rab
• tra ns
Cache compartilhado: em um ambiente RAC, os caches de buffer de instância são
n -
a no
compartilhados. Se uma instância tiver em seu cache um item de dados necessário
a outra instância, esses dados serão enviados para o nó adequado por meio da
a s
h eฺ
interconexão de cluster. Esse atributo-chave da arquitetura RAC melhora
)
b r
ฺ Guid
significativamente o desempenho, uma vez que a transferência de informações entre
m
k o ฺco dent
memórias por meio da interconexão é muito mais rápida do que a gravação e a leitura
ei Stu
das informações com o uso do disco. Com o Database Machine, o recurso de cache
t
tecnologia InfiniBand. o r te@ this
compartilhado usa a interconexão de cluster de alto desempenho baseada na
ฺ s up use
( t ec se to
e i ko licen
o T
ic
Tecn

Arquitetura de Rede do Database Machine
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 ic slide mostra como os principais componentes do Database Machine
Tecontidolno
O diagrama
o
icestão conectados entre si. O diagrama mostra o hardware KVM, o Ethernet switch, as
ecn
X2-2
T PDUs (Power Distribution Units) e os InfiniBand switches. Para fins de clareza, somente um
servidor de banco de dados e um servidor Exadata são mostrados. O Database Machine
contém três tipos de rede:
• Gerenciamento/ILOM: trata-se de uma rede Ethernet/IP padrão usada para gerenciar o
Database Machine. Com essa rede, os administradores podem acessar os servidores
de banco de dados e os Exadata Storage Servers usando o hardware KVM ou recursos
de login remoto, como o SSH (Secure Shell). Os servidores de banco de dados e os
Exadata Storage Servers também fornecem uma interface Ethernet para o ILOM
(Integrated Lights-Out Management). O ILOM fornece um poderoso conjunto de
recursos de administração remota. Utilizando o ILOM, os administradores podem
monitorar e controlar, de forma remota, o estado do hardware do servidor. Os InfiniBand
switches e as PDUs também fornecem portas Ethernet para fins de gerenciamento e
monitoramento remotos.
• Acesso do Cliente: trata-se também de uma rede Ethernet padrão, que é usada
principalmente para fornecer conectividade de banco de dados por meio do software
Oracle Net. Na configuração inicial do Database Machine, os clientes podem optar por
configurar os servidores de banco de dados com uma única interface de rede do cliente
(NET1) ou configurar uma interface de rede acoplada (usando NET1 e NET2).
Uma interface de rede de acesso do cliente acoplada poderá oferecer proteção se
ocorrer uma falha na interface de rede. No entanto, o uso de interfaces acopladas pode
exigir configurações adicionais na rede do cliente. Cada servidor de banco de dados
X2-2 também contém uma porta Ethernet sobressalente (NET3) que pode ser usada
para configurar uma rede adicional de acesso do cliente.
Cada servidor de banco de dados X2-2 também é dotado de duas interfaces Ethernet
de 10 gigabits (10 GbE) que podem ser usadas para conectividade do cliente. Essas
interfaces podem estar acopladas ou conectadas a redes separadas. Os clientes devem

ter a infraestrutura de rede necessária para 10 GbE a fim de usar essas interfaces.
• InfiniBand: a rede InfiniBand fornece uma rede de armazenamento de alta velocidade
confiável e interconexão de cluster para o Database Machine. Ela também pode ser
usada para fornecer conectividade externa de alto desempenho com servidores de
backup, servidores ETL e servidores de middleware, como o Oracle Exalogic Elastic
Cloud. Cada servidor de banco de dados e Exadata Storage Server é conectado à rede
le
descrita em mais detalhes mais adiante nesta lição. fe rab
InfiniBand por meio de uma interface de rede acoplada (BONDIB0). A rede InfiniBand é
tra ns
A arquitetura de rede do Database Machine X2-8 é essencialmente a mesma do Database
n -
Machine X2-2, com as diferenças:
a no
a s
• Cada servidor de banco de dados contém dois Network Express Modules fornecendo
h eฺ
r )
um total de oito portas de rede de 10 GbE e oito portas Ethernet de 1 Gb. Isso significa
ฺ Guid
b
m
que há muito mais portas que podem ser usadas para acesso do cliente.
o ฺco dent
• Cada servidor de banco de dados é configurado com quatro interfaces de rede
k
t ei Stu
InfiniBand acopladas (BONDIB0, BONDIB1, BONDIB2, BONDIB3) que são conectadas
à rede InfiniBand.
o r te@ this
ฺ s up use
• O Database Machine X2-8 não contém hardware KVM. Em vez disso, o acesso remoto
t ec se to
à console é fornecido através da console ILOM. Os servidores também podem ser
(
e i ko licen
acessados para fins de administração por meio de recursos de login remoto, como
SSH.
o T
ic
Tecn

Arquitetura da Rede InfiniBand
• Switches QDR (40 Gb/s) gerenciados de 36 portas Sun Datacenter.
– 2 leaf switches usados para conectar as portas InfiniBand do servidor
– 1 spine switch somente em configurações Full Rack e Half Rack

• Exadata Storage Servers e Servidores de Banco de Dados X2-2
– Cada servidor tem um HCA Infiniband QDR (40 Gb/s) de porta dupla
– Cada porta HCA é conectada a um leaf switch diferente para alta
disponibilidade
– Acoplamento ativo-passivo com um único endereço IP
le
rab
— O desempenho é limitado pelo barramento PCIe, portanto, o acoplamento
ativo-ativo não é necessário
fe
• Servidores de Banco de Dados X2-8 ns tra
n -
– Cada servidor tem quatro HCAs InfiniBand QDR (40 Gb/s)
a no de porta
dupla
) h as diferentes
ฺ
– Cada par de portas HCA é conectado a leaf
ฺ b r switches
i d e para
alta disponibilidade
om nt G u
– Acoplamento ativo-passivo para ฺ c
o cadaudpare acoplado
e i k
t na fábrica t
• As conexões são cabeadas @ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k c
DentroodoTDatabaseliMachine, a principal atribuição da rede InfiniBand é fornecer uma
e c nic
interconexão de alta disponibilidade confiável para oferecer suporte às comunicações entre o
T servidor de banco de dados e o servidor de armazenamento. Também é usada para facilitar
a comunicação e a coordenação entre os servidores de banco de dados usando os softwares
Oracle Clusterware e o Oracle RAC (Real Application Clusters). É importante observar que a
rede InfiniBand é interna ao Database Machine e não há necessidade de uma infraestrutura
InfiniBand adicional na rede do cliente.
Cada configuração do Database Machine usa, pelo menos, dois InfiniBand switches QDR (40
Gb/s) gerenciados de 36 portas Sun Datacenter. Cada servidor de banco de dados e cada
célula do Exadata é conectada aos dois switches usando uma ou mais interfaces de rede
acopladas. O acoplamento ativo-passivo e a redundância de switches garantem alta
disponibilidade. Se ocorrer uma falha no switch, a rede InfiniBand poderá ser mantida pelo
outro switch sem perda de desempenho. Os switches que conectam os servidores de banco
de dados e as células do Exadata em um rack são conhecidos como leaf switches.
As configurações Full Rack e Half Rack do Database Machine contêm um terceiro InfiniBand
switch, conhecido como spine switch. O spine switch conecta os dois leaf switches e também
é usado para conectar vários racks do Database Machine. As configurações Quarter Rack
não apresentam um spine switch.
A implementação da tecnologia InfiniBand no Database Machine usa o RDS/Open Fabrics
Enterprise Distribution (OFED) de código-fonte aberto. Os pacotes OFED são incluídos na
pilha de software do Database Machine.
Topologia Leaf Switch Full Rack X2-2
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 c como os dois leaf switches em cada Database Machine X2-2 Full
Tedo slideliilustra
O diagrama
o
icsão conectados aos servidores de banco de dados, aos servidores do Exadata e entre
ecn
Rack
T si. Cada servidor de banco de dados e cada célula do Exadata é configurada com uma
interface de rede acoplada (BOND0) que usa as duas portas HCA InfiniBand no servidor.
É usado um acoplamento ativo/passivo. Em todos os servidores, cada porta InfiniBand é
conectada a um leaf switch diferente.
Conforme ilustrado no diagrama, em um sistema Full Rack, as conexões ativas e passivas
são distribuídas entre todos os leaf switches para fins de balanceamento da carga de
trabalho. Nas configurações Half Rack e Quarter Rack, todos os links ativos são conectados
a um leaf switch e todos os links passivos são conectados ao outro leaf switch.
Além disso, os leaf switches são conectados entre si por meio de sete links inter-switch.
Todas as conexões são pré-cabeadas na fábrica.
O Database Machine X2-8 tem essencialmente a mesma topologia ilustrada anteriormente,
porém, cada um dos dois servidores de banco de dados tem quatro interfaces de rede
acopladas (BONDIB0, BONDIB1, BONDIB2, BONDIB3) com conexões distribuídas entre os
leaf switches. Assim como no Database Machine X2-2 Full Rack, os links de servidor ativos
e passivos são distribuídos entre os leaf switches para balanceamento da carga de trabalho.
Observação: os mapeamentos de portas de switch mostrados no diagrama são apenas
ilustrativos.

Topologia Spine e Leaf
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 c o spine switch adicionado, que existe somente nas configurações
Teno slidelimostra
O diagrama
o
Fullic
ecn
Rack e Half Rack do Database Machine. Conforme mostrado no diagrama, cada leaf
T switch é conectado ao spine switch usando um único link de rede. A finalidade do spine
switch é facilitar a conexão de vários racks, criando uma única grade de banco de dados de
grande escala.
Observação: os Quarter Racks podem ser interconectados a outros racks em situações
limitadas que são discutidas mais adiante nesta lição.

Desempenho e Capacidade Escaláveis
le
fe rab
Escalável Redundante e Tolerante n asFalhas
r a
• Escalável para oito racks
adicionando cabos
• A falha de qualquer
é tolerada. no
n-t componente
• Escalável de 9 para 36 racks com a • Os dados s asão espelhados em
) a
h os servidoresฺ
adição de dois InfiniBand switches
ฺ b todos
r i d e de
• Escalável para centenas de m tG u
armazenamento.
servidores de armazenamento paraoฺco e n
oferecer suporte a bancos deteik tu d
dados de vários petabytes @ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Full Rack e Half Rack, bem como os Racks de Expansão de
Te Machines
Os Database
o
e c nic
Armazenamento Full Rack e Half Rack, podem ser interconectados para aumentar o
T desempenho ou a capacidade de uma configuração do Database Machine de rack
único. É possível o escalonamento para até oito Full Racks com o simples acréscimo
de cabeamento entre eles. Há portas livres suficientes nos InfiniBand switches e largura
de banda suficiente para oito Database Machines Full Rack em execução no desempenho
total e com redundância completa.

Cenários Típicos de Escalonamento
• Sistema monolítico grande:
– Vários racks do Database Machine X2-2
— Possivelmente em conjunto com Exadata Storage Expansion Racks

– Vários racks do Database Machine X2-8
• Consolidação de plataformas:
– Vários racks do Database Machine X2-2 ou X2-8
• Capacidade máxima:
le
– Um rack do Database Machine X2-2 ou X2-8 em conjunto com Exadata
fe rab
Storage Expansion Racks
a ns
• n-tr
Capacidade adicional de armazenamento de alto desempenho:
no
– Vários racks do Database Machine com discos de alto desempenho
s a
Possivelmente com os servidores de banco de dadosaadicionais
—
r ) h e ฺ desativados
• Armazenamento em camadas:
m ฺb Guid
– Um ou mais racks do Database Machine
k o ฺco dX2-2 e ntou X2-8 com discos de alto
desempenho, em conjunto com
t ei umSoutumais Exadata Storage Expansion
Racks
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licde escalonamento são apresentados aqui. Esta não é uma lista
Cinco o Te típicos
cenários
e c nic Ela fornece apenas exemplos de situações comuns que exigem vários racks
completa.
T interconectados:
• Os sistemas monolíticos grandes podem exigir capacidade de computação, capacidade
de armazenamento ou throughput de entrada/saída maiores do que os oferecidos por
um único rack. Nesses casos, geralmente são implantados vários vários racks do
Database Machine. A implantação também poderá usar Exadata Storage Expansion
Racks para aumentar ainda mais a capacidade de armazenamento. Em um sistema
monolítico grande, uma combinação de Database Machines X2-2 e X2-8 não é
considerada, pois não é possível ter um único ambiente de banco de dados contendo
servidores de banco de dados dos racks X2-2 e X2-8.
• A consolidação de plataformas poderá reunir vários sistemas que juntos exigem
capacidade de computação, capacidade de armazenamento ou throughput de
entrada/saída maiores do que os oferecidos por um único rack. Nesses casos, podem
ser implantados vários racks do Database Machine, possivelmente em conjunto com
Exadata Storage Expansion Racks. Além disso, é possível interconectar modelos
do Database Machine X2-2 e 2-8 de modo que os bancos de dados executados
nos diferentes modelos possam compartilhar uma única grade de armazenamento
consolidada que abrange os dois tipos de racks. Em outras palavras, você poderá ter
uma única grade de armazenamento entre os dois modelos de Database Machine, mas
não uma única grade de banco de dados que abranja ambos os modelos.
• Os requisitos de processamento de vários sistemas podem ser atendidos com um
único rack do Database Machine, entretanto, a capacidade de armazenamento do
sistema poderá ser insuficiente. Nesses casos, o rack do Database Machine poderá
ser interconectado a um ou mais Exadata Storage Expansion Racks para oferecer a
capacidade de armazenamento necessária.
• Em alguns casos, uma capacidade adicional é necessária, entretanto, discos de alto
desempenho precisarão ser usados em todo o sistema. Nessa circunstância, vários
Database Machines contendo discos de alto desempenho podem ser interconectados.

Também é possível desativar (desligar) todos os servidores de banco de dados
excedentes. Isso eliminará o consumo desnecessário de energia, bem como ajudará
a otimizar os requisitos de licença de software.
• Em várias situações, os clientes usam discos de alto desempenho em seus Database
Machines, mas desejam discos de alta capacidade para fins de backup e arquivamento
de dados on-line. Esse requisito é facilmente atendido com a adição de Exadata
le
Storage Expansion Racks aos Database Machines. Assim, o armazenamento poderá
ser configurado em camadas, de modo que todos os discos de alto desempenho dos fe rab
tra ns
Database Machines sejam alocados a grupos de discos de dados, enquanto os discos
n -
no
de alta capacidade dos racks de expansão de armazenamento podem ser alocados a
a
grupos de discos que oferecem suporte à FRA ou a outra área dedicada ao
arquivamento on-line. a
h eฺs
b r )
ฺ é orientadoid a capacidade, os
Observação: nos três últimos casos, quando o requisito m G u
clientes também podem comprar Exadata Storage
k o ฺcoServers
e n tindividuais e colocá-los em um
rack separado. Embora essa opção sejate i
possível,
S udnão é abordada em detalhes neste
ela
t
curso devido ao grande número deeopções
todos esses casos, o ambiente o r t @ tdeixará
resultante h isconfiguração
de
de ser
que poderiam ser usadas. Em
padrão e, portanto, seu suporte se
u p s e
ua Oracle recomenda interconectar os racks por meio
e ฺs motivo,
tornará mais difícil. Porcesse
t o
das técnicas padrão t
( descritas
ousando senaStorage
próxima seção desta lição, em vez de montar configurações
personalizadasi k e n
Exadata Servers individuais.
T e l ic
n i co
Tec

Dimensionamento para Oito Racks
• Rede InfiniBand única baseada em uma topologia Fat

Tree
– Até oito racks suportados com os switches existentes
– Cabeamento de servidor de armazenamento e banco de
dados sem alterações
• Exemplo com dois racks:
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 ou Half Racks são conectados para formar uma grade de banco
Quando
o Te Full Racks
vários
ic de grande escala, a rede InfiniBand é modificada tornando-se semelhante a uma
dendados
c
e
T topologia Fat Tree. As conexões dos servidores de banco de dados e de armazenamento
com os leaf switches permanecem inalteradas.
Em um Database Machine Full Rack ou Half Rack autônomo, cada leaf switch tem oito links
que o conectam ao outro leaf switch no rack (sete links) e ao spine switch (1 link). Quando
vários racks estão interconectados, esses oito links são redistribuídos para os spine switches.
O diagrama contido no slide ilustra isso usando um exemplo com dois racks. Conforme
mostrado no diagrama, os sete links inter-switch que, originalmente, conectavam os leaf
switches em cada rack foram redistribuídos para que cada leaf switch tenha quatro links
para cada spine switch. Não há links diretos entre os spine switches e entre os leaf switches.
Para conectar oito racks, os oito links entre os leaf switches e os spine switches em cada
leaf switch são configurados para fornecer exatamente um link para cada spine switch. Para
configurações entre dois e oito racks, os oito links entre os leaf switches e os spine switches
em cada leaf switch são distribuídos com o máximo de uniformidade possível entre o número
total de spine switches.
A Oracle oferece suporte à interconexão de até oito racks usando os switches existentes em
cada rack. É possível interconectar até três Database Machines usando os cabos fornecidos
pela fábrica. Para interconectar mais do que três Database Machines, é necessário adquirir
cabos adicionais.
Dimensionamento para Mais de Oito Racks
• Rede InfiniBand única baseada em uma topologia Fat Tree

– Dimensione para 36 racks adicionando dos spine switches externos

– É adicionado um nível à topologia Fat Tree
• Exemplo:
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 entre 9 e 36 racks podem ser criadas com a adição de dois spine
Te contendo
Configurações
o
e c nic externos de 36 portas. O resultado é uma única rede InfiniBand ainda baseada em
switches
T uma topologia Fat Tree. Os spine switches externos simplesmente adicionam outro nível à
árvore.
A topologia de rede estendida é criada por meio do agrupamento dos racks, de modo
que cada grupo contenha entre 2 e 8 racks. Em cada grupo, os racks são interconectados
conforme descrito na página anterior. Os grupos de racks são interconectados ainda mais
adicionando-se um link entre o spine switch em cada rack e cada um dos dois spine switches
externos. Um exemplo é mostrado no diagrama do slide.
Como são necessários hops de rede adicionais para a comunicação entre os grupos de
racks, é recomendável agrupar os racks de forma a remover todas as comunicações
desnecessárias entre os grupos. Por exemplo, faria sentido criar uma configuração
de 10 racks com um grupo contendo seis racks e outro quatro racks se os grupos não
uniformes resultassem em uma redução significativa das comunicações entre grupos
em relação a dois grupos com cinco racks cada.

Interconectando Quarter Racks
• É possível interconectar Quarter Racks nas seguintes situações

limitadas:
– Interconectar dois Quarter Racks
— Conecte cada leaf switch em cada Quarter Rack aos dois leaf switches
no outro rack usando dois links para cada conexão
– Conectar um Quarter Rack a um Half Rack ou a um Full Rack
— Conecte cada leaf switch no Quarter Rack aos dois leaf switches no
outro rack usando dois links para cada conexão le
– Conectar um Quarter Rack a um grupo de até oito racks fe rab
interconectados
tr a ns
n -
—
Rack no
Remova os sete links inter-switch entre os leaf switches no Quarter
a
a
h eฺ s
Conecte cada leaf switch no Quarter Rack a cada spine switch nos
—
outros racks r
ฺ Guid
b )
m
Use dois links para cada conexão
—
k o ฺcseosehouver
houvertaté quatro racks adicionais
d e nmais de quatro racks adicionais
— i
Use um link para cada conexão
te Stu
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
É possível
o lic Quarter Racks nas seguintes situações limitadas. Observe que,
Teinterconectar
ic contexto, um Quarter Rack poderá ser um Database Machine Quarter Rack ou um
ecn
neste
T Rack de Expansão de Armazenamento Quarter Rack:
• Interconectar dois Quarter Racks: para isso, conecte cada leaf switch em cada
Quarter Rack aos dois leaf switches no outro rack. São usados dois links para cada
conexão inter-switch entre os racks. Os sete links inter-swicth existentes entre os leaf
switches permanecem inalterados.
• Conectar um Quarter Rack a um Half Rack ou a um Full Rack: para isso, conecte
também cada leaf switch no Quarter Rack aos dois leaf switches no outro rack.
São usados dois links para cada conexão inter-switch entre os racks. Os sete links
inter-swicth existentes entre os leaf switches permanecem inalterados. O spine switch
no Half Rack ou no Full Rack e os respectivos links no rack também permanecem
inalterados.

• Conectar um Quarter Rack a um grupo de até oito racks interconectados: para
esta configuração, o grupo de outros racks interconectados deve atender aos seguintes
requisitos:
- Ele deve conter apenas Half Racks ou apenas Full Racks; uma combinação de
Half Racks e Full Racks não é permitida.
- O grupo de outros racks deve estar interconectado por meio da topologia Fat Tree
descrita anteriormente nesta lição.
Pressupondo que os requisitos sejam atendidos, o Quarter Rack poderá ser

interconectado ao grupo usando o seguinte procedimento:
- Remova os sete links inter-swicth entre os leaf switches no Quarter Rack.
- Conecte cada leaf switch no Quarter Rack a cada spine switch nos outros racks
Use dois links para cada conexão se o Quarter Rack estiver sendo conectado a
um grupo de até quatro racks. Use um link para cada conexão se houver mais de
quatro racks adicionais. 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

Conectividade Externa da Rede InfiniBand
• Seis portas em cada leaf switch são reservadas para

conectividade externa
• As portas de conectividade externa podem ser usadas
para:
– Conectar a servidores de mídia para fins de backup em fita
– Conectar a servidores ETL externos
le
– Acesso de clientes ou aplicações
fe rab
— Incluindo o Oracle Exalogic Elastic Cloud
ra ns
• Use interfaces de rede acopladas do dispositivoon -t
externo
para garantir alta disponibilidade a n
s a
ha leaf eswitches
– Conecte cada um dos links acopladosr ) d ฺ
ฺ b i
separados om t Gu
i k oฺc uden
@ te St
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c switch são reservadas para conectividade externa. Essas portas
Teem cadalileaf
Seis portas
o
e c nic ser usadas para conectar os Database Machines diretamente aos servidores de mídia
podem
T usados para gerenciar dispositivos de armazenamento off-line, como bibliotecas de fitas. A
rede InfiniBand também pode ser utilizada para fornecer conectividade de alto desempenho
com servidores ETL associados a um data warehouse ou com servidores de middleware
associados a uma aplicação de negócios sensível ao desempenho.
É recomendável usar interfaces de rede acopladas no cliente ou no servidor externo, com
cada interface acoplada conectada a um leaf switch separado. O acoplamento ativo-passivo
deve ser usado para garantir a continuidade em caso de falha em um switch ou porta. Essa
recomendação indica que os clientes e os servidores externos se conectam à rede InfiniBand
essencialmente da mesma maneira que os servidores de banco de dados do Database
Machine e os Exadata Storage Servers.

Visão Geral da Arquitetura de Software do
Database Machine
BD de única instância BD para RAC
Servidor de banco Servidor de banco Servidor de banco
de dados de dados de dados Enterprise
Instância de Instância de Instância de Manager

banco de dados banco de dados banco de dados
DBRM DBRM DBRM
Único ASM ASM
ASM
cluster ASM
LIBCELL LIBCELL LIBCELL
Protocolo le
iDB pela
Rede de Armazenamento InfiniBand
fe rab
InfiniBand com
Failover de
tr ans
Caminho Oracle Linux Oracle Linux n -
Oracle Linux
Controle de Células
CELLSRV CELLSRV a MS
CELLSRV
no
CLI MS MS
a
h IORMs
(cellcli/dcli)
IORM IORM r ) d e ฺ RS
SSH
RS RS
m b
ฺ Gu i
o
ฺc dent
k o
Célula do Exadata t eido Exadata
Célula S tu Célula do Exadata
e @
rt e th i s
Copyright © 2012,
o (te nse
k lice
eide
o T
A arquitetura software do Exadata Database Machine inclui componentes do servidor
i c
ecn
de banco de dados e da célula do Exadata. A arquitetura geral é ilustrada no slide. Os
T componentes a seguir residem no servidor de banco de dados:
• Os clientes podem escolher o Oracle Linux x86_64 ou o Solaris 11 Express for x86
como o sistema operacional dos servidores de banco de dados do Exadata Database
Machine.
• Os servidores de banco de dados do Database Machine executam o Oracle Database
11g Release 2. A release do patch específica do software do Oracle Database deve
ser compatível com o software do Exadata Storage Server e outros componentes de
software do Database Machine. My Oracle Support bulletin 888828.1 contém uma lista
atualizada das versões suportadas desses componentes.
• O ASM (Automatic Storage Management) é solicitado e fornece um sistema de arquivos
e um gerenciador de volume otimizados para o Oracle Database.

• O Oracle Database se comunica com as células do Exadata usando uma biblioteca
especial chamada LIBCELL ($ORACLE_HOME/lib/libcell11.so). Em conjunto
com o kernel do banco de dados e o ASM, a LIBCELL mapeia de forma transparente
as operações de entrada/saída do banco de dados para operações avançadas do
Exadata Storage Server. A LIBCELL se comunica com as células do Exadata usando
o protocolo iDB (Intelligent Database). O iDB é um protocolo de transferência de dados
exclusivo da Oracle, baseado no RDS (Reliable Datagram Sockets), que é executado
no hardware de rede InfiniBand padrão do setor. A LIBCELL e o iDB permitem que as

instâncias ASM e do banco de dados utilizem os recursos do Exadata Storage Server,
como Smart Scan e I/O Resource Management.
• O DBRM (Database Resource Manager) está integrado ao IORM (Exadata Storage
Server I/O Resource Management). O DBRM e o IORM funcionam em conjunto para
garantir que os recursos de entrada/saída sejam alocados com base nas prioridades
definidas pelo administrador.
le
Observação: o slide ilustra a configuração recomendada na qual um único cluster ASM
é usado para consolidar o armazenamento para todos os seus bancos de dados. Como fe rab
tra ns
alternativa, você pode conectar vários ambientes ASM separados com grupos de discos
n -
distintos a um pool de Exadata Storage Servers.
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 da Arquitetura de Software do
BD de única instância
Database Machine
BD para RAC
Servidor de Servidor de Servidor de
banco de dados banco de dados banco de dados Enterprise
Instância de Instância de Instância de Manager

banco de dados banco de dados banco de dados
DBRM DBRM DBRM
Único ASM ASM
ASM
cluster ASM
LIBCELL LIBCELL LIBCELL
Protocolo le
iDB pela
fe rab
InfiniBand com
Failover de
tr ans
Caminho Oracle Linux Oracle Linux n -
Oracle Linux
Controle de
CELLSRV CELLSRV CELLSRV
no
a MS
Células CLI MS MS
a
h IORMs
(cellcli/dcli)
IORM IORM r ) d e ฺ RS
SSH
RS RS
m b
ฺ Gu i
o
ฺc dent
k o
Célula do Exadata t ei do Exadata
Célula S tu Célula do Exadata
e @
rt e th i s
Copyright © 2012,
o (te nse
T eik de software
Os componentes l ice contidos em cada célula do Exadata incluem:
o
• icO Oracle Linux x86_64 é o sistema operacional do Exadata Storage Server.
ec n
T • O CELLSRV (Cell Server) é o principal componente de software do Exadata Storage Server e
oferece a maior parte dos serviços de armazenamento do Exadata. O CELLSRV é um servidor
multithread. O CELLSRV atende a solicitações de blocos simples, como leituras do cache de
buffer do banco de dados, e a solicitações do Smart Scan, como varreduras de tabelas com
projeções e filtros. O CELLSRV também implementa o IORM, que funciona junto com o DBRM a
fim de medir a largura de banda de entrada/saída para os diversos bancos de dados e grupos de
consumidores que emitem entradas/saídas. Finalmente, o CELLSRV coleta várias estatísticas
relacionadas às suas operações. Os processos do Oracle Database e do ASM usam a
LIBCELL para se comunicar com o CELLSRV, e a LIBCELL converte as solicitações de
entrada/saída em mensagens que são enviadas para o CELLSRV por meio do protocolo iDB.
• O MS (Management Server) fornece as funções de configuração e gerenciamento de células do
Exadata. Ele opera em conjunto com o utilitário CellCLI (cell command-line interface) do
Exadata. Cada célula é gerenciada individualmente com o CellCLI. O utilitário CellCLI pode ser
usado somente em uma célula para gerenciar essa célula; no entanto, é possível executar o
mesmo comando CellCLI remotamente em várias células com o utilitário dcli. Além disso, o MS
é responsável pelo envio de alertas e pela coleta de algumas estatísticas, além das reunidas
pelo CELLSRV.
• O RS (Restart Server) é usado para inicializar/fazer shutdown dos serviços do CELLSRV e do
MS, bem como monitora esses serviços para que sejam reiniciados automaticamente se
necessário.

Detalhes da Arquitetura de
Software do Database Machine
Célula do Exadata Estruturas
Instância do RDBMS Instância ASM

Smart
SGA SGA
Impor- Flash Cache
tação ASM
Proc.
ASM
Proc.
dskm dskm
De De
entrada/saída entrada/saída
LIBCELL LIBCELL
/opt/oracle/cell/
cellsrv/deploy/ CellCLI
config cellsrv MS
cell_disk_ adrci diskmon css

config.xml Protocolo iDB Protocolo iDB
le
CELLSRV /etc/oracle/cell/network-config
fe rab
ns
cellinit.ora RS ADR
a cellinit.ora
n-tr
cellip.ora
bond0
Dicionário
interno MS
Listar células do
a no Listar IP de
as ฺ
Exadata acessíveis interface local
e
Rede InfiniBand
) h
ฺbr Guide
Parâmetros internos
CELLSRV e IP de
m
interface local
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 diagrama
o Tedo slideliapresenta uma visão mais detalhada dos principais componentes de
i c
n do Database Machine e dos relacionamentos existentes entre eles. Além disso,
software
T e c
também são listados alguns dos principais arquivos de configuração específicos do Exadata.
O diagrama também mostra alguns processos adicionais executados nos servidores de
banco de dados que estão relacionados ao uso das células do Exadata para armazenamento
no Database Machine. O Diskmon verifica o estado da interface de rede do armazenamento
e a atividade das células; ele também executa a propagação do plano do DBRM para as
células do Exadata.
O Diskmon usa um processo-mestre no nível de nó (diskmon.bin) e um processo escravo
(DSKM) para cada instância do RDBMS ou ASM. O mestre executa o monitoramento e
propaga as informações de estado para os escravos. Os escravos usam o SGA para se
comunicar com os processos do RDBMS ou do ASM. Se houver uma falha no cluster, o
Diskmon executará o isolamento da entrada/saída para proteger a integridade dos dados. O
CSS (Cluster Synchronization Services) ainda decide o que isolar.
O Diskmon-mestre é iniciado com os processos de clusterware. Os processos Diskmon
escravos são processos de background iniciados e interrompidos junto com a instância
associada do RDBMS ou ASM.

Entidades e Relacionamentos de
Armazenamento em Disco
Disco LUN CELLDISK GRIDDISK Disco ASM
Célula do Exadata CellCLI> CREATE GRIDDISK ...
Somente as duas
Partição de primeiras LUNs
Armazenamento Disco de
de Dados Grade
Área do Sistema le
Disco de fe rab
OU OU n spara
Visível
a
Célula -t r o ASM
n on
s
Disco ade Grade
LUN ) a
h eon-line)
(parte ฺ
Outras b r
ฺ GDisco i d
u de Grade
o m t
oฺc uden
dez LUNs (parte off-line)
i
te St k
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Cada o Tedo Exadata
célula lic contém 12 discos físicos. O software de célula do Exadata detecta
e c nic
automaticamente os discos físicos em cada servidor de armazenamento. Como
T administrador da célula, você pode somente visualizar um conjunto predefinido de atributos
do disco físico. Cada disco físico é mapeado para uma abstração lógica denominada LUN
(Unidade Lógica). Uma LUN expõe atributos de metadados predefinidos adicionais para o
administrador da célula. Você não pode criar nem remover uma LUN. Elas são criadas de
forma automática.
Cada um dos dois primeiros discos contém uma área do sistema que abrange várias
partições de disco. As duas áreas do sistema são cópias de espelho uma da outra, que são
mantidas por meio do espelhamento do software. As áreas do sistema consomem
aproximadamente 29 GB em cada disco. As áreas do sistema contêm a imagem do SO, o
espaço de swap, binários do software de célula do Exadata, o repositório de métricas e
alertas, além de vários outros arquivos de configuração e de metadados.
Um disco de célula é uma abstração de nível mais alto, que representa a área de
armazenamento de dados em cada LUN. No caso das duas LUNs que contêm as áreas do
sistema, o software de célula do Exadata reconhece a forma como a LUN está particionada e
mapeia o disco de célula para a partição de disco reservada para armazenamento de dados.
No caso dos outros 10 discos, o software de célula do Exadata mapeia o disco de célula
diretamente para a LUN.
Após a criação de um disco de célula, ele pode ser subdividido em um ou mais discos de
grade, que são expostos diretamente ao ASM.
A colocação de vários discos de grade em um disco de célula permite ao administrador
segregar o armazenamento em pools com diferentes características de desempenho. Por
exemplo, um disco de célula pode ser particionado de forma que o disco de grade resida na
parte de melhor desempenho do disco (as faixas mais externas do disco físico), enquanto um
segundo disco de grade pode ser configurado na parte com desempenho mais baixo do disco
(as faixas internas). Em seguida, o primeiro disco de grade pode ser usado em um grupo de
discos ASM que contém dados altamente ativos (muito acessados), enquanto o segundo
disco pode ser usado para armazenar arquivos de dados menos ativos (pouco acessados).
A colocação de vários discos de grade em um disco de célula também permite que o
administrador divida o armazenamento em dois pools separados, que podem ser designados
a bancos de dados diferentes.
Nos casos em que a capacidade da célula inteira é necessária para um único banco de
dados ou quando é difícil definir claramente conjuntos de dados muito e pouco acessados,
em geral, o administrador de célula do Exadata definirá um único disco de grade que contém
todo o espaço em cada disco de célula.
r a ble
Observação: o diagrama contido no slide mostra os casos em que um ou dois discos n s fede
ra implica um
grade são criados a partir do espaço em um disco de célula. Entretanto, isso-tnão
n
no o Database
limite de dois discos de grade em cada disco de célula. Na verdade, quando
a
h a s na maioria dos discos
Machine é configurado inicialmente, três discos de grade são definidos
)
de célula. Detalhes das opções de configuração inicial dorDatabase
d e ฺ
Machine e de seus
ฺ b u i
resultados são descritos mais adiante no curso.
ฺ c om nt G
i k o ude
t e S t
r @
te thi s
o
up use
ฺ s
( t ec se to
e i ko licen
i c oT
Tecn

Entidades e Relacionamentos de
Armazenamento Flash
Flash LUN CELLDISK GRIDDISK Disco ASM
OU
FLASHCACHE
Célula do Exadata CellCLI> CREATE FLASHCACHE ...

CellCLI> CREATE GRIDDISK ... FLASHDISK ...
Cache le
Flash fe rab
LUN Disco de tr a ns
Flash Célula
OU
n -
no
a
a s
h eCache
Flash
r ) d ฺ
m b
ฺ GDisco i
u de Grade
o t
i k oฺc uden
t e St Visível para
e @
rt e th i s o ASM

Copyright © 2012,
o (te nse
T ik lice
edo
Cada célula
em i c o placasExadata
quatro de
contém 384 GB de memória flash de alto desempenho distribuídos
memória flash PCI. Cada placa tem quatro módulos flash (FDOMs) para
e c n
um total de 16 módulos flash em cada célula. Cada dispositivo flash tem uma capacidade de
T 24 GB.
Basicamente, cada dispositivo flash é semelhante a um disco físico na hierarquia de
armazenamento. Cada dispositivo flash está visível para o software de célula do Exadata
como uma LUN. É possível criar um disco de célula usando o espaço em uma LUN baseada
em flash. Em seguida, você pode criar vários discos de grade em cada disco de célula
baseado em flash. Diferentemente dos dispositivos de disco físico, a ordem de alocação do
espaço flash não é importante da perspectiva do desempenho.
Embora seja possível criar discos de grade baseados em flash, o principal uso do
armazenamento flash é suportar o Exadata Smart Flash Cache, um mecanismo de
armazenamento em cache de alto desempenho para dados frequentemente acessados em
cada célula do Exadata.
Por default, o processo de configuração inicial da célula cria discos de célula baseados em
flash em todos os dispositivos flash e, em seguida, aloca a maior parte do espaço flash
disponível para o Exadata Smart Flash Cache. Para criar espaço para os discos de grade
baseados em flash, o Exadata Smart Flash Cache default deve ser eliminado primeiro. Em
seguida, um novo Exadata Smart Flash Cache e discos de grade baseados em flash podem
ser criados com os tamanhos escolhidos pelo administrador da célula.
Observação: o diagrama do slide mostra dois exemplos de como o espaço em um disco de
célula baseado em flash pode ser alocado. Entretanto, é possível alocar até uma área do
Exadata Smart Flash Cache e zero ou mais discos de grade baseados em flash a partir de
um disco de célula baseado em flash.
Configuração de Grupos de Discos
SQL> CREATE DISKGROUP
r a ble
Célula do Exadata (CELL1) Célula do Exadata (CELL2) n s fe
n - tra
Grupo com Proteção para Falhas CELL1
Grupo de
Discos Grupo com Proteção a no
para Falhas CELL2
DATA_1
) h as ฺ
ฺbrcomG idepara Falhas CELL2
Grupo de
Discos Grupo Proteção
Grupo com Proteção para Falhas CELL1
FRA_1
m u
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c discos de grade, é possível definir grupos de discos ASM para
Te
Após a configuração
o lidos
e c nic o armazenamento do Exadata. O slide ilustra um exemplo em que dois grupos de
consumir
discos ASM são definidos. O grupo de discos DATA_1 é definido em todos os discos de grade
T vermelhos, e o grupo de discos FRA_1 é definido nos discos de grade azuis. Quando os dados
são carregados em cada grupo de discos, o ASM os distribui de maneira uniforme entre todos
os discos de grade de cada grupo.
Para fornecer proteção contra a falha de um célula inteira do Exadata, grupos de discos para
falhas ASM separados são associados automaticamente a cada célula. O objetivo disso é
garantir que as extensões espelhadas do ASM sejam colocadas em diferentes células do
Exadata. Isso também é ilustrado no slide. Por default, quando grupos com proteção para falhas
são criados de forma automática, seus nomes correspondem ao nome da célula. Portanto,
diferentes grupos de discos podem ter os mesmos nomes de grupos com proteção para falhas.
Por exemplo, tanto o grupo de discos DATA como o grupo de discos FRA têm um grupo com
proteção para falhas chamado CELL1.
Como geralmente ocorre no caso do ASM, recomenda-se o uso da redundância NORMAL ou
HIGH do ASM com pelo menos três grupos com proteção para falhas em cada grupo de discos
no Database Machine. Isso garante que pelo menos duas cópias dos dados possam ser
acomodadas, mesmo em caso de falha em uma célula. Embora seja possível criar grupos de
discos com redundância EXTERNAL no Database Machine, não convém fazer isso, pois eles
não fornecem proteção contra falhas de armazenamento e impedem o uso de procedimentos de
manutenção de armazenamento on-line, como, por exemplo, a aplicação dinâmica de patches.
Observe que o processo de configuração inicial do Database Machine cria três grupos de discos
usando a redundância NORMAL ou HIGH do ASM. A configuração desses grupos de discos e das
opções de redundância associadas são discutidas em detalhes mais adiante no curso.
Questionário
Quais são os três principais serviços do Exadata?

a. OMS
b. MS
c. GMON
d. CELLSRV
e. RS 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
e d, e lic
Resposta:
o Tb,
e c nic
T

Questionário
Se você usar a redundância NORMAL do ASM para todos os

seus grupos de discos em conjunto com grupos de discos para

falhas ASM distribuídos em duas ou mais células do Exadata,
em quais dos seguintes cenários a disponibilidade dos dados
será mantida?
a. Falha em um único disco, em uma única célula
b. Falha simultânea de vários discos em uma única célula
r a ble
c. Falha simultânea de um disco em duas células n s fe
d. Falha total de uma única célula 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
Resposta:
o Ta,e b, d lic
An
c ic
configuração prescrita poderá oferecer proteção contra a falha simultânea de um disco em
T e duas células se e somente se não houver extensões de dados espelhadas nos dois discos
com falha. Para garantir a disponibilidade dos dados nos casos em que falhas simultâneas
afetam duas células, é necessário usar a redundância HIGH do ASM juntamente com grupos
com proteção para falhas distribuídos em, pelo menos, três células do Exadata.

Questionário
O recurso de acoplamento é usado para as interfaces de rede

InfiniBand nos servidores do Database Machine para fornecer:

a. Tolerância a Falhas e Alta Disponibilidade
b. Maior Largura de Banda e Desempenho
c. As duas alternativas acima
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 Tae
e c nicservidor de banco de dados e cada Exadata Storage Server é configurado com
Cada
T interfaces de rede acopladas, que usam as portas HCA InfiniBand no servidor. Como o
acoplamento ativo/passivo é usado, a largura de banda agregada dos links não é usada.
Para cada interface de rede acoplada, cada porta InfiniBand é conectada a um leaf switch
diferente. Essa configuração permite tolerância a falhas e alta disponibilidade, removendo o
InfiniBand switch como um ponto único de falha em potencial.

Questionário
Quais das opções de escalabilidade a seguir são suportadas?

a. Upgrade de um Database Machine Quarter Rack para um

Database Machine Half Rack
b. Upgrade de um Database Machine Half Rack para um
Database Machine Full Rack
c. Interconexão de dois Database Machines Quarter Rack
d. Interconexão de dois ou mais Database Machines Full erab
le
Rack n s f
ra 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
Resposta:
o Ta,e b, c, dlic
e c nic
T

Resumo

• Descrever a arquitetura de rede do Database Machine

• Descrever a arquitetura de software do Database Machine
• Descrever as entidades de armazenamento do Exadata
Storage Server e seus relacionamentos
• Descrever como vários Database Machines podem ser
interconectados 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
• Demonstrações da Lição
– Introdução ao Processo do Exadata

– Alta Disponibilidade do Exadata
– Hierarquia dos Objetos de Armazenamento do Exadata
• Tours Interativos
– Database Machine X2-2
le
– Database Machine X2-8
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

Introdução à Arquitetura de Células do Exadata
Nestes exercícios, você se familiarizará com a arquitetura de
células do Exadata. Você executará as seguintes tarefas:

• Examinará os processos do Exadata
• Testará a alta disponibilidade do Exadata
• Examinará a hierarquia de objetos de célula
• Examinará o Exadata Cache Smart Flash
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

Principais Recursos 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 descrever os

principais recursos 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

Modelo Clássico de Processamento de SQL e
Entrada/Saída de Banco de Dados
SELECT customer_id 1 6
Linhas retornadas
FROM orders
WHERE order_amount>20000;
Processamento
Extensões identificadas 2 5 SQL: 2 MB
retornados rab
le
n s fe
tra
n on-
s a
a
h eฺEntradas/saídas
Entradas/saídas emitidas 3 4br)
m ฺ Guid executadas:
k o ฺco dent 10 GB retornados
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic tradicional, toda a inteligência de banco de dados reside no software,
Te
Com ooarmazenamento
c ic
nonservidor de banco de dados. Para ilustrar como o processamento SQL é executado nessa
T e arquitetura, um exemplo de varredura de tabela é mostrado na figura contida no slide.
1. O cliente emite uma instrução SELECT com um predicado para filtrar uma tabela e
retornar somente as linhas de interesse do usuário.
2. O kernel de banco de dados mapeia essa solicitação para o arquivo e extensões que
contêm a tabela.
3. O kernel de banco de dados emite as Entradas/saídas para ler todos os blocos de
tabelas.
4. Todos os blocos da tabela que estiver sendo consultada são lidos na memória.
5. O processamento SQL é conduzido nos blocos de dados à procura de linhas que
atendam ao predicado.
6. As linhas necessárias são retornadas ao cliente.
Como quase sempre ocorre com consultas grandes, o predicado filtra a maioria das linhas
da tabela. Ainda assim, os blocos da tabela precisam ser lidos, transferidos pela rede de
armazenamento e copiados na memória. Muito mais linhas são lidas na memória do que o
necessário para concluir a operação SQL solicitada. Isso gera uma grande quantidade de
Entradas/saídas improdutivas, o que desperdiça recursos e afeta o throughput da aplicação
e o tempo de resposta.
Modelo do Exadata Smart Scan
SELECT customer_id 1 6 Linhas retornadas

FROM orders
WHERE order_amount>20000;
Conjunto de resultados
Comando iDB
2 5 consolidados, criado a
criado e enviado às
partir de todas as le
células do Exadata células do Exadatarab
n s fe
tra
n on-
s a
Processamento SQL 3 4 r) h
a ฺ2 MB retornados
nas células do Exadata b
ฺ Gu i d e
c o m t ao servidor
k ฺ
o ude n
t e i t
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic as operações de banco de dados são tratadas de maneira diferente. As
Te Machine,
Em um Database
o
e c nic que executam varreduras de tabelas podem ser processadas nas células do Exadata e
consultas
retornar somente o subconjunto necessário de dados ao servidor de banco de dados. É possível
T executar filtragem de linhas e de colunas, processamento de joins e outras funções nas células
do Exadata. O Exadata Storage Server usa um mecanismo especial de leitura direta para o
processamento do Smart Scan. A figura acima ilustra como uma varredura de tabela funciona
com um armazenamento de célula do Exadata:
1. O cliente emite uma instrução SELECT para retornar algumas linhas de interesse.
2. O kernel do banco de dados determina que os dados sejam armazenados nas células do
Exadata; assim, um comando iDB que representa o comando SQL é criado e enviado para
as células do Exadata.
3. O software do Exadata Storage Server varre os blocos de dados para extrair as linhas e as
colunas relevantes que atendem ao comando SQL.
4. As células do Exadata retornam para a instância do banco de dados mensagens do iDB
contendo as linhas e as colunas de dados solicitadas. Esses resultados não são imagens de
blocos, então, não são armazenados no cache do buffer.
5. O kernel de banco de dados consolida os conjuntos de resultados de todas as células do
Exadata. É similar à forma pela qual os resultados de uma operação de consulta paralela são
consolidados.
6. As linhas são retornadas ao cliente.
A retirada do processamento SQL do servidor de banco de dados libera ciclos da CPU do servidor e
elimina uma grande quantidade de transferências de Entrada/saída improdutivas. Esses recursos ficam
livres para melhor atender a outras solicitações. Consultas são executadas com mais rapidez e uma
maior quantidade delas é processada.
Recursos de Armazenamento
Inteligente do Exadata
• Filtragem de predicados:
– Somente as linhas solicitadas, e não todas as linhas de uma

tabela, são retornadas ao servidor de banco de dados.
• Filtragem de colunas:
– Somente as colunas solicitadas, e não todas as colunas de
uma tabela, são retornadas ao servidor de banco de dados.
– Exemplo:
able
fe r
SQL> SELECT name FROM employees WHERE LENGTH(name) > 5;
a n s
Com a filtragem de predicados e colunas, somente
t r
os- nomes
n
—
o
n enviados aos
de funcionários com mais de cinco caracteresasão
servidores de banco de dados.
) h as ฺ
ฺbr inteira e ser enviada
iddeve
Sem a filtragem, a tabela employees
—
m u
G de dados.
do armazenamento para o co ede
o ฺservidor n t banco
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Te funçõeslicde banco de dados estão integradas ao Exadata Storage Server:
As seguintes
o
e c n• icO Exadata Storage Server permite a filtragem de predicados para varreduras de
T tabelas. Em vez de retornar todas as linhas para avaliação do banco de dados, o
Exadata Storage Server retorna somente as linhas que atendem à condição do filtro.
Os operadores condicionais suportados incluem =, !=, <, >, <=, >=, IS [NOT] NULL,
LIKE, [NOT] BETWEEN, [NOT] IN, EXISTS, IS OF type, NOT, AND, OR. Além disso,
várias funções SQL comuns podem ser avaliadas pelo Exadata Storage Server durante
a filtragem de predicados. Para obter uma lista completa das funções que podem ser
avaliadas pela célula do Exadata, use a consulta a seguir:
SELECT * FROM v$sqlfn_metadata WHERE offloadable = 'YES';
• O Exadata Storage Server permite a filtragem de colunas, também denominada
projeção de colunas, para varreduras de tabelas. Somente as colunas solicitadas são
retornadas ao servidor de banco de dados em vez de todas as colunas de uma tabela.
No caso de tabelas com muitas colunas ou colunas que contêm LOBs, a largura de
banda de Entradas/saídas salva pela filtragem de colunas pode ser muito grande.
Quando usadas juntas, a combinação da filtragem de predicados e da filtragem de colunas
aperfeiçoa, de forma considerável, o desempenho e reduz o consumo de largura de banda
de Entradas/saídas.

• Processamento de join:
– O processamento de joins em estrela é executado no

Exadata Storage Server
• Varreduras em dados criptografados
• Varreduras em dados compactados
• Scoring para Data Mining:
le
– Exemplo:
fe rab
tra ns
SELECT cust_id
n -
FROM customers
a no
WHERE region = 'US'
h s
ausing
r )
AND prediction_probability(churnmod,'Y' deฺ *) > 0.8;ฺb Gui
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 Server executa o processamento de joins para esquemas em
• Oo Te Storage
Exadata
nicestrela (entre tabelas grandes e tabelas de lookup pequenas). Isso é implementado
Tec usando Filtros "Bloom", que é um método probabilístico muito eficiente para determinar
se um elemento é membro de um conjunto.
• O Exadata Storage Server executa Smart Scans em tablespaces e em colunas
criptografados. No caso de tablespaces criptografados, o Exadata Storage Server pode
descriptografar blocos e retornar os blocos descriptografados ao Oracle Database, ou
pode executar a filtragem de linhas e de colunas em dados criptografados. É possível
fazer uma economia significativa de CPU no servidor de banco de dados
descarregando a tarefa de descriptografia, que exige muito da CPU, em células do
Exadata.
• O Smart Scan funciona em conjunto com a compressão EHCC (Exadata Hybrid
Columnar Compression), de forma que a projeção de colunas e a filtragem de linhas
podem ser executadas juntamente com a descompactação no nível do armazenamento,
com o fim de economizar ciclos da CPU nos servidores de banco de dados.
• O Exadata Storage Server pode executar funções de scoring, como
PREDICTION_PROBABILITY, para modelos de data mining. Esse procedimento
acelera a análise do data warehouse, ao mesmo tempo em que reduz o consumo de
CPU do servidor de banco de dados e a carga de entrada/saída entre esse servidor e
os servidores de armazenamento.
• Criar/estender tablespace:
– O Exadata formata blocos do banco de dados.

• Backup e recuperação:
– A Entrada/saída de backups incrementais é muito mais
eficiente porque somente os blocos alterados são retornados
ao servidor de banco de dados.
– O Exadata executa a restauração de arquivos do RMAN. 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
• Como Teo armazenamento do Exadata , a operação de criação/extensão de tablespaces
i c
n é executada com mais eficiência. Em vez de formatar blocos vazios na memória do
Tec servidor de banco de dados e gravá-los no armazenamento, um único comando iDB
é enviado ao Exadata Storage Server instruindo-o a formatar os blocos. O uso da
memória do servidor de banco de dados é reduzido, e a atividade de entrada/saída
associada à criação e à formatação dos blocos do banco de dados é eliminada com o
armazenamento do Exadata.
• Com o Exadata Storage Server, a velocidade e a eficiência dos backups incrementais
de banco de dados aumentam. Com o armazenamento do Exadata, as alterações são
controladas no nível de blocos individuais do Oracle, em vez de para um grupo grande
de blocos. Isso resulta em mais rapidez e menos largura de banda de Entrada/saída
consumida nos backups.
• Com o armazenamento do Exadata, a operação de restauração de arquivos do
RMAN é descarregada nas células. Esse procedimento é essencialmente o mesmo
que a otimização associada à criação ou à extensão de um tablespace (descrita
anteriormente).

Exemplo de Dimensionamento do
Smart Scan do Exadata
Servidor de dbs1
Banco de Dados
Rede de Armazenamento
InfiniBand
Máximo de 40 Gb/s
le
Célula do
fe rab
Exadata edsc1 edsc2
… edsc13 edsc14
tra ns
n -
noa
Cada célula pode
transmitir 1,8 GB/s. a
h eฺ s
r
ฺ Guid
b )
m
ฺco dent
Total de 14 células
Discos
o
que podem transmitir
k
(12/célula)
ei = 25,2SGB/s
14 x 1,8
t tu
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
ic a seguir ilustra o poder do Smart Scan de forma quantificável,
Tenos três lslides
O exemplo
o
ic um caso típico no qual várias células do Exadata são dimensionadas para
ecn
usando
T compartilhar uma carga de trabalho.
O servidor de banco de dados, ilustrado na parte superior do slide, está conectado com a
rede de armazenamento InfiniBand, que pode transmitir, no máximo, 40 gigabits por segundo
(Gb/s). Para manter o exemplo claro e simples, suponhamos que a rede InfiniBand possa
transmitir dados a 40 Gb/s sem overhead de mensagens. Também suponhamos que um
único servidor de banco de dados tenha acesso à largura de banda de Entrada/saída integral
de todas as células do Exadata.
Nesse cenário, há 14 células do Exadata, da mesma maneira que em um Database Machine
Full Rack. Supondo que cada célula do Exadata possa fornecer 1,8 gigabytes (GB) de
throughput de entrada/saída de disco por segundo, a capacidade de varredura potencial
de todas as células do Exadata é de 25,2 GB por segundo.

n
rt Sca
ma select /*+ full(lineitem) */ count(*)
mS
Se
from lineitem
where l_orderkey < 0;
Servidor de O banco de dados solicita a recuperação de todos

dbs1 os blocos fazendo uma varredura integral da tabela
Banco de Dados
e, em seguida, filtra as linhas correspondentes.
Se a tabela estiver distribuída de maneira uniforme entre

Se a tabela tiver 4.800 GB de todos os discos, cada célula não poderá enviar mais do que
tamanho, a varredura integral 40/14 = 2,85 Gb/s = 0,357 GB/s para a instância do banco
levará cerca de 16 minutos. de dados.
le
Célula do
… fe rab
Exadata edsc1 edsc2 edsc13 edsc14
tr a ns
n -
0,357 GB/s
Os discos são otimizados a no
pela largura de banda a
h eฺ s
da rede! r
ฺ Guid
b )
m
Discos
k o ฺco dent
(12/célula)
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c uma tabela de 4.800 gigabytes esteja distribuída uniformemente
Te
Agora,osuponhamos lique
e c nic14 células do Exadata, e é executada uma consulta que requer uma varredura integral
pelas
T da tabela. Como normalmente ocorre, suponhamos que a consulta retorne um pequeno
grupo de resultados.
Sem os recursos de Smart Scan, cada Exadata Storage Server se comporta como um
servidor de armazenamento tradicional, transferindo os blocos do banco de dados para
o banco de dados cliente.
Como a rede de armazenamento apresenta uma largura de banda limitada a 40 gigabits por
segundo, as células do Exadata não conseguem usar toda a sua potência. Nesse caso, cada
célula não pode transmitir mais do que 0,357 gigabytes por segundo ao banco de dados e
levaria cerca de 16 minutos para varrer toda a tabela.

Scan
art
Sm select /*+ full(lineitem) */ count(*)
mo
from lineitem
Co where l_orderkey < 0;
Servidor de dbs1 O banco de dados solicita que as células do Exadata

Banco de Dados enviem todas as linhas correspondentes.
Se a tabela tiver 4.800 GB de tamanho, a Se a tabela estiver distribuída de maneira uniforme entre
varredura integral da tabela será todos os discos, cada célula não poderá enviar mais do
concluída em cerca de três minutos e dez que 40/14 = 2,85 Gb/s = 0,357 GB/s para a instância do
segundos! banco de dados.
le
Célula do
… fe rab
Exadata edsc1 edsc2 edsc13 edsc14
tr a ns
Cada célula pode varrer n -
1,8 GB/s
a uma velocidade de
a no
1,8 GB/s, e enviar suas
linhas correspondentes à a
h eฺ s
r
ฺ Guid
instância de banco de
b )
m
dados. Isso representa
Discos
k o ฺco dent
uma varredura total a
uma velocidade
(12/célula)
t ei Stu de 25,2 GB/s!
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Te quelico Smart Scan seja aplicado à mesma consulta. O mesmo limite de
Agora,oconsidere
e c nic de banda da rede de armazenamento se aplica. No entanto, dessa vez, os 4.800 GB

largura
T não são transmitidos pela rede de armazenamento; somente as linhas correspondentes são
transmitidas de volta ao servidor de banco de dados. Assim, cada célula do Exadata pode
processar sua parte da tabela com a velocidade máxima, ou seja, aproximadamente 1,8 GB
por segundo. Nesse caso, a varredura total da tabela seria concluída em cerca de três
minutos e dez segundos.

Visão Geral da Compressão EHCC (Exadata
Hybrid Columnar Compression)
Compactação de Data Compactação de Arquivo

Warehouse
Otimizado para Velocidade Otimizado para Espaço
• Economia média de 10x de • Economia média de 15x de
armazenamento armazenamento
• Redução de 10x de entrada/saída – Até 50x em alguns dados
• Otimizado para desempenho de • Maior overhead de acesso
r a ble
consultas • Para dados sem interesse ou fe
históricos ans- tr
no n
Tamanho Reduzido de a Discos
Recuperar
Data Warehouse a s
Melhor Desempenho ) h Dados
Manter eฺ On-line
ฺbr Guid
o ntm
É possível combinar tipos k o
deฺccompactação
de por partição
t e i t u
para ILM (Information
e S
@ his Lifecycle Management)
r t
o se t
u p
Copyright © 2012,
e
t
o ( ense
e i k liccompactação básica e OLTP do Oracle Database 11g, o Exadata
Além dos
o Trecursos de
e c nic Server inclui a compressão EHCC (Exadata Hybrid Columnar Compression).

Storage
T É possível especificar a compressão EHCC no nível de tabela, partição e tablespace.
Você também pode escolher entre dois tipos de compressão EHCC para obter o equilíbrio
adequado entre o uso do disco e o consumo de CPU, dependendo dos seus requisitos:
• A compactação de data warehouse é otimizada para melhorar o desempenho das
consultas e destina-se a aplicações de data warehouse.
• A compactação de arquivos on-line é otimizada para maximizar as relações de
compactação e destina-se a dados raramente alterados.
Você pode usar a compressão EHCC em tabelas completas ou em conjunto com
compactação básica e OLTP, utilizando particionamento.
Observação: um Compression Advisor, fornecido pelo pacote DBMS_COMPRESSION, ajuda
a determinar a relação de compactação esperada de determinado método de compactação
e para uma tabela específica.

Organização de Dados da Compressão EHCC
(Exadata Hybrid Columnar Compression)
Unidade de Compactação
Cabeçalho do Bloco Cabeçalho do Bloco Cabeçalho do Bloco Cabeçalho do Bloco

Cabeçalho da CU
C2 C5 C7 C8
C1 C4
C3
C2 C5 C6
le
• Uma unidade de compactação é uma estrutura lógica que fe rab
abrange vários blocos do banco de dados a n s
n -t r
• o
Cada linha fica contida em uma unidade de compactação
n
a
• Os dados são organizados por coluna) h as ฺ a sua carga
durante
• ฺbr Guide
Cada coluna é compactada separadamente
m
o ฺ co ent
• O Smart Scan é suportado
tei k tud
r t e @ his S
u p o se t
Copyright © 2012,
e
t
o ( ense
i k ic (Exadata Hybrid Columnar Compression), os dados são
Te
Com a compressão
o lEHCC
e c nic de compactação,
organizados
unidade
em conjuntos de linhas denominados unidades de compactação. Dentro de uma
os dados são organizados por colunas e, em seguida, compactados.
T A organização dos dados em colunas aproxima os valores similares, melhorando as
relações de compactação. Cada linha fica contida em uma unidade de compactação.
O tamanho de uma unidade de compactação é determinado automaticamente pelo Oracle
Database com base em vários fatores, a fim de produzir o resultado mais eficaz e manter,
ao mesmo tempo, um excelente desempenho das consultas. Embora o diagrama do slide
mostre uma unidade de compactação que contém quatro blocos de dados, isso não significa
que uma unidade de compactação sempre contenha quatro blocos.
Além de fornecer uma excelente compactação, a compressão EHCC (Exadata Hybrid
Columnar Compression) funciona juntamente com o Smart Scan, de forma que a projeção de
colunas e a filtragem de linhas podem ser executadas juntamente com a descompactação no
nível do armazenamento, com o fim de economizar ciclos da CPU nos servidores de banco de
dados.
Embora ajude na compactação, a organização em colunas não é adequada para operações
DML porque uma alteração aparentemente insignificante em uma linha poderá forçar a
reorganização de uma unidade de compactação inteira. Devido ao alto custo envolvido na
reorganização de dados organizados em colunas, essas operações são evitadas pela
compressão EHCC (Exadata Hybrid Columnar Compression). Em vez disso, as deleções são
essencialmente lógicas, enquanto as atualizações e as inserções de caminho convencional
resultam na inserção de novas linhas em unidades de compactação de bloco único. Portanto,
a compressão EHCC oferece excelentes relações de compactação para dados carregados de
caminho de direto e é recomendada no caso de dados que não são atualizados com
frequência.
Visão Geral do Exadata Smart Flash Cache
• Cache de alto desempenho para objetos acessados com

frequência
• Excelente para absorção de leituras aleatórias repetidas
• Permite a otimização por tabela de aplicação
Centenas de Dezenas de Milhares
de Entradas/saídas por
Entradas/saídas por Segundo
Segundo 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 c de restrição do desempenho do armazenamento foi o número de
Por muitos
o Teanos, umlifator
e c nic
Entradas/saídas aleatórias por segundo (IOPS) que um disco pode produzir. Para compensar
T o fato de que até mesmo um disco de alto desempenho pode produzir somente algumas
centenas de IOPS, arrays de armazenamento de grande porte eram necessários para
produzir 100.000 IOPS.
O Exadata Storage Server fornece o Exadata Smart Flash Cache, um mecanismo de
armazenamento em cache para dados acessados com frequência, que é útil para absorver
leituras aleatórias repetidas, bem como para OLTP. Com o Smart Flash Cache, uma única
célula do Exadata pode oferecer suporte a 100.000 IOPS, duas células podem oferecer
suporte a 200.000 IOPS etc.
O Smart Flash Cache concentra-se em armazenar no cache dados acessados com
frequência e blocos de índice, juntamente com informações críticas de desempenho,
como arquivos de controle e cabeçalhos de arquivos. Além disso, os DBAs podem alterar
as prioridades de armazenamento no cache utilizando o atributo de armazenamento
CELL_FLASH_CACHE para objetos de banco de dados específicos.

Armazenamento em Cache Inteligente do
Exadata Smart Flash Cache
O Exadata Smart Flash Cache reconhece diferentes tipos de entrada/saída
de banco de dados:
• Dados acessados com frequência e blocos de índice são armazenados
no cache.
• Leituras e gravações de arquivos de controle são
armazenados no cache.
• Leituras e gravações de cabeçalhos de arquivos
são armazenados no cache.
• O DBA pode alterar as prioridades de armazenamento no cache. le
fe rab
• Entradas/saídas para espelhar cópias não são
tra ns
armazenadas no cache. n -
• Entradas/saídas relacionadas a backup não são a no
armazenadas no cache.
) h as ฺ
• ฺbr Guideno cache.
Entradas/saídas do Data Pump não são armazenadas
m
• o é armazenada
A formatação de arquivos de dadosฺcnão n t no cache.
i k o d e
• te tu o cache.
Varreduras de tabelas não monopolizam
@ his S
r t
o se te
u p
Copyright © 2012,
e
t
o ( ense
i k ic caros e de grande porte introduziram caches de memória não
Te
Mais recentemente,
o larrays
e c nic e igualmente caros para melhorar o desempenho. Entretanto, como esses caches
voláteis
T desconhecem as aplicações que os utilizam, sua eficiência é limitada.
Com o armazenamento do Exadata, cada entrada/saída do banco de dados é marcada
com metadados que indicam o seu tipo. O Exadata Smart Flash Cache usa essa informação
para tomar decisões inteligentes sobre como usar o cache. Essa cooperação garante o uso
eficiente do Exadata Smart Flash Cache.
Por exemplo, com o espelhamento ASM ativado, várias cópias de cada bloco de dados
devem ser gravadas no disco, para proporcionar o nível desejado de proteção de dados. No
entanto, normalmente, não há necessidade de armazenar no cache a cópia secundária de
um bloco porque o ASM lerá a cópia principal, se ela estiver disponível. No uso de um array
de armazenamento tradicional, não se teria conhecimento dessa característica, o que levaria
à ineficiência do armazenamento no cache.
De forma semelhante, com arrays tradicionais de armazenamento, os backups e as
exportações geralmente fazem com que todos os dados sejam carregados no cache
embora a operação não os leia repetidamente. O Exadata Storage Server sabe que não
há necessidade de encher o cache com dados de backup e de exportação. O mesmo ocorre
em operações de formatação de arquivos de dados. Finalmente, o Exadata Storage Server
não sobrecarrega o cache com dados de varreduras integrais de tabela, como ocorre com a
maioria dos outros arrays de armazenamento.

Usando o Exadata Smart Flash Cache
Operação de Gravação Operação de Leitura Operação de Leitura

em dados previamente em dados não
armazenados no cache armazenados no cache
DB 1 DB 1 DB
Solicitação de Leitura
Solicitação de Leitura
3 1 3 3
Confirmação
le
cellsrv
cellsrv
cellsrv
fe rab
a ns
2 2 n2-tr4
4
a no
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
Exadata Smart
t ei Stu
te@ this
Flash Cache
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
TeSmart Flash
O Exadata
o lic Cache é um mecanismo de armazenamento no cache para dados
ic com frequência em cada célula do Exadata. Ele opera em conjunto com o Oracle
ecn
acessados
T Database automaticamente para otimizar, de forma inteligente, a eficiência do cache.
Cada Entrada/saída do banco de dados é marcada com os seguintes metadados:
• A definição CELL_FLASH_CACHE do objeto associado à Entrada/saída:
- O DEFAULT especifica que o Smart Flash Cache seja usado normalmente.
- O KEEP especifica que o Smart Flash Cache seja usado de forma mais agressiva.
- NONE determina que o Smart Flash Cache não seja usado.
• Uma dica do cache, que é designada pelo banco de dados com base no motivo da
Entrada/saída:
- CACHE indica que a Entrada/saída deve ser armazenada no cache. Por exemplo,
a Entrada/saída se destinada a um lookup de índice.
- NOCACHE indica que a Entrada/saída não deve ser armazenada no cache. Por
exemplo, a Entrada/saída se destina a um bloco espelhado de dados ou é uma
gravação em log.
- EVICT indica que os dados devem ser removidos do cache. Por exemplo, quando
uma operação de rebalanceamento do ASM move dados entre discos diferentes,
as cópias no cache correspondentes ao local original são movidas do cache.

Além disso, o Smart Flash Cache leva em consideração os seguintes itens ao processar a
Entrada/saída:
• Tamanho da Entrada/saída: Entradas/saídas grandes em objetos com
CELL_FLASH_CACHE definido como DEFAULT não são armazenadas no cache.
• Carga do cache atual: em geral, varreduras de tabela inteligentes são direcionadas
ao disco. No entanto, se o objeto tiver uma definição de CELL_FLASH_CACHE de KEEP,
algumas leituras podem ser atendidas usando o Smart Flash Cache a fim de melhor
utilizar o throughput combinado dos discos e do cache.

O Smart Flash Cache usa todas as informações mencionadas anteriormente para tomar
decisões inteligentes sobre quais dados são ou não adequados para o armazenamento
no cache.
Para operações de gravação, CELLSRV grava dados no disco e envia uma confirmação ao
banco de dados para que ele continue sem interrupções. Em seguida, se os dados não forem
adequados para o armazenamento no cache, eles serão gravados no Smart Flash Cache. O le
desempenho da gravação não é aperfeiçoado nem diminuído com esse método. No entanto,
fe rab
tra ns
se uma operação de leitura subsequente precisar dos mesmos dados, é provável que ela se
beneficie do cache. n -
no a
Para operações de leitura, o CELLSRV primeiro deve determinar se os dados solicitados já
a s
h eฺ
estão no Smart Flash Cache. O CELLSRV mantém uma tabela de hash na memória, que é
r
ฺ Guid
b )
usada para determinar, com rapidez, quais blocos de dados estão contidos no Smart Flash
m
usado para atender à solicitação de Entrada/saída.k o ฺco dent
Cache. Se os dados solicitados estiverem armazenados no cache, um lookup do cache será
t e i tu com o Smart Flash Cache,

Para operações de leitura que não podem @ sers S
atendidas
uma leitura de disco é executada,o r e t hi
tee as informações solicitadas são enviadas ao banco
u p
s os dados s
uforem adequados para o armazenamento no cache,
ecฺ Flash
de dados. Em seguida, se
serão gravados no(tSmart t o
i k o e n se Cache.
Quando ose
T l ic
dados adequados são inseridos em um cache cheio, um algoritmo LRU (menos
usado o
ic recentemente) priorizado determina quais dados serão substituídos. Objetos com o
c n definido como KEEP estão sujeitos a uma política de retenção no
Te
CELL_FLASH_CACHE
cache diferente dos objetos com o CELL_FLASH_CACHE definido como DEFAULT. Objetos
KEEP têm prioridade sobre objetos DEFAULT, de forma que novos dados de um objeto
DEFAULT não extrairão dados no cache de nenhum objeto KEEP. Para evitar que objetos
KEEP monopolizem o cache, é permitido que eles ocupem, no máximo, 80% do tamanho total
do cache. Além disso, para evitar que objetos KEEP não usados ocupem indefinidamente o
cache, eles são submetidos a uma política de classificação por vencimento adicional, que
expurga periodicamente dados de objetos KEEP não usados.

Visão Geral do Exadata Smart Flash Log
• O Exadata Smart Flash Log fornece um armazenamento

temporário confiável de baixa latência e alto desempenho

para gravações de redo log:
– As gravações do log são direcionadas para o disco e para o
Exadata Smart Flash Log
– O processamento continua após uma confirmação mais rápida
– Conceitualmente semelhante aos redo logs multiplexados
– O Exadata Storage Server gerencia automaticamente o Smart rab
le
Flash Log e garante que todas as entradas do log sejam nsfe
a
mantidas no disco n-tr no
a
Registro de
) h as Confirmação
Continua Após
ฺ
Redo Log ฺ b r i d e Mais
om nt G u Rápida
ฺ 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 Log fornece um mecanismo para melhorar a latência das operações
TeSmart Flash
O Exadata
o
ic
ecn
de gravação de redo log do banco de dados. O Exadata Smart Flash Log usa uma pequena
T parte da memória flash de alto de desempenho do Exadata Storage Server como um
armazenamento temporário a fim de permitir gravações de redo log de baixa latência.
Com o Exadata Smart Flash Log, os registros de log são gravados simultaneamente nos
arquivos de redo log on-line baseados em disco e no Exadata Smart Flash Log. O software
do Oracle Exadata Storage Server espera pela operação de gravação mais rápida, seja
no disco rígido ou no Exadata Smart Flash Log. Quando os discos rígidos que contêm os
arquivos de redo log on-line têm problemas de desempenho temporários, como cargas
intensas de entrada/saída, as operações de gravação no Exadata Smart Flash Log
normalmente serão concluídas com mais rapidez e apresentarão um bom tempo de
resposta de maneira consistente.
O Exadata Smart Flash Log é conceitualmente semelhante aos arquivos de redo log on-line
multiplexados, disponíveis no Oracle Database por muitos anos. A principal diferença é que
o Exadata Smart Flash Log usa somente a memória flash para armazenamento temporário
de dados de redo log. Por default, o Exadata Smart Flash Log usa 32 MB em cada disco de
célula baseado em flash, para um total de 512 MB em cada Exadata Storage Server.

Visão Geral do Exadata Storage Index
Storage Index na Memória Somente o primeiro bloco pode corresponder

Índice de Região
SELECT * FROM T1 WHERE B<2;
B:1/5 B:3/8
E:a/j
G:4/9
… …
1 AU do ASM
… 1MB
Região de
Armazenamento
1 Disco ASM
DBA
le
fe rab
Tabela T1 Tabela T1 ns
Tabela
traT2
o n -
A B C D A B C D a n
… 1 … … … 5 … … ) ha
s E F G
ฺ
Mín B = 1
… 3 … … … 8 … m …ฺbrMínGBui=d3e a … 4
Máx B = 5
k o ฺco denMáx t B=8 d … 7
… 5 … …
t e…i 3 … t u …
e @ i s S j … 9
r t
o se t h
u p
Copyright © 2012,
e
t
o ( ense
e i k lic é uma estrutura baseada na memória que reduz o volume de
Um índiceTde armazenamento
o
e c nic
entrada/saída física em uma célula do Exadata. O índice de armazenamento acompanha os valores de
coluna mínimos e máximos, e essas informações são usadas para evitar Entradas/saídas inúteis.
T Por exemplo, o slide mostra a tabela T1 que contém a coluna B. A coluna B é rastreada no índice de
armazenamento. Dessa forma, sabe-se que a primeira metade da tabela T1 contém valores para a
coluna B no intervalo de 1 a 5. De forma semelhante, sabe-se que a segunda metade da tabela T1
contém valores para a coluna B no intervalo de 3 a 8. Qualquer consulta na tabela T1 à procura de
valores de B inferiores a 2 pode ser feita com rapidez, sem nenhuma atividade de entrada/saída na
segunda parte da tabela.
Levando-se em conta uma combinação favorável de distribuição de dados e predicados de consulta,
um índice de armazenamento pode ser usado para acelerar de forma drástica uma consulta, ignorando
rapidamente um grande número de entradas/saídas. Para outra consulta, o índice de armazenamento
pode oferecer pouca ou nenhuma vantagem. Em qualquer caso, a facilidade de manutenção e de
consulta do índice de armazenamento baseado em memória significa que qualquer Entrada/saída
salva por meio do seu uso aumenta efetivamente a largura de banda geral de Entrada/saída da célula,
consumindo muito poucos recursos da célula.
O espaço de armazenamento dentro de cada disco de célula é logicamente dividido em partes de 1 MB
denominadas regiões de armazenamento. Os limites das unidades de alocação (AUs) do ASM são
alinhados com os limites das regiões de armazenamento. Para cada uma dessas regiões, as
estatísticas de distribuição de dados são mantidas em uma estrutura de memória denominada índice
de região. Cada índice de região contém informações de distribuição de até 8 colunas. O índice de
armazenamento é um conjunto de índices de região.

As estatísticas de armazenamento mantidas em cada índice de região representam a
distribuição de dados (valores mínimos e máximos) de colunas que são consideradas
bem clusterizadas. O Exadata Storage Server contém a lógica que determina, de forma
transparente, quais colunas são clusterizadas o suficiente para serem incluídas no índice de
região. Diversas partes da mesma tabela podem ter conjuntos diferentes de colunas em seus
índices de região correspondentes.
O índice de armazenamento funciona melhor nas condições a seguir:
• Os dados estão ordenados de forma que os mesmos valores de coluna estejam

clusterizados juntos.
• A consulta tem um predicado em uma coluna de índice de armazenamento que procura
=, <, > ou alguma combinação deles.
É importante observar que o índice de armazenamento funciona de forma transparente
sem intervenção do usuário. Não há necessidade de criar, eliminar nem ajustar o índice
de armazenamento. A única forma de alterá-lo é carregar suas tabelas usando dados le
pré-classificados.
fe rab
Além disso, como o índice de armazenamento é mantido na memória, ele desaparece
tr a ns
n -
quando a célula é reinicializada. As primeiras consultas executadas após a reinicialização
ano
da célula fazem com que o índice de armazenamento seja recriado automaticamente.
a s
h codificação
O índice de armazenamento funciona com tipos de dados )
r cuja
d e ฺ binária permita
b
que a comparação lexical binária no nível de bytes de ฺdois valores
m i
u do tipo de dados em
questão seja suficiente para determinar a ordenação ฺ o
c en dessest Gdois valores. Isso inclui tipos
de dados como NUMBER, DATE e VARCHAR2. k o ud os tipos NLS são um exemplo de
i No entanto,
tipos não incluídos para filtragem de@
t e S t
o r te índicethdeisarmazenamento.
ฺ s up use
( t ec se to
e i ko licen
i c oT
e c n
T

Exemplo de Índice de
Armazenamento com Partições
ORDER# ORDER_DATE SHIP_DATE ITEM
(Chave da Partição)
1 2007 2007
2 2008 2008
3 2009 2009
• Consultas em SHIP_DATE não se beneficiam do le

particionamento de ORDER_DATE: fe rab
ns
– No entanto, SHIP_DATE está altamente correlacionado a-tra
ORDER_DATE non a
• as ฺ das
O índice de armazenamento melhora o desempenho
) h
consultas em SHIP_DATE: ฺbr uide m G
ฺco particionamento
– Aproveita a ordenação criadaopelo ent
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic colunas correlacionadas. ORDER_DATE é altamente
O exemplo
o Teno slide lcontém
e c nic
correlacionado com SHIP_DATE. As datas são geralmente correlacionadas porque,
T em geral, uma data de envio é próxima a uma data de pedido.
Se a sua tabela for particionada por ORDER_DATE, e você executar uma consulta usando
ORDER_DATE como filtro, a remoção de partições será usada para que somente as partições
relevantes sejam lidas. No entanto, se você fizer uma consulta usando apenas SHIP_DATE
na cláusula WHERE, a remoção da partições não poderá ser usada para otimizar a consulta.
No entanto, se SHIP_DATE fizer parte do índice de armazenamento, esse índice será usado
para ignorar todos os blocos que não correspondam à sua consulta. Essa filtragem ocorre
no nível de armazenamento. O índice de armazenamento ajuda a consulta SHIP_DATE a
aproveitar a ordenação natural decorrente do particionamento de ORDER_DATE e a
correlação natural existente entre as colunas ORDER_DATE e SHIP_DATE.

Database File System
• O DBFS (Database File System) permite que o banco de dados

seja usado como um sistema de arquivos.

• Os arquivos são armazenados como LOBs SecureFiles nas
tabelas de banco de dados:
– Protegidos como qualquer dado Oracle – espelhamento ASM, Data
Guard, Flashback etc.
– Armazenamento compartilhado para preparação ETL, scripts,
relatórios e outros arquivos de aplicações
r a ble
s
– Throughput de entrada/saída do sistema de arquivos de 5 a 7nGB/s fe
em um Database Machine Full Rack
n - tra
no
Transformar e carregar
a
Copiar arquivos sde
nas tabelas
hadados
no DBFS bancor)de deฺ ฺb Gui
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 (Database lic File System) permite que um banco de dados Oracle seja usado
O Oracle
o TDBFS
ic um sistema de arquivos compatível com POSIX. O DBFS é um recurso do Oracle
ecn
como
T Database que fornece aos usuários do Database Machine uma área de teste de alto de
desempenho para processamento ETL e carga de dados em massa.
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,
criar etc. O utilitário dbfs_client permite a montagem de um sistema de arquivos DBFS
como um ponto de montagem no sistema operacional. Ele fornece o mapeamento das
operações de sistema de arquivos para as operações de banco de dados.
O DBFS é abordado em mais detalhes na lição Carregamento de Dados em Massa Usando o
Oracle DBFS.
Observação: não há suporte para o ACFS (ASM Cluster File System) no Exadata
Storage Server.

Visão Geral do I/O Resource Management
Solicitações
de Servidor de Fila de Discos FIFO

Entrada/Saída
Armazenamento
RDBMS H L H L L L
Tradicional
Não é possível Solicitação de Solicitação de

alterar o scheduler carga de trabalho carga de trabalho
de Entradas/saídas. de alta prioridade de baixa prioridade
le
fe rab
tr a ns
Exadata Storage Server n -
no
Scheduler de Entradas/Saídas
baseado no esquema
Solicitações s a
de priorização
de
) a
h eฺ
Entrada/Saída H H r
ฺ Guid
b
RDBMS m
co ent L H H H
L L LikLoฺ
t e Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic compartilhado tradicional, o balanceamento do trabalho de vários
Te
Com ooarmazenamento
e c nic de dados que compartilham o subsistema de armazenamento é essencialmente

bancos
T difícil. Esse problema é ilustrado pela figura na parte superior do slide, que mostra como
os servidores de armazenamento tradicionais processam as solicitações de Entrada/saída.
Basicamente, eles colocam na fila solicitações de Entrada/saída em uma ordem FIFO
(First-in, First-out), que não diferencia solicitações de alta e baixa prioridades.
O Exadata Storage Server permite a alocação de recursos de entrada/saída com base nas
prioridades e nas políticas especificadas pelo usuário. Isso é ilustrado na figura mostrada
na parte inferior do slide, em que o scheduler de entrada/saída do Exadata Storage Server
executa solicitações de entrada/saída com base em um esquema de priorização. Isso é feito
colocando internamente solicitações de Entrada/saída na fila, para evitar que uma carga de
trabalho de baixa prioridade, mas intensa, transborde os discos.
O gerenciamento de recursos de entrada/saída é abordado em mais detalhes na lição I/O
Resource Management.

Multiplicação de Benefícios
Em geral, vários terabytes de Menos com a Ainda menos com a

dados do usuário requerem compressão HCC (Hybrid remoção de partições
vários terabytes de Column Compression) do
Entradas/saídas Exadata
le
Resultados
fe rab
em tempo real ns
no Database
n - tra
o
O índice de Smart Scan significa que an
Machine
armazenamento ignora somente os resultados
) h as ฺ
Entradas/saídas inúteis são retornados ao banco
de dados m ฺbr Guide
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k ic mostra como os recursos apresentados nesta lição podem operar em
lque
Este éoumTexemplo
e c nic para multiplicar as vantagens do Exadata Database Machine.
conjunto
T Suponhamos que você tenha uma tabela com vários terabytes e alguém execute uma
consulta voltada para um pequeno subconjunto dos dados, mas causa uma varredura
completa da tabela. Tradicionalmente, o sistema teria que varrer os terabytes de dados.
No entanto, usando a compressão EHCC (Exadata Hybrid Columnar Compression), seria
possível reduzir o tamanho da tabela.
Se uma tabela for particionada, o otimizador de banco de dados poderá usar a remoção de
partições para eliminar uma parte substancial dos dados.
Usando índices de armazenamento, o Exadata Storage Server pode reduzir ainda mais o
volume de entradas/saídas físicas necessárias.
Finalmente, devido ao Smart Scan, os únicos dados retornados ao banco de dados serão os
de interesse da consulta, alguns dos quais poderão ter sido armazenados no cache, dentro
do Smart Flash Cache.
Este exemplo mostra como vários recursos podem operar em conjunto para melhorar o
desempenho de uma única operação utilizando o Exadata Database Machine.

Questionário
Quais dos seguintes recursos do Exadata Database Machine

também estão disponíveis em outras plataformas?

a. Smart Scan
b. Compressão HCC (Hybrid Columnar Compression)
c. Smart Flash Cache
d. Storage Index
a b le
e. Sistema de Arquivos de Banco de Dados fe r
n s
f. I/O Resource Management
n - tra
g. Todas as opções acima a no
h. Nenhuma das opções acima ) h as ฺ
r 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
e e lic
Resposta:
o Tb,
An
c ic
partir do Oracle Database release 11.2.0.3, a compressão HCC (Hybrid Columnar
T e Compression) é suportada no Pillar Axiom e no Sun ZFS Storage Appliance.
Observe que, embora os algoritmos da Hybrid Columnar Compression sejam os mesmos,
a compressão EHCC (Exadata Hybrid Columnar Compression) ainda é muito diferente. A
capacidade de descarregar o processamento no Exadata Storage Server indica que a EHCC
oferece uma opção viável para uso da compactação em dados dinâmicos de OLTP e de data
warehouse. O Pillar Axiom e o Sun ZFS Storage Appliance não são capazes de reduzir a
carga de processamento como o Exadata Storage Server. Por esse motivo, a compressão
HCC (Hybrid Columnar Compression) no Pillar Axiom e no Sun ZFS Storage Appliance é
mais adequada para as aplicações de arquivamento de dados.

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

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
– Introdução ao Smart Scan

– Introdução à Compressão EHCC (Exadata Hybrid Columnar
Compression)
– Introdução ao Exadata Smart Flash Cache
– Examinando o Exadata Smart Flash Cache
– Arquitetura do Exadata Smart Flash Cache
r a ble
– Exemplo de Dimensionamento do Smart Scan n s fe
a
– Storage Index n-tr no
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
• Outras Demonstrações
– Introdução ao Smart Scan

– Introdução à Compressão EHCC (Exadata Hybrid Columnar
Compression)
– Introdução ao Exadata Smart Flash Cache
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

Introdução aos Recursos do Exadata
Nestes exercícios, serão apresentados os quatro principais
recursos do Exadata, a saber:

• Smart Scan
• Compressão EHCC (Exadata Hybrid Columnar
Compression)
• Exadata Smart Flash Cache
le
• Storage Index
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

Configuração Inicial 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

• Descrever o processo de instalação e de configuração do

Database Machine.
• Descrever a configuração default do Database Machine.
• Descrever personalizações suportadas e não suportadas
do 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 da Implementação do
Database Machine
Quatro fases:
1. Pré-instalação
– Várias atividades de planejamento e programação, incluindo:
— Planejamento do local: espaço, alimentação, resfriamento,
logística…
— Planejamento da configuração: nomes de hosts, endereços IP,
bancos de dados…
le
— Preparação da rede: DNS, NTP, cabos…
fe rab
– A Oracle e os engenheiros do cliente trabalham juntos
tr a ns
2. Instalação e configuração n -
a
– Instalação e configuração de hardware e dessoftware
no
) a
h emeฺuma
– O resultado é um sistema funcional b r
baseado
ฺ Guid
configuração recomendada m
k o ฺco dentda Oracle
– Deve ser executada pelosi engenheiros
u
te St
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
O processo
o lic
Tede implementação bem-sucedida do Database Machine requer a cooperação e a
i c
ecn
coordenação entre vários representantes e engenheiros da Oracle e do cliente. Em um alto
T nível, o processo envolve quatro fases principais:
1. A pré-instalação envolve várias atividades de planejamento e de programação,
incluindo as listadas no slide. Geralmente, a Oracle orientará o cliente durante esta fase
ajudando-o a preencher as Planilhas de Configuração do Exadata Database Machine.
As informações coletadas nas planilhas de configuração são usadas para criar um
conjunto de arquivos de configuração que orientam a fase de instalação e configuração
(Fase 2).
2. A instalação e a configuração é o processo de instalar um Database Machine intacto no
ambiente do cliente. Envolve várias etapas conduzidas por engenheiros de hardware e
de software. É altamente recomendável que os engenheiros de hardware e software da
Oracle conduzam essa fase para garantir que o Database Machine seja configurado de
uma forma padrão e suportada. O resultado dessa fase é um sistema funcional
configurado de acordo com as planilhas de configuração.

Visão Geral da Implementação do
Database Machine
3. Configuração adicional
– Atividades adicionais para a preparação da produção,

incluindo:
— Reconfigurar o armazenamento usando definições não default
— Criar bancos de dados adicionais
— Configurar o Enterprise Manager
— Configurar o backup e a recuperação
— Conectar o Oracle Exalogic Elastic Cloud
r a ble
– Conduzida pelo cliente ou por contrato de serviços Oraclensf
e
4. Pós-instalação n - tra
a no
– Monitoramento e manutenção regulares
) h as ฺ
– Conduzida pelo cliente ou por contrato
m ฺbr deGserviços
u ide Oracle
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic e a configuração, o Database Machine é configurado na rede do
3. Após
o Tea instalação
niccliente. Dependendo do conteúdo das Planilhas de Configuração, o Database Machine
Tec poderá incluir um ou mais bancos de dados em execução. Nesse ponto, os clientes
podem iniciar o processo de carregamento ou migração de dados e preparação do
Database Machine para operação. No entanto, os clientes poderão desejar variar a
configuração do Database Machine a fim de criar bancos de dados personalizados
ou organizar o armazenamento disponível de forma não default. Essas tarefas de
configuração adicional são, em geral, conduzidas pelo cliente ou pelos serviços
da Oracle contratados para conduzir o trabalho. Outros exemplos de tarefas de
configuração adicionais incluem configurar o Oracle Data Guard, configurar o ambiente
de backup e recuperação ou conectar o Oracle Exalogic Elastic Cloud. As atividades
comuns adicionais suportadas e não suportadas são discutidas mais adiante na lição.
4. Durante a pós-instalação, o foco das atividades muda para o monitoramento e
a manutenção regulares do Database Machine. Em geral, essas atividades são
conduzidas pelo cliente.
O restante desta lição contém tópicos que o ajudarão a entender o processo de
implementação do Database Machine, especialmente a fase de instalação e configuração
(Fase 2). O objetivo não é substituir a documentação disponível, mas sim ajudá-lo a entender
melhor as opções de configuração disponíveis e avaliar melhor os resultados de opções
diferentes com o material apresentado.
Principais Documentos
• Oracle Exadata Database Machine Owner's Guide

– Documento de referência importante que aborda os

seguintes tópicos:
— Planejamento do local
— Planejamento da rede
— Configuração inicial
— Manutenção básica le
• Planilhas de Configuração do Oracle fe rab
Exadata Database Machine tr a ns
n -
– Conjunto de formulários usados para no a
coletar as definições de configuração a
h eฺ s
iniciais ฺbr) m G u id
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 Tede documentação
A biblioteca do Database Machine contém dois documentos principais que
i c
n particularmente importantes durante a configuração inicial do produto:
são
e c
T • Oracle Exadata Database Machine Owner's Guide: este guia se destina aos clientes
do Database Machine e aos responsáveis pelas tarefas de planejamento, configuração
e manutenção do local do centro de dados do Database Machine. Ele é o principal
documento de referencia relacionado à configuração do Database Machine.
• Planilhas de Configuração do Oracle Exadata Database Machine: estas planilhas são
o documento usado para coletar as definições de configuração iniciais do Database
Machine. Ele contém algumas informações de referência, além de links para o Owner's
Guide. A próxima parte desta lição se concentrará nas Planilhas de Configuração.

Preparação do Local do Database Machine
• Use as seguintes seções do Owner's Guide para

direcionar as atividades de preparação do local:

– Chapter 2: Site Requirements for Oracle Exadata Database
Machine
— General Environmental Requirements
— Space Requirements
— Flooring Requirements le
Electrical Power Requirements r a b
—
n s fe
— Temperature and Humidity Requirements
n - tra
— Ventilation and Cooling Requirements
a no
—
as
Network Connection and IP Address Requirements
) h eฺ
– Appendix A: Site Checklists b r
ฺ 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
TeMachinelicOwner's Guide documenta os requisitos do local de cada modelo do
O Database
o
ic Machine. Essas informações devem ser usadas para direcionar as atividades
ecn
Database
T de preparação do local antes da instalação. O guia também contém várias listas úteis de
verificação do local que podem ser usadas para ajudar a garantir a sua preparação.

Visão Geral das Planilhas de Configuração
As Planilhas de Configuração:
• Estão contidas em um documento PDF:
– Fazem parte da biblioteca de documentação do Exadata

Database Machine
– O documento contém campos de form para registrar as
definições
• Contêm definições de configuração específicas do local,
incluindo: le
– Nomes de hosts e de domínios fe rab
– Endereços IP tra ns
o n -
– Informações sobre regiões e fusos horários a n
– h as NTPฺ
Servidores de nomes e servidores de horário
)
r uide
– mฺbdo Exadata
Definições de notificações da célula
o tG
• i k oฺc que
São usadas para gerar arquivos
u d e n
orientam os programas
e t
de configuração @t s S r te thi
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Tea preparação
Assimocomo lic do local, uma das tarefas pré-instalação mais importantes do
e c nic Machine é preencher as Planilhas de Configuração. O preenchimento dessas
Database
T planilhas é, com frequência, um esforço de colaboração que envolve administradores de
banco de dados, de rede e de sistema. Em geral, os engenheiros da Oracle participarão
dessa atividade para prestar assistência. As informações coletadas nas planilhas de
configuração são usadas para configurar o Database Machine. As definições contidas
nas planilhas também determinam aspectos da preparação do loco, como os nomes e os
endereços de rede que precisam ser configurados antes da instalação do Database Machine.
O capítulo 3 do Owner's Guide, Understanding the Network Requirements for Oracle Exadata
Database Machine, deve ser considerado durante o preenchimento dessas planilhas.
A seção a seguir apresenta as Planilhas de Configuração e mostra um conjunto de definições
de exemplo.

Planilha de Configuração Geral
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 de Planilha de Configuração Geral preenchida. Todos os campos
Te um exemplo
O slideomostra
ic que contêm bordas vermelhas precisam ser preenchidos. Ao preencher a
danplanilha
c
e
T planilha, observe os seguintes itens:
• Operating system: selecione Linux ou Solaris como o sistema operacional dos
servidores de banco de dados. Observe que as células do Exadata sempre usam o
sistema operacional Linux.
• Oracle Exadata Database Machine name: o nome do Database Machine é um
identificador usado para gerar nomes de host para todos os servidores e outros
componentes do Database Machine, como switches de rede. Indiretamente, esse valor
também é usado em outros identificadores, como nomes de discos de célula, discos de
grade e grupos de discos. A Oracle recomenda que esse valor tenha quatro caracteres
ou menos, a fim de evitar possíveis problemas com nomes muito longos. Os clientes
que implementam vários Database Machines costumam incorporar um identificador
numérico no nome do Database Machine. Neste exemplo, eidm é uma abreviação de
Example Industries Database Machine. Os clientes devem escolher uma definição que
reflita suas próprias convenções de nomenclatura.
• Type of system: selecione na lista suspensa um valor que reflita o ambiente que está
sendo configurado. A definição deste campo tem um grande impacto no processo de
configuração do Database Machine uma vez que determina o tipo e o número de
servidores de banco de dados, bem como de células do Exadata, configurados.
Observe que um Quarter Rack é selecionado neste exemplo.
• Disk type: selecione na lista suspensa um valor que reflita o tipo de disco das células
do Exadata. O tipo de disco determina a capacidade dos discos e, consequentemente,
a capacidade de todos os discos de célula, discos de grade e grupos de discos
configurados.
• Time zone name: um nome de fuso horário válido é necessário para a instalação
do Oracle Exadata Database Machine. Ele deve ser um fuso horário válido contido
no banco de dados de informações sobre fusos horários (zoneinfo), no formato
Area/Location. Por exemplo, uma entrada válida é America/New_York. Exemplos

de entradas inválidas são EST, EDT e UTC-4. Para obter uma lista de nomes válidos,
consulte o arquivo zone.tab nos arquivos compactados do banco de dados de
informações sobre fusos horários (zoneinfo) disponíveis em ftp://elsie.nci.nih.gov/pub/
• As informações sobre o método de backup são usadas para dimensionar os grupos
de discos ASM criados durante a instalação. Elas são usadas especificamente para
determinar a divisão default do espaço em disco entre os grupos de discos DATA e
le
RECO. Os métodos de backup são os seguintes:
fe rab
- Backups internal to Oracle Exadata Database Machine: esta definição
tra
indica que os backups do banco de dados serão criados somente na FRA
ns
n -
a no
(Fast Recovery Area) localizada no grupo de discos RECO. Esta definição
aloca 40% do espaço disponível para o grupo de discos DATA e 60% para
a s
h eฺ
o grupo de discos RECO. )
r
ฺ Guid
b
m
- Backups external to Oracle Exadata Database Machine: se estiver executando
k o ฺco dent
backups em um armazenamento em disco externo ao Oracle Exadata Database
t ei Stu
Machine, como em Exadata Storage Servers dedicados adicionais, um servidor
o r te@ this
NFS, uma biblioteca de fitas virtual ou uma biblioteca de fitas, selecione esta
ฺ s up use
opção. Esta definição aloca 80% do espaço disponível para o grupo de discos
( t ec se to
DATA e 20% para o grupo de discos RECO.
•
e i ko licen
O nível de proteção especifica as definições de redundância do ASM aplicadas a
diferentes grupos de discos. Normalmente a definição variará dependendo de diversos
o T
ic fatores, como a natureza dos bancos de dados hospedados no Database Machine,
Tecn o tamanho dos bancos de dados, o método de backup selecionado e as metas de
disponibilidade do sistema. A Oracle recomenda o uso de grupos de discos de alta
redundância para aplicações de missão crítica.
- High for ALL: tanto o grupo de discos DATA como o RECO são configurados
com a redundância alta do Oracle ASM (espelhamento triplo). Esta opção estará
disponível somente se o método de backup externo for selecionado.
- High for DATA: o grupo de discos DATA é configurado com a redundância alta
do Oracle ASM, e o grupo de discos RECO é configurado com a redundância
normal do Oracle ASM (espelhamento duplo).
- High for RECO: o grupo de discos DATA é configurado com a redundância
normal do Oracle ASM, e o grupo de discos RECO é configurado com a
redundância alta do Oracle ASM. Esta opção estará disponível somente se
o método de backup externo for selecionado.
- Normal for ALL: Os grupos de discos DATA e RECO são configurados com a
redundância normal do Oracle ASM.

Escolhendo o Nível de Proteção Certo
• Redundância HIGH:
– Espelhamento triplo em três servidores de armazenamento separados

– Oferece a proteção máxima
— O espelhamento duplo ainda será mantido se uma célula estiver off-line
– Requer maior capacidade de armazenamento
– As gravações exigem maior largura de banda de entrada/saída
• Redundância NORMAL:
– Espelhamento duplo em dois servidores de armazenamento separados
le
– Fornece uma camada de redundância
fe rab
— Não oferecerá proteção adicional se uma célula estiver off-line
tr ans
—
n -
Requer tempo e esforço extras para manter a redundância por meio da
manutenção planejada no a
• Gerenciamento do espaço livre: a
h eฺ s
– É necessário espaço livre para preservar a redundância r )
– Considere o impacto da perda de umodisco m b
ฺ e da G uidde uma célula
perda
– Considere também o nível de proteção o ฺc desejado e n t e o número de células
disponíveis t k
ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
e nível apropriado
A escolha
o Tdo de redundância do ASM (NORMAL ou HIGH) para seus grupos
i c
ecn
de discos é uma decisão importante que afeta a capacidade de armazenamento, a tolerância
T a falhas e até mesmo o desempenho do Database Machine. Não há uma recomendação geral
adequada para todas as circunstâncias. Os clientes devem considerar os impactos de cada
definição e selecionar a mais adequada à sua situação. Lembre-se do seguinte:
• Redundância HIGH
A redundância HIGH resulta na gravação de três cópias dos dados no armazenamento em três
Exadata Storage Servers separados. Ela oferece a proteção máxima, tolerando a perda
simultânea de até duas células inteiras.
Um custo associado a essa proteção é que a capacidade de armazenamento geral
do Database Machine é reduzida em um-terço quando comparada à fornecida com a
redundância NORMAL. Por exemplo, um Database Machine Full Rack com discos de alto
desempenho tem uma capacidade de disco bruta de aproximadamente 100 TB. Com a
redundância HIGH aplicada, a capacidade utilizável torna-se aproximadamente 30 TB
comparada a aproximadamente 45 TB quando a redundância NORMAL é usada.
Outro custo é que todas as gravações nos grupos de discos de redundância HIGH devem ser
executadas em três servidores de armazenamento separados. Isso significa que uma largura
de banda de entrada/saída 50% maior é consumida pelas gravações nos grupos de discos de
redundância HIGH quando comparada às gravações nos grupos de discos de redundância
NORMAL.
Entradas/saídas adicionais não são necessárias para operações de leitura. Portanto,
ao selecionar o nível de proteção adequado, o equilíbrio entre as operações de leitura e
gravação da aplicação, bem como seus requisitos de largura de banda de entrada/saída,
devem ser considerados.
• Redundância NORMAL
A redundância NORMAL resulta na gravação de duas cópias dos dados no armazenamento
em dois Exadata Storage Servers separados. Como já foi ressaltado, a redundância
NORMAL tem custos mais baixos em termos da capacidade de armazenamento e do

consumo de largura de banda de entrada/saída para as operações de gravação.
O uso da redundância NORMAL no Database Machine fornece uma boa proteção para
os dados, tolerando a perda de até uma célula inteira. Entretanto, observe que, em
determinadas situações, a proteção dos dados poderá ser comprometida com o uso
da redundância NORMAL.
Em primeiro lugar, considere que algumas operações de manutenção, como a aplicação de
le
patches em células, por exemplo, exigem que uma célula fique off-line por um período de
fe rab
tempo. Durante esse período, a disponibilidade dos dados é mantida por meio da outra cópia.
a ns
Entretanto, o que acontecerá se uma falha afetar a única cópia restante? O grupo de discos
tr
n -
ficará off-line, interrompendo ou possivelmente encerrando o processamento do banco de
a no
dados. Essa situação pode ser evitada com a remoção da célula do grupo de discos e o
a s
rebalanceamento dos dados para outras células antes que a célula fique off-line. No entanto,
h eฺ
r )
ฺ Guid
essa operação requer um tempo substancial e consome uma quantidade significativa de
b
m
largura de banda de entrada/saída. Ela também exige que haja espaço livre suficiente
disponível nas demais células.
k o ฺco dent
t ei Stu
De maneira semelhante, com o uso da redundância NORMAL, a perda simultânea de dois
r te@ this
discos em servidores de armazenamento diferentes poderá resultar na indisponibilidade
o
ฺ s up use
de parte de um banco de dados. Embora esse seja um cenário altamente improvável, sua
( t ec se to
probabilidade é bem maior do que uma interrupção semelhante usando a redundância HIGH.
e i ko licen
• Gerenciamento do espaço livre
Quando o T uma falha, o ASM requer espaço livre em um grupo de discos para recriar
ocorre
n i c
extensões dos dados perdidos a fim de preservar a redundância. A quantidade de espaço
T e c
livre necessária depende da quantidade de armazenamento afetada pela falha. A Oracle
recomenda que os clientes considerem a possibilidade de perda de uma célula inteira ao
determinarem a quantidade espaço livre geralmente mantida. Observe que o nível de
redundância do ASM (HIGH ou NORMAL) e o modelo do Database Machine usado podem ter
um profundo impacto na quantidade de espaço livre necessária para manter essa
redundância.
Por exemplo, em um Database Machine Full Rack, com 14 células, a falha de uma célula
exige que o conteúdo dessa célula seja redistribuído entre as 13 células restantes. Isso
significa que 1/14 (pouco mais de 7%) da capacidade geral precisa ser reservada como
espaço livre para preservar a redundância em caso de perda de uma célula.
Por outro lado, em um Database Machine Quarter Rack, com apenas três células,
é necessário que pelo menos 1/3 da capacidade total esteja livre para preservar a
redundância NORMAL se uma célula ficar indisponível.
Além disso, em um Database Machine Quarter Rack com a redundância HIGH, será
impossível preservar a redundância se uma célula for perdida, uma vez que um Quarter Rack
contém apenas três células inicialmente. Entretanto, nesse caso, você poderá optar por
continuar as operações com as duas células restantes até que a terceira seja substituída.

Planilha de Configuração Geral de Rede
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 de Planilha de Configuração Geral de Rede preenchida.
Te um exemplo
O slideomostra
e c nic os campos da planilha precisam ser preenchidos. Descrições de cada campo

Todos
T são apresentadas a seguir:
• Domain name: este campo deve ser definido como o nome do domínio da rede de
gerenciamento em que reside o Database Machine.
• IP address of the name server: use este campo para identificar até quatro servidores
DNS na rede onde reside o Database Machine. Embora seja possível implementar
o Database Machine sem DNS, a Oracle recomenda que o DNS seja usado com o
Database Machine.
• IP address of the NTP time server: use este campo para identificar até quatro
servidores de tempo NTP na rede onde reside o Database Machine. Os serviços NTP
são um requisito obrigatório do Database Machine. O NTP fornece o tempo coordenado
que sincroniza os serviços no Database Machine. Sem NTP, uma falta de coordenação
pode fazer com que os nós do banco de dados sejam despejados do cluster ou as
células do Exadata sejam excluídas do pool de armazenamento. Os serviços NTP
também garantem que os timestamps gravados nos vários arquivos de log sejam
coordenados no Database Machine. Observe que o CTSS (Cluster Time
Synchronization Service) introduzido no Oracle Clusterware11g Release 2 não pode ser
usado para fornecer serviços de tempo às células do Exadata, portanto, ele não é
usado no Database Machine.
Planilha de Configuração da
Rede de Gerenciamento
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 de Planilha de Configuração da Rede de Gerenciamento
Te um exemplo
O slideomostra
e c nic
preenchida. Todos os campos da planilha precisam ser preenchidos. As entradas dessa
T planilha são usadas para configurar as interfaces de rede de gerenciamento de todos os
servidores de banco de dados, células do Exadata e interfaces de rede de gerenciamento
em outros componentes do Database Machine.
Defina o campo Starting IP address como o primeiro endereço IP na faixa de endereços IP
alocados para a rede de gerenciamento. Usando esse endereço como ponto de partida, os
programas de configuração alocam sequencialmente endereços IP para cada interface de
rede na rede de gerenciamento. Os endereços IP são alocados a tipos de interface diferentes
na seguinte ordem:
1. Interfaces de gerenciamento do servidor de banco de dados
2. Interfaces de gerenciamento do Exadata Storage Server
3. Interfaces ILOM do servidor de banco de dados
4. Interfaces ILOM do Exadata Storage Server
5. Interface de gerenciamento do KVM switch
6. Interface de gerenciamento do Ethernet switch
7. Interfaces de gerenciamento do InfiniBand switch
8. Interfaces de gerenciamento da PDU (Power Distribution Unit)

Exemplo de Alocação de Endereço IP de
Rede de Gerenciamento
Tipo de Interface Nome do host Endereço IP
Interface de gerenciamento do servidor de banco de dados eidmdb01 10.7.7.101

Interface de gerenciamento do servidor de banco de dados eidmdb02 10.7.7.102
Interface de gerenciamento da célula do Exadata eidmcel01 10.7.7.103
Interface ILOM do servidor de banco de dados eidmdb01-ilom 10.7.7.106
Interface ILOM do servidor de banco de dados eidmdb02-ilom 10.7.7.107
le
rab
Interface ILOM da célula do Exadata eidmcel01-ilom 10.7.7.108
Interface ILOM da célula do Exadata eidmcel02-ilom 10.7.7.109 fe
a n s
Interface ILOM da célula do Exadata eidmcel03-ilom
-t r
10.7.7.110
n
Interface de gerenciamento do KVM switch eidmsw-kvm
n o 10.7.7.111
Interface de gerenciamento do Ethernet switch eidmsw-ip s a 10.7.7.112
) a
h eฺ 10.7.7.114
Interface de gerenciamento do InfiniBand switch
b r
eidmsw-ib2
ฺeidmsw-ib3 u id 10.7.7.115
Interface de gerenciamento do InfiniBand switch m G
Interface de gerenciamento da PDU
k o ฺco deeidm-pdua
nt 10.7.7.116
t e i t u
Interface de gerenciamento da PDU
e @ i s S eidm-pdub 10.7.7.117
p o rt e th
ฺ s empresas afiliadas. Todos os direitos reservados.
suOracletoe/ouusuas
c
Copyright © 2012,
(te nse
o
ik lice
Usando T
as
eplanilhas de exemplo de Quarter Rack mostradas nesta lição, os endereços IP
en i c o
os nomes de host seriam alocados, por default, conforme indicado na tabela do slide.
T e c
Observe que os endereços são alocados sequencialmente em cada tipo de interface.
É possível alterar a política de endereçamento default definindo-se valores específicos mais
adiante no processo de configuração. Entretanto, esse procedimento não é recomendado
uma vez que os engenheiros de serviços e suporte da Oracle conhecem bem a ordem de
alocação default, e quaisquer alterações poderão gerar confusão caso os defaults sejam
utilizados posteriormente. Além disso, se a política de endereçamento default for modificada,
será necessário verificar se os endereços resultantes são válidos e se não há duplicações.
Observe também que o endereço 10.7.7.113 parece estar faltando. Na verdade, esse
endereço seria alocado para um InfiniBand switch com o nome de host eidmsw-ib1
caso algo diferente de um Quarter Rack estivesse sendo configurado. Entretanto, como
os Database Machines Quarter Rack têm apenas dois InfiniBand switches, o endereço
IP é ignorado.

Planilha de Configuração da Rede de
Acesso do Cliente
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 de Planilha de Configuração da Rede de Acesso do Cliente
Te um exemplo
O slideomostra
e c nic
preenchida. Todos os campos da planilha precisam ser preenchidos. As entradas dessa
T planilha são usadas para configurar as interfaces da rede de acesso do cliente em todos
os servidores de banco de dados do Database Machine.
Determine se essa rede usará a Ethernet de 1G ou de 10 Gb. Por default, a rede de acesso
do cliente é configurada como a Ethernet de 1Gb; entretanto, os clientes poderão configurar
a Ethernet de 10 Gb caso a sua rede esteja equipada de forma adequada.
Determine se o acoplamento de canais será usado para a interface de rede principal de
acesso do cliente. O acoplamento de canais fornece proteção adicional contra vários tipos
de falhas de rede, resultando em maior disponibilidade. Embora a Oracle recomende o uso
do acoplamento de canais, talvez os clientes precisem fazer alterações em suas redes para
suportar esse recurso.
Defina o campo Starting IP address como o primeiro endereço IP na faixa de endereços IP
alocados para a rede de acesso do cliente. Usando esse endereço como ponto de partida,
os programas de configuração alocam sequencialmente endereços IP na seguinte ordem:
1. Interfaces físicas da rede de acesso do cliente dos servidores de banco de dados
2. Interfaces de rede virtual (VIPs) dos servidores de banco de dados
3. Endereços SCAN (Single Client Access Name)

Exemplo de Alocação de Endereços IP da
Rede de Acesso do Cliente
Tipo de Endereço Nome do host Endereço IP

Interface física de acesso do cliente do servidor de banco
de dados eidm01 172.16.1.101
Interface física de acesso do cliente do servidor de banco

de dados eidm02 172.16.1.102
VIP do servidor de banco de dados eidm01-vip 172.16.1.103
VIP do servidor de banco de dados eidm02-vip 172.16.1.104 le

Endereço SCAN eidm-scan 172.16.1.105fe
rab
a n s
Endereço SCAN eidm-scan -t r
172.16.1.106
n
n o
Endereço SCAN eidm-scan
s a
172.16.1.107
) 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 c exemplo de Quarter Rack mostradas nesta lição, os endereços IP
Usando o Teplanilhaslide
as
en
c osicnomes de host seriam alocados, por default, conforme indicado na tabela do slide.
e
T Observe que os endereços são alocados sequencialmente a partir do endereço inicial
especificado na planilha de configuração.
Como os endereços IP da rede de gerenciamento, é possível alterar a política de
endereçamento default da rede de acesso do cliente definindo-se valores específicos mais
adiante no processo de configuração. Entretanto, esse procedimento não é recomendado
uma vez que os engenheiros de serviços e suporte da Oracle conhecem bem a ordem de
alocação default, e quaisquer alterações poderão gerar confusão caso os defaults sejam
utilizados posteriormente. Além disso, se a política de endereçamento default for modificada,
será necessário verificar se os endereços resultantes são válidos e se não há duplicações.

Planilhas de Configuração de Rede Opcional
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 de dados do Database Machine contêm outras portas de rede que
Te de banco
Os servidores
o
e c nic ser configuradas opcionalmente para acessar várias redes de acesso de cliente. Por
podem
T exemplo, uma rede de acesso do cliente secundária poderia ser configurada para conectar
o Database Machine a uma rede dedicada contendo um silo de fitas para fins de backup ou
uma organização poderia usar redes de acesso de cliente diferentes para suportar classes de
aplicação distintas.
Há duas outras planilhas que podem ser usadas para informar definições opcionais de rede
de acesso de cliente. Um exemplo de Planilha de Configuração de Rede Adicional em branco
é mostrado no slide.
Lembre-se de que, se você estiver usando o acoplamento de canais para a rede principal de
acesso do cliente, as duas primeiras interfaces de rede em cada servidor de banco de dados
serão acopladas. Nesse caso, a segunda interface de rede não estará mais disponível para
uma rede de acesso do cliente opcional.

Planilha de Configuração de PDUs
(Power Distribution Units)
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 de configuração que pode ser usada para especificar se as
Também
o Tháeuma planilha
e c nic (Power Distribution Units) serão monitoradas na rede. Em caso afirmativo, use os
PDUs
T dois outros campos da planilha a fim de especificar endereços IP para as interfaces de rede
de gerenciamento nas duas PDUs do Database Machine. As entradas dessa planilha são
opcionais. Se a planilha ficar em branco, endereços IP default serão alocados para as PDUs,
conforme mostrado no exemplo de alocação de endereços IP da rede de gerenciamento,
anteriormente na lição.

Planilha de Configuração do
Auto Service Request
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 ServicelicRequest) abre automaticamente solicitações de serviço (SRs) no
O ASRo(Auto
e c nic Support quando ocorrem falhas específicas de hardware, seja nos Exadata Storage
Oracle
T Servers ou nos servidores de banco de dados. A configuração do ASR é opcional, mas
recomendada. O slide mostra uma Planilha de Configuração do Auto Service Request
em branco. Ela descreve os atributos importantes de configuração do ASR. Informações
adicionais sobre a configuração e a operação do ASR são fornecidas mais adiante na lição
Ecossistema de Suporte Automatizado do Database Machine do curso.

Planilhas de Configuração do
Oracle Enterprise Manager 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 licGrid Control é o ambiente de monitoramento recomendado para o
Te Manager
O Enterprise
o
ic Database Machine. As planilhas de configuração mostradas no slide facilitam a
ecn
Exadata
T coleta das informações necessárias para configurar o Enterprise Manager Grid Control junto
com o Exadata Database Machine. A configuração é opcional, mas recomendada.
Se um ambiente inteiramente novo do Grid Control estiver sendo estabelecido para monitorar
o Database Machine, use a planilha de nova instalação mostrada do lado esquerdo do slide.
Se uma instalação existente do Grid Control for configurada para monitorar o Database
Machine, use a planilha de instalação mostrada do lado direito do slide.
A configuração e o uso do Enterprise Manager Grid Control com o Exadata Database
Machine são abordados em detalhes em várias lições mais adiante no curso.

Planilha de Configuração de
Envio de Alertas de Célula
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
e célulalidoc Exadata podem ser enviados aos administradores por meio do
Tde
Os alertas
o
e c nic SMTP (Simple Mail Transfer Protocol), do protocolo SNMP (Simple Network
protocolo
T Management Protocol) ou de ambos. O envio de alertas de célula pode ser configurado
durante o processo de configuração inicial ou a qualquer momento posteriormente. Para
configurar o envio de alertas de célula como parte da configuração inicial, preencha a
planilha de configuração mostrada no slide. A configuração é opcional, mas recomendada.

Etapas Posteriores às Planilhas de Configuração
Fase de
Pré-instalação Fase de
Instalação e
Configuração
Planejamento e
Preparação Planilhas de
Configuração
le
fe rab
Planilha do
tra ns
-
Configurador
n
no a
a
h eฺ s Gerar
r
ฺ Guid
b )
m
k o ฺcode dent
Arquivos
Programas de
Configuração t ei Stu
Configuração
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic poderá ter uma natureza iterativa à medida que os requisitos forem
A faseodeTpré-instalação
e c nic
esclarecidos e as definições das planilhas de configuração forem refinadas.
T Uma vez preenchidas as planilhas de configuração, suas informações serão usadas para
executar tarefas e orientar os programas que configuram o Database Machine. O diagrama
do slide mostra as principais etapas desse processo.
A próxima seção desta lição descreve as atividades relacionadas em mais detalhes.
Conforme mencionado anteriormente, é altamente recomendável que os engenheiros de
hardware e software da Oracle conduzam essas atividades para garantir que o Database
Machine seja configurado de uma forma padrão e suportada.

Visão Geral da Planilha do Configurador
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 nas planilhas de configuração são usadas para preencher a
Te coletadas
As informações
o
ic do Configurador do Database Machine. A planilha é um documento do Microsoft
ecn
Planilha
T Excel usado para gerar um conjunto de arquivos de configuração que orientam os programas
de configuração do Database Machine, principalmente o utilitário OneCommand.
Em geral, um engenheiro da Oracle usará a planilha e gerará os arquivos de parâmetros.
Os clientes que quiserem configurar o Database Machine por conta própria ou simplesmente
entender melhor a planilha do configurador devem consultar o capítulo Using the Oracle
Exadata Database Machine Configurator Spreadsheet do Database Machine Owner's Guide.
Observe os seguintes pontos sobre a planilha do configurador:
• A versão da planilha do configurador deve ser compatível com a release do software
existente no Database Machine. Confirme com o representante da Oracle se você tem
a versão correta dessa planilha.

• A planilha do configurador poderá conter algumas opções de configuração adicionais
que não são capturadas nas planilhas de configuração. O representante da Oracle
deverá discutir essas opções com você como parte do planejamento e da preparação
do local.
• A planilha do configurador fornece várias de definições default baseadas nas melhores
práticas atuais associadas ao Database Machine. Ela também permite a personalização
de várias definições de configuração. Por exemplo, os nomes de usuário e grupo
associados ao proprietário do software Oracle podem ser personalizados junto com

os locais do diretório Oracle Home. A Oracle recomenda que os clientes utilizem as
definições default sempre que possível para garantir que o Database Machine seja
configurado de uma forma padrão e suportada.
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

Gerando os Arquivos de Configuração
le
fe rab
tr ans
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 liccampos de entrada da planilha do configurador, os arquivos de
Uma vez
o Tdefinidos os
e c nic
configuração usados para orientar os programas de configuração do Database Machine
T podem ser gerados com este processo de duas etapas:
1. Clique no botão Generate para gerar as definições de configuração de servidores
individuais na planilha abaixo dos campos de entrada. O slide mostra um exemplo.
As entradas contidas nessa área da planilha podem ser personalizadas para definir
nomes de host e endereços IP específicos, por exemplo. Entretanto, é recomendável
que as definições default sejam usadas sempre que possível para minimizar o risco de
erros ou de configurações incorretas. Se algum dos campos de entrada coloridos for
alterado, clique novamente no botão Generate para que a alteração seja refletida na
seção gerada.
2. Após verificar as definições geradas, clique no botão Create Config Files para criar
os arquivos de configuração usados para orientar os programas de configuração do
Database Machine. Uma série de arquivos é gravada em um diretório nomeado de
acordo com a convenção a seguir:
c:\dbmachine_<Customer Name>\<Database Machine Prefix>\
Embora você possa examinar as entradas nos arquivos gerados, não é recomendável
que os arquivos sejam modificados diretamente porque esse procedimento poderá
resultar em erros durante a execução dos programas de configuração. Se você fizer
uma alteração na planilha após criar os arquivos de configuração, deverá recriá-los
para que a alteração seja incorporada.
Visão Geral da Instalação do
Hardware do Database Machine
Consulte o Owner's Guide para obter detalhes sobre as
seguintes tarefas de instalação do hardware:

• Revisar as Diretrizes de Segurança
• Desembalar o Oracle Exadata Database Machine
• Colocar o Oracle Exadata Database Machine no Espaço
Alocado para Ele
– Mover o Oracle Exadata Database Machine le
– Estabilizar o Oracle Exadata fe rab
Database Machine
tr a ns
– Conectar um Cabo de Aterramento n -
no a
• Ligar o Sistema pela Primeira Vez a s
– Inspecionar a Máquina Após a Instalação r ) h eฺ
m ฺ Guid
b
– Conectar os Cabos de Força
k o ฺco dent
– Ligar o Oracle Exadata t eiDatabase
S t u Machine
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lice a preparação do local, mas antes da execução dos programas de
Te
Após ooplanejamento
e c nic
configuração, o hardware do Database Machine deve ser instalado fisicamente no local. A
T lista do slide resume as tarefas recomendadas. O capítulo 5 do Owner's Guide, Installing
Oracle Exadata Database Machine at the Site , descreve essas tarefas em detalhes.

Visão Geral da Configuração do
Oracle Exadata Database Machine
• Conectar à Rede
• Configurar o KVM Switch

• Configurar o Sun Datacenter InfiniBand Switch 36
• Configurar o Cisco Ethernet Switch
• Configurar as PDUs (Power Distribution Units)
• Verificar os Exadata Storage Servers
• Verificar os Servidores de Banco de Dados Oracle
• Executar Verificações e Configurações Adicionais r a ble
• Verificar a Rede InfiniBand n s fe
• Selecionar o Sistema Operacional n - tra
n o
• Recuperar Espaço em Disco Após a Seleção do Sistema s a Operacional
h a ฺ
• Executar a Configuração Inicial da Rede
ฺ b r) uide
• Carregar as Informações de Configuração
ฺ c om enInstalar
t G o Software
o udeControl
• eik Grid
Instalar o Oracle Enterprise Manager
t S t
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Uma vez
e
Tinstalado ic
ol hardware do Database Machine, a configuração inicial poderá ser
o
e c nic Essa configuração usa as informações coletadas nas planilhas de configuração,
realizada.
T junto com os refinamentos implementados na planilha do configurador, para configurar
o hardware e o software do Database Machine. A lista do slide mostra as etapas de
configuração recomendadas documentadas no capítulo Configuring Oracle Exadata
Database Machine do Owner's Guide.
Várias das tarefas de configuração listadas são mecânicas por natureza, envolvendo a
execução de diversos comandos e verificações para configurar um componente do Database
Machine. Exemplos dessas tarefas incluem estabelecer conexão com a rede e configurar o
KVM switch.
Algumas das tarefas de configuração são mais complexas e têm um impacto maior no
Database Machine. Por exemplo, a seleção do sistema operacional e a instalação do
software com o utilitário OneCommand.
A próxima parte desta lição descreve em mais detalhes algumas das tarefas de configuração
mais complexas (listadas em vermelho no slide) e os utilitários usados para executá-las.

Selecionando o Sistema Operacional do
Servidor de Banco de Dados
• Agora os clientes podem escolher o sistema operacional
do servidor de banco de dados:

– Oracle Linux X86_64 (default)
– Oracle Solaris 11 for x86
• Os servidores vêm da fábrica com os dois sistemas
operacionais pré-carregados
• O espaço ocupado pelo sistema operacional não usado é rable
e
recuperado e reutilizado 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
e i k lic
O Oracle
o TExadata Database Machine é fornecido com os sistemas operacionais Linux e
i c
ecn
Solaris para os servidores do Oracle Database. O Linux é o sistema operacional default,
T mas os clientes podem optar pelo Solaris. Os servidores vêm da fábrica com os dois
sistemas operacionais pré-carregados Uma vez escolhido o sistema operacional, os discos
que contêm o sistema operacional não desejado devem ter seu espaço recuperado para
que possam ser usados pelo sistema selecionado.
Observe que a Oracle não recomenda um sistema operacional como preferencial. Ambos
são excelentes opções. Os clientes que preferem ou que têm maior familiaridade com o Linux
podem usá-lo. Os clientes que preferem ou que têm maior familiaridade com o Linux podem
escolhê-lo.

Implantando o Solaris nos Servidores de
Banco de Dados
Como o usuário root em cada servidor de banco de dados:
# cd /opt/SupportTools
# ./defaultOSchoose.pl
Default OS is : LINUX_BOOT_0
Please choose new default OS:
[0] LINUX_BOOT_0
[1] SOLARIS_BOOT_1
a b le
[2] SOLARIS_BOOT_2
fe r
Please type the number you would like to make a newans
default OS: 1 n-tr no
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 do Database Machine são pré-configurados com o Linux
Te de banco
Os servidores
o
e c nic o sistema operacional default. Os clientes que quiserem usar o Linux não precisam
como
T executar as tarefas mostradas nesta página.
Os clientes que optarem pelo Solaris devem executar as seguintes etapas em cada servidor
de banco de dados:
1. Efetue login como o usuário root.
2. Acesso o diretório /opt/SupportTools .
3. Execute defaultOSchoose.pl
4. Quando solicitado, informe 1 para selecionar SOLARIS_BOOT_1 como a opção de
sistema operacional e pressione Enter.

Recuperando no Linux o Espaço em Disco
do Sistema Operacional Não Usado
# ./reclaimdisks.sh -check
<check for expected output>
# ./reclaimdisks.sh –free –reclaim

le
<monitor /var/log/cellos/reclaimdisks.bg.log> fe rab
tr a ns
n -
no a
a
h eฺ s
<check for expected output>
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 servidor de banco de dados selecionado for o Linux, utilize
Te operacional
Se o sistema
o
ic
ecn
o procedimento a seguir em cada servidor para recuperar o espaço usado pelo sistema
T operacional Solaris:
2. Acesse o diretório /opt/oracle.SupportTools .
3. Verifique a configuração atual do disco com o comando:
# ./reclaimdisks.sh –check
O comando retorna um layout detalhado dos discos lógicos e físicos. No caso do Oracle
Exadata Database Machine X2-2, a última linha da saída deve ser a seguinte:
[INFO] Valid dual boot configuration found for Linux: RAID1 from
2 disks
No caso do Oracle Exadata Database Machine X2-8 Full Rack, a última linha da saída
deve ser a seguinte:
[INFO] Valid dual boot configuration found for Linux: RAID5 from
3 disks and 1 global hot spare disk

4. Inicie o processo de recuperação do disco usando o comando:
# ./reclaimdisks.sh -free –reclaim
O comando libera todos os discos configurados para o Solaris e recupera todos os
discos livres para o
Linux. O processo poderá levar aproximadamente duas horas para o Oracle Exadata
Database Machine X2-2 e cinco para o Oracle Exadata Database Machine X2-8 Full
Rack. Certifique-se de que o comando não seja interrompido e o servidor não seja
reinicializado durante o processo de recuperação. Para verificar o andamento do

processo de recuperação, monitore o arquivo de log do comando usando:
# tail -f /var/log/cellos/reclaimdisks.bg.log
5. Execute o comando a seguir quando o processo de recuperação do disco for concluído:
No caso do Oracle Exadata Database Machine X2-2, a última linha da saída deve ser a
seguinte: le
[INFO] Valid single boot configuration found for Linux: RAID5 fe rab
from 3 disks and 1 global hot spare disk
a n s
n
No caso do Oracle Exadata Database Machine X2-8 Full Rack, a última
r
-t linha da saída
n o
deve ser a seguinte: a
[INFO] Valid single boot configuration h
) as for
found ฺ Linux: RAID5
from 7 disks and 1 global hot spare r
ฺbdiskGuid e
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
n
Tec

Recuperando no Solaris o Espaço em Disco
do Sistema Operacional Não Usado
# ./reclaimdisks.pl
This script changes the Linux virtual and physical disks

to Solaris disks.
<Output truncated> le
fe rab
The virtual disks will be deleted. Do you want to
tra ns
proceed? (yes/no) yes n -
This is an irreversible operation. Confirm a no you want
that
to proceed. (yes/no) yes as ) h eฺ
r
ฺ Guid
b
Deleting the virtual disks ... om
k o ฺc dent
t ei Stu
te@ this
<Output continues>
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
Se o sistema
o lic de servidor de banco de dados selecionado for o Solaris, utilize
Te operacional
on
c ic
procedimento a seguir em cada servidor para recuperar o espaço usado pelo sistema
T e operacional Linux:
2. Acesse o diretório /opt/oracle.SupportTools .
3. Recupere o espaço em disco usando o comando:
# ./reclaimdisks.pl
Por default, o script é executado no modo interativo. Nos diversos pontos em que
o script faz uma pausa, informe yes quando solicitado até que o processo seja
concluído. Certifique-se de que o comando não seja interrompido e o servidor não
seja reinicializado durante o processo de recuperação.
Observe que o comando pode ser executado no modo não interativo usando:
# ./reclaimdisks.pl –unattended

Executando a Configuração Inicial da Rede
Os endereços IP e os nomes de host são aplicados aos

servidores do Database Machine:
# cd /opt/oracle.SupportTools/firstconf
# ./applyconfig.sh <size>
/opt/oracle.SupportTools/onecommand/preconf.csv
le
fe rab
tr a ns
n -
Endereços IP, no a
nomes de host
a
h eฺ s
r
ฺ Guid
b )
m
ฺco dent
preconf.csv
applyconfig.sh iko
@ te Stu
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licservidores de banco de dados do Database Machine e todas as
Te todos os
Inicialmente,
o
e c nic do Exadata são configurados com endereços IP e nomes de host default. Para aplicar
células
T os endereços IP e os nomes de host especificados usando as planilhas de configuração e a
planilha do configurador, use o seguinte processo:
1. Abra uma sessão de console no primeiro servidor de banco de dados. O primeiro
servidor de banco de dados é o que está posicionado na parte inferior (montado
próximo ao chão) do rack.
2. Efetue login como o usuário root no primeiro servidor de banco de dados. A senha
default é welcome1.
3. Copie os arquivos de configuração gerados pela planilha do configurador para o
diretório /opt/oracle.SupportTools/onecommand. O Owner's Guide documenta
os procedimentos para copiar os arquivos de configuração usando uma unidade flash
USB ou uma conexão de rede temporária.
4. Use o comando imagehistory para determinar a versão do software do Database
Machine. Se ela for anterior à 11.2.1.3.0, use o script fetch_macs.sh para obter
os endereços MAC da interface de rede e use o editor vi para atualizar o arquivo
preconf.csv. Consulte o Owner's Guide para obter detalhes completos sobre esse
procedimento se necessário.

5. Valide o arquivo preconf.csv usando o seguinte comando:
# /opt/oracle.cellos/ipconf.pl -verify \
-preconf /opt/oracle.SupportTools/onecommand/preconf.csv
6. Execute o script applyconfig.sh usando o seguinte comando:
# cd /opt/oracle.SupportTools/firstconf
# ./applyconfig.sh <size>
/opt/oracle.SupportTools/onecommand/preconf.csv
No comando anterior, <size> é o tamanho do Oracle Exadata Database Machine. Use
full para o Database Machine Full Rack, half para o Database Machine Half Rack
ou quarter para o Database Machine Quarter Rack. O script applyconfig.sh
executa a configuração da rede para todos os servidores de banco de dados e Exadata
Storage Servers. Todos os servidores são reinicializados durante o processo.
7. Conecte o cabo da rede corporativa de gerenciamento ao Cisco Ethernet switch.
8. Conecte os cabos da rede corporativa de acesso do cliente aos servidores de banco le
de dados. fe rab
a ns
9. Reinicialize todos os servidores de banco de dados e Exadata Storage Servers.
tr
n -
rede com os seguintes comandos: a no
10. Efetue login no primeiro servidor de banco de dados para verificar a conectividade de
a s
h eฺ
r
# cd /opt/oracle.SupportTools/onecommand )
ฺ Guid
b
# ./checkip.sh -m post_applyconfigm
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

Carregando as Informações de Configuração e
Instalando o Software
Etapas executadas pelo OneCommand:
• Etapa 0: Validar o ambiente. • Etapa 13: Revincular o Reliable Data Socket

• Etapa 1: Criar o diretório de trabalho. (RDS) para o Grid Infrastructure.
• Etapa 2: Descompactar os arquivos. • Etapa 14: Executar scripts de grade como
• Etapa 3: Configurar o SSH para o usuário usuário root.
root. • Etapa 15: Instalar o software do Oracle
• Etapa 4: Atualizar o arquivo /etc/hosts. Database.
• Etapa 5: Criar os arquivos cellip.ora e • Etapa 16: Aplicar patches no software de
cellinit.ora banco de dados.
• Etapa 6: Validar as células. • Etapa 17: Criar os grupos de discos
• Etapa 7: Verificar o RDS usando o comando do Oracle ASM.
le
ping. • Etapa 18: Executar o Oracle Database
fe rab
ns
• Etapa 8: Criar as contas de usuário para Configuration Assistant.
celladmin e cellmonitor. •
tr a
Etapa 19: Desbloquear o Oracle Grid
-
• Etapa 9: Configurar o SSH para as contas
•
Infrastructure.
no n
Etapa 20: Revincular o protocolo RDS.
de usuário.
• s a
Etapa 21: Bloquear o Oracle Grid
• Etapa 10: Criar os discos de grade.
Infrastructure.
) a
h eฺ
•
•
Etapa 11: Instalar o software de grade.
Etapa 12: Aplicar patches no software do • b r
ฺ Guid
Etapa 22: Configurar alertas de e-mail para
m
ฺ•co dent
diretório Home de grade. os Exadata Storage Servers.
k oEtapa 23: Aplicar correções de segurança.
t ei •Stu
Etapa 24: Proteger o Oracle Exadata
o r te@ this Database Machine.
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic é usado para configurar a pilha de software do Oracle Exadata
TOneCommand
O utilitário
o
ic Machine com base nas informações dos arquivos de configuração. O slide lista
ecn
Database
T as etapas atuais (a partir de agosto de 2011) executadas pelo OneCommand. As etapas
executadas pelo OneCommand estão sujeitas a alteração à medida que o processo de
instalação e configuração se torna mais preciso e automatizado.
As etapas são executadas sequencialmente e cada uma delas deve ser concluída com êxito
antes do início da próxima. Todas as etapas, ou uma faixa especificada de etapas, podem
ser executadas com um único comando. Também é possível executá-las individualmente.
Se uma etapa falhar, na maioria dos casos, a causa da falha poderá ser corrigida, e o
processo será reiniciado executando-se novamente a etapa com falha. Dependendo da
natureza exata do problema, é possível que algumas falhas exijam um esforço manual
adicional para restaurar o estado do Database Machine anterior à falha. O arquivo
README que acompanha o OneCommand fornece mais orientação sobre essas atividades.
Entretanto, o planejamento e a execução cuidadosos de todas as etapas de instalação e
configuração por pessoas com experiência são fundamentais para evitar problemas com
esse utilitário.
Dependendo do modelo e da capacidade do Database Machine, o processo inteiro (todas as
etapas) do OneCommand poderá levar até cerca de cinco horas para ser executado.

Executando o OneCommand no
Database Machine
1. Efetue login como o usuário root no primeiro servidor de banco de
dados. A senha default é welcome1.

– Os arquivos de configuração já devem estar localizados em
/opt/oracle.SupportTools/onecommand
2. Efetue download de todos os patches necessários do Software do
Oracle Exadata Storage Server e do Oracle Database.
– Consulte My Oracle Support note 888828.1 para obter detalhes.
3. Aplique as atualizações do utilitário OneCommand.
le
– Consulte o arquivo README associado para obter instruções.
fe rab
4. Acesse o diretório do OneCommand:
tr a ns
n -
# cd /opt/oracle.SupportTools/onecommand no a
a s
h comando:
5. Execute o utilitário OneCommand usando b )
o rseguinte d e ฺ
m ฺ Gu i
# ./deploy112.sh –i [ -s <n>o|ฺc-r <n>-<N> o n t
i k d e | -l ]
@ te Stu
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Te o procedimento
O slideodescreve necessário para executar o utilitário OneCommand para
i c
ecn
configurar o Database Machine. Observe que o utilitário é executado no primeiro servidor
T de banco de dados; esse é o servidor localizado na parte inferior do rack, que corresponde
à posição U16. Os arquivos de configuração já deverão ter sido carregados nesse servidor
como parte das tarefas de configuração anteriores.
Antes de executar o OneCommand, todos os patches e atualizações necessários devem
ser carregados no servidor. My Oracle Support bulletin 888828.1 é a principal referência
caso você deseje obter detalhes. Talvez também seja necessário atualizar o utilitário
OneCommand antes de executá-lo.
Para executar o OneCommand, acesse o diretório
/opt/oracle.SupportTools/onecommand e execute deploy112.sh usando a opção
-i (instalar). Os exemplos a seguir destacam as outras opções do script:
• Para executar uma etapa específica do OneCommand, use a opção –s. Por exemplo,
para executar a etapa 3 (Configurar o SSH para o usuário root), use o seguinte
comando:
# ./deploy112.sh –i –s 3
• Para executar várias etapas do OneCommand, use a opção –r. Por exemplo, para
executar todas as etapas (0-24), use o seguinte comando:
# ./deploy112.sh –i –r 0-24
• Para listar as etapas do OneCommand, use a opção -l, conforme mostrado a seguir:
# ./deploy112.sh –i -l
Configuração do Armazenamento do Exadata
Área do Sistema (Discos 0-1)

Célula do le
rab
ou DBFS_DG (Discos 2-11)
Exadata 1 do
Célula
(29 G)
fe
DATA_EIDM
Célula
Exadata 2 do
Exadata n
tr a ns
n -
(40%)
no a
a
h eฺ s
RECO_EIDM r
ฺ Guid
b )
m
(60%)
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k ic OneCommand, o armazenamento do Exadata é configurado de
Durante oTprocesso ldo
o
ic simétrica. Ou seja, o armazenamento em cada célula do Exadata é configurado
maneira
e c
da
nmesma maneira que nos outros servidores de armazenamento.
T Em cada servidor de armazenamento, um disco de célula é definido para cada disco físico.
Os discos de célula usam a convenção de nomeação de CD_<nn>_<cell host name>
em que <nn>é um identificador de dois dígitos no intervalo de 00 a 11 e <cell host
name> é o nome de host canônico do servidor de armazenamento. Por exemplo,
CD_01_eidmcel01.
Em cada disco de célula baseado em disco, além dos dois primeiros (<nn>=00 ou 01), é
criado um disco de grade com o prefixo DBFS_DG. Esses discos de grade têm cerca de 29
GB de tamanho cada um. Eles são alocados ao grupo de discos DBFS_DG. Nos primeiros
dois discos (<nn>=00 ou 01) de cada célula, cerca de 29 Gigabytes são usados para
armazenar a área do sistema, que contém a imagem do SO, o espaço de swap, os binários
do software do Exadata, o repositório de métricas e alertas, além de vários outros arquivos
de metadados e de configuração. Devido ao layout das áreas do sistema e do grupo de
discos DBFS_DG , o espaço restante em cada disco é idêntico.
No espaço restante em cada disco de célula baseado em disco, é criado um disco de grade
com o prefixo DATA e outro com o prefixo RECO. Esses discos de grade são alocados aos
grupos de discos chamados DATA_<DBM NAME> e RECO_<DBM NAME>, onde <DBM NAME>
é o nome do Database Machine representado em letras maiúsculas. Com base nas planilhas
de exemplo mostradas anteriormente nesta lição, os nomes dos grupos de discos seriam
DATA_EIDM e RECO_EIDM.

O dimensionamento dos discos de grade com prefixo DATA e RECO, bem como o dos
tablespaces que os consomem, é determinado pela definição do método de backup
especificada na planilha de configuração. Se forem especificados backups internos, 40% do
espaço restante em cada disco será alocado para o grupo de discos DATA e 60% será
alocado para o grupo de discos RECO. Se forem especificados backups externos, a divisão
do espaço restante será 80% para o grupo de discos DATA e 20% para o grupo de discos
RECO.
O fator final que afeta a configuração do armazenamento é a definição do nível de proteção.

Isso determinará a definição da redundância (normal ou alta) dos grupos de discos DATA e
RECO. O grupo de discos DBFS_DG usa a redundância normal do ASM.
Observe que a configuração de armazenamento default poderá ser alterada manualmente
pelos clientes após a configuração inicial. My Oracle Support note 1272569.1 fornece
orientação sobre como alterar um grupo de discos sem ocasionar a indisponibilidade de
um Database Machine.
le
fe rab
Se o exemplo de Quarter Rack mostrado anteriormente nesta lição for usado, isso resultará
na seguinte configuração de armazenamento:
tra ns
n
• Cada disco de alto de desempenho de 600 GB terá aproximadamente 29 GB -
no
reservados para a área do sistema do Exadata Storage Server ou para o grupo de
a
a s
discos DBFS_DG. Do espaço restante em cada disco, 40% (aproximadamente 228 GB)
h eฺ
r )
seriam alocados para o grupo de discos DATA_EIDM e 60% (aproximadamente
ฺ Guid
b
343 GB) para o grupo de discos RECO_EIDM. m
o nt
k o ฺcdiscos e
• O espaço total alocado para cada grupo
seria: t ei Stud em todas as três células do Exadata
de
- Aproximadamente 870o r teGB@(29 tGB

h isx 10 discos por célula x 3 células) para
DBFS_DG. ฺsu
p use
( t
- Aproximadamente
o (228 GB x 12 discos x 3 células) para DATA_EIDM.
ec se8 tTB
- e i ko licen 12 TB (343 GB x 12 discos x 3 células) para RECO_EIDM.
Aproximadamente
o T a redundância normal do ASM ser aplicada conforme especificado na definição de
• icApós
n
Tec configuração do nível de proteção, a quantidade de espaço utilizável em cada grupo de
discos será:
- Aproximadamente 435 GB para DBFS_DG.
- Aproximadamente 4 TB para DATA_EIDM.
- Aproximadamente 6 TB para RECO_EIDM.
Observe que os tamanhos acima não levam em consideração os overheads normais do
Oracle Database ou do ASM. Além disso, não há uma margem para atenuar falhas de
disco ou célula.

Resultado após a Instalação e a Configuração
eidm01 172.16.1.101 eidm02 172.16.1.102
eidm01-vip 172.16.1.103 eidm02-vip 172.16.1.104 eidm-scan 172.16.1.105

172.16.1.106
eidmdb01 eidmdb01-ilom eidmdb02 eidmdb02-ilom

10.7.7.101 10.7.7.106 10.7.7.102 10.7.7.107 172.16.1.107
Servidor de BD 1 Servidor de BD 2
Instância de Banco Instância de Banco
de Dados: dbm1 de Dados: dbm2
Instância ASM: +ASM1 Instância ASM: +ASM2
Cluster: eidm Cluster: eidm
eidmdb01-priv eidmdb02-priv
192.168.10.1 192.168.10.2
le
fe rab
ns
eidmcel01-priv eidmcel02-priv eidmcel03-priv
192.168.10.3 192.168.10.4 192.168.10.5
- tr a
DBFS_DG DBFS_DG DBFS_DG
no n
DATA_EIDM DATA_EIDM
s a DATA_EIDM
) a
h eฺ
RECO_EIDM RECO_EIDM r
ฺ Guid
b RECO_EIDM
Servidor Exadata 2 co
m t Exadata 3
Servidor Exadata 1
k o ฺ denServidor
eidmcel01 eidmcel01-ilom
t ei Stu
eidmcel02 eidmcel02-ilom eidmcel03 eidmcel03-ilom
te@ this
10.7.7.103 10.7.7.108 10.7.7.104 10.7.7.109 10.7.7.105 10.7.7.110
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
c o resultado após a instalação e a configuração, com base nos
Tedo slideliilustra
O diagrama
o
ic de planilha de configuração mostrados anteriormente nesta lição. Ele também
ecn
exemplos
T pressupõe que a planilha do configurador especificou a criação de um banco de dados com
as definições default.
Os nomes de host e endereços IP se baseiam nas definições e nas políticas de alocação
default. Observe que cada nome de host começa com o nome do Database Machine (eidm).
Observe também o esquema de alocação default de endereço IP.
Cada servidor de banco de dados é instalado com a mesma configuração de sistema
operacional, incluindo as mesmas definições de conta de usuário e grupo Oracle. Os
servidores de banco de dados são configurados como um cluster sob o controle do software
Oracle Clusterware. Um cluster ASM também é configurado. Finalmente, o software do
Oracle Database é instalado em cada servidor de banco de dados, e um banco de dados
RAC (Real Application Clusters) é estabelecido em todos os nós do cluster.
Observe os detalhes a seguir referentes à instalação e à configuração do Oracle Grid
Infrastructure e do Oracle Database no Database Machine:
• O GNS (Grid Naming Service) não é configurado. O DNS é o serviço de nomeação
preferencial para o Database Machine.
• Por default, o Database Control não é configurado para bancos de dados criados pelo
processo de instalação e de configuração.
Atividades de Configuração Adicionais Suportadas
• Proteção contra Terremotos usando uma Plataforma de

Isolamento Sísmico de Terceiros
• Substituir o Ethernet switch

• Conectar uma biblioteca de fitas para backup ble
• Personalizar a configuração do armazenamento fe r a
n s
• Criar e configurar bancos de dados n - tra
o
• Configurar recursos do banco de dados an
– Oracle Data Guard r) has eฺ
– DBFS (Database File System)om ฺ b
G uid
ฺc nt
• iko ude
Configurar o Enterprise eManager
t t
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic atividades típicas de configuração que os clientes podem executar
Te algumas
O slideorelaciona
e c nic sua própria mão de obra e à sua custa. Os pontos a seguir ampliam algumas delas:
usando
T • Os clientes podem implementar uma proteção contra terremotos com uma Plataforma
de Isolamento Sísmico de Terceiros desde que não haja alterações físicas no Database
Machine nem no rack.
• Os clientes podem substituir o Cisco Ethernet switch por um equivalente de sua
escolha. Como alternativa, os clientes podem implementar switches de gateway
de terceiros para isolar o Database Machine de outros componentes da rede.
• Os clientes podem conectar servidores ou dispositivos adicionais com o Database
Machine via Ethernet ou InfiniBand. Em geral, eles requerem que essas conexões
conectem sua infraestrutura de backup e recuperação ou facilitem a transferência
de dados de outros sistemas.

Atividades de Configuração não Suportadas
• Alteração do rack do hardware

• Adição de componentes a servidores

• Adição de servidores a configurações Quarter Rack ou
Half Rack
• Swapping de distribuições Linux
• Configuração de ACFS
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 Te de configuração
As atividades a seguir não são suportadas pelo Database Machine:
i c
Tecn• Alteração do rack do hardware: às vezes, os clientes desejam alterar o rack do
Database Machine para atender a uma política do centro de dados, obter uma proteção
contra terremotos ou superar algum tipo de limitação física. A alteração do rack, além
de gerar erros, poderá causar, entre outros, danos aos componentes, problemas no
gerenciamento térmico e de cabos. Como resultado, a alteração do rack do hardware
do Database Machine não é suportada.
• Adição de componentes a servidores: às vezes, os clientes desejam adicionar
componentes ao Database Machine. Um exemplo típico é o desejo de adicionar
um HBA (Host Bus Adapter) aos servidores de banco de dados para que eles
sejam conectados com o armazenamento SAN existente. A adição de componentes
a servidores no Database Machine não é suportada devido ao potencial de
incompatibilidades do driver e do firmware, que poderão prejudicar o sistema.
• Adição de servidores a configurações Quarter Rack ou Half Rack: fora de um
upgrade suportado, a adição física de servidores a um Quarter Rack ou a um Half Rack
não é suportada porque ela altera as características do ambiente e da alimentação
do sistema. Ela também afeta a capacidade futura de se conduzir uma atualização
suportada. Observe que os clientes podem adicionar células do Exadata a qualquer
configuração do Database Machine colocando células adicionais em um rack separado
e usando as portas InfiniBand sobressalentes conectadas com eles.
• Swapping de distribuições Linux: o Oracle Linux é fornecido como o sistema
operacional dos servidores de banco de dados e do Exadata no Database Machine.
O swapping de distribuições Linux não é suportado.
• Configuração de ACFS: o ACFS (ASM Cluster File System) não está disponível
atualmente no Database Machine.
Observação: consulte o seu representante da Oracle para saber se outras atividades de
configuração são ou não suportadas.
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
Utilizando as planilhas de configuração, é possível definir

endereços IP específicos para cada servidor de banco de

dados e cada célula do Exadata no 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
Asnplanilhas de configuração capturam somente o primeiro endereço IP em uma faixa de
c
T e endereços para as diversas redes do Database Machine. Posteriormente, na planilha do
configurador, será possível definir endereços IP individuais modificando os endereços
gerados depois que você clicar no botão Generate. Lembre-se de que, se você modificar
a política de endereçamento default, deverá garantir que os endereços resultantes sejam
válidos e que não haja duplicações. Observe que, embora a planilha do configurador
seja bastante flexível e ofereça várias oportunidades de personalização, é altamente
recomendável que os clientes sigam as convenções default sempre que possível. Isso não
somente reduz a possibilidade de erros ou configurações incorretas, mas também ajuda a
garantir um suporte mais fácil à configuração resultante.

Questionário
Qual das opções para conexão com o armazenamento SAN

existente é suportada com o Database Machine?

a. Instalar um Fiber Channel HBA em cada servidor de
banco de dados
b. Usar um servidor conectado com a SAN existente como
um gateway de armazenamento e conectá-lo com o
Database Machine usando NFS pela Ethernet
r a ble
c. Usar um servidor conectado com a SAN existente como n s fe
um gateway de armazenamento e conectá-lo com n -otra
o
npela
Database Machine usando NFS pela Etherneta
InfiniBand ) h as ฺ
r 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
e c lic
Resposta:
o Tb,
An
c ic
conexão do Database Machine com outros servidores usando Ethernet ou InfiniBand não é
T e suportada. A adição de componentes de hardware aos servidores do Database Machine não
é suportada.

Resumo

• Descrever o processo de instalação e de configuração do

Database Machine.
• Descrever a configuração default do Database Machine.
• Descrever personalizações suportadas e não suportadas
do 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

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
Configuração do Exadata Storage Server
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

• Configurar o software do Exadata

• Criar e configurar grupos de discos ASM usando 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

Visão Geral da Administração do
• Cada Exadata Storage Server é administrado individualmente
• A maior parte da administração é executada pelo utilitário CellCLI

– O CellCLI só pode ser executado na célula que está sendo
administrada
– O CellCLI opera junto com o MS para executar tarefas administrativas
– Exemplo de sessão do CellCLI:
le
[celladmin@cell01 ~]$ cellcli
fe rab
CellCLI: Release 11.2.1.2.0 - Production ...
tr a ns
n -
CellCLI> list cell
no a
cell01 online
a
h eฺ s
CellCLI> exit r
ฺ Guid
b )
m
ฺco dent
quitting
k o
[celladmin@cell01 ~]$
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic Server existente no Database Machine é autônomo uma vez que
Cada o Te Storage
Exadata
on
c ic operacional e os serviços de armazenamento em cada célula do Exadata são
sistema
e
T executados de maneira independente de todos os outros Exadata Storage Servers. Em linha
com essa autonomia, cada célula é administrada individualmente. A maioria das funções de
administração é executada com o utilitário CellCLI (cell command-line interface) do Exadata.
O CellCLI só pode ser usado em uma célula para gerenciar essa mesma célula. Entretanto, é
possível executar o mesmo comando CellCLI remotamente em várias células com o utilitário
dcli, que é descrito mais adiante nesta lição.
O utiliário CellCLI opera em conjunto com o MS (Management Server) do Exadata Storage
Server. Ele fornece a interface de comando enquanto o MS executa as funções
administrativas, como a criação e a eliminação de discos de grade.

Contas de Usuário Administrativo do
Três usuários do sistema operacional são configurados para cada
Exadata Storage Server:

• O usuário root pode:
– Editar arquivos de configuração, como cellinit.ora e cellip.ora
– Alterar as definições de configuração de rede
– Executar utilitários de suporte e de diagnóstico localizados no diretório
/opt/oracle.SupportTools
– Executar o comando CellCLI CALIBRATE le
– Executar todas as tarefas que o usuário celladmin pode executar fe rab
• O usuário celladmin pode:
ns tra
n -
– Executar tarefas administrativas (CREATE, DROP, ALTER,
a noetc.) usando
o utilitário CellCLI
) h as ฺ
– Incluir incidentes em pacotes para o Oracle
m ฺbr Support,u ideusando o utilitário
adrci
o ฺ co ent G
• O usuário cellmonitor somente
t e ik pode t u d visualizar (LIST) objetos
da célula do Exadata e usando S CellCLI.
@ hoisutilitário
r t
o se t
u p
Copyright © 2012,
e
t
o ( ense
i k lic operacional são configurados para cada Exadata Storage Server:
Te do sistema
Três usuários
o
e c nic celladmin e cellmonitor. O slide descreve a função de cada conta de usuário.
root,
T Após a configuração inicial de um Database Machine com o utilitário OneCommand,
as contas de usuário do sistema operacional são definidas com senhas iniciais. A senha
inicial default de root é welcome1. A senha inicial default dos usuários cellmonitor e
celladmin é welcome. É recomendável alterar as senhas iniciais de todas as contas de
usuário para senhas mais seguras uma vez concluída a configuração inicial.

Visão Geral do Utilitário dcli
• O utilitário dcli permite que você execute simultaneamente

um comando em vários servidores do Database Machine

• Tipos de comandos:
– Comandos do sistema operacional
– Comandos CellCLI
– Scripts do sistema operacional
– Scripts do CellCLI
le
• Os comandos são executados em threads paralelos fe rab
separados tra ns
n -
• Sessões interativas não são suportadas
a no
• O Python 2.3 e a equivalência de usuário ) h as são
SSH ฺ
necessários b r
ฺ Gu i d e
o m t no terminal
• A saída do comando é coletada
k o ฺc e exibida
e n
executando o utilitário@ tei Stud
dcli
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
e facilita lic o gerenciamento centralizado no Database Machine, automatizando
Tdcli
O utilitário
o
ic
ecn
a execução de um comando em um conjunto de servidores e retornando a saída para o
T local de gerenciamento centralizado, no qual o dcli foi executado. Os tipos de comandos
suportados pelo dcli incluem comandos do sistema operacional, comandos CellCLI, scripts
do sistema operacional e scripts do CellCLI.
O utilitário dcli executa comandos em vários servidores em threads paralelos. No entanto,
ele não oferece suporte a uma sessão interativa com uma aplicação remota em um servidor.
Por default, o utilitário dcli está localizado em /opt/oracle/cell/cellsrv/bin/dcli,
em cada servidor do Exadata, e em /usr/local/bin/dcli, em cada servidor de banco de
dados. Você também pode copiar o utilitário dcli em um servidor fora do Database Machine
e executar centralmente os comandos a partir desse servidor.
O utilitário dcli requer o Python versão 2.3 ou mais recente no servidor que o executa.
Você pode determinar a versão do Python executando o comando python -V. Além disso,
o dcli requer a configuração prévia da equivalência de usuário SSH entre todos os
servidores. É possível usar o utilitário dcli inicialmente com a opção -k para configurar
a equivalência de usuário SSH entre um grupo de servidores.
A saída do comando (para stdout e stderr) é coletada e exibida após a execução do comando
nos servidores especificados. As opções do utilitário dcli permitem abreviar a saída do
comando para filtragem como, por exemplo, para remover as mensagens que mostrem o
status normal.
Exemplos do utilitário dcli
$ dcli –g mycells date

cell01: Sun May 16 20:48:09 CDT 2010
cell02: Sun May 16 20:48:09 CDT 2010
$ dcli –c cell01,cell02 cellcli –e list cell

cell01: cell01 online
cell02: cell02 online
le
$ dcli –g mycells –x cellclicommands.scl fe rab
tra ns
n -
$ dcli –g mydbservers –l root –x dbwork.sh
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 de exemplos que usam o utilitário dcli.
Te uma lsérie
O slide mostra
o
ic exemplo mostra o dcli sendo usado para executar o comando date do sistema
Onprimeiro
c
e
T operacional. A opção –g especifica um arquivo (mycells) que contém a lista de servidores
de destino para os quais o comando (date) é enviado. Os servidores podem ser
identificados por nomes de host ou endereços IP. Os servidores podem ser servidores de
banco de dados ou Exadata Storage Servers.
O segundo exemplo usa a opção –c para especificar os servidores de destino
(cell01,cell02) na linha de comando. Ela chama o CellCLI para reportar o status da
célula.
O terceiro exemplo usa a opção –x para especificar um arquivo de comando. O arquivo de
comando deverá existir no servidor que estiver executando o utilitário dcli. Ele é copiado
nos servidores de destino e executado. Um arquivo com a extensão .scl é executado pelo
utilitário CellCLI no servidor de destino. Um arquivo com uma extensão diferente é executado
pelo shell do sistema operacional no servidor de destino. O arquivo é copiado para o diretório
home default do usuário no servidor de destino. Os arquivos especificados com a opção –x
devem ter privilégios de execução. Caso contrário, dcli reportará um erro.
O último exemplo adiciona o uso da opção –l para especificar o usuário com o qual
estabelecer conexão nos servidores remotos. Por default, o utilitário dcli conecta-se como o
usuário celladmin.
Para obter mais informações, consulte o capítulo Using the dcli Utility no Oracle Exadata
Storage Server Software User's Guide 11g Release 2 (11.2).

Testando o Desempenho do Servidor de
Armazenamento com o Comando CALIBRATE
Largura de banda do disco Largura de banda do canal
Métrica = IOPS Métrica = MBPS
É necessário um RPM É necessário

alto e tempo de busca um canal de
rápido entradas/saídas
grande
le
fe rab
OLTP DW/OLAP
tr ans
(Entrada/saída (Entrada/saída n -
aleatória pequena) no
sequencial grande)
a
a
h eฺ s
r
ฺ Guid
b )
m
k o ฺco dent
t ei Stu
CALIBRATE
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic executa testes de desempenho bruto nos discos do Exadata
TeCALIBRATE
O comando
o
ic Server e nos módulos flash do Exadata. Isso permite medir duas métricas
ecn
Storage
T importantes – IOPS e MBPS:
• IOPS (Entradas/saídas por segundo): esta métrica representa o número de
entradas/saídas aleatórias pequenas que podem ser atendidas em um segundo.
A taxa de IOPS depende, principalmente, da rapidez com que a mídia de disco
pode girar e quantos discos existem no sistema de armazenamento.
• MBPS (megabytes por segundo): esta métrica representa a taxa na qual os
dados podem ser transferidos entre o nó do servidor de computação e o array
de armazenamento. Isso depende principalmente da capacidade do canal de
entrada/saída usado para transferir os dados.
A carga de trabalho de entradas/saídas do banco de dados compreende entradas/saídas
aleatórias pequenas e entradas/saídas sequenciais grandes. As entradas/saídas aleatórias
pequenas costumam prevalecer em um ambiente de aplicação OLTP, enquanto as
entradas/saídas sequenciais grandes são comuns em ambientes de data warehouse.

Exemplo de Comando CALIBRATE
[root@cell01 ~]# cellcli

CellCLI: Release 11.2.1.2.0 - Production on Mon Nov 02 16:42:06 PST 2009
Copyright (c) 2007, 2009, Oracle. All rights reserved.

Cell Efficiency ratio: 1.0
CellCLI> CALIBRATE FORCE

Calibration will take a few minutes...
Aggregate random read throughput across all hard disk luns: 1601 MBPS
Aggregate random read throughput across all flash disk luns: 4194,49 MBPS
Aggregate random read IOs per second (IOPS) across all hard disk luns: 4838
Aggregate random read IOs per second (IOPS) across all flash disk luns: 137588
Controller read throughput: 1615.85 MBPS
le
Calibrating hard disks (read only) ...
fe rab
ns
Lun 0_0 on drive [20:0 ] random read throughput: 152,81 MBPS, and 417 IOPS
Lun 0_1 on drive [20:1
...
- tr a
] random read throughput: 154,72 MBPS, and 406 IOPS

no n
a
s
) a
Calibrating flash disks (read only, note that writes will be significantly slower).
h eฺ
r
Lun 1_0 on drive [[10:0:0:0]] random read throughput: 269,06 MBPS, and 19680 IOPS
ฺ Guid
b
m
ฺco dent
...
o
k
ei Stu
Lun 5_3 on drive [[11:0:3:0]] random read throughput: 268.91 MBPS, and 19637 IOPS
t
te@ this
CALIBRATE results are within an acceptable range.
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
TeCALIBRATE
O comando
o lic permite verificar o desempenho do disco e da memória flash. Você
icexecutar esse comando enquanto estiver conectado ao servidor de armazenamento
ecn
deve
T como o usuário root do sistema operacional.
O comando CALIBRATE FORCE permite executar os testes durante a execução de
CELLSRV. Se você não usar a opção FORCE, deverá ser feito shutdown de CELLSRV. A
execução de CALIBRATE e CELLSRV ao mesmo tempo afetará o desempenho e geralmente
não é recomendada durante as operações normais. O comando CALIBRATE FORCE é
aceitável quando as células não estão executando uma carga de trabalho do usuário,
como, por exemplo, durante os períodos de manutenção programada.
O exemplo do slide mostra uma saída típica para discos de alto desempenho em que os
resultados corresponderam às expectativas. Uma mensagem diferente será mostrada se
as medidas de desempenho ficarem abaixo do padrão.

Configurando o Software do Exadata Cell Server

CellCLI: Release 11.2.1.2.0 - Production on Mon Nov 02 17:46:13 PST 2009

Cell Efficiency ratio: 1.0
CellCLI> ALTER CELL smtpServer='my_mail.example.com', -

smtpFromAddr='exadata.cell01@example.com', -
smtpPwd=<email_address_password> - le
smtpToAddr='jane.smith@example.com', -
fe rab
notificationPolicy='critical,warning,clear',
notificationMethod='mail'
tr
-
a ns
n -
no
Cell cell01 successfully altered
s a
CellCLI>
) 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
Você pode
o Tealterar oulicconfigurar atributos de célula usando o comando CellCLI ALTER CELL.
ic
Onslide mostra um exemplo de comando ALTER CELL que configura a notificação por e-mail.
c
T e Esse recurso envia mensagens de e-mail ao administrador da célula de armazenamento
sempre que alertas críticos, de advertência e de eliminação são detectados pela célula.
Além da notificação por e-mail, é possível configurar a notificação usando o SNMP (Simple
Network Management Protocol).

Iniciando e Interrompendo o
Software do Exadata Cell Server

CellCLI: Release 11.2.2.1.0 - Production on Wed Jul 20 17:54:21 EDT 2011

Cell Efficiency Ratio: 19M
CellCLI> ALTER CELL RESTART SERVICES ALL
Stopping the RS, CELLSRV, and MS services...

le
rab
The SHUTDOWN of services was successful.
Starting the RS, CELLSRV, and MS services...
fe
Getting the state of RS services...
tr a ns
running
n -
Starting CELLSRV services...
no a
The STARTUP of CELLSRV services was successful.
Starting MS services... a
h eฺ s
The STARTUP of MS services was successful. r
ฺ Guid
b )
m
CellCLI>
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic você precise iniciar, interromper ou reiniciar os serviços de software
Te talvez
Ocasionalmente,
o
c ic
donExadata Storage Server: Restart Server (RS), Management Server (MS) e Cell Server
T e (CELLSRV). Para isso, use o comando CellCLI ALTER CELL. O slide mostra um exemplo.
A seguir é apresentado um resumo da sintaxe relevante:
ALTER CELL { SHUTDOWN | RESTART | STARTUP } SERVICES { RS | MS |
CELLSRV | ALL}

Configurando Discos de Célula
CellCLI> CREATE CELLDISK ALL HARDDISK

CellDisk CD_00_cell01 successfully created
...
CellCLI> LIST CELLDISK

CD_00_cell01 normal
... le
CD_10_cell01 normal
fe rab
CD_11_cell01
FD_00_cell01
normal
normal
tr a ns
n -
no
...
FD_14_cell01 normal
s a
FD_15_cell01 normal
) a
h eฺ
CellCLI> b r
ฺ 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
Para usar
o Toearmazenamento em disco de um Exadata Storage Server, é necessário criar
i c
n de célula baseados em disco com o comando CREATE CELLDISK.
discos
T e c
Observe que, na maioria das vezes, o processo de configuração inicial executado com
o utilitário OneCommand configurará os discos de célula e de grade do Exadata Storage
Server. A reconfiguração dos discos de célula e de grade existentes é abordada mais
adiante nesta lição.
O exemplo do slide mostra o uso do comando CREATE CELLDISK ALL HARDDISK para
criar 12 discos de célula baseados em disco com nomes default. Na maioria dos casos, os
nomes default de discos de célula são usados.
Se desejado, os discos de célula poderão ser configurados para permitir a criação de discos
de grade intercalados. Use o comando a seguir para criar discos de célula com intercalação
ativada:
CREATE CELLDISK ALL HARDDISK INTERLEAVING='normal_redundancy'
O exemplo anterior também mostra o uso do comando LIST CELLDISK. Na maioria dos
casos, a saída do comando LIST CELLDISK mostra os 12 discos de célula baseados em
disco junto com 16 discos de célula baseados em flash normalmente usados com o Exadata
Smart Flash Cache. O comando deve retornar o status normal para todos os discos de
célula.

Configurando Discos de Grade
Use a porção
CellCLI> CREATE GRIDDISK ALL PREFIX=data, SIZE=300G mais rápida

GridDisk data_CD_00_cell01 successfully created do disco
...
GridDisk data_CD_11_cell01 successfully created
CellCLI> CREATE GRIDDISK ALL PREFIX=fra

GridDisk fra_CD_00_cell01 successfully created
...
GridDisk fra_CD_11_cell01 successfully created Antes Depois
le
CellCLI> LIST GRIDDISK Disco
fe rab
Discos
data_CD_00_cell01 active de
célula
tra ns
de
grade
...
n -
data_CD_11_cell01 active
no a
fra_CD_00_cell01 active
h …a s
...
r ) d e ฺ …
fra_CD_11_cell01 active
ฺ b u i
CellCLI> exit
ฺ 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
Uma vezT
e ic de célula, os discos de grade devem ser provisionados com o
criados osldiscos
o
e c nic CREATE
comando
normalmente criados
GRIDDISK. Assim como os discos de célula, os discos de grade são
como parte da configuração inicial do Database Machine. Entretanto,
T algumas vezes, é possível que os discos de grade existentes sejam removidos e substituídos
por novos discos, como, por exemplo, quando os grupos de discos default são
redimensionados. Esse caso é analisado em mais detalhes posteriormente na lição.
O slide mostra exemplos de como criar discos de grade em novos discos de célula vazios.
No exemplo do slide, a opção ALL PREFIX é usada para criar automaticamente um disco de
grade em cada disco de célula. Quando a opção ALL PREFIX é usada, os nomes de discos
de grade gerados são compostos do prefixo do disco de grade seguido de um sublinhado (_)
e do nome do disco de célula.
Uma prática recomendada é usar o nome do grupo de discos ASM planejado como o prefixo
dos discos de grade correspondentes. No exemplo, os valores de prefixo data e fra são os
nomes dos grupos de discos ASM planejados que consumirão os discos de grade. Os nomes
de discos de grade devem ser exclusivos em todas as células de uma única implantação do
Database Machine. Seguindo as convenções recomendadas para nomeação dos discos de
grade e de célula, você obterá nomes exclusivos de forma automática.
O atributo SIZE opcional especifica o tamanho de cada disco de grade. Se esse atributo for
omitido, o disco de grade consumirá automaticamente todo o espaço restante no disco de
célula correspondente.
O comando LIST GRIDDISK mostra todos os discos de grade definidos no servidor de
armazenamento.
Discos de Grade Intercalados
Alocação Default dos
Discos de Grade Discos de Grade Intercalados
CellCLI> CREATE CELLDISK ALL HARDDISK –

CellCLI> CREATE CELLDISK ALL HARDDISK
INTERLEAVING='normal_redundancy'
CellCLI> CREATE GRIDDISK ALL PREFIX=data1, -
CellCLI> CREATE GRIDDISK ALL PREFIX=data3, -
SIZE=300G
SIZE=300G
CellCLI> CREATE GRIDDISK ALL PREFIX=data2
CellCLI> CREATE GRIDDISK ALL PREFIX=data4
disco de grade data1 disco de grade data3

faixas externas de melhor desempenho
Os discos de grade DATA1 utilizam as
O desempenho dos dois discos de

faixas mais rápidas faixas rápidas faixas mais rápidas faixas mais lentas
grade é mais equilibrado

le
fe rab
tr a ns
50% 50% 50% 50%
n -
a no
a
h eฺ s
r
ฺ Guid
b )
m
o nt
k o ฺcfaixas e
drápidas
faixas lentas faixas mais lentas
t e i t u faixas mais lentas
disco de grade data2
r t e @ his S disco de grade data4
u p o se t
Copyright © 2012,
e
t
o ( ense
i k
Teo espaçolicpara os discos de grade é alocado a partir das faixas externas para as
Por default,
o
e c nic internas
faixas
célula usa a
de um disco físico. Assim, o primeiro disco de grade criado em cada disco de
parte mais externa do disco, em que cada faixa contém mais dados, resultando
T em taxas de transferência mais altas e melhor desempenho.
No entanto, o espaço para discos de grade pode ser alocado de forma intercalada. Os discos
de grade que usam esse tipo de alocação de espaço são denominados discos de grade
intercalados. Esse método tenta equalizar o desempenho dos diversos discos de grade
que residem no mesmo disco físico.
O slide contrasta a alocação de discos de grade default com discos de grade intercalados. À
esquerda, dois discos de grade foram criados em um disco físico sem usar a intercalação.
Nesse caso, o disco de grade com PREFIX=data1 ocupa todas as faixas externas (mais
rápidas) e o disco de grade com PREFIX=data2 ocupa todas as faixas internas (mais
lentas).
À direita, observe um exemplo de discos de grade intercalados. Quando um disco de célula
é criado com INTERLEAVING='normal_redundancy', o disco é dividido em duas partes
iguais: a metade externa (parte superior) e a metade interna (parte inferior). Quando um novo
disco de grade é criado, metade do espaço é alocado na parte superior e a outra metade é
alocada na parte inferior.
Também é possível definir INTERLEAVING='high_redundancy'. Com essa definição,
um-terço do espaço em disco é alocado na parte superior e os dois-terços restantes são
alocados na parte inferior. Quando um novo disco de grade é criado, um-terço do espaço
desse disco é alocado na parte superior e os dois-terços restantes são alocados na parte
inferior.
Discos de Grade Intercalados e
ASM IDP (Intelligent Data Placement)
• Os discos de grade intercalados operam em conjunto
com o ASM IDP (Intelligent Data SQL> CREATE DISKGROUP data3dg

Placement): 2 NORMAL REDUNDANCY
3 DISK 'o/*/data3*' ...
– Extensões principais na parte superior SQL> CREATE DISKGROUP data4dg

2 NORMAL REDUNDANCY
— Garante que as extensões mais 3 DISK 'o/*/data4*' ...
acessadas estejam localizadas na parte grupo de discos data3dg

extensões principais extensões-espelho
de melhor desempenho do disco
– Extensões-espelho na parte inferior
le
• O IDP (Intelligent Data Placement) é
fe rab
ns
50% 50%
ativado automaticamente quando a
definição de REDUNDANCY do grupo - tr a
no n
de discos é compatível com a definição a
de INTERLEAVING subjacente a s
h grupo
) e
extensões principais
r d ฺde discos data4dg
extensões de espelhamento
– Definições incompatíveis não são permitidas:
m b
ฺ Gu i
Não é possível criar um grupo de o
ฺc dcom
discos ntdefinições incompatíveis
—
Não é possível adicionar e k o

i incompatíveis
discos u e a um grupo de discos
—
t S t
existente
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic
Os discosT de grade intercalados operam em conjunto com o ASM IDP (Intelligent Data Placement)
i c o
n de grade, enquanto as extensõesprincipais
para
ecdisco
garantir que as extensões ASM sejam colocadas na parte superior mais rápida de cada
secundárias (espelho) sejam colocadas na parte inferior mais
T lenta de cada disco. O IDP é ativado automaticamente quando a definição de REDUNDANCY do grupo
de discos é compatível com a definição de INTERLEAVING do disco de célula subjacente.
Portanto, para utilizar automaticamente o IDP em um grupo de discos com redundância NORMAL, os
discos de célula subjacentes devem ter a definição de atributo
INTERLEAVING='normal_redundancy'. Nesse caso, todas as extensões principais são colocadas
na metade externa (parte superior) do disco, e todas as extensões-espelho são colocadas na metade
interna (parte inferior).
Da mesma maneira, para utilizar automaticamente o IDP em um grupo de discos com redundância
HIGH, os discos de célula subjacentes devem ter a definição de atributo
INTERLEAVING='high_redundancy'. Nesse caso, todas as extensões principais são colocadas na
terça-parte externa (parte superior) do disco, e todas as extensões-espelho são colocadas nos dois-
terços internos (parte inferior).
Observe que o ASM não permitirá a incompatibilidade entre a definição de REDUNDANCY do grupo
de discos e a definição de INTERLEAVING dos discos de célula subjacentes. Por exemplo, um grupo
de discos com redundância NORMAL não poderá ser criado em discos de célula com a definição
INTERLEAVING='high_redundancy'. O ASM não permitirá a criação desse grupo de discos nem a
adição de discos a um grupo já existente caso isso venha resultar em uma incompatibilidade.

Criando Discos de Grade Baseados em Flash
CellCLI> DROP FLASHCACHE

Flash cache cell01_FLASHCACHE successfully dropped
CellCLI> CREATE FLASHCACHE ALL SIZE=100G

Flash cache cell01_FLASHCACHE successfully created
CellCLI> CREATE GRIDDISK ALL FLASHDISK PREFIX=flash

GridDisk flash_FD_00_cell01 successfully created
GridDisk flash_FD_01_cell01 successfully created Cache
Antes Depois Flash
le
rab
...
Cache
GridDisk flash_FD_15_cell01 successfully created
Flash
s fe
tra nDisco
de
CellCLI> LIST GRIDDISK
n - grade
...
no a
flash_FD_00_cell01
...
active
a
h e…ฺ s
flash_FD_15_cell01 active
ฺ b r ) i d …
CellCLI> exit
om nt G u
[celladmin@cell01 ~]$ ฺ 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 de configuração inicial da célula cria discos de célula baseados em
Teo processo
Por default,
o
e c nicem todos os dispositivos flash e, em seguida, aloca a maior parte do espaço flash
flash
disponível para o Exadata Smart Flash Cache. Em certas circunstâncias, você pode se
T beneficiar da criação de discos de grade baseados em flash para agir como um
armazenamento de dados baseado em flash permanente. Para criar espaço para discos de
grade baseados em flash, é necessário primeiro eliminar o flash cache default. Em seguida,
você pode criar um flash cache e discos de grade baseados em flash com os tamanhos
escolhidos.
No exemplo anterior, o flash cache default é eliminado. Em seguida, um novo Exadata Smart
Flash Cache é criado. O novo cache tem um tamanho total de 100 GB, o que significa que
6,25 GB do espaço é alocado em cada um dos 16 discos de célula baseados em flash.
O comando CREATE GRIDDISK é usado para criar discos de grade baseados em flash da
mesma forma que para discos de grade baseados em disco. Observe o uso da opção
FLASHDISK para especificar que discos de célula baseados em flash serão usados como
base para os discos de grade. No exemplo do slide, 16 discos de grade baseados em flash
são criados, e cada um consome o espaço restante disponível nos discos de célula baseados
em flash. Os discos de grade baseados em flash usam a mesma convenção de nomeação
default que os discos de grade baseados em disco.
Embora esse exemplo não mostre isso, você pode criar vários discos de grade em um disco
de célula baseado em flash. Diferente dos dispositivos de discos físicos, a ordem na qual
você aloca seu espaço flash não é importante do ponto de vista do desempenho. Da mesma
forma, a intercalação não é aplicável a discos baseados em flash.
Observação: as circunstâncias que favorecem o uso de discos de grade baseados em flash
são discutidas na lição Otimizando o Desempenho de Bancos de Dados com o Exadata.
Criando o Smart Flash Log
CellCLI> DROP FLASHCACHE

Flash cache cell01_FLASHCACHE successfully dropped
CellCLI> CREATE FLASHLOG ALL

Flash log cell01_FLASHLOG successfully created
CellCLI> CREATE FLASHCACHE ALL

Flash cache cell01_FLASHCACHE successfully created
le
rab
CellCLI> exit
fe
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 Server release 11.2.2.4.0, o Exadata Smart Flash Log fornece
A partir
o TeExadata lStorage
do
c
um imecanismo
ecn
para melhorar a latência das operações de gravação de redo logs do banco
T de dados. Para ambientes do Database Machine criados com essa release ou com releases
mais recentes do software, o Exadata Smart Flash Log é configurado automaticamente para
usar 32 MB em cada disco de célula baseado em flash, para um total de 512 MB em cada
Exadata Storage Server.
Os Database Machines atualizados para releases que fornecem o Exadata Smart Flash Log
devem ser reconfigurados para ativar esse recurso. O slide mostra a sequência de comandos
necessários para uma única célula do Exadata. O processo pode ser executado sem a
necessidade de períodos de indisponibilidade (downtime); entretanto, poderá ser observado
um impacto no desempenho a curto prazo devido à remoção temporária do Exadata Smart
Flash Cache.
Observe que, embora seja possível especificar o tamanho do Exadata Smart Flash Log, o
tamanho default deverá ser suficiente em todos os casos, com exceção dos mais extremos.
Além disso, se você estiver usando discos de grade baseados em flash, talvez precise fazer
ajustes a fim de levar em consideração a memória alocada para o Exadata Smart Flash Log.

Configurando Hosts para
Acessar Células do Exadata
• Arquivos de configuração em cada servidor de banco de
dados permitem o acesso ao armazenamento do Exadata

– cellinit.ora identifica a interface de rede de
armazenamento no servidor de banco de dados
– cellip.ora identifica as células do Exadata que podem
ser acessadas pelo servidor de banco de dados
– Exemplo: le
fe rab
$ cat /etc/oracle/cell/network-config/cellinit.ora
tr a ns
n -
no
ipaddress1=192.168.50.23/24
s a
$ cat /etc/oracle/cell/network-config/cellip.ora
) a
h eฺ
cell="192.168.51.27"
cell="192.168.51.28"
r
ฺ Guid
b
m
cell="192.168.51.29"
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Comoo Teda configuração
parte inicial do Database Machine, dois arquivos de configuração
n i c
importantes são criados em cada servidor de banco de dados os quais permitem que ele
T e c
acesse os Exadata Storage Servers:
• O arquivo cellinit.ora contém o endereço IP do servidor de banco de dados que
estabelece conexão com a rede de armazenamento. Esse arquivo é específico do host
e contém o endereço IP da interface de rede de armazenamento InfiniBand acoplada
desse servidor de banco de dados. O endereço IP é especificado no formato CIDR
(Classless Inter-Domain Routing).
• O arquivo cellip.ora contém os endereços IP das interfaces de rede
armazenamento InfiniBand acopladas dos Exadata Storage Servers que podem ser
acessados pelo servidor de banco de dados.
Se houver quaisquer problemas de conectividade entre um servidor de banco de dados e os
Exadata Storage Servers, verifique se esses arquivos contêm as definições corretas. Se
precisar fazer alterações nesses arquivos, siga este procedimento:
1. Interrompa as instâncias de banco de dados e Oracle ASM no host do servidor de
banco de dados.
2. Faça as alterações necessárias nos arquivos.
3. Reinicie as instâncias de banco de dados e Oracle ASM no host do servidor de banco
de dados.
Configurando Instâncias ASM e de Banco de
Dados para Acessar Células do Exadata
• Verifique se uma versão compatível do software do Oracle
Database está sendo usada:

– Consulte My Oracle Support bulletin 888828.1 para obter
uma lista atualizada das versões suportadas dos
componentes de software do Database Machine.
• Defina o parâmetro de inicialização do ASM
ASM_DISKSTRING: le
– ASM_DISKSTRING='o/*/*' fe rab
tra ns
• Defina o parâmetro de inicialização do banco de ndados
-
o
COMPATIBLE: an
– COMPATIBLE='11.2.0.0.0' ) 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
e i k c
apropriadasli dos diversos componentes de software do Database Machine devem
Versões T
c o
e c nisempre
ser
Oracle
mantidas para garantir a operação correta. Isso inclui a versão do software do
Database usada para as instâncias ASM e de banco de dados. Consulte My Oracle
T Support bulletin 888828.1 para obter uma lista atualizada das versões suportadas dos
componentes de software do Database Machine.
Para garantir que o ASM descubra os discos de grade do Exadata, defina o parâmetro de
inicialização ASM_DISKSTRING. Uma string de pesquisa com o formato a seguir é usada
para descobrir discos de grade do Exadata:
o/<cell IP address>/<grid disk name>
Coringas podem ser usados para expandir a string de pesquisa. Por exemplo, para descobrir,
de forma explícita, todos os discos de grade do Exadata, defina
ASM_DISKSTRING='o/*/*'. Para descobrir um subconjunto de discos de grade
disponíveis, com nomes que comecem com data, defina
ASM_DISKSTRING='o/*/data*'.
Observe que, se o parâmetro de inicialização ASM_DISKSTRING não estiver definido, o
default será descobrir todos os discos de grade do Exadata acessíveis no momento; ou seja,
os discos de grade das células listadas em cellip.ora e que não são proibidos por uma
definição de segurança. A segurança do Exadata Storage Server é discutida mais adiante
nesta lição.
Para configurar uma instância de banco de dados para acessar o armazenamento de célula,
verifique se o parâmetro COMPATIBLE está definido como 11.2.0.0.0 ou posteriormente
no arquivo de inicialização do banco de dados.
Configurando Grupos de Discos ASM com o
Armazenamento do Exadata
Grupo de discos DATA
Grupo com proteção para falhas cell01 Grupo com proteção para falhas cell02
o/<cell01 IP address>/data_cd_00_cell01 o/<cell02 IP address>/data_cd_00_cell02
... ...
o/<cell01 IP address>/fra_cd_00_cell01 o/<cell02 IP address>/fra_cd_00_cell02

... ...
le
rab
fe
Todos os discos candidatos em cell01 e cell02
tra ns
n -
no a
CREATE DISKGROUP data NORMAL REDUNDANCY
a
h eฺ s
DISK 'o/*/data*'
ATTRIBUTE 'compatible.rdbms' = '11.2.0.0.0', r
ฺ Guid
b )
m
'compatible.asm' = '11.2.0.0.0',
k o ฺco dent
ei Stu
'cell.smart_scan_capable' = 'TRUE',
t
te@ this
'au_size' = '4M';
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
Tede criação
O processo
o lic de grupos de discos ASM no Database Machine é essencialmente
ic usado em qualquer outra plataforma. Entretanto, para ativar o processamento
ecdonSmart Scan, as seguintes definições de atributo de grupo de discos devem ser usadas:
o mesmo
T
'compatible.rdbms' = '11.2.0.0.0' (ou posterior)
'compatible.asm' = '11.2.0.0.0' (ou posterior)
'cell.smart_scan_capable' = 'TRUE'
Além disso, é recomendável que você defina o valor de atributo de grupo de discos AU_SIZE
como 4M para otimizar a varredura de disco.
O exemplo contido no slide mostra discos ASM candidatos de duas células do Exadata:
cell01 e cell02. A instrução CREATE DISKGROUP faz referência a todos os discos ASM
candidatos que têm nomes que começam com data. Por default, grupos de discos para
falhas ASM correspondentes a cada célula são definidos automaticamente. Como resultado,
dois grupos com proteção para falhas são criados automaticamente usando os discos de
grade correspondentes de cada célula. Por default, os nomes de grupos com proteção para
falhas correspondem aos nomes das células.
Uma vez criado, um grupo de discos baseado no Exadata poderá ser usado para hospedar
os arquivos de dados Oracle da mesma forma que um grupo de discos ASM definido em
outro armazenamento. Para complementar a definição AU_SIZE recomendada de 4 MB,
você deve definir o tamanho de extensão inicial como 8 MB para segmentos grandes. Para
isso, use definições no nível de segmento ou de tablespace. As abordagens recomendadas
são discutidas na lição Otimizando o Desempenho de Bancos de Dados com o Database
Machine.
Reconfigurando o Armazenamento do Exadata
A realocação do espaço entre os grupos de discos DATA e RECO:

• Pode ser executada on-line (sem períodos de indisponibilidade)

• Pode ser um processo demorado
• Requer espaço livre suficiente DATA
• Detalhes em My Oracle Support note 1272569.1 RECO

• Descrição do procedimento:
le
SQL> ALTER DISKGROUP DATA DROP DISKS IN FAILGROUP <CELLNAME> ...
e rab
DATA
f
SQL> ALTER DISKGROUP RECO DROP DISKS IN FAILGROUP <CELLNAME> ...
trans RECO
o n -
CellCLI> DROP GRIDDISK ALL PREFIX='DATA' ...
a n
as ฺ
CellCLI> DROP GRIDDISK ALL PREFIX='RECO' ...
CellCLI> CREATE GRIDDISK ALL PREFIX='DATA', SIZE=<NEWSIZE>
) h
CellCLI> CREATE GRIDDISK ALL PREFIX='RECO'
m ฺbr Guide
o ฺco dent
SQL> ALTER DISKGROUP DATA ADD DISK k'o/<CELL_IB_IP>/DATA*';
SQL> ALTER DISKGROUP RECO ADD DISK t ei 'o/<CELL_IB_IP>/RECO*';
S tu
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Te o processo
Geralmente,
o lic de configuração inicial executado com o utilitário OneCommand é
e c nic para configurar todos os discos de célula, discos de grade e grupos de discos ASM
usado
T no Database Machine.
Se quiser reconfigurar o armazenamento, o meIhor momento para fazer isso é antes de os
dados do usuário serem carregados no Database Machine. Se for preciso reconfigurar um
armazenamento que já esteja sendo usado por bancos de dados de produção, isso será
possível, mas exigirá mais tempo, esforço e cuidado.
A forma mais comum de reconfiguração do armazenamento é ajustar o tamanho dos grupos
de discos default a fim de realocar o espaço entre os grupos de discos DATA e RECO.
Geralmente, o armazenamento é reconfigurado uma célula (grupo com proteção para falhas)
por vez. Ou seja, o armazenamento na primeira célula é reconfigurado e, depois que esse
processo é concluído e o armazenamento é adicionado novamente aos grupos de discos, a
próxima célula é reconfigurada, e assim por diante. O slide apresenta uma visão geral dos
comandos necessários.
My Oracle Support note 1272569.1 descreve três procedimentos baseados nesse resumo.
Em cada um dos casos, variações sutis nos comandos alteram o processo. Cada alternativa
apresenta requisitos diferentes em termos da quantidade de espaço livre necessária nos
grupos de discos que estão sendo reconfigurados. As opções também diferem no que diz
respeito ao modo como a redundância do ASM é mantida durante o processo de
reconfiguração, bem como ao tempo necessário para concluir esse processo.
Outra prática relativamente comum é tornar os grupos de discos default menores para
acomodar grupos de discos adicionais. Embora isso seja possível, a Oracle recomenda que
os clientes considerem se realmente precisam de grupos de discos adicionais porque a
criação desnecessária desses grupos fragmenta o armazenamento disponível e aumenta
desnecessariamente o overhead de gerenciamento.
Lembre-se das seguintes considerações gerais ao reconfigurar o armazenamento do
Exadata:
• Para reconfigurar um grupo de discos existente, é necessário eliminar os discos do

grupo, reconfigurá-los e, depois, adicioná-los novamente ao grupo. Se a quantidade de
espaço livre no grupo de discos for maior que o valor de REQUIRED_MIRROR_FREE_MB
reportado em V$ASM_DISKGROUP, você poderá usar métodos que reconfiguram o
grupo de discos uma célula por vez. Se o espaço livre for menor que
REQUIRED_MIRROR_FREE_MB, talvez seja preciso reorganizar o armazenamento para
aumentar esse espaço. Outra possibilidade, embora não recomendada, é reconfigurar o
armazenamento um disco por vez.
• As melhores práticas recomendam que todos os discos em um grupo de discos ASM le
tenham o mesmo tamanho e as mesmas características de desempenho. No caso do
fe rab
tra ns
Exadata, isso significa que todos os discos de grade alocados para um grupo de discos
devem ser do mesmo tamanho e ocupar a mesma região em cada disco. Não deve
n -
a no
haver uma mistura de discos de grade intercalados e não intercalados, nem de discos
de células de alta capacidade e de alto desempenho. Por fim, todos os discos de grade
devem ocupar o mesmo local em cada disco. a s
h eฺ
r )
ฺ Guid
b
• Se você tentar eliminar um disco de grade sem a opção FORCE, o comando não será
m
o ฺco dent
processado, e um erro será exibido se o disco de grade estiver sendo usado por um
grupo de discos ASM. Se você remover um disco de um grupo de discos ASM, verifique
k
t ei Stu
se a operação de rebalanceamento resultante foi concluída antes de tentar eliminar o
disco de grade associado.
o r te@ this
ฺ s up use
• Às vezes, parece não ser possível eliminar um disco de grade mesmo que ele tenha
( t ec se to
sido removido de todos os grupos de discos ASM. Nesse caso, talvez você queira usar
o comando DROP GRIDDISK com a opção FORCE. Use essa opção com extrema
i ko licen
cautela uma vez que a eliminação incorreta de um disco de grade ativo poderá resultar
e
o T
na perda de dados.
ic
ecn
• Se você tentar eliminar um disco de célula sem a opção FORCE, o comando não será
T processado, e um erro será exibido se o disco de célula contiver discos de grade. É
possível usar o comando DROP CELLDISK com a opção FORCE para eliminar um disco
de célula e todos os discos de grade associados. Use a opção FORCE com extrema
cautela uma vez que a eliminação incorreta de um disco de grade ativo poderá resultar
na perda de dados.
• Os arquivos de clusterware do Database (registro do cluster e discos de votação) são
armazenados, por default, em um grupo de discos ASM especial chamado DBFS_DG.
Geralmente, o redimensionamento do grupo de discos DBFS_DG não é recomendado,
pois os discos de grade associados a ele são dimensionados de acordo com o tamanho
das áreas do sistema nos dois primeiros discos de cada célula. Se for necessário
alterar esse grupo de discos, ou os discos de grade ou de célula subjacentes, tenha
cuidado para preservar os arquivos do clusterware.
• Embora seja possível reconfigurar o armazenamento do Exadata em um Database
Machine ativo sem qualquer período de indisponibilidade, esse procedimento poderá
ser demorado e envolver várias operações de rebalanceamento do ASM. O tempo
necessário dependerá do número de células de armazenamento, da utilização de disco
atual e da carga do sistema. A reconfiguração do armazenamento em um Database
Machine Full Rack poderá levar dois dias.

Tarefas de Configuração Opcionais
• Configurar a segurança do Exadata Storage Server

– Abordada na próxima parte desta lição

• Configurar o IORM (I/O Resource Management)
– Consulte a lição I/O Resource Management
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 c configuração opcionais podem ser executadas no Exadata Storage
Te tarefaslide
As seguintes
o
ic
ecn
Server:
T • Configurar a segurança do armazenamento do Exadata. A segurança do
armazenamento do Exadata é abordada na próxima parte desta lição.
• Configurar o IORM (I/O Resource Management). O IORM é abordado na lição I/O
Resource Management.

Visão Geral da Segurança do Armazenamento do
Exadata
Cluster ASM A
Modo de segurança
no escopo do Instâncias Instâncias

de banco de banco
ASM de dados de dados
não RAC do RAC
Disco de
le
rab
grade
fe
Célula do Exadata 1 Célula do Exadata 2
tra ns
n -
no a
a
h eฺs
Instâncias
b r )
Instâncias
ฺ banco GModo id de segurança
de banco m de u
de dados
k o ฺco ddedoedados nt no escopo do
não RAC
t ei ASMSBtu
Cluster
RAC
banco de dados
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
A segurança
o lic
Te do armazenamento do Exadata permite controlar quais clusters ASM e clientes
i c de dados podem acessar discos de grade específicos nas células de
denbanco
Tecarmazenamento. Ela garante que os pools de discos de grade sejam reservados para clusters
ou bancos de dados específicos.
• Para configurar a segurança de forma que todos os clientes de banco de dados de um
cluster ASM tenham acesso aos discos de grade especificados, configure a segurança
no escopo do ASM.
• Para configurar a segurança de modo que bancos de dados específicos tenham acesso
aos discos de grade especificados, configure a segurança no escopo do banco de dados.
Os dois conceitos estão ilustrados no slide. O cluster ASM A compartilha dois discos de grade
por célula com todos os seus clientes de banco de dados. O cluster ASM B compartilha um
disco de grade por célula para armazenar o banco de dados de instância única e outros dois
discos de grade (um por célula) para armazenar o banco de dados RAC. A segurança do
armazenamento do Exadata garante que nenhum dos clusters possa acessar os discos de
grade alocados para o outro cluster. Além disso, nenhum banco de dados do cluster B pode
acessar os discos de grade alocados para o outro banco de dados.
Observação: por default, nenhum desses modos de segurança é implementado durante a
configuração inicial de um Database Machine. Essa situação, na qual todos os clientes de
banco de dados podem acessar todos os discos de grade, é chamada de segurança aberta. A
segurança aberta não requer qualquer configuração e, desde que a rede e os hosts dos
bancos de dados estejam bem protegidos, você poderá usar esse modo para os seus bancos
de dados de produção. A segurança aberta também é útil para ambientes que não sejam de
produção, como os que hospedam bancos de dados de teste ou de desenvolvimento.

Implementação da Segurança do
Armazenamento do Exadata
Célula do
Exadata
Hosts do
cluster ASM
CREATE KEY A A
S S /etc/oracle/cell/network-config
M M
cellkey.ora
Cada
célula
ASSIGN KEY FOR
<ASM>='<KEY>'
le
Cada
fe rab
ns
banco
D
- tr a
de dados
Cada
CREATE/ALTER
GRIDDISK
B
no n
$ORACLE_HOME/admin/<db_unique_name>/pfile
disco availableTo=
cellkey.ora
s a Cada
'<ASM>'
) a
h CREATE/ALTER ฺ disco
D
Cada
célula b r
ฺ Gu GRIDDISK i d e
B
o m
CREATE KEY
k o ฺc deFOR
ASSIGN KEY
nt availableTo=
t i
e Stu <DB>='<KEY>'
'<ASM>,<DB>'
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Te brevemente
O slideodescreve as etapas para configurar a segurança no escopo do ASM e do
i c
n de dados. É importante perceber que você deve configurar a segurança no escopo do
banco
T e c
ASM primeiro se desejar configurar a segurança no escopo do banco de dados.
Para implementar a segurança no escopo do ASM, execute as etapas a seguir:
1. Faça shutdown das instâncias ASM e de banco de dados.
2. Gere uma chave de segurança usando o comando CellCLI CREATE KEY. Execute esse
comando somente uma vez em qualquer célula.
3. Use o comando ASSIGN KEY para designar a chave de segurança ao cluster
Oracle ASM em todas as células que ele deverá acessar. O nome do cluster ASM
é determinado pela definição do parâmetro de inicialização DB_UNIQUE_NAME.
4. Digite o nome do cluster Oracle ASM no atributo availableTo com o comando
CREATE GRIDDISK ou ALTER GRIDDISK para configurar a segurança nos discos de
grade de todas as células que o cluster Oracle ASM deverá acessar. Na conclusão
desta etapa, cada disco de grade terá uma associação com o cluster ASM que poderá
usar o disco.
5. Crie um arquivo cellkey.ora usando a chave de segurança gerada. Copie o arquivo
cellkey.ora para o diretório/etc/oracle/cell/network-config/ em cada
host do cluster ASM.
6. Reinicie as instâncias ASM e de banco de dados.

Depois de configurar e testar a segurança no escopo do ASM, você poderá configurar a
segurança no escopo do banco de dados. Execute as etapas a seguir para cada banco de
dados que você deseja configurar com esse tipo de segurança:
1. Faça shutdown das instâncias ASM e de banco de dados.
2. Gere uma chave de segurança usando o comando CellCLI CREATE KEY. Execute esse
comando somente uma vez em qualquer célula.
3. Use o comando ASSIGN KEY para designar a chave de segurança ao banco de dados
em todas as células que ele deverá acessar. O nome do banco de dados é determinado
pela definição do parâmetro de inicialização DB_UNIQUE_NAME.
4. Defina o atributo availableTo com o comando CREATE GRIDDISK ou ALTER
GRIDDISK para configurar a segurança em todos os discos de grade (em todas as
células) que o banco de dados deverá acessar. O atributo availableTo deve conter o
nome exclusivo da instância ASM e da instância de banco de dados que estão sendo
usadas, conforme mostrado no exemplo a seguir:
le
rab
alter griddisk DATA_CD_00_CELL01 availableTo='+ASM,dbm'
5. Na conclusão desta etapa, cada disco de grade terá uma associação com o cluster
s fe
ASM e com o banco de dados específico que tem permissão para usar o a
r n
disco.
6. Crie um arquivo cellkey.ora usando a chave de segurança gerada.
o n -t
Copie o arquivo cellkey.ora para o diretório a n
$ORACLE_HOME/admin/<db_unique_name>/pfile/aem
h s todos os hosts que
r ) d e ฺ
estiverem executando o banco de dados.
m b
ฺ Gu i
7. Reinicie as instâncias ASM e de banco de dados.
ฺ o
c ent
Observação: para obter mais informações, k o
i incluindoudexemplos e mais detalhes, consulte o
t eUser's S t
Oracle Exadata Storage Server Software
r t e @ his Guide 11g Release 2 (11.2).
u p o se t
e c ฺs to u
t
o ( ense
i k lic
o Te
ic
Tecn

Questionário
Os discos de grade estão visíveis no ASM por meio de uma

string de descoberta que começa com:

a. c/
b. o/
c. g/
d. e/
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
O primeiro disco de grade criado usa as faixas mais lentas do

disco físico correspondente:

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
Para criar um grupo de discos com os recursos de

armazenamento inteligente do Exadata ativados, quais

três atributos devem ser especificados?
a. compatible.rdbms
b. compatible.asm
c. au_size
d. disk_repair_time r a ble
n s fe
e. cell.smart_scan_capable 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, e lic
e c nic
T

Resumo

• Configurar o software do Exadata

• Criar e configurar grupos de discos ASM usando 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

Recursos Adicionais
– Configuração da Célula do Exadata

– Provisionamento do Armazenamento do Exadata
– Consumindo Discos de Grade do Exadata com o ASM
– Contas de Usuário da Célula do Exadata
– Usando o utilitário dcli (distributed command line)
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 Exadata
Nestes exercícios, você executará diversas tarefas de
configuração do Exadata, incluindo a configuração de células e

a reconfiguração do armazenamento. Você também consumirá
o armazenamento do Exadata usando o ASM, configurará
a segurança do armazenamento do Exadata, exercerá os
privilégios associados às diferentes contas de usuário de célula
e usará o utilitário dcli (distributed command line). 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
I/O Resource Management
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 usar o I/O

Resource Management do Exadata Storage Server para

gerenciar cargas de trabalho em um ou em vários bancos
de dados.
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 I/O Resource Management
• Benefícios tradicionais do armazenamento compartilhado:

– Custos de administração menores

– Uso mais eficiente do armazenamento
• Desafio comum do armazenamento compartilhado:
– As cargas de trabalho interferem entre si. Por exemplo:
— Consultas grandes afetam umas as outras
— As cargas de dados afetam consultas de data warehouse
a b le
As cargas de trabalho em lote interferem no desempenho do fe r
ans
—
OLTP
n - tr
• O I/O Resource Management do Exadata Storage no Server
permite controlar o uso de recursos de entrada/saída s a entre
h a ฺ
diferentes: ฺ b r) uide
– Tipos de usuários ฺ c om – nAplicações
t G
o e
– Tipos de cargas de trabalho t eik Stud– Bancos de dados
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k ic frequência, é compartilhado por diferentes cargas de trabalho, em
Te
O armazenamento,
o lcom
nic bancos de dados. O armazenamento compartilhado oferece alguns importantes
vários
ecbenefícios:
T • Quando um sistema de armazenamento é dedicado a um único banco de dados, o
administrador deve dimensionar esse sistema com base no tamanho e na carga de pico
antecipados do banco de dados. O equilíbrio correto dos recursos de armazenamento
quase nunca é obtido porque as cargas de trabalho reais são muito dinâmicas. Isso
leva a uma largura de banda de Entradas/ saídas e espaço não usados em alguns
sistemas, enquanto que outros sofrem com uma largura de banda e um espaço
insuficientes. Sharing facilitates more efficient usage of storage space and I/O
bandwidth.
• Ele diminui os custos de administração, reduzindo o número de sistemas de
armazenamento.
No entanto, o armazenamento compartilhado não é uma solução perfeita. A execução de
vários tipos de cargas de trabalho e bancos de dados em armazenamento compartilhado,
em geral, causam problemas de desempenho. Por exemplo, consultas paralelas grandes
em um data warehouse de produção podem afetar o desempenho de consultas críticas em
outro data warehouse de produção. Além disso, uma carga de dados em um data warehouse
pode afetar o desempenho de consultas críticas que também estejam em execução nele.
É possível mitigar esses problemas com o provisionamento excedente do sistema de
armazenamento, mas isso diminui as economias do armazenamento compartilhado. Você
também pode evitar a execução de tarefas não críticas em horas de pico, mas a execução
dessa tarefa manualmente é trabalhosa. Quando bancos de dados têm administradores
diferentes, que não coordenam suas atividades, a tarefa é ainda mais difícil.
O IORM (I/O Resource Management) do Exadata Storage Server permite que cargas de
trabalho e bancos de dados compartilhem recursos de entrada/saída de forma automática,
de acordo com as políticas definidas pelo usuário. Para gerenciar cargas de trabalho em
um banco de dados, você pode definir planos de recursos dentro do mesmo banco de
dados, usando o DBRM (Database Resource Manager), que foi aperfeiçoado para operar
em conjunto com o Exadata Storage Server. Para gerenciar cargas de trabalho em vários
bancos de dados, é possível definir planos do IORM.
Por exemplo, se um banco de dados de produção e um de teste estiverem compartilhando

uma célula do Exadata, você poderá configurar planos de recursos que priorizem o banco
de dados de produção. Nesse caso, sempre que a carga do banco de dados de teste afetar
o desempenho do banco de dados de produção, o IORM programará as solicitações de
entrada/saída de forma que o desempenho da entrada/saída do banco de dados de produção
não seja afetado. Isso significa que as solicitações de entrada/saída do banco de dados de
teste são colocadas na fila até que elas possam ser emitidas sem afetar o desempenho das
le
rab
entradas/saídas do banco de dados de produção.
fe
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

Conceitos do I/O Resource Management
Banco de dados A Banco de dados B

Grupo de Grupo de
consumidores consumidores
Finance
Categoria OnlineQuery
Interactive
le
rab
Grupo de Grupo de
consumidores fe
HR
consumidores
tra ns
BatchQuery
n -
no a
a
h deeฺs
Grupo de
Categoria b r )
Grupo
ฺconsumidores id
consumidores m G u
ฺco dent ETL
Batch
Reporting o
t k
ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
e bancolide c dados tem muitos tipos de cargas de trabalho. Essas cargas podem
Em geral,Tum
o
e c nic nos requisitos de desempenho e na quantidade de entradas/saídas que elas emitem. Os
diferir
grupos de consumidores de recursos oferecem uma forma de agrupar sessões que
T compreendem uma carga de trabalho específica. Por exemplo, se o banco de dados estiver
executando quatro aplicações diferentes, você poderá criar quatro grupos de consumidores,
um para cada aplicação. Como alternativa, se o seu data warehouse tiver três tipos de cargas
de trabalho, como consultas críticas e normais e ETL (extração, transformação e
carregamento), você poderá criar um grupo de consumidores para cada tipo de carga de
trabalho. Depois de criar os grupos de consumidores, você deverá criar regras que
especifiquem como as sessões são mapeadas para eles.
O plano de recursos do banco de dados ou o plano de recursos dentro do mesmo banco de
dados, especifica como os recursos são alocados entre os grupos de consumidores em um
banco de dados. Um banco de dados pode ter vários planos de recursos, no entanto, somente
um plano pode estar ativo em qualquer ponto no tempo. Isso permite que o gerenciamento de
recursos do banco de dados atenda a diferentes requisitos associados a períodos distintos.
O IORM do Exadata Storage Server amplia o conceito de grupo de consumidores usando
categorias. Embora os grupos de consumidores representem conjuntos de usuários dentro de
um banco de dados, as categorias representam conjuntos de grupos de consumidores dentro
de todos os bancos de dados. O diagrama exibido no slide mostra um exemplo de duas
categorias que contêm grupos de consumidores em dois bancos de dados. É possível
gerenciar recursos de entradas/saídas com base em categorias, criando um plano de
categoria. Por exemplo, você pode especificar uma precedência para grupos de consumidores
na categoria Interactive sobre os grupos na categoria Batch para todos os bancos de
dados que compartilham uma célula do Exadata.
Planos do I/O Resource Management
I/O
Resource
Management
Dentro de Entre vários
um banco bancos de
de dados dados
le
fe rab
a ns
Plano de Recursos Plano de Recursos de-tr
Plano n
Dentro do Mesmo entre Diferentes no da
Recursos
a
Banco de Dados Bancos de Dados as Categoria
) h eฺ
b r
ฺ doGIORM u id
m
Plano
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
e diferentes lic abordagens para o gerenciamento de alocações de recursos.
O IORM T
permite
o
nicabordagem pode ser usada de forma independente ou em conjunto com outras
Cada
ecabordagens.
T O gerenciamento de recursos do banco de dados permite que você gerencie cargas de
trabalho dentro de um banco de dados. O gerenciamento de recursos do banco de dados é
configurado dentro de cada banco de dados, usando o Database Resource Manager para
criar um plano de recursos dentro de um mesmo banco de dados. Você deve usar esse
recurso se tiver vários tipos de cargas de trabalho dentro de um banco de dados e precisar
definir uma política para especificar como essas cargas compartilham a alocação dos
recursos do banco de dados. Se apenas um banco de dados estiver usando o Exadata, esse
será o único recurso do IORM necessário.
O gerenciamento de recursos entre diferentes bancos de dados é gerenciado com um plano
de diferentes bancos de dados. Um plano como esse especifica como os recursos são
alocados entre vários bancos de dados para cada célula. As diretivas em um plano de
recursos de diferentes bancos de dados especificam alocações a bancos de dados em vez
de grupos de consumidores.
O gerenciamento de recursos de categoria é um recurso avançado. É útil quando o Exadata
está hospedando vários bancos de dados e você deseja alocar recursos principalmente pela
categoria do trabalho que estiver sendo feito. Por exemplo, suponha que todos os bancos de
dados tenham três categorias de cargas de trabalho: OLTP, relatórios e manutenção. Para
alocar os recursos de entrada/saída com base nessas categorias de carga de trabalho, você
usaria o gerenciamento de recursos de categoria.
Tanto o plano entre diferentes bancos de dados como o plano de categoria são definidos em
um objeto de célula conhecido como plano do IORM.
Exemplo de Planos do I/O Resource Management
Banco de Banco de
Dados A Dados B
(Inst. Única) (RAC)
Plano de Recursos no Plano de Recursos Dentro do
mesmo Banco de Dados A Mesmo Banco de Dados B

(DBMS_RESOURCE_MANAGER) (DBMS_RESOURCE_MANAGER)
Grupo de consumidores 1: 15% Grupo de consumidores 5: 22%

Grupo de consumidores 4: 40% Distribuição Grupo de consumidores 8: 45%
controlada de
entrada/saída
le
fe rab
… tr ans
Disco Disco
n -
noa
Plano do BD A Plano do BD B
a
h eฺ s
Plano de Recursos entre
b r ) idPlano de Categoria
Plano do IORM ฺ u
Diferentes Bancos de Dados m G
ฺco dent
(CellCLI)
(CellCLI)
i k o u
INTERACTIVE : 60%
Banco de Dados A : 70%
t e S t BATCH : 40%
Banco de Dados B : 30%
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Para cada
c é possível usar o DBRM para criar um plano de recursos no
Tebanco delidados,
o
e c nic banco de dados. Quando você define um plano de recursos no mesmo banco de
mesmo
T dados, uma descrição do plano é enviada automaticamente a cada célula. No exemplo do
slide, os Bancos de Dados A e B têm planos separados. Observe também que cada grupo
de consumidores em cada plano de recursos no mesmo banco de dados é associada com
a categoria INTERACTIVE ou BATCH.
Em cada célula, um plano de recursos entre diferentes bancos de dados pode ser
configurado e ativado. No exemplo do slide, o plano de recursos entre bancos de dados
é configurado com uma alocação de recursos maior para o Banco de dados A (70%) do
que para o Banco de dados B (30%).
Também dentro de cada célula, você pode categorizar grupos de consumidores de
diferentes bancos de dados e distribuir recursos de entradas/saídas de acordo com as
várias categorias. No exemplo do slide, é alocada à categoria INTERACTIVE (60%) um
compartilhamento de recursos maior do que à categoria BATCH (40%).

Exemplo de Planos do I/O Resource Management
Banco de dados A Banco de dados B Banco de dados A Banco de dados B

Alocação do CG1 CG2 CG5 CG6 CG3 CG4 CG7 CG8
IORM 16,8% 11,2% 6,6% 5,4% 19,6% 22,4% 4,5% 13,5%
Dentro do mesmo banco de dados

15%
18%
35%
15%
45%
10%
22%
40%
Entre diferentes bancos de dados
30%
70%
30%
70%
le
fe rab
Categorias
trans
40% 60% no n -
s a
) a
hINTERACTIVE ฺ
BATCH
b
ฺ Gur i d e
Todas as
o m
k o ฺc dent
entradas/saídas
t ei do(100%) tu
Usuário
S
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Tde
Os planos
o lic entre diferentes bancos de dados e no mesmo banco de dados são
e categoria,
e c nic em conjunto pelo Exadata para alocar recursos de entrada/saída.
usados
T O plano de categoria primeiro é usado para alocar recursos entre as categorias. Quando
uma categoria é selecionada, o plano de recursos entre diferentes bancos de dados é usado
para selecionar um banco de dados; somente bancos de dados que tenham grupos de
consumidores com a categoria selecionada podem ser escolhidos. Finalmente, o plano de
recursos no mesmo banco de dados do banco selecionado é usado para selecionar um dos
seus grupos de consumidores. A porcentagem de alocação de recursos representa a
probabilidade de fazer uma seleção em cada nível.
Expressando isso como uma fórmula:
Pcgn = cgn / sum(catcgs) * db% * cat%
em que:
• Pcgn é a probabilidade de selecionar um grupo de consumidores n
• cgn é a alocação de recursos para o grupo de consumidores n
• sum(catcgs) é a soma das alocações de recursos para todos os grupos de
consumidores na mesma categoria que o grupo de consumidores n e no mesmo
banco de dados que o grupo de consumidores n
• db% é a porcentagem de alocação do banco de dados no plano de recursos entre
diferentes bancos de dados
• cat% é a porcentagem de alocação da categoria no plano de categoria
A hierarquia usada para distribuir entradas/saídas é ilustrada no slide. O exemplo é uma
continuação do slide anterior, mas os nomes dos grupos de consumidores são abreviados
para CG1, CG2 etc.
Observe que, embora cada alocação de grupo de consumidores seja expressa como uma
porcentagem dentro de cada banco de dados, o IORM leva em conta a relação das
alocações dentro de cada categoria e banco de dados. Por exemplo, o CG1 recebe
nominalmente 16,8% dos recursos de entrada/saída do IORM (15/(15+10)*70%*40%); no
entanto, isso não será alterado caso as alocações do plano de recursos no mesmo banco de
dados para os grupos CG1 e CG2 forem dobradas para 30% e 20%, respectivamente. Isso
ocorre porque a alocação para o CG1 permanece 50% maior do que a alocação para o CG2.
Esse comportamento também explica por que o CG1 (16,8%) e o CG3 (19,6%) têm uma
alocação similar por meio do IORM, embora o CG3 pertença à categoria de prioridade mais
alta (60% versus 40%) e tenha uma alocação no mesmo banco de dados muito maior (35%
versus 15%).
le
Observação: as entradas/saídas do ASM (para rebalanceamento etc.) e as entradas/saídas
fe rab
emitidas pelos processos em background Oracle são processadas separadamente e de
tra ns
forma automática pelo Exadata. Para fins de clareza, as entradas/saídas em background não
n -
são mostradas no exemplo.
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 IORM
Banco de CELLSRV
Célula do Exadata
Banco de dados A
dados A Banco de dados A

Fila CG1
Banco de dados A
Fila CG1
O banco de Banco de dados A
Fila CG1
Fila CG2
dados envia Fila CG1
Fila CG2
solicitações de … Fila CG2
entrada/saída … Fila CG2
às células. …
Fila CGn …
Fila FilaCGn
Marca de solicitação Fila CGn
Filas BG
CGn
de entrada/saída:
- Nome do banco …
Filas BG
Banco de…
Filas BG
le
rab
de dados dados
FilasZBG
Banco de…dados Z
- Tipo Fila CG1
fe
ns
Banco
Fila CG1de dados Z
- Grupo de
consumidores
Banco
Fila CG1
Fila CG2
de dados Z
Fila CG1 IORM
- tr a
…
Fila CG2
…
Fila CG2
Fila CG2
Fila de discos
no n
Disco de célula
…
Fila CGn … s a
Fila Fila ) a
hEstatísticaseฺ
Fila
CGn
CGn
CGn b r
ฺ deGdesempenho
u id
Filas BG
m
Banco de
Filas BG
Filas BG
k o ฺco dent
Planos de
recursos
dados Z Filas BG
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
O IORM gerencia
i k
e os recursos
l ic de entrada/saída do Exadata em cada célula, programando as
o T
n c de entrada/saída
solicitações
iprograma recebidas de acordo com os planos de recursos configurados. O
c
IORM as entradas/saídas selecionando solicitações de diferentes filas CELLSRV. Os
e de recursos são usados para determinar a ordem na qual as solicitações de
Tplanos
entradas/saídas em fila são emitidas para o disco. Por default, o objetivo do IORM é utilizar
integralmente os recursos de disco disponíveis. Qualquer alocação que não seja utilizada
integralmente é colocada à disposição para outras cargas de trabalho, proporcionalmente aos
planos de recursos configurados.
O IORM intervém somente quando necessário. Por exemplo, o IORM não interferirá se houver
somente um grupo de consumidores ativo em um banco de dados porque não há possibilidade de
disputa com outro grupo ou banco de dados.
As entradas/saídas em background são programadas com base na sua prioridade relativa às
entradas/saídas do usuário. Por exemplo, as gravações de redo e as entradas/saídas do arquivo
de controle são críticas ao desempenho e são sempre priorizadas sobre todas as entradas/saídas
do usuário. As gravações feitas pelo processo do database writer (DBWn) são programadas no
mesmo nível de prioridade que as entradas/saídas do usuário.
O diagrama contido no slide ilustra a implementação de alto nível do IORM. Para cada disco de
célula baseado em disco, cada banco de dados que acessa a célula tem uma fila de entrada/saída
por grupo de consumidores e três filas de entradas/saída em background. As filas de
entrada/saída em background correspondem a solicitações de alta, média e baixa prioridade com
diferentes tipos de entradas/saídas mapeadas para cada fila. Se você não definir um plano de
recursos no mesmo banco de dados, todas as solicitações de entrada/saída que não sejam em
background são agrupadas em um único grupo de consumidores denominado OTHER_GROUPS.
O IORM gerencia somente as filas de entrada/saída nos discos físicos. Ele não gerencia
solicitações para discos de grade baseados em flash nem solicitações atendidas pelo Exadata
Smart Flash Cache.
Introdução ao IORM
CellCLI> list iormplan detail

name: cell01_IORMPLAN
catPlan:
dbPlan:
objective: off
status: active
CellCLI> alter iormplan objective='balanced'

IORMPLAN successfully altered
le
rab
CellCLI> list iormplan detail
name: cell01_IORMPLAN
fe
catPlan:
tra ns
dbPlan:
n -
objective:
status:
balanced
active 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 que controlam
As definições o IORM estão contidas em um objeto IORMPLANem cada célula
i c
donExadata. O objeto IORMPLAN é criado automaticamente quando a célula é configurada.
Tec Ele não pode ser eliminado nem criado novamente.
Inicialmente, o plano do IORM de cada célula é configurado da seguinte maneira:
• O plano do IORM tem um nome no formato <cell name>_IORMPLAN.
• Os atributos catPlan e dbPlan estão vazios. Esses atributos definem o plano de
gerenciamento de recursos de entrada/saída entre diferentes bancos de dados e o
plano de gerenciamento de recursos de entrada/saída de categoria. Detalhes sobre
esses planos são fornecidos mais adiante nesta lição.
• O objetivo do plano do IORM é definido como off, o que interrompe o gerenciamento
de recursos de entrada/saída pelo IORM.
• O status do plano do IORM é definido como active.
Para que os recursos de entrada/saída possam ser gerenciados pelo IORM, é necessário
que o plano do IORM esteja ativo e que o seu objetivo esteja definido como um valor
diferente de off.
Se o status desse plano estiver definido como inativo, ele poderá ser ativado com o
comando:
CellCLI> alter iormplan active
O exemplo do slide mostra a alteração de uma configuração default do IORM para definir o
objetivo do seu plano. As definições de objetivo disponíveis são descritas no próximo slide.
Definindo o Objetivo do IORM
• Definições de objetivo do IORM disponíveis:
– off
Definição default; o IORM não gerencia os recursos de entrada/saída
– low_latency
— Minimiza a latência limitando o número de solicitações de entrada/saída
concorrentes
— Útil para cargas de trabalho OLTP críticas
— O desempenho de cargas de trabalho com throughput elevado pode ser
afetado
– high_throughput
Maximiza o throughput não limitando as solicitações de entrada/saída le
rab
—
concorrentes
fe
— Útil para cargas de trabalho de data warehouses e DSS
tr a ns
—
n -
O desempenho de cargas de trabalho críticas em termos de latência pode ser
afetado no a
– balanced
a s
h e throughput
Mantém o equilíbrio entre baixa latência de rdisco ) d e ฺ elevado
—
Útil para cargas de trabalho mistas mฺ

b u i
—
o t G
– auto
i k oฺc uden
— O IORM escolhe a melhor
@ tedefinição
S tde objetivo com base nos planos e nas
cargas de trabalhoeativos
r t t hi s
o
p us
uOracle e
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Tede objetivo
A definição
o lic do IORM controla como as solicitações de entrada/saída física são
nic é necessário
enviadas
ecfazem,
para o disco pelo IORM. Para compreender as diferentes definições e o que elas
primeiro entender como um disco atende às solicitações de
T entrada/saída.
O maior custo envolvido no atendimento de uma solicitação de entrada/saída diz respeito ao
posicionamento do cabeçote do disco no local certo para executar a operação de
entrada/saída. Portanto, uma unidade de disco mantém um buffer de solicitações de
entrada/saída concorrentes que é usado para otimizar o seu atendimento. Se o buffer for
grande, a oportunidade de otimizar as entradas/saídas será maior. Nesse caso, o throughput
geral do disco será maximizado; entretanto, a latência referente a determinada solicitação
poderá ser maior uma vez que outras entradas/saídas poderão ser atendidas durante o
percurso. Se o buffer for pequeno, as entradas/saídas serão atendidas de maneira mais
sequencial. Nesse caso, a latência será reduzida uma vez que um menor número de
entradas/saídas concorrentes será atendido; entretanto, o throughput geral também será
reduzido uma vez que o fluxo de solicitações será menos otimizado.
O IORM permite que os administradores do Exadata controlem o objetivo do IORM de modo
que o desempenho de entrada/saída seja otimizado de acordo com as características das
cargas de trabalho e os requisitos de negócios. O slide lista as definições disponíveis e
descreve as características de cada uma.
No caso do objetivo auto, o IORM analisa continuamente a carga de trabalho de
entrada/saída e os planos ativos do IORM para escolher a definição de objetivo apropriada.
Por exemplo, se a maior parte dos recursos de entrada/saída for alocada para determinado
banco de dados, e ele estiver executando uma carga de trabalho OLTP, a definição
low_latency será automaticamente utilizada.
Ativando o Gerenciamento de Recursos Dentro
do Mesmo Banco de Dados
• É possível ativar o gerenciamento de recursos dentro do mesmo
banco de dados:
– Manualmente:
— Defina o parâmetro RESOURCE_MANAGER_PLAN do banco de dados.
– Automaticamente:
— Crie uma janela do job scheduler.
— Associe um plano de recursos à janela.
• O Exadata Storage Server é notificado quando um plano de recursos le
b
dentro do mesmo banco de dados é definido ou modificado: era f
ans
– Plano ativado ou modificado enviado a cada célula usando iDB
tr
• É necessário ativar o IORMPLAN em todas as célulasodo
n n-Exadata.
• a do mesmo
A seguir, são mostrados os planos de recursossdentro
a
banco de dados mais usados:
ฺb r) h eฺ id
– mixed_workload_plan m
ฺco dent Gu
– dss_plan k o
tei Stu
– default_maintenance_plan
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
e recursos licdentro do mesmo banco de dados pode ser ativado manualmente com
Um plano
o Tde
on
c ic
parâmetro de inicialização RESOURCE_MANAGER_PLAN ou automaticamente, usando o job
T e scheduler.
Quando você define um plano de recursos dentro do mesmo banco de dados, uma descrição
do plano é enviada automaticamente a cada célula. Quando uma nova célula é adicionada
ou uma célula existente é reiniciada, o plano de recursos dentro do mesmo banco de dados
atual é enviado automaticamente às células. Esse plano de recursos é usado para gerenciar
recursos no servidor de banco de dados e nas células.
Para que o IORM possa ser usado, é necessário ativar o IORMPLAN em todas as células
correspondentes do Exadata.
O Oracle Database fornece vários planos predefinidos de recursos dentro do mesmo banco
de dados. Os usados com mais frequência são mixed_workload_plan, dss_plan e
default_maintenance_plan.
Os planos de recursos dentro do mesmo banco de dados não contêm uma diretiva para
atividade de entrada/saída em background. As entradas/saídas em background são
programadas com base na sua prioridade relativa às entradas/saídas do usuário. Por
exemplo, as gravações de redo e as leituras de arquivo de controle são críticas ao
desempenho e são sempre priorizadas em relação a todas as entradas/saídas do usuário.
Observação: No caso de bancos de dados Oracle RAC no Database Machine, todas as
instâncias do RAC devem ser definidas para usar o mesmo plano de recursos.
Exemplo de Plano de Recursos
Dentro do Mesmo Banco de Dados
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'my_plan',

CONSUMER_GROUP1 => 'high_priority', GROUP1_PERCENT => 80,
CONSUMER_GROUP2 => 'low_priority' , GROUP2_PERCENT => 20);
END;
/
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'my_plan';
le
fe rab
ns
Grupo de Nível 1 Nível 2 Nível 3
O plano é enviado
Consumidores
tra
Porcentagens
-
diretamente às SYS_GROUP 100%
no n
são usadas para a
células do Exadata HIGH_PRIORITY 80%
s a
CPU e para os recursos
por meio de iDB. LOW_PRIORITY 20%
) a
h eฺ
de entrada/saída.
OTHER_GROUP b
ฺ G r 100% id
u
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 entrada/saída dentro do mesmo banco de dados especifica como os
O plano
o Terecursoslide
de
ic de entrada/saída são alocados entre os grupos de consumidores em um banco de
ecn
recursos
T dados específico.
Um plano de recursos de entrada/saída dentro do mesmo banco de dados é criado com os
procedures contidos no pacote PL/SQL DBMS_RESOURCE_MANAGER. Não há parâmetros
nem procedures de recursos de entrada/saída específicos. É criado um plano de recursos de
entrada/saída dentro do mesmo banco de dados exatamente da mesma forma que se criaria
um plano de recursos de CPU. Quando você especifica um percentual de alocação, esse
percentual se aplica tanto à CPU do servidor de banco de dados como aos recursos de
entrada/saída do Exadata Storage Server. Não há definições de entrada/saída específicas
porque, em geral, você é limitado pela CPU ou pela entrada/saída, mas não por ambas ao
mesmo tempo.
O exemplo do slide usa o procedure CREATE_SIMPLE_PLAN para criar o MY_PLAN. Esse
plano de recursos é usado para gerenciar recursos da CPU no nível do banco de dados e os
recursos de entrada/saída no nível da célula do Exadata.
Observe que o atributo MAX_UTILIZATION_LIMIT também pode ser usado para especificar
o limite máximo de utilização de CPU e de entrada/saída dos grupos de consumidores. Esse
atributo pode ser definido com o uso do procedure
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE.

Ativando o IORM para Vários Bancos de Dados
• Ative o IORM para vários bancos de dados configurando um

IORMPLAN:
– O plano de categoria designa recursos de entrada/saída usando

categorias
– O plano de recursos entre diferentes bancos de dados designa
recursos de entrada/saída usando nomes de bancos de dados
– Todas as combinações são possíveis
• Use o utilitário CellCLI para definir e ativar o IORMPLAN em
cada célula r a ble
• Configure o mesmo IORMPLAN em cada célula n s fe
n ra
-tuma
• Somente um IORMPLAN pode estar ativo por vez o em
célula a n
• As definições do IORMPLAN são persistentes ) h as emฺ todas as
m ฺ br uide
reinicializações da célula
o ฺ co ent G
• Todos os bancos de dados
t e ikobtêmt u d
alocações iguais na
e@ is S
ausência de um IORMPLAN
o rt e th
p s empresas afiliadas. Todos os direitos reservados.
suOracletoe/ouusuas
c ฺ
Copyright © 2012,
o (te nse
T eik delirecursos
O gerenciamento
ce de entrada/saída para vários bancos de dados é configurado
n
com i cooIORMPLAN. O IORMPLAN especifica como os recursos de entrada/saída são alocados
Tec para cada célula.
O IORMPLAN contém um plano de recursos entre diferentes bancos de dados, também
chamado de plano de BD, e um plano de categoria. As diretivas do plano de BD especificam
as alocações de recursos de entrada/saída para nomes de bancos de dados em vez de
grupos de consumidores. As diretivas do plano de categoria especificam as alocações de
recursos de entrada/saída para categorias em vez de para bancos de dados ou grupos de
consumidores. O IORMPLAN é configurado e ativado com o CellCLI em cada célula. Somente
um IORMPLAN pode estar ativo por vez em uma célula.
Na inicialização, o IORMPLAN é uma string vazia, que efetivamente desativa o IORM. Nesse
caso, todos os bancos de dados recebem uma alocação igual.
O IORMPLAN deve ser ativado para que o gerenciamento de recursos de entrada/saída
ocorra. Quando o IORMPLAN está desativado, o IORM não gerenciará recursos de
entrada/saída, mesmo se um plano de recursos dentro do mesmo banco de dados seja
definido ou um IORMPLAN seja configurado.

Exemplo de Plano de Recursos entre
Diferentes Bancos de Dados
CellCLI> alter iormplan -

> dbplan=((name=sales_prod, level=1, allocation=80), -
> (name=finance_prod, level=1, allocation=20), -
> (name=sales_dev, level=2, allocation=100), -
> (name=sales_test, level=3, allocation=50), -
> (name=other, level=3, allocation=50)), -
> catplan=''
le
fe rab
Banco de Dados Nível 1 Nível 2 Nível 3
tr a ns
sales_prod 80% n -
finance_prod 20%
no a
a
h eฺ s
sales_dev 100% r
ฺ Guid
b )
m
sales_test
k o ฺco dent 50%
outro t ei Stu 50%
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Em cada o lic
e do Exadata,
Tcélula um plano de recursos entre diferentes bancos de dados
n i c
especifica como os recursos são divididos entre vários bancos de dados. As diretivas em um
T e c
plano de recursos de diferentes bancos de dados especificam alocações a bancos de dados
em vez de grupos de consumidores. O plano de recursos entre diferentes bancos de dados é
configurado e ativado com o CellCLI em cada célula.
O exemplo acima implementa um plano de recursos entre diferentes bancos de dados
seguindo as diretivas mostradas na tabela.
O plano de recursos entre diferentes bancos de dados é criado especificando-se a parte
DBPLAN do IORMPLAN. Esse plano é semelhante a um plano de recursos dentro do mesmo
banco de dados uma vez que cada diretiva pode especificar um level de 1 a 8 e um valor
de allocation em termos percentuais. Para um determinado plano, todas as alocações em
qualquer nível devem somar 100 ou menos. Um plano de recursos entre diferentes bancos
de dados difere de um plano de recursos dentro do mesmo banco de dados porque não
contém subplanos, mas só diretivas de recursos de entrada/saída.
Como melhor prática, você deve criar uma diretiva para cada banco de dados usando a
mesma célula do Exadata. Para garantir que qualquer banco de dados sem uma diretiva
explícita possa ser gerenciado, é necessário criar uma alocação denominada OTHER.
É possível remover um plano de recursos entre diferentes bancos de dados usando:
ALTER IORMPLAN dbplan=''

Definindo Limites de Utilização de Entrada/Saída
do Banco de Dados

> dbplan=((name=db1, level=1, allocation=50, limit=75), -
> (name=db2, level=1, allocation=30, limit=75), -
> (name=db3, level=1, allocation=20, limit=50), -
le
> (name=other, level=2, allocation=100)), -
fe rab
> catplan=''
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 de plano entre diferentes bancos de dados que usa o atributo
Te um exemplo
O slideocontém
e c nic
limit.
T Por default, o objetivo do IORM é utilizar integralmente os recursos de disco disponíveis.
Qualquer alocação que não seja plenamente utilizada é disponibilizada para outras cargas
de trabalho. O atributo limit modifica esse comportamento especificando o limite superior
absoluto de consumo de recursos de entrada/saída permitido para um banco de dados.
Isso é útil nas situações em que se deseja obter um desempenho mais consistente de
entrada/saída, em vez de maximizar a utilização de recursos de entrada/saída.
O atributo limit só pode ser especificado para diretivas de planos entre diferentes bancos
de dados. Ele especifica o limite de utilização de entrada/saída de um banco de dados em
termos percentuais. Se o atributo limit for usado, o valor associado deverá ser maior que
zero e menor ou igual a 100.
Observe que, no caso de diretivas de plano entre diferentes bancos de dados, pelo menos
uma definição dos atributos level, allocation ou limit deverá ser especificada, além
do valor de name. Por exemplo, name e limit ou name e level são combinações válidas
de atributos.

Planos entre Diferentes Bancos de Dados e
Atribuições de Banco de Dados

> dbplan=((name=sales1, level=1, allocation=30, role=primary), -
> (name=sales2, level=1, allocation=35, role=primary), -
> (name=sales1, level=2, allocation=20, role=standby), -
le
rab
> (name=sales2, level=2, allocation=25, role=standby), -
> (name=other, level=3, allocation=50)),
fe-
> catplan=''
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 de plano entre diferentes bancos de dados que usa o atributo
Te um exemplo
O slideocontém
e c nic
role.
T O atributo role indica que a diretiva é aplicada somente quando o banco de dado está
na atribuição de banco de dados em questão. Isso oferece a flexibilidade para ajustar, de
forma automática, o plano do IORM de acordo com a atribuição do banco de dados em um
ambiente do Oracle Data Guard. Se o atributo role não for especificado, a diretiva será
aplicada, independentemente da atribuição do banco de dados.
O atributo role só pode ser especificado para diretivas de planos entre diferentes bancos de
dados. Entretanto, o atributo role não pode ser especificado para a diretiva OTHER.

Exemplo de Plano de Categoria
DBA_RSRC_CONSUMER_GROUPS
CONSUMER_GROUP CATEGORY
---------------------------- --------------- DBMS_RESOURCE_MANAGER.CREATE_CATEGORY

SYS_GROUP ADMINISTRATIVE
BATCH_GROUP BATCH
INTERACTIVE_GROUP INTERACTIVE
ORA$… MAINTENANCE
OTHER_GROUPS OTHER
Categoria Nível 1 Nível 2 Nível 3
DEFAULT_CONSUMER_GROUP OTHER
LOW_GROUP OTHER Interactive 90%
AUTO_TASK_CONSUMER_GROUP OTHER
Batch 80%
ab le
Maintenance 50%fer
Outros tr ns
a 50%
> dbplan= '' -
n -
> catplan=( - no a
> (name=interactive, level=1, allocation=90),
h a s -
> (name=batch, level=2, allocation=80),
r) uide - ฺ -
> ฺ b
(name=maintenance, level=3, allocation=50),
>
ฺ c om nt G
(name=other, level=3, allocation=50) -
o e
eik Stud
> )
t
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licManager permite a você especificar uma categoria para cada grupo de
TeResource
O Database
o
nic no slide.AsEssa
consumidores.
eclistados
categorias predefinidas e seus grupos de consumidores associados estão
é a situação default após a criação de um banco de dados.
T Se decidir usar essas categorias default, você deverá mapear todos os grupos de
consumidores administrativos em todos os bancos de dados para a categoria
ADMINISTRATIVE. Todas as atividades de alta prioridade do usuário, como grupos de
consumidores para transações importantes de processamento de transações on-line (OLTP)
e relatórios em que o tempo é crucial, devem ser mapeadas para a categoria INTERACTIVE.
Todas as atividades de baixa prioridade do usuário, como relatórios, manutenção e transação
OLTP de baixa prioridade, devem ser mapeadas para as categorias BATCH, MAINTENANCE e
OTHER.
Você pode criar suas próprias categorias usando o procedure CREATE_CATEGORY do pacote
DBMS_RESOURCE_MANAGER e, em seguida, designar sua categoria a um grupo de
consumidores usando os procedures CREATE_CONSUMER_GROUP ou
UPDATE_CONSUMER_GROUP.
Em seguida, é possível gerenciar recursos de entradas/saídas com base em categorias,
criando um plano de categoria. O exemplo mostrado no slide implementa um plano de
categoria com base nas alocações descritas na tabela. Com esse plano, os grupos de
consumidores associados à categoria INTERACTIVE obtêm até 90% dos recursos de
entradas/saídas. 80% do restante, incluindo a alocação não utilizada da categoria
INTERACTIVE, são alocados à categoria BATCH. As categorias MAINTENANCE e OTHER
compartilham o restante.
Qualquer grupo de consumidores sem uma categoria especificada de forma explícita tem, por
default, a categoria OTHER.
Usando Métricas de Entrada/Saída de
Banco de Dados
• Há métricas separadas para entradas/saídas pequenas
(≼ 128 KB) e grandes

• É possível monitorar o IORM para compreender o consumo
de recursos e fazer os ajustes necessários
– Qual banco de dados tem a carga mais pesada?
— Procure os valores DB_IO_RQ_SM + DB_IO_RQ_LG mais altos.
– Qual banco de dados foi mais otimizado?
le
— Procure os valores DB_IO_WT_SM + DB_IO_WT_LG mais altos.
fe rab
tr a ns
Nome Descrição
n -
DB_IO_RQ_SM no a
Número total de solicitações de entrada/saída emitidas pelo banco de
DB_IO_RQ_LG a s
dados desde que qualquer plano de recursos foi definido
h por segundo
Solicitações de entrada/saídab r ) d e ฺ pelo banco de
DB_IO_RQ_SM_SEC
dados no último minuto m
ฺ Gu
emitidas i
DB_IO_RQ_LG_SEC
o
ฺc dqueenastsolicitações de entrada/saída
DB_IO_WT_SM Número total de k o
i detdados
segundos
u aguardaram para serem programadas
t
emitidas pelo ebanco S
DB_IO_WT_LG
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
O ExadataT ic fornece três grupos de métricas de entrada/saída que correspondem
eStorage lServer
aosic o
três tipos de planos do IORM: métricas de categoria, de banco de dados e de grupo de
c n
consumidores. As métricas de entrada/saída permitem que você entenda o consumo de
Te entrada/saída e faça ajustes para otimizar o desempenho e a utilização de recursos.
Para cada métrica de entrada/saída, é feita uma distinção entre entradas/saídas pequenas, em
geral, associadas a aplicações OLTP, e entradas/saídas grandes, que, normalmente, indicam
cargas de trabalho DSS. Os nomes de métricas de entrada/saída incluem _SM ou _LG para
identificar entradas/saídas pequenas e grandes, respectivamente.
Para métricas de banco de dados, o atributo objectType é definido como IORM_DATABASE.
A tabela contida no slide fornece uma rápida descrição de algumas métricas importantes de
entrada/saída de banco de dados. Um conjunto separado de observações de métricas está
disponível para cada banco de dados especificado no plano do IORM. As observações de
métrica para diferentes bancos de dados são diferenciadas pelo nome do banco de dados, que
é definido no atributo metricObjectName. É possível comparar as métricas entre bancos de
dados para determinar qual tem a carga mais pesada ou qual foi mais otimizado, conforme
ilustrado no slide. Um valor especial metricObjectName de _OTHER_DATABASE_ é usado
para as métricas de entrada/saída de banco de dados associadas ao ASM e para bancos de
dados não mencionados, de forma explícita, no plano do IORM entre diferentes bancos de
dados.
Embora este slide se concentre nas métricas de banco de dados, os mesmos princípios se
aplicam para métricas de categorias e de grupos de consumidores. Por exemplo, a métrica
CG_IO_RQ_SM_SEC especifica a taxa de solicitações de entrada/saída pequenas emitidas por
um grupo de consumidores por segundo no último minuto. Um valor alto indica uma carga de
trabalho de entrada/saída pesada do grupo de consumidores associado no último minuto.
Consulte a lição Monitorando Exadata Storage Servers para obter mais informações sobre
métricas do servidor de armazenamento.
IORM e Memória Flash do Exadata Storage Server
• O IORM gerencia somente as filas de entrada/saída dos

discos físicos
– Ele não gerencia solicitações para discos de grade baseados
em flash nem solicitações atendidas pelo Exadata Smart Flash
Cache
• O IORM é capaz de controlar se um banco de dados pode
usar o Exadata Smart Flash Cache
le
• O IORM é capaz de controlar se um banco de dados pode ferab
s
usar o Exadata Smart Flash Log ran n -t
n o
a
as ฺ
CellCLI> alter iormplan
-
) h
> dbPlan=((name=oltp, level=1, allocation=80, flashCache=on,
m u ide flashLog=on),
ฺbrflashCache=off, -
> (name=dss, level=1, allocation=20, limit=50,
ฺ coflashCache=off,
n t G flashLog=off)) flashLog=on), -
> (name=other, level=2, allocation=100,
o e
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic anteriormente, o IORM gerencia somente as filas de entrada/saída
Conforme
o Tmencionado
e c nicdiscos físicos. Ele não gerencia solicitações para discos de grade baseados em flash
dos
T nem solicitações atendidas pelo Exadata Smart Flash Cache.
Entretanto, a partir da release 11.2.2.3 do software do Exadata Storage Server, o IORM pode
ser usado para especificar se um banco de dados pode usar o Exadata Smart Flash Cache.
Isso permite reservar o flash cache para os bancos de dados mais importantes, o que é útil
principalmente nos ambientes usados para consolidar vários bancos de dados.
Defina flashCache=on na diretiva do plano entre diferentes bancos de dados para
permitir que os bancos de dados associados usem o Exadata Smart Flash Cache e defina
flashCache=off para impedir que eles usem esse recurso. Se uma diretiva de plano
entre diferentes bancos de dados não contiver o atributo flashCache, a definição
flashCache=on será usada, por default.
Da mesma forma, o atributo flashLog poderá ser definido para especificar se os bancos
de dados podem ou não usar o Exadata Smart Flash Log. Se o atributo flashLog não for
especificado, a definição flashLog=on será usada, por default. O Exadata Smart Flash Log
requer a release 11.2.2.4.0 ou posterior do software do Exadata Storage Server.

Exemplo Completo
Banco de dados A
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => ‘DB_A_Plan',
CONSUMER_GROUP1 => ‘CG1', GROUP1_PERCENT => 15,
CONSUMER_GROUP4 => ‘CG4’, GROUP2_PERCENT => 40);
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(CONSUMER_GROUP => ‘CG1’,
NEW_CATEGORY => ‘BATCH’);
le
rab
fe
tra ns
NEW_CATEGORY => ‘INTERACTIVE’);
n -
NEW_CATEGORY => ‘INTERACTIVE’); no a
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); a
h eฺ s
END; r
ฺ Guid
b )
/
m
k o ฺco dent
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN t ei S= t‘DB_A_Plan';
u
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
e ic
primeiro del uma série de três slides, que fornecem um exemplo mais completo,
Este éoo T
e c nic o uso simultâneo dos diferentes tipos de planos do IORM. O exemplo se baseia
mostrando
T no cenário apresentado nas páginas 7, 8 e 9 desta lição.
Neste slide, são mostrados os comandos necessários para configurar o DBRM no Banco de
dados A.
Observe que o exemplo não mostra a criação de nenhuma categoria usando
DBMS_RESOURCE_MANAGER.CREATE_CATEGORY porque as categorias usadas no cenário
(BATCH e INTERACTIVE) são categorias predefinidas dentro do Oracle Database por default.

Exemplo Completo
Banco de dados B
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => ‘DB_B_Plan',
CONSUMER_GROUP4 => ‘CG8’, GROUP2_PERCENT => 45);
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
le
rab
fe
tra ns
NEW_CATEGORY => ‘INTERACTIVE’);
n -
NEW_CATEGORY => ‘INTERACTIVE’); no a
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); a
h eฺ s
END; r
ฺ Guid
b )
/
m
k o ฺco dent
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN t ei S= t‘DB_B_Plan';
u
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Nesteoslide, lic os comandos necessários para configurar o DBRM no Banco de
Tesão mostrados
e c nic B. Esses comandos são basicamente os mesmos usados para o Banco de dados A,
dados
T exceto os nomes dos grupos de consumidores e as porcentagens de alocação de recursos
diferentes.

Exemplo Completo
Células do Exadata
CellCLI> alter iormplan objective='balanced'

> dbplan=((name=Database_A, level=1, allocation=70), -
> (name=Database_B, level=1, allocation=30)), -
> catplan=((name=INTERACTIVE, level=1, allocation=60), -
le
rab
> (name=BATCH, level=1, allocation=40))
fe
CellCLI> alter iormplan active
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
e oslicomandosc
o Tmostra
Este slide necessários para configurar o IORM nas células do Exadata.
i c
Asncélulas do Exadata usam o plano do IORM em conjunto com os planos do DBRM
e c
T propagados pelos bancos de dados para alocar recursos de entrada/saída.

Questionário
Se um grupo de consumidores não requer a alocação de

recursos inteira, o que acontece com a alocação restante?

a. Ela permanece não utilizada
b. Ela é dividida igualmente entre outros grupos de
consumidores
c. Ela é alocada para outros grupos de consumidores ativos,
le
de acordo com o plano de recursos rab fe
n s
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 lic
Resposta:
o Tce
e c nic
T

Questionário
Quais das condições a seguir são necessárias para que o

IORM gerencie a alocação de recursos de entrada/saída?

a. O objetivo do plano do IORM deve ser definido
b. O plano do IORM deve estar ativo
c. Mais de um grupo de consumidores ou banco de dados
deve estar ativo
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
Resposta:
o Ta,e b, c lic
e c nic as condições listadas nesta pergunta devem existir para que o IORM gerencie a
Todas
T alocação de recursos de entrada/saída.

Questionário
Em qual ordem os diferentes planos de recursos de

entrada/saída são aplicados para alocação dos recursos?

a. Categoria, dentro do mesmo banco de dados, entre
diferentes bancos de dados
b. Entre diferentes bancos de dados, categoria, dentro do
mesmo banco de dados
c. Categoria, entre diferentes bancos de dados, dentro do rable
mesmo banco de dados n s fe
d. Entre diferentes bancos de dados, dentro do mesmon - tra
a no
banco de dados, categoria as ฺ
) h
e. Dentro do mesmo banco de dados,
m ฺbentre ide
r udiferentes
bancos de dados, categoria ฺco nt G 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 lic
Resposta:
o Tce
e c nic
T

Questionário
É possível criar categorias com o utilitário CellCLI:

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
e c nicpode criar suas próprias categorias usando o procedure CREATE_CATEGORY no
Você
T package DBMS_RESOURCE_MANAGER e, em seguida, designar sua categoria a um grupo
de consumidores usando os procedures CREATE_CONSUMER_GROUP ou
UPDATE_CONSUMER_GROUP.
Depois, os recursos de entrada/saída podem ser gerenciados com base em categorias,
criando um plano de categoria. O plano de categoria pode ser criado com o utilitário CellCLI.

Resumo
Nesta lição, você aprendeu a usar o Exadata I/O Resource

Management para gerenciar cargas de trabalho em um ou em

vários bancos de dados.
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
– Gerenciamento de Recursos de Entrada/Saída dentro do

Mesmo Banco de Dados
– Gerenciamento de Recursos de Entrada/Saída entre
Diferentes Bancos de Dados
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

Recomendações para Otimização do

Desempenho de Bancos de Dados
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

recomendações para otimizar o desempenho de bancos de

dados junto com 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

Otimizando o Desempenho
• Inicie com as melhores práticas para o ASM e o Oracle

Database
• Áreas de consideração especial:
– Uso da memória flash
– Uso de compactação
– Uso de índice
le
– Tamanho da unidade de alocação do ASM
fe rab
– Tamanho mínimo da extensão
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 licotimizar o desempenho do ambiente do Exadata Database Machine é
Tepasso para
O primeiro
o
ic boas práticas de projeto de banco de dados e de desenvolvimento de aplicações. Do
ecn
seguir
T ponto de vista da administração, é necessário continuar seguindo as melhores práticas para
o ASM e para o Oracle Database, juntamente com consultoria e estatísticas fornecidas por
ferramentas como o monitor SQL e o SQL Tuning Advisor.
Além disso, há várias áreas de consideração especial listadas no slide. Elas são abordadas
no restante desta lição.

Uso da Memória Flash
• Cada Exadata Storage Server contém 384 GB de memória flash de

alto desempenho. Usos possíveis:

– Exadata Smart Flash Cache:
— Acelera o acesso a dados utilizados com frequência
— Usa a maior parte da memória flash disponível por default
— Pode ser gerenciado automaticamente para obter a
eficiência máxima
— Os usuários podem fornecer dicas opcionais para influenciar as prioridades de
armazenamento no cache.
le
— Benéfico para cargas de trabalho OLTP e de Data Warehouse
– Armazenamento permanente baseado em flash: fe rab
Usa memória flash como um dispositivo de armazenamento superior tr a ns
—
n -
— Deve ser configurado por um administrador
Requer planejamento deliberado para usá-lo com eficiência
no
a
—
Benefícios adicionais para aplicações específicas a

h eฺ s
—
r
ฺ Guid
b )
– Exadata Smart Flash Log:
m
— Armazenamento temporário pequeno
k o ฺco (512 e n t de alto desempenho para
MB)
registros de redo log
t t ud do Exadata Storage Server
ei peloSsoftware
te@ this
— Gerenciado automaticamente
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
Te Storage
Cada Exadata
o lic Server contém 384 GB de memória flash de alto desempenho.
Por c
nidefault, quando o Database Machine é configurado pela primeira vez, praticamente toda
T e c
essa memória flash é configurada como Exadata Smart Flash Cache. O Exadata Smart Flash
Cache fornece um mecanismo de armazenamento em cache para dados acessados com
frequência em cada célula do Exadata, o que é útil para absorver leituras aleatórias
repetidas, bem como para o OLTP (Online Transaction Processing). O Smart Flash Cache
também beneficia aplicações de data warehousing armazenando no cache os dados
acessados com mais frequência.
O Smart Flash Cache concentra-se automaticamente em armazenar no cache dados
acessados com frequência e blocos de índice, juntamente com informações críticas de
desempenho, como arquivos de controle e cabeçalhos de arquivos. Além disso, os DBAs
podem alterar as prioridades de armazenamento no cache utilizando o atributo
CELL_FLASH_CACHE para objetos de banco de dados específicos.
Por exemplo, para priorizar o armazenamento no cache da tabela CALLDETAIL, use o
comando SQL a seguir:
ALTER TABLE calldetail STORAGE (CELL_FLASH_CACHE KEEP)
Por causa dessa definição, o Exadata Storage Server armazenará no cache os dados
da tabela CALLDETAIL de forma mais intensiva do que em outras situações. Com essa
definição, o Exadata Storage Server também tentará armazenar no cache varreduras feitas
na tabela CALLDETAIL. Isso aumenta a probabilidade de que varreduras subsequentes na
tabela CALLDETAIL também sejam atendidas com o uso do Exadata Smart Flash Cache.

Essa definição também faz com que o Exadata Storage Server remova outras tabelas do cache
antes de remover os dados da tabela CALLDETAIL armazenados no cache. Isso significa que
os registros da tabela CALLDETAIL permanecerão no Exadata Smart Flash Cache por mais
tempo do que os dados de outras tabelas armazenados no cache. Se a tabela CALLDETAIL for
distribuída por várias células do Exadata, cada uma delas armazenará sua parte da tabela em
seu próprio Exadata Smart Flash Cache. Se os caches tiverem tamanho suficiente, é provável
que a tabela CALLDETAIL seja completamente armazenada no cache com o passar do tempo.
Como alternativa, você pode configurar um Smart Flash Cache menor e usar a memória flash
restante como uma unidade de disco flash. Em seguida, é possível criar discos de grade nessa
memória flash. Esses discos flash podem ser usados para configurar grupos de discos ASM de
alto desempenho, com seus próprios tablespaces. Nesse caso, a memória flash não é usada
para armazenar dados no cache. Ela se transforma em um armazenamento permanente de alto
desempenho para alguns de seus dados. O armazenamento permanente baseado em flash
poderá ser muito útil nos seguintes casos:
• Aplicações que gravam grandes volumes de dados: no caso de aplicações que
executam muitas atualizações ou quando há o processamento de grandes volumes de
dados, considere armazenar tabelas, partições ou índices específicos em discos flash.
le
Nesses casos, o alto volume de gravações pode consumir uma parte considerável da
fe rab
largura de banda do disco físico. O armazenamento de tabelas, partições e índices com
a ns
muitas inserções e atualizações em um armazenamento baseado em flash significa que
tr
n -
não há entradas/saídas do disco físico associadas a esses objetos. A largura de banda do
no
disco físico salva com essa configuração pode ser usada por outras operações,
a
a s
aumentando o throughput geral do sistema. Discos flash também podem ser usados de
h eฺ
)
forma efetiva em conjunto com o particionamento. Em muitos cenários de particionamento
r
ฺ Guid
b
baseado em tempo, os dados mais atualizados podem ser muito voláteis, enquanto que
m
o ฺco dent
dados mais antigos estão sujeitos a poucas ou nenhuma atualização. Nessas situações,
você pode hospedar suas partições mais atualizadas em um tablespace baseado em flash
k
t ei Stu
e mover rotineiramente essas partições para um tablespace baseado em disco, à medida
o r te@ this
que sua volatilidade diminuir com o tempo.
ฺ s up use
• Esquemas em estrela: em um data warehouse baseado em um esquema em estrela, é
possível armazenar toda uma tabela de fatos em um disco flash. Ele age efetivamente
( t ec se to
como um cache permanente para essa tabela-chave. Se a tabela de fatos for muito grande
e i ko licen
para ser armazenada no disco flash, você poderá particioná-la e armazenar as partições
T
mais referenciadas nesse disco.
o
ic
A memória flash disponível em cada célula pode ser dividida entre o Exadata Smart Flash
TecnCache e o armazenamento baseado em flash permanente. As duas áreas podem ter qualquer
tamanho, desde que o total não exceda o tamanho total de memória flash disponível em cada
célula. Na prática, a eficácia do Smart Flash Cache diminuirá se o tamanho do cache for muito
pequeno, então, na maioria dos casos, seria alocada uma proporção substancial de memória
flash ao Smart Flash Cache.
Observe que o Exadata Smart Flash Cache é, em grande parte, automático, e há muito poucas
definições de configuração a serem consideradas. Em contrapartida, a configuração de
armazenamento permanente baseado em flash requer um planejamento preciso do espaço,
para que seja feito um uso eficaz desse recurso superior.
A partir do Exadata Storage Server release 11.2.2.4.0, o Exadata Smart Flash Log fornece um
mecanismo para melhorar a latência das operações de gravação dos redo logs do banco de
dados. O Exadata Smart Flash Log usa uma pequena parte da memória flash de alto de
desempenho do Exadata Storage Server como armazenamento temporário a fim de permitir
gravações de redo log de baixa latência. Por default, o Exadata Smart Flash Log usa 32 MB em
cada disco de célula baseado em flash, para um total de 512 MB em cada Exadata Storage
Server. O Exadata Smart Flash Log default pode ser eliminado e criado novamente com um
tamanho diferente. Entretanto, o tamanho do Exadata Smart Flash Log default é suficiente na
maioria dos casos. O Exadata Smart Flash Log é gerenciado automaticamente pelo Exadata
Storage Server.
Por fim, a capacidade de um banco de dados usar o Exadata Smart Flash Cache ou o Exadata
Smart Flash Log pode ser controlada com o Plano do IORM (I/O Resource Management).
Consulte a lição I/O Resource Management para obter mais detalhes.
Uso de Compactação
Método Sintaxe Relação de Consumo de Aplicações

de CREATE/ALTER Compactação CPU Típicas
Compactação
TABLE
Compactação COMPRESS Alta para inserções de Baixo: o Oracle Database DSS
Básica [BASIC] caminho direto executa compactação e
Atualizações e inserções de descompactação
caminho convencional não
são compactadas
Compactação COMPRESS FOR Alta para todos os tipos de Baixo: o Oracle Database OLTP e DSS
OLTP OLTP transações executa compactação e
descompactação, a
compactação para DML é
executada em lotes r a ble
Compactação COMPRESS FOR Mais alta para inserções de Médio: a descompactação é DSS ns
fe
de Data QUERY caminho direto executada pelo Exadata
n - tra
Warehouse [LOW|HIGH] Alta para atualizações e
inserções de caminho
Storage Server
a no
direto
) h as ฺ
Compactação COMPRESS FOR A mais alta para inserções Alto: r
u de é Arquivamento
ฺb a descompactação
iExadata
de Arquivo ARCHIVE de caminho direto
m executada
Alta para atualizaçõesฺeco StoragetServer
Gpelo
On-line [LOW|HIGH]
o e n
direto t eik Stud
inserções de caminho
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic logo em compactação de dados quando os limites de capacidade de
Te pensam
Muitas pessoas
o
e c nic
armazenamento estão próximos de serem atingidos. Frequentemente, a compactação de
dados é considerada um overhead do desempenho, que deve ser tolerado para que seja
T obtida uma capacidade de armazenamento adicional. No entanto, nos casos em que a largura
de banda de Entradas/saídas é limitada, a compactação de dados pode ser uma ferramenta
eficaz para aumentar o desempenho usando a capacidade disponível da CPU para aumentar,
de forma eficaz, o throughput de Entradas/saídas de um sistema de armazenamento.
O Oracle Database permite os modos de compactação de dados a seguir:
• A compactação básica compacta os dados no nível do bloco do Oracle. Ela permite que
mais dados sejam armazenados em cada bloco, substituindo valores duplicados por uma
representação simbólica menor. Por exemplo, se o valor numérico 99999 aparecer 50
vezes em um bloco de dados, ele poderá ser substituído por 50 ocorrências do símbolo #,
juntamente com uma entrada em uma tabela de símbolos (também armazenada no bloco)
definindo o uso do símbolo. O grau de compactação depende do nível de duplicação em
cada bloco. Relações de compactação mais altas podem ser atingidas usando tamanhos
maiores de blocos ou classificando os dados para aumentar a coincidência de valores
duplicados. Os dados permanecem no formato de armazenamento por linha, em que as
colunas em cada linha são armazenadas juntas. A compactação ocorre quando os dados
são carregados usando uma operação de carga de caminho direito, como CREATE
TABLE AS SELECT, ou o SQL*Loader de caminho direto. Tabelas que usam
compactação básica oferecem suporte a operações de DML, no entanto, quaisquer dados
inseridos ou atualizados permanecem descompactados. A compactação básica é útil em
DSS (sistemas de suporte a decisões), em que os dados compactados estão sujeitos a
alterações mínimas.
• A compactação OLTP usa a mesma técnica que a compactação básica, mas oferece
suporte à compactação de dados transacionais de todas as instruções DML, não
apenas cargas de caminho direto. Isso é útil em DSS e em ambientes OLTP. Em vez
de compactar alterações quando são gravadas, todas as alterações a um bloco de
dados são compactadas como um lote sempre que uma alteração faz com que o bloco
se torne mais cheio do que um limite controlado internamente. Em outras palavras,
somente as instruções DML que disparam uma compactação experimentam o overhead
da compactação de blocos de dados associados. No entanto, a maioria das instruções

DML não experimenta nenhum overhead de compactação. Isso significa que a
compactação pode ser implementada em sistemas OLTP sem afetar, de forma
significativa, o throughput transacional geral do sistema.
Além dos modos de compactação básica e OLTP oferecidos pelo Oracle Database, o
Exadata Storage Server fornece a compressão EHCC (Exadata Hybrid Columnar
Compression). A tecnologia da compressão EHCC (Exadata Hybrid Columnar Compression)
usa uma forma modificada de armazenamento em colunas em vez do armazenamento por le
linha. Conjuntos de linhas são armazenados em uma estrutura interna denominada unidade
fe rab
de compactação. Dentro de cada unidade, os valores de todas as colunas são armazenados
tr a ns
-
juntamente com os metadados que os mapeiam para as linhas. A compactação é obtida
n
no
substituindo valores repetidos por referências simbólicas menores. Como uma unidade de
a
a s
compactação é muito maior do que um bloco Oracle e a organização em colunas une valores
h eฺ
r )
similares, a compressão EHCC (Exadata Hybrid Columnar Compression) pode produzir
ฺ Guid
b
m
relações de compactação muito melhores do que as compactações básica e OLTP. As
k o ฺco dent
melhores taxas de compactação são obtidas usando cargas de caminho direto.
A compressão EHCC (Exadata Hybrid Columnar t ei SCompression)
tu é uma opção de modo de
compactação para obter um equilíbrior t e @ adequado
h i s entre o uso de disco e o overhead da CPU:
o e t
• Compactação de data
ฺ s upwarehouse:
usesdestina
esse tipo de compactação é otimizado para
desempenho das
( t c
e se t
consultas oe a aplicações de DSS e de data warehouse.
i
• Compactação
e ko lide c e n
arquivo on-line: esse tipo de compactação é otimizado para
i c o Talterados.
relações de compactação máximas e se destina a dados históricos e dados que não
e c n são
T A compressão EHCC (Exadata Hybrid Columnar Compression) oferece suporte a operações
DML em dados compactados. Entretanto, as linhas atualizadas e as adicionadas com
inserções de caminho convencional são colocadas em unidades de compactação de bloco
único que proporcionam uma relação de compactação mais baixa do que as cargas de
caminho direto. Além disso, as atualizações e as deleções em tabelas que usam a
compressão EHCC (Exadata Hybrid Columnar Compression) exigem que toda a unidade
de compactação seja bloqueada, o que poderá afetar a concorrência. Finalmente, as
atualizações em linhas com a compressão EHCC produz alterações nos IDs das linhas.
Como resultado, a compressão EHCC é recomendada em situações em que as alterações
dos dados não são frequentes ou quando os conjuntos de dados são recarregados em vez
de alterados de forma substancial.
Concluindo, a compressão EHCC faz uso eficaz do hardware do Exadata Storage Server a
fim de oferecer os níveis máximos de compactação de dados em um banco de dados Oracle.
É mais adequada em casos em que os dados não estão sujeitos a grandes alterações. No
caso de conjuntos de dados transacionais, você deve considerar a compactação OLTP em
vez de a compressão EHCC. Em todo caso, você deve lembrar-se dos méritos relativos e
overheads associados a cada tipo de compactação a fim de escolher a melhor abordagem
para a sua situação.

Uso de Índice
• As consultas que exigem índices de um sistema anterior

podem ter um desempenho melhor com o Exadata

Database Machine e o Smart Scan
• Considere remover os índices quando o Smart Scan
oferece um desempenho aceitável
• A remoção de índices desnecessários:
le
– Aperfeiçoará o desempenho do DML
fe rab
– Economizará espaço de armazenamento
tra ns
• on-
Teste o efeito da remoção de índices tornando-os
n
invisíveis: a
as ) h eฺ
r
ฺ Guid
b
SQL> ALTER INDEX <index_name> INVISIBLE; 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 requerem índices quando usam o armazenamento convencional
Algumas
o Tconsultas que
e c nicum desempenho aceitável sem índices com o Exadata Database Machine. Analise as
terão
T consultas que usam índices para determinar se elas teriam um desempenho aceitável com o
Smart Scan.
Para testar se as consultas funcionam de forma aceitável sem índice, você pode tornar
o índice invisível para o otimizador. Um índice invisível não é eliminado, é mantido por
operações DML, mas não é usado pelo otimizador para consultas. Para tornar um índice
invisível, uso o comando a seguir:
ALTER INDEX <index_name> INVISIBLE
A remoção de índices desnecessários ajudará no desempenho das operações do DML e
economizará espaço de armazenamento.

Tamanho da Unidade de Alocação do ASM
• Por default, o ASM usa um tamanho de unidade de alocação (AU)
de 1 MB.
• Para o armazenamento do Exadata, o tamanho de AU

recomendado é 4 MB.
– O tamanho da AU deve ser definido quando um grupo de discos
é criado
– O tamanho da AU não pode ser alterado após a criação de um grupo
de discos
– O tamanho da AU é definido com o atributo de grupo de discos
AU_SIZE le
— Exemplo:
fe rab
tr a ns
SQL> CREATE DISKGROUP data NORMAL REDUNDANCY
n -
DISK 'o/*/data_CD*' no a
ATTRIBUTE 'compatible.rdbms' = '11.2.0.0.0', a
h eฺ s
'compatible.asm' = '11.2.0.0.0', r
ฺ Guid
b )
m
'cell.smart_scan_capable' = 'TRUE',
k o ฺco dent
'au_size' = '4M';
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de varredura de disco, é importante dispor de segmentos com pelo
Tetaxas rápidas
Para atingir
o
e c nic 4 MB de espaço contíguo. Isso permite que as varreduras de disco leiam 4 MB de
menos
T dados antes de executar outra busca em outro local em um disco. Para garantir que sejam
dispostos segmentos com 4 MB de espaço contíguo, defina o tamanho da unidade de
alocação do Oracle ASM como 4 MB. A unidade de alocação pode ser definida com o
atributo de grupo de disco AU_SIZE ao criar o grupo de discos.

Tamanho Mínimo da Extensão
• Segmentos grandes devem ter extensões iniciais de 8 MB:

– Interrompe a proliferação desnecessária de extensões

pequenas no banco de dados
– Minimiza leituras de extensões pequenas abaixo do ideal
– Atende à recomendação de 4 MB de tamanho da AU do
ASM
– Exemplos: le
fe rab
SQL> CREATE TABLE t1
tra ns
(col1 NUMBER(6), col2 VARCHAR2(10))
n -
STORAGE ( INITIAL 8M MAXSIZE 1G ); no a
a s
SQL> CREATE BIGFILE TABLESPACE ts1 ฺbr
) h ideฺ
DATAFILE '+DATA' SIZE 100Gฺco
m t Gu
k o d e n
DEFAULT STORAGE ( INITIAL i
te 8M tuNEXT 8M );
@ s S
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic é gerenciado automaticamente em tablespaces gerenciados
Teda extensão
O tamanho
o
ic
ecn
localmente. Essa opção aumenta, de forma automática, o tamanho da extensão, dependendo
T do tamanho do segmento, do espaço livre disponível no tablespace e de outros fatores. Por
default, o tamanho da extensão começa com 64 KB e aumenta em incrementos de 1 MB, 8
MB ou 64 MB.
Grosso modo, é recomendável definir segmentos grandes com extensões maiores do que as
iniciais default, a fim de minimizar a proliferação desnecessária de extensões pequenas no
banco de dados. Para o Database Machine, a recomendação é ter extensões iniciais de 8
MB para segmentos grandes. Essa definição complementa a recomendação para definir o
tamanho da unidade de alocação do ASM como 4 MB. As opções a seguir podem ser usadas
para influenciar o banco de dados a alocar extensões grandes:
• O parâmetro de armazenamento INITIAL definirá o tamanho da primeira extensão
para um objeto recém-criado. Pode ser definido especificamente para objetos
individuais ou no nível do tablespace para tablespaces gerenciados localmente.
Para objetos grandes, defina INITIAL como 8 MB.
• Antes do Oracle Database release 11.2.0.2, o parâmetro de inicialização
CELL_PARTITION_LARGE_EXTENTS podia ser usado para definir o parâmetro de
armazenamento INITIAL como 8 MB para todos os novos segmentos de um objeto
particionado. A definição default e recomendada é TRUE. A partir do Oracle Database
release 11.2.0.2, o parâmetro permanece oculto e internalizado. A definição interna é
TRUE, e a Oracle não recomenda alterá-la.
Questionário
Em quais dos cenários a seguir faria sentido considerar a alteração
do Exadata Smart Flash Cache default para configurar um tablespace
baseado em flash no seu banco de dados?

a. Quando você consegue colocar 10 ou mais tabelas em um
tablespace baseado em flash.
b. Quando você consegue colocar pelo menos 80% das tabelas mais
usadas em um tablespace baseado em flash.
c. A transferência de tabelas e índices específicos para um tablespace
baseado em flash absorverá atividades de gravação pesadas,
r a ble
liberando largura de banda de Entradas/saídas para outras
n s fe
operações.
n - tra
d. Quando você tem objetos de aplicação importantes (como
a no uma
tabela de fatos de esquema em estrela) que deseja
) h as armazenar
ฺ
no
cache de forma permanente, tem conhecimento
m ฺ br udos ideseus requisitos
de espaço e está preparado para aceitar
ฺ c o ontesforçoG de
o
ik na
gerenciamento adicional implicado
u e
dconfiguração de um
tablespace baseado em@ t e
flash. s S t
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
Resposta:
o Tc,e d lic
e c nic
T

Questionário
Quais das seguintes cláusulas de compactação CREATE

TABLE estão disponíveis somente para uso com o Exadata

Database Machine?
a. COMPRESS BASIC
b. COMPRESS FOR OLTP
c. COMPRESS FOR QUERY
le
d. COMPRESS FOR ARCHIVE
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
Resposta:
o Tc,e d lic
e c nic
T

Resumo
Nesta lição, você aprendeu a descrever as recomendações

para otimizar o desempenho de bancos de dados junto com

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

Recursos Adicionais
– Configurando Grupos de Discos Baseados em Flash

– Examinando a Compressão EHCC (Exadata Hybrid
Columnar Compression)
– Eliminação de Índices com o 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

Visão Geral do Exercício 8: Otimizando o
Desempenho de Bancos de Dados com o Exadata
Nestes exercícios, você explorará a otimização do
desempenho de bancos de dados usando:

• Grupos de discos baseados em flash
• Compressão EHCC (Exadata Hybrid Columnar
Compression)
• Eliminação de índice
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
Usando o Smart Scan
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 o Smart Scan e o processamento de consultas

que pode ser descarregado no Exadata Storage Server
• Descrever os requisitos do Smart Scan
• Descrever as circunstâncias que impedem o uso do Smart
Scan
• Identificar o Smart Scan nos planos de execução de SQLerab
le
n s f
• Usar estatísticas de banco de dados e eventos de espera
tra
n -
no
para confirmar como as consultas são processadas
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

Visão Geral do Exadata Smart Scan
• O Smart Scan inclui:

– Varreduras de Tabelas e de Índices: em vez de transportar

todos os dados para o servidor de banco de dados, as
varreduras são executadas no Exadata Storage Server
– Filtragem de predicados: somente as linhas solicitadas, e
não todas as linhas de uma tabela, são retornadas para o
servidor de banco de dados
– Filtragem de colunas: somente as colunas solicitadas, e não r a ble
todas as colunas da tabela, são retornadas para o servidorn s fe
de banco de dados n - tra
a no
– Filtragem de joins: o processamento de a
h s com o uso de
joins
br)
filtros "Bloom" é descarregado no Exadata deฺ Server
iStorage ฺ Gu
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 liceficientes do Database Machine é a capacidade de descarregar
Um doso Te mais
recursos
on
c ic
processamento da recuperação e da pesquisa de dados nos Exadata Storage Servers.
T e Usando esse recurso, o Oracle Database pode otimizar o desempenho das operações que
realizam varreduras de tabelas e de índices executando as varreduras no Exadata Storage
Server, em vez de transportar todos os dados para o servidor de banco de dados. Esse
princípio também pode ser aplicado aos dados criptografados e compactados. Além disso,
vários aspectos do processamento SQL podem ser descarregados no Exadata Storage
Server, de forma que são executados mais próximo dos dados, reduzindo, assim, o volume
de dados retornados para o servidor de banco de dados.
O slide lista as principais funções de banco de dados integradas ao Exadata Storage Server.
O termo Smart Scan também é usado para descrever as situações em que essas funções
são executadas pelo Exadata Storage Server.
Esta lição se concentra nos requisitos para execução do processamento do Smart Scan e
mostra como usar os recursos básicos de monitoramento do SQL no Oracle Database para
identificar Smart Scans.

Requisitos do Smart Scan
O Smart Scan não é controlado pelo otimizador, mas é influenciado

pelos resultados da otimização de consultas.

• Requisitos específicos de consulta:
– O Smart Scan só pode ser usado para varreduras integrais de
tabelas ou índices
– O Smart Scan só pode ser usado para leituras de caminho direto
As leituras de caminho direto são usadas automaticamente para
—
le
consultas paralelas
fe rab
— As leituras de caminho direto podem ser usadas para consultas seriais
tr a ns
n -
Não usadas, por default, para varreduras de tabelas pequenas seriais
no
—
Use _serial_direct_read=TRUE para forçar leituras de caminho direto

—
s a
• Outros requisitos gerais: ) a
h eฺ
b
ฺ G r id
– O Smart Scan deve estar ativado no m banco deudados
– Os segmentos devem ser armazenados k o ฺco denem t
grupos de discos
t e i t u
configurados de forma@
e adequada
i s S
r t
o se t h
u p
Copyright © 2012,
e
t
o ( ense
i k lic Scan é uma decisão de runtime. Embora ele não esteja integrado
Te do Smart
A otimização
o
ic
ecn
ao otimizador do Oracle, ele é influenciado pelos resultados da otimização de consultas.
T Em outras palavras, a decisão quanto ao uso ou não do Smart Scan não é tomada pelo
otimizador, mas ele determina indiretamente quando o Smart Scan pode ser usado.
Antes de se considerar o uso do Smart Scan, os seguintes requisitos específicos de consulta
devem ser atendidos:
• O Smart Scan só pode ser usado para varreduras integrais de segmentos; ou seja,
varreduras integrais de tabelas, varreduras integrais rápidas de índices e varreduras
integrais rápidas de índices de bitmap.
• O Smart Scan só pode ser usado junto com leituras de caminho direto. Essas leituras
são usadas por operações paralelas de modo que quaisquer consultas paralelas
tornam-se automaticamente um candidato potencial para o Smart Scan. As operações
seriais também podem executar leituras diretas, dependendo de fatores como o
tamanho da tabela e o estado do cache de buffer. Por default, as leituras de caminho
direto não são usadas para tabelas consideradas pequenas. Entretanto, essas leituras
podem ser forçadas para permitir o acesso serial definindo-se
_serial_direct_read=TRUE no nível do sistema ou de sessão.

Além dos requisitos específicos de consulta, os seguintes requisitos gerais também devem
ser atendidos para ativar o Smart Scan:
• O Smart Scan deve estar ativado no banco de dados. O parâmetro de inicialização
CELL_OFFLOAD_PROCESSING controla o Smart Scan. O valor default do parâmetro é
TRUE e indica que o Smart Scan está ativado por default.
• Cada segmento submetido à varredura deve estar em um grupo de discos totalmente
armazenado nas células do Exadata. O grupo de discos também deve ter as seguintes
definições de atributo:
'compatible.rdbms' = '11.2.0.0.0' (ou posterior)
'compatible.asm' = '11.2.0.0.0' (ou posterior)
'cell.smart_scan_capable' = 'TRUE'
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

Situações que Impedem o Uso do Smart Scan
O Smart Scan não pode ser usado nestas circunstâncias:

• Uma varredura em uma tabela clusterizada

• Uma varredura em uma tabela organizada por índice
• Uma varredura integral rápida em um índice compactado
• Uma varredura integral rápida em índices de chave invertida
• A tabela tem o rastreamento de dependências no nível de linha ativado
• A pseudocoluna ORA_ROWSCN está sendo extraída por meio de uma
operação de fetch
• O otimizador deseja que a varredura retorne as linhas na ordem de ROWID
r a ble
• O comando é CREATE INDEX usando NOSORT
n s fe
• Uma coluna LOB ou LONG está sendo selecionada ou consultada
n - tra
• Uma operação Flashback Query SELECT ... VERSIONS
a no está sendo
executada
) h as ฺ
• r uide
Mais de 255 colunas são referenciadas nabconsulta
ฺ
• m
co ent G baseada em célula está
Os dados estão criptografados e a descriptografia
desativada o ฺ
• teikbaseSem
Para avaliar um predicado com tuduma coluna virtual
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
Teas circunstâncias
O slideolista específicas em que o recurso Smart Scan não pode ser usado.
i c
n a seguir informações adicionais sobre alguns desses casos:
Leia
T e c
• Mais de 255 colunas são referenciadas na consulta: essa restrição se aplicará somente
se a consulta envolver tabelas que não são compactadas por meio da compressão
EHCC (Exadata Hybrid Columnar Compression). As consultas em tabelas compactadas
com a compressão EHCC poderão ser descarregadas mesmo que façam referência a
mais de 255 colunas.
• Os dados estão criptografados e a descriptografia baseada em célula está desativada:
para que o Exadata Storage Server execute a descriptografia, o Oracle Database
precisa enviar a chave de descriptografia para cada célula. Se houver preocupações
de segurança em relação ao envio de chaves pela rede de armazenamento, a
descriptografia baseada em célula poderá ser desativada definindo-se o parâmetro
de inicialização CELL_OFFLOAD_DECRYPTION como FALSE.

Monitorando o Smart Scan nos Planos de
Execução de SQL
Parâmetros de Inicialização Relevantes:
• CELL_OFFLOAD_PROCESSING
– TRUE | FALSE
– Ativa ou desativa o Smart Scan e outros recursos de
armazenamento inteligente
– Modificável de forma dinâmica no nível da sessão ou do
sistema usando ALTER SESSION ou ALTER SYSTEM
le
– Pode ser especificado no nível de instrução usando a dica
OPT_PARAM fe rab
• tra ns
CELL_OFFLOAD_PLAN_DISPLAY
n -
– NEVER | AUTO | ALWAYS no
a sa
– Permite que o plano de execução mostrehpredicados
r ) d e ฺ
descarregados
m b
ฺ Gu i
– Modificável de forma dinâmica o
ฺc dentda sessão ou do
no nível
i k
sistema usando ALTEReSESSIONo
tu ou ALTER SYSTEM
@ t S
r t e h i s
u p o se t
Copyright © 2012,
e
t
o ( ense
i k lic
o Te de inicialização
O parâmetro CELL_OFFLOAD_PROCESSING controla o Smart Scan. O valor
i c
default
n definido como FALSE,eoindica
do parâmetro é TRUE que o Smart Scan está ativado. Se esse parâmetro
Tecestiver Smart Scan estará desativado, e o banco de dados usará
o armazenamento do Exadata para fornecer blocos de dados de maneira semelhante ao
armazenamento tradicional. Para ativar o Smart Scan para uma instrução SQL específica,
use a dica OPT_PARAM, conforme mostrado no exemplo a seguir:
SELECT /*+ OPT_PARAM('cell_offload_processing' 'true') */ ...
O parâmetro de inicialização CELL_OFFLOAD_PLAN_DISPLAY determina se a instrução SQL
EXPLAIN PLAN exibe os predicados que podem ser avaliados pelo Exadata Storage Server
como predicados STORAGE de uma instrução SQL específica. Os valores possíveis são:
• AUTO determina que a instrução SQL EXPLAIN PLAN exiba os predicados que podem
ser avaliados como STORAGE somente se houver uma célula presente e se ela contiver
uma tabela. AUTO é a definição default.
• ALWAYS produzirá alterações na instrução SQL EXPLAIN PLAN independentemente de
o armazenamento do Exadata estar ou não presente ou de a tabela existir ou não na
célula. Você pode usar essa definição para identificar instruções candidatas para
descarregamento antes de efetuar a migração para o Exadata Database Machine.
• NEVER não produz alterações na instrução SQL EXPLAIN PLAN devido ao Exadata.
Isso poderá ser desejável, por exemplo, se você tiver criado ferramentas que
processam a saída do plano de execução, e essas ferramentas não tiverem sido
atualizadas para lidar com a sintaxe atualizada, ou ao comparar os planos do Database
Machine com os do sistema anterior.
Exemplo de Plano de Execução do Smart Scan
SQL> explain plan for select count(*) from customers where cust_valid = 'A';
Explained.
SQL> select * from table(dbms_xplan.display);
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
------------------------------------------------------------------------------
le
rab
| 0 | SELECT STATEMENT | | 1 | 2 | 627K (1)|
| 1 | SORT AGGREGATE | | 1 | 2 | |
fe
|* 2 | TABLE ACCESS STORAGE FULL| CUSTOMERS | 38M| 73M| 627K (1)|
tr a ns
------------------------------------------------------------------------------
n -
Predicate Information (identified by operation id): no a
--------------------------------------------------- a
h eฺ s
r
ฺ Guid
b )
2 - storage("CUST_VALID"='A') m
filter("CUST_VALID"='A')
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic básico de Smart Scan manifestado em um plano de consulta.
Te um exemplo
O slideomostra
ic
TecAnoperação TABLE ACCESS STORAGE FULL indica que o Smart Scan está sendo usado
para varrer a tabela CUSTOMERS. O plano também mostra que a filtragem de linhas está
sendo usada. Neste exemplo, o predicado "CUST_VALID"='A' é avaliado no Exadata
Storage Server.
Observe que o plano de execução não indica a presença de uma consulta paralela, portanto,
a tabela do exemplo é evidentemente grande o suficiente para sugerir o uso de leituras de
caminho direto.

Exemplo de Plano de Execução do Smart Scan
SQL> explain plan for select count(*) from customers where cust_id > '10000';
Explained.
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 6 |
| 1 | SORT AGGREGATE | | 1 | 6 |
le
rab
| 2 | PX COORDINATOR | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | 6 |
fe
| 4 | SORT AGGREGATE | | 1 | 6 |
tr a ns
| 5 | PX BLOCK ITERATOR | | 77M| 443M|
n -
|* 6 | INDEX STORAGE FAST FULL SCAN| CUSTOMERS_PK | 77M| 443M|
------------------------------------------------------------------------------ no a
a
h eฺ s
Predicate Information (identified by operation id): r
ฺ Guid
b )
--------------------------------------------------- m
k o ฺco dent
6 - storage("CUST_ID">10000)
t ei Stu
te@ this
filter("CUST_ID">10000)
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
e outro
Tmostra
Este slide
o lic exemplo de plano de consulta do Smart Scan. Desta vez, o
e c nic
descarregamento de uma varredura integral rápida de índice é indicado. A filtragem
T de linhas também é transferida para os servidores de armazenamento.
Diferentemente do exemplo anterior, este exemplo indica o uso de uma consulta paralela que
implica automaticamente o uso de leituras de caminho direto.

Exemplo de Situação que Impede o
Uso do Smart Scan
SQL> explain plan for select count(*) from cust_iot where cust_id > '10000';
Explained.
-----------------------------------------------------------------------------
|Id | Operation | Name | Rows | Bytes |Cost(%CPU)| Time |
le
rab
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 | 21232 (1)| 00:04:15 |
fe
| 1 | SORT AGGREGATE | | 1 | 13 | | |
tr a ns
|* 2 | INDEX RANGE SCAN| CUST_PK | 86M| 1071M| 21232 -
(1)| 00:04:15 |
n
no
-----------------------------------------------------------------------------
a
Predicate Information (identified by operation id): a
h eฺ s
--------------------------------------------------- r
ฺ Guid
b )
m
2 - access("CUST_ID">10000)
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k
O exemplo
o Temostradolicneste slide é praticamente o mesmo do slide anterior. A única diferença
ic a tabela que está sendo consultada neste exemplo é organizada por índice, com a
ecn
é que
T coluna CUST_ID definida como a chave primária. Como o Smart Scan não pode ser aplicado
a tabelas organizadas por índice, o plano de execução não contém operações de
armazenamento.

Processamento de Joins do
Smart Scan com Filtros "Bloom"
• Um filtro "Bloom" é uma estrutura de dados que pode ser
usada para verificar se um elemento é membro de um conjunto

• Propriedades do filtro "Bloom":
– O volume de dados usado no filtro "Bloom" é muito menor que o
conjunto testado
– O tempo necessário para verificar se um elemento é membro do
conjunto é constante
– Falsos positivos são possíveis, mas sua frequência pode ser
a b le
gerenciada fe r
n s
– Falsos negativos não são possíveis tra -
• A partir do Oracle 10g Release 2, os filtros "Bloom" n onsão usados
para otimizar joins paralelas s a
) a
hprocessado
ฺ
• Com o Exadata, o filtro "Bloom" pode b r
ser
ฺ Gu i d e pelo
m
co ento volume de dados
servidor de armazenamento, reduzindo
o ฺ
eik Studpara o servidor de banco de
transportado desnecessariamente
t
dados e@ iso rt e th
p s empresas afiliadas. Todos os direitos reservados.
suOracletoe/ouusuas
c ฺ
Copyright © 2012,
o (te nse
Um filtro T eik concebido
"Bloom", l ice por Burton Howard Bloom em 1970, é uma estrutura de dados
n i co
probabilística eficiente em termos de espaço que é usada para verificar se um elemento
T e c
é membro de um conjunto. Por causa de suas propriedades, os filtros "Bloom" são uma
maneira muito eficiente de determinar quais valores não estão incluídos em um conjunto.
Isso é muito útil para o processamento de condições de join em que uma parte significativa
dos dados não atende aos critérios de join.
O Oracle Database 10g Release 2 usava inicialmente filtros "Bloom" para otimizar operações
de join paralelas. Quando duas tabelas são unidas por meio de um hash join, a primeira
tabela (geralmente a menor) é varrida, e as linhas que satisfazem aos predicados da cláusula
WHERE (dessa tabela) são usadas para criar uma tabela de hash. Durante a criação da tabela
de hash, uma string de bits de filtro "Bloom" também é criada com base na coluna de join. Em
seguida, a string de bits é enviada como um predicado adicional para a varredura da
segunda tabela. Depois que os predicados da cláusula WHERE relativos à segunda tabela são
aplicados, as linhas resultantes são testadas com o filtro "Bloom". Todas as linhas rejeitadas
pelo filtro "Bloom" não deverão atender aos critérios de join e serão descartadas. Todas as
linhas que atenderem aos critérios com o uso do filtro "Bloom" serão enviadas para o hash
join.
Com o Exadata, o filtro "Bloom" é passado para os servidores de armazenamento como um
predicado adicional. O processamento do filtro "Bloom" no Exadata Storage Server poderá
reduzir o volume de dados transportado para o servidor de banco de dados para processar
uma join, o que, por sua vez, poderá aumentar o desempenho das consultas.
Exemplo de Filtragem de Join do Smart Scan
SQL> SELECT AVG(s.amount_sold) FROM customers cu, sales s
2 WHERE cu.cust_id = s.cust_id
3 AND cu.cust_credit_limit > 5000;
-----------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 19 | 55979 (1)| 00:11:12 | | | |
| 1 | SORT AGGREGATE | | 1 | 19 | | | | | |
| 2 | PX COORDINATOR | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10002 | 1 | 19 | | | Q1,02 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | 19 | | | Q1,02 | PCWP | |
|* 5 | HASH JOIN | | 577M| 10G| 55979 (1)| 00:11:12 | Q1,02 | PCWP | |
| 6 | JOIN FILTER CREATE | :BF0000 | 57M| 547M| 14499 (1)| 00:02:54 | Q1,02 | PCWP | |
| 7 | PX RECEIVE | | 57M| 547M| 14499 (1)| 00:02:54 | Q1,02 | PCWP | |
| 8 | PX SEND HASH | :TQ10000 | 57M| 547M| 14499 (1)| 00:02:54 | Q1,00 | P->P | HASH |
le
rab
| 9 | PX BLOCK ITERATOR | | 57M| 547M| 14499 (1)| 00:02:54 | Q1,00 | PCWC | |
|* 10 | TABLE ACCESS STORAGE FULL| CUSTOMERS | 57M| 547M| 14499 (1)| 00:02:54 | Q1,00 | PCWP | |
| 11 | PX RECEIVE | | 774M| 6651M| 24044 (1)| 00:04:49 | Q1,02 | PCWP | |
fe
| 12 |
| 13 |
PX SEND HASH
JOIN FILTER USE
| :TQ10001 |
| :BF0000 |
774M| 6651M| 24044
774M| 6651M| 24044
(1)| 00:04:49 | Q1,01 | P->P | HASH
(1)| 00:04:49 | Q1,01 | PCWP |
tr a ns
|
|
| 14 | PX BLOCK ITERATOR | | 774M| 6651M| 24044
n
(1)| 00:04:49 | Q1,01 | PCWC |
- |
no
|* 15 | TABLE ACCESS STORAGE FULL| SALES | 774M| 6651M| 24044 (1)| 00:04:49 | Q1,01 | PCWP | |
a
-----------------------------------------------------------------------------------------------------------------------------
s
Predicate Information (identified by operation id):
) a
h eฺ
---------------------------------------------------
r
ฺ Guid
b
m
ฺco dent
5 - access("CU"."CUST_ID"="S"."CUST_ID")
10 - storage("CU"."CUST_CREDIT_LIMIT">5000)
filter("CU"."CUST_CREDIT_LIMIT">5000)
k o
t ei Stu
15 - storage(SYS_OP_BLOOM_FILTER(:BF0000,"S"."CUST_ID"))
filter(SYS_OP_BLOOM_FILTER(:BF0000,"S"."CUST_ID"))
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de filtragem de join do Smart Scan com o uso de um filtro
Te um exemplo
O slide mostra
o
e c nic A consulta do exemplo une uma tabela contendo aproximadamente 77 milhões de
"Bloom".
registros de clientes a outra contendo aproximadamente 774 milhões de registros de vendas,
T para determinar o volume médio de transações dos clientes que têm um limite de crédito
superior a 5000. A consulta é processada da seguinte maneira:
• O Smart Scan é usado para filtrar os registros de clientes e recuperar os valores de
CUST_ID referentes aos clientes que têm um limite de crédito superior a 5000
(operação 10).
• É criado um filtro "Bloom" que representa o conjunto de valores de CUST_ID que
atendem aos critérios da consulta da tabela CUSTOMERS (operação 6).
• Na ausência do armazenamento do Exadata, o filtro "Bloom" será aplicado aos dados
da tabela SALES em um processo do servidor de consulta paralela (operação 13).
Entretanto, com o Exadata, o filtro "Bloom" é enviado para os servidores de
armazenamento como um predicado e aplicado como parte de um Smart Scan da
tabela SALES (operação 15). Como a tabela SALES é bem grande, o desempenho da
consulta melhorará de forma considerável se o volume de entrada/saída for
significativamente reduzido com a eliminação do transporte dos registros de vendas
desnecessários de volta para o banco de dados. O Exadata Storage Server também
executa a filtragem de colunas da tabela SALES de modo que somente os valores de
CUST_ID e AMOUNT_SOLD são retornados.
• Os resultados das operações do Smart Scan nas tabelas CUSTOMERS (operações 6-10)
e SALES (operações 11-15) são combinados por meio de um HASH JOIN (operação 5).
• Por fim, a consulta é serializada, e o resultado é retornado (operações 1-4).
Outras Situações que Afetam o Smart Scan
• A presença de uma operação STORAGE no plano de execução não

garante que a consulta seja satisfeita usando apenas o Smart Scan

• Mesmo quando o Smart Scan é indicado pelo plano de execução,
entradas/saídas de outros blocos também podem ser usadas; por
exemplo:
– Se o Exadata Storage Server não tiver certeza de que um bloco está
atualizado, ele transferirá a leitura desse bloco para o cache de buffer
– Se forem detectadas linhas encadeadas ou migradas, talvez sejam le
necessárias leituras de blocos adicionais sem o uso do Smart Scan
fe rab
– Se a amostragem dinâmica for usada, a entrada/saída da amostragem
tr a ns
não usará o Smart Scan n -
– Se a utilização de CPU do Exadata Storage Server for
no a
a
h eฺ
significativamente maior que a do servidor de banco de dados, o Smart
s
Scan poderá enviar dados adicionais para esse servidor r
ฺ Guid
b )
co eserm t usados para verificar o
• Estatísticas e eventos de espera
k o ฺpodem n
que está acontecendo t ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic
e de execução
Embora oTplano da consulta forneça um indicador referente ao uso do Smart
i
Scan, c o
a presença de uma operação STORAGE no plano não garante que a consulta seja
e c n
totalmente satisfeita com esse recurso. Lembre-se de que, mesmo quando o Smart Scan é
T indicado no plano de execução, entradas/saídas de outros blocos também podem ser
usadas. Estas são algumas situações em que isso poderá ocorrer:
• Como o Smart Scan usa leituras de caminho direto, os dados que estão sendo lidos
devem estar atualizados. Se o Exadata Storage Server não tiver certeza de que um
bloco está atualizado, ele transferirá a leitura desse bloco para o caminho de
consistência de leitura do cache de buffer tradicional. Portanto, se as atualizações
forem executadas ao mesmo tempo que as consultas, as vantagens obtidas com o uso
do Smart Scan serão menores.
• O mesmo se aplica às linhas indiretas, ou seja, linhas encadeadas ou migradas. Para
resolver referências de linhas indiretas, leituras de blocos adicionais talvez sejam
necessárias. Se as suas tabelas contiverem linhas encadeadas ou migradas, as
vantagens de usar o Smart Scan serão menores.
• Se o otimizador usar a amostragem dinâmica para formular o plano de execução da
consulta, a entrada/saída da amostragem não usará o Smart Scan, mesmo que a
consulta venha a utilizá-lo. Nesse caso, você poderá observar o uso do Smart Scan
junto com entradas/saídas de outros blocos.
• A partir do Exadata Storage Server versão 11.2.2.3.0, se a utilização de CPU do
servidor de armazenamento for significativamente maior que a do servidor de banco de
dados, o Exadata Storage Server poderá optar por enviar blocos de dados adicionais
de volta para o servidor de banco de dados para processamento, em vez de processá-
los na célula.
Visão Geral das Estatísticas do
SELECT s.name, m.value/1024/1024 MB FROM V$SYSSTAT s, V$MYSTAT m
WHERE s.statistic# = m.statistic# AND
(s.name LIKE 'physical%total bytes' OR s.name LIKE 'cell phys%'

OR s.name LIKE 'cell IO%');
cell IO
uncompressed cell physical IO
bytes bytes saved during
optimized RMAN file
cell physical IO restore
bytes eligible for cell physical IO
predicate offload interconnect bytes
le
rab
cell physical IO
V$SQL
interconnect bytes
cell physical IO
- SQL_TEXT
fe
ns
bytes saved by
returned by smart
scan
storage index - PHYSICAL_READ_BYTES
- tra
physical write
total bytes
physical read
total bytes
-
no
PHYSICAL_WRITE_BYTESn
- IO_INTERCONNECT_BYTES
s a
cell physical IO
bytes sent directly -
) a
h eฺ
IO_CELL_OFFLOAD_ELIGIBLE_BYTES
V$SYSSTAT
to DB node to
balance CPU usage - r
ฺ Guid
b
IO_CELL_UNCOMPRESSED_BYTES
m
ฺco dent
- NAME cell physical IO - IO_CELL_OFFLOAD_RETURNED_BYTES
k o
-
ei St...u
bytes saved during OPTIMIZED_PHY_READ_REQUESTS
- VALUE
t
optimized file
te@ this
... creation
o r
p use
ฺ s uOracle
t e c
Copyright © 2012,
i k o ( ense
Inúmeraso
e
Testatísticas licespecíficas de célula são registradas em V$SYSSTAT e V$SESSTAT.
e c nic estatísticas podem ser usadas para monitorar as operações do Exadata Storage
Essas
T Server no nível de sistema e de sessão, bem como a eficácia do Smart Scan. Também há
estatísticas relacionadas aos seguintes recursos: Exadata Smart Flash Cache, Compressão
EHCC (Exadata Hybrid Columnar Compression), índice de armazenamento, criação rápida
de arquivos e backups incrementais otimizados. Além disso, outras estatísticas fornecem o
volume total de entrada/saída transferido pela interconexão e o volume total de leituras e
gravações físicas em disco. O slide lista uma seleção das estatísticas disponíveis.
A consulta do slide mostra as principais estatísticas de célula referentes à sessão atual.
Exemplos da saída dessa consulta são mostrados nas próximas páginas.
Além disso, V$SQL lista estatísticas sobre áreas SQL compartilhadas. Ele contém estatísticas
no nível de instrução sobre o volume de entrada/saída física (leituras e gravações), o volume
de entradas/saída transferido pela interconexão, juntamente com informações relacionadas à
eficácia do Smart Scan e de outros recursos do Exadata Storage Server.
Para obter mais informações sobre estatísticas específicas de célula, consulte o Oracle
Exadata Storage Server Software User's Guide.

Visão Geral dos Eventos de
Espera do Exadata Storage Server
SELECT DISTINCT event, total_waits, time_waited/100 wait_secs,
average_wait/100 avg_wait_secs
FROM V$SESSION_EVENT e, V$MYSTAT s

WHERE event LIKE 'cell%' AND e.sid = s.sid;
Evento de Espera Descrição

cell interconnect retransmit Espera do banco de dados durante a nova transmissão de uma
during physical read entrada/saída de uma leitura de bloco único ou de vários blocos
cell single block physical read Equivalente de db file sequential read na célula
cell multiblock physical read Equivalente de db file scattered read na célula
r a ble
Espera do banco de dados pela conclusão da varredura da fe
cell smart table scan
tabela
a n s
Espera do banco de dados pela varredura integraln r
-trápida de
cell smart index scan
índice ou IOT n o
Espera do banco de dados pela a
a
s de criação de arquivos
operação
cell smart file creation
r ) h e ฺde backup incremental
cell smart incremental backup b
ฺ Gu
Espera do banco de dados i d
pela operação
Espera do bancoo m
c ent a inicialização do arquivo
de dados durante
cell smart restore from backup
o ฺ
k tud
para restauração
t eidurante
Espera Sa consulta de views V$CELL
cell statistics gather
e @
rt e th i s
Copyright © 2012,
o (te nse
O Oracle T eikum conjunto
usa l ice específico de eventos de espera de entradas/saídas de disco para
on i co Storage Server. Informações sobre eventos de espera por célula são exibidas nas
Exadata
Tecviews dinâmicas de desempenho V$, como V$SESSION_WAIT, V$SYSTEM_EVENT e
V$SESSION_EVENT.
O slide mostra um exemplo de consulta usada para exibir um resumo dos eventos de espera
por célula da sessão atual. Exemplos da saída dessa consulta são mostrados nas próximas
páginas.
Também é mostrada uma lista de eventos de espera por célula com uma breve descrição.
A maioria dos eventos de espera por célula é autoexplicativa, entretanto, o evento cell
statistics gather é um pouco diferente. Ele aparece quando uma consulta é executada
na view V$CELL_STATE, V$CELL_THREAD_HISTORY ou V$CELL_REQUEST_TOTALS.
Durante essa consulta, os dados das células e quaisquer eventos de espera são mostrados
nesse evento de espera. Normalmente, essas views V$CELL são usadas apenas pelo Oracle
Support Services.
Observe que, para fins de uma análise detalhada, os eventos de espera por célula também
podem identificar o disco de célula e de grade correspondente que está sendo acessado, o
que tem maior utilidade para fins de desempenho e diagnóstico do que as informações sobre
o número de blocos e de arquivos de banco de dados fornecidas pelos eventos de espera do
armazenamento convencional.
Para obter mais informações sobre esses eventos de espera, consulte o Oracle Exadata
Storage Server Software User's Guide.
Exemplo de Estatísticas do Smart Scan
SQL> select count(*) from customers where cust_valid = 'A';

COUNT(*)
----------
8602831
Elapsed: 00:00:11.76
SQL> SELECT s.name, m.value/1024/1024 MB FROM V$SYSSTAT s, V$MYSTAT m

2 WHERE s.statistic# = m.statistic# AND
3 (s.name LIKE 'physical%total bytes' OR s.name LIKE 'cell phys%'
le
4 OR s.name LIKE 'cell IO%');
NAME MB
fe rab
----------------------------------------------------------------
physical read total bytes
----------
18005.6953
tra ns
physical write total bytes 0
n -
cell physical IO interconnect bytes no
120.670433
a
cell physical IO bytes sent directly to DB node to balance CPU u
cell physical IO bytes saved during optimized file creation
0
a
h eฺ
0 s
cell physical IO bytes saved during optimized RMAN file restore
b r
ฺ Guid) 0
cell physical IO bytes eligible for predicate offload
m 18005.6953
cell physical IO bytes saved by storage index
k o ฺco dent
cell physical IO interconnect bytes returned by smart scan
0
120.670433
cell IO uncompressed bytes
t ei Stu 18005.6953
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic exemplo de consulta apresentado anteriormente nesta lição. O
Te o primeiro
O slideomostra
e c nic de execução mostrado anteriormente na lição indicou o uso do Smart Scan. Isso é
plano
T confirmado pelas estatísticas exibidas após a consulta. As estatísticas mostram que, embora
a consulta tenha referenciado mais de 18000 MB de dados, o Smart Scan reduziu o volume
de entrada/saída transportado pela interconexão de armazenamento a pouco mais de 120
MB. Em outras palavras, o Smart Scan reduziu o volume de entrada/saída transportado para
o servidor de banco de dados em mais de 99% comparado ao que seria necessário se um
armazenamento diferente do Exadata fosse usado.
Observe que o volume de dados retornado pelo Smart Scan corresponde ao volume
transportado pela interconexão de armazenamento. Isso indica que todas as entradas/saídas
desse exemplo estão associadas ao Smart Scan.

Exemplo de Eventos de Espera do Smart Scan
COUNT(*)
----------
8602831
Elapsed: 00:00:11.76
SQL> SELECT DISTINCT event, total_waits, time_waited/100 wait_secs,

le
2 average_wait/100 avg_wait_secs
fe rab
ns
3 FROM V$SESSION_EVENT e, V$MYSTAT s
4 WHERE event LIKE 'cell%' AND e.sid = s.sid;
n - tra
EVENT TOTAL_WAITS WAIT_SECS
a no AVG_WAIT_SECS
---------------------------------------- ----------- ---------- s
9026 ha 11.05
-------------
r ) d e ฺ .0012
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 lic exemplo de consulta do slide anterior, mas, desta vez, os eventos
Te o mesmo
O slideomostra
ic associados à sessão da consulta são mostrados. Os eventos de espera confirmam
denespera
c
e
T que todas as entradas/saídas associadas à consulta foram satisfeitas com o Smart Scan.
Observe também que o tempo total de espera do Smart Scan (11,05 s) representa
praticamente todo o tempo decorrido da consulta (11,76 s). Isso significa que praticamente
todo o processamento dessa consulta ocorreu nas células do Exadata.

Exemplo de Transação Concorrente

COUNT(*)
----------
8602831
Elapsed: 00:02:13.55
NAME MB
---------------------------------------------------------------- ----------
physical read total bytes 19047.2266
cell physical IO interconnect bytes 4808.85828
le
0
0
fe rab
cell physical IO bytes saved during optimized RMAN file restore 0
tra ns
cell physical IO bytes eligible for predicate offload 18005.6953
n -
no
cell physical IO bytes saved by storage index 0
cell physical IO interconnect bytes returned by smart scan 3767.32703
s a
cell IO uncompressed bytes 18005.6953
) a
h AVG_WAIT_SECSฺ
EVENT
b
TOTAL_WAITS WAIT_SECSr i
ฺ Gu------------- d e
---------------------------------------- ----------- ----------
o m
cell list of blocks physical read
k o ฺc19238dent32,70
1 .0006
t e i t u 0,0017
cell single block physical read
@ s S
133286 74.91 .0006
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic a mesma consulta que a anterior, porém, desta vez, um processo
Te exatamente
O slideomostra
e c nic atualizou a tabela CUSTOMERS ao mesmo tempo. Os eventos de espera confirmam que
batch
T o Smart Scan ainda é usado, entretanto, desta vez, um grande número de leituras físicas
de um único bloco da célula também é necessário. As estatísticas quantificam o resultado.
Observe como a entrada/saída física transferida pela interconexão aumenta de
aproximadamente 120 MB no exemplo anterior para mais de 4800 MB nesse caso. Observe
também o aumento no tempo decorrido da consulta e sua correlação com os tempos de
espera.

Exemplo Extremo de Transação Concorrente

COUNT(*)
----------
8602831
Elapsed: 00:15:04.29
NAME MB
---------------------------------------------------------------- ----------
le
0
0
fe rab
tra ns
n -
no
s a
) a
h AVG_WAIT_SECSฺ
EVENT
b
ฺ Gu------------- d e
---------------------------------------- ----------- ----------
o m t 0
cell list of blocks physical read
k o ฺc den683.94
1 .0006
t e i 1349704
t u .0005
@ s S
9191 3.29 .0004
o r te thi
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k c
Desta vez,Ta consulta léi executada depois que outra sessão atualizou todas as linhas da tabela
o
e c nic
CUSTOMERS, mas antes de a transação de atualização ser submetida a commit (ou a rollback). Nesse
caso extremo, ainda há uma tentativa de usar o Smart Scan, entretanto, como todos os registros estão
T sujeitos a uma transação pendente, todas as entradas/saídas de blocos devem ser transferidas para o
caminho de consistência de leitura do cache de buffer tradicional. Nesse caso incomum, a tentativa de
usar o Smart Scan resultará em um tráfego de entrada/saída na interconexão de armazenamento
maior do que se o Smart Scan não fosse usado.
A seguir é apresentado um resumo dos resultados do mesmo cenário, mas com o Smart Scan
desativado:
SQL> select /*+ OPT_PARAM('cell_offload_processing' 'false') */
count(*) from customers where cust_valid = 'A';
Elapsed: 00:14:52.63
NAME MB
----------------------------------------------------- ----------
cell physical IO bytes eligible for predicate offload 0
EVENT TOTAL_WAITS WAIT_SECS AVG_WAIT

--------------------------------- ----------- --------- --------
cell single block physical read 1346130 678.83 .0005
cell list of blocks physical read 2 0 .0007

Exemplo de Linhas Migradas

COUNT(*)
----------
8602831
Elapsed: 00:00:14.02
NAME MB
---------------------------------------------------------------- ----------
le
0
0
fe rab
tr a ns
n -
no
s a
) a
h AVG_WAIT_SECSฺ
EVENT
b
ฺ Gu------------- d e
---------------------------------------- ----------- ----------
o m
c en13.19 t .14
k o ฺ10880
236 .0006
ei St17ud .02
cell smart table scan .0012
cell multiblock physical read
@ t .0009
r te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Nesteo Te a tabela
exemplo, lic CUSTOMERS foi atualizada o que resultou na migração de linhas em
e c nic
aproximadamente 6,5% dos seus blocos de dados. Agora, quando a consulta é executada,
T o tempo da consulta, as estatísticas e os eventos de espera se aproximam dos valores
originais observados quando não há linhas migradas. Entretanto, ainda há uma diferença
notável entre o volume de dados retornado pelo Smart Scan e o volume de entrada/saída
da interconexão física. Essa diferença, junto com os eventos de espera de leitura física de
células, são sintomas da migração de linhas existente na tabela CUSTOMERS.

Exemplo de Entrada/Saída Enviada Diretamente
para o Servidor de Banco de Dados
para Balancear o Uso de CPU
COUNT(*)
----------
8602831
Elapsed: 00:01:42.59
NAME MB
---------------------------------------------------------------- ----------
le
cell physical IO interconnect bytes
2475.24233
2394.57133
fe rab
cell physical IO bytes saved during optimized file creation 0
tra ns
cell physical IO bytes saved during optimized RMAN file restore
n
0
-
no
s a
cell physical IO interconnect bytes returned by smart scan
cell IO uncompressed bytes
) a
2475.24233
h eฺ
18005.6953
b r id
ฺ GuAVG_WAIT_SECS
EVENT
m
TOTAL_WAITS WAIT_SECS
o ---------- t -------------
---------------------------------------- -----------
k o ฺc9128 d e n
t e i t u 98.19 .0108
e @ i s S
r t
o se t h
u p
Copyright © 2012,
e
t
o ( ense
i k ic Server versão 11.2.2.3.0, o Exadata Storage Server pode enviar
A partir
o TeExadata lStorage
do
ic de dados novamente ao servidor de banco de dados para processamento, em
osnblocos
c
e
T vez de processá-los na célula. Isso acontece quando o uso de CPU do servidor de
armazenamento atinge um limite interno e há capacidade sobressalente de CPU disponível
na camada de banco de dados. O objetivo é otimizar a utilização geral dos recursos de CPU
no Exadata Database Machine.
Esse comportamento é indicado por um valor diferente de zero associado à estatística cell
physical IO sent directly to DB node to balance CPU usage e geralmente
indica que os servidores de armazenamento estão ocupados executando atividades que
consomem muitos recursos de CPU. Por exemplo, isso poderá ocorrer quando várias
operações concorrentes do Smart Scan já estão sendo processadas ou quando as células
estão ocupadas executando várias operações concorrentes de descompactação de dados.
Neste exemplo, praticamente 2400 MB de dados foram enviados ao servidor de banco de
dados a fim de tentar balancear o uso de CPU no ambiente. Embora a consulta tenha ficado
significativamente mais lenta do que quando executada com a capacidade total do Smart
Scan, o resultado obtido poderá ser melhor do que se os servidores de armazenamento já
ocupados fossem ainda mais sobrecarregados.

Exemplo de Filtragem de Coluna
SQL> select * from customers;

----------------------------------------------------------------------------

----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1239K| 244M| 10242 (1)|
| 1 | TABLE ACCESS STORAGE FULL| CUSTOMERS | 1239K| 244M| 10242 (1)|
----------------------------------------------------------------------------
NAME MB
---------------------------------------------------------------- ----------
cell physical IO bytes eligible for predicate offload 0
cell physical IO interconnect bytes returned by smart scan 0
le
SQL> select cust_email from customers;
fe rab
----------------------------------------------------------------------------
tr a ns
n -
----------------------------------------------------------------------------
|
|
0 | SELECT STATEMENT | | 1239K|
1 | TABLE ACCESS STORAGE FULL| CUSTOMERS | 1239K|
20M| 10235
20M| 10235no (1)|
(1)| a
a s
----------------------------------------------------------------------------
h eฺ MB
NAME
b r )
ฺ Gu---------- id
m
----------------------------------------------------------------
ฺco dent 29.0223618

cell physical IO interconnect bytes
k o
cell physical IO bytes eligible for predicate
t ei by Ssmart
t u scan
offload 290.289063
e @
cell physical IO interconnect bytes returned
rt e th i s
29.0223618

Copyright © 2012,
o (te nse
T eikexamina
Este exemplo l iceo impacto da filtragem de colunas com o uso de duas consultas SQL
n i co
simples.
Tec A consulta mostrada na parte superior do slide seleciona a tabela Customers inteira. O
plano de execução associado mostra que a varredura da tabela é descarregada no Exadata
Storage Server. Entretanto, como a consulta solicita que toda a tabela seja retornada, a
tabela inteira deve ser transportada pela rede de armazenamento.
A consulta na parte inferior do slide seleciona apenas uma coluna da tabela customers.
Observe que o plano de execução associado não fornece qualquer notificação explícita sobre
a filtragem de colunas. Ele indica que o otimizador espera processar um volume menor de
dados (20M bytes comparados a 244M bytes), o que poderá ser usado para deduzir que
a filtragem de colunas ocorrerá. As estatísticas associadas à consulta comprovam que a
filtragem de colunas ocorre. Desta vez, a tabela inteira é elegível para o descarregamento
de predicados e somente os dados associados à coluna cust_email são transportados
pela rede de armazenamento.

Resumo

• Descrever o Smart Scan e o processamento de consultas

que pode ser descarregado no Exadata Storage Server
• Descrever os requisitos do Smart Scan
• Descrever as circunstâncias que impedem o uso do Smart
Scan
• Identificar o Smart Scan nos planos de execução de SQLerab
le
n s f
• Usar estatísticas de banco de dados e eventos de espera
tra
n -
no
para confirmar como as consultas são processadas
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

Questionário
O parâmetro de inicialização CELL_OFFLOAD_PLAN_DISPLAY

ativa o Smart Scan:

a. VERDADEIRO
b. FALSO
le
fe rab
tr a ns
n -
ano
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
Onparâmetro CELL_OFFLOAD_PROCESSING é usado para ativar o Smart Scan.
c
T e

Questionário
O Smart Scan está ativado e o plano da consulta indica o seu

uso. Entretanto, a estatística cell physical IO

interconnect bytes returned by smart scan
mostra valores maiores do que o esperado. Qual das
seguintes opções poderia ser a causa?
a. Linhas migradas
b. Varredura integral de uma tabela organizada por índice rab
le
c. Transações concorrentes não submetidas a committran
sfe
-
d. non
Uma varredura integral rápida de um índice compactado
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
Resposta:
o Ta,e c lic
ic
OnSmart Scan é usado, na medida do possível, nessas duas situações; no entanto, nos
c
T e dois casos, a sua eficiência é reduzida. O Smart Scan não pode ser usado para as outras
situações.

Usando o Smart Scan
Nestes exercícios, você testará o Exadata Smart Scan e
examinará diversas estatísticas e eventos de espera para

determinar o que está ocorrendo.
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

Opções e Recomendações de Consolidaçã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 as opções para a consolidação de vários

bancos de dados no Database Machine
• Descrever as vantagens e os custos associados a
diferentes opções
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 da Consolidação
• Por que consolidar:

– Minimizar os recursos ociosos

– Maximizar a eficiência
– Reduzir os custos
• Exemplos de consolidação:
– Hospedar vários servidores virtuais em um servidor físico
– Hospedar várias aplicações em um servidor r a ble
– Suportar vários usuários diferentes em uma instância a n
da sfe
aplicação n - tr
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 ic TI, a consolidação é uma das principais estratégias usadas
Te
Nos departamentos
o lde
por c
niorganizações de todos os tipos para aumentar a eficiência de suas operações.
T e c
Essencialmente, a consolidação permite que as organizações aumentem a utilização dos
recursos de TI de modo que os ciclos ociosos possam ser minimizados. Isso, por sua vez,
reduz os custos porque são necessários menos recursos para alcançar o mesmo resultado.
Por exemplo, as aplicações que apresentam picos de carga em horários diferentes do dia
podem compartilhar o mesmo hardware, em vez de usar um hardware dedicado que poderá
ficar ocioso durante os períodos de menor atividade.
A consolidação poderá ser alcançada de diversas maneiras dependendo dos sistemas e das
circunstâncias envolvidos. A execução de várias máquinas virtuais ou várias aplicações em
um único servidor são exemplos de consolidação. O uso de uma instância de uma aplicação
para suportar diferentes populações de usuário, possivelmente de organizações ou LOBs
(lines of business) diferentes, é outro exemplo de consolidação.
O desempenho e a capacidade do Exadata Database Machine fazem dele a plataforma de
consolidação ideal. Esta lição descreve a abordagem recomendada para a consolidação no
Database Machine, bem como algumas das principais alternativas. As vantagens e os custos
de cada abordagem também serão discutidos. Observe que as recomendações desta lição
têm como objetivo fornecer uma base sólida na maioria das circunstâncias. Elas devem ser
usadas como orientação, mas não devem ser seguidas cegamente uma vez que abordagens
alternativas poderão ser mais eficazes em determinadas circunstâncias.
Diferentes Tipos de Consolidação
• Consolidação de Esquemas de Aplicação:

– Vários esquemas de aplicação consolidados em um único

banco de dados
– Uma instância do banco de dados (ou um conjunto de
instâncias do RAC)
– Um banco de dados a ser gerenciado
• Consolidação de Bancos de Dados: le
– Vários bancos de dados consolidados em uma única fe rab
plataforma tra ns
n -
no
– Instâncias separadas para cada banco de dados
a
has eฺ
– Gerenciamento de bancos de dadosr)separados
m ฺb Guos
– Os bancos de dados devem compartilhar
idrecursos da
plataforma k o ฺco dent
i te Stu
r @
te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Te emlilinhas
O slide descreve
c gerais dois tipos de consolidação geralmente associados ao Oracle
ic o
Database.
e c
A
nconsolidação de esquemas de aplicação é o processo pelo qual vários esquemas de
T aplicação são hospedados em um único banco de dados. A principal vantagem desse tipo de
consolidação é que ela permite evitar o overhead associado a várias instâncias do banco de
dados. A principal desvantagem é que os esquemas de aplicação tornam-se inexoravelmente
vinculados, o que poderá causar dificuldades em determinadas circunstâncias. Por exemplo,
se uma aplicação puder se beneficiar de um upgrade do banco de dados e a outra não estiver
certificada para a versão desse banco de dados com upgrade, algum tipo de concessão será
inevitável. Além disso, em algumas circunstâncias, poderá haver conflitos entre os esquemas
de aplicação, tornando a consolidação inviável. Por exemplo, se duas aplicações contiverem
definições públicas de sinônimos com o mesmo nome, esse conflito poderá comprometer uma
das aplicações.
Em termos gerais, há poucas recomendações relacionadas à consolidação de esquemas de
aplicação, pois é necessário configurar e gerenciar apenas um banco de dados. As
recomendações para a consolidação de esquemas de aplicação são consideradas no final da
lição.
A consolidação de bancos de dados é processo pelo qual vários bancos de dados são
hospedados em uma única plataforma, como um Database Machine. Nesse tipo de
consolidação, um certo grau de autonomia é mantido para cada banco de dados. Cada bancos
de dados usa instâncias separadas e cada um deles é gerenciado separadamente. No entanto,
todos os bancos de dados devem compartilhar os recursos da plataforma subjacente. A maior
parte desta lição descreve as recomendações associadas à consolidação de bancos de dados
no Exadata Database Machine.
Princípios Básicos da
Consolidação de Bancos de Dados
• Consolide bancos de dados com objetivos semelhantes de
disponibilidade e de manutenção planejada

• Outras considerações são o desempenho, os requisitos de
sistema, a segurança e os limites organizacionais
• A consolidação de aplicações no Database Machine é
possível, mas não é recomendada
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
TeDatabaselicMachine é uma plataforma de consolidação adequada para bancos de
O Exadata
o
ic Oracle. A arquitetura de grade na qual o armazenamento do Exadata e o software
ecn
dados
T Oracle RAC (Real Application Clusters) se baseiam oferece várias opções possíveis de
configuração da consolidação.
Ao considerar a consolidação de bancos de dados no Database Machine, alguns princípios
básicos devem ser aplicados. Em primeiro lugar, os objetivos de disponibilidade e de
manutenção planejada dos bancos de dados candidatos à consolidação devem ser
semelhantes. Caso contrário, um dos sistemas será inevitavelmente comprometido de
alguma forma. Por exemplo, se um sistema de negócios crítico compartilhar o mesmo
ambiente que um sistema de desenvolvimento, as operações de negócios serão
interrompidas se o sistema tiver um patch aplicado e for reinicializado ou as atividades de
desenvolvimento serão interrompidas se o patch não for aplicado.
Outras considerações, como os objetivos de desempenho, os requisitos de sistema, a
segurança e os limites organizacionais, também devem ser considerados para garantir a
compatibilidade entre os diversos candidatos à consolidação. Por exemplo, se uma diretiva
de segurança determinar a separação física dos dados em dois sistemas diferentes,
certamente eles não seriam um bom candidato para a consolidação.
Por fim, embora seja tecnicamente viável hospedar aplicações que não sejam de banco de
dados nos servidores de banco de dados do Database Machine, isso não é recomendado
principalmente porque a alteração do software do Database Machine para atender aos
requisitos da aplicação poderá degradar o desempenho e a disponibilidade do Database
Machine.
Abordagem de Consolidação Recomendada
• Categorize os bancos de dados em três grupos:

– Crítico: relacionados ao negócio principal, geradores de

receita, voltados ao cliente
– Padrão: outros bancos de dados de produção não críticos
– Não produção: bancos de dados de desenvolvimento e de
teste
• Crie ambientes (pods) que consolidem os bancos de le
dados em cada grupo, mas não entre os grupos: fe rab
tra do ns
– Consolide os bancos de dados usando um ou doisn -
racks
Exadata Database Machine por pod a no
– Os bancos de dados que exigem mais
) h
deasdoisฺracks devem
r uide
ter um pod dedicado mฺb co ent G
o ฺ
t eik Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licé recomendada para a consolidação de bancos de dados usando
Te a seguir
A abordagem
o
ic
ecn
o Database Machine. Primeiro, categorize os bancos de dados em três grupos. Os
T agrupamentos sugeridos são listados no slide e se baseiam nos requisitos semelhantes
dos bancos de dados incluídos em cada grupo.
Em cada grupo, os bancos de dados podem ser consolidados no mesmo ambiente do
Exadata Database Machine. Para garantir uma terminologia consistente em toda esta lição,
o termo "pod" será usado para se referir a cada ambiente consolidado. Não é recomendável
consolidar bancos de dados de mais de um grupo no mesmo pod.
Além disso, é recomendável limitar o tamanho de um pod a dois racks do Database Machine.
Isso deverá garantir amplo espaço e capacidade para a maioria dos requisitos. Quando for
necessária uma capacidade maior, vários pods deverão ser considerados uma vez que a
complexidade envolvida no gerenciamento de um ambiente extremamente grande começará
a comprometer as vantagens da consolidação.
Bancos de dados individuais que exigem mais de dois racks provavelmente não serão bons
candidatos para a consolidação e deverão ser mantidos em seu próprio ambiente.

Configuração de Armazenamento
Recomendada para a Consolidação
• Uma grade de armazenamento compartilhada do Exadata por pod:
– Grupos de discos recomendados:

— DATA para arquivos de banco de dados
— RECO para a FRA (Fast Recovery Area)
— DBFS_DG para arquivos compartilhados do clusterware e DBFS
– Use a redundância alta para o grupo DATA
– Distribua os grupos de discos por striping entre todas as células e
todos os discos
r a ble
– Use o IORM para gerenciar e alocar recursos de entrada/saída n s fe
– Defina o atributo COMPATIBLE.RDBMS do grupo de discos n - tracomo a
o
versão mínima do software de banco de dados usada an
• Vantagens: ) h as ฺ
– Configuração padrão; mais fácil de m ฺbr Guide
gerenciar
– Configuração balanceada; alta o co ent e desempenho;
ฺdisponibilidade
t k
ei Stud
adequada à maioria das circunstâncias
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic
T
A configuração de armazenamento recomendada para a consolidação é usar uma grade de
i co
armazenamento ASM compartilhada para cada ambiente consolidado (pod). A configuração de
n
Te c
grupo de discos default resultante do processo de configuração do OneCommand deve ser
usada. Por default, o grupo de discos DBFS_DG é usado para armazenar os arquivos
compartilhados do clusterware (registro do cluster e arquivos de votação) e também pode ser
usado para armazenar um sistema de arquivos com o recurso de banco de dados DBFS. Use
o grupo de discos DATA para armazenar arquivos de banco de dados e o grupo de discos
RECO para armazenar principalmente a FRA. Com o processo do OneCommand, os grupos
de discos DATA e RECO serão configurados com stripes de disco de tamanho idêntico (discos
de grade) em cada disco e célula do Exadata.
Quando possível, é recomendável usar a definição de redundância alta para o grupo de discos
DATA. Isso fornecerá a proteção máxima contra interrupções do funcionamento das células e
falhas de armazenamento. Para pods críticos, o Oracle data guard também é recomendado.
Para ambientes consolidados, o Exadata IO Resource Management (IORM) é uma ferramenta-
chave. Ele oferece uma maneira flexível de gerenciar os recursos de entrada/saída a fim de
garantir que as cargas de trabalho dos bancos de dados sejam priorizadas de acordo com as
políticas especificadas. Observe que, no momento, o IORM não prioriza as gravações,
portanto, um cuidado especial é necessário ao consolidar aplicações com muitas operações de
gravação.
A configuração de armazenamento recomendada apresenta as seguintes vantagens
importantes. Em primeiro lugar, ela é conceitualmente simples e inerentemente fácil de
gerenciar; além disso, é a configuração mais conhecida e mais suportada. Em segundo lugar,
é uma configuração balanceada adequada para a maioria das circunstâncias, bem como
fornece um alto nível de disponibilidade e desempenho.
Configurações de Armazenamento Alternativas
Particionamento por Célula

Célula 1 Célula 2 Célula 3 Célula 4
DATA1 DATA2
RECO1 RECO2
le
Particionamento por Disco fe rab
Célula 1 Célula 2 Célula 3
tr
Célula 4 ans
DATA3 n -
no a
RECO3
a
h eฺ s
DATA4 r
ฺ Guid
b )
m
RECO4
k o ฺco dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licilustram duas estratégias alternativas de configuração do
Te do slide
Os diagramas
o
c ic
armazenamento.
nparte
T e A superior do slide ilustra o particionamento do armazenamento no nível de célula.
Nessa configuração, diferentes grupos de discos, ou conjuntos de grupos de discos, são
configurados em grupos de células separadas. Na ilustração, um conjunto de grupos de
discos (DATA1 e RECO1) é armazenado em um conjunto de células (Célula 1 e Célula 2), e
outro conjunto de grupos de discos (DATA2 e RECO2) é armazenado em um conjunto
diferente de células (Célula 3 e Célula 4). A mesma ideia poderia ser estendida para
acomodar mais conjuntos de grupos de discos ou modificada de forma que os grupos de
discos DATA e RECO ocupem células separadas.
A parte inferior do slide ilustra o particionamento do armazenamento do Exadata por discos
nas células. Nessa configuração, grupos de discos diferentes são configurados em um
subconjunto de discos em cada célula. Na ilustração, um conjunto de grupos de discos
(DATA3 e RECO3) é armazenado na metade dos discos em cada célula, e outro conjunto
(DATA4 e RECO4) é armazenado nos demais discos em cada célula. A mesma ideia poderia
ser estendida para acomodar mais conjuntos de grupos de discos ou modificada de forma
que grupos de discos diferentes ocupem um número específico de discos em cada célula.
As configurações de armazenamento mencionadas anteriormente também podem ser
implementadas junto com a segurança do armazenamento do Exadata no escopo do banco
de dados a fim de permitir uma separação mais eficiente do armazenamento associado a
diferentes bancos de dados. A segurança do armazenamento do Exadata é discutida na lição
Configuração do Exadata Storage Server.
Outras configurações de armazenamento alternativas podem ser criadas combinando-se as
duas abordagens de particionamento descritas aqui.
Vantagens e Limitações das Configurações de
Armazenamento Particionado
• Vantagens:
9 Isolamento do armazenamento
— Grupos de discos e bancos de dados diferentes podem ocupar células

ou discos separados
9 Isolamento de patches
— Níveis diferentes de patches podem ser aplicados a diversos conjuntos
de células
• Limitações:
le
2 Configuração manual
fe rab
— As configurações particionadas precisam ser feitas manualmente
tra ns
n -
2 Largura de banda reduzida de entrada/saída no a
— Uma única operação não pode utilizar a grade de armazenamento
a
h eฺ s
inteira r
ฺ Guid
b )
2 Maior overhead de gerenciamento m
Duplicação de comandos k o ฺco dent
—
t eiespeciais
S tu
— Necessidade de ajustes
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
( nse
k o
As opções de
T e i
configuração
l i ce de armazenamento alternativas apresentam as seguintes vantagens
n i cOoparticionamento de grupos de discos em células ou discos separados fisicamente
e limitações:
Tec permite melhor isolamento entre as atividades nos diversos grupos de discos. Por
9
exemplo, isso poderá ser vantajoso quando as políticas de segurança determinam a
separação física dos dados ou quando os clientes desejam isolar a entrada/saída de
bancos de dados diferentes.
9 Com a abordagem de particionamento por células, níveis diferentes de patches podem ser
aplicados às diversas células. Esse isolamento de patches poderá ser útil quando um
patch for necessário para um banco de dados, mas poderá ter consequências não
desejadas em outro.
2 As configurações de armazenamento não padrão devem ser definidas manualmente,
exigindo planejamento e esforço adicionais quando comparadas às configurações
recomendadas.
2 Todas as configurações alternativas em que os grupos de discos não são distribuídos por
striping entre todos os discos de todas as células devem ter menor capacidade de largura
de banda de entrada/saída quando comparadas à configuração de armazenamento
padrão recomendada.
2 As configurações de armazenamento não padrão exigem maior esforço de gerenciamento.
No mínimo, a existência de mais grupos de discos aumenta o número de comandos
necessários para gerenciá-los. Além disso, as operações de gerenciamento que se
baseiam em uma configuração de armazenamento padrão talvez precisem ser alteradas
para funcionarem em um ambiente não padrão. Por exemplo, as instruções fornecidas
com um patch talvez precisem de ajuste para acomodar uma configuração de
armazenamento não padrão.
Opções de Configuração de Cluster
• Configuração recomendada:
– Use um cluster por pod

– Use serviços de banco de dados para gerenciar as cargas
de trabalho dos bancos de dados nos servidores disponíveis
– Use o Oracle data guard para oferecer proteção contra
falhas de cluster em pods críticos
• Configuração alternativa: le
– Configure vários clusters por pod fe rab
tr a ns
-
9 Melhor isolamento em caso de falhas de cluster e patches
n
2 Exige configuração manual a no
h as ฺ
2 Maior esforço e complexidade de gerenciamento
) e
br uiddiscos
— Requer um conjunto separado de ฺgrupos de para cada
o m t G
cluster
i k oฺc uden
tepor cluster
— O mínimo de três nós
St é recomendado
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic recomendada para o Exadata Database Machine é usar um cluster
Te de cluster
A configuração
o
paraiccada ambiente (pod). Para ambientes de consolidação, serviços de banco de dados
Tecnsão recomendados como o principal recurso de gerenciamento das cargas de trabalho dos
bancos de dados nos servidores disponíveis. Para pods críticos, o uso do Oracle data guard
é recomendado para oferecer proteção contra falhas de cluster.
Há suporte para a execução de vários clusters em um único Exadata Database Machine.
Nesse modo, cada cluster ocupa um subconjunto separado de servidores de banco de
dados. Essa alternativa poderá oferecer melhor isolamento em caso de falha no cluster ou se
for necessário aplicar um patch no software Grid Infrastructure. Assim como as configurações
de armazenamento não padrão, as configurações de cluster não padrão exigem configuração
manual, bem como envolvem maior esforço e complexidade de gerenciamento.
Além disso, uma configuração de cluster não padrão implica uma configuração de
armazenamento não padrão uma vez que os grupos de discos não podem ser
compartilhados entre os diferentes clusters. Consulte as vantagens e as limitações
associadas às configurações de armazenamento não padrão antes de considerar uma
configuração de cluster não padrão.
Por fim, se você optar por implementar uma configuração de cluster não padrão, é
recomendável ter, no mínimo, três nós em cada cluster.

Recomendações de Parâmetros do
Sistema Operacional
• Defina o número de segmentos de memória compartilhada
(SHMMNI) como sendo maior que o número de bancos de dados

• Defina o tamanho máximo do segmento de memória
compartilhada (SHMMAX) como 85 % do tamanho da memória
física
• Defina o número total máximo de semáforos do sistema
(SEMMNS) como sendo maior que a soma de todos os processos
de banco de dados
r a ble
• Defina o número máximo de semáforos em um conjunto densfe
semáforos (SEMMSL) como sendo maior que o número n - ra
tmáximo
de processos de um único banco de dados a no
• Para o Linux, se PageTables em /proc/meminfo
) h as ฺ for > 2% do
tamanho da memória física, considere
m ide
r uHugePages
ฺbdefinir como a
o
deฺcmemória t G
soma de todos os segmentos o en compartilhada
ik d
Stu401749.1 e 361468.1
te notes
– Consulte My Oracle Support
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic de parâmetros do sistema operacional Linux recomendadas para
sãoTas definições
Estas o
e c nic
consolidação:
T • Defina o número de identificadores de memória compartilhada como sendo maior
que o número de bancos de dados em execução no nó. Verifique a definição de
kernel.shmmni usando o comando sysctl. Se necessário, faça ajustes definindo
kernel.shmmni em /etc/sysctl.conf.
• Defina o tamanho máximo do segmento de memória compartilhada como 85% do
tamanho da memória física do servidor de banco de dados. Verifique a definição de
kernel.shmmax usando o comando sysctl. Se necessário, faça ajustes definindo
kernel.shmmax em /etc/sysctl.conf.
• Defina o número máximo de semáforos no sistema como sendo maior que a soma dos
processos de todos os bancos de dados em execução no sistema. Verifique a definição
de kernel.sem usando o comando sysctl. A definição de kernel.sem contém uma
lista de quatro valores numéricos. A definição do número total de semáforos do sistema,
também conhecida como SEMMNS, é o segundo valor da lista. Se necessário, faça
ajustes definindo kernel.sem em /etc/sysctl.conf.

• Defina o número máximo de semáforos em um conjunto de semáforos como sendo
maior que o número máximo de processos de um único banco de dados em execução
no sistema. Verifique a definição de kernel.sem usando o comando sysctl. A
definição do número máximo de semáforos em um conjunto de semáforos, também
conhecida como SEMMSL, é o primeiro valor da lista. Se necessário, faça ajustes
definindo kernel.sem em /etc/sysctl.conf.
Observe que, embora as recomendações de parâmetros do sistema operacional descritas
anteriormente sejam específicas do Linux, as recomendações relacionadas à memória

compartilhada e aos semáforos também se aplicam ao Solaris. O Oracle Solaris usa
a funcionalidade de controle de recursos como uma alternativa ao uso do arquivo
/etc/system para implementar o System V IPC. Entretanto, a Oracle recomenda que tanto
o controle de recursos como os parâmetros /etc/system sejam definidos. Consulte a
documentação do Solaris para obter mais informações sobre o controle de recursos e os
parâmetros de kernel IPC (System V).
le
fe rab
Além disso, os usuários do Linux devem considerar a possibilidade de usar o recurso
tra ns
HugePages. Esse é um recurso do kernel do Linux que permite tamanhos maiores de
página no sistema operacional. Isso, por sua vez, permite que os processos que fazem
n -
a no
referência a grandes volumes de memória tenham tabelas de página menores, reduzindo,
assim, o uso de memória dessas tabelas. Considere a implementação do recurso
a s
h eฺ
HugePages se PageTables em /proc/meminfo for > 2% da memória física. Quando
r )
ฺ Guid
b
definido, HugePages deve ser igual à soma da memória compartilhada usada por todos
m
k o ฺco dent
os bancos de dados. Se todas as instâncias de banco de dados estiverem em execução, o
ei Stu
volume de memória compartilhada em uso poderá ser calculado analisando-se a saída do
t
te@ this
comando ipcs -m. My Oracle Support note 401749.1 fornece um script que pode ser usado
o r
para determinar o volume de memória compartilhada em uso. My Oracle Support note
s up use
361468.1 descreve como definir HugePages no Linux de 64 bits.
ฺ
( t ec se to
e i ko licen
o T
ic
Tecn

Recomendações de Memória do Banco de Dados
• Para OLTP:
– soma(PGA_AGGREGATE_TARGET + SGA_TARGET)de todos

os bancos de dados em cada servidor deve ser inferior a
75% do tamanho da memória física do servidor
• Para data warehousing:
– soma(3 x PGA_AGGREGATE_TARGET) + SGA_TARGET)de
todos os bancos de dados em cada servidor deve ser inferior
a b le
a 75% do tamanho da memória física do servidor fe r
a ns
n- t r
a no
) 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 é que as áreas de memória das instâncias (SGA mais PGAs) de todos
Te geral
A recomendação
o
ic de dados em uma definição de consolidação devam ocupar menos de 75% da
ecn
os bancos
T memória física em um servidor de banco de dados. Se o uso de memória recomendado for
excedido, isso poderá causar problemas de desempenho. Se forem necessários ajustes para
acomodar os bancos de dados existentes dentro do limite recomendado, verifique se os
valores resultantes são suficientes para as aplicações que usam os bancos de dados
associados.
Observe que a definição do parâmetro de banco de dados PGA_AGGREGATE_TARGET não
impõe um valor máximo fixo para o uso da PGA. Em algumas aplicações de data warehouse,
foi observado um valor igual a três vezes a meta especificada. Para aplicações OLTP, a
saturação potencial é geralmente bem menor.
O espaço restante da memória física é usado para diversas alocações de memória
específicas de processo e garante proteção contra saturações adicionais da PGA. O
monitoramento da utilização de memória da aplicação e do sistema é necessário para
garantir que haja memória suficiente durante os ciclos de carga de trabalho e de negócios.
A Oracle recomenda que haja sempre pelo menos 5% de memória livre.

Recomendações Sobre o Gerenciamento da CPU
• Use o recurso Instance Caging para evitar que bancos de

dados individuais consumam muita CPU

• Definições do parâmetro CPU_COUNT recomendadas:
– Para pods críticos: soma(CPU_COUNT) < 75% do número
total de núcleos de CPU (CPU cores)
– Caso contrário:
— Para bancos de dados que consomem muitos recursos de CPU:
soma(CPU_COUNT) <= o numero total de núcleos de CPU (CPU ble
cores)
s fera
Para bancos de dados que consomem poucos recursos t r den
a
n- de
—
CPU: soma(CPU_COUNT) <= três vezes o número ototal

núcleos de CPU (CPU cores) a n
ha controlar s
• Use o Database Resource Managerrpara
) d e ฺ a
alocação de CPU em cada banco b
ฺ Gu i
om de dados
ฺc den t
– Use o atributo de diretivai k oMAX_UTILIZATION_LIMIT
u
para
e
detCPU pelos
limitar a utilização @ t
S grupos de consumidores
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c ferramenta importante para o gerenciamento de recursos de CPU
TeCaging éliuma
O Instance
o
c
em iambientes
ecn
de consolidação onde cada servidor de banco de dados hospeda várias
T instâncias de banco de dados. O recurso Instance Caging usa o parâmetro de inicialização
CPU_COUNT para especificar o número máximo de núcleos de CPU (CPU cores) que um
banco de dados pode usar simultaneamente.
Esse recurso pode ser usado para garantir que as instâncias não compitam entre si por
recursos de CPU. Ele também pode ser configurado de forma que as alocações de CPU
sejam superprovisionadas.
Por exemplo, um servidor com 32 núcleos de CPU (CPU cores) poderá hospedar quatro
bancos de dados, cada um com CPU_COUNT definido como 16. Essa configuração é
aceitável quando a maioria dos bancos de dados está ociosa ou tem padrões de uso
distintos. Isso garante que nenhum banco de dados sobrecarregue o sistema inteiro. Porém,
se todos os bancos de dados ficarem sobrecarregados ao mesmo tempo, certamente haverá
uma disputa por recursos de CPU e uma degradação do desempenho.
Estas são as diretrizes recomendadas para a definição do parâmetro CPU_COUNT:
• Para pods críticos, o total dos valores do parâmetro CPU_COUNT em todos os bancos
de dados deve ser inferior a 75% do número total de núcleos de CPU (CPU cores) do
servidor. Essa alocação deverá garantir que não haja falta de recursos de CPU nos
bancos de dados. Os 25% restantes de recursos de CPU são reservados para outros
processos, como ASM e clusterware.

• Para pods não críticos, é possível praticamente evitar a falta de recursos de CPU
em qualquer banco de dados alocando para todos eles valores de CPU_COUNT que
correspondam ao número de núcleos de CPU (CPU cores) no servidor. Essa política
é aceitável para bancos de dados que consomem muitos recursos de CPU, como os
que executam consultas analíticas grandes ou volumes elevados de processamento
PL/SQL.
• No caso de bancos de dados que consomem menos recursos de CPU ou que têm
períodos ativos e ociosos diferentes, o superprovisionamento dos recursos de CPU

é uma abordagem válida. Um valor total de CPU_COUNT igual a três vezes o número
disponível de núcleos de CPU (CPU cores) é aceitável. Lembre-se de que você deve
monitorar o ambiente e poderá ajustar dinamicamente as definições de CPU_COUNT
para tratar de diferentes ciclos de processamento.
Observe que, para ativar o Instance Caging, é necessário definir o parâmetro de
inicialização CPU_COUNT, bem como ativar o Database Resource Manager usando o
le
parâmetro de inicialização RESOURCE_MANAGER_PLAN. Você pode definir o parâmetro
RESOURCE_MANAGER_PLAN para usar o plano predefinido DEFAULT_PLAN como um valor fe rab
inicial básico. ns
tra
n -
O Database Resource Manager também é recomendado para o gerenciamento
a no dos recursos
de CPU em cada banco de dados. Ele pode ser configurado paraso compartilhamento desses
recursos entre as cargas de trabalho dos bancos de dados. r ) hadefault,
Por e ฺ o Resource Manager
só interfere na alocação dos recursos de CPU quando b i
ฺa utilização d
u aumenta a ponto de haver
o m t G
uma disputa. Em outras palavras, uma carga o deฺctrabalho n
poderá consumir todos os recursos
i k d e
@ te de CPU
disponíveis se nenhuma outra estiver competindo
S tu eles. Entretanto, se quiser definir
por
um limite superior para o compartilhamento
t h i s
rte MAX_UTILIZATION_LIMIT
alocado para determinada carga de
u o
trabalho, você poderá usar apdiretiva
s e do Resource Manager.
e c ฺs to u
t
o ( ense
i k lic
o Te
e c nic
T

Outras Recomendações
• Configure o IO Resource Management

• Definição de DB_RECOVERY_FILE_DEST_SIZE:
– soma(DB_RECOVERY_FILE_DEST_SIZE) < tamanho

utilizável da FRA
• Gerenciamento de processos:
– PARALLEL_THREADS_PER_CPU = 1
– X2-2: soma(PARALLEL_MAX_SERVERS) <= 240
le
– X2-8: soma(PARALLEL_MAX_SERVERS) <= 1280
fe rab
• Diretrizes sobre processos e conexões: tra ns
n -
– Processos ativos <= 4 x CPU_COUNT no
– Use pools de conexões para gerenciar a ฺ de
hconexões sa
)
ฺb Guide
r
aplicações m
ฺco dedenttaxa de conexão para
– Use a funcionalidade deklimitação
o
t ei Stu
evitar storms de conexão
@ r te this
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
As seguintes
o lic
Te recomendações adicionais se aplicam à consolidação de bancos de dados:
i c
Tecn• O Exadata IO Resource Management (IORM) fornece recursos avançados que são
muito úteis para a consolidação de bancos de dados. O IORM é abordado em detalhes
em outra lição.
• Verifique se o parâmetro DB_RECOVERY_FILE_DEST_SIZE de cada banco de dados
está definido de forma que a soma de todos os tamanhos seja menor que a área FRA
utilizável. A área FRA utilizável é o tamanho da FRA menos o espaço consumido por
arquivos, como as cópias espelhadas dos arquivos de redo log on-line e dos arquivos
de controle.
• Verifique se o parâmetro PARALLEL_THREADS_PER_CPU está definido como 1. Essa
definição é adequada para a arquitetura de CPU Intel de vários núcleos do Database
Machine.
• Verifique se o parâmetro PARALLEL_MAX_SERVERS de cada banco de dados está
definido de forma que a soma de todos os parâmetros não exceda os valores máximos
recomendados para os servidores de banco de dados do Database Machine.
- Para os servidores de banco de dados X2-2, o valor máximo recomendado é 240.
- Para os servidores de banco de dados X2-8, o valor máximo recomendado é
1280.

• Como orientação geral, o número de processos ativos de banco de dados não deve
exceder quatro vezes o valor da definição do parâmetro CPU_COUNT. Se essa relação
for excedida, considere alocar mais recursos de CPU para o banco de dados.
• Quando viável, use pools de conexões para gerenciar as conexões de aplicações.
Isso permite o uso mais eficiente das conexões, bem como minimiza o uso de recursos
associado ao estabelecimento e ao encerramento de conexões.
• Considere o uso da funcionalidade de limitação de taxa de conexão do Oracle
Net Listener para limitar a taxa de novas conexões tratadas pelo listener. Essa
funcionalidade pode ser usada para evitar possíveis impactos negativos no
desempenho associados a um grande número de conexões simultâneas.
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 Atribuições de Gerenciamento
• Separe as atribuições de administração de DBA e do ASM:
– Pode ser configurado como parte do processo do
OneCommand
• Separe os grupos OSDBA e OSOPER, bem como as contas de
SO do administrador de cada banco de dados:
– Deve ser configurado manualmente
– Pode ser usado para fins de auditoria ou para impor o
isolamento
le
– O isolamento imposto requer uma instalação do software doerab
Oracle Database separada para cada banco de dadosans
f
n - tr
• Separe os grupos de discos de cada banco deno dados:
a
– Consulte a discussão sobre configurações
) h asde armazenamento
ฺ
não padrão anteriormente nesta lição b
ฺ Gur i d e
– A segurança do armazenamento o m
k o ฺc denExadata
do t no escopo do
banco de dados também t ei pode S t user implementada para impor
o r e@ this
o isolamento dotarmazenamento
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic uma definição de consolidação é a capacidade de isolar as funções
Um desejo
o Tecomum em
c ic
dengerenciamento associadas a cada banco de dados. Com o Database Machine, há várias
T e opções para definir e impor o isolamento em diversos níveis.
• Durante o processo inicial de instalação e configuração, há uma opção para criar
contas separadas de administração de banco de dados e de administração do ASM.
Essa opção permite criar uma conta de sistema operacional, chamada grid, por
default, para gerenciar o ASM e o Grid Infrastructure. Outra conta de sistema
operacional, chamada oracle, por default, é criada com os privilégios necessários
para administrar o Oracle Database. Grupos privilegiados também são criados e
associados às atribuições OSDBA, OSOPER, OSASM, OSDBA do ASM e OSOPER do ASM.
• Além da separação das atribuições descrita anteriormente, os clientes podem
configurar manualmente grupos OSDBA e OSOPER separados, bem como contas de
usuário do SO separadas para cada banco de dados. Os diferentes usuários do SO
podem ser usados como um mecanismo para auditar a atividade de diversos
administradores. Eles também podem ser usados para impor o isolamento do
gerenciamento entre bancos de dados distintos. Por exemplo, uma conta do SO
específica poderá ter direitos para gerenciar determinado banco de dados, mas poderá
não ter permissão para se conectar a outros bancos de dados. O isolamento imposto
requer uma instalação do software do Oracle Database separada para cada banco de
dados.
• Outro nível de isolamento pode ser alcançado com o uso de diferentes grupos de
discos para cada banco de dados. Esse procedimento pode ser usado para obter
uma separação física de modo que cada banco de dados seja armazenado em
discos separados fisicamente. Algumas opções de configuração alternativa de
armazenamento foram discutidas anteriormente nesta lição. Além de separar os grupos
de discos, a segurança do armazenamento do Exadata no escopo do banco de dados
pode ser usada para impor o isolamento do armazenamento. Com o uso desse recurso,
discos de grade específicos do Exadata podem ser associados a um banco de dados

de modo que nenhum outro banco de dados possa usá-los. Consulte a lição
Configuração do Exadata Storage Server para obter uma descrição de como
implementar a segurança do armazenamento do Exadata.
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 para a
Consolidação de Esquemas
• Isole os esquemas de aplicação em seus próprios tablespaces:
– Simplifica o gerenciamento de espaço

– Permite uma recuperação rápida e granular com o uso do recurso
TSPITR (tablespace point-in-time recovery)
• Ajuste as práticas de backup, restauração e recuperação de
tablespaces:
– Compreenda os overheads e os requisitos das diferentes le
abordagens: fe rab
TSPITR tra ns
—
n -
— Tecnologias de flashback no a
— Exportação e importação lógicas a s
hde tempo
– Avalie se o TSPITR atende aos objetivos r ) d e ฺ de
b
ฺ Gu i
recuperação das aplicações com t
k o ฺ e n
—
t ei Studpara obter um TSPITR mais
Considere o uso de cópias-imagem
rápido
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k c nível de esquema, a principal consideração é determinar se os
Te
Para aoconsolidação lino
e c nic de aplicação são ou não adequados para coexistir no mesmo banco de dados.
esquemas
T Se a consolidação no nível de esquema for viável, o resultado será um único banco de dados
que deverá ser configurado e gerenciado de acordo com todas as recomendações padrão
aplicáveis ao Database Machine. Além disso, as seguintes recomendações e considerações
se aplicam:
• Cada esquema de aplicação deve estar contido em um tablespace separado ou em
um conjunto de tablespaces. Isso permite o gerenciamento fácil e eficiente do espaço,
bem como facilita o uso do recurso TSPITR (tablespace point-in-time recovery) para
executar a recuperação de um esquema de aplicação específico sem afetar outros
tablespaces e esquemas.
• Ajuste suas práticas de backup e recuperação de modo que esquemas de aplicação
individuais possam ser mantidos com a interrupção mínima de outras aplicações. Para
isso, é necessário compreender os overheads e os requisitos de diferentes abordagens,
bem como garantir a disponibilidade dos recursos necessários do sistema para atender
aos objetivos desejados.
• Se o TSPITR for considerado, avalie também se cópias-imagem poderão ser usadas
para permitir uma recuperação mais rápida. Nesse caso, o RMAN não precisará
restaurar os arquivos de dados a partir de um backup.

Considerações Sobre Manutenção
• Uma margem adicional e procedimentos especializados

poderão ser necessários para acomodar interrupções no

funcionamento do servidor ou a aplicação dinâmica de patches:
– Como o ambiente é afetado pela ausência de um servidor de
banco de dados ou de um Exadata Storage Server?
– Use serviços e bancos de dados gerenciados por política para fins
de adaptação
• Isole as alterações em um novo diretório Oracle Home, depoiserab
le
migre e valide cada banco de dados: n s f
a -tr
on
– Valide nos modos de teste e stand-by primeiro se possível
n
a
• Mantenha apenas algumas versões ativas do
) h assoftware ฺ
Oracle:
– Por exemplo: 11.2.0.1 BP9, 11.2.0.2ฺBP7,
m br 11.2.0.3
u ide BP2
– Lembre-se de que a versão doฺcGrid o Infrastructure
n t G deve ser igual
i k o d e
ou posterior à do kerneltdo
@
e banco S tude dados
r te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
Te de uma
A manutenção
o lic plataforma de consolidação poderá exigir uma margem adicional ou
ic de procedimentos personalizados. Por exemplo, a ausência temporária de uma
ecn
a adoção
T célula de armazenamento durante a aplicação dinâmica de um patch terá um impacto maior
em um banco de dados que usa apenas algumas células do que em outro distribuído por
striping entre todas as 14 células de um Database Machine Full Rack. Considere como a
ausência de um servidor poderá afetar o ambiente e faça o planejamento adequado. Além
disso, use recursos como serviços de banco de dados e bancos de dados gerenciados
por política a fim de que o ambiente possa absorver mais facilmente o impacto de uma
interrupção no funcionamento do servidor.
Ao atualizar as versões do software do Oracle Database, em geral, uma prática
recomendada é isolar a atualização em um novo diretório Oracle Home. Isso se aplica
principalmente em um ambiente de consolidação uma vez que permite que os bancos
de dados sejam migrados e validados separadamente.
Lembre-se de gerenciar o conjunto de versões do software Oracle e mantenha somente
algumas versões ativas uma vez que a proliferação de diversas versões provavelmente
aumentará a complexidade da manutenção. Além disso, lembre-se de que a versão do
software Grid Infrastructure deve ser igual ou posterior à versão ativa mais recente do kernel
do banco de dados. Ou, em outras palavras, a versão do software Grid Infrastructure não
poderá ser anterior a qualquer versão do kernel do banco de dados.

Questionário
O Exadata Database Machine é adequado para:

a. Consolidação de Esquemas de Aplicação

b. Consolidação de Bancos de Dados
c. As duas alternativas acima
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

Questionário
Durante a consolidação de bancos de dados no Exadata

Database Machine, a Oracle recomenda criar um conjunto

separado de grupos de discos ASM para cada banco de
dados:
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
configuração de armazenamento recomendada para consolidação é usar uma grade de
T e armazenamento ASM compartilhada para cada ambiente consolidado. A configuração de
grupo de discos default resultante do processo de configuração do OneCommand deve ser
usada. A configuração de armazenamento recomendada apresenta as seguintes vantagens
principais. Em primeiro lugar, ela é conceitualmente simples e inerentemente fácil de
gerenciar; além disso, é a configuração mais conhecida e mais suportada. Em segundo
lugar, é uma configuração balanceada adequada para a maioria das circunstâncias, bem
como fornece um alto nível de disponibilidade e desempenho.
Embora seja possível criar um conjunto separado de grupos de discos para cada banco
de dados e embora essa configuração ofereça vantagens específicas em algumas
circunstâncias, a Oracle não recomenda criar um conjunto separado de grupos de discos
ASM para cada banco de dados. Os clientes devem considerar as vantagens e as limitações
de usar vários conjuntos de grupos de discos antes de implementar essa configuração.

Resumo

• Descrever as opções para a consolidação de vários

bancos de dados no Database Machine
• Descrever as vantagens e os custos associados a
diferentes opções
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

Migrando Bancos de Dados para 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 as etapas gerais para migrar o seu banco de

dados para o Database Machine
• Listar as principais abordagens para migrar o seu banco
de dados para o Database Machine
• Identificar a abordagem mais adequada para diferentes
le
circunstâncias
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 das Melhores Práticas de Migração
Armazenamento legado para o Database Machine
le
fe rab
tra ns
1 2 3 n -4
no a Tarefas de
Planejamento Escolha da Migração s
da capacidade abordagem ) a
h epós-migraçãoฺ
b
ฺ Gur i d
de migração m
o
ฺc dent
k o
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic fases importantes envolvidas na migração dos bancos de dados
Te as quatro
O slideomostra
e c nic para o Database Machine. Cada fase é abordada no restante desta lição.
existentes
T

Executando o Planejamento da Capacidade
Exadata
…
Storage
Banco de Server CALIBRATE
dados
de origem
Disco de Alto Disco de Alta
Desempenho Capacidade
Exadata Smart Flash Cache 384 GB 384 GB
Capacidade do Disco Bruto 7,2 TB 36 TB

le
Relatório Capacidade de Dados não Compactados Até 3,25 TB
fe
Até 16 TB rab
do AWR s
aAtén1.300
Throughput de Disco Bruto (MBPS) Até 1.800
n - tr
Throughput Efetivo com Flash (MBPS) no Até 4.900
Até 5.400
a
Throughput Efetivo com Flash e
) h asAté 54.000ฺ Até 49.000
ฺbr ide
Compactação (MBPS)
m Segundo GuAté 3.600

Tamanho IOPS MBPS (IOPS) ฺ c o nt
Entradas/saídas de Disco por Até 2.000
i k o ude
t e
Entradas/saídas Flash portSegundo (IOPS) Até 100.000
S Até 100.000
r @
te thi s
o
p use
uOracle
c ฺ s
Copyright © 2012,
t e
i k o ( ense
O maior desafio
o lic
Te do planejamento da capacidade do Database Machine é compreender a
i c
diferença
nrequisitos de armazenamento, éexistente
entre o armazenamento e o armazenamento do Exadata. Para determinar
T e c
os necessário compreender as características de
entrada/saída do ambiente atual. Verifique o tamanho e o throughput do seu sistema atual.
As principais medidas de throughput de entrada/saída são IOPS (entradas/saídas por
segundo) e MBPS (megabytes por segundo). Use a estatística do sistema physical I/O disk
bytes para obter o MBPS atual do sistema. Use as estatísticas do sistema physical reads e
physical writes para determinar o IOPS atual do sistema. Essas estatísticas estão disponíveis
no relatório do AWR (Automatic Workload Repository).
Depois de compreender a capacidade do sistema atual, você poderá determinar o número
necessário de células do Exadata e, a partir daí, determinar a configuração adequada de
armazenamento do Database Machine. É importante dimensionar o desempenho e a
capacidade. Use as métricas de desempenho e capacidade mostradas no slide para ajudar
no dimensionamento. Você pode verificar o throughput das células executando o comando
CALIBRATE. Além disso, lembre-se de que talvez seja possível obter um throughput bem
maior por meio do uso eficiente do Exadata Smart Flash Cache e da Exadata Hybrid
Columnar Compression. O impacto exato dessas tecnologias deve ser verificado por meio de
teste.
Também é importante considerar falhas ao planejar a capacidade. As falhas nas células e
nos discos do Exadata são toleradas usando a redundância do ASM (Automatic Storage
Management). No entanto, é uma melhor prática garantir que a capacidade de entrada/saída
pós-falha seja suficiente para atender aos requisitos de redundância e aos níveis de serviço
de desempenho.
Considerações sobre a Migração do
Database Machine
• A plataforma é a Intel de 64 bits
– A ordem de bytes é little endian

• A versão do Exadata, do ASM e do software de banco de
dados deverá ser 11.2.0.1 ou mais recente.
• Atributos do grupo de discos ASM:
– COMPATIBLE.ASM=11.2.0.0.0
– COMPATIBLE.RDBMS=11.2.0.0.0
le
– CELL.SMART_SCAN_CAPABLE=TRUE
fe rab
– AU_SIZE=4M ns tra
n -
• Parâmetros de inicialização de banco de dados:
a no
– COMPATIBLE=11.2.0.0.0
) h as ฺ
– DB_BLOCK_CHECKSUM=TYPICAL|FULL
m ฺbr Guide
• Os tamanhos das extensõesฺcdo o banco n t de dados devem
ser múltiplos de 4 MB. tei k o ud e
S t
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic os requisitos e as recomendações de configuração do Database
A seguir,T
apresentaremos
o
ic que você deverá ter em mente ao planejar a migração do seu banco de dados:
Machine
Tecn• O Database Machine é uma plataforma baseada em Intel de 64 bits. A ordem de bytes é
little endian.
• A release do software de banco de dados, do ASM e do Exadata Storage Server no
Database Machine deve ser a 11.2.0.1 ou mais recente.
• Para grupos de discos ASM que contêm discos de grade Exadata, especifique as
definições de atributos mostradas no slide. Embora não sejam obrigatórias, elas são
altamente recomendadas para ativar todos os recursos do Exadata Storage Server e
otimizar o desempenho.
• Para ativar todos os recursos do Exadata no banco de dados, a release do software do
Oracle Database deverá ser a 11.2.0.1 ou mais recente, e você deverá definir o parâmetro
de inicialização COMPATIBLE, conforme mostrado no slide. Como o armazenamento do
Exadata é compatível com HARD (Hardware Assisted Resilient Data), você deve definir
DB_BLOCK_CHECKSUM como TYPICAL ou FULL para garantir que os checksums sejam
calculados e armazenados nos blocos. Observe que o parâmetro de inicialização é
definido como TYPICAL por default.
• O Exadata funciona melhor ao varrer chunks contíguos de, pelo menos, 4 MB de tamanho.
Para garantir que isso ocorra, o tamanho da unidade de alocação do grupo de discos ASM
(AU_SIZE) deve ser definido como 4 MB, e o tamanho das extensões do banco de dados
deve ser um múltiplo de 4 MB.
Observação: os parâmetros destacados em vermelho são necessários para ativar os recursos
de armazenamento inteligente.
Escolhendo o Caminho de Migração Correto
• Determinar o que será migrado

– Evitar métodos que migrem o que será descartado

• Considerar a configuração do sistema de origem
– A versão do Oracle Database e da plataforma de origem é
importante
– O sistema de destino é fixo: 11.2, ASM, Little endian
• Pesar os custos e priorizar métodos que facilitem a le
aplicação das melhores práticas fe rab
– A implementação das melhores práticas é importante trano ns
longo prazo porque o seu desempenho futuro n o n -
depende disso
a
– Lembre-se: as ) h ฺ
O tamanho de 4 MB da AU do ASM
ฺ b rsomente e ser definido
idpode
—
na criação do grupo de discoso m G u

o ฺ c n t
—
t e ik de
Os tamanhos das extensões
t u de de dados são definidos
banco
durante a alocação S
@das extensões
o r te this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k lic de dados existente para o Database Machine poderá ser feita por
A migração
o Tede um banco
meio
c n icdelição.
nesta
diferentes abordagens. As abordagens mais usadas são abordadas mais adiante
Antes de considerá-las, é válido analisar alguns fatores que poderão ajudá-lo a
Te escolher o caminho correto de migração.
Antes de escolher uma abordagem de migração, é necessário definir claramente o que você
deseja migrar. Isso o ajudará a evitar esforços inúteis como migrar dados não necessários. A
definição clara do escopo da migração também ajuda a identificar, de forma clara, os sistemas
de origem. É necessário compreender os sistemas de origem porque a sua composição poderá
limitar as opções de migração disponíveis. Por exemplo, como o Database Machine é uma
plataforma little endian, se você estiver migrando de uma plataforma big endian, algumas
abordagens de migração física não serão viáveis. Além disso, o uso de recursos de banco de
dados, como views materializadas ou tipos de objeto de dados, poderá impor restrições a
alguns métodos de migração.
Ao escolher a abordagem de migração correta, você deverá ponderar o requisito de curto
prazo para executar a migração levando em consideração o impacto de longo prazo da
abordagem de migração selecionada. Especificamente, você deve priorizar métodos que
facilitem a implementação de melhores práticas e evitar métodos que prejudiquem sua
habilidade de implementá-las.
Por exemplo, o Exadata funciona melhor com um tamanho de 4 MB da AU do ASM e
extensões de banco de dados que sejam múltiplas de 4 MB. Se o tamanho das extensões do
banco de dados de origem não for múltiplo de 4 MB, uma vez que é impossível reorganizar o
banco de dados antes da migração, você deverá priorizar uma abordagem que lhe permita
reorganizar o banco de dados durante a migração. Se você escolher uma abordagem que não
permita a reorganização das extensões, talvez você obtenha uma migração mais rápida e fácil,
no entanto, poderá sofrer uma penalidade de desempenho contínua.
Abordagens de Migração Lógica
Abordagem de migração A versão É possível Suporte da Requisito de Tempo de

do banco ajustar plataforma de tempo e interrupção

de dados o tamanho origem esforço da
de origem da AU migração
deve ser do ASM
11.2 para 4MB
Banco de dados stand-by No Yes Limitada Alta Baixa
lógico
Indisponibilidade mínima
Streams No Yes Ampla Alta Baixa

le
rab
Indisponibilidade mínima
s f e
Data Pump
Para migração durante um período
No Yes Ampla Baixa
tr a nAlta
de manutenção planejado n -
noa
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
A migração
o Tepara o Database Machine pode ser feita de forma lógica ou física.
n i c
TecUtilizando uma abordagem lógica, você poderá alterar o tamanho das extensões e outras
características físicas do banco de dados, como o seu conjunto de caracteres, o que não é
possível com uma abordagem de migração física.
A tabela do slide resume algumas abordagens de migração lógica usando as tecnologias
incorporadas no Oracle Database:
• Banco de dados stand-by lógico: se os contratos de nível de serviço de sua
aplicação permitirem pouca ou nenhuma indisponibilidade, você poderá usar um banco
de dados stand-by lógico do Oracle Data Guard para replicar o banco de dados no
Database Machine, e rastrear e mesclar as alterações durante a execução do banco de
dados de origem. Após o estabelecimento da configuração, o banco de dados stand-by
lógico (no Database Machine) poderá ser alterado para assumir a atribuição de banco
de dados principal, desativando o banco de dados de origem original. O procedimento
documentado em My Oracle Support bulletin 737460.1 pode ser usado para alterar os
atributos de armazenamento físico do banco de dados, como os tamanhos das
extensões dos segmentos. Consulte My Oracle Support bulletin 1085687.1 para obter
informações sobre o suporte a plataformas heterogêneas na mesma configuração do
Data Guard.

• Streams: se os contratos de nível de serviço de sua aplicação permitirem pouca ou
nenhuma indisponibilidade, você também poderá usar Oracle Streams para propagar
os dados e para rastrear e mesclar as alterações durante a execução do banco de
dados de origem. Para obter mais informações sobre essa abordagem, consulte o
Apêndice D em Oracle Streams Concepts and Administration 11g Release 2 (11.2).
A abordagem de streams oferece um suporte mais amplo a plataformas de bancos
de dados de origem do que a abordagem de banco de dados stand-by lógico.
• Data Pump: Se for possível especificar uma janela de tempo de manutenção adequada
e se o tamanho do banco de dados não for extremamente grande, use o Data Pump
para mover os dados em massa do sistema legado para o Database Machine. O Data
Pump é fácil de usar e oferece um suporte amplo a diferentes plataformas e versões
de bancos de dados.
Observação: no caso das abordagens de banco de dados stand-by lógico e streams, há
considerações adicionais que poderão contraindicar seu uso. Em primeiro lugar, nas duas
le
fe
Database. Embora haja métodos para superar essa limitação, o esforço extra necessário
rab
abordagens não é possível processar, de forma nativa, todos os tipos de dados do Oracle
tra ns
para implementar e manter esses métodos não pode ser desconsiderado. Além disso, as
n -
banco de dados principal. a no
duas abordagens não conseguirão duplicar as operações NOLOGGING executadas 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

Abordagens de Migração Física
Abordagem de migração A versão do É possível Suporte da Requisito Tempo de
banco de ajustar plataforma de de tempo interrupção
dados de o tamanho da origem e esforço da
origem deve AU do ASM migração

ser 11.2 para 4MB
Migração On-line do ASM Sim Não Somente igual Médio Baixo
Melhor quando o ASM ao do Database
e AUs de 4 MB já estão em uso Machine
Recovery Manager Sim Sim Somente igual Médio Baixo
Migração no nível do tablespace ao do Database
Machine
le
rab
Criação de novos tablespaces Sim Sim Somente igual Médio Baixo
Em conjunto com partições dinâmicas ao do Database
fe
Machine
tra ns
Banco de dados stand-by físico Não Sim Limitado -
Baixo
n Baixo
Migração do servidor de BD e
armazenamento
a no
Banco de Dados Transportável Sim Sim
h a s
Little endian Baixo Médio
) ฺ
ฺbr Guide
Migração para uma plataforma diferente,
com o mesmo formato endian
m
co entAmplo
Tablespace Transportável Não
k o ฺSim Médio Médio
Migração para uma plataforma diferente,
com formato endian diferente t ei Stud
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k lic algumas abordagens de migração física usando as tecnologias
A tabela
o T
do slide resume
e c nic
incorporadas no Oracle Database: :
T • Migração On-line do ASM: esse método é aplicável somente se o seu banco de dados
já estiver usando o ASM e você não precisar ajustar o tamanho da AU de alocação do
ASM. Para usar esse método, você também precisará conectar seu armazenamento
de banco de dados atual com o Database Machine e migrar as instâncias de banco de
dados para o Database Machine. Após a migração das instâncias, a migração de dados
é muito simples; para migrar os dados, basta adicionar novos discos de grade
baseados no Exadata aos seus grupos de discos ASM e eliminar destes os discos
existentes.
• Recovery Manager: esse método será útil se o seu banco de dados de origem não
usar o ASM e você já estiver usando a plataforma Linux x86_64 para o seu servidor
de banco de dados atual. Para usar esse método, você também deverá conectar
seu armazenamento de banco de dados atual com o Database Machine e migrar as
instâncias de banco de dados para o Database Machine. Com essa abordagem, você
migrará o banco de dados para o ASM criando backups do RMAN dos arquivos de
banco de dados de origem e usando o comando SWITCH...TO COPY do RMAN para
executar a migração. Consulte o Capítulo 8 do Oracle Database Storage Administrator's
Guide 11g Release 2 (11.2) para obter mais informações sobre o uso de RMAN para
migrações do ASM.
• Criação de novos tablespaces: esse método é útil quando o mesmo sistema
operacional já está sendo usado no servidor de banco de dados atual e a técnica
de roll-in e roll-out de partições é utilizada para inserir e remover dados do banco de
dados. Para usar esse método, você também deverá conectar seu armazenamento
de banco de dados atual com o Database Machine e migrar as instâncias de banco
de dados para o Database Machine. Após a migração das instâncias de banco de
dados, crie novos tablespaces baseados no Exadata e neles, as suas novas partições
de dados. Com o passar do tempo, mais partes do seu banco de dados serão
armazenadas no Database Machine. Para migrar o restante do banco de dados para o
Database Machine, será necessário empregar outros métodos, como Migração On-line
do ASM ou o Recovery Manager.
• Banco de dados stand-by físico: crie um banco de dados stand-by físico no Database
Machine e execute um switchover do Data Guard para migração. Consulte My Oracle
Support bulletin 413484.1 para obter mais informações sobre o suporte a plataformas
heterogêneas. Se a versão do banco de dados de origem for anterior à 11.2, você le
e rab
precisará usar o recurso de upgrade de banco de dados dinâmico lógico transitório. My
f
a ns
Oracle Support bulletin 413484.1 também contém informações adicionais sobre esse
tr
recurso. n -
• a no
Banco de Dados Transportável: use esse recurso para migrar o banco de dados
a s
h eฺ
inteiro. Para usar esse método com o Database Machine, o banco de dados de origem
r )
ฺ Guid
b
deverá ser uma plataforma little endian. Consulte o white paper Platform Migration
m
k o ฺco dent
Using Transportable Database em http://www.oracle.com/us/solutions/maa-wp-10gr2-
de Dados Transportável. t ei Stu

platformmigrationtdb-131164.pdf para obter mais informações sobre o recurso Banco
• o r te@ this
Tablespaces Transportáveis: use esse recurso para migrar tablespaces do seu
ฺ s up use
sistema atual para um novo banco de dados hospedado no Database Machine. Esse
( t ec se to
é o único método de migração física que oferece amplo suporte a plataformas e à
i ko licen
migração de versões mais antigas do Oracle Database.
e
o T
ic
Observação: os segmentos de banco de dados criados com versões do Oracle Database
Tecnanteriores à 11g poderão não se alinhar perfeitamente aos limites de extensão do ASM. No
caso de arquivos de dados copiados de bancos de dados anteriores à versão 11g, esse
desalinhamento poderá fazer com que uma única solicitação de entrada/saída emitida pelo
banco de dados resulte em duas entradas/saídas físicas divididas em um limite de extensão
do ASM e, possivelmente, em dois discos físicos em Exadata Storage Servers diferentes.
Como esse comportamento é mais evidente quando entradas/saídas grandes e contíguas
são emitidas, é provável que o impacto seja pequeno em cargas de trabalho OLTP. No
entanto, no caso de cargas de trabalho que contenham muitas varreduras de tabelas
integrais, o impacto poderá ser significativo. Para criar o alinhamento de extensões mais
eficiente, os dados devem ser carregados em segmentos novos. Para isso, use uma
abordagem de migração lógica ou comandos como CREATE TABLE ... AS SELECT,
ALTER TABLE ... MOVE ou a redefinição de tabelas on-line para recriar os segmentos
em um novo tablespace após uma migração física.

Reduzindo o Período de Indisponibilidade Durante
a Migração com Tablespaces Transportáveis
Migração Tradicional usando Migração usando
Tablespaces Transportáveis Backup Incremental entre Plataformas
atualizações durante as Fases 1 e

1. Torne os tablespaces de origem Fase 1 - Fase de Preparação
O banco de dados de origem

READ ONLY.
permanece disponível para

1. Transfira as cópias dos arquivos de dados para o sistema
de destino.
2. Transfira os arquivos de dados
para o sistema de destino. 2. Converta as cópias dos arquivos de dados no formato
endian do sistema de destino.
3. Converta os arquivos de
dados no formato endian Fase 2 - Fase de Rollforward
2.
do sistema de destino. 1. Crie um backup incremental no sistema de origem.
2. Transfira o backup incremental para o sistema de destino.
4. Exporte os metadados de
3. Converta o backup incremental no formato endian do sistema
le
rab
objetos dos tablespaces do
banco de dados de origem de destino e aplique-o às cópias dos arquivos de dados de destino.
fe
ns
usando o Data Pump. Repita a Fase 2 até que o sistema de destino esteja quase atualizado.
5. Importe os metadados para o
banco de dados de destino. - tr a
6. Torne o tablespace de destino
Fase 3 - Fase de Transporte
no n
1. Torne os tablespaces do banco de dados de origem READ ONLY.
READ WRITE.
s a
2. Repita a Fase 2 mais uma vez a fim de atualizar os arquivos de
) a
dados de destino de acordo com os arquivos de dados de origem.
h eฺ
Os dados permanecem
indisponíveis para atualização r
3. Exporte os metadados de objetos dos tablespaces do
ฺ Guid
b
banco de dados de origem usando o Data Pump.
m
ฺco dent
durante todo o processo.
4. Importe os metadados para o banco de dados de destino.
k o
5. Torne os tablespaces do banco de dados de destino READ WRITE.
t ei Stu
Os dados permanecem indisponíveis para atualização somente na Fase 3.
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
e i k licna página anterior, os Tablespaces Transportáveis facilitam a
ConformeTobservado
o
e c nic
abordagem de migração física a qual oferece o mais amplo suporte para diversas versões de
banco de dados e plataformas de origem. Quando Tablespaces Transportáveis são usados
T para migrar dados entre sistemas com formatos endian diferentes, o período de
indisponibilidade necessário poderá ser significativo por causa do processo de conversão de
arquivos que deve ocorrer, e a duração desse processo é diretamente proporcional ao
tamanho do conjunto de dados que está sendo movido.
A Oracle lançou um novo recurso chamado Backup Incremental entre Plataformas o qual,
quando usado em conjunto com Tablespaces Transportáveis, reduz significativamente o
período de indisponibilidade envolvido na migração de dados para o Exadata Database
Machine.
O slide mostra um resumo do novo processo comparado ao método de migração tradicional
com o uso de Tablespaces Transportáveis. Para obter detalhes completos sobre esse
processo, consulte My Oracle Support bulletin 1389592.1.
Observe que o Backup Incremental entre Plataformas não afeta a quantidade de tempo
necessária para executar outras ações de migração, como a exportação e a importação de
metadados. Portanto, uma vantagem limitada será observada no caso de bancos de dados
com grandes volumes de metadados se o tempo de migração for gasto, em sua maior parte,
em operações de metadados, em vez de na transferência e na conversão de arquivos de
dados.
Observe também que a funcionalidade de Backup Incremental entre Plataformas é fornecida
como um patch o qual exige que o Exadata Database Machine esteja executando o Linux
com o Oracle Database versão 11.2.0.2 e o Bundle Patch 12 para Exadata instalados.
Outras Abordagens
• Ferramentas de Integração de Dados

– Oracle GoldenGate
– Oracle Data Integrator
• Código Personalizado
– Consulta por link de banco de dados
– Rotinas PL/SQL
le
• Abordagens Híbridas
fe rab
– Por exemplo, Tablespaces Transportáveis do banco rde
t ateste ns
dados de produção atual para um banco de dados n -
de
fora do Database Machine e, depois, o Data a no para
Pump
descarregar do banco de dados de teste
) h aescarregar
ฺ no
ฺ b r i d e
Database Machine om G u
k o ฺc dent
t ei Stu
o r te@ this
s p use
uOracle
c ฺ
Copyright © 2012,
t
o ( ense
i k licapresentaram várias abordagens de migração baseadas em
Teanteriores
As páginas
o
ic
ecn
ferramentas e tecnologias que fazem parte do Oracle Database. Além disso, há muitas
T outras tecnologias e abordagens de migração, incluindo:
• Tecnologias de integração de dados, como o Oracle GoldenGate ou o Oracle Data
Integrator, podem ser usadas para migrar e, se necessário, transformar dados. Em
geral, esses ambientes oferecem um alto grau de flexibilidade, juntamente com uma
forma produtiva de definir e implementar as integrações de dados e transformações
necessárias. Além disso, essas tecnologias são, com frequência, usadas para facilitar
a migração de dados durante a execução do sistema de origem.
• Em alguns casos, os clientes apresentam circunstâncias específicas que resultam no
uso de código personalizado para a migração de dados. Em geral, essa abordagem usa
consultas por links de bancos de dados como o principal mecanismo de transferência
de dados. Às vezes, essas consultas distribuídas são encapsuladas em rotinas PL/SQL.
O código personalizado é usado com frequência em situações em que rotinas
existentes podem ser adaptadas com facilidade para executar uma migração para o
Database Machine.
• Também há muitas abordagens híbridas potenciais que combinam dois ou mais
métodos apresentados nesta lição. Por exemplo, é possível que um cliente já use
Tablespaces Transportáveis em seu ambiente, portanto, usá-los como fonte de dados
para uma migração seria fácil e conveniente. No entanto, a organização física dos
dados nos Tablespaces Transportáveis pode não ser ideal para o Database Machine.
Dessa forma, ele pode optar por recarregar os dados em segmentos novos usando o
Data Pump.
Melhores Práticas de Pós-Migração
• Verifique se os grupos de discos ASM estão balanceados:

– Talvez seja necessário o rebalanceamento manual

– Há um script disponível em My Oracle Support bulletin
367445.1
– Alerta de desbalanceamento do grupo de discos emitido
pelo Enterprise Manager
• Avalie os requisitos de índice:
able
– Com o Exadata, varreduras integrais podem apresentar um fe r
a n s
desempenho aceitável
n -t r
– Determine os índices desnecessários e os remova n o
a
• Configure o I/O Resource Management ) 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
Considere
o Teo seguintelicapós migrar os bancos de dados para o Database Machine:
e c n• icUma das funções básicas do ASM é garantir que os dados sejam distribuídos de
T maneira uniforme entre todos os discos de um grupo de discos. Isso ocorre de forma
automática, mas ocasionalmente, um grupo de discos poderá se tornar desbalanceado
devido a erros comuns, como falhas no rebalanceamento. Assim sendo, é uma
melhor prática operacional verificar os grupos de discos regularmente e executar um
rebalanceamento manual, se necessário. Há um script disponível para verificar o
balanceamento do grupo de discos em My Oracle Support bulletin 367445.1. Além
disso, o Enterprise Manager Grid Control exibe um alerta se um grupo de discos se
tornar desbalanceado além de um limite personalizável.
• As taxas de varredura superiores disponíveis no Database Machine tornam possível
que índices, anteriormente obrigatórios para um bom desempenho, não sejam mais
necessários. Você deve avaliar os planos de execução que usam índices para verificar
se eles seriam executados de forma aceitável com Smart Scans. Para determinar se as
consultas funcionam de forma aceitável sem índice, você pode tornar o índice invisível
para o otimizador. Um índice invisível é mantido pelas operações DML, mas não é
usado pelo otimizador para consultas. Para tornar um índice invisível, uso o comando a
seguir:
ALTER INDEX <index_name> INVISIBLE;
• Depois de executar as tarefas acima, você poderá configurar o IORM (I/O Resource
Management).
Questionário
Quais são as duas práticas recomendadas ao migrar para o

armazenamento do Exadata?
a. Dobrar o tamanho da SGA
b. Configurar as unidades de alocação do ASM como 4 MB
c. Dobrar o tamanho do espaço em disco
d. Configurar as extensões de banco de dados como
múltiplos de 4 MB 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
e d lic
Resposta:
o Tb,
e c nic
T

Questionário
Qual das abordagens de migração física a seguir é a mais

aplicável universalmente?
a. Migração On-line do ASM
b. Banco de Dados Stand-by Físico
c. Tablespaces Transportáveis
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 Tce
e c nictablespaces transportáveis, é possível migrar para o Database Machine a partir de uma
Com
T gama muito mais ampla de plataformas do que com as outras abordagens.

Resumo

• Descrever as etapas gerais para migrar o seu banco de

dados para o Database Machine
• Listar as principais abordagens para migrar o seu banco
de dados para o Database Machine
• Identificar a abordagem mais adequada para diferentes
le
circunstâncias
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
– Migrando para o Database Machine com o Uso de

Tablespaces Transportáveis
• My Oracle Support Notes
– Changing Storage Definition in a Logical Standby Database
– Data Guard Support for Heterogeneous Primary and
Standby Systems in Same Data Guard Configuration
r a ble
– Script to Report the Percentage of Imbalance in all Mounted
n s fe
Diskgroups -tra on
a n
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
• Documentação e White Papers

– Oracle Streams Concepts and Administration

11g Release 2 (11.2)
– Oracle Database Storage Administrator's Guide
11g Release 2 (11.2)
– Platform Migration Using Transportable Database
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

Migrando para o Database Machine com o Uso de
Tablespaces Transportáveis
Neste exercício, você usará o Oracle RMAN (Recovery

Manager), juntamente com o recurso Tablespace
Transportável do Oracle Database, a fim de migrar dados de
uma plataforma big endian para o Database Machine, que é
uma plataforma little endian.
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

D73668BP11 sg1

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 sg1

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

Após concluir este curso, você será capaz de:

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

• Este curso se destina principalmente aos administradores

que configurarão e administrarão o Oracle Exadata

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

1. Introdução (Esta Lição) 14. Configurando o Enterprise Manager Grid

3. Arquitetura do Exadata Database Machine Database Machine

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

• Durante todo o curso, 'Database Machine' é usado como

– Em geral, Database Machine refere-se ao sistema completo,

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

Workshop de Administração do Exadata Database Machine 1 - 6

laboratório usado como apoio a todos os exercícios durante

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

Visão Geral do Exadata Database Machine

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

• Fornecer uma descrição geral do Exadata Storage Server

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

• Plataforma totalmente integrada para o

O Database Machine foi projetado para tratar de problemas comuns:

• Problemas de Data Warehousing:

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

• Permite o processamento eficiente de commit.

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

• Armazenamento de alto desempenho

Exadata Storage para o Oracle Database

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

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

necessário para varrer um conjunto de dados de 10 Gigabytes.

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

Processadores Dois Processadores Six-Core Intel® Xeon® L5640 (2,26 GHz)

Unidades de Disco 12 SAS de Alto Desempenho de 600 GB 15K RPM

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

Exadata Smart Flash Cache1 384 GB 384 GB

Capacidade do Disco Bruto1 7,2 TB 36 TB

Capacidade de Dados não Compactados2 3,25 TB 16 TB

Throughput de Disco Bruto 1,8 GB/s 1,3 GB/s

Throughput de Flash 5,4 GB/s 4,9 GB/s