Administração de Usuários

USER, USER ACCOUNT, SCHEMA

Usuário (User): Pessoa que se conecta à uma conta de usuário no Banco de Dados.

Conta de Usuário (User Account): A conta de usuário define sua permissão inicial de acesso os atributos da sessão.

Schema: Está associado diretamente à conta de usuário. É um conjunto de objetos que pertencem à conta do usuário.

Quando se cria uma conta de usuário, um schema de mesmo nome é criado automaticamente. Por conta disso, é comum encontrarmos referências dizendo que Schema e User Account são a mesma coisa.

ATRIBUTOS DAS CONTAS DE USUARIO

São atributos definidos no momento da criação dos usuários e definem parâmetros para a sessão que será criada no momento da conexão.

Os atributos são:o Nome do Usuário;o Método de Autenticação;o Tablespace Default;o Quota de Tablespace;o User Profile;o Status da Conta.

Apenas Nome e Método de Autenticação são obrigatórios. O restante assumem default, caso não sejam informados.

Criando um usuário:

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 EXPIREACCOUNT [Lock/Unlock]

USUARIOS PRE DEFINIDOS

SYS o Possui o perfil de DBA;o Possui todos os privilégios como ADMIN OPTION;o É dono do dicionário de dados;

o É dono do Automatic Workload Repository (AWR);o É necessário para Startup e Shutdown do Banco (ou Privilégio

SYSDBA); SYSTEM

o Possui o perfil de DBA;o BOA PRATICA: Esses usuários não devem ser usados para o dia a

dia. Idealmente cada DBA deve ter seu usuário próprio com os devidos privilégios (Princípio do Menor Privilégio).

DIFERENÇA ENTRE AUTENTICAÇÃO E AUTORIZAÇÃO

Autenticação: Processo de reconhecimento da credencial fornecida pelo usuário. É o processo que identifica se o solicitante da conexão é um usuário legítimo do sistema, através da validação de senha ou chave de acesso.

Autorização: É o processo que ocorre após a autenticação, onde é validado os acessos e permissões que o usuário possui e dado permissão para seu acesso. Por exemplo, autorização de leitura de uma tabela, ou de permissão de execução de uma procedure.

ADMINISTRAÇAO DE ROLES

Todas as permissões do banco de dados podem ser agrupados em perfis de privilégios para facilitar a manutenção a atribuição aos usuários. A isso se dá o nome de Role.

As roles podem ser atribuídas ou revogadas aos usuários.

As roles também podem ser autenticadas por senhas, de forma que somente usuários que conheçam a senha consigam ativar os privilégios.

Início de Segurança em Banco de Dados

Contextualização da Segurança da Informação:

Possuir informação é um diferencial competitivo. Traz agilidade, dinamismo, previsibilidade.

o Exemplo: Google, Big Data, Redes Sociais (Porquê o Facebook vale tanto?)

Informações úteis podem ser utilizadas para o bem e para o Mal. Uma violação pode colocar em risco toda a organização.

Os princípios da segurança da informação:

Confidencialidade: garantia de que a informação é acessível somente por pessoas autorizadas a terem acesso;

Integridade: a informação é alterada somente pelas pessoas autorizadas;

Disponibilidade: garantia de que as pessoas autorizadas obtenham acesso à informação e aos ativos correspondentes sempre que necessário.

o Oracle RAC. Exemplificar Single Node Multi-node Cluster Geográfico Oracle 12c – Cloud Computing

ORACLE: Acesso do Administrador:

o SYSDBAo SYSTEMo Password Fileo Acesso via Console (OS Authentication)

Checar o entendimento de Permissionamento Oracle: o DML – Linguagem utilizada para a manipulação 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 commando 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 segurança da informação é fazer com que as informações permaneçam confidenciais, integras e disponíveis para a pessoa certa na hora certa.

Por que devemos proteger uma informação?

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

Impacto de sua ausência: Perder os saldos das contas correntes;

O Impacto do seu uso por terceiros: Vazamento do GMAIL.

o A informação deve ser protegida em todo o seu ciclo de vida, pois senão não é considerada segura.

Criação - Somente pessoas autorizadas; Manuseio - Somente pessoas autorizadas; Armazenamento: Backup com criptografia. Transporte: Protocolos de Rede com Criptografia Descarte: Fitas, HDs e outros métodos de armazenamento

devem ser apagados ou destruídos antes do descarte.

Segurança de SGBD – Garantindo a Integridade dos Dados

Controle de Redundância

Redundância é representada como a presença de um elemento duplicado.

Os SGBD devem garantir que os dados não sejam redundantes, ou seja duplicados.

Isso se chama INTEGRIDADE REFERENCIAL.

o Controla duplicidade via Chave Primária;o Controla deleções via Chave Estrangeira;

Busca evitar a inconsistência dos dados.

É o fundamento do modelo relacional, portanto um Banco de Dados relacional deve implementar a Integridade Referencial.

Controle de Concorrência

É um mecanismo usado para garantir que as transações sejam executadas de forma segura.

O SGBD deve ser multi thread, e portanto deve conseguir gerenciar as diversas transações concorrentes.

Apesar de ganhar escala com o paralelismo, deve garantir a seriabilidade, ou seja, deve garantir uma ordem de execução das transações.

Controle de Concorrência PESSIMISTA: Bloqueiam o acesso aos dados, inclusive para leitura enquanto há atualização.

Controle de Concorrência OTIMISTA: Bloqueia os registros somente durante a atualização e mantem a consistência de leitura.

o Exemplificar: LOCKs; ORACLE FOR UPDATE; Dead Lock UNDO para consistência de Leitura x Dados Alterados na

Transação.

Restrição de Integridade

Visa garantir que as alterações feitas pelos usuários não resultem em perda da consistência dos dados.

A forma mais elementar é a Restrição de Domínio – Check Constraints.

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

Restrição de Acesso

Visa garantir que somente usuários autorizados tenham acesso às informações e passam manipulá-las.

Verificar o entendimento de DCL.

Mecanismos que Evitam a Violação do SGBD

Mecanismos Físicoso Portaso Trancaso Salas Cofreso Guardas Armadoso Blindagem

Mecanismos de Controle Lógicoso Criptografia de Protocolos e de Dados;o Assinatura Digital;o Mecanismo de Controle de Acesso.

Segurança de Acesso o SGBD

Princípio do Menor Privilégioo Permite-se privilégios específicos e nega-se todo o resto.o Exemplificar: Firewall, Acessos somente leitura, etc.

Privilégios Públicos: São aqueles que todos precisam ter.o Exemplo Oracle: Tabela DUAL (Select)o Grant to PUBLIC.

Aula 6 – Auditoria Padrão do Banco de Dados

É o conjunto de ações para verificar o que os usuários estão fazendo.

Visa prover mecanismos para trilhar as ações dos usuários de forma a verificar qualquer tipo de acesso indevido (trilha de auditoria).

Existem uma série 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 padrões instituídos mundialmente.

Sarbanes-Oxley Act (SOX) – Estados Unidos - 2002: Determina que Companhias Publicas criem mecanismos de auditoria e segurança e criação de comitês para auditar processos e evitar ações fraudulentas e fuga de capital estrangeiro por conta das incertezas. Grandes corporações com capital estrangeiro tem que seguir essa lei.

Health Information Portability and Accountability Act (HIPAA) Estados Unidos - 1996: Previne o mal uso das informações relativas à saúde. Prevê auditoria de todos os acessos.

EU Data Directive - Uniao Europeia - 1995: visa proteger a privacidade individual e define padrões de segurança para todos os indivíduos da União Europeia.

UK Data Protection Act – Reino Unido – 1998: Protege o direito individual através da restrição de acesso a dados que identifique o indivíduo.

Norwegian Personal Data Act – Noruega - 2000: Inclui o EU Data Directive e ainda vai além em alguns aspectos.

Decreto 3.505/2000: por meio do qual foi instituída a política nacional de segurança das informações. Dispõe sobre o uso de medidas de segurança para previnir acesso e controles indevidos às informações sensíveis.

Essas e muitas outras leis determinam auditorias constantes e determinam padrões de segurança que devem ser seguidos. Como muitas outras, são vagas e sua implementação demandam interpretações. ISSO TORNA O ASSUNTO CRÍTICO.

Passos Importantes para a Segurança do Banco de Dados

É primordial separar as responsabilidades para aumentar a segurança. (Dividir para conquistar. O poder dividido fica mais difícil de ser corrompido).

O DBA precisa ser de Confiança: O DBA é superpoderoso. Para realizar suas atividades, precisa de acessos irrestritos e devido a isso deve ser cautelosamente escolhido (NA PRÁTICA ISSO NÃO OCORRE!!!).

o Sempre deve se considerar o abuso de confiança. Ele pode usar todas as senhas de forma indevida, por exemplo.

o Auditoria é a proteção para os cargos de confiança: Uma auditoria completa e bem desenhada protegem a organização dos abusos de poder e também o DBA de problemas que possam ocorrer, pois acompanham todos os passos.

Oracle Database Vault: força essa separação. Seu uso deve ser feito com mto cuidado.

O Oracle Database provê um dos melhores sistemas de segurança do mundo, porém ele só é efetivo se algumas boas práticas forem tomadas pelo DBA e o Banco deve sempre estar em constante monitoração.

Os usuários devem acessar apenas os dados que lhe cabem, conforme as regras de negócios especificadas. Esses acessos devem seguir o principio do menor privilégio.

Os usuários devem ser autenticados. Senhas Fortes, Políticas de Expiração de Senha, Usos de Conexões criptografadas, etc.

Monitorar Atividades Suspeitas: Mesmo usuários autenticados eventualmente tentam comprometer o sistema, buscar dados não permitidos e etc. Ex.: Listar a tabela inteira de cartões de crédito.

PRINCIPIO DO MENOR PRIVILÉGIO

Sempre existe alguma brecha a ser explorada e novas podem aparecer. Esse principio visa diminuir a chance de explorá-lo. Comece com nenhum privilégio e vá concedendo somente o necessário.

Instale somente os softwares necessários: menos coisas instaladas, menor chance de conflito, menos upgrades, e menor exposição do servidor.

Ative somente os serviços necessários: Menos exposição de portas, e menos pontos de ataques.

Dê acesso ao SO e DB somente para pessoas que necessitem: Menos administração de usuários e risco de senhas erradas, senhas antigas e exposição do Sistema.

Limite o acesso de Root ou Administrador: Essa senha deve ser guardada, administrada e não deve ser dividida entre os usuários.

Limite o Acesso ao SYSDBA e SYSOPER: Usuários com essas roles devem ter usuários pessoais e devem ser auditados.

Limite o acesso aos objetos realmente necessários para seu trabalho: isso evita usos indevidos e por erro de objetos desnecessários.

MENOR PRIVILÉGIO EM ORACLE

O Parametro 07_DICTIONARY_ACCESSIBILITY é configurado como falso e evita que usuários com Any table vejam as tabelas de dicionário e que o usuário SYS se conecte somente como SYSDBA.

Revoge privilégios desnecessários do Public. Por default vem com acesso às packages UTL_SMTP, UTL_TCP, UTL_HTTP, UTL_FILE. São controlados pela ACL mas se não for usado deve ser revogado.

Restringir acesso aos diretórios do SO: uso dos objetos Directories.

Limite os acessos administrativos do banco.

Limite a autenticação remota dos usuários: somente se todos os clientes possam ser confiados.

Proteja as senhas dos usuários SYSDBA, SYSOPER e SYSASM com senhas fortes, case sensitive, com Autenticação LDAP e as conexões 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 propósito pode causar problemas sérios de performance. A PERFORMANCE É INIMIGA DA SEGURANÇA!!!

Auditoria Mandatória: O banco precisa auditar algumas atividades básicas, independentemente de opções de auditoria, como por exemplo acesso dos usuários privilegiados.

Auditoria Padrão do Banco de Dados: É ligada no nível do sistema, através do parâmetro AUDIT_TRAIL. Feito isso, se escolhe os objetos a serem auditados através do comando AUDIT e NOAUDIT.

o AUDIT_TRAIL = OS: Os dados são armazenados no Sistema operacional, no diretório do AUDIT_FILE_DEST.

o AUDIT_TRAIL = DB: Os dados são 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 usuário.

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

System-privilege Auditing: Audita qualquer privilégio de sistema. Pode ser focado em um usuários ou não.

AUDIT select any table, create any trigger;

AUDIT select any table BY hr BY SESSION;

Object-privilege auditing: Pode ser usado para auditar ações em views, tabelas, procedures, sequences, diretórios. Por default é agrupada por sessão 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 usuários privilegiados.o Podem conectar com o banco de dados fechado, por isso deve ser

armazenado fora do Banco.o As conexões como SYSDBA e SYSOPER são sempre auditadas;

o Podem ser incluídas auditorias adicionais com o audit_sys_operations.

audit_sys_operations=TRUE (The default is FALSE.)o Os arquivos são gerados no local do audit_file_dest.o Somente será auditado caso o usuário conecte como SYSDBA. Caso

se conecte normal, será auditado através da auditoria normal.

Auditoria Baseada em Valor com Triggers: Além da auditoria padrão, guarda os valores antes e depois de cada comando. É implementada através de Triggers que auditam os valores.

TRABALHO EM SALA:

1 – Seu chefe esta desconfiado que houve uma fraude e que os salários andam sendo adulterados. Com isso solicita a você uma solução de auditoria que guarde o usuário e o IP e a data todas as vezes que o valor do salário for alterado. Elaborar uma proposta para essa auditoria. A proposta deve conter o Comando de Criação da Tabela de Auditoria, o Código da trigger, e comprovação de que a auditoria funciona.

Coluna de salário: hr.employees.salary

Solução:

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 ROWBEGIN 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 conteúdo.

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

condição 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 Práticas:

1. Deve ser realizado mais de um método de backup para evitar possíveis falhas em um dos processos;

2. Deve ser armazenado mais de uma cópia do backup, em estruturas e mídias separadas, de forma a diminuir o risco da perda de informação.

3. Deve-se considerar criptografia e senhas de acessos às mídias e diretórios de backup para garantia da segurança.

4. O processo de restore deve ser testado com certa frequência para garantir tanto que o processo de backup é efetivo, bem como os procedimentos para a realização dele sejam treinados.

5. Deve-se prever situações de catástrofe, e buscar soluções de forma a garantir a continuidade dos negócios.

Obrigações do DBA

Proteger o Banco de falhas sempre que possível Aumentar o tempo entre a ocorrência de uma falha e outra. Proteger o banco da redundância. Diminuir o tempo do Recover Diminir qualquer perda de dados.

O DBA deve atuar na antecipação de falhas.

O DBA deve garantir a redundancia e disponibilidade do Hardware.

Não perder dados: Se as boas práticas são 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 sessão falha. Network Failure – Conexão com o DB é perdida. User Error – O usuário executa uma operação errada. (Drop table, update

sem where). Instance Failure – A instância falha repentinamente. Media Failure – Um ou mais arquivos são perdidos (Foram deletados ou o

disco falhou).

Statement Failure

Geralmente o DBA atua ajustando permissão ou alocação de espaço. O DBA pode auxiliar na depuração do problema avaliando o Redo da

transação.

User Process Failure

Quando o usuário perde a conexão, o PMON (Process Monitor) avalia e realiza o expurgo da conexão.

O PMON também faz o Rollback e libera os locks das tabelas. Em geral o DBA não tem ação. Muitas perdas de conexão podem simbolizar um problema de rede ou

necessidade de treinamento dos usuário.

Network Failure

Não existe muitas soluções. Se possível, prever uma rede de contingência. 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 são 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 versões dos dados em um interval de tempo.

Flashback Transaction Query: Mostra todas as alterações do banco no nível da transação.

Flashback Transaction Backout: Desfaz uma transação específica e suas transações 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 informações da lixeira, inclusive indices e triggers.

Flashback Database: Reverte todas as mudanças realizadas no banco.

Instance Failure

Acontece quando o banco de dados desliga antes de conseguir sincronizar todos os arquivos.

A recuperação da instância é automatica aplicando as mudanças gravadas no Redo Log e fazendo roll back das transações não comitadas após o startup da instancia.

ENTENDENDO A RECUPERAÇÃO DA INSTANCIA

PROCESSO DE CHECKPOINT (CKPT)

Para entender a recuperação da instância é necessário entender o funcionamento de alguns processos de background.

A cada três 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 propósito do checkpoint é identificar o lugar no Redo online onde a

recuperação da instância deve começar (isso é chamado de checkpoint Position).

Toda vez que ocorre um Log Switch, o CKPT também escreve essa informação no header dos Data files.

Razões para a existência dos Checkpoints:

Para garantir que os blocos de dados modificados sejam escritos regularmente no disco, garantindo que esse dado não seja perdido no caso de uma falha sistêmica ou do Database.

Para diminuir o tempo necessário na recuperação do Banco de Dados (Somente os Redos Logs online após o último checkpoint precisam ser processados para a recuperação).

Para garantir que todos os dados comitados sejam escritos nos data files durante o desligamento do banco de dados.

As principais informações gravadas em um checkpoint são: Checkpoint Position, SCN (System Change Number), local no Redo Log File onde começar o recovery, e etc.

REDO LOG FILES AND LogWritter

Redo log files armazena as mudanças ocorridas no Database através do processamento de transações e ações 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 não é 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 são utilizados de uma forma circular.

ARCHIVER (ARCn) PROCESS

ARCn é um processo opcional, porém é crucial para a recuperação do banco em caso de uma perda de um disco.

O ARCn arquiva todo Redo Log após cada log switch e só libera para o reuso após o termino do arquivamento. Com isso, todas as mudanças são 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 são sobrescritos a cada log switch.

ARCHIVELOG: Os arquivos de REDO são arquivados antes de poderem ser utilizados novamente. É essencial para a maioria das estratégias de backup.

BOA PRÁTICA: Arquivar os arquivos em um conjunto de disco separado e apartado dos discos onde estão os data files.

RECUPERAÇÃO AUTOMATICA DE INSTANCIA OU DE CRASH

Ocorre quando se tenta abrir um banco de dados em que os arquivos não foram sincronizados durante o Shutdown.

Utiliza as informações gravadas nos Arquivos de REDO para sincronizar os arquivos.

Envolve duas operações distintas:o Rolling Foward: Os Data Files são restaurados para seus estados

originais antes da falha da instância;o Rolling Back: Mudanças que são feitas mas não foram commitadas

são retornadas para o estado original. Todo o processo é feito de forma automática, bastando o DBA apenas

iniciar a instância.

FASES DA RECUPERAÇÃO 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 não coincidir, a instancia aplica as operações à partir dos arquivos de Redo Log Online, refazendo de forma sequencial as transações até elas ficarem atualizadas. Após todos os data files serem atualizados, o Database é aberto e os usuários podem se conectar.

A instancia aplica todas as alterações presentes nos Redos Logs, inclusive as mudanças não commitadas, e posteriormente realiza o rollback dessas transações não commitadas. Ao final, só temos as transações efetivamente commitadas no banco de dados.

Media Failure

A Oracle define falha de mídia como toda falha que resulte na perda ou corrupção de um ou mais arquivos do database (data, control, ou redo log files).

Recuperar uma falha de mídia requer uma recuperação e restauração do arquivo faltante. Para garantir que isso seja possível, deve ser consideradas as práticas a seguir:

Agendar Backups Regulares: A maioria das falhas de mídia exigem o restore do arquivo à partir do backup.

Multiplexar os Controls Files: É muito mais complexo a recuperação se todos os control files forem perdidos. Por isso, é importante guardar várias cópias deles.

Multiplexar os Redo Log Groups: A perda de um Redo log pode significar perda de informação caso não haja redundância. De preferência, os arquivos devem ser gravados me discos diferentes.

Reter as cópias arquivadas dos Redo Logs: O banco no modo Archivelog armazena os redo logs e permite a recuperação de informações, mesmo se já tiverem sido apagadas dos Redo Logs.

CONFIGURANDO A FLASH RECOVERY AREA

A Flash Recovery Area (FRA) é um espaço reservado em um espaço de disco separado do disco onde estão os Data Files e armazenam os Archive Logs, backups, Flashback logs, os control files espelhados, e os redo logs espelhados.

A quantidade de espaço 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 média 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 espaço da FRA é feita de forma automática pelo Oracle de acordo com a política de retenção do Backup. Quando os arquivos se tornam obsoletos, o Oracle mesmo deleta os arquivos, liberando o espaço.

CONFIGURANDO O ARCHIVE LOG

Para facilitar a criação dos archive logs:

Especifique o padrão de nome para a geração dos Archive Logs.o A Oracle fornece uma lista de variáveis para a criação dos nomes:

%s: Inclui o numero sequencial do Log como parte do nome;

%t: Inclui o número da Thread como parte do arquivo. %r: Inclui o número do Resetlog ID para garantir que o

nome continue único, mesmo depois de algum procedimento avançado de backup que reset o sequencial dos logs.

%d: inclui o Database ID como parte do nome.o Deve incluir as três variáveis para garantir que o nome seja único.

o Padrão: %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 parâmetro número 10 para determinar o caminho padrão da FRA. A Recovery Area é identificada pelo parâmetro de inicialização DB_RECOVERY_FILE_DEST.

Colocando o Banco em Archive Log MODE:

sqlplus / as sysdbashutdown immediatestartup mountalter database archivelog;alter database open;archive log list;

EXECUTANDO BACKUPS DE BANCO DE DADOS

Os backups podem ser feitos das seguintes maneiras:

Recovery Manager (RMAN): É o método 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 através de scripts escritos pelo DBA. Para a realização de backup, uma série de coisas deve ser consideradas na construção 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 são parte da tablespace que foi

colocado no modo de backup online. Realizar a copia através dos comandos de SO para gravar as copias nos

diretórios 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 são identicos).

Partial Database Backup: Pode incluir zero ou mais tablespaces e zero ou mais data files; pode ou não incluir um control file.

Full Backup: Faz uma cópia de cada bloco que contem dados.

Incremental Backup: Copia todos os blocos que sofreram alterações desde a ultima execução do processo de backup.

Offline Backups: (Também conhecido como "Cold"ou backup consistente): São feitos com o database fechados. São considerados consistentes pois no momento do backup o SCN no header to datafile são idênticos ao SCN nos control files.

Online Backups: (Também conhecido como "Hot"ou backup inconsistente): São feitos com o banco de dados aberto. São inconsistentes pois não há garantia de que os SCN dos datafiles irão coincidir com os SCN dos control files. Para utilizar esse backup, também é necessário arquivos de recovery.

Image Copies: São cópias dos data files ou dos archive logs. Simples quanto copiar via SO.

Backup Set: São coleções de um ou mais arquivos binários que contém um ou mais data files, control file, server parameter file, ou archive log files. Com um backup set, os blocos vazios não são copiados, fazendo com que o backup ocupe menos espaço. Eles podem ser comprimidos para reduzir o espaço necessário para a realização do backup.

RECOVERY MANAGER

É o componente do Oracle Database responsável pela recuperação da instância. É capaz de criar backups consistentes ou inconsistentes, incremental ou full, e fazer o backup do banco de dados inteiro ou de somente uma porção dele.

Pode realizar backups de forma local ou em mídias para armazenamento de longo tempo.

UTILIZANDO O RMAN

Pode ser configurado de forma visual através do Enterprise Manager ou através de linha de comando.

O Enterprise Manager somente está disponível nas versões Standard ou Enterprise do Banco de Dados Oracle. A versão express pode ser utilizada através da linha de comando ou através da ferramenta de realização de backup.

RMAN EM LINHA DE COMANDO

O RMAN é um utilitário 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 parâmetros permanentes das políticas 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 cópia dos arquivos e não 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. Além disso, podemos solicitar que os Archive logs sejam deletados após o backup, liberando assim o espaço da instância.

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 informações alteradas.

RECOVERY DA INSTANCIA

Quando o Oracle inicia a instância, ele realiza a verificação de que todos os arquivos relativos ao banco de dados estão disponíveis e acessíveis. 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 instância tentará realizar o recovey automático, porém caso não consiga, ela informará que a recuperação da mídia será necessária.

As falhas de instância 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 identificação de falhas.

Possui uma interface visual para sua configuração.

É possível 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 não haja perda para os usuários.

Comando para listar as falhas identificadas:RMAN> List failure all;

PERDA DE UM CONTROL FILE

1. Se a instancia ainda não 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 recuperação da perda de um único arquivo de Redo Log não deveria afetar o funcionamento da instância.

Para a recuperação, faça o seguinte:

1. Descubra o arquivo faltante através 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 não está em modo archive, deve-se limpar o grupo de Redo Log. (Comando SQL> ALTER DATABASE CLEAR LOGFILE GROUP #;)

5. O Banco não deixará apagar um redo log ainda não arquivado. Para isso, faça um backup completo do banco antes de apaga-lo, pois caso outra falha ocorra, a informação 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á não 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 usuários reexecutem todas as operações.

RECOVERY TO POINT IN TIME

O banco deve estar em modo MOUNT.

Restauramos o banco para um momento no tempo. Ele irá buscar as informações no Backup e nos archive logs disponíveis.

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;

}