Blog do Rodrigo Almeida

Olá,

Gostaria de compartilhar com vocês dois vídeos bem interessantes sobre o Sun Oracle Database Machine (Exadata II) e o Oracle Database 11g Release 2.

Os vídeos estão abaixo:

Sun Oracle Database Machine - Exadata II

Apresentação do Oracle Database 11g Release 2

O legal de ver essas duas apresentações, é que o hardware, Exadata II só roda o Oracle Database 11g Release 2, e o banco de dados Oracle 11g Release 2 tem customizações específicas de performance somente para o Exadata.

Até mesmo o ASM 11g foi modificado para o Exadata, normalmente o ASM trabalha com um Stripe Size de 1 MB para todas as plataformas, no Exadata com a combinação do HP InfiniBand, o ASM pode trabalhar com o Stripe Size de 4 MB. É realmente EXTREME PERFORMANCE!

Os vídeos estão em inglês, porém, dá quem não conhece muito a língua inglesa, dá para entender alguma coisa. Vale a pena conhecer.

Abraços,

 

 

Olá,

A carreira do profissional de banco de dados (DBA) é cercada de especializações, pelo motivo de trabalhar com diversas áreas do TI, como desenvolvimento, projetos, infra-estrutura e etc. O DBA, conforme os anos vão se passando, é natural ter preferências ou “ser forçado” a trabalhar com áreas específicas, criando assim um perfil do administrador de banco de dados, onde podemos ter os tipos de DBAs abaixo:

DBA Desenvolvedor

É o profissional que desde administrar o banco de dados também desenvolve a aplicação, tem no perfil as seguintes características:

• Profundos conhecimentos na linguagem de programação local;
• Conhecimentos em instalação e administração do banco de dados;
• Sempre preocupado com a qualidade e manutenção das querys;
• Procura sempre o mais performático, mesmo que a atividade não seja uma boa prática;
• Fortes conhecimentos em modelagem de dados, sabe aplicar a 3FN (brincadeira);
• Trabalha sobre prazos e acostumado a “martelar” o banco de dados ou aplicação para que seja entregue na data prevista.

Geralmente, o DBA desenvolvedor é lider de desenvolvimento ou atua como um guru na equipe, mandando orientações aos novos integrantes, organizando as atividades e analisando todos os requisitos de desenvolvimento.

DBA Infra-Estrutura

É o profissional que conhece toda a infra-estrutura necessária para a implementação do banco de dados, atua desde a concepção do hardware até a analise da infra-estrutura local do banco de dados, tem as seguintes características:

• Profundos conhecimentos da arquitetura e administração Oracle;
• Profundos conhecimentos em infra-estrutura, desde a configuração do hardware, cabeamento, switch, sistema operacional e backup & recover;
• Especialidade em performance ao nível de sistema operacional e instância Oracle;
• Extremamente cuidadoso no momento de aplicação de patches no banco de dados e sistema operacional;
• Trabalha mais voltado a projetos e implementação de novos recursos de banco de dados ou aplicação;
• Responsável em adotar as boas práticas para administração do banco de dados, mesmo que isso crie conflitos internamente na equipe.

O DBA Infra-Estrutura geralmente não dá tanta importância para as aplicações da empresa, costuma se preocupar apenas com o banco de dados e afeta diretamente a vida o SYSADMIN, pois, tudo que o SYSADMIN fizer que tenha banco de dados no meio, ele irá questionar.

DBA Projetos

É o perfil do profissional que já foi um DBA Desenvolvedor e Infra-Estrutura, sabe como funciona cada área é aplica as boas práticas na construção da aplicação e na infra-estrutura para o banco de dados, suas principais características são:

• Bons conhecimentos em desenvolvimento de aplicações;
• Bons conhecimentos sobre o produto e arquitetura Oracle;
• Gerencia os prazos das atividades, aquisição de produtos extras, manutenção na aplicação, patches de banco de dados e requisitos básicos da infra-estrutura;
• Costuma usar o Microsoft Project para se organizar e documenta todas as suas atividades;
• Acostumado a opinar/sugerir/questionar o comportamento
• Acostumado a delegar as atividades básicas de administração do banco de dados e cuidar apenas dos projetos que envolvem o banco de dados e a burocracia da empresa.

O DBA Projetos é conhecido com o “cara” do projeto da empresa, pois ele que em diversas reuniões com dezenas de áreas costuma a questionar e interrogar os participantes para coletar as informações no momento de criar o projeto do banco de dados.

Com sua experiência, ele consegue detectar muitos problemas e possui pró-atividade em suas atividades.

Agora, para descontrair um pouco, vamos falar sobre as outras vertentes da carreira de um DBA, aquelas vertentes que é comentada pela “rádio Peão” da empresa, como:

DBA Cafeteira

É o profissional que passa o tempo tomando café e fumando que trabalhando efetivamente, porém, resolve os problemas da empresa rapidamente.

DBA Google

Esse é o profissional criado dentro do SIBEL ou qualquer outra ferramenta de gerenciamento de mudanças,  conhecido pelas filas de CHAMADOS! Passa a maior parte de sua vida atendendo chamados para produção ou desenvolvimento, tendo que aprender todos os tipos de coisas possíveis que existe no mundo Oracle, por isso que falam que um DBA Google sem internet não trabalha!

Mas é muito bom para quem quer aprender banco de dados, aprende e tem noção de tudo!

DBA Bombeiro

Essa vertente é a pós-graduação do DBA Google, pois em algum momento da vida o DBA Google fica revoltado com a vida que tem e quer mudar de empresa, e a empresa que ele será empregado é um consultoria com N clientes e ele deverá atender todos.

Deste modo, acaba surgindo o DBA Bombeiro, pois ele vai para os clientes apenas para apagar incêndios a todo momento, não consegue prosseguir em uma especialização. E para ajudar, é o perfil de DBA que costuma a receber um celular ou Page para ficar 24×7 para a empresa.

Também muito conhecido pelas suas olheiras que vem com o tempo!

DBA Ghost

Esse é o perfil de um profissional que escutou de alguém que DBA ganha bem, que sendo DBA ele irá prosperar em sua vida financeira e terá tudo que o mundo pode vender para ele, assim sendo, alguem muito conhecido consegue arrumar uma vaga na área de banco de dados e quando ele realmente consegue entrar, possui as caractéristicas abaixo:

• Não sabe administrar o banco de dados;
• Quando se tem problemas, ele desaparece;
• Não atende o celular após as 18 horas nunca;
• Mata dezenas de parentes no ano para justificar suas faltas;
• Não gosta de estudar, ler livros, buscar conhecimentos e muito mesmo debater assuntos referentes a Oracle;
• E o melhor, não se esforça para aprender o que foi solicitado.

Acho que é isso pessoal, deu para entender um pouco como funciona a carreira de um profissional de banco de dados Oracle, muitos área de especializações ou até mesmo uma generalização de tudo, com muita moderação, não diga que sabe trabalhar com RAC, sendo que nunca viu como funciona RAC em sua frente.

Certificação é importante e recomendo a todos, porém o Certificado Oracle, seja ele um OCA ou OCP, não vai dar garantias que seja o melhor profissional de todos os tempos, pois, certificação não é garantia de qualidade no serviço.

Abraços,

Olá,

Recentemente estive sobre os olhares da auditoria Sarbanes-Oxley (SOX) para os bancos de dados Oracle da empresa que trabalho e gostaria de compartilhar alguns check-lists necessários para os DBAs passarem sem muitos problemas dessa auditoria.

Sobre a Lei Sarbanes-Oxley (SOX)

A auditoria SOX, foi criada em 2.002 por um senador Paul Sarbanes e um deputado Michael Oxley no EUA tendo como objetivo controlar e investigar todos os investimentos estrangeiros de empresas que possuem capital aberto no mercado, afim de evitar grandes fraudes e governança inapropriada.

Como muitas empresas que possuem operações financeiras no exterior, a Sox promove a criação de processos de auditoria e segurança em todos os departamentos da empresa, afim de tornar-la uma empresa confiável, transparente e principalmente segura.

Deste modo, a atenção ao departamento de Tecnologia da Informação (TI) é uma parte muito importante durante uma auditoria SOX, pois, os sistemas da empresa devem ser seguros e seguir diversos processos internos elaborados pelas suas gestões para prevenir fraudes.

O banco de dados acaba sendo um alvo certo no processo de auditoria, porque simplesmente, armazena todos os dados vitais de uma empresa, e essa “caixa” de dados precisa ser segura e de acesso controlado, tornando uma dor de cabeça aos DBAs e projetos da empresa, porque muitas restrições são impostas.

Essas restrições impostas poderão ver no check-list abaixo, onde são pontos que os auditores pedem evidências sobre o processo e/ou atividade realizada. Todo o check-list foi realizado para ambientes de bancos de dados Oracle.

Primeiramente, vamos iniciar o nosso check-list partindo da infra-estrutura, ou seja, o que é necessário para o ambiente de banco de dados estar de acordo com o SOX.

Infra-Estrutura

• Backup & Recover em dia;
• Documentação da Estratégia de Backup & Recover para cada banco de dados;
• Evidências de testes de recover vindas de Fita e/ou disco, o verdadeiro LOG da operação;
• Padrão de instalação seguindo o OFA (Optimal Flexible Architecture);
• Para bancos de dados em ambientes Windows:
  • Lista de usuários Locais do servidor;
  • Permissões dos usuários e pastas Oracle;
  • DUMPSEC dos servidores;
  • Relacionamento de confiança entre os servidores;
  • Lista de serviços do windows, para saber qual é necessário ou não;
  • Lista de protocolos utilizados pelo servidor;
  • Permissão dos arquivos listener.ora, sqlnet.ora e Executáveis;
  • Permissão do Oratab;
  • Arquivo de Parâmetro, quais e qual o motivo dos parâmetros;
  • Informação sobre os processos do Windows Scheduler;
  • Informações sobre os processos Batch, não é permitido fixar a senha de usuários em hardcode;
  • Informações sobre as últimas atualizações do Windows, principalmente de Vulnerabilidade.
• Para bancos de dados em ambientes Linux/Unix:
  • Utilizar o umask 022 no profile Oracle;
  • Fornecer os detalhes do profile default dos usuários e csh.login do sistema operacional;
  • Lista de serviços que estão executando, e desativar os desnecessários.
  • Lista dos usuários do DBA Group;
  • Permissão dos arquivos, diretórios e FileSystem do Oracle User;
  • Permissão do OraTab;
  • Permissão de shell scripts, não é permitido fixar a senha de usuários em hardcode;
  • Permissão nos arquivos Listener.ora, sqlnet.ora e Executáveis/Libs;
  • Arquivo de Parâmetro, quais e qual o motivo dos parâmetros;
  • Informações sobre os processos da Crontab e suas permissões.
• Informações de permissão sobre os arquivos de dados, traces e log;

Agora, vamos para um check-list mais refinado, internamente no banco de dados, o que o DBA deverá prestar atenção na auditoria, veja abaixo:

Banco de dados

• Lista de usuários Genéricos, ou seja, Lista dos owners da aplicação;
• Lista de usuários Convencionais, os usuários finais;
• Lista de Profiles e seus parâmetros;
• A função VERIFY_PASS_FUNCTION deve ser programada para de acordo com a política de senha da empresa;
• Permissões de visualização no dicionário de dados Oracle, principalmente as views dba_source e dba_objects;
• Lista de permissão dos Usuários por objeto, role e grants de sistema;
• Lista de permissão dos usuáriso com WITH OPTION para concessão de permissão;
• Documentação do processo de Backup sobre os componentes lógicos, como tabelas, procedures, packages, functions e triggers;
• Documentação do processo de agendamento de Jobs ou a utiização do DBMS_SCHEDULER, Quem usa, Como usa e quem utiliza;
• O DBA não pode utilizar as contas SYS e SYSTEM, deve possuir uma conta própria e nomeada para cada profissional;
• Senha no Listener;
• Não utilizar autenticação via SO para logar-se como SYS AS SYSDBA;
• Utilizar arquivo de senha no banco de dados;
• Utilizar o parâmetro DBLINK_ENCRYPT_LOGIN = TRUE no banco de dados quando se trabalha com versões anteriores ao 9.2.0.1;

• Recomendação de habilitar o AUDIT_TRAIL = DB ou SO, mas é apenas recomendação, depende de analise de ambiente;
• Habilitar o parâmetro AUDIT_SYS_OPERATIONS = TRUE para auditoria no usuário SYS;

• Ocultar as autenticações no banco de dados pelo sistema operacional, usando o parâmetro OS_AUTHENT_PREFIX = “;
• Ter habilitado o parâmetro REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE para administração remota.

Dependendo da empresa que irá auditar, alguns itens podem ser incluídos e outros nem solicitados, porém, nunca se sabe o que eles vão pedir, por isso, fica a recomendação e as devidas atenções de segurança.

Outro detalhe importante sobre uma auditoria SOX, que os auditores pedem todos os documentos de processo e/ou atividade do banco de dados, portanto, mais e mais documentos são necessário para os nossos ambientes, como:

• Documentação de Instalação do banco de dados;
• Documentação do controle de incidentes de banco de dados;
• Documentação do controle de alteração do banco de dados feitas atráves de aplicação, ou seja, quando é necessário incluir, deletar ou modificar algum objeto da base;
• Documentação dos serviços que estão sendo monitorados no banco de dados;
• Documentação de procedimentos de manutenção no banco de dados e etc;

Para a equipe de DBAs pode ser um imenso problema isso, porque documentar todo esses processos leva muito tempo e dificilmente um específico profissional sabe tudo sobre um determinado ambiente. Por um lado, a documentação é extremamente importante para equipes com muitos DBAs, ou empresa que possuem alta rotatividade desses profissionais, pois o ambiente fica muito mais controlado, seguro e fácil de se administrar. Eu sou totalmente favorável a qualquer tipo de documentação, tanto banco e aplicação.

Uma recomendação importante quando for passar por auditoria SOX, são elas:

• O DBA deve ter um backup, ou seja, outro profissional que faça as mesmas tarefas quando ele ficar doente ou sair da empresa;
• Tenha ambientes separados para a aplicação, exemplo: Ambiente de DESENVOLVIMENTO, HOMOLOGAÇÂO e PRODUÇÂO;
• Tenha uma gestão de incidentes ou projeto que controle todas as transações sobre os ambientes mencionados acima;
• Todo o código PL/SQL que passe a terceiros ou outras filiais deve usar o aplicativo WRAP para criptografia dos dados e posteriormente comparar os checksum;
• Tenha ótimas estratégias de Backup & Recover;
• E um acesso restrito para querys em ambiente de produção.

BOM! Acho que é isso pessoal, esses são alguns (”grandes”) check-lists para supotar uma auditoria da SOX, ou até melhor, para conhecer também um pouco mais sobre como proteger o seu banco de dados, não precisa passar por uma auditoria para poder implementar alguns sugestões que estão acima ou até mesmo, documentar os seus processos. São check-lists que é válido como um todo!

Abraços,

Olá,

Recentemente muitas empresas estão utilizando a solução de Nota Fiscal Eletrônica (NFE) da Mastersaf, um aplicativo desenvolvido em Java Server pages (JSP) sobre o webserver GlassFish da Sun/Oracle.

Na teoria um aplicativo web de pequeno porte para validação e envio de Notas Fiscais ao Sefaz, contudo, se o aplicativo tiver problemas de performance ou parar por erro humano ou hardware, trará grandes problemas ao negócios da empresa.

Nos manuais de instalação do aplicativo, não há muitas informações de como configurar ou administrar um banco de dados Oracle de acordo com as necessidades do aplicativo. Por essa razão, vou passar algumas dicas de como melhorar a performance do aplicativo quando está se trabalhando com Oracle.

1° Dica) Use o parâmetro DB_KEEP_CACHE_SIZE

Esse parâmetro é utilizado para mantér todos os blocos de dados de uma determinada tabela em memória, desde modo, evita-se realizar Physical Reads, leitura direta em disco, e começa a trabalhar mais com Logical reads, leitura em memória. O ganho de performance é bem considerado.

Para o NFE, o ideal é colocar todas as tabelas que inicia com NFE_, ARC_, CTRL_ e NFS_ em keep, pois são tabelas utilizadas com muita frequência pelo aplicativo. Abaixo segue um modo de como configurar.

1 - Habilitando o db_keep_cache_size

SQL> alter system set db_keep_cache_size = 120M scope=both;

Sistema alterado.

2 -  Colocando a tabela em keep

SQL> alter table NFE.<nome_da_tabela> storage (buffer_pool keep);

Tabela alterada.

Recomendação

O DBA deverá realizar os cálculos corretos para divisão do SGA (Database Buffers) para o parâmetro db_keep_cache_size, ou seja, recomendo utilizar em tabelas pequenas, que tenha no máximo 20MB, é interessante alocar seu contéudo completo em memória, porém, existe outro parâmetro db_recycle_cache_size que pode ser utilizado para tabelas maiores ou deixar no buffer_pool padrão, ou seja, alocar os blocos de dados no espaço destinado do db_cache_size.

2° Dica) Bulk Collect na Integração de dados

Para empresas que possuem soluções próprias de ERP ou sistemas de gerenciamento independentes, que trabalham na plataforma Oracle (Forms/Reports/Apex/PLSQL), é recomendado utilizar cursos em Bulk Collect para criar a integração com o sistema NFE da Mastersaf.

O Bulk Collect é o tipo de cursor que traz um excelente ganho de performance em relação aos outros (Implicítos/Explicítos) e aumenta a velocidade na troca de informações entre as bases.

Para maiores informações sobre como utilizar o Bulk Collect, meu amigo Leonardo Litz escreveu um artigo realizando a comparação entre os diferentes tipos de cursores, que pode ser visto no link abaixo.

Utilizando cursores no Oracle

http://imasters.uol.com.br/artigo/12960/oracle/utilizando_cursores_no_oracle/

3° Dica ) Bloco de dados em 8k

Já cheguei a ver algumas empresas que estão trabalhando com 16k para os blocos de dados do banco, em questões de performance, isso pode lhe trazer alguns Latchs desnecessários. Em testes realizados, trabalhar com o banco de dados com os parâmetros db_block_size = 8k e o db_file_multiblock_read_count = 16 mostrou muito mais performático em relação a criar o banco de dados em 16k ou até mesmo criar as tablespaces utilizando a blocagem de 16k. Mantenha-se no 8k.

Recomendação

Quando se deseja utilizar um específico bloco de dados no projeto de banco de dados, o DBA deverá analisar desde o stripe utilizado na criação da RAID, o tipo de formatação utilizado no disco e posteriormente o bloco de dados que irá utilizar, pois todos esses fatores influência em performance.

E é isso pessoal, conforme a experiência com os produtos Mastersaf e as soluções adotadas, vou postando mais informações para melhorar o dia-a-dia e compartilhar o conhecimento com todos. Sugestões e novas soluções também são muito bem-vindas.

Abraços,

Olá,

Esse post é dedicado as “pérolas” que já foram ditas dentro do departamento de TI, pelos próprios profissionais ou usuários. O verdadeiro momento para relaxar e rir um pouco.

Pérola 1

Durante uma reunião de projetos da empresa:

Gerente de TI : - “Como podemos encurtar o tempo do projeto?”

Coordenador de Desenvolvimento: - “Amigos, é possível instalar o banco de dados antes do sistema operacional  para adiantarmos o projeto?”

… Ocorre um momento de silêncio na sala …

Consultoria: “Ééééééé… começamos bem, heimmmm galera!”

=====================================================

Pérola 2

Durante uma troca de e-mails:

Desenvolvedor: - “Preciso do seu VNC?”

Coordenador de Desenvolvimento: - “OK! Estou enviando por email (anexado VNC.EXE)”

=====================================================

Pérola 3

Durante o processo de suporte da uma fábrica de software:

Desenvolvedor: - “Porque as views VT_EMPREGADOS e VT_CARGOS foi criado?”

Analista de Suporte: - “Essas views que apareceram no Banco de Dados foi o próprio Oracle quem as criou sozinhos, e isso invalidou os outros objetos…”

=====================================================

Pérola 4

Conversa entre os desenvolvedores do projeto:

Desenvolvedor: - “Eu sou o Desenvolvedor Baby, fulano é o Junior e Ciclano é o Sênior …”

=====================================================

Pérola 5

Conversa de almoço:

Analista Notes: - “Você viu o novo Fiat, o Fiat PONTO.”

=====================================================

Pérola 6

Quando ocorre problemas de enviar e-mail na empresa:

Analista de Suporte: - “Porque os e-mails não estão chegando?”

Analista Notes: - “O Notes não está enviando e-mail porque o Ar-condicionado não está funcionando e por isso o serviço de roteamento paro!.”

Analista de Suporte: - “Eitttttaaaaaaaaaaa… ”

=====================================================

Pérola 7

Reunião de Projetos da empresa:

Analista de Suporte: - “Vou conversar com o Carlos que cuida da Venezuela”

Analista Notes: - “Não adianta o Carlos só cuida da America do Sul”

Analista de Suporte: - “Desculpa a Venezuela fica na ARABIA agora”

=====================================================

Pérola 8

Pergunta no lado da mesa:

Analista de Suporte: - “Qual comando para executar .exe no Linux ?”

=====================================================

Pérola 9

Acionando o DBA na madrugada:

Suporte: - “Alô, DBA? Estamos com problemas, todas as bases estão fora!”

DBA: - “O Link está fora? Acabo a energia?”

Suporte: - “Pior que não, porque algumas unidades estão no ar!”

DBA: - “Tente fazer um PING para a unidade São Paulo”

Suporte: - “Não consegui …

DBA: - “Tenta agora para Curitiba.”

Suporte: - “Também não.”

DBA: - “Faz um ping para o banco XYZ.”

(Era um banco local onde o suporte estava)

Suporte: - ” Também não consegui, estranho esse problema né.”

DBA: - ” Cara, faz o seguinte, vê se sua máquina está com o cabo de rede conectado?”

(revoltado já)

Suporte: - “Putzzzzzz. cara, minha placa de rede estava sem nenhum cabo…”

( tu tu tu tu tu…)

DBA já tinha desligado o telefone e voltou a dormir.

=====================================================

Pérola 10

Dúvidas entre a equipe:

Analista de Negócio: - “Puts meu não consigo recriar um perfil.. Tá dando erro!”

Adm. de Infra: - “É só reiniciar a máquina que funciona seu animal, se não der certo eu fico pelado aqui …”

=====================================================

Pérola 11

Conversa entre desenvolvedores:

Desenvolvedor: - “Cara! A gente prescisa mudar o nome daquele JOB do Oracle, o nome com aquele número não é muito sujestivo…..”

O job era de NÚMERO 666.

=====================================================

Pérola 12

Requisição de novos equipamentos para o TI:

Adm. de Infra: - “Compramos um novo notebook pra usarmos.”

Analista de Negócios: - “Veio com teclado e mouse?”

=====================================================

Pérola 13

Conversa de alinhamento das equipes:

Analista da Filial Argentina: - “Hola como Estas?
Analista Notes: - “Muy Bem is Too ?
Analista da Filial Argentina: - “Gracias por su ayuda”
Analista Notes: - “Graxias bye bye ”

=====================================================

Pérola 14

Conversa na fila de café na empresa entre coordenadores:

Coordenador 1: - “Tu fez ITIL no Instituto COBIT?”

Coordenador 2: - “Hãmm! Fumo o quê?”

=====================================================

Pérola 15

Solicitação de execução de script para correção da aplicação:

Coordenador de Desenvolvimento: - “Fulano, Por favor, abaixe todos os bancos de dados da aplicativo X, pois preciso executar os scripts no horário de almoço”

DBA: - “Se eu baixar, tu vai executar por OSMOSE e promete não me ligar!”

=====================================================

Pérola 16

Quando o Administrador de rede não está presente e mandam um estagiário fazer o serviço:

Estagiário: Entra na sala dos servidores para auxiliar o analista de suporte  na manutenção do no-break.

Analista de Suporte: - “Por favor, poderia apertar o botão X do no-break para saber o status!”.

Estagiário: “É esse **BUTÃO** aqui!”.

… nesse momento todos os servidores da empresa são desligados …

Momentos depois…

Todos os funcionários do TI olhavam para a porta da sala dos servidores, quando o estagiário sai e diz:

Estagiário: - “Algum problema aí?”

DBA: - “Acho que a noite vai ser longa…”

=====================================================

Pérola 17

Manutenção de servidores durante o final de semana:

Coordenador de Infra-Estrutura: - “Porque o banco X está fora desde sábado?”.

DBA: - “Verifiquei aqui e o servidor está fora desde Sábado, vou ver o que aconteceu!”.

DBA: - “Suporte! Sabe me dizer o motivo da máquina X estar fora desde sábado?”

Suporte: - “Fomos mudar o servidor de Rack, porém, nós não queriamos prejudicar os usuários, e preferimos mudar o servidor de lugar com a máquina ligado mesmo, para não atrapalhar e ligar para você!”

Final da história…

Cabos de rede desconectados, discos SATAs corrompidos e não existia backup dos últimos 2 dias.

=====================================================

Pérola 18

Dúvidas sobre um hardware de criptografia:

Coordenador de Desenvolvimento: - “Que caixinha preta é essa?”

Analista de Suporte: - “È o hardware para criptografia da informação para as entidades externas!”.

Coordenador de Desenvolvimento: - “Nossssaaaa! Que Legal, eu não sabia que ele também usava cabo COAXIAL! Muito banaca!”

Lembrete …

Como todo hardware, ele só tinha entrada de fonte de energia e 2 entradas RJ-45 (rede).

=====================================================

Pérola 19

Durante uma reunião de projeto lendário:

Coordenador de Desenvolvimento: - “O meu sonho é colocar o JD. Edwards e um banco de dados ATG!”

=====================================================

Agredecimentos aos amigos que me mandaram e-mails com as pérolas ouvidas ou vivenciadas.

BOM! Esse post será atualizado constantemente, e quem quiser colaborar, só me mandar um e-mail ou deixar comentários.

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á,

Muitos profissionais, principalmente iniciantes tem ou já tiveram bastantes problemas de conexão com o banco de dados Oracle, os conhecidos erros de TNS, sigla para Transparent Network Substrate. Esses erros ocorrem durante uma tentativa de conexão com o banco de dados ou até mesmo quando se está utilizando Database Link (DBLINK) para uma outra base de dados.

A origem desses erros podem ser diversos e sempre estarão ligados com o SQL*NET ou a sua infra-estrutura de rede LAN/WAN. Para quem não conhece o SQL*NET ou Net8 (Antes do Oracle8i), é um produto de middleware da Oracle que oferece suporte para as conexões (Transparent Connection) entre cliente/servidor, entre bancos de dados Oracle  ou ambientes não-Oracle (Transparent Gateways).

Porém, nossa meta não é conhecer as soluções e arquitetura de rede do Oracle Server, e sim, solucionar os principais problemas de TNS. Mas, antes devemos conhecer três arquivos que compõe uma arquitetura de rede Oracle e importantes para iniciar a nossa jornada, são eles:

Listener.ora

Arquivo de configuração de ouvinte no lado do servidor. Ele fornece as principais configurações como:

• Nome único do banco de dados (Unique Name)
• Protocolo de Comunicação e porta de acesso
• Serviços do Listener e Home Oracle associado a versão da base.

A origem desse arquivo é sempre em $ORACLE_HOME/network/admin em Unix\Linux e %ORACLE_HOME%\network\admin para Windows, onde ORACLE_HOME é a origem da sua instalação do Oracle Server. Abaixo segue um modelo simples do Listener.ora.

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS_LIST =

        (ADDRESS = (PROTOCOL = TCP)(HOST = 10.72.0.171)(PORT = 1521))

      )

     )

  )

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (SID_NAME = PLSExtProc)

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

      (PROGRAM = extproc)

    )

    (SID_DESC =

      (GLOBAL_DBNAME = ranet.world)

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

      (SID_NAME = ranet)

    )

  )

LEMBRETE!

Esse arquivo é geralmente encontrado no servidor que está instalado o banco de dados e não na máquina cliente. E resumidamente, é ele que fornece o suporte de conexão ao banco de dados.

Tnsnames.ora

Arquivo de configuração para acesso aos bancos de dados Oracle, configurado tanto no lado cliente ou servidor. Ele fornece as informações de destino dos banco de dados, como:

• Nome do banco de dados (SID);
• Tipo de Protocolo, Nome do servidor e Porta de conexão.

Abaixo segue um exemplo do contéudo de um arquivo Client:

ranet.world =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = 10.72.0.171)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SID = ranet)

 )

  )

Podemos encontrar o arquivo no diretório  $ORACLE_HOME\network\admin em Unix\Linux e %ORACLE_HOME%/network/admin em Windows da máquina cliente ou servidor, onde a instalação do Oracle Home pode ser de um simples Client Oracle ou Oracle Server.

LEMBRETE!

O arquivo tnsnames.ora deve ser configurado no lado cliente e servidor de banco de dados e aplicação, no lado cliente para permitir o usuário acessar o banco de dados, nos servidores de banco de dados para validar a utilização de DBLINKs e nos servidores de aplicação para permitir a conectividade.

Sqlnet.ora

Arquivo de configuração que habilita alguns recursos de rede para o cliente ou banco de dados, como:

• Tipo de nomeação de metódos;
• Habilita logs e traces;
• Recursos avançados de segurança e entre outros.

Assim como os outros arquivos, pode ser encontrado em $ORACLE_HOME\network\admin em Unix\Linux e %ORACLE_HOME%/network/admin em Windows da máquina cliente ou servidor.

Bom, depois de algumas suaves explicações dos arquivos de configuração, vamos discutir um check list antes de entrar nos problemas de TNS, esse check list tem como funcionalidade encontrar os possíveis problemas antes de realizar qualquer alteração nos arquivos do SQL*NET mencionados acima, o check list consiste nas seguintes tarefas:

1) PING

Antes de qualquer coisa, faça um ping para o IP do servidor e veja se ele está respondendo na rede, como o exemplo abaixo:

C:\>ping 10.72.0.171

Disparando contra 10.72.0.171 com 32 bytes de dados:

Resposta de 10.72.0.171: bytes=32 tempo=81ms TTL=60

Resposta de 10.72.0.171: bytes=32 tempo=70ms TTL=60

Resposta de 10.72.0.171: bytes=32 tempo=137ms TTL=60

Resposta de 10.72.0.171: bytes=32 tempo=96ms TTL=60

Estatísticas do Ping para 10.72.0.171:

    Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda),

Aproximar um número redondo de vezes em milissegundos:

    Mínimo = 70ms, Máximo = 137ms, Média = 96ms

Ter a resposta do servidor já é um bom começo, caso não tenha, existe alguns possíveis problemas:

1. O servidor está com outro endereço IP;
2. O cabe de rede não está conectado ao servidor;
3. O servidor pode estar bloqueado no Firewall;
4. Verificar as regras de firewall do seu usuário para o servidor específico;
5. Para ambientes distribuídos, verifique se o link entre as unidades está ativo;
6. Verificar se a(s) placa(s) de rede do servidor estão habilitadas;
7. Verificar se o servidor está no domínio desejado ou em uma DMZ, se sim, verificar se possui acesso.

Todos os problemas mencionados acima, se trata diretamente da infra-estrutura e configuração do servidor em questão, portanto, não tem que realizar nenhum tipo de configuração ou manutenção no seu ambiente Oracle.

2) TNSPING

O SQL*NET fornece um aplicativo chamado TNSPING, que pode ser executado diretamente no servidor ou da máquina cliente, ele é utilizado para determinar se o Listener do banco de dados alvo está ativo ou não. Pois, em alguns momentos, podemos ter uma base com o status OPEN (online), porém, o seu serviço de Listener esta parado, deste modo não permite acesso dos usuários. Veja um exemplo:

C:\>tnsping ranet

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 15-JAN-2009 10:42:10

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

Arquivos de parâmetros usados:

D:\oracle\product\10.2.0\db_1\network\admin\sqlnet.ora

Usado o adaptador TNSNAMES para resolver o apelido

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = tcp.world) (PROTOCOL = TCP) (Host = 10.72.0.171) (Port = 1521)) (

ADDRESS = (COMMUNITY = tcp.world) (PROTOCOL = TCP) (Host = 10.72.0.171) (Port = 1521))) (CONNECT_DATA = (SID = ranet)))

OK (80 ms)

Diferente do PING, o TNSPING já faz um teste do serviço de conexão diretamente no banco de dados desejado, no exemplo, utilizei o alías RANET para o banco de dados RANET, que é o alías configurado em meu tnsnames.ora, a mensagem final de OK diz que é possível realizar a conexão com o banco de dados.

Mas para ter do sucesso de conexão para seu banco de dados, tudo vai depender do status que a sua instância se encontra, pois se o banco de dados estiver em NOMOUNT (não mountado) ou MOUNT (montado), o teste de conexão com o TNSPING irá funcionar, porém, o acesso não será possível, assim sendo, quado acessar à aplicação ou SQL*PLUS, terá um erro como o abaixo:

C:\>sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on Qui Jan 15 13:43:16 2009
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

SQL> conn system@ranet
Informe a senha:

ERROR:
ORA-01033: ORACLE initialization or shutdown in progress

Isso é porque o seu banco de dados se encontra em status NOMOUNT ou MOUNT, ou também como a mensagem diz, em processo de SHUTDOWN em modo  immediate, normal ou transacional.

Utilizando ainda o TNSPING, é possível medir o tempo de resposta do serviço de Listener, colocando um valor N para o teste, conforme o exemplo:

C:\>tnsping ranet 5

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 15-JAN-2009 10:49:21

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

Arquivos de parâmetros usados:

D:\oracle\product\10.2.0\db_1\network\admin\sqlnet.ora

Usado o adaptador TNSNAMES para resolver o apelido

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = tcp.world) (PROTOCOL = TCP) (Host = 10.72.0.171) (Port = 1521)) (

ADDRESS = (COMMUNITY = tcp.world) (PROTOCOL = TCP) (Host = 10.72.0.171) (Port = 1521))) (CONNECT_DATA = (SID = ranet)))

OK (50 ms)

OK (60 ms)

OK (60 ms)

OK (80 ms)

OK (80 ms)

Acima, foi realizado 5 tentativas, ou como alguns preferem, 5 saltos. Com essa opção do TNSPING é fornecida para cada salto o tempo de resposta da máquina origem para o banco de dados destino, e com isso também podemos entrar problemas de performance, caso o tempo de resposta esteja alto de um valor tolerado, que é de 0 a 200 ms (milisegundos), pode começar a verificar alguns problemas de rede.

Atráves do TNSPING, começamos a receber alguns erros de TNS, que podemos discutir abaixo:

TNS-03505

Esse erro acontece geralmente quando se tenta realizar um teste de conexão (TNSPING) para um banco de dados que não está registrado no tnsnames.ora da máquina cliente ou servidor, exemplo:

C:\>tnsping ranet99

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 15-JAN-2009 10:57:52

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

Arquivos de parâmetros usados:

D:\oracle\product\10.2.0\db_1\network\admin\sqlnet.ora

TNS-03505: Falha ao determinar o nome

Solução

Existem algumas possíveis soluções simples para esse erro específico de TNS, que são:

• Colocar o nome correto do banco de dados;
• Verifique se o alías que está tentando conecta está cadastrado no seu arquivo tnsnames.ora;
• Verifique se o alías necessita utilizar o .WORLD ao final do nome, o .WORLD significa que é de um domínio global, e sua configuração pode ser feita alterando o nome do alías no tnsnames.ora para RANET.WORLD;
• Talvez seja necessário colocar o parâmetro NAME.DEFAULT_ZONE = WORLD no arquivo sqlnet.ora;
• Verifique o tipo de nomeação utilizado pelo parâmetro NAMES.DIRECTORY_PATH.

TNS-12541

Esse erro é retornado quando o serviço do Listener não está online, ou está com outro tipo de configuração, exemplo:

C:\>tnsping ranet

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 15-JAN-2009 11:09:24

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

Arquivos de parâmetros usados:
D:\oracle\product\10.2.0\db_1\network\admin\sqlnet.ora

Usado o adaptador TNSNAMES para resolver o apelido
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = 10.72.0.171) (Port = 1521))) (CONNECT_DATA = (SID = ranet)))

TNS-12541: TNS:nâo há listener

Solução

Nos casos mais simples, para resolver esse problema basta ativar novamente o serviço do Listener no banco de dados alvo, para isso, utiliza a ferramenta LSNRCTL (Listener Control) fornecido junto com o SQL*NET, atráves de linha de comando para habilitar novamente o serviço, exemplo:

C:\>lsnrctl

LSNRCTL for 32-bit Windows: Version 10.2.0.4.0 - Production on 15-JAN-2009 11:13:41

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

Bem vindo ao LSNRCTL, digite "help" para obter informações.

LSNRCTL> start LISTENER

Starting D:\oracle\product\10.2.0\db_1\bin\tnslsnr: please wait...

TNSLSNR for Windows: Version 10.2.0.4.0 - Production
System parameter file is D:\oracle\product\10.2.0\db_1\network\admin\listener.ora
Log messages written to D:\oracle\product\10.2.0\db_1\network\log\listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.72.0.171)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.72.0.171)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Windows: Version 10.2.0.4.0 - Production
Start Date                15-JAN-2009 11:10:26
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   D:\oracle\product\10.2.0\db_1\network\admin\listener.ora
Listener Log File         D:\oracle\product\10.2.0\db_1\network\admin\listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.72.0.171)(PORT=1521)))
Services Summary...
Service "ranet" has 1 instance(s).
  Instance "ranet", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

Perceba que ao acessar o aplicativo LSNRCTL (Listener Control), emiti o comando start LISTENER, para iniciar o serviço do Listener, por padrão o nome do ouvinte é LISTENER, então eu poderia apenas deixar start que resolveria, porém, se coloquei outro nome ao LISTENER, basta iniciar com start <nome_do_listener>, e para saber se existe outro nome de Listener configurado no seu SQL*NET, basta verificar o seu arquivo listener.ora do servidor de banco de dados.

Existem outros checks que devem ser feitos para evitar esse tipo de erro, são:

• Verificar o hostname e porta do arquivo listener.ora;
• Verificar o nome do Listener atual no LSNRCTL;

ORA-12154

O mesmo que o erro TNS-12154, onde não há um Listener para conexão, porém, ele é emitido dentro do banco de dados Oracle, por isso o motivo do ORA no início, e esse erro é quando se está utilizando um DBLINK para um determinado banco de dados e o ALIAS utilizado no DBLINK não corresponde ao banco de dados. Exemplo:

SQL> select count(*) from NOTAS_FISCAIS@RANET_SP.WORLD;
select count(*) from NOTAS_FISCAIS@RANET_SP.WORLD
                                   *
ERRO na linha 1:

ORA-12154: TNS:could not resolve service name

Solução

A solução para esse tipo de problema é igual ao do TNS-12154, porém necessita de mais detalhes, como:

Verificar qual o alías que o DBLINK está utilizando para realizar a comunicação, fazendo o SELECT abaixo:

SQL> select owner, db_link, username, host from dba_db_links;

OWNER      DB_LINK         USERNAME                       HOST
---------- --------------- ------------------------------ ---------------
PUBLIC     RANET_SP.WORLD   dbara                             RANET_RO

1 linha selecionada

A coluna HOST fornece o nome do alías que será utilizado para realizar a comunicação com outro banco de dados, esse alías é o mesmo encontrado no arquivo tnsnames.ora, então, para resolver o problema, basta no arquivo de tnsnames colocar um alías chamado RANET_RO para o hostname, porta e SID corretos, deste modo o DBLINK volta a funcionar. Existem outras coisas que devemos prestar atenção como mencionado nos erros TNS acima, como:

• Verificar se é necessário utilizar o .WORLD para o domínio global;
• Verificar o NAMES.DIRECTORY_PATH e NAME.DEFAULT_DOMAIN do sqlnet.ora do servidor de banco de dados;
• Executar os testes de PING e TNSPING.

PRONTO! Com essa introdução aos erros de TNS e um pequeno overview dos principais arquivos do SQL*NET, já conseguimos realizar alguns testes simples e que podem nos ajudar e  nosso dia-a-dia de trabalho, lembrando que esse foi somente a primeira parte, terá a segunda parte com mais alguns tipos de erros TNS e suas respectivas soluçõ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á,

Demorei um pouco para postar como foi o Encontro Nacional de Profissionais Oracle que ocorreu no sábado passado (29/11/2008)  na FIAP, pois estava numa correria danada e precisando um pouco de descanso.

Bom, como todas as edições da ENPO, tivemos ótimas palestras, oportunidade de conhecer diversos profissionais oracle, aumentando a rede social e agregar conhecimentos.

Nessa edição, tive o prazer para poder palestrar sobre um tema bem discutido, que é backup e recover com RMAN. Bem, a apresentação tinha bastante slides e o assunto é extenso, tive 1 hora para contar os conceitos básicos da arquitetura da ferramenta rman e suas principais funcionalidades, foi um pouco corrido, mas acho que deu para o público conhecer e entender um pouco sobre essa maravilhosa ferramenta. Em breve a apresentação estará disponível no site da ENPO e GPO.

Tivemos outras palestras bem interessantes também, como do nosso parceiro de blog e comunidade Oracle Ricardo Portilho que discutiu sobre o Load Balance em RAC, que teve uma apresentação bastante divertida (principalmente a imagem do balanceamento de cerveja entre a mulher e o homem), tive o prazer de conhecer pessoalmente, e é um cara super gente fina! Vale a recomendação de conhecer o blog dele também aqui na GPO com contéudo bem legal.

Outras palestras como o Chiappa, que discutiu um pouco sobre a utilização e o modo de utilizar a ferramenta SQL*Plus, o nosso velho e bom amigo de todos os dias, tivemos também Roberto Serson, ou show man Oracle, falando um pouco sobre Expressões Regulares, que se existe um desenvolvedor que gosta da trabalhar com a metodologia POG, ao conhecer as expressões regulares, ninguem mais irá dar manutenção em seus códigos! =D

Para o público, tivemos ainda uma boa visão geral de como trabalha o Oracle Spatial, que teve como palestrante o profissional Marcos Couto, de como o BI trabalha no geral como o Francisco Piedade, que detalhou e mostrou experiência no assunto.

E como todo palestrante, abaixo segue a imagem do meu novo trófeu recebido pelos organizadores da ENPO, que será guardado com muito carinho.

Gostei da participação da galera no geral, e desculpas por não ter dado muita atenção ao pessoal que veio tirar dúvidas durante os coffee breaks ou me esperado para almoçar, pois estava muito corrido o dia e muita gente comigo também, então estava díficil administrar tudo, quem quizer ainda discutir alguma coisa, fique a vontade de mandar e-mails para mim.

E agradeço aos organizadores (Fernanda, Morgado e Willians) pela oportunidade e aos amigos, tanto da iMasters, Affinia, Pellegrino, GPTI, IBTA e aos leitores em geral que compareceram ao evento.

Abraços,