1. Semana da Computação
UFSCar
31/05 a 02/jun de 2010
Integridade de dados e
administração de segurança
em SGBDs
Prof. Daniel dos Santos Kaster
Dept. Computação – Universidade Estadual de Londrina (UEL)
dskaster@uel.br
Prof. Daniel dos Santos Kaster © 2010 1

2. Conteúdo
Introdução
integridade e consistência de dados
Segurança de dados
Disponibilidade de dados
Prof. Daniel dos Santos Kaster © 2010 2

3. Introdução
Na era da informação, os dados são a porção
mais valiosa das organizações.
Portanto, é preciso que estejam seguros e
disponíveis.
Além disso, o acesso aos dados precisa ser
eficiente, porém controlado, garantindo a
integridade.
Prof. Daniel dos Santos Kaster © 2010 3

4. Introdução
“O cofre não pode ser mais caro do que o tem
dentro.”
Prof. Daniel dos Santos Kaster © 2010 4

5. Existe diferença entre desenvolver e
desenvolver!
Prof. Daniel dos Santos Kaster © 2010 5

6. Existe diferença entre desenvolver e
desenvolver!
Desenvolver um aplicativo
Prof. Daniel dos Santos Kaster © 2010 6

7. Existe diferença entre desenvolver e
desenvolver!
Desenvolver um aplicativo
Desenvolver um aplicativo que funcione
Prof. Daniel dos Santos Kaster © 2010 7

8. Existe diferença entre desenvolver e
desenvolver!
Desenvolver um aplicativo
Desenvolver um aplicativo que funcione
Desenvolver um aplicativo que funcione e seja
robusto com relação ao seu uso típico
Prof. Daniel dos Santos Kaster © 2010 8

9. Existe diferença entre desenvolver e
desenvolver!
Desenvolver um aplicativo
Desenvolver um aplicativo que funcione
Desenvolver um aplicativo que funcione e seja
robusto com relação ao seu uso típico
Desenvolver um aplicativo que funcione e seja
robusto com relação ao seu uso típico e tentativas de
uso malicioso
Prof. Daniel dos Santos Kaster © 2010 9

10. Existe diferença entre desenvolver e
desenvolver!
Desenvolver um aplicativo
Desenvolver um aplicativo que funcione
Desenvolver um aplicativo que funcione e seja
robusto com relação ao seu uso típico
Desenvolver um aplicativo que funcione e seja
robusto com relação ao seu uso típico e tentativas de
uso malicioso
Desenvolver um aplicativo que funcione e seja
robusto com relação ao seu uso típico e tentativas de
uso malicioso e tenha alta disponibilidade
Prof. Daniel dos Santos Kaster © 2010 10

11. Conteúdo
Introdução ✓
integridade e consistência de dados
Segurança de dados
Disponibilidade de dados
Prof. Daniel dos Santos Kaster © 2010 11

12. Integridade e consistência de dados
Integridade
– Os dados armazenados devem respeitar as regras do
modelo de dados projetado para a aplicação
Prof. Daniel dos Santos Kaster © 2010 12

13. Integridade e consistência de dados
Integridade
– Os dados armazenados devem respeitar as regras do
modelo de dados projetado para a aplicação
Consistência
– Os dados têm que estar consistentes com relação aos
“objetos” reais aos quais correspondem no momento
em questão
Prof. Daniel dos Santos Kaster © 2010 13

14. Integridade de identidade
Garantem a unicidade de elementos em um
conjunto de elementos
Prof. Daniel dos Santos Kaster © 2010 14

15. Integridade de identidade
Garantem a unicidade de elementos em um
conjunto de elementos
Boas práticas
– Partir das restrições de unicidade inerentes ao
problema
Prof. Daniel dos Santos Kaster © 2010 15

16. Integridade de identidade
Garantem a unicidade de elementos em um
conjunto de elementos
Boas práticas
– Partir das restrições de unicidade inerentes ao
problema
– Garantir todas a unicidade de todas as chaves
candidatas
Prof. Daniel dos Santos Kaster © 2010 16

17. Integridade de identidade
Garantem a unicidade de elementos em um
conjunto de elementos
Boas práticas
– Partir das restrições de unicidade inerentes ao
problema
– Garantir todas a unicidade de todas as chaves
candidatas
– Usar chaves artificiais de forma adequada (geradores
e sequências)
Prof. Daniel dos Santos Kaster © 2010 17

18. Integridade de identidade
Garantem a unicidade de elementos em um
conjunto de elementos
Boas práticas
– Partir das restrições de unicidade inerentes ao
problema
– Garantir todas a unicidade de todas as chaves
candidatas
– Usar chaves artificiais de forma adequada (geradores
e sequências)
– Cuidado ao lidar com tipos de dados que admitem
variações (p. ex. maiúsculas e minúsculas)
Prof. Daniel dos Santos Kaster © 2010 18

19. Integridade de associações
Elementos do problema em geral são
representados de forma fragmentada no modelo
de dados. As associações entre tais fragmentos
tem que ser consistente.
Prof. Daniel dos Santos Kaster © 2010 19

20. Integridade de associações
Elementos do problema em geral são
representados de forma fragmentada no modelo
de dados. As associações entre tais fragmentos
tem que ser consistente.
Boas práticas
– Cuidado com afirmações do tipo: “se os dados sempre
são inseridos corretamente, por que gastar tempo
verificando as associações?”
Prof. Daniel dos Santos Kaster © 2010 20

21. Integridade de associações
Elementos do problema em geral são
representados de forma fragmentada no modelo
de dados. As associações entre tais fragmentos
tem que ser consistente.
Boas práticas
– Cuidado com afirmações do tipo: “se os dados sempre
são inseridos corretamente, por que gastar tempo
verificando as associações?”
– Modelar adequadamente a propagação de
atualizações nas associações
Prof. Daniel dos Santos Kaster © 2010 21

22. Integridade de domínio de dados
Todo dado tem um domínio especificado na
aplicação que deve ser respeitado
A maior parte do trabalho de análise de dados,
em geral, compreende tratar inconsistências
Prof. Daniel dos Santos Kaster © 2010 22

23. Integridade de domínio de dados
Todo dado tem um domínio especificado na
aplicação que deve ser respeitado
A maior parte do trabalho de análise de dados,
em geral, compreende tratar inconsistências
Boas práticas
– Se o domínio é restrito, utilizar referências ou
verificações CHECK
Prof. Daniel dos Santos Kaster © 2010 23

24. Integridade de domínio de dados
Todo dado tem um domínio especificado na
aplicação que deve ser respeitado
A maior parte do trabalho de análise de dados,
em geral, compreende tratar inconsistências
Boas práticas
– Se o domínio é restrito, utilizar referências ou
verificações CHECK
– Definir tipos específicos de dados de acordo com a
necessidade
Prof. Daniel dos Santos Kaster © 2010 24

25. Integridade de domínio de dados
Todo dado tem um domínio especificado na
aplicação que deve ser respeitado
A maior parte do trabalho de análise de dados,
em geral, compreende tratar inconsistências
Boas práticas
– Se o domínio é restrito, utilizar referências ou
verificações CHECK
– Definir tipos específicos de dados de acordo com a
necessidade
– Usar as restrições de atributos adequadamente
Prof. Daniel dos Santos Kaster © 2010 25

26. Integridade de restrições complexas
Algumas aplicações possuem restrições
complexas que devem ser respeitadas
Dúvida comum: “tratar restrições complexas no
banco de dados ou na aplicação?”
Prof. Daniel dos Santos Kaster © 2010 26

27. Integridade de restrições complexas
Algumas aplicações possuem restrições
complexas que devem ser respeitadas
Dúvida comum: “tratar restrições complexas no
banco de dados ou na aplicação?”
Boas práticas
– Uso de assertions ou triggers
Prof. Daniel dos Santos Kaster © 2010 27

28. Uso adequado de transações
Transação: é a unidade lógica de processamento
em bancos de dados que engloba uma ou mais
operações de acesso ao banco de dados
(consulta ou atualização)
Prof. Daniel dos Santos Kaster © 2010 28

29. Uso adequado de transações
Transação: é a unidade lógica de processamento
em bancos de dados que engloba uma ou mais
operações de acesso ao banco de dados
(consulta ou atualização)
Propriedades ACID:
Atomicidade: ou tudo é executado, ou nada;
Consistência: leva o banco de dados de um estado
consistente a outro estado consistente;
Isolamento: a execução de uma transação não é afetada pela
execução de outras transações;
Durabilidade: as alterações feitas por uma transação comitada
são armazenadas no banco de dados.
Prof. Daniel dos Santos Kaster © 2010 29

30. Boas práticas no uso de transações
Prof. Daniel dos Santos Kaster © 2010 30

31. Boas práticas no uso de transações
Usá-las!!!
Prof. Daniel dos Santos Kaster © 2010 31

32. Boas práticas no uso de transações
Usá-las!!!
Atenção ao armazenar informações de objetos
fragmentadas em vários objetos do banco de
dados
Prof. Daniel dos Santos Kaster © 2010 32

33. Boas práticas no uso de transações
Usá-las!!!
Atenção ao armazenar informações de objetos
fragmentadas em vários objetos do banco de
dados
Definir adequadamente o nível de isolamento
Prof. Daniel dos Santos Kaster © 2010 33

34. Níveis de isolamento
O padrão SQL define níveis de isolamento,
considerando três fenômenos que devem ser
evitados em transações concorrentes:
dirty read: uma transação lê um dado de uma transação
concorrente não comitada;
nonrepeatable read: uma transação faz uma nova leitura em
um dado e obtém um valor diferente, modificado por outra
transação que comitou após a leitura inicial;
phantom read: uma transação re-executa uma consulta
retornando um conjunto de tuplas e obtém um conjunto
diferente, afetado por uma transação comitada após a
consulta inicial.
Prof. Daniel dos Santos Kaster © 2010 34

35. Níveis de isolamento
Os 4 níveis de isolamento definidos no padrão
SQL e seus comportamentos são os seguintes:
Dirty Nonrepeatable Phantom
read read read
Read uncommitted Sim Sim Sim
Read committed Não Sim Sim
Repeatable read Não Não Sim
Serializable Não Não Não
Prof. Daniel dos Santos Kaster © 2010 35

36. Boas práticas no uso de transações
Usá-las!!!
Atenção ao armazenar informações de objetos
fragmentadas em vários objetos do banco de
dados
Definir adequadamente o nível de isolamento
Usar savepoints em muitos casos facilita
Prof. Daniel dos Santos Kaster © 2010 36

37. Boas práticas no uso de transações
Usá-las!!!
Atenção ao armazenar informações de objetos
fragmentadas em vários objetos do banco de
dados
Definir adequadamente o nível de isolamento
Usar savepoints em muitos casos facilita
Usar bloqueios explícitos quando for o caso
LOCK TABLE; SELECT FOR UPDATE/SHARE
Prof. Daniel dos Santos Kaster © 2010 37

38. “To denormalize, or not to
denormalize: that is the question”
Um banco de dados normalizado minimiza
problemas de integridade e otimiza atualizações
– As alterações são feitas em relações simples e
tipicamente pequenas.
Porém, afeta o desempenho de consultas
– Para retornar um conjunto de dados associados é
preciso realizar mais junções
A pergunta é: quando desnormalizar?
Prof. Daniel dos Santos Kaster © 2010 38

39. Tipos comuns de desnormalização
Tabelas prejoined
Tabelas de relatórios
Tabelas particionadas ou replicadas
Replicação de atributos frequentemente
consultados
Prof. Daniel dos Santos Kaster © 2010 39

40. Existem boas práticas para
desnormalização? :-)
Um banco de dados só deve ser
desnormalizado quando a necessidade de
desempenho é determinante na aplicação.
Deve-se refletir sobre as seguintes questões:
– O sistema pode alcançar um desempenho aceitável
sem ser desnormalizado?
– O desempenho do sistema depois da
desnormalização ainda será inaceitável?
– O sistema será menos confiável após a
desnormalização?
Prof. Daniel dos Santos Kaster © 2010 40

41. Se for realmente necessário
desnormalizar, documente!
Toda decisão de desnormalização deve ser
documentada.
Não tente criar um modelo conceitual
desnormalizado. O modelo conceitual deve ser
normalizado, com documentação sobre as
decisões de desnormalização no modelo físico.
Prof. Daniel dos Santos Kaster © 2010 41

42. Boa prática: usar visões
materializadas
Uma visão é uma tabela computada a partir de
tabelas armazenadas de acordo com uma
instrução de seleção
– Uma visão computada é gerada a cada acesso
– Uma visão materializada é gerada e armazenada no
banco
Exige atualização mediante atualizações nas tabelas base
Rápido acesso aos resultados, pois já estão computados
Prof. Daniel dos Santos Kaster © 2010 42

43. Visões materializadas são suas
amigas!
O seu SGBD suporta visões materializadas?
Prof. Daniel dos Santos Kaster © 2010 43

44. Visões materializadas são suas
amigas!
O seu SGBD suporta visões materializadas?
– O otimizador de consultas pode usar a visão
materializada para reescrever consultas
Prof. Daniel dos Santos Kaster © 2010 44

45. Visões materializadas são suas
amigas!
O seu SGBD suporta visões materializadas?
– O otimizador de consultas pode usar a visão
materializada para reescrever consultas
– As aplicações podem estar em produção
Prof. Daniel dos Santos Kaster © 2010 45

46. Visões materializadas são suas
amigas!
O seu SGBD suporta visões materializadas?
– O otimizador de consultas pode usar a visão
materializada para reescrever consultas
– As aplicações podem estar em produção
O seu SGBD não suporta?
Prof. Daniel dos Santos Kaster © 2010 46

47. Visões materializadas são suas
amigas!
O seu SGBD suporta visões materializadas?
– O otimizador de consultas pode usar a visão
materializada para reescrever consultas
– As aplicações podem estar em produção
O seu SGBD não suporta?
– Que tal ajudar a desenvolver? ;-)
Prof. Daniel dos Santos Kaster © 2010 47

48. Conteúdo
Introdução ✓
integridade e consistência de dados ✓
Segurança de dados
Disponibilidade de dados
Prof. Daniel dos Santos Kaster © 2010 48

49. Gerência de usuários
Tem que estar de acordo com a política de
segurança da organização.
É preciso definir padrões de acesso e de
recursos que garantam a integridade dos dados
e a segurança de dados confidenciais.
Prof. Daniel dos Santos Kaster © 2010 49

50. Mecanismos de controle de acesso
Há dois tipos básicos de mecanismos de
controle de acesso:
– Discricionário: concessão de privilégios a usuários
sobre objetos do banco de dados
– Mandatório: definição de níveis de segurança para
usuários e objetos para implementar a política de
segurança da organização
Prof. Daniel dos Santos Kaster © 2010 50

51. Controle de acesso discricionário
Concessão de privilégios em nível de:
Conta (ou sistema): create, alter, drop
Objetos: select, insert, delete, update, execute
Conjuntos de privilégios são agrupados em
atribuições para facilitar a administração
CREATE ROLE
Prof. Daniel dos Santos Kaster © 2010 51

52. Concessão/revogação de
privilégios
Privilégios de sistema
Grant <privilegio_sist>|<role> to <user>|<role> [with admin
option];
Revoke <privilegio_sist>|<role> from <user>;
GRANT create table TO jward;
GRANT connect TO jward WITH ADMIN OPTION;
Prof. Daniel dos Santos Kaster © 2010 52

53. Concessão/revogação de
privilégios
Privilégios de objetos
Grant <privilegio_obj> (<atributo>) on <esquema>.<objeto> to
<user>|<role> [with grant option];
Revoke <privilegio_sist> on <esquema>.<objeto> from <user>;
GRANT select,insert ON jward.projetos TO public;
GRANT select, update(nome) ON jward.empregado TO
willy WITH GRANT OPTION;
Prof. Daniel dos Santos Kaster © 2010 53

54. Controle de acesso mandatório
Cada usuário ou objeto está classificado em um
nível
Modelo Bell-LaPadula
Níveis: Top Secret (TS), Secret (S), Confidential (C) e
Unclassified (U)
Raras aplicações comerciais
– Oracle Label Security
Prof. Daniel dos Santos Kaster © 2010 54

55. Fluxo de informações no controle
de acesso mandatório
Um usuário U pode ler um objeto O somente se
classe(S) >= classe(O)
Prof. Daniel dos Santos Kaster © 2010 55

56. Fluxo de informações no controle
de acesso mandatório
Um usuário U pode ler um objeto O somente se
classe(S) >= classe(O)
Um usuário U pode escrever um objeto O
somente se classe(S) <= classe(O)
Evita fluxo de informações de níveis de segurança
superiores para níveis inferiores
Prof. Daniel dos Santos Kaster © 2010 56

57. Fluxo de informações no controle
de acesso mandatório
Um usuário U pode ler um objeto O somente se
classe(S) >= classe(O)
Um usuário U pode escrever um objeto O
somente se classe(S) <= classe(O)
Evita fluxo de informações de níveis de segurança
superiores para níveis inferiores
– Atributos/tuplas sem permissão podem aparecer com
null ou “poli-instanciados”
Prof. Daniel dos Santos Kaster © 2010 57

58. Segurança de dados
A segurança de um sistema só é efetiva se está
implantada em todos os seus níveis
– Segurança física
– Segurança de sistema operacional
– Segurança do SGBD
– Segurança da rede
– Segurança da aplicação
Prof. Daniel dos Santos Kaster © 2010 58

59. Segurança física
O nível mais básico de segurança é a
segurança física do servidor de banco de dados
Acessos ao console devem ser restritos
A informação está nos dispositivos físicos que
devem ser resguardados
– Cuidado com as mídias de backup!
Prof. Daniel dos Santos Kaster © 2010 59

60. Segurança de sistema operacional
Aplicar atualizações e patches do sistema
operacional
Executar os processos do banco de dados com
uma conta própria
– Restrição de acesso à conta que possui os arquivos
do banco
– Proteção dos arquivos do banco
Auditoria de logs
– Utilizar um servidor de log
Prof. Daniel dos Santos Kaster © 2010 60

61. Segurança de SGBD
Autenticação
Definição de privilégios
Criptografia
Auditoria
Prof. Daniel dos Santos Kaster © 2010 61

62. Mecanismos de autenticação
Mecanismos de autenticação
– Autenticação Interna: um usuário do banco por usuário
da aplicação;
– Autenticação Externa: um usuário do banco por
usuário da aplicação com autenticação externa;
– Autenticação via Aplicação: um usuário do banco para
todos os usuários da aplicação;
Prof. Daniel dos Santos Kaster © 2010 62

63. Mecanismos de autenticação
Autenticação Interna
– Prós
Distinção de que usuários estão conectados
Auditoria consistente
– Contras
DBA tem que criar os usuários
Usuários podem conectar diretamente ao banco
Prof. Daniel dos Santos Kaster © 2010 63

64. Mecanismos de autenticação
Autenticação Externa
– Prós
Os mesmos da autenticação interna
Criação de usuários fica a cargo do administrador de sistemas
Os usuários utilizam uma única conta para usar vários
sistemas
– Contras
É mais difícil de configurar
Violações de contas de rede comprometem a segurança do
banco
Prof. Daniel dos Santos Kaster © 2010 64

65. Mecanismos de autenticação
Autenticação via Aplicação
– Prós
Bom para muitos usuários em operações não críticas
– Contras
O controle de acesso tem que ser garantido pela aplicação
Auditoria tem que ser implementada na aplicação
Prof. Daniel dos Santos Kaster © 2010 65

66. Boas práticas para autenticação de
usuários
Utilizar senhas criptografadas
Utilizar funções de reforço de senha
Desabilitar contas desnecessárias e/ou sem senha
Definir adequadamente os privilégios de sistema e de
acesso ao catálogo do banco
Prof. Daniel dos Santos Kaster © 2010 66

67. Segurança de rede
Utilizar tráfego criptografado de senhas
Desabilitar serviços e compartilhamentos que não forem
estritamente necessários
Não colocar arquivos do banco em compartilhamentos
publicados
Colocar o servidor de banco de dados atrás de um
firewall
Utilizar VPN (Virtual Private Networks) quando um canal
seguro for necessário
Controlar o acesso dos usuários internos da organização
Prof. Daniel dos Santos Kaster © 2010 67

68. Segurança de aplicação
Validar as entradas dos usuários para evitar a
injeção de SQL
Toda entrada de dados é suspeita!
Boas práticas
– Usar funções de scape de caracteres especiais
– Fornecer dados por meio de parâmetros para as
instruções SQL (binding)
Prof. Daniel dos Santos Kaster © 2010 68

69. Mais boas práticas de segurança
de aplicação
Utilizar usuários com privilégios distintos para conexão
com o banco de dados de acordo com o nível de acesso
na aplicação
Nunca fazer conexão da aplicação como usuário
privilegiado
Utilizar tráfego criptografado de informações
Tratar adequadamente erros e warnings emitidos pelo
banco
Prof. Daniel dos Santos Kaster © 2010 69

70. Auditoria de acesso aos dados
É fundamental adotar uma política adequada de
monitoramento dos acessos aos dados
– Identificar situações atípicas.
– Detectar ações mal intencionadas.
– Detectar falhas de segurança.
Prof. Daniel dos Santos Kaster © 2010 70

71. Esquemas de auditoria
Alguns SGBDs fornecem pacotes de
funcionalidades para auditoria
Ex: instrução AUDIT no Oracle
Implementar triggers de auditoria
Implementar scripts de verificação periódica de
consistência
Prof. Daniel dos Santos Kaster © 2010 71

72. Auditar é chato, mas necessário!
Há também outras fontes fundamentais para a
auditoria
– Arquivos de log do SGBD
– Arquivos de log do SO
As aplicações também devem gerar
informações de auditoria e suporte!
Auditoria em excesso pode causar degradação
desnecessária de desempenho do SGBD e
dificuldade de interpretação dos resultados
Prof. Daniel dos Santos Kaster © 2010 72

73. Conteúdo
Introdução ✓
integridade e consistência de dados ✓
Segurança de dados ✓
Disponibilidade de dados
Prof. Daniel dos Santos Kaster © 2010 73

74. Garantir a disponibilidade do
sistema
Disponibilidade é a condição em que um recurso
pode ser acessado pelos seus consumidores
Disponibilidade e desempenho são diferentes e
devem ser tratadas pelo DBA como assuntos
distintos
Disponibilidade compreende gerenciabilidade,
recuperabilidade e confiabilidade
Prof. Daniel dos Santos Kaster © 2010 74

75. Garantir a disponibilidade do
sistema (cont.)
Questões
– Qual é o custo de downtime da organização?
– “Quanto” de disponibilidade é o suficiente?
Com o advento da internet, o uptime de muitas organizações
tornou-se contínuo
Eventuais problemas são possíveis e não
acontecem somente com os outros
– Falhas de instância, hardware, energia, ...
– Falhas catastróficas
– Falhas humanas
Prof. Daniel dos Santos Kaster © 2010 75

76. Redundância é importante!
Redundância é importante!
– redundância é importante!
redundância é importante!
– redundância é importante!
redundância é importante!
redundância é importante!
Prof. Daniel dos Santos Kaster © 2010 76

77. Disponibilidade de armazenamento
Há várias alternativas
– Discos isolados
– RAID
– Storages
É preciso encontrar a melhor relação custo-
benefício
Prof. Daniel dos Santos Kaster © 2010 77

78. RAID
A taxa de aumento da performance dos discos
rígidos tem sido consideravelmente inferior ao
das memórias e dos microprocessadores
(limitações mecânicas).
O conceito de RAID (Redundant Array of
Inexpensive/Independent Disks) consiste em
organizar conjuntos de discos para uso em
paralelo para reduzir esta lacuna de
desempenho.
Desempenho (stripping)
Redundância (espelhamento/paridade)
Prof. Daniel dos Santos Kaster © 2010 78

79. Storages
Uma Storage Area Network (SAN) é uma
arquitetura para conectar dispositivos de
armazenamento, tais como arrays de discos e
jukeboxes, de forma que para o sistema
operacional apareçam como se estivessem
localmente conectados.
– Protocolos mais utilizados
SCSI paralelo (tradicional)
Fibre channel (rede gigabit sobre cabos óticos ou par
trançado)
iSCSI – SCSI serial sobre TCP/IP
Prof. Daniel dos Santos Kaster © 2010 79

80. Storages
Exemplo: Dell CX4-960 SAN
Prof. Daniel dos Santos Kaster © 2010 80

81. Storages
Novas portas podem ser adicionadas ao array
Portas 4Gbit Fibre Channel e 1Gbit iSCSI em um único array
Capacidade de conexão de até 512 servidores
Fibre Channel iSCSI
Prof. Daniel dos Santos Kaster © 2010 81

82. Storages
5 a 960 drives (até 950TB!!!)
1 drive flash, com desempenho
equivalente a 30 Fibre Channel
Prof. Daniel dos Santos Kaster © 2010 82

83. Só Jesus salva! Então faça backup!
Algumas vezes a única forma de recuperar o
sistema de uma falha é restabelecer o backup
do sistema
É tarefa do DBA definir e implementar uma
política adequada de backup
– Backup completo
– Backup incremental
– Arquivamento dos arquivos de log de
transações
Prof. Daniel dos Santos Kaster © 2010 83

84. Procedimentos de backup
Definir a periodicidade do backup e agendar
Definir estratégia de verificação da integridade do
backup
Definir a metodologia de recuperação do backup
Tempo de recuperação faz parte do contrato! ;-)
Definir a estratégia de descarte, quando usada
Testar regularmente o sistema e arquivos de backup
Prof. Daniel dos Santos Kaster © 2010 84

85. Semana da Computação
UFSCar
31/05 a 02/jun de 2010
Até que en Fim! :-)
Perguntas?
Prof. Daniel dos Santos Kaster
Dept. Computação – Universidade Estadual de Londrina (UEL)
dskaster@uel.br
Prof. Daniel dos Santos Kaster © 2010 85