Banco de Dados Oracle 10g - Workshop de Administração II Vol.I.pdf

D17092BP30Produção 3.0Março de 2006D45125

Oracle Database 10g: Workshop deAdministração II

Guia do Aluno • Volume 1

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ

Development Program (WDP) eKit materials are provided for WDP in-class use only. Copying eKit materials is strictly prohibited and is inviolation of Oracle copyright. All WDP students must receive an eKit watermarked with their name and email. [email protected] if you have not received your personalized eKit.

Autores

Tom BestM.J. Billings

Revisores e Colaboradores Técnicos

Herbert BradburyHoward BradleyHarald van BreederodeM.J. BryksaDonna CookseyJoe FongAndy FortunakGerlinde FrenzenJoel GoodmanSushma JagannathChristine JealPierre LabrousseJerry LeeStefan LindbladWendy LoYi LuAndreas ReinhardtIra SingerJames SpillerJanet SternJean-Francois Verrier

Redatores

Aju KumarNita Pavitran

Designers Gráficos

Steve Elwood Sanjeev Sharma

Editor

Sujatha Nagendra

Copyright © 2006, Oracle. Todos os direitos reservados.

Isenção de Responsabilidade

Esta documentação contém informações proprietárias e é protegida pela legislação de direitos autorais e por outras leis de propriedade intelectual. A cópia e a impressão deste documento são permitidas exclusivamente para uso durante os cursos de treinamento da Oracle. O documento não poderá ser modificado de nenhuma forma. Salvo quando o uso estiver em conformidade com a lei de direitos autorais, é vedado usar, compartilhar, fazer download ou upload, copiar, imprimir, exibir, reproduzir, publicar, licenciar, divulgar, transmitir ou distribuir o presente documento, no todo ou em parte, sem a expressa autorização da Oracle.

As informações contidas neste documento estão sujeitas a alterações sem aviso prévio. Eventuais problemas encontrados no documento deverão ser reportados por escrito e enviados para: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 EUA. Distribuidor no Brasil: Oracle do Brasil Sistemas Ltda. Av. Alfredo Egydio de Souza Aranha, 100, São Paulo, SP - 04726-170 - Brasil - CNPJ: 59.456.277/0001-76 Este documento pode conter erros.

Aviso de Direitos Restritos

Caso o destinatário do presente documento seja o Governo dos Estados Unidos ou qualquer pessoa que esteja usando o documento em seu nome, será aplicado o seguinte aviso:

DIREITOS DO GOVERNO DOS EUAOs direitos do Governo dos EUA de usar, modificar, reproduzir, divulgar, exibir ou publicar estes materiais de treinamento são restritos pelas condições estabelecidas no contrato de licença da Oracle e/ou no contrato do Governo dos EUA aplicável.

Aviso de Registro de Marca

Oracle, JD Edwards e PeopleSoft são marcas comerciais da Oracle Corporation e/ou de suas coligadas. Outros nomes poderão constituir marcas comerciais de seus respectivos titulares.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Prefácio

1 Introdução Objetivos da Lição 1-2 Objetivos do Curso 1-3 Programação Sugerida 1-4 Conteúdo do Curso DBAI 1-5 Exemplos do Curso: O Esquema HR 1-6 Oracle Database 10g: O Banco de Dados para a Grade 1-7 Arquitetura do Banco de Dados: Revisão 1-8 Estruturas de Memória Oracle 1-9 Processos Oracle 1-11 Revisando o Gerenciamento de Instâncias Oracle 1-12 Estrutura Física do Banco de Dados 1-14 OMF (Oracle Managed Files) 1-16 Estruturas Lógicas e Físicas do Banco de Dados 1-17 Arquitetura do Banco de Dados: Resumo dos Componentes Estruturais 1-19 Sumário 1-20

2 Configurando o Recovery Manager Objetivos 2-2 Backup e Recuperação: Revisão 2-3 Recursos do Recovery Manager 2-4 Componentes do Recovery Manager 2-6 Etapas de Configuração do RMAN 2-8 Armazenamento de Dados do Repositório do RMAN: Comparação de Opções 2-9 Destinos de Backup 2-11 Gerenciamento de Mídia 2-12 Usando uma Área de Recuperação Flash com o RMAN 2-14 Monitorando a Área de Recuperação Flash com o EM 2-16 Uso do Espaço da Área de Recuperação Flash 2-17 V$FLASH_RECOVERY_AREA_USAGE 2-18Fazendo Backup da Área de Recuperação Flash 2-20 Vantagens do Uso de uma Área de Recuperação Flash 2-21 Definindo Parâmetros que Afetam o RMAN 2-22 Considerações sobre a Utilização do RMAN 2-24 Tipos de Conexões com o RMAN 2-25 Iniciando o RMAN 2-26 Argumentos de Linha de Comandos Adicionais do RMAN 2-27 Configurando Definições Persistentes para o RMAN 2-28 Configurando as Definições do RMAN com o EM 2-29 Backups Automáticos do Arquivo de Controle 2-30 Políticas de Retenção 2-32 Gerenciando Definições Persistentes 2-34 Alocação de Canais 2-35 Alocação Automática e Manual de Canais 2-36

Conteúdo

iii

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Opções de Controle de Canal 2-37 Sumário 2-39 Visão Geral do Exercício: Configurando o RMAN 2-40

3 Usando o Recovery Manager Objetivos 3-2 Executando Comandos do Recovery Manager 3-3 Tipos de Comandos do RMAN 3-5 Comandos de Job: Exemplo 3-6 Comandos do RMAN: Visão Geral 3-7 Comando BACKUP 3-9Restrições de Backup 3-10 Paralelização de Conjuntos de Backup 3-11 Backups Compactados 3-13 Cópia-Imagem 3-14 Tags para Backups e Cópias-Imagem 3-16 Opções do Comando BACKUP 3-17Fazendo Backup de Redo Logs Arquivados 3-19 Backup Completo do Banco de Dados 3-21 Tipos de Backup com o RMAN 3-22 Comparação entre Diferencial e Cumulativo 3-24 Rastreamento de Alterações em Blocos 3-25 Ativando o Rastreamento de Alterações em Blocos 3-26 Atualização Incremental de Backups 3-27 Comando LIST 3-28Comando REPORT 3-29Comando REPORT NEED BACKUP 3-30REPORT NEED BACKUP: Exemplos 3-31REPORT OBSOLETE e DELETE OBSOLETE 3-32Gerenciando Backups com o EM 3-33 Views Dinâmicas do RMAN 3-34 Monitorando Backups com o RMAN 3-36 Sumário 3-38 Visão Geral do Exercício: Fazendo o Backup do Banco de Dados 3-39

4 Recuperando Perdas Não Críticas Objetivos 4-2 Causas da Perda de Dados 4-3 Comparação entre Crítico e Não Crítico 4-4 Perdendo um TEMPFILE 4-5 Recuperando a Perda de um TEMPFILE 4-6 Status do Grupo de Logs: Revisão 4-7 Perdendo um Membro do Grupo de Redo Logs 4-8 Recriando Arquivos de Redo Log 4-9 Recriando Índices 4-13 Métodos de Autenticação para Administradores de Bancos de Dados 4-15

iv

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Recriando um Arquivo de Autenticação de Senha 4-16 Sumário 4-18 Visão Geral do Exercício: Recuperação a Perda de um TEMPFILE e de um Arquivo Redo Log 4-19

5 Recuperação de Banco de Dados Objetivos 5-2 Métodos de Recuperação 5-3 Recuperação Gerenciada por Usuário: Comando RECOVER 5-4 Recuperação do RMAN: Comandos RESTORE e RECOVER 5-5 Recuperação com o Enterprise Manager 5-6 Recuperação Completa e Incompleta 5-7 Recuperação Completa 5-8 Recuperação Incompleta 5-9 Situações Que Exigem Recuperação Incompleta 5-11 Tipos de Recuperação Incompleta 5-12 Executando a Recuperação Incompleta Gerenciada pelo Usuário 5-14 Recuperação Baseada em Horário Gerenciada por Usuário: Exemplo 5-16 Recuperação Baseada em Cancelamento Gerenciada por Usuário: Exemplo 5-18 Executando a Recuperação Incompleta com o RMAN 5-20 Recuperação Baseada em Horário com o RMAN: Exemplo 5-21 Recuperação de Seqüência de Log com o RMAN: Exemplo 5-23 Recuperação Incompleta com o Enterprise Manager 5-24 Recuperação Incompleta e o Log de Alerta 5-25 Pontos de Restauração 5-26 Recuperação Incompleta: Melhores Práticas 5-27 Recuperando um Arquivo de Controle por Backup Automático 5-29 Criando um Novo Arquivo de Controle 5-31 Recuperando Tablespaces Somente para Leitura 5-33 Questões Relativas à Recuperação de Tablespaces Somente para Leitura 5-35 Sumário 5-37 Visão Geral do Exercício: Executando uma Recuperação Incompleta 5-38

6 Flashback Objetivos 6-2 Tecnologia de Flashback: Revisão 6-3 Flashback de Eliminação e Lixeira 6-4 Lixeira 6-5 Restaurando Tabelas a Partir da Lixeira 6-7 Lixeira: Reutilização Automática de Espaço 6-8 Lixeira: Reutilização Manual de Espaço 6-10 Ignorando a Lixeira 6-11 Consultando a Lixeira 6-12 Consultando Dados de Tabelas Eliminadas 6-13 Flashback de Banco de Dados: Revisão 6-14 Arquitetura do Flashback de Banco de Dados 6-15 Configurando o Flashback de Banco de Dados 6-16

v

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Configurando o Flashback de Banco de Dados com o EM 6-17 Flashback de Banco de Dados: Exemplos 6-19 Executando o Flashback de Banco de Dados com o EM 6-20 Excluindo Tablespaces do Flashback de Banco de Dados 6-23 Considerações sobre o Flashback de Banco de Dados 6-24 Monitorando o Flashback de Banco de Dados 6-26 Monitorando o Flashback de Banco de Dados com o EM 6-28 Pontos de Restauração Garantidos 6-29 Sumário 6-30 Visão Geral do Exercício: Executando o Flashback de Banco de Dados 6-31

7 Lidando com Bancos de Dados Danificados Objetivos 7-2 O Que É um Bloco Danificado? 7-3 Sintomas de Blocos Danificados: ORA-1578 7-4 Como Lidar com Danos 7-5 Recursos Relacionados a Danos 7-7 Utilitário DBVERIFY 7-8 Interpretando a Saída DBVERIFY 7-9 Comando ANALYZE 7-11Verificando a Integridade de Blocos em Tempo Real: DB_BLOCK_CHECKING 7-12 Verificando a Integridade de Blocos em Tempo Real: DB_BLOCK_CHECKSUM 7-13 Usando EXP para Detectar Danos 7-14 Usando o Flashback para Danos Lógicos 7-15 Package DBMS_REPAIR 7-16Usando o DBMS_REPAIR 7-17 BMR (Block Media Recovery) 7-21 Comando BLOCKRECOVER 7-22Exemplos do Uso do Comando BLOCKRECOVER 7-23 A Interface do RMAN BMR 7-25 Ações Alternativas 7-26 Sumário 7-27 Visão Geral do Exercício: Executar uma Recuperação de Mídia de Bloco 7-28

8 Monitorando e Gerenciando a Memória Objetivos 8-2 Gerenciamento de Memória: Visão Geral 8-3 Estruturas de Memória Oracle 8-4 Cache de Buffer 8-6 Usando Vários Pools de Buffers 8-8 Shared Pool 8-10 Large Pool 8-11 Java Pool 8-12 Buffer de Redo Log 8-13 Gerenciamento Automático da Memória Compartilhada: Visão Geral 8-14 Vantagens do Gerenciamento Automático da Memória Compartilhada 8-15

vi

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Como Funciona o ASMM 8-16 Configurando o ASMM com o Database Control 8-17 Configurando o ASMM Manualmente 8-18 Comportamento de Parâmetros Auto-ajustáveis da SGA 8-21 Comportamento de Parâmetros da SGA Ajustados Manualmente 8-22 Usando a View V$PARAMETER 8-23 Modificando o Parâmetro SGA_TARGET 8-24 Desativando o ASMM 8-25 Redimensionando Manualmente os Parâmetros da SGA Dinâmica 8-26 PGA (Program Global Area) 8-27 Gerenciamento Automático da Memória PGA 8-29 Recursos de Gerenciamento da PGA 8-30 Usando o Memory Advisor para Dimensionar a SGA 8-31 Usando o Memory Advisor para Dimensionar a PGA 8-32 Uso de Memória Eficiente: Diretrizes 8-33 Diretrizes de Ajuste da Memória para o Cache de Biblioteca 8-35 Sumário 8-37 Visão Geral do Exercício: Usando o ASMM para Corrigir um Problema de Alocação de Memória 8-38

9 Gerenciamento Automático do Desempenho Objetivos 9-2 Atividades de Ajuste 9-3 Planejamento do Desempenho 9-4 Ajuste de Instância 9-6 Metodologia de Ajuste de Desempenho 9-7 Coleta de Estatísticas 9-8 Eventos de Espera Oracle 9-10 Estatísticas do Sistema 9-11 Exibindo Estatísticas Relativas a Sessões 9-13 Exibindo Estatísticas Relativas a Serviços 9-14 Views para Diagnóstico/Solução de Problemas e Ajuste 9-15 Views de Dicionário 9-16 Diagnósticos de Bancos de Dados Bloqueados ou Extremamente Lentos 9-17 Usando o Modo de Acesso à Memória 9-18 Usando a Página de Análise de Bloqueio 9-19 Automatic Workload Repository 9-21 Linhas de Base de Snapshots do AWR 9-23 Advisory Framework: Visão Geral 9-24 Database Control e Advisors 9-26 Sessão de Ajuste Convencional de Advisor 9-27 Chamando o ADDM Manualmente 9-28 Usando o SQL Tuning Advisor: Revisão 9-29 SQL Access Advisor: Visão Geral 9-30 Sessão Típica do SQL Access Advisor 9-31 Origem da Carga de Trabalho 9-32 Opções de Recomendação 9-33

vii

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Verificando Recomendações 9-35 COMMIT Assíncrono 9-36 Usando o COMMIT Assíncrono 9-37 Sumário 9-38 Visão Geral do Exercício: Usando o ADDM para Diagnosticar Problemas de Desempenho 9-39

10 Gerenciando Objetos de Esquema Objetivos 10-2 Tipos de Tabelas 10-3 O Que É uma Partição e Por Que Usá-la? 10-4 Partições 10-5 Criando uma Partição 10-6 Métodos de Particionamento 10-7 Manutenção da Partição 10-8 Tabelas Organizadas por Índice 10-9 Tabelas Organizadas por Índice e Tabelas de Heap 10-10 Criando Tabelas Organizadas por Índice 10-12 Clusters 10-13 Tipos de Cluster 10-14 Situações em que os Clusters São Úteis 10-16 Cluster de Hash Classificado: Visão Geral 10-17 Cluster de Hash Classificado: Exemplo 10-18 Cluster de Hash Classificado: Arquitetura Básica 10-19 Tarefas de Gerenciamento de Esquemas 10-20 Estimando a Utilização de Recursos 10-21 Analisando Tendências de Crescimento 10-22 Gerenciando Estatísticas do Otimizador 10-23 Reorganizando Objetos de Esquema On-line 10-24 Reorganizando Objetos: Relatório de Impacto 10-26 Reorganizando Objetos: Revisão 10-27 Etapas Básicas da Reorganização Manual On-line 10-28 Sumário 10-29 Visão Geral do Exercício: Gerenciando Objetos de Esquema 10-30

11 Gerenciando o Armazenamento Objetivos 11-2 Gerenciamento do Espaço: Visão Geral 11-3 Gerenciamento do Espaço Livre 11-4 Tipos de Segmentos 11-5 Alocando Extensões 11-6 Gerenciamento do Espaço em Bloco 11-7 Encadeamento e Migração de Linhas 11-8 Monitoramento Pró-ativo de Tablespaces 11-9 Limites e Resolução de Problemas de Espaço 11-10 Monitorando a Utilização do Espaço para Tablespace 11-11 Comprimindo Segmentos 11-12

viii

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Resultados da Operação de Compressão 11-13 Reutilização de Espaço com o ASSM 11-14 Segment Advisor: Visão Geral 11-15 Segment Advisor 11-16 Implementando Recomendações 11-18 Database Control e Compressão de Segmentos 11-19 Comprimindo Segmentos com SQL 11-20 Gerenciando a Alocação de Espaço Retomável 11-21 Usando a Alocação de Espaço Retomável 11-22 Retomando Instruções Suspensas 11-24 Transportando Tablespaces 11-26 Conceito: Nível Mínimo de Compatibilidade 11-27 Procedimento para Tablespace Transportável 11-28 Determinando o Formato Endian de uma Plataforma 11-29 Transportando Bancos de Dados 11-30 Procedimento de Transporte de Banco de Dados: Conversão do Sistema de Origem 11-31 Procedimento de Transporte de Banco de Dados: Conversão do Sistema de Destino 11-32 Transporte do Banco de Dados: Considerações 11-33 Sumário 11-34 Visão Geral do Exercício: Gerenciando o Armazenamento 11-35

12 ASM (Automatic Storage Management) Objetivos 12-2 ASM (Automatic Storage Management): Revisão 12-3 Arquitetura Geral do ASM 12-5 Tarefas da Instância ASM 12-7 Criando uma Instância ASM 12-8 Parâmetros de Inicialização da Instância ASM 12-9 Alterações nos Parâmetros de Instância do Banco de Dados 12-10 Inicializando uma Instância ASM 12-11 Acessando uma Instância ASM 12-12 Home Page do ASM 12-14 Página de Desempenho do ASM 12-15 Página de Configuração do ASM 12-16 Fazendo Shutdown de uma Instância ASM 12-17 DBCA e Opções de Armazenamento 12-18 Armazenamento do ASM: Conceitos 12-19 Grupos de Discos ASM 12-20 Grupo com Proteção para Falhas 12-21 Espelhamento de Grupos de Discos 12-22 Rebalanceamento Dinâmico de Grupos de Discos 12-23 Gerenciando Grupos de Discos 12-24 Página de Administração do ASM 12-25 Página Create Disk Group 12-26 Criando e Eliminando Grupos de Discos 12-27 Adicionando Discos a Grupos de Discos 12-28

ix

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Comandos ALTER 12-30 Arquivos ASM 12-32 Utilitário ASMCMD 12-33Migrando o Banco de Dados para o Armazenamento do ASM 12-34 Sumário 12-36 Visão Geral do Exercício: Usando o ASM (Automatic Storage Management) 12-37

13 Gerenciando Recursos Objetivos 13-2 Database Resource Manager: Visão Geral 13-3 Conceitos do Database Resource Manager 13-4 Por Que Usar o Resource Manager 13-5 Acessando Planos de Recursos 13-7 Exemplo: SYSTEM_PLAN 13-8 Criando um Novo Plano de Recursos 13-9 Criando Grupos de Consumidores 13-10 Designando Usuários a Grupos de Consumidores 13-11 Especificando Diretivas de Planos de Recursos 13-12 Métodos de Alocação de Recursos para Planos de Recursos 13-13 Comparação entre EMPHASIS e RATIO 13-14 Mecanismo do Pool de Sessões Ativas 13-16 Definindo o Pool de Sessões Ativas 13-17 Tempo Máximo de Execução Estimado 13-18 Alternância de Grupos de Consumidores 13-19 Retornando ao Grupo Inicial de Consumidores ao Final da Chamada 13-20 Definindo Timeouts de Inatividade 13-22 Mapeamento de Grupos de Consumidores de Recursos 13-23 Ativando um Plano de Recursos para uma Instância 13-25 Informações sobre o Database Resource Manager 13-26 Monitorando o Resource Manager 13-27 Sumário 13-30 Visão Geral do Exercício: Usando o Resource Manager 13-31

14 Automatizando Tarefas com o Scheduler Objetivos 14-2 Simplificando Tarefas de Gerenciamento 14-3 Um Job Simples 14-4 Principais Componentes e Etapas 14-5 1. Criando um Programa 14-6 2. Criando e Usando Programações 14-7 3. Criando e Executando um Job 14-8 4. Monitorando um Job 14-9 Usando uma Programação Baseada em Horário ou Evento 14-10 Criando um Job Baseado em Horário 14-11 Criando uma Programação Baseada em Evento 14-13 Criando Programações Baseadas em Evento com o Enterprise Manager 14-14

x

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Criando um Job Baseada em Evento 14-15 Programação Baseada em Evento 14-16 Criando Programações Complexas 14-18 Criando Cadeias de Job 14-19 Exemplo de uma Cadeia 14-21 1. Criando um Objeto de Cadeia 14-22 2. Definindo Etapas da Cadeia 14-23 3. Definindo Regras da Cadeia 14-24 4. Iniciando a Cadeia 14-25 Monitorando Cadeias de Job 14-26 Conceitos Avançados do Scheduler 14-27 Criando uma Classe de Job 14-28 Criando uma Janela de Tempo 14-29 Priorizando Jobs em uma Janela de Tempo 14-30 Sumário 14-31 Visão Geral do Exercício: Automatizando Tarefas com o Scheduler 14-32

15 Segurança do Banco de Dados Objetivos 15-2 Oracle TDE (Transparent Data Encryption): Visão Geral 15-3 Processo da TDE 15-5 Implementando a TDE 15-6 Tabelas Existentes e TDE 15-9 TDE: Considerações 15-10 Suporte dos Wallets para Nomes de Usuários e Senhas 15-11 Data Pump e TDE (Transparent Data Encryption) 15-12 Backups Criptografados pelo RMAN: Visão Geral 15-13 Configuração do Modo Transparente 15-14 Configuração do Modo de Senha 15-15 Configuração do Modo Duplo 15-16 Backups Criptografados pelo RMAN: Considerações 15-17 Necessidade de Privacidade dos Dados 15-18 Definição e Uso de Termos 15-19 Virtual Private Database: Visão Geral 15-20 Virtual Private Database: Recursos 15-21 VPD em Nível de Coluna: Exemplo 15-22 Criando uma Política em Nível de Coluna 15-23 Sumário 15-24 Visão Geral do Exercício: Usando a Segurança do Banco de Dados Oracle 15-25

16 Usando o Suporte à Globalização Objetivos 16-2 O Que Todo DBA Precisa Saber 16-3 O Que É um Conjunto de Caracteres? 16-4 Noções Básicas de Unicode 16-6 Como os Conjuntos de Caracteres São Usados? 16-8

xi

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Problemas a Serem Evitados 16-9Outro Exemplo de Problema 16-10Como Escolher Seu Conjunto de Caracteres 16-11Conjuntos de Caracteres de Banco de Dados e Conjuntos de Caracteres Nacionais 16-12Como Obter Informações sobre Conjuntos de Caracteres 16-13Como Especificar um Comportamento Dependente do Idioma 16-14Como Especificar um Comportamento Dependente do Idioma para a Sessão 16-15Parâmetros Dependentes de Idioma e Território 16-16Como Especificar um Comportamento Dependente do Idioma 16-18Pesquisa e Classificação Lingüísticas 16-19Como Usar a Pesquisa e a Classificação Lingüística 16-21Pesquisa e Classificação sem Distinção de Acentos e entre Maiúsculas e Minúsculas 16-23Suporte em Cláusulas SQL e Functions 16-24Suporte a Índices Lingüísticos 16-25Como Personalizar a Pesquisa e a Classificação Lingüísticas 16-26Conversão Implícita entre CLOB e NCLOB 16-27Conversão de Dados NLS com Utilitários Oracle 16-28Conversão de Dados NLS com o Data Pump 16-30Características do Suporte à Globalização 16-31Sumário 16-32Visão Geral do Exercício: Usando Recursos do Suporte à Globalização 16-33

17 WorkshopObjetivos 17-2Metodologia do Workshop 17-3Necessidades de Negócios 17-5Configuração do Banco de Dados 17-6Método de Resolução de Problemas do Banco de Dados 17-7Sumário 17-9Visão Geral do Exercício: Configuração do Workshop 17-10

Apêndice A: Exercícios

Apêndice B: Soluções

Apêndice C: Comandos Básicos do Linux e do vi

Apêndice D: Acrônimos e Termos

Apêndice E: Servidores Compartilhados OracleObjetivos E-2Estabelecendo uma Conexão E-3Processo do Servidor Dedicado E-4Sessões do Usuário E-5Sessões do Usuário: Servidor Dedicado E-6Sessões do Usuário: Servidor Compartilhado E-7Processando uma Solicitação E-8SGA e PGA E-9

xii

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


UGA e Servidor Compartilhado Oracle E-10 Configurando o Servidor Compartilhado Oracle E-11 DISPATCHERS E-12SHARED_SERVERS E-14MAX_SHARED_SERVERS E-15CIRCUITS E-16SHARED_SERVER_SESSIONS E-17Parâmetros Relacionados E-18 Verificando a Configuração do Servidor Compartilhado E-19 Views de Dicionário de Dados E-21 Escolhendo um Tipo de Conexão E-22 Quando Não Usar o Servidor Compartilhado E-23 Sumário E-24

Apêndice F: Oracle Secure Backup Objetivos F-2 Proteção de Dados em Fita para a Pilha de Produtos Oracle F-3 A Vantagem para o Cliente: Solução Completa Oracle F-4 Oracle Secure Backup para Gerenciamento Centralizado de Backups em Fita F-5 Domínio Administrativo do Oracle Secure Backup F-6 Oracle Secure Backup: Visão Geral do Gerenciamento de Backup F-7 Catálogo do Oracle Secure Backup F-8 Usuários do Oracle Secure Backup F-9 Classes Predefinidas F-11 Opções de Interface do Oracle Secure Backup F-12 Gerenciando os Dados a Serem Protegidos F-13 Conceitos de Mídia do Oracle Secure Backup F-14 Reciclagem de Conjuntos de Volumes F-15 Gerenciamento Automatizado de Dispositivos F-17 Operações de Gerenciamento de Biblioteca F-18 Oracle Secure Backup: Instalação F-19 Instalando o Software Oracle Secure Backup F-20 Instalação do Servidor Administrativo: Exemplo F-21 Definindo o Servidor Administrativo no EM F-22 A Página Oracle Secure Backup Device and Media F-23 Adicionando Dispositivos F-24 Gerenciando Dispositivos com o EM F-25 RMAN e Oracle Secure Backup F-26 Acessando o Oracle Secure Backup no RMAN F-27 Pré-autorização do Usuário F-28 Seletor de Armazenamento de Backup de Banco de Dados F-29 RMAN e Oracle Secure Backup: Modelo de Uso F-30 Definindo o Seletor de Armazenamento de Banco de Dados F-31 Testando as Unidades de Fita F-32 Programando os Backups com o EM Database Control F-33

xiii

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Estratégia de Backup Sugerida pela Oracle F-34 Gerenciando Backups em Fita F-35 Executando a Recuperação do Banco de Dados com Backups em Fita F-36 Executando o Backup de Arquivos do Sistema de Arquivos com o Oracle Secure Backup F-37 Ferramenta Web do Oracle Secure Backup F-38 Scripts de Conjuntos de Dados do Oracle Secure Backup F-39 Script de Conjunto de Dados: Exemplos F-40 Organização do Conjunto de Dados F-41 Criando Conjuntos de Dados com a Interface Web F-42 Arquivos do Sistema de Arquivos: Conceitos de Backup F-43 Jobs do Oracle Secure Backup F-44 Criando Solicitações de Backup Sob Demanda F-46 Enviando Solicitações de Backup para o Scheduler F-47 Criando Programações de Backup F-48 Criando Triggers de Backup F-49 Verificando Históricos e Propriedades de Jobs F-50 Restaurando Arquivos do Sistema de Arquivos com o Oracle Secure Backup F-51 Criando uma Solicitação de Restauração Baseada em Catálogo F-52 Enviando Solicitações de Restauração Baseada em Catálogo para o Scheduler F-55 Listando Todos os Backups de um Cliente F-56 Sumário F-57

Apêndice G: Tópicos Diversos Visão Geral do Apêndice G-2 Tablespaces para Arquivos Grandes: Visão Geral G-3 Vantagens dos BFTs G-4 BFT: Modelo de Uso G-5 Criando Tablespaces para Arquivos Grandes G-7 Cláusulas de Instruções SQL G-8 BFTs e Instruções SQL: Exemplos G-9 Adições do Dicionário de Dados para Suporte a VLDB G-10 Formato ROWID Estendido e BFTs G-11 Suporte a VLDB: Pacote DBMS_ROWID G-13 TTG (Temporary Tablespace Group): Visão Geral G-14 Grupo de Tablespaces Temporários: Vantagens G-15 Criando e Mantendo TTGs G-16 Grupo de Tablespaces Temporários: Exemplos de Instruções SQL G-17 Sumário G-20

Apêndice H: Próximas Etapas: Continuando o Treinamento O Que Aprender Agora? H-2 Recursos para Dar Continuidade ao Programa de Estudos H-3 Oracle University H-4 Continuando o Treinamento H-5 Oracle University Knowledge Center H-6 Oracle Technology Network H-7

xiv

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Treinamento na Tecnologia Oracle H-8 Oracle by Example H-9 Oracle Magazine H-10 Oracle Applications Community H-11 Suporte Técnico: Oracle MetaLink H-12 Obrigado! H-13

Índice

xv

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Prefácio

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Prefácio - 3

Perfil

Antes de Iniciar Este CursoPara iniciar este curso, você deverá ter as seguintes qualificações:

• Experiência com SQL e conhecimento dos comandos básicos do UnixPré-requisitosOracle Database 10g: Workshop de Administração I (D17090GC30)

Organização deste CursoOracle Database 10g: Workshop de Administração I é um curso conduzido por instrutor que consiste em aulas e exercícios práticos. As sessões de demonstração on-line e os exercícios reforçam as técnicas e os conceitos apresentados.

Próximos Cursos Sugeridos • Oracle Database 10g: SQL Tuning Workshop (D17265GC10)• Oracle Enterprise Manager 10g Grid Control (D17244GC11)• Oracle Database 10g: Real Application Clusters (D17276GC10)• Oracle Database 10g: Implement Streams (D17333GC10)• Oracle Database 10g: Data Guard Administration (D17316GC11)

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Prefácio - 4

Publicações Relacionadas

Publicações OracleTitle Part Number Oracle Database 2 Day DBA 10g Release 2 (10.2) B14196-02Oracle Database Administrator's Guide 10g Release 2 (10.2) B14231-01Oracle Database Application Developer's Guide - Large Objects 10g Release 2 (10.2) B14249-01Oracle Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) B14191-02Oracle Database Backup and Recovery Basics 10g Release 2 (10.2) B14192-03Oracle Database Concepts 10g Release 2 (10.2) B14220-02Oracle Database Data Warehousing Guide 10g Release 2 (10.2) B14223-02Oracle Database Globalization Support Guide 10g Release 2 (10.2) B14225-01Oracle Database Licensing Information 10g Release 2 (10.2) B14199-02Oracle Database Net Services Administrator's Guide 10g Release 2 (10.2) B14212-02Oracle Database Net Services Reference 10g Release 2 (10.2) B14213-01Oracle Database New Features Guide 10g Release 2 (10.2) B14214-02Oracle Database Performance Tuning Guide 10g Release 2 (10.2) B14211-01Oracle Database PL/SQL Packages and Types Reference 10g Release 2 (10.2) B14258-01Oracle Database PL/SQL User's Guide and Reference 10g Release 2 (10.2) B14261-01Oracle Database Recovery Manager Quick Start Guide 10g Release 2 (10.2) B14193-03Oracle Database Recovery Manager Reference 10g Release 2 (10.2) B14194-03Oracle Database Reference 10g Release 2 (10.2) B14237-02Oracle Database Security Guide 10g Release 2 (10.2) B14266-01Oracle Database SQL Quick Reference 10g Release 2 (10.2) B14195-02Oracle Database SQL Reference 10g Release 2 (10.2) B14200-02Oracle Database Utilities 10g Release 2 (10.2) B14215-01Oracle Streams Advanced Queuing User's Guide and Reference B14257-01Oracle Streams Concepts and Administration B14229-01

Publicações Adicionais• Boletins de releases de sistemas• Manuais de instalação e do usuário• Arquivos read.me• Artigos do IOUG (International Oracle Users Group)• Oracle Magazine

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Prefácio - 5

Convenções TipográficasConvenções Tipográficas do Texto

Convenção Elemento Exemplo Negrito Palavras e expressões

enfatizadas somente no conteúdo da Web

Para navegar nessa aplicação, não clique nos botões Back e Forward.

Itálico negrito Termo de glossário (caso exista um glossário)

O algoritmo insere a nova chave.

Colchetes Nomes de teclas Pressione [Enter].

Maiúsculas e minúsculas

Botões, caixas de seleção, triggers de aplicação, janelas

Clique no botão Executable. Marque a caixa de seleção Can’t Delete Card. Atribua um trigger When-Validate-Item ao bloco ORD. Abra a janela Master Schedule.

Colchetes angulares

Caminhos de menu Selecione File > Save.

Vírgulas Seqüências de teclas Pressione e solte as seguintes teclas uma de cada vez: [Alt], [F], [D]

Courier new, distinção entre maiúsculas e minúsculas (o default é o uso de minúsculas)

Saída de código, nomes de diretório, nomes de arquivo, senhas, nomes de caminho, entrada do usuário, nomes de usuário

Saída de código: debug.set ('I', 300); Diretório: bin (DOS), $FMHOME (UNIX) Nome do arquivo: Localize o arquivo init.ora. Senha: Use tiger como senha. Nome do caminho: Abra c:\my_docs\projects. Entrada do usuário: Informe 300. Nome de usuário: Efetue login como HR.

Inicial maiúscula

Labels de gráficos (a menos que o termo seja um nome próprio)

Endereço do cliente (mas Oracle Payables)

Itálico Palavras e expressões enfatizadas, títulos de livros e cursos, variáveis

Não salve as alterações no banco de dados. Para obter mais informações, consulte o Oracle Database SQL Reference 10g Release 2(10.2). Digite [email protected], em que user_id é o nome do usuário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Prefácio - 6

Convenções Tipográficas (continuação)Convenções Tipográficas do Texto (continuação)

Convenções Tipográficas Usadas em Códigos

Convenção Elemento Exemplo

Aspas Elementos de interface com nomes longos e iniciais maiúsculas; títulos de lições e capítulos em referências cruzadas

Selecione “Include a reusable module component” e clique em Finish. Este assunto será abordado na lição “Trabalhando com Objetos”.

Letras maiúsculas

Nomes de colunas SQL, comandos, functions, esquemas, nomes de tabelas, nomes de triggers de banco de dados

Use o comando SELECT para exibir as informações armazenadas na coluna LAST_NAME da tabela EMPLOYEES.

Convenção Elemento Exemplo

Letras minúsculas

Nomes de colunas, tabelas e triggers de banco de dados

SELECT last_name FROM employees; CREATE OR REPLACE TRIGGER secure_employees

Senhas CREATE USER scott IDENTIFIED BY tiger;

Objetos PL/SQL items.DELETE(3);

Minúsculas em itálico

Variáveis de sintaxe

CREATE ROLE role

Letras maiúsculas

Comandos e funções SQL

SELECT first_name FROM employees;

O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ


Prefácio - 7

Convenções Tipográficas (continuação)Convenções Tipográficas em Caminhos de NavegaçãoEste curso usa caminhos de navegação simplificados, como o exemplo a seguir, para orientar você nos Aplicativos Oracle. Exemplo:

Sumário de Lotes de NFFs(N) Invoice > Entry > Invoice Batches Summary (M) Query > Find (B) Approve

Esse caminho simplificado pode ser traduzido da seguinte forma:1. (N) Na janela Navigator, selecione Invoice > Entry > Invoice Batches Summary.2. (M) No menu, selecione Query > Find.3. (B) Clique no botão Approve.Notação:

(N) = Navegador (I) = Ícone(M) = Menu (H) = Hiperlink(T) = Tab (B) = Botão

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Introdução

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Oracle Database 10g: Workshop de Administração II 1-2


Objetivos da Lição

Ao concluir esta lição, você será capaz de:• Listar os objetivos do curso e explicar a estrutura

da aula• Rever a arquitetura do Oracle Database 10g

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos do Curso

Neste curso, você obterá experiência no:• Uso do RMAN (Recovery Manager) em backup e

recuperação avançados • Emprego de práticas de monitoramento de banco de

dados relacionadas a memória, desempenho earmazenamento

• Gerenciamento de recursos, programações de jobs,segurança e problemas de globalização

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Programação Sugerida

1: Introdução2: Configurando o RMAN3: Usando o RMAN4: Recuperação Não Crítica

5: Recuperação6: Flashback7: Danos8: Memória

9: Desempenho

10: Esquema11: Armazenamento12: ASM

13: Recursos14: Scheduler15: Segurança

16: Globalização17: WorkshopApêndices

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Conteúdo do Curso DBAI

1. Introdução2. Instalação3. Criação de Bando de Dados4. Instância

5. Armazenamento6. Usuários7. Esquema8. Dados e Concorrência

9. Operações de Undo10. Segurança11. Rede12. Manutenção Pró-ativa

13. Desempenho14. Conceitos de Backup

e Recuperação15. Backup

16. Recuperação17. Flashback18. Movendo Dados

Conteúdo do Curso DBAI DBAI refere-se ao curso Oracle Database 10g: Workshop de Administração I (Release 2).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Exemplos do Curso: O Esquema HR

REGIONSREGION_ID (PK)REGION_NAME

COUNTRIESCOUNTRY_ID (PK)COUNTRY_NAMEREGION_ID (FK)

LOCATIONSLOCATION_ID (PK)STREET_ADDRESSPOSTAL_CODECITYSTATE_PROVINCECOUNTRY_ID (FK)

DEPARTMENTSDEPARTMENT_ID (PK)DEPARTMENT_NAMEMANAGER_IDLOCATION_ID (FK)

JOBSJOB_ID (PK)JOB_TITLEMIN_SALARYMAX_SALARY

EMPLOYEESEMPLOYEE_ID (PK)FIRST_NAMELAST_NAMEEMAILPHONE_NUMBERHIRE_DATEJOB_ID (FK)SALARYCOMMISION_PCTMANAGER_ID (FK)DEPARTMENT_ID (FK)

JOB_HISTORYEMPLOYEE_ID (PK)START_DATE (PK)END_DATEJOB_ID (FK)DEPARTMENT_ID (FK)

REGIONS

COUNTRIES

LOCATIONS

DEPARTMENTS

JOBS

EMPLOYEES

JOB_HISTORY

Exemplos do Curso: O Exemplo de Esquema HROs exemplos usados neste curso provêm de uma aplicação de recursos humanos (HR), que pode ser criada para integrar o banco de dados inicial. Veja abaixo algumas das regras de negócios mais importantes em aplicações de recursos humanos:

• Cada departamento pode ser empregador de um ou mais funcionários. Cada funcionário só pode ser atribuído a um único departamento.

• Cada cargo deve ser preenchido por um ou mais funcionários. Cada funcionário só deve ser atribuído a um único cargo em um momento.

• Quando um funcionário muda de departamento ou cargo, um registro na tabela JOB_HISTORY marca as datas de início e fim das últimas atribuições.

• Os registros de JOB_HISTORY são identificados por uma chave primária composta (PK): as colunas EMPLOYEE_ID e START_DATE.

Notação: PK = chave primária; FK = chave estrangeira As linhas contínuas representam restrições obrigatórias da chave estrangeira (FK), e as linhas tracejadas representam restrições opcionais da FK. A tabela EMPLOYEES também contém uma restrição de FK. Esta é uma implementação da regra de negócios: cada funcionário só pode se reportar diretamente a um único gerente. A FK é opcional porque o funcionário de nível mais alto não se reporta a outro funcionário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Oracle Database 10g: O Banco de Dados para a Grade

• ASM (Automatic Storage Management)• Clusterware portável• RAC (Real Application Clusters) e gerenciamento

automático de carga de trabalho• Resource Manager • Oracle Streams• Gerenciamento centralizado com o Enterprise

Manager Grid Control• Novos recursos de auto-gerenciamento do Oracle

Database 10g

Oracle Database 10g: O Banco de Dados para a Grade O Oracle Database 10g é o primeiro banco de dados projetado para a computação em grade. Para resumir, veja abaixo alguns dos recursos mais importantes:

• O ASM (Automatic Storage Management) virtualiza o armazenamento e permite provisionar com facilidade o armazenamento no banco de dados.

• O Oracle Database 10g oferece clusterware portável executado em todas as plataformas.• O Oracle Database 10g oferece gerenciamento automático de carga de trabalho para os

serviços internos de um banco de dados RAC. • O Oracle Database 10g fornece mapeamentos adicionais para grupos de consumidores com

base na máquina host do usuário, na aplicação, no nome do usuário no sistema operacional ou no serviço.

• O Oracle Streams pode criar fluxos de dados entre os bancos de dados, os nós ou as blade farms em uma grade. Ele fornece uma estrutura unificada para o compartilhamento de informações, reunindo enfileiramentos de mensagens, replicação, eventos e carga de data warehouse em uma única tecnologia.

• O Enterprise Manager Grid Control fornece uma única ferramenta que pode monitorar e gerenciar todos os elementos de software Oracle (Oracle Application Server 10g e Oracle Database 10g) na grade, bem como as aplicações Web via APM (Application Performance Management), hosts, dispositivos de armazenamento e balanceadores de carga de servidores.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Arquitetura do Banco de Dados: Revisão

Estruturas de armazenamento

Estruturas de memória

Estruturas do processo

Instância

SGA (System Global Area)

Processos de background

Arquivos do banco de dados

Arquitetura do Banco de Dados: Revisão As páginas a seguir oferecem uma revisão básica da arquitetura do banco de dados Oracle. Neste curso, você aprofundará seu conhecimento sobre as estruturas, os processos e os utilitários do banco de dados Oracle. Cada banco de dados Oracle em execução é associado a uma instância Oracle. Quando um banco de dados é iniciado em um servidor de banco de dados, o software Oracle aloca uma área de memória compartilhada chamada SGA (System Global Area) e inicia vários processos de background Oracle. Essa combinação de SGA e processos Oracle é chamada de instância Oracle. Depois de iniciar uma instância, o software Oracle associa a instância a um banco de dados específico. Essa operação recebe o nome de montagem do banco de dados. O banco de dados está pronto para ser aberto, o que o torna acessível a usuários autorizados. É possível executar várias instâncias simultaneamente no mesmo computador, cada uma acessando seu próprio banco de dados físico. Você pode considerar a arquitetura do banco de dados Oracle como vários componentes estruturais interrelacionados. Um banco de dados Oracle usa estruturas e processos de memória para gerenciar e acessar o banco de dados. Todas as estruturas de memória se situam na memória principal dos computadores que compõem o servidor do banco de dados. Os processos são jobs que trabalham na memória desses computadores. Um processo é definido como uma “elemento de controle” ou um mecanismo de um sistema operacional que pode executar uma série de procedimentos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Estruturas de Memória Oracle

Java pool Cache de bufferdo banco de dados

Buffer deredo log

Shared pool Large pool

SGA

Streams pool

Processodo servidor

1PGA

Processodo servidor

2PGA Processo de

background PGA

Estruturas de Memória Oracle As estruturas de memória básicas associadas a uma instância Oracle incluem:

• SGA (System Global Area): Compartilhada por todos os processos do servidor e de background

• PGA (Program Global Area): Exclusiva de cada servidor e processo de background. Há uma PGA para cada processo

A SGA é uma área da memória que contém dados e informações de controle da instância. Ela inclui as seguintes estruturas de dados:

• Cache de buffer do banco de dados: Armazena no cache blocos de dados recuperados do banco de dados

• Buffer de redo log: Armazena no cache informações de redo (usadas na recuperação dainstância) até que elas possam ser gravadas nos arquivos físicos de redo log armazenados no disco

• Shared pool: Armazena no cache várias estruturas que podem ser compartilhadas pelos usuários

• Large pool: É uma área opcional que aloca parte considerável da memória para alguns processos grandes, como operações de backup e recuperação Oracle e processos de entrada/saída do servidor

• Java pool: Usado para armazenar todos os códigos Java específicos da sessão e dados da JVM (Java Virtual Machine)

• Streams pool: Usado pelo Oracle Streams Quando você iniciar a instância usando o Enterprise Manager ou o SQL*Plus, será exibido o volume de memória alocado para a SGA.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Estruturas de Memória Oracle (continuação) A PGA (Program Global Area) é uma região da memória que contém informações de controle e dados de cada processo do servidor. Um processo do servidor Oracle atende às solicitações de um cliente. Cada processo do servidor tem sua própria PGA privada, criada quando o processo é iniciado. O acesso à PGA é exclusivo desse processo do servidor, e a PGA é lida e gravada apenas pelo código Oracle que está atuando em seu nome. A infra-estrutura dinâmica da SGA permite alterar o tamanho do cache de buffer do banco de dados, do shared pool, do large pool, do Java pool e do Streams pool sem fazer shutdown da instância. Os bancos de dados Oracle usam parâmetros de inicialização para criar e configurar estruturas de memória. Por exemplo, o parâmetro SGA_TARGET especifica o espaço total disponível para a SGA. Se você definir o parâmetro SGA_TARGET como 0, o Gerenciamento Automático da Memória Compartilhada será desativado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Processos Oracle

SystemMonitor(SMON)

DatabaseWriter

(DBWn)

Check-point

(CKPT)

LogWriter(LGWR)

ProcessMonitor(PMON)

Archiver(ARCn)

Processodo servidor

Processodo servidor

Processodo servidor

Processodo servidor

SGA(System Global Area)

Processos de background

Processos Oracle Quando você chama um programa de aplicação ou uma ferramenta Oracle, como o Enterprise Manager, o servidor Oracle cria um processo do servidor para executar os comandos da aplicação. O servidor Oracle também cria um conjunto de processos de background para uma instância, que interagem entre si e com o sistema operacional para gerenciar as estruturas da memória e executar entradas/saídas assincronamente a fim de gravar dados em disco, além de realizar outras tarefas necessárias. Os processos de background que estarão presentes dependem dos recursos usados no banco de dados. Estes são os processos de background mais comuns:

• SMON (System Monitor): Executa a recuperação de falha quando a instância é iniciada após uma falha

• PMON (Process Monitor): Executa a limpeza do processo quando ocorre uma falha em um processo do usuário

• DBWn (Database Writer): Grava blocos modificados do cache de buffer do banco de dados nos arquivos de dados no disco

• CKPT (Checkpoint): Atualiza todos os arquivos de dados e controla arquivos do banco de dados para indicar o checkpoint mais recente

• LogWriter (LGWR): Grava as entradas de redo log em disco • ARCn (Archiver): Copia arquivos de redo log para um armazenamento quando ocorre

uma alternância de log

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Revisando o Gerenciamentode Instâncias Oracle

SGA

DatabaseWriter

(DBWn)

LogWriter(LGWR)

Cache de bufferdo banco de dados

Bufferde redo log

1

Processodo usuário

2

Exemplo:Iniciando uma instância do

banco de dadosEstabelecendo uma conexão

SystemMonitor(SMON)

ProcessMonitor(PMON)

Arquivos de dados Arquivos de redo log

Instância

Processodo servidor3

Revisando o Gerenciamento de Instâncias Oracle O exemplo a seguir descreve o nível mais básico de operações realizadas pelo banco de dados Oracle. Ele ilustra uma configuração Oracle quando o usuário e os processos do servidor associados estão em computadores diferentes (conectados por uma rede).

1. Uma instância foi iniciada no computador que está executando o Oracle (freqüentemente chamado de host ou servidor do banco de dados ).

2. Um computador que executa uma aplicação (um computador local ou estação de trabalho cliente) executa essa aplicação em um processo do usuário. A aplicação cliente tenta estabelecer uma conexão com a instância usando o driver do Oracle Net Services.

3. A instância detecta a solicitação de conexão da aplicação e se conecta a um processo do servidor em nome do processo do usuário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




O usuário atualizauma linha.

Arquivosde redo log

Revisando o Gerenciamentode Instâncias Oracle

InstânciaSGA

DatabaseWriter

(DBWn)


Buffer deredo log

Processodo servidor

Processodo usuário

4

10

7

6

5

8

Exemplo:Processando uma

instrução SQL

Archiver(ARCn)

9

Checkpoint(CKPT)

Arquivosde dados

Logs dearquivamento

Arquivode controle

LogWriter(LGWR)

Revisando o Gerenciamento de Instâncias Oracle (continuação) 4. O usuário atualiza uma linha. 5. O processo do servidor recebe a instrução e verifica se ela já está no shared pool da SGA.

Se a área SQL compartilhada for encontrada, o processo do servidor verificará os privilégios de acesso do usuário aos dados solicitados, e a área SQL compartilhada existente anteriormente será usada para processar a instrução. Se a instrução não estiver no shared pool, uma nova área SQL compartilhada será alocada para a instrução para ser analisada por parse e processada.

6. O processo do servidor recupera todos os valores de dados necessários do arquivo de dados (tabela) real ou de blocos de dados armazenados na SGA.

7. O processo do servidor modifica os dados da tabela na SGA. 8. Quando a transação é enviada, o processo LGWR registra imediatamente a transação no

arquivo de redo log. 9. O processo DBWn grava blocos modificados no disco quando essa gravação é eficiente. 10. O processo do servidor envia à aplicação uma mensagem de êxito ou de erro pela rede.

Durante todo esse procedimento, os outros processos de background são executados, procurando condições que exigem intervenção.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Estrutura Física do Banco de Dados

Arquivos deredo log on-line

Arquivo de senha

Arquivo de parâmetros Arquivos de log de arquivamento

Arquivos de controle Arquivos de dados

Arquivos de log de alerta e rastreamento

Arquivos de backup

Estrutura Física do Banco de Dados Os arquivos que constituem um banco de dados Oracle são organizados da seguinte forma:

• Arquivos de controle: Contêm dados sobre o próprio banco de dados (isto é, informações sobre a estrutura física do banco de dados). Eles são fundamentais para o banco de dados. Sem eles, não é possível abrir os arquivos de dados para acessar os dados do banco de dados.

• Arquivos de dados: Contêm os dados do usuário ou da aplicação do banco de dados. • Arquivos de redo log on-line: Permitem uma recuperação de instância do banco de dados.

Se o banco de dados travar sem perder arquivos de dados, a instância poderá recuperá-lo com as informações desses arquivos.

Os arquivos adicionais abaixo são importantes para a execução bem-sucedida do banco de dados:

• Arquivo de parâmetros: Usado para definir o modo de configuração da instância durante sua inicialização.

• Arquivo de senha: Permite que os usuários estabeleçam uma conexão remota com o banco de dados e executem tarefas administrativas.

• Arquivos de backup: Usados para a recuperação do bancos de dados. Geralmente, restaura-se um arquivo de backup quando uma falha de mídia ou um erro do usuário danifica ou deleta o arquivo original.

• Arquivos de log de arquivamento: Contêm um histórico contínuo das alterações de dados (redo) que são geradas pela instância. Usando esses arquivos e um backup do banco de dados, você pode recuperar um arquivo de dados perdido. Isto é, os logs de arquivamento permitem a recuperação de arquivos de dados restaurados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Estrutura Física do Banco de Dados (continuação) • Arquivos de rastreamento: Todo processo do servidor e de background pode gravar em

um arquivo de rastreamento associado. Quando um processo detecta um erro interno, ele descarrega as informações sobre o erro no respectivo arquivo de rastreamento. Algumas informações gravadas em um arquivo de rastreamento são destinadas ao administrador do banco de dados, enquanto outras informações seguem para o Oracle Support Services.

• Arquivos de log de alerta: Também conhecidos como logs de alerta, são arquivos de rastreamento especiais. O log de alerta de um banco de dados consiste em um log cronológico de mensagens e erros. A Oracle recomenda analisar esses arquivos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Exemplo:SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/oradata'; SQL> CREATE TABLESPACE tbs_1;

OMF (Oracle Managed Files)Especificam operações de arquivos em termos deobjetos do banco de dados, e não por nome de arquivo.

Define o local dos backups do RMAN

DB_RECOVERY_FILE_DEST

Define o local dos arquivos de redo log e a criação do arquivo de controle

DB_CREATE_ONLINE_LOG_DEST_n

Define o local do diretório default do sistema de arquivos para arquivos de dados e arquivos temporários

DB_CREATE_FILE_DEST.

DescriçãoParâmetro

OMF (Oracle Managed Files) O recurso OMF (Oracle Managed Files) elimina a necessidade de gerenciar diretamente os arquivos do sistema operacional que compõem o banco de dados Oracle. Você especifica as operações em termos de objetos do banco de dados, e não por nome de arquivo. O banco de dados usa interfaces do sistema de arquivos padrão internamente para criar e deletar arquivos conforme necessário para as seguintes estruturas do banco de dados:

• Tablespaces • Arquivos de redo log • Arquivos de controle • Logs arquivados • Arquivos de rastreamento de alterações em blocos • Logs de flashback • Backups do RMAN

Um banco de dados pode conter uma combinação de arquivos gerenciados e não gerenciados pelo Oracle. O diretório do sistema de arquivos especificado por qualquer um desses parâmetros deve existir previamente; o banco de dados não o cria. O diretório também deve ter as permissões necessárias para que o banco de dados crie arquivos nele. O exemplo mostra que, após a definição do parâmetro DB_CREATE_FILE_DEST, a cláusula DATAFILE pode ser omitida da instrução CREATE TABLESPACE. O arquivo de dados é criado no local especificado por DB_CREATE_FILE_DEST.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Estruturas Lógicas eFísicas do Banco de Dados

Banco de dados

Lógico Físico

Tablespace Arquivode dados

Bloco dosistema operacional

Segmento

Extensão

Bloco de dadosOracle

Esquema

Estruturas Lógicas e Físicas do Banco de Dados O banco de dados Oracle é um conjunto de dados tratados como uma unidade. O objetivo geral de um banco de dados é armazenar e recuperar informações relacionadas. O banco de dados tem estruturas lógicas e físicas. TablespacesUm banco de dados é dividido em unidades lógicas de armazenamento, denominadas tablespaces, que agrupam estruturas lógicas relacionadas. Por exemplo, tablespaces geralmente agrupam todos os objetos de uma aplicação para simplificar algumas operações administrativas. Você pode ter um tablespace para os dados da aplicação e outro para os índices da aplicação. Bancos de Dados, Tablespaces e Arquivos de Dados A relação entre bancos de dados, tablespaces e arquivos de dados é ilustrada no slide. Cada banco de dados está dividido logicamente em um ou mais tablespaces. Um ou mais arquivos de dados são criados de forma explícita para cada tablespace a fim de armazenar fisicamente os dados de todas as estruturas lógicas em um tablespace. No caso de um tablespace TEMPORARY, em vez de um arquivo de dados, o tablespace terá um arquivo temporário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Estruturas Lógicas e Físicas do Banco de Dados (continuação) EsquemasUm esquema é um conjunto de objetos de banco de dados pertencentes a um usuário de banco de dados. Os objetos de um esquema são as estruturas lógicas que fazem referência direta aos dados do banco de dados. Esses objetos incluem estruturas como tabelas, views, sinônimos, seqüências, procedures armazenados, índices, clusters e links de banco de dados. Em geral, os objetos do esquema incluem tudo que a aplicação cria no banco de dados. Blocos de DadosNo nível mais fino de granularidade, os dados de um banco de dados Oracle são armazenados em blocos de dados. Um bloco de dados corresponde a um número específico de bytes de espaço no banco de dados físico no disco. Um tamanho de bloco de dados é especificado para cada tablespace quando ele é criado. Um banco de dados usa e aloca o espaço livre em blocos de dados do Oracle. ExtensõesO próximo nível de espaço no banco de dados lógico é chamado de extensão. Uma extensão é um número específico de blocos de dados contíguos (obtidos de uma única alocação) que são usados para armazenar um tipo específico de informação. SegmentosO nível de armazenamento do banco de dados lógico acima de uma extensão é chamado de segmento. Um segmento é um conjunto de extensões alocadas para determinada estrutura lógica. Por exemplo, os tipos diferentes de segmentos incluem:

• Segmentos de dados: Cada tabela não clusterizada e não organizada em índice tem um segmento de dados. Todos os dados da tabela são armazenados nas extensões de seus segmentos de dados. Em uma tabela particionada, cada partição tem um segmento de dados. Cada cluster tem um segmento de dados. Os dados de cada tabela no cluster são armazenados no segmento de dados do cluster.

• Segmentos de índice: Cada índice tem um segmento de índice que armazena todos os seus dados. Em um índice particionado, cada partição tem um segmento de índice.

• Segmentos de undo: Um tablespace UNDO é criado pelo administrador do banco de dados para armazenar temporariamente informações de undo. As informações de um segmento de undo são usadas para gerar informações de banco de dados com leitura consistente e, durante a recuperação do banco de dados, para fazer rollback de transações sem commit para usuários.

• Segmentos temporários: Os segmentos temporários são criados pelo banco de dados Oracle quando uma instrução SQL precisa de uma área de trabalho temporária para concluir a execução. Quando a execução da instrução é concluída, as extensões do segmento temporário são retornadas à instância para uso futuro. Especifique um tablespace temporário default para cada usuário ou um tablespace temporário default usado em todo o banco de dados.

O banco de dados Oracle aloca espaço dinamicamente. Quando as extensões existentes de um segmento ficam cheias, são adicionadas extensões. Como as extensões são alocadas conforme necessário, as extensões de um segmento podem ou não ser contíguas no disco.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Arquitetura do Banco de Dados:Resumo dos Componentes Estruturais

• Estruturas de memória– SGA (System Global Area): Cache de buffer do banco

de dados, buffer de redo e vários pools – PGA (Program Global Area)

• Estruturas de processo – Processos do usuário e do servidor:– Processos de background: SMON, PMON, DBWn,

CKPT, LGWR, ARCn e assim por diante • Estruturas de armazenamento

– Lógicas: Banco de dados, esquema, tablespace,segmento, extensão e bloco Oracle

– Físicas: Arquivos para dados, parâmetros, redo ebloco do sistema operacional

Arquitetura do Banco de Dados: Resumo dos Componentes Estruturais Você reviu em um nível superior os componentes estruturais do banco de dados Oracle: memória, estruturas do processo e estruturas de armazenamento. A compreensão da arquitetura do banco de dados Oracle é pré-requisito para este curso.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a:• Listar os objetivos do curso• Rever a arquitetura do Oracle Database 10g

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Configurando o Recovery Manager

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Descrever o repositório e o catálogo de recuperação

do RMAN• Descrever a interface da MML (Media Management

Library)• Configurar parâmetros de banco de dados que afetam

as operações do RMAN• Conectar-se a três tipos diferentes de bancos de dados

com o RMAN• Configurar dois tipos de políticas de retenção • Alterar as definições default do RMAN com CONFIGURE

Objetivos O RMAN (Recovery Manager) é o componente do banco de dados Oracle usado para executar operações de backup e recuperação. O EM (Enterprise Manager) fornece uma interface gráfica para as funcionalidades do RMAN usadas com mais freqüência. O curso Oracle Database 10g: Workshop de Administração I demonstrou as operações básicas do RMAN com a Console do EM Database Control. Portanto, a interface gráfica para o RMAN não é abordada com detalhes nesta lição.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Backup e Recuperação: Revisão

Os principais tópicos relacionados a backup erecuperação abordados no Curso de Administração deBanco de Dados I são:• Tipos de falhas que podem ocorrer

– Instrução, sessão, instância, mídia e assim por diante• Como configurar o modo ARCHIVELOG

• Como automatizar backups • Como fazer backups incrementais• Como executar e ajustar a recuperação de instância

Backup e Recuperação: Revisão O curso Oracle Database 10g: Workshop de Administração I abordou os tópicos relacionados a backup e recuperação listados no slide. As lições a seguir analisam esses tópicos com mais detalhes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recursos do Recovery Manager

O RMAN permite realizar as seguintes tarefas de formaflexível:• Fazer backup do bancos de dados, inclusive de

arquivos de dados, arquivos de controle e redo logsarquivados

• Gerenciar tarefas de backup e recuperação • Executar backup incremental e recuperação de mídia

no nível do bloco • Detectar blocos danificados durante operações de

backup• Usar compactação binária durante a criação de

backups

Recursos do Recovery Manager O RMAN é um utilitário Oracle usado no gerenciamento de operações de backup, restauração e recuperação de bancos de dados Oracle. Ele tem uma avançada linguagem de comandos que independe do sistema operacional. O RMAN contém vários recursos que não estão disponíveis em backups gerenciados pelo usuário que utilizam comandos do sistema operacional.

• Você pode armazenar as operações executadas com freqüência no banco de dados como scripts.

• Com o rastreamento de alterações em blocos ativado no banco de dados, o RMAN pode limitar os backups incrementais ao registro apenas dos blocos alterados desde o último backup. Com isso, há uma melhoria no desempenho dos backups e uma redução no tempo necessário para realizar operações de backup no modo ARCHIVELOG.

• É possível utilizar o RMAN para gerenciar o tamanho dos componentes de backup e poupar tempo, paralelizando a operação de backup.

• O RMAN pode recuperar um bloco de dados individual ou um conjunto de bloco de dados danificado dentro de um arquivo de dados, em vez de restaurar e recuperar todo o arquivo de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recursos do Recovery Manager (continuação) • É possível integrar as operações do RMAN às do Scheduler para automatizar os backups. O

Scheduler é abordado na lição “Automatizando Tarefas com o Scheduler”. • Você pode usar o RMAN para detectar blocos danificados. As informações relativas aos

blocos danificados detectados durante o backup podem ser obtidas com o auxílio das views dinâmicas V$BACKUP_CORRUPTION e V$COPY_CORRUPTION.

• O RMAN proporciona melhorias de desempenho como: – Paralelização automática de operações de backup, restauração e recuperação – Nenhuma geração de redo extra durante backups on-line do banco de dados – Backups restritos para limitar o número de leituras por arquivo por segundo, de modo

a evitar interferências no trabalho de OLTP – O uso de multiplexação, que pode impedir a sobrecarga de leituras e gravações nos

arquivos durante o streaming de uma unidade de fita • O RMAN tem uma API de gerenciamento de mídia para garantir a integração com

ferramentas de gerenciamento de mídia terceirizadas que tenham interface com dispositivos de armazenamento, o que possibilita maior velocidade e confiabilidade.

• O Oracle Secure Backup permite que o RMAN faça backup em fita sem ferramentas de gerenciamento de mídia de terceiros.

• No método gerenciado pelo usuário, você precisa controlar todos os backups e arquivos do banco de dados. Em uma situação de recuperação, você deve localizar backups para cada arquivo de dados, copiá-los para o local correto utilizando comandos do sistema operacional e escolher os arquivos de redo log a serem aplicados. O RMAN gerencia essas tarefas automaticamente. As vantagens do uso do RMAN serão ainda maiores se você usar o recurso Oracle Managed Files ou a área de recuperação flash.

ObservaçãoNem todos esses recursos são abordados neste curso. Para obter mais informações sobre:

• O RMAN e suas opções, consulte a documentação Oracle Database Backup and Recovery Basics e Oracle Database Backup and Recovery Advanced User’s Guide

• A sintaxe dos comandos do RMAN, consulte o Oracle Database Recovery Manager Reference Manual O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Sessão doservidor

Canal

Sessão doservidor

Enterprise Manager

Componentes do Recovery Manager

Banco de dados de destino

Banco de dados do

catálogo derecuperação

Banco de dados auxiliar

Disco Área derecuperação flash

Canal Canal

MML

Opções

RecoveryManager(RMAN)

Componentes do Recovery Manager Executável do Recovery Manager: A interface de linha de comandos do Recovery Manager é chamada por meio da aplicação cliente do RMAN. O RMAN interpreta os comandos do usuário e chama de forma adequada as sessões do servidor para realizar as tarefas desejadas. Enterprise Manager: A Console do EM Database Control fornece uma interface gráfica para as funcionalidades do RMAN usadas com mais freqüência. Sessões do servidor: Os processos do servidor (UNIX) ou threads (Windows 2000) chamados pelo RMAN estabelecem uma conexão com o banco de dados de destino para executar as funções de backup, restauração e recuperação através de uma interface PL/SQL. Essas sessões lêem ou gravam arquivos em disco, fita ou na área de recuperação flash, que é um local de armazenamento especificado como área de armazenamento default para arquivos relacionados à recuperação do banco de dados. Banco de dados de destino: O banco de dados cujas operações de backup e recuperação estão sendo executadas com o RMAN é chamado de banco de dados de destino. O arquivo de controle do banco de dados de destino contém informações sobre sua estrutura física, como o tamanho e a localização dos arquivos de dados, arquivos de redo log on-line arquivados e arquivos de controle. Essas informações são usadas pelas sessões do servidor chamadas pelo RMAN durante operações de backup e recuperação.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Componentes do Recovery Manager (continuação) Banco de dados auxiliar: Um banco de dados auxiliar é usado durante a duplicação de um banco de dados ou a execução de TSPITR (tablespace point-in-time recovery, recuperação pontual de tablespaces). Para as tarefas, o banco de dados auxiliar serve como destino da nova cópia do banco de dados ou dos tablespaces recuperados. Esse tipo de banco de dados pode residir no mesmo host que seu pai ou em outro host. O banco de dados auxiliar é apresentado nesta lição com fins meramente informativos. Para obter mais informações, consulte o Oracle Database Backup and Recovery Advanced User’s Guide. Canal: Um canal representa um fluxo de dados direcionado para um tipo de dispositivo. Para executar e registrar operações de backup e recuperação, o RMAN precisa de um link com o banco de dados de destino. Um canal estabelece esse link criando uma sessão no banco de dados de destino capaz de fazer interface com o sistema de arquivos do host (para fazer interface com discos) e com a MML (Media Management Library) (para fazer interface com fitas). Os canais podem ser alocados manualmente ou pré-configurados com o recurso de alocação automática de canais. Repositório do RMAN: O RMAN mantém no repositório metadados sobre o banco de dados de destino e suas operações de backup e recuperação. Entre outras coisas, o RMAN armazena em disco ou fita informações sobre suas próprias definições de configuração, o esquema do banco de dados de destino, redo logs arquivados e todos os arquivos de backup. Os dados do repositório do RMAN sempre são armazenados no arquivo de controle do banco de dados de destino. Catálogo de recuperação: Opcionalmente, os dados do repositório do RMAN podem ser mantidos em um catálogo de recuperação, que é um banco de dados Oracle separado. Media Management Library: A MML (Media Management Library) é usada pelo RMAN durante a gravação ou a leitura de fitas. O software de gerenciamento de mídia adicional necessário para usar a mídia de fita é desenvolvido pelos fornecedores de sistemas de armazenamento e mídia. Além disso, o produto Oracle Secure Backup permite que o RMAN faça backup em fita sem exigir ferramentas de terceiros.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Etapas de Configuração do RMAN

1. Determine o local do repositório: arquivo de controle ou catálogo de recuperação.

2. Defina as variáveis do banco de dados e do ambiente.

3. Inicie o RMAN e conecte-se ao banco de dados de destino e, opcionalmente, ao catálogo de recuperação.

4. Configure definições persistentes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Armazenamento de Dados do Repositório do RMAN: Comparação de Opções

Arquivo de controle:– Administração mais simples– Default

Catálogo de recuperação:– Replica os dados do arquivo de controle– Tem espaço para mais dados– Pode atender vários destinos– Pode armazenar scripts RMAN

MetadadosLista de conjuntos de backup

Lista de cópias de imagem...

Armazenamento de Dados do Repositório do RMAN: Comparação de Opções Os dados do repositório do RMAN sempre são armazenados no arquivo de controle do banco de dados de destino. No entanto, eles também podem ser armazenados em um banco de dados separado, chamado catálogo de recuperação. O catálogo de recuperação preserva as informações de backup em outro banco de dados, o que é útil em caso de perda de um arquivo de controle. Assim, é possível armazenar um histórico de backups mais longo do que com um repositório baseado em arquivo de controle. Um único catálogo de recuperação pode armazenar as informações de vários bancos de dados de destino. O catálogo de recuperação também pode conter scripts armazenados do RMAN, que são seqüências de comandos do RMAN para as tarefas de backup mais comuns. O armazenamento centralizado de scripts no catálogo de recuperação pode ser mais conveniente do que o uso de arquivos de comandos. A utilização de um banco de dados de catálogo de recuperação separado não é recomendável para pequenas instalações nas quais a administração desse tipo de banco de dados é onerosa.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Armazenamento de Dados do Repositório do RMAN: Comparação de Opções (continuação)

Como Configurar um Catálogo de Recuperação 1. Crie o banco de dados a ser usado como catálogo de recuperação. Se preferir, identifique

um banco de dados existente e use-o. Como um único catálogo de recuperação pode atender a mais de um banco de dados, você pode optar por criar um único catálogo de recuperação para atender a todos os bancos de dados que estão sofrendo backup.

2. No banco de dados do catálogo de recuperação, crie o usuário que será o proprietário dos dados do catálogo de recuperação. Por exemplo, suponha que catdb seja o nome do banco de dados do catálogo e que rcat_ts seja o nome do tablespace que você criou no local onde os dados do catálogo serão armazenados.

$ sqlplus sys/password@catdb as sysdba

SQL> CREATE USER rman IDENTIFIED BY cat 2 TEMPORARY TABLESPACE temp 3 DEFAULT TABLESPACE rcat_ts 4 QUOTA UNLIMITED ON rcat_ts;

SQL> GRANT UNLIMITED ON rcat_ts TO rman;

3. Conceda a atribuição RECOVERY_CATALOG_OWNER ao proprietário do catálogo. Essa atribuição fornece ao usuário todos os privilégios necessários para manter e consultar o catálogo de recuperação.

GRANT RECOVERY_CATALOG_OWNER TO rman;

4. Inicie o RMAN e efetue login como proprietário do catálogo. $ rman catalog rman/cat@catdb RMAN> CREATE CATALOG TABLESPACE rcat_ts;

5. Conecte-se ao banco de dados de destino com o RMAN e registre-o no catálogo de recuperação criado recentemente.

$ rman target sys/oracle@orcl catalog rman/cat@catdb

RMAN> register database;

Observação: É importante fazer backup do banco de dados do catálogo de recuperação.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Destinos de Backup

Os backups podem ser gravados no(a): • Diretório do disco • MML (dispositivo de fita)

– Geralmente usada na recuperação após desastres, quando os backups em disco são perdidos

• Área de recuperação flash – É uma área do disco separada para fins de backup e

recuperação, bem como de flashback de banco de dados.

– Você define o local e o tamanho. – Os arquivos são nomeados automaticamente com o

recurso Oracle Managed Files. – Os arquivos são retidos e deletados automaticamente

conforme necessário.

Destinos de Backup Os backups podem ser gravados em um diretório de disco designado, na MML (Media Management Library) ou na área de recuperação flash. A especificação de um diretório de disco ou da área de recuperação flash significa que os backups vão para a mídia do disco rígido. Geralmente, eles são movidos off-line para fita por meio da interface de gerenciamento de mídia para manter a disponibilidade do espaço em disco. Qualquer diretório de disco pode ser especificado como destino de um backup, contanto que ele já exista. Se você configurar uma área de recuperação flash, muitas tarefas de backup e recuperação serão simplificadas. O banco de dados Oracle nomeia automaticamente os arquivos e deleta os arquivos obsoletos quando há necessidade de espaço.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciamento de Mídia

RecoveryManager

Software do servidorde gerenciamento

de mídia

Biblioteca degerenciamento

de mídia

Sessão doservidor(canal)

Oracle SecureBackup com

MML incorporada

Ou

Gerenciamento de Mídia Para armazenar em fita os backups do banco de dados, o RMAN requer o Oracle Secure Backup ou um gerenciador de mídia. Para obter informações sobre o Oracle Secure Backup, consulte o Apêndice F. Um gerenciador de mídia é um utilitário que carrega, identifica e descarrega mídias seqüenciais, como unidades de fita, para fins de backup, restauração e recuperação de dados. O banco de dados Oracle chama rotinas de software MML para fazer backup e restaurar arquivos de dados de uma mídia controlada pelo gerenciador de mídia. Alguns produtos de gerenciamento de mídia podem gerenciar completamente toda a movimentação de dados entre os arquivos de dados do Oracle e os dispositivos de backup. Alguns produtos que utilizam conexões em alta velocidade entre subsistemas de mídia e armazenamento podem reduzir muito a carga de backup do servidor do banco de dados principal. Lembre-se de que o banco de dados Oracle não precisa estabelecer conexão com o software MML quando faz backup em disco.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Gerenciamento de Mídia (continuação) O Oracle BSP (Backup Solutions Program) dispõe de uma variedade de produtos para gerenciamento de mídia compatíveis com a especificação MML da Oracle. Um software compatível com a interface MML permite que uma sessão do banco de dados Oracle faça backup no gerenciador de mídia e que solicite ao gerenciador a restauração dos backups. Informe-se com o seu fornecedor de mídia se o gerenciador integra o Oracle BSP. Antes de começar a usar o RMAN com um gerenciador de mídia, você deve instalar o software do gerenciador de mídia e verificar se o RMAN consegue se comunicar com ele. Você poderá encontrar instruções sobre esse procedimento na documentação do software do fornecedor do gerenciador de mídia. Dependendo do produto que está sendo instalado, siga este procedimento básico:

1. Instale e configure o software de gerenciamento de mídia no host de destino ou na rede de produção. Nesse estágio, não há necessidade de integração com o RMAN.

2. Verifique se é possível fazer backups, sem usar o RMAN, de arquivos do sistema operacional no host do banco de dados de destino. Essa etapa facilita o diagnóstico e a solução de problemas posteriormente. Consulte a documentação do gerenciador de mídia para saber como fazer backup de arquivos no gerenciador.

3. Obtenha e instale o módulo de gerenciamento de mídia terceirizado para integração com o banco de dados Oracle. Esse módulo deve conter a biblioteca que o banco de dados Oracle carrega ao acessar o gerenciador de mídia.

Operações de Backup e Restauração com um Gerenciador de Mídia O seguinte script do Recovery Manager executa um backup de arquivo de dados em uma unidade de fita controlada por um gerenciador de mídia:

run { # Allocating a channel of type 'sbt_tape' for serial device

ALLOCATE CHANNEL ch1 DEVICE TYPE sbt; BACKUP DATAFILE 3;

}

Quando executa esse comando, o Recovery Manager envia a solicitação de backup para a sessão do banco de dados Oracle que está fazendo o backup. A sessão do banco de dados Oracle identifica o canal de saída como um dispositivo de gerenciamento de mídia e solicita que o gerenciador carregue uma fita e grave a saída. O gerenciador de mídia identifica e controla a fita e os nomes dos arquivos contidos em cada fita. O gerenciador de mídia também controla as operações de restauração. Quando você restaura um arquivo, ocorre o seguinte:

1. O banco de dados Oracle solicita a restauração de um arquivo específico. 2. O gerenciador de mídia identifica a fita que contém o arquivo e faz a leitura dessa fita. 3. O gerenciador de mídia transmite as informações de volta à sessão do banco de dados

Oracle. 4. O banco de dados Oracle grava o arquivo em disco.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando uma Área de Recuperação Flash com o RMAN

Você pode configurar o RMAN para usar a área de recuperação flash.

Área do bancode dados

Processo de backupdo RMAN

Área derecuperação flash

DB_RECOVERY_FILE_DEST = '/u01/oracle/fra'

DB_RECOVERY_FILE_DEST_SIZE = 2G

Usando uma Área de Recuperação Flash com o RMAN Embora não seja necessária em operações do RMAN, a área de recuperação flash simplifica o gerenciamento de espaço em disco e os arquivos relacionados ao backup e à recuperação. Não é necessário especificar os nomes dos arquivos de backup, pois o RMAN gera esses nomes automaticamente. Quando a área de recuperação flash é usada, o RMAN utiliza automaticamente o OMF (Oracle Managed Files) em seus arquivos de backup. Sempre que o RMAN cria um arquivo na área de recuperação flash, o banco de dados Oracle atualiza a lista de arquivos que não são mais necessários no disco. Quando é necessário gravar um arquivo na área de recuperação flash e não há espaço disponível para ele, o banco de dados Oracle deleta um arquivo que esteja na lista de arquivos obsoletos e grava uma notificação no log de alerta. Quando a área de recuperação flash tem pouco espaço livre porque não há arquivos que possam ser deletados, um aviso é emitido. Para resolver o problema, você pode adicionar espaço em disco, fazer backup dos arquivos em um dispositivo terciário, deletar os arquivos da área de recuperação flash usando o RMAN ou alterar a política de retenção do RMAN. A área de recuperação flash é configurada de acordo com a definição do parâmetro de inicialização DB_RECOVERY_FILE_DEST. O parâmetro DB_RECOVERY_FILE_DEST_SIZE especifica o tamanho.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Usando uma Área de Recuperação Flash com o RMAN (continuação) Por default, o RMAN coloca automaticamente os arquivos de backup na área de recuperação flash, se ela estiver configurada. Observação: Uma área de recuperação flash pode residir em uma instância ASM (Automated Storage Management). Essa área também pode ser usada com o OCFS (Oracle Cluster File Storage) ou com qualquer armazenamento local.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitorando a Área de RecuperaçãoFlash com o EM

Monitorando a Área de Recuperação Flash com o EM Você também pode exibir as métricas referentes à área de recuperação flash em tempo real na Console EM Database Control. Na página Maintenance, role a tela até a seção Related Links e selecione All Metrics. Examine a lista e clique em Recovery Area. A página exibida mostra a métrica Recovery Area Free Space (%), que representa o espaço livre na área de recuperação como uma porcentagem. Clique na porcentagem para ver o gráfico de uso da área de recuperação.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Uso do Espaço da Área de Recuperação Flash

• Configure a política de retenção como o valormínimo apropriado para o banco de dados.

• Faça backup dos arquivos de log de arquivamento regularmente e delete-os após a conclusão do backup

• Use os comandos REPORT OBSOLETE e DELETEOBSOLETE do RMAN para remover as cópias dearquivos e os backups desnecessários

Uso do Espaço da Área de Recuperação Flash Para evitar a falta de espaço na área de recuperação flash, nunca armazene arquivos gerenciados por usuários nessa área. Execute também o procedimento a seguir conforme necessário ou apropriado:

• Delete os arquivos desnecessários da área de recuperação usando o RMAN. • Faça backups freqüentes da área de recuperação usando o RMAN. • Altere a política de retenção do RMAN para reter backups durante um período menor. • Altere a política de deleção de logs arquivados do RMAN. • Adicione espaço em disco e aumente o valor do parâmetro de inicialização do banco de

dados DB_RECOVERY_FILE_DEST_SIZE se a falta de espaço for freqüente. Por exemplo, para fazer backup dos arquivos de log arquivados na área de recuperação e deletar esses arquivos após um backup bem-sucedido deles, use o comando do RMAN:

BACKUP ARCHIVELOG ALL DELETE ALL INPUT;

Mesmo que você use uma solução de backup diferente do RMAN, ainda precisará utilizar o RMAN para remover os arquivos da área de recuperação flash. Depois de fazer backup dos arquivos de log arquivados e removê-los do disco, use os comandos CROSSCHECK e DELETEdo RMAN para obter novamente o espaço em disco ocupado pelos logs arquivados na área de recuperação flash. Execute essa operação regularmente ou depois de cada backup.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




V$FLASH_RECOVERY_AREA_USAGE

Você pode consultar V$FLASH_RECOVERY_AREA_USAGEpara exibir o uso do espaço em disco da área derecuperação flash.

SQL> SELECT file_type,

2 percent_space_used AS used,

3 percent_space_reclaimable AS reclaimable,

4 number_of_files AS number

5 FROM v$flash_recovery_area_usage ;

FILE_TYPE USED RECLAIMABLE FILES

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

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ





Saída da consulta V$FLASH_RECOVERY_AREA_USAGE

FILE_TYPE USED RECLAIMABLE FILES

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

CONTROLFILE 0 0 0

ONLINELOG 0 0 0

ARCHIVELOG 69.13 0 593

BACKUPPIECE 0 0 0

IMAGECOPY 0 0 0

FLASHBACKLOG 1.77 0 37


As colunas significam o seguinte: • FILE_TYPE: É o tipo de arquivo e pode ter os seguintes valores: CONTROLFILE, ONLINELOG, ARCHIVELOG, BACKUPPIECE, IMAGECOPY, FLASHBACKLOG.

• PERCENT_SPACE_USED: É a porcentagem da área de recuperação flash que está sendo usada para armazenar arquivos do tipo especificado.

• PERCENT_SPACE_RECLAIMABLE: É a porcentagem da área de recuperação flash que está sendo usada para armazenar arquivos do tipo especificado que poderiam ser deletados por serem obsoletos ou redundantes ou porque já têm backup em outro dispositivo.

• NUMBER_OF_FILES: É o número de arquivos do tipo especificado. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Fazendo Backup da Área de Recuperação Flash

RMAN> BACKUP RECOVERY FILES;

Fazendo Backup da Área de Recuperação Flash Em função da importância dos dados contidos nos arquivos da área de recuperação flash, faça backup desses arquivos regularmente. Para fazer esse backup, navegue até a página com a tab Maintenance. Nessa página, clique no link Schedule Backup da região Backup/Recovery. Selecione Customized na lista drop-down Backup Strategy e, em seguida, selecione a opção All Recovery Files on Disk. Você também pode usar os comandos BACKUP do RMAN para fazer backup da área de recuperação flash.

• RMAN> BACKUP RECOVERY AREA;Esse comando faz backup de todos os arquivos de recuperação flash criados nos destinos atuais da área de recuperação flash sem um backup anterior. Os arquivos que se encaixam nessa categoria são os conjuntos de backups incrementais e integrais, os backups automáticos do arquivo de controle, os logs de arquivamento e as cópias de arquivos de dados. Arquivos como logs de flashback, bitmaps incrementais, arquivos de controle atuais e arquivos de redo log on-line não são submetidos a backup.

• RMAN> BACKUP RECOVERY FILES;Esse comando faz backup em disco de todos os arquivos de recuperação sem um backup anterior. Os arquivos que se encaixam nessa categoria são os conjuntos de backups incrementais e integrais, os backups automáticos do arquivo de controle, os logs de arquivamento e as cópias de arquivos de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Vantagens do Uso de umaÁrea de Recuperação Flash

O uso da área de recuperação flash para os arquivos relacionados à recuperação:• Simplifica a localização dos backups do banco de

dados• Gerencia automaticamente o espaço em disco

alocado para os arquivos de recuperação • Não requer alterações nos scripts existentes • Coloca os backups do banco de dados, os logs de

arquivamento e os backups do arquivo de controle na área de recuperação flash

Vantagens do Uso de uma Área de Recuperação Flash O uso de uma área de recuperação flash para todos os arquivos relacionados à recuperação simplifica a administração contínua do banco de dados, dependendo da definição dos parâmetros de inicialização DB_RECOVERY_FILE_DEST_SIZE e DB_RECOVERY_FILE_DEST. A Oracle Corporation recomenda o uso da área de recuperação flash para todos os arquivos relacionados à recuperação. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Definindo Parâmetros que Afetam o RMAN

• Parâmetros de inicialização de banco de dados – CONTROL_FILE_RECORD_KEEP_TIME

– DB_RECOVERY_FILE_DEST e DB_RECOVERY_FILE_DEST_SIZE, se estiver usando aárea de recuperação flash

• Variáveis de ambiente– NLS_DATE_FORMAT

– NLS_LANG

Definindo Parâmetros que Afetam o RMAN O RMAN armazena no repositório informações sobre o banco de dados de destino e suas operações de backup e recuperação. O volume de informações armazenadas pode aumentar ou diminuir dependendo da freqüência de backups, do número de arquivos de redo log arquivados que são gerados e do período de retenção de registros do RMAN. O parâmetro CONTROL_FILE_RECORD_KEEP_TIME especifica o número mínimo de dias em que as informações do RMAN permanecem armazenadas no arquivo de controle antes de serem sobregravadas. Um valor baixo resulta na sobregravação mais rápida de informações, minimizando, assim, o crescimento do arquivo de controle. Se for usado um catálogo de recuperação, deverá ser escolhido um valor menor. Esse parâmetro aplica-se somente a registros do arquivo de controle que são reutilizados de forma circular (como registros de log de arquivamento e registros de backup variados). Ele não se aplica a registros como os de arquivos de dados, tablespaces e threads de redo, que nunca são reutilizados, salvo quando o objeto correspondente é eliminado do tablespace. O default equivale a sete dias.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Definindo Parâmetros que Afetam o RMAN (continuação) Se você definir uma área de recuperação flash, esse será o local no qual, por default, os arquivos de backup serão gravados. Defina o tamanho e a localização da área de recuperação flash usando os parâmetros de inicialização DB_RECOVERY_FILE_DEST e DB_RECOVERY_FILE_DEST_SIZE. Especifique também uma política de retenção que determine quando os backups poderão ser descartados. O RMAN gerencia o armazenamento de backups, deletando os backups obsoletos e os backups já copiados para fita quando há falta de espaço, mas mantendo o maior número de backups possível, de acordo com o espaço. Isso minimiza as restaurações da fita durante as operações de recuperação de dados para diminuir os tempos de restauração e recuperação. Você pode redimensionar a área de recuperação flash a qualquer momento definindo a variável DB_RECOVERY_FILE_DEST, que é dinâmica. As variáveis de ambiente NLS_DATE_FORMAT e NLS_LANG determinam o formato usado para os parâmetros de tempo nos comandos do RMAN, como RESTORE, RECOVER e REPORT. Um banco de dados que não é montado usa o conjunto de caracteres default: US7ASCII. Se o conjunto de caracteres for diferente do default, defina NLS_LANG conforme apropriado. Por exemplo, se o conjunto de caracteres for WE8DEC, você poderá definir o parâmetro NLS_LANG da seguinte forma:

NLS_LANG=american_america.we8dec

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Considerações sobre a Utilização do RMAN

• Recursos: Memória compartilhada, mais processos • Privilégios concedidos aos usuários:

– Banco de dados: SYSDBA– Sistema operacional: Acesso a dispositivos

• Operações remotas:– Configurar o arquivo de senha – Garantir que haja um backup do arquivo de senha

Considerações sobre a Utilização do RMAN Antes de usar o Recovery Manager, considere os seguintes itens:

• Os recursos compartilhados no sistema: A maior parte do trabalho do RMAN é realizada por meio de processos do banco de dados Oracle. As operações também podem ser executadas em paralelo para aumentar o throughput. Para isso, o parâmetro de banco de dados PROCESSES precisa ter um valor suficientemente alto. Para os recursos do sistema operacional, isso significa que talvez seja necessário aumentar a memória compartilhada e as definições de semáforo.

• Os usuários que executam operações privilegiadas: Você deve decidir quais usuários poderão executar operações privilegiadas. Em seguida, conceda os privilégios necessários às contas dos usuários no nível do sistema operacional e dentro do banco de dados Oracle. Por exemplo, para inicializar e fazer shutdown de um banco de dados, o usuário deve ter o privilégio SYSDBA.

• Operações remotas: Você precisa usar um arquivo de senha para se conectar ao banco de dados de destino no Oracle Net a fim de executar operações privilegiadas, como inicialização e shutdown, em uma máquina remota.

• Uso do catálogo de recuperação: Quando você usa um catálogo de recuperação, o RMAN pode executar uma variedade maior de funções automáticas de backup e recuperação. O uso do catálogo de recuperação envolve espaço de armazenamento e esforços de manutenção. Você deve decidir se terá ou não um banco de dados dedicado para manter os catálogos de recuperação de vários bancos de dados de destino.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tipos de Conexão com o RMAN

Banco de dados de destino

Banco de dadosdo catálogo de

recuperação

Banco dedados auxiliar

RecoveryManager

Tipos de Conexão com o RMAN Você pode usar o Recovery Manager para se conectar aos seguintes tipos de bancos de dados:

• Banco de dados de destino: O RMAN conecta você ao banco de dados de destino com o privilégio SYSDBA. É preciso ter esse privilégio para que a conexão seja bem-sucedida. O banco de dados de destino é a instância em que você deseja executar operações comuns do RMAN.

• Banco de dados do catálogo de recuperação: É um banco de dados opcional, configurado para o repositório do RMAN. Conecte-se ao banco de dados do catálogo de recuperação quando você quiser recuperar informações armazenadas nele, como dados de backup ou scripts armazenados.

• Banco de dados auxiliar: Um banco de dados auxiliar pode ser: – Criado com o comando RMAN DUPLICATE– Um banco de dados temporário, usado durante a TSPITR (tablespace point-in-time

recovery, recuperação pontual de tablespaces) – Um banco de dados stand-by, ou uma cópia do banco de dados de produção, que pode

ser usada para a recuperação de acidentes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Iniciando o RMAN

• Iniciando o RMAN localmente

• Iniciando o RMAN remotamente

UNIX: $ ORACLE_SID=DB01; export ORACLE_SID$ rman target /

rman target sys/password@DB01

Windows NT: C:\> set ORACLE_SID=DB01 C:\> rman target /

Iniciando o RMAN Conexão LocalPara uma conexão local do RMAN, em um prompt do sistema operacional, digite o seguinte:

UNIX: $ ORACLE_SID=DB01; export ORACLE_SID $ rman target /

Windows:C:\> SET ORACLE_SID=DB01 C:\> rman target /

Se você não especificar o ID do usuário ou a senha durante a conexão com o banco de dados de destino, uma barra estabelecerá uma conexão como o usuário SYS usando a autenticação do sistema operacional. Como alternativa, você pode especificar a palavra-chave NOCATALOG da seguinte maneira:

$ rman target / nocatalog

NOCATALOG é o modo default usado para indicar que você está utilizando o RMAN sem um catálogo de recuperação. Conexão Remota Para estabelecer conexão a partir de outro servidor, use o nome de serviço Oracle Net para o banco de dados de destino:

$ rman target sys/target_pwd@DB01

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Argumentos de Linha de ComandosAdicionais do RMAN

• Gravando a saída do RMAN em um arquivo de log

• Executando um arquivo de comandos quando o RMAN é chamado

• Estabelecendo conexões de banco de dadosdurante a inicialização do RMAN

$ rman TARGET sys/oracle CMDFILE=$HOME/scripts/my_rman_script.rcv

$ rman TARGET sys/oracle LOG=$HOME/oradata/u03/rman.log APPEND

$ rman TARGET SYS/sys_pwd@orcl CATALOGrman/rman@rcat

Argumentos de Linha de Comandos Adicionais do RMAN O argumento LOG=filename especifica o arquivo no qual a saída do RMAN será registrada. Caso não seja especificado, o RMAN gravará seu arquivo de log de mensagens na saída padrão. A palavra-chave APPEND especifica que a nova saída deverá ser acrescentada ao fim do arquivo de log de mensagens. Você pode usar CMDFILE=filename para executar um arquivo contendo comandos do RMAN. O RMAN é encerrado após a execução do arquivo de comandos.Os nomes de arquivos especificados na linha de comandos que não começarem por um caractere alfabético deverão estar entre aspas simples. Você pode especificar opções de conexão para o RMAN, como:

• AUXILIARY: Especifica uma string de conexão com um banco de dados auxiliar• CATALOG: Especifica uma string de conexão com o banco de dados que contém o

catálogo de recuperação • NOCATALOG: Indica que você esta usando o RMAN sem um catálogo de recuperação • TARGET: Especifica uma string de conexão com o banco de dados de destino

Quando você usa a cláusula SCRIPT , depois de estar conectado ao banco de dados de destino e ao catálogo de recuperação (especificado com as cláusulas TARGET e CATALOG), o RMAN executa o script armazenado no catálogo de recuperação para o banco de dados de destino.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Configurando DefiniçõesPersistentes para o RMAN

• As definições default do RMAN são predefinidas• Use o comando CONFIGURE para:

– Configurar canais automáticos – Especificar a política de retenção de backup– Especificar o número de cópias de backup a serem

criadas – Definir o tipo de backup default como BACKUPSET ou

COPY

– Limitar o tamanho dos conjuntos de backup– Isentar um tablespace de ser submetido a backup– Ativar e desativar a otimização de backup– Configurar backups automáticos de arquivos de controle

Configurando Definições Persistentes para o RMAN Para simplificar o uso contínuo do RMAN em backups e recuperações, ele permite que você especifique algumas definições de configuração persistentes para cada banco de dados de destino. Essas definições controlam muitos aspectos do comportamento do RMAN durante a operação com esse banco de dados. Você pode salvar informações de configuração persistentes como parâmetros do canal, paralelismo e o tipo de dispositivo default no repositório do RMAN (que é armazenado no arquivo de controle ou em um banco de dados do catálogo de recuperação). Essas definições têm valores default, que permitem usar o RMAN prontamente. No entanto, quando montar uma estratégia de backup e recuperação mais avançada, você terá de alterar essas definições para implementar a estratégia. É possível utilizar o comando CONFIGURE para configurar definições persistentes para jobs de backup, restauração, duplicação e manutenção do RMAN. Essas definições permanecem em vigor para qualquer sessão do RMAN até que a configuração seja removida ou alterada.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Configurando as Definiçõesdo RMAN com o EM

Configurando as Definições do RMAN com o EM Você pode usar o Oracle Enterprise Manager para especificar as definições de backup de uma instância. Para especificar as definições de backup, na página Maintenance, selecione BackupSettings na seção Backup/Recovery Settings. A página de propriedade Backup Settings consiste em três tabs: Device, Backup Set e Policy. Você pode acessar:

• A página Device para definir as configurações de disco e fita, incluindo as configurações da MML (Media Management Library)

• A página Backup Set (mostrada no slide) para especificar os parâmetros dos conjuntos de backup e para inserir credenciais de host

• A página Policy para definir várias políticas de backup e retenção antes de iniciar um backup, como o backup automático do arquivo de controle e SPFILE. A página Policy também mostra como configurar o suporte para o rastreamento de alterações em bloco, um recurso que oferece backups incrementais mais rápidos.

Observação: As definições de backup alteram as definições no nível do banco de dados e aplicam-se a qualquer backup que não sobregrave definições no nível do backup.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Backups Automáticos do Arquivo de Controle

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Melhor prática: A Oracle recomenda ativar o backupautomático do arquivo de controle.

Backups Automáticos do Arquivo de Controle Para evitar a perda de uma cópia do arquivo de controle atual, configure o RMAN para fazer backups automáticos desse arquivo. O backup automático do arquivo de controle ocorre independentemente de qualquer backup do arquivo de controle atual solicitado como parte do seu comando de backup. Se você estiver executando o RMAN no modo NOCATALOG, é altamente recomendável ativar o backup automático do arquivo de controle. Caso contrário, se você perder o arquivo de controle, o banco de dados talvez não possa ser recuperado. Para configurar o backup automático do arquivo de controle, modifique a política de backup do banco de dados usando o Enterprise Manager ou o seguinte comando RMAN:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

Por default, o backup automático do arquivo de controle fica desativado. Se você ativar esse recurso, o RMAN fará o backup automático do arquivo de controle e do arquivo de parâmetros do servidor atual (se usado para inicializar o banco de dados) em uma destas duas circunstâncias:

• Um backup bem-sucedido é registrado no repositório do RMAN. • Uma alteração estrutural no banco de dados afeta o conteúdo do arquivo de controle e,

portanto, é necessário realizar seu backup

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Backups Automáticos do Arquivo de Controle (continuação) O nome do arquivo de backup automático do arquivo de controle tem o formato default %F para todos os tipos de dispositivos, de forma que o RMAN possa localizar o arquivo e restaurá-lo sem um repositório. O formato dessa variável é convertido em c-IIIIIIIIII-YYYYMMDD-QQ, onde:

• IIIIIIIIII representa o DBID. • YYYYMMDD é um timestamp do dia em que o backup foi gerado. • QQ é a seqüência hexadecimal iniciada com 00 e que tem um máximo de FF.

Você pode alterar o formato default usando o comando CONFIGURE CONTROLFILEAUTOBACKUP FORMAT FOR DEVICE TYPE type TO 'string'. O valor de string deverá conter a variável de substituição %F e nenhuma outra. Por exemplo:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/oradata/cf_ORCL_auto_%F';

Os backups automáticos do arquivo de controle serão armazenados na área de recuperação flash, salvo se especificado de outra forma. Com um backup automático do arquivo de controle, o RMAN poderá recuperar o banco de dados mesmo que o arquivo de controle atual, o catálogo de recuperação e o arquivo de parâmetros do servidor estejam inacessíveis. Como o caminho usado para armazenar o backup automático segue um formato bem conhecido, o RMAN pode procurar e restaurar o arquivo de parâmetros do servidor ou o arquivo de controle desse backup.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




• Uma política de retenção descreve quais backupsserão mantidos e por quanto tempo.

• Há dois tipos de políticas de retenção:– Período de recuperação: Estabelece um período

dentro do qual a recuperação pontual é viável

– Redundância: Estabelece um número fixo de backups a serem mantidos.

• Essas políticas são mutuamente exclusivas epodem ser definidas com o comando CONFIGURE.

Políticas de Retenção

Agora

Retenção de sete dias

Arquivo1Arquivo2O Arquivo2 precisa

sofrer backup:

Políticas de Retenção Uma política de retenção descreve quais backups serão mantidos e por quanto tempo. O valor da política de retenção é definido pelo comando CONFIGURE. O ideal é estabelecer um período durante o qual será possível descobrir erros lógicos e corrigir os objetos afetados através de uma recuperação pontual até o momento imediatamente anterior à ocorrência do erro. Esse período é denominado período de recuperação. Essa política é especificada em número de dias. Para cada arquivo de dados, deverá existir sempre um backup que atenda às seguintes condições:

SYSDATE - checkpoint_time <= recovery_window

Por exemplo, se a política tiver sido definida da seguinte forma: RMAN> CONFIGURE RETENTION POLICY 2 TO RECOVERY WINDOW OF 7 DAYS;

Para cada arquivo, deverá existir um backup que satisfaça as seguintes condições: SYSDATE - (SELECT checkpoint_time

FROM V$DATAFILE WHERE file#= …) >= 7

No exemplo do slide, o Arquivo1 tem um backup que está dentro do período de retenção de sete dias. O Arquivo2 não tem, por isso precisa sofrer backup para satisfazer a política de retenção.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Políticas de Retenção (continuação) Você deve manter o período de recuperação inferior ou igual ao valor do parâmetro do arquivo de controle CONTROL_FILE_RECORD_KEEP_TIME para evitar que o registro de backups mais antigos seja sobregravado no arquivo de controle. Se for necessário reter um certo número de backups, você poderá definir a política de retenção com base na opção de redundância. Essa opção exige que um número específico de backups seja catalogado antes que qualquer backup seja identificado como obsoleto. A política de retenção default tem a redundância 1, o que significa que apenas um backup de um arquivo deve existir em determinado momento. Um backup será considerado obsoleto quando tiver sido feito o backup de uma versão mais recente dos mesmos arquivos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciando Definições Persistentes

• Use o comando SHOW para listar as definições atuais:

• Use o comando CLEAR para redefinir qualquer definição persistente como seu valor default:

RMAN> SHOW CONTROLFILE AUTOBACKUP FORMAT; RMAN> SHOW EXCLUDE; RMAN> SHOW ALL;

RMAN> CONFIGURE BACKUP OPTIMIZATION CLEAR; RMAN> CONFIGURE MAXSETSIZE CLEAR; RMAN> CONFIGURE DEFAULT DEVICE TYPE CLEAR;

Gerenciando Definições Persistentes Usando o comando SHOW do RMAN, você pode exibir as definições do RMAN. Se SHOW ALLfor executado durante uma conexão com um banco de dados de destino, somente as configurações específicas do nó e do banco de dados serão exibidas. Você pode retornar ao valor default de qualquer comando CONFIGURE, executando o mesmo comando com a opção CLEAR. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Alocação de Canais

Canal (DISCO)

BACKUPRESTORERECOVER

Sessão doservidor

Sessão doservidor

Banco dedados dedestino

Canal (SBT)

RMAN

Alocação de Canais Um canal representa um fluxo de dados direcionado para um tipo de dispositivo. Você precisa alocar um canal antes de executar os comandos de backup e recuperação. Cada canal alocado estabelece uma conexão do executável do RMAN com uma instância do banco de dados de destino. Um processo do banco de dados Oracle para o banco de dados de destino é criado para cada canal alocado. Cada comando BACKUP, COPY, RESTORE ou RECOVER executado no Recovery Manager exige pelo menos um canal. O tipo de mídia desejado determina o tipo de canal alocado. O número de canais alocados será o grau máximo de paralelização usado durante a operação de backup, restauração ou recuperação. Você pode consultar a view V$BACKUP_DEVICE para determinar os tipos de dispositivo aceitos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Alocação Automática e Manual de Canais

• Um canal automático é aquele pré-configurado eusado para comandos subseqüentes. Para alterar otipo de dispositivo default para a alocação automática de canais, use:

• Um canal alocado manualmente é aquele que sobrepõe a definição automática de canal. Essecanal sobrepõe o canal automático para executar este bloco:

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;

RMAN> RUN { 2> ALLOCATE CHANNEL c1 DEVICE TYPE disk;3> BACKUP DATAFILE '/u01/oradata/user01.dbf';4> }

Alocação Automática e Manual de Canais Use o comando CONFIGURE para pré-configurar canais a serem usados em todas as sessões do RMAN, por meio da alocação automática de canais. Os canais automáticos aplicam-se a qualquer job do RMAN no qual você não aloque canais manualmente. Por default, o RMAN tem um canal de disco pré-configurado, para que você possa fazer backup em disco sem qualquer configuração manual. Portanto, se preferir fazer backup em disco em vez de usar um gerenciador de mídia, você poderá começar a fazer esse backup imediatamente. O comando ALLOCATE CHANNEL com um comando RUN e o comando ALLOCATECHANNEL FOR MAINTENANCE executados no prompt do RMAN são utilizados para a alocação manual de canais. A alocação manual de canais sobrepõe a alocação automática. Você pode usar canais alocados manualmente para executar comandos (como os comandos CHANGE, DELETE e CROSSCHECK) que deletam ou alteram o status de backups existentes. Observe que se você usar CONFIGURE para configurar canais automáticos, o RMAN poderá usá-los em operações de manutenção; não é necessário alocá-los manualmente. Os canais de manutenção alocados manualmente não podem ser usados para outras operações de entrada/saída, como backup ou cópia. Os recursos de canais automáticos e manuais são mutuamente exclusivos. O RMAN utiliza um ou outro em determinado job.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Opções de Controle de Canal

• Configure o paralelismo:

• Especifique o tamanho máximo do componente de backup:

• Formate o nome dos arquivos de backup gerados:

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3;

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK 2> MAXPIECESIZE 2G;

RMAN> RUN { 2> ALLOCATE CHANNEL d1 DEVICE TYPE DISK 3> FORMAT '/disk1/backups/%U'; 4> BACKUP DATABASE PLUS ARCHIVELOG; }

Opções de Controle de Canal Você pode especificar opções de controle para o canal alocado, de modo a alterar seu comportamento default. As opções de controle configuráveis para canais alocados manual ou automaticamente são:

• CONNECT: A string de conexão para a instância de destino • FORMAT: O formato a ser usado para nomes de componentes de backup criados nesse

canal • MAXOPENFILES: O número máximo de arquivos de entrada abertos que um comando BACKUP pode ter a qualquer momento (o default é 8)

• MAXPIECESIZE: O tamanho máximo de cada componente de backup criado nesse canal, especificado em bytes (default), kilobytes (K), megabytes (M) ou gigabytes (G)

• DURATION: O tempo necessário para a execução do job de backup, definido em horas e minutos. A duração também pode ser especificada como:

– PARTIAL: Nenhum erro será sinalizado se o backup não for concluído no final da duração especificada.

– MINIMIZE TIME: O backup é executado em velocidade máxima e, possivelmente, concluído no tempo alocado.

– MINIMIZE LOAD: O RMAN monitora a velocidade do backup e reduz automaticamente a velocidade de processamento quando detecta que o backup será concluído em um tempo menor do que o alocado. Essa opção não é permitida durante a gravação em fita, pois é desejável que esse tipo de operação com fitas seja conduzida o mais rápido possível.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Opções de Controle de Canal (continuação) Se o tipo de dispositivo de canal for SBT ou SBT_TAPE, você também poderá especificar:

• PARMS="ENV(…)": Defina as variáveis de ambiente para a sessão do servidor correspondente a esse cliente RMAN.

• PARMS="SBT_LIBRARY=…": Especifique o local da MML a ser usado pelo canal. Para os canais automáticos, também é possível configurar o nível de paralelismo default e o tipo de backup default para backups em disco ou fita como BACKUPSET, COMPRESSEDBACKUPSET ou COPY.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Resumo

Nesta lição, você aprendeu a:• Usar o arquivo de controle ou um catálogo de

recuperação para o repositório do RMAN• Alterar as definições default do RMAN com CONFIGURE• Usar a área de recuperação flash em operações do

RMAN• Monitorar a área de recuperação flash usando views v$

e o Enterprise Manager• Implementar as políticas de retenção de período de

recuperação e de redundância • Implementar a alocação manual e automática de canais

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício:Configurando o RMAN

Este exercício aborda os seguintes tópicos:• Utilização do Recovery Manager para estabelecer

conexão com um banco de dados de destino nomodo default NOCATALOG

• Exibição das definições default do RMAN• Configuração de backups automáticos do arquivo de

controle • Alteração da política de retenção de backup para um

banco de dados

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Usando o Recovery Manager

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Usar o comando BACKUP do RMAN para criar

conjuntos de backup e cópias-imagem• Gerenciar os backups e as cópias-imagem feitas

com o RMAN

CommandsBACKUPBlock C.T.Inc. UpdateLISTREPORTDELETE

Objetivos O RMAN (Recovery Manager) é o componente do banco de dados Oracle usado para executar operações de backup e recuperação. O EM (Enterprise Manager) fornece uma interface gráfica para as funcionalidades do RMAN usadas com mais freqüência. A aula Oracle Database 10g: Workshop de Administração I demonstra as operações básicas do RMAN com a Console do EM Database Control. Portanto, a interface gráfica para o RMAN não é abordada com detalhes nesta lição.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Executando Comandos do Recovery Manager

• Cliente interativo – Informe comandos no prompt do RMAN. – Use ao fazer análises ou ao executar relatórios ou

scripts armazenados.• Modo batch

– Use com jobs automatizados.– Especifique um arquivo de comandos quando iniciar o

RMAN.– Especifique o nome do arquivo de log para capturar o

log da sessão. • Interface de pipe

– Especifique o argumento de linha de comandos PIPE. – Use para transferir dados entre sessões ou entre o

RMAN e uma aplicação externa.

Executando Comandos do Recovery Manager O Recovery Manager tem sua própria linguagem de comandos. Há várias maneiras de especificar comandos para o RMAN usando a CLI (Command-Line Interface). Para executar comandos do RMAN de forma interativa, inicie o RMAN e informe os comandos na interface de linha de comandos. Por exemplo:

$ rman TARGET sys/sys_pwd@db1 RMAN> BACKUP DATABASE;

Você pode informar comandos do RMAN em um arquivo de comandos e executar esse arquivo especificando seu nome na linha de comandos. Esse método é conhecido como processamento batch. O conteúdo do arquivo de comandos deve corresponder aos comandos que seriam informados na linha de comandos. Por exemplo: $ rman TARGET SYS/sys_pwd@prod1 @'/oracle/backup_all_l0.rcv'

Durante a execução no modo batch, o RMAN lê a entrada de um arquivo de comandos e grava mensagens de saída em um arquivo de log (se especificado). O RMAN analisa por parse o arquivo de comandos inteiramente antes de compilar ou executar qualquer comando. Não há necessidade de incluir um comando de saída no arquivo, porque o RMAN é encerrado no fim do arquivo. A interface de pipe do RMAN é um método alternativo para a execução de comandos do RMAN e o recebimento da saída desses comandos. O RMAN obtém comandos e envia a saída usando o package PL/SQL DBMS_PIPE.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Executando Comandos do Recovery Manager (continuação) A interface de pipe é chamada com o parâmetro de linha de comandos PIPE. O RMAN usa dois pipes particulares: um para receber comandos e o outro para enviar a saída. Os nomes dos pipes são derivados do valor do parâmetro PIPE. Por exemplo:

% rman PIPE abc TARGET SYS/pwd@trgt

O RMAN abre os dois pipes no banco de dados de destino: ORA$RMAN_ABC_IN, que o RMAN utiliza para receber comandos do usuário, e ORA$RMAN_ABC_OUT, que o RMAN utiliza para enviar toda a saída de volta para ele mesmo. Todas as mensagens nos pipes de entrada e saída são do tipo VARCHAR2. Quando a interface de pipe é usada, o RMAN não lê nem grava dados com o shell do sistema operacional. Você pode usar pipes para se comunicar com outra sessão na mesma instância ou com uma aplicação em espera, como um programa UNIX. Usando essa interface, é possível criar uma interface programática portável para o RMAN. Consulte o Oracle Database Backup and Recovery Advanced User’s Guide para obter mais informações sobre o uso de pipes com o RMAN. Consulte o guia PL/SQL Packages and Types Reference para obter mais informações sobre o package DBMS_PIPE e a criação de pipes no banco de dados Oracle.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tipos de Comandos do RMAN

Estes são os tipos de comandos do RMAN:• Comando stand-alone:

– Executado individualmente no prompt do RMAN– Não pode ser incluído como subcomando do

comando RUN

• Comando de job:– Deve estar entre as chaves de um comando RUN

– Executado como um grupo Alguns comandos podem ser executados como comandos stand-alone ou de job.

Tipos de Comandos do RMAN Você pode executar dois tipos básicos de comandos do RMAN: stand-alone e de job. Os comandos stand-alone são executados no prompt do RMAN e, geralmente, não necessitam de parâmetros adicionais. Estes são alguns dos comandos stand-alone:

• CHANGE • CONNECT • CREATE CATALOG, RESYNC CATALOG • CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT

Em geral, os comandos de job são agrupados e executados seqüencialmente em um bloco de comandos. Se um comando contido no bloco falhar, o RMAN interromperá o processamento. Nenhum outro comando do bloco será executado. Os efeitos de qualquer comando já executado continuam válidos; eles nunca são anulados. Um exemplo de um comando que só pode ser executado como um comando de job é ALLOCATE CHANNEL. O canal é alocado somente para a execução do job, por isso esse comando não pode ser executado como stand-alone. Há alguns comandos que podem ser executados no prompt ou dentro de um bloco do comando RUN, como BACKUP DATABASE. Se você executar comandos stand-alone, o RMAN alocará os canais necessários com o recurso de alocação automática de canais. Os comandos stand-alone e de job podem ser executados no modo interativo ou no modo batch.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comandos de Job: Exemplo

Os comandos de job aparecem dentro de um bloco docomando RUN:

RMAN> RUN {2> BACKUP AS BACKUPSET3> FORMAT '/u01/db01/backup/%d_%s_%p'4> DURATION 10:00 MINIMIZE LOAD 5> (DATABASE); 6> SQL 'alter system archive log current'; 7> }

Comandos de Job: Exemplo Ao contrário dos comandos stand-alone, os comandos de job devem ser incluídos entre as chaves de um comando RUN. Eis alguns exemplos de comandos de job:

• ALLOCATE CHANNEL • SWITCH

O RMAN executa os comandos de job em seqüência dentro de um bloco do comando RUN. Se algum comando contido no bloco falhar, o RMAN interromperá o processamento. Nenhum outro comando do bloco será executado. Na verdade, o comando RUN define uma unidade de execução do comando. Depois de concluído o último comando de um bloco RUN, o banco de dados Oracle libera os recursos do servidor, como buffers de entrada/saída ou processos escravos de entrada/saída, que estiverem no bloco.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comandos do RMAN: Visão Geral

Banco dedados dedestino

REPORTLIST

Banco de dados do catálogo

Enterprise Manager

RESTORERECOVERFLASHBACK

SPFILE

BACKUP

Arquivo decontrole

Arquivos de logarmazenados

RMAN

Manutenção decatálogo

CROSSCHECKDELETE…EXPIRED

CHANGE

Scriptsarmazenados

Comandos do RMAN: Visão Geral Os comandos do RMAN mais comuns que você executa no banco de dados de destino são:

• BACKUP para fazer backup de um banco de dados, tablespace, arquivo de dados (atual ou cópia), arquivo de controle (atual ou cópia), SPFILE, log arquivado ou conjunto de backup para um banco de dados de destino ou stand-by. Fazer backup de um conjunto de backup é uma forma fácil de mover um backup de disco para fita.

• DUPLICATE para criar um banco de dados clone ou stand-by a partir de backups (conjuntos de backup ou cópias-imagem) do banco de dados de destino.

• FLASHBACK para executar uma operação de flashback de banco de dados, retornando o banco de dados a um horário de destino (ou imediatamente antes), conforme especificado pelo horário, SCN ou número de seqüência de log.

• RECOVER para recuperar e RESTORE para restaurar arquivos a partir de backups ou cópias-imagem.

Os comandos de relatório do RMAN incluem: • LIST para consultar o catálogo de recuperação ou o arquivo de controle e criar uma lista

de backups, cópias, redo logs arquivados e versões do banco de dados registradas aqui. • REPORT para executar uma análise detalhada do catálogo de recuperação ou arquivo de

controle.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Comandos do RMAN: Visão Geral (continuação) O RMAN fornece os seguintes conjuntos de comandos para a manutenção do catálogo:

• CROSSCHECK verifica o status de um backup ou de uma cópia em disco ou fita. • DELETE lista os objetos de backup especificados e solicita confirmação para

removê-los.• CHANGE altera o status dos objetos de backup no repositório. • LIST mostra o que CROSSCHECK/DELETE EXPIRED processaria se executado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comando BACKUP

RMAN> BACKUP AS BACKUPSET2> FORMAT '/BACKUP/df_%d_%s_%p.bus'3> TABLESPACE hr_data;

Conjuntode backup

Arquivo de dados 1

Arquivo de dados 2

Arquivo de dados 3

Arquivo de dados 1

Arquivo de dados 2

Arquivo de dados 3

TablespaceHR_DATA

Commands > BACKUP

Block C.T.Inc. UpdateLISTREPORTDELETE

Comando BACKUPUm backup é uma cópia dos dados de um banco de dados que pode ser usada para recuperar esses dados. Os resultados de um backup criado com o RMAN podem ser cópias-imagem ou conjuntos de backup. Uma cópia-imagem é uma cópia idêntica de um arquivo do banco de dados. O RMAN também pode armazenar seus backups em um formato exclusivo, denominado conjunto de backup. Um conjunto de backup é uma coleção de arquivos denominados componentes de backup, sendo que cada qual pode conter um ou mais backups de arquivos do banco de dados. Ao executar um backup com o RMAN, você pode especificar:

• O tipo de backup a ser executado. Você pode executar backups do banco de dados inteiro para incluir todos os blocos de dados usados nos arquivos (um backup FULL) ou backups incrementais (INCREMENTAL). Se CONFIGURE CONTROLFILE AUTOBACKUP estiver ativado, o RMAN fará automaticamente backup do arquivo de controle e do arquivo de parâmetros atual do servidor, depois dos comandos BACKUP.

• Do que fazer backup. Os valores válidos são DATABASE, DATAFILE, TABLESPACE, ARCHIVELOG, CURRENT CONTROLFILE ou SPFILE.

• Se uma cópia-imagem (AS COPY) ou um conjunto de backup (AS BACKUPSET) será criado.

• O formato do nome de arquivo e a localização dos componentes de backup (FORMAT). • Quais arquivos de dados ou redo logs arquivados deverão ser excluídos do conjunto de

backup (SKIP). • O tamanho máximo para um conjunto de backup (MAXSETSIZE). • Se os arquivos de entrada deverão ser deletados com a criação bem-sucedida do conjunto

de backup (DELETE INPUT).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Restrições de Backup

• O banco de dados deve estar montado ou aberto.• Não é possível fazer o backup de redo logs on-line.• Somente os backups “limpos” podem ser usados no

modo NOARCHIVELOG.• Somente os backups de arquivos de dados “atuais”

podem ser usados no modo ARCHIVELOG.

Restrições de Backup Ao fazer backup usando o Recovery Manager, você precisa estar ciente de que:

• O banco de dados de destino deverá estar montado para que o Recovery Manager possa ser conectado.

• Não há suporte a backups de redo logs on-line. • Se o banco de dados de destino estiver no modo NOARCHIVELOG, só poderão ser feitos

backups de tablespaces e arquivos de dados “limpos” (isto é, backups de tablespaces “normais off-line” ou de tablespaces “somente para leitura”). Só será possível fazer backups do banco de dados depois de seu shutdown e reinicialização no modo MOUNT.

• Se o banco de dados de destino estiver no modo ARCHIVELOG, só será possível fazer backup de arquivos de dados “atuais” (os arquivos de dados restaurados serão atualizados depois de recuperados).

• Se um catálogo de recuperação for utilizado, o banco de dados do catálogo deverá estar aberto.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Paralelização de Conjuntos de Backup

Por questão de desempenho, aloque vários canais edesigne arquivos aos canais específicos.

Arquivo de dados 4

Arquivo de dados 1

Arquivo de dados 5 Canal

MML Componentede backup 1

Componentede backup 2

Arquivo de dados 2

Arquivo de dados 3

Arquivo de dados 9 Canal

MML

Arquivo de dados 6

Arquivo de dados 7

Arquivo de dados 8

Componentede backup 3

Canal

MML

Paralelização de Conjuntos de Backup Você pode configurar backups paralelos definindo a opção PARALLELISM do comando CONFIGURE como um valor superior a 1 ou alocando manualmente diversos canais. O RMAN paraleliza sua operação e grava vários conjuntos de backup em paralelo. As sessões do servidor dividem o trabalho de backup dos arquivos especificados. Exemplo

RMAN> RUN {

2> ALLOCATE CHANNEL c1 DEVICE TYPE sbt;



5> BACKUP

6> INCREMENTAL LEVEL = 0

7> FORMAT '/disk1/backup/df_%d_%s_%p.bak'

8> (DATAFILE 1,4,5 CHANNEL c1)

9> (DATAFILE 2,3,9 CHANNEL c2)

10> (DATAFILE 6,7,8 CHANNEL c3);

11> ALTER SYSTEM ARCHIVE LOG CURRENT;

12> }

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Paralelização de Conjuntos de Backup (continuação) Ao fazer backup de arquivos de dados, você pode especificar os arquivos pelo nome do caminho ou pelo respectivo número. Por exemplo, os seguintes comandos executam a mesma ação:

BACKUP DEVICE TYPE sbt DATAFILE '/home/oracle/system01.dbf'; BACKUP DEVICE TYPE sbt DATAFILE 1;

Quando você cria diversos conjuntos de backup e aloca vários canais, o funcionamento do RMAN é paralelizado automaticamente e ele grava diversos conjuntos de backup em paralelo. As sessões do servidor alocado compartilham o trabalho de backup dos arquivos de dados, arquivos de controle e redo logs arquivados especificados. Não é possível fazer o striping de um único conjunto de backup entre vários canais. Você pode obter a paralelização de conjuntos de backup da seguinte forma:

• Configurando PARALLELISM como um valor superior a 1 ou alocando vários canais • Especificando muitos arquivos para backup

Exemplo• Existem nove arquivos dos quais é necessário fazer backup (arquivos de dados de 1 a 9). • Designe os arquivos de dados a um conjunto de backup, de modo que cada conjunto tenha

aproximadamente o mesmo número de blocos de dados para backup (para uma operação eficiente.)

– Os arquivos de dados 1, 4 e 5 estão designados ao conjunto de backup 1. – Os arquivos de dados 2, 3 e 9 estão designados ao conjunto de backup 2. – Os arquivos de dados 6, 7 e 8 estão designados ao conjunto de backup 3.

Observação: O parâmetro FILESPERSET também pode ser usado para limitar o número de arquivos de dados incluídos em um conjunto de backup.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Backups Compactados

RMAN> BACKUP AS 2> COMPRESSED BACKUPSET3> DATABASE;

RMAN> CONFIGURE DEVICE TYPE2> DISK PARALLELISM 23> BACKUP TYPE TO 4> COMPRESSED BACKUPSET;

Arquivosde backup

compactadosArquivos do

banco de dados

Backups Compactados Os backups compactados reduzem o espaço necessário para o armazenamento de conjuntos de backup. Você pode criar um backup compactado de um banco de dados usando o seguinte comando:

RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE;

Não é possível usar o recurso de conjunto de backup compactado com bancos de dados anteriores ao Oracle Database 10g. O parâmetro de inicialização de banco de dados COMPATIBILITY deve ser definido como pelo menos 10.0.0.0. A compactação aplica-se apenas aos conjuntos de backup, e não às cópias-imagem. Você pode configurar o RMAN para criar conjuntos de backup compactados automaticamente com o comando CONFIGURE DEVICE TYPE:

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 2> BACKUP TYPE TO COMPRESSED BACKUPSET;

Por default, a compactação é desativada.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Cópia-Imagem

Cópia do arquivo de dados 3

Cópia do log arquivado

Arquivo de dados 3

Arquivo de log arquivado

Arquivo de dados 3

Arquivo delog arquivado

RMAN> BACKUP AS COPY2> DATAFILE '/ORADATA/users_01_db01.dbf' 3> FORMAT '/BACKUP/users01.dbf';

RMAN> BACKUP AS COPY 4> ARCHIVELOG LIKE 'arch_1060.arc' 5> FORMAT 'arch_1060.bak';

Cópia-Imagem Uma cópia-imagem é um clone de um único arquivo de dados, redo log arquivado ou arquivo de controle. É possível criar uma cópia-imagem com o comando BACKUP AS COPY ou com um comando do sistema operacional. Quando a cópia-imagem é criada com o comando BACKUP AS COPY do RMAN, a sessão do servidor valida os blocos do arquivo e registra a cópia no arquivo de controle. Uma cópia-imagem tem as seguintes características:

• Só pode ser gravada em disco. No caso de arquivos grandes, a cópia pode demorar bastante, mas o tempo de restauração é reduzido consideravelmente, pois a cópia já está disponível no disco.

• Se os arquivos forem armazenados em disco, eles poderão ser usados imediatamente com o comando SWITCH no RMAN, que é equivalente à instrução SQL ALTER DATABASERENAME FILE.

• Em uma cópia-imagem, todos os blocos são copiados, independentemente de conterem dados ou não, porque o processo do banco de dados Oracle copia o arquivo e executa outras ações, como a verificação de blocos danificados e o registro da cópia no arquivo de controle. Para acelerar o processo de cópia, você pode usar o parâmetro NOCHECKSUM.

• A cópia-imagem pode fazer parte de um backup integral ou incremental de nível 0, pois uma cópia de arquivo sempre inclui todos os blocos. Utilize a opção de nível 0 se a cópia for usada com um conjunto de backup incremental.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Cópia-Imagem (continuação) O exemplo no slide cria duas cópias-imagem:

• Uma cópia do arquivo de dados users01_db01.dbf renomeada como users01.dbfe armazenada no diretório BACKUP

• Uma cópia do log arquivado com o número de seqüência 1060 O exemplo pressupõe que você esteja usando a alocação automática de canais. Caso você aloque canais manualmente, inclua o comando COPY na instrução RUN da seguinte maneira:

RMAN> RUN { 2> ALLOCATE CHANNEL c1 type disk;3> COPY

4> DATAFILE '/ORADATA/users_01_db01.dbf' to 5> '/BACKUP/users01.dbf',6> ARCHIVELOG 'arch_1060.arc' to7> 'arch_1060.bak';

8> }

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tags para Backups e Cópias-Imagem

Uma tag é um nome lógico designado a um conjunto de backup ou cópia-imagem.

month_full_backup week_full_backup

Arquivo de dados 3

Arquivo de dados 4

Conjunto de backup

Arquivos de dados 1, 3

Arquivos de dados 2, 4

Conjunto de backup

Tags para Backups e Cópias-Imagem Uma tag é um nome significativo que você pode designar a um conjunto de backup ou a uma cópia-imagem. As vantagens das tags são:

• Fazem uma referência útil a um grupo de cópias de arquivos ou a um conjunto de backup. • Podem ser usadas no comando LIST para localizar facilmente arquivos com backup. • Podem ser usadas nos comandos RESTORE e SWITCH. • A mesma tag pode ser usada para vários conjuntos de backup ou cópias de arquivos.

Se uma tag não exclusiva fizer referência a mais de um arquivo de dados, o RMAN escolherá o arquivo disponível mais atual. Exemplo

• Todo mês, é feito um backup integral dos arquivos de dados 1, 2, 3 e 4. A tag no arquivo de controle para esse backup é month_full_backup, embora o nome do arquivo físico gerado seja df_DB00_863_1.dbf.

RMAN> BACKUP TAG 'month_full_backup' DATAFILE 1,2,3,4;

• Toda semana, é feito um backup integral dos arquivos de dados 3 e 4. O nome da tag desse backup é week_full_backup.

RMAN> BACKUP TAG 'week_full_backup' DATAFILE 3,4;

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Opções do Comando BACKUP

• Verifica danos em blocos físicos.• Verifica danos lógicos e físicos. • Define um limite para o número de danos detectados

permitido antes de abortar.• Valida os arquivos de entrada de destino antes de

executar uma operação de backup.• Duplexa o conjunto de backup.• Sobregrava um conjunto de backup ou cópia-

imagem existente.• Passa o controle da transferência de dados entre

dispositivos de armazenamento e arquivos de dadosem disco para a camada de gerenciamento de mídia.

• Criptografa os arquivos de backup.

Opções do Comando BACKUPDurante a operação de backup, um processo do banco de dados Oracle executa um checksum de cada bloco para detectar danos. O RMAN verifica o checksum ao restaurar a cópia. Esse processo também é conhecido como detecção de danos físicos. É possível usar a opção NOCHECKSUM para suprimir a operação de checksum e acelerar o processo de backup. Se já houver checksums dos blocos no banco de dados, essa opção não terá efeito. Você pode usar a opção CHECK LOGICAL para testar danos lógicos, como danos em parte de uma linha ou em uma entrada de índice, em dados e blocos de índice aprovados em verificações de danos físicos. Se forem detectados danos lógicos, o bloco será registrado no log de alerta e no arquivo de rastreamento do processo do servidor. Você pode definir um limite para o número permitido de danos lógicos e físicos com o parâmetro MAXCORRUPT. Contanto que o total de danos físicos e lógicos detectados em um arquivo fique abaixo desse valor, a operação de backup do RMAN será concluída e o banco de dados Oracle preencherá a view V$DATABASE_BLOCK_CORRUPTION com as faixas de blocos danificados. Se o valor de MAXCORRUPT for ultrapassado, a operação será encerrada e a view não será preenchida. Use a opção VALIDATE para verificar erros físicos e lógicos em arquivos do banco de dados. Quando você usa o comando BACKUP com a opção VALIDATE, o RMAN varre os arquivos especificados e verifica seu conteúdo, testando se é possível fazer backup desses arquivos. Na verdade, esse comando não faz o backup dos arquivos especificados. A criptografia dos arquivos de backup é abordada na lição “Segurança do Banco de Dados”.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Opções do Comando BACKUP (continuação) Você pode criar até quatro cópias idênticas de cada componente de backup por meio da duplexação do conjunto de backup. Os seguintes comandos podem ser usados para produzir um conjunto de backup duplexado:

• BACKUP COPIES• SET BACKUP COPIES• CONFIGURE ... BACKUP COPIES

O RMAN não cria vários conjuntos de backup, e sim cópias idênticas de cada componente do conjunto de backup. Você não pode usar essa opção com o comando BACKUP AS COPY para criar várias cópias-imagem. Se especificar REUSE, você permitirá que o RMAN sobregrave um conjunto de backup ou uma cópia-imagem já existente com o mesmo nome do arquivo que o comando BACKUP está criando no momento. A funcionalidade de cópia PROXY faz o backup dos arquivos especificados, fornecendo ao software de gerenciamento de mídia o controle sobre a transferência de dados entre os dispositivos de armazenamento e os arquivos de dados em disco. O gerenciador de mídia — não o RMAN—decide como e quando mover os dados. Quando você executa o comando BACKUPcom a opção PROXY, o RMAN segue estas etapas:

1. Procura um canal do tipo de dispositivo especificado que utilize proxy. Se um canal desse tipo não for encontrado, o RMAN emitirá uma advertência e tentará um backup convencional (ou seja, sem proxy) dos arquivos especificados.

2. Se o RMAN localizar um canal que utilize proxy, ele chamará o gerenciador de mídia para verificar se ele pode fazer uma cópia proxy dos arquivos. Se o gerenciador de mídia não puder fazer a cópia proxy, o RMAN usará os conjuntos de backup convencionais para o backup dos arquivos.

Se você não quiser que o RMAN tente fazer uma cópia convencional quando uma cópia proxy falhar, use a opção ONLY. Como as cópias-imagem são gravadas apenas em disco, você não pode usar a opção PROXYcom o comando BACKUP AS COPY. Observação: Se você especificar PROXY, a variável %p deverá ser incluída na string FORMATexplícita ou implicitamente dentro de %U.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Fazendo Backup de Redo Logs Arquivados

• A alternância do arquivo de redo log on-line éautomática.

• É efetuado o failover do log arquivado.• Você pode especificar uma faixa de redo logs

arquivados para o backup.• Conjuntos de backups de arquivos de redo log

arquivados não podem conter outro tipo de arquivo.

RMAN> BACKUP 2> FORMAT '/disk1/backup/ar_%t_%s_%p' 3> ARCHIVELOG FROM SEQUENCE=234 4> DELETE INPUT;

Fazendo Backup de Redo Logs Arquivados Um problema comum que os DBAs enfrentam é não saber se um log arquivado foi completamente copiado para o destino do log de arquivamento antes de tentarem fazer backup do log. Por ter acesso ao arquivo de controle ou às informações do catálogo de recuperação, o RMAN sabe quais logs foram arquivados e poderão ser restaurados durante a recuperação. Você pode fazer backup dos arquivos de redo log arquivados com o comando BACKUPARCHIVELOG ou pode incluí-los no backup de arquivos de dados e de controle com o comando BACKUP … PLUS ARCHIVELOG. Os logs arquivados são sempre incluídos em um conjunto de backup separado, mesmo quando é usado PLUS ARCHIVELOG; nesse caso, um único comando de backup gera mais de um conjunto de backup. Se você só quiser fazer backup dos arquivos de log arquivados, especifique a faixa de logs arquivados para o backup. Os logs arquivados são sempre colocados em um conjunto de backup separado dos outros arquivos. Você também pode usar a cláusula NOT BACKED UP integer TIMES do comando BACKUPARCHIVELOG para fazer backup apenas dos logs cujo backup não foi feito o número de vezes especificado. Essa é uma maneira conveniente de fazer backup de logs arquivados em mídias específicas (por exemplo, você pode manter pelo menos três cópias de cada log em fita).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Fazendo Backup de Redo Logs Arquivados (continuação) O RMAN executa automaticamente o failover do log arquivado. Se forem detectados blocos danificados em um arquivo de redo log arquivado, o RMAN procurará um arquivo sem blocos danificados em outros destinos de arquivamento. O exemplo mostrado no slide faz backup de todos os redo logs arquivados com um número de seqüência de 234 ou mais alto para um conjunto de backup. Depois de serem copiados, os logs arquivados são deletados do disco e marcados como deletados na view V$ARCHIVED_LOG.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Backup Completo do Banco de Dados

RMAN> BACKUP DATABASEPLUS ARCHIVELOG;

Cópias doarquivo de log

arquivado

SPFILEArquivo decontroleCópias do

arquivo de dados

Backup Completo do Banco de Dados Um backup completo de banco de dados é uma cópia de todos os arquivos de dados e do arquivo de controle. Você pode incluir, opcionalmente, o SPFILE e os arquivos de log arquivados. Usar o Recovery Manager para criar uma cópia-imagem de todos os arquivos de banco de dados é tão fácil quanto montar o banco de dados, iniciar o RMAN e especificar o comando BACKUPmostrado no slide. Isso será possível se você já tiver executado os seguintes comandos CONFIGURE:

• CONFIGURE DEFAULT DEVICE TYPE TO disk; • CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; • CONFIGURE CONTROLFILE AUTOBACKUP ON;

Você também pode criar um backup (conjunto de backup ou cópia-imagem) das cópias-imagem anteriores de todos os arquivos de dados e arquivos de controle do banco de dados, usando o seguinte comando:

RMAN> BACKUP COPY OF DATABASE;

Por default, o RMAN executa cada comando BACKUP em série. No entanto, é possível paralelizar a operação de cópia:

• Usando CONFIGURE DEVICE TYPE DISK PARALLELISM n, em que n corresponde ao grau desejado de paralelismo

• Alocando vários canais • Especificando um comando BACKUP AS COPY e listando vários arquivos

Observação: Um alto grau de paralelismo exige mais recursos da máquina, mas pode economizar tempo.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tipos de Backup com o RMAN

• Um backup integral contém todos os blocos de arquivos de dados usados.

• Um backup incremental de nível 0 éequivalente a um backup integral que tenha sido marcado como nível 0.

• Um backup incremental cumulativode nível 1 contém apenas blocos modificados desde o últimobackup incremental de nível 0.

• Um backup incremental denível 1 diferencial contém apenas blocos modificados desdeo último backup incremental.

Backupincremental diferencial

Backupincremental cumulativo

Integral ou "backupincremental de nível 0"

Tipos de Backup com o RMAN Backups Integrais Um backup integral é diferente de um backup completo do banco de dados. Um backup integral do arquivo de dados é aquele que inclui todos os blocos de dados usados no arquivo. O RMAN copia todos os blocos no conjunto de backup ou cópia-imagem, ignorando somente os blocos de arquivos de dados que nunca foram usados. No caso de uma cópia-imagem integral, todo o conteúdo do arquivo é reproduzido com exatidão. Um backup integral não pode fazer parte de uma estratégia de backup incremental; não pode ser o pai de um backup incremental subseqüente. Backups Incrementais Um backup incremental é um backup de nível 0, que inclui cada bloco nos arquivos de dados, exceto os que nunca foram usados, ou um backup de nível 1, que inclui apenas os blocos que foram alterados desde o último backup. Um backup incremental de nível 0 é fisicamente idêntico a um backup integral. A única diferença é que o backup de nível 0 pode ser usado como base para o de nível 1, mas um backup integral nunca pode ser usado como base para um backup de nível 1. Os backups incrementais são especificados com a palavra-chave INCREMENTAL do comando BACKUP. Especifique INCREMENTAL LEVEL = [0 | 1].

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Tipos de Backup com o RMAN (continuação) Backups Incrementais (continuação) O RMAN pode criar backups incrementais em vários níveis da seguinte maneira:

• Diferencial: O tipo default de backup incremental que faz backup de todos os blocos alterados após o backup incremental mais recente executado no nível 1 ou 0.

• Cumulativo: Backup de todos os blocos alterados após o backup mais recente executado no nível 0

Exemplos• Para executar um backup incremental no nível 0, use o seguinte comando:

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

• Para executar um backup incremental diferencial, use o seguinte comando: RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

• Para executar um backup incremental cumulativo, use o seguinte comando: RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

O RMAN fará backups integrais por default se não for especificada a opção FULL ou INCREMENTAL. A compactação de blocos não utilizados faz com que os blocos nunca gravados sejam ignorados durante o backup dos arquivos de dados em conjuntos de backup, até mesmo em backups integrais. Um backup integral não afeta os backups incrementais subseqüentes e não é considerado parte de uma estratégia de backup incremental, embora o backup integral de uma cópia-imagem possa ser atualizado incrementalmente, aplicando-se backups incrementais com o comando RECOVER. Esse tópico será abordado posteriormente nesta lição.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comparação entre Diferencial e Cumulativo

• Um backup incremental diferencial contém todos os blocos alterados desde o último backup incremental.

• Um backup incremental cumulativo contém todos os blocos alterados desde o último backup incremental de nível 0.

NívelDia Dom Seg Ter Qua Qui Sex Sáb Dom

Nível 0 Nível 0

1 1 1c 110 01c

Comparação entre Diferencial e Cumulativo Os backups incrementais cumulativos duplicam as alterações já copiadas pelos backups incrementais não-cumulativos anteriores no mesmo nível. Dessa forma, se for feito um backup incremental de nível 1, o backup cumulativo de nível 1 seguinte incluirá todos os blocos recém-modificados, além daqueles dos quais já houve backup incremental de nível 1. Isso significa que é necessário somente um backup incremental do mesmo nível para a recuperação completa. Comparação entre backups incrementais e cumulativos:

• Os backups incrementais diferenciais são mais rápidos, gravam em menos blocos e produzem arquivos de backup menores. Isso resulta em um processo de backup mais rápido mas, durante a recuperação, o RMAN precisa recuperar cada backup incremental e aplicá-lo.

• Os backups incrementais cumulativos podem levar mais tempo, gravar em mais blocos e gerar arquivos de backup maiores. Os backups cumulativos são usados para acelerar a recuperação, pois um número menor de backups deverá ser aplicado durante a recuperação.

No gráfico mostrado no slide, uma empresa optou por uma estratégia de backup que utiliza backups incrementais e cumulativos. A cada domingo, um backup incremental de nível 0 é realizado. Duas vezes por semana, às quartas e sextas, um backup cumulativo é realizado para reduzir o tempo de recuperação do banco de dados. Nos outros dias, um backup diferencial é realizado para reduzir o tempo de backup e os requisitos de armazenamento.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Rastreamento deAlterações em Blocos

O processo de backup pode ser dinamizado ativando-se o rastreamento de alterações em blocos, que: • Registra os blocos alterados em um arquivo de

rastreamento de alterações • É usado automaticamente pelo RMAN, se ativado • Otimiza os backups incrementais evitando

verificações integrais de arquivos de dados durante o backup

Lista de blocos alterados

Geraçãode redo

Redo log

101100101011000011101001011010101110011

Arquivo derastreamento dealterações

SGA

CTWR

Commands BACKUP

> Block C.T. Inc. UpdateLISTREPORTDELETE

Rastreamento de Alterações em Blocos O objetivo de um backup incremental é copiar apenas os blocos de dados que foram alterados desde o backup anterior. O arquivo de dados é lido por inteiro durante cada backup incremental, mesmo que apenas uma pequena parte dele tenha sido alterada desde o último backup incremental. O recurso de rastreamento de alterações em blocos utiliza o processo de background CTWR(Change Tracking Writer) para registrar a localização física de todas as alterações do banco de dados em um novo tipo de arquivo chamado arquivo de rastreamento de alterações. Depois de ativado o rastreamento de alterações, o primeiro backup incremental de nível 0 ainda precisa verificar todo o arquivo de dados, já que o arquivo de rastreamento de alterações ainda não reflete o status dos blocos. Para os backups incrementais seguintes, o RMAN utiliza esses dados de rastreamento de alterações para determinar quais blocos devem ser lidos durante um backup incremental, aprimorando o desempenho ao eliminar a necessidade de leitura de todo o arquivo de dados. Use os mesmos comandos para executar backups incrementais se o rastreamento de alterações em blocos estiver ativado. Os próprios arquivos de rastreamento de alterações geralmente requerem pouca manutenção após a configuração inicial. O tamanho do arquivo de rastreamento de alterações em blocos é proporcional ao:

• Tamanho do banco de dados em bytes e ao número de threads ativados em um ambiente RAC

• Número de backups antigos mantidos pelo arquivo de rastreamento de alterações em blocos

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Ativando o Rastreamentode Alterações em Blocos

SQL> ALTER DATABASE ENABLE 2> BLOCK CHANGE TRACKING 3> USING FILE '/mydir/rman_change_track.f' 4> REUSE;

Ativando o Rastreamento de Alterações em Blocos Ative o rastreamento de alterações em blocos na página Maintenance do Enterprise Manager (EM). Clique no link Backup Settings e na tab Policy. Você precisa fornecer credenciais de login no sistema operacional para salvar essa definição de backup. O tamanho mínimo do arquivo de rastreamento de alterações em blocos é 10 MB, e mais espaço é alocado em incrementos de 10 MB. Não será necessário especificar um nome para o arquivo de rastreamento de alterações em bloco se o parâmetro db_create_file_dest for definido; nesse caso, será criado um arquivo gerenciado pelo Oracle. É possível usar os seguintes comandos para configurar manualmente o backup incremental rápido:

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

Se o parâmetro db_create_file_dest não estiver configurado, use a cláusula USINGFILE para especificar uma localização de diretório definida pelo usuário e um nome para o arquivo de rastreamento. Você pode verificar os detalhes da configuração atual do rastreamento de alterações em blocos consultando a view V$BLOCK_CHANGE_TRACKING. Por default, o rastreamento de alterações permanece desativado porque gera um pouco de overhead no desempenho do banco de dados durante as operações normais.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Atualização Incrementalde Backups

Arquivos de backup incremental

Arquivo de dados recuperado

Cópia-imagemdo arquivo de dados

Cópia-imagem do arquivo de dados atualizada para um estado mais recente

RMAN> RECOVER COPY OF2> DATAFILE {n|'file_name'}3> WITH TAG 'incr_upd_df1';

Commands BACKUPBlock C.T.

> Inc. Update LISTREPORTDELETE

Atualização Incremental de Backups Com o recurso de Backups com Atualização Incremental, você pode usar o RMAN paraaplicar backups incrementais a cópias-imagem de arquivos de dados. Esse método de recuperação permite ao RMAN recuperar uma cópia de um arquivo de dados ou efetuar rollforward da cópia-imagem em determinado momento aplicando os backups incrementais.Esta cópia é atualizada com todas as alterações efetuadas até o SCN em que o backup incremental foi realizado. O RMAN pode usar a cópia-imagem atualizada resultante na recuperação de mídia da mesma forma que utilizaria uma cópia-imagem integral realizada nesse SCN, sem o overheadcausado pela geração de uma cópia-imagem integral do banco de dados ou do arquivo dedados todos os dias. A atualização incremental de backups requer dois comandos diferentes:

• Use a forma BACKUP INCREMENTAL LEVEL 1...FOR RECOVER OF COPY WITHTAG ... do comando BACKUP para criar backups incrementais que podem seratualizados de modo incremental. Se um backup incremental de nível 0 ainda não existir,a execução desse comando criará um backup de nível 0 com a tag especificada.

• Aplique qualquer backup incremental a um conjunto de cópias de arquivos de dados coma mesma tag usando a forma RECOVER COPY ...WITH TAG ... do comandoBACKUP. Se não houver backup incremental ou cópia de arquivo de dados, o comando gerará uma mensagem mas não produzirá um erro.

As tags devem ser usadas para identificar os backups incrementais e as cópias de arquivos de dados criadas para uso nessa estratégia, de modo que não interfiram com outras estratégias de backup implementadas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comando LIST

• Lista conjuntos de backup e cópias dearquivos de dados:

• Lista conjuntos de backup e cópias de arquivos de dados de um tablespace específico:

• Lista conjuntos de backup e cópias com logs de arquivamento incluídos em uma faixa específica:

RMAN> LIST BACKUP OF DATAFILE 2> “/db01/ORADATA/u03/users01.dbf”;

RMAN> LIST BACKUP OF DATABASE;

RMAN> LIST COPY OF TABLESPACE “SYSTEM”;

RMAN> LIST COPY OF DATABASE ARCHIVELOG 2> FROM TIME='SYSDATE-7';

Commands BACKUPBlock C.T. Inc. Update

> LISTREPORTDELETE

Comando LISTUse o comando LIST do RMAN para exibir informações sobre conjuntos de backup, cópias proxy e cópias-imagem registradas no repositório. Use esse comando para listar:

• Backups e cópias que não têm o status AVAILABLE no repositório do RMAN • Backups e cópias de arquivos de dados disponíveis e que podem ser usados em uma

operação de restauração • Conjuntos de backup e cópias que contêm um backup de uma lista especificada de arquivos

de dados ou tablespaces especificados • Conjuntos de backup e cópias que contêm backup de qualquer log arquivado com um nome

ou uma faixa específica • Conjuntos de backup e cópias restritos por tag, horário de conclusão, grau de recuperação

ou dispositivo • Versões de um banco de dados específico ou de todos os bancos de dados do repositório • Scripts armazenados no catálogo de recuperação

Para usar o comando LIST, você deve estar conectado ao banco de dados de destino. Se você estiver conectado no modo NOCATALOG, o banco de dados de destino deverá estar montado. Se você se conectar usando um catálogo de recuperação, a instância de destino deverá ser iniciada (mas não precisará ser montada). Você pode controlar o modo como a saída é organizada (BY BACKUP ou BY FILE), bem como o nível de detalhes na saída (VERBOSE ou SUMMARY).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comando REPORT

• Faz uma análise detalhada do repositório

• Gera relatórios para responder a perguntas como:– Quais são os arquivos de

dados do banco de dados?– Quais arquivos precisam de

backup?– Quais backups podem ser

deletados?– Quais arquivos são

irrecuperáveis?

Commands BACKUP Block C.T. Inc. UpdateLIST

> REPORTDELETE

Comando REPORTEsse comando ajuda a analisar as informações do repositório do RMAN com mais detalhes. É possível gerar relatórios para várias perguntas, como:

• Qual é a estrutura do banco de dados? RMAN> REPORT SCHEMA;

• Quais arquivos precisam de backup? RMAN> REPORT NEED BACKUP ...;

• Quais backups podem ser deletados (isto é, estão obsoletos)? RMAN> REPORT OBSOLETE;

• Quais arquivos não são recuperáveis por causa de operações irrecuperáveis? RMAN> REPORT UNRECOVERABLE ...;

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comando REPORT NEED BACKUP

• Lista todos os arquivos de dados que precisam de backup

• Supõe que o backup mais recente será utilizado durante uma restauração

• Oferece quatro opções: – Incremental – Days – Redundancy – Recovery window

• Usa a configuração de política de retenção atual, caso nenhuma opção seja especificada

Comando REPORT NEED BACKUPO comando REPORT NEED BACKUP é utilizado para identificar todos os arquivos de dados que precisam de backup. O relatório supõe que o backup mais recente seja usado em caso de restauração. Existem quatro opções:

• Incremental: Um inteiro que especifica o número máximo de backups incrementais a serem restaurados durante a recuperação. Se a recuperação completa de um arquivo de dados exigir mais do que o número especificado de backups incrementais, o arquivo de dados necessitará de um novo backup integral. Por exemplo, para informar os arquivos que precisam de três ou mais backups incrementais para recuperação:

RMAN > REPORT NEED BACKUP incremental 3 database; • Days: Um inteiro que especifica o número máximo de dias desde o último backup integral

ou incremental de um arquivo. O arquivo precisará de um backup se o backup mais recente for igual ou superior a esse número.Por exemplo, para informar os arquivos do sistema cujo backup não é executado hátrês dias:

RMAN > REPORT NEED BACKUP days 3 tablespace system; • Redundancy: Um inteiro que especifica o nível mínimo de redundância considerado

necessário. Por exemplo, o nível de redundância dois exigirá um backup se não houver no mínimo dois backups.

• Recovery window: Um período durante o qual o RMAN deve recuperar o bancode dados

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




REPORT NEED BACKUP: Exemplos

• Arquivos que precisam de mais de três backups incrementais para recuperação:

• Arquivos sem backup há três dias:

• Backup necessário caso ainda não existam dois ou mais backups:

• Backup necessário para recuperar três dias:

RMAN> REPORT NEED BACKUP days 3;

RMAN> REPORT NEED BACKUP incremental 3;

RMAN> REPORT NEED BACKUP redundancy 2;

RMAN> REPORT NEED BACKUP 2> recovery window of 3 days;

REPORT NEED BACKUP: Exemplos Você pode avaliar o tempo de recuperação obtendo informações sobre o número de backups que precisam ser processados para recuperar os arquivos. Se você não quiser processar mais de três backups incrementais durante uma recuperação, poderá usar este comando que informa os arquivos que violaram esse requisito:

RMAN> REPORT NEED BACKUP incremental 3;

Se você tiver efetuado alterações significativas recentemente no banco de dados, precisará considerar os arquivos que não sofreram backup desde essa atividade. Se as alterações tiverem ocorrido há mais de três dias, o seguinte comando informará os arquivos que não sofreram backup enquanto as alterações eram implementadas:

RMAN> REPORT NEED BACKUP days 3;

Talvez você queira ver quais arquivos ainda não têm determinado número de backups, como um cenário hipotético diferente da sua política de retenção. Para obter essa informação para uma redundância de dois, digite este comando:

RMAN> REPORT NEED BACKUP redundancy 2;

Você pode informar quais arquivos precisam sofrer backup para poder fazer uma recuperação dos três últimos dias digitando este comando:

RMAN> REPORT NEED BACKUP recovery window of 3 days;

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




REPORT OBSOLETE eDELETE OBSOLETE

• Localizam todos os arquivos de recuperação obsoletos de acordo com as definiçõesda política de retenção atual:

• Listam os arquivos de recuperação obsoletos, se não forem necessárias mais do que duas cópias de backup:

• Deletam o conjunto de backup com uma chave de conjunto de backup igual a 4:

• Deletam os arquivos de recuperação considerados obsoletos, porque têm mais de dois backups:

RMAN> REPORT OBSOLETE REDUNDANCY 2;

RMAN> REPORT OBSOLETE;

RMAN> DELETE BACKUPSET 4;

RMAN> DELETE OBSOLETE REDUNDANCY 2;

Commands BACKUPBlock C.T. Inc. Update LIST REPORT

> DELETE

REPORT OBSOLETE e DELETE OBSOLETEUm backup obsoleto não é o mesmo que um backup expirado. Um backup obsoleto não é mais necessário de acordo com a política de retenção do usuário. Um backup expirado é um backup que o comando CROSSCHECK não conseguiu localizar no dispositivo de mídia especificado; orepositório indica que ele está lá, mas os arquivos de backup foram deletados ou movidos. Use o comando REPORT OBSOLETE para identificar os arquivos que não são mais necessários para satisfazer as políticas de retenção de backup. Por default, o comando REPORT OBSOLETEinforma quais arquivos estão obsoletos de acordo com a política de retenção configurada atualmente. Você pode gerar relatórios de arquivos obsoletos de acordo com diferentes políticas de retenção, usando as opções de política de retenção REDUNDANCY ou RECOVERY WINDOWcom o comando REPORT OBSOLETE. Se você executar REPORT OBSOLETE sem uma opção e uma política de retenção configuradas, o RMAN exibirá uma mensagem de erro. O comando DELETE pode remover qualquer arquivo no qual os comandos LIST e CROSSCHECK possam operar. Por exemplo, você pode deletar conjuntos de backup, redo logs arquivados e cópias de arquivos de dados. O comando DELETE remove o arquivo físico e o registro de catálogo do arquivo. O comando DELETE OBSOLETE deleta backups que não são mais necessários. Ele usa as mesmas opções REDUNDANCY e RECOVERY WINDOW que o comando REPORT OBSOLETE. Se deletar backups sem usar o RMAN, você poderá executar o comando CROSSCHECK ou UNCATALOG para remover os arquivos do catálogo de recuperação.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciando Backups com o EM

Auxílio de navegação:Home page do banco de dados > Maintenance > Manage Current Backups

Gerenciando Backups com o EM Você pode gerenciar os registros de backup com o Enterprise Manager. As funções de manutenção de backup fornecidas no Enterprise Manager incluem as seguintes:

• Exibição de listas de backups (conjuntos de backup e cópias-imagem) registradas no repositório do RMAN

• Verificação cruzada do repositório: – Verificação da existência e da acessibilidade dos backups listados no repositório – Marcação dos backups não acessíveis como expirados no momento da verificação

cruzada • Deleção do registro de backups expirados do repositório do RMAN • Deleção dos backups obsoletos do repositório e do disco

Você pode acessar a página Manage Current Backups no Enterprise Manager clicando em Manage Current Backups na região Backup/Recovery da página Maintenance. A página Manage Current Backups tem duas páginas de propriedades: Backup Set (a view inicial) e Image Copy. Cada uma atende a um propósito semelhante, listando os backups conforme registrados no repositório do Recovery Manager. Observação: Se você usar uma área de recuperação flash para o armazenamento do backup, muitas atividades de manutenção serão reduzidas ou eliminadas em virtude do gerenciamento automático do espaço em disco dessa área e da retenção de arquivos baseada na política de retenção.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Views Dinâmicas do RMAN

• V$ARCHIVED_LOG

• V$BACKUP_CORRUPTION

• V$BACKUP_DEVICE

• V$BACKUP_FILES

• V$BACKUP_PIECE

• V$BACKUP_REDOLOG

• V$BACKUP_SET

• V$BACKUP_SPFILE

• V$COPY_CORRUPTION

• V$RMAN_CONFIGURATION

Views Dinâmicas do RMAN Você pode usar as seguintes views para obter informações sobre o RMAN armazenadas no arquivo de controle:

• A view V$ARCHIVED_LOG mostra os archives que foram criados, submetidos a backup e removidos do banco de dados.

• A view V$BACKUP_CORRUPTION mostra os blocos considerados danificados durante o backup de um conjunto de backup.

• A view V$BACKUP_DATAFILE, que determina o número de blocos em cada arquivo de dados, é útil para criar conjuntos de backup de tamanhos iguais. Ela também pode ajudar a localizar o número de blocos danificados do arquivo de dados.

• A view V$BACKUP_DEVICE exibe informações sobre os dispositivos de backup suportados. O tipo de dispositivo especial DISK não é retornado por essa view porque sempre está disponível.

• A view V$BACKUP_FILES exibe informações sobre todos os backups do RMAN (cópias-imagem e conjuntos de backups) e logs arquivados. Essa view simula os comandos LISTBACKUP e LIST COPY do RMAN.

• A view V$BACKUP_PIECE mostra os componentes de backup criados para conjuntos de backup.

• A view V$BACKUP_REDOLOG mostra logs arquivados, armazenados em conjuntos de backup.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Views Dinâmicas do RMAN (continuação) • A view V$BACKUP_SET mostra os conjuntos de backup que foram criados. • A view V$BACKUP_SPFILE exibe informações sobre arquivos de parâmetros do servidor

em conjuntos de backup. • A view V$COPY_CORRUPTION mostra os blocos considerados danificados durante uma

cópia-imagem. • A view V$DATABASE_BLOCK_CORRUPTION lista os blocos do banco de dados

marcados como danificados durante o backup mais recente do RMAN.• A view V$RMAN_CONFIGURATION lista informações sobre as definições persistentes do

RMAN. Se usar definições proxy para o RMAN, você poderá consultar:

• V$PROXY_ARCHIVEDLOG• V$PROXY_DATAFILE

Para obter estatísticas de desempenho de backup, você pode consultar: • V$BACKUP_ASYNC_IO• V$BACKUP_SYNC_IO

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitorando Backups com o RMAN

• Correlacione as sessões do servidor e os canais usando o comando SET COMMAND ID.

• Consulte as views V$PROCESS e V$SESSION para determinar uma correspondência entre sessões e canais do RMAN.

• Consulte a view V$SESSION_LONGOPS para monitorar o andamento dos backups e das cópias.

• Use um utilitário do sistema operacional para monitorar o processo ou os threads.

Monitorando Backups com o RMAN Para correlacionar um processo e um canal durante um backup, siga este procedimento:

1. Inicie o Recovery Manager e conecte-se ao banco de dados de destino e, como alternativa, ao catálogo de recuperação.

2. Defina o parâmetro COMMAND ID depois de alocar os canais e copie o objeto desejado. A string especificada pelo comando SET COMMAND ID é informada na coluna V$SESSION.CLIENT_INFO de todos os canais alocados.

run { allocate channel t1 type disk; set command id to 'rman'; backup datafile 1; release channel t1;}

3. Consulte as views V$PROCESS e V$SESSION para obter o SID (Session Identifier) e o SPID (Operating System Process Identifier) dos canais usando a string COMMAND IDespecificada anteriormente.

SELECT sid, spid, client_info FROM v$process p, v$session s WHERE p.addr = s.paddr AND client_info LIKE '%id=rman%';

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Monitorando Backups com o RMAN (continuação) 4. Consulte a view V$SESSION_LONGOPS para verificar o status da cópia.

SELECT sid, serial#, context, sofar, totalwork, round(sofar/totalwork*100,2) "% Complete"

FROM V$SESSION_LONGOPS WHERE opname LIKE 'RMAN:%' AND opname NOT LIKE 'RMAN: aggregate%' AND totalwork != 0;

5. Se você usar um canal do tipo sbt e o processo de cópia parecer pendente, consulte a view V$SESSION_WAIT usando o SID obtido na etapa 3 para determinar se o RMAN está aguardando a conclusão de uma chamada de função ao gerenciador de mídia.

SELECT * FROM V$SESSION_WAIT WHERE event LIKE '%sbt%';

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Usar o comando BACKUP do RMAN para criar

conjuntos de backup e cópias-imagem • Listar os backups e as cópias-imagem feitas com o

RMAN • Informar e deletar backups obsoletos do RMAN

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício: Fazendo o Backup do Banco de Dados

Este exercício aborda os seguintes tópicos: • Ativação do arquivamento de redo logs para um

banco de dados • Uso do RMAN para exibir a estrutura do banco de

dados • Uso do Recovery Manager para fazer backup de

arquivos de dados e do arquivo de controle • Uso do Recovery Manager para criar cópias-imagem

dos arquivos de dados • Criação de um backup compactado de um banco de

dados • Programação de um job de backup

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperando Perdas Não Críticas

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Recuperar tablespaces temporários • Recuperar um membro de um grupo de redo logs• Recuperar um índice perdido • Recriar o arquivo de senha

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Causas da Perda de Dados

A perda de arquivos pode ser causada por:• Erro do usuário• Erro da aplicação• Falha de mídia

Causas da Perda de Dados Os arquivos podem ser perdidos ou danificados como conseqüência de:

• Erro do usuário: Um administrador pode inadvertidamente deletar ou sobregravar um arquivo necessário do sistema operacional.

• Erro da aplicação: Uma aplicação ou um script também pode apresentar erro de lógica ao processar arquivos do banco de dados, o que resulta em um arquivo perdido ou danificado.

• Falha de mídia: Uma unidade de disco ou uma controladora pode falhar total ou parcialmente, e incluir danos em arquivos, ou até causar a perda total de arquivos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Corrija o problema tomando uma destas medidas:• Crie um novo arquivo.• Reconstrua o arquivo.• Recupere o arquivo perdido ou danificado.

Comparação entre Crítico e Não Crítico

Uma perda de arquivo não crítica é aquela em que obanco de dados pode continuar funcionando.

Comparação entre Crítico e Não Crítico Um arquivo não crítico é um arquivo sem o qual o banco de dados e a maioria das aplicações conseguem operar. Por exemplo, se o banco de dados perder um arquivo de controle multiplexado, existem outros arquivos de controle que você pode usar para manter o banco de dados em atividade. Embora a perda de um arquivo não crítico não desative o banco de dados, ela pode comprometer o funcionamento dele. Por exemplo:

• A perda de um tablespace de índice pode tornar a execução de aplicações e consultas muito mais lenta, ou mesmo tornar uma aplicação inutilizável, caso os índices sejam usados para impor constraints.

• A perda de um grupo de redo logs on-line, desde que não seja o grupo atual de logs on-line, pode causar a suspensão das operações do banco de dados até que novos arquivos de log sejam gerados.

• A perda de um tablespace temporário pode impedir os usuários de executar consultas ou criar índices até que eles sejam designados a um novo tablespace temporário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Perdendo um TEMPFILE

SQL> select * from big_table order by 1,2,3,4,5,6,7,8,9,10,11,12,13;select * from big_table order by 1,2,3,4,5,6,7,8,9,10,11,12,13

*ERROR at line 1:ORA-01565: error in identifying file '/u01/app/oracle/oradata/orcl/temp01.dbf'ORA-27037: unable to obtain file statusLinux Error: 2: No such file or directory

As instruções SQL que exigem espaço TEMP para serem executadas falham caso esteja faltando um dosarquivos temporários.

Perdendo um TEMPFILESe um arquivo temporário pertencente ao tablespace TEMP for perdido ou danificado, o tablespace TEMP ficará indisponível. Esse problema se manifesta na forma de erros durante a execução de instruções SQL que exigem espaço TEMP para classificação. A instrução SQL mostrada no slide tem uma longa lista para ordenação dos valores, o que resulta na necessidade de espaço TEMP. Esse é o momento em que o erro de arquivo ausente é encontrado. É possível iniciar o banco de dados Oracle sem um arquivo temporário. Se um dos arquivos temporários não existir quando o banco de dados for iniciado, ele será criado automaticamente e o banco de dados será aberto normalmente. Quando isso acontece, uma mensagem como a mostrada abaixo aparece no log de alerta durante a inicialização:

Recreating tempfile /u01/app/oracle/oradata/orcl/temp01.dbf

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperando a Perda de um TEMPFILE

Arquivo desenha

Arquivo deparâmetros

SYSTEM

SYSAUX

UNDO

USERS

INDEX

Arquivo deredo log 1B

Arquivo deredo log 1A



Arquivosde controle

TEMP

Recuperando a Perda de um TEMPFILEVocê pode se recuperar da perda de um TEMPFILE sem reiniciar o banco de dados. Por exemplo, para recuperar o banco de dados quando o arquivo de dados temp01.dbfpertencente ao tablespace temporário default TEMP for deletado no nível do sistema operacional, adicione um novo arquivo de dados e elimine o arquivo deletado:

SQL> ALTER TABLESPACE temp ADD DATAFILE '/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 20M;

Tablespace altered.

SQL> ALTER TABLESPACE temp DROP TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf';

Tablespace altered.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Status do Grupo de Logs: Revisão

Um grupo de redo logs tem um dos seguintes valores de status em qualquer momento específico:• CURRENT: O processo LGWR está gravando

dados de redo no grupo de redo logs no momento.

• ACTIVE: Não são mais feitas gravações no grupo de redo logs, mas ele ainda é necessário para a recuperação de instâncias.

• INACTIVE: Não são mais feitas gravações no grupo de redo logs, e ele não é mais necessário para a recuperação de instâncias.

Status do Grupo de Logs: Revisão Para lidar com a perda de um arquivo de redo log, é importante compreender os estados possíveis dos grupos de redo logs. Os grupos de redo logs passam por um clico de três estados diferentes como parte da execução normal do banco de dados Oracle. A ordem do ciclo é a seguinte:

• CURRENT: Esse estado significa que o LGWR está gravando no grupo de redo logs para registrar dados de redo das transações que estão ocorrendo no banco de dados. O grupo de logs permanece nesse estado até ocorrer uma alternância para outro grupo de logs.

• ACTIVE: O grupo de redo logs ainda contém dados de redo necessários para a recuperação de instâncias. Esse é o status atribuído durante o período anterior à execução de um checkpoint que gravará nos arquivos de dados todas as alterações de dados representadas no grupo de redo logs.

• INACTIVE: O checkpoint mencionado acima foi realmente executado, o que significa que o grupo de redo logs não é mais necessário para a recuperação de instâncias e está livre para se tornar o próximo grupo de logs CURRENT.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_arc1_25739.trc:ORA-00313: open failed for members of log group 2 of thread 1ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/orcl/redo02b.log'ORA-27037: unable to obtain file statusLinux Error: 2: No such file or directory

Perdendo um Membro do Grupo de Redo Logs

O log de alerta e o arquivo de rastreamento do processo archiver (ARCn) registram um erro quando está faltando um membro do grupo de arquivos deredo log.

Perdendo um Membro do Grupo de Redo Logs Os dados de redo são essenciais para a recuperação porque contêm o registro de todas as modificações do banco de dados, que permitem o rollforward após a restauração a partir de um backup. Um grupo de redo logs pode conter vários membros, todos idênticos. Essa característica é importante para fins de redundância. Pelo menos dois grupos de redo logs devem estar disponíveis para que o banco de dados continue em execução, e no mínimo um membro deve estar disponível em cada grupo. Se um membro de um grupo de redo logs estiver inacessível, será gravado um erro no log de alerta e no arquivo de rastreamento do processo archiver. Se você perder um grupo de redo logs não atual, poderá usar a instrução ALTER DATABASECLEAR LOGFILE para recriar todos os membros do grupo. Nenhuma transação será perdida. Se o grupo de redo logs perdido tiver sido arquivado antes da perda, nenhuma outra ação será necessária. Caso contrário, você deverá fazer imediatamente um novo backup integral do banco de dados. Os backups anteriores à perda do log não são recuperáveis por causa do log perdido.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recriando Arquivos de Redo Log

SQL> ALTER DATABASE DROP LOGFILE MEMBER> '/u01/app/oracle/oradata/orcl/redo02b.log';

SQL> !rm /u01/app/oracle/oradata/orcl/redo02b.logSQL> ALTER DATABASE ADD LOGFILE MEMBER

> '/u01/app/oracle/oradata/orcl/redo02b.log'> TO GROUP 2;

Arquivo desenha


SYSTEM

SYSAUX

UNDO

USERS

INDEX




Arquivosde controle

TEMP


Recriando Arquivos de Redo Log Às vezes, convém eliminar um grupo inteiro de membros de redo log, ou eliminar um ou mais membros específicos de redo log. Por exemplo, em caso de falha no disco, talvez seja necessário eliminar todos os arquivos de redo log nesse disco para que o banco de dados não tente gravar em arquivos inacessíveis. Para eliminar um grupo de redo logs, você precisa do privilégio de sistema ALTER DATABASE. Antes de eliminar um grupo de redo logs, considere estas restrições e precauções:

• Uma instância requer pelo menos dois grupos de arquivos de redo log, independentemente do número de membros dos grupos.

• Você só poderá eliminar um grupo de redo logs ou um membro de um grupo se ele estiver inativo.

• Arquive um grupo de redo logs (se o arquivamento estiver ativado) antes de eliminá-lo. Para verificar se o arquivamento foi feito, use a view V$LOG.

SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG; GROUP# ARC STATUS --------- --- ----------------

1 YES ACTIVE 2 NO CURRENT 3 YES INACTIVE

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recriando Arquivos de Redo Log (continuação) Para eliminar um grupo de redo logs, use a instrução SQL ALTER DATABASE com a cláusula DROP LOGFILE. A seguinte instrução elimina o grupo de redo logs número 3:

ALTER DATABASE DROP LOGFILE GROUP 3;

Para eliminar um membro de redo log, você precisa do privilégio de sistema ALTERDATABASE. Considere estas restrições e precauções antes de eliminar membros individuais de redo log:

• Você pode eliminar arquivos de redo log de forma que um redo log multiplexado se torne temporariamente assimétrico. Por exemplo, se você usar grupos duplexados de arquivos de redo log, poderá eliminar um membro de um grupo, embora todos os outros grupos tenham dois membros cada um. No entanto, corrija essa situação imediatamente para que todos os grupos tenham no mínimo dois membros, eliminando, assim, o único ponto de falha possível para o redo log.

• Uma instância sempre requer pelo menos dois grupos válidos de arquivos de redo log, independentemente do número de membros dos grupos.

• Arquive o grupo ao qual um membro de redo log pertence (se o arquivamento estiver ativado) antes de eliminar o membro. Para verificar se o arquivamento foi feito, consulte a view V$LOG.

• Você só poderá eliminar um membro de redo log se ele não fizer parte de um grupo ativo ou atual. Se o grupo que você deseja eliminar estiver ativo, force uma alternância de log. O grupo ficará ativo ou inativo. Se ficar inativo, você poderá prosseguir com a eliminação. Se ficar ativo, primeiro será necessário forçar um checkpoint para torná-lo inativo. O exemplo abaixo mostra a progressão do grupo de log número 1 de CURRENT para ACTIVE e para INACTIVE:

SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG; GROUP# ARC STATUS

---------- --- ----------------1 NO CURRENT 2 YES INACTIVE 3 YES INACTIVE

SQL> alter system switch logfile; SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

GROUP# ARC STATUS ---------- --- ----------------

1 YES ACTIVE 2 NO CURRENT 3 YES INACTIVE

SQL> alter system checkpoint; System altered. SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

GROUP# ARC STATUS ---------- --- ----------------

1 YES INACTIVE 2 NO CURRENT 3 YES INACTIVE

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recriando Arquivos de Redo Log (continuação) Para eliminar membros inativos específicos de redo log, use a instrução ALTER DATABASEcom a cláusula DROP LOGFILE MEMBER. A seguinte instrução elimina o arquivo de redo log /u01/app/oracle/oradata/orcl/redo02b.log:

ALTER DATABASE DROP LOGFILE MEMBER '/u01/app/oracle/oradata/orcl/redo02b.log';

Quando um membro de redo log ou um grupo de redo logs for eliminado do banco de dados, e você não estiver usando o recurso OMF (Oracle Managed Files), os arquivos do sistema operacional não serão deletados do disco; somente o arquivo de controle será atualizado. Depois de eliminar um membro de redo log ou um grupo de redo logs, verifique se a eliminação foi concluída com êxito e, depois, use o comando apropriado do sistema operacional para deletar os arquivos de redo log eliminados, se eles ainda não tiverem sido eliminados. Quando você usa o Oracle Managed Files, a limpeza de arquivos do sistema operacional é feita automaticamente.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recriando Arquivos de Redo Log

Recriando Arquivos de Redo Log (continuação) Com o Enterprise Manager, você pode criar ou editar as informações sobre os grupos de redo logs associados ao banco de dados atual. Na página Administration, selecione Redo Log Groups na região Storage. A página Redo Log Groups exibe informações sobre cada grupo de redo logs, permitindo que você veja ou edite um grupo. Selecione um grupo de redo logs específico e clique em View. A tabela Redo Log Members lista os arquivos e os diretórios que compõem os membros do grupo de redo logs. Para adicionar ou deletar membros do grupo, clique em Edit.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recriando Índices

Use estas opções para reduzir o tempo de criação do índice:• PARALLEL

• NOLOGGING

SQL> CREATE INDEX rname_idx2 ON hr.regions (region_name)3 PARALLEL 4;

Recriando Índices Ao criar ou recriar um índice, você pode usar as seguintes palavras-chave para reduzir o tempo de criação:

• PARALLEL (NOPARALLEL é o default): Vários processos podem trabalhar simultaneamente para criar um índice. Ao dividir o trabalho necessário para criar um índice entre vários processos, o servidor Oracle cria o índice com mais rapidez do que quando um único processo do servidor cria o índice em seqüência. É criada uma amostra aleatória da tabela e um conjunto de chaves de índice é localizado, o qual divide igualmente o índice no mesmo número de partes de acordo com o grau de paralelismo especificado. Um primeiro conjunto de processos de consultas varre a tabela, extrai a chave e os pares de IDs de linha, e envia cada par para um processo localizado em um segundo conjunto de processos de consultas baseados em chave. Cada processo do segundo conjunto classifica as chaves e constrói um índice da maneira habitual. Após todas as partes do índice serem criadas, o coordenador paralelo concatena essas partes (que são ordenadas) para formar o índice final.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recriando Índices (cont.) • NOLOGGING: O uso dessa palavra-chave agiliza a criação de índice porque gera um

volume mínimo de entradas de redo log como resultado do processo de criação. Essa geração de redo bastante minimizada também se aplica a inserções de caminho direto e inserções do Direct Loader (SQL*Loader). Esse é um atributo permanente e, portanto, aparece no dicionário de dados. Ele pode ser atualizado com o comando ALTER INDEXNOLOGGING/LOGGING a qualquer momento.

Quando um índice é perdido, às vezes é mais rápido e simples recriá-lo, em vez de tentar recuperá-lo. Uma forma de determinar o SQL para criar o índice é usar o comando impdp SQLFILE=<filename> em um arquivo de saída expdp previamente gerado. Esse comando gera as instruções SQL necessárias para criar os objetos no arquivo de dump. Os utilitários expdp e impdp são abordados em detalhes no curso Oracle Database 10g: Workshop de Administração I.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Administração remotado banco de dados

Administração localdo banco de dados

Sim Sim

Não Não

Vocêtem uma conexão

segura?

Use aautenticaçãodo sistema

operacional.

Use umArquivo

de senha.

Métodos de Autenticação para Administradores de Bancos de Dados

Você desejausar a autenticação

do sistemaoperacional?

Métodos de Autenticação para Administradores de Bancos de Dados Dependendo do fato de você administrar o banco de dados localmente na mesma máquina em que o banco de dados reside, ou administrar vários servidores do banco de dados a partir de um único cliente remoto, você poderá optar pelo sistema operacional ou pelo arquivo de senha para autenticar os administradores do banco de dados:

• Se o banco de dados tiver um arquivo de senha e você tiver o privilégio de sistema SYSDBA ou SYSOPER, o arquivo de senha poderá autenticá-lo.

• Se o servidor não estiver usando um arquivo de senha, ou se você não tiver o privilégio SYSDBA ou SYSOPER, use a autenticação do sistema operacional. Na maioria dos sistemas operacionais, a autenticação de administradores de banco de dados envolve a colocação do nome de usuário do administrador do banco de dados em um grupo especial, conhecido genericamente como OSDBA. Os usuários desse grupo recebem privilégios SYSDBA. Um grupo semelhante, OSOPER, é usado para conceder os privilégios SYSOPER a usuários.

A autenticação do sistema operacional tem precedência sobre a autenticação do arquivo de senha. Particularmente, se você for membro do grupo OSDBA ou OSOPER do sistema operacional e se conectar como SYSDBA ou SYSOPER, você será conectado com os privilégios administrativos associados independentemente do nome de usuário/senha especificados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recriando um Arquivo de Autenticação de Senha

1. Efetue login no banco de dados usando a autenticação do sistema operacional.

2. Defina o parâmetro REMOTE_LOGIN_PASSWORDFILEcomo NONE e reinicie o banco de dados.

3. Recrie o arquivo de senha usando orapwd.

4. Defina REMOTE_LOGIN_PASSWORDFILE como EXCLUSIVE.

5. Adicione usuários ao arquivo de senha e designe os privilégios apropriados a cada usuário.

6. Reinicie a instância.

$ orapwd file=$ORACLE_HOME/dbs/orapwORCLpassword=admin entries=5

Recriando um Arquivo de Autenticação de Senha O banco de dados Oracle fornece um utilitário de senhas, orapwd, para a criação de um arquivo de senha. Ao conectar-se com o privilégio SYSDBA, você estará se conectando ao esquema SYS, e não ao esquema associado ao seu nome de usuário. Como SYSOPER, você se conectará ao esquema PUBLIC. O acesso ao banco de dados por meio do arquivo de senha é possibilitado por comandos GRANT especiais executados por usuários privilegiados. Em geral, o arquivo de senha não é incluído em backups porque, em quase todas as situações, é possível recriar esse arquivo como um último recurso. Se você perder o arquivo de senha, será necessário fazer shutdown e reiniciar o banco de dados pelo menos uma vez para recriar o arquivo. Para evitar um período de indisponibilidade desnecessário, inclua o arquivo de senha nos seus backups. É crucial para a segurança do sistema que você proteja o arquivo de senha e as variáveis de ambiente que identificam a localização desse arquivo. Qualquer usuário com acesso a esses itens pode comprometer a segurança da conexão. Observação: Não remova nem modifique o arquivo de senha se você tiver uma instância ou um banco de dados montado usando REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE (ou SHARED). Se você fizer uma dessas alterações, não poderá se reconectar remotamente usando o arquivo de senha. Mesmo que você o substitua, não será possível usar o novo arquivo de senha porque os timestamps e checksums estarão incorretos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recriando um Arquivo de Autenticação de Senha (continuação) Usando um Arquivo de Senha

1. Efetue login no banco de dados usando a autenticação do sistema operacional. 2. Defina o parâmetro REMOTE_LOGIN_PASSWORDFILE como NONE e reinicie o banco de

dados. 3. Crie o arquivo de senha usando o utilitário de senhas orapwd.

orapwd file=filename password=password entries=max_users

Onde: – filename é o nome do arquivo de senha (obrigatório). – password é a senha de SYSOPER e SYSDBA (obrigatório). – Entries é o número máximo de usuários distintos que podem se conectar como SYSDBA ou SYSOPER. Se você ultrapassar esse número, crie um novo arquivo de senha. É mais seguro usar um número maior. Não há espaços antes nem depois do sinal de igualdade (=).

Exemplo: orapwd file=$ORACLE_HOME/dbs/orapwU15 password=admin entries=5

4. Defina o parâmetro REMOTE_LOGIN_PASSWORDFILE como EXCLUSIVE, em que:

– EXCLUSIVE indica que apenas uma instância pode usar o arquivo de senha e que esse arquivo contém outros nomes além de SYS. Com um arquivo de senha EXCLUSIVE, você pode conceder privilégios SYSDBA ou SYSOPER a usuários individuais.

5. Conecte-se ao banco de dados usando o arquivo de senha criado na etapa 3. CONNECT sys/admin AS SYSDBA

6. Reinicie a instância. Localizações do Arquivo de SenhaUNIX: $ORACLE_HOME/dbsWindows: %ORACLE_HOME%\databaseMantendo o Arquivo de Senha Delete o arquivo de senha existente usando comandos do sistema operacional e crie um novo arquivo de senha usando o utilitário de senhas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Recuperar tablespaces temporários • Recuperar um membro de um grupo de redo logs • Recuperar um índice perdido • Recriar o arquivo de senha

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício: Recuperando a Perda de um TEMPFILE e de um Arquivo de Redo Log

Este exercício aborda os seguintes tópicos: • Inicialização de um banco de dados sem um arquivo

temporário • Criação de um novo tablespace temporário • Alteração do tablespace temporário default de um

banco de dados • Recuperação de um membro de redo log on-line

perdido

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperação de Banco de Dados

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos Ao concluir esta lição, você será capaz de: • Executar uma recuperação completa ou

incompleta gerenciada pelo usuário• Identificar situações nas quais é necessária uma

recuperação incompleta • Executar uma recuperação completa ou incompleta

usando o RMAN • Executar uma recuperação incompleta baseada em

horário, SCN, seqüência de log, pontos de restauração ou método de cancelamento

• Recuperar um arquivo de controle com backup automático

• Usar o Enterprise Manager para executar recuperações

• Recuperar tablespaces somente para leitura

Ger. usuárioRMAN CLIEMCompletaIncompletaArquivo de controleRO TBS

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Métodos de Recuperação

Existem dois métodos de recuperação: • Recuperação gerenciada por usuário

– Os arquivos devem ser mantidos e movidos manualmente.

– Use comandos SQL*Plus. • Recuperação do RMAN

– Os arquivos são gerenciados automaticamente. – Use a funcionalidade do RMAN, incluindo todos os

recursos de manutenção do repositório e de geração de relatórios.

– Pode ser feita com o Enterprise Manager. – Método recomendado pela Oracle Corporation.

Métodos de Recuperação A recuperação gerenciada por usuário requer mais envolvimento manual que a recuperação do RMAN, que é o método recomendado e abordado em mais detalhes nesta lição.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Gerenciada por Usuário:Comando RECOVER

• Restaure todos os arquivos do banco de dados apartir de um backup e recupere o banco de dados:

• Restaure os arquivos de dados danificados apartir de um backup e recupere esses arquivos:

Ou:

SQL> RECOVER DATABASE

SQL> RECOVER TABLESPACE index_tbs

SQL> RECOVER DATAFILE 2> '/oradata/indx01.dbf'

Recuperação Gerenciada por Usuário: Comando RECOVERA primeira etapa da recuperação de mídia gerenciada por usuário é a cópia dos arquivos de dados de um backup para restaurá-los manualmente. Se você não restaurar um arquivo de dados em sua localização original, atualize o arquivo de controle com a nova localização usando o comando ALTER DATABASE RENAME FILE. Restaure também os arquivos de log arquivados necessários para recuperar os arquivos de dados restaurados. Em restaurações com o RMAN, use o comando SET NEWNAME para especificar a nova localização do arquivo. Você pode usar um dos comandos a seguir para recuperar o banco de dados ou o arquivo de dados:

• RECOVER [AUTOMATIC] DATABASEEsse comando só pode ser usado para a recuperação de um banco de dados fechado.

• RECOVER [AUTOMATIC] TABLESPACE <NUMBER> | <NAME>Esse comando só pode ser usado para recuperação de um banco de dados aberto.

• RECOVER [AUTOMATIC] DATAFILE <'filename'> | <NAME>Esse comando pode ser usado para recuperação de bancos de dados abertos e fechados.

A palavra-chave AUTOMATIC instrui o banco de dados Oracle a gerar automaticamente o nome do próximo arquivo de redo log arquivado para continuar a operação de recuperação. Caso contrário, você será solicitado a informar esses nomes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação do RMAN:Comandos RESTORE e RECOVER

run{

sql "ALTER TABLESPACE inv_tbs OFFLINE IMMEDIATE";

RESTORE TABLESPACE inv_tbs;

RECOVER TABLESPACE inv_tbs DELETE ARCHIVELOG;

sql "ALTER TABLESPACE inv_tbs ONLINE";

}

Ger. usuário> RMAN CLI

EMCompletaIncompletaArquivo de controleRO TBS

Recuperação do RMAN: Comandos RESTORE e RECOVERSe você usar o RMAN para executar uma recuperação de mídia, ele restaurará qualquer log de redo arquivado de backups durante a operação de recuperação. Se os backups estiverem armazenados em um gerenciador de mídia, configure ou aloque canais a serem utilizados no acesso aos backups armazenados nesse local. A reconstrução do conteúdo total ou parcial de um banco de dados a partir de um backup geralmente envolve duas fases: a recuperação de uma cópia do arquivo de dados a partir de um backup e a reaplicação das alterações ocorridas desde o backup dos redo logs arquivados e on-line ao arquivo, para levar o banco de dados até o SCN desejado (geralmente o mais recente). O comando RESTORE recupera o arquivo de dados em um disco a partir de um backup armazenado em fita, disco ou outra mídia e o disponibiliza para o servidor do banco de dados. O comando RECOVER aplica as alterações registradas nos redo logs do banco de dados à cópia restaurada do arquivo de dados. Para gerenciar o espaço em disco associado a esses arquivos restaurados, uma opção muito útil é DELETE ARCHIVELOG, que causa a deleção dos redo logs arquivados restaurados do disco quando eles não são mais necessários à operação RECOVER. Para restaurações na área de recuperação flash, a opção DELETE ARCHIVELOG entra automaticamente em vigor.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação como Enterprise Manager

Com o Recovery Wizard do EnterpriseManager, você pode criar e executar um script do RMAN para realizar a recuperação.

RMAN> RECOVER DATABASE …

Ger. usuário RMAN CLI

> EMCompletaIncompletaArquivo de controleRO TBS

Recuperação com o Enterprise Manager Você também pode executar uma recuperação completa ou incompleta usando o Recovery Wizard disponível no Enterprise Manager. Na página Login, efetue login como um usuário com o privilégio SYSDBA. Clique em Login para acessar a página Database Summary. Nessa página, clique na tab Maintenance. A página Maintenance contém várias opções de backup, restauração e recuperação. Nessa página, clique em Perform Recovery. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Recuperação Completa e Incompleta

Existem dois tipos de recuperação: • A recuperação completa atualiza o banco de dados

até o presente, incluindo todas as alterações de dados efetuadas até o momento em que arecuperação foi solicitada.

• A recuperação incompleta leva o banco de dados atéum momento específico anterior à solicitação da operação de recuperação.

Tarefa derecuperação iniciada

neste momento

Recuperaçãocompleta

Recuperaçãoincompleta

Transações ausentes apósrecuperação incompleta

Restauraçãodeste backup

Recuperação Completa e Incompleta Quando você executa uma recuperação completa, o banco de dados é colocado no estado de completa atualização, incluindo todas as modificações de dados efetuadas até o presente. A recuperação incompleta, no entanto, devolve o banco de dados a um momento anterior. Isso significa que faltarão algumas transações e que todas as modificações de dados efetuadas entre o momento de destino da recuperação e o presente serão perdidas. Em vários casos, essa é a meta desejada porque podem ter sido realizadas operações no banco de dados que devem ser desfeitas. A recuperação até um momento anterior é uma forma de remover transações indesejadas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Completa

Arquivos de dadosrestaurados

Arquivos de dadoscom transaçõessubmetidas ounão a commit

Arquivos de dadosrecuperados

Alterações aplicadas

Undo aplicado

6

5

3

2

1

LogarquivadoLog

arquivadoRedo logon-line

4

Banco dedados aberto

Ger. usuário RMAN CLI EM

> CompletaIncompletaArquivo de controleRO TBS

Recuperação Completa Estas são as etapas que ocorrem durante a recuperação completa:

1. Os arquivos danificados ou não encontrados são restaurados a partir de um backup. 2. As alterações de backups incrementais, arquivos de redo log arquivados e arquivos de redo

log on-line são aplicadas conforme necessário. As alterações dos redo logs são aplicadas aos arquivos de dados até que o log on-line atual seja atingido e as transações mais recentes sejam informadas novamente. São gerados blocos de undo durante esse processo inteiro. Essa operação é chamada de rollforward ou recuperação do cache.

3. Os arquivos de dados restaurados agora podem conter alterações submetidas ou não a commit.

4. O banco de dados é aberto antes da aplicação do undo. Assim, é conseguida maior disponibilidade.

5. Os blocos de undo são utilizados para fazer o rollback de alterações não submetidas a commit. Essa operação às vezes é chamada de recuperação de transação.

6. Agora, os arquivos de dados estão em um estado recuperado e consistente com os outros arquivos de dados do banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Incompleta

Arquivos de dados comtransações submetidas

ou não a commit atéum momento específico

Arquivos de dadosecuperados até um

momento específico

Undo aplicado

6

5

3

2

1

LogarquivadoLog

arquivadoRedo logon-line

4

Banco dedados aberto

XX

Alterações aplicadas atéum momento específico

Arquivos de dadosrestaurados até o

momento necessáriono passado

Ger. usuário RMAN CLI EM Completa

> IncompletaArquivo de controleRO TBS

Recuperação Incompleta A recuperação incompleta ou pontual, usa um backup para produzir uma versão não atualizada do banco de dados. Em outras palavras, você não aplica todos os registros de redo gerados após o backup mais recente. Só execute esse tipo de recuperação quando for absolutamente necessário. Para executar uma recuperação incompleta, você precisa de:

• Um backup off-line ou on-line válido de todos os arquivos de dados executado antes do momento da recuperação

• Todos os logs arquivados do momento do backup até o momento específico da recuperação As etapas para executar uma recuperação incompleta são listadas abaixo:

1. Restaure arquivos de dados do backup. O backup usado pode não ser o mais recente, caso o momento de destino da restauração desejada não seja muito recente.

2. Aplique o redo dos arquivos de redo log arquivados, incluindo todos os arquivos necessários para alcançar o momento de destino da restauração.

3. Agora os arquivos de dados contêm algumas transações submetidas e outras não submetidas a commit porque o redo pode conter dados não submetidos.

4. O banco de dados é aberto antes da aplicação do undo. Assim, é conseguida maior disponibilidade.

5. Durante a operação de redo, também foi aplicado o redo de suporte aos arquivos de dados de undo. Assim, o undo fica disponível para ser aplicado aos arquivos de dados a fim de desfazer transações não submetidas a commit. Essa é a próxima etapa.

6. Os arquivos de dados são recuperados até o momento escolhido.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperação Incompleta (continuação) A recuperação pontual é a única opção quando você precisa executar uma recuperação e descobre que não tem um log arquivado com as transações que ocorreram em algum ponto entre o momento do backup usado na restauração e o SCN de destino da recuperação. Sem esse log, você não tem os registros das atualizações dos arquivos de dados durante esse período. A única opção é a recuperação do banco de dados a partir do momento do backup restaurado, até quando a série não interrompida de logs arquivados permitir, e a abertura do banco de dados com a opção RESETLOGS. Todas as alterações registradas no arquivo de redo log ausente ou posteriores a esse arquivo são perdidas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Situações Que Exigem Recuperação Incompleta

• Há uma falha na recuperação completa em decorrência da falta de um arquivo de log arquivado.

• Um ou mais arquivos de redo log não arquivados e um arquivo de dados são perdidos.

• Um backup do arquivo de controle é usado para abrir ou recuperar o banco de dados.

Situações Que Exigem Recuperação Incompleta Normalmente, você executa uma recuperação incompleta do banco de dados inteiro nestas situações:

• Perda de redo logs: Os redo logs não foram espelhados e você perdeu um redo log antes de seu arquivamento, juntamente com um arquivo de dados. Não é possível continuar a recuperação além do redo log perdido.

• Archive ausente: Ocorre uma falha na operação de recuperação completa porque um log arquivado não foi encontrado ou está danificado. Só é possível completar a recuperação até um momento anterior à aplicação do log arquivado.

• Arquivo de controle de backup: Um backup do arquivo de controle, e não a cópia atual, é usado para abrir o banco de dados. Talvez seja necessário usar um backup do arquivo de controle se:

– Todos os arquivos de controle forem perdidos, não for possível recriar o arquivo de controle e existir um backup binário do arquivo de controle. O espelhamento do arquivo de controle (em discos separados) e a manutenção de uma versão de texto atual da instrução CREATE CONTROLFILE reduzem as chances de uso desse método.

– Você estiver recuperando um banco de dados até um momento anterior e o banco de dados restaurado tiver uma estrutura diferente do atual.

Especifique a cláusula USING BACKUP CONTROLFILE no comando RECOVER DATABASEquando usar uma cópia antiga do arquivo de controle para recuperar ou abrir o bancode dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tipos de Recuperação Incompleta

Existem quatro tipos de recuperação incompleta: • Recuperação baseada em horário • Recuperação baseada em cancelamento • Recuperação baseada em alteração • Recuperação de seqüência de log

Tipos de Recuperação Incompleta Recuperação Baseada em Horário Com a cláusula UNTIL TIME, especifique o momento anterior até o qual o banco de dados deverá ser recuperado. A recuperação termina depois do commit de todas as alterações até o momento especificado. Utilize esse método quando um usuário fizer alterações indesejadas nos dados ou eliminar tabelas importantes, e o momento aproximado do erro for conhecido. O tempo de recuperação e a perda de dados serão minimizados se você for notificado imediatamente. Programas, segurança e procedimentos bem testados deverão evitar a necessidade desse tipo de recuperação. Recuperação Baseada em Cancelamento Durante o processo de recuperação, informe CANCEL no prompt da recuperação (e não o nome de um arquivo de log) para encerrar a recuperação. Utilize esse método quando:

• Um arquivo ou grupo atual de redo logs for danificado e não estiver disponível para recuperação. O espelhamento deverá evitar a necessidade desse tipo de recuperação.

• Um arquivo de redo log arquivado necessário para a recuperação for perdido. Backups freqüentes e vários destinos de arquivamento deverão evitar a necessidade desse tipo de recuperação.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Tipos de Recuperação Incompleta (continuação) Recuperação Baseada em Alteração Com a cláusula UNTIL CHANGE dos backups gerenciados pelo usuário e a cláusula UNTILSCN dos backups gerenciados pelo RMAN, especifique o SCN (número de alteração do sistema) da última alteração submetida a commit a ser recuperada. A recuperação termina depois do commit de todas as alterações até o SCN especificado. Use essa estratégia ao recuperar bancos de dados em um ambiente distribuído. Como alternativa, você pode usar a sintaxe UNTILRESTORE POINT e especificar um apelido para o SCN, chamado de ponto de restauração. Os pontos de restauração são abordados posteriormente nesta lição. Recuperação de Seqüência de Log Nos backups gerenciados pelo RMAN, você pode especificar o último número de seqüência de log a ser usado para recuperar o banco de dados com a cláusula UNTIL SEQUENCE. A recuperação será encerrada depois da aplicação de todos os arquivos de log, com exceção do arquivo de log especificado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Executando a Recuperação Incompleta Gerenciada por Usuário

• Recupere um banco de dados até um horário especificado:

• Recupere um banco de dados até o cancelamento:

• Recupere usando um arquivo de controle de backup:

SQL> RECOVER DATABASE UNTIL CANCEL

SQL> RECOVER DATABASE UNTIL

2 TIME '2005-12-14:12:10:03';

SQL> RECOVER DATABASE 2 UNTIL TIME '2005-12-14:12:10:03'3 USING BACKUP CONTROLFILE;

Executando a Recuperação Incompleta Gerenciada por Usuário O seguinte comando é usado para executar uma recuperação incompleta:

RECOVER [AUTOMATIC] DATABASE option

Onde: • AUTOMATIC: Aplica automaticamente arquivos de redo log e arquivos de redo log

arquivados • option: UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS'

UNTIL CANCEL UNTIL CHANGE <integer> USING BACKUP CONTROLFILE

Observação: Para aplicar os arquivos de redo log automaticamente durante a recuperação, você pode usar o comando SQL*Plus SET AUTORECOVERY ON, especificar AUTO no prompt de recuperação ou usar o comando RECOVER AUTOMATIC.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Executando a Recuperação Incompleta Gerenciada por Usuário

Para executar a recuperação incompleta gerenciada por usuário, siga este procedimento:1. Faça shutdown do banco de dados.2. Restaure os arquivos de dados.3. Monte o banco de dados.4. Recupere o banco de dados.5. Abra o banco de dados com a opção RESETLOGS.

Executando a Recuperação Incompleta Gerenciada pelo Usuário (continuação) 1. Caso ele esteja aberto, faça shutdown do banco de dados usando a opção NORMAL, IMMEDIATE ou TRANSACTIONAL.

2. Restaure todos os arquivos de dados do backup (o mais recente, se possível). Talvez seja necessário restaurar os logs arquivados. Se houver espaço suficiente disponível, faça a restauração em LOG_ARCHIVE_DEST ou use o comando ALTER SYSTEM ARCHIVE LOG START TO <LOCATION> ou LOGSOURCE <LOCATION> para alterar essa localização.

3. Monte o banco de dados. 4. Recupere o banco de dados usando o comando RECOVER DATABASE. 5. Para sincronizar os arquivos de dados com os arquivos de controle e os redo logs, abra o

banco de dados usando a opção RESETLOGS. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Recuperação Baseada em Horário Gerenciada por Usuário: Exemplo

Este é o cenário: • Um job executado com erro e seus efeitos precisam

ser desfeitos. • Isso ocorreu há 15 minutos e houve pouca atividade

de banco de dados desde então. • Você decide executar uma recuperação incompleta

para restaurar o estado do banco de dados de 15 minutos atrás.

SQL> SHUTDOWN IMMEDIATE$ cp /BACKUP/* /u01/db01/ORADATASQL> STARTUP MOUNTSQL> RECOVER DATABASE UNTIL TIME '2005-11-28:11:44:00';SQL> ALTER DATABASE OPEN RESETLOGS;

Recuperação Baseada em Horário Gerenciada por Usuário: Exemplo O seguinte cenário é típico do uso da recuperação UNTIL TIME. Considere estes fatos:

• O horário atual é 12:00 de 28 de novembro de 2005. • Um job foi executado incorretamente, e muitas tabelas de vários esquemas foram afetadas. • Esse problema ocorreu aproximadamente às 11:45. • A atividade do banco de dados é mínima porque a maior parte da equipe está em uma

reunião. O estado do banco de dados antes da execução do job deve ser restaurado. Como o horário aproximado do erro é conhecido, e a estrutura do banco de dados não foi alterada desde às 11:44, você pode utilizar o método UNTIL TIME:

1. Caso ele esteja aberto, faça shutdown do banco de dados usando a opção NORMAL, IMMEDIATE ou TRANSACTIONAL.

2. Restaure todos os arquivos de dados do backup (o mais recente, se possível). Talvez seja necessário restaurar os logs arquivados. Se houver espaço suficiente disponível, faça a restauração em LOG_ARCHIVE_DEST ou use o comando ALTER SYSTEM ARCHIVE LOG START TO <LOCATION> ou SET LOGSOURCE <LOCATION> para alterar essa localização.

3. Monte o banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperação Baseada em Horário Gerenciada por Usuário: Exemplo (continuação) 4. Recupere o banco de dados:

SQL> recover database until time '2005-11-28:11:44:00' ORA-00279: change 148448 … 11/27/05 17:04:20 needed for thread ... Media recovery complete.

5. Para sincronizar os arquivos de dados com os arquivos de controle e os redo logs, abra o banco de dados usando a opção RESETLOGS:

SQL> alter database open resetlogs; SQL> archive log list ... Oldest online log sequence 0 Next log sequence to archive 1 Current log sequence 1

Quando a recuperação for bem-sucedida, notifique os usuários de que o banco de dados está disponível para uso e de que será necessário digitar novamente os dados informados após o horário da recuperação (11:44:00).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Baseada em Cancelamento Gerenciada por Usuário: Exemplo

O cenário é o mesmo do exemplo baseado em horário, exceto pelas seguintes descobertas: • Os redo logs não são multiplexados. • Um dos redo logs on-line não foi encontrado. • O redo log ausente não foi arquivado. • O redo log continha informações das 11:34. • Vinte e seis minutos de dados foram perdidos. • Os usuários podem reinserir seus dados

manualmente.

Recuperação Baseada em Cancelamento Gerenciada por Usuário: Exemplo Após pesquisar o diretório dos arquivos de redo log, você percebe que o redo log log2a.rdonão foi localizado nem arquivado. Portanto, não é possível fazer uma recuperação além desse ponto. A consulta à view V$LOG_HISTORY confirma a ausência da seqüência de log arquivado 48 (log2a.rdo): SQL> SELECT * FROM v$log_history; RECID STAMP ... FIRST_CHANGE FIRST_TIME ----- --------- ... ------------ ----------

1 318531466 ... 88330 05-11-15:12:43 47 319512880 ... 309067 05-11-28:11:26

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Baseada em Cancelamento Gerenciada por Usuário: Exemplo

Recupere o banco de dados da seguinte maneira: 1. Faça shutdown do banco de dados. 2. Restaure todos os arquivos de dados do backup

mais recente. 3. Você já tem um backup válido; portanto, monte o

banco de dados. 4. Execute RECOVER DATABASE UNTIL CANCEL. 5. Execute ALTER DATABASE OPEN RESETLOGS para

abrir o banco de dados.

Recuperação Baseada em Cancelamento Gerenciada por Usuário: Exemplo (continuação)

As etapas da recuperação baseada em cancelamento são as mesmas da recuperação baseada em horário, exceto em relação à etapa RECOVER DATABASE. Quando o comando RECOVERDATABASE UNTIL CANCEL é executado, ele recupera o banco de dados até não conseguir encontrar um arquivo de log. Quando for solicitado o nome do arquivo, digite CANCEL para que a recuperação pare nesse momento.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Executando a RecuperaçãoIncompleta com o RMAN

1. Monte o banco de dados. 2. Aloque vários canais para fins de paralelização. 3. Restaure todos os arquivos de dados. 4. Recupere o banco de dados usando UNTIL TIME,

UNTIL SEQUENCE ou UNTIL SCN. 5. Abra o banco de dados usando RESETLOGS.

Executando a Recuperação Incompleta com o RMAN O RMAN pode recuperar o banco de dados até um momento anterior, um SCN ou um número de seqüência de log. Para executar uma recuperação incompleta do banco de dados, você precisa abri-lo com a opção RESETLOGS. Essa opção fornece aos redo logs on-line novos timestamp e SCN, impossibilitando danos aos arquivos de dados causados pela aplicação de redo logs arquivados obsoletos. Não é possível recuperar alguns arquivos de dados até um momento anterior aos RESETLOGS e outros até um momento posterior aos RESETLOGS. Você precisa recuperar todos os arquivos de dados até o mesmo SCN. A única exceção é feita quando o arquivo de dados é normal off-line ou somente para leitura. Você pode colocar os arquivos de tablespaces normais off-line ou somente para leitura on-line depois dos RESETLOGS, pois não há alterações transacionais nesses arquivos armazenadas nos redo logs. Observação: Só use o RMAN para restaurar os arquivos de dados se tiver feito ou registrado os backups por meio dele.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Baseada emHorário com o RMAN: Exemplo

RMAN> RUN {

2> SET UNTIL TIME = '2005-11-28:11:44:00';

3> RESTORE DATABASE;

4> RECOVER DATABASE;

5> ALTER DATABASE OPEN RESETLOGS; }

Recuperação Baseada em Horário com o RMAN: Exemplo Às 12:00 de terça-feira, em 28 de novembro de 2005, você percebeu que a tabela OE.ORDERStinha sido eliminada por engano. O horário aproximado da falha é conhecido, e a estrutura do banco de dados não foi alterada desde às 11:44. Você pode usar o método UNTIL TIME:

1. Caso ele esteja aberto, faça um shutdown normal do banco de dados. 2. Monte o banco de dados de destino. Não faça backup do banco de dados durante a

recuperação. 3. Certifique-se de que as variáveis de ambiente NLS_LANG e NLS_DATE_FORMAT foram

definidas de forma apropriada: $ NLS_LANG=american_america.we8iso8859p15 $ NLS_DATE_FORMAT=’YYYY-MM-DD:HH24:MI:SS’

4. Inicie o Recovery Manager e conecte-se ao banco de dados de destino. $ rman target rman/rman@ORCL

5. Você pode alocar vários canais para melhorar o desempenho: RMAN> run { allocate channel c1 type DISK;

2> allocate channel c2 type DISK;

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperação Baseada em Horário com o RMAN: Exemplo (continuação)6. Especifique o horário para recuperar e restaurar todos os arquivos de dados a partir de um

backup com os comandos do RMAN. O RMAN escolherá os arquivos corretos com base no comando SET UNTIL:

RMAN> ... set until time = '2005-11-28:11:44:00'; RMAN> ... restore database;

Observação: Se você precisar restaurar arquivos de redo log arquivados, use o comando RMAN SET ARCHIVELOG DESTINATION TO <location>.

7. Recupere o banco de dados até o horário especificado no comando SET UNTIL: RMAN> ... recover database;

8. Abra o banco de dados usando a opção RESETLOGS: RMAN> ... alter database open resetlogs; }

9. Verifique se a tabela existe. 10. Notifique os usuários de que o banco de dados está disponível para uso e de que eles

devem informar novamente os dados que não foram submetidos a commit antes da falha no sistema.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação de Seqüênciade Log com o RMAN: Exemplo

RMAN> RUN {2> SET UNTIL SEQUENCE 120 THREAD 1;3> ALTER DATABASE MOUNT;4> RESTORE DATABASE;5> RECOVER DATABASE; # recovers through log 1196> ALTER DATABASE OPEN RESETLOGS;7> }

Recuperação de Seqüência de Log com o RMAN: Exemplo A cláusula UNTIL SEQUENCE especifica um número de seqüência de redo log e um thread como limite superior. O RMAN seleciona apenas os arquivos que podem ser usados para a recuperação, mas não inclui o número de seqüência de log especificado. O exemplo do slide pressupõe que a seqüência de log 120 tenha sido perdida em decorrência de uma falha de disco e que o banco de dados precisa ser recuperado com os arquivos de redo log arquivados disponíveis.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Incompleta como Enterprise Manager

Recuperação Incompleta com o Enterprise Manager Para recuperar o banco de dados inteiro até um momento específico, na página Perform Recovery, selecione a opção “Recover to the current time or a previous point-in-time”. Em seguida, clique em Perform Whole Database Recovery. Escolha “Restore all datafiles” para restaurar todos os arquivos de dados do banco de dados até o estado de um backup anterior. Você também pode executar a recuperação a partir de arquivos de dados restaurados anteriormente. São usados dados de redo para fazer rollforward do banco de dados até um momento específico.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Incompleta e o Log de Alerta

Veja abaixo algumas das melhores práticas referentes ao log de alerta em cenários de recuperação incompleta:• Verifique o log de alerta antes e depois da

recuperação. • Procure informações sobre erros, dicas e SCNs.• Confirme se as etapas do processo de recuperação

foram bem-sucedidas.

Recuperação Incompleta e o Log de Alerta Durante a recuperação, as informações sobre andamento são armazenadas no log de alerta. Sempre verifique esse arquivo antes e depois da recuperação. Este é um exemplo de entrada no arquivo alert.log:

$ vi $ORACLE_BASE/admin/orcl/bdump/alert_orcl.log ... ALTER DATABASE RECOVER database until cancel Media Recovery Start ORA-279 signalled during: ALTER DATABASE RECOVER database until cancel ... Fri Aug 26 15:22:46 2005 ALTER DATABASE RECOVER CONTINUE DEFAULT ... Fri Aug 26 15:28:27 2005 ALTER DATABASE RECOVER CANCEL Fri Aug 26 15:28:27 2005 Media Recovery Canceled Completed: ALTER DATABASE RECOVER CANCEL

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Pontos de Restauração

Um ponto de restauração: • Serve como um apelido para um

SCN ou momento específico• É armazenado no arquivo de controle • Pode ser usado com:

– RECOVER DATABASE

– FLASHBACK DATABASE

– FLASHBACK TABLE

SQL> CREATE RESTORE POINT before_load;

before_load

RMAN> RECOVER DATABASE UNTIL RESTORE POINT before_load;2

1

Pontos de Restauração A criação de um ponto de restauração normal designa o nome do ponto de restauração a um momento específico ou SCN. Esse nome funciona como um tipo de marcador ou apelido que você pode usar com comandos que reconhecem uma cláusula RESTORE POINT como abreviatura para especificar um momento. Antes de executar qualquer operação que talvez precise ser revertida, você pode criar um ponto de restauração normal. O nome do ponto de restauração e do SCN são gravados no arquivo de controle. Posteriormente, se você precisar fazer referência a esse ponto em um comando RECOVER DATABASE, poderá fazê-la sem tentar decifrar um timestamp ou um valor de SCN. Com o Flashback de Banco de Dados, o Flashback de Tabela ou a recuperação pontual, você poderá fazer referência ao momento de destino usando o nome do ponto de restauração, em vez de uma expressão de tempo ou SCN. A definição de um ponto de restauração normal antes de uma operação a ser revertida elimina a necessidade de registrar manualmente um SCN com antecedência ou de descobrir o SCN correto depois do fato usando recursos como a Consulta de Flashback. Os pontos de restauração normais são bastante leves. O arquivo de controle pode manter um registro de milhares de pontos de restauração normais sem impacto significativo no desempenho do banco de dados. Ao final, os pontos de restauração normais são eliminados automaticamente do arquivo de controle caso não sejam deletados manualmente, por isso não exigem manutenção contínua. Observação: O uso de pontos de restauração com comandos FLASHBACK é abordado na lição “Flashback”.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recuperação Incompleta: Melhores Práticas

• Planeje e teste cenários com antecedência.• Investigue e verifique a necessidade da recuperação

incompleta.• Siga todas as etapas com cuidado.• Faça backups do banco de dados inteiro antes e

depois da recuperação.• Sempre verifique se a recuperação foi bem-sucedida.• Aproveite as vantagens dos pontos de restauração.

Recuperação Incompleta: Melhores Práticas • É importante seguir todas as etapas da recuperação com cuidado, pois a maioria dos

problemas de recuperação incompleta é causada por erro de um DBA durante o processo de recuperação.

• Durante a recuperação do banco de dados, só é possível fazer rollforward, e não rollback, da atividade de transação até o momento desejado. Esse é o motivo pelo qual é necessário restaurar todos os arquivos de dados para que o banco de dados retroceda até um momento anterior. Uma falha na restauração de todos os arquivos de dados impede que o banco de dados (não sincronizado) seja aberto.

• Faça um backup fechado do banco de dados inteiro (inclusive dos arquivos de controle e redo logs) antes de iniciar a recuperação incompleta. Esse procedimento é vantajoso porque:

– Permite a recuperação em caso de erro. Se ocorrer uma falha na recuperação (por exemplo, se você fizer a recuperação além do momento de recuperação desejado), não será possível usar os redo logs e os arquivos de controle na próxima recuperação, a menos que exista um backup desses arquivos.

– Economiza tempo em caso de falha na recuperação. Nessa situação, você pode restaurar os arquivos de dados a partir do novo backup, em vez de restaurá-los de um backup anterior, que necessita da aplicação de archives.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperação Incompleta: Melhores Práticas (continuação) Observação: Se um backup completo não for feito, pelo menos arquive o redo log atual:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT

e faça backup do arquivo de controle: SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/u01/data/backup.ctl';

• Faça um backup fechado completo após uma recuperação bem-sucedida. Essa ação poderá poupar muito tempo se for necessária outra recuperação antes do próximo backup programado. Com o Oracle Database 10g, essa etapa passa a ser opcional.

• Caso ocorra falha na recuperação e seja necessário executá-la novamente, sempre verifique se o problema foi corrigido antes de permitir que os usuários acessem o sistema.

Considere o seguinte exemplo: • Um banco de dados na seqüência de log 14 tem logs arquivados da seqüência 2

(arch_2.rdo) até a seqüência 13 (arch_13.rdo). • Após a execução de uma recuperação incompleta, será criada uma nova versão do banco de

dados, que define a seqüência de log do banco de dados como 0. • Agora, os logs arquivados de arch_2.rdo a arch_13.rdo fazem parte da antiga

versão do banco de dados. • Após algumas alternâncias de log, o log arquivado arch_2.rdo é sobregravado e seu

backup é executado com todos os outros archives (incluindo os antigos logs arquivados de arch_3.rdo a arch_13.rdo).

• Em um estágio posterior, se a recuperação precisar do log arch_6.rdo, será necessário verificar se o log arquivado restaurado a partir do backup está relacionado à versão correta do banco de dados; caso contrário, ocorrerá um erro.

Para evitar complicações, você pode usar a opção de formato %r do parâmetro de inicialização do banco de dados log_archive_format para:

• Incorporar automaticamente o ID dos resetlogs do banco de dados aos nomes dos arquivos de log arquivados

• Garantir que sejam construídos nomes exclusivos em diversas versões do banco de dados para os arquivos de log arquivados O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Recuperando um Arquivo deControle por Backup Automático

RecoveryManager(RMAN) Área de recuperação

flash

Banco de dados

Arquivo decontrole

RECOVER DATABASE;

ALTER DATABASE OPEN RESETLOGS;

ALTER TABLESPACE temp ADD TEMPFILE...;

RMAN> RESTORE CONTROLFILE TO 2> '/oradata/ctlfile.bak' FROM AUTOBACKUP;

Ger. usuárioRMAN CLI EMCompleta Incompleta

> Arquivo de controleRO TBS

Recuperando um Arquivo de Controle por Backup Automático Se você não estiver usando um catálogo de recuperação, configure o backup automático do arquivo de controle para restaurar esse arquivo rapidamente caso seja necessário. Os comandos usados para restaurar o arquivo de controle são os mesmos, independentemente de você estar usando ou não uma área de recuperação flash. No entanto, se você estiver usando uma área de recuperação flash, o RMAN executará implicitamente uma verificação cruzada dos backups e das cópias-imagem listadas no arquivo de controle, e catalogará os arquivos contidos na área de recuperação flash não registrados no arquivo de controle restaurado, melhorando a utilidade do arquivo de controle restaurado na restauração do restante do banco de dados. Observação: Não há uma verificação cruzada automática dos backups em fita após a restauração de um arquivo de controle. Se você estiver usando backups em fita, após restaurar o arquivo de controle e montar o banco de dados, execute a verificação cruzada desses backups.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperando um Arquivo de Controle por Backup Automático (continuação) Para restaurar o arquivo de controle a partir de um backup automático, o banco de dados deve estar no estado NOMOUNT. Em seguida, use o comando RESTORE CONTROLFILE FROMAUTOBACKUP:

RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP NOMOUNT; RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

O RMAN procura um backup automático do arquivo de controle. Se esse backup for localizado, o RMAN restaurará o arquivo de controle a partir dele em todas as localizações desse arquivo listadas no parâmetro de inicialização CONTROL_FILES. Se você tiver um catálogo de recuperação, não precisará definir o DBID ou usar o backup automático do arquivo de controle para restaurar esse arquivo. Você poderá usar o comando RESTORE CONTROLFILE sem argumentos:

RMAN> RESTORE CONTROLFILE;

A instância deverá estar no estado NOMOUNT quando você executar essa operação, e o RMAN deverá estar conectado ao catálogo de recuperação. O arquivo de controle restaurado é gravado em todas as localizações listadas no parâmetro de inicialização CONTROL_FILES. Se você também tiver perdido o SPFILE do banco de dados e precisar restaurá-lo a partir do backup automático, o procedimento será semelhante ao de restauração do arquivo de controle a partir do backup automático. Primeiro defina o DBID do banco de dados e, em seguida, use o comando RESTORE SPFILE FROM AUTOBACKUP. Depois que você iniciar a instância com o arquivo de parâmetros do servidor restaurado, o RMAN poderá restaurar o arquivo de controle a partir do backup automático. Após restaurar e montar o arquivo de controle, você terá as informações de backup necessárias para restaurar e recuperar o banco de dados. Depois de restaurar os arquivos de controle do banco de dados a partir de um backup, execute a recuperação completa da mídia e, depois, abra o banco de dados com a opção RESETLOGS.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando um Novo Arquivo de Controle

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Arquivo desenha


SYSTEM

SYSAUX

UNDO TEMP

USERS

INDEX





Arquivosde controle

Criando um Novo Arquivo de Controle Se o backup automático do arquivo de controle estiver configurado, é pouco provável que você precise recriá-lo. Entretanto, se for necessário, você poderá gerar e salvar um script para recriar esse arquivo. O comando ALTER DATABASE BACKUP CONTROLFILE TO TRACE gera um arquivo de rastreamento do usuário com o comando SQL para recriar o arquivo de controle. Copie o arquivo de rastreamento para um arquivo de script, como new_control.sql, delete as informações do cabeçalho do arquivo de rastreamento antes das palavras STARTUP NOMOUNT e efetue outras alterações desejadas, como aumentar o valor de MAXDATAFILES, MAXLOGFILES etc. Execute o script para criar um novo arquivo de controle. Use esse comando enquanto o banco de dados estiver montado ou aberto, e enquanto você estiver conectado como um usuário com privilégios de DBA.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando um Novo Arquivo de Controle

Criando um Novo Arquivo de Controle (continuação) A Console do Database Control permite gerenciar os arquivos de controle usados pelo banco de dados. Na página Administration, selecione Control Files na seção Storage. Você pode usar a página Control Files General para exibir as imagens espelhadas do arquivo de controle e as respectivas localizações. Clique em Backup To Trace para criar um arquivo de rastreamento para o arquivo de controle. Você também pode criar seu próprio comando CREATE CONTROLFILE, mas precisa fornecer os tamanhos e os caminhos completos para:

• Os arquivos de redo log • Todos os arquivos de dados associados ao banco de dados, inclusive os arquivos de dados

para SYSTEM e SYSAUXO

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Recuperando TablespacesSomente para Leitura

Alteração deEstado de

Tablespace

Falha erecuperação

Caso 1

Caso 2

Caso 3

Backup

Somente para leitura

Leitura/gravação



Leitura/gravação

*

*

*

* Backup de arquivo decontrole a ser usadopara recuperação seo atual for perdido

Ger. usuário RMAN CLI EM Completa IncompletaArquivo de controle

> RO TBS

Recuperando Tablespaces Somente para Leitura Ao tornar um tablespace somente para leitura, você impede operações de gravação nos arquivos de dados do tablespace, independentemente do nível de privilégio de atualização de um usuário. A vantagem dos tablespaces somente para leitura é que eles dispensam o backup e a recuperação de grandes partes estáticas de um banco de dados. Além disso, eles protegem os dados históricos contra modificações dos usuários. Como nunca é possível atualizar tablespaces somente para leitura, eles podem residir em dispositivos de CD-ROM ou WORM (write once, read many). O método de recuperação de um tablespace somente para leitura depende dos backups que estão disponíveis e de o tablespace ter sido ou não alterado para leitura/gravação ou somente para leitura durante o período da recuperação. Caso 1: O tablespace que está sendo recuperado é somente para leitura e tinha essa mesma configuração quando o último backup foi feito. Nesse caso, basta restaurar o tablespace a partir do backup. Não é necessário aplicar informações de redo. Caso 2: O tablespace que está sendo recuperado é de leitura/gravação, mas era somente para leitura quando ocorreu o último backup. Nesse caso, você precisa restaurar o tablespace a partir do backup e aplicar as informações de redo desde o momento em que o tablespace passou a ser de leitura/gravação. Caso 3: O tablespace que está sendo recuperado é somente para leitura, mas era de leitura/gravação quando ocorreu o último backup. Faça sempre backup de um tablespace após torná-lo somente para leitura a fim de evitar essa situação. No entanto, se essa situação ocorrer, será necessário restaurar o tablespace a partir do backup e recuperá-lo até o momento em que ele passou a ser somente para leitura.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Recuperando Tablespaces Somente para Leitura (continuação) Em todos os três casos, se o arquivo de controle atual não estiver disponível, o asterisco indicará o backup do arquivo de controle a ser usado na recuperação. Isso é necessário porque, quando é usado um arquivo de controle de backup, o processo de recuperação exige a execução de OPENRESETLOGS. Esse comando atualiza os cabeçalhos dos arquivos de dados, e esses arquivos não podem ser gravados quando são somente para leitura.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Questões Relativas à Recuperação de Tablespaces Somente para Leitura

É necessário tomar alguns cuidados especiais em relação aos tablespaces somente para leitura durante: • A recriação de um arquivo de controle • A renomeação de arquivos de dados • A utilização de um arquivo de controle de backup

Questões Relativas à Recuperação de Tablespaces Somente para Leitura Recriando um Arquivo de Controle Se você precisar recriar um arquivo de controle com o comando CREATE CONTROL FILE e o banco de dados contiver tablespaces somente para leitura, será necessário seguir procedimentos especiais. As etapas estão listadas no arquivo de rastreamento gerado pelo comando ALTERDATABASE BACKUP CONTROLFILE TO TRACE. Como o tablespace é somente para leitura, ele não sofre alterações e, por isso, supõe-se que não seja necessária uma recuperação. Os arquivos de dados do tablespace não são incluídos no arquivo de controle; portanto, como o banco de dados é inicializado com o novo arquivo de controle, o conteúdo desse arquivo é comparado por verificação cruzada aos arquivos do dicionário de dados. Todos os arquivos encontrados no dicionário de dados que não estiverem no arquivo de controle serão adicionados a esse arquivo com um nome do tipo MISSINGnnnnn. Depois que o banco de dados for aberto, renomeie os arquivos no arquivo de controle usando o comando ALTER DATABASE RENAMEFILE.

ALTER DATABASE RENAME FILE 'MISSING00005' TO '/u01/app/oracle/oradata/orcl/example01.dbf';

ALTER TABLESPACE "EXAMPLE" ONLINE;

A Oracle Corporation recomenda ativar o backup automático do arquivo de controle no RMAN para que você não precise depender dessa solução alternativa que é necessária quando o backup de um arquivo de controle é feito com o comando BACKUP CONTROLFILE TO TRACE.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Questões Relativas à Recuperação de Tablespaces Somente para Leitura (continuação)

Alterando o Local do Arquivo de Dados Se não conseguir restaurar uma cópia dos arquivos de dados em um tablespace somente para leitura para um destino correto, você poderá usar o comando ALTER DATABASE RENAME a fim de colocar os arquivos em outro local. Arquivo de Controle de Backup Se você tiver um tablespace somente para leitura em uma mídia somente para leitura, poderá encontrar erros ou ter problemas de desempenho na recuperação com a opção USING BACKUPCONTROLFILE. Essa situação ocorre quando o arquivo de controle de backup indica que um tablespace era de leitura/gravação quando foi feito o backup do arquivo de controle. Nesse caso, a recuperação da mídia talvez tente gravar nos arquivos. Quando a mídia é somente para leitura, o banco de dados exibe uma mensagem de erro informando que não pode gravar nos arquivos. A seguir, estão relacionadas algumas alternativas de recuperação de mídia somente para leitura quando é usado um arquivo de controle de backup:

• Coloque os arquivos de dados dos tablespaces somente para leitura off-line antes da recuperação com um arquivo de controle de backup. Após a recuperação da mídia, coloque os arquivos on-line.

• Use a versão correta do arquivo de controle para a recuperação. Para que o tablespace seja somente para leitura no final da recuperação, faça backup do arquivo de controle em um momento em que o tablespace era somente para leitura. Da mesma forma, para que o tablespace seja de leitura/gravação no final da recuperação, obtenha o arquivo de controle em um momento em que o tablespace era de leitura/gravação.

Recuperando o Banco de Dados Se o arquivo de dados for somente para leitura no momento da recuperação do banco de dados, o RMAN não o recuperará. Para alterar esse comportamento e fazer o RMAN verificar se os cabeçalhos dos arquivos de dados correspondem ao momento especificado, defina a opção CHECK READONLY com o comando RECOVER DATABASE.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário Nesta lição, você aprendeu a:• Executar uma recuperação completa ou incompleta

gerenciada pelo usuário • Executar uma recuperação completa ou incompleta

usando o RMAN• Identificar situações nas quais é necessária uma

recuperação incompleta • Executar uma recuperação incompleta baseada em

horário, SCN, seqüência de log, pontos derestauração ou método de cancelamento

• Recuperar um arquivo de controle com backupautomático

• Usar o Enterprise Manager para executar recuperações

• Recuperar tablespaces somente para leitura

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício: Executando umaRecuperação Incompleta

Este exercício aborda os seguintes tópicos:• Recuperação pontual usando o RMAN• Recuperação após perda de arquivos de controle

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Flashback

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Consultar a lixeira • Configurar o Flashback de Banco de Dados• Executar o Flashback de Banco de Dados em um

momento específico • Monitorar estatísticas de log de flashback• Ativar e desativar o recurso Flashback de Banco

de Dados• Usar o Recovery Wizard do Enterprise Manager

para executar o Flashback de Banco de Dados• Usar pontos de restauração garantidos com o

Flashback de Banco de Dados

LixeiraFlashback de BDConfig. FB de BDMonitorar FB de BDPt. Rest. Gar.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tecnologia de Flashback: Revisão

SIMDados de undo

TabelaAtualizar com a cláusulaWHERE incorreta

Dados de undo

Dados de undo

Dados de undo

Lixeira

Logs de flashback

Usos

Transação

Versão

Consulta

Eliminação

Banco de Dados

Tecnologiade Flashback

NÃOComparar dados atuais com dados antigos

NÃOInvestigar vários estados históricos de dados

Transação

NÃOComparar versões de uma linha

SIMEliminar tabelaTabela

SIMTruncar tabela; alteraçõesindesejadas em várias tabelas

Banco de Dados

AfetaDadosExemplos de Cenários

Nível do Objeto

Tecnologia de Flashback: Revisão Use a tecnologia de flashback em caso de danos lógicos no banco de dados Oracle, nos quais é necessário executar uma recuperação rápida e fácil dos dados. Assim como acontece com as falhas humanas, é difícil identificar os objetos e as linhas afetados por uma transação incorreta. Com a tecnologia de flashback, você pode diagnosticar como os erros são introduzidos no banco de dados e, depois, reparar os danos ocorridos. Você pode ver as transações que contribuíram para modificar linhas específicas, ver o conjunto inteiro de versões de determinada linha durante um período ou exibir apenas os dados na forma em que apareceram em um período anterior. A tabela do slide mostra os usos comuns da tecnologia de flashback. O Flashback de Banco de Dados usa logs de flashback para realizar o flashback. O Flashback de Eliminação usa a lixeira. Todas as outras técnicas usam dados de undo. Nem todos os recursos de flashback modificam o banco de dados. Alguns são simplesmente métodos de consulta de outras versões dos dados. Eles são ferramentas que você pode usar para investigar um problema e obter auxílio para a recuperação. Os resultados dessas consultas de flashback podem ajudá-lo a realizar uma destas tarefas:

• Determinar o tipo de operação de flashback de modificação de banco de dados a ser executada para corrigir o problema.

• Alimentar os resultados dessas consultas em uma instrução INSERT, UPDATE ou DELETEque permita reparar facilmente os dados incorretos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Flashback de Eliminação e Lixeira

DROP TABLE employees; FLASHBACK TABLEemployeesTO BEFORE DROP;

Um errofoi cometido.

RECYCLEBIN=ON

Flashback de Eliminação e Lixeira Nas releases anteriores do banco de dados Oracle, se você eliminasse uma tabela por engano, precisaria recuperar o banco de dados até um momento anterior para recuperar a tabela eliminada. Esse procedimento costumava demorar e gerava a perda do trabalho realizado por outras transações. O Oracle Database 10g dispõe do recurso Flashback de Eliminação, que você pode usar para desfazer os efeitos de uma instrução DROP TABLE sem precisar executar a recuperação pontual. Observação: O parâmetro de inicialização RECYCLEBIN é usado para verificar se o recurso de Flashback de Eliminação está no estado ON ou OFF. Se o parâmetro for definido como OFF, as tabelas eliminadas não irão para a lixeira. Se o parâmetro for definido como ON, as tabelas eliminadas irão para a lixeira e poderão ser recuperadas. Por default, RECYCLEBIN é definido como ON.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




3

21

Lixeira

DROP TABLE employees;

BIN$zbjra9wy==$0 EMPLOYEES_PK

EMPLOYEES

Lixeira

DBA_FREE_SPACE

BIN$zbjrBdpw==$0

USER_OBJECTS

BIN$zbjrBdpw==$0 EMPLOYEESBIN$zbjra9wy==$0 EMPLOYEES_PK

4

Os objetos são:– Renomeados– Não movimentados

Lixeira Sem a lixeira ativada, quando você elimina uma tabela, o espaço associado a ela e a seus objetos dependentes torna-se imediatamente reutilizável (isto é, pode ser usado para outros objetos). Se a lixeira estiver ativada, quando você eliminar uma tabela, o espaço associado a ela e a seus objetos dependentes não se tornará imediatamente reutilizável, mesmo que apareça em DBA_FREE_SPACE. Em vez disso, os objetos eliminados serão armazenados temporariamente na lixeira e continuarão a pertencer aos respectivos proprietários. O espaço usado pelos objetos da lixeira nunca é reutilizado automaticamente, a não ser em caso de insuficiência de espaço. Essa característica permite recuperar os objetos da lixeira pelo maior período possível. Quando é movida para a lixeira, uma tabela eliminada e os respectivos objetos e constraints associados são renomeados com nomes gerados pelo sistema. Essa alteração é necessária para evitar conflitos de nomes caso você crie posteriormente um novo objeto com o mesmo nome. A lixeira é uma tabela de dicionário de dados que mantém os relacionamentos entre os nomes originais dos objetos eliminados e os respectivos nomes gerados pelo sistema. É possível consultar o conteúdo da lixeira com a view DBA_RECYCLEBIN.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Lixeira (continuação) O diagrama do slide ilustra o novo comportamento:

1. Você criou uma tabela chamada EMPLOYEES no tablespace. 2. Você eliminou a tabela EMPLOYEES. 3. As extensões ocupadas por EMPLOYEES agora são consideradas espaço livre. 4. EMPLOYEES é renomeada e inserida na lixeira.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Restaurando Tabelas a Partir da Lixeira

• Restaure tabelas eliminadas e respectivos objetos dependentes.

• Se várias entradas da lixeira tiverem o mesmo nome original: – Use os nomes exclusivos gerados pelo sistema para

restaurar uma versão específica – Quando são usados os nomes originais, a tabela

restaurada é LIFO (last in, first out) • Altere o nome original caso ele esteja em uso no

momento.

FLASHBACK TABLE <table_name>TO BEFORE DROP [RENAME TO <new_name>];

Restaurando Tabelas a Partir da Lixeira Use o comando FLASHBACK TABLE ... TO BEFORE DROP para recuperar da lixeira uma tabela e todos os respectivos objetos dependentes possíveis. Você pode especificar o nome original da tabela ou o nome gerado pelo sistema designado ao objeto durante a sua eliminação. Se você especificar o nome original e a lixeira contiver mais de um objeto com esse nome, o objeto movido para a lixeira por último será recuperado primeiro (LIFO: last in, first out). Para recuperar uma versão mais antiga da tabela, especifique o nome gerado pelo sistema para a tabela a ser recuperada ou execute instruções FLASHBACK TABLE ... TO BEFORE DROPadicionais até recuperar a tabela desejada. Se uma nova tabela de mesmo nome tiver sido criada no mesmo esquema após a eliminação da tabela original, será retornado um erro, a não ser que você também especifique a cláusula RENAME TO. Observação: Quando você efetua o flashback de uma tabela eliminada, os índices, os triggers e as constraints recuperados mantêm os mesmos nomes que tinham quando estavam na lixeira. Portanto, convém consultar a lixeira e a view DBA_CONSTRAINTS antes de realizar o flashback de uma tabela eliminada. Desse modo, é possível renomear os índices, os triggers e as constraints recuperados com nomes mais apropriados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Lixeira: ReutilizaçãoAutomática de Espaço

BIN$zbjrBdpw==$0 BIN$zbjra9wy==$0

BIN$zbjra9wy==$0

BIN$zbjrBdpw==$0

1

2

3

Lixeira

DBA_FREE_SPACE - RECYCLEBIN

Expansão automática

Lixeira: Reutilização Automática de Espaço Você pode recuperar os objetos da lixeira com o recurso Flashback de Eliminação, contanto que o espaço usado por eles não seja reutilizado. Veja a seguir as políticas de reutilização de objetos da lixeira:

• Limpeza manual quando o comando PURGE é executado explicitamente • Limpeza automática em caso de falta de espaço: Enquanto os objetos são mantidos na

lixeira, o espaço correspondente também é informado em DBA_FREE_SPACE, pois é reutilizado automaticamente. O espaço livre em determinado tablespace é consumido na seguinte ordem:

1. Espaço livre não correspondente a objetos da lixeira 2. Espaço livre correspondente a objetos da lixeira. Nesse caso, os objetos da lixeira são

expurgados automaticamente por meio de um algoritmo FIFO (first in, first out). 3. Espaço livre automaticamente alocado se o tablespace tiver expansão automática

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Lixeira: Reutilização Automática de Espaço (continuação) Suponhamos que você crie uma nova tabela no tablespace TBS1. Se houver espaço livre alocado para esse tablespace que não corresponda a um objeto da lixeira, esse espaço será usado primeiro. Se o espaço for insuficiente, será utilizado o espaço livre correspondente aos objetos da lixeira que residem em TBS1. Se o espaço livre de alguns objetos da lixeira for utilizado, esses objetos serão expurgados automaticamente. Nesse momento, não será mais possível recuperá-los com o Flashback de Eliminação. Como último recurso, caso ainda haja necessidade de espaço, o tablespace TBS1 será estendido se possível.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Lixeira: Reutilização Manual de Espaço

PURGE {TABLE <table_name>|INDEX <index_name>}

PURGE TABLESPACE <ts_name> [USER <user_name>]

PURGE [USER_|DBA_]RECYCLEBIN

Lixeira: Reutilização Manual de Espaço Use o comando PURGE para remover objetos da lixeira definitivamente. Quando um objeto é expurgado da lixeira, esse objeto e os respectivos objetos dependentes são removidos do banco de dados permanentemente. Como resultado, não é mais possível recuperar os objetos expurgados da lixeira com o recurso Flashback de Eliminação. Os possíveis usos de PURGE são:

• PURGE TABLE expurga a tabela especificada. • PURGE INDEX expurga o índice especificado. • PURGE TABLESPACE expurga todos os objetos que residem no tablespace especificado.

Além disso, os objetos residentes em outros tablespaces poderão ser expurgados se forem dependentes. Como alternativa, defina a cláusula USER para expurgar somente os objetos pertencentesao usuário especificado com insuficiência de cota em disco no tablespace em questão.

• PURGE RECYCLEBIN expurga todos os objetos pertencentes ao usuário atual. RECYCLEBIN e USER_RECYCLEBIN são sinônimos.

• PURGE DBA_RECYCLEBIN expurga todos os objetos. Para executar esse comando, é necessário ter os privilégios de sistema adequados ou o privilégio de sistema SYSDBA.

Observação: Com relação aos comandos PURGE TABLE e PURGE INDEX, se você especificar um nome original ea lixeira contiver mais de um objeto com esse nome, o objeto que permaneceu mais tempo na lixeira será expurgado primeiro (FIFO).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Ignorando a Lixeira

DROP TABLESPACE <ts_name> [INCLUDING CONTENTS] ;

DROP USER <user_name> [CASCADE] ;

DROP TABLE <table_name> [PURGE] ;

Ignorando a Lixeira É possível usar o comando DROP TABLE PURGE para eliminar definitivamente uma tabela e os respectivos objetos dependentes do banco de dados. Quando você utiliza esse comando, os objetos correspondentes não são movidos para a lixeira. Esse comando fornece a mesma funcionalidade do comando DROP TABLE das releases anteriores. Quando você executa o comando DROP TABLESPACE ... INCLUDING CONTENTS, os objetos do tablespace não são colocados na lixeira. Além disso, os objetos na lixeira pertencentes ao tablespace são expurgados. Quando você executa o mesmo comando sem a cláusula INCLUDING CONTENTS, o tablespace precisa estar vazio para a execução bem-sucedida do comando. Entretanto, talvez existam objetos pertencentes ao tablespace na lixeira. Nesse caso, esses objetos são expurgados. Quando você executa o comando DROP USER ... CASCADE, o usuário e todos os objetos pertencentes a ele são eliminados do banco de dados definitivamente. Todos os objetos na lixeira pertencentes ao usuário eliminado são expurgados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Consultando a Lixeira

SELECT owner, original_name, object_name, type, ts_name, droptime, related, space

FROM dba_recyclebinWHERE can_undrop = 'YES';

SELECT original_name, object_name, type, ts_name, droptime, related, space

FROM user_recyclebinWHERE can_undrop = 'YES';

SQL> SHOW RECYCLEBIN

Consultando a Lixeira Para ver todos os objetos eliminados, consulte user_recyclebin ou RECYCLEBIN. dba_recyclebin mostra todos os objetos que foram eliminados por todos os usuários e que ainda estão na lixeira. Também é possível usar o comando SHOW RECYCLEBIN do SQL*Plus. Esse comando mostra somente os objetos cuja eliminação pode ser cancelada. Os exemplos mostram como extrair informações importantes da lixeira:

• original_name é o nome do objeto antes da eliminação. • object_name é o nome do objeto gerado pelo sistema após a eliminação. • type é o tipo do objeto. • ts_name é o nome do tablespace ao qual o objeto pertence. • droptime é a data em que o objeto foi eliminado. • related é o identificador do objeto eliminado. • space é o número de blocos usados no momento pelo objeto.

Você também pode ver o conteúdo da lixeira usando o Database Control. Observação: Para obter informações detalhadas sobre a view DBA_RECYCLEBIN, consulte o Oracle Database Reference Guide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Consultando Dados deTabelas Eliminadas

SELECT ... FROM "BIN$zbjrBdpw==$0" [AS OF ...]WHERE ...

Lixeira

USER_INDEXES

YES

INDEX_NAMEDROPPED

NO SALES_PK

USER_TABLESTABLE_NAMEDROPPED

YES

NO SALES

BIN$zbjrBdpw==$0 EMPLOYEES

BIN$zbjra9wy==$0 EMPLOYEES_PK

Consultando Dados de Tabelas Eliminadas Quando você elimina uma tabela, ela é movida para a lixeira e o seu nome original é alterado para um nome exclusivo gerado pelo sistema. Como ainda é o proprietário da tabela eliminada, você pode ver suas características nas diversas views de dicionário, como DBA_TABLES, DBA_OBJECTS, DBA_SEGMENTS e assim por diante. Para fazer a distinção entre as tabelas que estão na lixeira e as que não estão, a view DBA_TABLES tem uma nova coluna denominada DROPPED que é definida como YES no caso das tabelas que foram eliminadas, mas ainda permanecem na lixeira. Portanto, contanto que exista na lixeira um nome de tabela gerado pelo sistema, você poderá usá-lo em uma instrução SELECT e em consultas de flashback. Contudo, não é possível executar nenhum tipo de instrução DML ou DDL em objetos residentes na lixeira.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Flashback de Bancode Dados: Revisão

A operação de Flashback de Banco de Dados: • Funciona como um botão Retroceder do banco de

dados • Pode ser utilizada em caso de danos nos dados

lógicos provocados pelos usuários

O banco de dados está danificado.

O bancode dados

“retrocede”.

Você pressiona o botão

“Retroceder”.

Os usuários geram os

erros.

Lixeira> Flashback de BD

Config. FB de BDMonitorar FB de BDPt. Rest. Gar.

Flashback de Banco de Dados: Revisão Com o Flashback de Banco de Dados, você pode retornar o banco de dados rapidamente para um momento anterior desfazendo todas as alterações efetuadas desse momento em diante. Essa operação é rápida porque não é necessário restaurar backups. Você pode usar esse recurso para desfazer as alterações que causaram danos nos dados lógicos. Em caso de danos físicos no banco de dados ou perda de mídia, use os métodos de recuperação tradicionais.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Arquitetura do Flashback de Banco de Dados

Buffer deflashback

Buffer deredo log

SGA

LGWR

RVWRLogs deflashback

Redologs

… …

Cache de buffer

1

Registrar imagensanteriores de

blocosperiodicamente.

Reverter alterações no banco de dados usando

imagens anteriores.

Encaminhar recuperação

de mídia.

Todas asalterações

Nem todas asalterações!

2

Arquitetura do Flashback de Banco de Dados Quando você ativa o Flashback de Banco de Dados, o novo processo de background RVWR é iniciado. Esse processo grava seqüencialmente os dados do Flashback de Banco de Dados do buffer de flashback nos logs do Flashback de Banco de Dados reutilizados de maneira circular. Posteriormente, quando o comando FLASHBACK DATABASE é executado, os logs de flashback são usados para restaurar as imagens anteriores dos blocos; em seguida, são usados os dados de redo para fazer rollforward para o período de flashback desejado. O overhead de ativação do Flashback de Banco de Dados depende da combinação de leitura/gravação da carga de trabalho do banco de dados. Como as consultas não precisam registrar dados de flashback, quanto maior for o nível de gravação exigido pela carga de trabalho, maior será o overhead de ativação do Flashback de Banco de Dados. Observação: Os logs do Flashback de Banco de Dados não são arquivados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Configurando o Flashbackde Banco de Dados

1. Configure a área de recuperação flash.

3. Ative o Flashback de Banco de Dados.

2. Defina o alvode retenção.

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP MOUNT EXCLUSIVE;SQL> ALTER SYSTEM SET

2 DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH;SQL> ALTER DATABASE FLASHBACK ON;SQL> ALTER DATABASE OPEN;

LixeiraFlashback de BD

> Config. FB de BDMonitorar FB de BDPt. Rest. Gar.

Configurando o Flashback de Banco de Dados É possível configurar o Flashback de Banco de Dados da seguinte maneira:

1. Configure a área de recuperação flash. 2. Defina o alvo de retenção com o parâmetro de inicialização DB_FLASHBACK_RETENTION_TARGET. É possível especificar um limite superior, em minutos, para determinar até que momento deverá ser efetuado o flashback do banco de dados. O exemplo usa 2880 minutos, que equivalem a dois dias. Esse parâmetro é apenas um alvo e não fornece nenhuma garantia. O intervalo de tempo de flashback depende do volume de dados de flashback mantido na área de recuperação flash.

3. Ative o Flashback de Banco de Dados com o seguinte comando: ALTER DATABASE FLASHBACK ON;

Antes de executar o comando para ativar o Flashback de Banco de Dados, você precisa configurar o banco de dados para arquivamento e iniciá-lo no modo MOUNT EXCLUSIVE.

Para determinar se o Flashback de Banco de Dados está ativado, use a seguinte consulta: SELECT flashback_on FROM v$database;

Você pode desativar o Flashback de Banco de Dados com o comando ALTER DATABASEFLASHBACK OFF. Como resultado, todos os logs existentes do Flashback de Banco de Dados são deletados automaticamente. Observação: Você só pode ativar o Flashback de Banco de Dados com o banco de dados montado no modo exclusivo, e não aberto.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Configurando o Flashback deBanco de Dados com o EM

Verifique se o banco de dados está no modo ARCHIVELOG.

Configurando o Flashback de Banco de Dados com o EM Efetue login na Console de Banco de Dados do Enterprise Manager. Na página Maintenance, selecione Backup/Recovery Settings e escolha Recovery Settings. Verifique se o banco de dados está no modo ARCHIVELOG. Se não estiver, selecione ARCHIVELOG Mode e clique em Continue. Você precisará fazer shutdown e reiniciar a instância para que as alterações tenham efeito. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Configurando o Flashback deBanco de Dados com o EM

Ative o log de flashback e especifique a área de recuperação flash

Configurando o Flashback de Banco de Dados com o EM (continuação) Quando tiver certeza de que o banco de dados está no modo ARCHIVELOG, retorne à página Recovery Settings e role a tela até as regiões Media Recovery e Flash Recovery Area para observar as novas definições. Quando a área de recuperação flash e o arquivamento estiverem configurados, USE_DB_RECOVERY_FILE_DEST será configurado como o destino do log de arquivamento 10. Para ativar o log de flashback, marque Enable Flashback Logging. Também é possível definir o tempo de retenção de flashback, bem como exibir informações importantes sobre o período de flashback do banco de dados. Verifique a localização da área de recuperação flash. A área de recuperação flash é um local de armazenamento unificado de todos os arquivos e atividades relacionados à recuperação de um banco de dados Oracle. Todos os arquivos necessários para recuperar integralmente um banco de dados de uma falha de mídia fazem parte da área de recuperação flash. Os arquivos referentes à recuperação que você pode criar na área de recuperação flash incluem: arquivos de redo log arquivados, arquivos de controle, backups criados pelo RMAN (Recovery Manager), logs de flashback e o arquivo de rastreamento de alterações. Ao reservar um local de armazenamento e unificar os arquivos relacionados à recuperação em uma área específica, o servidor do banco de dados Oracle poupa o administrador do gerenciamento dos arquivos de disco criados por esses componentes. A localização default da área de recuperação flash é $ORACLE_BASE. Se preferir uma localização diferente, altere-a agora. Role a tela até a parte inferior da página Recovery Settings e clique em Apply.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Flashback de Banco de Dados: ExemplosRMAN> FLASHBACK DATABASE TO TIME =

2> "TO_DATE('2004-05-27 16:00:00',3> 'YYYY-MM-DD HH24:MI:SS')";

RMAN> FLASHBACK DATABASE TO SCN=23565;

RMAN> FLASHBACK DATABASE 2> TO SEQUENCE=223 THREAD=1;

SQL> FLASHBACK DATABASE 2 TO TIMESTAMP(SYSDATE-1/24);

SQL> FLASHBACK DATABASE TO SCN 53943;

SQL> FLASHBACK DATABASE TO RESTORE POINT b4_load;

Flashback de Banco de Dados: Exemplos É possível usar o comando FLASHBACK DATABASE do RMAN para executar a operação de Flashback de Banco de Dados. Você pode usar SEQUENCE e THREAD para especificar um número de seqüência de redo log e um thread como limite inferior. O RMAN seleciona apenas os arquivos que podem ser usados para fazer o flashback, mas não inclui o número de seqüência especificado. Como alternativa, é possível usar o comando SQL FLASHBACK DATABASE para retornar o banco de dados a um SCN ou um momento anterior. Se você usar a cláusula TO SCN, forneça um número. Se especificar TO TIMESTAMP, forneça um valor de timestamp. Você também pode especificar um nome de ponto de restauração. Observação: Monte o banco de dados no modo exclusivo para executar o comando FLASHBACK DATABASE e, quando terminar, abra-o com a opção RESETLOGS.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Executando o Flashback deBanco de Dados com o EM

Selecione o tipo deobjeto e deoperação

Executando o Flashback de Banco de Dados com o EM Na página Maintenance, escolha Perform Recovery. Na lista drop-down Object Type, selecione Whole Database. Em seguida, selecione “Recover to current time or a previous point-in-time” como Operation Type. Por fim, forneça as credenciais no sistema operacional de um usuário do banco de dados (isto é, alguém que pertença ao grupo dba). Quando concluir essas etapas, clique em Continue para avançar até a próxima etapa da operação de Flashback de Banco de Dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ





Iniciando o Recovery Wizard:

Executando o Flashback de Banco de Dados com o EM (continuação) Depois que você escolhe o tipo de operação de recuperação, o Recovery Wizard é acionado. Você é informado de que ocorrerá shutdown do banco de dados e de que ele será reinicializado no modo MOUNT. Essa operação demorará alguns minutos e você será informado sobre o atraso. Depois de aguardar durante o tempo necessário, você será solicitado a clicar em Refresh para continuar a operação. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ





Executando o Flashback de Banco de Dados com o EM (continuação) O Recovery Wizard foi iniciado. Nessa fase, ocorrem o shutdown e a inicialização do banco de dados no modo MOUNT. Clique em Refresh. A página Perform Recovery: Point-in-time é exibida. Nessa página, selecione a opção “Recover to a prior point-in-time” e especifique uma data ou um SCN. Clique em Next. A página Perform Recovery: Flashback é exibida. Nela, você pode optar pela recuperação por meio de flashback ou pela recuperação normal. Escolha a opção desejada e clique em Next. Essa ação leva você diretamente à página Perform Recovery: Review mostrada no slide. Clique em Submit para fazer flashback do banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Excluindo Tablespaces doFlashback de Banco de Dados

• Coloque o tablespace off-line antes de executar a recuperação de Flashback de Banco de Dados.

• Elimine o tablespace ou recupere os arquivos off-line com a recuperação pontual tradicional.

ALTER TABLESPACE <ts_name> FLASHBACK {ON|OFF}

SQL> SELECT name, flashback_on2 FROM v$tablespace;

Excluindo Tablespaces do Flashback de Banco de Dados Talvez você tenha um tablespace cujos dados do Flashback de Banco de Dados você não queira registrar. Nesse caso, você pode usar o comando ALTER TABLESPACE para excluir a participação do tablespace no flashback do banco de dados. Também é possível especificar esse atributo durante a criação de um tablespace. O valor default é ON. Coloque o tablespace off-line antes de efetuar o flashback do banco de dados. Depois, você pode eliminar o tablespace ou recuperar os arquivos de dados off-line usando métodos tradicionais de recuperação pontual. É possível consultar a view V$TABLESPACE para determinar o status do flashback de um tablespace. Observação: Se você recriar o arquivo de controle, todos os tablespaces serão colocados no modo FLASHBACK ON. Repita os comandos ALTER TABLESPACE para garantir que os tablespaces sejam excluídos das operações de Flashback de Banco de Dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Considerações sobre o Flashback de Banco de Dados

• Quando a operação de Flashback de Banco de Dados for concluída, abra o banco de dados: – No modo somente para leitura para verificar se o SCN

ou o tempo-alvo correto foi utilizado – Com uma operação RESETLOGS para permitir DML

• O contrário de “flashback” é “recuperação”. • Não é possível usar o Flashback de Banco de Dados

nas seguintes situações: – Se o arquivo de controle tiver sido restaurado ou

recriado. – Se um tablespace tiver sido eliminado. – Se um arquivo de dados tiver sido comprimido.

• Use TO BEFORE RESETLOGS para fazer flashback para um momento anterior à operação RESETLOGS.

Considerações sobre o Flashback de Banco de Dados Nas situações em que não for possível usar o recurso Flashback de Banco de Dados, execute uma operação de recuperação incompleta a fim de retornar o banco de dados para um momento específico. Quando a operação for concluída, você poderá abrir o banco de dados no modo somente para leitura e verificar se o SCN ou o tempo-alvo correto foi utilizado. Se nenhum deles tiver sido utilizado corretamente, você poderá repetir o flashback do banco de dados ou executar uma recuperação para efetuar o rollforward do banco de dados. Assim, para desfazer uma operação de Flashback de Banco de Dados, execute a recuperação avançada do banco de dados. Não é possível usar o Flashback de Banco de Dados para recuperar um arquivo de dados eliminado durante a operação de flashback. O arquivo de dados eliminado é adicionado ao arquivo de controle e marcado como off-line, mas não é submetido a flashback. O Flashback de Banco de Dados não pode fazer flashback de um arquivo de dados até um momento posterior à sua criação e anterior à operação de redimensionamento. Se um arquivo foi redimensionado durante o período até o qual você efetuará o flashback, coloque o arquivo off-line antes de iniciar a operação de flashback. Esse procedimento se aplica aos arquivos comprimidos, e não aos expandidos. É possível usar o Flashback de Banco de Dados com arquivos de dados configurados para extensão automática.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Considerações sobre o Flashback de Banco de Dados (continuação) Você pode fazer flashback para um ponto imediatamente anterior à operação RESETLOGSfornecendo a cláusula TO BEFORE RESETLOGS no comando FLASHBACK DATABASE. Observação: O alvo de retenção de flashback não é uma garantia absoluta de que o flashback estará disponível. Se for preciso liberar espaço para os arquivos necessários na área de recuperação flash, os logs de flashback poderão ser deletados automaticamente.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitorando o Flashbackde Banco de Dados

Para monitorar a capacidade de atender oalvo de retenção: • Exiba a cota de disco da área de recuperação flash:

• Determine o período de flashback atual:

• Monitore a geração de logs do Flashback de Banco de Dados:

SQL> SELECT estimated_flashback_size, 2 flashback_size3 FROM V$FLASHBACK_DATABASE_LOG;

SQL> SELECT *2 FROM V$FLASHBACK_DATABASE_STAT;

SQL> SELECT oldest_flashback_scn, 2 oldest_flashback_time3 FROM V$FLASHBACK_DATABASE_LOG;

LixeiraFlashback de BDConfig. FB de BD

> Monitorar FB de BDPt. Rest. Gar.

Monitorando o Flashback de Banco de Dados É importante monitorar o uso do espaço da área de recuperação flash para que você saiba se está atendendo adequadamente ao alvo de retenção. Use a view V$FLASHBACK_DATABASE_LOGpara monitorar o alvo de retenção do Flashback de Banco de Dados:

• ESTIMATED_FLASHBACK_SIZE usa dados de flashback registrados anteriormente a fim de fornecer uma estimativa do espaço em disco necessário na área de recuperação flash para que os logs de flashback atinjam o alvo de retenção de flashback atual. A estimativa se baseia na carga de trabalho desde a inicialização da instância ou durante o intervalo de tempo mais recente equivalente ao alvo de retenção de flashback, o que for mais curto.

• FLASHBACK_SIZE especifica o tamanho atual em bytes dos dados de flashback. • OLDEST_FLASHBACK_SCN e OLDEST_FLASHBACK_TIME exibem o menor valor

aproximado de SCN e o horário até o qual é possível fazer flashback do banco de dados. CURRENT_SCN em V$DATABASE especifica o SCN atual do banco de dados.

Use a view V$FLASHBACK_DATABASE_STAT para monitorar o overhead do registro de dados de flashback nos logs do Flashback de Banco de Dados. Essa view contém 24 horas de informações, com cada linha representando o intervalo de 1 hora. Você pode usá-la para determinar as alterações de taxas na geração de dados de flashback.

SQL> SELECT begin_time, end_time, flashback_data, db_data, 2 redo_data, estimated_flashback_size AS EST_FB_SZE 3 FROM V$FLASHBACK_DATABASE_STAT;

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Monitorando o Flashback de Banco de Dados (continuação)BEGIN_TIM END_TIME FLASHBACK_DATA DB_DATA REDO_DATA EST_FB_SZE --------- --------- -------------- ---------- ---------- ----------12-FEB-04 12-FEB-04 16384 0 24576 0 12-FEB-04 12-FEB-04 6594560 7471104 1533440 815923200 12-FEB-04 12-FEB-04 17235968 12361728 5150720 839467008 12-FEB-04 12-FEB-04 311648256 37249024 10272768 855195648

Com base nessas informações, talvez seja necessário ajustar o tempo de retenção ou o tamanho da área de recuperação flash. FLASHBACK_DATA e REDO_DATA representam o número de bytes de dados de flashback e de redo, respectivamente, gravados durante o intervalo de tempo, enquanto DB_DATA fornece o número de bytes de blocos de dados lidos e gravados. Essa view também contém o espaço de flashback estimado necessário ao intervalo.Você pode consultar a view V$RECOVERY_FILE_DEST para exibir informações referentes à área de recuperação flash. As descrições de coluna são:

• NAME: Nome da área de recuperação flash que indica a string do local• SPACE_LIMIT: Limite de disco especificado no parâmetro DB_RECOVERY_FILE_DEST_SIZE

• SPACE_USED: Espaço utilizado pelos arquivos da área de recuperação flash (em bytes)• SPACE_RECLAIMABLE: Espaço que pode ser reutilizado por meio da deleção de

arquivos obsoletos, redundantes e de prioridade baixa com o algoritmo de gerenciamento de espaço

• NUMBER_OF_FILES: Número de arquivos

SQL> SELECT name, space_limit AS quota, 2 space_used AS used, 3 space_reclaimable AS reclaimable, 4 number_of_files AS files 5 FROM v$recovery_file_dest ;

NAME QUOTA USED RECLAIMABLE FILES ------------------------ ---------- ---------- ----------- -----/u01/flash_recovery_area 5368709120 2509807104 203386880 226

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitorando o Flashback deBanco de Dados com o EM

Monitorando o Flashback de Banco de Dados com o EM É possível exibir a maioria das estatísticas de Flashback de Banco de Dados mencionadas nas páginas anteriores na página Recovery Settings. Essas métricas incluem o espaço atual usado por todos os logs de flashback, o SCN mais baixo e o horário do SCN mais baixo nos dados de flashback.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Pontos de RestauraçãoGarantidos

Um ponto de restauração garantido assegura que você possa executar um comando FLASHBACK DATABASEpara um SCN em qualquer momento.

SQL> CREATE RESTORE POINT before_load

2 GUARANTEE FLASHBACK DATABASE;

LixeiraFlashback de BDConfig. FB de BDMonitorar FB de BD

> Pt. Rest. Gar.

Pontos de Restauração Garantidos Assim como os pontos de restauração normais, abordados na lição “Recuperação do Banco de Dados”, os pontos de restauração garantidos podem ser usados como apelidos para SCNs em operações de recuperação. No entanto, eles também fornecem uma funcionalidade específica referente ao uso do recurso Flashback de Banco de Dados. A criação de um ponto de restauração garantido em um SCN específico impõe a condição de que você possa executar uma operação de Flashback do Banco de Dados para devolver o banco de dados ao estado em que ele se encontrava naquele SCN, mesmo que o log de flashback não esteja ativado para o banco de dados. Se o log de flashback estiver ativado, a criação de um ponto de restauração garantido imporá a retenção dos logs de flashback necessários para retornar o Flashback de Banco de Dados a qualquer momento posterior à criação do primeiro ponto de restauração garantido. Um ponto de restauração garantido pode ser usado para reverter um banco de dados inteiro para um estado reconhecidamente correto dias ou semanas antes, contanto que haja espaço suficiente no disco na área de recuperação flash para armazenar os logs necessários. Como ocorre com o Flashback de Banco de Dados, até mesmo os efeitos de operações NOLOGGING, como inserções de carga direta podem ser revertidos por meio de pontos de restauração garantidos. Observação: Assim como os pontos de restauração normais, os pontos de restauração garantidos podem ser usados para especificar um momento para operações RECOVERDATABASE. Consulte a lição “Recuperação de Banco de Dados” para obter mais informações.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Consultar a lixeira • Configurar o Flashback de Banco de Dados • Executar o Flashback de Banco de Dados até um

momento específico usando o Enterprise Manager ou o RMAN

• Monitorar estatísticas de log de flashback • Ativar e desativar o recurso Flashback de Banco de

Dados • Usar pontos de restauração garantidos com o

Flashback de Banco de Dados

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício: Executando o Flashback de Banco de Dados

Este exercício aborda os seguintes tópicos: • Execução do Flashback de Banco de Dados para

desfazer transações indesejadas • Monitoramento da retenção do Flashback de Banco

de Dados • Determinação do tamanho dos logs de flashback

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Lidando com Bancos de Dados Danificados

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Identificar os motivos de danos em bancos de dados:

– Hardware – Software

• Detectar danos em bancos de dados usando: – ANALYZE

– DBVERIFY

– DB_BLOCK_CHECKING

– DBMS_REPAIR

• Corrigir danos usando o RMAN

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




O Que É um Bloco Danificado?

• Sempre que um bloco é lido ou gravado, é executada uma verificação de consistência.– Versão do bloco– O valor do DBA (endereço do bloco de dados) no

cache comparado ao valor do DBA no buffer do bloco– Checksum do bloco, se estiver ativado

• Um bloco danificado é identificado por uma destas características:– Danos de mídia – Danos lógicos (ou de software)

O Que É um Bloco Danificado? Um bloco de dados danificado é um bloco que não está em um formato reconhecível pelo Oracle ou cujo conteúdo não é consistente internamente. Em geral, os danos são causados por hardware defeituoso ou problemas no sistema operacional. O banco de dados Oracle identifica blocos danificados com “danos lógicos” ou “danos de mídia”. Se o bloco apresentar danos lógicos, significa que houve um erro interno Oracle. O banco de dados Oracle marca blocos com danos lógicos após a detecção da inconsistência. Se houver dano de mídia, significa que o formato do bloco não está correto; as informações contidas nele não terão sentido após a leitura do disco. Para corrigir um bloco com dano de mídia, recupere o bloco e/ou elimine o objeto do banco de dados que contém o bloco danificado. Se os danos de mídia forem conseqüência de hardware defeituoso, o problema só será solucionado completamente depois que a falha no hardware for corrigida.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sintomas de Blocos Danificados: ORA-01578

O erro ORA-01578: "ORACLE data block corrupted (file # %s, block # %s)": • É gerado quando um bloco de dados danificado é

localizado • Sempre retorna o número absoluto do arquivo e do

bloco• É retornado à sessão responsável pela consulta que

estava em execução quando o dano foi descoberto • Aparece no arquivo alert.log

Sintomas de Blocos Danificados: ORA-01578 Com freqüência, o erro ORA-01578 é o resultado de um problema de hardware. Caso o erro ORA-01578 seja sempre retornado com os mesmos argumentos, é provável que o bloco tenha danos de mídia. Se os argumentos forem alterados em cada ocorrência, talvez exista um problema de hardware. Nesse caso, o cliente deve certificar-se de que haja espaço na memória e na página e, em seguida, verificar se existem controladoras incorretas no subsistema de entrada/saída.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Como Lidar com Danos

• Verifique o log de alerta e o arquivo de log dosistema operacional.

• Use as ferramentas de diagnóstico disponíveis para descobrir o tipo de dano.

• Determine se os erros são persistentes executando verificações diversas vezes.

• Recupere dados do objeto danificado se necessário.

Como Lidar com Danos Tente sempre descobrir se o erro é permanente. Execute o comando ANALYZE diversas vezes ou, se possível, execute um shutdown e uma inicialização, e repita a operação malsucedida anteriormente. Descubra se há mais danos. Se encontrar algum, é possível que existam outros blocos danificados. Use ferramentas como o DBVERIFY para lidar com essa situação. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Como Lidar com Danos

• Solucione os problemas de hardware:– Placas de memória – Controladoras de disco – Discos

• Recupere ou restaure os dados do objeto danificadose necessário.

Como Lidar com Danos (continuação) Não faz sentido continuar a trabalhar quando há falhas de hardware. Quando tiver problemas de hardware, entre em contato com o fornecedor para examinar e consertar a máquina antes de continuar. Execute uma sessão completa de diagnóstico do hardware. Há vários tipos possíveis de falhas de hardware:

• Firmware ou hardware de entrada/saída defeituoso • Problema de entrada/saída do sistema operacional ou de armazenamento no cache • Problemas de memória ou paginação • Utilitários de correção de disco

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recursos Relacionados a Danos

SIMNenhumRecuperação de mídia de bloco

SIMLógicoFlashback

SIMLógicoDBMS_REPAIR

NÃOLógicoDB_BLOCK_CHECKING

FísicoFísico

LógicoFísico

DanoDetectado

NÃODB_BLOCK_CHECKSUM

NÃOexp

NÃOANALYZE

NÃODBVERIFY

ReparaDanos

Recurso

Recursos Relacionados a Danos Existem várias ferramentas disponíveis para detectar, diagnosticar e corrigir danos em bancos de dados Oracle. O slide mostra um resumo das ferramentas abordadas nesta lição.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Utilitário DBVERIFY

• Só funciona em arquivos de dados; não é possível verificar arquivos de redo log

• Verifica a consistência dos blocos • Pode ser usado com o banco de dados aberto • Nome do programa utilitário: dbv

$ dbv file=/u01/oradata/users01.dbf \blocksize=8192

Utilitário DBVERIFY O DBVERIFY é um utilitário externo de linha de comandos que executa uma verificação de integridade da estrutura de dados físicos em um banco de dados off-line ou on-line. É possível usá-lo em arquivos on-line e de backup (ou em partes de arquivos). Use esse utilitárioprincipalmente quando precisar garantir que um banco de dados ou um arquivo de dados de backup seja válido antes que ele seja restaurado ou como ajuda para diagnósticos ao encontrar problemas de dados danificados. Como é possível executar o DBVERIFY em um banco de dados off-line, as verificações de integridade são muito mais rápidas. As limitações do DBVERIFY incluem:

• Ele não consegue detectar problemas como a falta de correspondência entre INDEX e TABLE, que o comando ANALYZE TABLE .. VALIDATE STRUCTURE CASCADEconsegue descobrir.

• Ele não verifica arquivos de redo log ou de controle. • Ele só verifica um bloco isoladamente, sem detectar se esse bloco faz parte ou não de um

objeto existente. • No caso de dispositivos brutos, use o parâmetro END para evitar a varredura de blocos após

o término do espaço do arquivo de dados: dbv FILE=/dev/rdsk/r1.dbf END=last_data_block#

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Interpretando a Saída DBVERIFY

• Uma “página” é um bloco. • Se o cabeçalho e o final do bloco não

corresponderem, o DBVERIFY lerá o bloco novamente. Se corresponderem, será informado um bloco de influxo; caso contrário, será sinalizado um dano.

Total Pages Examined : 12800Total Pages Processed (Data) : 4408Total Pages Failing (Data) : 0Total Pages Processed (Index): 1264

.

.

.Total Pages Marked Corrupt : 4Total Pages Influx : 0Highest block SCN : 654836 (0.654836)

Interpretando a Saída DBVERIFY Os blocos de influxo são blocos divididos. Se o DBVERIFY reportar blocos de influxo mas não reportar danos, significa que, quando ele leu o bloco na primeira vez, o DBWn estava gravando uma nova versão, e ele obteve parte da antiga versão e parte da nova versão desse bloco. Além disso, o DBVERIFY só verifica danos lógicos. Portanto, os danos podem ocorrer acima da marca d’água superior. Uma amostra de verificação do DBVERIFY é exibida abaixo:

$ dbv file=example01.dbf blocksize=8192DBVERIFY: Release 10.1.0.2.0 - Production on Fri Sep 9 13:17:45 2005

Copyright (c) 1982, 2005, Oracle. All rights reserved.

DBVERIFY - Verification starting : FILE = example01.dbf

DBVERIFY - Verification complete

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Interpretando a Saída DBVERIFY (continuação) Total Pages Examined : 12800 Total Pages Processed (Data): 4409 Total Pages Failing (Data): 0 Total Pages Processed(Index): 1264 Total Pages Failing(Index): 0 Total Pages Processed (Other): 1539 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 5588 Total Pages Marked Corrupt: 0 Total Pages Influx: 0 Highest block SCN : 654836 (0.654836)

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comando ANALYZE

• Executa uma verificação lógica dos blocos • Não marca danos lógicos em blocos; apenas

informa esses danos • Valida entradas de índices e tabelas

SQL> ANALYZE TABLE table_name VALIDATE 2 STRUCTURE CASCADE;

SQL> ANALYZE INDEX index_name VALIDATE 2 STRUCTURE;

Comando ANALYZEUse o comando ANALYZE para validar a estrutura de uma tabela ou de partições da tabela, e de um índice ou de partições do índice. O objeto a ser analisado precisa ser local e estar situado no seu esquema, ou você precisa ter o privilégio de sistema ANALYZE ANY. A opção CASCADEvalida um objeto, incluindo todos os objetos relacionados. Você pode executá-lo em uma sessão SQL*Plus de um objeto específico para realizar uma verificação de integridade e determinar se o erro é persistente, executando o mesmo comando ANALYZE várias vezes. Em tabelas particionadas, o comando ANALYZE também verifica se a linha pertence à partição correta. Se a linha não é intercalada corretamente, o ID da linha é inserido na tabela INVALID_ROWS.

SQL> ANALYZE TABLE partitioned_table PARTITION (p1)2 VALIDATE STRUCTURE INTO invalid_rows;

Uma instrução select simples (SELECT * FROM table) executa uma varredura integral de tabela, o que significa que ela lê todos os blocos de dados até a marca d’água superior da tabela. Você pode usar essa instrução para realizar uma verificação rápida de danos nos dados atuais da tabela. Você também pode usar o Data Pump para exportar objetos; ele também verifica integralmente cada tabela. Observação: O comando ANALYZE valida as informações sobre bitmaps referentes a segmentos ASSM (Auto Segment Space Management), mas não considera os blocos sem formatação abaixo da marca d’água superior nesses segmentos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Verificando a Integridade de Blocos em Tempo Real: DB_BLOCK_CHECKING

O parâmetro de inicialização DB_BLOCK_CHECKING: • Controla o grau de verificações de autoconsistência

executadas em cada bloco, à medida que é processado

• Pode evitar danos à memória e aos dados • Pode ser definido por meio do comando ALTER

SESSION ou ALTER SYSTEM DEFERRED

Verificando a Integridade de Blocos em Tempo Real: DB_BLOCK_CHECKINGQuando DB_BLOCK_CHECKING é definido como TRUE, o banco de dados Oracle verifica todos os blocos de dados. Para verificar um bloco, o banco de dados Oracle lê os dados do bloco e verifica a autoconsistência. Com freqüência, a verificação de blocos impede danos na memória e em dados. Em geral, essa verificação causa um overhead de 1% a 10%, de acordo com a carga de trabalho. Quanto maior for o número de atualizações ou inserções em execução, mais dispendiosa será a ativação da verificação de blocos. Os quatro valores possíveis para DB_BLOCK_CHECKING são:

• OFF: Não são realizadas verificações de blocos em nenhum tablespace, exceto SYSTEM. • LOW: São realizadas verificações básicas de cabeçalho de blocos após a alteração do

conteúdo dos blocos na memória (por exemplo, depois de instruções UPDATE ou INSERTe de leituras em disco).

• MEDIUM: São realizadas todas as verificações LOW, bem como as verificações de todos os blocos de tabelas não organizadas por índice.

• FULL: São realizadas todas as verificações LOW e MEDIUM, bem como as verificações em blocos de índice.

Defina DB_BLOCK_CHECKING como FULL se o overhead do desempenho for aceitável. O valor default é FALSE, que, para fins de retrocompatibilidade, é equivalente a OFF. Mesmo que esse parâmetro seja desativado, a verificação de blocos para o tablespace SYSTEM sempre estará ativada.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Verificando a Integridade de Blocos em Tempo Real: DB_BLOCK_CHECKSUM

O parâmetro de inicialização DB_BLOCK_CHECKSUM:• Determina se um checksum deve ou não ser mantido

e verificado em cada bloco• Pode evitar danos causados por sistemas de

entrada/saída subjacentes

a14f

Verificando a Integridade de Blocos em Tempo Real: DB_BLOCK_CHECKSUMSe DB_BLOCK_CHECKSUM for definido como TRUE, o processo DBWn e o Direct Loader calcularão um checksum e o armazenarão no cabeçalho do cache de cada bloco de dados ao gravá-lo em disco. Um checksum é um número calculado com base em todos os bytes armazenados no bloco. Quando o bloco é lido posteriormente, o checksum é recalculado e o valor armazenado é verificado em relação a esse valor calculado. Como os checksums permitem que o banco de dados detecte danos causados por discos subjacentes, sistemas de armazenamento ou sistemas de entrada/saída com um overhead de somente 1% a 2%, a Oracle recomenda a definição de DB_BLOCK_CHECKSUM como TRUE, que é o valor default.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando EXP para Detectar Danos

A exportação convencional pode ser usada para detectar danos.

$ exp hr/hr tables=departments

About to export specified tables via Conventional Path .... . exporting table DEPARTMENTSEXP-00056: ORACLE error 1578 encounteredORA-01578: ORACLE data block corrupted (file # 5, block # 51)ORA-01110: data file 5: '/u01/app/oracle/oradata/orcl/example01.dbf'

Usando EXP para Detectar Danos Uma outra alternativa para detectar danos em blocos é o utilitário de exportação, EXP. Como o EXP faz uma varredura integral de cada bloco do objeto que está exportando, ele reporta erros quando encontra danos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando o Flashback para Danos Lógicos

DBA

USUÁRIO

SQL de Undo ou

Flashback de Tabela

Dados danificadoslocalizados

Flashback de Consulta de Versão

Flashback de Consulta de Transação

Usando o Flashback para Danos Lógicos Depois da eliminação de um dano físico, você pode usar uma combinação de recursos de flashback para determinar quando ocorreu um dano lógico. Por exemplo, primeiro você pode usar o flashback de consulta de versão para exibir os valores de uma linha durante um período. O flashback de consulta de versão também pode retornar o ID da transação. Com o ID da transação, você pode exibir todos os objetos afetados pela mesma transação. Para desfazer os danos nos dados, você pode usar as informações retornadas na coluna UNDO_SQL a fim de corrigir o erro ou pode efetuar o flashback da tabela até o horário (SCN) anterior à execução da transação. Observação: Os detalhes sobre a execução de um flashback de consulta de versão são abordados no curso Oracle Database 10g: Workshop de Administração I.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Package DBMS_REPAIR

Procedures disponíveis • CHECK_OBJECT

• FIX_CORRUPT_BLOCKS

• DUMP_ORPHAN_KEYS

• REBUILD_FREELISTS

• SEGMENT_FIX_STATUS

• SKIP_CORRUPT_BLOCKS

• ADMIN_TABLES

Package DBMS_REPAIRPara gerenciar danos em blocos de dados, também é possível usar o package DBMS_REPAIR. Você pode usar o DBMS_REPAIR para detectar e corrigir blocos danificados em tabelas e índices. Com esse método, você pode solucionar danos onde for possível e continuar a usar objetos enquanto tenta reconstruí-los ou corrigi-los. Os procedures contidos no package incluem:

• CHECK_OBJECT: Detecta e informa danos em uma tabela ou índice • FIX_CORRUPT_BLOCKS: Marca blocos que foram identificados anteriormente pelo

procedure CHECK_OBJECT como danificados por software (ou logicamente) • DUMP_ORPHAN_KEYS: Informa entradas de índice em uma tabela-chave órfã que

apontam para linhas em blocos de dados danificados • REBUILD_FREELISTS: Reconstrói as freelists de um objeto • SEGMENT_FIX_STATUS: Permite corrigir o estado danificado de uma entrada de bitmap

quando o gerenciamento do espaço em segmento é definido como AUTO• SKIP_CORRUPT_BLOCKS: Ignora blocos marcados como danificados durante varreduras

de tabelas e índices. Se não for usado, você receberá o erro ORA-01578 quando encontrar blocos marcados como danificados.

• ADMIN_TABLES: Fornece funções administrativas (create, drop ou purge) para correção de tabelas-chave órfã. Essas tabelas são sempre criadas no esquema SYS.

Observação: As chaves-órfãs são entradas de índice que apontam para linhas de tabela não mais existentes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando o DBMS_REPAIR

1. Detecte e informe danos.

2. Avalie os custos e as vantagens do DBMS_REPAIR.

SET SERVEROUTPUT ONDECLARE num_corrupt INT;BEGINnum_corrupt := 0;DBMS_REPAIR.CHECK_OBJECT (

schema_name => 'HR',object_name => 'DEPARTMENTS',repair_table_name => 'REPAIR_TABLE',corrupt_count => num_corrupt);

END;

Usando o DBMS_REPAIR Sua primeira tarefa, antes de usar o DBMS_REPAIR, deve ser detectar e informar danos. Ao informar danos, você não apenas indica o que está errado com um bloco, mas também identifica a diretiva de correção associada. Depois de usar as opções apresentadas anteriormente nesta lição, você pode considerar o uso do package DBMS_REPAIR para corrigir o dano. O procedure CHECK_OBJECT verifica os objetos especificados e preenche uma tabela de correção com informações sobre danos e diretivas de correção. Antes de executar um procedure do DBMS_REPAIR, construa a tabela de correção usando o procedure ADMIN_TABLES:

BEGIN DBMS_REPAIR.ADMIN_TABLES (

table_name => 'REPAIR_TABLE', table_type => DBMS_REPAIR.REPAIR_TABLE, action => DBMS_REPAIR.CREATE_ACTION, tablespace => 'USERS');

END;

Antes de usar o DBMS_REPAIR, pondere as vantagens e as desvantagens de seu uso. Considere também outras opções disponíveis para corrigir objetos danificados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Usando o DBMS_REPAIR (continuação)Como primeira etapa, responda a estas perguntas:

• Qual é a extensão do dano? Para determinar se há danos e definir as ações de correção, execute o procedure CHECK_OBJECT e consulte a tabela de correção.

• Quais são as outras opções disponíveis para solucionar problemas de danos em blocos? • Quais são os danos lógicos e os efeitos colaterais resultantes do uso do DBMS_REPAIR

para tornar um objeto utilizável? É possível solucionar esses problemas satisfatoriamente? • Quando a correção envolve perda de dados, é possível recuperar os dados?

Você pode recuperar dados do índice quando um bloco de dados é marcado como danificado. O procedure DUMP_ORPHAN_KEYS pode ajudar a recuperar essas informações. Claro que a recuperação de dados dessa maneira depende do nível de redundância entre os índices e a tabela. O exemplo abaixo ilustra a criação de uma tabela-chave órfã para o tablespace USERS.

BEGIN DBMS_REPAIR.ADMIN_TABLES (

table_name => 'ORPHAN_KEY_TABLE', table_type => DBMS_REPAIR.ORPHAN_TABLE, action => DBMS_REPAIR.CREATE_ACTION, tablespace => 'USERS');

END;

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ





3. Torne os objetos utilizáveis.SET SERVEROUTPUT ONDECLARE num_fix INT;BEGINnum_fix := 0;DBMS_REPAIR.FIX_CORRUPT_BLOCKS (

schema_name => 'HR',object_name => 'DEPARTMENTS',object_type => DBMS_REPAIR.TABLE_OBJECT,repair_table_name => 'REPAIR_TABLE',fix_count => num_fix);

END;

Usando o DBMS_REPAIR (continuação) Para tornar o objeto utilizável, o DBMS_REPAIR ignora danos durante varreduras de tabelas e índices. Com os procedures FIX_CORRUPT_BLOCKS e SKIP_CORRUPT_BLOCKS, você pode tornar um objeto danificado utilizável estabelecendo um ambiente que ignore os danos fora do escopo dos recursos de correção do DBMS_REPAIR. Se os danos envolverem perda de dados, como uma linha incorreta em um bloco de dados, todos os blocos com esse problema serão marcados como danificados pelo procedure FIX_CORRUPT_BLOCKS. Então, você poderá executar o procedure SKIP_CORRUPT_BLOCKS, que ignora os blocos referentes ao objeto marcados como danificados. Quando esse procedure é definido, as varreduras de tabelas e índices ignoram todos os blocos marcados como danificados. Essa regra é aplicada a blocos com danos de mídia e software. Você pode ver se a regra está em vigor para uma tabela visualizando a coluna SKIP_CORRUPT da view de dicionário de dados DBA_TABLES. Se um índice e uma tabela não estiverem sincronizados, uma transação SET TRANSACTIONREAD ONLY poderá estar inconsistente em situações nas quais uma consulta verifica apenas o índice e, em seguida, outra consulta verifica o índice e a tabela. Se o bloco da tabela for marcado como danificado, as duas consultas retornarão resultados distintos, quebrando assim as regras de uma transação somente para leitura. Uma das maneiras de solucionar esse problema é não ignorar os danos contidos em uma transação SET TRANSACTION READ ONLY.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ





4. Corrija danos e reconstrua dados perdidos. SET SERVEROUTPUT ONDECLARE num_orphans INT;BEGINnum_orphans := 0;DBMS_REPAIR.DUMP_ORPHAN_KEYS (schema_name => 'SCOTT',object_name => 'PK_DEPT',object_type => DBMS_REPAIR.INDEX_OBJECT,repair_table_name => 'REPAIR_TABLE',orphan_table_name => 'ORPHAN_KEY_TABLE',key_count => num_orphans);

DBMS_OUTPUT.PUT_LINE('orphan key count: ' || TO_CHAR(num_orphans));

END;

Usando o DBMS_REPAIR (continuação) Depois de tornar um objeto utilizável, você poderá recuperar dados usando o procedure DUMP_ORPHAN_KEYS. Esse procedure informa entradas de índice que apontam para linhas em blocos de dados danificados. Todas essas entradas de índice são inseridas em uma tabela-chave órfã que armazena a chave e a ID de linha do dano. Crie a tabela-chave órfã com antecedência. Depois de recuperar as informações das entradas de índice, você poderá reconstruir esse índice usando a instrução ALTER INDEX ... REBUILD ONLINE.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




BMR (Block Media Recovery) Recuperação de mídia de bloco: • Reduz o MTTR (mean time to recover, tempo médio

para recuperação) • Aumenta a disponibilidade durante a recuperação de

mídia – O arquivo de dados permanece on-line durante a

recuperação. – Apenas os blocos em recuperação ficam inacessíveis.

• É chamada no RMAN por meio do comando BLOCKRECOVER. – Restaura blocos individuais de backups disponíveis – Faz a coordenação com o servidor para a recuperação

dos blocos de dados

BMR (Block Media Recovery) A BMR (Block Media Recovery, Recuperação de Mídia de Bloco) reduz a menor unidade recuperável da recuperação de mídia de um arquivo de dados a um bloco. Quando alguns blocos do banco de dados precisam de recuperação de mídia, é mais eficiente restaurar seletivamente e recuperar apenas esses blocos. Apenas os blocos em recuperação precisam ficar indisponíveis, o que permite a disponibilidade contínua do restante do banco de dados durante a recuperação. A BMR oferece duas vantagens principais sobre a recuperação em nível de arquivo:

• Reduz o MTTR (mean time to recover, tempo médio para recuperação) • Permite maior disponibilidade dos dados durante a recuperação de mídia, pois o arquivo de

dados em recuperação permanece on-line A BMR usa os mecanismos de recuperação existentes para aplicar alterações do fluxo de redo às versões dos blocos restaurados dos backups adequados. Use o RMAN para executar a BMR. O RMAN restaura blocos de dados individuais a partir de backups disponíveis e faz a coordenação com o processo do servidor Oracle para recuperar esses blocos. Sem a recuperação em nível de bloco, mesmo quando apenas um bloco é danificado, é necessário restaurar o arquivo inteiro e todos os dados de redo devem ser aplicados ao arquivo. A redução do MTTR obtida com o uso da recuperação em nível de bloco inclui o tempo de restauração e de recuperação. Observe que apenas a recuperação completa é possível. A recuperação incompleta torna o banco de dados logicamente inconsistente.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comando BLOCKRECOVER

O comando BLOCKRECOVER do RMAN: • Identifica os backups que contêm os blocos a serem

recuperados • Lê os backups e acumula os blocos necessários em

buffers de memória • Gerencia a sessão de recuperação de mídia de bloco

lendo os logs de arquivamento no backup, se necessário

• Não pode ser usado na recuperação incompleta

RMAN> BLOCKRECOVER DATAFILE 6 BLOCK 3;

Comando BLOCKRECOVERO RMAN suporta a BMR por meio do comando BLOCKRECOVER. Quando o usuário encontra um dano em algum bloco, a mensagem de erro, o log de alerta e os arquivos de rastreamento indicam qual bloco está causando o problema. O DBA pode chamar esse comando para restaurar apenas o bloco em questão, evitando um longo período de indisponibilidade de dados. O comando BLOCKRECOVER faz o seguinte:

• Identifica os backups dos quais é preciso obter os blocos para recuperação • Lê os backups e acumula os blocos necessários em buffers na memória. Se qualquer um

dos blocos necessários estiver danificado (danos lógicos ou de mídia), o RMAN lerá o próximo backup mais antigo do arquivo, buscando uma cópia íntegra do bloco. A opção UNTIL limita a seleção a conjuntos de backup ou cópias de arquivos obtidos até o horário, a seqüência de logs ou o SCN especificado; ela força o comando BLOCKRECOVER a usar um backup mais antigo em vez do mais recente.

• Inicia e gerencia a sessão de recuperação de mídia de bloco, lendo logs de arquivamento contidos no backup, se necessário

• Sempre executa a recuperação completa. Não é possível efetuar uma recuperação pontual com o comando BLOCKRECOVER.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Exemplos de Uso do Comando BLOCKRECOVER

• Recuperando um grupo de blocos danificados • Limitando a recuperação de mídia de bloco por tipo

de restauração • Limitando a recuperação de mídia de bloco por tag

de backup • Limitando a recuperação de mídia de bloco por

horário, SCN ou seqüência de log

Exemplos de Uso do Comando BLOCKRECOVER• Recuperando um grupo de blocos danificados

BLOCKRECOVER DATAFILE 2 BLOCK 12, 13 DATAFILE 7 BLOCK 5, 98, 99 DATAFILE 9 BLOCK 19;

• Este exemplo recupera uma série de blocos e executa a restauração apenas de cópias de arquivos de dados:

{ BLOCKRECOVER DATAFILE 3 BLOCK 1,2,3,4,5 TABLESPACE sales DBA 4194405, 4194409, 4194412 FROM DATAFILE COPY;

}

Observação: O DBA é o endereço do bloco de dados. • Limitando a BMR por tag de backup:

BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405 FROM TAG "weekly_backup";

• Este exemplo recupera dois blocos no tablespace SYSTEM e força a restauração dos blocos de backups criados, no mínimo, há dois dias:

BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404, 4194405 RESTORE UNTIL TIME 'SYSDATE-2';

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Exemplos de Uso do Comando BLOCKRECOVER (continuação)• Este exemplo recupera dois blocos e força a restauração dos blocos a partir de backups

feitos antes do SCN 100: BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE UNTIL SCN 100;

• Este exemplo recupera dois blocos e força a restauração dos blocos a partir de backups feitos antes da seqüência de log 7024:

BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE UNTIL SEQUENCE 7024;

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




A Interface do RMAN BMR

Views dinâmicas mostram o estado atual do dano. • A view V$DATABASE_BLOCK_CORRUPTION mostra a

lista de blocos do banco de dados danificados nomomento.

• A view V$BACKUP_CORRUPTION mostra a lista deblocos danificados em backups de arquivos de dados.

• A view V$COPY_CORRUPTION mostra a lista deblocos danificados em cópias de arquivos deimagens.

RMAN> BLOCKRECOVER CORRUPTION LIST2> RESTORE UNTIL TIME 'sysdate – 10';

A Interface do RMAN BMR Com a cláusula CORRUPTION LIST, você pode recuperar os blocos listados em V$DATABASE_BLOCK_CORRUPTION. Essa view é preenchida durante uma operação de backup, à medida que são encontrados blocos danificados. Se o backup encontrar uma quantidade maior que a tolerada de blocos danificados, a view não será preenchida. Você deve executar o comando BACKUP…VALIDATE para preencher completamente essa view com um registro de todos os blocos danificados. Após a correção de um bloco por meio da recuperação de mídia de bloco (ou da recuperação de mídia normal), V$DATABASE_BLOCK_CORRUPTION só será atualizada depois que você fizer um novo backup. A cláusula UNTIL especifica que somente os backups e as cópias criados antes do horário, do SCN ou do número de seqüência de log especificado devem ser restaurados e usados na recuperação. Mesmo assim, o RMAN executará uma recuperação completa até a data atual. Dois tipos de danos resultam na inclusão de linhas em V$BACKUP_CORRUPTION e V$COPY_CORRUPTION pelos comandos BACKUP e COPY, respectivamente:

• Danos físicos (chamados às vezes de danos de mídia): O servidor Oracle não reconhece o bloco: o checksum é inválido, o bloco contém apenas zeros ou o cabeçalho e o rodapé do bloco são incompatíveis. A verificação de danos físicos é definida como ON por default e pode ser desativada com a opção NOCHECKSUM.

• Danos lógicos: O bloco tem um checksum válido, o cabeçalho e o rodapé são compatíveis, e assim por diante, mas o conteúdo é inconsistente do ponto de vista lógico. A verificação lógica é definida como OFF por default e pode ser ativada com a opção CHECK LOGICAL.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Ações Alternativas

• Tabela: Os dados do bloco danificado são perdidos.– Elimine e recrie a tabela. Em seguida, importe os

dados de um dump de exportação. – Use SQL ou PL/SQL a fim de extrair dados da tabela

para uma tabela criada recentemente.• Índice: Elimine e recrie o índice.

Ações Alternativas Se você não planeja restaurar arquivos de dados e recuperá-los, use a instrução a seguir para determinar o objeto que contém blocos danificados. Você pode obter o número absoluto do arquivo (por exemplo, 5) e do bloco (por exemplo, 2) na mensagem de erro, como em:

ORA-01578: ORACLE data block corrupted (file #5, block # 2)

Execute o seguinte comando: SQL> SELECT segment_name, segment_type, relative_fno

2 FROM dba_extents3 WHERE file_id = 54 AND 2 BETWEEN block_id AND block_id + blocks - 1;

SEGMENT_NAME SEGMENT_TYPE RELATIVE_FNO-------------- --------------- ------------EXAMPLE TABLE PARTITION 5

Após identificar o objeto danificado, você tem outras opções disponíveis para recuperá-lo. Se for uma tabela, você poderá usar um arquivo de dump de exportação. Você também poderá usar SQL para gerar uma tabela correta a partir de uma tabela danificada. Essa recuperação pode exigir conhecimento dos dados de negócios. Caso o índice esteja danificado, talvez seja melhor simplesmente eliminá-lo e recriá-lo.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a:• Identificar os motivos de danos em bancos de dados:

– Hardware – Software

• Detectar danos em bancos de dados usando: – ANALYZE

– dbverify

– DB_BLOCK_CHECKING

– DBMS_REPAIR

• Corrigir danos usando o RMAN

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício:Executar uma Recuperação de Mídia de Bloco

Este exercício aborda os seguintes tópicos:• Detecção de danos • Identificação do local do dano • Recuperação do dano usando a recuperação de

mídia de bloco

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Monitorando e Gerenciando a Memória

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Descrever os componentes da memória na SGA• Implementar o Gerenciamento Automático da

Memória Compartilhada • Configurar manualmente os parâmetros da SGA• Configurar o gerenciamento automático da memória

PGA

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciamento de Memória: Visão Geral

O DBA deve considerar o gerenciamento de memória como parte essencial de seu trabalho porque: • O volume de memória disponível é finito• A alocação de mais memória para atender a certos

tipos de funções pode melhorar o desempenho geral• A alocação de memória ajustada automaticamente é,

com freqüência, a configuração adequada, mas ambientes específicos ou até mesmo condições decurto prazo podem exigir mais atenção

Gerenciamento de Memória: Visão Geral Como o volume de memória disponível em um servidor de banco de dados, e portanto em uma instância do banco de dados Oracle, é finito, preste atenção na forma como a memória é alocada. Se um volume muito grande de memória for usado em uma área específica que não precise desse volume, provavelmente existirão outras áreas funcionais operando desnecessariamente sem memória suficiente para alcançar o desempenho ideal. A capacidade de determinar e manter automaticamente a alocação de memória simplifica muito seu trabalho. No entanto, a memória ajustada automaticamente também precisa ter sua otimização monitorada e pode necessitar de configuração manual. Além da introdução ao ajuste de memória apresentado no curso Oracle Database 10g: Workshop de Administração I, esta lição descreve o funcionamento do ajuste automático de memória, quando fazer o ajuste manual, o que é a PGA (Program Global Area) e os detalhes sobre cada estrutura de memória em uma instância Oracle.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Estruturas de Memória Oracle

SGA

Java pool Cache de bufferdo banco de dados

Shared pool

Buffer deredo log

Large poolStreams pool

Processodo servidor

1PGA

Processodo servidor

2PGA

Processode

backgroundPGA

Keep buffer cache

Recycle buffer cache

Caches de buffer comtamanho de bloco nK

Estruturas de Memória Oracle As estruturas de memória básicas associadas a uma instância Oracle incluem:

• SGA (System Global Area): Compartilhada por todos os processos do servidor e de background

• PGA (Program Global Area): Exclusiva para cada servidor e processo de background. Há uma PGA para cada processo

A SGA (System Global Area) é uma área de memória compartilhada que contém dados e informações de controle para a instância, incluindo o seguinte:

• Cache de buffer do banco de dados: Armazena no cache blocos de dados recuperados do disco

• Buffer de redo log: Armazena no cache informações de redo até que elas possam ser gravadas em disco

• Shared pool: Armazena no cache várias estruturas que podem ser compartilhadas pelos usuários

• Large pool: Área opcional usada como buffer de grandes solicitações de entrada/saída para suporte a consulta paralela, servidor compartilhado, Oracle XA e certos tipos de operações de backup

• Java pool: Armazena os códigos Java específicos da sessão e dados da JVM (Java Virtual Machine)

• Streams pool: Usado pelo Oracle Streams

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Estruturas de Memória Oracle (continuação)• Keep buffer cache: Armazena os dados no cache de buffer pelo maior período possível • Recycle buffer cache: Armazena dados que expiram rapidamente no cache de buffer • Caches de buffer com tamanho de bloco nK: Armazena no cache os blocos de dados

de tamanho diferente do tamanho default dos blocos do banco de dados; usado para suporte a tablespaces transportáveis

É possível ajustar automaticamente o tamanho do cache de buffer do banco de dados, shared pool, large pool, streams pool e Java pool para atender às necessidades atuais. Além disso, esses buffers de memória, junto com o keep buffer cache, o recycle buffer cache e os caches de buffer com tamanho de bloco nK podem ser alterados sem shutdown da instância. O banco de dados pré-configurado foi ajustado previamente com as definições adequadaspara os parâmetros de memória. No entanto, como a utilização do banco de dados é expansível, talvez seja necessário alterar as definições dos parâmetros de memória. O banco de dados Oracle fornece alertas e advisors para identificar problemas de dimensionamento de memória, com o objetivo de ajudá-lo a determinar os valores apropriados para os parâmetros de memória. A PGA (Program Global Area) é uma região da memória que contém informações de controle e dados de cada processo do servidor. O processo do servidor atende às solicitações de um cliente. Cada processo do servidor tem a sua própria PGA privada, criada quando o processo do servidor é iniciado. O acesso a ela é exclusivo a esse processo do servidor. O volume da memória PGA usado e o conteúdo dessa memória dependem da configuração ou não da instância no modo de servidor compartilhado. Geralmente, a PGA contém o seguinte:

• Área privada para SQL: Contém dados, como as informações de bind e as estruturas de memória de runtime. Cada sessão que executa uma instrução SQL tem uma área privada para SQL.

• Memória de sessão: Memória alocada para reter as variáveis de uma sessão e outras informações relativas a essa sessão

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Cache de Buffer

Arquivos de dados

SGAFila de

checkpoints

....

DBWn

Servidor

DB_BLOCK_SIZE

DB_CACHE_SIZE

DB_RECYCLE_CACHE_SIZE

DB_KEEP_CACHE_SIZE

Listas LRU

....

Cache de buffer do banco de dados

Cache de Buffer Para configurar o cache de buffer, especifique um valor para o parâmetro DB_CACHE_SIZE. O cache de buffer armazena cópias dos blocos de dados dos arquivos de dados com tamanho de bloco DB_BLOCK_SIZE. O cache de buffer faz parte da SGA. Portanto, todos os usuários podem compartilhar esses blocos. Os processos do servidor lêem dados dos arquivos de dados no cache de buffer. Às vezes, para melhorar o desempenho, o processo do servidor lê vários blocos em uma única operação. O processo DBWn grava dados do cache de buffer nos arquivos de dados. Para melhorar o desempenho, o DBWn grava vários blocos em uma única operação. Em determinado momento, o cache de buffer poderá armazenar várias cópias de um único bloco de banco de dados. Existe apenas uma cópia atual do bloco, mas, para atender às consultas, talvez os processos do servidor precisem criar cópias com leitura consistente a partir de informações de imagens passadas. Isso se chama bloco de leitura consistente (CR). A lista LRU (least recently used, menos usado recentemente) monitora o uso de buffers. Os buffers são classificados segundo uma combinação da freqüência com que foram referenciados e da última vez em que a referência ocorreu. Assim, os buffers usados com mais freqüência e por último ficam localizados na extremidade usada mais recentemente. Os blocos recebidos são copiados da extremidade menos usada recentemente para um buffer, que é então atribuído ao meio da lista, como ponto inicial. Depois disso, o buffer sobe ou desce na lista dependendo do uso.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Cache de Buffer (continuação)Os buffers do cache de buffer podem estar em um destes quatro estados:

• Pinned: O bloco está sendo lido ou gravado no cache no momento. As outras sessões terão que esperar para acessar o bloco.

• Clean: O buffer está livre e expirará imediatamente se o conteúdo atual (bloco de dados) não for referenciado novamente. O conteúdo está em sincronia com o disco, ou o buffer contém um snapshot CR de um bloco.

• Free/unused: O buffer está vazio porque a instância acabou de ser inicializada. Este estado é muito parecido com o estado Clean; a única diferença é que, neste caso, o buffer não foi usado.

• Dirty: O buffer não está mais retido, mas o conteúdo (bloco de dados) foi alterado e deve ser descarregado em disco pelo DBWn antes de expirar.

Os processos do servidor usam os buffers contidos no cache de buffer, mas o processo DBWn os disponibiliza gravando os buffers alterados novamente nos arquivos de dados. A fila de checkpoint lista os buffers que devem ser gravados no disco. O banco de dados Oracle suporta vários tamanhos de blocos no mesmo banco de dados. O tablespace SYSTEM usa o tamanho de bloco padrão. Para especificar o tamanho de bloco padrão, defina o parâmetro de inicialização DB_BLOCK_SIZE. Os valores legítimos variam de 2K a 32K, sendo 8K o default. Os tamanhos dos caches para buffers de blocos de tamanho não-padrão são especificados por estes parâmetros:

• DB_2K_CACHE_SIZE • DB_4K_CACHE_SIZE • DB_8K_CACHE_SIZE • DB_16K_CACHE_SIZE • DB_32K_CACHE_SIZE

Não é possível usar os parâmetros DB_nK_CACHE_SIZE a fim de dimensionar o cache para o tamanho de bloco padrão. Se o valor de DB_BLOCK_SIZE for nK, a definição de DB_nK_CACHE_SIZE não será aceita. O tamanho do cache para blocos de tamanho padrão é sempre determinado com base no valor de DB_CACHE_SIZE. Um cache de buffer tem um tamanho limitado; portanto, ele geralmente não pode conter todos os dados de um disco. Quando o cache estiver cheio, os cache misses subseqüentes farão com que o banco de dados Oracle grave dados sujos já contidos no cache em disco a fim de liberar espaço para novos dados. (Se um buffer não estiver sujo, não será necessário gravá-lo em disco antes da leitura de um novo bloco no buffer.) O acesso posterior aos dados gravados em disco resulta em outros cache misses. O tamanho do cache afeta a probabilidade de que uma solicitação de dados resulte em um cache hit. Se o cache for grande, é mais provável que contenha os dados solicitados. Com o aumento do tamanho de um cache, cresce o percentual de solicitações de dados que resultam em cache hits.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando Vários Pools de Buffers

SGACaches de buffer

do banco de dados

Keep pool

Recycle pool

Pool default

Usando Vários Pools de Buffers O administrador do banco de dados (DBA) talvez possa melhorar o desempenho do cache de buffer do banco de dados criando vários pools de buffers. Os objetos são atribuídos a um pool de buffers dependendo da maneira como eles são acessados. Há três pools de buffers:

• Keep: Este pool é usado para manter na memória os objetos que talvez venham a ser reutilizados. Com esses objetos na memória, as operações de entrada/saída são reduzidas. Os buffers são mantidos neste pool, que deverá ser maior que o tamanho total dos segmentos atribuídos a ele. Isso significa que os buffers não precisam estar obsoletos. Para configurar o keep pool, especifique um valor para o parâmetro DB_KEEP_CACHE_SIZE.

• Recycle: Este pool é usado para blocos da memória com pouca probabilidade de reutilização. O recycle pool é menor que o tamanho total dos segmentos atribuídos a ele. Isso significa que, com freqüência, os blocos lidos no pool têm de ser eliminados de um buffer. Para configurar o recycle pool, especifique um valor para o parâmetro DB_RECYCLE_CACHE_SIZE.

• Default: Este pool sempre existe. Ele é equivalente ao cache de buffer de uma instância sem um keep pool ou recycle pool. Para configurá-lo, use o parâmetro DB_CACHE_SIZE.

Observação: A memória no keep pool ou recycle pool não é um subconjunto do pool de buffers default.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando Vários Pools de Buffers

CREATE INDEX cust_idx … STORAGE (BUFFER_POOL KEEP …);

ALTER TABLE oe.customers STORAGE (BUFFER_POOL RECYCLE);

ALTER INDEX oe.cust_lname_ix STORAGE (BUFFER_POOL KEEP);

Usando Vários Pools de Buffers (continuação) A cláusula BUFFER_POOL é usada para definir o pool de buffers default de um objeto. Ela faz parte da cláusula STORAGE e é válida para as instruções CREATE e ALTER de índices, clusters e tabelas. Os blocos de um objeto sem um pool de buffers definido explicitamente vão para o pool de buffers default. A sintaxe é BUFFER_POOL [KEEP | RECYCLE | DEFAULT]. Quando o pool de buffers default de um objeto é alterado por meio da instrução ALTER, os blocos já armazenados no cache permanecem nos buffers atuais até que sejam descarregados pela atividade normal de gerenciamento de cache. Os blocos lidos do disco são colocados no pool de buffers recém-especificado para o segmento.Como os pools de buffers são atribuídos a um segmento, os objetos que possuem vários segmentos podem ter blocos em vários pools de buffers. Por exemplo, uma tabela organizada por índice pode ter diferentes pools definidos no índice e no segmento de overflow.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Shared pool

Cache debiblioteca

Cache dedicionário de

dados

UGA

Shared poolShared pool

Shared Pool • O tamanho é especificado pelo uso de

SHARED_POOL_SIZE. • O cache de biblioteca contém o texto da instrução, o

código analisado por parse e o plano de execução. • O cache de dicionário de dados contém definições

de tabelas, colunas e privilégios das tabelas de dicionário de dados.

• A UGA (User Global Area) contém informações da sessão quando o servidor compartilhado Oracle é usado.

Shared Pool Você pode especificar o tamanho do shared pool com o parâmetro de inicialização SHARED_POOL_SIZE. O shared pool é uma área da memória que armazena informações compartilhadas por diversas sessões. Ele contém tipos diferentes de dados, conforme mostrado no slide. Cache de Biblioteca O cache de biblioteca contém áreas para SQL e PL/SQL compartilhadas – as representações de blocos PL/SQL e as instruções SQL totalmente compiladas ou analisadas por parse. Os blocos PL/SQL incluem:

• Procedures e functions • Packages • Triggers • Blocos PL/SQL anônimos

Cache de Dicionário de Dados O cache de dicionário de dados mantém definições dos objetos de dicionário na memória. Área Global do Usuário A UGA (User Global Area, Área Global do Usuário) contém as informações sobre as sessões do servidor compartilhado Oracle. Ela está localizada no shared pool quando é usada uma sessão do servidor compartilhado e quando o large pool não está configurado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Shared poolCache de buffer

do banco de dadosBuffer deredo log

Large pool

Large Pool • Pode ser configurado como uma área separada da

memória na SGA • É dimensionado pelo parâmetro LARGE_POOL_SIZE• É usado no armazenamento de dados na memória para:

– UGA – Operações de backup e restauração – Sessões dos servidores compartilhados – Mensagens de consulta paralela

Cache de biblioteca

Cache de dicionário

UGA Backup

Sessão

Paralelo

Large Pool Existência do Large Pool O large pool deve ser explicitamente configurado. A memória do large pool não vem do shared pool. Ela é obtida diretamente da SGA, aumentado assim o volume de memória compartilhada de que o servidor Oracle necessita para uma instância durante a inicialização. Vantagens do Large Pool O large pool é usado para permitir grandes alocações de memória da sessão para:

• Processos do servidor de entrada/saída • Operações de backup e restauração • Processos do servidor compartilhado Oracle e a interface Oracle XA (usada quando há

interação entre as transações e mais de um banco de dados) Alocando memória de sessão do large pool para o servidor compartilhado Oracle, o shared pool apresenta fragmentação inferior à resultante de alocações e desalocações freqüentes de grandes objetos. A retirada de grandes objetos do shared pool resulta em maior eficiência no uso desse pool, o que significa maior disponibilidade de memória para atender a novas solicitações e reter os dados existentes, se necessário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Java Pool

• Pode ser configurado como uma área separada da memória na SGA

• É dimensionado pelo parâmetro JAVA_POOL_SIZE• É usado para armazenar na memória todos os

códigos Java específicos da sessão e dados da JVM Shared pool


Buffer deredo log

Large poolCache de biblioteca

Cache de dicionário Java pool

Java Pool O Java pool é uma estrutura da SGA usada para armazenar todos os códigos Java específicos da sessão e dados do Java engine. Shared PoolA memória do shared pool é usada pelo carregador de classes na JVM. Esse carregador usa cerca de8 KB de memória por classe carregada. O shared pool também é usado durante a compilação do código-fonte Java ou a utilização de objetos de recursos Java no banco de dados. A memória do shared pool também é consumida quando você cria especificações de chamadas e enquanto o sistema rastreia dinamicamente as classes Java carregadas no runtime. Java PoolO gerenciador de memória do Oracle JVM aloca todos os outros estados Java durante o runtime do Java pool, incluindo a representação na memória compartilhada das definições de classes e métodos Java, bem como os objetos Java migrados para o espaço da sessão no final da chamada. A memória do Java pool é usada de maneiras diferentes, dependendo da utilização ou não de servidores compartilhados pelo banco de dados Oracle. Para obter mais informações sobre o uso da memória do Java pool, consulte o Oracle Database Java Developer’s Guide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Buffer de Redo Log

SQL> UPDATE employees

2 SET salary=salary*1.1

3 WHERE employee_id=736;

LGWRArquivos de controle

ARCn

Arquivos de logarmazenadosArquivos

de redo log

Arquivosde dados

Shared poolBuffer deredo log

Cache de bufferdo banco de dados Cache de biblioteca

Cache de dicionário

Processo doservidor

Buffer de Redo Log Os processos do servidor Oracle copiam entradas de redo do espaço da memória do usuário para o buffer de redo log em relação a cada instrução DML (data manipulation language) ou DDL (data definition language). As entradas de redo contêm as informações necessárias para recriar ou refazer alterações efetuadas no banco de dados pelas operações DML e DDL. Elas são usadas para a recuperação de bancos de dados e ocupam espaço seqüencial contínuo no buffer. O buffer de redo log é um buffer circular; os processos do servidor podem copiar novas entradas sobre as entradas do buffer de redo log que já tiverem sido gravadas no disco. Em geral, o LGWR grava com rapidez suficiente para garantir que haja sempre espaço disponível no buffer para novas entradas. O processo LGWR grava as entradas do buffer de redo log no arquivo de redo log on-line ativo (ou em membros do grupo ativo) no disco. Esse processo copia para o disco todas as entradas de redo inseridas no buffer desde a última vez que o LGWR gravou no disco. O Que Faz o LGWR Gravar? O LGWR esvaziará os dados de redo do buffer de redo log:

• Quando um processo do usuário submeter uma transação a commit • A cada três segundos ou quando o buffer de redo log estiver com um terço de sua

capacidade ocupada ou contiver pelo menos 1 MB de dados • Quando um processo DBWn gravar buffers modificados no disco, se os dados de redo log

correspondentes ainda não tiverem sido gravados no disco

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciamento Automático da Memória Compartilhada: Visão Geral

• Adapta-se automaticamente a alterações de carga de trabalho

• Maximiza a utilização da memória• Ajuda a eliminar erros de falta de memória

Cache de buffer

Large pool

Shared pool

Java pool

Cache de buffer

Large pool

Shared pool

Java pool

Usuários on-line Jobs batch

Streams pool Streams pool

Exemplo:

Gerenciamento Automático da Memória Compartilhada: Visão Geral O ASMM (Automatic Shared Memory Management) é outra melhoria importante de auto-gerenciamento do banco de dados Oracle. Essa funcionalidade automatiza o gerenciamento das estruturas de memória compartilhada mais importantes usadas por uma instância do banco de dados Oracle e evita que você precise configurar esses componentes manualmente. Além de usar a memória disponível com mais eficiência e, dessa forma, reduzir o custo de aquisição de recursos adicionais de memória de hardware, o ASMM simplifica bastante a administração do banco de dados Oracle apresentando um esquema de gerenciamento de memória mais dinâmico, flexível e adaptável. Por exemplo, em um sistema que executa jobs OLTP (Online Transactional Processing) grandes durante o dia (que requerem um grande cache de buffer) e executa jobs batch paralelos à noite (que requerem um valor alto para o large pool), você precisa configurar simultaneamente o cache de buffer e o large pool para acomodar seus requisitos de pico. Com o ASMM, quando o job OLTP é executado, o cache de buffer captura a maior parte da memória para permitir um desempenho satisfatório de entrada/saída. Quando o job batch de análise de dados e geração de relatório é iniciado posteriormente, a memória é migrada de forma automática para o large pool, a fim de ser usada por operações de consulta paralela sem produzir erros de overflow de memória.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Vantagens do Gerenciamento Automáticoda Memória Compartilhada

DB_CACHE_SIZESHARED_POOL_SIZELARGE_POOL_SIZEJAVA_POOL_SIZESTREAMS_POOL_SIZE

Tamanho total da SGA

SGA_TARGET

Vantagens do Gerenciamento Automático da Memória Compartilhada O Gerenciamento Automático da Memória Compartilhada simplifica a configuração da SGA (System Global Area). No passado, era preciso especificar manualmente o volume de memória a ser alocado para o cache de buffer do banco de dados, o shared pool, o Java pool, o large pool e o Streams pool. Com freqüência, a definição do tamanho ideal para esses componentes é um desafio. O subdimensionamento pode levar a um desempenho insatisfatório e a erros de insuficiência de memória (ORA-4031), enquanto o superdimensionamento pode desperdiçar memória. Esse recurso permite especificar um volume total de memória a ser usado para todos os componentes da SGA. O banco de dados Oracle redistribui periodicamente a memória entre os componentes no slide de acordo com os requisitos de carga de trabalho. Em releases anteriores, você não tinha controle preciso sobre o tamanho total da SGA porque a distribuição de memória era feita para a SGA fixa e para outras alocações internas de metadados acima do tamanho total dos parâmetros da SGA especificados pelo usuário. Em geral, essa memória adicional era de 10 MB a 20 MB. O parâmetro de inicialização de tamanho da SGA (SGA_TARGET) compreende toda a memória na SGA, inclusive os componentes dimensionados automaticamente, os componentes dimensionados manualmente e as alocações internas durante a inicialização.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Como Funciona o ASMM

• O ASMM baseia-se em informações de carga de trabalho capturadas pelo MMAN em background.

• O MMAN usa advisors de memória. • A memória é movida para o local em que ela é mais

necessária. • Se for usado um SPFILE (o que é recomendado):

– Os tamanhos dos componentes serão salvos entre shutdowns.

– Os valores salvos serão usados para fazer bootstrap do tamanho dos componentes.

– Não será necessário reaprender os valores ideais.

Como Funciona o ASMM O recurso Gerenciamento Automático da Memória Compartilhada usa um processo de background chamado MMAN (Memory Manager). O MMAN funciona como o gerenciador da memória SGA e coordena o dimensionamento dos componentes da memória. Esse gerenciador acompanha o tamanho dos componentes e as operações pendentes de redimensionamento. O controlador da memória SGA observa o sistema e a carga de trabalho para determinar a distribuição ideal de memória. Ele nunca é complacente e executa essa verificação periodicamente (a um intervalo de alguns minutos), a fim de que a memória possa sempre estar presente quando necessário. Antes do Gerenciamento Automático da Memória Compartilhada, era necessário dimensionar os componentes prevendo os requisitos individuais de memória nos casos mais graves. Com base nas informações de carga de trabalho, o Gerenciamento Automático da Memória Compartilhada:

• Captura periodicamente as estatísticas em background • Usa advisors de memória • Executa análises de hipóteses para determinar a melhor distribuição da memória • Transfere a memória para o local em que ela é mais necessária • Salva os tamanhos dos componentes entre shutdowns caso seja usado um SPFILE (é

possível recuperar os tamanhos anteriores ao último shutdown)

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Configurando o ASMM com oDatabase Control

Configurando o ASMM com o Database Control Para configurar o Gerenciamento Automático de Memória Compartilhada com o Database Control, siga este procedimento:

1. Clique na tab Administration. 2. Selecione Memory Parameters no cabeçalho Instance. 3. Clique na tab SGA. 4. Clique no botão Enable relativo a Automatic Shared Memory Management e informe o

tamanho total da SGA (em MB). Quando você usa o Database Control para ativar o ASMM, as instruções para alterar os parâmetros auto-ajustáveis são emitidas automaticamente. Todos esses parâmetros, exceto DB_CACHE_SIZE, são definidos como zero para indicar que não têm um tamanho mínimo. O parâmetro DB_CACHE_SIZE é definido como 4 MB para especificar um valor mínimo que permita ao tablespace SYSTEM residir na memória. Sem essas mudanças, os valores anteriormente definidos serão interpretados como tamanhos mínimos (relativamente altos), o que é bem provável que sobrecarregue sem necessidade o algoritmo de dimensionamento de memória. Observação: Ao clicar em Enable, você pode especificar um valor para SGA_TARGET.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Configurando o ASMM Manualmente

Para atribuir tamanhos mínimos a alguns componentes da memória, será necessário configurar manualmente esses tamanhos:• Se, por qualquer motivo, os tamanhos calculados

automaticamente não servirem aos seus propósitos

• Se houver pequenas altas ou baixas no volume de memória necessária não detectadas pelo ASMM

• Se você simplesmente quiser garantir um volume mínimo de memória para um componente específico

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Configurando o ASMM Manualmente

SGA_TARGET = 8G

Tamanho total da SGA = 8 GB

Java pool


Buffer deredo logShared pool

Large poolSGA fixa

STATISTICS_LEVEL = TYPICAL

Auto-ajustável Auto-ajustável

Auto-ajustávelAuto-ajustável

Streamspool

Pool debuffers keep

Auto-ajustável

Configurando o ASMM Manualmente Você pode configurar manualmente o Gerenciamento Automático da Memória Compartilhada usando o parâmetro de inicialização SGA_TARGET. Por default, esse parâmetro é definido como 0. Esse valor significa que o Gerenciamento Automático da Memória Compartilhada está desativado e é necessário configurar manualmente a memória do banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Configurando o ASMM Manualmente (continuação)Caso você especifique um valor diferente de zero para SGA_TARGET, estes cinco pools de memória serão automaticamente dimensionados: cache de buffer do banco de dados (pool default), shared pool, large pool, Streams pool e Java pool. Os parâmetros usados para configurar esses pools de memória (por exemplo, SHARED_POOL_SIZE) são denominados parâmetros auto-ajustáveis. Estes buffers são conhecidos como componentes manualmente dimensionados:

• Buffer de log • Outros caches de buffer (KEEP/RECYCLE, tamanhos de bloco diferentes do default) • SGA fixa e outras alocações internas

Observação: O Gerenciamento Automático da Memória Compartilhada exige que o parâmetro STATISTICS_LEVEL seja definido como TYPICAL ou ALL.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comportamento de ParâmetrosAuto-ajustáveis da SGA

• Quando SGA_TARGET não é definido ou é igual a zero: – Os parâmetros auto-ajustáveis apresentam

comportamento normal – Talvez seja necessário aumentar a definição de

SHARED_POOL_SIZE em relação aos valores usados em versões anteriores do banco de dados.

• Quando SGA_TARGET é definido como um valor diferente de zero: – O valor default dos parâmetros auto-ajustáveis é zero – O valor especificado é usado como um tamanho mínimo

SELECT SUM(bytes)/1024/1024 size_mb FROM v$sgastat WHERE pool = 'shared pool';

SELECT component, current_size/1024/1024 size_mb FROM v$sga_dynamic_components;

Comportamento de Parâmetros Auto-ajustáveis da SGA Quando o valor de SGA_TARGET não é definido ou é igual a zero, os parâmetros auto-ajustáveis da SGA apresentam comportamento normal: eles especificam o tamanho real dos componentes. Quando o Gerenciamento Automático da Memória Compartilhada está ativado, você pode especificar valores para os parâmetros auto-ajustáveis da SGA, mas os valores têm um significado diferente. Se você definir algum dos parâmetros auto-ajustáveis como um valor diferente de zero, o valor especificado será usado como um limite inferior pelo algoritmo de auto-ajuste. Por exemplo, se SGA_TARGET for definido como 8 GB e SHARED_POOL_SIZE, como 1 GB, o algoritmo do Gerenciamento Automático da Memória Compartilhada só comprimirá o shared pool até 1 GB. Use a segunda consulta indicada no slide para determinar o tamanho real dos componentes auto-ajustáveis na SGA.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comportamento de Parâmetros da SGAAjustados Manualmente

• Alguns componentes não são auto-ajustáveis. – Caches de buffer KEEP e RECYCLE– Caches com diferentes tamanhos de bloco – Buffer de log

• É necessário configurar esses componentes manualmente usando os parâmetros do banco de dados.

• A memória usada por esses componentes reduz o volume de memória disponível para o auto-ajusteda SGA.

Comportamento de Parâmetros da SGA Ajustados Manualmente Os parâmetros da SGA ajustados manualmente são:

• DB_KEEP_CACHE_SIZE • DB_RECYCLE_CACHE_SIZE • DB_nK_CACHE_SIZE (n = 2, 4, 8, 16, 32) • LOG_BUFFER

Para usar componentes da memória que não são auto-ajustáveis, configure os parâmetros apropriados. Os valores especificados para esses parâmetros controlam com precisão os tamanhos dos componentes da memória. Quando SGA_TARGET for definido, o tamanho total dos parâmetros manuais de dimensionamento da SGA será subtraído do valor de SGA_TARGET. Além disso, os componentes auto-ajustáveis da SGA serão submetidos a um balanceamento. Por exemplo, se SGA_TARGET for definido como 8 GB e DB_RECYCLE_CACHE_SIZE como 1 GB, o tamanho total dos cinco componentes auto-ajustáveis (shared pool, Java pool, cache de buffer default, Streams pool e large pool) será limitado a 7 GB. O tamanho de 7 GB inclui a SGA fixa e o buffer de log e, só depois que for alocada memória para eles, o restante da memória será dividido entre os componentes auto-ajustáveis. O tamanho do cache recycle é 1 GB, conforme especificado pelo parâmetro.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando a View V$PARAMETER

SGA_TARGET = 8G

SELECT name, value, isdefault FROM v$parameterWHERE name LIKE '%size';

DB_CACHE_SIZE = 0JAVA_POOL_SIZE = 0LARGE_POOL_SIZE = 0SHARED_POOL_SIZE = 0STREAMS_POOL_SIZE = 0

Usando a View V$PARAMETERQuando você especificar um valor diferente de zero para SGA_TARGET e não especificar um valor para um parâmetro auto-ajustável da SGA, o valor do parâmetro auto-ajustável da SGA na view V$PARAMETER será 0, enquanto o valor da coluna ISDEFAULT será TRUE. Se você tiver especificado um valor para qualquer um dos parâmetros auto-ajustáveis da SGA, o valor exibido durante a consulta de V$PARAMETER será o valor definido para o parâmetro. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Modificando o Parâmetro SGA_TARGET

• O parâmetro de inicialização SGA_TARGET:– É dinâmico– Pode ser aumentado até o valor de SGA_MAX_SIZE– Pode ser reduzido até que todos os componentes

atinjam o tamanho mínimo• Uma alteração no valor de SGA_TARGET afeta

somente os componentes dimensionados automaticamente.

Modificando o Parâmetro SGA_TARGETSGA_TARGET é um parâmetro dinâmico que pode ser alterado por meio do Database Control ou com o comando ALTER SYSTEM. SGA_MAX_SIZE é o volume máximo de memória que pode se alocado para a SGA. Ele não pode ser modificado sem a reinicialização do banco de dados. É possível aumentar o valor desse parâmetro até atingir o valor de SGA_MAX_SIZE. Também é possível reduzi-lo até que qualquer um dos componentes auto-ajustáveis atinja seu tamanho mínimo: um mínimo especificado pelo usuário ou um mínimo determinado internamente.

• Se você aumentar o valor do parâmetro SGA_TARGET, a memória adicional será distribuída de acordo com a política de auto-ajuste entre os componentes auto-ajustáveis.

• Se você reduzir o valor desse parâmetro, a memória será retirada pela política de auto-ajuste de um ou mais componentes auto-ajustáveis.

Suponha que SGA_MAX_SIZE seja definido como 10 GB e SGA_TARGET, como 8 GB. Se DB_KEEP_CACHE_SIZE for definido como 1 GB e você aumentar o valor de SGA_TARGETpara 9 GB, o 1 GB adicional será distribuído apenas entre os componentes controlados pelo parâmetro SGA_TARGET. O valor de DB_KEEP_CACHE_SIZE não será afetado. Da mesma forma, se SGA_TARGET for reduzido para 7 GB, o 1GB só será retirado dos componentes controlados por SGA_TARGET. Essa redução não afeta as definições dos parâmetros controlados manualmente, como DB_KEEP_CACHE_SIZE.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tamanho daSGA = 8 GB

Desativando o ASMM

• A definição de SGA_TARGET como zero desativa o auto-ajuste.

• Os parâmetros auto-ajustáveis são definidos como os respectivos tamanhos atuais.

• O tamanho da SGA como um todo não é afetado.

Parâmetros:sga_target = 8G

shared_pool_size = 1G

Parâmetros:sga_target = 0

db_cache_size = 5G

shared_pool_size = 2G

large_pool_size = 512M

java_pool_size = 256M

streams_pool_size = 256M

Tamanho daSGA = 8 GB

Valores originais

Desativando o ASMM Você pode optar dinamicamente por desativar o Gerenciamento Automático da Memória Compartilhada definindo SGA_TARGET como zero. Nesse caso, os valores de todos os parâmetros auto-ajustáveis serão definidos como os tamanhos atuais dos componentes correspondentes, mesmo que o usuário tenha especificado antes um valor distinto diferente de zero para um parâmetro auto-ajustável. No exemplo do slide, o valor de SGA_TARGET é 8 GB e o valor de SHARED_POOL_SIZE é 1 GB. Se o sistema tiver ajustado internamente o tamanho do componente de shared pool para 2 GB, a definição de SGA_TARGET como zero resultará na definição de SHARED_POOL_SIZEcomo 2 GB, sobrepondo, assim, o valor original especificado pelo usuário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Redimensionando Manualmente os Parâmetros da SGA Dinâmica

• Em parâmetros auto-ajustáveis, o redimensionamento manual: – Resultará no redimensionamento imediato do

componente se o novo valor for maior que o valor atual – Alterará o tamanho mínimo se o novo valor for menor

que o tamanho atual • O redimensionamento de parâmetros ajustados

manualmente só afeta a parte ajustável da SGA.

Redimensionando Manualmente os Parâmetros da SGA Dinâmica Quando um parâmetro auto-ajustável for redimensionado e SGA_TARGET for definido, o redimensionamento só resultará em uma alteração imediata do tamanho do componente se o novo valor for maior que o tamanho atual do componente. Por exemplo, se você definir SGA_TARGET como 8 GB e SHARED_POOL_SIZE como 2 GB, estará assegurando que o shared pool tenha sempre um mínimo de 2 GB para acomodar as alocações de memória necessárias. Depois dessas definições, o ajuste do valor de SHARED_POOL_SIZE como 1 GB não terá efeito imediato no tamanho do shared pool. Ele permitirá que o algoritmo de ajuste automático de memória reduza posteriormente o tamanho do shared pool para 1 GB caso necessário. Por outro lado, se o tamanho do shared pool for 1 GB no início, o ajuste do valor de SHARED_POOL_SIZE como 2 GB resultará no crescimento imediato do componente de shared pool para um tamanho de 2 GB. A memória usada nessa operação de redimensionamento é retirada de um ou mais componentes auto-ajustáveis e os tamanhos dos componentes manuais não são afetados. Também é possível alterar de forma dinâmica os parâmetros dos componentes dimensionados manualmente, mas a diferença é que o valor do parâmetro especifica o tamanho exato desse componente imediatamente. Portanto, se o tamanho de um componente manual for aumentado, mais uma parte da memória será retirada de um ou mais componentes dimensionados automaticamente. Se o tamanho de um componente manual for reduzido, a memória liberada será alocada para os componentes dimensionados automaticamente.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




PGA (Program Global Area)

PGA

Processodo servidor PGA

Shared poolou

large pool PGA

Conexõesdedicadas

Servidorcompartilhado PGA

Conexõesde servidor

compartilhado

Áreasprivadas

para SQL

Cursor e área para SQL

Memóriada

sessão

Área detrabalho

PGA (Program Global Area) A PGA (Program Global Area) é uma região da memória que contém dados e informações de controle referentes a um processo do servidor. Trata-se de uma memória não-compartilhada criada pelo servidor Oracle quando um processo do servidor é iniciado. O acesso a ela é exclusivo a esse processo do servidor. A memória PGA total alocada por todos os processos do servidor associados a uma instância Oracle também é chamada de memória PGA agregadaalocada pela instância. Parte da PGA pode estar localizada na SGA quando são usados servidores compartilhados. A memória PGA geralmente contém: Área Privada para SQL Uma área privada para SQL contém dados, como as informações de bind e estruturas de memória de runtime. Essas informações são específicas para a chamada da instrução SQL de cada sessão; as variáveis de bind têm valores distintos, o estado do cursor é diferente, entre outras variações. Cada sessão que executa uma instrução SQL tem uma área privada para SQL. Cada usuário que submete a mesma instrução SQL tem uma área privada para SQL própria que usa uma única área SQL compartilhada. Dessa forma, é possível associar várias áreas privadas para SQL à mesma área SQL compartilhada. A localização da área privada para SQL depende do tipo de conexão estabelecida para a sessão. Se a sessão for conectada por meio de um servidor dedicado, a área privada para SQL estará localizada na PGA do processo do servidor. No entanto, se a sessão for conectada por meio de um servidor compartilhado, parte da área privada para SQL será mantida na SGA.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Program Global Area (continuação)Cursor e Áreas para SQL O desenvolvedor de aplicações de um programa pré-compilador Oracle ou de um programa OCI pode abrir explicitamente cursores ou handles de áreas privadas para SQL específicas e usá-los como um recurso nomeado durante a execução do programa. Os cursores recorrentes que o banco de dados executa implicitamente para algumas instruções SQL também usam as áreas para SQL compartilhadas. Área de Trabalho Em consultas complexas (por exemplo, consultas de suporte a decisão), grande parte da PGA é dedicada a áreas de trabalho alocadas por operadores que usam muita memória, como:

• Operadores baseados em classificação, como ORDER BY, GROUP BY, ROLLUP e funções de período

• Hash join • Intercalação de bitmap • Criação de bitmap • Buffers de gravação usados em operações de carga em alto volume

Uma operação de classificação usa uma área de trabalho (a área de classificação) para executar a classificação na memória de um conjunto de linhas. Da mesma forma, um operador hash join usa uma área de trabalho (a área de hash) para construir uma tabela de hash a partir da entrada à esquerda. É possível controlar e ajustar o tamanho de uma área de trabalho. Em geral, as áreas de trabalho maiores podem melhorar consideravelmente o desempenho de um operador específico com o consumo mais elevado de memória. Memória de Sessão A memória de sessão é a memória alocada para reter as variáveis de uma sessão (informações de logon) e outras informações relativas à sessão. Em um servidor compartilhado, a memória de sessão é compartilhada, e não privada.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciamento Automático da Memória PGA

• Ajusta dinamicamente o volume de memória PGA dedicado às áreas de trabalho, com base no parâmetro PGA_AGGREGATE_TARGET

• Ajuda a maximizar o desempenho de todas as operações SQL que usam muita memória

• É ativado por default

Gerenciamento Automático da Memória PGA O ideal é que a área de trabalho seja grande o suficiente para acomodar os dados de entrada e as estruturas auxiliares da memória alocadas pelo operador SQL associado. Esse tamanho é considerado o tamanho ideal de uma área de trabalho. Quando o tamanho da área de trabalho é menor que o ideal, o tempo de resposta aumenta, pois é executada uma passagem extra por parte dos dados de entrada. O gerenciamento automático da memória PGA simplifica e melhora a forma de alocação dessa memória. Por default, o gerenciamento da memória PGA é ativado. Nesse modo, o banco de dados Oracle ajusta dinamicamente o tamanho da parte da memória PGA dedicada a áreas de trabalho, com base em 20% do tamanho da memória SGA. O valor mínimo é 10 MB. Durante a execução no modo de gerenciamento automático da memória PGA, o dimensionamento de áreas de trabalho para todas as sessões é automático, e os parâmetros *_AREA_SIZE (como SORT_AREA_SIZE) são ignorados por todas as sessões executadas nesse modo. O volume total de memória PGA disponível para áreas de trabalho ativas na instância é sempre derivado automaticamente do parâmetro de inicialização PGA_AGGREGATE_TARGET. Esse volume é definido como o valor de PGA_AGGREGATE_TARGET menos o volume da memória PGA alocado por outros componentes do sistema (por exemplo, a memória PGA alocada por sessões). A memória PGA resultante é então designada a áreas de trabalho ativas individuais com base nos respectivos requisitos de memória.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Recursos de Gerenciamento da PGA

• Estatísticas para gerenciar o parâmetro de inicialização PGA_AGGREGATE_TARGET, como PGA cache hit percentage

• As views utilizadas para monitorar a área de trabalho da PGA são: – v$sql_workarea_histogram

– v$pgastat

– v$sql_workarea_active

– v$sql_workarea

– v$tempseg_usage

• As views utilizadas para auxiliar no dimensionamento da área de trabalho da PGA são: – v$pga_target_advice

– v$pga_target_advice_histogram

Recursos de Gerenciamento da PGA Durante a configuração de uma nova instância, é difícil saber exatamente a definição adequada para PGA_AGGREGATE_TARGET. Você pode determinar essa definição em três estágios:

1. Faça a primeira estimativa para PGA_AGGREGATE_TARGET com base na convenção. Por default, o banco de dados Oracle define essa estimativa como 20% do tamanho da SGA. No entanto, essa definição inicial pode ser muito baixa para um sistema DSS grande.

2. Execute uma carga de trabalho representativa na instância e monitore o desempenho, usando as estatísticas da PGA coletadas pelo Oracle, para descobrir se a configuração do tamanho máximo da PGA é muito alta ou muito baixa.

3. Ajuste PGA_AGGREGATE_TARGET usando as estatísticas informativas de PGA do Oracle.

Para fins de retrocompatibilidade, você pode desativar o gerenciamento automático da memória PGA definindo o valor do parâmetro de inicialização PGA_AGGREGATE_TARGET como 0. Quando o gerenciamento automático da memória PGA é desativado, é possível dimensionar o tamanho máximo de uma área de trabalho com o parâmetro *_AREA_SIZE associado, como:

• SORT_AREA_SIZE • HASH_AREA_SIZE • BITMAP_MERGE_AREA_SIZE • CREATE_BITMAP_AREA_SIZE

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando o Memory Advisor paraDimensionar a SGA

Usando o Memory Advisor para Dimensionar a SGA (continuação) Com o Memory Advisor, é possível ajustar o tamanho das estruturas da memória. Se o Gerenciamento Automático da Memória Compartilhada estiver ativado, use esse advisor para ajustar o tamanho total da SGA. Caso contrário, use-o para ajustar os diferentes componentes da SGA. O Memory Advisor é composto de três advisors que fornecem recomendações sobre estas estruturas da memória SGA:

• Shared pool • Cache de buffer

Para acionar os advisors de memória, execute estas etapas: 1. Clique em Advisor Central na região Related Links da home page Database. 2. Clique em Memory Advisor na página Advisor Central. A página Memory Parameters é

exibida. Essa página apresenta um detalhamento do uso da memória SGA. 3. Clique em Advice ao lado do valor Shared Pool ou Buffer Cache para acionar os

respectivos advisors.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando o Memory Advisorpara Dimensionar a PGA

Usando o Memory Advisor para Dimensionar a PGA O Memory Advisor pode ser usado para obter recomendações sobre o tamanho da PGA. Para tanto, clique na tab PGA e, em seguida, em Advice. Neste exemplo, o gráfico mostra que a elevação de Aggregate PGA Target de 80 MB para aproximadamente 140 MB causará um aumento no percentual de cache hits de 60% para quase 100%.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Uso de Memória Eficiente: Diretrizes

• Tente adequar a SGA à memória física. • Faça um ajuste para uma relação de cache hits de

buffer mais alta, com os seguintes cuidados: – Até varreduras integrais de tabela válidas e

necessárias reduzem essa relação. – É possível que leituras repetidas desnecessárias dos

mesmos blocos estejam aumentando a relação artificialmente.

• Use o Memory Advisor.

Uso de Memória Eficiente: Diretrizes Se possível, é melhor adequar a SGA à memória física, o que proporciona o acesso mais rápido. Mesmo que o sistema operacional possa oferecer memória virtual adicional, por sua natureza, essa memória pode sofrer swap para o disco. Em algumas plataformas, você pode usar o parâmetro de inicialização LOCK_SGA para bloquear a SGA na memória física. Quando uma instrução SQL é executada, são solicitados blocos de dados Oracle para leitura, gravação ou ambas as operações. Isso se chama entrada/saída lógica. À medida que o bloco é solicitado, o banco de dados Oracle primeiro verifica se ele já existe na memória. Se ele não estiver na memória, o banco de dados lerá esse bloco no disco. Essa operação é chamada de entrada/saída física. O número de ocorrências do bloco na memória comparado ao número total de entradas/saídas lógicas é chamado de relação de cache hits de buffer. Uma relação mais alta costuma ser melhor porque significa que mais blocos estão sendo encontrados na memória sem incorrer em entrada/saída do disco. Não é rara uma relação de cache hits de buffer superior a 99%. Entretanto, essa relação nem sempre significa que o sistema está bem ajustado. Quando uma consulta é executada com mais freqüência que o necessário e solicita constantemente os mesmos blocos, a relação aumenta. Quando uma consulta é ineficiente ou desnecessária, ela eleva artificialmente a relação. Isso ocorre porque a consulta não deveria ter sido executada daquela forma ou com aquela freqüência.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Uso de Memória Eficiente: Diretrizes (continuação)Lembre-se também de que grandes varreduras integrais de tabela (uma leitura integral da tabela inteira) podem reduzir a relação porque a tabela inteira poderá ser lida no disco; a varredura talvez ignore que alguns blocos já estão no cache de buffer. Por isso, se a aplicação exigir grandes varreduras integrais de tabela, seu banco de dados adequadamente ajustado poderá ter sempre uma baixa relação de cache hits do buffer do banco de dados. Use o Memory Advisor do Enterprise Manager. Ele pode ajudar a dimensionar a SGA com base na atividade de seu banco de dados específico.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Diretrizes de Ajuste da Memóriapara o Cache de Biblioteca

• Estabeleça convenções de formatação para desenvolvedores de forma que as instruções SQL tenham correspondentes no cache.

• Use variáveis de bind. • Elimine instruções SQL duplicadas desnecessárias. • Considere o uso de CURSOR_SHARING. • Use PL/SQL sempre que possível. • Armazene a seqüência de números no cache. • Retenha objetos no cache de biblioteca.

Diretrizes de Ajuste da Memória para o Cache de Biblioteca O cache de biblioteca, que faz parte do shared pool, é o local onde o banco de dados Oracle armazena todos os códigos SQL, PL/SQL e Java executados. O código permanece nessa área central para que possa ser compartilhado por todos os usuários. A vantagem do compartilhamento é permitir que todos os usuários se beneficiem do trabalho já realizado em termos de SQL. Portanto, tarefas como o parse da instrução e a determinação do caminho de acesso aos dados (também conhecido como “plano de execução”) são realizadas apenas uma vez por instrução, independentemente de quantas vezes a instrução é executada e de quantos usuários a executaram. Um cache de biblioteca muito pequeno não tem espaço suficiente para todas as instruções que são executadas, portanto não é possível aproveitar esse compartilhamento de trabalho em algumas instruções. Um cache de biblioteca muito grande causa uma sobrecarga no sistema com o simples gerenciamento de seu conteúdo. Um cache de biblioteca pode acabar sendo preenchido com instruções aparentemente diferentes que, na verdade, são cópias da mesma instrução. Uma causa comum para esse problema é uma formatação ligeiramente diferente para cada instrução. Não haverá correspondência se a string não for idêntica. Uma outra causa é o uso de literais em vez de variáveis de bind. Se a única diferença entre duas instruções for o valor literal, na maioria das vezes cada execução dessas instruções e o sistema geral serão beneficiados com a substituição desses literais por variáveis de bind.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Diretrizes de Ajuste de Memória para o Cache de Biblioteca (continuação)O parâmetro de inicialização CURSOR_SHARING poderá ser definido para que o sistema substitua automaticamente os literais por variáveis de bind quando as instruções corresponderem. Em geral, você deve aproveitar essa definição como uma medida temporária até que a aplicação seja corrigida para usar variáveis de bind quando adequado. Assim como ocorre com todas as diretrizes aqui descritas, o uso dessas variáveis pode apresentar efeitos colaterais, que devem ser investigados. Em vez executar a mesma instrução SQL de vários locais diferentes em uma aplicação, coloque a instrução ou instruções em um procedure armazenado usando PL/SQL. Em seguida, basta chamar o procedure. Assim você garante que a instrução SQL seja compartilhada porque ela só existe em um local. Além disso, o SQL já foi analisado por parse e tem um plano de execução porque já está em um procedure armazenado e compilado. As seqüências de números podem ser armazenadas no cache. Portanto, caso existam seqüências com alta atividade, especifique uma definição adequada para o tamanho do cache e aproveite-a. Você pode usar o package DBMS_SHARED_POOL para reter objetos no cache de biblioteca. Assim você reduz a probabilidade de recarga e recompilação de objetos. Consulte o documento PL/SQL Packages and Types Reference para obter mais informações sobre o uso desse package.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Descrever os componentes da memória na SGA • Implementar o Gerenciamento Automático da

Memória Compartilhada • Configurar manualmente os parâmetros da SGA • Usar o gerenciamento automático da memória PGA

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício: Usando o ASMM para Corrigir um Problema de Alocação de Memória

Este exercício aborda os seguintes tópicos: • Diagnóstico de um problema de alocação de

memória • Ativação do Gerenciamento Automático da Memória

Compartilhada

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Gerenciamento Automático do Desempenho

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Diagnosticar problemas de desempenho do banco

de dados• Configurar o Automatic Workload Repository• Acessar os advisors de banco de dados• Usar o SQL Access Advisor para melhorar o

desempenho do banco de dados• Usar COMMIT assíncrono com eficiência

AjusteEstatísticasAssociação de SGAAWRAdvisorsCommit Assíncrono

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Atividades de Ajuste

As três atividades de gerenciamento do desempenho são:• Planejamento do desempenho • Ajuste de instância • Ajuste de SQL

Atividades de Ajuste As três facetas da atividade de ajuste envolvem o planejamento do desempenho, o ajuste de instância e o ajuste de SQL.

• O planejamento do desempenho é o processo de estabelecer o ambiente: hardware, software, sistema operacional, infra-estrutura de rede e assim por diante.

• O ajuste de instância é o verdadeiro ajuste dos parâmetros do banco de dados Oracle e do sistema operacional com o objetivo de melhorar o desempenho do banco de dados Oracle.

• O ajuste de SQL envolve o preparo de sua aplicação para submeter SQL eficiente. Essa é uma consideração que pode abranger a aplicação inteira ou apenas uma instrução. Se abranger o sistema inteiro, certifique-se de que diferentes partes da aplicação estejam aproveitando o trabalho umas das outras, e não estejam competindo desnecessariamente por recursos. Nesta lição, você aprenderá algumas ações comuns para ajustar instruções SQL específicas.

Observação: Para obter mais informações sobre o ajuste de desempenho, consulte o Oracle Database Performance Tuning Guide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Planejamento do Desempenho

• Opções de investimento• Arquitetura do sistema • Escalabilidade• Princípios de design de aplicações • Teste, modelagem e implementação de carga de

trabalho • Disponibilização de novas aplicações

Planejamento do Desempenho O planejamento do desempenho apresenta várias facetas. É preciso considerar o investimento feito na sua arquitetura de sistema: a infra-estrutura de hardware e software necessária para atender aos seus requisitos. O número de discos rígidos e controladoras influencia a velocidade do acesso aos dados. O striping de dados entre vários dispositivos é um método usado com freqüência para melhorar o desempenho. É claro que ele requer uma análise com o objetivo de determinar o valor para seus requisitos específicos de ambiente, aplicação e desempenho. A escalabilidade de uma aplicação também é um fator importante. Significa que você pode lidar com um número cada vez maior de usuários, clientes, sessões ou transações, sem causar muito impacto no desempenho geral do sistema. O inimigo mais óbvio da escalabilidade é a serialização de operações entre os usuários. Se todos os usuários, um após o outro, precisarem percorrer um único caminho, o desempenho será prejudicado cada vez mais à medida que novos usuários forem adicionados. Isso ocorre porque cada vez mais usuários entrarão na fila para usar esse caminho. SQL mal escrito também afeta a escalabilidade. Ele exige que muitos usuários esperem a conclusão de SQL ineficiente; os usuários competem entre si por um grande número de recursos de que, na verdade, nem precisam. Os princípios do design de aplicação podem melhorar significativamente o desempenho. A simplicidade do design, o uso de views e índices e a modelagem de dados são fatores muito importantes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Planejamento do Desempenho (continuação)Uma aplicação precisa ser testada com uma carga de trabalho de produção representativa. Esse teste requer uma estimativa da carga de trabalho e do tamanho do banco de dados, bem como a geração dos dados de teste e da carga do sistema. O desempenho deve ser analisado à medida que novas aplicações (ou novas versões de aplicações) são disponibilizadas. Às vezes, são tomadas decisões de design para manter a compatibilidade com sistemas antigos durante o desenvolvimento. Um novo banco de dados deve ser configurado (com base no ambiente de produção) especificamente para as aplicações que ele hospeda.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Ajuste de Instância

• Tenha objetivos bem definidos.• Aloque memória para estruturas do bancos de

dados.• Considere os requisitos de entrada/saída em cada

parte do banco de dados.• Ajuste o sistema operacional para alcançar o

desempenho ideal do banco de dados.

Ajuste de Instância No início de uma atividade de ajuste, é necessário ter objetivos específicos. É mais fácil trabalhar com um objetivo como “Processar 500 transações de venda por minuto” que “Torne o processo o mais rápido possível e veremos quando estiver bom”. Você deve alocar memória do banco de dados Oracle adequada para que sua aplicação alcance o desempenho ideal. O volume de memória disponível é finito. Pouca memória alocada para determinadas partes do banco de dados Oracle pode resultar em atividade de background ineficiente, o que você só perceberá se fizer uma análise. Com freqüência, a entrada/saída de disco é o gargalo de um banco de dados. Portanto, essa área requer muita atenção durante a implementação de um banco de dados. A configuração do sistema operacional também pode afetar o desempenho de um banco de dados Oracle. Para obter mais informações, consulte o Oracle Database Installation Guidereferente à sua plataforma.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Metodologia de Ajuste de Desempenho

As etapas de ajuste:• Ajuste de cima para baixo. Ajuste:

– O design antes de ajustar o código da aplicação– O código antes de ajustar a instância

• Ajuste a área que apresenta maior potencial debenefício.– Identifique as esperas mais longas.– Identifique os tempos de serviço mais demorados.

• Pare de ajustar quando o objetivo for alcançado.

Metodologia de Ajuste de Desempenho A Oracle desenvolveu uma metodologia de ajuste baseada em anos de experiência. As etapas básicas são as seguintes:

• Verifique as estatísticas do sistema operacional e o estado geral da máquina antes de ajustar a instância para ter certeza de que o problema encontra-se no banco de dados.

• Ajuste de cima para baixo. Comece com o design, passe para a aplicação e, em seguida, para a instância. Por exemplo, tente eliminar as varreduras integrais de tabelas que causam a retenção da entrada/saída antes de ajustar o layout de tablespaces no disco.

• Ajuste a área que apresenta maior potencial de benefício. A metodologia de ajuste apresentada neste curso é simples. Identifique o maior gargalo e ajuste-o. Repita esta etapa. Todas as ferramentas de ajuste identificam de alguma forma as instruções SQL, a retenção de recursos ou os serviços mais demorados. O banco de dados Oracle oferece um modelo e métricas de tempo para automatizar o processo de identificação de gargalos.

• Pare de ajustar quando o objetivo for alcançado. Esta etapa implica a definição de objetivos de ajuste.

Essa é uma abordagem geral da atividade de ajuste da instância do banco de dados e pode exigir várias passagens.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Coleta de Estatísticas

• O ajuste do desempenho depende do conjunto deestatísticas precisas.

• Existem três tipos diferentes de estatísticas:– Estatísticas do otimizador – Estatísticas do sistema

• Há vários métodos de coleta de estatísticas:– Automaticamente, por meio de GATHER_STATS_JOB– Manualmente, com o package DBMS_STATS– Definindo os parâmetros de inicialização do banco de

dados– Importando estatísticas de outro banco de dados

Coleta de Estatísticas As estatísticas do otimizador são conjuntos de dados que oferecem mais detalhes sobre o banco de dados e os objetos nele contidos. O otimizador de consultas usa essas estatísticas a fim de escolher o melhor plano de execução para cada instrução SQL. As estatísticas do sistema descrevem as características de hardware do sistema, como a utilização e o desempenho da CPU e da entrada/saída, para o otimizador de consultas. Ao escolher um plano de execução, o otimizador calcula os recursos de entrada/saída e da CPU necessários para cada consulta. As estatísticas do sistema permitem ao otimizador de consultas calcular com mais precisão os custos de entrada/saída e da CPU e, assim, escolher um plano de execução melhor. As estatísticas do sistema são coletadas por meio do procedure DBMS_STATS.GATHER_SYSTEM_STATS. Quando o banco de dados Oracle coleta estatísticas do sistema, ele analisa a atividade do sistema em um período especificado. As estatísticas do sistema não são coletadas automaticamente. A Oracle Corporation recomenda o uso do package DBMS_STATS para coletar as estatísticas do sistema. O método recomendado para coletar estatísticas do otimizador é permitir que o banco de dados Oracle colete essas estatísticas automaticamente. O job GATHER_STATS_JOB é gerado automaticamente durante a criação do banco de dados e é gerenciado pelo Scheduler. Esse job coleta estatísticas sobre todos os objetos do banco de dados cujas estatísticas do otimizador estão desatualizadas ou não existem.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Coleta de Estatísticas (continuação)Se você optar por não usar a coleta automática de estatísticas, colete as estatísticas manualmente em todos os esquemas, inclusive nos esquemas do sistema. Se os dados do banco de dados forem alterados com regularidade, você também precisará coletar estatísticas regularmente para garantir que elas representem com precisão as características dos objetos do banco de dados. Para coletar estatísticas manualmente, use o package DBMS_STATS. Esse package PL/SQL também é usado para modificar, exibir, exportar, importar e deletar estatísticas. Você também pode gerenciar a coleta de estatísticas do otimizador e do sistema por meio dos parâmetros de inicialização do banco de dados. Por exemplo:

• O parâmetro OPTIMIZER_DYNAMIC_SAMPLING controla o nível de amostragem dinâmica executada pelo otimizador. Você pode usar a amostragem dinâmica a fim de calcular estatísticas para tabelas e índices relevantes quando eles não estão disponíveis ou estão muito desatualizados para serem confiáveis. A amostragem dinâmica também calcula seletividades de predicados de uma única tabela quando as estatísticas coletadas não podem ser usadas ou levam a erros significativos de estimativa.

• O parâmetro STATISTICS_LEVEL controla todos os principais advisories e coletas de estatísticas do banco de dados. Ele também define o nível de coleta de estatísticas do banco de dados. Os valores desse parâmetro são BASIC, TYPICAL e ALL.

• O parâmetro TIMED_STATISTICS orienta o servidor Oracle a coletar o tempo de espera por eventos e as contagens de esperas já disponíveis. Esses dados são úteis para comparar o tempo total de espera por um evento com o tempo total decorrido entre as coletas de dados de desempenho.

• O parâmetro TIMED_OS_STATISTICS especifica o intervalo (em segundos) em que o Oracle coleta as estatísticas do sistema operacional quando é feita uma solicitação do cliente ao servidor ou quando uma solicitação é concluída.

As estatísticas de tempo do sistema são coletadas automaticamente para o banco de dados quando o parâmetro de inicialização STATISTICS_LEVEL é definido como TYPICAL ou ALL. Se STATISTICS_LEVEL for definido como BASIC, especifique TIMED_STATISTICS como TRUE para permitir a coleta de estatísticas de tempo. Observe que a definição de STATISTICS_LEVEL como BASIC desativa vários recursos automáticos e não é recomendada. Se você definir explicitamente TIMED_STATISTICS ou TIMED_OS_STATISTICS no arquivo de parâmetros de inicialização ou por meio do comando ALTER SYSTEM ou ALTERSESSION, o valor definido explicitamente sobreporá o valor derivado de STATISTICS_LEVEL. Você pode consultar a view V$STATISTICS_LEVEL para determinar quais parâmetros são afetados pelo parâmetro STATISTICAL_LEVEL.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Eventos de Espera Oracle

• Um conjunto de eventos de espera forneceinformações sobre as sessões ou os processos que precisaram esperar ou devem esperar por diversosmotivos.

• Esses eventos são listados na view V$EVENT_NAME.

Ajuste> Estatísticas

Associação de SGAAWRAdvisorsCommit Assíncrono

Eventos de Espera Oracle Os eventos de espera são estatísticas incrementadas por um thread ou um processo do servidor para indicar que ele precisou esperar a conclusão de um evento antes de continuar o processamento. Os dados de eventos de espera revelam diversos sintomas de problemas que podem afetar o desempenho, como disputa por latch, buffer e entrada/saída. Lembre-se de que esses são apenas sintomas de problemas, e não os motivos reais. Os eventos de espera são agrupados em classes. As classes de eventos de espera incluem: Administrative, Application, Cluster, Commit, Concurrency, Configuration, Idle, Network, Other, Scheduler, System I/O e User I/O. Existem mais de 800 eventos de espera no banco de dados Oracle, incluindo free bufferwait, latch free, buffer busy waits, db file sequential read e db filescattered read. Usando o EM, você pode exibir eventos de espera abrindo a página Performance e examinando o gráfico “Sessions: Waiting and Working”, conforme mostrado no slide. Ao clicar no link de uma classe de eventos de espera, você pode fazer drill-down até os eventos de espera específicos usando a interface Top Sessions. Neste exemplo, os eventos de espera mais significativos foram leituras de arquivos. Para obter uma lista dos eventos Oracle mais comuns, consulte a documentação Oracle Database Reference 10g.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




V$SGASTAT• pool• name• bytes

V$SYSSTAT• statistic#• name• class• value• stat_id

V$SYSTEM_EVENT• event• total_waits• total_timeouts• time_waited• average_wait• time_waited_micro

Estatísticas do Sistema

V$EVENT_NAME• event_number• event_id• name• parameter1• parameter2• parameter3• wait_class

V$SYSTEM_WAIT_CLASS• wait_class_id • wait_class#• wait_class• total_waits• time_waited

Estatísticas do Sistema Para diagnosticar problemas de desempenho com eficiência, você precisa de estatísticas. O banco de dados Oracle gera vários tipos de estatísticas cumulativas relativas ao sistema, a sessões e a instruções SQL individuais. Ele também rastreia estatísticas cumulativas sobre segmentos e serviços. Ao analisar um problema de desempenho em um desses escopos, em geral, você examina a alteração nas estatísticas (valor delta) durante o período em que está interessado. Estatísticas dos Eventos de Espera Todos os eventos de espera possíveis são catalogados na view V$EVENT_NAME. As estatísticas cumulativas referentes a todas as sessões são armazenadas em V$SYSTEM_EVENT, que mostra as esperas totais por um evento específico desde a inicialização da instância. Se você estiver diagnosticando e solucionando problemas, precisará saber se um processo esperou por algum recurso. Estatísticas do Sistema Todas as estatísticas do sistema são catalogadas na view V$STATNAME: cerca de 330 estatísticas estão disponíveis no Oracle Database 10g. O servidor exibe todas as estatísticas calculadas do sistema na view V$SYSSTAT. Você pode consultar essa view para localizar totais cumulativos desde a inicialização da instância.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Estatísticas do Sistema (continuação)Estatísticas do Sistema (continuação) Por exemplo:

SQL> SELECT name, class, value FROM v$sysstat; NAME CLASS VALUE ------------------------------- ------ ----------... table scans (short tables) 64 135116 table scans (long tables) 64 250 table scans (rowid ranges) 64 0 table scans (cache partitions) 64 3 table scans (direct read) 64 0 table scan rows gotten 64 14789836 table scan blocks gotten 64 558542 ...

As estatísticas do sistema são classificadas por tópico de ajuste e finalidade da depuração. As classes incluem a atividade geral de instâncias, a atividade dos buffers de redo log, o bloqueio, a atividade dos caches de buffer do banco de dados, e assim por diante. Para exibir todos os eventos de espera referentes a determinada classe de espera, consulte a view V$SYSTEM_WAIT_CLASS. Por exemplo (com a formatação aplicada):

SQL> SELECT * FROM V$SYSTEM_WAIT_CLASS 2 WHERE wait_class LIKE '%I/O%';

CLASS_ID CLASS# WAIT_CLASS TOTAL_WAITS TIME_WAITED ---------- ------ ------------ ----------- -----------1740759767 8 User I/O 1119152 39038 4108307767 9 System I/O 296959 27929

Estatísticas Globais da SGA O servidor exibe todas as estatísticas de memória calculadas na view V$SGASTAT. Você pode consultar essa view para localizar totais cumulativos do uso detalhado da SGA desde a inicialização da instância. Por exemplo:

SQL> SELECT * FROM v$sgastat; POOL NAME BYTES ------ ------------------------- ----------

fixed_sga 7780360 buffer_cache 25165824 log_buffer 262144

shared pool sessions 1284644 shared pool sql area 22376876 ...

Os resultados mostrados são apenas uma exibição parcial da saída.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Exibindo Estatísticas Relativas a Sessões

V$STATNAME

• statistic#• name• class

V$SESSTAT• sid• statistic#• value

V$SESSION• sid• serial#• username• command• osuser• seq#• event#• event• p1/2/3text• p1/2/3• p1/2/3raw• wait_class• wait_time• seconds_in_wait• state• ...

V$SESSION_EVENT• sid• event• total_waits• total_timeouts• time_waited• average_wait• max_wait• time_waited_micro• event_id

V$EVENT_NAME• event#• name• parameter1• parameter2• parameter3

Exibindo Estatísticas Relativas a Sessões Para exibir informações sobre a sessão atual de cada usuário conectado, consulte a view V$SESSION. Por exemplo, você pode usar a view V$SESSION para determinar se uma sessão representa uma sessão de usuário ou foi criada por um processo do servidor do banco de dados (BACKGROUND). Consulte V$SESSION ou V$SESSION_WAIT para determinar os recursos ou os eventos pelos quais as sessões ativas estão esperando. O servidor Oracle exibe as estatísticas das sessões dos usuários na view V$SESSTAT. A view V$SESSION_EVENT lista informações sobre esperas de uma sessão por um evento. Os valores cumulativos das estatísticas geralmente estão disponíveis em views dinâmicas de desempenho, como as views V$SESSTAT e V$SYSSTAT. Observe que os valores cumulativos em views dinâmicas são redefinidos quando é feito shutdown da instância do banco de dados. A view V$MYSTAT exibe as estatísticas da sessão atual. Você também pode consultar a view V$SESSMETRIC para exibir os valores das métricas de desempenho referentes a todas as sessões ativas. Essa view lista métricas de desempenho, como o uso da CPU, o número de leituras físicas, o número de parses incondicionais e a relação de leituras lógicas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Exibindo Estatísticas Relativas a Serviços

Em ambientes de n camadas, como as estatísticas desessões não são tão úteis, você pode ver estatísticasde serviços nestas views:• V$SERVICE_EVENT: Contagens de esperas e

tempos de espera agregados para cada serviço por evento

• V$SERVICE_WAIT_CLASS: Contagens de esperase tempos de espera agregados para cada serviço por classe de espera

Exibindo Estatísticas Relativas a Serviços Em um ambiente de n camadas, no qual há um servidor de aplicações executando o pool de conexões do banco de dados, a exibição das sessões pode não fornecer as informações necessárias à análise do desempenho. O agrupamento de sessões em nomes de serviço permite monitorar o desempenho com mais precisão. Estas duas views fornecem as mesmas informações que suas correspondentes de sessões de mesmo nome, mas as informações são apresentadas no nível de serviço, e não no nível de sessão. V$SERVICE_WAIT_CLASS mostra as estatísticas de espera para cada serviço, divididas por classe de espera. V$SERVICE_EVENT mostra as mesmas informações de V$SERVICE_WAIT_CLASS, mas apresenta mais um grau de divisão, por ID de evento.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Instância/Banco de Dados V$DATABASE V$INSTANCE V$PARAMETER V$SPPARAMETER V$SYSTEM_PARAMETER V$PROCESS V$BGPROCESS V$PX_PROCESS_SYSSTATV$SYSTEM_EVENT

Views para Diagnóstico/Soluçãode Problemas e Ajuste

Disco V$DATAFILE V$FILESTAT V$LOG V$LOG_HISTORY V$DBFILE V$TEMPFILE V$TEMPSEG_USAGE V$SEGMENT_STATISTICS

DisputaV$LOCK V$UNDOSTAT V$WAITSTAT V$LATCH

MemóriaV$BUFFER_POOL_STATISTICS V$LIBRARYCACHE V$SGAINFO V$PGASTAT

Views para Diagnóstico/Solução de Problemas e Ajuste O slide lista algumas das views que você talvez precise acessar para determinar o motivo dos problemas de desempenho ou analisar o status atual do banco de dados. Para obter uma descrição completa dessas views, consulte o Oracle Database Reference Manual. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Views de Dicionário

• As seguintes views especiais e de dicionário fornecem estatísticas úteis após o uso do package DBMS_STATS: – DBA_TABLES, DBA_TAB_COLUMNS

– DBA_CLUSTERS

– DBA_INDEXES

– DBA_TAB_HISTOGRAMS

• Essas informações estatísticas são estáticas até você executar novamente os procedures adequadosno DBMS_STATS.

Views de Dicionário Para examinar o armazenamento de dados em detalhes, use o package DBMS_STATS, que coleta estatísticas e preenche colunas de algumas views DBA_xxx. DBMS_STATS preenche colunas das views relativas a:

• Armazenamento de dados de tabela em extensões e blocos: – DBA_TABLES – DBA_TAB_COLUMNS

• Armazenamento de dados de cluster em extensões e blocos: – DBA_CLUSTERS

• Armazenamento de dados de índice em extensões e blocos, e recurso de índice: – DBA_INDEXES

• Distribuição de dados de colunas indexadas e não indexadas: – DBA_TAB_HISTOGRAMS

Para obter mais informações sobre o uso do package DBMS_STATS, consulte o Oracle Database Performance Tuning Guide. Quando o comando ANALYZE INDEX … VALIDATE STRUCTURE é executado, as views INDEX_STATS e INDEX_HISTOGRAM, que contêm estatísticas para índices, são preenchidas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Diagnósticos de Bancosde Dados Bloqueados ou

Extremamente Lentos

Use na análise de problemas, quando o banco de dados estiver lento ou bloqueado:• Acesso direto à SGA para monitoramento do

desempenho (modo de acesso à memória) – V$SESSION

– V$SESSION_WAIT

– V$SYSTEM_EVENT

– V$SYSSTAT

– Análise de bloqueio usando o Enterprise Manager

Ajuste Estatísticas

> Associação de SGAAWRAdvisorsCommit Assíncrono

Diagnósticos de Bancos de Dados Bloqueados ou Extremamente Lentos Existe uma funcionalidade disponível para analisar problemas de desempenho insatisfatório ou bloqueio do banco de dados. O sistema suporta a coleta de estatísticas de desempenho em tempo real diretamente da SGA (System Global Area) por meio de chamadas otimizadas ou leves no nível do sistema como alternativa para SQL. No Enterprise Manager, esse tipo de coleta é chamado de modo de acesso à memória. Há um thread coletor da SGA por instância Oracle, que é iniciado automaticamente pelo agente do EM quando ele começa a monitorar uma instância do banco de dados. As views V$ mostradas no slide são as principais views usadas em diagnósticos de desempenho de alto nível e, portanto, são aquelas que têm acesso direto à SGA. Se forem necessárias mais informações de drill-down, use SQL para recuperá-las. As informações sobre o host, como o número de CPUs e o nome do host, também são coletadas e exibidas por meio da interface do EM.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando o Modo de Acesso à Memória

1

23

4

Usando o Modo de Acesso à Memória Você pode acessar a página gráfica do modo de acesso à memória na home page da seção Related Links clicando no link “Monitor in Memory Access Mode”. O link leva à página Performance do modo de exibição “Memory Access”. Como mostra o slide, é preciso ativar pela primeira vez o modo de acesso à memória, clicando em “Enable Memory Access Mode”. Posteriormente, você pode desativá-lo. Para retornar ao modo de exibição de acesso SQL, basta clicar no botão “Switch to SQL Access Mode” na página Performance. O modo de acesso à memória evita a computação associada ao parse e à execução de instruções SQL, o que o torna eficiente em casos graves de disputa de cache de biblioteca que podem impedir o monitoramento da instância com SQL. Alterne para o modo de acesso à memória se o sistema estiver lento ou bloqueado.As páginas do modo de acesso à memória contêm dados de amostras obtidos com mais freqüência que os dados das páginas do modo SQL. Por esse motivo, os gráficos podem parecer ligeiramente diferentes do modo SQL. Conseqüentemente, a página do modo de acesso à memória oferece melhores informações sobre o local de início e término de eventos; além disso, também é possível detectar eventos de curta duração que, de outra forma, seriam omitidos. Observação: O modo de acesso à memória também é chamado de modo de associaçãode SGA

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando a Página de Análise de Bloqueio

Microjanela

Usando a Página de Análise de Bloqueio Para analisar sistemas lentos e bloqueados, você pode usar a página Hang Analysis na seção Additional Monitoring Links da página Performance do EM. Pode também usar a página Blocking Sessions para exibir uma lista de todas as sessões que estão bloqueando outras sessões no momento. Use a página Hang Analysis para:

• Determinar quais sessões estão causando gargalos • Examinar sumários de sessões para identificar as sessões bloqueadoras e bloqueadas

Essa página fornece uma topologia gráfica das sessões em espera no sistema, exibindo as sessões bloqueadas abaixo das sessões bloqueadoras. O Enterprise Manager avalia a situação com base no histórico de atividades e determina quais sessões estão bloqueadas ou podem ser bloqueadas, em vez de estarem apenas instantaneamente em estado de espera. Para exibir as informações sumariadas de uma sessão, clique no ID da sessão na topologia. A página Session Summary é exibida com as informações gerais sobre a sessão selecionada. Você pode clicar em View Session Details na página Session Summary para obter mais detalhes sobre a sessão e determinar se encerrá-la é a melhor opção.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Usando a Página de Análise de Bloqueio (continuação)As sessões são exibidas em verde, amarelo ou vermelho, dependendo da gravidade de seu estado na topologia. Você também pode selecionar um percentual em Zoom Factor com base no tamanho desejado da topologia. Quando houver muitas sessões bloqueadas, você poderá usar um fator menor para visualizar as informações gerais de espera do sistema. Em seguida, você poderá aplicar mais zoom às partes relevantes e ler a topologia ou fazer drill-down. Clique na área da microjanela Zoom Factor para mover a topologia para a posição de visualização desejada. Por exemplo, se você clicar no lado esquerdo da janela, a topologia mudará para a direita, permitindo uma visualização completa de seu lado esquerdo.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Automatic WorkloadRepository

SYSAUX

SGA

Estatísticasna memória

06:00:0007:00:0008:00:00

Snapshot 1Snapshot 2Snapshot 3Snapshot 409:00:00

09:30:00

O ADDM detecta problemas

importantes.

MMON

Ajuste EstatísticasAssociação de SGA

> AWRAdvisorsCommit Assíncrono

Automatic Workload Repository O AWR (Automatica Workload Repository) é um conjunto de estatísticas persistentes de desempenho do sistema pertencente a SYS. Ele reside no tablespace SYSAUX. Um snapshot é um conjunto de estatísticas de desempenho capturadas em determinado momento e armazenadas no AWR. Os snapshots são usados para calcular a taxa de alteração de uma estatística. Cada snapshot é identificado por um número de seqüência de snapshot (snap_id) exclusivo no AWR. Os usuários do Statspack devem começar a usar o Workload Repository no Oracle Database 10g. Entretanto, não há um caminho suportado de migração de dados do Statspack para o Workload Repository. Além disso, o Workload Repository não é retrocompatível com o esquema do Statspack. Por default, os snapshots são gerados a cada 60 minutos. Você pode ajustar essa freqüência alterando o parâmetro INTERVAL do snapshot. Como os advisors do banco de dados dependem desses snapshots, lembre-se de que o ajuste da definição de intervalo pode afetar a precisão do diagnóstico. Por exemplo, se INTERVAL for definido como 4 horas, você poderá perder oscilações que ocorrem em intervalos de 60 minutos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Automatic Workload Repository (continuação)Você pode usar o procedure armazenado DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS ou o Database Control para alterar as definições que controlam a coleta de snapshots. No Database Control, clique em Automatic Workload Repository na região Statistics Management da página com a tab Administration. Em seguida, clique em Edit para fazer as alterações. O procedure armazenado oferece mais flexibilidade na definição de valores INTERVAL que o Database Control. Você pode gerar snapshots manuais usando o Database Control ou o procedure armazenado DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT. A geração de snapshots manuais é suportada com os snapshots automáticos que o sistema gera. Os snapshots manuais devem ser usados quando você deseja capturar o comportamento do sistema em dois momentos específicos que não coincidem com a programação automática.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Linhas de Base de Snapshots do AWR

DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE ( -

start_snap_id IN NUMBER ,

end_snap_id IN NUMBER ,

baseline_name IN VARCHAR2);

Período relevanteno passado

Linhas de Base de Snapshots do AWR As linhas de base são um mecanismo para indicar conjuntos de dados de snapshots relativos a períodos importantes. Uma linha de base é definida com base em um par de snapshots; os snapshots são identificados pelos respectivos números de seqüência (snap_id). Cada linha de base corresponde a apenas um par de snapshots. É possível identificar uma linha de base por um nome fornecido pelo usuário ou por um identificador gerado pelo sistema. Para criar uma linha de base, use o Database Control ou execute o procedure DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE e especifique um nome e um par de identificadores de snapshots. Um identificador de linha de base é atribuído à linha de base recém-criada. Os identificadores de linha de base são exclusivos durante toda a vida útil de um banco de dados. As linhas de base são usadas para reter dados de snapshots. Portanto, os snapshots pertencentes a linhas de base são retidos até que essas linhas de base sejam eliminadas. Em geral, você configura linhas de base de alguns períodos representativos no passado para fins de comparação com o comportamento atual do sistema. Você também pode configurar alertas baseados em limites usando linhas de base no Database Control. É possível obter os snap_ids diretamente do DBA_HIST_SNAPSHOT ou do Database Control. Observação: Para obter mais informações sobre o package DBMS_WORKLOAD_REPOSITORY, consulte o Oracle Database PL/SQL Packages and Types Reference Guide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Advisory Framework:Visão Geral

ADDM

SQL Tuning Advisor

SQL Access Advisor

Memória

Espaço

PGA Advisor

SGA

Segment Advisor

Undo Advisor

Buffer CacheAdvisor

Library CacheAdvisor

PGA

Ajuste EstatísticasAssociação de SGA AWR

> AdvisorsCommit Assíncrono

Advisory Framework: Visão Geral Os advisors são componentes do servidor que fornecem comentários úteis sobre a utilização de recursos e o desempenho do componente em questão. Eles usam todos os recursos abordados anteriormente e outros. Veja a seguir a lista de advisors disponíveis:

• ADDM (Automatic Database Diagnostic Monitor): Faz uma análise top-down da instância, identifica problemas e possíveis causas, e sugere ações corretivas para solucioná-los. O ADDM pode chamar outros advisors.

• SQL Tuning Advisor: Fornece recomendações de ajuste de instruções SQL • SQL Access Advisor: Trata problemas relacionados a esquema e determina os caminhos

ideais de acesso a dados, como views materializadas e índices • PGA Advisor: Fornece estatísticas detalhadas sobre as áreas de trabalho e oferece

recomendações sobre o uso ideal da memória PGA (Program Global Area) com base nas características da carga de trabalho

• SGA Advisor: É responsável por ajustar e recomendar o tamanho da SGA (System Global Area) de acordo com o padrão de acesso de vários componentes da SGA

• Segment Advisor: Monitora eventuais problemas de espaço de objetos e analisa as tendências de crescimento

• Undo Advisor: Sugere valores de parâmetros e o espaço adicional necessário para suportar o flashback durante um período específico

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Advisory Framework: Visão Geral (continuação)As principais vantagens da infra-estrutura de advisor são:

• Ela usa uma interface uniforme para todos os advisors. • Todos os advisors são chamados e informam resultados de maneira consistente.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Database Control e Advisors

Database Control e Advisors A página Advisor Central é a página principal de todos os advisors. Para acessar essa página, clique no link Advisor Central na região Related Links da home page Database. Entretanto, esse não é o único local na Console do Database Control onde é possível chamar os advisors. Na página Advisor Central, você pode listar todas as tarefas de advisors que foram registradas no AWR. Também pode filtrar essa lista por tipo de advisor e por períodos predefinidos. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Sessão de Ajuste Convencional de Advisor

Ajustar os parâmetros para a tarefa.

Aceitar osresultados?

Implementarrecomendações.

Sim

Não

Executar uma análise.

Criar uma tarefa de advisor.

Sessão de Ajuste Convencional de Advisor Uma sessão de ajuste convencional compreende estas etapas:

1. Criar uma tarefa de advisor.Uma tarefa de advisor é uma área de dados executáveis no repositório do advisor que gerencia atividades de ajuste.

2. Ajustar os parâmetros apropriados para a tarefa. Os parâmetros são definidos na tarefa de advisor principal. Eles controlam o comportamento do advisor.

3. Executar uma análise. A execução da tarefa é uma operação síncrona; o controle só é retornado quando a operação é concluída ou a interrupção de um usuário é detectada. A qualquer momento, você pode interromper a operação e verificar os resultados até esse momento no processo de análise. Se não estiver satisfeito, você poderá retomar a execução para obter mais recomendações ou poderá ajustar os dados da tarefa e reiniciar a execução.

4. Verificar os resultados. É possível verificar os resultados da análise com o auxílio das views incorporadas ou do procedure mostrado no slide. Você pode aceitar, rejeitar ou ignorar as recomendações. Caso uma recomendação seja rejeitada, convém reexecutar uma análise usando essa recomendação como dica para a próxima operação de análise.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Chamando o ADDM Manualmente

Chamando o ADDM Manualmente Por default, as tarefas do ADDM são executadas em cada snapshot do banco de dados Oracle armazenado no AWR. No entanto, você pode criar uma tarefa personalizada do ADDM para analisar um período identificado por um snapshot inicial e um snapshot final. Para criar uma tarefa do ADDM, execute estas etapas:

1. Navegue até a home page Database. Na seção Related Links, clique em Advisor Central. 2. Em Advisors, escolha ADDM. 3. Selecione a opção Period Start Time e clique no snapshot a ser usado como ponto inicial do

período. Depois, selecione a opção End Time e clique no snapshot a ser usado como ponto final do período.

4. Use a página ADDM Task para exibir os resultados de uma tarefa selecionada do ADDM. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Usando o SQL Tuning Advisor: Revisão

• Use o SQL Tuning Advisor para analisar instruçõesSQL e obter recomendações de desempenho.

• Origens para análise do SQL Tuning Advisor: – Top SQL: Analisa as principais instruções SQL ativas

no momento– SQL Tuning Sets: Analisa um conjunto fornecido de

instruções SQL – Snapshots: Analisa um snapshot – Baselines: Analisa uma linha de base

Usando o SQL Tuning Advisor: Revisão Você pode usar o SQL Tuning Advisor para analisar instruções SQL e obter recomendações de desempenho. Em geral, você executa esse advisor como uma ação de detecção de desempenho do ADDM. Além disso, você pode executar o SQL Tuning Advisor para analisar as instruções SQL que mais consomem tempo da CPU, entrada/saída e memória. O SQL Tuning Advisor é abordado em detalhes no curso Oracle Database 10g: Workshop de Administração I.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




SQL Access Advisor: Visão Geral

SQL AccessAdvisor

Recomendações-Índices-Views materializadas-Logs de viewmaterializada

Especificação da cargade trabalho

-Instrução SQL-SQL Tuning Set-Conteúdo do cache SQL-Estatísticas-Nome do esquema

SQL Access Advisor: Visão Geral O SQL Access Advisor pode recomendar o conjunto adequado de views materializadas, logs de views materializadas e índices para uma carga de trabalho específica. É essencial conhecer e usar essas estruturas ao otimizar SQL, já que elas podem resultar em melhorias significativas de desempenho na recuperação de dados. O SQL Access Advisor recomenda índices de bitmap, baseados em função e em árvore B. O índice de bitmap oferece um tempo de resposta mais curto para vários tipos de consultas ad hoc e menos requisitos de armazenamento em comparação a outras técnicas de indexação. Os índices em árvore B são mais usados em data warehouse para indexar chaves exclusivas ou quase exclusivas. Outro componente do SQL Access Advisor também fornece recomendações sobre como otimizar views materializadas de forma que elas sejam rapidamente atualizadas e aproveitem as vantagens da reescrita geral de consultas. Observação: Para obter mais informações sobre views materializadas e reescrita de consultas, consulte o Oracle Database Performance Tuning Guide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sessão Típica do SQL Access Advisor

Sessão Típica do SQL Access Advisor Ao iniciar uma sessão do SQL Access Advisor, você pode selecionar Use Default Options e começar com um conjunto predefinido de opções recomendadas do Advisor. Pode também iniciar uma tarefa e fazê-la herdar um conjunto de valores de opções definidos por um gabarito ou tarefa. Para isso, selecione “Inherit Options from a Task or Template”. Essas opções incluem vários gabaritos genéricos projetados para ambientes com finalidades gerais, OLTP e banco de dados de data warehousing. Você pode salvar gabaritos personalizados de uma tarefa anterior e reutilizá-los quando necessário. Clique em Continue para iniciar o assistente do SQL Access Advisor. Observação: Você pode acessar o SQL Access Advisor na página Advisor Central do Database Control.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Origem da Carga de Trabalho

Origem da Carga de Trabalho Use a página Workload Source do assistente do SQL Access Advisor para fornecer uma carga de trabalho definida que permita ao Access Advisor fazer recomendações. As cargas de trabalho suportadas são:

• Current and Recent SQL Activity: Usa o SQL atual do cache como a carga de trabalho • Import Workload from SQL Repository: Permite especificar um SQL Tuning Set criado

anteriormente como a origem da carga de trabalho • User-Defined Workload; Import SQL from a Table or View: Permite receber

recomendações de uma carga de trabalho que não esteja em execução no banco de dados atual. Assim as recomendações de acesso são fornecidas e implementadas antes que uma aplicação seja ativada.

• Create a Hypothetical Workload from the Following Schemas and Tables: Oferece um esquema que permite ao advisor procurar tabelas de dimensões e produzir uma carga de trabalho

Para reduzir ainda mais o escopo da carga de trabalho, aplique filtros, que você pode acessar na seção Filter Options. Com essas opções, você pode reduzir o escopo das instruções SQL presentes na carga de trabalho. Os filtros são aplicados à carga de trabalho pelo advisor para concentrar o foco na atividade de ajuste. As possíveis opções de filtro são:

• Instruções SQL que mais consomem recursos • Usuários, identificador de módulo ou ações • Tabelas

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Opções de Recomendação

Opções de Recomendação Use a página Recommendations Options para decidir se o advisor será limitado a fazer recomendações baseadas em um único método de acesso. Escolha Indexes, Materialized Views ou as duas opções na seção Recommendation Types. Você pode escolher Evaluation Only para avaliar somente as estruturas de acesso existentes. Nesse modo, o advisor não gera novas recomendações, mas sim comentários sobre o uso das estruturas existentes. Esse recurso é útil para controlar a eficiência do uso do índice, da view materializada e do log da view materializada atuais ao longo do tempo. Você pode usar a seção Advisor Mode para executar o advisor em um dos dois modos possíveis. Esses modos afetam a qualidade das recomendações, bem como o tempo necessário para o processamento. No Comprehensive Mode, o advisor procura um large pool de candidatos, resultando em recomendações de melhor qualidade. No Limited Mode, o advisor é executado rapidamente, limitando as recomendações de candidatos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Opções de Recomendação

Opções de Recomendação (continuação) Você pode escolher Advanced Options para mostrar ou ocultar opções que permitem definir restrições de espaço, opções de ajuste e locais de armazenamento default. Use a seção Workload Categorization para definir opções para Workload Volatility e Workload Scope. Você pode optar por favorecer as operações somente para leitura ou pode considerar a volatilidade de objetos referenciados ao criar recomendações. Pode também selecionar Partial Workload, que não inclui recomendações para eliminar estruturas de acesso não utilizadas, ou Complete Workload, que inclui esse tipo de recomendação. Use a seção Space Restrictions para especificar um limite rígido de espaço, que force o advisor a produzir recomendações somente com os requisitos de espaço total que não excedam o limite estabelecido. Use a seção Tuning Options para especificar opções que personalizem as recomendações feitas pelo advisor. Use a lista drop-down “Prioritize Tuning of SQL Statements by” para priorizar porOptimizer Cost, Buffer Gets, CPU Time, Disk Reads, Elapsed Time e Execution Count. Use a seção Default Storage Locations para substituir os defaults definidos para locais de esquemas e tablespaces. Por default, os índices são colocados no esquema e no tablespace da tabela a qual fazem referência. As views materializadas são colocadas no esquema e no tablespace do usuário que executou uma das consultas que contribuiu para a recomendação da view materializada. Depois de definir esses parâmetros, você pode programar e revisar a tarefa de ajuste.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Verificando Recomendações

Verificando Recomendações Usando a página Advisor Central, você pode listar todas as tarefas concluídas do SQL Access Advisor. Selecione aquela cujas recomendações você deseja ver e clique no botão View Result. Use a página Results for Task Summary para obter uma visão geral das descobertas do advisor. A página apresenta gráficos e estatísticas que informam a possível melhoria do desempenho geral da carga de trabalho e do tempo de execução obtida com as recomendações. Você pode usar a página para mostrar contagens de instruções e de ações de recomendações. Para ver outros aspectos dos resultados da tarefa do advisor, clique em uma das outras três tabs da página: Recommendations, SQL Statements ou Details. A página Recommendations exibe um gráfico e uma tabela que mostram as recomendações principais ordenadas pela melhoria percentual do custo total da carga de trabalho inteira. As principais recomendações possibilitam a maior melhoria total de desempenho. Ao clicar no botão Show SQL, você poderá ver o script SQL gerado para as recomendações selecionadas. Você pode clicar no identificador da recomendação correspondente na tabela para ver a lista de ações a serem executadas para implementar a recomendação. Na página Actions, você pode realmente ver todas as instruções SQL correspondentes a serem executadas para implementar a ação. Mantenha desmarcadas as caixas de seleção das recomendações que não deseja implementar. Em seguida, clique no botão Schedule Implementation para implementar as ações retidas. Essa etapa é executada na forma de um job do Scheduler.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




COMMIT Assíncrono

• O comportamento default do COMMIT é esperar até que o redo seja salvo nos arquivos de redo log.

• O comportamento default pode ser alterado para“não esperar”.

• O COMMIT assíncrono é útil para transações de alto throughput.

• No entanto, as transações podem ser perdidas.– Falhas de máquina – Problemas de entrada/saída de arquivos de redo log

Ajuste EstatísticasAssociação de SGA AWRAdvisors

> Commit Assíncrono

COMMIT Assíncrono Quando uma transação é submetida a commit, o processo log writer (LGWR) grava no disco o redo para o commit, junto com o redo acumulado de todas as alterações ocorridas na transação correspondente. Por default, o banco de dados Oracle grava o redo no disco antes que a chamada seja retornada ao cliente. Esse comportamento introduz uma latência no commit porque a aplicação precisa esperar que o redo seja gravado no disco. Suponha que você esteja gravando uma aplicação que requeira um throughput de transação muito alto. Se você quiser trocar a durabilidade do commit por uma latência menor, poderá alterar as opções default do COMMIT de forma que a aplicação não precise esperar até o banco de dados Oracle gravar dados nos redo logs on-line. Assim, o redo gerado para uma transação poderá não persistir quando o commit retornar ao usuário. Dessa forma, a transação supostamente submetida a commit se tornará vulnerável a um rollback. O caso mais óbvio é a falha da máquina. Nesse caso, também são perdidos os redos da operação de commit armazenados nos buffers de redo log antes de serem gravados nos arquivos de redo log on-line. Em outro caso, você pode ter problemas de entrada/saída de arquivos com os redo logs on-line no momento em que o LGWR realmente tenta forçar a gravação no disco de qualquer redo armazenado no buffer de redo log. Se os redo logs não forem multiplexados para fornecer um certo nível de redundância, a ação de commit poderá ser perdida.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando o COMMIT Assíncrono

• Combinações possíveis: – IMMEDIATE, WAIT (default) – IMMEDIATE, NOWAIT

– BATCH, WAIT

– BATCH, NOWAIT

• Exemplos em nível de sistema ou sessão:

• Exemplos de instrução COMMIT:

ALTER SYSTEM SET COMMIT_WRITE = IMMEDIATE, WAIT

ALTER SESSION SET COMMIT_WRITE = IMMEDIATE, NOWAIT

COMMIT WRITE BATCH WAIT

COMMIT WRITE BATCH NOWAIT

Usando o COMMIT Assíncrono Você pode alterar o comportamento do commit nos seguintes locais:

• Parâmetro de inicialização COMMIT_WRITE no nível de sistema ou sessão • Instrução COMMIT

A opção IMMEDIATE assegura que o redo para o commit da transação seja gravado imediatamente pelo processo LGWR; ou seja, é iniciada uma entrada/saída. A opção BATCHsignifica que o redo é armazenado no buffer e não é iniciada uma entrada/saída. No entanto, o LGWR ainda pode gravar o redo no disco em seu próprio tempo. A opção WAIT garante que o commit não retorne até que o redo correspondente a ele persista nos redo logs on-line. Quando você usa a opção NOWAIT, o commit retorna sem esperar que o redo da operação de commit seja gravado nos redo logs on-line. Na ausência de opções, os defaults são IMMEDIATE e WAIT, o que é consistente com releases anteriores do banco de dados. Não é possível especificar BATCH e IMMEDIATE juntos, nem WAIT e NOWAIT. Após a definição do parâmetro de inicialização, uma instrução COMMIT sem opções adapta-se às opções especificadas no parâmetro. Observação: As opções da instrução COMMIT sobrepõem as definições existentes no parâmetro de inicialização.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a:• Diagnosticar problemas de desempenho do banco

de dados• Configurar o Automatic Workload Repository• Acessar os advisors de banco de dados• Usar o SQL Access Advisor para melhorar o

desempenho do banco de dados• Usar COMMIT assíncrono com eficiência

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício: Usando o ADDMpara Diagnosticar Problemas de Desempenho

Este exercício aborda os seguintes tópicos:• Exibição e interpretação de descobertas do ADDM

para diagnosticar um problema de desempenho • Implementação dessas descobertas

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Gerenciando Objetos de Esquema

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de gerenciar objetos de esquema e:• Determinar os tipos de tabela adequados aos seus

requisitos: heap, partição, IOT ou cluster• Executar tarefas do DBA correlatas:

– Estimar o tamanho de novas tabelas – Analisar tendências de crescimento – Gerenciar estatísticas do otimizador – Reorganizar objetos de esquema on-line

Tipos de TabelasPartiçãoIOTClusterTarefas do DBA

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tipos de Tabelas

Os dados correlatos de uma ou mais tabelas são armazenados juntos.

Tabela clusterizada

Os dados (incluindo valores não relacionados achave) são classificados e armazenados em uma estrutura de índice em árvore B.

IOT (index-organized table)

Os dados são divididos em partes menores, mais fáceis de gerenciar.

Tabela particionada

Os dados são armazenados como um conjunto desordenado (heap).

Tabela comum (organizada por heap)

DescriçãoTipo

Heap

IOTParticionada

Clusterizada

Tipos de Tabelas As tabelas comuns “organizadas por heap” são apresentadas no curso Oracle Database 10g: Workshop de Administração I. Partições são partes de uma tabela ou de um índice, criadas para facilitar o gerenciamento de um VLDB (very large database), que pode conter vários terabytes de dados. Diferentemente de uma tabela comum organizada por heap cujos dados são armazenados como um conjunto desordenado (heap), os dados de uma IOT (index-organized table) são armazenados em uma estrutura de índice em árvore B e classificados por chave primária. Um cluster é um grupo de tabelas que compartilham os mesmos blocos de dados, pois elas compartilham colunas comuns e são freqüentemente usadas em conjunto.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




O Que É uma Partição e Por Que Usá-la?

Uma partição é: • Uma parte “muito grande” de uma tabela ou de um

índice • Armazenada em seu próprio segmento • Usada para melhorar o desempenho e a

gerenciabilidade

Tipos de Tabelas> Partição

IOTClusterTarefas do DBA

O Que É uma Partição e Por Que Usá-la? Uma partição é uma parte “muito grande” de uma tabela ou de um índice, armazenada em seu próprio segmento para ser gerenciada individualmente. Um exemplo de tabela “muito grande” é uma tabela de data warehouse de várias centenas de gigabytes de dados. As partições podem ser divididas ainda em subpartições para obter um nível de gerenciabilidade mais detalhado e melhorar o desempenho. O particionamento também pode melhorar o desempenho porque várias consultas podem ignorar as partições que, de acordo com a cláusula WHERE, não têm as linhas solicitadas; dessa forma, o volume de dados a ser varrido para produzir um conjunto de resultados é reduzido. As operações em tabelas e índices particionados podem ser realizadas em paralelo; para tanto, basta designar servidores de execução paralelos a partições diferentes da tabela ou do índice.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Partições

As características das partições são: • Mesmos atributos lógicos: Mesmas colunas,

constraints e índices • Atributos físicos diferentes: Armazenadas em

tablespaces distintos • Transparentes para as aplicações • Vários métodos de particionamento

Partições Cada partição é armazenada em seu próprio segmento e pode ser gerenciada individualmente. Ela pode funcionar independentemente de outras partições, oferecendo, assim, uma estrutura que pode ser ajustada para proporcionar melhor disponibilidade e desempenho. Se você estiver usando execução paralela, as partições oferecerão outros meios de paralelização. As operações em tabelas e índices particionados são realizadas em paralelo; para tanto, basta designar servidores de execução paralelos a partições diferentes da tabela ou do índice, As partições e as subpartições de uma tabela ou de um índice compartilham os mesmos atributos lógicos. Por exemplo, todas as partições (ou subpartições) de uma tabela compartilham as mesmas definições de colunas e constraints, e todas as partições (ou subpartições) de um de índice compartilham as mesmas opções de índice. No entanto, elas podem ter atributos físicos diferentes (como TABLESPACE). É vantajoso armazenar partições em tablespaces diferentes para fazer backups e recuperações independentes, controlando o mapeamento para unidades de disco (balanceando as entradas/saídas) e reduzindo a possibilidade de danos aos dados. O particionamento é transparente para aplicações existentes e instruções DML padrão executadas em tabelas particionadas. No entanto, uma aplicação pode ser programada para aproveitar as vantagens do particionamento usando nomes de índices ou de tabelas estendidos por partições em DML. Para obter mais informações sobre tabelas e índices particionados, incluindo métodos de particionamento, consulte o Oracle Database Administrator’s Guide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando uma Partição

Criando uma Partição O Database Control suporta vários tipos de particionamento de tabelas e índices, além de simplificar o processo de criação desses elementos. Os assistentes orientam esse processo e recomendam as opções possíveis. Selecione Administration > Tables. Na página Tables, clique no botão Create para criar uma tabela particionada. É exibida a página “Create Table: Table Organization”, na qual você pode decidir se deseja criar uma tabela organizada por heap ou por índice. Em seguida, clique no botão Continue para acessar a página Create Table. Nessa página, você pode especificar o nome da tabela e várias outras informações. Clique na tab Partitions e, depois, no botão Create Partitions. A página Create Partitions: Partitioning Method mostrada no slide é aberta. Esse é o ponto de entrada para o assistente de criação de tabelas particionadas. Especifique o tipo de particionamento desejado e clique no botão Continue. O assistente orientará você pelo processo de criação, definindo as colunas de partição e suas especificações.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Métodos de Particionamento

• Particionamento por faixa: Mapeia linhas com base em faixas lógicas de valores de colunas – por exemplo, meses de um ano

• Particionamento por hash: Mapeia linhas com base no valor hash da chave de particionamento

• Particionamento por lista: Mapeia linhas com base em uma lista discreta de valores, fornecida pelo DBA

• Particionamento por faixa/hash: Mapeia linhas usando o método de faixa e, em cada partição por faixa, cria subpartições por hash

• Particionamento por faixa/lista: Mapeia linhas com base, primeiro, em uma faixa de valores e, depois, com base em valores discretos

Métodos de Particionamento • O desempenho do particionamento por faixa é melhor quando os dados são distribuídos

uniformemente na faixa. • O particionamento por hash significa distribuição automática e uniforme de dados: O DBA

não tem controle sobre a forma como uma linha específica é mapeada para uma partição. Por exemplo:

CREATE TABLE regions (region_id NUMBER, region_name VARCHAR2 (25)) PARTITION BY HASH (region_id) PARTITIONS 4 STORE IN (tbs1, tbs2, tbs3, tbs4);

Esse exemplo mostra uma tabela particionada por hash. A coluna de particionamento é id; quatro partições são criadas e recebem nomes gerados pelo sistema; essas partições são colocadas em quatro tablespaces chamados tbs1, tbs2, tbs3 e tbs4.

• Especifique uma lista de valores discretos para a coluna de particionamento na descrição de cada partição se quiser controlar expressamente a forma como as linhas são mapeadas para as partições. Por exemplo, especifique códigos de país e estado.

• As partições compostas, produzidas pelo particionamento por faixa/hash, são ideais para dados históricos e striping.

• As partições de uma tabela particionada por faixa/lista são apenas estruturas lógicas, já que seus dados são armazenados nos segmentos de suas subpartições.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Manutenção da Partição

Manutenção da Partição Após a criação de um objeto particionado, você pode manter suas partições usando o Database Control. Selecione Administration > Tables. Clique na tabela particionada de seu interesse. É exibida a página Edit Table. Clique na tab Partitions dessa página para abrir a tela mostrada no slide. Você pode selecionar uma partição e aplicar uma manutenção de partição a ela, selecionando a operação na lista drop-down Actions. Observação: Use o botão Advanced Options para alterar as características de armazenamento da partição selecionada.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Acesso a tabelaspor ROWID

Tabelas Organizadas por Índice

Acesso comum a tabelas Acesso IOT

Colunas não relacionadas a chaveColuna-chave

Cabeçalho da linha

Tipos de TabelasPartição

> IOT ClusterTarefas do DBA

Tabelas Organizadas por Índice Diferentemente de uma tabela comum (organizada por heap) cujos dados são armazenados como um conjunto desordenado (heap), os dados de uma IOT (index-organized table) são armazenados em uma estrutura de índice em árvore B e classificados por chave primária. Além de armazenar os valores da coluna de chave primária, cada entrada de índice na árvore B da IOT armazena os valores das colunas que não são chaves. As tabelas organizadas por índice têm funcionalidade integral de tabela. Elas suportam recursos como constraints, triggers, colunas de objetos e LOB, particionamento, operações paralelas, reorganização on-line e replicação. Você pode até criar índices em uma tabela organizada por índice. As tabelas organizadas por índice são ideais para as aplicações OLTP, que requerem acesso rápido à chave primária e alta disponibilidade. As consultas e as operações DML em uma tabela de pedidos usada em um processamento on-line de pedidos são predominantemente baseadas em chave primária, e o alto volume de DML causa a fragmentação que resulta em uma necessidade freqüente de reorganização. Como é possível reorganizar uma tabela organizada por índice on-line sem invalidar os índices secundários, o período de indisponibilidade é consideravelmente reduzido ou eliminado. Uma tabela organizada por índice é uma alternativa para:

• Uma tabela indexada na chave primária com a instrução CREATE INDEX• Uma tabela de cluster armazenada em um cluster indexado que foi criado com a instrução CREATE CLUSTER. Essa instrução mapeia a chave primária da tabela para a chave do cluster

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tabelas Organizadas por Índicee Tabelas de Heap

• Comparadas às tabelas de heap, as IOTs: – Permitem acesso baseado em chave mais rápido a

dados de tabelas – Não duplicam o armazenamento de valores de chave

primária – Requerem menos armazenamento – Usam índices secundários e IDs de linha lógicos – Oferecem maior disponibilidade, pois a reorganização

da tabela não invalida os índices secundários • As IOTs têm as seguintes restrições:

– Precisam de uma chave primária que não seja DEFERRABLE

– Não podem ser clusterizadas – Não podem usar particionamento composto – Não podem conter uma coluna do tipo ROWID ou LONG

Tabelas Organizadas por Índice e Tabelas de Heap As tabelas organizadas por índice não têm IDs de linha (físicos) comuns. Elas usam IDs de linha lógicos. Os IDs de linha lógicos permitem o acesso mais rápido possível a linhas de IOTs por dois métodos:

• Uma estimativa física cujo tempo de acesso é igual ao dos IDs de linha físicos • Acesso sem estimativa (ou após uma estimativa incorreta), executado como um acesso de

chave primária da IOT A estimativa se baseia no conhecimento do arquivo e do bloco em que uma linha reside. As informações sobre o bloco são precisas quando o índice é criado, mas são alteradas caso o bloco-folha seja dividido. Se a estimativa estiver errada e a linha deixar de residir no bloco especificado, a parte restante da entrada do ID de linha lógico, a chave primária, será usada para obter a linha. O banco de dados Oracle constrói índices secundários em tabelas organizadas por índice usando IDs de linha lógicos que são baseados na chave primária da tabela. Como as linhas das tabelas organizadas por índice não têm endereço físico permanente, as estimativas físicas podem ficar obsoletas quando as linhas são movidas para novos blocos. Para obter estimativas atualizadas, você pode reconstruir o índice secundário. Observe que a reconstrução de um índice secundário em uma tabela organizada por índice envolve a leitura da tabela-base, diferentemente da reconstrução de um índice em uma tabela comum.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Tabelas Organizadas por Índice e Tabelas de Heap (continuação)Uma maneira mais rápida e simples de corrigir as estimativas é usar a instrução ALTERINDEX ... UPDATE BLOCK REFERENCES. Essa instrução é executada on-line, ao mesmo tempo em que é permitida a operação DML na tabela organizada por índice subjacente. Depois de reconstruir um índice secundário ou atualizar as referências de blocos nas estimativas, colete as estatísticas de índice novamente. O tipo de dados UROWID permite que as aplicações usem IDs de linha lógicos da mesma forma que usam IDs de linha físicos; por exemplo, a seleção de IDs de linha para atualização posterior ou como parte de um cursor. Também é possível usar dados UROWID para armazenar IDs de linha de outros bancos de dados, acessados por meio de gateways. O tipo UROWIDtambém pode ser usado para fazer referência a IDs de linha físicos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando Tabelas Organizadas por Índice

SQL> CREATE TABLE country

2 ( country_id CHAR(2)

3 CONSTRAINT country_id_nn NOT NULL,

4 country_name VARCHAR2(40),

5 currency_name VARCHAR2(25),

6 currency_symbol VARCHAR2(3),

7 map BLOB,

8 flag BLOB,

9 CONSTRAINT country_c_id_pk

10 PRIMARY KEY (country_id))

11 ORGANIZATION INDEX

12 TABLESPACE indx

13 PCTTHRESHOLD 20

14 OVERFLOW TABLESPACE users;

Criando Tabelas Organizadas por Índice As entradas de índice em árvore B normais geralmente são pequenas. Elas consistem apenas no valor da chave primária e em um valor de ID para cada linha. Muitas dessas pequenas entradas de índice podem ser armazenadas em um bloco-folha. Esse nem sempre é o caso das tabelas organizadas por índice porque elas armazenam linhas integrais. O armazenamento de entradas grandes em blocos-folha de índice torna as pesquisas e as varreduras de índice mais lentas. Você pode especificar a transferência das linhas para uma área de overflow definindo um valor-limite que represente uma porcentagem do tamanho do bloco. A coluna de chave primária deve ser sempre armazenada nos blocos de índice da IOT como uma base para a pesquisa. No entanto, você pode inserir valores não relacionados a chaves em uma área separada, a área de overflow de linha, para que a própria árvore B permaneça densamente clusterizada. As tabelas organizadas por índice diferem das tabelas comuns somente na organização física. Logicamente, elas são manipuladas da mesma forma que as tabelas comuns. Você pode especificar uma tabela organizada por índice da mesma forma que define uma tabela comum nas instruções INSERT, SELECT, DELETE e UPDATE. Todas as opções de alteração disponíveis para tabelas comuns estão disponíveis para tabelas organizadas por índice. Elas incluem ADD, MODIFY, DROP COLUMNS e DROPCONSTRAINTS. No entanto, não é possível eliminar, adiar ou desativar a constraint de chave primária de uma tabela organizada por índice.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Clusters

Tabelas orders e order_item clusterizadas

Cluster Key(ORD_NO)

101 ORD_DT CUST_CD05-JAN-97 R01

PROD QTYA4102 20A5675 19 W0824 10

102 ORD_DT CUST_CD07-JAN-97 N45

PROD QTYA2091 11G7830 20 N9587 26

Tabelas orders eorder_item não clusterizadas

ORD_NO ORD_DT CUST_CD------ ------ ------

101 05-JAN-97 R01102 07-JAN-97 N45

ORD_NO PROD QTY ...----- ------ ------

101 A4102 20102 A2091 11102 G7830 20102 N9587 26101 A5675 19101 W0824 10

Tipos de TabelasPartiçãoIOT

> ClusterTarefas do DBA

Definição de Clusters Um cluster é um grupo de uma ou mais tabelas que compartilham os mesmos blocos de dados, pois elas compartilham colunas comuns e são freqüentemente usadas em conjunto em consultas de join. O armazenamento de tabelas em clusters oferece ao DBA um método para desnormalizar os dados. Se você implementar tabelas clusterizadas no banco de dados, não precisará alterar o código da aplicação que acessa as tabelas. Os clusters são transparentes ao usuário final e ao programador. Vantagens de Desempenho Proporcionadas pelos Clusters

• A entrada/saída de disco é reduzida e o tempo de acesso é melhorado para as joins de tabelas clusterizadas.

• Cada valor-chave de cluster é armazenado apenas uma vez para todas as linhas que tenham o mesmo valor-chave; portanto, há um consumo menor do espaço de armazenamento.

Considerações de Desempenho As varreduras integrais de tabela são geralmente mais lentas em tabelas clusterizadas do que em tabelas não clusterizadas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tipos de Cluster

Cluster de índiceCluster de hash

classificadoClusterde hash

1

2

3

Function de hash Function de hash

Tipos de Cluster Clusters de ÍndicesUm cluster de índice usa um índice, denominado índice de cluster, para manter os dados no cluster. O índice de cluster deve estar disponível para armazenar, acessar ou manter dados em um cluster de índice. O índice de cluster é usado para apontar para o bloco cujas linhas têm um valor-chave especificado. A estrutura de um índice de cluster é semelhante à de um índice normal. Apesar de um índice normal não armazenar valores-chave nulos, os índices de cluster armazenam chaves nulas. Existe apenas uma entrada para cada valor-chave no índice de cluster. Conseqüentemente, é provável que um índice de cluster seja menor que um índice normal no mesmo conjunto de valores-chave. Clusters de Hash Um cluster de hash usa um algoritmo de hash (definido pelo usuário ou gerado pelo sistema) para calcular a localização de uma linha, tanto para recuperação como para operações DML. Em pesquisas de igualdade que usam a chave de cluster, um cluster de hash pode proporcionar maior ganho de desempenho que um cluster de índice, pois há apenas um segmento a ser varrido (não é necessário acessar o índice).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Tipos de Cluster (continuação)Clusters de Hash Classificados Em um cluster de hash classificado, as linhas são organizadas em listas de linhas ordenadas. Cada lista corresponde a um valor específico das colunas-chave de hash definidas pelo cluster de hash classificado associado. Em cada lista, as linhas são armazenadas na ordem especificada pelas colunas-chave de classificação definidas pelo cluster de hash classificado correspondente. Essa é também a ordem de retorno default quando a tabela de cluster de hash classificada é consultada usando-se colunas-chave de hash no predicado. Os clusters de hash classificados oferecem a vantagem de eliminar a memória particular e o tempo de CPU necessários para classificar os dados em consultas que requerem uma ordem de retorno garantida entre as instruções SQL.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Situações em que os Clusters São Úteis

Os dados são recuperados na ordem em que foram inseridos

Consultas que usam predicado de igualdade em chaves

Número previsível de valores-chave

Tabelas-mestre/detalhadas freqüentemente unidas

Chave raramente atualizada

Valores-chave distribuídos uniformemente

Distribuição uniforme de chaves

Hashclassificado Hash Índice Critério

Situações em que os Clusters São Úteis Quando Não Usar Clusters

• Se a aplicação só usar consultas que unem tabelas ocasionalmente ou modificar os valores das colunas comuns com freqüência. A modificação do valor-chave de cluster de uma linha demora mais que a modificação do valor em uma tabela não clusterizada porque o banco de dados Oracle talvez precise migrar a linha modificada para outro bloco a fim de manter o cluster.

• Se uma varredura integral for executada com freqüência em apenas uma das tabelas clusterizadas. Essa tabela será armazenada em mais blocos do que se tivesse sido criada sozinha.

• Se os dados de todas as linhas de um valor-chave de cluster excederem um ou dois blocos do Oracle. Para acessar uma linha individual de uma tabela-chave clusterizada, o servidor Oracle lê todos os blocos que contêm linhas com o mesmo valor.

Quando Não Usar Clusters de Hash • Se a tabela crescer constantemente ou se a aplicação modificar os valores-chave de cluster

com freqüência • Se a aplicação executar varreduras integrais de tabela freqüentes e você precisar alocar um

grande volume de espaço para o cluster de hash por prever o crescimento da tabela Os clusters de hash e de índice exigem muito planejamento antes de sua utilização. Pode haver mais overhead de desempenho em operações maiores como inserções (de caminho direto) em alto volume e rebuilds.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Cluster de Hash Classificado: Visão Geral

• Nova estrutura de dados usada para armazenar dados classificados por colunas-chave não primárias: – Há uma operação de hash com valores-chave do cluster. – As linhas correspondentes a um valor-chave do cluster

específico são ordenadas de acordo com a chave de classificação.

• Usado para garantir que a ordem das linhas seja retornada por consultas sem dados classificados: – As linhas são retornadas em ordem crescente ou

decrescente de acordo com um valor-chave de cluster específico.

– A cláusula ORDER BY não é obrigatória para recuperar linhas em ordem crescente.

Cluster de Hash Classificado: Visão Geral Quando o banco de dados Oracle armazena dados em uma tabela organizada por heap, as linhas não são armazenadas em uma ordem controlada pelo usuário. Em vez disso, a decisão sobre onde colocar uma linha depende da eurística de armazenamento. O banco de dados Oracle não garante a ordem de retorno das linhas, a menos que a consulta inclua uma cláusula ORDER BY. Em um cluster de hash classificado, as linhas são organizadas em listas de linhas ordenadas. Cada lista corresponde a um valor específico das colunas-chave de hash definidas pelo cluster de hash classificado associado. Em cada lista, as linhas são armazenadas na ordem especificada pelas colunas-chave de classificação definidas pelo cluster de hash classificado correspondente. Essa é também a ordem de retorno default quando a tabela é consultada usando-se colunas-chave de hash no predicado. Os clusters de hash classificados oferecem a vantagem de eliminar a memória particular e o tempo de CPU necessários para classificar os dados em consultas que requerem uma ordem de retorno garantida entre as instruções SQL. Quando o otimizador consulta dados em uma tabela clusterizada de hash classificada por colunas-chave de cluster com uma cláusula ORDER BY que só faz referência às colunas-chave de classificação ou a um de seus prefixos, ele evita o overhead de classificação, já que as linhas são retornadas ordenadas pelas colunas-chave de classificação. No entanto, para o mesmo tipo de consulta, se houver uma cláusula ORDER BY em um sufixo das colunas-chave de classificação ou das colunas-chave não-utilizadas para classificação, será necessária uma ordenação adicional, supondo que não existam índices definidos na tabela. Por esse motivo, ao criar um cluster de hash classificado, selecione as colunas-chave de ordenação correspondentes com cuidado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Cluster de Hash Classificado: Exemplo

CREATE CLUSTER calls_cluster( origin_number NUMBER, call_timestamp NUMBER SORT, call_duration NUMBER SORT)HASHKEYS 10000SINGLE TABLE HASH IS origin_numberSIZE 50;

CREATE TABLE calls( origin_number NUMBER, call_timestamp NUMBER , call_duration NUMBER , other_info VARCHAR2(30))CLUSTER calls_cluster(origin_number,call_timestamp,call_duration);

Chave de cluster

Chave declassificação

Cluster de Hash Classificado: Exemplo A forma de definir os clusters de hash classificados é muito semelhante à maneira de criar clusters de hash tradicionais. Na primeira etapa, você cria o cluster de hash classificado. Como você pode observar, a diferença mais importante de um cluster de hash tradicional é a necessidade de definir as colunas-chave de classificação e as colunas-chave de cluster. Neste exemplo, a chave de cluster é ORIGIN_NUMBER, e as colunas-chave de classificação são CALL_TIMESTAMP e CALL_DURATION. Outra diferença dos clusters de hash tradicionais é que, nos clusters de hash classificados, o parâmetro SIZE especifica quantas entradas de metadados devem ser armazenadas para um valor-chave de hash específico. O tamanho de uma entrada de metadados é determinado principalmente pelo tamanho das colunas-chave de cluster. Na segunda etapa, crie a tabela real especificando o link com o cluster de hash classificado, por meio da cláusula CLUSTER. É necessário especificar as colunas-chave de cluster na ordem correta seguidas pelas colunas-chave de classificação também na ordem correta. O exemplo do slide representa o seguinte cenário: uma empresa de telecomunicações precisa armazenar os registros de chamadas de um número fixo de telefones que originaram essas chamadas por meio de um comutador de telecomunicações. Cada telefone pode gerar um número ilimitado de chamadas telefônicas. As chamadas são armazenadas à medida que são realizadas e processadas, de acordo com a ordem da primeira chamada recebida/originada quando são geradas as contas para cada telefone de origem. Cada chamada é identificada por um número de timestamp. Observação: Embora o exemplo use um cluster de hash de uma tabela, você pode armazenar mais de uma tabela em um cluster de hash classificado. Nesse aspecto, os clusters de hash tradicionais e classificados são semelhantes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Cluster de Hash Classificado:Arquitetura Básica

Chave de cluster 2…

Chave de cluster 1

Chave de cluster n

HASHKEYS

SIZE

…

Pontos iniciais decadeias de blocos

Linhas classificadas por chave de

classificação emcada cadeia de blocos

Cluster de Hash Classificado: Arquitetura Básica No exemplo do slide anterior, apenas uma tabela é armazenada no cluster de hash classificado. Além disso, a function de hash é bem simples e não são esperadas colisões. Isso porque a function de hash é determinada pela própria chave de cluster e cada valor-chave de cluster é exclusivo. Basicamente, HASHKEYS representa o número de diferentes telefones de origem e SIZE representa o número de bytes usados para armazenar os metadados de chave de cluster. Como você pode observar, a primeira parte do segmento de cluster de hash classificado é reservada para armazenar entradas de metadados. Cada entrada de metadados contém um link para a lista de linhas correspondentes. Cada lista é composta por uma série de blocos Oracle vinculados. Cada lista é classificada de acordo com as colunas-chave de classificação. Sempre que você quiser recuperar as linhas de um valor-chave de cluster correspondente, ocorrerá uma operação de hash com esse valor até o local da respectiva entrada de metadados, que fornece a lista classificada de linhas selecionadas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tarefas de Gerenciamentode Esquemas

As tarefas do DBA incluem: • Estimar o tamanho de novas tabelas • Analisar tendências de crescimento • Gerenciar estatísticas do otimizador • Reorganizar objetos de esquema on-line

Tipos de TabelasPartição IOT Cluster

> Tarefas do DBA

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Estimando a Utilização de Recursos

Estimando a Utilização de Recursos A função de estimativa de recursos permite estimar o volume de recursos exigido pela criação de um novo segmento. Com base na estrutura de uma tabela ou de um índice e no número de linhas estimadas da tabela, o banco de dados Oracle calcula o volume de espaço em disco que o objeto possivelmente consumirá. Por exemplo, a estimativa do tamanho da tabela é baseada nos seguintes dados: tipos de dados das colunas, tamanhos das colunas e PCTFREE. As informações sobre extensões também são usadas para calcular o impacto da alocação de espaço no tablespace selecionado no momento. Para acessar esse recurso para tabelas, na página Administration, selecione Tables na seção Storage e clique em Create para criar a nova tabela. Você também pode usar a funcionalidade “Create like”. Especifique o tablespace e as colunas com os tipos de dados e os tamanhos e clique no botão “Estimate Table Size”. Agora, especifique “Projected Row Count” e clique no botão “Estimate Table Size” para obter o tamanho estimado da tabela e o espaço correspondente alocado no tablespace.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Analisando Tendências de Crescimento

Relatório de tendência de crescimento do EM: • Usado pelo Segment Advisor • Estatísticas de utilização de espaço coletadas no AWR

Analisando Tendências de Crescimento Os relatórios de crescimento de segmentos disponibilizam dados críticos de crescimento para advisories e ferramentas de geração de relatórios, como o Segment Advisor e o gráfico Growth Trend Report. Algumas características do recurso de geração de relatórios de tendência de crescimento incluem:

• Análise de dados do Automatic Workload Repository. O Workload Repository coleta as estatísticas persistentes de utilização de espaço e as armazena em um esquema definido pelo sistema. Essas estatísticas são capturadas durante a criação de snapshots e quando são acionados alertas.

• Indicações da tendência de crescimento anterior e previsões de padrões de crescimento futuro

• Suporte somente a tablespaces gerenciados localmente O relatório de tendência de crescimento consiste em dois componentes: histórico de crescimento e previsão de crescimento. O histórico de crescimento é um gráfico dos dados de utilização de espaço no passado. A previsão de crescimento prevê as necessidades de espaço futuras usando as informações de histórico e a projeção linear. No Database Control, selecione Administration > Tables. Selecione a tabela desejada, clique em Edit e clique na página com a tab Segments. A tela mostra esse relatório. Você pode escolher o período de análise e, no gráfico calculado, ver o momento em que talvez seja necessário alocar mais espaço para o seu segmento.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciando Estatísticas do Otimizador

Não analisado 1

23

Gerenciando Estatísticas do Otimizador As melhores práticas recomendam a coleta de estatísticas depois de atividades DML importantes, como após a inserção de 9.000 linhas. A lista de tabelas do exemplo (1) mostra que a tabela TEST_REGIONS não foi analisada. No Enterprise Manager, escolha Administration > Tables. Selecione “Manage Optimizer Statistics” na lista drop-down Actions (2) e siga o assistente (3) para criar um job Optimizer Statistics.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Reorganizando Objetos de Esquema On-line

• Modificando a estrutura lógica ou física de um objeto de esquema, como uma tabela ou um índice

• Transparente para usuários• Requisitos de espaço

Reorganizando Objetos de Esquema On-line Às vezes, é necessário modificar a estrutura lógica ou física de uma tabela para gerenciar o armazenamento, melhorar o desempenho ou acomodar novas aplicações. Para executar essas tarefas, enquanto a tabela fica acessível a consultas e DML, use o assistente Reorganize Objects do Enterprise Manager ou o package DBMS_REDEFINITION. A reorganização de tabelas on-line aumenta significativamente a disponibilidade em comparação com os métodos tradicionais de redefinição de tabelas. A tabela é bloqueada no modo exclusivo apenas por um período muito breve, independente de seu tamanho e da complexidade da redefinição, e fica completamente transparente para os usuários. O processo requer um volume de espaço livre aproximadamente equivalente ao espaço usado pela tabela que está sendo redefinida. Talvez seja necessário mais espaço se novas colunas forem adicionadas. A reorganização on-line pode ser usada para:

• Reconstrução de índices fragmentados • Reconstrução de tabelas fragmentadas • Realocação de objetos para outro tablespace • Recriação de objetos com atributos de armazenamento melhores

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Reorganizando Objetos de Esquema On-line (continuação)Opções para personalizar a reorganização:

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Reorganizando Objetos:Relatório de Impacto

Reorganizando Objetos: Relatório de Impacto Antes da execução de qualquer comando, o relatório de impacto apresenta erros ou advertências, bem como uma visão geral das atividades planejadas, como a reconstrução de um índice.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Reorganizando Objetos: Revisão

Reorganizando Objetos: Revisão Para conhecer detalhes sobre os comandos que serão executados, selecione Full Script e examine todas as instruções relevantes. Se preferir uma visão geral mais simples dessa reorganização, selecione Script Summary.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Etapas Básicas daReorganização Manual On-line

1. Verifique se a tabela é candidata à reorganização on-line.

2. Crie uma tabela provisória.3. Inicie o processo de redefinição. 4. Copie os objetos dependentes. (Essa ação cria

automaticamente triggers, índices, concessões e constraints na tabela provisória.)

5. Consulte a view DBA_REDEFINITION_ERRORS para verificar erros.

6. Como alternativa, sincronize a tabela provisória.7. Conclua a redefinição. 8. Elimine a tabela provisória.

Etapas Básicas da Reorganização Manual On-line Comandos e procedures usados:

1. DBMS_REDEFINITION.CAN_REDEF_TABLE 2. CREATE TABLE … 3. DBMS_REDEFINITION.START_REDEF_TABLE4. DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS and DBMS_REDEFINITION.CONS_ORIG_PARAMS

5. SELECT object_name, base_table_name, ddl_txtFROM DBA_REDEFINITION_ERRORS;

6. DBMS_REDEFINITION.SYNC_INTERIM_TABLE 7. DBMS_REDEFINITION.FINISH_REDEF_TABLE 8. DROP TABLE … PURGE

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a gerenciar objetos de esquema e a: • Determinar os tipos de tabela adequados aos seus

requisitos • Executar tarefas do DBA correlatas:

– Estimar o tamanho de novas tabelas – Analisar tendências de crescimento – Gerenciar estatísticas do otimizador – Reorganizar objetos de esquema on-line

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício:Gerenciando Objetos de Esquema

Este exercício aborda os seguintes tópicos: • Monitoramento da utilização do espaço de tabela e

de índice • Gerenciamento de estatísticas do otimizador • Reorganização de tabelas e índices

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Gerenciando o Armazenamento

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Após concluir esta lição, você será capaz de:• Descrever como o banco de dados Oracle gerencia

espaço automaticamente • Monitorar e gerenciar de forma pró-ativa o uso do

espaço de tablespaces • Usar o Segment Advisor• Reutilizar o espaço desperdiçado de tabelas e

índices com a funcionalidade de compressão desegmentos

• Gerenciar a alocação do espaço retomável • Descrever os conceitos de bancos de dados e

tablespaces transportáveis

• Gerenciamentode Espaço

• Monitoramento Pró-ativo

• Seg. Advisore Compr. Seg.

• Alocação Retomável

• TBS e DBTransportáveis

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciamento do Espaço: Visão Geral O espaço é gerenciado automaticamente pelo banco de dados Oracle. Ele gera alertas sobre problemas potenciais e recomenda possíveis soluções. Osrecursos incluem: • OMF (Oracle Managed Files)• Gerenciamento de espaço livre com bitmaps

(“gerenciados localmente”) e extensão automáticade arquivos de dados

• Gerenciamento de espaço pró-ativo (limites default ealertas gerados pelo servidor)

• Reutilização de espaço (compressão de segmentos,redefinição de tabelas on-line)

• Planejamento de capacidade (relatórios decrescimento)

Gerenciamento do Espaço: Visão Geral Com o OMF (Oracle Managed Files), você pode especificar operações em termos de objetosdo banco de dados, em vez de nomes de arquivos. Para obter mais detalhes, consulte a lição “Introdução”. O banco de dados Oracle gerencia o espaço livre em uma tabela com bitmaps, conhecidocomo tablespace “gerenciado localmente”. (Tablespaces gerenciados por dicionário são suportados apenas para fins de retrocompatibilidade.) A implementação de bitmap eliminaboa parte do ajuste de espaço das tabelas e, ao mesmo tempo, melhora o desempenho durante cargas de pico. Além disso, o banco de dados Oracle fornece extensão automática de arquivos de dados; assim, os arquivos podem crescer automaticamente com base no volume de dados neles contidos. Quando você cria um banco de dados, o monitoramento de espaço pró-ativo é ativado por default. (Esse monitoramento não causa impacto no desempenho.) O banco de dados Oracle monitora a utilização do espaço durante as operações normais de alocação e desalocação de espaço e alerta-o quando a disponibilidade de espaço livre fica abaixo dos limitespredefinidos (que você pode sobrepor). Advisors e assistentes auxiliam na reutilização de espaço. Para fins de planejamento da capacidade, o banco de dados Oracle fornece estimativas deespaço com base na estrutura de tabela e no número de linhas, bem como um relatório de tendência de crescimento baseado no histórico de utilização de espaço armazenado no AWR (Automatic Workload Repository). O curso Oracle Database 10g: Workshop de Administração I apresenta os conceitos deespaço e armazenamento, utilitários correlatos e tarefas do DBA. Por meio dessa e de outras fontes, você pode se familiarizar com os conceitos básicos e com os recursos dearmazenamento.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciamento do Espaço Livre

• Automático• Ativado pelo uso de

tablespaces gerenciadas localmente

• Rastreado por bitmapsem segmentos

Vantagens:• Utilização de espaço

mais flexível• Ajuste de runtime• Pesquisa de BMBs por

vários processos{Extensão

BMB BMB

Blocodedados

… … … …

…

…

…

…

…

…

…

BMB

BMB

BMB

BMB

BMB

Segmento

Gerenciamento do Espaço Livre É possível gerenciar automaticamente o espaço livre em segmentos do banco de dados. O espaço livre ou utilizado em segmentos é rastreado com bitmaps. Ao criar um tablespace gerenciado localmente, especifique o Gerenciamento Automático do Espaço em Segmentos. A especificação se aplicará a todos os segmentos criados posteriormente nesse tablespace. Os segmentos do gerenciamento automático de espaço contêm um conjunto de blocos de bitmap (BMBs) que descreve a utilização de espaço dos blocos de dados nesses segmentos. Os BMBs são organizados em uma hierarquia em árvore. O nível raiz da hierarquia, que contém as referências a todos os BMBs intermediários, é armazenado no cabeçalho do segmento. As folhas da hierarquia representam as informações sobre espaço de um conjunto de blocos de dados contíguos pertencente ao segmento. O número máximo de níveis nessa hierarquia é três. Vantagens do uso do gerenciamento automático de espaço (comparado ao gerenciamento manual, que usa estruturas de dados de “free list” e é sinônimo de tablespace “gerenciada por dicionário”)

• Melhor utilização do espaço, especialmente para os objetos com linhas de tamanho altamente variável

• Melhor ajuste de runtime às variações no acesso concorrente • Melhor comportamento de várias instâncias em termos de utilização de espaço ou

desempenho Portanto, menos trabalho para você, DBA.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tipos de Segmentos

Um segmento é um conjunto de extensões alocadas para uma estrutura lógica específica. Os diferentes tipos de segmentos são: • Segmento de dados • Segmento de índice • Segmento temporário Os segmentos são alocados dinamicamente pelo banco de dados.

Tipos de Segmentos Segmento de dados: Cada tabela não clusterizada tem um segmento de dados. Todos os dados da tabela são armazenados nas extensões do segmento de dados. Em uma tabela particionada, cada partição tem um segmento de dados. Cada cluster tem um segmento de dados. Os dados de cada tabela no cluster são armazenados no segmento de dados do cluster. Segmento de índice: Cada índice tem um segmento de índice que armazena todos os seus dados. Em um índice particionado, cada partição tem um segmento de índice. Segmento temporário: Quando uma instrução SQL precisa de uma área temporária no banco de dados para concluir uma execução, o banco de dados Oracle cria um segmento temporário. Quando a execução da instrução é concluída, as extensões do segmento temporário são retornadas ao sistema para uso futuro. O banco de dados Oracle aloca espaço dinamicamente quando as extensões existentes de um segmento ficam cheias. Como as extensões são alocadas à medida que se tornam necessárias, elas podem ou não ser contíguas no disco.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Alocando Extensões

• Pesquisa do número exigido de blocos livres adjacentes no bitmap do arquivo de dados

• Dimensionamento das extensões com cláusulas de armazenamento: – UNIFORM

– AUTOALLOCATE

• Exibição do mapa deextensão

• Obtenção darecomendação de desalocação

Alocando Extensões Em tablespaces gerenciados localmente, o banco de dados Oracle procura espaço livre a ser alocado para uma nova extensão. Primeiro, ele determina um arquivo de dados candidato no tablespace e, então, pesquisa no bitmap desse arquivo o número exigido de blocos livres adjacentes. Se o arquivo de dados não tiver espaço livre adjacente suficiente, o banco de dados Oracle examinará outro arquivo de dados. Duas cláusulas afetam o dimensionamento de extensões:

• Com a cláusula UNIFORM, o banco de dados cria todas as extensões em um tamanho uniforme especificado por você (ou em um tamanho default) para qualquer objeto criado no tablespace.

• Com a cláusula AUTOALLOCATE, o banco de dados determina a política de dimensionamento de extensões para o tablespace.

Para ver o mapa de extensão no Enterprise Manager, escolha Administration > Tablespaces > View Tablespace > Show Tablespace Contents. O banco de dados Oracle fornece o Segment Advisor, que ajuda a determinar se um objeto tem espaço disponível para reutilização com base no nível de fragmentação de espaço no objeto.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciamento do Espaço em Bloco

PCTFREE = 10

Deleções

Bloco cheio

Inserções,atualizações

Deleções

FS2

FS3

FS1

FS2

FS3

FS4

FS1

Bloco cheio

Gerenciamento do Espaço em Bloco O gerenciamento do espaço envolve a administração do espaço livre em nível de bloco. Com o Gerenciamento Automático do Espaço em Segmentos, cada bloco é dividido em quatro seções, chamadas FS1 (entre 0% e 25% de espaço livre), FS2 (25% a 50%), FS3 (50% a 75%) e FS4 (75% a 100%). Dependendo do nível de espaço livre no bloco, seu status é atualizado automaticamente. Dessa maneira, dependendo do tamanho de uma linha inserida, é possível saber se determinado bloco pode ser usado para atender a uma operação de inserção. Observe que o status “cheio” indica que o bloco não está mais disponível para inserções. No exemplo do slide, o bloco à esquerda é um bloco FS3, pois tem entre 50% e 75% de espaço livre. Após algumas instruções de inserção e de atualização, PCTFREE é atingido (a linha tracejada) e não é mais possível inserir novas linhas nesse bloco. Agora o bloco é considerado “cheio” ou do tipo FS1. O bloco poderá ser usado novamente em inserções tão logo seu nível de espaço livre fique abaixo do nível da seção seguinte. No caso acima, ele terá o status FS2 assim que o espaço livre for maior que 25%. Observação: Os tipos de dados LOB (Large Object), como BLOB, CLOB, NCLOB e BFILE, não utilizam o parâmetro de armazenamento PCTFREE. Para obter mais informações, consulte o documento Oracle Database Application Developer’s Guide - Large Objects 10g Release 2 (10.2).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Encadeamento e Migração de Linhas

Exemplo:• Em atualizações: O tamanho da linha

aumenta, excedendo o espaço livre disponível no bloco.

• Os dados precisam ser armazenados em outro bloco.

• O identificador físico original da linha (ROWID) é preservado.

• O banco de dados Oracle precisa ler dois blocos para recuperar os dados.

• O Segment Advisor encontra os segmentos que contêm as linhas migradas.

Antigos

Bloco original com ponteiro

para linha migrada

Novosdados

Encadeamento e Migração de Linhas Em duas circunstâncias, os dados de uma linha de uma tabela podem ser muito grandes para caber em um único bloco de dados. No primeiro caso, a linha é muito grande e não se encaixa em um bloco de dados ao ser inserida pela primeira vez. Nesse caso, o banco de dados Oracle armazena os dados da linha em uma cadeia (de um ou mais) blocos de dados reservados para o segmento em questão. O encadeamento de linhas ocorre com mais freqüência em linhas grandes, como as que contêm uma coluna do tipo de dados LONG ou LONG RAW. Nesses casos, o encadeamento de linhas é inevitável. No segundo caso, porém, uma linha que cabia originalmente em um bloco de dados é atualizada, o que resulta no aumento de seu tamanho geral e no preenchimento completo do espaço livre do bloco. Nesse caso, o banco de dados Oracle migra os dados da linha inteira para um novo bloco de dados, supondo que essa linha vá caber no novo bloco. O banco de dados preserva o trecho de linha original de uma linha migrada para apontar para o novo bloco que contém a linha migrada. O ROWID de uma linha migrada não se altera. Quando uma linha é encadeada ou migrada, ocorre uma redução no desempenho de entrada/saída associado a ela porque o banco de dados Oracle precisa varrer mais de um bloco de dados para obter as informações referentes à linha. O Segment Advisor encontra os segmentos que contêm linhas migradas resultantes de UPDATE.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitoramento Pró-ativode Tablespaces

Gerenciamento de Espaço

> Monitoramento Pró-ativoSeg. Advisore Compr. Seg.Alocação RetomávelTBS e DB Transportáveis

Monitoramento Pró-ativo de Tablespaces O banco de dados gerencia de maneira pró-ativa o uso do espaço em disco de tablespaces das seguintes formas:

• Você é informado por alertas do banco de dados quando há pouco espaço disponível em disco para um tablespace e quando há falta de espaço para segmentos específicos. Assim, você pode fornecer mais espaço em disco para o tablespace, evitando condições de falta de espaço.

• As informações coletadas são armazenadas no AWR (Automatic Workload Repository) e usadas para realizar a análise da tendência de crescimento e o planejamento da capacidade do banco de dados.

Para exibir e modificar informações sobre tablespaces no Enterprise Manager, selecione Administration > Tablespaces. Selecione o tablespace desejado e clique no botão Edit.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Limites e Resolução de Problemas de Espaço

Resolva problemas de espaço:• Adicionando ou redimensionando um arquivo de dados• Definindo AUTOEXTEND ON• Comprimindo objetos• Reduzindo UNDO_RETENTION • Procurando consultas de duração longa em

tablespaces temporários

85% cheio ou 100 MB de espaço advertência

97% cheio ou 5 MB de espaço crítico

Resolva o problema de espaço

Alerta

Tablespace gerenciado localmente

DBA

Limites e Resolução de Problemas de Espaço Os limites dos tablespaces são definidos como espaço cheio ou disponível. Há dois tipos de limites aplicáveis a um tablespace: crítico e de advertência. O package DBMS_SERVER_ALERTcontém procedures que permitem definir e obter os valores-limite. Quando os limites do tablespace são alcançados, é emitido o alerta adequado. O limite é expresso com base no percentual do tamanho do tablespace ou em bytes livres restantes. Ele é calculado na memória. Você pode definir um limite percentual e outro baseado em bytes para um tablespace. Um desses limites, ou ambos, pode gerar um alerta.A definição ideal para o valor do trigger do limite de advertência resulta em um alerta precoce o suficiente para garantir que você tenha tempo para resolver o problema antes que ele se torne crítico, mas tardio o bastante para que você não se preocupe com questões de espaço antes da hora. O alerta indica que o problema pode ser resolvido das seguintes maneiras:

• Adicionando mais espaço ao tablespace por meio do fornecimento de um arquivo ou do redimensionamento de arquivos existentes, ou tornando um arquivo existente auto-expansível

• Liberando espaço nos discos que contêm arquivos auto-expansíveis • Comprimindo objetos esparsos no tablespace

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitorando a Utilização doEspaço para Tablespaces

• Tablespaces off-line e somente para leitura: Não configure alertas.

• Tablespace temporário: O limite corresponde ao espaço utilizado no momento pelas sessões.

• Tablespace de undo: O limite corresponde ao espaço utilizado pelas extensões ativas e não expiradas.

• Arquivos auto-expansíveis: O limite é baseado no tamanho máximo de arquivo.

MMON

85% Advertência

97% Crítico

Verificação a cada10 minutos

Alerta

Alerta Removido

Removido

Monitorando a Utilização do Espaço para Tablespaces O banco de dados rastreia a utilização do espaço enquanto executa atividades comuns de gerenciamento de espaço. Essas informações são agregadas pelo processo MMON a cada 10 minutos. É acionado um alerta quando o limite de um tablespace é atingido ou removido.

• Não devem ser emitidos alertas para tablespaces que estão no modo somente para leitura ou que foram colocados off-line, pois não há muito o que fazer sobre eles.

• Nos tablespaces temporários, o valor-limite deve ser definido como uma limitação ao espaço utilizado no tablespace.

• Em tablespaces de undo, uma extensão será reutilizável se não contiver segmentos de undo ativos ou não expirados. Para calcular a violação de limites, a soma de extensões ativas e não expiradas é considerada espaço utilizado.

• Em tablespaces com arquivos auto-expansíveis, os limites são calculados de acordo com o tamanho máximo de arquivo especificado ou com o tamanho máximo de arquivo do sistema operacional.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comprimindo Segmentos

HWM

HWM

HWM

ALTER TABLE employees SHRINK SPACE COMPACT;1

ALTER TABLE employees SHRINK SPACE;2

É possível executar consultas e operações DML durante a compactação.

As operações DML são bloqueadas quando a HWM é ajustada.

Gerenciamento de Espaço Monitoramento Pró-ativo

> Seg. Advisor e Compr. Seg.Alocação RetomávelTBS e DB Transportáveis

Comprimindo Segmentos A ilustração do slide descreve as duas fases de uma operação de compressão de tabela. A primeira fase é a compactação. Durante essa fase, as linhas são movidas ao máximo para aparte esquerda do segmento. Internamente, as linhas são movidas por pacotes para evitar problemas de bloqueio. Depois que as linhas são movidas, a segunda fase da compressão é iniciada. Durante essa fase, a HWM (High-Water Mark) é ajustada e o espaço não utilizado é liberado.A cláusula COMPACT será útil se você tiver consultas de longa duração que possam sobrecarregar a operação de compressão, tentando ler blocos cujo espaço foi reutilizado.Quando você especifica a cláusula SHRINK SPACE COMPACT, o andamento da compressãoé salvo nos blocos de bitmap do segmento correspondente. Isso significa que, na próxima vez que uma operação de compressão for executada no mesmo segmento, o banco de dadosOracle lembrará do que já foi feito. Você poderá, então, executar novamente a cláusulaSHRINK SPACE sem a cláusula COMPACT fora dos horários de pico para concluir asegunda fase.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Resultados da Operação de Compressão

• Desempenho e utilização de espaço melhores • Índices mantidos • Triggers não executados • Possível redução no número de linhas migradas • Recriação de índices secundários em IOTs

recomendada

DBAComprimir

Triggers não executados

Tabela

Índice

Resultados da Operação de Compressão A compressão de um segmento preenchido de forma dispersa melhora o desempenho de operações DML e varreduras no segmento porque há menos blocos a serem observados depois que o segmento é comprimido. Isso se aplica principalmente a:

• Varreduras integrais de tabelas (blocos menos numerosos e mais densos) • Melhoria de acesso a índices (menos operações de entrada/saída em varreduras de ROWID

por faixa como resultado de uma árvore mais compacta) Além disso, comprimindo os segmentos preenchidos de forma dispersa, você melhora a eficiência da utilização do espaço no banco de dados porque disponibiliza um espaço livre maior para os objetos que precisam. A dependência de índices é tratada durante a operação de compressão de segmentos. Os índices permanecem utilizáveis depois da compressão da tabela correspondente. Portanto, a manutenção não é mais necessária. A compressão é tratada internamente como uma operação INSERT/DELETE. Entretanto, nenhum trigger DML é executado, pois os dados propriamente ditos não são alterados. Como resultado de uma operação de compressão de segmento, é possível que o número de linhas migradas seja reduzido. Entretanto, nem sempre você deve contar com a redução do número de linhas migradas após a compressão de um segmento. Isso porque uma operação de compressão de segmento talvez não afete todos os blocos do segmento. Portanto, não é possível assegurar que todas as linhas migradas sejam incluídas na operação. Observação: É recomendável reconstruir índices secundários em uma IOT (tabela organizada por índice) após uma operação de compressão.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Reutilização de Espaço com o ASSM

• Operação on-line no local • Aplicável somente a segmentos que residem em

tablespaces com ASSM • Tipos de segmentos candidatos:

– Tabelas organizadas por heap e por índice – Índices – Partições e subpartições – Views materializadas e logs de views materializadas

Reutilização de Espaço com o ASSM Uma operação de compressão é uma operação on-line no local, pois não precisa de espaço extra do banco de dados para ser executada.

• Você não pode executar uma operação de compressão em segmentos gerenciados por free lists. É possível comprimir segmentos de tablespaces com espaço gerenciado automaticamente. No entanto, não é possível comprimir os seguintes objetos armazenados em tablespaces com ASSM:

– Tabelas em clusters – Tabelas com colunas LONG– Tabelas com views materializadas no commit – Tabelas com views materializadas baseadas em ROWID– Tabelas de mapeamento de IOTs – Tabelas com índices baseados em function

• É necessário ativar ROW MOVEMENT para segmentos organizados por heap. Observação: O ASSM (Automatic Segment Space Management) é o tipo default degerenciamento de espaço em segmentos para todos os tablespaces novos, permanentes e localmente gerenciados do Oracle Database 10g Release 2.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Segment Advisor: Visão Geral

Segment Advisor: Visão Geral O Segment Advisor determina se um objeto é um bom candidato a uma operação de compressão. O advisor também localiza os segmentos que contêm linhas migradas resultantes de UPDATE. (A partir do Oracle Database 10.2, os jobs do Segment Advisor são automaticamente executados.) O advisor faz recomendações com base no volume de espaço não utilizado que pode ser liberado e leva em consideração as necessidades estimadas de espaço no futuro, usando os critérios das informações coletadas sobre as tendências de crescimento de segmentos. Depois que as recomendações são feitas, você pode optar por implementá-las. É possível chamar o Shrink Advisor no nível do segmento ou do tablespace. A Console do EM Database Control é a interface com o Segment Advisor. Você pode acessar o Segment Advisor em diversos locais no Enterprise Manager:

• Página Advisor Central • Página Tablespaces • Páginas de objetos de esquema

A Console do Database Control permite selecionar várias entradas e programar um job que chama o Segment Advisor para obter uma sugestão de compressão. É possível chamar o assistente do Segment Advisor fora de um contexto ou no contexto de um tablespace ou de um objeto de esquema. O Segment Advisor faz recomendações com base na amostra de análise, nas informações históricas e nas tendências de crescimento futuro.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Segment Advisor

Segment Advisor Na página Administration, selecione Tablespaces na seção Storage. Na página Tablespaces, selecione o tablespace sobre o qual deseja executar a análise de compressão e escolha Run Segment Advisor na lista drop-down Actions. Clique em Go para abrir a página inicial do Segment Advisor. Escolha o modo de análise “abrangente” “ou “limitado”. No modo abrangente, a análise é mais longa porque o advisor cria amostras dos segmentos para identificar os destinos corretos. Clique em Continue diversas vezes para responder às perguntas do advisor. Você será levado à página Segment Advisor: Review, onde poderá verificar os detalhes da análise. A análise do Segment Advisor é executada como um job programado; portanto, você pode examinar a tarefa programada na página Advisor Central. Ao terminar, você pode verificar as recomendações do advisor. Observação: O Segment Advisor permite especificar a duração da análise. Assim, você pode limitar o tempo utilizado pelo advisor para produzir as recomendações. De maneira geral, um período de análise mais longo produz resultados mais abrangentes. Os resultados são armazenados no AWR e podem ser vistos posteriormente. Use a opção “Number of days to retain” para informar ao banco de dados Oracle por quanto tempo esses resultados deverão ser mantidos antes de serem expurgados do AWR.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Segment Advisor (continuação)

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Implementando Recomendações

Implementando Recomendações Uma vez concluído o job do Segment Advisor, você pode exibir os detalhes das recomendações e implementá-las diretamente. Observação: Antes de comprimir uma tabela organizada por heap, ative a movimentação de linhas nessa tabela. Para isso, no Database Control, selecione a tab Options na página Edit Table. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Database Control eCompressão de Segmentos

Database Control e Compressão de Segmentos Como alternativa (à implementação das recomendações do Segment Advisor), você pode comprimir segmentos individuais. Por exemplo, na home page do Database Control, clique no link Tables da seção Storage. Na página Tables, selecione sua tabela e, depois, Shrink Segment na lista drop-down Actions. Em seguida, clique no botão Go. Essa ação permite acessar a página Shrink Segment, onde você pode escolher os segmentos dependentes a serem comprimidos. Você pode apenas compactar ou compactar e liberar o espaço. Pode também escolher a opção CASCADE. Quando terminar, clique no link Continue. Com essa ação, você submete as instruções de compressão como um job programado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comprimindo Segmentos com SQLALTER … SHRINK SPACE [CASCADE]

TABLE [OVERFLOW] INDEX MATERIALIZED VIEW MATERIALIZED VIEW LOG

MODIFY PARTITION MODIFY SUBPARTITION MODIFY LOB

ALTER TABLE employees SHRINK SPACE CASCADE;

ALTER TABLE employees ENABLE ROW MOVEMENT; 1

2

ALTER TABLE employees MODIFY LOB(resume) (SHRINK SPACE);3

ALTER TABLE employees OVERFLOW SHRINK SPACE; 4

Comprimindo Segmentos com SQL Como uma operação de compressão pode fazer com que os ROWIDs sejam alterados nos segmentos organizados por heap, ative a movimentação de linhas no segmento correspondente antes de executar a compressão nesse segmento. Por default, a movimentação de linhas é desativada no nível do segmento. Para ativar a movimentação de linhas, é usada a cláusula ENABLE ROW MOVEMENT dos comandos CREATE TABLE ou ALTER TABLE. Essa situação é ilustrada no primeiro exemplo do slide. Use o comando ALTER para acionar a compressão de segmento em um objeto. O objeto pode ser: tabela (organizada por heap ou por índice), partição, subpartição, LOB (segmento de dados e de índice), índice, view materializada ou log de view materializada.Use a cláusula SHRINK SPACE para comprimir o espaço em um segmento. Se você especificar CASCADE, a compressão será reproduzida em cascata para todos os segmentos dependentes que suportarem uma operação de compressão, com exceção de views materializadas, índices de LOB, tabelas de mapeamento de IOT (tabelas organizadas por índice). A cláusula SHRINKSPACE é ilustrada no segundo exemplo.Em um segmento de índice, a compressão aglutina o índice antes de compactar os dados.O exemplo 3 mostra um comando que comprime um segmento LOB, já que a coluna RESUMEusa o tipo de dados CLOB. O exemplo 4 mostra um comando que comprime um segmento de overflow de IOT pertencente à tabela EMPLOYEES. Observação: Para obter mais informações, consulte o Oracle Database SQL Reference Guide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciando a Alocação de Espaço Retomável

Uma instrução retomável: • Permite suspender operações longas, em vez de

causar um erro • Permite corrigir o problema durante a suspensão da

operação, em vez de começar novamente • É suspensa nas seguintes condições:

– Falta de espaço – Número máximo de extensões atingido – Cota de espaço excedida

Gerenciamento de Espaço Monitoramento Pró-ativo Seg. Advisor e Compr. Seg.

> Alocação RetomávelTBS e DB Transportáveis

Gerenciando a Alocação de Espaço Retomável O banco de dados Oracle oferece um meio de suspender, e retomar posteriormente, a execução de operações extensas do banco de dados no caso de falhas de alocação de espaço. Dessa forma, você pode executar uma ação corretiva e impedir que o servidor do banco de dados Oracle retorne um erro para o usuário. Após a correção da condição de erro, a operação suspensa é automaticamente retomada. Esse recurso é denominado “alocação de espaço retomável”. As instruções afetadas são chamadas de “instruções retomáveis”. Uma instrução só é executada no modo retomável quando o recurso de instrução retomável está ativado para o sistema ou a sessão. A suspensão de uma instrução resulta automaticamente na suspensão da transação. Portanto, todos os recursos transacionais são interrompidos durante a suspensão e a retomada de uma instrução SQL. Quando a condição de erro desaparece (por exemplo, como resultado da intervenção de um usuário ou em função da liberação de espaço de classificação por outras consultas), a execução da instrução suspensa é retomada automaticamente. Um intervalo de timeout de suspensão é associado a instruções retomáveis. Uma instrução retomável suspensa durante o intervalo de timeout (o default é 7.200 segundos, ou duas horas) é reativada e retorna a exceção para o usuário. É possível suspender e retomar uma instrução retomável diversas vezes durante sua execução.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando a Alocação de Espaço Retomável

• É possível retomar consultas, operações DML e algumas operações DDL quando ocorre um erro de falta de espaço.

• Você pode usar o SQL, o PL/SQL, o SQL*Loader ou o OCI (Oracle Call Interface) para executar uma instrução retomável.

• Antes de executar instruções retomáveis, ative-as para a sessão.

ALTER SESSION ENABLE RESUMABLE;

INSERT INTO sales_new SELECT * FROM sh.sales;

ALTER SESSION DISABLE RESUMABLE;

Usando a Alocação de Espaço Retomável A alocação de espaço retomável só é possível quando as instruções são executadas em uma sessão em que o modo retomável está ativado. Existem duas maneiras de ativar e desativar a alocação de espaço retomável:

• Execute o comando ALTER SESSION ENABLE RESUMABLE. • Defina o parâmetro de inicialização RESUMABLE_TIMEOUT como um valor diferente de

zero com uma instrução ALTER SESSION ou ALTER SYSTEM. Ao ativar o modo retomável para uma sessão ou para o banco de dados, você pode especificar um período de timeout depois do qual são exibidos os erros da instrução suspensa caso não ocorram intervenções. O parâmetro de inicialização RESUMABLE_TIMEOUT indica o número de segundos antes que um timeout ocorra. Você também pode especificar o período de timeout com o seguinte comando:

ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600;

O valor de TIMEOUT tem efeito até que seja alterado por outra instrução ALTER SESSIONENABLE RESUMABLE ou por outros meios, ou até o encerramento da sessão. O intervalo de timeout default quando a cláusula ENABLE RESUMABLE TIMEOUT é usada para ativar o modo retomável é de 7.200 segundos ou 2 horas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Usando a Alocação de Espaço Retomável (continuação)Você também pode atribuir um nome a instruções retomáveis. Por exemplo:

ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600 NAME 'multitab insert';

O nome é usado para identificar a instrução retomável nas views DBA_RESUMABLE e USER_RESUMABLE. Por exemplo:

SELECT name, sql_text FROM user_resumable;

NAME SQL_TEXT --------------- --------------------------------------------multitab insert INSERT INTO oldsales SELECT * FROM sh.sales;

Para configurar automaticamente as definições de instruções retomáveis referentes a sessões individuais, você pode criar e registrar um trigger LOGON no nível do banco de dados que altere a sessão de um usuário. O trigger executa comandos que ativam as instruções retomáveis para a sessão, especifica um período de timeout e associa um nome às instruções retomáveis executadas pela sessão. Como as instruções suspensas podem reter alguns recursos do sistema, os usuários precisam receber o privilégio do sistema RESUMABLE antes da permissão para ativar a alocação de espaço retomável e executar instruções retomáveis.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Retomando Instruções Suspensas

Instrução SQL

Tabela cheia

Suspensa

Continuar a operação SQL

TriggerAFTER

SUSPENDAbortar

Opcionalmente

Tabela com espaço livre

1

2

3 4

5

Retomando Instruções Suspensas Exemplo:

1. Uma instrução INSERT encontra um erro informando que a tabela está cheia. 2. A instrução INSERT é suspensa, e nenhum erro é passado ao cliente. 3. Como alternativa, é executado um trigger AFTER SUSPEND. 4. Como opção, a exceção SQLERRROR é ativada para abortar a instrução. 5. Se a instrução não for abortada e for adicionado espaço livre à tabela, a execução da

instrução INSERT será retomada. Detectando uma Instrução Suspensa Quando uma instrução retomável é suspensa, o erro não é informado ao cliente. O banco de dados Oracle oferece métodos alternativos para notificar o erro aos usuários e fornecer informações sobre as circunstâncias, de modo que uma ação corretiva seja executada.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Retomando Instruções Suspensas (continuação)Possíveis Ações Durante a Suspensão Quando uma instrução retomável encontra um erro corrigível, o sistema gera internamente o evento AFTER SUSPEND. Os usuários podem registrar triggers para esse evento no nível do banco de dados e do esquema. Se um usuário registrar um trigger para lidar com esse evento do sistema, esse trigger será executado após a suspensão de uma instrução SQL. As instruções SQL executadas em um trigger AFTER SUSPEND são sempre não retomáveis e autônomas. As transações iniciadas no trigger usam o segmento de rollback SYSTEM. Essas condições são impostas para solucionar deadlocks e reduzir a possibilidade de o trigger causar a mesma condição de erro da instrução. No código do trigger, você pode usar a view USER_RESUMABLE ou DBA_RESUMABLE, ou a function DBMS_RESUMABLE.SPACE_ERROR_INFO, para obter informações sobre as instruções retomáveis. Quando uma instrução retomável é suspensa:

• A sessão que chama a instrução é colocada em estado de espera. É inserida uma linha em V$SESSION_WAIT para a sessão, com a frase “statement suspended, wait error to be cleared” na coluna EVENT.

• É emitido um alerta de operação suspensa sobre o objeto que precisa de outros recursos para a conclusão da instrução suspensa.

Encerrando uma Instrução Suspensa Quando a condição de erro é solucionada (por exemplo, como resultado da intervenção de um DBA ou em função da liberação de espaço de classificação por outras consultas), a execução da instrução suspensa é retomada automaticamente e o alerta “resumable session suspended” é removido. Para impor a uma instrução suspensa a ativação da exceção SERVERERROR, use o procedure DBMS_RESUMABLE.ABORT(). Um DBA ou o usuário que executou a instrução pode chamar esse procedure. Se o intervalo de timeout associado à instrução retomável terminar, a instrução será automaticamente abortada e um erro será retornado para o usuário.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Transportando Tablespaces . Conceito: Tablespaces transportáveis entre plataformas: • Simplificam a distribuição de dados entre o data

warehouse e data marts • Permitem a migração do banco de dados de uma

plataforma para outra • Plataformas suportadas:

Microsoft Windows 64 bits para AMD

HP Open VMSSistemas Baseados em AIX (64 bits)

Sistema Operacional Solaris (x86)

Apple Mac OSLinux IA(64 bits)

Linux IA (32 bits)

Linux 64 bits para AMDHP-UX IA(64 bits)

Microsoft Windows IA(32 bits)

Linux Baseado em IBM zSeriesHP Tru64 UNIXSolaris[tm] OE (64 bits)Microsoft Windows IA (64 bits)HP-UX (64 bits)Solaris[tm] OE (32 bits)

…Alocação Retomável

> TBS TransportáveisBD Transportável

Transportando Tablespaces Você pode usar o recurso de tablespace transportável para movimentar dados entre plataformas. Essa propriedade simplifica a distribuição de dados de um ambiente de data warehouse para data marts, que, com freqüência, são executados em plataformas menores. Ela também permite a migração de um banco de dados de uma plataforma para outra, recriando o dicionário e transportando os tablespaces dos usuários. Para transportar arquivos de dados de uma plataforma para outra, você precisa certificar-se de que os sistemas de origem e de destino estejam em execução em uma das plataformas suportadas (consulte o slide). Observação: O recurso de tablespace transportável entre plataformas requer que as duas plataformas estejam usando os mesmos conjuntos de caracteres.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Conceito: Nível Mínimo de Compatibilidade • O parâmetro COMPATIBLE dos bancos de dados de

origem e de destino deve ser definido como 10.0.0ou maior.

• Os cabeçalhos de arquivos de dados identificam as respectivas plataformas.

• Antes do transporte, certifique-se de que todos os arquivos off-line e somente para leitura identifiquem as respectivas plataformas.

Somente paraleitura

Somentepara leitura

Leitura/gravação

Somentepara leitura

COMPATIBLE=10.0.0COMPATIBLE=9.2.0

Leitura/gravação

Leitura/gravação

Conceito: Nível Mínimo de Compatibilidade É necessário avançar o parâmetro de inicialização COMPATIBLE dos bancos de dados de origem e de destino até 10.0.0 ou um valor maior antes de usar o recurso de tablespace transportável entre plataformas. Quando os arquivos de dados são abertos pela primeira vez no Oracle Database 10g com o parâmetro COMPATIBLE definido como 10.0.0 (ou maior), esses arquivos passam a identificar as respectivas plataformas. Isso é indicado pelas marcas de seleção no diagrama. Cada arquivo identifica a plataforma à qual pertence. Esses arquivos têm formatos idênticos para os blocos de cabeçalho usados na identificação e verificação de arquivos. A compatibilidade de arquivos somente para leitura e off-line só ocorrerá depois que eles se tornarem arquivos de leitura/gravação ou forem colocados on-line. Portanto, os tablespaces que eram somente para leitura nos bancos de dados anteriores ao Oracle Database 10g devem se tornar tablespaces de leitura/gravação para que possam usar o recurso transportável entre plataformas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Procedimento para Tablespace Transportável

Transformar os tablespaces em somente para leitura.

Sim

O destinousa o mesmo

formato endian?

Usar o Data Pump para extrair metadados.

Converter arquivos dedados usando o RMAN.

Enviar arquivos de dados e arquivo de dump para o destino.

Usar o Data Pump para importar metadados.

Transformar os tablespaces em leitura/gravação.

Não

Origem

Destino

Procedimento para Tablespace Transportável Para transportar um tablespace de uma plataforma para outra (origem para destino), os arquivos de dados pertencentes ao conjunto de tablespaces devem ser convertidos em um formato que possa ser reconhecido pelo banco de dados de destino. Embora com o Oracle Database 10g as estruturas dos discos se adaptem a um formato comum, é possível que as plataformas de origem e destino usem diferentes formatos endian (ordenação de bytes). Ao passar para uma plataforma endian distinta, use o comando CONVERT do utilitário RMAN para converter a ordenação de byte. Essa operação pode ser feita na plataforma de origem ou de destino. Para as plataformas com o mesmo formato endian, a conversão não é necessária. A ilustração do slide apresenta as etapas possíveis do transporte de tablespaces de uma plataforma de origem para uma plataforma de destino. No entanto, é possível fazer a conversão depois de enviar os arquivos à plataforma de destino. As últimas duas etapas devem ser executadas na plataforma de destino. Basicamente, o procedimento é o mesmo usado nas releases anteriores do banco de dados Oracle, exceto quando as duas plataformas usam formatos endian distintos. Supõe-se que ambas permitam o transporte entre plataformas. Observação: A ordenação de bytes pode afetar os resultados quando os dados são gravados e lidos. Por exemplo, o valor inteiro de 2 bytes 1 é gravado como 0x0001 em um sistema big endian (como o Sun SPARC Solaris) e como 0x0100 em um sistema little endian (como um PC compatível com Intel).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Determinando o Formato Endiande uma Plataforma

SELECT tp.endian_format FROM v$transportable_platform tp,

v$database d WHERE tp.platform_name = d.platform_name;

Origem Destino

Determinando o Formato Endian de uma Plataforma É possível consultar a view V$TRANSPORTABLE_PLATFORM para determinar se a ordenação endian é a mesma nas duas plataformas. A view V$DATABASE contém duas colunas que você pode usar para determinar o nome e o identificador da plataforma. Use a consulta do slide nas duas plataformas e compare os resultados. Em um sistema Sun SPARC Solaris, a instrução SELECT produz a seguinte saída: ENDIAN_FORMAT-------------Big

Em uma plataforma Microsoft Windows baseada em Intel, a instrução SELECT produz a seguinte saída: ENDIAN_FORMAT-------------Little

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Transportando Bancos de Dados

• Generalize o recurso de tablespace transportável. • Em um ambiente de data warehouse, os dados

podem ser facilmente distribuídos para data marts, que geralmente são utilizados em plataformas menores.

• Um banco de dados pode ser rapidamente migrado de uma plataforma para outra.

Plataforma X Plataforma Y

Transferência de arquivosdo banco de dados

Mesmo formato endian

Banco de dados existente Novo banco de dados

…Alocação Retomável TBS Transportáveis

> BD Transportável

Transportando Bancos de Dados O recurso de tablespace transportável agiliza a movimentação de dados entre diferentes plataformas. No entanto, ainda é necessário descarregar os metadados, já que não é possível transportar tablespaces do sistema. A finalidade do recurso de transporte de banco de dados é oferecer um meio rápido e fácil de transportar bancos de dados entre plataformas com o mesmo formato endian. Entretanto, a plataforma de origem e a plataforma de destino podem ter alinhamentos de disco diferentes. Por exemplo, a HP-UX e a Solaris têm endian grande, mas o alinhamento de disco é oito na HP-UX, e quatro na Solaris. Para transportar bancos de dados de uma plataforma para outra, você precisa assegurar que os sistemas de origem e de destino estejam em execução em uma das plataformas listadas em V$TRANSPORTABLE_PLATFORM e que as duas plataformas tenham o mesmo formato endian. Por exemplo, você pode transportar um banco de dados que executa Linux IA (32 bits) para uma das plataformas Windows. Se um ou ambos os bancos de dados usarem ASM (Automatic Storage Management), talvez seja preciso usar o package DBMS_FILE_TRANSFER para transmitir os arquivos por ftp. Diferentemente de um tablespace transportável, no qual há um banco de dados de destino ao qual vincular os dados, esse recurso cria um novo banco de dados na plataforma de destino. O novo banco de dados contém os mesmos dados do banco de dados de origem. O banco de dados recém-criado também tem as mesmas configurações do banco de dados de origem, exceto o nome, o nome da instância e a localização dos arquivos. Observação: Transportar bancos de dados é mais rápido que usar o Data Pump paramovê-los.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Procedimento de Transporte de Banco de Dados: Conversão do Sistema de Origem

Sistemade origem

Somentepara leitura

Abrir banco de dados no modo READ ONLY e COMPATIBLE=10.0.0

Sistemade destino

Somentepara leituraCONVERT

DATABASETO PLATFORM

Somentepara leitura

Entrega dearquivos

Somentepara leitura

Procedimento de Transporte de Banco de Dados: Conversão do Sistema de Origem Antes de transportar seu banco de dados, abra-o no modo READ ONLY. Em seguida, use o RMAN para converter os arquivos de dados necessários do banco de dados. Quando a conversão é feita na plataforma de origem, o novo comando do RMAN CONVERTDATABASE gera um script com o comando CREATE CONTROLFILE RESETLOGS correto, que é usado no sistema de destino para criar o novo banco de dados. O comando CONVERTDATABASE converte todos os arquivos de dados identificados para que eles possam ser usados no sistema de destino. Em seguida, você envia os arquivos de dados convertidos e o script gerado à plataforma de destino. Executando o script gerado na plataforma de destino, você cria uma nova cópia do banco de dados. Observação: O banco de dados de origem deve estar executando o parâmetro de inicialização COMPATIBLE definido para 10.0.0 ou valor superior. Todos os tablespaces identificados devem ter sido READ WRITE pelo menos uma vez desde que COMPATIBLE foi definido para 10.0.0 ou valor superior.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Procedimento de Transporte de Banco de Dados: Conversão do Sistema de Destino

Sistemade origem

Abrir banco de dados no modoREAD ONLY e COMPATIBLE=10.0.0

Sistemade destino

Somentepara leituraCONVERT

DATABASEON TARGET

Somentepara leitura

Somentepara leitura

Somentepara leitura

Entrega dearquivos

Procedimento de Transporte de Banco de Dados: Conversão do Sistema de Destino

Antes de transportar seu banco de dados, abra-o no modo READ ONLY. Em seguida, use o RMAN para converter os arquivos de dados necessários do banco de dados. Quando a conversão é feita na plataforma de destino, o comando CONVERT DATABASE(executado no sistema de origem) gera apenas dois scripts usados no sistema de destino para converter os arquivos de dados e recriar os arquivos de controle para o novo banco de dados. Em seguida, você envia os arquivos de dados identificados e os dois scripts para a plataforma de destino. Depois disso, execute os dois scripts na ordem correta. O primeiro usa o comando existente do RMAN CONVERT DATAFILE para fazer a conversão, e o segundo executa o comando SQL CREATE CONTROLFILE RESETLOGS com os arquivos de dados convertidos para criar o novo banco de dados. Observação: O banco de dados de origem deve estar em execução com o parâmetro de inicialização COMPATIBLE definido como 10.0.0 ou um valor superior. Todos os tablespaces identificados devem ter sido READ WRITE pelo menos uma vez desde que COMPATIBLE foi definido como 10.0.0 ou valor superior.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Transporte do Banco de Dados: Considerações

• Crie o arquivo de senha na plataforma de destino. • Transporte os BFILEs usados no banco de dados de

origem. • O pfile gerado e o script de transporte usam OMF. • Use DBNEWID para modificar o DBID.

Transporte do Banco de Dados: Considerações Os redo logs, os arquivos de controle e os arquivos temporários não são transportados. Eles são recriados no novo banco de dados da plataforma de destino. Como resultado, o novo banco de dados da plataforma de destino precisa ser aberto com a opção RESETLOGS. Um arquivo de senha não é transportado, portanto você precisa criá-lo na plataforma de destino. Esse transporte não é possível porque os tipos de nomes de arquivos de senha permitidos são específicos de cada sistema operacional. No entanto, a saída do comando CONVERT DATABASElista todos os nomes de usuários e seus privilégios de sistema, e recomenda a recriação do arquivo de senha e a adição de entradas para esses usuários na plataforma de destino. O comando CONVERT DATABASE lista todos os objetos do diretório e os objetos que usam tipos de dados BFILE ou tabelas externas no banco de dados de origem. Talvez seja necessário atualizar esses objetos com os novos nomes de diretório e arquivos. Se forem usados BFILEs no banco de dados, você precisará transportá-los. O pfile e o script de transporte gerados usam OMFs (Oracle Managed Files) nos arquivos do banco de dados. Se você não quiser usar OMFs, modifique o pfile e o script de transporte. O banco de dados transportado tem o mesmo DBID do banco de dados de origem. Você pode usar o utilitário DBNEWID para alterar o DBID. No script de transporte, assim como na saída do comando CONVERT DATABASE, você é solicitado a usar o utilitário DBNEWID para alterar o ID do banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Usar o banco de dados Oracle para gerenciar espaço

automaticamente • Monitorar e gerenciar de forma pró-ativa o uso do

espaço de tablespaces • Usar o Segment Advisor • Reutilizar o espaço desperdiçado de tabelas e

índices com a funcionalidade de compressão de segmentos

• Gerenciar a alocação do espaço retomável • Descrever os conceitos de bancos de dados e

tablespaces transportáveis

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício:Gerenciando o Armazenamento

Este exercício aborda os seguintes tópicos: • Uso de alertas de limite para gerenciar tablespaces

de forma pró-ativa • Uso do Segment Advisor para comprimir espaço • Exibição de alertas e do histórico de alertas no

SQL*Plus e no Enterprise Manager

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



ASM (Automatic Storage Management)

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Identificar os recursos do ASM (Automatic Storage

Management)• Configurar arquivos de parâmetros de inicialização

para instâncias ASM e do banco de dados• Executar comandos SQL com nomes de arquivos ASM• Inicializar instâncias ASM e fazer shutdown dessas

instâncias • Administrar grupos de discos ASM• Usar o RMAN a fim de migrar o banco de dados para

o ASM

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




ASM (Automatic StorageManagement): Revisão

• Sistema de arquivos clusterizadoportável e de alto desempenho

• Gerencia arquivos do banco de dados Oracle

• Distribuição de dados entrediscos para balancear a carga

• Espelhamento integrado entrediscos

• Soluciona vários desafios degerenciamento de armazenamento

ASM

Sistema dearquivos

Gerenciadorde volumes

Sistema operacional

Aplicação

Banco de Dados

ASM (Automatic Storage Management): Revisão O ASM (Automatic Storage Management) permite a integração vertical do sistema de arquivos e do gerenciador de volumes especificamente criado para os arquivos do banco de dados Oracle. O ASM pode gerenciar máquinas SMP individuais ou vários nós de um cluster para fins de suporte ao Oracle RAC (Real Application Clusters). O ASM distribui a carga de entrada/saída entre todos os recursos disponíveis, a fim de otimizar o desempenho e, ao mesmo tempo, eliminar a necessidade do ajuste manual de entrada/saída. O ASM ajuda os DBAs a gerenciar um ambiente de banco de dados dinâmico, permitindo que eles aumentem o tamanho do banco de dados sem fazer shutdown do banco de dados para ajustar a alocação do armazenamento. O ASM pode manter cópias de dados redundantes a fim de oferecer tolerância a falhas ou pode ser complementado com mecanismos de armazenamento confiáveis produzidos por terceiros. O gerenciamento de dados é feito por meio da seleção das características de confiabilidade e desempenho desejadas das classes de dados, e não por meio da interação humana em cada arquivo. Os recursos do ASM economizam o tempo dos DBAs com a automatização do armazenamento manual, aumentando, assim, a capacidade de gerenciamento de bancos de dados grandes com mais eficiência.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



ASM (Automatic Storage Management): Revisão (continuação)O ASM divide os arquivos em AUs (allocation units) e as distribui uniformemente entre todos os discos. Ele utiliza uma técnica de índice para rastrear o posicionamento de cada AU. Quando a capacidade de armazenamento é alterada, o ASM não refaz o striping de todos os dados, mas move um volume de dados proporcional ao volume de armazenamento adicionado ou removido, para redistribuir uniformemente os arquivos e manter uma carga balanceada entre os discos. Isso é feito enquanto o banco de dados está ativo. Você pode aumentar a velocidade de uma operação de rebalanceamento ou diminuí-la para reduzir o impacto no subsistema de entrada/saída. O ASM fornece a proteção de espelhamento sem que seja necessário comprar um gerenciador de volumes lógicos de terceiros. Uma vantagem exclusiva do ASM é que o espelhamento é aplicado por arquivo, e não por volume. Portanto, o mesmo grupo de discos pode conter uma combinação de arquivos protegidos por espelhamento, bem como arquivos sem qualquer proteção. O ASM suporta arquivos de dados, arquivos de log, arquivos de controle, logs de arquivamento, conjuntos de backup do RMAN e outros tipos de arquivo do banco de dados Oracle. Ele suporta o RAC (Real Application Clusters) e elimina a necessidade de um Gerenciador de Volumes Lógicos de Cluster ou de um Sistema de Arquivos Clusterizado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Arquitetura Geral do ASM

InstânciaASM

SID=asm

Discos ASM Discos ASM

Grupo de discos ASM 1

Instância do banco de dadosSID=sales

ASMBRBAL

ARB0

ARBA

…

Discos ASM Discos ASM Discos ASM

Grupo de discos ASM 2

Discos ASM

DBW0

RBAL

FG

Arquitetura Geral do ASM Para usar o ASM, inicie uma instância especial, chamada de instância ASM, antes de iniciar a instância do banco de dados. As instâncias ASM não montam bancos de dados, mas gerenciam os metadados necessários à disponibilização de arquivos do ASM para instâncias comuns do banco de dados. As instâncias ASM e as instâncias do banco de dados têm acesso a um conjunto comum de discos denominado grupos de discos. As instâncias do banco de dados acessam diretamente o conteúdo dos arquivos ASM, comunicando-se com uma instância ASM apenas para obter informações sobre o layout desses arquivos. Uma instância ASM contém dois novos processos de background. Um coordena a atividade de rebalanceamento dos grupos de discos. Ele é denominado RBAL. O segundo é responsável pela movimentação das AUs de rebalanceamento. Várias delas podem ocorrer simultaneamente, e serão denominadas ARB0, ARB1 e assim sucessivamente. Uma instância ASM também apresenta alguns dos processos de background de uma instância do banco de dados, incluindo SMON, PMON, LGWR, DBWR e CKPT.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Arquitetura Geral do ASM (continuação)Cada instância do banco de dados que esteja utilizando o ASM tem dois novos processos de background denominados ASMB e RBAL. O RBAL executa aberturas globais dos discos pertencentes aos grupos de discos. Durante a inicialização da instância de banco de dados, o ASMB se conecta como um processo de foreground à instância ASM. A comunicação entre o banco de dados e a instância ASM é feita por meio dessa ponte. Isso inclui alterações físicas em arquivos, como a criação e a deleção de arquivos de dados. Nessa conexão, mensagens periódicas são trocadas para atualizar estatísticas e verificar a integridade das duas instâncias.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tarefas da Instância ASM

Veja abaixo as tarefas que você precisa saber executar para usar uma instância ASM: • Criar a instância ASM • Definir os parâmetros de inicialização • Iniciar a instância ASM • Gerenciar a instância ASM • Fazer shutdown da instância ASM

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando uma Instância ASM

Criando uma Instância ASM Crie uma instância ASM executando o DBCA (Database Configuration Assistant). Na primeira tela, escolha a opção Configure Automatic Storage Management e siga as etapas. A instância ASM é criada e iniciada. Em seguida, você é orientado a definir grupos de discos para a instância. Como parte do processo de criação de instâncias ASM, o DBCA gera automaticamente uma entrada no arquivo oratab. Essa entrada é usada para fins de descoberta. Nas plataformas Windows em que é utilizado um mecanismo de serviço, o DBCA cria automaticamente um Oracle Service e a entrada de registro apropriada para facilitar a descoberta de instâncias ASM.Quando uma instância ASM é configurada, o DBCA cria um arquivo de parâmetros e um arquivo de senha para a instância. Se você precisar criar um banco de dados habilitado para ASM primeiro, o DBCA determinará se já existe uma instância ASM no host. Se a descoberta de instâncias ASM retornar uma lista vazia, o DBCA criará uma nova instância ASM.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Parâmetros de Inicialização da Instância ASM

INSTANCE_TYPE = ASM

DB_UNIQUE_NAME = +ASM

ASM_POWER_LIMIT = 1

ASM_DISKSTRING = '/dev/rdsk/*s2', '/dev/rdsk/c1*'

ASM_DISKGROUPS = dgroupA, dgroupB

LARGE_POOL_SIZE = 8MB

Parâmetros de Inicialização da Instância ASM • INSTANCE_TYPE deve ser definido como ASM nas instâncias ASM. • DB_UNIQUE_NAME especifica o nome do provedor de serviço para o qual a instância

ASM gerencia grupos de discos. O valor default de +ASM só deverá ser modificado se você executar várias instâncias ASM no mesmo nó.

• ASM_POWER_LIMIT controla a velocidade de uma operação de rebalanceamento. Os valores variam de 1 a 11, em que 11 representa a velocidade mais rápida. Em caso de omissão, esse valor assume o default 1. O número de escravos é obtido do nível de paralelização especificado em um comando de rebalanceamento manual (POWER) ou por meio do parâmetro ASM_POWER_LIMIT.

• ASM_DISKSTRING é um valor dependente do sistema operacional usado pelo ASM para limitar o conjunto de discos considerados para a descoberta.

• ASM_DISK_GROUPS é a lista de nomes dos grupos de discos a serem montados por uma instância ASM na inicialização ou quando o comando ALTER DISKGROUP ALL MOUNT for usado.

O parâmetro INSTANCE_TYPE é o único que você precisa definir. Todos os outros parâmetros do ASM têm valores default adequados à maioria dos ambientes. Observação: Se o ambiente ASM tiver sido criado na linha de comandos, e não no Enterprise Manager, você precisará criar os grupos de discos antes de montá-los.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Alterações nos Parâmetrosde Instância do Banco de Dados

…

INSTANCE_TYPE = RDBMS

LOG_ARCHIVE_FORMAT

DB_BLOCK_SIZE

DB_CREATE_ONLINE_LOG_DEST_n

DB_CREATE_FILE_DEST.

DB_RECOVERY_FILE_DEST

CONTROL_FILES

LOG_ARCHIVE_DEST_n

LOG_ARCHIVE_DEST

STANDBY_ARCHIVE_DEST

LARGE_POOL_SIZE = 8MB

…

Alterações nos Parâmetros de Instância do Banco de Dados INSTANCE_TYPE assume RDBMS como default e especifica que esta é uma instância RDBMS. O parâmetro LOG_ARCHIVE_FORMAT será ignorado se LOG_ARCHIVE_DEST for definido como um nome de arquivo incompleto do ASM, como +dGroupA. Se o parâmetro LOG_ARCHIVE_DEST for definido como um diretório ASM (por exemplo, +dGroupA/myarchlogdir/), LOG_ARCHIVE_FORMAT será utilizado e os arquivos serão não-OMF. Os nomes de arquivo exclusivos dos logs arquivados são criados automaticamente pelo banco de dados Oracle. Os parâmetros a seguir aceitam o formato de contexto de criação multifile dos nomes de arquivos ASM como destino.

• DB_CREATE_ONLINE_LOG_DEST_n • DB_CREATE_FILE_DEST. • DB_RECOVERY_FILE_DEST • CONTROL_FILES • LOG_ARCHIVE_DEST_n • LOG_ARCHIVE_DEST • STANDBY_ARCHIVE_DEST

Observação: Como os mapas de unidades de alocação para arquivos ASM são alocados com base no LARGE_POOL, defina o parâmetro de inicialização LARGE_POOL_SIZE como um valor de, pelo menos, 8 MB ou, de preferência, mais alto.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Inicializando uma Instância ASM

$ export ORACLE_SID='+ASM'

$ sqlplus /nolog

SQL> CONNECT / AS sysdba

Connected to an idle instance.

SQL> STARTUP;

ASM instance started

Total System Global Area 147936196 bytes

Fixed Size 324548 bytes

Variable Size 96468992 bytes

Database Buffers 50331648 bytes

Redo Buffers 811008 bytes

ASM diskgroups mounted

Inicializando uma Instância ASM As instâncias ASM são iniciadas da mesma maneira que as instâncias de banco de dados; a única diferença é que o arquivo de parâmetros de inicialização contém uma entradasemelhante a INSTANCE_TYPE=ASM. Quando esse parâmetro é definido como o valor ASM, ele informa ao executável Oracle que uma instância ASM, e não uma instância do banco de dados, está sendo iniciada. Além disso, a variável ORACLE_SID deve ser definida como o nome da instância ASM. Quando a instância ASM é inicializada, o estágio de montagem tenta montar os grupos de discos especificados pelo parâmetro de inicializaçãoASM_DISKGROUPS, em vez de montar um banco de dados, como é feito com instânciasnão-ASM. Outras cláusulas STARTUP apresentam uma interpretação para as instâncias ASM que é semelhante à utilizada para as instâncias de bancos de dados. OPEN é inválido para uma instância ASM. NOMOUNT inicializa uma instância ASM sem montar grupos de discos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Acessando uma Instância ASM

Grupo de discos Grupo de discos

Sistema de armazenamento

AS SYSDBA AS SYSOPERInstância

ASM

Todas as operações Operaçõesnão destrutivas

Acessando uma Instância ASM As instâncias ASM não têm um dicionário de dados; portanto, a única maneira de se conectar a um é usando a autenticação do sistema operacional, ou seja, SYSDBA ou SYSOPER. Para estabelecer conexão remotamente, utilize um arquivo de senha. Normalmente, o privilégio SYSDBA é concedido por meio de um grupo do sistema operacional. No UNIX, esse grupo geralmente é o dba. Por default, os membros do grupo dba têm o privilégio SYSDBA em todas as instâncias do nó, incluindo a instância ASM. Os usuários que se conectam à instância ASM com o privilégio SYSDBA têm acesso administrativo a todos os grupos de discos do sistema. O privilégio SYSOPER é suportado nas instâncias ASM e limita o conjunto de comandos SQL permitidos ao mínimo necessário para a operação básica de um sistema já configurado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Acessando uma Instância ASM (continuação)Os seguintes comandos estão disponíveis para os usuários SYSOPER:

• STARTUP/SHUTDOWN • ALTER DISKGROUP MOUNT/DISMOUNT • ALTER DISKGROUP ONLINE/OFFLINE DISK • ALTER DISKGROUP REBALANCE • ALTER DISKGROUP CHECK • SELECT all V$ASM_* views

Todos os outros comandos, como CREATE DISKGROUP, ADD/DROP/RESIZE DISK etc. requerem o privilégio SYSDBA e não são permitidos com o privilégio SYSOPER.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Home Page do ASM

Home Page do ASM O Enterprise Manager oferece uma interface gráfica amigável para as tarefas de gerenciamento, administração e monitoramento do banco de dados Oracle. O Oracle Database 10g estende a funcionalidade existente para suportar de forma transparente o gerenciamento, a administração e o monitoramento dos bancos de dados Oracle que usam o armazenamento do ASM. Ele também suporta as novas tarefas de gerenciamento necessárias à administração de instâncias AMS e grupos de discos ASM. A home page do ASM mostra o status da instância ASM juntamente com as métricas e os alertas gerados pelos mecanismos de coleta. Ela também fornece a funcionalidade de inicialização e shutdown. Ao clicar no link Alert, você acessa uma página de detalhes do alerta. O gráfico DiskGroup Usage mostra o espaço utilizado por cada banco de dados cliente e seu espaço livre.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Página de Desempenho do ASM

Página de Desempenho do ASM A tab Performance da página Automatic Storage Management mostra o tempo de resposta de entrada/saída e o throughput de cada grupo de discos. Posteriormente, você poderá fazer drill-down para exibir métricas de desempenho em nível de disco.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Página de Configuração do ASM

Página de Configuração do ASM A tab Configuration da página Automatic Storage Management permite exibir ou modificar os parâmetros de inicialização da instância ASM.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Fazendo Shutdown de uma Instância ASM

SHUTDOWN NORMAL

Instância ASM

Instância do banco de dados A Instância do banco de dados B

1 1

2

3

Fazendo Shutdown de uma Instância ASM Quando você tentar fazer shutdown de uma instância ASM nos modos NORMAL, IMMEDIATEou TRANSACTIONAL, a operação só terá êxito se não houver instâncias de banco de dados conectadas à instância ASM. Se houver pelo menos uma instância conectada, você receberá o seguinte erro:

ORA-15097: cannot SHUTDOWN ASM instance with connected RDBMS instance

Se você executar SHUTDOWN ABORT na instância ASM, ocorrerá o shutdown dessa instância e ela precisará ser recuperada na próxima inicialização. Também ocorrerá o shutdown de todas as instâncias de banco de dados conectadas e será informado o seguinte erro:

ORA-15064: communication failure with ASM instance

Em uma única configuração da instância ASM, se a instância ASM apresentar falha enquanto os grupos de discos estiverem abertos para atualização, ela lerá o log do grupo de discos e recuperará todas as alterações transitórias, depois de ser reinicializada. Quando várias instâncias ASM compartilharem grupos de discos, se ocorrer uma falha em uma instância ASM, a outra instância ASM recuperará automaticamente as alterações transitórias nos metadados ASM causadas pela falha na primeira instância. A falha de uma instância do banco de dados não afeta as instâncias ASM. A instância ASM deve ser iniciada automaticamente sempre que o host é reinicializado. Uma instância ASM deve usar o mecanismo de inicialização automática suportado pelo sistema operacional subjacente. Observe que uma falha no sistema de arquivos geralmente causa uma falha em um nó.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




DBCA e Opções de Armazenamento

DBCA e Opções de Armazenamento Para suportar o ASM como uma opção de armazenamento, esta tela aparece no DBCA (Database Configuration Assistant) durante a criação de um banco de dados. Ela permite que você escolha as opções de armazenamento: sistema de arquivos, ASM ou dispositivos brutos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Armazenamento do ASM: Conceitos

Banco de Dados

Tablespace

Segmento

Extensão

Bloco de dadosOracle

Arquivo de dados

Blocofísico

Disco ASM

Arquivo ASM

AU(Allocation unit)

Arquivo do sistemade arquivos

oudispositivo bruto

Grupo de discosASM

Armazenamento do ASM: Conceitos O ASM não elimina nenhuma funcionalidade existente do banco de dados. Os bancos de dados existentes podem continuar operando normalmente. Você pode criar novos arquivos como arquivos ASM e deixar que os arquivos existentes sejam administrados da maneira antiga ou pode posteriormente migrá-los para o ASM. O diagrama representa os relacionamentos entre os vários componentes de armazenamento em um banco de dados Oracle com ASM disponível. As partes esquerda e central do diagrama mostram os relacionamentos presentes nas releases anteriores. À direita, estão os novos conceitos apresentados pelo ASM. Você pode armazenar os arquivos do banco de dados como arquivos ASM. No alto da nova hierarquia, estão os grupos de discos ASM. Cada arquivo do ASM é armazenado em um único grupo de discos. No entanto, um grupo de discos pode conter arquivos que pertencem a diversos bancos de dados e um único banco de dados pode usar o armazenamento de vários grupos de discos. Como você pode ver, um único grupo de discos é composto de vários discos ASM e cada disco ASM pertence a apenas um grupo. Os arquivos do ASM sempre são distribuídos entre todas as unidades ASM do grupo de discos. Os discos ASM são particionados em AUs (allocation units) de um megabyte cada uma. Uma AU é o menor espaço em disco contíguo alocado pelo ASM. O ASM não permite a divisão de blocos Oracle entre AUs. Observação: O gráfico ilustra apenas um tipo de arquivo ASM: o arquivo de dados. No entanto, o ASM pode ser usado para armazenar outros tipos de arquivo de banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Grupos de Discos ASM

• Um pool de discos gerenciadocomo uma unidade lógica

• Particiona o espaço total em disco em unidades de tamanho uniforme

• Distribui uniformemente cada arquivo entre todos os discos

• Usa o striping COARSE ou FINE de acordo com o tipo de arquivo

• Administra grupos de discos, e não arquivos

Grupo de discos

InstânciaASM

Grupos de Discos ASM Um grupo de discos é um conjunto de discos gerenciado como uma unidade lógica. A área de armazenamento é adicionada e removida dos grupos de discos nas unidades de discos ASM. Cada disco ASM tem um nome, que é um nome comum a todos os nós de um cluster. A abstração no nome do disco ASM é necessária porque diferentes hosts podem usar nomes distintos para se referir ao mesmo disco. O ASM sempre distribui uniformemente os arquivos em AUs (allocation units) de 1 MB entre todos os discos de um grupo de discos. Isso é chamado de striping COARSE. Dessa maneira, o ASM elimina a necessidade de um ajuste manual do disco. No entanto, os discos de um grupo precisam ter tamanhos e características de desempenho semelhantes para atingir a entrada/saída ideal. Na maioria das instalações, há apenas um pequeno número de grupos de discos. Por exemplo, um grupo de discos para uma área de trabalho e outro para uma área de recuperação. No caso dos arquivos que requerem baixa latência, como os arquivos de log, o ASM fornece um striping FINE (128 KB). O striping FINE divide cada AU. Ele divide as operações de entrada/saída de tamanho médio em várias operações de entrada/saída menores executadas paralelamente. Embora o número de arquivos e discos aumente, você só precisa gerenciar um número constante de grupos de discos. Sob a perspectiva de um banco de dados, os grupos de discos podem ser especificados como a localização default dos arquivos criados no banco de dados. Observação: Cada grupo de discos é auto-descritivo e contém seu próprio diretório de arquivos e diretório de discos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Grupo com Proteção para Falhas

Controladora 1 Controladora 2

Grupo com proteçãopara falhas 1


Grupo de discos A

Controladora 3


1 7 131 7 131 7 13

1 7 131 7 131 7 13

1 7 131 7 131 7 13

2

3

4

5

6

Grupo com Proteção para Falhas Um grupo com proteção para falhas é um conjunto de discos, contidos em um grupo específico, que compartilham um recurso comum cuja falha precisa ser tolerada. Uma string de discos SCSI conectados a uma controladora SCSI comum é considerada um exemplo de grupo com proteção para falhas. Uma falha na controladora fará com que todos os discos do barramento SCSI se tornem indisponíveis, embora eles ainda estejam funcionais. Um grupo com falha é específico para uma instalação. Ele se baseia amplamente nos modos de falha que uma instalação pretende tolerar. Por default, o ASM designa cada disco ao seu próprio grupo com proteção para falhas. Ao criar um grupo de discos ou adicionar um disco a um grupo, os administradores podem especificar seu próprio conjunto de discos nos grupos com proteção para falhas. Após a identificação dos grupos com proteção para falhas, o ASM poderá otimizar o layout do arquivo para reduzir a falta de disponibilidade dos dados por causa de uma falha em um recurso compartilhado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Espelhamento de Grupos de Discos • Espelhamento no nível da AU • Combinação de AUs

principais e AUs-espelhoem cada disco

• Redundância externa: Adiada para o espelhamento de hardware

• Redundância normal: – Espelhamento bidirecional – Pelo menos dois grupos com

proteção para falhas • Redundância alta:

– Espelhamento tridirecional – Pelo menos três grupos com

proteção para falhas

Espelhamento de Grupos de Discos O ASM tem três tipos de grupo de discos que suportam vários tipos de espelhamento:

• Redundância externa: Não fornece espelhamento. Escolha um grupo de discos com redundância externa se você usar espelhamento de hardware ou se puder tolerar a perda de dados provocada por uma falha no disco. Os grupos com falha não são usados com esses tipos de grupos de discos.

• Redundância normal: Suporta o espelhamento bidirecional • Redundância alta: Fornece o espelhamento triplo

O ASM não espelha discos, mas sim AUs (allocation units). Conseqüentemente, você só precisa de capacidade sobressalente no grupo de discos. Quando um disco apresenta falha, o ASM reconstrói automaticamente o conteúdo desse disco nos discos sobreviventes do grupo. Para isso, o ASM lê o conteúdo espelhado desses discos. Assim, ele divide os hits de entrada/saída de um disco com falha entre vários discos. Quando o ASM aloca uma AU principal de um arquivo em um disco pertencente a um grupo de discos, ele aloca uma cópia-espelho dessa AU em outro disco do mesmo grupo. As AUs de um disco específico podem manter suas respectivas cópias de espelhamento em um dos vários discos parceiros do grupo de discos. O ASM assegura que uma AU principal e sua cópia-espelho nunca residam no mesmo grupo com proteção para falhas. Se você definir grupos com proteção para falhas para o seu grupo de discos, o ASM poderá tolerar a falha simultânea dos vários discos em um único grupo com proteção para falhas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Rebalanceamento Dinâmicode Grupos de Discos

• Rebalanceamento automático on-line sempre que a configuração de armazenamento é alterada

• Só move os dados proporcionalmente à área de armazenamento adicionada

• Não é necessário o ajuste manual de E/S

• Migração on-line para nova área de armazenamento

• Carga configurável no sistema usando ASM_POWER_LIMIT

Rebalanceamento Dinâmico de Grupos de Discos • Com o ASM, o processo de rebalanceamento é muito fácil e é feito sem a intervenção do

DBA ou do administrador do sistema. O ASM rebalanceia automaticamente um grupo de discos sempre que os discos são adicionados ou eliminados.

• Usando as técnicas de índice para distribuir AUs entre os discos disponíveis, o ASM não precisa refazer o striping de todos os dados. Em vez disso, ele só precisará mover um volume de dados proporcional ao volume de armazenamento adicionado ou removido, a fim de redistribuir uniformemente os arquivos e manter uma carga de entrada/saída balanceada entre os discos de um grupo de discos.

• Com a entrada/saída balanceada sempre que os arquivos são alocados e a configuração de armazenamento é alterada, o DBA não precisa procurar os hotspots em um grupo de discos nem mover manualmente os dados para restaurar uma carga de entrada/saída balanceada.

• É mais eficaz adicionar ou eliminar vários discos ao mesmo tempo para que eles sejam rebalanceados como uma única operação. Isso evitará a movimentação desnecessária dos dados. Com essa técnica, é fácil realizar a migração on-line dos dados. Tudo o que você precisa fazer é adicionar os novos discos em uma única operação e eliminar os discos antigos em uma única operação.

• Você pode controlar o volume de carga que a operação de rebalanceamento tem no sistema definindo a variável de inicialização ASM_POWER_LIMIT. Seus valores variam de 0 a 11. Quanto mais baixo for o valor, mais leve será a carga. Por outro lado, uma definição mais alta terá mais carga e terminará mais cedo. A definição 0 coloca as operações de rebalanceamento em retenção. O valor default é 1.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Gerenciando Grupos de Discos

CREATE DISKGROUP

ALTER DISKGROUP

DROP DISKGROUPInstânciaASM

Instância debanco de dados

Gerenciando Grupos de Discos O objetivo principal de uma instância ASM é o gerenciamento de grupos de discos e a proteção de seus dados. As instâncias ASM também transmitem layouts de arquivos às instâncias do banco de dados. Desse modo, as instâncias do banco de dados podem acessar diretamente os arquivos armazenados nos grupos de discos. Há vários novos comandos administrativos de grupo de discos. Todos eles exigem o privilégio SYSDBA e devem ser executados a partir de uma instância ASM.Você pode adicionar novos grupos de discos, Você também pode modificar os grupos de discos existentes para adicionar novos discos, remover discos existentes e executar várias outras operações. Também é possível remover os grupos de discos existentes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Página de Administração do ASM

Página de Administração do ASM Ao clicar na página com a tab Administration da página Automatic Storage Management, você pode ver os grupos de discos listados na view V$ASM_DISKGROUP. Nela, você pode criar, editar ou eliminar um grupo de discos. Você também pode executar operações, como montagem, desmontagem, rebalanceamento, verificação e correção, em um grupo de discos selecionado. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Página Create Disk Group

Página Create Disk Group Clique em Create na página Disk Group Overview para exibir a página Create Disk Group. Você pode informar o nome do grupo de discos, o mecanismo de redundância e a lista de discos a serem incluídos no novo grupo de discos.A lista de discos é obtida na view fixa V$ASM_DISK. Por default, somente os discos que podem ser designados a um grupo são mostrados. Eles aparecem com um dos seguintes status:

• CANDIDATE: O disco nunca foi designado a um grupo de discos ASM. • FORMER: O disco já foi designado a um grupo de discos ASM mas, no momento, não está

mais. • PROVISIONED: A ASMLib está sendo usada, e o disco ainda não foi designado a um

grupo. Observação: A ASMLib é uma API que faz interface com arrays de armazenamento de outros fornecedores. Consulte o Database Administrator’s Guide para obter mais informações sobre a ASMLib.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando e Eliminando Grupos de Discos

CREATE DISKGROUP dgroupA NORMAL REDUNDANCY

FAILGROUP controller1 DISK

'/devices/A1' NAME diskA1 SIZE 120G FORCE,

'/devices/A2',

'/devices/A3'

FAILGROUP controller2 DISK

'/devices/B1',

'/devices/B2',

'/devices/B3';

DROP DISKGROUP dgroupA INCLUDING CONTENTS;

Criando e Eliminando Grupos de Discos Vamos supor que a descoberta de disco ASM tenha identificado os seguintes discos no diretório /devices: A1, A2, A3, B1, B2 e B3. Além disso, vamos supor que os discos A1, A2 e A3estejam em uma controladora SCSI separada dos discos B1, B2 e B3. O primeiro exemplo do slide ilustra como configurar um grupo de discos denominado DGROUPA com dois grupos com proteção para falhas: CONTROLLER1 e CONTROLLER2. O exemplo também usa a característica de redundância default, NORMAL REDUNDANCY, para o grupo de discos. Você pode optar por atribuir um nome e um tamanho ao disco. Se você não fornecer essas informações, o ASM criará um nome default e tentará determinar o tamanho do disco. Se não for possível determinar o tamanho, um erro será exibido. FORCE indica que um disco específico deve ser adicionado ao grupo de discos especificado, mesmo que o disco já esteja formatado como membro de um grupo de discos ASM. A utilização da opção FORCE para um disco não formatado como membro de um grupo de discos ASM retornará um erro. Como mostrado na segunda instrução do slide, é possível deletar um grupo de discos e todos os seus arquivos. Para evitar deleções acidentais, a opção INCLUDING CONTENTS deverá ser especificada se o grupo de discos ainda contiver algum arquivo além dos metadados internos do ASM. Para eliminar o grupo de discos, ele precisa estar montado. Depois que você se certificar de que nenhum arquivo do grupo de discos esteja aberto, o grupo e todas as respectivas unidades serão removidas do grupo de discos. Em seguida, o cabeçalho de cada disco será sobreposto para eliminar as informações de formatação do ASM.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Adicionando Discos a Grupos de Discos

ALTER DISKGROUP dgroupA ADD DISK

'/dev/rdsk/c0t4d0s2' NAME A5,



'/dev/rdsk/c0t7d0s2' NAME A8;

ALTER DISKGROUP dgroupA ADD DISK '/devices/A*';

Formatação do disco

Rebalanceamento do grupo de discos

Adicionando Discos a Grupos de Discos Este exemplo mostra como adicionar discos a um grupo de discos. Execute o comando ALTERDISKGROUP ADD DISK para adicionar os discos. A primeira instrução adiciona quatro novos discos ao grupo DGROUPA. A segunda instrução demonstra as interações das strings de descoberta. Considere a seguinte configuração:/devices/A1 é um membro do grupo de discos DGROUPA./devices/A2 é um membro do grupo de discos DGROUPA./devices/A3 é um membro do grupo de discos DGROUPA./devices/A4 é um disco candidato.O segundo comando adiciona A4 ao grupo de discos DGROUPA. Ele ignora os outros discos, mesmo que correspondam à string de descoberta, pois já fazem parte do grupo de discos DGROUPA. Conforme mostrado no diagrama, quando você adiciona um disco a um grupo de discos, a instância ASM garante que o disco possa ser utilizado. O disco será, então, formatado e rebalanceado. O processo de rebalanceamento é demorado, pois move as AUs de cada arquivo para o novo disco.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Adicionando Discos a Grupos de Discos (continuação)Observação: O rebalanceamento não bloqueia qualquer operação do banco de dados. O principal impacto de um processo de rebalanceamento está na carga de entrada/saída do sistema. Quanto maior a velocidade do rebalanceamento, maior será a carga de entrada/saída no sistema. Assim, menos largura de banda de entrada/saída estará disponível para as entradas/saídas de banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comandos ALTER

Remova um disco do dgroupA:

Adicione e elimine um disco com um único comando:

Cancele uma operação de eliminação de disco:

ALTER DISKGROUP dgroupA DROP DISK A5;

ALTER DISKGROUP dgroupA DROP DISK A6

ADD FAILGROUP fredDISK '/dev/rdsk/c0t8d0s2' NAME A9;

ALTER DISKGROUP dgroupA UNDROP DISKS;

Comandos ALTERA primeira instrução do slide mostra como remover um dos discos do grupo DGROUPA. A segunda instrução mostra como é possível adicionar e eliminar um disco por meio de um único comando. A grande vantagem nesse caso é que o rebalanceamento só é iniciado depois que o comando é concluído. A terceira instrução mostra como cancelar uma operação de eliminação de disco. O comando UNDROP funciona somente em eliminações pendentes de discos; ele não tem efeito em eliminações que já foram concluídas. A instrução abaixo rebalanceará o grupo de discos DGROUPB se necessário:

ALTER DISKGROUP dgroupB REBALANCE POWER 5;

Em geral, esse comando não é necessário porque ele é automaticamente executado quando os discos são adicionados, eliminados ou redimensionados. No entanto, ele será útil quando você quiser usar a cláusula POWER para sobrepor a velocidade default definida pelo parâmetro de inicialização ASM_POWER_LIMIT. É possível alterar o nível de velocidade de uma operação de rebalanceamento reespecificando o comando com um novo nível. O nível de velocidade zero faz com que o rebalanceamento seja interrompido até que o comando seja chamado novamente, de forma implícita ou explícita. A seguinte instrução desmonta DGROUPA:

ALTER DISKGROUP dgroupA DISMOUNT;

As opções MOUNT e DISMOUNT permitem disponibilizar ou indisponibilizar um ou mais grupos de discos para as instâncias do banco de dados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Comandos ALTER (continuação)Use a instrução a seguir para verificar a consistência interna dos metadados do grupo de discos e corrigir eventuais erros detectados:

ALTER DISKGROUP dgroupA CHECK ALL;

Também será possível usar a cláusula NOREPAIR se você quiser apenas ser alertado sobre os erros. Embora o exemplo solicite uma verificação em todos os discos do grupo, essa verificação pode ser específica a um arquivo ou um disco. Este comando requer a montagem do grupo de discos. Se algum erro for detectado, será exibida uma mensagem de erro resumida e os detalhes do erro detectado serão mostrados no log de alerta. Observação: Dos seis exemplos mostrados, os quatro primeiros acionam um rebalanceamento de grupo de discos, e os dois últimos não.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Arquivos ASM

Arquivo de banco de dados

O arquivo ASM é distribuído automaticamente no grupo de discos dgroupA

CREATE TABLESPACE sample DATAFILE '+dgroupA';

1234

1 2 3 4

Criação automáticado arquivo ASM

RMAN

Arquivos ASM Quando você especifica um grupo de discos ASM como o nome do arquivo de dados para um tablespace, são criados arquivos ASM no grupo para armazenar o tablespace. Quando um arquivo ASM é criado, determinados atributos são definidos permanentemente. Entre eles, estão a política de proteção e a política de striping. Os arquivos do ASM são considerados OMF (Oracle Managed Files). Qualquer arquivo criado pelo ASM será automaticamente deletado quando não for mais necessário. Com o ASM, as operações com arquivos são especificadas em termos de objetos de banco de dados. A administração de bancos de dados não exige o conhecimento do nome de um arquivo, embora o nome do arquivo seja exposto por algumas views do dicionário de dados ou pelo comando ALTER DATABASE BACKUP CONTROLFILE TO TRACE. Como cada arquivo de um grupo de discos é distribuído fisicamente entre todos os discos do grupo, não convém fazer backup de um único disco. Os backups dos arquivos ASM contidos no banco de dados devem ser feitos com o RMAN. Observação: O ASM não gerencia binários, logs de alerta, arquivos de rastreamento ou arquivos de senha.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Utilitário ASMCMD

$ asmcmd

ASMCMD> ls -l DGROUP1/ORCL/DATAFILE

Type Redund Striped Time Sys Name

DATAFILE MIRROR COARSE OCT 05 21:00:00 Y HRAPPS.257.570923611

DATAFILE MIRROR COARSE OCT 05 21:00:00 Y TBSASM.256.570922917

ASMCMD>

SQL> CREATE TABLESPACE tbsasm DATAFILE '+DGROUP1' SIZE 100M;

Tablespace created.

SQL> CREATE TABLESPACE hrapps DATAFILE '+DGROUP1' SIZE 10M;

Tablespace created.

Utilitário ASMCMDASMCMD é um utilitário de linha de comandos que permite exibir e manipular arquivos e diretórios de grupos de discos ASM. Ele pode listar o conteúdo de grupos de discos, pesquisar, criar e remover diretórios e exibir a utilização de espaço, entre outras ações. Observação: Para obter mais informações sobre o ASMCMD, consulte o documento Oracle Database Utilities. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Migrando o Banco de Dados para o Armazenamento do ASM

1. Faça shutdown do banco de dados. 2. Faça shutdown do banco de dados e modifique o

arquivo de parâmetros do servidor para usar o OMF (Oracle Managed Files).

3. Edite e execute o seguinte script do RMAN: STARTUP NOMOUNT;RESTORE CONTROLFILE FROM '/u1/c1.ctl';ALTER DATABASE MOUNT;BACKUP AS COPY DATABASE FORMAT '+dgroup1';SWITCH DATABASE TO COPY;SQL "ALTER DATABASE RENAME '/u1/log1' TO '+dgroup1' ";# Repeat RENAME command for all online redo log members ...ALTER DATABASE OPEN RESETLOGS;SQL "ALTER DATABASE TEMPFILE '/u1/temp1' DROP";

Migrando o Banco de Dados para o Armazenamento do ASM Como os arquivos ASM não podem ser acessados com interfaces de sistema operacional normais, o RMAN é o único meio de cópia dos arquivos ASM. Embora um tablespace possa conter arquivos do ASM e outros tipos de arquivos como resultado do histórico do tablespace, os comandos do RMAN permitem que os arquivos não-ASM sejam reposicionados em um grupo de discos ASM. Você pode usar o procedimento a seguir para reposicionar o banco de dados inteiro em um grupo de discos ASM: (Parte-se do pressuposto de que você está usando um arquivo de parâmetros do servidor.)

1. Obtenha os nomes de arquivo dos redo logs on-line e dos arquivos de controle atuais usando as views V$CONTROLFILE e V$LOGFILE.

2. Faça shutdown do banco de dados de modo consistente. Modifique o arquivo de parâmetros do servidor do banco de dados da seguinte maneira:

– Defina os parâmetros de destino OMF necessários com o grupo de discos ASM desejado.

– Remova o parâmetro CONTROL_FILES.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Migrando o Banco de Dados para o Armazenamento do ASM (continuação)3. Edite e execute o arquivo de comandos do RMAN, que faz backup do banco de dados,

alterna os arquivos de dados atuais para os backups e renomeia os redo logs on-line. Você só pode mover tablespaces ou arquivos de dados usando o comando BACKUP AS COPY.

4. Delete os arquivos de banco de dados antigos. Observação: Se você criar um arquivo de controle OMF e houver um arquivo de parâmetros do servidor, será criada uma entrada do parâmetro de inicialização CONTROL_FILES no arquivo de parâmetros do servidor.Consulte o Oracle Database Backup and Recovery Advanced User’s Guide para obter detalhes sobre como migrar um banco de dados para ASM.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Descrever os conceitos do ASM (Automatic Storage

Management) • Configurar arquivos de parâmetros de inicialização

para instâncias ASM e do banco de dados • Executar comandos SQL com nomes de arquivos ASM • Inicializar instâncias ASM e fazer shutdown dessas

instâncias • Administrar grupos de discos ASM • Usar o RMAN a fim de migrar o banco de dados para

o ASM

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício:Usando o ASM (Automatic Storage Management)

Este exercício aborda os seguintes tópicos: • Criação e inicialização de uma instância ASM • Criação e uso de grupos de discos ASM • Migração de um tablespace para o armazenamento

do ASM

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Gerenciar Recursos

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Configurar o Database Resource Manager• Acessar e criar planos de recursos • Criar grupos de consumidores • Especificar diretivas para alocação de recursos a

grupos de consumidores • Mapear grupos de consumidores para planos • Ativar um plano de recursos • Monitorar o Resource Manager

> ConceitosPlano de RecursosConsumidores de RecursosDiretivas de PlanosMapeamentoAtivação do PlanoMonitoramento

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Mais recursosUsuários OLTP

DatabaseResource Manager

Banco de dados Oracle

Database Resource Manager: Visão Geral

Use o Resource Manager para: • Gerenciar a carga de trabalho mista • Controlar o desempenho do sistema

Usuários batch

Menos recursos

Recursos mínimos

Usuários DSS

Database Resource Manager: Visão Geral Usando o Database Resource Manager (também chamado de Resource Manager), você tem mais controle sobre a alocação de recursos de máquina do que o normalmente possível apenas com o gerenciamento de recursos do sistema operacional. Caso as decisões de gerenciamento de recursos sejam tomadas pelo sistema operacional, é possível que surjam problemas como:

• Overhead excessivo resultante da alternância de contexto dos processos do servidor do banco de dados Oracle pelo sistema operacional quando há um grande número desses processos

• Suspensão dos processos do servidor de um banco de dados que está retendo um latch • Distribuição desigual de recursos entre todos os processos do banco de dados Oracle e

incapacidade de priorizar tarefas • Incapacidade de gerenciar recursos específicos do banco de dados, como servidores de

execução paralela e sessões ativas O Database Resource Manager controla a distribuição de recursos entre várias sessões monitorando a programação da execução no banco de dados. Controlando quais sessões são executadas e o seu tempo de execução, o Database Resource Manager garante que a distribuição de recursos corresponda à diretiva de plano e, portanto, atenda aos objetivos de negócios. Com o Database Resource Manager, é possível garantir aos grupos de usuários um volume mínimo de recursos de processamento, independentemente da carga do sistema e do número de usuários.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Diretivas de planos de recursos

Conceitos do Database Resource Manager

Grupos de usuários ou sessões com necessidades semelhantes de recursos

Um plano detalhado de alocação de recursos entre grupos de consumidores de recursos (um plano ativo)

Especifica como um recurso é dividido entre os grupos de consumidores de recursos (no escopo dos métodos de alocação)

Grupo de consumidores

de recursos

Plano de recursos

Conceitos do Database Resource Manager A administração de sistemas com o Database Resource Manager envolve o uso de planos de recursos, grupos de consumidores de recursos e diretivas de planos de recursos. Um grupo de consumidores de recursos define um conjunto de usuários ou de sessões com necessidades semelhantes de uso de recursos do sistema e do banco de dados. Um plano de recursos especifica como os recursos são distribuídos entre vários grupos de consumidores. O Database Resource Manager também permite a criação de planos dentro de outros planos, denominados subplanos. As diretivas de planos de recursos especificam como um recurso específico é compartilhado entre grupos de consumidores e subplanos. Associe grupos de consumidores de recursos e subplanos a um plano de recursos específico por meio de diretivas de planos. Os métodos de alocação de recursos determinam qual política deve ser usada durante a alocação de determinado recurso. Esses métodos são usados pelos planos e pelos grupos de consumidores de recursos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Por Que Usar o Resource Manager

• Você pode gerenciar recursos do banco de dados e do sistema operacional, como: – Uso da CPU – Grau de paralelismo – Número de sessões ativas – Geração de undo – Tempo de execução de operações – Tempo de inatividade

• Você também pode especificar critérios que, se atendidos, causarão a alternância automática de sessões para outro grupo de consumidores.

Por Que Usar o Resource Manager O Database Resource Manager oferece diversos meios para a alocação de recursos:

• Método de CPU: Permite especificar como os recursos da CPU são alocados entre grupos de consumidores e subplanos.

• Limite do Grau de Paralelismo: Permite controlar o grau máximo de paralelismo de qualquer operação em um grupo de consumidores.

• Pool de Sessões Ativas com Enfileiramento: Permite limitar o número de sessões ativas concorrentes para um grupo de consumidores ou um subplano. Se um grupo exceder o número máximo permitido de sessões, as novas sessões serão colocadas em uma fila onde esperarão até a conclusão de uma sessão ativa. Você também pode especificar um limite de tempo de espera para uma sessão antes de ela ser encerrada com um erro.

• Undo Pool: Permite controlar o volume total de undo que um grupo de consumidores ou um subplano pode gerar. Sempre que o espaço total de undo exceder o volume especificado por UNDO_POOL, não serão permitidos comandos INSERT, UPDATE ou DELETE até que o espaço de undo seja liberado por outra sessão do mesmo grupo ou até que o undo pool do grupo de consumidores seja aumentado. Se a cota do grupo de consumidores for ultrapassada durante a execução de uma instrução DML, essa operação será abortada e retornará um erro. Ainda serão permitidas consultas, mesmo que um grupo de consumidores tenha ultrapassado o limite de undo.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Por Que Usar o Resource Manager (continuação)• Limite de Tempo de Execução: Permite especificar um tempo máximo de execução para

uma operação. O banco de dados Oracle usa as estatísticas do otimizador baseado em custo para estimar a duração de uma operação. Se essa duração for maior que o tempo máximo permitido (MAX_EST_EXEC_TIME), a operação retornará um erro e não será iniciada. Se um grupo de consumidores de recursos tiver mais de uma diretiva de plano com o parâmetro MAX_EST_EXEC_TIME especificado, o Resource Manager escolherá o mais restritivo de todos os valores de entrada.

• Limite de Tempo de Inatividade: Permite especificar o período durante o qual uma sessão pode permanecer inativa. Após esse período, a sessão será encerrada (MAX_IDLE_TIME). Você pode restringir ainda mais o Resource Manager para que ele só encerre as sessões que estiverem bloqueando outras sessões (MAX_IDLE_TIME_BLOCKER).

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Acessando Planosde Recursos

Enterprise Managere PL/SQL

Conceitos> Plano de Recursos

Consumidores de RecursosDiretivas de PlanosMapeamentoAtivação do PlanoMonitoramento

Acessando Planos de RecursosUso do Enterprise Manager A Console do EM Database Control fornece uma interface gráfica fácil de usar para a configuração de planos de recursos, grupos de consumidores e outros elementos. Usando o Package DBMS_RESOURCE_MANAGEREste package PL/SQL contém vários procedures, incluindo:

• CREATE_PLAN: Nomeia um plano de recursos e especifica seus métodos de alocação• UPDATE_PLAN: Atualiza o comentário de um plano de recursos• DELETE_PLAN: Deleta um plano de recursos e suas diretivas

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Exemplo: SYSTEM_PLAN

100%0%0%LOW_GROUP

0%100%0%OTHER_GROUPS

0%0%100%SYS_GROUP

CPU_P3CPU_P2CPU_P1

Métodos de AlocaçãoGrupo de Consumidores de Recursos

Exemplo: SYSTEM_PLANO plano de recursos SYSTEM_PLAN é um dos planos default fornecidos. Ele contém diretivas para os seguintes grupos de consumidores fornecidos:

• SYS_GROUP: O grupo inicial de consumidores para os usuários SYS e SYSTEM.• OTHER_GROUPS: Usado para todas as sessões pertencentes a grupos de consumidores que

não fazem parte do plano de recursos ativo. Deve existir uma diretiva de plano para OTHER_GROUPS em qualquer plano ativo.

• LOW_GROUP: Um grupo com prioridade mais baixa que SYS_GROUP e OTHER_GROUPSneste plano. Você deve decidir quais sessões de usuário farão parte de LOW_GROUP. Inicialmente, nenhum usuário é associado a esse grupo de consumidores. O privilégio de alternância é concedido a PUBLIC neste grupo.

O grupo inicial de consumidores de um usuário é o grupo de consumidores ao qual as sessões criadas por esse usuário pertencem inicialmente. Se você não tiver definido o grupo inicial de consumidores para um usuário, esse grupo será designado automaticamente como DEFAULT_CONSUMER_GROUP. O SYSTEM_PLAN e os grupos de consumidores de recursos associados podem ou não ser usados. Ele poderá ser um modelo para novos planos de recursos e também poderá ser modificado ou deletado. Utilize-o conforme adequado para seu ambiente.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando um Novo Plano de Recursos

DBMS_RESOURCE_MANAGER.SWITCH_PLAN(PLAN_NAME => 'DAY_PLAN',SID => 'ORCL', ALLOW_SCHEDULER_PLAN_SWITCHES => true );

Criando um Novo Plano de RecursosPara criar um novo plano, é necessário configurar diversos objetos do Resource Manager. Selecione Administration > Plans e clique em Create ou escolha “Create Like” e cliqueem Go. O plano do Resource Manager pode ser alterado pelo Scheduler nos seus respectivos limites de períodos. Desselecione a opção default “Automatic Plan Switching Enabled”, se ela for inaceitável. Para obter mais informações sobre o Scheduler, consulte a lição “Automatizando Tarefas com o Scheduler”.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando Gruposde Consumidores

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'APPUSER', CPU_MTH => 'ROUND-ROBIN',COMMENT => '');

ConceitosPlano de Recursos

> Consumidores de Recursos Diretivas de PlanosMapeamentoAtivação do PlanoMonitoramento

Criando Grupos de ConsumidoresPara gerenciar um grupo de consumidores de recursos, selecione Administration > Resource Consumer Groups. Escolha a ação a ser executada. Você pode criar um novo grupo de consumidores de recursos ou selecionar um grupo na lista de resultados e escolher uma das ações relacionadas na lista drop-down Actions. Use a página Resource Consumer Groups para criar ou editar o grupo de consumidores e a descrição, bem como para selecionar os usuários designados ao grupo. Você pode adicionar ou deletar membros na tabela Selected Users. A folha de propriedades General (mostrada no slide) é uma das duas páginas incluídas nas páginas Create Resource Consumer Group e Edit Resource Consumer Group. Para definir ou editar as atribuições do banco de dados associadas ao grupo de consumidores de recursos especificado, navegue até a outra folha de propriedades (Roles).Especifique um método de alocação de recursos para a distribuição da CPU entre as sessões do grupo de consumidores. A programação por rodízio garante que as sessões sejam executadas de forma adequada. Portanto, o método de alocação default é “Round Robin”. O método de alocação “Run to Completion” especifica que as sessões com o maior tempo de atividade sejam programadas antes das outras. A funcionalidade equivalente é obtida por meio do procedure DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP com a opção CPU_MTH.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Designando Usuários aGrupos de Consumidores

Designando Usuários a GruposAntes de ativar o Database Resource Manager, é preciso designar os usuários a grupos de consumidores de recursos. O grupo de consumidores default do usuário é aquele ao qual pertence inicialmente qualquer sessão criada pelo usuário. Se não for definido um grupo inicial de consumidores para um usuário, o valor default desse grupo será DEFAULT_CONSUMER_GROUP. Você deve conceder diretamente ao usuário, ou a PUBLIC, o privilégio de alternância para um grupo de consumidores, antes que este se torne o grupo de consumidores default do usuário. O privilégio de alternância não pode ser proveniente de uma atribuição concedida ao usuário em questão.

DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP ( user => ‘PM', consumer_group => 'APPUSER' );

O package DBMS_RESOURCE_MANAGER_PRIVS contém o procedure usado para designar grupos de consumidores de recursos a usuários. A concessão do privilégio de alternância a um usuário permite que ele alterne para outro grupo de consumidores.

DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP (grantee_name => 'PM', consumer_group => 'APPUSER', grant_option => FALSE );

Você não precisa usar uma área pendente para nenhum desses procedures.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Especificando Diretivasde Planos de Recursos

Valores de CPU_MTH

ConceitosPlano de Recursos Consumidores de Recursos

> Diretivas de Planos MapeamentoAtivação do PlanoMonitoramento

1 2 3 4 5 6 7

Especificando Diretivas de Planos de RecursosSe você não usar o Enterprise Manager para criar o plano de recursos ou os grupos de consumidores de recursos, precisará criar primeiro uma área pendente. Esta é uma área de scratch na qual você pode colocar as alterações e validá-las antes que se tornem ativas. No Enterprise Manager, há várias páginas de propriedades, que podem ser usadas para especificar diretivas de planos:

1. Na página General, associe grupos de consumidores a planos e especifique quanto da CPU cada grupo ou subplano obterá com o valor de CPU_MTH.

2. Especifique um limite de grau de paralelismo para controlar o grau máximo de paralelismo das operações em um grupo de consumidores.

3. É possível controlar o número máximo de sessões que estão ao mesmo tempo ativas em um grupo de consumidores. Uma sessão inteira de execução paralela é considerada como uma sessão ativa.

4. Você pode controlar o volume total de undo que um grupo de consumidores pode gerar. 5. Você pode especificar o tempo máximo de execução de uma operação. 6. Você pode controlar os recursos especificando critérios que, se atendidos, causarão a

alternância automática de sessões para outro grupo de consumidores. 7. Você pode especificar o tempo de inatividade permitido para uma sessão, após o qual ela

será encerrada. Além disso, é possível restringir esse encerramento somente às sessões que estejam bloqueando outras sessões.

Observação: Os slides a seguir fornecem mais detalhes sobre diretivas usando os números das tabs indicados neste slide. Consulte este slide quando aparecer "Tab de Diretiva n" nos slides subseqüentes.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Métodos de Alocação de Recursos para Planos de Recursos

Valores PossíveisParâmetro

FIFO_TIMEOUTQUEUING_MTH

ACTIVE_SESS_POOL_ABSOLUTE

ACTIVE_SESS_POOL_MTH

PARALLEL_DEGREE_LIMIT_ABSOLUTE

PARALLEL_DEGREE_LIMIT_MTH

RATIO

EMPHASISCPU_MTH

Métodos de Alocação de Recursos para Planos de RecursosOs métodos de alocação determinam como o Resource Manager aloca um recurso específico para um grupo de consumidores ou um plano de recursos. Ao criar o plano de recursos, você especifica valores para os métodos de alocação de recursos apresentados a seguir. Há duas maneiras de especificar a distribuição da CPU com o parâmetro CPU_MTH:

• EMPHASIS, o método default, destina-se a planos com vários níveis que usam percentuais para especificar como a CPU deve ser distribuída entre os grupos de consumidores.

• RATIO destina-se a planos com um único nível que usam taxas para especificar como a CPU será distribuída.

PARALLEL_DEGREE_LIMIT_MTH limita o grau máximo de paralelismo de qualquer operação. Esse método só pode ser especificado para grupos de consumidores de recursos; não é possível especificá-lo para subplanos. O método ABSOLUTE é o valor possível, que especifica quantos processos podem ser designados a uma operação. Se houver várias diretivas de planos referentes ao mesmo subplano ou grupo de consumidores, será usado o valor mínimo entre todos os valores possíveis como o limite de grau de paralelismo.ACTIVE_SESS_POOL_MTH limita o número de sessões ativas. Todas as outras sessões são inativas e esperam a ativação em uma fila. ACTIVE_SESS_POOL_ABSOLUTE é o default e o único método disponível.QUEUING_MTH controla a ordem de execução das sessões inativas enfileiradas. FIFO_TIMEOUT é o default e o único método disponível.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Comparação entre EMPHASIS e RATIO

É possível alocar recursos em até 8 níveis distintos.

RATIOEMPHASIS

O valor default é NULL.O valor default é NULL.

É necessário usar valores inteiros,mas não há limites sobre a soma de valores.

A soma de percentuais em qualquer nível específico deveser inferior ou igual a 100.

Só é possível especificar valores para um nível.

O valor especifica um número que indica a taxa de recursos da CPU a ser alocada para o grupo de consumidores.

O valor especifica o percentual máximo de recursos da CPU que um grupo de consumidores pode usar.

Comparação entre EMPHASIS e RATIOO método EMPHASIS de alocação de CPU determina a ênfase dada a sessões em grupos de consumidores distintos em um plano de recursos. São designados níveis de 1 a 8 ao uso da CPU, sendo que o nível 1 tem a prioridade mais alta. Os percentuais especificam como alocar a CPU para cada grupo de consumidores por nível. As seguintes regras se aplicam ao método EMPHASIS de alocação de recursos:

• Os recursos de CPU são distribuídos em determinado nível com base nos percentuais especificados. O percentual de CPU especificado para um grupo de consumidores de recursos é o máximo que esse grupo pode usar em um nível específico.

• Os recursos de consumidores que não são usados em um nível específico são disponibilizados para os grupos de consumidores do próximo nível. Por exemplo, se os grupos de consumidores no Nível 1 usarem apenas 60% dos recursos disponíveis, os 40% adicionais serão disponibilizados para os grupos de consumidores no Nível 2.

• A soma de percentuais em qualquer nível específico deve ser inferior ou igual a 100. • Os níveis sem diretivas de plano especificadas explicitamente têm um default de 0% para

todos os subplanos e grupos de consumidores. • O método EMPHASIS de alocação de recursos evita problemas de escassez, em que

consumidores com prioridades mais baixas não são executados.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Comparação entre EMPHASIS e RATIO (continuação)A política RATIO é um método de alocação de CPU em um único nível. Em vez de percentuais, especifique números que correspondam à taxa de CPU a ser destinada ao grupo de consumidores. Por exemplo, considerando-se três grupos de consumidores OLTP_USERS, DSS_USERS e BATCH_USERS, você pode especificar as seguintes taxas:

• OLTP_USERS: 4• DSS_USERS: 3• BATCH_USERS: 2• OTHER: 1

Isso equivale a dizer que os usuários OLTP obterão 40% dos recursos, os usuários DSS, 30%, os usuários BATCH, 20% e todos os outros grupos de consumidores obterão 10% dos recursos disponíveis. Se não houver consumidores no grupo OTHER ou DSS_USERS usando os recursos da CPU no momento, o grupo de consumidores OLTP_USERS receberá dois-terços dos recursos disponíveis e o grupo de consumidores BATCH_USERS obterá um-terço.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Mecanismo do Poolde Sessões Ativas

Usuários OLTP

Active_sess_pool_P1=5

Usuários DSS

Active_sess_pool_P1=3

Sess6 Sess7

Sess8

p001 p002 p003

Fila desessões

DSSativas

Sess10

Sess9

Sess1 Sess2

Sess3

Sess5Sess4

Tab deDiretiva 3

Mecanismo do Pool de Sessões AtivasO recurso de pool de sessões ativas permite controlar o número máximo de sessões ativas concorrentes por grupo de consumidores de recursos. Com essa funcionalidade, um DBA pode controlar indiretamente o volume de recursos usado por um grupo de consumidores de recursos, pois o consumo de recursos é proporcional ao número de sessões ativas. Um pool de sessões ativas pode ajudar a reduzir o número de servidores que usam recursos do sistema, evitando a paginação e o swapping ineficientes, além da exaustão de outros recursos (como a memória) resultante da tentativa de execução simultânea de vários jobs. Assim que o pool de sessões ativas for preenchido com sessões ativas, o Resource Manager enfileirará todas as sessões subseqüentes que tentarem se tornar ativas até que outras sessões ativas sejam concluídas ou se tornem inativas. Uma sessão ativa é aquela envolvida no momento em uma transação, consulta ou operação paralela. Os escravos paralelos individuais não são considerados como sessões; a operação paralela inteira é considerada como uma sessão ativa. Existe apenas uma fila por grupo de consumidores de recursos e o método de enfileiramento será o FIFO (First In, First Out) com um timeout. A fila é implementada como uma estrutura da memória e não é possível consultá-la diretamente.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Definindo o Pool de Sessões Ativas

Definindo o Pool de Sessões AtivasCom o Enterprise Manager, é possível configurar facilmente as definições do Pool de Sessões Ativas para um plano de recursos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Tempo Máximo deExecução Estimado

• O Database Resource Manager pode estimar o tempo de execução de uma operação de forma pró-ativa.

• Você pode especificar o tempo máximo de execução estimado para uma operação no nível do grupo de consumidores de recursos.

• A operação não será iniciada se a estimativa for maior que o valor de MAX_EST_EXEC_TIME. (ORA-07455)

• A vantagem deste recurso é a eliminação do job excepcionalmente grande que usa muitos recursos do sistema.

• O default é UNLIMITED.

Tab deDiretiva 5

Tempo Máximo de Execução EstimadoÉ possível definir o tempo máximo de execução estimado de qualquer operação, em qualquer momento, definindo o parâmetro MAX_EST_EXEC_TIME da diretiva de plano de recursos. Após a definição desse parâmetro, o Database Resource Manager estima o tempo de execução de um job específico. Se a estimativa exceder o valor de MAX_EST_EXEC_TIME, a operação não será iniciada, e o erro ORA-07455 será exibido. Isso eliminará qualquer job excepcionalmente grande que utilize muitos recursos do sistema. Se houver mais de uma diretiva de plano referente a um grupo de consumidores de recursos, talvez haja mais de um MAX_EST_EXEC_TIME. para esse grupo. O Database Resource Manager escolhe o valor de entrada mais restritivo de todos. O tempo de execução estimado para determinada instrução é calculado com base nas estatísticas do otimizador baseado em custos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Alternância de Gruposde Consumidores

xx

Tab deDiretiva 6

Alternância de Grupos de ConsumidoresA Console do EM Database Control oferece uma interface gráfica para a configuração da alternância automática de grupos de consumidores. Você pode configurar essa opção quando cria um novo plano de recursos ou edita um plano existente. Observação

• Não é possível definir SWITCH_GROUP como CANCEL_SQL ou KILL_SESSIONusando a Console do EM Database Control.

• Não é possível definir SWITCH_TIME_IN_CALL usando a interface do Enterprise Manager. Você pode definir SWITCH_TIME, que é exibido como Execution Time na tela do slide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Retornando ao Grupo Inicial de Consumidores ao Final da Chamada

Retornando ao Grupo Inicial de Consumidores ao Final da ChamadaVocê pode especificar que, ao final de toda chamada principal, a sessão seja retornada ao seu grupo inicial de consumidores, marcando a caixa de seleção “Switch back to original group after call?” na janela Create Resource Plan. Este é o grupo em que a sessão estava durante o login. A chamada principal é definida como o tratamento de um bloco PL/SQL inteiro como uma chamada ou, de forma semelhante, o tratamento de instruções SQL executadas separadamente pelo cliente como chamadas individuais. Essa funcionalidade é mais útil para as aplicações de três camadas em que o servidor de camada intermediária implementa o pool de sessões. Nesse caso, a camada intermediária tende a fazer uma chamada para um usuário final e, depois, usar a mesma sessão para chamar outro usuário final. Portanto, os limites de trabalho são realmente as chamadas, e as ações de um usuário final anterior não devem afetar o próximo usuário final.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Retornando ao Grupo Inicial de Consumidores ao Final da Chamada

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'Day_Plan',GROUP_OR_SUBPLAN => 'LONGRUN_GROUP',CPU_P1 => 0, CPU_P2 => 100);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'Day_Plan',GROUP_OR_SUBPLAN => 'DSS_GROUP',CPU_P1 => 100, CPU_P2 => 0,SWITCH_GROUP => 'LONGRUN_GROUP',SWITCH_TIME_IN_CALL => 600);

Ao final da chamada

Chamada 1

Chamada 2

Retornando ao Grupo Inicial de Consumidores ao Final da Chamada (continuação)Usando o exemplo de cenário anterior do Enterprise Manager, porém com o procedure DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE, quando um usuário efetua login, o Resource Manager coloca a sessão no grupo de consumidores DSS_GROUP em função de seu mapeamento de grupos iniciais de consumidores. Em seguida, o usuário executa uma consulta. Quando estabelece um valor (em segundos) para o parâmetro SWITCH_TIME_IN_CALL, você está definindo um timer para a chamada antes da execução de uma ação, ditada pelo parâmetro SWITCH_GROUP. Ao final da chamada principal, o Resource Manager retorna automaticamente o usuário ao grupo inicial de consumidores. Observação: Você não pode especificar os parâmetros SWITCH_TIME_IN_CALL e SWITCH_TIME na mesma diretiva. O parâmetro SWITCH_TIME destina-se principalmente a aplicações cliente/servidor.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Definindo Timeouts de Inatividade

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'DAY_PLAN',GROUP_OR_SUBPLAN => 'DSS_GROUP',COMMENT => 'Limit Idle Time Example',MAX_IDLE_TIME => 600,MAX_IDLE_BLOCKER_TIME => 300);

Tab deDiretiva 7

Definindo Timeouts de InatividadeUse a tab Idle Time do plano de recursos para definir os timeouts máximos de inatividade para um plano de recursos. “Max Idle Time (sec)” e “Max Idle Time if Blocking Another Session (sec)” são, respectivamente, equivalentes das diretivas de recursos MAX_IDLE_TIME e MAX_IDLE_BLOCKER_TIME no procedure DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE. Ambos são especificados em segundos. MAX_IDLE_TIME especifica o tempo durante o qual uma sessão não está em execução nem esperando por uma entrada/saída. Quando a sessão excede o limite especificado, o processo PMON a elimina e desativa seu estado. Além de limitar esse tempo, também é possível limitar o período durante o qual uma sessão inativa pode bloquear outra sessão. Para impor esse limite, defina a diretiva de recurso MAX_IDLE_BLOCKER_TIME como o número de segundos para permitir que uma sessão permaneça inativa, ao mesmo tempo em que bloqueia outra sessão. Você também pode especificar um valor UNLIMITED para indicar que não definiu um tempo máximo. O default é NULL, que significa tempo ilimitado. Essas definições permitem um controle mais detalhado do que os perfis, cujo valor único não faz distinção entre sessões bloqueadoras e não bloqueadoras.No exemplo do slide, o processo PMON elimina as sessões inativas por mais de 600 segundos. O processo PMON também encerra as sessões inativas por mais de 300 segundos e que estejam bloqueando outras sessões. O PMON verifica esses limites uma vez a cada minuto e, se encontrar uma sessão que tenha excedido um dos limites, ele a eliminará e removerá todos os seus recursos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Mapeamento de Grupos de Consumidores de Recursos

Conceitos Plano de Recursos Consumidores de Recursos Diretivas de Planos

> Mapeamento Ativação do PlanoMonitoramento

Mapeamento de Grupos de Consumidores de RecursosVocê pode configurar o Database Resource Manager para designar automaticamente grupos de consumidores a sessões estabelecendo mapeamentos entre atributos de sessão e grupos de consumidores. Além disso, pode priorizar os mapeamentos para indicar qual deles terá precedência em caso de conflitos. Há dois tipos de atributos de sessão: atributos de login e atributos de runtime. Os atributos de login (os cinco últimos da lista Attribute Mappings mostrada no slide) são importantes somente durante o login da sessão, quando o Database Resource Manager determina o grupo inicial de consumidores da sessão. Por outro lado, é possível redesignar posteriormente a outro grupo de consumidores uma sessão já conectada, com base nos atributos de runtime. Na home page do Database Control, navegue até a página com a tab Administration e clique no link Resource Consumer Group Mappings na seção Resource Manager. Para cada um dos atributos, configure um mapeamento que consiste em uma forma de identificar uma sessão (por exemplo, nome de usuário) e um grupo de consumidores. Adicione ou remova linhas relativas a cada uma das categorias de grupos de consumidores de recursos, conforme necessário, e informe um texto que identifique o usuário, o cliente, o módulo ou o serviço no grupo correspondente. Para estabelecer uma ordem de prioridade entre os mapeamentos conflitantes dos atributos, use a tab Priorities. Você pode definir a prioridade do mais importante para o menos importante usando as setas de navegação (conforme destacado). Os mapeamentos no início da lista têm a prioridade mais alta. O EM Database Control permite exibir facilmente o código SQL gerado a partir de suas ações quando você clica no botão Show SQL.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Mapeamento de Grupos de Consumidores de Recursos (continuação)

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Ativando um Plano deRecursos para uma Instância

Conceitos Plano de Recursos Consumidores de Recursos Diretivas de Planos Mapeamento

> Ativação do Plano Monitoramento

Ativando um Plano de Recursos para uma InstânciaVocê pode usar a página “Resource Plans” do Enterprise Manager para gerenciar planos de recursos. Para ativar um plano, selecione o plano desejado, escolha “Activate” na lista drop-down Actions e clique em Go. O plano selecionado torna-se o plano principal da instância no momento. Usando o Parâmetro de Inicialização RESOURCE_MANAGER_PLANO plano para uma instância é definido com o parâmetro de inicialização do banco de dados RESOURCE_MANAGER_PLAN. Esse parâmetro especifica o plano principal a ser usado para ainstância. Se não for especificado um plano, o Resource Manager não será ativado para a instância. Para ativar, desativar ou alterar o plano principal atual, use a instrução ALTER SYSTEM. Quando um plano de recursos é alterado com esse comando, a alteração tem efeito instantaneamente. Se o parâmetro for definido em um arquivo de parâmetros e o plano especificado não for definido no banco de dados, não será possível abrir o banco de dados com esse arquivo de parâmetros. O seguinte erro será retornado:

ORA-07452: specified resource manager plan does not exist in the data dictionary

Se esse erro ocorrer, modifique o parâmetro para que ele mostre um valor correto antes de reiniciar a instância.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Informações sobre oDatabase Resource Manager

Usuários/atribuiçõesDBA_RSRC_MANAGER_SYSTEM_PRIVS

Colunainitial_rsrc_ consumer_group

DBA_USERS

Informações Nome da View

Prioridade de mapeamentoDBA_RSRC_MAPPING_PRIORITY

Mapeamento do grupo de consumidores

DBA_RSRC_GROUP_MAPPINGS

Usuários/atribuiçõesDBA_RSRC_CONSUMER_GROUP_PRIVS

Grupos de consumidoresDBA_RSRC_CONSUMER_GROUPS

Diretivas de planosDBA_RSRC_PLAN_DIRECTIVES

Planos e statusDBA_RSRC_PLANS

Informações sobre o Database Resource ManagerHá várias views do dicionário de dados disponíveis para a verificação dos planos de recursos, dos grupos de consumidores e das diretivas de planos declaradas na instância. Esta seção aborda algumas informações úteis que podem ser obtidas nessas views. Para obter informações mais detalhadas sobre o conteúdo de cada uma dessas views, consulte o Oracle Database Reference Manual. Use a seguinte consulta para obter informações sobre os planos de recursos definidos no banco de dados:

SQL> SELECT plan, num_plan_directives, status, mandatory 2 FROM dba_rsrc_plans;

PLAN NUM_PLAN_DIRECTIVES STATUS MAN -------------- ------------------- --------- ---SYSTEM_PLAN 3 ACTIVE NO INTERNAL_QUIESCE 2 ACTIVE YES INTERNAL_PLAN 1 ACTIVE YES BUGDB_PLAN 4 ACTIVE NOMAILDB_PLAN 3 ACTIVE NO MYDB_PLAN 3 ACTIVE NO

O status ACTIVE indica que o plano foi submetido e pode ser usado, enquanto o status PENDING mostra que o plano foi criado, mas ainda está na área pendente.Se for designado o valor YES à coluna mandatory, não será possível deletar o plano.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitorando o Resource Manager

Conceitos Plano de Recursos Consumidores de Recursos Diretivas de Planos Mapeamento Ativação do Plano

> Monitoramento

Monitorando o Resource ManagerVocê pode monitorar o funcionamento do Database Resource Manager no nível de sessão. Ele está integrado ao ADDM (Automatic Database Diagnostic Monitor). Existem diversas maneiras de gerenciar e monitorar o Resource Manager com o EM Database Control. Na página com a tab Administration, clique no link Monitors na seção Resource Manager. A página Resource Monitors exibe um grupo de estatísticas e gráficos que ilustram o estado atual do plano de recursos ativo. Você pode exibir as estatísticas do plano ativo no momento, bem como selecionar um plano na lista e ativá-lo. A tabela Consumer Group Statistics lista uma série de estatísticas dos grupos de consumidores que fazem parte do plano de recursos atual. Observação: Quando ativar um plano na página Resource Monitors, saia da página e escolha Resource Monitors novamente para atualizar essa página e exibir as estatísticas do plano recém-ativado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Monitorando o Resource Manager

• V$SESSION: Contém a coluna resource_consumer_group que mostra o grupo atual de uma sessão

• V$RSRC_PLAN: Uma view que mostra o plano de recursos ativo

• V$RSRC_CONSUMER_GROUP: Uma view que contém estatísticas para todos os grupos ativos

Monitorando o Resource Manager (continuação)Utilização da CPU Existem, no mínimo, três views distintas no sistema que podem exibir informações sobre a utilização da CPU no banco de dados Oracle:

• V$RSRC_CONSUMER_GROUP mostrará as estatísticas de utilização da CPU por grupode consumidores, se você estiver executando o Oracle Database Resource Manager. Essa view exibe dados relacionados aos grupos de consumidores de recursos ativos nomomento.

• V$SYSSTAT mostra o uso de CPU do banco de dados Oracle para todas as sessões. A estatística “CPU used by this session” mostra o consumo agregado de CPU de todas as sessões.

• V$SESSTAT mostra o uso de CPU do banco de dados Oracle por sessão. Você podeusar essa view para determinar qual sessão está usando mais a CPU.

A View V$RSRC_CONSUMER_GROUPVeja uma rápida descrição de algumas das colunas dessa view:

• name: Nome do grupo de consumidores• active_sessions: Número de sessões ativas no momento no grupo de

consumidores• execution_waiters: Número de sessões ativas que esperam por um intervalo de

tempo• requests: Número cumulativo de solicitações executadas no grupo de consumidores• cpu_wait_time: Tempo cumulativo que as sessões esperaram pela CPU• consumed_cpu_time: Tempo cumulativo da CPU consumido por todas as sessões

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Monitorando o Resource Manager (continuação)Nenhuma view mostra diretamente a fila do pool de sessões ativas, mas você pode obter algumas informações em:

• V$SESSION: A coluna current_queue_duration mostra há quanto tempo uma sessão está na fila ou exibirá 0 (zero) caso a sessão não esteja enfileirada no momento.

• V$RSRC_CONSUMER_GROUP: A coluna queue_length mostra o número de sessões enfileiradas no momento por grupo de consumidores.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Configurar o Database Resource Manager • Acessar e criar planos de recursos • Criar grupos de consumidores • Especificar diretivas para alocação de recursos a

grupos de consumidores • Mapear grupos de consumidores para planos • Ativar um plano de recursos • Monitorar o Resource Manager

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício: Usando o Resource Manager

Este exercício aborda os seguintes tópicos: • Criando um grupo de consumidores de recursos • Especificando diretivas de alocação de recursos da

CPU para grupos de consumidores • Associando usuários a um grupo de consumidores

de recursos • Ativando um plano de recursos • Testando no SQL*Plus • Desativando um plano de recursos

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Automatizando Tarefas com o Scheduler

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Objetivos

Ao concluir esta lição, você será capaz de:• Simplificar tarefas de gerenciamento com o

Scheduler• Criar um job, um programa e uma programação • Monitorar a execução de um job• Usar uma programação baseada em horário ou em

evento para executar jobs do Scheduler• Usar cadeias de jobs para executar uma série de

tarefas correlatas • Usar conceitos avançados do Scheduler para

priorizar jobs

Principais Comp. e EtapasProgramaçõesCadeias de JobsConceitos Av.

Objetivos Para obter mais informações sobre os vários componentes do Scheduler e a interação entre eles, consulte o Oracle Database Administrador’s Guide. Para obter mais informações sobre o package DBMS_SCHEDULER, consulte o Oracle Database PL/SQL Packages and Types Reference. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Simplificando Tarefas de Gerenciamento

Executar uma sériede tarefas de fimdo mês no últimodia de cada mês

Replicar dados de tabelaspor meio de atualizaçõesde views materializadas

Calcular estatísticasde tabelas e índicesduas vezes ao dia

Gerar um relatóriohorário sobre as

tentativas inválidasde acesso ao servidor

Executar um job diário de backup

do banco de dados

Iniciar a carga de batchassim que o arquivo chegar

ao sistema de arquivos

Executar um procedure dedesenfileiramento assim

que uma mensagemfor enfileirada

Reconstruir um índice ao terminarde reconstruir o

índice atual

Simplificando Tarefas de Gerenciamento Várias tarefas do ambiente Oracle precisam de recursos de programação de job. A lógica de aplicações e a manutenção de rotina do banco dados exigem a programação e a execução periódica de jobs. As aplicações B2B (Business-to-Business) requerem a programação de seus eventos de negócios. Os DBAs precisam programar jobs regulares de manutenção em janelas de tempo especificadas. O Oracle Database 10g fornece recursos avançados de programação por meio do Scheduler, que é um conjunto de functions e procedures do package DBMS_SCHEDULER. O Scheduler pode ser chamado em qualquer ambiente SQL ou por meio do Enterprise Manager. O Scheduler permite que os administradores de bancos de dados e os desenvolvedores de aplicações controlem quando e onde as tarefas ocorrerão no ambiente do banco de dados. Essas tarefas podem ser complexas e demoradas; com o Scheduler, é possível gerenciá-las e planejá-las. Os jobs do Scheduler podem ser iniciados em um horário definido ou quando um evento específico ocorre; além disso, o Scheduler pode gerar eventos quando o estado de um job é alterado (por exemplo, de RUNNING para COMPLETE). Você também pode usar uma série de programas específicos reunidos para atingir um objetivo comum.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Um Job Simples

O QUÊ

QUANDO

Um Job Simples Os principais componentes de um job são dois: a ação, “o que” precisa ser feito, e a programação, “quando” a ação ocorrerá. A parte “o que” é expressa na região Command da tela mostrada no slide e nos parâmetros job_type e job_action. BEGIN sys.dbms_scheduler.create_job( job_name => '"HR"."CREATE_LOG_TABLE_JOB"', job_type => 'PLSQL_BLOCK', job_action => 'begin

execute immediate (''create table session_history( snap_time TIMESTAMP WITH LOCAL TIME ZONE, num_sessions NUMBER)''); end;',

start_date => systimestamp at time zone 'America/New_York', job_class => 'DEFAULT_JOB_CLASS', comments => 'Create the SESSION_HISTORY table', auto_drop => FALSE, enabled => TRUE); END;

Um job também é definido pelo momento (“quando”) em que a ação desejada precisa ocorrer. A parte “quando” é expressa em uma “programação”, que pode se basear em um horário (consulte o parâmetro start_date) ou em eventos ou pode ainda depender do resultado de outros jobs. Essas opções são abordadas nesta lição.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Principais Componentes e Etapas

Para simplificar as tarefas de gerenciamento com o Scheduler, siga este procedimento: 1. Crie um programa. 2. Crie e use uma programação. 3. Crie e submeta um job. 4. Monitore um job.

Argumentos

Job

Programa Atributos do jobProgramação

Principais Componentes e Etapas O Scheduler oferece um método de divisão por módulos para gerenciar tarefas no banco de dados Oracle. Ao decompor uma tarefa em seus componentes, como tempo, localização e objeto do banco de dados, o Scheduler facilita o gerenciamento do ambiente do banco de dados. O Scheduler utiliza três componentes básicos:

• Um job especifica o que deve ser executado e quando. Alguns exemplos de tarefas que podem ser executadas são um procedure PL/SQL, um executável binário nativo, uma aplicação Java ou um script de shell. Você pode especificar o programa (o que) e a programação (quando) como parte da definição do job ou pode usar um programa ou uma programação existente. É possível usar argumentos para um job a fim de personalizar seu comportamento durante o runtime.

• Uma programação especifica quando e quantas vezes um job deve ser executado. Umaprogramação pode se basear em um horário ou em um evento. Você pode definir uma programação para um job usando uma série de datas, um evento ou uma combinação dos dois, além de especificações adicionais para indicar intervalos de repetição. Você pode armazenar a programação de um job separadamente e usá-la para vários jobs.

• Um programa é um conjunto de metadados sobre um arquivo executável, um script ou um procedure específico. Um job automatizado executa algum tipo de tarefa. O uso de um programa permite modificar a tarefa do job, ou o “conteúdo”, sem modificar o próprio job. Você pode definir argumentos para um programa, permitindo que os usuários modifiquem o comportamento da tarefa durante o runtime.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




1. Criando um Programa

BEGINDBMS_SCHEDULER.CREATE_PROGRAM(

program_name => 'CALC_STATS2',program_action =>

'HR.UPDATE_HR_SCHEMA_STATS',program_type =>

'STORED_PROCEDURE',enabled => TRUE);

END;/

1. Criando um Programa Use o procedure CREATE_PROGRAM para criar um programa. A criação de um programa é um recurso opcional do Scheduler. Você também pode codificar a ação a ser executada em um bloco PL/SQL anônimo do procedure CREATE_JOB. Criando o programa separadamente, você pode definir a ação uma vez e, depois, reutilizá-la em vários jobs. Assim, você pode alterar a programação de um job sem recriar o bloco PL/SQL Também é possível personalizar o job especificando valores de argumentos. Para criar um programa em seu próprio esquema, você precisa do privilégio CREATE JOB. Um usuário com o privilégio CREATE ANY JOB pode criar um programa em qualquer esquema. Por default, o programa é criado no estado desativado (a menos que o parâmetro enabled seja definido como TRUE). Um programa desativado não pode ser executado por um job enquanto não for ativado. Você pode especificar que o programa seja criado no estado ativado especificando o valor TRUE para enabled. A ação do programa é uma string que especifica um procedure, um nome executável ou um bloco PL/SQL anônimo, dependendo da definição de program_type. Se você tiver um procedure chamado UPDATE_HR_SCHEMA_STATS que coleta estatísticas para o esquema hr, poderá criar um programa para chamar esse procedure. No Enterprise Manager, selecione Administration > Programs e clique no botão Create.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




2. Criando e Usando Programações

BEGINDBMS_SCHEDULER.CREATE_SCHEDULE(schedule_name => 'stats_schedule',start_date => SYSTIMESTAMP, end_date => SYSTIMESTAMP + 30,repeat_interval =>'FREQ=HOURLY;INTERVAL=1',

comments => 'Every hour');END;/

2. Criando e Usando Programações Ao utilizar uma programação (em vez de especificar os horários de execução de um job ao defini-lo), você pode gerenciar a execução programada de diversos jobs sem atualizar as respectivas definições. Se uma programação for modificada, todos os jobs que a utilizam passarão automaticamente a usar a nova programação. Use o procedure CREATE_SCHEDULE do package PL/SQL DBMS_SCHEDULER para criar uma programação. O parâmetro start_date representa a data em que a programação se torna ativa. A programação não pode fazer referência a datas anteriores à data especificada e não é válida após end_date. Você pode programar execuções repetidas fornecendo uma expressão de calendário para repeat_interval. Essa expressão é usada para gerar a próxima data da programação. As datas posteriores a end_date não são incluídas na programação. No exemplo do slide, foi criada uma programação denominada STATS_SCHEDULE com um intervalo de repetição de quatro horas, começando neste momento e valendo por 30 dias. Você pode usar o Enterprise Manager para criar programações conforme mostrado no slide.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




3. Criando e Executando um Job

3. Criando e Executando um Job Um job é uma combinação de uma programação e uma descrição do que será feito, acompanhada de argumentos adicionais exigidos por ele. O programa ou “comando” pode ser um programa PL/SQL ou Java preexistente, um bloco PL/SQL anônimo ou um executável que é executado na linha de comandos do sistema operacional. A programação de um job pode ser predefinida (criada com o procedure DBMS_SCHDULER.CREATE_SCHEDULE) ou definida durante a criação do job. A programação especifica atributos sobre o momento em que job será executado, como:

• Um horário de início, que define quando o job será selecionado para execução, e um horário de término, que especifica o horário no qual o job perderá a validade e sairá da programação

• Uma expressão que especifica um intervalo de repetição para o job • Uma programação complexa criada pela combinação das programações existentes • Uma condição ou alteração de estado, chamada de evento, que deve ser cumprida para que

o job seja iniciado Você pode definir vários atributos para um job. Os atributos controlam a forma como o job é executado. Para executar um job no Enterprise Manager, selecione Administration > Jobs.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




4. Monitorando um JobSELECT job_name, status, error#, run_durationFROM USER_SCHEDULER_JOB_RUN_DETAILS;

JOB_NAME STATUS ERROR# RUN_DURATION ---------------- ------ ------ ------------GATHER_STATS_JOB SUCCESS 0 +000 00:08:20 PART_EXCHANGE_JOB FAILURE 6576 +000 00:00:00

4. Monitorando um Job A view DBA_SCHEDULER_JOB_RUN_DETAILS tem uma linha para cada instância do job. Cada linha contém informações sobre a execução do job naquela instância. As views DBA|ALL]_SCHEDULER_JOB_RUN_DETAILS contêm as seguintes colunas:

• LOG_ID: O identificador exclusivo da entrada de log • LOG_DATE: O timestamp da entrada de log • OWNER: O proprietário do job • JOB_NAME: O nome do job • STATUS: O status da execução do job • ERROR#: O número do primeiro erro encontrado • REQ_START_DATE: O horário em que o job foi programado para iniciar • ACTUAL_START_DATE: O horário em que o job foi realmente iniciado • RUN_DURATION: A duração da execução do job • INSTANCE_ID: A instância em que o job foi executado • SESSION_ID: A sessão em que o job foi executado • SLAVE_PID: O ID do processo escravo usado para executar o job • CPU_USED: O volume de CPU usado para executar o job • ADDITIONAL_INFO: Outras informações sobre a execução do job

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Usando uma ProgramaçãoBaseada em Horário ou Evento

Programação

EventoHorário

Principais Comp. e Etapas

> Programações Cadeias de JobsConceitos Av.

Usando uma Programação Baseada em Horário ou Evento Para especificar uma programação baseada em horário para um job, você pode definir uma expressão de calendário ou uma expressão de data/horário. Quando você usa uma expressão de calendário, o próximo horário inicial de um job é calculado com base no intervalo de repetição e na data inicial do job. Quando você usa expressões de data/horário, a expressão especificada determina o próximo horário de execução do job. Se não for definido um intervalo de repetição, o job será executado somente uma vez na data inicial especificada. Se o job usar uma programação baseada em evento, ele será executado quando o evento for gerado. Em um nível alto, um evento pode ser visto como uma alteração de estado. Um evento ocorre quando uma condição booleana altera seu estado de FALSE para TRUE ou de TRUE para FALSE. O Scheduler usa o Oracle Streams AQ (Advanced Queuing) para gerar e consumir eventos. Observação: O Scheduler não garante que um job seja executado no horário exato porque o sistema pode estar sobrecarregado; portanto, os recursos talvez não estejam disponíveis.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando um Job Baseado em Horário

Exemplo:Crie um job que chame um script de backup toda noite às 11:00, a partir desta noite.

BEGINDBMS_SCHEDULER.CREATE_JOB(job_name=>'HR.DO_BACKUP',job_type => 'EXECUTABLE',job_action =>

'/home/usr/dba/rman/nightly_incr.sh',start_date=> SYSDATE,repeat_interval=>'FREQ=DAILY;BYHOUR=23',

/* next night at 11:00 PM */comments => 'Nightly incremental backups');

END;/

Criando um Job Baseado em Horário Use o procedure CREATE_JOB do package DBMS_SCHEDULER para criar um job. Por default, os jobs são criados desativados; eles só se tornam ativos e são programados quando explicitamente ativados. Todos os nomes de jobs têm o formato [schema.]name. Use SYSTIMESTAMP e especifique um fuso horário para que a execução de seu job seja ajustada automaticamente quando o horário de verão entrar em vigor. Por default, um job é criado no esquema atual. Você pode criar um job em outro esquema especificando o nome do esquema, conforme mostrado no exemplo do slide. O proprietário do job é o usuário do esquema no qual o job foi criado, ao passo que o criador do job é o usuário que o criou. Os jobs são executados com os privilégios do respectivo proprietário. O ambiente NLS (national language support) do job quando ele é executado é o mesmo do momento de sua criação. O parâmetro job_type indica o tipo de tarefa a ser executada pelo job. Os valores possíveis são:

• PLSQL_BLOCK: Um bloco PL/SQL anônimo • STORED_PROCEDURE: Um procedure PL/SQL, Java ou externo nomeado • EXECUTABLE: Um comando que pode ser executado na linha de comandos do sistema

operacional.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Criando um Job Baseado em Horário (continuação)O parâmetro job_action pode ser o nome do procedure a ser executado, o nome de um script ou comando do sistema operacional, ou um bloco de código PL/SQL anônimo, dependendo do valor do parâmetro job_type. No exemplo do slide, job_type é especificado como EXECUTABLE, e job_action é o caminho completo dependente do sistema operacional para o executável externo desejado, além dos argumentos de linha de comandos opcionais. Um job externo é aquele executado fora do banco de dados. Todos os jobs externos são executados como usuário guest com poucos privilégios, conforme determinado pelo administrador do banco de dados durante a configuração do suporte a jobs externos. Como o executável é executado como uma conta guest com poucos privilégios, você deve verificar se ele tem acesso aos arquivos e recursos necessários. A maioria das plataformas, mas não todas, suporta jobs externos. Em plataformas que não suportam jobs externos, a criação ou a definição do atributo de um job ou programa como o tipo EXECUTABLE retorna um erro. Consulte a documentação específica da plataforma do seu banco de dados Oracle para obter mais informações sobre como configurar o ambiente para executar programas externos com o Scheduler. Por exemplo, talvez seja necessário consultar um ou mais destes documentos:

• Oracle Database Platform Guide 10g for Windows• Oracle Database Installation Guide for UNIX Systems• Oracle Database Release Notes 10g for AIX-Based Systems • Oracle Database Release Notes 10g for hp HP-UX PA-RISC (64-bit)

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando uma Programação Baseada em Evento

Para criar um job baseado em evento, é preciso definir: • Uma especificação de fila (onde sua aplicação

enfileira as mensagens para iniciar o job) • Uma condição de evento (mesma sintaxe usada

como uma condição de regra do Oracle Streams AQ) que, se definida como TRUE, inicia o job

Oracle Database 10g

Scheduler

ADT de Evento(Tipo de Dados

Abstrato) FilaAplicação

Criando uma Programação Baseada em Evento Os jobs podem ser acionados com base em eventos. Uma aplicação pode instruir o Scheduler a iniciar um job incluindo uma mensagem na fila do Oracle Streams AQ. Um job iniciado dessa forma é chamado de job baseado em evento. Para criar um job baseado em evento, defina os seguintes atributos adicionais com o procedure CREATE_JOB:

• queue_spec: Uma especificação de fila que inclui o nome da fila na qual a aplicação coloca as mensagens para gerar eventos que acionarão o job ou, no caso de uma fila segura, o par <queue_name>, <agent_name>

• event_condition: Uma expressão condicional baseada em propriedades da mensagem que deve ser avaliada como TRUE para que a mensagem inicie o job. A expressão deve usar a mesma sintaxe de uma condição de regra do Oracle Streams AQ. Você pode incluir propriedades de dados do usuário na expressão, desde que o payload da mensagem seja um tipo de objeto definido pelo usuário e que você inclua prefixos nos atributos de objeto da expressão tab.user_data.

Você pode especificar queue_spec e event_condition como atributos de job em linha, ou criar uma programação baseada em evento com esses atributos e, depois, criar um job que faça referência a essa programação.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando Programações Baseadasem Evento com o Enterprise Manager

Criando Programações Baseadas em Evento com o Enterprise ManagerA página Create Schedule permite escolher entre uma programação padrão baseada em horário e uma programação baseada em evento. Se você escolher uma programação baseada em evento, a interface será alterada e será possível especificar o nome da fila, o nome do agente e a condição do evento, além de outros atributos de programação. Observação: O Scheduler executa o job baseado em evento para cada ocorrência de um evento que atenda à condição event_condition. No entanto, são ignorados os eventos que ocorrem enquanto o job já está em execução; os eventos são consumidos, mas não acionam outra execução do job. Referências:

• Consulte Oracle Streams Advanced Queuing User’s Guide and Reference para obter mais informações sobre como criar filas e enfileirar mensagens.

• Para obter mais informações sobre as condições de eventos e regras, consulte a seção sobre o procedure DBMS_AQADM.ADD_SUBSCRIBER no manual Oracle Database PL/SQL Packages and Types Reference 10g Release 2.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando um Job Baseado em Evento

Exemplo: Crie um job que seja executado se um arquivo de dados de carga de batch chegar ao sistema de arquivos até às 9:00 da manhã.BEGINDBMS_SCHEDULER.CREATE_JOB(job_name=>'ADMIN.PERFORM_DATA_LOAD',job_type => 'EXECUTABLE',job_action => '/home/usr/dba/rman/report_failure.sh',start_date => SYSTIMESTAMP, event_condition => 'tab.user_data.object_owner = ''HR'' and tab.user_data.object_name = ''DATA.TXT'' and tab.user_data.event_type = ''FILE_ARRIVAL'' and tab.user_data.event_timestamp < 9 ',queue_spec => 'HR.LOAD_JOB_EVENT_Q');

END;

event_condition => 'tab.user_data.object_owner = ''HR'' and tab.user_data.object_name = ''DATA.TXT'' and tab.user_data.event_type = ''FILE_ARRIVAL'' and tab.user_data.event_timestamp < 9 ',queue_spec => 'HR.LOAD_JOB_EVENT_Q');

Criando um Job Baseado em Evento Para especificar informações do evento como atributos do job, use uma sintaxe alternativa de CREATE_JOB que inclua os atributos queue_spec e event_condition. O job pode conter informações de evento em linha como atributos ou pode especificar informações de evento apontando para uma programação de evento. O exemplo do slide usa uma programação baseada em evento em linha. Esse exemplo mostra um job que será iniciado quando um arquivo chegar ao sistema operacional, desde que o arquivo chegue até às 9:00 da manhã. Suponha que o payload da mensagem seja um objeto com quatro atributos chamados object_owner, object_name, event_type e event_timestamp. O exemplo usa um evento definido pelo usuário. Portanto, antes que o job seja iniciado, quando o arquivo chegar ao sistema de arquivos, um programa ou um procedure deverá colocar o tipo de objeto de evento com as informações adequadas na fila de eventos especificada. A fila HR.LOAD_JOB_EVENT_Q deve ser do mesmo tipo do objeto de evento usado para notificar o Scheduler sobre a ocorrência de um evento. Ou seja, a fila HR.LOAD_JOB_EVENT_Q precisa ser uma fila do tipo que tem quatro atributos chamados object_owner, object_name, event_type e event_timestamp. Para obter mais informações sobre como criar filas e enfileirar mensagens, consulte a documentação Oracle Streams Advanced Queuing User’s Guide and Reference.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Programação Baseada em Evento

Tipos de eventos: • Eventos gerados pelo usuário ou por aplicações • Eventos gerados pelo Scheduler Eventos gerados por jobs do Scheduler: • JOB_START • JOB_SCH_LIM_REACHED

• JOB_SUCCEEDED • JOB_DISABLED

• JOB_FAILED • JOB_CHAIN_STALLED

• JOB_BROKEN • JOB_ALL_EVENTS

• JOB_COMPLETED • JOB_RUN_COMPLETED

• JOB_STOPPED

Exemplo de geração de um evento: DBMS_SCHEDULER.SET_ATTRIBUTE('hr.do_backup', 'raise_events', DBMS_SCHEDULER.JOB_FAILED);

Programação Baseada em Evento Em vez de designar uma programação a um job, você pode criar um job que seja iniciado por meio de uma referência direta a um evento. Há dois tipos de eventos:

• Eventos gerados pelo usuário ou por uma aplicação: Uma aplicação pode gerar um evento a ser consumido pelo Scheduler. O Scheduler reage ao evento iniciando um job. Um exemplo de um evento desses: um job é concluído; um arquivo chega ao sistema de arquivos; uma conta no banco de dados é bloqueada; e o inventário atinge um limite inferior.

• Eventos gerados pelo Scheduler: O Scheduler pode gerar um evento para indicar alterações de estado que ocorrem no próprio Scheduler. Por exemplo, o Scheduler pode gerar um evento quando um job é iniciado, quando ele é concluído, quando excede o runtime atribuído a ele e assim por diante. O consumidor do evento é uma aplicação que executa uma ação em resposta ao evento.

Você pode configurar um job de forma que, quando houver uma alteração em seu estado, o Scheduler gere um evento. Para fazer isso, defina o atributo de job raise_events. Por default, um job não gera um evento de alteração de estado até que você altere o atributo raise_events do job. Para alterar esse atributo, primeiro crie o job usando o procedure CREATE_JOB e, depois, use o procedure SET_ATTRIBUTE para modificar o valor default do atributo. O exemplo mostra que o job hr.do_backup é alterado para, em caso de falha, gerar um evento.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Programação Baseada em Evento (continuação)Depois que você ativa os eventos de alteração de estado de um job, o Scheduler gera esses eventos colocando mensagens na fila de eventos default SYS.SCHEDULER$_EVENT_QUEUE. A fila de eventos default do Scheduler é uma fila segura. Dependendo da aplicação, talvez seja preciso configurar a fila para permitir que certos usuários executem operações nela. Consulte a documentação Oracle Streams Concepts and Administration para obter mais informações sobre filas seguras. A fila de eventos default do Scheduler destina-se principalmente a eventos gerados pelo Scheduler. A Oracle não recomenda o uso dessa fila para aplicações do usuário ou para eventos definidos pelo usuário.

O limite da programação do job é alcançado. O job não é iniciado porque o atraso em iniciá-lo ultrapassou o valor do atributo de job SCHEDULE_LIMIT.

JOB_SCH_LIM_REACHED

O job é desativado pelo Scheduler ou por uma chamada do procedure SET_ATTRIBUTE.

JOB_DISABLED

Um job executando uma cadeia é colocado no estado CHAIN_STALLED. Uma cadeia em execução será bloqueada se não houver etapas em execução ou programadas para execução e se o atributo EVALUATION_INTERVAL da cadeia for definido como NULL. A cadeia aguardará intervenção manual.

JOB_CHAIN_STALLED

JOB_ALL_EVENTS não é um evento, mas uma constante que facilita a ativação de todos os eventos.

JOB_ALL_EVENTS

Uma execução de job é concluída. A execução pode ter falhado, ter obtido êxito ou ter sido interrompida.

JOB_RUN_COMPLETED

O job é interrompido por uma chamada do procedure STOP_JOB.

JOB_STOPPED

O job é concluído porque atingiu os valores definidos pelos atributos de job MAX_RUNS ou END_DATE.

JOB_COMPLETED

O job é desativado e seu estado é alterado para BROKENporque ele ultrapassou o número de falhas definidas pelo atributo de job MAX_FAILURES.

JOB_BROKEN

Ocorreu uma falha no job que resultou na geração de um erro ou em seu encerramento anormal.

JOB_FAILED

O job é concluído com êxito.JOB_SUCCEEDED

O job é iniciado.JOB_START

DescriçãoTipo de Evento

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando Programações Complexas

INCLUDE EXCLUDE INTERSECT

Criando Programações Complexas Uma programação é um objeto do banco de dados. Quando você cria programações, elas são salvas automaticamente. Você pode usar combinações de programações para criar outras mais complexas. Ao combinar programações, você pode adicionar ou excluir datas específicas de uma expressão de calendário. É possível usar as seguintes opções ao definir o intervalo de repetição de uma programação:

• INCLUDE: Adiciona uma lista de datas aos resultados da expressão de calendário • EXCLUDE: Remove uma lista de datas dos resultados da expressão de calendário • INTERSECT: Usa somente as datas comuns a uma ou mais programações

Ao criar programações a serem usadas em combinações, você pode codificar a lista de datas incluindo datas codificadas na forma [YYYY]MMDD ou incluindo programações nomeadas criadas com o procedure CREATE_SCHEDULE. Por exemplo, você pode especificar uma lista de datas usando os seguintes valores para o intervalo de repetição de uma programação:

0115,0315,0325,0615,quarter_end_dates,1215

Essa string representa as datas de 15 de janeiro, 15 de março, 25 de março, 15 de junho, 15 de dezembro e a lista de datas especificada pela programação QUARTER_END_DATES. Se você não especificar o componente de ano opcional para as datas codificadas na programação, serão incluídas as datas para todos os anos.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando Cadeias de Job

1. Crie um objeto de cadeia. 2. Defina as etapas da cadeia. 3. Defina as regras da cadeia. 4. Iniciando a cadeia:

– Ative a cadeia. – Crie um job que aponte para a cadeia.

Job

Cadeia de job

Principais Comp. e Etapas Programações

> Cadeias de JobsConceitos Av.

Criando Cadeias de Job Uma cadeia é uma série de programas vinculados para atingir um objetivo comum, o que é conhecido como “dependency scheduling” (programação de dependência). Veja um exemplo de cadeia: Executar o programa A, depois o programa B, mas executar o programa C somente se os programas A e B forem concluídos com êxito; caso contrário, executar o programa D. Cada posição de uma cadeia de programas interdependentes é chamada de etapa. Para criar e usar uma cadeia, as etapas devem ser executas em ordem. Todos os procedures mencionados fazem parte do package DBMS_SCHEDULER, salvo indicação em contrário.

1. Crie uma cadeia usando o procedure CREATE_CHAIN. Como alternativa, o nome da cadeia pode ser qualificado com um nome de esquema (por exemplo,myschema.myname).

2. Defina (uma ou mais) etapas da cadeia. Definir uma etapa significa nomeá-la e especificar o que ela faz. Cada etapa pode apontar para um dos seguintes itens:

– Um programa – Outra cadeia (uma cadeia aninhada) – Um evento

Para definir uma etapa que aponte para um programa ou uma cadeia aninhada, chame o procedure DEFINE_CHAIN_STEP.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ



Criando Cadeias de Job (continuação)(Definindo Etapas, continuação)

Para definir uma etapa que aguarda a ocorrência de um evento, use o procedure DEFINE_CHAIN_EVENT_STEP. Os argumentos do procedure podem apontar para uma programação de evento ou podem incluir uma especificação de fila em linha e uma condição de evento. Uma etapa que aponta para um evento aguarda até que o evento especificado seja gerado. Se o evento ocorrer, a etapa será concluída com êxito.

3. Depois de criar o objeto de cadeia, defina as regras da cadeia. Essas regras determinam quando executar as etapas e definem as dependências entre elas. Cada regra tem uma condição e uma ação:

– Se a condição for avaliada como TRUE, a ação será executada. A condição pode conter qualquer sintaxe válida em uma cláusula SQL WHERE. Geralmente, as condições se baseiam no resultado de uma ou mais etapas anteriores. Por exemplo, você pode definir a execução de uma etapa caso as duas etapas anteriores sejam concluídas com êxito e pode determinar a execução de uma outra etapa caso ocorra uma falha nas duas etapas anteriores.

– A ação especifica o que deve ser feito depois que a regra é acionada. Uma ação típica é a execução de uma etapa especificada. As ações possíveis incluem iniciar ou interromper uma etapa. Você também pode optar por encerrar a execução da cadeia de job, retornando um valor ou um nome de etapa e um código de erro.

Todas as regras adicionadas a uma cadeia funcionam juntas para definir o comportamento geral da cadeia. Quando o job é iniciado ao final de cada etapa, todas as regras são avaliadas para identificar a ação ou as ações que devem ocorrer em seguida. Adicione uma regra a uma cadeia com o procedure DEFINE_CHAIN_RULE. Chame esse procedure uma vez para cada regra que você deseja adicionar à cadeia.

4. Iniciar a cadeia envolve duas ações: – Ative uma cadeia com o procedure ENABLE. (A cadeia é sempre criada desativada;

assim, você pode adicionar etapas e regras antes que ela seja executada por um job.) Ativar uma cadeia já ativada não retorna um erro.

– Para executar uma cadeia, é necessário criar um job do tipo 'CHAIN'. A ação do job deve fazer referência ao nome da cadeia. Você pode usar programações baseadas em evento ou em horário para esse job.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Exemplo de Cadeia

BULK_LOAD_CHAIN

Do_bulk_loadJob Load_data_evt

FIM

Rebuild_indxProgramaçãoStop_when_

disk_full_evt

Run_reports(HR.GEN_REPORTS)

INÍCIO 1 2

5 3

4

Programação de Dependência

Exemplo de Cadeia Como exemplo de cadeia, considere todas as tarefas e as condições que ocorrem durante uma carga de dados em alto volume. Primeiro, obtenha os dados a serem carregados. Depois, carregue os dados observando o sistema de arquivos para assegurar que haja espaço suficiente durante a carga. Ao fim da carga de dados, recrie os índices definidos nas tabelas de atualização. Em seguida, execute relatórios sobre os dados recém-carregados. Eis um exemplo de programação de dependência.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




1. Criando um Objeto de Cadeia

Create_job_chain_1.jpg

12345

1. Criando um Objeto de Cadeia Na página Administration, selecione Chains na região Scheduler. Na página Scheduler Chains, você pode criar ou editar uma cadeia de job. Na página Create Chain, informe o nome e o proprietário da cadeia de job. Decida então se a cadeia de job recém-criada deverá ser ativada ou não. Você pode ativar a cadeia posteriormente. Exemplo de PL/SQL:

DBMS_SCHEDULER.CREATE_CHAIN ( chain_name => 'bulk_load_chain', rule_set_name => NULL, evaluation_interval => NULL, comments => 'Load data and run reports');

Depois de nomear a cadeia de job e, opcionalmente, fornecer uma descrição, informe as etapas da cadeia, uma por vez. Você pode criar etapas dos seguintes tipos:

• Uma etapa que execute um programa (PROGRAM) • Uma etapa que constitua outra cadeia de job (SUBCHAIN) • Uma etapa que use uma programação armazenada baseada em evento

(EVENT_SCHEDULE) Apenas um programa pode ser executado durante cada etapa. Para poder ativar e usar a cadeia, você precisa primeiro definir cada uma das etapas.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




2. Definindo Etapas da Cadeia

DBMS_SCHEDULER.DEFINE_CHAIN_EVENT_STEP (chain_name => 'bulk_load_chain',step_name => 'load_data_evt',event_condition => 'tab.user_data.object_owner =

''HR'' and tab.user_data.object_name = ''DATA.TXT'' and tab.user_data.event_type = ''FILE_ARRIVAL'' ',

queue_spec => 'HR.LOAD_JOB_EVENT_Q');DBMS_SCHEDULER.DEFINE_CHAIN_STEP (

chain_name => 'bulk_load_chain', step_name => 'do_bulk_load', program_name => 'hr.load_data_prog);

DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => 'bulk_load_chain', step_name => 'rebuild_indx', program_name => 'hr.rebuild_indexes');

1

2

3

2. Definindo Etapas da Cadeia 1. A etapa load_data_evt utiliza uma programação baseada em evento. Essa etapa espera

até que o evento FILE_ARRIVAL seja colocado em HR.LOAD_JOB_EVENT_Q. Esse evento avisa ao Scheduler que o arquivo de dados DATA.TXT chegou ao sistema de arquivos. Como o argumento queue_spec não contém um nome de agente, a fila especificada não é segura.

2. A etapa do_bulk_load executa uma carga de dados em alto volume nas tabelas do esquema.

3. A etapa rebuild_indx reconstrói os índices das tabelas após a carga de dados. 4. A etapa run_reports gera um relatório sobre os novos dados. HR.GEN_REPORTS é

outra cadeia de job. DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => 'bulk_load_chain', step_name => 'run_reports', program_name => 'hr.gen_reports');

5. A etapa stop_when_disk_full_evt encerrará a execução da cadeia se o sistema detectar falta de espaço no disco.

DBMS_SCHEDULER.DEFINE_CHAIN_EVENT_STEP ( chain_name => 'bulk_load_chain', step_name => 'stop_when_disk_full_evt' event_schedule_name => 'disk_full_sched')

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




3. Definindo Regras da Cadeia

Create_job_chain_2.jpg

3. Definindo Regras da Cadeia Após especificar as etapas da cadeia do job, você pode criar regras para ela. As regras determinam quando as etapas serão executadas e definem as dependências entre elas. Cada regra tem uma condição e uma ação. Se a condição for avaliada como TRUE, a ação será executada. A condição também pode conter a sintaxe da cadeia do Scheduler. Para criar uma regra no EM, clique no botão Add na região Rules.Ao informar condições de regras, digite as strings de caracteres entre aspas simples. A interface GUI ignora as aspas conforme necessário ao executar os comandos.Exemplo de PL/SQL DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => 'bulk_load_chain', condition => 'TRUE, action => 'START load_data_evt,stop_when_disk_full_evt', rule_name => 'dataload_rule1', comments => 'start the chain');

Observação: Esse exemplo de PL/SQL usa um nome de regra definido pelo usuário, enquanto o exemplo do EM mostra o nome gerado por default.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




4. Iniciando a Cadeia

BEGIN DBMS_SCHEDULER.ENABLE ('bulk_load_chain');

END; /

BEGIN DBMS_SCHEDULER.CREATE_JOB (

job_name => 'bulk_load_chain_job', job_type => 'CHAIN', job_action => 'bulk_load_chain', repeat_interval => 'freq=daily;byhour=7;

byminute=5;bysecond=0', enabled => TRUE);

END; /

4. Iniciando a Cadeia Após criar e modificar a cadeia de job, ative-a chamando o procedure ENABLE. Para executar uma cadeia, é necessário criar um job. Defina job_type como 'CHAIN' e a ação do job como o nome da cadeia de job que você deseja executar. Configure os outros argumentos como faria com qualquer outro tipo de job. O

racl

e U

nive

rsity

and

Impa

cta

Tecn

olog

ia u

se o

nlyฺ




Monitorando Cadeias de Job

[DBA | ALL | USER]_SCHEDULER_CHAINS

[DBA | ALL | USER]_SCHEDULER_CHAIN_RULES

[DBA | ALL | USER]_SCHEDULER_CHAIN_STEPS

[DBA | ALL | USER]_SCHEDULER_RUNNING_CHAINS

Monitorando Cadeias de Job A view ALL_SCHEDULER_CHAINS contém informações como o proprietário e o nome da cadeia; o proprietário e o nome do conjunto de regras da cadeia; o número de regras; o número de etapas; se a cadeia está ativada ou não; se a cadeia usa um intervalo de avaliação ou não; e se a cadeia usa um conjunto de regras definido pelo usuário ou não.A view ALL_SCHEDULER_CHAIN_RULES mostra informações como o nome e o proprietário da cadeia para a qual a regra foi definida; o nome, o proprietário e a condição da regra; e ação a ser executada se a condição for avaliada como TRUE. A view ALL_SCHEDULER_CHAIN_STEPS mostra informações como o nome e o proprietário da cadeia para a qual a etapa foi criada; o nome da etapa; o nome e o proprietário do programa; se a etapa deve ser ignorada ou não; e se a etapa deve ser interrompida após sua conclusão ou não. A view ALL_SCHEDULER_RUNNING_CHAINS contém informações como o nome e o proprietário da cadeia; o nome e o proprietário do job que aponta para a cadeia; o nome das etapas da cadeia e respectivos estados atuais; os erros encontrados pela etapa; o horário de início e de término da etapa; a duração da etapa; e o nome do job que está executando a etapa, caso ela esteja em execução no momento.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Conceitos Avançados do Scheduler

JobPrograma

Argumentos Argumentos

Programação

EventoHorário

Classe de job Janela de tempoCadeia de job

Grupo deConsumidores

de recursos

Grupode janelasde tempo

Plano derecursos

Principais Comp. e Etapas ProgramaçõesCadeias de Jobs

> Conceitos Av.

Conceitos Avançados do Scheduler Com os conceitos avançados do Scheduler, você pode ter um controle mais preciso sobre aspectos da programação, como a priorização de jobs. Os componentes são resumidos abaixo e abordados com detalhes nos próximos slides.

• Uma janela de tempo é representada por um intervalo com um início e um fim bem definidos, e é usada para ativar planos de recursos diferentes em momentos distintos. Com ela, você pode alterar a alocação de recursos durante um período, como um horário do dia ou um período anual de vendas.

• Um grupo de janelas de tempo representa uma lista de janelas de tempo, o que facilita seu gerenciamento. Você pode usar uma janela de tempo ou um grupo de janelas de tempo como a programação de um job para garantir que esse job só seja executado quando uma janela de tempo e seu plano de recursos associado estiverem ativos.

• Uma classe de job define uma categoria de jobs que compartilham necessidades comuns de uso de recursos e outras características. Uma classe de job agrupa os jobs em entidades maiores.

• Um grupo de consumidores de recursos associado à classe de job determina os recursos alocados para os jobs da classe.

• Um plano de recursos permite que os usuários priorizem recursos (principalmente a CPU) entre grupos de consumidores de recursos.

Observação: Para obter mais informações sobre grupos de consumidores de recursos e planos de recursos, consulte a lição “Gerenciando Recursos”.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando uma Classe de Job

EXECUTE DBMS_SCHEDULER.CREATE_JOB_CLASS( -job_class_name => 'ADMIN_JOBS', -resource_consumer_group => 'DAYTIME_JOBS', -logging_level => DBMS_SCHEDULER.LOGGING_OFF);

Criando uma Classe de Job Você pode usar o procedure CREATE_JOB_CLASS do package DBMS_SCHEDULER para criar uma classe de job. Uma classe sempre pertence ao esquema sys. Para criar uma classe, você precisa do privilégio MANAGE SCHEDULER. Após a criação de uma classe de job, você poderá especificar jobs como membros dessa classe quando criá-los ou depois que eles forem gerados com o procedure SET_ATTRIBUTE do package DBMS_SCHEDULER. Se estiver usando o Enterprise Manager Database Control, utilize a página Job Class para criar ou editar uma classe de job que você designará a um job. Informe o nome da classe de job e o grupo de consumidores de recursos ao qual essa classe está associada. Você pode selecionar o grupo de consumidores de recursos usando a função de pesquisa. Existe uma classe de job default chamada DEFAULT_JOB_CLASS que é criada com o banco de dados. Se um job não for associado a uma classe, ele pertencerá a essa classe default. Se não for especificado um grupo de consumidores de recursos quando uma classe de job for criada, a classe será mapeada para o grupo de consumidores de recursos DEFAULT_CONSUMER_GROUP. Os jobs da classe de job default ou de uma classe de job associada ao grupo de consumidores de recursos default talvez não tenham recursos alocados suficientes para concluir as respectivas tarefas quando o Resource Manager for ativado.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Criando uma Janela de Tempo

Crie uma janela de tempo para o mês de dezembro que use o plano de recursos END_OF_YEAR e que seja ativada todas as noites das 18:00 às 6:00 no Horário Padrão do Leste. BEGINDBMS_SCHEDULER.CREATE_WINDOW(

window_name => 'DEC_NIGHTS',resource_plan => 'END_OF_YEAR',start_date => '01-DEC-03 06.00.00 PM EST',repeat_interval => 'FREQ=DAILY; BYHOUR=18',duration => '0 12:00:00',end_date => '31-DEC-03 06.00.00 AM EST',comments => 'Every day at 6:00 PM');

END;/

Criando uma Janela de Tempo A prioridade dos jobs é alterada durante um período. Por exemplo, talvez você queira alocar um alto percentual de recursos do banco de dados para jobs de carga de data warehouse à noite, e alocar um percentual ainda mais alto de recursos para os jobs de aplicações durante o dia. Para fazer isso, você pode alterar o plano de recursos do banco de dados usando uma janela de tempo do Scheduler. O objetivo de uma janela de tempo é especificar o plano de recursos que estará ativo em um período específico. A janela de tempo é representada por um intervalo, como “todo dia, das 8:00 às 18:00”. A janela de tempo de repetição é definida como uma programação que especifica um padrão de datas iniciais e uma duração (em minutos). Uma janela de tempo é considerada aberta quando está em vigor. Apenas uma janela de tempo pode estar aberta de cada vez. No exemplo do slide:

• O janela de tempo é aberta (fica ativa) às 18:00 do dia 1 de dezembro de 2003. • A duração, especificada como um tipo de dados INTERVAL DAY TO SECOND, indica

que a janela de tempo será fechada às 6:00 de 2 de dezembro de 2003. • A próxima abertura da janela de tempo será calculada com base no valor de REPEAT_INTERVAL, avaliado como 18:00 de 2 de dezembro de 2003.

• Às 6:00 de 31 de dezembro de 2003, a janela de tempo será fechada e desativada. Enquanto a janela de tempo DEC_NIGHTS estiver aberta, os recursos alocados para os jobs serão determinados pelas diretrizes especificadas no plano de recursos END_OF_YEAR.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Priorizando Jobs em uma Janela de Tempo

Janela de tempo diurna

APPL_JOBS

Job1 Job2

ADMIN_JOBS

Job4 Job5OTHER

Job3

2Job5

5Job4

3Job3

2Job2

1Job1

PrioridadeJob

Priorizando Jobs em uma Janela de Tempo Ao criar vários jobs em um banco de dados, você precisa encontrar uma maneira de alinhar o processamento dos jobs com as necessidades de negócios e especificar os jobs com a prioridade mais alta. Em uma janela de tempo específica, é possível executar diversas classes de jobs, cada uma com sua própria prioridade. As classes de job são usadas para categorizar jobs. A classe de job é mapeada para um grupo de consumidores de recursos. O plano de recursos ativo determina os recursos alocados para cada grupo de consumidores de recursos e, portanto, para cada classe de job. É possível priorizar jobs em dois níveis: no nível da classe e no nível do job.

• Em primeiro lugar, é estabelecida a prioridade no nível da classe usando planos de recursos. A priorização entre jobs de classes diferentes é efetuada unicamente com base em uma alocação de recursos para classes.

• Em seguida, é estabelecida a prioridade na classe usando o atributo de prioridade do job. Os níveis de priorização só são relevantes quando dois jobs da mesma classe devem ser iniciados ao mesmo tempo. O job com a prioridade mais alta é iniciado primeiro. A priorização não é garantida para os jobs de classes distintas. Por exemplo, um job da classe APPL_JOBS com prioridade alta talvez não seja iniciado antes de um job da classe ADMIN_JOBS com prioridade baixa, embora compartilhem a mesma programação. Se a classe de job APPL_JOBS tiver um nível menor de recursos disponíveis, o job com prioridade alta dessa classe aguardará até que os recursos estejam disponíveis, mesmo que existam recursos disponíveis para jobs de prioridade menor em outra classe.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Sumário

Nesta lição, você aprendeu a: • Simplificar tarefas de gerenciamento com o

Scheduler • Criar um job, um programa e uma programação • Monitorar a execução de um job • Usar uma programação baseada em horário ou em

evento para executar jobs do Scheduler • Usar cadeias de jobs para executar uma série de

tarefas correlatas • Usar conceitos avançados do Scheduler para

priorizar jobs

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ




Visão Geral do Exercício:Automatizando Tarefas com o Scheduler

Este exercício aborda os seguintes tópicos: • Criação de um job que execute um programa fora do

banco de dados • Criação de um programa e de uma programação • Criação de um job que use um programa e uma

programação • Alteração do programa e da programação do job e

observação da mudança de comportamento desse job • Monitoramento de execuções de jobs

Visão Geral do Exercício Observação: Este exercício usa o Enterprise Manager Database Control e o SQL*Plus.

Ora

cle

Uni

vers

ity a

nd Im

pact

a Te

cnol

ogia

use

onl

yฺ


Banco de Dados Oracle 10g - Workshop de Administração II Vol.I.pdf

Documents

Transcript of Banco de Dados Oracle 10g - Workshop de Administração II Vol.I.pdf