Aula 04

Banco de Dados para Concursos - Curso Regular

Professor: Thiago Rodrigues Cavalcanti
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

AULA 04: Cópias de segurança, restauração e

recuperação.

Sumário
Aula xx - Cópias de segurança, restauração e recuperação. .......................................... 1
1. Introdução ........................................................................................................................... 1
2. A importância do backup e recuperação ................................................................. 2
3. Preparando-se para os problemas ............................................................................. 3
Cópias de segurança ....................................................................................................................... 4
4. Cópias de segurança (Backup) ................................................................................... 4
5. Backup incremental x backup full .............................................................................. 6
6. Mesclando cópias incrementais ................................................................................... 8
7. Objetos do banco de dados e cópias de segurança ............................................ 8
8. Copiando índices ............................................................................................................... 9
9. O controle do SGBD ........................................................................................................ 9
9.1. O utilitário DB2 COPY................................................................................................ 10
9.2. Oracle RMAN................................................................................................................. 10
9.3. Requisitos de acesso concorrente ........................................................................ 11
9.4. Consistência das cópias de segurança ............................................................... 12
9.5. Arquivamento de log e backup ............................................................................. 13
9.5.1. Log de transações no SQL Server .................................................................... 14
9.6. Determinando a programação de backup......................................................... 15
Recuperação ..................................................................................................................................... 17
10. Recuperação ..................................................................................................................... 17
10.1. Opções de recuperação ............................................................................................ 17
10.2. Modos de recuperação do SQL Server ............................................................... 19
10.3. Passo-a-passo para recuperação ......................................................................... 19
10.4. Tipos de recuperação ................................................................................................ 20
11. Alternativas para backup e recuperação ............................................................... 25
11.1. Bancos de Dados em Standby............................................................................... 25
11.2. Replicação ..................................................................................................................... 26
11.3. Espelhamento de disco ............................................................................................ 27
Questões ........................................................................................................................................ 28
16712855225

Questões Extras .......................................................................................................................... 46

Considerações Finais ..................................................................................................................... 50

Aula 04 - Cópias de segurança, restauração e

recuperação.

1. Introdução
Olá Senhores, vamos começar hoje a debater o assunto de backup,
restauração e recuperação. Esses assuntos estão relacionados a prevenção e
reação de falhas de banco de dados.

Prof. Thiago Rodrigues Cavalcanti

[Link] 1 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

As coisas quebram! Quando um novo banco de dados é criado ou uma

nova aplicação vai entrar em produção, tudo é bem estruturado e novo e,
possivelmente, deve estar funcionando como projetado. Mas, o ambiente muda
ao longo do tempo. Novos hardwares e softwares são adicionados, juntamente
com mais usuários, mais dados, mais exigências, mais, mais, mais... Sistemas
desgastam a medida que são utilizados diariamente na prestação de um serviço.
O DBA deve estar preparado para situações em que uma falha afeta a
disponibilidade, a integridade ou a usabilidade de um banco de dados. Reagir às
falhas e interrupções de serviço é um componente chave do trabalho do DBA. A
capacidade para reagir de forma adequada depende diretamente de ter uma
abordagem bem planejada para backup e recuperação de dados.
Geralmente, os termos backup e recuperação referem-se às estratégias e
aos procedimentos envolvidos na proteção de banco de dados contra
perdas, e na reconstrução do banco de dados caso essa perda aconteça. Essa
reconstrução dos dados é feita por meio da recuperação de arquivos de um
armazenamento secundário, conhecido como mídia de backup.
Essa ação pode ser feita para substituir arquivos danificados ou para
copiar/mover o banco de dados para uma nova localização. A reconstrução
envolve várias operações como restauração, rolling foward e rolling back feitas
com base nos arquivos de backup sobre o banco de dados. Semelhantemente, a
instalação, criação e configuração do banco de dados, a ação de backup e
recuperação pode ser bastante simples ou muito complexa. Tudo vai depender
do ambiente do banco de dados e dos objetivos desejados. Vamos começar
agora nosso passo-a-passo sobre o assunto para entender sua real dimensão
dentro do contexto de concursos de TI.

2. A importância do backup e recuperação

Mesmo sabendo que muitos DBAs acreditam que a garantia de
desempenho ideal do banco de dados e da aplicação é a tarefa mais importante
na sua lista de responsabilidades dos seus trabalhos, isso não é verdade. Estes
DBAs estão confundindo frequência com importância.
A maioria dos DBAs, provavelmente, está realizando tarefas relacionadas
com o desempenho mais frequentemente do que a construção de planos de
backup. É claro que é melhor que eles estejam gerenciando o desempenho com
16712855225

mais frequência do que recuperando suas bases de dados ou a sua empresa

teria grandes problemas! Mas recuperação deve estar no topo da lista de tarefas
DBA (ou muito próximo do topo), definitivamente antes de desempenho. Por
quê? Bem, se você não pode recuperar seus bancos de dados após um
problema, não importa o quão rápido você pode acessá-los, não é? Qualquer
pessoa pode oferecer acesso rápido à informação errada. É trabalho do DBA
manter a informação em bases de dados da empresa precisos, seguros e
acessíveis.
Então, o que os DBAs precisam fazer para garantir a segurança e precisão
dos dados? Esta aula irá descrever as noções básicas de backup e recuperação
de banco de dados e fornecer orientações sobre a construção de um backup
robusto e um plano de recuperação para seus bancos de dados.

Prof. Thiago Rodrigues Cavalcanti

[Link] 2 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

3. Preparando-se para os problemas

Numerosos perigos diários podem causar falhas nos sistemas. Quando
você planeja seu backup de banco de dados e sua estratégia de recuperação,
certifique-se considerar todas as várias ameaças à integridade do banco de
dados e a sua disponibilidade. É aconselhável tomar medidas de precaução para
evitar falhas.
Técnicas como sistemas UPS (uninterruptible power supply), discos
espelhados, e a tecnologia failover podem minimizar a necessidade de
recuperação, mas nenhum planejamento ou regulação pode evitar falhas
inesperadas. Falhas de banco de dados que podem exigir recuperação podem ser
divididas em três categorias:
• Falhas de instância são o resultado de uma exceção interna dentro
dos SGBDs, uma falha no sistema operacional ou uma falha de outro software
relacionado com o banco de dados. Em alguns casos, uma falha da instância
pode resultar na corrupção de dados que requer uma recuperação, mas
geralmente tais falhas não danificam os dados, de modo que os SGBDs
simplesmente precisam ser reiniciados para restabelecer as operações
normais.
• Falhas de aplicação (ou transação) ocorrem quando programas ou
scripts são executados na hora errada, usando as entradas erradas ou na ordem
errada. Uma falha de aplicativo geralmente resulta em dados corrompidos o que
requer uma recuperação ou restauração do banco de dados. Quanto mais
cedo uma falha de aplicação é identificada e corrigida, menor será a quantidade
de danos à base de dados.
• Falha de mídia é susceptível também a danificar os dados. Ela
inclui danos aos dispositivos de armazenamento, falhas nos sistemas de
arquivos, degradação ou danos da fita, e deleção de arquivos de dados. Embora
menos comum na prática, chips de memória danificados também podem causar
corrupção nos dados. Após uma falha de mídia, o banco de dados ficará,
provavelmente, em um estado no qual os dados válidos são ilegíveis, dados
inválidos são legíveis, ou a integridade referencial é violada. Interrupções devido
a falhas de mídia, muitas vezes, podem ser evitadas através da implementação
de tecnologias de disco modernas, tais como RAID.
As empresas hoje estão exigindo maior desempenho e disponibilidade,
16712855225

mesmo quando elas aumentam a quantidade de dados armazenados e

processados. É comum para as organizações a gerencia de um terabyte ou mais
de dados em um único servidor de banco de dados.
Portanto, mais dados precisam estar constantemente disponíveis e tem
de ser processadas mais rapidamente do que nunca. Organizações dependem de
dados para realizar seus negócios, por isso é imperativo que o DBA esteja
preparado com um plano consistente para neutralizar falhas o mais rapidamente
possível. Um plano de backup e recuperação pode ser pensado como uma
apólice de seguro para seus dados. Vamos começar no próximo tópico a
detalhar a primeira etapa deste processo, veremos como fazer as cópias de
segurança ou backups.

Prof. Thiago Rodrigues Cavalcanti

[Link] 3 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Cópias de segurança

4. Cópias de segurança (Backup)

Um componente fundamental de um backup de banco de dados e do
plano de recuperação é a criação de cópias de segurança de dados. Quando
ocorre um erro que danifica a integridade da base de dados, uma cópia de
segurança dos dados pode ser usada como base para recuperar ou restaurar as
informações. No entanto, a história completa sobre o backup de um banco de
dados e sua utilização não é tão simples assim.
Fazer o backup de bancos de dados envolve fazer cópias consistentes,
geralmente sob a forma de cópias de imagens do banco em um determinado
momento, que são a saída de um utilitário de cópia (COPY). O nome do utilitário
de cópia irá variar de SGBD para outro. Os nomes comuns para o utilitário de
backup incluem BACKUP, COPY, DUMP, e EXPORT. Alguns SGBDs contam
com comandos nativos do sistema de arquivos do SO para fazer backup de
dados. No entanto, mesmo se o SGBD fornece uma opção de backup interno, o
DBA pode optar por utilizar ferramentas que operam fora da esfera do SGBD.
Cópias da imagem dos dados atuais e precisas fornecem a base para a
recuperação do banco de dados. O DBA deve assegurar a coerência e precisão
das cópias e basear o plano de backup nas necessidades de recuperação das
aplicações. Ele vai usar essas exigências de recuperação para determinar
quantas vezes devem-se fazer backups e quantas versões do backup deve ser
mantidas.
Além disso, o DBA deve certificar-se de que os registros apropriados estão
disponíveis ou armazenados para fins de recuperação. Para decidir a frequência
que devemos fazer backup de um objeto de banco de dados, considere quanto
tempo será necessário para recuperar o objeto. A duração da recuperação é
determinada por fatores, tais como:
• O número de registros de log que devem ser processados para
recuperar.
• Se o registro é compactado ou comprimido.
• Se o backup é criptografado ou compactado.
16712855225

• O tempo que um operador leva para montar e desmontar as fitas

requeridas, caso essa tecnologia seja utilizada.
• O tempo que leva para ler a parte do log necessários para recuperação.
• O tempo necessário para reprocessar as páginas alteradas.
Além disso, a duração da recuperação depende da arquitetura do SGBD.
Por exemplo, o DB2 mainframe registra a informação sobre o intervalo de tempo
das transações e lê apenas os arquivos de log necessários para a operação de
recuperação. No entanto, alguns SGBDs exigem que todos os arquivos de log
sejam lidos para procurar as informações necessárias para a recuperação.
Tenha em mente que os backups de banco de dados são executados
quando temos atividades somente de leitura, ou nenhuma atividade, e pode ser
restaurado de volta a esse ponto no tempo usando apenas os arquivos de
Prof. Thiago Rodrigues Cavalcanti
[Link] 4 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

backup - nenhum arquivo de log é necessário. Isto pode simplificar e minimizar

o custo da recuperação.
Em geral, quanto mais vezes você faz cópias de backup, menos tempo de
recuperação é necessário. No entanto, a quantidade de tempo necessária para
fazer um backup deve ser equilibrada com a necessidade de processamento
concorrente durante o processo de backup.
O DBA deve decidir quantas “gerações” ou versões completas de backups
são necessárias manter armazenadas (tanto para as cópias de objetos dos
bancos de dados quanto para as cópias de log). Ao manter gerações extras, às
vezes é possível recuperar de um segundo erro durante a recuperação de uma
falha inicial, alternando para um backup mais antigo. No mínimo, o período de
retenção deve ser de pelo menos dois ciclos completos.
Quando você faz uma cópia agendada completa da imagem de um espaço
de tabela, a última cópia completa da imagem e pelo menos outra cópia anterior
vão existir simultaneamente, além do registro de log criado desde a cópia mais
antiga. Você pode considerar manter apenas as cópias de, pelo menos, duas
semanas. Naturalmente, o número de cópias que você decidir manter deve ser
ajustado pelo número de registros associados que também devem ser mantidos
para o backup permanecer viável.
As seguintes diretrizes sobre como fazer backups vão ajudar a garantir
um ambiente recuperável:
• Faça pelo menos duas cópias locais de cada backup de imagem para
ajudar a evitar um estado irrecuperável no caso de um erro de mídia (por
exemplo, uma fita danificada).
• Coordene a estratégia de backup local com sua estratégia de backup
de recuperação de desastres. Muitos utilitários de backup permitem backups
locais e off-site sejam criados simultaneamente.
• Mantenha pelo menos duas gerações de backups de imagem para
cada objeto de banco de dados. Se a cópia mais recente da imagem falhar, você
pode voltar para a cópia mais antiga e ainda ser capaz de se recuperar os dados.
• Considere a criação de backups em disco, e depois migrá-los para a fita
(ou disco óptico, como CD ou DVD), o que pode acelerar o processo de cópia.
Não só porque o disco é mais rápido do que a fita, mas também porque a
recuperação não terá que esperar a montagem de uma fita manual.
16712855225

• Quando cópias de imagem são migradas para a fita, considere

compactar os arquivos para reduzir o número de fitas necessárias para backup
de arquivos grandes. Isso geralmente pode ser realizado utilizando as
funcionalidades da unidade de fita. Além disso, considere criptografar os
arquivos de backup para dados sensíveis.
• Certifique-se de incluir os objetos de banco de dados do catálogo do
sistema em seus planos de backup e recuperação. Os dados do catálogo devem
ser copiados semanalmente pelo menos, talvez com mais frequência para
sistemas muito dinâmicos. Sempre que você emitir uma DDL, que altera os
dados no catálogo do sistema seria uma boa opção guardar essa mudança.
Deixar de fazer o backup do catálogo do sistema após uma alteração DDL pode
fazer com que os objetos de banco de dados alterados tornem-se inacessíveis
depois de uma recuperação.

Prof. Thiago Rodrigues Cavalcanti

[Link] 5 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

• Certifique-se que o processo de backup seja reinicializável. Por

exemplo, considere um processo de backup de banco de dados que leva três
horas para ser concluído. Se o processo falhar depois de duas horas e meia, o
reinício deve exigir apenas meia hora para terminar. Se o backup não for
reinicializável, ele teria que começar de novo desde o início.
• Depois que o backup for concluído, utilizar as funcionalidades do SGBD
para verificar a regularidade do backup, por exemplo, a operação do DB2
db2ckbkp ou o utilitário Sybase BCP.
• Dados que não são armazenados em um banco de dados, mas são
usados por aplicativos de banco de dados devem sofre backup, ao mesmo tempo
em que os objetos de banco de dados.
Como regra geral, fazer imagens de backups em intervalos de tempo
suficiente para que você não interrompa as atividades diárias, mas para que
você possa pagar o preço (tempo) necessário para recuperar o objeto de banco
de dados. Claro, isso é fácil de dizer, mas difícil de realizar! Você vai precisar se
manter a par dos requisitos de aplicação de cada objeto do banco de dados, a
fim de encontrar o equilíbrio certo para a criação de backups.
Muitas vezes, é uma decisão sábia ter um backup de imagem completo de
cada objeto de banco de dados. Por exemplo, antes da reorganização do
catálogo do sistema, você deve fazer cópia de todos os objetos de banco de
dados desse catálogo.
Além disso, após cada reorganização você deve ter um backup completo
do objeto de banco de dados reorganizado. Se você precisar recuperar o objeto,
você pode recuperar para a versão reorganizada dos objetos de banco de dados
em vez de uma versão anterior, desorganizada. Alternativamente, se a
reorganização foi registrada no log, você não precisa aplicar todos os registros
de log escritos durante a reorganização.
Outra situação que requer um backup é quando os dados são carregados
em uma tabela com o log desativado. Depois de ter carregado os dados em
uma tabela usando o utilitário de carga, deve-se fazer um backup completo.
Mesmo se você carregar com o log habilitado, é aconselhável criar um backup
dos dados após o processo de carregamento ser concluído. Dessa forma, se você
precisar recuperar o objeto, você não precisa aplicar os registros de log escritos
durante a carga.
16712855225

Finalmente, a imagem de backup deve ser executada após recuperações

feitas para um ponto no tempo. Isto irá assegurar que o objeto do banco de
dados possa ser recuperado se outra falha ocorrer.
Após fazermos uma rápida análise sobre conceitos relacionados as cópias
de segurança e entendermos quando devemos executar um backup, vamos
agora analisar entre quais os tipos de backup podemos optar.

5. Backup incremental x backup full

Dois tipos de backups devem ser entendidos e utilizados: completo (full) e
incremental. Um DBA deve aprender a diferença entre os dois e implementar a
estratégia de cópia de imagem mais adequada com base nas necessidades de
aplicação e atividades de banco de dados.

Prof. Thiago Rodrigues Cavalcanti

[Link] 6 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Um backup completo da imagem do banco de dados é uma cópia

completa de todos os dados dos objetos no momento em que a cópia foi
executada. Um backup incremental de imagem, também conhecido como
backup diferencial, contém apenas os dados que mudaram desde a última
cópia completa ou incremental da imagem. A vantagem de ter um backup
incremental em vez de um backup completo é que pode ser feito mais
rapidamente, e ocupa menos espaço em disco ou fita. A desvantagem é que a
recuperação com base em cópias incrementais pode demorar mais tempo
porque, em alguns casos, a mesma linha é atualizada várias vezes antes da
última alteração.
Por exemplo, suponha que você gerou uma cópia da imagem completa de
um objeto de banco de dados na manhã de segunda-feira às 2h e depois levou
uma cópia da imagem incremental, na mesma hora das três manhãs seguintes
(veja a Figura). A cópia da imagem completa, mais as três cópias de imagens
incrementais precisam ser aplicadas para recuperar o espaço de tabela. Se a
mesma coluna da mesma linha foi atualizada na terça-feira para "A", na quarta-
feira para "B", e quinta-feira para "C", o processo de recuperação teria de aplicar
estas três alterações antes de chegar aos dados finais, precisos. Se uma cópia
completa for feita todas as noites, o processo de recuperação terá de aplicar
apenas o último backup, que deve conter o valor correto.

16712855225

Alguns SGBDs fornecem a capacidade de analisar um objeto de banco de

dados para determinar se um backup completo ou incremental é recomendado
ou exigido. Isso é tipicamente realizado utilizando uma opção do utilitário de
cópia. Se existe tal opção, o DBA pode executar o utilitário de cópia para
examinar a quantidade de dados que foram alterados desde o último backup.
Além disso, o DBA pode definir um limite para que uma cópia completa seja
executada quando uma determinada quantidade de dados for alterada; uma
cópia incremental é executada quando a quantidade de dados modificados é
inferior ao limite. Quando esta opção não estiver disponível, o DBA deve

Prof. Thiago Rodrigues Cavalcanti

[Link] 7 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

configurar o tipo de backup a ser tomado com base em seu conhecimento sobre
as consultas e utilizações das bases de dados.
A maioria dos objetos de banco de dados será criada para backups
completos em vez de cópias incrementais. O tempo poupado em cópias
incrementais é útil apenas quando uma pequena quantidade de dados é
alterada. No entanto, o trabalho adicional necessário para uma recuperação
usando cópias incrementais pode ser problemático. Em geral, a imagem
completa é recomendada para objetos de banco de dados, onde 30 a 40 por
cento ou mais dos blocos de dados são modificados entre os backups. O DBA faz
essa determinação se baseando não apenas na volatilidade dos dados, mas
também em fatores como a criticidade dos dados, requisitos de disponibilidade e
a funcionalidade dos SGBDs.
Prefira cópias de imagem completas para objetos de banco de pequeno
porte. A definição de "pequeno" irá variar de local para local e de SGBD para
SGBD. Por exemplo, para grandes bancos de dados, baseados em mainframe,
um objeto de banco de dados "pequeno" é, provavelmente, dentro do intervalo
de 150GB para 200GB. Considere o uso de cópias incrementais para reduzir a
janela de processamento em lote para objetos de banco de dados muito grandes
que são minimamente modificados entre backups.
A DBA deve basear a decisão pelo backup completo ou incremental na
percentagem de blocos de dados que tenham sofrido modificações, não sobre o
número de linhas que foram modificados. Em geral, considere a cópia
incremental quando a tabela se torna maior e a janela de processamento em
lote tornar-se menor.
Além disso, alguns cenários não são compatíveis com backups
incrementais. Alguns SGBDs permitem que o usuário desative o registro durante
algumas operações e utilitários. Sempre que uma ação que seja tomada adicione
ou altere dados sem registro, uma cópia da imagem completa é necessária.

6. Mesclando cópias incrementais

Se o SGBD suporta backups de imagem incrementais, também deve
apoiar fusão de cópias incrementais. Um utilitário de merge, por vezes referido
como MERGECOPY, pode ser utilizado para combinar vários backups
incrementais em um único backup, ou para combinar um backup de imagem
16712855225

completo com um ou mais backups incrementais, para criar uma cópia completa.
Se o seu SGBD suporta a fusão de cópias incrementais, considere a
execução do utilitário de fusão para criar uma nova cópia completa da imagem
logo após a criação de uma cópia incremental. O utilitário de fusão pode ser
executado sem impacto no acesso a dados simultâneo ou na janela de lote. Se
você esperar até que a recuperação seja necessária para executar a mesclagem,
o tempo de inatividade será aumentado porque a fusão (ou o processamento
similar) irá ocorrer durante o processo de recuperação enquanto o objeto de
banco de dados não está disponível.

7. Objetos do banco de dados e cópias de

segurança
Prof. Thiago Rodrigues Cavalcanti
[Link] 8 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Normalmente, um backup de imagem é feito no banco de dados, no

espaço de tabela (tablespace), ou no nível de tabela. O nível suportado
dependerá do SGBD utilizado. Em geral, porém, a ideia é fazer backup de um ou
mais objetos que contêm os dados do banco de dados. Em geral, o controle mais
granular do SGBD favorece os backups de objetos de banco de dados, sendo
mais fácil de implementar eficazmente uma estratégia de backup e recuperação.

8. Copiando índices
Alguns SGBDs dão suporte a cópias de segurança dos índices. Na verdade,
alguns SGBDs, inclusive, necessitam de índices para o backup, enquanto o
backup de índice é opcional em outros. O backup de índice pode ser opcional,
porque o SGBD pode recriar um índice a partir dos dados da tabela. Portanto,
um cenário de recuperação típico envolveria a recuperação das tabelas ou
espaços de tabela e, em seguida, usam-se os dados para reconstruir os índices.
Se o SGBD suporta backups de índice, você pode optar por copiar os índices e,
em seguida, recuperar usando os backups.
Um DBA terá de analisar as vantagens e desvantagens de copiar os
índices para o backup, se o seu SGBD suportar backup de índices. A questão que
o DBA deve responder para cada índice é "reconstruir ou recuperar?". Quanto
mais dados devem ser indexados, mais tempo um índice levará para reconstruir
em uma situação de recuperação.
Para tabelas maiores, fazer backup do índice pode resultar em uma
recuperação muito mais rápida, embora à custa do aumento do tempo
necessário para backup. No entanto, tenha em mente que os backups de índice
vão necessitar de tempo adicional para executar durante o processo de cópia
regular. O DBA terá que pesar o custo de recuperação contra o custo de backup
na sua decisão.
Certifique-se de executar backups de dados e de índices, ao mesmo
tempo, se você optar por fazer backup em vez de reconstruir seus índices. Em
outras palavras, quando você fizer o backup de uma tabela, certifique-se
também que o backup de todos os índices associados foi feito. Não fazer isso
pode resultar em índices que não correspondem aos dados durante a
recuperação.
16712855225

9. O controle do SGBD
O grau de controle que o DBMS tem sobre o processo de backup e
recuperação difere de SGBD para SGBD. Alguns SGBDs armazenam as
informações sobre backup e recuperação no catálogo do sistema. Essa
informação é então usada pelo processo de recuperação para determinar os
logs, os backups de logs e os backups de banco de dados necessários para uma
recuperação bem-sucedida. O DB2 para z/OS funciona dessa maneira. Veja a
próxima sessão sobre o utilitário DB2 COPY. Quanto mais informações o SGBD
mantém sobre backups, mais o SGBD pode controlar o seu uso durante a
recuperação.
Por outro lado, alguns SGBDs não gravam informações de backup e
recuperação no catálogo do sistema. Se este for o caso, o DBA deve rastrear
arquivos de backup e assegurar a sua utilização adequada durante uma
Prof. Thiago Rodrigues Cavalcanti
[Link] 9 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

recuperação. O SQL Server é um exemplo de um SGBD que funciona desta

forma. Sempre que um backup é feito, o DBA deve capturar os detalhes
pertinentes da cópia de segurança, tais como o tipo, a hora e a data. Durante
uma situação de recuperação, o DBA deve fornecer as cópias de segurança (para
ambos os objetos de banco de dados e logs) na sequência adequada para
assegurar uma recuperação válida.
Backup e recuperação de bancos de dados Oracle podem ser tratados
desta forma, também; no entanto, a maioria das organizações não vai optar por
fazê-lo. A Oracle fornece um método abrangente para o gerenciamento de
backup e recuperação chamado RMAN. RMAN, que é uma sigla para Recovery
Manager, é um utilitário que estabelece uma conexão com uma sessão de
servidor e gerencia a movimentação de dados para operações de backup e
recuperação. Ao usar o RMAN, o backup e recuperação do Oracle operam de
forma semelhante ao DB2 para z/OS. Veja mais na frente detalhes sobre o uso
do Oracle RMAN para backup e recuperação.

9.1. O utilitário DB2 COPY

O utilitário COPY é utilizado pelo DB2 para z/OS para criar uma cópia da
imagem para backup. Este utilitário mantém um catálogo de informações sobre
a cópia da imagem no catálogo do sistema. Toda a execução bem-sucedida do
utilitário COPY registrar informações no catálogo do sistema que indica o status
da cópia de imagem, o nome do conjunto de dados da cópia de imagem e
detalhes do arquivo, a data e hora do backup e as informações de log. Esta
informação é lida pelo utilitário DB2 RECCOVER para permitir uma recuperação
automatizada do espaço de tabela e do índice. Somente cópias de imagem
válidas registradas no catálogo do sistema podem ser usadas pelo DB2 para a
recuperação.
Com o passar do tempo, backups de cópia de imagem tornam-se
obsoletos. Novas cópias de segurança são feitas e objetos de banco de dados
são recuperados para vários pontos no tempo. O DBA deve manter as
informações no catálogo do sistema, porque backup de linhas obsoletas e
desnecessárias no catálogo do sistema pode retardar o processo de recuperação.
Informações de backup no catálogo do sistema podem ser removido pela DBA
usando o utilitário DB2 MODIFY.
16712855225

9.2. Oracle RMAN

RMAN é um poderoso programa para gerenciar o backup e recuperação de
dados no Oracle. O DBA pode usar o RMAN para especificar arquivos ou logs
arquivados para o backup usando o comando RMAN BACKUP. Isso faz com que o
RMAN crie um conjunto de backup como resultado da execução. Um conjunto de
backup é um ou mais arquivos de dados, arquivos de controle, ou redo logs que
são escritos pelo RMAN em formato proprietário. A única maneira de recuperar o
conjunto de backup é usando o comando RMAN RESTORE. Claro, o DBA pode
optar por usar o comando COPY em vez disso. Isso cria uma cópia de imagem de
um arquivo que pode ser utilizado fora do escopo do RMAN.
RMAN acessa as informações de backup e recuperação a partir de
qualquer arquivo de controle ou do catálogo de recuperação opcional. O catálogo

Prof. Thiago Rodrigues Cavalcanti

[Link] 10 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

de recuperação é similar ao do catálogo do sistema do SGBD, mas contém

apenas os metadados de backup e recuperação.
Tenha em mente que o RMAN é um veículo para controlar o backup e
recuperação de dados Oracle. Não se trata, por si só, apenas de executar o
backup e recuperação; em vez disso, ele controla quando e como backups são
feitos e pode ser usado para coordenar os procedimentos e tarefas de
recuperação.
RMAN geralmente é preferível a outros métodos de backup e recuperação
do Oracle porque é mais fácil de usar e oferece mais funcionalidade. Por
exemplo, o RMAN fornece a capacidade de criar cópias de segurança
incrementais. Se você optar por usar métodos tradicionais do Oracle só backups
completos estão disponíveis.

9.3. Requisitos de acesso concorrente

Algumas técnicas de backup permitem acesso de gravação simultânea
para o objeto de banco de dados. Usando estas técnicas é possível manter os
dados on-line durante o processo de backup, mas vai retardar qualquer
recuperação subsequente porque o SGBD tem de examinar o log do banco de
dados para garantir uma recuperação precisa.
Alguns SGBDs e utilitários de recuperação fornecem a capacidade de
executar acumulação mudança. O processo de acumulação mudança cria uma
imagem da cópia de backup atualizada, fundindo cópias de imagem existentes
com os dados dos registros de banco de dados. Isto é semelhante à fusão de
cópias de imagens incrementais.
Algumas técnicas de backup permitem apenas acesso de leitura para o
objeto de banco de dados. Antes da cópia da imagem ser feita, um QUIESCE
(explicado na próxima seção) do objeto de banco de dados estabelece um ponto
de consistência. Backups que permitem apenas o acesso de leitura proporcionam
uma recuperação mais rápida do que aqueles que permitem operações de
leitura-escrita porque o log de banco de dados não é necessário para garantir
uma recuperação adequada quando temos apenas operações de read sendo
executadas concorrentemente.
Finalmente, algumas técnicas de exigem o objeto que o banco de dados
seja parado, ou esteja completamente off-line. Sob tais condições, ninguém
16712855225

pode ler ou escrever para o espaço de tabela. Este tipo de cópia fornece um
backup rápido porque não há nenhuma disputa pelo espaço de tabela.
O DBA deve compreender as capacidades de backup de cada SGBD da
organização e planejar uma estratégia de backup adequada, que leva em
consideração:
• A necessidade de acesso simultâneo e modificação durante o processo
de backup
• A quantidade de tempo disponível para o processo de backup e o
impacto do acesso simultâneo na velocidade de backup dos dados
• A velocidade dos utilitários de recuperação
• A necessidade de acesso aos logs de banco de dados

Prof. Thiago Rodrigues Cavalcanti

[Link] 11 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Alguns SGBDs usam os termos de backup quente e backup frio para

descrever o acesso simultâneo que pode ocorrer aos dados enquanto está sendo
feito o backup. Um backup frio é realizado ao desligar a instância de banco de
dados, fazendo o backup dos arquivos de banco de dados relevantes. Um backup
quente é realizado enquanto a instância de banco de dados permanece on-line, o
que significa que o acesso simultâneo é possível. Dependendo das capacidades
dos SGBDs que estão sendo utilizados, backups quentes podem ser
problemáticos por que:
• Eles podem ser mais complexos de operacionalizar
• Eles podem causar sobrecarga adicional na forma de maior uso de CPU,
operações de E/S adicionais e registros adicionais de arquivos de log de banco
de dados
• Eles podem exigir que o DBA crie scripts locais específicos para realizar
o backup quente
• Eles exigem testes extensivos para garantir que os backups são viáveis
de recuperação

9.4. Consistência das cópias de

segurança
Certifique-se de seu plano de backup cria um ponto de recuperação
consistente para os objetos de banco de dados. A fim de assegurar a
consistência de backup, é preciso estar ciente de todos os relacionamentos entre
os objetos de banco de dados que está sendo feito backup e outros objetos de
banco de dados. Estes incluem relações determinadas por aplicações, restrições
de integridade referencial e gatilhos. Se você usar um backup para recuperar um
objeto de banco de dados para um ponto anterior no tempo, você vai precisar
recuperar todos os objetos de banco de dados relacionados no mesmo ponto no
tempo. Se não o fizer, o resultado será, provavelmente, dados inconsistentes.
Se o seu DBMS fornece um utilitário QUIESCE, usá-lo para estabelecer um
ponto de consistência para todos os objetos relacionados do banco de dados
antes de fazer o backup. O utilitário QUIESCE irá parar os pedidos de
modificação nos objetos de banco de dados para assegurar a consistência e
registrar o ponto de consistência. Use o utilitário QUIESCE mesmo quando
16712855225

alguns objetos de banco de dados não precisam ser copiados, para que você
possa fornecer um ponto consistente de recuperação para todos os espaços de
tabela amarrados referencialmente.
Se o DBMS não fornece a opção de QUIESCE, você terá de tomar outras
medidas para garantir um ponto consistente para recuperação. Por exemplo,
você pode colocar os objetos de banco de dados em um modo de somente
leitura, tonar o banco de dados off-line, ou parar os processos de aplicação, pelo
menos, os processos de aplicação que atualizar o banco de dados relacionado
com os objetos.
Observação: Algumas opções de recuperação ou produtos podem
encontrar pontos tranquilos baseado no log de banco de dados sem a
necessidade de um QUIESCE durante os backups.

Prof. Thiago Rodrigues Cavalcanti

[Link] 12 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Então, quando criar um ponto de consistência? Se possível, o DBA deve

criar um ponto de consistência durante o processamento diário. Um ponto de
consistência pode vir a calhar se uma recuperação point-in-time for necessária.
Você deve considerar a criação de um ponto de consistência nas seguintes
situações:
• Antes de arquivar o log ativo. Se você perder seus logs ativos, e você
precisa usar seus registros de arquivo para a recuperação, você pode aplicar
com segurança os registros de log somente até o último ponto de recuperação.
Se você aplicar os logs depois desse ponto, você pode acabar com dados
inconsistentes. Se os logs ativos não são arquivados automaticamente, você
pode imobilizar seus objetos pouco antes de descarregar o log ativo, o que lhe
permitirá utilizar os dados todo o caminho até o final do log sem ter deixado em
um estado inconsistente.
• Antes de copiar objetos de banco de dados relacionados.
Considere a criação de um ponto de consistência antes de copiar conjuntos de
tabelas relacionadas. Isto assegura que os backups de todos os objetos de banco
de dados relacionados são consistentes uns com os outros.
• Logo após criar um backup. Ao fazer backups concorrente com
alterações de banco de dados on-line, você pode criar um ponto de consistência
após o backup ser feito para estabelecer um bom ponto de recuperação.
• Pouco antes de uma modificação pesada de banco de dados.
Quando os trabalhos em lote são executados fora de ordem, ou programas on-
line trabalham incorretamente, recuperações parciais são usadas para restaurar
os dados ao seu estado anterior à atividade de atualização. Ao estabelecer um
ponto de consistência antes da atividade de atualização, você pode recuperar a
esse ponto sem ter que utilizar outros backups anteriores a atividade de
atualização pesada.
• Durante momentos de silêncio (quiet moments). Estabelecer um
ponto de consistência pode ser perturbador durante períodos de atividade
pesada. O SGBD deve estabelecer um ponto no tempo em que nenhum dos
objetos de banco de dados em questão estão sendo atualizados. Ao agendar
uma QUIESCE durante períodos de calma, você pode evitar estas perturbações.

9.5. Arquivamento de log e backup16712855225

Todas as alterações de banco de dados são registradas pelo SGBD em um

arquivo de log comumente chamado de log de transações ou log de banco de
dados. Os registros de log são escritos para cada instrução de INSERT, UPDATE
ou DELETE que é executada e confirmada com êxito. É possível rever e recriar
ou desfazer os efeitos de todas as alterações feitas ao banco de dados usando o
log.
Com o passar do tempo e o crescimento do número de alterações de
banco de dados, o log vai aumentar de tamanho. O log de banco de dados para
os registros que estão sendo atualizados é referido como o log ativo. Quando o
log de banco de dados ativo é preenchido, o SGBD invoca um processo
conhecido como arquivamento de log ou log off-loading. Quando um log de
banco de dados é arquivado, a informação atual do registo ativo é movida para
um arquivo de log off-line, e o log ativo é limpo. Se a informação não pode ser

Prof. Thiago Rodrigues Cavalcanti

[Link] 13 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

gravada no log de banco de dados ativo, o SGBD irá parar modificações de

banco de dados até que o registro seja arquivado e o log ativo é reestabelecido.
O DBA normalmente controla a frequência do processo de arquivamento
de log usando um parâmetro de configuração do SGBD. A maioria dos SGBDs
também fornece um comando para permitir que o DBA para solicite
manualmente o processo de arquivamento de log. E lembre-se, cada SGBD
executa arquivamento e backup do log de forma diferente. Veja a seção seguinte
sobre logs de transações no SQL Server para uma breve discussão das
considerações de backup de log.

9.5.1. Log de transações no SQL Server

Para garantir uma estratégia de backup e recuperação eficiente e eficaz
para bancos de dados Microsoft SQL Server, você precisará implementar
backups do log de transações periódicos. Um backup do log de transações é
criado usando o comando BACKUP LOG. Um banco de dados pode ser restaurado
para qualquer ponto no tempo contido dentro da sequência de logs de transação
que você fez backup, até o ponto de falha. Se você não fizer backup de seus
logs de transação antes de truncá-los, você será capaz de restaurar o banco de
dados apenas para o último backup de banco de dados que você criou.
Quando o SQL Server termina de fazer o backup do log de transações, ele
trunca a parte inativa do log. Isso libera espaço no log de transações. O SQL
Server pode reutilizar esse espaço truncado em vez crescer continuamente o
registo de transações e consumir mais espaço. A parte ativa do log de
transações contém transações que ainda estavam em execução e ainda não
tinham sido concluídas no momento do backup.
O SQL Server vai tentar fazer um ponto de verificação sempre que o log
de transações se torna 70% cheio, ou quando ocorre um erro no log completo.
Além disso, quando o SQL Server é desligado (a menos que a opção NOWAIT
seja especificada), ele vai gerar um checkpoint com o arquivamento do log para
cada banco de dados.
O log de transações não deve ser copiado se a opção de banco de dados
TRUNC LOG ON CHKPT for definida como TRUE. Se você especificar TRUNC LOG
ON CHKPT como verdadeira, o SQL Server irá limpar as entradas de log de
transações inativas em cada checkpoint. (Por padrão isso ocorre uma vez a cada
16712855225

minuto). Esta opção diz ao SQL Server que você não vai usar o log de
transações para restaurar as operações.
O log de transações ainda deve ser criado, porque ele é necessário para
reverter transações e para o SQL Server para determinar como recuperar bancos
de dados quando ele é reiniciado. Ative o truncamento de log no checkpoint
apenas para sistemas onde é OK para você perder transações durante o curso
de um dia, porque você vai ser capaz de restaurar o banco de dados de volta
para apenas o último backup de banco de dados. Aplicações desta natureza são
incomuns na maioria dos ambientes de produção.
Você também deve evitar o backup de logs de transação em que tenham
ocorrido operações nonlogged desde o último backup de banco de dados. Se
esta é a situação, crie um backup de banco de dados, completo ou diferencial
em seu lugar.

Prof. Thiago Rodrigues Cavalcanti

[Link] 14 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Finalmente, se todos os arquivos são adicionados ou excluídos do banco

de dados, um backup do log de transações não deve ser tomado. Em vez disso,
você deve criar um backup de banco de dados completo, após o qual os backups
do log de transações podem ser criados novamente. Vejam que é necessário
uma fotografia ou um estado anterior do banco de dados para que possamos
aplicar as modificações descritas no log.

9.6. Determinando a programação de

backup
Estabelecer uma agenda de backup razoável exige equilibrar duas
exigências concorrentes: a necessidade de fazer backups de imagens com
frequência suficiente para garantir um tempo de recuperação razoável, e a
necessidade de não interromper a atividade diária. O DBA deve ser capaz de
equilibrar estes dois objetivos com base em critérios de uso e os recursos do
SGBD.
Nem todos os dados são criados iguais. Alguns dos seus bancos de dados
e tabelas contêm dados que são necessários para o núcleo do seu negócio.
Outros objetos da base de dados contêm dados que são menos críticos ou
facilmente derivados de outras fontes. Antes de definir uma estratégia de
backup viável e seus horários, é necessário analisar seus bancos de dados e
dados e determinar sua natureza e valor ao negócio. Para isso, responda às
seguintes perguntas para cada objeto de banco de dados:
• Quanto de atividade diária ocorre sobre os dados?
• Quantas vezes os dados são modificados?
• Quão crítico os dados são para o negócio?
• Os dados podem ser recriados facilmente?
• Que tipo de acesso que os usuários precisam? O acesso 24/7 é
necessário?
• Qual é o custo de não ter disponíveis os dados durante uma
recuperação? Qual é o valor associado a cada minuto de inatividade?
Classifique cada objeto de banco de dados em termos de sua criticidade e
volatilidade. Isto pode ser conseguido usando o gráfico abaixo. O eixo vertical
16712855225

representa a criticidade dos dados variando do mais facilmente substituível para

dados que não podem ser facilmente substituídos. O eixo horizontal representa a
volatilidade de dados, variando dos estáticos, que muda com pouca frequência,
aos dados voláteis que mudam frequentemente.

Prof. Thiago Rodrigues Cavalcanti

[Link] 15 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Depois de ter definido a classificação dos seus objetos de banco de dados,

você pode usar o diagrama acima como um indicador geral da frequência com
que cada objeto de banco de dados deve sofrer um backup. O DBA deve
desenvolver as restrições e regras de backup para cada tipo diferente de dados.
Em geral, os dados críticos devem ser apoiados com mais frequência do que os
dados não críticos, e os dados voláteis devem ser apoiados com mais frequência
do que os dados estáticos. A chave, no entanto, é como você define o termo
frequentemente. Por exemplo, 1.000 atualizações por dia podem ser frequente
em algumas lojas, enquanto que 50.000 atualizações por dia pode ser pouco
frequentes em outras organizações. O DBA usa a rede para determinar uma
agenda de backup apropriado para cada objeto de banco de dados. O método de
backup também é afetado por necessidades de acesso do usuário.
Quadrante 1: Identifica os dados críticos e dinâmicas da organização. Esta
informação é crucial para o seu negócio e muda rapidamente. Como tal, você
deve ser capaz de recuperá-la rapidamente, assim que você deve copiá-lo com
frequência. Como regra geral, os dados devem ser copiados para o backup, pelo
menos, em uma base diária. Se mais de 20 por cento dos dados mudam
diariamente, não se esqueça de fazer backups completos ao invés de backups
incrementais.
Quadrante 2: Representa os dados críticos, mas estáticos. Mesmo que os
dados mudem pouco de um dia para outro, você vai precisar recuperar os dados
rapidamente em caso de uma falha ou erro porque ele é fundamental para o
negócio. Certifique-se de fazer backup desses dados pelo menos semanalmente.
Considere o uso de backups incrementais que são incorporadas imediatamente
após a conclusão para minimizar um possível trabalho durante uma recuperação.
16712855225

Quadrante 3: Representa dados volátil que não são tão vitais para o seu
negócio. Você pode ser capaz de recriar os dados se ele for corrompido.
Dependendo da quantidade de dados e do volume de mudança, você pode até
não fazer backup de tudo. Para pequenas quantidades de dados, um relatório
impresso pode ser suficiente e funciona como um backup. Se os dados falharem,
você pode simplesmente redigita a partir do relatório impresso.
Alternativamente, se os dados são recriados à noite em um trabalho em lotes,
você pode simplesmente executar o trabalho em lotes para atualizar os dados.
Como um DBA, você vai precisar assegurar que os dados podem ser recriados
ou copiado em uma base regular. De um modo geral, mais do que uma cópia de
segurança dos dados semanal para dados classificados no quadrante-3 é
susceptível de ser considerado um exagero.
Quadrante 4: Representa dados estáticos e não críticas. Tais dados não
mudam muito e podem ser substituídos facilmente. São os dados menos

Prof. Thiago Rodrigues Cavalcanti

[Link] 16 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

importantes e devem ser pensados do ponto de vista de cópias de segurança

apenas quando os dados dos outros três quadrantes forem devidamente
copiados para arquivos de backup. Na verdade, no quadrante-4 os dados podem
não precisar de backup, o DBA pode adoptar uma abordagem semelhante à
descrita para o quadrante 3.
Com isso terminamos nosso material teórico sobre backups. Vamos agora
tratar da recuperação.

Recuperação

10. Recuperação
Quando os problemas impactam o banco de dados, o DBA pode usar os
backups e os registros de log para recuperar o banco de dados. Seja qual for a
causa do problema, o DBA deve ser capaz de recuperar os dados rapidamente,
de modo que a atividade de negócio possa voltar a funcionar. Quando os dados
estão disponíveis, a sua empresa pode estar perdendo milhares ou mesmo
milhões de reais. Reconhecer a necessidade de uma recuperação de banco de
dados é bastante diferente de realmente executar uma recuperação de forma
rápida e adequada. A recuperação dos dados pode ser uma tarefa muito
complexa que é propenso a erros e difícil de gerenciar.
A recuperação envolve muito mais do que simplesmente restaurar uma
imagem dos dados como ele apareceu em algum momento anterior no tempo. A
recuperação de dados envolverá trazer os dados de volta ao seu estado em (ou
antes) do momento no qual aconteceu o problema. Muitas vezes uma
recuperação envolve restaurar o banco de dados e, em seguida, reaplicar
corretamente as alterações que ocorreram ao banco de dados, na sequência
correta.
Simplificando, uma recuperação bem-sucedida é aquela em que você
obtém os dados do aplicativo para o estado que você quer – independente de
ser o estado em que ele estava na semana passada, ontem, ou apenas
momentos atrás. Se você planejou sua estratégia de backup de forma adequada,
você deve ser capaz de recuperar a partir de praticamente qualquer tipo de falha
que você encontrar. 16712855225

10.1. Opções de recuperação

Quando ocorre uma falha, o DBA deve determinar se a recuperação é
necessária. Se for necessária, é preciso determinar quais recursos (cópias de
segurança) estão disponíveis e a melhor forma de executar essa recuperação. É
necessário ainda responder a várias perguntas para determinar o tipo e a
extensão da falha. As respostas podem ditar os passos a serem tomados para
recuperar o sistema. Vejamos algumas perguntas plausíveis:
• Que tipo de falha ocorreu: de mídia, transação, ou instância de banco de
dados?
• Qual é a causa da falha?

Prof. Thiago Rodrigues Cavalcanti

[Link] 17 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

• Como é que o banco de dados foi para o estado off-line: abortou, sofre
algum acidente, o desligamento normal?
• Será que erros do sistema operacional ocorreram?
• O servidor foi reiniciado?
• Existem erros no registro do sistema operacional?
• Existem erros no log de alerta?
• Um dump foi produzido?
• Foram gerados quaisquer arquivos de rastreamento?
• Quão crítica é a perda de dados?
• Você já tentou qualquer tipo de recuperação até agora? Em caso
positivo, quais medidas já foram realizadas?
• Que tipos de backups existem: completo, incremental, ou ambos?
• O que precisa ser recuperado? A base de dados completa, um espaço de
tabela, uma única tabela, um índice, ou combinações desses objetos?
• A sua estratégia de backup apoia o tipo de recuperação necessária?
• Se você tem backups frios, como o banco de dados foi desligado quando
os backups frios foram executados?
• Todos os logs de banco de dados arquivados estão disponíveis para a
recuperação?
• Você tem um backup lógico recente (EXPORT ou UNLOAD)?
• Que atividades simultâneas foram executadas quando o sistema caiu?
• Você pode subir a instância do SGBD?
• Você pode acessar os objetos de banco de dados?
• Quais são os seus requisitos de disponibilidade do sistema?
• Qual a quantidade de dados deve ser recuperada?
• Você está usando arquivos raw (imagens digitais)?
Além disso, uma migração de versão do SGBD pode ter impacto na
capacidade de recuperação. Por exemplo, considere a seguinte sequência de
16712855225

eventos:
• Uma cópia de backup da Tabela A é tomado enquanto o DBMS está
sendo executado em versão 10.
• O SGBD é migrado para uma nova versão, digamos a versão 11.
• Um problema é encontrado, e Tabela A que precisa ser recuperada.
Dependendo do SGBD e dos dados da nova versão, a Tabela A pode não
ser recuperável. Às vezes, fornecedores de SGBDs alteram o formato de
arquivos de backup, tornando os backups, feitos no formato antigo, inutilizáveis.
O mesmo pode ser verdade para o arquivo de log - o formato pode ter mudado
na nova versão, tornando os arquivos de log antigos ilegíveis e os dados,
portanto, irrecuperáveis. Talvez a nova versão tenha alterado a funcionalidade
do utilitário RECOVER, de tal forma que não poderia ler arquivos de backup mais
antigos. Em ambos os casos, o DBA está preso porque não há nenhum backup
Prof. Thiago Rodrigues Cavalcanti
[Link] 18 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

válido que possa ser utilizado para recuperação. Por estas razões, não se
esqueça de investigar os dados de backup e recuperação para cada nova versão
do SGBD antes da migração, e tomar novos backups após a migração se os
backups antigos forem inutilizados.
Naturalmente, estas são apenas algumas das perguntas que o DBA deve
estar preparado para responder a fim de recuperar efetivamente os objetos de
banco de dados. Além disso, o DBA precisa entender todos os detalhes
específicos do SGBD, informações sobre os segmentos de reversão do Oracle ou
como identificar um log RBA (relative byte address) específico para a
recuperação no DB2.

10.2. Modos de recuperação do SQL Server

Ao usar o SQL Server, o DBA pode escolher entre vários modelos de
recuperação a serem usados. O DBAs pode selecionar modelos de recuperação
ao criar o plano de backup e recuperação para os seus bancos de dados. Um
modelo de recuperação seleciona as opções de recuperação com base em
requisitos de desempenho, armazenamento de log de transações, e tolerância a
falhas. Existem três modelos de recuperação: recuperação simples, a
recuperação total, e recuperação de log em massa (bulk-logged).
A recuperação simples requer menos espaço de log, mas tem o maior
potencial de perda de dados. Com a recuperação simples, apenas backups
completos e diferenciais estão disponíveis para recuperação.
A recuperação total registra tudo e necessita de espaço de log extra
para uma abordagem mais abrangente para a recuperação. Com a recuperação
total, o DBA pode executar a recuperação point-in-time usando o log de
transações.
Finalmente, a recuperação bulk-logged que é otimizada para operações
em massa e oferece o melhor desempenho das três opções. Operações em
massa incluem execuções BCP, SELECT INTO, criação do índice, e atualização de
texto e escrita. A recuperação de log em massa não suporta a recuperação
point-in-time.
Os DBAs podem escolher entre esses modelos para ajustar as operações
de backup e recuperação de suas bases de dados de produção.
16712855225

10.3. Passo-a-passo para recuperação

Em um nível alto, os seguintes passos são comuns para a maioria das
recuperações de banco de dados:
1. Identificar a falha. A detecção de uma falha geralmente é simples:
ou o banco de dados não está respondendo a um pedido, ou o SGBD apresenta
algum tipo de mensagem de erro. Alguns problemas são mais complexos como
um arquivo de controle corrompido. Estes tipos de problemas requerem mais
habilidade para identificação.
2. Analisar a situação. O DBA deve analisar o erro para determinar a
causa, o tipo e extensão da falha. Com base nos resultados desta análise, o DBA

Prof. Thiago Rodrigues Cavalcanti

[Link] 19 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

irá escolher um método de recuperação. Esta é normalmente a tarefa de

recuperação mais demorada.
3. Determinar o que precisa ser recuperado. O DBA deve determinar
quais objetos de banco de dados (e talvez outros componentes, como logs)
estão falhando e preparar um roteiro de recuperação que é apropriado para cada
componente. Esta tarefa também pode consumir uma quantidade significativa de
tempo, especialmente para sistemas de maior dimensão.
4. Identificar as dependências entre os objetos de banco de dados a
serem recuperados. A falha de um objeto de banco de dados pode afetar outros
objetos de banco de dados (por exemplo, índices e tabelas referenciadas). A
perda de dados ou uma recuperação para um ponto anterior no tempo
provavelmente irá afetar objetos de banco de dados relacionados.
5. Localize o backup desejado. A imagem de backup mais próxima do
ponto de recuperação no tempo deve ser escolhida, pois levará um menor
intervalo de tempo para se recuperar. Tenha em mente outros fatores, como o
tempo que leva para encontrar fitas na biblioteca.
6. Restaure o(s) backup(s). A restauração é realizada usando o
comando de recuperação utilitário de recuperação de banco de dados ou sistema
de arquivos de escolha.
7. Role para frente (roll foward) através dos registros de log do
banco de dados. Para recuperar o banco ao momento atual ou a um ponto no
tempo após o backup ser feito, os logs de banco de dados devem ser
processados.
Em um nível muito básico, cada banco de dados recuperação envolverá a
maioria desses sete passos. No entanto, dependendo da situação e do tipo de
recuperação solicitada, certos passos podem ser eliminados ou alterados
significativamente.

10.4. Tipos de recuperação

Dos diferentes tipos de recuperação realizados, o primeiro que
normalmente vem à mente é a recuperação para o momento presente (recover
to current), para lidar com algum tipo de desastre. Este desastre poderia ser
qualquer coisa que ocasione uma falha de mídia até um desastre natural que
16712855225

destrói toda a central de processamento de dados. As aplicações ficam

completamente indisponíveis até que a recuperação esteja completa. Este
processo está representado na figura.

Prof. Thiago Rodrigues Cavalcanti

[Link] 20 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Para recuperar com sucesso para o momento atual, o processo de

recuperação deve ser capaz de redefinir o conteúdo do banco de dados para
estado como ele estava no momento (ou imediatamente antes) da falha. Para
recuperar, o processo de recuperação deve encontrar uma imagem completa de
backup válida, copiar e restaurar a cópia desta imagem. Em seguida, a
recuperação vai rolar para frente através do registro de log do banco de dados,
aplicando todas as alterações presentes no log.
Se a última cópia de backup completa for perdida ou destruída, ela ainda
pode ser possível de recuperação se existir uma cópia de imagem anterior. O
processo de recuperação pode começar com a cópia de backup mais antiga,
aplicando quaisquer cópias incrementais, e depois fazendo o rolling foward
através dos logs arquivados e ativos. Naturalmente, mais logs da base de dados
serão requeridos em tal caso, de modo que o processo da recuperação irá
demorar mais tempo.
Se nenhuma cópia de segurança estiver disponível como um ponto de
partida, pode ser possível recuperar o objeto de banco de dados usando apenas
o log do banco de dados. Se os dados foram carregados e o processo de
carregamento foi registrado, a recuperação pode ser capaz de prosseguir
simplesmente aplicando os registros de log.
Outro tipo tradicional de recuperação é a point-in-time (PIT), que
geralmente é feita para lidar com um problema de nível de aplicativo. A
16712855225

recuperação PIT é muitas vezes referida como recuperação parcial porque

somente parte dos dados existentes permanecerão após sua execução. A
recuperação para um ponto no tempo remove os efeitos de todas as transações
que ocorreram desde o ponto especificado no tempo para frente.
Para executar uma recuperação PIT, um backup é restaurado e, em
seguida, as alterações são aplicadas por rolando para frente através do registro
de log do banco de dados (ou do backup de log). No entanto, apenas os
registros de log até o momento especificado são processados. Às vezes, o ponto
de recuperação é especificado como uma data e hora reais; às vezes ele é
especificado usando um endereço de byte relativo ao log do banco de dados. O
processo de recuperação point-in-time é mostrado na figura abaixo:

Prof. Thiago Rodrigues Cavalcanti

[Link] 21 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Para recuperar com êxito a um ponto no tempo, a recuperação deve ser

capaz de redefinir o conteúdo do banco de dados para o estado como ele estava
ou um ponto consistente antes. A chave é manter todas as boas alterações aos
dados, e remover ou desfazer todas as ruins. A recuperação PIT representada
acima poderia ser feita em uma das duas maneiras, dependendo das
características dos SGBD e a quantidade de dados a ser recuperada. Poderíamos
ter as seguintes opções:
• Restaure a cópia da imagem de backup, vá rolando para frente através
dos registos de log e aplicando as alterações de banco de dados até o ponto de
recuperação, ou
• Não restaurar a cópia de imagem de backup, em vez disso, deve-se dar
rollback baseado nos registros log e remover as alterações de banco de dados
que ocorreram após o ponto de recuperação.
Se o SGBS suportar ambos os tipos de recuperação, o DBA deve optar por
implantar a que cria menos tempo de inatividade. Se um número significativo de
alterações precisa ser removido, a restauração e rolando para frente geralmente
resulta em menos tempo de inatividade. Se o número de mudanças que devem
ser removidos é mínimo, a opção de rolar para trás através dos logs deve
resultar em menos tempo de inatividade. Poucos SGBDs suportam a rolagem
para trás a partir do log, mas produtos de terceiros estão disponíveis que podem
tornar essa técnica viável.
Independentemente do método utilizado para executar a recuperação PIT,
o DBA deve selecionar um ponto de recuperação que representa um ponto onde
os dados são consistentes. Um ponto de recuperação consistente irá garantir a
16712855225

integridade dos dados, a integridade referencial, e integridade da transação.

Alguns SGBDs fornecem um utilitário QUIESCE para atingir um ponto de
consistência, enquanto outros exigem que os objetos de banco de dados sejam
bloqueados durante a cópia da imagem.
Um problema adicional é determinar o que exatamente foi executado
desde a má operação ou falha a partir da qual você está recuperando. O DBA
pode examinar a agenda de trabalho, formatar um relatório dos registros do
banco de dados (se o SGBD fornece um utilitário para produzir esse relatório), e
rever no console do computador as mensagens que possam ajudar a determinar
quais os processos foram prejudicados após a falha acontecer.
A recuperação de transações é um terceiro tipo de recuperação. Ela
aborda as deficiências dos tipos tradicionais de recuperação: o tempo de
inatividade e a perda de dados de boa qualidade. Assim, a recuperação de
transações é uma recuperação de aplicativos em que os efeitos das transações

Prof. Thiago Rodrigues Cavalcanti

[Link] 22 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

específicas durante um período de tempo especificado são removidos do banco

de dados. Software de terceiros são necessários para executar uma recuperação
de transação.
Tipos tradicionais de recuperação, tanto a recuperação para um momento
atual e quanto a recuperação PIT, tratam da recuperação no nível de objetos de
banco de dados. Em contraste direto com este nível de granularidade, a
recuperação de transações permite que um usuário recupere uma parte
específica do banco de dados com base em critérios definidos pelo ele.
Neste contexto, uma transação é definida pela visão do usuário do
processo. Este pode ser o conjunto de painéis que constituem uma operação
para novas contratações, ou o conjunto de trabalhos que destacam a
contabilidade geral da empresa. O ponto importante é que não pode ou não
deve haver uma correlação entre as transações que você está tentando corrigir e
transações (ou unidades de recuperação) do SGBD.
Exemplos de definições de transação em nível de usuário podem ser:
• Todas as atualizações do banco de dados executadas pelo usuário ID
DSGRNTLD desde quarta-feira às 11h50min
• Todas as exclusões no banco de dados feitas pelo programa aplicativo
FOLHA DE PAGAMENTO desde 20h00min de ontem
Qualquer número de problemas, tais como o seguinte pode ocorrer no
nível do aplicativo:
• A edição de controles nos programas ou banco de dados não são
definidos corretamente ou conter bugs.
• Alguém mudou o software de agendamento de trabalho ou não verificou
se há códigos de conclusão válidos, de modo que determinados processos foram
executados fora de sequência, causando problemas de dados.
• Código inadequadamente testado atinge produção.
• Existem bugs no software do sistema.
Ou talvez não exista nenhum problema, mas você precisa executar um
programa várias vezes contra os mesmos dados. Há momentos, em especial em
ambientes de teste de sistema, quando você pode executar um teste e, em
seguida, apenas rolar os resultados de volta e tentar novamente.
16712855225

Depois de ter identificado a transação a recuperar, você tem três opções

de recuperação:
• Recuperação PIT. Você pode tentar identificar todos os objetos de
banco de dados impactados pelo aplicativo e executar a recuperação tradicional
point-in-time para remover os efeitos das transações. Você, então, volta a
executar manualmente ou insere novamente os dados relacionados com um
trabalho que era válido.
• Recuperação de UNDO. Remover apenas os efeitos das operações
más.
• Recuperação de REDO. Remover todas as operações depois de um
determinado ponto no tempo, e depois refazer apenas as boas transações.
A recuperação PIT foi discutida anteriormente, por isso não vamos cobri-la
novamente aqui. As outras duas formas de recuperação de transações são
Prof. Thiago Rodrigues Cavalcanti
[Link] 23 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

técnicas de recuperação de aplicativos baseados em SQL. A ideia básica é a de

ler o log e gerar as instruções SQL apropriadas que podem ser executados para
alcançar os resultados desejados da recuperação.
Vamos primeiro examinar uma recuperação UNDO. Ela é a versão mais
simples da recuperação de transações baseadas em SQL, pois envolve apenas
SQL. Para realizar uma recuperação UNDO, os logs de banco de dados devem
ser verificados para a transação identificada e, então um anti-SQL é produzido.
O anti-SQL reverte o efeito de comandos SQL por meio da:
• Conversão de inserções em exclusões
• Conversão de exclusões em inserções
• Invertendo os valores de alterações (por exemplo, UPDATE "A" em "X"
transforma-se em um UPDATE "X" para "A")
Uma vez que o anti-SQL é gerado, ele é executado usando um script SQL
interativo para recuperação UNDO, que é mostrada na figura a seguir. A porção
da base de dados que não necessita de ser recuperada permanece intacta. Ao
desfazer transações errôneas, a recuperação pode ser realizada online, sem
gerar uma interrupção do aplicativo ou banco de dados.
Na verdade, o SGBD deve estar instalado e funcionando, a fim de
executar o anti-SQL. No entanto, certas aplicações podem necessitar do estado
off-line duração da recuperação de UNDO para eliminar o potencial de anomalias
de dados que gerem falhas adicionais.

A recuperação de REDO é uma combinação da recuperação PIT e da

recuperação UNDO, com uma diferença. Em vez de gerar o SQL para a transação
ruim que queremos eliminar, geramos o SQL para as transações que desejamos
salvar. Em seguida, fazemos uma recuperação point-in-time padrão para
16712855225

eliminar todas as operações desde o ponto de recuperação. Finalmente, aplicam-

se as boas transações capturadas na primeira etapa. Este processo é mostrado
na figura.

Prof. Thiago Rodrigues Cavalcanti

[Link] 24 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Ao contrário do processo de UNDO, que cria instruções SQL para fora

todas as transações problemáticas, o processo REDO cria instruções SQL que são
projetados para aplicar apenas sobre as transações válidas a partir de um ponto
consistente no tempo. O processo REDO não gera SQL para as transações
problemáticas, realizando uma recuperação e, em seguida, executando o REDO
SQL pode restaurar os objetos de banco de dados para um estado atual que não
inclui as transações problemáticas.
Ao refazer transações em um ambiente onde a disponibilidade é crucial:
1. Realize uma recuperação para um ponto no tempo.
2. Traga a aplicação e banco de dados online.
3. Refaça as transações válidas posteriores para completar a recuperação.
Esta etapa deve ser feita enquanto o banco de dados está on-line para
operações de leitura/gravação concorrentes.
Se a sua abordagem para backup e recuperação é usar o software de
gerenciamento de armazenamento, backups individuais para objetos de banco
de dados não existem. Neste caso, você precisará implantar o software de
gerenciamento de armazenamento para executar a recuperação. O processo de
recuperação real dependerá do tipo de software em uso, bem como da forma
(ou se) ele interage com os mecanismos de recuperação SGBD.
O termo off-site de recuperação de desastres é o tipo mais raro, mas mais
abrangente, de recuperação de banco de dados. Uma recuperação de desastres
fora do local atual é necessária quando um desastre natural (incêndio,
inundação, etc.) ou outro acidente grave torna impossível usar o seu centro de
processamento de dados primários. Neste caso, é necessário restabelecer o
ambiente do sistema inteiro, bem como recuperar seus SGBDs, objetos de banco
de dados e dados.

11. Alternativas para backup e recuperação

A criação de backups para recuperação é o método mais comum, confiável
e seguro contra falhas e perdas de dados. No entanto, existem várias
alternativas que podem substituir os métodos de backup e recuperação padrão.
As próximas seções examinam brevemente algumas destas alternativas.
16712855225

11.1. Bancos de Dados em Standby

Oracle introduziu de volta o conceito de um banco de dados em standby
na Versão 7. Um banco de dados de espera é uma cópia idêntica de um banco
de dados de produção on-line que está atualizado em termos do seu conteúdo
num estado muito próximo do real. O banco de dados de espera pode não ser
100 por cento “up-to-date” devido a latência do sistema entre a aplicação de
atualizações do banco de dados de produção on-line e o banco de dados de
espera. Quando ocorre uma falha, o controle é transferido para o banco de
dados de espera, que é então aberto, como a base de dados de produção on-line
para permitir que a atividade normal possa continuar.
Normalmente, um banco de dados standby é criado inicialmente por
restaurar um backup frio. Então, todos os logs de arquivo do banco de dados de

Prof. Thiago Rodrigues Cavalcanti

[Link] 25 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

produção devem ser copiados para o banco de dados standby e aplicados. Para
todos os efeitos, o banco de dados standby é continuamente executado em
modo de recuperação, porque ele está aplicando os logs dos arquivos do banco
de dados de produção com as operações realizadas no banco de dados.
Mas, cuidado. Uma base de dados de espera não elimina a necessidade de
backups normais a serem executada na base de dados de produção. As
operações executadas em erro na base de dados de produção serão duplicadas
no banco de dados de espera. Por exemplo, uma linha excluída acidentalmente
também será excluída na máquina de espera.
Um banco de dados de espera é bastante fácil de implementar e fornece a
recuperação rápida de certos tipos de falhas. No entanto, bancos de dados
standby quase nunca são completamente “up-to-date”. Se um arquivo de
produção é perdido, o banco de dados de espera ficar fora de sincronização, e
apenas um banco de dados inteiro pode ser duplicado (em vez de apenas alguns
objetos de banco de dados).

11.2. Replicação
Replicação de dados envolve armazenar e manter dados redundantes em
uma cópia separada do banco de dados. Dados replicados pode ser um
subconjunto de linhas e/ou colunas do banco de dados original. Uma forma
simples de replicação seria implementada através da cópia de tabelas inteiras
para vários locais em vários momentos ao longo do dia. Claro que isso é bem
mais fácil de dizer do que fazer. Alguns SGBDs fornecem recursos de replicação
automatizados, e para os SGBDs sem tais características, ferramentas de
terceiros estão disponíveis.
Há duas tecnologias básicas para a replicação de dados entre bases de
dados:
• Replicação snapshot
• Replicação simétrica
Replicação de instantâneo produz uma cópia de tabelas de banco de
dados em um sistema de destino com base em uma consulta do banco de dados
de origem. No momento em que o instantâneo é inicialmente tomado, a consulta
especificada (talvez sobre uma tabela inteira) é executada e os dados
16712855225

resultantes são carregados na tabela de destino snapshot. Além disso, cada

banco de dados de réplica deve conter informações precisas e atualizadas.
Quando existem várias réplicas, o DBA deve facilitar a atualização de todos os
exemplares replicados ao mesmo tempo. Se as réplicas são atualizadas em
horários diferentes, torna-se complicado e oneroso acompanhar o estado de
cada réplica.
A vantagem de replicação de instantâneo é sua facilidade de
implementação. No entanto, réplicas deste tipo podem se tornar desatualizadas
muito rapidamente, e atualizar a réplica pode causar problemas administrativos
e de desempenho.
Replicação simétrica é uma implementação mais robusta de replicação
porque mantém as réplicas atualizadas. Replicação simétrica pode ser
configurada para garantir que nenhuma transação está totalmente efetivada até
que todas as modificações forem localmente efetivadas em todas as réplicas.
Prof. Thiago Rodrigues Cavalcanti
[Link] 26 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Alternativamente, pode replicar de forma assíncrona, permitindo que cada nó de

banco de dados execute em velocidade máxima sem segurar as atualizações
locais por causa de problemas de velocidade de banco de dados remotos. As
atualizações são aplicadas mais tarde, depois o COMMIT é levado para o banco
de dados mestre.
A maior vantagem da replicação simétrica sobre replicação de instantâneo
é a sincronização automática das modificações do banco de dados mestre para
as réplicas. No entanto, a replicação simétrica é mais difícil de configurar e
administrar. Altos volumes de transações podem causar a degradação do
desempenho, e uma falha na rede pode levar o banco de dados à falha, pois as
modificações não podem ser sincronizadas.
A replicação não é um substituto para backup e recuperação, mas pode
ser útil em algumas situações. Com a replicação de instantâneo, pode ser
possível utilizar réplicas em um ponto no tempo antes de uma falha. No entanto,
a replicação simétrica tem o mesmo problema de um banco de dados, a falha
seria propagada para a réplica. Ambos os tipos de replicação podem ser úteis
para uma recuperação de desastres.

11.3. Espelhamento de disco

Espelhamento de dispositivos de disco pode adicionar um nível extra de
proteção aos bancos de dados. O espelhamento de disco ocorre através da
atribuição de um dispositivo secundário que conterá uma cópia duplicada do
dispositivo primário. Todas as modificações de dados feitas ao dispositivo
primário também são feitas para o dispositivo espelhado. Se o dispositivo
primário falhar, o dispositivo espelho pode ser usado sem causar uma falha de
sistema. Claro, o espelhamento de disco consome o dobro da quantidade de
armazenamento em disco para a mesma quantidade de dados.
Espelhamento de disco difere de replicação em que a duplicação dos
dados ocorre no nível físico em vez do nível de banco de dados. O espelhamento
de disco pode remover a necessidade de recuperar de uma falha de mídia.
Mais uma vez, o espelhamento de disco não substitui a necessidade de
backup e recuperação, porque os dados espelhados serão os mesmos que os
dados que estão apresentando problemas. O espelhamento de disco, no entanto,
pode remover a necessidade de recuperar uma falha de mídia. Em vez de
16712855225

recuperar os objetos de banco de dados do disco que falhou, o DBA pode mudar
para os dados espelhados.
Aqui terminamos nosso assunto de backup e recuperação. Segue nas
próximas páginas uma lista de questões sobre o assunto. Espero que gostem.

Prof. Thiago Rodrigues Cavalcanti

[Link] 27 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Questões
Apresentamos abaixo um conjunto de questões sobre o assunto que
aprendemos nesta aula. Esperamos que elas ajudem na fixação da matéria.
Qualquer dúvida, estamos às ordens!

1. Ano: 2012 Banca: IADES Orgão: EBSERH Cargo: Analista de TI –

Banco de dados
QUESTÃO 46 A exportação de banco de dados é uma das formas de backup mais
conhecida e, em certos casos, mais utilizada. Sobre as características desta
forma de backup, assinale a alternativa correta.
(A) A exportação executa o tipo de backup, conhecido como backup físico, onde
os dados são lidos e gravados em um arquivo, no sistema operacional.
(B) Não há como separar as informações de dicionários de dados associadas às
tabelas, como concessões, índices e constraints. Deverão ser exportadas com os
demais objetos.
(C) As exportações não são permitidas via acesso remoto, ou seja, só é possível
exportar uma tabela, localmente.
(D) Os dados que foram exportados devem, necessariamente, ser importados no
mesmo banco de dados, inclusive no mesmo esquema que foi usado para gerar
o arquivo de exportação.
(E) É possível importar todos ou parte dos dados exportados.
Comentários: Exportação em massa é também conhecido como bulk. Tratamos
deste tipo de backup no SQL Server durante a aula. Vamos utilizar esse exemplo
para responder a questão.
O SQL Server oferece suporte à exportação de dados em massa (bulk data) de
uma tabela do SQL Server e à importação dos dados em massa para uma visão
não particionada ou uma tabela do SQL Server. A importação e a exportação em
massa são essenciais para transferir os dados de maneira eficiente entre o SQL
Server e as fontes de dados heterogêneos. Exportação em massa se refere à
16712855225

cópia de dados de uma tabela SQL Server para um arquivo de dados.

Importação em massa se refere a carregar dados de um arquivo de dados em
uma tabela SQL Server. Essa importação pode ser feita no todos em apenas
sobre parte dos dados exportados. Por exemplo, você pode exportar dados de
um aplicativo do Microsoft Excel para um arquivo de dados e então importar em
massa os dados em uma tabela do SQL Server.
Veja que pelos exposto no parágrafo anterior nossa resposta encontra-se na
alternativa E.
Gabarito: E

Prof. Thiago Rodrigues Cavalcanti

[Link] 28 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

2. Ano: 2014 Banca: IADES Orgão: TRE/PA Cargo: – Analista Judiciário:

Área Apoio Especializado – Especialidade em Análise de Sistemas
QUESTÃO 47 Backup é uma cópia de segurança de arquivos ou dados que
garante a sua respectiva restauração, em casos de falhas. As falhas podem
ocorrer a partir de problemas de hardware, sinistros da natureza ou mesmo por
erros do usuário. Assinale a alternativa que apresenta a definição correta acerca
dos diversos tipos de backups.
(A) O backup a frio (cold backup) é feito online, com o banco de dados, gerando
transações (em produção).
(B) Um backup completo é mais aconselhável, pois demanda menos tempo e
menos recursos de armazenamento.
(C) O backup incremental faz cópia de segurança dos dados alterados desde o
último backup.
(D) Time-Based Recovery é o nome dado a um backup realizado com base na
data (ou tempo) de realização.
(E) A restauração de um backup diferencial é feita usando todas as cópias
realizadas desde o backup completo.
Comentários: Vamos analisar cada uma das alternativas acima:
A. Apresenta um erro logo no início da frase ao dizer que backup a frio, feito
quando o banco de dados está off-line, é feito online.
B. Um backup completo, conforme nós vimos ao longo da aula, demanda mais
tempo para ser realizado e mais recursos de armazenamento. Desta forma, a
alternativa encontra-se incorreta.
C. Essa é a nossa resposta.
D. Recuperação baseada no tempo é uma restauração que leva o banco de
dados a uma instância referente a um momento específico no tempo. Não tem
relação com quando o backup é realizado.
E. A definição de backup diferencial pega todas as alterações desde o último
backup completo.
Gabarito: C
16712855225

3. Ano: 2014 Banca: IADES Orgão: EBSERH Cargo: Analista de

Tecnologia da Informação – Suporte e Redes
QUESTÃO 38 O backup de um sistema de arquivos é realizado todos os dias às
23 horas, de acordo com a política de backup indicada a seguir:

Prof. Thiago Rodrigues Cavalcanti

[Link] 29 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Se o sistema de arquivo for corrompido às 16 horas da sexta-feira, quantos

backups terão que ser restaurados para recuperá-lo?
(A) 1.
(B) 2.
(C) 4.
(D) 5.
(E) 6.
Comentários: A falha aconteceu na sexta, vamos começar a recuperação pelo
domingo com o backup completo, utilizando ainda os backups da segunda, terça,
quarta e quinta. Ou seja, precisamos de cinco backups para restaurar os dados.
Gabarito: D

4. Ano: 2015 Banca: FCC Órgão: CNMP Prova: Analista do CNMP -

Suporte e Infraestrutura 16712855225

O CNMP deseja realizar cópias de segurança de seus dados corporativos

periodicamente. Ele pretende adotar a política de backup incremental dos dados.
Sobre essa política é correto afirmar que
A para a restauração de todos os arquivos, deve-se ter à disposição todos os
backups incrementais já realizados.
B apresenta um risco de falha muito alto, quando comparada com o backup total
e o backup diferencial.
C exige mais espaço de armazenamento, quando comparada com o backup total
e o backup diferencial.
D exige sempre um tempo maior para a sua realização do que um backup total.
E não é possível restaurar um arquivo específico, pois ela só permite a
restauração completa
Prof. Thiago Rodrigues Cavalcanti
[Link] 30 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Comentários: Vimos durante nossa aula como funcionam os backups

incrementais, eles guardam as diferenças entre o último backup feito, seja ele
incremental ou completo e o atual. Para recuperar o banco de dados precisamos,
neste caso, do último backup full e dos backups incrementais subsequentes.
Vejam que pela explicação a resposta encontra-se de cara na alternativa A.
Na alternativa B temos um equívoco ao supor que o risco de falha seria maior.
Na situação de backups incrementais o risco de falha é menor devido ao tempo
de backup e a quantidade de informações serem menores do que o backup total
ou diferencial. Isso já exibe também os erros das alternativas C e D.
Vamos aproveitar para falar sobre o backup diferencial, ele é executado após o
último backup FULL, e realiza backup apenas dos arquivos alterados, em sua
primeira execução. Na segunda execução, ele irá realizar o backup dos arquivos
que foram alterados após o último backup FULL, mais os arquivos que foram
alterados depois do primeiro backup diferencial, na terceira execução, o backup
diferencial irá pegar o montante dos arquivos alterados do primeiro e segundo
backups, mais os arquivos alterados depois da segunda execução conforme
imagem a seguir:

Observem que na realização de um restore, será necessário apenas o último

backup FULL, e o último backup Diferencial.
Finalizando com o comentário da alternativa E, podemos sim restaurar apenas
16712855225

um arquivo específico ao invés do banco de dados inteiro.

Gabarito: A

5. Ano: 2014 Banca: FCC Órgão: TRT - 1ª REGIÃO (RJ) Prova: Técnico do
Judiciário - Tecnologia da Informação
Um usuário deseja implantar um sistema de backup que apresente um tempo de
restauração menor que outras técnicas, mesmo que para isso seja necessário
utilizar um maior espaço de armazenamento. Dentre os tipos usuais de backup
praticados, o mais recomendado para esse caso é o

Prof. Thiago Rodrigues Cavalcanti

[Link] 31 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

A completo.
B diferencial.
C incremental.
D semidiferencial.
E semi-incremental.
Comentários: Sabemos pelo exposto na nossa aula que o backup que possui o
tempo de recuperação mais rápido é o backup full. Seu trade-off está no espaço
de armazenamento e no tempo de execução do backup. Vejam que isso não é
um requisito descrito no enunciado, desta forma podemos cravar na alternativa
A nossa resposta correta. Já tratamos das definições de backup diferencial e
incremental em momentos anteriores.
Gabarito: A

6. Ano: 2014 Banca: FCC Órgão: AL-PE Prova: Analista Legislativo -

Infraestrutura
Uma das atividades fundamentais dos serviços de operação de tecnologia é a
execução de cópias de segurança das instalações, que podem incluir o backup de
configurações de switches e roteadores de rede, backup de bancos de dados,
entre outros. Mesmo em ambientes cloud computing, estratégias de backup são
requeridas. São fatores determinantes da frequência de um backup:
I. A volatilidade dos dados.
II. O grau de utilização dos dados armazenados.
III. A quantidade de atualizações dos dados armazenados.
IV. A distância entre o dispositivo de armazenamento de dados e o usuário.
Está correto o que se afirma APENAS em
A I, II e III.
B II, III e IV.
C I, III e IV. 16712855225

D I e II.
E III e IV.
Comentários: A própria questão já deixa a dica de qual assertiva está errada ao
falar de cloud computing. Em computação na nuvem, os dados podem estar em
servidores na mesma cidade ou do outro lado do planeta. Então, certamente, a
distância não pode ser um fator determinante quando o assunto é backup.
Vimos que a volatilidade e a importância dos dados são alguns dos aspectos
relevantes para determinar a frequência da operação de backup. Observem que,
apesar de usar termos diferentes as opções I e III tratam da volatilidade, ao
passo que a alternativa II fala da importância, se um dado é muito acesso, pelo
menos na teoria ele deve ter alguma relevância.

Prof. Thiago Rodrigues Cavalcanti

[Link] 32 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Analisando as alternativas podemos marcar I, II e III como verdadeiras, o que

está descrito na letra A.
Gabarito: A

7. Ano: 2014 Banca: FCC Órgão: AL-PE Prova: Analista Legislativo -

Infraestrutura
O equipamento servidor da ALEPE teve seu banco de dados corrompido após
uma queda de energia no meio de um dia de trabalho, quando o sistema se
encontrava em plena utilização. A área de TI foi acionada para solucionar o
problema e a principal expectativa dos usuários é que a perda de dados seja a
mínima possível. Considerando que o ambiente servidor e seus dados não
contavam com réplicas nem cluster e que o único mecanismo de proteção contra
perda de dados da instituição era o de backup em dispositivo e mídia externo, é
correto afirmar que
A se for executada a recuperação simples de dados com base no último backup
completo de dados com o banco de dados offline, isso garantirá a recuperação
dos dados no momento mais próximo ao colapso.
B devem ser aplicados os logs correspondentes às modificações de bancos de
dados que ocorreram após a confirmação da queda de energia que corrompeu o
banco de dados.
C deve ser feita a recuperação do último backup offline completo realizando join
das tabelas de dados restauradas do backup com as tabelas do banco de dados
presentes no ambiente corrompido.
D será necessária a recuperação completa aplicando logs do banco de dados
após a recuperação do último backup completo do banco.
E devem ser recuperados os backups diferenciais, sem necessidade de
recuperação de qualquer backup completo.
Comentários: Pela narração descrita no enunciado da questão podemos
perceber que a primeira ação a ser tomada é a recuperação do backup completo
da mídia externa. A próxima etapa é verificar os arquivos de logs do banco de
dados e aplica-los sobre a base até o momento atual refazendo as operações
16712855225

efetivadas. Desta forma podemos encontrar nosso gabarito na alternativa D.

Gabarito: D

8. Ano: 2013 Banca: FCC Órgão: MPE-MA Prova: Analista Judiciário -

Banco de Dados
O tipo de backup de um banco de dados conhecido como diferencial compreende
salvar
A os dados modificados nas últimas 24 horas, independentemente de outros
backups realizados durante esse período.
B apenas a lista dos usuários do banco de dados acompanhados de suas senhas.
Prof. Thiago Rodrigues Cavalcanti
[Link] 33 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

C apenas os dados que sofreram alteração depois do último backup do tipo

completo.
D o banco de dados completo, independentemente de outros backups
anteriormente realizados.
E apenas o conteúdo do dicionário de dados do banco de dados.
Comentários: Vimos a definição de cópias de segurança diferenciais numa
questão anterior. Sabemos que será necessário armazenar as alterações desde o
último backup full. Vejam que essa descrição está presente na letra C.
Gabarito: C

9. Ano: 2012 Banca: FCC Órgão: TRE-CE Prova: Técnico do Judiciário -

Programador de Sistemas
Sobre backup e recuperação do banco de dados Oracle é correto afirmar:
A As informações dos arquivos de controle do banco de dados não podem ser
usadas para orientar a progressão automatizada da recuperação porque não
trazem dados sobre a estrutura de arquivos e o número atual de sequência do
registro que está sendo gravado.
B O backup de datafiles e dos arquivos de controle do banco de dados só poderá
ser feito quando o banco de dados estiver fechado ou o tablespace estiver off-
line.
C O backup dos datafiles de um tablespace individual ou o de um arquivo de
controle são exemplos de backups completos.
D Os backups completos são executados quando o banco de dados está aberto e
disponível para uso.
E O registro redo é um conjunto de arquivos que protegem os dados alterados
do banco de dados alojados na memória e que não foram gravados nos
datafiles.
Comentários: Falamos um pouco sobre o uso do Oracle para backup e
recuperação, vimos o uso do RMAN para contribuir para essas atividades. Vamos
verificar então se o nosso conhecimento é suficiente para respondermos
16712855225

corretamente a questão acima.

Um dos tipos de arquivos do banco de dados Oracle é o arquivo de controle ou
control file. Eles contêm dados sobre o próprio banco de dados (metadados).
São arquivos fundamentais, pois sem eles o SGBD não conseguiria abrir os
arquivos de dados para acessar os dados do banco. O arquivo de controle é lido
quando você inicia a instância e monta o banco de dados. As entradas nesse
arquivo especificam os arquivos físicos incluídos no banco de dados. O arquivo
de controle é atualizado automaticamente quando você adiciona mais arquivos
ao banco de dados. A localização dos arquivos de controle é especificada em um
parâmetro de inicialização. Para proteger o banco de dados contra falhas
causadas pela perda do arquivo de controle, crie cópias do arquivo em, no
mínimo, três diferentes dispositivos físicos. A especificação de vários arquivos
através do parâmetro de inicialização permite ao servidor de banco de dados
Oracle manter diversas cópias do arquivo de controle.
Prof. Thiago Rodrigues Cavalcanti
[Link] 34 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

A utilização dos arquivos de controle que trazem dados sobre a estrutura do

arquivo e o número de sequência do registro auxilia no processo de restauração.
O que torna a alternativa A incorreta.
O Oracle suporta backup on-line e off-line. Isso invalida a alternativa B.
Backups completos devem ser feitos sobre todos os objetos do banco de dados e
não apenas sobre um espaço de tabela (tablespace). Sendo assim, a alternativa
C não condiz com a realidade.
No Oracle é possível fazer um backup completo com o banco de dados montado
e aberto, ou seja, em execução. Letra D também está incorreta, portanto.
Vejam que, pelo exposto, resta para ser nossa resposta correta a alternativa E.
O exemplo a seguir faz backup do banco de dados, alterna os logs de redo on-
line, e inclui os registros arquivados no backup:
DATABASE BACKUP PLUS ARCHIVELOG;
Ao arquivar os logs imediatamente após o backup, você garante que tem um
conjunto completo de registros arquivados durante o período do backup. Desta
forma, você garante que pode executar a recuperação da mídia depois de
restaurar a cópia de segurança.
Gabarito: E

10. Ano: 2012 Banca: FCC Órgão: TST Prova: Analista Judiciário -
Tecnologia da Informação
O Backup de dados e das informações de um computador deve ser realizado
considerando as particularidades do uso dos arquivos. Considerando que já foi
realizado um Backup normal de uma pasta no início de um dia, a forma mais
eficiente e rápida para realizar o Backup dos arquivos modificados daquela
pasta, no mesmo dia, é por meio do Backup
A de cópia.
B diário.
C diferencial.
16712855225

D incremental.
E normal.
Comentários: Você pode estar em dúvida sobre a diferença de backups
diferencias para backups incrementais, vamos tentar entender a diferença entre
eles:
Backup Incremental - Um backup incremental copia somente os arquivos
criados ou alterados desde o último backup normal ou incremental e os marca
como arquivos que passaram por backup (o atributo de arquivo é desmarcado).
Se você utilizar uma combinação dos backups normal e incremental, precisará
do último conjunto de backup normal e de todos os conjuntos de backups
incrementais para restaurar os dados.
Backup Diferencial - Um backup diferencial copia arquivos criados ou alterados
desde o último backup normal ou incremental. Não marca os arquivos como
Prof. Thiago Rodrigues Cavalcanti
[Link] 35 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

arquivos que passaram por backup (o atributo de arquivo não é desmarcado).

Se você estiver executando uma combinação dos backups normal e diferencial, a
restauração de arquivos e pastas exigirá o último backup normal e o último
backup diferencial.
Gabarito: C

11. Ano: 2010 Banca: FCC Órgão: TCE-SP Prova: Agente da

Fiscalização Financeira - Produção e Banco de Dados
Um DBA tem de definir e implementar um esquema apropriado de controle de
danos, em geral envolvendo a operação de dumping, que significa
A gerenciamento e controle de mudanças dos requisitos de BD.
B gerenciamento de espaço do BD em disco.
C monitoramento de performance do SGBD.
D descarga do BD para mídia de backup.
E agrupamento de tabelas afins.
Comentários: Um dump (despejo) de banco de dados, ou database dump,
contém um registro da estrutura de tabela e/ou dados de um banco de dados e
normalmente está na forma de uma lista de declarações SQL. Um dump de
banco de dados é muito usado para realização de cópia de segurança de um
banco de dados, desta forma seus conteúdos podem ser recuperados em caso
de perda de dados. Bancos de dados corrompidos podem ser frequentemente
recuperados pela análise do dump. Vejam, portanto, a resposta na alternativa D.
Gabarito: D

12. Ano: 2010 Banca: FCC Órgão: TCE-SP Prova: Agente da

Fiscalização Financeira - Produção e Banco de Dados
Salvar apenas os blocos do banco de dados que foram alterados desde o último
16712855225

backup completo é função específica

A do restore reversamente incremental.
B do restore full.
C da cópia de segurança incremental.
D da cópia de segurança completa.
E do sistema aplicativo.
Comentários: Vejam que, pelas opções apresentadas pela questão, não nos
resta alternativa a não ser firmar nossa resposta na letra C.
Gabarito: C

Prof. Thiago Rodrigues Cavalcanti

[Link] 36 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

13. Ano: 2014 Banca: FCC Órgão: TJ-AP Prova: Analista Judiciário -
Banco de Dados - DBA
Uma propriedade importante quando se considera a recuperação de um banco
de dados é constituída pelos chamados pontos de verificação (checkpoints). Um
checkpoint consiste de um registro, cuja função é indicar que
A o banco de dados sofreu uma paralisação programada para manutenção.
B houve uma falha no conjunto de discos utilizado para armazenamento dos
dados.
C houve uma falha de comunicação entre as máquinas servidora e cliente.
D o banco de dados passou por uma operação de backup completo.
E todas as transações encerradas anteriormente ao checkpoint já foram
confirmadas.
Comentários: Vamos aproveitar a questão para falarmos um pouco a respeito
do comando CHECKPOINT. Ele escreve todas as páginas sujas (dirty pages) do
banco de dados corrente no disco. As páginas sujas são páginas de dados que
entraram no buffer cache e foram modificadas, mas ainda não foram escritas no
disco. Os pontos de verificação economizam tempo durante uma recuperação
posterior por criarem um ponto onde existe a garantia de que todas as páginas
sujas foram escritas no disco. Por motivo de desempenho, o Mecanismo de
Banco de Dados realiza modificações nas páginas do banco de dados em
memória e não escreve a página no disco após cada modificação. Entretanto, o
Mecanismo de Banco de Dados precisa realizar periodicamente um ponto de
verificação para escrever as páginas sujas no disco. Escrever as páginas sujas
no disco cria um ponto bom conhecido a partir do qual o Mecanismo de Banco de
Dados pode começar a aplicar as modificações contidas no log durante a
recuperação após uma parada não esperada ou queda.
Gabarito: E

16712855225

14. Ano: 2014 Banca: FGV Órgão: DPE-RJ Prova: Técnico Superior
Especializado - Analista de Suporte
No MS SQL Server, a recuperação de um banco de dados em caso de falhas
depende da propriedade que define o modelo de recuperação (recovery model).
As opções disponíveis para essa propriedade são
A Simple; Bulk logged; Full.
B BackUp; Restore.
C On line; Off line.
D HotbackUp; Log.
E AlwaysOn; Database mirroring.

Prof. Thiago Rodrigues Cavalcanti

[Link] 37 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Comentários: Vimos durante a aula que o SQL Server possibilita três modelos
de recuperação: recuperação simples, a recuperação total, e recuperação
de log em massa (bulk-logged). Sendo assim, podemos gabarita a alternativa
A.
Gabarito: A

15. Ano: 2014 Banca: VUNESP Órgão: TCE-SP Prova: Agente da

Fiscalização Financeira - Infraestrutura de TI e Segurança da
Informação
Em um sistema gerenciador de bancos de dados, o principal objetivo de se
utilizar a técnica de fail-over é
A criar um trigger de restauração do banco de dados a ser acionado antes da
ocorrência de uma falha.
B duplicar a estrutura de indexação de cada tabela presente no banco de dados.
C excluir os registros das tabelas que possuam valores nulos.
D substituir o nome das tabelas presentes no banco de dados por nomes
padronizados.
E manter o funcionamento do sistema na ocorrência de falhas no servidor
originalmente designado como o servidor principal.
Comentários: Dentro do contexto de um grupo de disponibilidade, as funções
primária e secundária das réplicas de disponibilidade, normalmente, são
intercambiáveis em um processo conhecido como failover. Existem três formas
de failover: failover automático (sem perda de dados), failover manual planejado
(sem perda de dados) e failover manual forçado (com possível perda de dados),
geralmente chamado de failover forçado. Os failovers automáticos e manuais
planejados preservam todos os seus dados. Um grupo de disponibilidade faz
failover no nível da réplica de disponibilidade. Ou seja, um grupo de
disponibilidade realiza failover em uma de suas réplicas secundárias (o destino
de failover atual).
O failover é a capacidade de determinado sistema/serviço migrar
automaticamente para outro servidor, sistema ou rede redundante, ou que está
16712855225

em standby quando da ocorrência de uma falha ou término anormal do servidor,

do sistema ou da rede que estava ativo até aquele instante. A ideia é reduzir ao
máximo o tempo de indisponibilidade mantendo o funcionamento do sistema na
ocorrência de falhas no servidor originalmente designado como o servidor
principal.
Gabarito: E

16. Ano: 2014 Banca: UFG Órgão: UEAP Prova: Analista de TI - Banco
de Dados

Prof. Thiago Rodrigues Cavalcanti

[Link] 38 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Em uma situação de falha, o Sistema Gerenciador de Banco de Dados (SGBD)

busca restaurar o banco de dados ao estado consistente mais recente antes do
momento da falha. Para realizar essa função, o sistema precisa manter
informações sobre as mudanças que foram aplicadas aos itens de dados pelas
diversas transações. Tais mudanças são armazenadas no
A catálogo do banco de dados.
B arquivo de log do banco de dados.
C dicionário do banco de dados.
D arquivo de metadados do banco de dados.
Comentários: Para fazer o rolamento para frente dos dados sobre a base é
preciso que esses dados estejam armazenados no arquivo de log do banco de
dados. Desta forma, podemos marcar o gabarito na alternativa B. Vejam que
todas as demais alternativas são sinônimas, logo ou todas estão erradas ou
corretas. Neste caso, todas estão erradas.
Gabarito: B

17. Ano: 2014 Banca: UFG Órgão: UEAP Prova: Analista de TI - Banco
de Dados
As operações refazer (REDO) e desfazer (UNDO) são usadas no processo de
recuperação de banco de dados. Na recuperação baseada em atualização adiada,
os dados atualizados por uma transação não podem ser gravados no banco de
dados antes do commit da transação. O algoritmo para esse tipo de recuperação
é denominado
A UNDO/REDO.
B UNDO/NO-REDO.
C NO-UNDO/NO-REDO.
D NO-UNDO/REDO.
Comentários: Já entendemos como as operações de UNDO e REDO funcionam.
Agora vamos falar sobre como a atualização imediata ou a atualização adiada
16712855225

afetam o uso dessas operações. Vamos entender os conceitos.

Quando estamos falando da atualização adiada o processo de recuperação usa
duas listas de transações: as transações acabadas desde o último checkpoint e
as transações ativas. Aplica-se a operação REDO para todas as operações de
escrita das transações acabadas no log, na ordem na qual elas foram gravadas.
As transações ativas e não acabadas são canceladas e devem ser re-submetidas.
Desta forma não realizamos a operação de UNDO.
Veja que a questão trata do algoritmo, neste caso não temos a operação de
UNDO, mas utilizamos a de REDO. O algoritmo é conhecido como NO-
UNDO/REDO.
As outras opções de algoritmos são baseadas na atualização imediata. O
primeiro seria o Undo/No-Redo, se a técnica de recuperação garante que todas
as atualizações são gravadas no BD (disco) antes do commit da transação, não é

Prof. Thiago Rodrigues Cavalcanti

[Link] 39 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

necessário REDO. Vamos apenas fazer o UNDO das operações que estavam em
execução e não foram efetivadas.
A segunda opção para de algoritmo baseada na atualização imediata é
denominada: Undo/Redo, se as modificações são gravadas no BD (disco) depois
do commit da transação. Este é um caso bem mais geral e mais complexo onde
devemos executar as operações de UNDO e REDO.
Vejam que pelo exposto nossa resposta está na alternativa D.
Gabarito: D

18. Ano: 2013 Banca: BIO RIO Órgão: ELETROBRAS Prova: Analista
de Sistemas - Infraestrutura de Rede e Suporte Técnico
Leia o fragmento a seguir, relacionado aos modos operacionais de “Alta
Disponibilidade” no SQL Server 2008, instalado no sistema operacional Windows
2008.
“(1) High ___________ Mode: fornece transferência síncrona durável entre os
bancos de dados principal e espelho, assim como a detecção de falha automática
e o failover automático;
(2) High ___________ Mode: usa transferência de dados assíncrona e um banco
de dados principal e um espelho, mas não precisa de um servidor testemunha
(witness), fornece uma configuração standby warm que não suporta detecção de
failover automático;
(3) High ___________ Mode: transfere as transações no modo síncrono, mas
não tem um servidor testemunha (witness), o que impede o failover automático
para o espelho no caso de uma falha do principal.”
As lacunas são corretamente preenchidas respectivamente por:
A Availability – Security – Performance;
B Availability – Performance – Security;
C Security – Performance – Availability;
D Performance – Availability – Security;
16712855225

E Performance – Security – Availability.

Comentários: Estamos tratando da disponibilidade, performance e segurança,
respectivamente.
Gabarito: B

19. Ano: 2012 Banca: CESPE Órgão: BANCO DA AMAZÔNIA Prova:

Técnico Científico - Administrador de Dados
Julgue os itens que se seguem, relativos aos procedimentos de backup de banco
de dados.

Prof. Thiago Rodrigues Cavalcanti

[Link] 40 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

[1] A fim de que a recuperação de um banco de dados seja capaz de recompor

todos os dados sem nenhuma perda em caso de falha, é necessário que seja
realizado backup do log de transações ativas.
[2] O uso de backups diferenciais em conjunto com backups de log de transação
reduz o tempo de restauração do banco de dados em caso de falha,
comparando-se a situações em que os backups diferenciais não tenham sido
criados.
Comentários: O log é pré-requisito para conseguirmos avançar a recuperação
até o estado atual, sem perda de dados. Assim, a alternativa 1 está correta.
A ideia da alternativa 2, que também está correta, é que você possa visualizar
que se um banco de dados passou por um backup diferencial, a recuperação
dele, comparada com um banco que possui apenas o arquivo de log desde o
último backup full é mais rápida. Por isso, a alternativa está correta.
Gabarito: C C

20. Ano: 2010 Banca: FCC Órgão: TCE-SP Prova: Agente da

Fiscalização Financeira - Produção e Banco de Dados
Tratando-se do algoritmo ARIES, quando o gerenciador de recuperação é
invocado após uma falha, o reinício se procede em fases. A identificação das
páginas sujas no buffer pool e das transações ativas no momento da falha
pertence à fase de
A preempção.
B refazer.
C lock.
D análise.
E correção.
Comentários: Essa e as próximas três questões tratam do algoritmo de AIRES
para recuperação após uma falha. O ARIES é um algoritmo de recuperação que
é projetado para trabalhar com uma abordagem de “roubar” e “não forçar”. Ele
está baseado em três conceitos: registro adiantado em log, repetição de
16712855225

histórico durante o refazer e mudanças do log durante o desfazer.

Repetição de histórico significa que o ARIES relê todas as ações tomadas pelo
sistema de banco de dados antes da queda para reconstruir seu estado quando a
queda ocorreu. Transações que não foram efetivadas em tempo de queda, as
transações ativas são desfeitas.
Usar log durante o desfazer evitará que o ARIES torne a desfazer operações já
desfeitas, caso ocorra uma falha durante a recuperação, com consequente
reinício do processo de recuperação.
Quando o gerenciador de recuperação é invocado após uma falha, o reinício se
procede em três fases:
Fase de Análise (1): identifica páginas sujas no buffer e transações ativas no
momento da falha. Essa é nossa resposta para a questão acima.

Prof. Thiago Rodrigues Cavalcanti

[Link] 41 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Fase de Refazer (2): repete todas as ações, começando do ponto apropriado no

log e restaura o estado da base de dados idêntico ao momento da falha.
Fase de Desfazer (3): desfaz as ações das transações que não realizaram o
commit, de forma que a base de dados reflita apenas as ações das transações
que realizaram o commit.
Gabarito: D

21. Ano: 2013 Banca: IADES Orgão: CAU Cargo: Analista de

Infraestrutura de TI
QUESTÃO 48 Acerca dos conceitos de recuperação de bancos, assinale a
alternativa correta em relação ao método de recuperação ARIES.
(A) Para reduzir o tempo gasto na recuperação, é necessário aumentar o
overhead do ponto de verificação.
(B) Não permite o registro de savepoints.
(C) Não armazena operações de exclusão no log.
(D) Sua principal desvantagem é o aumento significativo da quantidade de
informações redundantes registradas no log.
(E) Possui o recurso denominado de independência de recuperação, isto é,
recupera uma página em caso de falha sem interromper a execução de outras
transações nas demais páginas.
Comentários: Pela explicação apresentada na questão anterior podemos
perceber que as alternativas A, B, C e D estão incorretas. Restando apenas a
letra E que é a nossa resposta.
Gabarito: E

22. Ano: 2010 Banca: FCC Órgão: TCE-SP Prova:

16712855225
Agente da
Fiscalização Financeira - Produção e Banco de Dados
As fases de operação do algoritmo ARIES são em número de
A1
B2
C3
D4
E5
Comentários: Vimos no comentário da questão anterior que o algoritmo tem
três fases.
Gabarito: C

Prof. Thiago Rodrigues Cavalcanti

[Link] 42 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

23. Ano: 2010 Banca: FCC Órgão: TCE-SP Prova: Agente da

Fiscalização Financeira - Produção e Banco de Dados
O sistema ARIES é considerado um adequado mecanismo de recuperação de BD,
pois
I. fornece alto grau de paralelismo.
II. usa a abordagem não-tomar-memória e forçar escrita.
III. reduz a sobrecarga na operação de registro no histórico-de-ocorrências.
IV. minimiza o tempo de recuperação.
Está correto o que consta em
A I e II, apenas.
B I e III, apenas.
C I, III e IV, apenas.
D II, III e IV, apenas.
E I, II, III e IV.
Comentários: A alternativa II, a única incorreta do texto do enunciado trocou
as características do algoritmo. O ARIES é um algoritmo de recuperação que é
projetado para trabalhar com uma abordagem de “roubar memória” e “não
forçar escrita”. Sendo assim a alternativa C é nossa resposta.
Gabarito: C

24. Ano: 2014 Banca: CESGRANRIO Órgão: BANCO DA AMAZÔNIA

Prova: Técnico Científico - Banco de Dados
Uma empresa, que só trabalha nos dias úteis, de 8 h às 17 horas, decidiu fazer o
seu plano de backup do SGBD Oracle da seguinte forma, sempre após as 19
horas: 16712855225

segunda-feira: backup incremental diferencial nível 1

terça-feira: backup incremental diferencial nível 1
quarta-feira: backup incremental cumulativo nível 1
quinta-feira: backup incremental diferencial nível 1
sexta-feira: backup incremental nível 0
sábado: backup completo (full-backup)
Caso ocorra uma falha com perda total da base durante a quinta-feira, qual o
conjunto mínimo de backups que a empresa deve usar para montar a base como
estava na quinta-feira no início do expediente?
A quarta-feira, apenas

Prof. Thiago Rodrigues Cavalcanti

[Link] 43 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

B sábado e quarta-feira, apenas

C sexta-feira e quarta-feira, apenas
D sábado, segunda-feira, terça-feira e quarta-feira
E sexta-feira, segunda-feira, terça-feira e quarta-feira
Comentários: No Oracle, quando fazemos backups utilizando o RMAN, além da
opção do backup FULL, temos também a opção de utilizarmos os backups
incrementais. No RMAN, o termo "backup incremental" é utilizado para fazer
referência a dois tipos: incremental diferencial e incremental cumulativo. O
backup incremental inicial é conhecido como backup Nivel-0 (nível zero). Cada
backup incremental realizado após o inicial é chamado de backup Nivel-1 (nível
um). Os backups incrementais Nivel-1 podem ser cumulativos ou diferenciais:
O backup incremental cumulativo registra todos os blocos alterados tendo
como referência o último backup Nivel-0.
O backup incremental diferencial registra todos os blocos alterados tendo
como referência o último backup incremental, seja ele um backup
incremental Nivel-0 ou Nivel-1.
Vejam que o backup cumulativo, feito na quarta-feira, registra todos os blocos
alterados desde o último backup nível-0, desta forma, se observarmos os
backups podemos chegar à conclusão que precisamos do backup da sexta-feira
anterior que é nível zero, e do backup feito na quarta. Por isso, nossa resposta
encontra-se na alternativa C.
Gabarito: C

25. Ano: 2012 Banca: CESPE Órgão: BANCO DA AMAZÔNIA Prova:

Técnico Científico - Administrador de Dados
Julgue os itens que se seguem, relativos aos procedimentos de backup de banco
de dados.
[1] Os procedimentos de recuperação de um banco de dados devem prever uma
sequência de operações que se inicie com a restauração de um backup
diferencial, quando ele existir. 16712855225

Comentários: Um backup diferencial prever a existência de pelo menos um

backup completo anterior, desta forma a afirmação acima encontra-se incorreta.
Gabarito: E

26. Ano: 2015 Banca: CESPE Órgão: MEC Prova: Técnico de Nível
Superior - ANALISTA DE SEGURANÇA
Com relação aos sistemas de becape, julgue os itens que se seguem.
[1] Um becape completo consiste na cópia de todos os arquivos para a mídia de
becape.

Prof. Thiago Rodrigues Cavalcanti

[Link] 44 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Comentários: Questão apresenta uma definição simples de bacape, podendo

ser considerada verdadeira.
Gabarito: C

16712855225

Prof. Thiago Rodrigues Cavalcanti

[Link] 45 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Questões Extras

27. Ano: 2014 Banca: CESPE Órgão: TC-DF Prova: Analista de

Administração Pública - Sistemas de Tecnologia da Informação
Julgue os seguintes itens, acerca de sistemas de gerenciamento de bancos de
dados (SGBD) e de cópias de segurança de dados.
[1] No caso de a atualização de dados ocorrer com frequência e de esses dados
serem considerados de alto valor, recomenda-se a implementação de becapes
diferenciais.

Gabarito: C

28. Ano: 2014 Banca: CESPE Órgão: TJ-SE Prova: Analista Judiciário -
Banco de Dados
No que se refere a becape e restauração de dados, julgue os próximos itens.
[1] Mesmo com a realização de becapes totais e incrementais dos bancos de
dados, é possível haver perda de dados em casos de desastres.
[2] O becape total de um banco de dados permite que esse banco seja
restaurado a qualquer ponto temporal específico.

Gabarito: C E

29. Ano: 2013 Banca: CESPE Órgão: CRPM Prova: Analista em

16712855225

Geociências - Sistemas de Informação

A respeito de becape e restore, julgue os itens seguintes.
[1] Considere que, em uma empresa, seja realizado becape de segunda-feira a
sexta-feira. Considere, ainda, que seja executado becape completo na segunda-
feira e que sejam executados becapes do tipo incremental de terça-feira a sexta-
feira. Nessa situação, o becape realizado na quinta-feira não contemplará os
dados do becape realizado na segunda-feira, mas contemplará os dados que
foram modificados na quinta-feira.
[2] Se, na realização de becape completo do servidor de uma rede de
computadores, o tamanho total dos dados for igual a 1,9 TB, não havendo
nenhuma compressão, então, para atender a essa demanda, deve-se utilizar
uma fita LTO2.

Prof. Thiago Rodrigues Cavalcanti

[Link] 46 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Gabarito: C E

30. Ano: 2013 Banca: CESPE Órgão: BACEN Prova: Analista do BACEN
- Suporte à Infraestrutura de Tecnologia da Informação
Julgue o item que se segue, relativo às cópias de segurança.
[1] Tanto o becape incremental, quanto o diferencial copiam arquivos criados ou
alterados desde o último becape normal, e o becape incremental não desmarca o
atributo de arquivo.

Gabarito: E

31. Ano: 2015 Banca: FGV Órgão: TCE-SE Prova: Analista de

Tecnologia da Informação - Segurança da Informação
Restaurar a operação de um sistema para recuperá-lo de um desastre e
armazenar arquivos com baixa probabilidade de serem utilizados novamente são
algumas das motivações para desenvolver um procedimento efetivo de backup.
Em relação às estratégias de backup, analise as afirmativas a seguir:
I - A deduplicação de dados é uma maneira eficiente de reduzir a quantidade de
armazenamento, principalmente em relação a dados de backup e de
arquivamento.
II - Backup incremental contém todos os arquivos modificados desde o último
backup completo, possibilitando executar uma restauração completa somente
com o último backup completo e o último backup incremental.
III - Quando a janela de backup é curta e a quantidade de dados a serem
copiados é grande, a gravação do backup deve ser feita em fita magnética.
Está correto o que se afirma em:
A somente I; 16712855225

B somente II;
C somente III;
D somente I e III;
E I, II e III.

Gabarito: A

Prof. Thiago Rodrigues Cavalcanti

[Link] 47 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

32. Ano: 2015 Banca: FGV Órgão: TCE-SE Prova: Analista de

Tecnologia da Informação - Suporte Técnico em Infraestrutura e
Redes
O administrador de sistemas de uma empresa precisa desenvolver um
procedimento de backup efetivo que leve em consideração as seguintes
características:
 Permitir a recuperação de arquivos individuais e, quando necessário, a
recuperação de sistemas de arquivo inteiros de uma só vez.
 A janela de backup do data center é curta e a quantidade de dados a serem
copiados é grande.
 A cada execução, a rotina de backup deve copiar todos os arquivos
modificados desde o último backup completo.
A estratégia de backup mais adequada para atender a essas características é:
A backup diferencial e armazenamento em disco em um data center remoto com
um link de alta velocidade ao data center principal;
B backup diferencial e armazenamento em fita magnética no data center
principal da empresa;
C backup incremental e armazenamento em disco em um data center remoto
com um link de alta velocidade ao data center principal;
D backup incremental e armazenamento em fita magnética no data center
principal da empresa;
E backup incremental e armazenamento em disco no data center principal da
empresa.

Gabarito: A

33. Ano: 2014 Banca: CESGRANRIO Órgão: BANCO DA AMAZÔNIA

Prova: Técnico Científico - Suporte e Infraestrutura
No SQL Server, um backup diferencial captura os dados que mudaram desde o
16712855225

momento do último backup

A diferencial
B diferencial, apenas do mesmo plano de manutenção
C completo
D completo, apenas do mesmo plano de manutenção
E completo e diferencial
Comentários:
Gabarito: C

Prof. Thiago Rodrigues Cavalcanti

[Link] 48 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

34. Ano: 2013 Banca: CESGRANRIO Órgão: BNDES Prova: Analista de

Sistemas - Analista de Sistemas - Suporte
A restauração de dados pode utilizar diferentes tipos de backup, tais como
diferencial, incremental e completo. A esse respeito, considere as afirmações a
seguir.
I O backup incremental exige que antes seja realizado pelo menos um backup
diferencial.
II Os backups completo e diferencial, em uso combinado, exigem apenas os
conjuntos de backups diferenciais realizados desde o último backup completo.
III Os backups completo e incremental, em uso combinado, exigem o último
backup completo e todos os conjuntos de backups incrementais realizados desde
o último backup completo.
Está correto APENAS o que se afirma em
AI
B II
C III
D I e II
E II e III

Gabarito: C

16712855225

Prof. Thiago Rodrigues Cavalcanti

[Link] 49 de 50
 Cópias de segurança, restauração e recuperação.
Prof. Thiago Rodrigues Cavalcanti Aula 04

Considerações Finais

Chegamos ao final da nossa aula onde abordamos os assuntos relacionados

a copias de segurança, restauração e recuperação.

Esperamos que você tenha gostado e aprendido bastante sobre o assunto.

Até a próxima!

Thiago Cavalcanti

16712855225

Prof. Thiago Rodrigues Cavalcanti

[Link] 50 de 50