Administração de bases-de-dados Oracle 11g (Básico)

Depois de adquirir alguma experiência na área de administração de bases-de-dados Oracle e, em particular, na recuperação de bases-de-dados em cenário de catástrofe, considero pertinente abordar o tema, em primeiro lugar, expondo os conceitos na vertente prática e, em segundo, complementá-los de forma teórica. É este o objectivo deste texto. No que se segue, em todas as referências a processos de sistema operativo no qual este não esteja identificado, deverá sempre assumir-se o Windows Server.

Instalação

A instalação do motor da base-de-dados é o primeiro passo a tomar caso este ainda não tenha sido dado. Antes de proceder à sua instalação é conveniente ler o manual de utilização de modo a garantir que o sistema que se pretende ser o anfitrião é suportado e possui o mínimo de recuros necessários. É possível encontrar este manual na ligação Database Quick Installation Guide. Supondo que o sistema se encontra de acordo com os requisitos e os recursos de memória e processamento são suficientes, estamos aptos a proceder à instalação do programa, o qual pode ser obtido em Oracle Database Software Downloads. É importante lembrar que os programas disponibilizados pela Oracle são regulados por uma licença que restringe legalmente a sua utilização e deverá ser lida com a devida atenção.
A instalação da base-de-dados Oracle 11g não oferece grandes dificuldades se for realizada em sistemas operativos profissionais, empresariais ou de servidor (como é o caso do Windows Server/Enterprise ou Linux). A sua distribuição é realizada por intermédio de dois ficheiros compactados em formato zip, os quais terão de ser descompactados para uma directoria à escolha. Entre os ficheiros descompactados encontra-se o executável Setup.exe que permite iniciar o instalador. O instalador requer a introdução de alguns parâmetros de configuração, nomedamente, a Oracle Base Location (localização onde serão guardados os binários de base-de-dados) e a Oracle Home Location (localização dos ficheiros que constituem o motor em si). Além disso, permite criar uma instância inicial. Como cada instância consiste numa base-de-dados e o motor suporta várias instâncias, a sua criação poderá ser adiada para uma fase posterior desde que seja criado um Listener. A criação de uma instância aquando da instalação resulta numa base-de-dados completamente funcional com o menor esforço possível e é aconselhável numa fase inicial (de facto, suporei aqui que esta opção foi seleccionada). Para efeitos de testes, a escolha de uma instalação por defeito é suficiente.
Suponhamos que instalámos o motor da base-de-dados, criando uma instância denominada orcl com palavra-chave do sistema orcl num anfitrião qualquer. Pretendemos, portanto, conectar-nos ao sistema. Duas formas são imediatamente disponibilizadas, nomeadamente, o Oracle Enterprise Manager e o SQLPlus.
O Oracle Enterprise Manager consiste numa aplicação de servidor que pode ser acedida por intermédio de um navegador como o Chrome ou o Firefox. Em ambiente Windows, é criada uma ligação no menu Oracle – OraDb11g_home1 sita no submenu Todos os Programas (All Programs) do menu Iniciar (Start) designada por Database Control – orcl que permite lançar o navegador definido por defeito no endereço e porta correctos. Para acedermos às páginas de controlo da base-de-dados, caso esta opção tenha sido escolhida durante a instalação da instância de base-de-dados, introduzimos o utilizador SYS, a palavra-chave definida durante a instalação e conectamo-nos como SYSDBA. Neste ambiente é possível realizar praticamente todas as tarefas de administração da base-de-dados.
O SQLPlus consiste num utilitário de linha de comandos que permite ao administrador executar qualquer comando ou script na base-de-dados, incluindo consultas de SQL. Se executarmos, na linha de comandos do anfitrião,

>sqlplus sys/orcl as sysdba

o SQLPlus tenta uma ligação à instância que se encontra definida por defeito (no caso do Windows Server, vem definido na tabela dos registos – Configuration Parameters and the Registry) com o utilizador SYS e palavra-chave orcl. É útil observar que, quando é executado o SQLPlus, surge a sua versão no cabeçalho. Esta informação torna-se importante quanto pretendemos recuperar bases-de-dados em instalações diferentes, sendo os erros, devidos a diferenças nas versões, difíceis de detectar.
Para aceder à instância específica, teremos de alterar a variável de ambiente oracle_sid na sessão actual. Para garantir que o SQLPlus se conecta à instância orcl, introduzimos, na linha de comandos, supondo que pretendemos conectar-nos à base-de-dados com SID=orcl (o SID é definido durante a criação da base-de-dados, caso tenha sido seleccionada a opção de criação de uma instância durante a instalação),

>set oracle_sid=orcl
>sqlplus sys/orcl as sysdba

Uma vez iniciado o SQLPlus, podemos emitir comandos de administração bem como realizar consultas sobre as bases-de-dados. Por exemplo, a consulta

SQL>select instance_name, status from v$instance;

permite-nos confirmar o SID da base-dados ao qual nos conectámos e o seu estado (STARTED, MOUNTED, OPEN).
Deixo aqui uma nota final sobre a conexão à base-de-dados com o auxílio do SQLPlus é efectuada a partir do anfitrião (máquina onde se encontra instalada a base-de-dados). Como podemos ver no capítulo Configuring Users, Groups and Environments for Oracle Database do Database Installation Guide, vários grupos são criados no servidor aquando da instalação e, em particular, o grupo ORA_DBA. Se executarmos o SQLPlus numa conta de utilizador que se encontre registada no grupo ORA_DBA (ver como acrescentar um utilizador a um grupo no Windwos Server aqui), é-nos suficiente emitir os comandos

>set oracle_sid=orcl
>sqlplus / as sysdba

para nos conectarmos à base-de-dados como adiministradores.
Se não proporcionarmos a palavra-chave, isto é, se fizermos

>sqlplus sys as sysdba

o programa força-nos a introduzi-la posteriormente. Esta opção é mais segura na medida em que o seu conteúndo não é imprimido no ecrã.

Encerramento e Inicialização

Apesar de ser obrigatório, à primeira vista, manter uma base-de-dados ligada indefinidamente, por vezes é necessário encerrá-la por motivos de manutenção. Assim, é útil compreender todos os estados em que uma determinada base-de-dados se pode encontrar. Veja-se, por exemplo, Starting Up and Shutting Down.
Existem quatro modos de encerramento de uma base-de-dados Oracle. Estes são

  1. Normal: Para encerrar a base-de-dados no modo normal é sufciente emitir o comando
    SQL>shutdown normal;

    no SQLPlus. Neste modo, a base-de-dados é encerrada apenas quando todos os utilizadores ligados fecharem as suas conexões, apesar de novas conexões serem recusadas. Convém notar que se algum utilizador não terminar a sua sessão, o encerramento não é finalizado.

  2. Imediato: Para encerrar a base-de-dados no modo imediato, emitimos o comando
    SQL>shutdown immediate;

    no SQLPlus. Neste modo, a base-de-dados é encerrada independentemente dos utilizadores que se encontram ligados, sendo todas as suas transacções anuladas (dados úteis possivelmente descartados).

  3. Transaccional: O comando
    >SQL>shutdown transactional;

    no SQLPlus permite encerrar a base-de-dados no modo transaccional. Este tipo de encerramento aguarda pela conclusão de todas as transacções (conjuntos de alterações que aguardam a conclusão da submissão para a base-de-dados) que se encontrem activas, apesar de nenhuma nova transacção ser permitida.

  4. Abortar: Por vezes é necessário abortar uma base-de-dados com o comando
    SQL>shutdown abort;

    Neste modo, a base-de-dados é imediamtamente encerrada podendo ser necessária uma recuperação dos ficheiros uma vez que estes poderão não se encontrar devidamente actualizados.

A inicialização de uma base-de-dados Oracle efectua-se em três fases, nomeadamente, STARTED, MOUNTED e OPEN. O comando

SQL>startup;

permite executar consecutivamente todas as fases, elevando a base-de-dados ao estado OPEN e tornando-a completamente funcional. Note-se que o SQLPlus continua a ligar-se à instância configurada mesmo quando esta se encontra encerrada. Neste estado, a base-de-dados aceita um conjunto limitado de comandos.
O comando

SQL>startup nomount;

permite elevar a base-de-dados ao estado de STARTED. Caso pretendamos passar ao estado MOUNTED teremos de utilizar o comando

SQL>alter database mount;

De seguida, se pretendermos disponibilizá-la, recorremos ao comando

SQL>alter database open;

Vemos que o startup é executado apenas uma vez, sendo as restantes elevações conseguidas por intermédio da instrução alter database. Se a base-de-dados se encontrar encerrada, é possível iniciá-la em qualquer um dos estados. Por exemplo,

SQL>startup mount;

permite iniciar a base-de-dados no modo MOUNTED, passando automaticamente pelo modo STARTED.

Os ficheiros spfile e controlfile

Para termos uma ideia do que acontece em cada um dos estados de inicialização, é conveniente percebermos o propósito de dois ficheiros fundamentais, nomedamente o spfile (Server Parameter File) e o control file. O comando no SQLPlus

SQL>create pfile='...\Desktop\pfile_orcl.ora' from spfile

cria um ficheiro denominado pfile_orcl.ora na directoria ...\Desktop. Se editarmos o ficheiro com um editor detexto como o notepad++ verificamos que este contém uma lista de parâmetros e respectivos valores que parametrizam a instância durante a sua inicialização. Este formato era utilizado para parametrizar bases-de-dados em versões antigas. O spfile constitui uma evolução do mesmo e não pode ser alterado com um auxílio de um editor de texto. Entre estes encontra-se definido o parâmetro control_files, definindo a localização dos ficheiros de controlo (uma ou mais cópias). O ficheiro spfile consiste, portanto, num ficheiro de servidor onde estão persistidas as configurações associadas a uma determinada instância. Para consultar a directoria onde o ficheiro de inicialização se encontra, podemos emitir o comando no SQLPlus

SQL>show parameter spfile;

A instrução

SQL>show parameter;

permite obter o valor de todos os parâmetros configuráveis na base-de-dados. O comando

SQL>startup pfile='...\Desktop\pfile_orcl.ora'

permite iniciar a base-de-dados configurada pelos parâmetros definidos no ficheiro pfile_orcl.ora. Encontrando-se a base-de-dados inicializada com um pfile, é possível criar um ficheiro spfile com o comando

SQL>create spfile from pfile;

Assim, um ficheiro spfile é criado na directoria que está definida para conter este tipo de ficheiros. De um modo geral, é possível criar um ficheiro spfile a partir de um pfile com a ajuda da instrução

SQL>create spfile='...\Desktop\spfile_orcl.ora' from pfile='...\Desktop\pfile_orcl.ora';

e também um ficheiro pfile a partir de um spfile com

SQL>create pfile='...\Desktop\pfile_orcl_created.ora' from pfile='...\Desktop\spfile_orcl.ora';

Se pretendermos inicializar a base-de-dados, importando os parâmetros de um ficheiro do tipo spfile que se encontre numa localização diferente da definida, por exemplo, …\Desktop\spfile.ora,
criamos um ficheiro …\Desktop\pfile_orcl.ora com a linha
SPFILE=’…\Desktop\spfile.ora’
e iniciamos a base-de-dados com

SQL>startup pfile='pfile.ora';

Os parâmetros do spfile podem ser alterados no SQLPlus com o auxílio da instrução “alter system”.
Verificámos atrás que um dos parâmetros explicitados no spfile contém o caminho para os ficheiros de controlo e como este parâmetro pode ser consultado, isto é,

SQL>show parameter control_files;

proporciona-nos essa lista. Os ficheiros de controlo contêm a informação sobre a estrutura física da base-de-dados, mantendo, por exemplo, o caminho para todos os ficheiros de dados que a constituem. Além desta informação, também lá se poderão encontrar os últimos registos de cópias de segurança efectuadas com o auxílio do RMAN.
É possível obter um script que nos permita criar um ficheiro de controlo da nossa base-de-dados. Para o efeito temos de determinar, em primeiro lugar, onde se encontra a directoria de rastreio da base-de-dados com a consulta

SQL>select value from v$diag_info where name='Default Trace File';

no SQLPlus. O comando

SQL>alter database backup controlfile to trace;

permite salvaguardar o ficheiro de controlo no ficheiro de rastreio actual. No final do ficheiro (à altura da execução do comando) deverá surgir o script que possibilita a construção de um ficheiro de controlo semelhante ao que se encontra na nossa base-de-dados. Verificamos que um ficheiro de controlo é criado com a base-de-dados em modo STARTED através do comando create controlfile. Como se pode observar, a criação manual de um ficheiro de controlo pode ser extensa, sendo aconselhável manter uma cópia de segurança regular destes ficheiros.
De um modo resumido, a inicialização da base-de-dados começa com a leitura do spfile para a obtenção da parametrização. A entrada na fase STARTED não requer a existência do ficheiro de controlo nem dos ficheiros de dados. Se este ficheiro não existir é nesta fase que deverá ser criado.
Na fase MOUNTED, tanto o ficheiro de controlo como os ficheiros de dados são carregados. A base-de-dados só passa ao estado OPEN se toda a estrutura física se encontrar livre de problemas.

Os ficheiros de dados

Os dados numa base-de-dados relacional, como é o caso da Oracle, são estruturados em forma tabular, sendo definidas restrições sobre as suas relações. Fisicamente, são armazenados em disco, fita ou outro tipo de dispositivo sob a forma de ficheiros. Neste motor, as tabelas que contêm os dados são logicamente agrupadas naquilo que recebe a designação de tablepsaces. Esta separação permite-nos apartar os metadados que descrevem as tabelas e a estrutura geral da base-de-dados dos dados físicos, bem como os dados físicos de acordo com a aplicação que os consome. Deste modo, é possível desligar um tablespace, mantendo ligados os outros. Além disso, é possível restringir os processos de savaguardas a este tipo de estruturas.
Dois tablespaces são criados aquando da criação da base-de-dados, nomeadamente, o SYSTEM e o SYSAUX, os quais não podem ser renomeados ou removidos. O primeiro contém os metadados que definem a estrutura da base-de-dados, isto é, contém os dicionários de dados. O segundo contém informação sobre os utilitários Oracle. Em adição aos tablespaces fundamentais, existem ainda os tablespaces temporários e os de undo. Os tablespaces temporários são utilizados pelo motor da base-de-dados para armazenar informação necessária para a execução de consultas. Apesar de uma base-de-dados funcionar sem conter nenhum tabelspace temporário, determinadas consultas deixarão de funcionar. Os tablespaces de undo contêm informação que permite reverter alterações à base-de-dados por motivos de consistência ou quando for emitido o comando ROLLBACK.
Para criar um tablepsace, utilizamos a instrução no SQLPlus

SQL>create tablespace lmtbsb datafile '...\Desktop\lmtbsb.dbf' size 50m extent management autoallocate;

Este comando permite criar um tablespace com um ficheiro associado iniciado com 50 MB de tamanho. A instrução EXTENT MANAGEMENT AUTOALLOCATE indica ao sistema que a reserva e libertação de espaço em disco é gerida pelo sistema.
Suponhamos, por exemplo, que pretendemos mover o ficheiro de dados associado ao tablespace para numa nova pasta. Tal é possível sem encerrar a base dados, desligando temporariamente o respectivo tablepsace. A lista de comandos é a seguinte:

SQL>alter tablespace lmtbsb offline normal;
SQL>alter tablespace lmtbsb rename datafile '...\Desktop\lmtbsb.dbf' to '...\Desktop\Data\lmtbsb.dbf':
SQL>alter tablespace lmtbsb online;

A primeira instrução permite-nos desligar o tablespace para podermos efectuar a respectiva alteração do nome do ficheiro, a qual é realizada com a emissão do segundo comando. A última linha permite disponibilizar novamente o tablespace. A gestão de tablespaces temporários e de undo é muito semelhante. De facto, as instruções

SQL>create temporary tablespace tmptbsp datafile '...\Desktop\tmptbsp.dbf' size 50m extent management autoallocate;
SQL>create undo tablespace undotbsp datafile '...\Desktop\undotbsp.dbf' size 50m extent management autoallocate;

permitem criar um tablespace temporário e um outro de undo, respectivamente. A lista de ficheiros por tablespace pode ser obtida com

SQL>select ts.name, df.file#, df.name from v$datafile df, v$tablespace ts where df.ts# = ts.ts#;

A lista proporcionada pela consulta não inclui os tablespaces temporários. Para os obter, é necessário emitir a consulta

SQL>select ts.name, tf.file#, tf.name from v$tempfile tf, v$tablespace ts where tf.ts# = ts.ts#;

A lista de ficheiros é útil no caso em que pretendemos estabelecer uma estratégia para cópias de segurança mas não temos o conhecimento de toda a estrutura física da base-de-dados.

Conexão remota e o Listener

Para podermos conectar-nos remotamente às bases-de-dados Oracle necessitamos dos programas de cliente. A sua instalação não oferece quaisquer desafios. Convém-nos apenas anotar a directoria escolhemos para Oracle_home. No Windows, esta directoria está definida na tabela dos registos. Para obtê-la, iniciamos o regedit e navegamos até à chave HKEY_LOCAL_MACHINE/SOFTWARE/ORALCE/OraDb11gHome1.
Vimos atrás como nos conectar a uma instância de base-de-dados a partir do anfitrião, isto é, a partir da máquina onde a instância se encontra alojada. Para o efeito, é suficiente definir a variável de ambiente oracle_sid com o valor do SID  associado à base-de-dados. O SID é um valor único dentro do mesmo sistema. Deste modo, todas as instâncias contidas no mesmo anfitrião possuem valores diferentes do SID. O comando

SQL> select instance from v$thread;

emitido no SQLPlus retorna-nos o valor do SID.
A consulta

SQL> show parameter service_names;

no SQLPlus permite-nos obter todos os serviços que estão registados na instância. Os serviços, bem como os SID, desempenham um papel importante nas conexões remotas.
Vimos que, para nos conectarmos à base-de-dados no anfitrião, fazemos, numa consola do sistema operativo do anfitrião,

>set oracle_sid=orcl
>sqlplus sys as sysdba

sendo depois introduzida a palavra-chave. Suponhamos agora que nos encontramos numa máquina diferente daquela onde se encontra alojada a base-de-dados à qual nos pretendemos conectar com o auxílio do SQLPLus. É evidente que teremos de especificar o endereço e a porta do anfitrião bem como o SID da base-de-dados à qual nos pretendemos conectar. Para o efeito, fazemos, na consola do sistema operativo onde nos encontramos,

>sqlplus sys@(description=(address=(protocol=tcp)(host=_._._._)(port=1521))(connect_data=(sid=orcl))) as sysdba;

O parâmetro host (anfitrião) contém o endereço de IP da máquina que contém a base-de-dados ou o nome do domínio que seja resolvido nesse mesmo endereço (note-se que o utilitário ping permite-nos obter o endereço de IP quando o nome no domínio é conhecido bem como o inverso se utilizarmos a opção -a). Se a base-de-dados estiver associada ao serviço orcl.local, podemos fazer

>sqlplus sys@(description=(address=(protocol=tcp)(host=_._._._)(port=1521))(connect_data=(service_name=orcl.local))) as sysdba;

para nos conectarmos remotamente.
As conexões assim definidas são muito extensas. Interessa-nos, pois, tornar o processo de conexão remota mais simples. Dois métodos poderão vir em nosso auxílio. O primeiro, recebe a designação de EZconnect (que soa como easy connect – conexão fácil). Esta tecnologia permite-nos conectar à nossa base-de-dados, registada com o serviço orcl.local com o auxílio do comando

>sqlplus sys/orcl@host:1521/orcl.local

Note-se que a palavra-chave terá de ser especificada ou então a conexão irá falhar.
O outro método requer a configuração das conexões num ficheiro engendrado para esse propósito que se encontra na directoria Oracle_home\network\admin. Criemos nesta directoria, caso não exista, um ficheiro de texto designado por tnsnames.ora e acrescentemos as linhas seguintes :

orcl_service =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = _._._._)(PORT = 1521))
)
(CONNECT_DATA =
(SID = orcl)
)
)

De seguida, na linha de comandos da consola, fazemos

>sqlplus sys@orcl_service as sysdba

Depois de introduzirmos a palavra-chave, encontramo-nos conectados. O ficheiro tnsnames.ora é utilizado pelos programas cliente para resolver o nome do serviço que passamos durante a conexão.

Convém neste ponto dar uma ideia do fluxo associado a um pedido de cliente. Todos os pedidos de conexão à base-de-dados são realizados por intermédio de um processo que se encontra em execução no anfitrião designado por Listener. Quando uma nova instância de base-de-dados é configurada no anfitrião, esta deverá ser registada num Listener de modo a possibilitar conexões de cliente. Nas versões superiores à 9i, o registo das instâncias é garantido por um processo que se encontra em execução, não sendo necessária qualquer configuração (as configurações estáticas dos serviços associados a um Listener são configuradas num ficheiro designado por listener.ora que se encontra na mesma directoria Oracle_home\network\admin). Para consultar quais são os serviços que estão registados nos Listeners, emitir o comando na consola do sistema operativo do anfitrião

>lsnrctl status

Como já foi referido atrás, a criação de uma base-de-dados durante a instalação do motor Oracle efectua a criação de um Listener. Caso essa opção não tenha sido tomada, é necessário proceder à sua criação com o auxílio do Oracle Net Configuration Assistant antes de proceder à criação da primeira instância, utilizando o Database Configuration Assistant.

O ficheiro de palavras-chave

Suponhamos que nos conectamos remotamente ao anfitrião com endereço IP _._._._ na porta por defeito 1521, assumindo que a palavra-chave para o utilizador sys é orcl com o serviço orcl.local registado,

>sqlplus sys/orcl@._._._.:1521/orcl.local

Aí, fazemos

SQL>shutdown immediate;
SQL>exit

Ora, a base-de-dados é, deste modo, desligada. Tentemos ligar-nos novamente à mesma instância que agora se encontra em baixo.

>sqlplus sys/orcl@._._._.:1521/orcl.local

Provavelmente iremos obter um erro a indicar que o listener não reconhece o serviço especificado. Isto deve-se ao facto do resgisto da base-de-dados efectuado no listener ser realizado automaticamente (ver serviço de registos). Quando a base-de-dados é desligada, o seu registo automático no listener é eliminado do mesmo modo. Para podermos continuar a conectar-nos à base-de-dados quando esta foi desligada, o serviço associado deverá encontrar-se configurado estaticamente no ficheiro listener.ora. Para registarmos estaticamente o serviço, começamos por parar o listener

>lsnrctl stop

Editamos o ficheiro listener.ora que se encontra na directoria Oracle_home\network\admin, acrescentando-lhe as linhas

SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(GLOBAL_DBNAME=orcl.local)
(ORACLE_HOME=[Oracle_home])
(SID_NAME=orcl)))

Observe-se que se trata de uma lista de listas de registos de SID. Se alguns outros SID se encontrarem registados, adicionar

(SID_DESC=
(GLOBAL_DBNAME=orcl.local)
(ORACLE_HOME=[Oracle_home])
(SID_NAME=orcl))

à lista SID_LIST. A variável GLOBAL_DBNAME deverá conter o nome global da base-de-dados e pode ser obtido por intermédio da consulta

SQL>select global_name from global_name

no SQLPlus quando a base-de-dados se encontra ligada. Agora, podemos voltar a tentar a ligação

>sqlplus sys/orcl@._._._.:1521/orcl.local

quando a nossa base-de-dados orcl se encontra desligada. Caso a nossa ligação não seja bem-sucedida devido a privilégios insuficientes, o problema encontrar-se-á certamente na ausência do ficheiro de palavras-chave.
De facto, quando nos conectamos remotamente a uma base-de-dados que foi desligada o nome de utilizador e a palavra-chave não podem ser comparados com os registos das tabelas internas uma vez que estas não se encontram disponíveis quando a base-de-dados se encontra nesses estado. Deste modo, é necessário criar um ficheiro de palavras-chave, com o auxílio da ferramenta orapwd,

>orapwd pwdfile.pwd entries=4 force=n ignorecase=n

Este comando permite-nos criar um ficheiro de palavras-chave com capacidade para quatro administradores na directoria corrente da consola. De modo a ser reconhecido pelo motor de bases-de-dados, este terá de se encontrar nas directorias especificadas na seguinte tabela.

Plataforma Nome obrigatório Localização requerida
UNIX and Linux orapwORACLE_SID ORACLE_HOME/dbs
Windows PWDORACLE_SID.ora ORACLE_HOME\database

Depois de criar o ficheiro na directoria correcta, é necessário sincronizar a palavra-chave do SYS com este ficheiro. Para o efeito, é suficiente emitir o comando no SQLPlus

SQL>alter user sys identified by nova_palavra_chave;

Esta alteração permite criar uma nova palavra-chave tanto no dicionário de dados como no ficheiro de palavras-chave. Se criarmos um utilizador

SQL>create nome_do_utilizador identified by palavra_chave_do_novo_utilizador;

podemos acrescentá-lo ao ficheiro de palavras-chave e ao dicionário como administrador com o comando

SQL>grant sysdba to nome_do_utilizador;

Se o utilizador já existia com privilégios de sysdba é necessário remover-lhe e voltar a adicionar-lhe o privilégio de modo a proceder à respectiva sincronização com a base-de-dados. Os comandos são

SQL>revoke sysdba from nome_do_utilizador;
SQL>grant sysdba to nome_do_utilizador;

Para obter uma lista de utilizadores listados no ficheiro, fazemos

SQL>select username from v$pwfile_users;

Resta, neste ponto, enfatizar o facto de que um ficheiro de palavras-chave pode ser partilhado por várias bases-de-dados. Para verificar se a base-de-dados se encontra a utilizar um ficheiro partilhado, fazer

SQL>show parameter remote_login_passwordfile;

Este parâmetro, que se encontra configurado no spfile admite três valores possíveis, nomeadamente, none, exclusive e shared. O primeiro, indica que a base-de-dados não possui ficheiro, o segundo indica que o ficheiro é exclusivo e o terceiro que se trata de um ficheiro partilhado. Apenas podemos acrescentar ou eliminar utilizadores do ficheiro caso este esteja no modo exclusivo. Para alterar para none o valor deste parâmetro, fazemos

SQL>alter system set remote_login_password=none scope=spfile;

Trata-se de uma parâmetro de configuração que surtirá efeito apenas quando a base-de-dados for reiniciada e, por isso, trata-se de um daqueles parâmetros que terá de ser configurado apenas ao nível do spfile.
Como nota final, o algoritmo de encriptação utilizado pela Oracle encontra-se descrito no livro Special Ops Host And Network Security For Microsoft, Unix, And Oracle. Apesar de alguns ataques poderem ser realizados, resultando em possíveis falhas de segurança associadas à publicação deste tipo de ficheiros, não iremos aqui debater o assunto. Convém utilizar, no caso de utilizadores com privilégios de administração, boas palavras-chave.

Os diários de arquivo – archive logs

A estrutura mais crucial no que concerne à recuperação da base-de-dados em caso de falha na instância são os designados por ficheiros redo. Estes ficheiros contêm as sucessivas alterações à medida que estas ocorrem. Para consultar que ficheiros do género estão associados à nossa base-de-dados, podemos fazer

SQL>select l.group#, l.sequence#, l.status, l.bytes/(1024 * 1024) || ' MB' as "Size", lf.member from v$log l, v$logfile lf where lf.group# = l.group#;

no SQLPlus. A consulta permite-nos obter os grupos e a sequência, estado e ficheiros associados a cada grupo. Para acrescentar um redo log, basta fazer

SQL>alter database add logfile('caminho_do_ficheiro') size 50M;

É possível acrescentar um membro ao grupo 1, por exemplo, com o comando

SQL alter database add logfile member 'caminho_do_novo_ficheiro' to group 1;

Para remover um membro, basta fazer

SQL>alter database drop logfile membmer 'caminho_do_ficheiro_a_remover';

À medida que a base-de-dados recebe actualizações, estas são registadas no grupo redo log cujo estado se encontra marcado com current – actual. Quando os ficheiros se encontram completos, o estado current move-se para o grupo seguinte e deixa o anterior no estado active – activo. Este movimento recebe a designação de log switch. Os grupos de redo log que estão no estado activos são necessários para a recuperação da base-de-dados em caso de falha de instância. A utilização de grupos é importante, na medida em que é possível gravar as alterações em várias localizações distintas, diminuindo a probabilidade de falha. Se pretendermos mudar o grupo actual, fazemos

SQL>alter system switch logfile;

Este comando permite mudar o estado de current para o grupo seguinte. A consulta acima permite verificar que agora o grupo anterior se encontra activo, isto é, continua a ser necessário pela base-de-dados. Se pretendermos colocá-lo como inactivo, fazemos

SQL>alter system checkpoint;

Esta instrução permite forçar a escrita da informação que se encontra em memória e nos ficheiros redo para os ficheiros de dados. Se uma instância colapsar um instante após a realização de um checkpoint, a sua recuperação, em caso de falha, irá requerer apenas os ficheiros de dados. Ver, por exemplo, How to change the Redo Log File size in Oracle Database, onde é apresentado um processo para alteração do tamanho dos ficheiros sem desligar a instância.

Relativamente a este tipo de ficheiros de diário, ou log, a instância pode-se encontrar configurada para executar em um dos dois modos. Estes são o modo NOARCHIVELOG e o modo ARCHIVELOG. No primeiro modo, a escrita da informação de redo é realizada alternadamente sobre os grupos. Se um grupo se encontrar cheio, o processo passa a escrever no próximo ficheiro, mesmo que este ainda se encontre no estado activo. No segundo modo, os vários ficheiros activos de redo são arquivados em ficheiros designados por archive logs. Para verificarmos em que modo se encontra a instância, podemos fazer, no SQLPlus,

SQL>archive log list;

ou

SQL>select log_mode from v$database;

A alteração da base-de-dados de um destes estados para o outro requer que seja efectuada uma cópia de segurança (backup). Suponhamos que a instância se encontra configurada no modo NOARCHIVELOG e pretendemos alterar o seu estado para o modo ARCHIVELOG. Em primeiro lugar, efectuamos uma cópia de segurança. Depois fazemos

SQL>alter system set log_archive_dest_1='caminho_para_o_primeiro_arquivo' scope = spfile;
SQL>alter system set log_archive_dest_2='caminho_para_o_segundo_arquivo' scope = spfile;

que configura ambos os parâmetros log_archive_dest_1 e log_archive_dest_2 no spfile. De seguida, desligamos a instância e inciamo-la no estado mount:

SQL>shutdwon immediate;
SQL>startup mount;

Alteramos o estado da base-de-dados com

SQL>alter database archivelog;

e abrimo-la

SQL>alter database open;

Neste ponto é importante realizar uma nova cópia de segurança. Para colocar a base-de-dados em NOARCHIVELOG, é suficiente colocar a base-de-dados no estado mount, alterar o estado e depois abri-la:

SQL>shutdwon immediate;
SQL>startup mount;
SQL>alter database noarchivelog;
SQL>alter database open;

Note-se que, em ambos os casos, é importante ter em mente que deverão ser realizadas uma cópia de segurança antes e depois de alterar o modo de arquivo dos diários.

Criação e eliminação de instâncias de base-de-dados

A criação de novas instâncias de bases-de-dados podem ser realizadas de duas maneiras. A mais complicada consiste em criar manualmente todos os elementos necessários ao funcionamento de uma base-de-dados com o auxílio de comandos. Este método requer, contudo, um conhecimento demasiado profundo do funcionamento do sistema. Deste forma, a Oracle disponibiliza a ferramenta Oracle Database Configuration Assistant. Se nenhum listener se encontrar configurado, é necessário proceder à criação de um com o Oracle Net Configuration Assistant. Ambas as ferramentas encontram-se disponibilizadas sob o submenu todos os programas do menu iniciar. O Oracle Database Configuration Assistant permite também remover instâncias de bases-de-dados.
Convém notar que a desinstalação de uma uma instância poderá não remover todos os ficheiros. É necessário, portanto, eliminá-los manualmente. Entre estes, encontram-se os ficheiros de dados, diários, ficheiros de palavras-chave, entradas nas configurações do listener, entre outros. Por vezes é conveniente desinstalar o Enterprise Manager, caso este tenha sido instalado, com o auxílio do emca. É difícil remover instâncias sem deixar para trás grandes quantidades de lixo. Assim, é conveniente manter instâncias definitivas em ambientes de produção e criar instâncias de teste em ambientes que poderão ser completamente reconstruídos mais tarde.

Sobre Sérgio O. Marques

Licenciado em Física/Matemática Aplicada (Astronomia) pela Faculdade de Ciências da Universidade do Porto e Mestre em Matemática Aplicada pela mesma instituição, desenvolvo trabalho no PTC (Porto Technical Centre) - Yazaki como Administrador de bases-de-dados. Dentro o meu leque de interesses encontram-se todos os temas afins às disciplinas de Matemática, Física e Astronomia. Porém, como entusiasta, interesso-me por temas relacionados com electrónica, poesia, música e fotografia.
Esta entrada foi publicada em Computadores e Internet com as etiquetas , , , , . ligação permanente.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s