Administrao de Usurios

USER, USER ACCOUNT, SCHEMA

Usurio (User): Pessoa que se conecta uma conta de usurio

no Banco de Dados.
Conta de Usurio (User Account): A conta de usurio define
sua permisso inicial de acesso os atributos da sesso.
Schema: Est associado diretamente conta de usurio. um
conjunto de objetos que pertencem conta do usurio.
Quando se cria uma conta de usurio, um schema de mesmo
nome criado automaticamente. Por conta disso, comum
encontrarmos referncias dizendo que Schema e User Account
so a mesma coisa.

ATRIBUTOS DAS CONTAS DE USUARIO

So atributos definidos no momento da criao dos usurios e

definem parmetros para a sesso que ser criada no
momento da conexo.
Os atributos so:
o Nome do Usurio;
o Mtodo de Autenticao;
o Tablespace Default;
o Quota de Tablespace;
o User Profile;
o Status da Conta.
Apenas Nome e Mtodo de Autenticao so obrigatrios. O
restante assumem default, caso no sejam informados.

Criando um usurio:
SQL> CREATE USER [Usuario]
IDENTIFIED BY [Senha/Externally/Globally as] DEFAULT
TABLESPACE [Nome Default]
TEMPORARY TABLESPACE [Nome Temporaria] PROFILE [Nome
Profile]
QUOTA [K/M/Unlimited]
ON [Tablespace]
PASSWORD EXPIRE
ACCOUNT [Lock/Unlock]

USUARIOS PRE DEFINIDOS

SYS
o Possui o perfil de DBA;

Possui todos os privilgios como ADMIN OPTION;

dono do dicionrio de dados;
dono do Automatic Workload Repository (AWR);
necessrio para Startup e Shutdown do Banco (ou
Privilgio SYSDBA);
SYSTEM
o Possui o perfil de DBA;
o BOA PRATICA: Esses usurios no devem ser usados
para o dia a dia. Idealmente cada DBA deve ter seu
usurio prprio com os devidos privilgios (Princpio do
Menor Privilgio).
o
o
o
o

DIFERENA ENTRE AUTENTICAO E

AUTORIZAO
Autenticao: Processo de reconhecimento da credencial fornecida
pelo usurio. o processo que identifica se o solicitante da conexo
um usurio legtimo do sistema, atravs da validao de senha ou
chave de acesso.
Autorizao: o processo que ocorre aps a autenticao, onde
validado os acessos e permisses que o usurio possui e dado
permisso para seu acesso. Por exemplo, autorizao de leitura de
uma tabela, ou de permisso de execuo de uma procedure.
ADMINISTRAAO DE ROLES
Todas as permisses do banco de dados podem ser agrupados em
perfis de privilgios para facilitar a manuteno a atribuio aos
usurios. A isso se d o nome de Role.
As roles podem ser atribudas ou revogadas aos usurios.
As roles tambm podem ser autenticadas por senhas, de forma que
somente usurios que conheam a senha consigam ativar os
privilgios.

Incio de Segurana em Banco de Dados

Contextualizao da Segurana da Informao:

Possuir informao um diferencial competitivo. Traz

agilidade, dinamismo, previsibilidade.
o Exemplo: Google, Big Data, Redes Sociais (Porqu o
Facebook vale tanto?)

Informaes teis podem ser utilizadas para o bem e para o

Mal. Uma violao pode colocar em risco toda a organizao.

Os princpios da segurana da informao:

Confidencialidade: garantia de que a informao acessvel

somente por pessoas autorizadas a terem acesso;

Integridade: a informao alterada somente pelas pessoas

autorizadas;

Disponibilidade: garantia de que as pessoas autorizadas

obtenham acesso informao e aos ativos correspondentes
sempre que necessrio.
o Oracle RAC. Exemplificar
Single Node
Multi-node
Cluster Geogrfico
Oracle 12c Cloud Computing

ORACLE:
Acesso do Administrador:
o SYSDBA
o SYSTEM
o Password File
o Acesso via Console (OS Authentication)

Checar o entendimento de Permissionamento Oracle:

o DML Linguagem utilizada para a manipulao dos
dados.
SELECT - retrieve data from the a database
INSERT - insert data into a table
UPDATE - updates existing data within a table
DELETE - deletes all records from a table, the
space for the records remain
MERGE - UPSERT operation (insert or update)
CALL - call a PL/SQL or Java subprogram
EXPLAIN PLAN - explain access path to data
LOCK TABLE - control concurrency

o DCL Linguagem usada para o controle do Database.

GRANT - gives user's access privileges to database
REVOKE - withdraw access privileges given with
the GRANT command
o DDL Linguagem usada para definir a estrutura do DB.
CREATE - to create objects in the database
ALTER - alters the structure of the database
DROP - delete objects from the database
TRUNCATE - remove all records from a table,
including all spaces allocated for the records are
removed
COMMENT - add comments to the data dictionary
RENAME - rename an object

Dessa forma, garantir a segurana da informao

fazer com que as informaes permaneam
confidenciais, integras e disponveis para a pessoa
certa na hora certa.

Por que devemos proteger uma informao?

o De acordo com SEMOLA:
O seu valor: Projetos Secretos, investimentos,
Mailing Lists

Impacto de sua ausncia: Perder os saldos das

contas correntes;

O Impacto do seu uso por terceiros: Vazamento do

GMAIL.

o A informao deve ser protegida em todo o seu ciclo de

vida, pois seno no considerada segura.
Criao - Somente pessoas autorizadas;
Manuseio - Somente pessoas autorizadas;
Armazenamento: Backup com criptografia.
Transporte: Protocolos de Rede com Criptografia
Descarte: Fitas, HDs e outros mtodos de
armazenamento devem ser apagados ou
destrudos antes do descarte.

Segurana de SGBD Garantindo a

Integridade dos Dados

Controle de Redundncia

Redundncia representada como a presena de um

elemento duplicado.

Os SGBD devem garantir que os dados no sejam

redundantes, ou seja duplicados.

Isso se chama INTEGRIDADE REFERENCIAL.

o Controla duplicidade via Chave Primria;
o Controla delees via Chave Estrangeira;

Busca evitar a inconsistncia dos dados.

o fundamento do modelo relacional, portanto um Banco de

Dados relacional deve implementar a Integridade Referencial.

Controle de Concorrncia

um mecanismo usado para garantir que as transaes

sejam executadas de forma segura.

O SGBD deve ser multi thread, e portanto deve conseguir

gerenciar as diversas transaes concorrentes.

Apesar de ganhar escala com o paralelismo, deve garantir a

seriabilidade, ou seja, deve garantir uma ordem de execuo
das transaes.

Controle de Concorrncia PESSIMISTA: Bloqueiam o acesso

aos dados, inclusive para leitura enquanto h atualizao.

Controle de Concorrncia OTIMISTA: Bloqueia os registros

somente durante a atualizao e mantem a consistncia de
leitura.
o Exemplificar:
LOCKs;
ORACLE FOR UPDATE;
Dead Lock
UNDO para consistncia de Leitura x Dados
Alterados na Transao.

Restrio de Integridade

Visa garantir que as alteraes feitas pelos usurios no

resultem em perda da consistncia dos dados.

A forma mais elementar a Restrio de Domnio Check

Constraints.

Outra Forma: FK - Valores do Filho devem existir no Pai.

Restrio de Acesso

Visa garantir que somente usurios autorizados tenham

acesso s informaes e passam manipul-las.

Verificar o entendimento de DCL.

Mecanismos que Evitam a Violao do

SGBD

Mecanismos Fsicos
o Portas
o Trancas
o Salas Cofres
o Guardas Armados
o Blindagem

Mecanismos de Controle Lgicos

o Criptografia de Protocolos e de Dados;
o Assinatura Digital;
o Mecanismo de Controle de Acesso.

Segurana de Acesso o SGBD

Princpio do Menor Privilgio

o Permite-se privilgios especficos e nega-se todo o resto.
o Exemplificar: Firewall, Acessos somente leitura, etc.

Privilgios Pblicos: So aqueles que todos precisam ter.

o Exemplo Oracle: Tabela DUAL (Select)

o Grant to PUBLIC.

Aula 6 Auditoria Padro do Banco de Dados

o conjunto de aes para verificar o que os usurios esto

fazendo.

Visa prover mecanismos para trilhar as aes dos usurios de

forma a verificar qualquer tipo de acesso indevido (trilha de
auditoria).

Existem uma srie de leis que regulamentam a privacidade e

o rigor ao acesso aos dados, apesar de variar de lugar pra
lugar, as leis se baseiam em padres institudos
mundialmente.

Sarbanes-Oxley Act (SOX) Estados Unidos - 2002:

Determina que Companhias Publicas criem mecanismos de
auditoria e segurana e criao de comits para auditar
processos e evitar aes fraudulentas e fuga de capital
estrangeiro por conta das incertezas. Grandes corporaes
com capital estrangeiro tem que seguir essa lei.

Health Information Portability and Accountability Act (HIPAA) Estados

Unidos - 1996: Previne o mal uso das informaes relativas sade. Prev
auditoria de todos os acessos.

EU Data Directive - Uniao Europeia - 1995: visa proteger

a privacidade individual e define padres de segurana para
todos os indivduos da Unio Europeia.

UK Data Protection Act Reino Unido 1998: Protege o

direito individual atravs da restrio de acesso a dados que
identifique o indivduo.

Norwegian Personal Data Act Noruega - 2000: Inclui o

EU Data Directive e ainda vai alm em alguns aspectos.

Decreto 3.505/2000: por meio do qual foi instituda a

poltica nacional de segurana das informaes. Dispe sobre
o uso de medidas de segurana para previnir acesso e
controles indevidos s informaes sensveis.

Essas e muitas outras leis determinam auditorias constantes e

determinam padres de segurana que devem ser seguidos. Como

muitas outras, so vagas e sua implementao demandam

interpretaes. ISSO TORNA O ASSUNTO CRTICO.
Passos Importantes para a Segurana do Banco de Dados

primordial separar as responsabilidades para aumentar a

segurana. (Dividir para conquistar. O poder dividido fica mais
difcil de ser corrompido).
O DBA precisa ser de Confiana: O DBA superpoderoso.
Para realizar suas atividades, precisa de acessos irrestritos e
devido a isso deve ser cautelosamente escolhido (NA PRTICA
ISSO NO OCORRE!!!).
o Sempre deve se considerar o abuso de confiana. Ele
pode usar todas as senhas de forma indevida, por
exemplo.
o Auditoria a proteo para os cargos de
confiana: Uma auditoria completa e bem desenhada
protegem a organizao dos abusos de poder e
tambm o DBA de problemas que possam ocorrer, pois
acompanham todos os passos.
Oracle Database Vault: fora essa separao. Seu uso
deve ser feito com mto cuidado.

O Oracle Database prov um dos melhores sistemas de

segurana do mundo, porm ele s efetivo se algumas boas
prticas forem tomadas pelo DBA e o Banco deve sempre
estar em constante monitorao.

Os usurios devem acessar apenas os dados que lhe

cabem, conforme as regras de negcios especificadas.
Esses acessos devem seguir o principio do menor
privilgio.

Os usurios devem ser autenticados. Senhas Fortes,

Polticas de Expirao de Senha, Usos de Conexes
criptografadas, etc.

Monitorar Atividades Suspeitas: Mesmo usurios

autenticados eventualmente tentam comprometer o
sistema, buscar dados no permitidos e etc. Ex.: Listar
a tabela inteira de cartes de crdito.

PRINCIPIO DO MENOR PRIVILGIO

Sempre existe alguma brecha a ser explorada e novas podem
aparecer. Esse principio visa diminuir a chance de explor-lo.

Comece com nenhum privilgio e v concedendo somente o

necessrio.
Instale somente os softwares necessrios: menos coisas
instaladas, menor chance de conflito, menos upgrades, e
menor exposio do servidor.
Ative somente os servios necessrios: Menos exposio
de portas, e menos pontos de ataques.
D acesso ao SO e DB somente para pessoas que
necessitem: Menos administrao de usurios e risco de
senhas erradas, senhas antigas e exposio do Sistema.
Limite o acesso de Root ou Administrador: Essa senha
deve ser guardada, administrada e no deve ser dividida
entre os usurios.
Limite o Acesso ao SYSDBA e SYSOPER: Usurios com
essas roles devem ter usurios pessoais e devem ser
auditados.
Limite o acesso aos objetos realmente necessrios para
seu trabalho: isso evita usos indevidos e por erro de objetos
desnecessrios.
MENOR PRIVILGIO EM ORACLE

O Parametro 07_DICTIONARY_ACCESSIBILITY configurado

como falso e evita que usurios com Any table vejam as
tabelas de dicionrio e que o usurio SYS se conecte somente
como SYSDBA.

Revoge privilgios desnecessrios do Public. Por default vem

com acesso s packages UTL_SMTP, UTL_TCP, UTL_HTTP,
UTL_FILE. So controlados pela ACL mas se no for usado deve ser
revogado.

Restringir acesso aos diretrios do SO: uso dos objetos

Directories.

Limite os acessos administrativos do banco.

Limite a autenticao remota dos usurios: somente se todos

os clientes possam ser confiados.

Proteja as senhas dos usurios SYSDBA, SYSOPER e SYSASM

com senhas fortes, case sensitive, com Autenticao LDAP e
as conexes remotas com criptografia SSL.

AUDITORIA EM BANCO DE DADOS ORACLE

http://docs.oracle.com/cd/E11882_01/server.112/e41084/statements
_4007.htm#SQLRF01107
A auditoria deve ser feita de forma focada e estruturada. Auditar o
banco inteiro sem um propsito pode causar problemas srios de
performance. A PERFORMANCE INIMIGA DA SEGURANA!!!

Auditoria Mandatria: O banco precisa auditar algumas

atividades bsicas, independentemente de opes de
auditoria, como por exemplo acesso dos usurios
privilegiados.
Auditoria Padro do Banco de Dados: ligada no nvel do
sistema, atravs do parmetro AUDIT_TRAIL. Feito isso, se
escolhe os objetos a serem auditados atravs do comando
AUDIT e NOAUDIT.
o AUDIT_TRAIL = OS: Os dados so armazenados no
Sistema operacional, no diretrio do AUDIT_FILE_DEST.
o AUDIT_TRAIL = DB: Os dados so armazenados no
banco e pode ser visto na VIEW SYS.DBA_AUDIT_TRAIL.
o AUDIT_TRAIL = XML, XML, EXTENDED = Arquivo XML
salvo no SO. Extendido armazena os valores das BINDs.
SQL Statement Auditing: Audita qualquer DDL. Pode ser
auditado por erro ou sucesso. Pode ser auditado por usurio.

AUDIT table;
SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL;

System-privilege Auditing: Audita qualquer privilgio de

sistema. Pode ser focado em um usurios ou no.

AUDIT select any table, create any trigger;

AUDIT select any table BY hr BY SESSION;

Object-privilege auditing: Pode ser usado para auditar aes em views,

tabelas, procedures, sequences, diretrios. Por default agrupada por sesso
mas pode ser aberta por comando. Pode ser dividida por sucesso ou falha.

AUDIT ALL on hr.employees;

AUDIT UPDATE,DELETE on hr.employees BY ACCESS;

Auditoria de DBA (SYSDBA): Auditoria dos usurios

privilegiados.

o Podem conectar com o banco de dados fechado, por

isso deve ser armazenado fora do Banco.
o As conexes como SYSDBA e SYSOPER so sempre
auditadas;
o Podem ser includas auditorias adicionais com o
audit_sys_operations.
audit_sys_operations=TRUE (The default is FALSE.)
o Os arquivos so gerados no local do audit_file_dest.
o Somente ser auditado caso o usurio conecte como
SYSDBA. Caso se conecte normal, ser auditado atravs
da auditoria normal.

Auditoria Baseada em Valor com Triggers: Alm da

auditoria padro, guarda os valores antes e depois de cada
comando. implementada atravs de Triggers que auditam os
valores.
TRABALHO EM SALA:
1 Seu chefe esta desconfiado que houve uma fraude e que
os salrios andam sendo adulterados. Com isso solicita a voc
uma soluo de auditoria que guarde o usurio e o IP e a data
todas as vezes que o valor do salrio for alterado. Elaborar
uma proposta para essa auditoria. A proposta deve conter o
Comando de Criao da Tabela de Auditoria, o Cdigo da
trigger, e comprovao de que a auditoria funciona.
Coluna de salrio: hr.employees.salary
Soluo:
Somente por trigger ou FGA, pois somente deve
auditar quando o valor do salario for alterado.

CREATE OR REPLACE TRIGGER system.hrsalary_audit

AFTER UPDATE OF salary ON hr.employees
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF :old.salary != :new.salary THEN
INSERT INTO system.audit_employees
VALUES
(sys_context('userenv', 'os_user'),
SYSDATE,
sys_context('userenv', 'ip_address'),
:new.employee_id || ' salary changed from ' || :old.salary ||
' to ' ||
:new.salary);

END IF;
END;
/

Fined-Grained Auditing: Monitora o acesso aos dados baseados

no contedo.

Audita SELECT, INSERT, UPDATE, DELETE e MERGE.

Pode ser vinculada a uma ou mais colunas da tabela ou view.
Pode disparar uma procedure;
E administrada com a package DBMS_FGA package;
Somente dispara se a coluna auditada faz parte do select ou
se atende a condio do select.

begin
dbms_fga.add_policy (
object_schema => 'HR',
object_name => 'EMPLOYEES',
policy_name => 'audit_emps_salary',
audit_condition=> 'department_id=10',
audit_column => 'SALARY',
handler_schema => 'secure',
handler_module => 'log_emps_salary',
enable => TRUE,
statement_types => 'SELECT,UPDATE');
end;
/

CONCEITOS DE BACKUP E RESTORE

Boas Prticas:
1. Deve ser realizado mais de um mtodo de backup para
evitar possveis falhas em um dos processos;
2. Deve ser armazenado mais de uma cpia do backup, em
estruturas e mdias separadas, de forma a diminuir o risco
da perda de informao.
3. Deve-se considerar criptografia e senhas de acessos s
mdias e diretrios de backup para garantia da segurana.
4. O processo de restore deve ser testado com certa
frequncia para garantir tanto que o processo de backup
efetivo, bem como os procedimentos para a realizao dele
sejam treinados.
5. Deve-se prever situaes de catstrofe, e buscar solues
de forma a garantir a continuidade dos negcios.

Obrigaes do DBA

Proteger o Banco de falhas sempre que possvel

Aumentar o tempo entre a ocorrncia de uma falha e outra.
Proteger o banco da redundncia.
Diminuir o tempo do Recover
Diminir qualquer perda de dados.

O DBA deve atuar na antecipao de falhas.

O DBA deve garantir a redundancia e disponibilidade do Hardware.
No perder dados: Se as boas prticas so seguidas, nenhum dado
perdido.
FERRAMENTAS QUE APOIAM ESSE PROCESSO

Archive Log Files

Standby Databases and Oracle Data Guard.

Mais do que se ter backup, preciso testar o restore.

CATEGORIAS DE FALHAS

Statement Failures um nico comando falha (Select, insert,

update, delete).
User Process Failure Uma nica sesso falha.
Network Failure Conexo com o DB perdida.
User Error O usurio executa uma operao errada. (Drop
table, update sem where).
Instance Failure A instncia falha repentinamente.
Media Failure Um ou mais arquivos so perdidos (Foram
deletados ou o disco falhou).

Statement Failure

Geralmente o DBA atua ajustando permisso ou alocao de

espao.
O DBA pode auxiliar na depurao do problema avaliando o
Redo da transao.

User Process Failure

Quando o usurio perde a conexo, o PMON (Process Monitor)

avalia e realiza o expurgo da conexo.
O PMON tambm faz o Rollback e libera os locks das tabelas.
Em geral o DBA no tem ao.
Muitas perdas de conexo podem simbolizar um problema de
rede ou necessidade de treinamento dos usurio.

Network Failure

No existe muitas solues.

Se possvel, prever uma rede de contingncia.
A rede pode ter rotas alternativas.
Pode-se ter um listener de backup.

User Error
O Oracle prove a tecnologia Flashback para permitir que seja
visualizado o estado dos dados no passado, sem ter que voltar
backup para isso. Os dados comitados por engano so recuperados
com as funcionalidades abaixo:

Flashback Query: Select AS OF mostra os dados conforme o

parametro de tempo passado.
Flashback Version Query: Mostra todas as verses dos
dados em um interval de tempo.
Flashback Transaction Query: Mostra todas as alteraes
do banco no nvel da transao.
Flashback Transaction Backout: Desfaz uma transao
especfica e suas transaes dependents.
Flashback Table: Retorna uma ou mais tabelas ao seu
estado anterior sem afetar o restante do sistema.
Flashback Drop: Reverte os efeitos de uma tabela dropada,
buscando as informaes da lixeira, inclusive indices e
triggers.
Flashback Database: Reverte todas as mudanas realizadas
no banco.

Instance Failure
Acontece quando o banco de dados desliga antes de conseguir
sincronizar todos os arquivos.
A recuperao da instncia automatica aplicando as mudanas
gravadas no Redo Log e fazendo roll back das transaes no
comitadas aps o startup da instancia.

ENTENDENDO A RECUPERAO DA INSTANCIA

PROCESSO DE CHECKPOINT (CKPT)
Para entender a recuperao da instncia necessrio entender o
funcionamento de alguns processos de background.

A cada trs segundos (s vezes menos) o CKTP guarda dados

no Control File para documentar quais blocos alterados que
estavam na SGA e foram gravados no disco pelo DBWn.
Esse processo chamado de CHECKPOINT.
O propsito do checkpoint identificar o lugar no Redo online
onde a recuperao da instncia deve comear (isso
chamado de checkpoint Position).
Toda vez que ocorre um Log Switch, o CKPT tambm escreve
essa informao no header dos Data files.

Razes para a existncia dos Checkpoints:

Para garantir que os blocos de dados modificados sejam

escritos regularmente no disco, garantindo que esse dado no
seja perdido no caso de uma falha sistmica ou do Database.
Para diminuir o tempo necessrio na recuperao do Banco de
Dados (Somente os Redos Logs online aps o ltimo
checkpoint precisam ser processados para a recuperao).
Para garantir que todos os dados comitados sejam escritos
nos data files durante o desligamento do banco de dados.

As principais informaes gravadas em um checkpoint so:

Checkpoint Position, SCN (System Change Number), local no Redo
Log File onde comear o recovery, e etc.
REDO LOG FILES AND LogWritter

Redo log files armazena as mudanas ocorridas no Database

atravs do processamento de transaes e aes internas do
servidor Oracle.

Os Redo Logs protegem o banco de dados de perda de

integridade no caso de falhas como falta de energia, falhas de
disco, e etc.

A Oracle recomenda que os Redo Logs sejam multiplexados

(replicados em mais de um disco), pois em caso de falha de
disco, ele no todo perdido.

O Redo Log consite em um conjunto de Redo Log Files. O

LGWR escreve os registros do Redo Log Buffer em todos os
arquivos multiplexados at que o arquivo encha ou que ocorra
um log switch.

Os Redo Log Files so utilizados de uma forma circular.

ARCHIVER (ARCn) PROCESS

ARCn um processo opcional, porm crucial para a recuperao
do banco em caso de uma perda de um disco.
O ARCn arquiva todo Redo Log aps cada log switch e s libera para
o reuso aps o termino do arquivamento. Com isso, todas as
mudanas so gravadas e podem ser usadas para recuperar o
banco, mesmo no caso de uma falha de disco.
O banco pode ser usado em dois modos:
NOARCHIVELOG: Os redo logs so sobrescritos a cada log switch.
ARCHIVELOG: Os arquivos de REDO so arquivados antes de
poderem ser utilizados novamente. essencial para a maioria das
estratgias de backup.
BOA PRTICA: Arquivar os arquivos em um conjunto de disco
separado e apartado dos discos onde esto os data files.

RECUPERAO AUTOMATICA DE INSTANCIA OU DE CRASH

Ocorre quando se tenta abrir um banco de dados em que os

arquivos no foram sincronizados durante o Shutdown.
Utiliza as informaes gravadas nos Arquivos de REDO para
sincronizar os arquivos.
Envolve duas operaes distintas:
o Rolling Foward: Os Data Files so restaurados para seus
estados originais antes da falha da instncia;
o Rolling Back: Mudanas que so feitas mas no foram
commitadas so retornadas para o estado original.
Todo o processo feito de forma automtica, bastando o DBA
apenas iniciar a instncia.

FASES DA RECUPERAO DA INSTANCIA

Para a instancia abrir um Data File, o SCN contido no Header do

Data File deve coincidir com o SCN corrente que est arquivado no
Control File do Database.
Se no coincidir, a instancia aplica as operaes partir dos
arquivos de Redo Log Online, refazendo de forma sequencial as
transaes at elas ficarem atualizadas. Aps todos os data files
serem atualizados, o Database aberto e os usurios podem se
conectar.
A instancia aplica todas as alteraes presentes nos Redos Logs,
inclusive as mudanas no commitadas, e posteriormente realiza o
rollback dessas transaes no commitadas. Ao final, s temos as
transaes efetivamente commitadas no banco de dados.

Media Failure
A Oracle define falha de mdia como toda falha que resulte na perda
ou corrupo de um ou mais arquivos do database (data, control, ou
redo log files).
Recuperar uma falha de mdia requer uma recuperao e
restaurao do arquivo faltante. Para garantir que isso seja
possvel, deve ser consideradas as prticas a seguir:

Agendar Backups Regulares: A maioria das falhas de mdia

exigem o restore do arquivo partir do backup.

Multiplexar os Controls Files: muito mais complexo a

recuperao se todos os control files forem perdidos. Por isso,
importante guardar vrias cpias deles.

Multiplexar os Redo Log Groups: A perda de um Redo log pode

significar perda de informao caso no haja redundncia. De
preferncia, os arquivos devem ser gravados me discos
diferentes.

Reter as cpias arquivadas dos Redo Logs: O banco no modo

Archivelog armazena os redo logs e permite a recuperao de
informaes, mesmo se j tiverem sido apagadas dos Redo
Logs.

CONFIGURANDO A FLASH RECOVERY AREA

A Flash Recovery Area (FRA) um espao reservado em um espao

de disco separado do disco onde esto os Data Files e armazenam
os Archive Logs, backups, Flashback logs, os control files
espelhados, e os redo logs espelhados.
A quantidade de espao a ser reservado para a FRA depende da
quantidade de atividade que o Banco de Dados ter. Quanto maior a
FRA maior a quantidade de atividade do banco.
Em mdia a FRA deve ter duas vezes o tamanho do banco de dados,
pois pode armazenar um backup do banco e uma grande
quantidade de Archive Logs.
O gerenciamento do espao da FRA feita de forma automtica
pelo Oracle de acordo com a poltica de reteno do Backup.
Quando os arquivos se tornam obsoletos, o Oracle mesmo deleta os
arquivos, liberando o espao.
CONFIGURANDO O ARCHIVE LOG
Para facilitar a criao dos archive logs:

Especifique o padro de nome para a gerao dos Archive

Logs.
o A Oracle fornece uma lista de variveis para a criao
dos nomes:
%s: Inclui o numero sequencial do Log como parte
do nome;
%t: Inclui o nmero da Thread como parte do
arquivo.
%r: Inclui o nmero do Resetlog ID para garantir
que o nome continue nico, mesmo depois de
algum procedimento avanado de backup que
reset o sequencial dos logs.
%d: inclui o Database ID como parte do nome.
o Deve incluir as trs variveis para garantir que o nome
seja nico.
o Padro: %t_%s_%r.arc
Especifique o destino ou os destinos para o armazenamento
dos arquivos. Um dos destinos provavelmente ser a FRA.
Coloque o Banco no modo ARCHIVELOG.

Os Archive logs podem ser escrito em at 10 destinos locais ou

remotos, via Oracle Net para um Standby Database.
O destino Default utiliza o parmetro nmero 10 para determinar o
caminho padro da FRA. A Recovery Area identificada pelo
parmetro de inicializao DB_RECOVERY_FILE_DEST.

Colocando o Banco em Archive Log MODE:

sqlplus/assysdba
shutdownimmediate
startupmount
alterdatabasearchivelog;
alterdatabaseopen;
archiveloglist;
EXECUTANDO BACKUPS DE BANCO DE DADOS
Os backups podem ser feitos das seguintes maneiras:

Recovery Manager (RMAN): o mtodo de backup

recomendado pela Oracle.
Oracle Secure Backup: Complementa a funcionalidade
existente adicionando a possibilidade de gravar em fitas ou
pela rede.
User-managed Backup: se baseia em scripts que o DBA deve
escrever. Aos poucos tem sido abandonado por conta do
trabalho excessivo.

USER MANAGED BACKUP

tratado atravs de scripts escritos pelo DBA. Para a realizao de
backup, uma srie de coisas deve ser consideradas na construo
do Script:

Verificar na v$datafile para identificar os redo logs online;

Verificar na v$controlfile para identificar o control file para
backup;
Colocar cada tablespace em modo de backup online (nesse
modo, para de escrever nos datafiles e escreve somente no
Redo);
Verificar na v$backup quais data files so parte da tablespace
que foi colocado no modo de backup online.
Realizar a copia atravs dos comandos de SO para gravar as
copias nos diretrios de backup.
Retirando cada tablespace fora do status de backup.

TERMINOLOGIA DE BACKUP

Whole Database Backup: Inclui todos os data files e pelo menos

um control file (lembrando que todos os control files so identicos).
Partial Database Backup: Pode incluir zero ou mais tablespaces e
zero ou mais data files; pode ou no incluir um control file.
Full Backup: Faz uma cpia de cada bloco que contem dados.
Incremental Backup: Copia todos os blocos que sofreram
alteraes desde a ultima execuo do processo de backup.
Offline Backups: (Tambm conhecido como "Cold"ou backup
consistente): So feitos com o database fechados. So considerados
consistentes pois no momento do backup o SCN no header to
datafile so idnticos ao SCN nos control files.
Online Backups: (Tambm conhecido como "Hot"ou backup
inconsistente): So feitos com o banco de dados aberto. So
inconsistentes pois no h garantia de que os SCN dos datafiles iro
coincidir com os SCN dos control files. Para utilizar esse backup,
tambm necessrio arquivos de recovery.
Image Copies: So cpias dos data files ou dos archive logs.
Simples quanto copiar via SO.
Backup Set: So colees de um ou mais arquivos binrios que
contm um ou mais data files, control file, server parameter file, ou
archive log files. Com um backup set, os blocos vazios no so
copiados, fazendo com que o backup ocupe menos espao. Eles
podem ser comprimidos para reduzir o espao necessrio para a
realizao do backup.

RECOVERY MANAGER
o componente do Oracle Database responsvel pela recuperao
da instncia. capaz de criar backups consistentes ou
inconsistentes, incremental ou full, e fazer o backup do banco de
dados inteiro ou de somente uma poro dele.
Pode realizar backups de forma local ou em mdias para
armazenamento de longo tempo.
UTILIZANDO O RMAN
Pode ser configurado de forma visual atravs do Enterprise Manager
ou atravs de linha de comando.

O Enterprise Manager somente est disponvel nas verses

Standard ou Enterprise do Banco de Dados Oracle. A verso
express pode ser utilizada atravs da linha de comando ou atravs
da ferramenta de realizao de backup.
RMAN EM LINHA DE COMANDO
O RMAN um utilitrio de linha de comando semelhante ao
SQL*Plus.
1. Primeiramente se conecte ao RMAN:
[root@localhost ~]# rman target sys/abc123X@XE
Recovery Manager: Release 11.2.0.2.0 - Production on Tue
Nov 11 23:29:39 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates.
All rights reserved.
connected to target database: XE (DBID=2741488349)
2. Depois configuramos os parmetros permanentes das polticas de
Backup:
CONFIGURE DEFAULT DEVICE TYPE TO disk;
Configura como device default uma unidade de disco.
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
Configura o backup para realizar cpia dos arquivos e no somente
os blocos alterados.
CONFIGURE CONTROLFILE AUTOBACKUP ON;
Configura para sempre realizar o backup do control file.
3. Depois disso, podemos realizar um backup completo do Database
com um simples comando. Isso incluir todos os datafiles e o control
file. Alm disso, podemos solicitar que os Archive logs sejam
deletados aps o backup, liberando assim o espao da instncia.
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;

LIST BACKUP;
LIST COPY;
Exemplo de backup incremental:

RUN {
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG
'meu_bkp_incr' DATABASE;
RECOVER COPY OF DATABASE WITH TAG 'meu_bkp_incr';
}

Primeiro executa um backup incremental e identifica com a TAG

criada. Depois recupera o ultimo backup feito e adiciona as
informaes alteradas.
RECOVERY DA INSTANCIA
Quando o Oracle inicia a instncia, ele realiza a verificao de que
todos os arquivos relativos ao banco de dados esto disponveis e
acessveis. Caso haja algum problema, um alerta emitido.
Quando o banco encontra a falta de um arquivo, somente o primeiro
arquivo faltante mostrado. Para verificar todos os arquivos
faltantes, deve-se selecionar a view v$recover_file.
A instncia tentar realizar o recovey automtico, porm caso no
consiga, ela informar que a recuperao da mdia ser necessria.
As falhas de instncia podem ser causadas pela perda de um control
file, ou de um grupo inteiro de Redo logs ou por algum data file da
tablespace users e system. Nesses casos, o recovery deve ser feito
com o banco de dados fechado e causara indisponibilidade total.
Nos demais caso, pode ser realizado com o banco de dados aberto,
causando indisponibilidade parcial.
DATA RECOVERY ADVISOR
Ferramenta da Oracle que monitora o banco de dados em busca da
identificao de falhas.
Possui uma interface visual para sua configurao.
possvel configurar que em caso de falha seja ativado o banco em
standby via uso da ferramenta Oracle Data Guard. Em seguida
ajusta-se o problema no primeiro banco de dados que sofreu a falha.
Isso garante que no haja perda para os usurios.
Comando para listar as falhas identificadas:
RMAN> List failure all;

PERDA DE UM CONTROL FILE

1. Se a instancia ainda no apresentou erro, desligue utilizando o
shutdown abort;
2. Copie um dos arquivos de control file para o local onde est
faltando o arquivo. Lembrando que recomendado ter pelo menos
dois arquivos de control file.
3. Reinicie a instancia.

PERDA DE UM REDO LOG FILE

A recuperao da perda de um nico arquivo de Redo Log no
deveria afetar o funcionamento da instncia.
Para a recuperao, faa o seguinte:
1. Descubra o arquivo faltante atravs do Alert.log (Show
Parametrer Background).
2. Restaure o arquivo faltante copiando um dos outros arquivos
do mesmo grupo.
3. Se o erro for causado por uma falha de disco ou placa
controladora, mova o arquivo faltante e redirecione o grupo de
redo.
4. Se o redo j foi arquivado ou o banco no est em modo
archive, deve-se limpar o grupo de Redo Log. (Comando SQL>
ALTER DATABASE CLEAR LOGFILE GROUP #;)

5. O Banco no deixar apagar um redo log ainda no arquivado.

Para isso, faa um backup completo do banco antes de apagalo, pois caso outra falha ocorra, a informao ser perdida.
Caso queria apagar mesmo assim, o seguinte comando deve
ser executado:
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #;
RECOVERY DE UM DATA FILE EM NOARCHIVELOG MODE
1. Feche o banco de dados, caso j no tenha apresentado falha;
2. Recupere o banco de dados inteiro, incluindo todos os data
files e control files partir do Backup.
3. Abra o Banco de Dados.
4. Solicite que os usurios reexecutem todas as operaes.

RECOVERY TO POINT IN TIME

O banco deve estar em modo MOUNT.

Restauramos o banco para um momento no tempo. Ele ir buscar as
informaes no Backup e nos archive logs disponveis.

RUN {
SET UNTIL TIME "TO_DATE('11-NOV-2014 23:59:00','DD-MON-YYYY
HH24:MI:SS')";
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
}