segunda-feira, 22 de junho de 2009

Troubleshooting XE – Parte IV – ARCHIVELOG mode

Como prometi no artigo anterior, nesta quarta parte da série vou falar sobre o ARCHIVELOG mode. Antes, porém, observe atentamente a figura a seguir.

Database Storage Structure
Flash Recovery Area

Na figura abaixo podemos ver a estrutura de armazenamento do Oracle 10g Express Edition. Podemos ver as estruturas lógicas (as Tablespaces); as estruturas físicas (Datafiles, Tempfile, Password file, Control file e Server Parameter file); e a Flash Recovery Area.

Inicialmente, a flash recovery area (FRA) armazena os Online Redo Logs. Mas ela também é destinada ao armazenamento dos backups e dos Archived Redo Logs, na medida em que você faz os backups e ativa o modo de Archive Log.


Online Redo Log Files

A estrutura mais crucial para a recuperação do banco de dados é um grupo de redo log files. Este grupo de arquivos é coletivamente conhecido como redo log. Um redo log é feito de redo entries, que são também chamados de redo records.

A função principal do redo log é registrar todas as alterações de dados em um banco de dados. Se uma instância Oracle falhar ou o sistema operacional por alguma razão impedir que os dados modificados sejam permanentemente escritos nos arquivos de dados, as alterações podem ser recuperadas do redo log, de modo que as atualizações de dados enviadas (commited) não sejam perdidas.

O banco de dados escreve no redo log em um modo circular. Existem arquivos físicos associados ao redo log. Um redo logcurrent) e os outros inativos. Deste modo, os logs de arquivamento são registrados sempre no grupo ativo. Quando o grupo de redo log ativo é preenchido, o banco de dados começa a escrever no próximo grupo de redo log disponível. Quando o último grupo de redo log disponível é preenchido, o banco de dados retorna ao primeiro grupo de redo log e escreve nele (sobrescrevendo as entradas anteriores), reiniciando o ciclo.
está sempre associado a, no mínimo, dois grupos. Destes, sempre um está ativo (ou

Percebe-se que há um limite para o arquivamento das operações realizadas pelo banco de dados pois, quando ele tem que reiniciar o ciclo, os logs anteriores à um certo período (indeterminado) começam a ser sobrescritos.

O ARCHIVELOG mode

O Oracle Database XE pode ser configurado de modo que um processo de arquivamento em background faça cópias dos redo log files inativos para a FRA, antes deles poderem ser reutilizados. Este processo de copiar os Redo log files é chamado de archived redo log files. Desta forma, praticamente não há limite para o arquivamento das operações realizadas sobre o banco de dados.

Um banco de dados configurado para arquivar redo logs é dito estar no ARCHIVELOG mode. (Um banco de dados não configurado para arquivar redo logs é dito estar no NOARCHIVELOG mode).

Antes de prosseguirmos, é preciso saber em que o modo o XE está neste momento: se está ou não no modo ARCHIVELOG. Uma das maneiras para fazer isto é abrir a interface HTML do XE e verificar o painel Usage Monitor.

Na figura acima, podemos ver que o modo de arquivamento não está ativo (Log Archiving: Off).

Ativando o ARCHIVELOG mode

Vamos ver os procedimentos necessários para colocar o XE no ARCHIVELOG mode.

SHUTDOWN IMMEDIATE

Se o comando for bem sucedido, a tela irá exibir:

Database closed.
Database dismounted.
ORACLE instance shut down.

  • Agora digite:
STARTUP MOUNT

ORACLE instance started.
Total System Global Area 599785472 bytes
Fixed Size 1220804 bytes
Variable Size 180358972 bytes
Database Buffers 415236096 bytes
Redo Buffers 2969600 bytes
Database mounted.
(os números podem ser diferentes na tua tela)

  • Agora digite o próximo comando:
ALTER DATABASE ARCHIVELOG;

Database altered.

  • Agora digite o próximo comando, para abrr o banco de dados e deixá-lo operacional:

ALTER DATABASE OPEN;

Database altered.

  • Pronto, o banco de dados agora está rodando no ARCHIVELOG mode!

Agora vem a próxima recomendação: aumente o tamanho da FRA para pelo menos 15GB, para ter espaço extra de armazenamento para os redo log files.

Alterando o tamanho da FRA

Para alterar o tamanho da FRA para 15G Bytes, conecte como SYSDBA e digite o seguinte comando:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 15G;

Movendo a FRA

A FRA, como sabemos, fica dentro da pasta de instalação do XE. Isto não é um inconveniente tão grande assim. Mas se você for uma pessoa que leva segurança ao extremo, pode querer transferí-la para outro lugar, por uma simples razão: ela é usada pelo XE para garantir a segurança e a integridade dos dados, em caso de “crash”. Além disso, todos os backups e archive logs são guardados dentro dela. Aí é que “mora o perigo”, pois se ocorrer uma pane catastrófica no HD, tudo, inclusive os backups e archive logs, será perdido para sempre!

Além disto, a depender do tamanho da partição destinada ao sistema operacional, o XE e seus datafiles, que ocupam mais de 5GB, adicionados aos 15GB em média que a FRA termina ocupando, pode deixar pouco espaço para outras necessidades do sistema operacional, como arquivos temporários e etc. É só lembrar que no windows o XE é instalado por default em C:\OracleXE e no linux em /usr/lib/oracle/xe, ambos na partição do sistema operacional. É certo que no windows você ainda tem a possibilidade de alterar o diretório de instalação e consequentemente o HD de destino.

Mover a FRA para outro lugar (outro HD, de preferência), além de dar maior segurança, termina por liberar 15GB de espaço na partição do sistema.

Planejando o local de destino

Para mover a FRA para outro lugar, um detalhe precisa ser lembrado, principalmente no linux: o usuário oracle precisa ter direito de leitura e escrita no local de destino. Assim, é preciso certificar-se de que dar as permissões adequadas ao usuário oracle e ao grupo dba (ORA_DBA, no windows) sobre a pasta.

A título de exemplo, digamos que eu, no linux, transferi a FRA para o seguinte caminho:

/bigfoot/BACKUP_XE/flash_recovery_area

/bigfoot é uma partição montada em outro HD. Nesta partição, criei uma pasta chamada BACKUP_XE e dentro dela a pasta flash_recovery_area, para onde irei transferir a FRA.

A principio, bastaria dar os privilégios necessários, assim (como su):

chown -R oracle:dba /bigfoot/BACKUP_XE

desta forma, BACKUP_XE e tudo dentro dela passa a pertencer ao usuário oracle, sob o grupo dba. Mas há um pequeno detalhe: o usuário oracle não faz parte do grupo users (o grupo secundário default para todo usuário linux) e isto o impedirá de ter acesso à partição /bigfoot!

Para corrigir isto, basta incluir o usuário oracle também no grupo users.

Quem trabalho com o XE no windows, precisa contornar estas “pegadinhas” à sua maneira.

Informando ao XE o novo local da FRA

Para ter certeza de que as coisas correram bem, verifique as configurações atuais de FRA, usando o comando SQL abaixo. Conecte-se com SYSDBA e rode a seguinte SELECT:

SELECT
NAME,
TO_CHAR(SPACE_LIMIT, '999,999,999,999') AS SPACE_LIMIT,
TO_CHAR(SPACE_LIMIT - SPACE_USED + SPACE_RECLAIMABLE, '999,999,999,999')
AS SPACE_AVAILABLE,
ROUND((SPACE_USED - SPACE_RECLAIMABLE)/SPACE_LIMIT * 100, 1)
AS PERCENT_FULL
FROM V$RECOVERY_FILE_DEST;


Na figura acima, o resultado da SELECT em meu computador de testes (para este exemplo, usei o SQL Developer, pois queria capturar uma tela mais “elegante”). Podemos ver que ainda se encontra na localização padrão.

Para alterar o local da FRA, use o comando abaixo, conectado como SYSDBA:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = 'new_path';

new_path deve ser o caminho completo para a nova localização da FRA. Neste exemplo, o comando foi

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/bigfoot/BACKUP_XE/flash_recovery_area';

Movendo os on-line redo log files para a nova localização

Após mudar a localização da FRA, é necessário rodar um script oferecido pelo XE para mover os Online redo log files para a nova localização. Ainda no SQL*Plus, basta rodar o seguinte comando:

@?/sqlplus/admin/movelogs

Este script (movelogs.sql) fica na pasta ORACLE_HOME/sqlplus/admin. No SQL*Plus, a interrogação é uma abreviação para ORACLE_HOME. O comando deve ser executado inteiramento em letras minúsculas no linux.

ATENÇÃO USUÁRIOS LINUX.: Quando executei este script, recebi uma mensagem de erro informando que não foi possível apagar determinado grupo de redo log, pois ele se encontrava em uso. Certamente, é por causa do "excesso" de segurança do Linux. :-)

Você pode ignorar esta mensagem, por enquanto!

Não apague ainda os arquivos da FRA antiga

Em hipótese alguma apague manualmente os arquivos da FRA antiga. Os scripts de backup e restore, e o mecanismo de restauração do banco de dados (se for necessário) do XE, continuarão usando os dados da velha FRA até que eles se tornem obsoletos.

Uma forma de torná-los logo obsoletos é fazer dois backups seguidos do XE (três, se você não tiver feito nenhum, ainda). Somente depois de certificar-se de que o XE não precisará mais da FRA antiga é que você poderá apagar algum arquivo remanescente.

Verificando o resultado

Para verificar se as coisas deram certo, rode mais uma vez a SELECT que acessa V$RECOVERY_FILE_DEST e veja a nova localização da FRA.


Além disto, abra a interface HTML do XE, conectado como SYSTEM, e verifique a localização dos redo log files. Para isto, você deve clicar no link Log Archiving: On, que fica na parte inferior do painel Usage Monitor.


Note na figura acima que os dois grupos de redo logs já apontam para a nova FRA.


Somente para usuários Linux

Quando a gente escreve um tutorial, muitas vezes passa a impressão de que tudo dá sempre certo. Mas isto não é bem verdade! Comigo as coisas não deram tão certo assim :-(!

Lembram do erro que falei que pode ocorrer quando rodar o script movelogs.sql? Certamente ele vai acontecer. E pior ainda: você continuará com um grupo de redo log na velha FRA!

Caso isto realmente aconteça com você, vou dizer o que fiz para “corrigir” este pequeno inconveniente.

Rodei o script movelogs.sql mais duas vezes! Ao fazer isto, terminei com cinco grupos de on-line redo logs.

Após isto, segui a “sugestão” do manual do XE e fiz dois backups consecutivos, para o XE tornar obsoletos os arquivos da velha FRA.

Ainda assim, um dos (agora cinco) grupos de Online redo log ficava sempre na velha FRA. Dam!

Foi quando percebi que tinha que remover o danado “na unha”!

Dropping Log Groups

O manual da Oracle é categórico quando o assunto é apagar grupos de log. Vejamos algumas recomendações:

Antes de apagar um grupo de redo log, considere as seguintes restrições e precauções (Extraído do Oracle® Database Administrator's Guide, capítulo 6, item Dropping Redo Log Groups and Members):

  • Uma instância Oracle requer, ao menos, dois grupos de redo log, independentemente do número de membros de cada grupo (um grupo pode ter vários membros [arquivos]);
  • Você só pode apagar um grupo de redo log se ele estiver inativo. Se você precisar apagar um grupo que esteja ativo (current), primeiro force uma comutação (switch);
  • Certifique-se de que o grupo tenha sido arquivado antes de apagá-lo.

Para saber o estado de grupos de redo log, você pode fazer uma consulta via interface HTML do XE, como mostrado na figura anterior ou consultar a view V$LOG, com o seguinte comando:

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

GROUP# ARCHIVED STATUS
---------- --------- --------
1 YES INACTIVE
2 NO CURRENT

SQL>

Você vai precisar usar a interface HTML, pois além destas informações, ela mostra o arquivo associado ao grupo. Só assim você saberá se ele se encontra na antiga ou na nova FRA.

Caso o grupo que você deseja apagar esteja ativo, você pode forçar uma comutação (switch) com o seguinte comando:

ALTER SYSTEM SWITCH LOGFILE;

Com estas informações, agora dá para você se livrar do grupo de redo log indesejável. Tudo o que você precisa fazer é se certificar que ele está arquivado (ARCHIVED) e inativo (INACTIVE). A boa notícia é que ao fazer os dois backups subseqüentes, todos os redo log passaram a assumir este estado, exceto o que está ativo (CURRENT).

Para apagar um grupo de redo log, basta usar o seguinte comando:

ALTER DATABASE DROP LOGFILE GROUP N;

Onde N é o número do redo log que você quer apagar. Identifique qual o grupo que deseja apagar, usando os métodos já descritos e execute o comando;

Finalmente, faça um novo backup, para que o estado atual seja mantido.

-X-

quinta-feira, 18 de junho de 2009

Troubleshooting XE – Parte III – Backup / Restore

Continuando a série troubleshooting, nesta terceira parte vou falar sobre Backup / Restore.

Antes, um comentário muito particular:

Acho incrível a comunidade que adota bancos de dados “livres” ainda não ter migrado para o Oracle XE! Não bastasse o XE ser um produto da líder mundial em soluções para bancos de dados, ele ainda conta com uma poderosa ferramenta para backup/Restore muito poderosa: O RMAN (Recovery Manager). O mesmo RMAN presente nas versões pagas do Oracle. Nenhum outro servidor de banco de dados da categoria “livre” oferece coisa semelhante!

Graças ao RMAN, você pode fazer backups “inteligentes” e depois recuperar o backup de forma também “inteligente”, garantindo a mais completa e absoluta integridade dos dados. Os outros servidores de banco de dados da categoria “livre” oferecem também ferramentas de backup. Mas considero muito grosseiras, pois um “restore” implica sempre em perda de dados. Com o RMAN, é possível recuperar um backup e deixar o banco de dados na situação em que se encontrava no exato segundo anterior ao “crash”, graças ao poderoso recurso de “archive log” do Oracle.

O Backup

Fazer um backup no Oracle XE é incrivelmente simples: basta digitar algo como backup!

Como funciona o backup do XE

Quando você instala o XE, o RMAN é instalado também. O RMAN é a ferramenta de backup recomendada pela Oracle. Junto com o RMAN, o XE também instala um script para a realização do backup, de forma simplificada. No windows o script é chamada de backup.bat e no linux é chamado de backup.sh. Este script facilita muito a realização do backup e livra o DBA iniciante de detalhes muito técnicos do RMAN. Claro que, neste caso, você fica limitado às configurações do script.

No windows, backup.bat fica na pasta ORACLE_HOME\bin e no linux, backup.sh fica na pasta ORACLE_HOME/config/scripts.

Para saber onde é ORACLE_HOME, no linux digite echo $ORACLE_HOME e no Windows echo &ORACLE_HOME. Pode ser que no Windows esta variável de ambiente não esteja setada. Então você deverá procurar no arquivo de registro pela chave [HKEY_LOCAL_MACHINE \ SOFTWARE \ ORACLE \ KEY_XE] . Nela você poderá ver a variável ORACLE_HOME e o caminho que ela aponta.

O backup no Linux


Para fazer um backup no linux, basta abrir um terminal e abrir uma sessão como o usuário oracle (su – oracle) e digitar

oracle@SuSE111:~> $ORACLE_HOME/config/scripts/backup.sh
Warning: Log archiving (ARCHIVELOG mode) is currently disabled. If you restore the database from this backup, any transactions that take place between this backup and the next backup will be lost. It is recommended that you enable ARCHIVELOG mode before proceeding so that all transactions can be recovered upon restore. See the section 'Enabling ARCHIVELOG Mode...' in the online help for instructions. Backup with log archiving disabled will shut down and restart the database. Are you sure [Y/N]? Y
Backup in progress...
Backup of the database succeeded.
Log file is at /usr/lib/oracle/xe/oxe_backup_current.log.
Press ENTER key to exit
oracle@SuSE111:~>

O backup no Windows

Para fazer um backup no windows, basta abrir um “Prompt de Comando” e digitar

C:\>backup
Warning: Log archiving (ARCHIVELOG mode) is currently disabled. If you restore the database from this backup, any transactions that take place between this backup and the next backup will be lost. It is recommended that you enable ARCHIVELOG mode before proceeding so that all transactions can be recovered upon restore. See the section 'Enabling ARCHIVELOG Mode...' in the online help for instructions. Backup with log archiving disabled will shut down and restart the database. Are you sure [Y/N]? Y

Gerenciador de Recuperação: Release 10.2.0.1.0 - Production on Seg Jun 15 19:52:13 2009

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

Windows XP Version V5.1 Service Pack 3
CPU : 1 - type 586, 1 Physical Cores
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:230M/639M, Ph+PgF:160M/602M, VA:2003M/2047M
Starting with debugging turned off

conectado ao banco de dados de destino: XE (DBID=2569805002)

RMAN> set echo on;

(SEGUE-SE UMA INFINIDADE DE INFORMAÇÕES NA TELA!!! ATÉ QUE)

a política de retenção RMAN será aplicada ao comando
a política de retenção RMAN está definida para a redundância 2
utilizando o canal ORA_DISK_1
nenhum backup obsoleto encontrado

Recovery Manager completo.


Onde e como é feito o Backup?!


O backup é feito na pasta XE, que fica dentro da pasta flash_recovery_area.
Esta pasta pode ser localizada dentro do diretório de instalação do XE. Abaixo, sua localização no windows e no linux.

Windows: ORACLE_BASE\app\oracle\flash_recovery_area
Linux: ORACLE_BASE/app/oracle/flash_recovery_area

ORACLE_BASE é uma variável de ambiente, que serve como referência para os aplicativos Oracle. No caso do XE, seu valor aponta para lugares ligeiramente diferentes, dependendo se está instalado no windows ou no linux. Abaixo uma descrição.

ORACLE_BASE:
Windows → C:\OracleXE
Linux → /usr/lib/oracle/xe


O script de backup vai criar e manter sempre dois “sets” de backup. Assim, você poderá fazer um restore para a situação de até dois backups anteriores. Esta “lógica” é mantida dentro das pastas autobackup e backupset. A pasta autobackup armazena algumas informações de cada “set” e a pasta backupset armazena os backups propriamente ditos.

O Restore

Feito o backup, o restore é igualmente simples. Basta digitar algo como restore!

O script de restore encontra-se no mesmo lugar que o script de backup. E tudo o que ele faz é restaurar o banco de dados para a situação em que se encontrava imediatamente antes do último backup. Simples assim!

Para executar o restore, basta fazer o mesmo procedimento que adotado para o backup. Mas desta vez chamando o script restore.bat, no windows ou restore.sh, no linux.

As situações em que um restore se faz necessário são as mais diversas possíveis: varia de um erro de usuário, que apagou inadvertidamente uma série muito grande de dados; até um procedimento incomum, onde alguém apagou uma tabela do banco de dados; e, pior ainda, exclusão acidental de arquivos essenciais para o funcionamento do próprio Oracle XE.

Cuidados adicionais

Um ponto que acho vulnerável no Oracle XE, é o fato de, por default, ele fazer o backup no mesmo disco onde está instalado e ainda dentro de uma pasta hierarquicamente “subordinada” à ele.

Acho recomendável depois de feito o(s) backup(s), copiar estes arquivos para outro lugar. Outro disco, por exemplo, ou para uma midia de DVD regravável. Assim, mesmo que aconteça uma catástrofe no servidor, como perda total do HD ou até da própria máquina, basta instalar o XE novamente, copiar de volta a pasta XE para dentro da pasta flash_recovery_area, e executar um restore.

ARCHIVELOG mode

Os mais atentos observaram e leram o alerta que o script de backup faz, assim que é chamado:

Warning: Log archiving (ARCHIVELOG mode) is currently disabled. If you restore the database from this backup, any transactions that take place between this backup and the next backup will be lost. It is recommended that you enable ARCHIVELOG mode before proceeding so that all transactions can be recovered upon restore. See the section 'Enabling ARCHIVELOG Mode...' in the online help for instructions. Backup with log archiving disabled will shut down and restart the database. Are you sure [Y/N] ?

Primeiro vou explicar o que isto significa!

Simplesmente, o alerta informa que todas as operações realizadas no banco de dados após o último backup serão perdidas na ocasião de um restore. Exemplo:

Você agenda os backups todos os dias, à meia noite. Se durante o dia seguinte acontecer um “crash”, e você precisar recuperar o backup feito na noite anterior, todos as operações realizadas sobre o banco de dados durante o dia estarão perdidas.

Uma forma de contornar isto seria fazer backups intermediários durante o dia: um às 10:00h e outro às 15:00h. Assim, em caso de “crash”, um restore faria perder meio expediente de trabalho, digamos assim. Mas isto tem o inconveniente de ter que parar o banco de dados enquanto durar o backup (alguns segundos, diga-se de passagem).

O que é ARCHIVELOG mode?

Archive log mode ou Modo de Registro de Arquivamento é um dos recursos que fazem do Oracle o melhor servidor de banco de dados do mundo!

Neste modo, em intervalos de tempo regular, todas as operações realizadas no banco de dados são gravadas dentro de arquivos especiais. Assim, em caso de um “crash”, você tem registrado em algum lugar não só a situação em que o banco de dados se encontrava segundos antes do “crash”, mas a situação em que se encontrava ao longo de um tempo determinado, que pode ser segundos, minutos, horas, dias, semanas ou até mesmo meses!

Qual o significado disto?

Simples! Ao ser feito um restore, o RMAN busca nestes arquivos de registro de arquivamento todas as operações que foram realizadas no banco de dados após o backup sendo restaurado e as aplica de volta no banco de dados. Isto quer dizer que mesmo que o backup tenha sido feito dias antes, todas as operações realizadas sobre o banco de dados serão restauradas dos arquivos de registro de arquivamento.

Além disso, se o archivelog mode estiver ativo, você nem precisa restaurar todo um backup por causa de uma simples exclusão ou alteração indevida em uma tabela. Através de comandos apropriados via SQL, você pode olhar o passado do banco de dados; pode restaurar a informação de um campo ou tabela para a situação em que se encontrava no passado; etc.

Mais uma vantagem: com o archivelog ativado, os backups podem ser feitos "on-line", ou seja, não é preciso parar o banco de dados para a realização do backup. As pessoas podem continuar trabalhando sobre o banco de dados, enquanto o backup se processa em background.

Uau! Vamos correndo ativar o archive log...

...calma! Muita calma nesta hora!

Como sempre, tudo tem um preço. Se você não tomar os cuidados necessários, se não estudar o bastante, e se não conhecer certos detalhes do modo de registro de arquivamento, você tornará impraticável o uso do banco de dados! Em poucos minutos, você poderá “explodir” o HD, abarrotando-o de giga bytes e giga bytes de arquivos de log e o servidor irá parar!

ARCHIVELOG é um recurso incrível, mas que precisa de um certo planejamento e cuidado, antes de ser usado. Precisa ver a relação custo/benefício. Se o benefício de poder restaurar o banco de dados para qualquer situação anterior a segundos, em pouco tempo, justificar o custo de ocupar mais espaço em disco e uma dedicação maior para monitoramento do servidor, então faça!

A boa notícia é que está disponível no XE e pode ser habilitado. Mas como o tiro pode sair pela culatra, a Oracle optou em deixar este modo desabilitado por default, no XE.

Para aprender como colocar o XE no ARCHIVELOG mode, leia este outro artigo.

--X--

segunda-feira, 15 de junho de 2009

Troubleshooting XE – Parte II - Listener

Continuando a série troubleshooting, nesta segunda parte vou falar sobre o Listener. O Listener é um componente de uma arquitetura desenvolvida pela Oracle, chamada Net Services.

Como não dá para falar de Listener sem falar do Oracle Client, nesta segunda parte também vou falar um pouco sobre o Oracle Client, que deve ser instalado em máquinas onde rodam aplicações Cliente/Servidor e que acessam o banco de dados Oracle.

Para entendermos tanto o Listener, quanto o Oracle Client, é preciso uma introdução mínima aos fundamentos de conexão em rede da Oracle.


A Arquitetura de Redes da Oracle: Oracle Net Connections


Oracle Net Connections é a camada de software que reside tanto no lado do cliente quanto no lado do servidor de banco de dados oracle (servidor). É responsável por estabelecer e manter a conexão entre a aplicação cliente e o servidor, bem como o intercâmbio de mensagens entre eles, usando protocolos padrão da indústria. A Oracle Net é compreendida de dois componentes de software:

  • Oracle Net foundation layer
  • Oracle protocol suport

Oracle Net Foundation Layer (ONF)


Do lado do cliente, as aplicações se comunicam com a ONF para estabelecer e manter conexões. A ONF usa uma camada de suporte a protocolos da Oracle, que roda em cima de protocolos padrão de rede, como o TCP/IP, para se comunicar com o servidor.





Do lado do servidor, o funcionamento é similar ao do lado do cliente. O protocolo de rede envia as requisições do cliente para uma camada de suporte a protocolos da Oracle, que envia a informação para a ONF. A ONF então se comunica com o servidor, para processar as solicitações do cliente.




Oracle protocol suport

A Oracle Net foundation layer (ONF) usa a camada de suporte a protocolos da Oracle para se comunicar com os seguintes protocolos de rede padrão da indústria:
  • TCP/IP
  • TCP/IP with SSL
  • Named Pipes
  • SDP
A camada de suporte a protocolos da Oracle faz o mapeamento necessário entre a ONF e os protocolos padrão da indústria, usados para a comunicação entre máquinas em uma rede.

Oracle Net Listener

A única, porém importante função do Oracle Net Listener ou simplesmente Listener, é receber requisições de acesso ao servidor de banco de dados oracle. O Listener é configurado com um endereço e um protocolo. Clientes configurados com o mesmo protocolo podem enviar requisições de conexão para o Listener, no endereço em que ele se encontra (sempre do lado do servidor). Uma vez recebida a requisição, ela é passada para o servidor, quando então é estabelecida uma conexão direta entre o banco de dados e a aplicação cliente. Após estabelecida uma conexão entre o cliente e o servidor, o Listener “sai de campo”, pois já terá cumprido seu papel.


Oracle Net Client

Em uma estrutura cliente/servidor (tipicamente uma rede local), é necessário instalar o Oracle Net Client ou o que chamamos aqui no Brasil de Cliente Oracle. Consiste em instalar os componentes necessários para a Oracle Net foundation layer (ONF), que devem estar presentes na máquina cliente.


Using Easy Connect Naming on the Client


A partir da versão 10g, a Oracle introduziu o conceito de Easy Connect ou conexão fácil. Neste modo, não é preciso configurar coisa alguma no cliente. Basta instalar e pronto! Entretanto, os softwares precisam usar uma sintaxe de conexão da seguinte forma:

username/password@[//]host[:port][/service_name]

Se, por exemplo, o Oracle XE Server estiver rodando numa rede local em uma máquina cujo IP é 172.16.148.2, e você estiver numa máquina cliente querendo conectar-se ao servidor via SQL*Plus, basta fazer o seguinte:

sqlplus /nolog
SQL> CONNECT usuario/senha@172.16.148.2

Note que no exemplo acima só foi informado o que é obrigatório. Todos os defaults não foram informados (a // | a porta: 1521 | e o service_name:XE).

DICA: para conexões via URL ou JDBC, o uso das barras (//) é obrigatório antes do host:
usuario/senha@//172.16.148.2

Compatibilidade “para trás”: Oracle Names

O Oracle 10g e versões posteriores não suportam mais Oracle Names. Se você tiver aplicações em tua rede que foram desenvolvidas usando Oracle Names, basta você instalar versões anteriores do Oracle Client. Geralmente a versão Cliente do Oracle 9i resolve.

Como o público alvo deste Blog é o pessoal que usa o Oracle 10g e posteriores, não vou entrar em detalhes neste assunto. Mas a instalação de clientes de versões anteriores ao 10g consiste em duas etapas: a instalação do software cliente e sua configuração. A instalação é simples, via famoso avançar; e a configuração também é fácil: basta rodar o Oracle Net Configuration Assistant (ou netca, em linha de comando).

A configuração nada mais é que informar um Nome de Serviço e o IP ou nome do Host onde o Oracle Server está rodando. Através do Nome de Serviço é que tanto as aplicações quanto os utilitários, a exemplo do SQL*Plus, podem se conectar ao servidor.

Resumindo:

O Listener é um processo que reside num servidor de banco de dados Oracle, cuja responsabilidade é “ouvir” requisições de conexão que chegam dos clientes, além de gerenciar o tráfego para o servidor.

Quando um cliente solicita uma seção de rede com o servidor, um listener recebe a solicitação. Se as informações do cliente combinam com as informações do listener, é permitida uma conexão com o servidor de banco de dados.

Do lado da máquina cliente, é preciso instalar o Cliente Oracle. A partir da versão 10g, não há mais suporte ao Oracle Names e a conexão é feita no modo Easy Connect.


Enfim, O Listener


Na primeira parte desta séria, vimos como iniciar e parar o Listener. Vimos também como checar seu status. A partir de agora vamos estudar seu funcionamento, a fim de poder sanar eventuais problemas. Começaremos pela configuração do Listener e o arquivo listener.ora.

Configurando o Listener

Quando você instala o Oracle 10g XE, ele deixa o Listener configurado. Não há o que fazer neste aspecto. Além disto, é muito raro problemas com o Oracle XE, uma vez instalado e mantido em condições normais de temperatura e pressão :-). Se não ocorrer nenhuma pane no HD onde o XE foi instalado, você nunca terá que se preocupar com o Listener, nem com qualquer outra coisa mais séria.
Mas como o XE é usado por estudantes e até mesmo por desenvolvedores que instalam o XE em seus Desktops ou Notebooks, algumas coisas “inusitadas” podem acontecer e o XE parar de funcionar. Uma delas é o banco de dados rodar perfeitamente, mas o Listener não! O que impede, por exemplo, o SQL Developer ou a interface HTML de conectar ao banco de dados.

O arquivo listener.ora

Para que a gente possa entender o funcionamento do Listener, vamos “espionar” o arquivo listener.ora.
O arquivo listener.ora fica, tipicamente, em $ORACLE_HOME/network/admin, na plataforma Unix/Linux e ORACLE_HOME\network\admin na plataforma Windows. ORACLE_HOME é uma variável de ambiente.

Um arquivo listener.ora típico apresenta a seguinte configuração:

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /usr/lib/oracle/xe/app/oracle/product/10.2.0/server)
(PROGRAM = extproc)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
(ADDRESS = (PROTOCOL = TCP)(HOST = SuSE111)(PORT = 1521))
)
)

DEFAULT_SERVICE_LISTENER = (XE)

A parte que nos interessa é a que está em negrito. E as linhas relevantes são as que estão na cor vermelha. As demais informações se devem ao fato que em um mesmo arquivo listener.ora pode existir configurações para mais de um Listener e para mais de uma instância Oracle (mais de um servidor na mesma máquina, rodando em paralelo). Na versão XE isto é irrelevante, pois só pode haver uma instância. Então nos concentremos nas linhas em vermelho.

A linha (ADDRESS = (PROTOCOL = TCP)(HOST = SuSE111)(PORT = 1521)) informa o protocolo padrão (PROTOCOL) sobre o qual a Oracle Net Foundation Layer está trabalhando, o nome da máquina (HOST) e a porta (PORT) através da qual o Listener estará “escutando”.

Esta informação deve ser passada para a equipe de desenvolvimento das aplicações, uma vez que é com base nestas informações que eles irão configurar o “string de conexão” para o Easy Connect Naming. Com base nas informações acima, uma conexão típica seria:

sqlplus /nolog
SQL> CONNECT usuario/senha@SuSE111:1521/XE

Como a porta 1521 é a porta padrão e o DEFAULT_SERVICE_LISTENER = (XE), a conexão poderia ser feita mais resumidamente assim:

sqlplus /nolog
SQL> CONNECT usuario/senha@SuSE111

O que pode dar errado no Listener?

Sinceramente? Pouquíssima coisa! Numa situação de produção, depois de instalado e configurado, só uma pane geral no HD da máquina servidora para causar algum problema, caso o HD danificado contenha o XE instalado nele. Neste caso, depois de sanado o problema, somente o Restore de um Backup que você, pessoa prevenida, deverá ter feito, irá resolver o problema.

Mas, e se eu tiver o XE instalado no meu Notebook ou numa estação de trabalho e apesar de aparentemente estar tudo Ok., mesmo assim o Listener não funcionar?

Bem, somente uma de duas coisas poderá ter acontecido:

  1. ou o arquivo listener.ora “sumiu”
  2. ou as informações contidas nele não estão mais “batendo” com a máquina!

A segunda “alternativa” é a mais provável! E a causa mais provável é uma mudança no nome do Host! Se você usar DHCP ou se tua máquina ingressar num domínio Windows, por exemplo, o nome do Host pode mudar sem você se dar conta, e isto é um problema para o Listener!

O Nome do Host mudou!

Por isto que é bom saber como iniciar, parar e verificar o status do Listener “manualmente”. Uma saída típica do Listener com mensagem de erro, por causa de troca de nome de host, é listada abaixo:

oracle@SuSE111:~> lsnrctl start

LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 14-JUN-2009 23:29:33

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

Iniciando /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr: aguarde...

TNSLSNR for Linux: Version 10.2.0.1.0 - Production
O arquivo de parâmetros do sistema é /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/admin/listener.ora
Mensagem de log gravada para /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/log/listener.log
Atendendo em: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
Erro ao atender em: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=SuSE)(PORT=1521)))
TNS-12545: A conexão falhou porque o objeto ou host de destino não existe
TNS-12560: TNS:erro de adaptador de protocolo
TNS-00515: A conexão falhou porque o objeto ou host de destino não existe


Falha ao iniciar o listener. Consulte a(s) mensagem(ns) de erro acima...

Assim fica fácil, não é? :-)

No linux, basta o comando uname -n para saber o nome do host. Então é só abrir o arquivo listener.ora e corrigir.

No windows, você precisa descobrir o nome do computador clicando com o botão direito em “Meu Computador” e selecionar Propriedades. Depois é clicar na aba [Nome do computador] e ver o que está escrito no campo “Nome completo do computador”.
Não é que eu implique com a Microsoft, mas isto acontece muito frequentemente no Windows e muito raramente no Linux!

Full Backup!

Uma outra situação não muito rara é que, pelo fato do XE ser pequeno em termos de ocupação de espaço em disco, algumas pessoas fazem um backup inteiro do XE, copiando toda a pasta para outro disco. Não deixa de ser uma solução!

Alguns até se aproveitam deste fato para copiar o XE de uma máquina para outra, simplesmente instalando o XE na outra máquina e depois "jogando" a cópia feita "por cima" da nova instalação. É também uma solução simples!


Mas ambas esbarram no pequeno detalhe que o nome do host provavelmente não será o mesmo. E por este pequeno detalhe muitos terminam descartando estas possiblidades, quando bastaria editar o arquivo listener.ora!

sexta-feira, 12 de junho de 2009

Troubleshooting XE – Parte I

Após a instalação de um banco de dados, começa a “rotina” de um DBA (DataBase Administrator): Backup/Restore; resolução de pequenos e grandes problemas causados ou pelo usuário ou por uma pane no Sistema Operacional; Medidas de segurança; etc. Neste primeiro artigo de uma série que chamarei troubleshooting, vou falar sobre dois componentes fundamentais de um servidor de banco de dados Oracle.

Para que um servidor de banco de dados baseado em Oracle possa funcionar perfeitamente, seja qual for a versão, é preciso que ao menos dois componentes fundamentais estejam funcionando: o Database Service e o Listener.

Como é necessário sabermos como as coisas funcionam normalmente, para sabermos o que fazer quando as coisas dão errado, vou começar explicando o funcionamento destas partes fundamentais. Nas próximas publicações, entrarei na questão de chamada deste tópico: o “troubleshooting”.

Database Service & Listener

O Database Service é o componente principal. É o que nós chamamos de uma Instância. Depois que você instala um servidor de banco de dados Oracle, é preciso criar uma instância de banco de dados. Normalmente, durante o processo de instalação lhe é dada a opção de criar esta instância ou deixar para depois. Na versão XE não há esta escolha: uma instância é criada automaticamente e ela é identificada por XE. Esta identificação é chamada de SID (System IDentifier). O SID do XE, seja no windows ou no linux, é sempre XE.

O Listener é um serviço que permite a comunicação entre o Database Server e os clientes. Os clientes a que me refiro são os usuários do banco de dados ou as aplicações que acessam o mesmo.




Sem o Listener, não há comunicação entre as estações remotas e o servidor (Database Server), mesmo que o Database Service esteja funcionando perfeitamente.

Identificando as partes

Inicie o XE da forma adequada ao teu SO e vamos neste momento conhecer os mecanismos para obter informações a respeito do Listener e do Database Service.

Trabalhando com o Listener

Existe um utilitário de linha de comando que serve para gerenciar as atividades do Listener. Algumas destas atividades são: iniciar; parar; e verificar o status. O nome do utilitário é lsnrctl.

Iniciando e Parando o Listener

Para iniciar ou parar o Listener, basta usar o utilitário lsnrctl, adicionando o comando que informa se você quer iniciar (start) ou parar (stop). Exemplo:

  • Iniciar o Listener

lsnrctl start

TNSLSNR for Linux: Version 10.2.0.1.0 - Production
O arquivo de parâmetros do sistema é /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/admin/listener.ora
Mensagem de log gravada para /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/log/listener.log
Atendendo em: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
Atendendo em: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SuSE111)(PORT=1521)))

Estabelecendo conexão com (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
STATUS do LISTENER
------------------------
Apelido LISTENER
Versão TNSLSNR for Linux: Version 10.2.0.1.0 - Production
Data Inicial 11-JUN-2009 20:13:50
Funcionamento 0 dias 0 hr. 0 min. 0 seg
Nível de Análise off
Segurança ON: Local OS Authentication
SNMP OFF
Serviço Default XE
Arq. Parâm. Listn. /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/admin/listener.ora
Arq. Log Listener /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/log/listener.log
Resumo de Atendimento...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SuSE111)(PORT=1521)))
Resumo de Serviços...
O serviço "PLSExtProc" tem 1 instância(s).
Instância "PLSExtProc", status UNKNOWN, tem 1 handler(s) para este serviço...
O comando foi executado com êxito

  • Parar o Listener

lsnrctl stop

LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 11-JUN-2009 20:15:11

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

Estabelecendo conexão com (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
O comando foi executado com êxito

  • Verificar o Status do Listener

lsnrctl status

A saída deste comando é uma série de informações a respeito do status do listener. Há pouca variação de formato e informações se o XE está no Linux ou no Windows. Abaixo, a saída para o windows (em marrom) e logo depois para o linux (em azul), de uma situação normal, ou seja, o Listener está ativo e tudo funcionando perfeitamente bem.

LSNRCTL for 32-bit Windows: Version 10.2.0.1.0 - Production on 04-JUN-2009 21:14:29

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

Estabelecendo conexão com (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
STATUS do LISTENER
------------------------
Apelido LISTENER
Versão TNSLSNR for 32-bit Windows: Version 10.2.0.1.0 - Production
Data Inicial 11-JUN-2009 17:35:58
Funcionamento 0 dias 0 hr. 4 min. 17 seg
Nível de Análise off
Segurança ON: Local OS Authentication
SNMP OFF
Serviço Default XE
Arq. Parâm. Listn. C:\oraclexe\app\oracle\product\10.2.0\server\network\admin\listener.ora
Arq. Log Listener C:\oraclexe\app\oracle\product\10.2.0\server\network\log\listener.log
Resumo de Atendimento...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC_FOR_XEipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dreamer)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=8080))(Presentation=HTTP)(Session=RAW))
Resumo de Serviços...
O serviço "CLRExtProc" tem 1 instância(s).
Instância "CLRExtProc", status UNKNOWN, tem 1 handler(s) para este serviço...
O serviço "PLSExtProc" tem 1 instância(s).
Instância "PLSExtProc", status UNKNOWN, tem 1 handler(s) para este serviço...
O serviço "XEXDB" tem 1 instância(s).
Instância "xe", status READY, tem 1 handler(s) para este serviço...
O serviço "XE_XPT" tem 1 instância(s).
Instância "xe", status READY, tem 1 handler(s) para este serviço...
O serviço "xe" tem 1 instância(s).
Instância "xe", status READY, tem 1 handler(s) para este serviço...
O comando foi executado com êxito


LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 11-JUN-2009 17:36:36

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

Estabelecendo conexão com (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
STATUS do LISTENER
------------------------
Apelido LISTENER
Versão TNSLSNR for Linux: Version 10.2.0.1.0 - Production
Data Inicial 11-JUN-2009 17:35:58
Funcionamento 0 dias 0 hr. 0 min. 38 seg
Nível de Análise off
Segurança ON: Local OS Authentication
SNMP OFF
Serviço Default XE
Arq. Parâm. Listn. /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/admin/listener.ora
Arq. Log Listener /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/log/listener.log
Resumo de Atendimento...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SuSE111)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=8080))(Presentation=HTTP)(Session=RAW))
Resumo de Serviços...
O serviço "PLSExtProc" tem 1 instância(s).
Instância "PLSExtProc", status UNKNOWN, tem 1 handler(s) para este serviço...
O serviço "XE" tem 1 instância(s).
Instância "XE", status READY, tem 1 handler(s) para este serviço...
O serviço "XEXDB" tem 1 instância(s).
Instância "XE", status READY, tem 1 handler(s) para este serviço...
O serviço "XE_XPT" tem 1 instância(s).
Instância "XE", status READY, tem 1 handler(s) para este serviço...
O comando foi executado com êxito


Como podem ver, não há muita diferença entre a saída no linux e a saída no windows, a não ser por pequenos detalhes de nome de host, caminhos de arquivos e etc. Então vamos ao que interessa!

  • Parâmetros e Log do Listener

Atenção para estas duas linhas:
Arq. Parâm. Listn. /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/admin/listener.ora
Arq. Log Listener /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/log/listener.log

listener.ora é o arquivo de parâmetros do Listener. Quando o Listener é iniciado, ele abre este arquivo, para poder se configurar adequadamente.
listener.log é o arquivo de Log do Listener. Uma série de informações de inciação e parada do Listener são gravadas neste arquivo. Se algo estiver dando errado, este é o primeiro arquivo que você deverá abrir, para identificar o problema.

Vamos prestar atenção agora em outras três linhas, abaixo de Resumo de Atendimento...:

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SuSE111)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=8080))(Presentation=HTTP)(Session=RAW))

A segunda linha informa que o Listener está “escutando” através da porta (PORT) 1521, a porta padrão, e o nome da máquina (HOST) onde ele está rodando. Estas informações são importantes para quando você for configurar as estações clientes.

A terceira linha informa que a interface HTML do XE (HTTP) está disponível na porta 8080. Se ao iniciar o Listener você não visualizar esta linha, é porque ou o Database Service não está iniciado, ou ainda está iniciando. Explico: o Listener inicia muito rápido. Mas o Database Service demora mais um pouco e pode ser que o serviço HTTP ainda não esteja disponível se você por acaso solicitar o status do Listener logo após inciar o Database Service.

  • 127.0.0.1, o IP “cabalístico”

Se observaram bem, o HOST informado na terceira linha é o 127.0.0.1. Por que este número, ao invés do nome do host (SuSE111)? Bem, por hora basta saber que o serviço HTTP para a interface HTML do XE é oferecido pelo Database Service e não pelo Listener. O Listener apenas dá esta informação. Mas deixando de lado questões técnicas, vamos nos ater ao número.

127.0.0.1 é chamado IP de loop-back ou IP do localhost. Numa rede, localhost se refere sempre a máquina local, ou seja, a máquina onde “você está”! O número “cabalístico” 127.0.0.1 é o endereço IP de localhost. Confuso? Nem tanto...

Se você não tiver certeza de que está numa rede ou se não tiver certeza que a rede está operacional, mas quiser ter certeza que tua máquina está com os serviços de rede funcionando bem (primeiro passo para solucionar problemas de conexão em rede), basta você se referir a ela mesma, seja usando localhost ou o IP 127.0.0.1.
O comando ping é muito usado para ver se tua máquina está se comunicando com outras máquinas na rede. Mas serve também para checar se os serviços de rede em tua máquina estão rodando. Se você “pingar” tua própria máquina e ela não responder, nem adianta tentar se comunicar com as outras. Então se você fizer ping localhost ou ping 127.0.0.1 você deve obter alguma resposta.

Talvez por isto o endereço da interface HTML do XE seja o 127.0.0.1 (poderia ser localhost). Assim, não é preciso se preocupar com o nome do host, se você está na máquina onde o XE está rodando. Claro que para acessar através de outra máquina da rede, você precisa saber o nome do host ou seu endereço IP, na rede.

O Database Service

O Database Service é o serviço da instância do servidor de banco de dados sobre a qual você está trabalhando. Na caso do XE, como já se sabe, esta instância é identificada pelo SID XE. Se o Database Service não estiver “no ar”, não há meios de você trabalhar sobre o banco de dados.

Em outra matéria deste blog, quando falei sobre Tarefas após instalação no Windows e no Linux, expliquei como configurar o servidor para ser iniciado “manualmente”, tanto no windows, quanto no linux. Mesmo dito “manualmente”, aquela maneira é uma forma indireta de iniciar o banco de dados. Agora vamos ver como um verdadeiro DBA pode iniciar diretamente um banco de dados Oracle.

Existe um modo especial para se conectar ao Oracle, através do SQL*Plus, que permite a um DBA controlar o modo como o banco de dados é iniciado (start) ou parado (shutdown). Este modo especial permite, ainda, resolver eventuais problemas com o banco de dados. Por isto vamos estudá-lo agora.

Conectando-se como sysdba.

Tanto o usuário system quanto o usuário sys podem se conectar ao Oracle com a prerrogativa de sysdba. Esta prerrogativa dá poderes absolutos sobre o banco de dados, com ligeiras variações. Certas tarefas, podem ser executadas apenas pelo usuário system; outras, somente pelo usuário sys. Mas para controlar a instância do banco de dados, você pode usar tanto um quanto o outro.

Para fazer isto, basta entrar no SQL*Plus passando as credenciais usuário/senha, acrescentando a diretiva as sysdba. Exemplo:

sqlplus system/senha as sysdba

Usando as credenciais do sistema operacional

Outra maneira mais simples de se conectar é utilizar as credenciais do SO. Se você estiver conectado como um usuário pertencente ao grupo de DBAs do Oracle, basta usar a seguinte sintaxe:

sqlplus / as sysdba

A / colocada sozinha, sem usuário e senha, informa que é para o SQL*Plus usar as credenciais do usuário conectado no SO.

Dependendo de como o servidor está no momento em que você se conecta, o SQL*Plus exibirá as seguintes informações:

  • Servidor Parado (shutdown)

oracle@SuSE111:~> sqlplus / as sysdba

SQL*Plus: Releduction on Sex Jun 12 00:57:21 2009

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

Conectado a uma instância inativa.

SQL>

  • Servidor Rodando (startup)

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Jun 12 01:10:51 2009

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


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

SQL>

Iniciando o banco de dados

Para iniciar uma instância Oracle basta, uma vez conectado como sysdba, usar o comando startup:

SQL> startup
Instância ORACLE iniciada.

Total System Global Area 805306368 bytes
Fixed Size 1261444 bytes
Variable Size 243269756 bytes
Database Buffers 557842432 bytes
Redo Buffers 2932736 bytes
Banco de dados montado.
Banco de dados aberto.

Parando o banco de dados

Quando quiser parar uma instância Oracle basta, uma vez conectado como sysdba, usar o comando shutdown:

SQL> shutdown
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.

shutdown immediate, shutdown abort e shutdown normal

O modo default do comando shutdown é o modo normal. Nos exemplos acima, foi este o modo de shutdown da instância. Deu certo pois este exemplo foi dado num ambiente de testes. Mas no “mundo real” isto raramente funcionaria! Para entender isto, vamos ver o que diz a documentação:

Normal (default) - waits for in-flight work to complete
Immediate - terminates all sessions and does a rollback on all uncommitted transactions
Abort - aborts all sessions, leaving current DML in need of rollback, de-allocates the SGA and terminates the background processes.

  • Traduzindo em miúdos:

Normal – Espera que todos os trabalhos pendentes se completem, antes do shutdown. Isto é raríssimo de funcionar, pois qualquer conexão aberta com o banco de dados impedirá o shutdown. Além disto, acontece de as vezes existirem “sessões fantasmas”, ou seja, por alguma razão o Oracle “pensa” que tem alguém conectado, quando não há efetivamente ninguém. Se algum dia você esquecer deste detalhe e der um shutdown normal, não hesite em apertar CTRL+C após alguns minutos esperando pelo shutdown, sem nada acontecer!

Este modo é chamado por alguns DBAs de “clean shutdown”. Infelizmente, é muito raro de funcionar.

Immediate – termina todas as seções e faz um rollback em todas as transações não enviadas (commited). Talvez esta seja a melhor maneira de você interromper uma instância do Oracle. Este comando evita novos logins, faz um rollback de todas as transações pendentes e desativa a instância. Um shutdown immediate ainda garante um posterior startup bem mais rápido, pois não haverá muito trabalho de recuperação da instância.

Na maioria das vezes, o shutdown immediate funcionará “redondo”. Mas para o caso de ele não funcionar, existe o shutdown abort.

Abort – aborta (interrompe) todas as seções, deixando qualquer DML pendente de rollback, desaloca a SGA (System Global Area) e termina todos os processos de background. Este comando não causará nenhum dano ao banco de dados. O único “efeito colateral” é que o banco de dados levará mais tempo para se recuperar no próximo startup.

Resumo da Ópera

Este “post” foi bem extenso! Por isto vou fazer um resumo. Assim, da próxima vez que voltar aqui para fazer uma consulta rápida, basta vir aqui no final.

O Listener

O Listener é o responsável por “escutar” e atender as solicitações de conexão ao banco de dados. Para que ele seja iniciado e configurado adequadamente, busca informações no arquivo listener.ora.

O utilitário de linha de comando lsnrctl permite que você obtenha o status do Listener, interrompa (stop) ou inicie (start) o Listener. Para isto, basta executá-lo, passando o comando que desejar:

lsnrctl start ← Inicia o Listener
lsnrctl status ← Apresenta o status do Listener
lsnrctl stop ← Pára o Listener

O Dabase Service

O Database Service é a instância do Oracle responsável pelo provimento do banco de dados propriamente dito. Para que um DBA possa controlar o Database Service, ele pode se conectar com as prerrogativas de sysdba. A maneira mais simples e habitual é utilizar o comando

sqlplus / as sysdba

que utiliza o perfil do usuário conectado ao SO para fazer a autenticação. Este usuário precisa fazer parte do grupo dba, no linux ou ORA_DBA, no windows. Para dar um “tiro certeiro”, um DBA pode conectar-se usando as senhas do sys ou do system:

sqlplus system/senha as sysdba

Uma vez conectado como sysdba, um DBA pode iniciar (startup) ou parar (shutdown) uma instância do Oracle.

Com relação ao shutdown, o modo mais apropriado é usando o comando shutdown immediate. Mas se existir alguma situação em que este comando não funcione, utiliza-se o shutdown abort.

Na próxima publicação irei entrar, de fato, na resolução de problemas (troubleshooting) envolvendo o Listener e a Instância Oracle. Até lá...