Oracle 8i: Backup e Recovey

SOLUÇÕES DA ORACLE
Features do Oracle para aumentar a disponibilidade do banco de dados:
- Oracle Parallel Server: múltiplas instâncias pertencem lêem mesmo BD. Quando
uma instância falha, a outra assume e a centralização é feita por um cluster;
- Oracle FailSafe: somente para plataforma NT. Dois nós dividem os mesmos
discos e somente um nó fica ativo; quando o nó ativo cai, o outro nó assume

CONFIGURAÇÕES
Large Pool
A large pool é uma área de memória que é usada durante o backup pelos IO slaves.
Ela é configurada por LARGE_POOL_SIZE no arquivo de parâmetros. Deve-se
sempre configurá-la se for usado IO slaves (configurados no arquivo de parâmetros
com DBWR_IO_SLAVES ou BACKUP_TAPE_IO_SLAVES). Quando esta área
não for especificada, os buffers da shared pool serão usados. Se ela for especificada
mas for subdimensionada, um comando RMAN é escrito no alert file e não serão
usados IO slaves na operação.
Na V$SGASTAT, pode-se checar o tamanho definido pra large pool.
Os parâmetros a configurar são:
- DBWR_IO_SLAVES: é o número de DBWn que serão criados. Se este
parâmetro for configurado para um valor diferente de zero, o número de IO slaves
usados pelos processos ARCn, LGWR e recovery manager será quatro.
- BACKUP_TAPE_IO_SLAVES: especifica se serão usados IO slaves pelo
recovery manager para bakup, copy ou restore dados para fita. Aceita valor
TRUE ou FALSE.

BACKUP DO CONTROL FILE

Há dois modos de fazer backup do control file on-line.
1- Cria uma cópia binária do control file:
alter database backup controlfile to ‘<nome do arquivo.bkp>’;
2- Cria um script para criar o control file
alter database backup controlfile to trace;
Para fazer backup do control file offline, é só fazer uma cópia física deste.
É importante, de qualquer forma, que o control file seja duplexado (no parâmetro
CONTROL_FILES).
No momento de fazer restore, este backup do control file deve estar situado no
diretório definido pelo parâmetro control_files do arquivo de parâmetros init.ora.

ARCHIVELOG MODE
Configuração
 Localização e formatação dos archive log files
 LOG_ARCHIVE_DEST = <string com a localização default dos archive log
files>

NOTA
Este parâmetro não pode se referir a um raw device!

LOG_ARCHIVE_FORMAT = <o nome default do archive com %s, para o

número de log sequence e/ou %t, para o número de thread>. Exemplo:
LOG_ARCHIVE_FORMAT = arch%s.arc

 Duplexação de archive log files

Há dois métodos e eles são mutuamente exclusivos:
1- LOG_ARCHIVE_DUPLEX_DEST = <nome do arquivo com %s ou %S ou
nome do device>.

NOTA
Este parâmetro não pode se referir a um raw device!

2- LOG_ARCHIVE_DEST_n, onde n é um número inteiro variando de 1 a 5:

Pode ser referente a um diretório local através de “LOCATION = <diretório
local>” ou um diretório remoto através de “SERVICE=<alias para um banco
remoto presente no TNSNAMES.ORA>”.
Pode-se fazer com que a gravação do archive log seja mandatório ou obrigatória.
Se, após os parâmetros acima, inserir-se a key word OPTIONAL, o diretório será
opcional e, caso ocorra erro na gravação do archive log anteriormente, os archive
logs posteriores continuarão a ser gravados nessa localização. Caso se insira a key
word MANDATORY, o arquivamento para esta localização deve ser com sucesso
para que o redo log file online possa ser sobreescrito. Após a key word
MANDATORY, pode-se ainda adicionar a key word REOPEN que corresponde
ao número de segundos após os quais se fará retry em caso de falha.
Exemplo:

Log_archive_dest_1 = “LOCATION = /archive MANDATORY REOPEN”

NOTA
Caso ocorra erro na gravação do archive log será registrado no arquivo de
alert.

Caso se opte por utilizar LOG_ARCHIVE_DEST_n, ainda há o parâmetro

LOG_ARCHIVE_MIN_SUCCEED_DST onde se insere o número mínimo de
localizações mandatórias, isto é, caso este parâmetro assuma valor 3 e há somente
2 saídas mandatórias, ao menos uma saída opcional será considerada mandatória.

Da mesma forma, pode-se inabilitar a armazenagem de archive logs para um

destino através do parâmetro LOG_ARCHIVE_DEST_STATE_n (assumindo
valores DEFER e ENABLE) e isso serve para quando ocorre erro em um destino e
este fica inabilitado até que se corrija o problema. Este parâmetro é dinâmico.
 LOG_ARCHIVE_MAX_PROCESSES = número máximo de processos para
archive (limite de 10)
 LOG_ARCHIVE_START = TRUE|FALSE
É um parâmetro dinâmico que pode ser alterado por
alter system archive log start to ‘/archive’;
Desta forma, configura-se o archive para automático.
Caso queira que o archive seja manual, este parâmetro deve assumir valor FALSE e
deve-se digitar o seguinte comando, por exemplo:
alter system archive log sequence 052;

Procedimentos
Inserir o commando abaixo quando o banco estiver em modo mount:
alter database archivelog;
Para checar, digitar
archive log list;
Se foi habilitado vários processos de archive, pode-se alterar a quantidade de
processos de acordo com a quantidade de trabalho, conforme demonstram os
comandos abaixo:
alter system set LOG_ARCHIVE_MAX_PROCESSES = 3;

Monitoramento
SELECT name, thread#, sequence#, archived,
completion_time
FROM v$archived_log;

SELECT destination, binding, target, status

FROM v$archive_dest;
Neste caso, o status INACTIVE indica que a destination não foi especificada.

SELECT destination, fail_sequence, error

FROM v$archive_dest
WHERE status = ‘ERROR’;

SELECT *
FROM v$archive_processes;

SELECT *
FROM v$backup;

SELECT name, status, fuzzy “Estah em backup?”

FROM v$datafile_header;

Como fazer o backup

Se o seu banco está em archivelog mode, vc tem a possibilidade de fazer um backup
frio ou quente.
 Backup quente

Colocar o data file ou tablespace em modo backup:

1 Alter tablespace user_data begin backup;
2 Usar um utilitário do SO para fazer a cópia física dos data files da tablespace
Retirar o data file ou tablespace de modo backup:
3 Alter tablespace user_data end backup;
4 Alter system switch logfile;

 Backup frio

1 Dar um shutdown no banco (normal, immediate ou transaction)

Usar um utilitário do SO para fazer a cópia física dos datafiles (incluindo
2 datafile referente a segmento rollback e temporário), redo log files, control
files, parameter files, e password file
3 Restarta a instância.

NOARCHIVELOG MODE
Como fazer o backup
O único backup que pode ser feito é o backup frio.

 Backup frio

1 Dar um shutdown no banco (normal, immediate ou transaction)

Usar um utilitário do SO para fazer a cópia física dos datafiles (incluindo
2 datafile referente a segmento rollback e temporário), redo log files, control
files, parameter files, e password file
3 Restarta a instância.

CASOS PARA CADA CONFIGURAÇÃO

Instance Failure
Situação: Ocorre quando há falha de energia do servidor ou ocorre um problema de
hardware tipo falha de CPU ou um dos background processes falha.
Reflexo no banco: a instância cai.
Ação: dar startup no banco e deixar ele fazer o recovery. Os dados inseridos não
commitados são perdidos. Examinar o alert para ver a causa da falha.

Media Failure
 NoArchiveLog Mode
É necessário que exista um backup válido e isto corresponde a um backup de data
files, control files e redo logs (os arquivos de password e parameter só precisam
ser recuperados se eles foram perdidos)

1 Dar um shutdown no banco (abort)

Usar um utilitário do SO para fazer a cópia física dos data files, redo log files,
2
control files, parameter files(opcional), e password file (opcional)
3 Restarta a instância.

Caso nenhum redo log file foi sobreescrito, não é necessário fazer o recover acima
mas sim um recover manual:

 ArchiveLog Mode

Caso 1: com o banco em MOUNT

Garantir que os arquivos que serão sobreescritos não estão abertos (através da
1
v$datafile e v$tablespace)
Usar um utilitário do SO para fazer a cópia física do arquivo que foi danificado
2
sem restaurar os redo log files que estão online.
3 Colocar o banco em MOUNT ou OPEN

4 Usar o comando recover.

Por
Caso 2: com o banco OPEN, inicialmente OPEN
Checar a que tablespace pertence o arquivo danificado e, se for de uma
1 tablespace diferente da SYSTEM, obter o nome do arquivo correspondente.
Colocar o arquivo/tablespace correspondente offline, se ele já não o estiver.
Usar um utilitário do SO para fazer a cópia física do arquivo que foi danificado
2
sem restaurar os redo log files que estão online.
Usar o comando recover. (recover datafile ‘<arquivo>’ ou recover tablespace
3
<ts>)
4 Colocar o arquivo/tablespace online.

Caso 3: com o banco OPEN, inicialmente CLOSED

1 Starta em MOUNT o banco

Checa o arquivo que foi danificado. Este arquivo deve ser colocado offline.
2 Por exemplo, ALTER DATABASE DATAFILE
‘/users/dba00/u01/user01.dbf’ OFFLINE;
 3 Abre o banco.
Usar um utilitário do SO para fazer a cópia física do arquivo que foi
danificado. Se o problema foi com a controladora, restaurar o arquivo para
4 outra localização. Sendo este o caso, entrar o comando: alter database
rename file ‘<arquivo com antiga localização>’ to ‘<arquivo com
nova localização>’;

5 Recuperar o arquivo ou tablespace referente ao arquivo.

RECOVER TABLESPACE USER_DATA;
Por exemplo,

6 Colocar o arquivo/tablespace online

Caso 4: perda do arquivo que não tinha backup (não da tablespace SYSTEM
ou rollback)
1 Starta em MOUNT o banco
2 Colocar o arquivo offline.
Confirma que o arquivo está realmente offline e perdido através de SELECT *
3
FROM v$recover_file;
Recria o arquivo através de: alter database create datafile ‘<antigo arquivo>’ as
4
‘<novo arquivo>’
Recheca na v$recover_file se o erro “File not found” sumiu e faz recover da
5
tablespace referente: recover tablespace <nome da ts>;
6 Colocar o arquivo/tablespace online

Exemplos:

Startando o banco com datafiles faltando

 STARTUP MOUNT;
 ALTER DATABASE DATAFILE ‘/users/dba00/u01/user01.dbf’
OFFLINE;
 ALTER DATABASE OPEN;
 Restaura a cópia física
 RECOVER TABLESPACE USER_DATA;
 ALTER TABLESPACE USER_DATA ONLINE;

Perda de tablespaces não essenciais (TEMP e INDEX)

 Starta a instância, se for necessárioe coloca em MOUNT
 SELECT b.NAME, a.ONLINE, a.ERROR, a.CHANGE#
FROM V$RECOVER_FILE a, V$DATAFILE b
WHERE a.FILE# = b.FILE#;
 ALTER DATABASE DATAFILE ‘/users/dba00/u01/indx01.dbf’
OFFLINE DROP;
 ALTER DATABASE OPEN;
 Para a tablespace temporária: SELECT * FROM V$TABLESPACE;
DROP TABLESPACE <nome>
CREATE TABLESPACE <nome> DATAFILE ‘<datafile>’ SIZE <tamanho>;
 Para a tablespace de indices: SELECT * FROM V$TABLESPACE;
Ver as primary keys que deverão ser inabilitadas:
SELECT pk.OWNER,
pk.CONSTRAINT_NAME,
pk.CONSTRAINT_TYPE,
pk.TABLE_NAME,
fk.OWNER,
fk.CONSTRAINT_NAME,
fk.CONSTRAINT_TYPE,
fk.TABLE_NAME
FROM dba_constraints pk, dba_constraints fk
WHERE pk.constraint_name = fk.r_constraint_name(+)
AND pk.table_name in (SELECT table_name
FROM dba_indexes
WHERE tablespace_name = ‘INDX’)
AND pk.constraint_type = ‘P’;
ALTER TABLE <owner>.<tabela> DISABLE PRIMARY KEY CASCADE;
DROP TABLESPACE <nome> INCLUDING CONTENTS CASCADE CONSTRAINTS;
CREATE TABLESPACE <nome> DATAFILE ‘<datafile>’ SIZE <tamanho>;
ALTER TABLE <owner>.<tabela> ENABLE PRIMARY KEY USING INDEX
TABLESPACE <nome>;
ALTER TABLE <owner>.<tabela> ENABELA CONSTRAINT <constraint>;
 Fazer um backup off-line full, se necessário

 Incomplete Recovery for Archivelog Mode (only)

Time-based recovery
Recover database until time ‘<yyyy-mm-dd:hh:mi:ss>’;
1 Checar o alert log anter e depois do recovery
2 Dê shutdown no banco (immediate, transactional ou normal)
3 Coloque o banco em MOUNT
4 Faça a cópia física dos arquivos .dbf
5 Coloque os archive logs necessário no diretório especificado por LOG_ARCHIVE_DEST
ARCHIVE SYSTEM ARCHIVE LOG START TO <localização>)
6 Recover database until time ‘<data-hora>’;
7 Alter database open resetlogs;
8 Checar se o backup recuperou o que foi perdido
9 Dar shutdown e fazer um backup full (porque mudou a incarnation)
LogMnr ajuda a verificar a hora exata do erro.
Cancel-based recovery
Recover database until cancel;
1 Dê shutdown no banco (immediate, transactional ou normal)
2 Coloque o banco em MOUNT
3 Faça a cópia física dos arquivos .dbf
4 Recover database until cancel;
5 Alter database open resetlogs;
6 Checar se o backup recuperou o que foi perdido
7 Dar shutdown e fazer um backup full (porque mudou a incarnation)
Este tipo de recover é feito se não se tem todos os archive logs e se tem problema em um redo log e t
que se parar quando se alcança o último archive log disponível. Pode-se checar os archive log atrav
da v$log_history. Dados serão perdidos e o momento inicial de perda é checado
v$log_history.first_time
 Recovery using a backup control file
Recover database until time ‘<yyyy-mm-dd:hh:mi:ss>’ using backup controlfile;
1 Checa aonde está o backup do controlfile (binary) que contém a informação do segmento (cuida
para não ser um controlfile ultrapassado!)
2 Confirma a hora que dropou o segmento no alert log
3 Dá shutdown no banco e faz a cópia dos arquivos backup.
4 Abra o banco (ocorrerá erro indicando falta de sincronia entre o redo log e control file)’
5 Verifica se tem algum arquivo offline; em caso afirmativo, colocar online
6 Recover datatabase until time ‘yyyy-mm-dd:hh:mm:ss’ using backup controlfile;
7 Alter database open resetlogs;
Este tipo de recovery é pra quando se apaga um segmento (uma tablespace, por exemplo) e se quer fa
recovery dela mas ela não existe.
Change-based recovery
Recover database until scn <integer>;

OTIMIZAÇÃO DE PERFORMANCE
FAST_START_IO_TARGET
Este parâmetro corresponde ao número de operações de IO que são feitas para
recovery. Deve-se configurar este parâmetro caso o tempo para recovery (de instance
failure e crash recovery) seja crucial. A consequência da configuração deste
parâmetro é um aumento (ou diminuição) na frequência de checkpoints.

FAST_START_PARALLEL_ROLLBACK
Este parâmetro assume os valores FALSE, LOW (2*CPU_COUNT) e HIGH
(4*CPU_COUNT) onde o valor LOW é o default.
Com a configuração deste parâmetro, o SMON irá usar parallel query slaves para
completar a operação de rollback.
Para monitorar a operação, pesquisar a view v$fast_start_servers e/ou a view
v$fast_start_transactions.

RECOVERY_PARALLELISM
Este parâmetro define o número de processos de recovery que serão usados e, caso
não seja especificado durante o comando recover, será este valor que será usado.
Este valor não pode exceder o valor de PARALLEL_MAX_SERVERS.
Este processo recovery é o que liga o server process ao data file, sincronizando o
banco.

PROBLEMAS COM REDO LOG FILE

Se o redo log file corrente ficou corrompido enquanto o banco estava aberto, utilizar o
seguinte comando:
Alter database clear logfile;

NOTA
Deve-se realizar um backup full logo após esse comando..

Se houverem data files que estão offline mas requerem o redo log file, utilizar o
comando:
Alter database clear logfile <nro> unrecoverable
datafile;
Os data files que requerem este log file firarão inutilizáveis após esse comando. Estes
datafiles devem, então, ser eliminados.
Se você perder redo log files que não estão ativos checar se o redo log foi arquivado.
Em caso afirmativo, a única ação é deletá-lo e recriá-lo (nenhuma informação foi
perdida). O comando SELECT * FROM v$logfile me informa o nome do
arquivo referente ao grupo. O comando alter database drop logfile
group <nro> elimina o log file inválido.

EXPORT E IMPORT
Pode-se utilizar Export e Import para complementar a operação normal de backup.

Tipos de export
Table Mode User Mode Tablespace Full Database
Mode Mode
Definição de tabelas Definição de Definição de Definição de
tabelas tabelas tabelas
Dados de tabela ou Dados de tabelas Dados de tabelas
linhas selecionadas
Grants fornecidos pelo Grants fornecidos Grants Grants
owner da tabela pelo owner da
tabela
Índices criados pelo Índices criados Índices Índices
owner da tabela pelo owner da
tabela
Constraints da tabela Constraints da Constraints da Constraints da
tabela tabela tabela
Triggers

* Full database mode não exporta objetos no schema SYS.

A linha de comando para export é via command line do SO.

Exemplo: exp system/manager FULL=y inctype=cumulative

file=expcum1.dmp

Parâmetros de export
Parâmetro Descrição
USERID Username/Password dos objetos
do schema para exportar
FILE Nome do arquivo de saída
ROWS Inclui linhas da tabela no modo
de exportação? (Yes/No)
FULL Exporta todos os objetos?
 (Yes/No)
OWNER Usuários para exportas: username
TABLES Tabelas para exportar: lista de
tabelas
TRIGGERS Indica se as informações
associadas a triggers serão
exportadas
CONSTRAINTS Indica se as informações
associadas a constraints serão
exportadas
INDEXES Exportar índices? Yes/No
DIRECT Tipo de exportação Direct mode:
Yes/No
INCTYPE Tipo de nível de export:
cumulative/complete/incremental
PARFILE Nome do arquivo onde os
parâmetros de export estão
especificados
HELP Mostra os parâmetros de
exportação em modo interativo
LOG Nome do arquivo que
armazenará as mensagens de erro
CONSISTENT Congela a tabela (read-
consistency) quando exporta?
Yes/No
BUFFER Tamanho do buffer de dados em
bytes
TRANSPORT_TABLESPACE Habilita o metadados de
exportação de transportable
tablespace
TABLESPACES Tablespaces para serem
transportadas
POINT_IN_TIME_RECOVER Indica se o utilitário de export
exporta uma ou mais tablespaces
em um banco Oracle (só para
versão 8.0)
RECOVERY_TABLESPACES Especifica as tablespaces que
serão recuperadas com a
utilização de point-in-time
recovery (só para versão 8.0)
COMPRESS Especifica se todo o dado será
incluído em somente um extent

Antes de se usar o direct-path (com a string direct=true), deve-se executar o script

catexpt.sql.
Quando se usa direct-path, deve-se atentar para a configuração de caracter. O characer
set do lado do cliente deve corresponder ao character set do lado do servidor (variável
NLS_LANG). O parâmetro BUFFER não tem nenhum efeito quando se está
trabalhando dom direct-path e não se pode usar direct-path quando se está trabalhando
com BFILE, REF ou colunas do tipo objeto incluindo VARRAY e nested tables.
Esquema de Export incremental:

2a feira

3a feira

4a feira

5a feira

6a feira
COMP I I I CUM

Tipos de import
Table Mode User Mode Tablespace Full Database
Mode Mode
Importa tabelas Importa todos os Importa todas as Importa todos os
específicas do schema objetos que definições de objetos do arquivo
pertencem ao objetos que estão de exportação
schema contidos na (exceto do schema
tablespace (move SYS)
uma tablespace
de um banco para
outro)

Exemplo: imp system/manager FROMUSER=scott file=expincr1.dmp

Parâmetros de export
Parâmetro Descrição
USERID Username/Password dos objetos do schema para
exportar
FILE Nome do arquivo de saída
ROWS Inclui linhas da tabela no modo de importação?
(Yes/No)
IGNORE Ignora os erros de criação devido a inexistência de
um objeto
FULL Importa o arquivo inteiro? (Yes/No)
TABLES Tabelas para importar: lista de tabelas
INDEXES Importar índices? Yes/No
INCTYPE Tipo de import incremental (System/Restore)
PARFILE Nome do arquivo onde os parâmetros de import
estão especificados
HELP Mostra os parâmetros de importação em modo
interativo
LOG Nome do arquivo que armazenará as mensagens
de erro
DESTROY Especifica se o datafile existente deverá ser
reutilizado
FROMUSER Uma lista de schemas contendo os objetos para
importação
TOUSER Especifica uma lista de usernames que terão seus
 schemas importados
INDEXFILE Especifica o arquivo que receberá o comando de
criação dos índices
TRANSPORT_TABLESPACE Instrui o import a importar metadados de uma
transportable tablespace de um arquivo export
TABLESPACES Lista de tablespaces para serem transportadas para
o banco de dados
DATAFILES Lista de datafiles que serão transportados para o
banco de dados
TTS_OWNERS Lista de usuários que possuem dados dentro do
conjunto de tablespaces
POINT_IN_TIME_RECOVERY Indica se o utilitário de Import fará recover de uma
ou mais tablespaces para um período anterior sem
afetar o resto do banco (somente para versão 8.0)

Não são sincronizadas

com os archive logs!

Novas tabelas são INDEXES = Y

criadas Se colocar INDEXES = N posterga a
criação dos índices poupango
segmento rollback necessário para
o import

São construídas as
estruturas dos
índices
ROWS = Y

A ordem de importação
Os dados são das tabelas pode ser
importados para as importante caso não se
tabelas importe todos os
objetos do usuário.

São importados os triggers e

integridade referencial é
habilitada nas novas tabelas

Exportando transportable tablespace

1 Alter tablespace sales_ts read only;
2 Exp ‘system/manager as SYSDBA’ TRANSPORT_TABLESPACE=y FILE=md.dmp
TABLESPACES=(ts_emp) LOG=ts_emp.log TRIGGERS=n CONSTRAINTS=n
3 Fazer uma cópia via SO do(s) arquivo(s) da tablespace (datafiles)
4 Fazer uma cópia via SO do arquivo md.dmp (definido no parâmetro FILE)
Importando transportable tablespace
1 Imp ‘/ as sysdba’ FILE = md.dmp TRANSPORT_TABLESPACE=y
DATAFILES=(/disk1/sales01.dbf,/disk2/sales02.dbf)
2 Alter tablespace sales_ts read write;
* Este tipo de importação e exportação pode ser útil para backup. Porém, quando a
tablespace for importada, ela não pode já existir. Desta forma, se um objeto de uma
tablespace for erroneamente dropado, por exemplo, o procedimento é dropar a tablespace e
fazer um import desta.
A view PLUGGABLE_SET_CHECK captura as referências que não estão contidas
totalmente em um tablespace e também lista todos os objetos que não podem fazer
parte de um conjunto de transporte. A coluna PLUGGED_IN existente na
DBA_TABLESPACES onde o valor YES se refere a tablespace tendo sido importada.

LOG MINER
O log miner possui uma procedure que extrai as informações do dicionário de dados
para uma forma textual.
Etapas:
1- Executar dbmslogmnrd.sql através do usuário SYS para criar o package
DBMS_LOGMNR_D (no Oracle v. 8.1.6, este script se chama dbmslmd; se
este script não existir é porque o catproc não foi executado como deveria ter
sido após criação do banco. A execução do catproc.sql cria o script
dbmslmd.sql);
2- Executar dbmslogmnr.sql através do usuário SYS para criar o package
DBMS_LOGMNR (no Oracle v. 8.1.6 este script se chama dbmslm.sql);
3- Inicializar o parâmetro UTL_FILE_DIR no init.ora (senão, haverá problemas
na próxima etapa e corresponde, na verdade, ao diretório onde o dicionário do
log miner será criado)
4- Rodar DBMS_LOGMNR_D.BUILD

DBMS_LOGMNR_D.BUILD(‘<nome do arquivo de dicionário que será

criado>’,
‘<nome do diretório especificado no
utl_file_dir>’)
NOTA
Há um bug que acarreta no aparecimento do erro ORA-06532 nesta etapa. A
correção deste erro é a edição do script dbmslmd.sql alterando:
TYPE col_desc_array IS VARRAY(513) OF col_description;
por
TYPE col_desc_array IS VARRAY(700) OF col_description;

5- Rodar DBMS_LOGMNR.ADD_LOGFILE. Esta rotina deve ser executada

para cada logfile a ser analisado. Desta forma, a view x$logmnr_logs (ou
v$logmnr_logs) será populada.

DBMS_LOGMNR.ADD_LOGFILE(‘<o logfile a ser examinado>’,

DBMS_LOGMNR.NEW|DBMS_LOGMNR.ADDFILE|
DBMS_LOGMNR.REMOVEFILE);
Exemplo:
DBMS_LOGMNR.ADD_LOGFILE(‘/database/files/redo03.log’,DBMS_LOGMNR.NEW)
;

DBMS_LOGMNR.ADD_LOGFILE(‘/database/files/redo02.log’,DBMS_LOGMNR.ADDF
ILE);

6- Rodar DBMS_LOGMNR.START_LOGMNR. Desta forma, a views

v$logmnr_dictionary, v$logmnr_parameters e v$logmnr_contents serão
populadas:

DBMS_LOGMNR.START_LOGMNR(‘<start scn>’,’<end scn>’,

 ‘<start time>’,’<end time>’,
‘<nome do arquivo de dicionário>’);
Se quiser especificar somente um parâmetro, como por exemplo somente o
dictfilename:
DBMS_LOGMNR.START_LOGMNR(dictfilename=>’/utl_file_dir/dict.ora’
);
Os parâmetros são, startscn, endscn, starttime, endtime e dictfilename.

7- Monitoramento:
SELECT scn, username, sql_undo
FROM v$logmnr_contents
WHERE seg_name = ‘&nome_do_segmento’;

8- Rodar DBMS_LOGMNR.END_LOGMNR. Se não executar essa rotina, ao

fazer logoff (ou exit) receberá ORA-00600

RECOVERY MANAGER
O RMAN pode ser utilizado para efetuar backup e restore de arquivos do BD, archive
logs e control files. Além disso, pode ser utilizado para realizar recovery completo ou
incompleto.

O RMAN inicializa processos servidores no Oracle para os procedimentos de backup

e restore.

IMPORTANTE
 Para que o banco abra, todos os data files devem ter o mesmo número de
checkpoint (com exceção de data files offlines ou read only)
 Archived files e redo log files recuperam as transações commitadas e fazem
rollback das não commitadas.
 Caso queira mudar a localização de um data file ou control file:

1 Dar um shutdown no banco e o coloca em MOUNT

Alter database
2 rename file ‘<localização original com nome.dbf>’
to ‘<localização nova com nome.dbf>’

3 Alter database open;

 Se o DBA quiser fazer um backup ou restore e quiser evitar que a partir de um

certo momento somente usuários específicos possam se logar, digitar: alter system
enable restricted session;
 Problema que ocorreu em uma exportação de usuário:
Conectado a: Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production
EXP-00023: deve ser um DBA para executar a exportação do Banco de Dados
Integral
Exportação executada no conjunto de caracteres de WE8ISO8859P1 e no
conjunto de caracteres de WE8ISO8859P1 NCHAR
. exportando objetos e ações procedurais anteriores ao esquema
. exportando os nomes da biblioteca de função externa para usuário KRAISER
. exportando definições de tipos de objeto para usuário KRAISER
Sobre exportar objetos de KRAISER ...
. exportando vínculos de banco de dados
. exportando números de seqüência
. exportando definições de cluster
. sobre exportar tabelas de KRAISER ... via Caminho Convencional ...
. . exporting table TBEXP 21 linhas
exportadas
. . exporting table TBKP 10 linhas
exportadas
. exportando sinônimos
. exportando views
. exportando procedimentos armazenados
. exportando operadores
. exportando restrições referenciais de integridade
. exportando gatilhos
. exportando tipos de índices
. exportando índices funcionais, extensíveis e de bitmap
. exportando ações contabilizáveis
. exportando snapshots
. exportando logs de snapshot
. exportando filas de serviço
EXP-00008: Erro Oracle: 904 encontrado
ORA-00904: nome inválido de coluna
EXP-00000: Exportação encerrada sem êxito

A solução foi rodar novamente o script catexp localizado no %ORACLE_HOME

%/rdbms/admin com o usuário SYS. No Metalink há ocorrência do mesmo erro
porém há notificação que a ação de reexecutar o catexp não resolve por completo e
indica executar o script %ORACLE_HOME%/javavm/install/initdbj.sql.