Você está na página 1de 13

Administração de bases-de-dados Oracle

11g (Básico)
Publicado em 27 de Maio de 2015por Sérgio O. Marques

Depois de adquirir alguma experiência na área de administração de bases-de-


dados Oraclee, 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
1sysdba
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),
1>set oracle_sid=orcl
>sqlplus sys/orcl as
2sysdba
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
1v$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
1oracle_sid=orcl
2>sqlplus / as
sysdba
para nos conectarmos à base-de-dados como adiministradores.
Se não proporcionarmos a palavra-chave, isto é, se fizermos

>sqlplus sys as
1sysdba
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
1normal;
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
1immediate;
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
1transactional;
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
1abort;
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
1;
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
1nomount;
permite elevar a base-de-dados ao estado de STARTED. Caso pretendamos passar ao estado
MOUNTED teremos de utilizar o comando
SQL>alter database
1mount;
De seguida, se pretendermos disponibilizá-la, recorremos ao comando

SQL>alter database
1open;
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
1mount;
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
1spfile
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 spfileconsiste, 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
1spfile;
A instrução

SQL>show
1parameter;
permite obter o valor de todos os parâmetros configuráveis na base-de-dados. O comando

SQL>startup
1pfile='...\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
1pfile;
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
1pfile='...\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
1pfile='...\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
1pfile='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
1control_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
1File';
no SQLPlus. O comando
SQL>alter database backup controlfile to
1trace;
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 spfilepara 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
1management 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:
1SQL>alter tablespace lmtbsb offline normal;
SQL>alter tablespace lmtbsb rename datafile '...\Desktop\lmtbsb.dbf' to
2'...\Desktop\Data\lmtbsb.dbf':
3SQL>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
1extent management autoallocate;
2SQL>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#
1= 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#
1= 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
1v$thread;
emitido no SQLPlus retorna-nos o valor do SID.
A consulta
SQL> show parameter
1service_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,
1>set oracle_sid=orcl
>sqlplus sys as
2sysdba
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))
1(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))
1(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
1sys/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 :
1orcl_service =
2(DESCRIPTION =
3(ADDRESS_LIST =
4(ADDRESS = (PROTOCOL = TCP)(HOST = _._._._)(PORT =
1521))
5)
6(CONNECT_DATA =
7(SID = orcl)
8)
9)
De seguida, na linha de comandos da consola, fazemos

>sqlplus sys@orcl_service as
1sysdba
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
1status
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
1sys/orcl@._._._.:1521/orcl.local
Aí, fazemos

1SQL>shutdown
immediate;
2SQL>exit
Ora, a base-de-dados é, deste modo, desligada. Tentemos ligar-nos novamente à mesma instância
que agora se encontra em baixo.
>sqlplus
1sys/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
1stop
Editamos o ficheiro listener.ora que se encontra na directoria Oracle_home\network\admin,
acrescentando-lhe as linhas
1SID_LIST_LISTENER=
2(SID_LIST=
3(SID_DESC=
(GLOBAL_DBNAME=orcl.local)
4(ORACLE_HOME=[Oracle_home]
5)
6(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

1(SID_DESC=
2(GLOBAL_DBNAME=orcl.local)
(ORACLE_HOME=[Oracle_home]
3)
4(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


1global_name
no SQLPlus quando a base-de-dados se encontra ligada. Agora, podemos voltar a tentar a ligação
>sqlplus
1sys/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
1ignorecase=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


1nova_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
1palavra_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
1nome_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
1SQL>revoke sysdba from
nome_do_utilizador;
2SQL>grant sysdba to nome_do_utilizador;
Para obter uma lista de utilizadores listados no ficheiro, fazemos

SQL>select username from


1v$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
1remote_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
1scope=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",
1lf.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
150M;
É 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


11;
Para remover um membro, basta fazer

SQL>alter database drop logfile membmer


1'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
1logfile;
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
1checkpoint;
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
1list;
ou

SQL>select log_mode from


1v$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 =
1spfile;
2SQL>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:
1SQL>shutdwon
immediate;
2SQL>startup mount;
Alteramos o estado da base-de-dados com

SQL>alter database
1archivelog;
e abrimo-la

SQL>alter database
1open;
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:
1SQL>shutdwon immediate;
2SQL>startup mount;
SQL>alter database
3noarchivelog;
4SQL>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.