Blog do Rodrigo Almeida

Olá,

Um assunto muito pouco abordado entre os profissionais Oracle e que sempre causa estresse e problemas quando necessário, e a eficiência da estratégia de backup & recover de um determinado banco de dados da empresa, pois todos só prestam atenção nesse assunto quanto é necessário e já está com a corda no pescoço.

Para ter uma eficiente estratégia de backup & recover, primeiramente deve-se conhecer a infra-estrutura que a empresa oferece para adequar as soluções de backup e planejar quais estratégias e técnicas que serão aplicadas. E quando estamos falando de infra-estrutura, diversos pontos devem ser destacados, como:

• Rede LAN dedicada para backup & recover;
• Dispositivos de Fita (DLT, LTO e DDS) disponíveis para armazenamento;
• Se existe uma necessidade de storage para backup em disco, é viável uma aquisição?;
• Se existe servidores dedicados para testes e validação de restore e recover;
• A empresa possui outro site para planejar estratégias de backup;
• Se a empresa centraliza backups de outras unidades, qual o tamanho da banda de rede.

O segundo ponto que deve ser analisado é a politíca de backup de cada banco de dados, tratado de forma única, pois em banco de dados, pelo mais que seja padronizado as instalações, arquitetura e funcionalidades de cada base, necessita de políticas de backup customizadas, onde a aplicação da empresa que irá ditar as principais regras, e existem pontos que merecem atenção, como:

• Tempo para janela de recuperação;
• Tempo de retenção dos dados;
• Agendamento das rotinas de backup, exemplo: diáriamente, semanalmente, mensalmente ou anual;
• Volumetria que será armazenada;
• Nível de proteção dos dados;
• Tipos de backups que serão executados;
• Definicação dos procedimentos de backup, restore e recover.

Os dois pontos citados, é o início para enxergar as deficiências da empresa ao elaborar as estratégias de backup, são os principais pontos que devem ser levantados para posteriormente planejar as melhores técnicas e politícas adequadas para as bases.

Não adianta o DBA ter diversas ideias e soluções de armazenamento e recuperações ótimas se a empresa não permite ou não suporta tais tarefas. Seria uma frustação ao profissional tentar implementar uma solução sem sucesso ou com diversos problemas e que não consegue atingir o principal objetivo que é a segurança dos dados e disponibilidade do banco de dados.

Em relação ao assunto, soluções de backup,  existem diversas no mercado, a própria Oracle oferece diversas soluções de backup interessantes, como Oracle Secure Backup, Data Guard, Stand-by Database, Recovery Manager (RMAN) e Legato Single Server. Outros produtos de terceiros podem oferecer soluções adequadas a sua empresa, como: CA BrightStor ArcServer e Backup Exec, Symantec NetBackup, IBM Tivoli ou EMC NetWorker. Tudo é uma questão de analise, planejamento e execução na implantação da solução, e é claro, verificar se o valor da solução está dentro do orçamento do departamento de TI.

Agora, aos DBAs, existem técnicas e práticas que podemos aplicar, para complementar as estratégias de backup existentes e outras práticas que devem possuir requisitos citados no início, principalmente na parte de infra-estrutura. Quando vamos pensar em backup & recover, O que lhe vem na cabeça? Vamos montar uma lista com as opções:

1. Backup cold;
2. Backup hot;
3. Backup por tablespace;
4. Backup do control file;
5. Export do banco de dados;
6. Arquivos de carga (originadas do ETL ou de algum outro processo);
7. Cópia fria de um servidor para o outro;
8. Cópia dos objetos de banco;
9. E no pior das hípoteses, garantia de alguma coisa no ambiente de desenvolvimento e homologação.

OK! Percebeu que estamos falando de um assunto delicado e de forma abrangente, sem determinar o que será feito, se existe procedimento para tal, quais as garantias que vou ter e sempre pensando naquela frase linda e determinante:

“Backup bom é aquele que volta”

Agora, vamos discutir um pouco sobre os tipos de backups citados acima.

Backup Frio (Cold Backup), backup realizado com o banco de dados offline, ou seja consistente.

O backup cold pode ser feito de modo automatizado atráves do RMAN (Recovery Manager) ou atráves de scripts shell (Linux/Unix) ou batch (Windows), onde para o formato manual do backup, pode envolver a cópia até mesmo dos arquivos de redo log, no RMAN não é necessário. Interessante ter um backup frio na sua estratégia de backup.

Backup Quente (Hot backup), backup realizado com o banco de dado online, ou seja inconsistente.

O backup HOT é um dos principais tipos de backup realizados nos ambientes de produção, pois não é necessário a parada do banco de dados, quando está em modo ARCHIVELOG, porém, uma estratégia de backup HOT, pode envolver a utilização de níveis de backups incrementais, como:

• Backup incremental nível 0, ou backup base;
• Backup incremental nível 1, 2, 3 e 4.

Ao colocar esses níveis de backup na sua estratégia, irá ganhar performance, redução de volumetria de backup gerado e aumentar o nível de disponibilidade dos dados, dando mais eficiência à recuperação. Acho que é a opção mínima de backup para o ambiente de produção.

Backup por tablespace, backup realizado para uma determinada tablespace, tendo como opção até mesmo a seleção dos datafiles que poderão ser copiados, pode ser feito manualmente e automaticamente, mas em alguns banco de dados existem tablespaces que armazenam as principais tabelas da aplicação, em que pode forçar uma parada crítica da aplicação, então, vem a pergunta valendo 1 milhão, Se eu peder uma tablespace com tabelas de alta criticidade à aplicação, tenho que voltar o meu banco de dados por completo?

A resposta é simples, se traçou um bom planejamento e tem recursos de hardware disponível, poderá aplicar uma técnica apenas de recuperação da tablespace e seus respectivos datafiles, chamada TSPITR (Tablespace Point-in-Time Recovery), que pode ser realizado manualmente ou automatizado com RMAN, onde não é necessário voltar seu backup por completo, porém, é necessário uma máquina auxiliar nessa atividade ou espaço em disco suficiente na própria máquina que ocorreu o problema, com isso, podemos recuperar partes do banco de dados de forma completa e deixar a aplicação operante.

Backup por control file, é o bakcup de um dos principais arquivos do banco de dados, onde armazena todas as informações do banco de dados com checkpoint, valor de scn, origem dos datafiles, tablespaces, nome do banco de dados, backupsets e etc. Esse backup pode ser feito manualmente ou automático pelo RMAN ou até mesmo por um trace diretamente do SQL*PLUS, usando o comando ALTER DATABASE BACKUP CONTROLFILE TO TRACE.

Export do banco de dados, é uma espécie de backup lógico, ou seja, poderá realizar um backup completo ou por usuário do banco de dados, porém, muitos se enganam quando deixam apenas um EXPORT, ou apenas DMP (Dump) como é conhecido no mercado, pois o EXPORT não garante a segurança total dos dados e com isso poderá ter perda de dados, e geralmente para uma empresa isso não é muito bom. Basta analisar um simples exemplo prático.

Imagine que tenho um banco de dados que é atualizado todos os dias, com INSERT/DELETE/UPDATES diários, um bom e velho OLTP (Online Transaction Processs), e na minha estratégia de backup tenha apenas um Export (ou DMP, como preferir) realizado sempre ás 07:00Hs da manhã.

Em uma bela sexta-feira ás 17:45Hs da tarde, o servidor que hospeda esse banco de dados teve problemas nos discos internos, perdeu-se archived logs do dia e um maravilhoso “crash” na base. Sua recuperação ficou impossível, o que você tem na mão para salvar o mundo? Apenas um DMPzinho das 07:00Hs da manhã, e o que aconteceu com todas as movimentações das 07:00Hs até as 17:45Hs? Vão sumir? Você não tem archived logs e a base está totalmente inconsistente para recuperação, resultado final, muito café e cigarros para falar esse cenário com o seu gerente.

Isso é apenas um cenário que ocorre em muitas empresas, onde as Leis de Murphy podem ocorrer, e quando ocorre sua reputação pode estar em jogo. E pior, existem muitos ambientes que estão com esse cenário atualmente.

Arquivos de carga, é considerado backup, principalmente para ambiente de Data WareHouse onde existe uma alta volumetria de dados e os bancos de dados não trabalham em ARCHIVELOG, pois, como você poderia recuperar os dados que foi apagado acidentalmente nos dias 20 e 21 de uma tabela de FATO ou de alguma dimensão importante do seu DW? Com Mágica? Export poderia resolver o problema também, mas trazer um export FULL de um DW não seria muito legal (esperar cansa!), e nesse caso, como estamos falando de apenas 2 dias, porquê não os arquivos de carga desses dias! Usando o mesmo processo de ETL poderia refazer a carga e completar a tabela novamente com seus respectivos dados, em bem menos tempo.

Cópia fria de um banco de dados, é uma opção muito interessante para implementar na estratégia de backup da empresa onde tem bancos de dados praticamente aberto ao público, ou seja, até o porteiro sabe a senha do owner da aplicação e o estagiário treina seus primeiros comandos DML diretamente na base de produção, porque somente a produção tem uma volumetria para ele testar o tempo e a eficiência do seu DELETE.

E quando estamos falando de cópia fria, não precisa ser as práticas do “Old School”, baixa o banco de dados e CTRL+C e CTRL+V em todos os arquivos e copia para outra máquina, é uma solução também dependendo do ambiente, mas porquê não optar por um DUPLICATE DATABASE, usar um Data Guard (Lógico ou Físico), Stand-by database, ou um backup online na produção e restore em outra máquina, com o RMAN, isso é possível até entre diferentes plataformas, de um Linux para windows. Olha que maravilha! Desde jeito você consegue uma imagem da sua produção e consultar essa imagem para reparar os “ensinamentos” do estagiário na produção! Recomendação: Depois ensina o controle ROLLBACK! rs.

Cópia dos objetos do banco de dados, esse é um ponto interessante também, principalmente, quando sua empresa não tem definição de ambientes, como desenvolvimento, homologação e produção. Poucos DBAs se atentam nisso, mas quando é necessário voltar uma procedure que foi alterada em produção e essa alteração não ajudou em nada ou pior, só complicou as coisas! Qual a sua estratégia para voltar isso, montar um owner em alguma base de teste ou na sua própria máquina e realizar um IMPORT do owner da aplicação sem registros e posteriormente pegar o DDL da procedure? Pegar os DDL do desenvolvimento ou homologação? Ou mandar o desenvolvedor se virar? Quais as alternativas!

Para resolver esse simples probleminha, basta começar a realizar um backup lógico dos objetos do banco de dados, pode usar as próprias views do dicionário de dados do Oracle, como dba_source, dba_triggers, dba_views, dba_mviews e etc, usar o pacote DBMS_METADATA, gerar um DDL script com o Export ou até mesmo para os adeptos de programas gráficos como PL/SQL Developer, SQL Developer e TOAD gerar um “scriptão” a partir deles!

Nessa simples solução, que pode economizar tempo, menos estresse e agilizar o objeto correto ao banco de dados, vai gastar apenas tempo para preparar os scripts e posteriormente, realizar os agendamentos necessários e mandar para FITA, eles podem gerados em arquivos com os nomes e tipos dos objetos, um scripts completo do owner da aplicação com a data do backup e etc. Fica a gosto do cliente!

Percebeu que existem diversos tipos, formas, tamanhos, técnicas, soluções e práticas de backup, uma boa estratégia de backup varia muito conforme o ambiente e os recursos que a empresa oferece, e também as estratégias que o DBA irá implementar na empresa. O banco de dados Oracle oferece para você um leque de opções, basta saber aplicar essas opções. É igual ao antigo slogan do um ótimo produto da NESTLE.

“Existe 1001 maneiras de preparar sua Estratégia de backup, invente a sua!”

E Ficamos por aqui, dúvidas, críticas e sugestões, só entrar em contato.

Abraços,

Olá,

Uma das tarefas mais legais do DBA, é a criação de uma banco de dados manualmente, ou seja, sem a utilização da ferramenta gráfica DBCA (Database Configuration Assistant) da Oracle para realizar essa tarefa, pois deste modo, o DBA consegue acompanhar todos os processos básicos do início ao fim da criação do banco de dados sem a necessidade de executar apenas um batch ou shell e acaba não sabendo o que aconteceu.

Porém, antes de iniciar os passos, temos alguns pré-requisitos que devemos salientar, que são:

• Possuir um hardware com os requisitos minímos exigidos pela versão do banco de dados.
• Verificar se o seu linux é homologado pela Oracle para efetuar a instalação do Oracle Server.
• Ter os binários do Oracle Server instalado no servidor, ou seja, ter uma versão do Oracle Database 10g instalada corretamente no ambiente Linux, com todos os pacotes necessários.
• Conhecer a metodologia OFA (Optimal Flexible Architecture) para criação do banco de dados.

Esses passos são necessários para quem deseja criar um banco de dados manualmente, pois irá realizar uma instalação igual ao do DBCA, que na versão 10g já utiliza a metodologia OFA por padrão. Abaixo segue alguns links para realizar a instalação apenas do software do Oracle Database, para quem não possui ele instalado.

Sites de referência

iMasters - Instalação do Oracle Database 11g em Linux

Puschitz - Installing Oracle 10gR1, R2 on RHEL 4

OTN - Installing Oracle Database 10g Release 2 on Linux x86

Para dar mais enfâse, vamos criar um “resumão” de um pequeno projeto de banco de dados, para conseguimos imaginar como ficará a nossa estrutura disponível e o banco de dados em sí.

Projeto de Banco de dados

Nome: RANET (DBNAME e SID)

Plataforma: Linux Red Hat EL As 4

Volumetria Inicial: 2GB

Tablespaces Permanentes: SYSTEM (500MB), SYSUAX (250MB) e UNDO (500MB).

Tablespaces Aplicação para Dados: RADAT (500MB)

Tablespaces Aplicação para Índices: RAIDX (250MB)

Tablespaces Temporárias: TEMP

Modo de Gerenciamento das tablespaces: LMT (Local Management Tablespace)

Valor em memória (SGA): 1GB

Quantidade de usuários atendidos: 10

Portas do Listener: 1521 e 1522

E agora vamos ao que interessa!

1° Passo | Criando a estrutura física do banco de dados

A estrutura física consiste em diretórios que serão utilizados pelo banco de dados no nível de sistema operacional,que podem ou não obdecer o padrão OFA e sua principal função é organizar e armazenar os arquivos do banco de dados no sistema operacional.

Para a criação do banco de dados, devemos conhecer duas variáveis de ambiente importantes criadas nas instalações Unix/Linux, que são as variáveis ORACLE_BASE e ORACLE_HOME.

A variável ORACLE_BASE é o caminho da instalação do software do Oracle Database, não confunda com as pastas do banco de dados, como ORADATA e ADMIN, um ORACLE_BASE pode ser o mesmo para uma instalação do Database como do Application Server.

A variável ORACLE_HOME é responsável em dizer o caminho que os produtos do banco de dados estão executando, como os binários, configuração de rede (SQL*NET), bibliotecas, grupos de programas e etc.

No exemplo utilizado, nosso caminho para ORACLE_BASE e ORACLE_HOME são essas:

ORACLE_BASE = /u01/app/oracle

ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1

Após validar as variáveis da sua instalação ou verificar quais os caminhos de cada variável, vamos criar os diretórios de dados e administrativos para o banco de dados, pois quando estamos realizando um projeto de banco de dados, devemos analisar as opções que temos de armazenamento, organização e volumes lógicos disponíveis para sua criação, baseando-se a partir do ORACLE_BASE e File System disponíveis.

Nosso objetivo agora é criar os diretórios administrativos do banco de dados, que seguirá essa estrutura física abaixo:

$ORACLE_BASE/admin/<nome_do_banco>/<diretorios>

Conforme o exemplo abaixo:

[oracle@pelspos7h oracle]$ cd $ORACLE_BASE

[oracle@pelspos7h product]$ mkdir admin

[oracle@pelspos7h product]$ cd admin

[oracle@pelspos7h admin]$ mkdir ranet

[oracle@pelspos7h admin]$ cd ranet

[oracle@pelspos7h ranet]$ mkdir adhoc adump bdump cdump flash_recovery_area udump exp

[oracle@pelspos7h ranet]$ cd ..

[oracle@pelspos7h admin]$ cd ..

[oracle@pelspos7h product]$ ls -R |grep ranet

ranet

./admin/ranet:

./admin/ranet/adhoc:

./admin/ranet/adump:

./admin/ranet/bdump:

./admin/ranet/cdump:

./admin/ranet/flash_recovery_area:

./admin/ranet/udump:

./admin/ranet/exp:

Acima está a nossa estrutura física administrativa montada, onde cada um tem sua finalidade como:

./admin

Resposável por organizar os arquivos administrativos de cada instância Oracle.

./admin/ranet:

Pasta que recebe o nome do meu futuro banco de dados.

./admin/ranet/adhoc:

Pasta destinado a armazenar scripts SQL, PL/SQL ou shells.

./admin/ranet/adump:

Audit Dump, onde é gerado os arquivos e auditória do banco de dados, com extensão AUD.

./admin/ranet/bdump:

Background Dump, caminho que é utilizado pelo processos de plano de fundo do Oracle e do alert.log da instância.

./admin/ranet/cdump:

Core Dump, onde é gerado traces do Core do Oracle, geralmente ligados á problemas do sistema operacional.

./admin/ranet/flash_recovery_area:

Flashback Recovery Area (FRA), é um caminho opcional no momento da criação do banco de dados, pois nesse caminho, é gerado backupsets, backup pieces, archive logs, online logs e flashback logs. É opcional pois dependendo do tamanho e quantidade de archived logs gerados pelo banco de dados, é necessário ter um disco dedicado ao FRA.

./admin/ranet/udump:

User Dump, é o diretório que armazena os traces gerados por usuários ou por processos específicos do banco de dados.

./admin/ranet/exp:

Export, diretório destinado aos arquivos gerados atráves do Data Pump Export (Expdp) ou Export Utility (exp).

Depois de realizar a criação dos diretórios administrativos, devemos criar a estrutura que irá armazenar os arquivos do banco de dados propriamente dito, como datafiles, redo logs e control files. E nesse momento, devemos verificar no servidor, qual a melhor opção para o armazenamento desses arquivos, veja:

[oracle@pelspos7h oracle]$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda1             127G   64G   57G  53% /

none                  2.0G     0  2.0G   0% /dev/shm

/dev/sdb1             404G  279G  105G  73% /u02

No exemplo, a melhor opção para o meu banco de dados é o FileSystem /u02, que tem bastante espaço em disco sobrando, o FileSystem /u01 (que não está montado) ficou para os arquivos de traces, archives, dumps e os binários do Oracle.

Após decidido a localização dos arquivos, devemos criar as pastas para armazenar-las.

[oracle@pelspos7h u02]$ mkdir oracle
[oracle@pelspos7h u02]$ cd oracle
[oracle@pelspos7h oracle]$ mkdir oradata
[oracle@pelspos7h oracle]$ cd oradata
[oracle@pelspos7h oradata]$ mkdir ranet
[oracle@pelspos7h oradata]$ cd ranet
[oracle@pelspos7h ranet]$ pwd

/u02/oracle/oradata/ranet

Onde,

/u02/oracle/oradata/ranet
  |     |      |      |-> Diretório para armazenamento dos arquivos do respectivo banco de dados.
  |     |      |--------> Diretório para armazenamento de dados, segundo o padrão OFA.
  |     |---------------> Diretório que específica do software.
  |---------------------> File System com capacidade suficiente para criar o banco de dados.

PRONTO! Já estamos com a nossa estrutura física criado para suporta o novo banco de dados.

2° Passo | Criação do Arquivo de parâmetros

O arquivo de parâmetro, conhecido como PFILE, é um arquivo texto responsável pelas características e comportamento da instância Oracle, esses parâmetros são para trabalhar diretamente em memória da máquina e pelo banco de dados físicamente. É um arquivo essencial para iniciar uma instância Oracle.

Abaixo vou colocar um arquivo de parâmetro básico para iniciar a instância.

control_files              = (/u02/oracle/oradata/ranet/control01.ctl)

db_name                    = ranet

db_domain                  = world

log_archive_dest         = "LOCATION=LOCATION=USE_DB_RECOVERY_FILE_DEST"

db_block_size              = 8192

pga_aggregate_target       = 250M

processes                  = 100

sessions                   = 120

open_cursors               = 80

undo_management            = AUTO

undo_tablespace            = UNDOTBS

compatible                 = 10.1.0.0.0

sga_target                 = 1G

nls_language               = AMERICAN

nls_territory              = AMERICA

db_recovery_file_dest      = /u01/app/oracle/admin/ranet/flash_recovery_area

db_recovery_file_dest_size = 10G

background_dump_dest       = /u01/app/oracle/admin/ranet/bdump

core_dump_dest             = /u01/app/oracle/admin/ranet/cdump

user_dump_dest             = /u01/app/oracle/admin/ranet/udump

audit_file_dest            = /u01/app/oracle/admin/ranet/adump

Veja que alguns parâmetros receberam os valores da nossa estrutura física, seguindo o padrão OFA. Deste modo, podemos salvar o nosso pfile em sua respestiva pasta (/u01/app/oracle/admin/ranet/pfile) como initranet.ora, pois estamos seguindo um padrão da Oracle, que é init<nome_do_banco>.ora para gerar o arquivo.

Posteriormente, vamos criar um SPFILE, sigla para Server Parameter File, que é um melhorando do PFILE, pois já é um arquivo binário, que permite alterar o valores para os parâmetros dinâmicos da instância Oracle.

3° Passo | Preparando script de criação do banco de dados

Uma das tarefas que devemos realizar no momento, é a preparação do script que irá criar nosso banco de dados, esse script será necessário para criar nosso banco de dados fisicamente. Lembre-se que na arquitetura Oracle, quando trabalhamos com recursos em memória, chamamos de Instância Oracle e quando vamos gravar, apagar, modificar, consultar e manipular os dados, estamos trabalhando diretamente no banco de dados físico, onde fica nossos datafiles, control files e redo logs. O Script para criação está abaixo:

CREATE DATABASE "ranet"

MAXINSTANCES 1

MAXLOGHISTORY 1

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 200

DATAFILE '/u02/oracle/oradata/ranet/system01.dbf' SIZE 500M AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED

EXTENT MANAGEMENT LOCAL

SYSAUX

DATAFILE '/u02/oracle/oradata/ranet/sysaux01.dbf' SIZE 500M AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED

SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP

TEMPFILE '/u02/oracle/oradata/ranet/temp01.dbf' SIZE 2000M AUTOEXTEND OFF

SMALLFILE UNDO TABLESPACE "UNDOTBS"

DATAFILE '/u02/oracle/oradata/ranet/undotbs01.dbf' SIZE 2000M AUTOEXTEND OFF

CHARACTER SET WE8ISO8859P1

NATIONAL CHARACTER SET AL16UTF16

LOGFILE

GROUP 1 ('/u01/oracle/oradata/ranet/redo01a.log', '/u02/oracle/oradata/ranet/redo01b.log') SIZE 50M,

GROUP 2 ('/u01/oracle/oradata/ranet/redo02a.log', '/u02/oracle/oradata/ranet/redo02b.log') SIZE 50M,

GROUP 3 ('/u01/oracle/oradata/ranet/redo03a.log', '/u02/oracle/oradata/ranet/redo03b.log') SIZE 50M

USER SYS IDENTIFIED BY DBARODRIGO

USER SYSTEM IDENTIFIED BY SUECO_REPITA;

O scripts acima possui diversos parâmetros e instruções de criação das tablespaces do banco de dados, diga-se de passagem, as principais do banco de dados, e vamos discutir um pouco sobre cada ponto.

Primeiro, vamos comentar sobre os parâmetros utilizados na cláusula de CREATE DATABASE, veja:

MAXINSTANCES

Específica o número máximo de instâncias simultâneas para o banco de dados quando está em MOUNT ou OPEN. Válido para bancos de dados com RAC (Real Application Cluster).

MAXLOGHISTORY

Específica o número máximo de archived redo logs files para automatic media recovery. Válido para bancos de dados com RAC (Real Application Cluster).

MAXLOGFILES

Específica o número máximo de grupos de redo logs que o banco de dados pode possuir.

MAXLOGMEMBERS

Específica o número máximo de membros (ou cópias do aruqivo de redo) que cada grupo pode ter.

MAXDATAFILES

O número máximo de arquivos de dados (datafiles) do banco de dados.

Segundo, agora vamos para as instruções que cria as principais tablespaces do banco de dados.

DATAFILE ‘/u02/oracle/oradata/ranet/system01.dbf’ SIZE 500M AUTOEXTEND ON NEXT 10240K

Responsável em criar a tablespace SYSTEM, sem ele, sem banco de dados!

No início estamos criando a tablespace SYSTEM com apenas 500MB e com a opção de auto-expansível a cada 1MB.

SYSAUX
DATAFILE ‘/u02/oracle/oradata/ranet/sysaux01.dbf’ SIZE 500M AUTOEXTEND ON NEXT  10240K

Essa tablespace é nova e foi introduzida no Oracle 10g, a tablespace SYSAUX é para “prestar suporte” a tablespace SYSTEM, com owners de produtos da própria Oracle. Como Oracle Spatial, RMAN, Workflow e etc.

A tablespace também será criado com 500MB inicialmente.

SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP
TEMPFILE ‘/u02/oracle/oradata/ranet/temp01.dbf’ SIZE 2000M AUTOEXTEND OFF

A tablespace temporária, muito utilizada no banco de dados para operações de SORT, AGREGAÇÃO, CRIAÇÃO DE ÍNDICE e etc.

Vamos iniciar ela com 2GB, pois desde a criação do banco de dados será muito utilizada, a única diferença que estamos limitando o seu crescimento em 2GB, caso seja necessário mais, aumentamos conforme a necessidade.

SMALLFILE UNDO TABLESPACE “UNDOTBS”
DATAFILE ‘/u02/oracle/oradata/ranet/undotbs01.dbf’ SIZE 2000M AUTOEXTEND OFF

Essa instrução é responsável pela criação da tablespace de UNDO, que será chamada de “UNDOTBS”, que é o mesmo valor do parâmetro undo_tablespace que colocamos em nosso PFILE. A tablespace de UNDO que tem como finalidade armazenar nossos dados não comprometidos, desfazer as transações sem sucesso e controlar as modificações dos dados no banco de dados, falando resumidamente.

CHARACTER SET WE8ISO8859P1

Específica o conjunto de caracteres que será armazenado no banco de dados. Se errar nesse momento o conjunto de caracteres, para alterar, somente reconstruindo o banco de dados.

NATIONAL CHARACTER SET AL16UTF16

Específica o conjunto nacional de caracteres, para armazenar os dados em colunas que são do tipo NCHAR, NVARCHAR2 e NCLOB.

LOGFILE
GROUP 1 (’/u01/oracle/oradata/ranet/redo01a.log’, ‘/u02/oracle/oradata/ranet/redo01b.log’) SIZE 50M,
GROUP 2 (’/u01/oracle/oradata/ranet/redo02a.log’, ‘/u02/oracle/oradata/ranet/redo02b.log’) SIZE 50M,
GROUP 3 (’/u01/oracle/oradata/ranet/redo03a.log’, ‘/u02/oracle/oradata/ranet/redo03b.log’) SIZE 50M

Essas instruções específica os membros e a quantidade dos grupos de redo log. Eles podem ser alterados posteriormente quando o banco de dados estiver criado. E perceba que em cada grupo (1,2,3) possui dois arquivos de redo log, isso se chama multiplexação, caso um disco (/u01 ou /u02) dê problemas, terá uma replica do arquivo em outro disco, que poderá facilitar a sua recuperação e não perder os dados.

USER SYS IDENTIFIED BY DBARODRIGO

A instrução acima é para mencionar a senha do usuário SYS.

USER SYSTEM IDENTIFIED BY SUECO_REPITA

A instrução acima é para mencionar a senha do usuário SYSTEM.

Bom, já conseguimos criar o PFILE e o script do banco de dados, agora vamos colocar a mão na massa. Vamos realizar os processos que criação.

4° Passo | Processo de criação

Após o PFILE e SCRIPT prontos, vamos realizar as atividades de criação do banco de dados.

4.1 - Definindo Variáveis de ambiente.

Vamos logar na máqunia que será criado o banco de dados, e vamos configurar a variável de ambiente ORACLE_SID e conferir os valores de ORACLE_BASE e ORACLE_HOME.

ORACLE_SID

A variável ORACLE_SID é responsável em dizer ao Oracle Server qual é o nome do banco de dados que será utilizada, e como estamos criando a base, devemos mencionar o seu nome, que é o mesmo que o parâmetro DB_NAME. Exemplo:

[oracle@pelspos7h adhoc]$ export ORACLE_SID=ranet

[oracle@pelspos7h adhoc]$ echo $ORACLE_SID

ranet

Depois, vamos checar os valores de ORACLE_BASE e ORACLE_HOME.

[oracle@pelspos7h adhoc]$ echo $ORACLE_BASE

/u01/app/oracle

[oracle@pelspos7h adhoc]$ echo $ORACLE_HOME

/u01/app/oracle/product/10.2.0/db_1

4.2 - Abrindo o SQL*PLUS

Vamos iniciar o SQL*PLUS e se conectar a instância.

[oracle@pelspos7h adhoc]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on Fri Feb 13 11:16:54 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

SQL> conn / as sysdba

Connected to an idle instance.

A mensagem “Connected to an idle instance” é normal, porquê você não iniciou a instância.

4.3 - Iniciando a instância Oracle.

Vamos pegar o caminho completo do nosso PFILE e vamos iniciar a instância, com o comando STARTUP NOMOUNT, que significa que vamos apenas carregar seus valores em memória, pois ainda não temos o control file da base criado.

SQL> startup nomount pfile=/u01/app/oracle/admin/ranet/pfile/initranet.ora;

ORACLE instance started.

Total System Global Area  524288000 bytes

Fixed Size                  1268412 bytes

Variable Size             146801988 bytes

Database Buffers          369098752 bytes

Redo Buffers                7118848 bytes

Instância iniciada em modo NOMOUNT. Podemos prosseguir.

4.4 - Criando o banco de dados.

Vamos executar o script de criação do banco de dados.

SQL> @/u01/app/oracle/admin/ranet/adhoc/create_db.sql

Database created.

Nesse momento criamos o banco de dados, os arquivos com extensão .DBF, .CTL e .LOG devem estar disponíveis no sistema operacional. Como no exemplo:

[oracle@pelspos7h ranet]$ ls -ltr

total 3390508

-rw-r-----  1 oracle oinstall   52429312 Feb 13 11:24 redo03b.log

-rw-r-----  1 oracle oinstall   52429312 Feb 13 11:24 redo03a.log

-rw-r-----  1 oracle oinstall   52429312 Feb 13 11:24 redo02b.log

-rw-r-----  1 oracle oinstall   52429312 Feb 13 11:24 redo02a.log

-rw-r-----  1 oracle oinstall 2097160192 Feb 13 11:25 temp01.dbf

-rw-r-----  1 oracle oinstall  524296192 Feb 13 11:25 sysaux01.dbf

-rw-r-----  1 oracle oinstall 2097160192 Feb 13 13:55 undotbs01.dbf

-rw-r-----  1 oracle oinstall  524296192 Feb 13 13:55 system01.dbf

-rw-r-----  1 oracle oinstall   52429312 Feb 13 14:00 redo01b.log

-rw-r-----  1 oracle oinstall   52429312 Feb 13 14:00 redo01a.log

-rw-r-----  1 oracle oinstall    8011776 Feb 13 14:04 control01.ctl

O comando acima foi para verificar nossos datafiles, redo logs e control files. Criados com sucesso.

4.5 - Criando o dicionário de dados Oracle

A criação do dicionário de dados do Oracle é através de scripts que a própria Oracle fornece quando instalado o software. Esses scripts NÃO PODEM SER MODIFICADOS e toda vez que for criar um banco de dados novo, deve ser executado. Ele é obrigatório.

A localização dos scripts fica em $ORACLE_HOME/rdbms/admin, nessa pasta existe diversos scripts que são usados para criação de pacotes administrativos, de produtos adicionais e etc.

Assim que localizado, devemos executar os seguintes scripts, obrigatórios:

• catalog.sql

Cria as views do dicionário de dados.

• catproc.sql

Executa diversos scripts para criação de views e objetos necessário para o banco de dados.

Veja o exemplo:

SQL> @?/rdbms/admin/catalog.sql

...

SQL> @?/rdbms/admin/catproc.sql

Como os scripts são longos e principalmente o catproc.sql que chama diversos outros scripts do /rdbms/admin essa operação pode demorar um pouco, então pode ir tomar um cafézinho nesse momento.

Dica 1

No linux, para executar os scripts você pode utilizar os seguintes caminhos na execução, $ORACLE_HOME/rdbms/admin ou simplesmente ?/rdbms/admin.

Após o termíno da execução do catproc.sql, vamos verificar nosso novo banco de dados. Vamos efetuar as seguintes instruções SQL:

SQL> select instance_name, host_name, status from v$instance;

INSTANCE_NAME    HOST_NAME                      STATUS
---------------- ------------------------------ ------------
ranet            pelspos7h                      OPEN

1 row selected.

Com isso, temos nosso banco de dados no ar. Para quem já conhece a arquitetura Oracle, quando um banco de dados é criado, estará sempre no modo NOARCHIVELOG, como mostra o exemplo:

SQL> select log_mode from v$database;

LOG_MODE
------------
NOARCHIVELOG

1 row selected.

E caso queira mudar para o modo ARCHIVELOG e trabalhar com as vantagens que o ARCHIVELOG pode lhe oferecer para recuperação do banco de dados, basta fazer os procedimentos abaixo:

4.5.1 - Descendo o banco de dados

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

4.5.2 - Colocando o banco de dados em modo MOUNT

SQL> startup mount pfile=/u01/app/oracle/admin/ranet/pfile/initranet.ora;
ORACLE instance started.

Total System Global Area  524288000 bytes
Fixed Size                  1268412 bytes
Variable Size             146801988 bytes
Database Buffers          369098752 bytes
Redo Buffers                7118848 bytes
Database mounted.

Dica 2

Sempre que trabalhar com o pfile em $ORACLE_BASE/admin/ranet/pfile, quando for realizar qualquer tipo de startup, irá aparecer o erro ORA-01078 e LRM-00109, pois o arquivo de parâmetro não se encontra no diretório padrão do Oracle, que é $ORACLE_HOME/dbs. Se quiser resolver esse tipo de problema, copie o seu arquivo de parâmetro para o diretório $ORACLE_HOME/dbs e PRONTO!

4.5.3 - Alterar o modo de arquivamento do banco de dados

SQL> alter database archivelog;

Database altered.

4.5.4 - Abrindo o banco de dados

SQL> alter database open;

Database altered.

4.5.5 - Verificando o modo de arquivamento

SQL> archive log list;

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     13

Next log sequence to archive   15

Current log sequence           15

4.5.6 - Forçar a geração dos archived logs

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

Agora, verifique a origem dos seus archived logs e veja os no sistema operacional. Foi executado o comando ALTER SYSTEM SWITCH LOGFILE três vezes pois nós tinhamos três grupos de redo logs.
SQL> show parameters db_reco

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /u01/app/oracle/admin/ranet/fl
ashback_area
db_recovery_file_dest_size           big integer 10G
SQL> host;
[oracle@pelspos7h adhoc]$ cd /u01/app/oracle/admin/ranet/flashback_area
[oracle@pelspos7h flashback_area]$ ls -ltr
total 4
drwxr-x—  3 oracle oinstall 4096 Feb 13 14:52 RANET
[oracle@pelspos7h flashback_area]$ ls -R
.:
RANET

./RANET:
archivelog

./RANET/archivelog:
2009_02_13

./RANET/archivelog/2009_02_13:
o1_mf_1_15_4sc99r39_.arc  o1_mf_1_16_4sc99x0o_.arc  o1_mf_1_17_4sc9b2j5_.arc

PRONTO! Agora já temos um banco de dados criado e trabalhando no modo archivelog, agora temos que criar as tablespaces que fazem parte do projeto de banco de dados e realizar alguns ajustes finais, como criação do SPFILE, LISTENER, TNSNAMES e um backup do banco.

5° passo | O projeto de banco de dados

Como o objetivo era aproximar ao máximo do mundo corporativo, criamos um micro-projeto no início para podermos criar um banco de dados com alguns recursos e preparado para aplicação. Todo o processo de criação do banco de dados foi realizado, agora falta somente criar as tablespaces necessárias e ajustes no banco de dados para disponibilizar aos usuários.

5.1 - Criação da tablespace RADAT

A tablespace RADAT será para abrigar todas as tabelas de usuários ou aplicação, e seu tamanho inicial é de 500MB.

SQL> create tablespace RADAT
2  datafile
3     '/u02/oracle/oradata/ranet/radat01.dbf' size 500M
4  online
5  permanent
6  extent management local autoallocate
7  segment space management auto;

Tablespace created.

5.2 - Criação da tablespace RAIDX

A tablespace RAIDX irá armazenar os índices dos usuários ou aplicação, e seu volume inicial é de 200MB.

SQL> create tablespace RAIDX
2  datafile
3     '/u02/oracle/oradata/ranet/raidx01.dbf' size 250M
4  online
5  permanent
6  extent management local autoallocate
7  segment space management auto;

Tablespace created.

Na criação das tablespaces foram utilizadas algumas opções de criação, como por exemplo o extent management e segment space, para tirar as dúvidas de como trabalha cada opção, leia o documento oficial, Oracle Database SQL Reference 10g Release 2.

6° Passo | Criando um SPFILE

Uma dos recursos importantes ao DBA é a utilização do SPFILE, onde permite ao DBA alterar alguns parâmetros dinâmicos sem a necessidade de efetuar um stop/start no banco de dados em horários não apropriados. Para criar o SPFILE é bem simples, veja:

SQL> create spfile from pfile='/u01/app/oracle/admin/ranet/pfile/initranet.ora';

File created.

Para confirmar que iremos utilizar os valores dos parâmetros que montamos o banco de dados, criamos o spfile a partir do nosso arquivo de parâmetros construído no início, por isso a passagem do caminho completo e o nome do pfile.

Porém, mesmo como o SPFILE criado, ainda não é possível utilizar-lo, como mostra o comando abaixo:

SQL> show parameters spfile

NAME                                 TYPE        VALUE

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

spfile                               string

Para começar a utilização do SPFILE, é necessário um stop/start do base, e logo depois verifique se a coluna VALUE já preenchida com o caminho completo e nome do seu SPFILE.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup;

ORACLE instance started.

Total System Global Area  524288000 bytes

Fixed Size                  1268412 bytes

Variable Size             146801988 bytes

Database Buffers          369098752 bytes

Redo Buffers                7118848 bytes

Database mounted.

Database opened.

SQL> show parameters spfile

NAME                                 TYPE        VALUE

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

spfile                               string      /u01/app/oracle/product/10.2.0

                                                 /db_1/dbs/spfileranet.ora

Como dito na Dica 2, o caminho utilizado pelo Oracle foi o caminho padrão, $ORACLE_HOME/dbs.

7° Passo | Criando os serviços de rede

Como já estamos como todo o nosso banco de dados criado, vamos ter que disponibilizar aos usuários e possíveis aplicações, e para isso, precisamos do serviço ouvinte (LISTENER) e depois efetuar as configurações nas máquinas client (TNSNAMES) para acessar o banco de dados. E para isso, devemos configurar os arquivos responsáveis por essa tarefa.

7.1 - Criando o Listener

A atividade a ser realizada agora é a criação do LISTENER, ou o serviço ouvinte, que é um processo separado no banco de dados que tem como responsabilidade receber as conexões dos clientes (usuários ou outras bases de dados) e gerenciar o tráfico e pedidos dessas requisições. O arquivo LISTENER.ORA que pode ser encontrado em $ORACLE_HOME/network/admin é o resposável por esse serviço, abaixo segue um exemplo de criação de um LISTENER usando protocolo TCP e disponibilizando as portas 1521 e 1522 para comunicação.

Arquivo: LISTENER.ORA

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = PELSPOS7H)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = PELSPOS7H)(PORT = 1522))
)
)

Após criar o seu arquivo listener.ora e salvar-lo, deverá iniciar o serviço do listener, usando o aplicativo LSNRCTL (Listener Control), veja:

[oracle@pelspos7h admin]$ lsnrctl

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 27-FEB-2009 23:06:18

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=PELSPOS7H)(PORT=1521)))
TNS-12541: TNS:no listener
 TNS-12560: TNS:protocol adapter error
  TNS-00511: No listener
   Linux Error: 111: Connection refused
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=PELSPOS7H)(PORT=1522)))
TNS-12541: TNS:no listener
 TNS-12560: TNS:protocol adapter error
  TNS-00511: No listener
   Linux Error: 111: Connection refused

Ao verificar o atual status do serviço de LISTENER, verificamos que não está disponível, basta iniciarmos o serviço e pronto! Após a configuração nos clientes, a comunicação será possível com o banco de dados.

LSNRCTL> start LISTENER
Starting /u01/app/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 10.2.0.4.0 - Production
System parameter file is /u01/app/oracle/product/10.2.0/db_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1522)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=PELSPOS7H)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                27-FEB-2009 23:06:38
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/10.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1522)))
The listener supports no services
The command completed successfully

Dica 3

Na versão do Oracle Database 10g, existe uma opção no SQL*NET de trabalhar por serviços ou SERVICE_NAME, onde deverá ser realizado outros procedimentos. Mais detalhes nesse documento Quick Start to Oracle Net Connections.

PRONTO! O serviço no lado do servidor de banco de dados já está configurado e pronto para utilização.

7.2 - Configurando o TNSNAMES.ORA e SQLNET.ORA do cliente.

Os arquivos TNSNAMES.ORA e SQLNET.ORA são os arquivos de configuração no lado do cliente ou em algum banco de dados remoto, cada arquivo com sua respectiva função. O arquivo TNSNAMES.ORA tem como finalidade fornecer as principais informações para um serviço ouvinte, como nome do banco de dados, porta de comunicação, tipo de protocolo utilizado e host de destino. A função do arquivo SQLNET.ORA é dizer o metódo de conexão, habilitar a rota de específicas conexões, tipo de autenticação utilizada e fornecer um rastreamento detalhado sobre a comunicação do cliente e servidor. Ambos os arquivos podem ser encontrados em $ORACLE_HOME/network/admin. Abaixo segue um modelo que iremos utilizar.

Arquivo: SQLNET.ORA

AUTOMATIC_IPC = OFF
names.directory_path = (TNSNAMES)
names.default_domain = world
name.default_zone = world

Arquivo: TNSNAMES.ORA

ranet.WORLD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(Host = 10.72.30.83)(Port = 1522))
)
(CONNECT_DATA =
(SID = ranet)
)
)

Caso você queira acessar o seu banco de dados de uma outra máquina que tenha o Oracle Client instalado, basta adicionar a entrada de TNS acima, mostrada no modelo do TNSNAMES.ORA e caso seja necessário, colocar as configurações de SQLNET acima.

7.3 - Validação da conexão

Ao realizar todas as tarefas acima de configuração dos arquivos do SQLNET, basta validar se a conexão com o banco de dados remotamente será realizado com sucesso, para isso, basta utilizar o aplicativo TNSPING para validar. Exemplo.

[oracle@pelspos7h admin]$ tnsping ranet

TNS Ping Utility for Linux: Version 10.2.0.4.0 - Production on 27-FEB-2009 23:33:58

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
/u01/app/oracle/product/10.2.0/db_1/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(Host = 10.72.30.83)(Port = 1522))) (CONNECT_DATA = (SID=ranet)))
OK (0 msec)

UFA! Agora podemos liberar o nosso mini banco de dados aos usuários e iniciar posteriormente as configurações de usuários e aplicações na base. Esse artigo foi bem longo e cansativo, porém, a principal ideia era fornecer os conceitos básicos na criação de um banco de dados manualmente, como:

• Entender os conceitos do Optial Flexible Architecture (OFA);
• Variáveis de ambiente essênciais ao Oracle;
• Entender os scripts e processos de criação do banco de dados;
• Conhecer os scripts básicos para criar o dicionário de dados do Oracle Server;
• Colocar o banco de dados no modo de arquivamento automático;
• Realizar as tarefas básicas de tablespaces para um determinado projeto;
• Ajustar o banco de dados para acesso remoto.

Todos esses passos são de real importância para um projeto de banco de dados, e nunca se esqueça, depois de realizar todas as tarefas acima, faça um BACKUP FULL do banco de dados para não ter problemas e aumentar a segurança do projeto.

Qualquer dúvida, crítica e sugestão, estou disponível no e-mail ou aqui no blog.

Abraços,

Olá,

Nesse final de semana (14/02/2009 - DST Brazil) estamos terminando o horário de verão, que vale somente para a região Sul, Sudeste e Centro-Oeste. Com o termíno, deveremos atrasar nossos relógios em 1 hora, e isso será um grande problema para os DBAs que tem banco de dados Oracle na produção da empresa, pois apenas atrasar o horário do servidor com o banco de dados no ar (online) pode causar grandes danos.

Problemas

Ao atrasar o horário do servidor em 1 hora, e não realizar os procedimentos corretos para efetuar essa atividade, pode trazer diversos impactos ao banco de dados Oracle. E esses impactos podemos listar abaixo:

• Sobreescrita na geração dos Archived Logs;
• Problemas de comunicação com o LISTENER do Oracle Server;
• Problemas de novos registros incluídos atráves da aplicação ou processos de ETL, pois se esses registros trabalham com funções de data como SYSDATE, TIMESTAMP ou SYSTIMESTAMP, podem ser invalidadas por primarys keys e constraints de check no modelo e banco de dados;
• Para ambientes RAC (Real Application Cluster), mudar o horário pode trazer diversos problemas, desde o CRS (Cluster Registry Services), LISTENER e InterConnect, pois podem ocorrer sobreescritas na gravação dos logs e sincronização dos nós;
• Para ambientes DataGuard ou Stand-by, podem ocorrer problemas também com sobreescritas dos redo logs, onde pode causar problemas e até mesmo erros do kernel do Oracle Server gerando os ORA-600;
• Problemas nas mensagens gravadas no alert.log;
• Problemas no agendamento de JOBS no banco de dados, que seja feito por DBMS_JOB ou DBMS_SCHEDULER;
• Se ocorre a sobreescrita dos archived logs, terá problemas com o Point-in-Time-Recovery do seu banco de dados, e com isso, uma simples troca do horário pode ser uma catástrofe em seu backup e recover;
• Pode ocorrer problemas com o JVM do Oracle;

Todos os impactos citados acima, estão resumidos e que podem ser afetados de imediato, existem outros impactos que podem aparecer depois de 2 ou 3 dias e até mesmo semanas. E para não correr esse risco, existe um procedimento bem básico para os DBAs.

Procedimento

Antes de realizar a troca do horário do servidor e futuramente do banco de dados, siga os procedimentos abaixo:

1. Realizar um backup full do banco de dados.
2. Parar os serviços do Listener, exemplo: lsnrctl stop ou lsnrctl <nome_listener> stop;
3. Parar o banco de dados, com shutdown immediate, normal ou transactional.;
4. Para ambiente Windows: Depois que descer o banco de dados pelo SQL*PLUS, descer o serviço do windows, exemplo: net stop OracleService<nome_da_base>;
5. Anotar o horário de STOP GERAL, para saber com exatidão o momento da parada de todos os serviços;
6. Alterar o horário do servidor (Windows\Linux\Unix);
7. Após a troca do horário no servidor, esperar 1 hora para subir os bancos. Exemplo, se meu STOP GERAL foi as 00:05AM (antes da troca), anoto esse valor e espero 1 hora, realizo a troca do horário e quando for 01:05AM, meu horário será atrasado para 00:05AM novamente (ajuste para o fim do horário de verão), e a partir desse horário posso subir todos os serviços novamente a partir do horário que desceu, deste modo não regresso no tempo.
8. Subir todos os serviços novamento, pode ser pela ordem BANCO DE DADOS -> LISTENER -> APLICAÇÃO.

E pronto! Já estamos com nossos horários ajustados para o horário de Brasilia (Oficial Brasileiro).

Recomendação

Nunca deixem os servidores de banco de dados com o ajuste de horário de verão automático, pois a cada ano, as datas são de início e fim podem sofrer alterações e seja necessário patchs para os novos ajustes e fora que isso, pode trazer todos os problemas citados acima no banco de dados, então faça sempre manualmente.

Blog cadastrado no Rec6

Abraços,

Olá,

Os organizadores da ENPO já disponibilizaram as palestras em vídeo que fizeram parte dessa última edição. Abaixo estou postando a minha palestra.

http://video.google.com/videoplay?docid=8521428875400605543

Para mais informações

ENPO - www.enpo-br.org

GPO - www.profissionaloracle.com.br

No site terá mais palestrars disponível para download e suas respectivas apresentações.

Abraços,

Olá!

A GPO já colocou a disposição em seu website a apresentação sobre a ferramenta RMAN que foi utilizada para a palestra na V ENPO para consulta dos profissionais. Acho legal realizarem o download do power point, pois a apresentação traz mais detalhes sobre a ferramenta e técnicas de backup e recover.

Para fazer o download, basta clicar aqui. E caso tenha dúvidas ou sugestões, fique a vontade para entrar em contato.

Abraços,

 

Olá,

Uma dos maiores problemas de realizar uma recuperação completa ou uma restauração de um banco de dados para um novo servidor, é o problema de mencionar o DBID (Database Identifier - Identificação do banco de dados) para o catálogo do RMAN.

Pois, para conseguir uma restauração da base, é necessário mencionar o DBID ao catálogo de recuperação para conseguir associar o banco de dados no catálogo e posteriormente restaurar e recuperar seus backups sets.

Agora, vamos mencionar quais os meios que podemos encontrar o DBID de um banco de dados.

1. Dicionário de dados

Podemos realizar um simples select na view v$database para conseguir a informação, veja.

SQL> select dbid from v$database;

      DBID
----------
4263396950

1 linha selecionada.

2. RMAN - Inicío de sessão

O DBID também é informado quando você conecta ao RMAN, lembrando, que o DBID será informado se o banco de dados estiver em MOUNT ou OPEN, se apenas com NOMOUNT, não será informado, pois não irá ler o arquivo de controle, ou control file. Exemplo.

[oracle@PELSPOWMS2 ~]$ rman

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Oct 23 17:15:23 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

RMAN> connect target ‘rman/##########@wmssp.world’;

connected to target database: WMSSP (DBID=4263396950)

RMAN>

3. RMAN - Usando o comando List incarnation

Outro modo de se conseguir o DBID do banco de dados, é após logar-se no banco de dados target e estar conectado ao catálogo de recuperação, utilizar o comando LIST INCARNATION, exemplo:

RMAN> list incarnation;
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
8451    8458    WMSSP    4263396950       PARENT  1          30/06/2005 19:09:40
8451    8452    WMSSP    4263396950       CURRENT 446075     27/02/2008 09:03:20

RMAN>

Uma dica muito importante é sempre manter uma planilha com todos os bancos de dados, senhas e seus respectivos DBID armazenados após as criação do banco de dados para não correr risco de não saber o DBID do banco de dados criado.

Abraços,

Olá,

Nesse post vamos realizar um simples backup e recover do controlfile do banco de dados utilizando o RMAN, sem a necessidade de um catálogo de recuperação.

Nos exemplos, vou utilizar a versão XE (Oracle Express Edition) que é gratuita e disponível para download no site da Oracle Technology Network e também fornacerá um pequeno treinamento na utilização do RMAN. Pois bem, vamos checar alguns pontos para iniciar nossos testes, como demostrado abaixo:

C:\>start OracleServiceXE
O sistema não pode encontrar o arquivo OracleServiceXE.

C:\>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:28:33 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:28:36
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              DBARODRIGO          OPEN

USER IS "SYS"

SQL> select * from v$controlfile;
STATUS     NAME                                                         IS_ BLOCK_SIZE FILE_SIZE_BLKS
---------- ------------------------------------------------------------ --- ---------- --------------
           C:\ORACLE\ORADATA\XE\CONTROL.DBF                             NO       16384            430

Atenção

Existe uma etapa que emito o comando @id, ele é apenas um script que utilizo para ver as horas, instância, servidor e o status da instância. Ele está disponível na área de script aqui do Blog, depois comento como configurar o SQLPATH para executar scripts sem a necessidade do caminho absoluto. Não confunda com um comando interno do banco de dados ou do SQL*PLUS.

Nessas etapas, estamos apenas checando informações básicas do banco e onde está seu controlfile, por padrão no XE, o controlfile veem com extensão DBF, o que pode ser um pouco diferente para quem geralmente trabalha com os controlfiles em extensão CTL (mas, não muda nada!).

Agora, vamos executar um backup atual do nosso controlfile com o RMAN, para termos um backup atualizado em casos de futuros problemas. O processo a seguir irá desativar o banco de dados pelo SQL*PLUS e posteriormente, logar-se pelo RMAN e iniciar o banco de dados no estado montado, ou seja, vou apenas abrir o controlfile do banco de dados e coletar as suas informações, porém, nesse estado, fica inutilizável para os usuários.

SQL> shutdown immediate;
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

C:\>rman target /

Gerenciador de Recuperação: Release 10.2.0.1.0 - Production on Sex Ago 22 13:30:48 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

conectado ao banco de dados de destino (não iniciado)

RMAN> startup mount;

instância Oracle iniciada
banco de dados montado

Total da área Global do Sistema     146800640 bytes

Fixed Size                     1286220 bytes
Variable Size                 62918580 bytes
Database Buffers              79691776 bytes
Redo Buffers                   2904064 bytes

RMAN> list backup of controlfile;

usar o arquivo de controle do banco de dados de destino em vez do catálogo de recuperação

Lista de Conjuntos de Backup
===================

RMAN>

Observe, executei o comando shutdown immediate para desativar o banco de dados, e logo em seguida, me conectei no RMAN usando uma autenticação pelo sistema operacional, por isso o (target /), e sem a necessidade de um catálogo de recuperação, pois o RMAN quando não usa um catálogo de recuperação pega as informações do controlfile, sobre SCN, datafiles, logs e etc.

Para uma simples conferência, acima executei o comando LIST BACKUP OF CONTROLFILE apenas para saber se já exisitia ou não um backup do controlfile. E Finalmente o mais interessante, como realizar o backup do controlfile:

RMAN> run {
2> allocate channel t1 type disk format 'c:\oracle\backup\rman\BKP_CF_%d_%t_%s.rman';
3> backup current controlfile tag 'BKP_CF';
4> release channel t1;
5> }

canal alocado: t1
canal t1: sid=35 devtype=DISK

Iniciando backup em 22/08/08
canal t1: iniciando conjunto de backup completo de arquivo de dados
canal t1: especificando arquivo(s) de dados no conjunto de backups
incluindo arquivo de controle atual no conjunto de backups
canal t1: iniciando o componente 1 em 22/08/08
canal t1: componente 1 finalizado em 22/08/08
handle de componente=C:\ORACLE\BACKUP\RMAN\BKP_CF_XE_663427972_18.RMAN tag=BKP_CF comentário=NONE
canal t1: conjunto de backups concluído, tempo decorrido: 00:00:05
Finalizado backup em 22/08/08

canal liberado: t1

RMAN> exit

No script acima, coloquei apenas um canal de I/O para realizar o backup e mandar para o destino do backup, que no exemplo, foi “c:\oracle\backup\rman\”, sempre utilizo variáveis de ambiente do RMAN para gerar o meu arquivo de backupset, no caso, %d (nome do banco de dados), %t (timestamp) e %s (sequência de backupsets gerados) junto com a extensão .RMAN, para saber que foi gerado pelo Recovery Manager.

Após realizar a tarefa, vamos ver o arquivo gerado e posteriormente os passos para simular a restauração do controlfile, todos os passos estão abaixo:

C:\>cd c:\oracle\backup\rman

C:\oracle\backup\rman>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\backup\rman

22/08/2008  13:32    <DIR>          .
22/08/2008  13:32    <DIR>          ..
19/08/2008  21:58               187 afiedt.buf
22/08/2008  13:32         7.110.656 BKP_CF_XE_663427972_18.RMAN
              2 arquivo(s)  7.110.853 bytes
               2 pasta(s)  5.920.763.904 bytes disponíveis

Agora, vou para a pasta que está os arquivos de dados do Oracle XE, para deletar o controlfile.

C:\oracle\backup\rman>cd ..

C:\oracle\backup>cd ..

C:\oracle>cd oradata

C:\oracle\oradata>cd xe

C:\oracle\oradata\XE>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\oradata\XE

19/08/2008  22:21    <DIR>          .
19/08/2008  22:21    <DIR>          ..
22/08/2008  13:33         7.061.504 CONTROL.DBF
22/08/2008  13:30       450.895.872 SYSAUX.DBF
22/08/2008  13:30       356.524.032 SYSTEM.DBF
19/08/2008  22:21        20.979.712 TEMP.DBF
22/08/2008  13:30        94.380.032 UNDO.DBF
22/08/2008  13:30       104.865.792 USERS.DBF
               6 arquivo(s)  1.034.706.944 bytes
               2 pasta(s)  5.920.763.904 bytes disponíveis

Vou logar no banco de dados novamente, para deletar o arquivo, pois, em ambiente windows, não é possível deletar os arquivos quando estão em uso. Então segue novamente os passos. Lembrando que meu banco de dados sempre esteve no modo MOUNT.

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:34:51 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> shutdown immediate;
ORA-01109: banco de dados não aberto
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

C:\oracle\oradata\XE>del /F /Q CONTROL.DBF

C:\oracle\oradata\XE>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\oradata\XE

22/08/2008  13:35    <DIR>          .
22/08/2008  13:35    <DIR>          ..
22/08/2008  13:30       450.895.872 SYSAUX.DBF
22/08/2008  13:30       356.524.032 SYSTEM.DBF
19/08/2008  22:21        20.979.712 TEMP.DBF
22/08/2008  13:30        94.380.032 UNDO.DBF
22/08/2008  13:30       104.865.792 USERS.DBF
               5 arquivo(s)  1.027.645.440 bytes
               2 pasta(s)  5.927.821.312 bytes disponíveis

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:35:25 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup;
Instância ORACLE iniciada.

Total System Global Area  146800640 bytes
Fixed Size                  1286220 bytes
Variable Size              62918580 bytes
Database Buffers           79691776 bytes
Redo Buffers                2904064 bytes
ORA-00205: erro na identificação do arquivo de controle, verifique o log de alertas para obter mais informações
SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:35:36
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              PELSPOMARIO          STARTED

USER IS "SYS"
SQL> shutdown immediate;
ORA-01507: banco de dados n?o montado
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Depois de todo o processo, e ao deletar o CONTROL.DBF, tentei iniciar o banco de dados e apareceu a seguinte mensagem de erro, ORA-00205, onde não foi possível encontrar um controlfile para montar o banco de dados e posteriormente abrir aos usuários.

Isso é comum quando se perde um controlfile, em ambiente corporativos o controlfile sempre estará multiplexado, ou seja, sempre terá uma cópia fiel dos controlfile na abertura do banco, porém, dependentdo do crash, o Oracle pode dizer que um controlfile está mais atualizado que o outro, e isso é um assunto para outro post. rs.

Mas, vamos em frente, o que temos que fazer agora é apenas restaurar o controlfile que fizemos backup no início do post, aquele que foi gerado no caminho “c:\oracle\backup\rman”, e o processo de restauração também é bem fácil, observe a recuperação abaixo:

C:\oracle\oradata\XE>rman target /

Gerenciador de Recuperação: Release 10.2.0.1.0 - Production on Sex Ago 22 13:36:05 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

conectado ao banco de dados de destino (não iniciado)

RMAN> startup nomount;

instância Oracle iniciada

Total da área Global do Sistema     146800640 bytes

Fixed Size                     1286220 bytes
Variable Size                 62918580 bytes
Database Buffers              79691776 bytes
Redo Buffers                   2904064 bytes

RMAN> restore controlfile from 'c:\oracle\backup\rman\BKP_CF_XE_663427972_18.RMAN';

Iniciando restore em 22/08/08
usar o arquivo de controle do banco de dados de destino em vez do catálogo de recuperação
canal alocado: ORA_DISK_1
canal ORA_DISK_1: sid=36 devtype=DISK

canal ORA_DISK_1: restaurando arquivo de controle
canal ORA_DISK_1: restauração concluída, tempo decorrido: 00:00:03
nome do arquivo de saída=C:\ORACLE\ORADATA\XE\CONTROL.DBF
Finalizado restore em 22/08/08

RMAN> alter database mount;

banco de dados montado
canal liberado: ORA_DISK_1

RMAN> alter database open resetlogs;

banco de dados aberto.

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:38:15 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:39:41
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              PELSPOMARIO          OPEN

 

 PRONTO! Olhe no início do LOG que ao se conectar ao RMAN, peço para realizar a restauração do controlfile pelo arquivo gerado pelo backup, ou seja, do arquivo ‘c:\oracle\backup\rman\BKP_CF_XE_663427972_18.RMAN’, e assim sendo após a restauração com sucesso é só mandar abrir o banco de dados com a opção RESETLOGS (será gerado uma nova incarnação) e permitir o acesso novamente dos usuários.

A ideia do post, vou comentar de maneira bem rápida e de fácil entendimento, como podemos realizar um backup e restore do controlfile de um banco de dados. Espero que tenham gostado.

Abraços,