Você está na página 1de 16

SISTEMAS DE BANCO

DE DADOS

Nome: Gustavo Nbrega RA: 532894


Prof. Emerson Alberto Marconato

Marlia
2015

SUMRIO
1.

2.

3.

4.

ORACLE .................................................................................................................................. 3
1.1

Funcionamento Bsico .................................................................................................. 3

1.2

Ferramenta de Backup .................................................................................................. 5

1.3

Restaurao ................................................................................................................... 6

1.4

Poltica de Backup ......................................................................................................... 7

MYSQL ................................................................................................................................... 8
2.1

Funcionamento Bsico .................................................................................................. 8

2.2

Ferramenta de Backup .................................................................................................. 8

2.3

Restaurao ................................................................................................................... 9

2.4

Poltica de Backup ......................................................................................................... 9

SQL SERVER ......................................................................................................................... 11


3.1

Funcionamento Bsico ................................................................................................ 11

3.2

Ferramenta de Backup ................................................................................................ 12

3.3

Restaurao ................................................................................................................. 12

3.4

Poltica de Backup ....................................................................................................... 13

POSTGRE SQL....................................................................................................................... 14
4.1

Funcionamento Bsico ................................................................................................ 14

4.2

Ferramenta de Backup ................................................................................................ 15

4.3

Restaurao ................................................................................................................. 15

4.4

Poltica de Backup ....................................................................................................... 15

1. ORACLE

1.1 Funcionamento Bsico


Um banco de dados uma coleo de dados relacionados utilizada por uma ou
mais aplicaes informatizadas.
Fisicamente, um banco de dados Oracle um conjunto de arquivos em algum
lugar do disco. O local fsico desses arquivos irrelevante para as funes do
banco de dados, mas no para seu funcionamento.
Logicamente, o banco de dados Oracle dividido em um conjunto de contas de
usurio conhecido como schemas. Cada schema est associado a um ID de
usurio. Sem um nome de usurio, senha e privilgios vlidos, no possvel
acessar informaes do banco de dados.
O Oracle Server composto de duas partes bsicas:

Banco de Dados (Database)


Instncia (Instance)

O Banco de Dados representa os arquivos fsicos que armazenam os dados.


A Instncia composta pelas estruturas de memria e pelos processo de
segundo plano(background).
Cada Banco de Dados pode estar associado a uma Instncia. possvel que
mltiplas Instncias acessem um Banco de Dados, isto ocorre na configurao
conhecida como RAC Real Application Cluster.
O Banco de Dados possui uma estrutura fsica e uma estrutura lgica.
As estruturas lgicas representam os componentes que voc pode ver no
Banco de Dados Oracle (tabelas, ndices, etc.) e as estruturas fsicas
representam os mtodos de armazenamento utilizado internamente pelo Oracle
(os arquivos fsicos). O Oracle mantm separadamente as estruturas lgicas e
fsicas. Por isso, as estruturas lgicas podem ser idnticas independentemente
da plataforma de hardware ou do sistema operacional.

ESTRUTURAS LGICAS
O Oracle divide o Banco de Dados em unidades menores para gerenciar,
armazenar e recuperar os dados de forma eficiente. Os itens a seguir
apresentam um overview das estruturas lgicas. Posteriormente,
apresentaremos mais detalhes de cada uma delas.
TABLESPACES: O Banco de Dados est logicamente dividido, no nvel mais
alto, em estruturas menores chamadas Tablespaces. O DBA pode utilizar as
Tablespaces para organizar melhor o Banco de Dados (por aplicao, por
funo, por departamento, etc.). Esta diviso lgica ajuda a administrar uma
parte do Banco de Dados sem afetar outras. Cada Banco de Dados pode ter
uma ou mais Tablespaces. Quando voc cria um novo Banco de Dados, o
Oracle pelo menos uma Tablespace: SYSTEM.
BLOCKS: O Bloco a menor estrutura de armazenamento do Oracle. O
tamanho de um Bloco normalmente um mltiplo do tamanho de um Bloco do
Sistema Operacional. Um bloco de dados corresponde a um nmero especfico
de bytes. Seu tamanho baseado no parmetro DB_BLOCK_SIZE e
determinado quando o Banco de Dados criado.
EXTENTS: Formam o prximo nvel da estrutura lgica. So formados por um
agrupamento de blocos contguos.
SEGMENTS: Um Segmento composto por um conjunto de Extents alocados
para uma estrutura lgica: tabela, ndice, etc. Quando uma dessas estruturas
criada, o Oracle aloca um segmento contendo pelo menos um Extent, que por
sua vez dever conter pelo menos um Bloco. Um Segmento pode estar
associado a uma nica Tablespace. A figura a seguir apresenta a relao entre
Tablespaces, Segments, Extents e Blocks.

ESTRUTURAS FSICAS
A estrutura fsica de um Banco de Dados consiste em trs tipos de arquivos:
DATA FILES: Contm todos os dados do Banco. Cada Banco de Dados
formado por um ou mais Data Files. Cada Data File est associado a uma
nica Tablespace. Uma Tablespace pode consistir de um ou mais Data Files.
REDO LOG FILES: Gravam todas alteraes nos dados do Banco. O Oracle
possui dois ou mais desses arquivos, porque eles so gravados de forma
cclica. Atravs deles pode-se obter informaes sobre os dados alterados. So
fundamentais nas operaes de recovery. aconselhvel manter cpias
mltiplas destes arquivos de preferncia em discos diferentes.

CONTROL FILES: Cada Banco de Dados Oracle tem pelo menos um Control
File. Eles mantm informaes sobre a estrutura fsica do Banco de Dados. O
Oracle manter mltiplas cpias destes arquivos e recomenda-se esta prtica. O
Control File contm o nome do Banco de Dados e o timestamp de sua criao,
bem como os nomes e localizao de todos os Data Files e Redo Log Files.

1.2 Ferramenta de Backup


Falando diretamente de Oracle ns temos dois tipos de backups:
Backups Lgicos: Que contm dados e\ou definies de objetos. Um exemplo
comum de backup lgico o famoso export\import atravs do datapump pois
ele gera nada mais do que um arquivo binrio com as definies de estrutura,
ndices, grants, dados (e o que mais voc quiser) para importao.
Backups Fsicos: Que contm os arquivos fsicos do banco de dados como
datafiles, archive logs ou controlfiles.
Podem ser feitos pelo banco (RMAN ou manualmente com o BEGIN\END
BACKUP) ou diretamente pelo usurio administrador via servidor.
BACKUPS CONSISTENTES E INCONSISTENTES
Dentro dos backups fsicos ainda temos dois subtipos que tambm so muito
importantes.
- Backups Consistentes (tambm conhecidos como cold backup): Feitos com a
base desligada ou em modo mount.
Consiste basicamente em fazer um backup sem que a base esteja com
transaes ativas, garantindo assim que todas as transaes previamente
realizadas estejam consistentes.
A caracterstica deste tipo de backup que h a garantia de que todos os
SCNs esto idnticos, ou seja, todas as alteraes que estavam no redo log e
no buffer esto gravadas nos datafiles.
- Backups Inconsistentes (tambm conhecidos como hot backup): Feitos com a
base aberta e gerando transaes.
Como o banco est sendo constantemente utilizado antes, durante e depois do
backup os SCNs geralmente nunca batem (da o nome inconsistente), o que
faz o sistema depender dos archived logs para posterior recuperao.
Conforme podemos analisar das afirmaes certo que backups
inconsistentes necessitam que a base esteja em modo ARCHIVELOG.

1.3 Restaurao
Geralmente envolvem duas fases:
- Restaurar o arquivo fsico, que nada mais do que pegar o arquivo do backup
e deixar o mesmo disponvel para a database (conhecida como Fase de
Restore).
- Recuperar os dados aplicando os on-line\archived redo a fim de trazer a base
ao ponto mais atual antes de falha (conhecida como Fase de Recover).
No Oracle existem trs tipos bsicos de recuperao:
- Instance recovery:
Realizado pelo prprio banco aps uma queda anormal ou um shutdown abort,
feito com o objetivo de garantir a integridade dos dados, aplica no banco o
que est em redo (commitados) e da rollback no que estiver em undo (no
commitados). Neste processo no h interveno do usurio.
- Media recover:
a recuperao de algum arquivo que est danificado (devido a uma falha de
disco por exemplo).
Temos como casos de media recovery as recuperaes de SPfiles, datafiles ou
controlfiles.
Neste processo h interveno do usurio pois o sistema precisa receber as
informaes de o que restaurar e onde esto os dados de backup.
Uma vez recuperado o arquivo o sistema ir analisar se h a necessidade de
Recovery, se houver o mesmo ir realizar este passo sem interveno (A
menos que voc especifique que queira interferir como com o comando
RECOVER DATABASE UNTIL CANCEL).
Lembrando apenas que essa ao no realizada pelo RMAN. Pois o RMAN
no faz recuperao UNTIL CANCEL, somente LOG SEQUENCE, TIME ou
SCN.
- Recover Completo\Incompleto e Point-in-Time:
Recover completo o processo de trazer a base de dados para o momento
mais atual aps a falha, sem nenhuma perda dos dados commitados.

Por exemplo, voc teve um problema s 10 da manh, mas possui os backups


certinhos e os archives at antes da falha, ento, voc ir restaurar os arquivos
com problema e o sistema aplicar se necessrio os archives para trazer todos
os dados dos arquivos at 9:59, praticamente Zero de perda.
Porm nem sempre isto ser possvel, por exemplo, se voc precisa voltar um
DROP TABLE incorreto de um usurio que foi feito as 9:00 e agora j so
10:00 impossvel utilizar uma recuperao completa pois a mesma ir manter
as informaes do ltimo horrio.
Nestas situaes realizada uma operao de recover incompleto (tambm
conhecida como Point-in-Time) que voltar base a um SCN que no seja
ltimo para consertar um erro de usurio ou na falta de um archive.
Temos como uma opo ao Point-in-Time recovery (como no exemplo do
DROP TABLE ou de um UPDATE INCORRETO) a funcionalidade de
Flashback, porm no iremos abordar a mesma nestes artigos.

1.4 Poltica de Backup

Quando falamos de estratgia de backup, implicitamente estamos planejando


tambm uma estratgia de recovery.
No Oracle, quando fazemos backups utilizando o RMAN, alm da opo do
backup FULL, temos tambm a opo de utilizarmos os backups incrementais.
No RMAN, o termo "backup incremental" utilizado para fazer referncia a dois
tipos: incremental diferencial e incremental cumulativo. O backup incremental
inicial conhecido como backup Nivel-0 (nvel zero). Cada backup incremental
realizado aps o inicial chamado de backup Nivel-1 (nvel um). Os backups
incrementais Nivel-1 podem ser cumulativos ou diferenciais:

O backup incremental cumulativo registra todos os blocos alterados


tendo como referncia o ltimo backup Nivel-0.

O backup incremental diferencial registra todos os blocos alterados


tendo como referncia o ltimo backup incremental, seja ele um backup
incremental Nivel-0 ou Nivel-1.

2. MYSQL
2.1 Funcionamento Bsico

O MySQL um sistema gerenciador de banco de dados relacional de cdigo


aberto usado na maioria das aplicaes gratuitas para gerir suas bases de
dados. O servio utiliza a linguagem SQL (Structure Query Language
Linguagem de Consulta Estruturada), que a linguagem mais popular para
inserir, acessar e gerenciar o contedo armazenado num banco de dados.
Na criao de aplicaes web abertas e gratuitas, o conjunto de aplicaes
mais usado o LAMP, um acrnimo para Linux, Apache, MySQL e
Perl/PHP/Python. Nesse conjunto de aplicaes, inclui-se, respectivamente, um
sistema operacional, um servidor web, um sistema gerenciador de banco de
dados e uma linguagem de programao. Assim, o MySQL um dos
componentes centrais da maioria das aplicaes pblicas da Internet.

2.2 Ferramenta de Backup


A forma mais simples de fazer backup das bases de dados do MySQL
simplesmente salvar o contedo da pasta "/var/lib/mysql", criando um
arquivo.tar.gz ou mesmo copiando os arquivos diretamente para outra partio.
O maior problema que as bases de dados so alteradas continuamente
durante a operao do banco de dados, o que leva a cpias inconsistentes. Se
alguns dos arquivos dentro da pasta com a base mudam no meio da cpia, o
backup conter uma mistura de dados novos e antigos, uma receita para o
desastre.
A forma mais segura parar o servio do MySQL antes de fazer o backup,
garantindo assim que nada ser alterado durante a cpia, como no exemplo
abaixo:
# /etc/init.d/mysql stop
# tar -zcvf mysql.tar.gz /var/lib/mysql/
# /etc/init.d/mysql start
O problema nesse caso que o servio fica fora do ar durante alguns
segundos ou minutos. Se a base de dados usada pelo site da sua empresa,
por exemplo, ele ficar fora do ar at que o backup seja concludo e o servidor
MySQL volte a ser iniciado.

Voc pode agendar os backups usando o cron, para que eles sejam
executados durante a madrugada, por exemplo, mas, mesmo assim, voc vai
acabar sempre perdendo algumas visitas.
A segunda opo fazer um backup online, sem parar o servidor. O utilitrio
mais simples (e provavelmente o mais usado) para isso o mysqldump, que
acompanha o pacote principal do MySQL.
Diferente do mtodo anterior, onde os arquivos so copiados diretamente, o
mysqldump acessa o banco de dados por vias normais, da mesma forma que
um aplicativo qualquer faria.
Em outras palavras, ele no l os arquivos, mas sim as informaes
armazenadas nas bases de dados. Isso permite que o backup seja consistente,
mesmo que as bases de dados sejam alteradas durante o backup.

2.3 Restaurao
O processo de restaurar to simples quanto o de criar. Ao invs de usarmos
o mysqldump, usaremos o prprio mysql e invertendo o sinal de caminho.
Agora ser do arquivo .sql para o banco de dados.
mysql -h [servidor.mysql.com] -u [usuario] -p [database_name] < [arquivo-pararestaurar.sql]
2.4 Poltica de Backup
CONSISTNCIA E INTEGRIDADE
Aplicativos comerciais fazem grande uso de conceitos relacionais e
transacionais, em alguns casos a falha desses recursos invalida qualquer
informao presente no banco de dados. Por isso para estabelecer uma
poltica de backup importante ter em mente qual o tipo de aplicativo que
operado no banco de dados, quais so as caractersticas deste banco de
dados.
JANELA DE BACKUP
Se o backup for Online o banco de dados no precisa passar por uma
indisponibilidade total nem parcial, afinal o backup Online, se no for esse o
caso, voc precisar estabelecer uma janela de backup.

MONITORAMENTO
De nada adianta elaborar um plano de backup se esses backups no forem
averiguados, afinal erros ocorrem e preciso que algum intervenha nessas
falhas garantindo que a politica de backup funcione conforme planejado. Para
isso necessrio implantar um monitoramento dessas rotinas. Em outros
SGBD isso um pouco mais fcil, pois os prprios SGBD j provem de
informaes de backup, disponibilizando a data de execuo do ultimo backup.
Como isso ainda no foi implementado no MySQL, necessrio anexar a
rotina de backup um meio de armazenar o histrico de execuo, seja ele
atravs de uma tabela do MySQL ou de arquivos texto. E posteriormente
verificar esses estados.

3. SQL SERVER
3.1 Funcionamento Bsico

Geralmente dizemos que o SQL Server um SGBD cliente/Servidor pois


comporta diferentes tipos de plataformas e possui funcionalidades divididas
entre clientes e servidores, onde o cliente fornece uma ou mais interfaces que
sero usadas para requerer uma solicitao ao servidor(SGBD) ; este por sua
vez , processa a solicitao e devolve o resultado ao cliente.
O SQL Server possui uma linguagem relacional chamada de Transact-SQL que
um dialeto da linguagem SQL - Structured Query Language. A principal
caracterstica da linguagem SQL ter sido projetada para trabalhar com
conjuntos de registros de dados, enquanto que as linguagens tradicionais (C++,
VB, Delphi,..) podem tratar apenas um registro por vez. Alm disto a SQL no
procedural , ou seja , a SQL no precisa descrever em detalhes como realizar
uma tarefa , ela apenas descreve o que o usurio final deseja.
A SQL se divide em dois subconjuntos de linguagem:
1. A linguagem de Definio de Dados - DDL - que usa instrues para
descrever
o esquema
das
tabelas
do
banco
de
dados
2. A linguagem de Manipulao de Dados - DML - que usa instrues para
manipular os dados.
Na organizao do SQL Server podemos ter objetos fsicos e lgicos:
i. Os objetos fsicos relacionam-se com a organizao dos dados no disco.
ii. Os objetos lgicos so constitudos por : banco de dados , tabelas, vises ,
colunas , linhas , etc...
O SQL Server permite a criao de banco de dados do usurio (criados por
um usurio autorizado) e banco de dados do sistema (criados durante a
instalao) os quais so:

Master
tempdb
model
msdb
distribution

3.2 Ferramenta de Backup


O SQL Server disponibiliza para os administradores de banco de dados
algumas opes de backups, de forma que o banco de dados em questo no
perca nenhuma informao, ou o mnimo possvel delas em caso de falha de
hardware ou em caso de falha causada pelo usurio (como, por exemplo,
excluso acidental de registros).
Os tipos disponveis so o backup completo (tambm conhecido como backup
full), backup diferencial (tambm conhecido como backup differential), backup
do log de transao (tambm conhecido como backup do transaction log ou
backup incremental), backup do grupo de arquivos (tambm conhecido como
backup do filegroup) e backup parcial. O nico tipo de backup obrigatrio em
qualquer estratgia de backup o backup completo, pois a partir dele que
uma restaurao de banco de dados se inicia e tambm pr-requisito para a
restaurao de qualquer outro tipo de backup. Sem um backup completo no
possvel realizar um backup diferencial ou do log de transao, por exemplo,
retornando um erro para o administrador de banco de dados.

3.3 Restaurao
Restaurar um banco consiste, basicamente, em operaes que recriam os
objetos da base de dados at um ponto especfico no tempo. Este ponto o
momento em que a criao do backup foi realizada e finalizada.
Diferente da criao do backup, o processo de restaurao sequencial. Desta
forma, o SQL Server garante a consistncia dos dados, mas acaba
consumindo mais tempo e recursos do servidor.
Por reescrever todas as pginas de dados, o processo de restaurao no
apenas pode ser utilizado para fins de substituio de uma base originalmente
defeituosa, mas tambm em processos de transferncia de bancos de dados
para novos servidores SQL Server.
Alm disso, vale lembrar que uma operao de Restore pode se resumir em
um nico passo onde apenas um Backup Completo recuperado e o banco
passa a esta disponvel para os usurios e receber transaes. Entretanto, na
grande maioria dos casos, o cenrio exige que o Administrador restaure um
conjunto de backups, possibilitando assim a minimizao da perda de dados.
Em ambientes de alta disponibilidade, cinco minutos de perda de dados podem
significar a eliminao de milhares de registros.
Por fim, uma observao importante: durante todo o processo de restaurao,
o banco fica inacessvel para todos os usurios. Ele s se tornar acessvel no
momento em que o banco estiver no estado Restored (Restaurado).

3.4 Poltica de Backup

O backup e a restaurao dos dados devem ser personalizados em um


ambiente especfico e devem funcionar com os recursos disponveis. Portanto,
um uso confivel de backup e restaurao para recuperao requer uma
estratgia de backup e restaurao. Uma estratgia de backup e restaurao
bem-planejada maximiza a disponibilidade dos dados e minimiza a perda de
dados, considerando, ao mesmo tempo, seus requisitos empresariais
especficos.
Uma estratgia de backup e restaurao contm uma parte de backup e uma
parte de restaurao. A parte de backup da estratgia define o tipo e a
frequncia dos backups, a natureza e velocidade do hardware exigido para
eles, como os backups sero testados, e onde e como a mdia de backup deve
ser armazenada (incluindo consideraes de segurana).

A parte de restaurao da estratgia define quem responsvel pela execuo


da restaurao e como a restaurao deve ser executada para atender s
metas de disponibilidade do banco de dados e minimizar perda de dados.
Recomendamos que voc documente seus procedimentos de backup e
restaurao e mantenha uma cpia da documentao em seu livro de
execues.
O design de uma estratgia de backup e restaurao eficaz requer
planejamento, implementao e teste cuidadosos. O teste obrigatrio. No
existir uma estratgia de backup at que voc tenha restaurado com xito os
backups em todas as combinaes includas na estratgia de restaurao.
Voc deve considerar uma variedade de fatores. Eles incluem o seguinte:
- As metas de produo de sua organizao para os bancos de dados,
especialmente os requisitos para disponibilidade e proteo contra perda de
dados.
- A natureza de cada um dos seus bancos de dados: o tamanho, os padres
de uso, a natureza de seu contedo, os requisitos dos dados, e assim por
diante.
- Restries de recursos, como hardware, pessoal, espao para
armazenagem de mdia de backup, a segurana fsica da mdia
armazenada,
e
assim
por
diante.

4. POSTGRE SQL

4.1 Funcionamento Bsico

PostgreSQL um SGBDR (sistema de gesto de banco de dados relacionais)


funcionando em sistemas de tipo UNIX (por exemplo Linux, FreeBSD, AIX, HPUX, IRIX, Solaris, ...).
Uma das principais qualidades de PostgreSQL de ser um software livre, quer
dizer gratuito e cujas fontes so disponveis.
PostgreSQL possui numerosas caractersticas fazendo um SGBDR robusto e
potente digno dos SGBD comerciais:

Interfaces grficos (X-Window ento necessrio ) para gerenciar as


bandejas.
Bibliotecas para numerosas linguagens (chamadas frontais) para acessar os
registros a partir de programas em:
Java (JDBC)
language C/C++
Perl

Tcl/Tk
Uma API ODBC que permite a qualquer aplicao que suporta este tipo de
interface de acessar bases de dados de tipo PostgreSQL.

PostgreSQL funciona de acordo com uma arquitetura cliente/servidor, assim


constitudo

De um lado servidor, quer dizer uma aplicao que funciona em uma


mquina que hospeda a base de dados do servidor de base de dados capaz
de tratar as solicitaes dos clientes. Trata-se no caso de PostgreSQL de
um programa residente em memria postmaster

De outro lado cliente que deve ser instalado em todas as mquinas que
necessitam acessar ao servidor de base de dados (um cliente pode
eventualmente funcionar sobre o servidor dele mesmo)

4.2 Ferramenta de Backup

H trs ferramentas diferentes para fazer backup de PostgreSQL:

SQL dump

File system level backup


Continuous archiving

4.3 Restaurao
O pg_restore um utilitrio para restaurar um banco de dados do PostgreSQL a
partir de um arquivo gerado pelo pg_dump em um dos formatos no-texto-puro.
So executados os comandos necessrios para criar novamente todos os tipos,
funes, tabelas, ndices, agregaes e operadores definidos pelo usurio.
Os arquivos de exportao contm informaes para o pg_restore reconstruir o
banco de dados, mas tambm permitem ao pg_restore selecionar o que deve
ser restaurado, ou mesmo reordenar a restaurao dos itens. Os arquivos de
exportao so projetados para serem portveis entre arquiteturas.
O pg_restore pode operar de dois modos: Se um nome de banco de dados for
especificado, o arquivo de exportao restaurado diretamente no banco de
dados. Seno, um script contendo os comandos SQL necessrios para
reconstruir o banco de dados criado (e escrito em um arquivo ou na sada
padro), semelhante aos scripts criados pelo pg_dump no formato texto-puro.
Algumas das opes que controlam a criao do script so, portanto, anlogas
s
opes
do
pg_dump.
Obviamente, o pg_restore no pode restaurar informaes que no estejam
presentes no arquivo de exportao; por exemplo, se o arquivo de exportao
foi gerado usando a opo "exportar dados como INSERT", o pg_restore no
poder importar os dados usando o comando COPY.

4.4 Poltica de Backup

Os backups devem fazer parte da rotina de operao dos seus sistemas e


seguir uma politica determinada. O melhor faz-los da forma mais
automatizada possvel, de modo a reduzir o seu impacto sobre o trabalho dos
administradores e operadores de sistemas.

A lista de itens cujo backup deve ser feito com frequncia inclui:

Dados
Arquivos de configurao
Logs

As combinaes de backup mais comuns so:

Backup total
Backup incremental
Backup diferencial

Você também pode gostar