Você está na página 1de 17

Backup Engine do SQL Server 2005

Fonte: http://www.devmedia.com.br/articles/viewcomp.asp?comp=4417

Para entender como o SQL Server 2005 realiza o backup do banco de dados, é necessário entender como funciona a sua Backup Engine . Esta Engine é configurada para realizar todas as tarefas relacionadas a cópia dos dados da forma mais rápida possível, minimizando o impacto na performance do Servidor de Dados.

Quando o backup é iniciado, a Engine escreve as páginas de dados no dispositivo de backup (Disco ou Fita) sem se preocupar com a ordem. Graças a isso, o SQL Server pode abrir vários processos para escrever os dados no seu destino, agilizando o processo.

Mas como este processo geralmente ocorre em ambientes de produção (com usuários trabalhando com os dados), podem ocorrer alterações nos dados durante o processo de criação do backup, e isso poderia gerar inconsistência dos dados.

Para evitar este problema, o SQL Server 2005 realiza uma seqüência de tarefas para garantir que ao término da criação da cópia de segurança, todos os dados e objetos existentes na base de dados estão copiados no backup. Estes passos são:

Travamento do Banco de Dados: Ao travar o banco de dados, o SQL Server fecha todas as conexões existentes.

Criação da marca Checkpoint no Log de Transações: Neste passo, o SQL Server insere uma marca chamada Checkpoint. É através desta marcação que o SQL Server delimita até que ponto do log será feito o backup inicial. As transações que forem realizadas durante o processo de criação são copiadas depois de criado o backup inicial.

Liberação do Banco de Dados: Depois de criado o Checkpoint, a base de dados é então liberada para receber as transações durante o processo de backup.

Cópia de todas as páginas de dados: Neste passo, ocorre a criação do backup, onde o SQL Server 2005 realiza a cópia de todas as páginas de dados para o destino.

Travamento do Banco de Dados: Uma vez copiada todas as páginas de dados, o SQL Server fecha novamente todas as conexões existentes.

Criação da marca Checkpoint no Log de Transações: Novamente, o SQL Server insere a marca Checkpoint no Log de Transações.

Liberação do Banco de Dados: Depois de criado o novo Checkpoint, o SQL Server libera o banco.

Extração de todas as transações que ocorreram durante o processo de Backup: Através dos dois Checkpoints criados no arquivo de log, o SQL Server extrai todas as transações que foram efetuadas entre as duas marcações e adiciona ao backup. Isto garante a consistência dos dados e objetos existentes no backup no horário de termino da sua criação.

Métodos de Backup no SQL Server 2005

O SQL Server 2005 oferece quatro métodos de Backups. Estes métodos são:

Full Backup;

Differential Backup;

Transaction Log Backup;

Filegroup Backup.

Cada método possui características e dependências específicas, que são utilizadas pelo DBA para decidir quando cada um será utilizado na sua política de backup.

Tipos de Backup

1. Full Backup

O Full Backup (Backup Completo) captura todos os dados que estão armazenados no banco de

dados. A Engine executa esta tarefa copiando todas as Extents (Uma Extent contém 8 páginas de dados físicas e contínuas, ocupando 64kb de espaço) que possuem objetos do banco alocados. Com este tipo de backup, é possível recriar toda a base de dados. Além disso, ele sempre está disponível para o Administrador, independente do Recovery Model (Full , Bulk

Logged ou Simple ) configurando no banco em questão. O Full Backup é prérequisito para criação dos outros tipos de backup

2. Differential Backup

O Differential Backup (Backup Diferencial) captura todas as Extents que sofreram alterações

desde o ultimo Full Backup . Isso significa que todas as alterações de dados e objetos realizadas

no banco são copiadas e armazenadas. As informações das Extents alteradas são armazenadas através do Extents Map .

Extent Map é um conjunto de páginas de dados pertencentes ao banco de dados, onde é armazenado um mapeamento de todas as Extents usadas pela base de dados. Cada Extent é um bit no mapa, de valor inicial 0 (zero). Quando uma Extent sofre alterações, o SQL Server acessa

o mapa e marca com o valor 1. Esta é a condição usada pela Backup Engine para realizar o backup diferencial: apenas as Extents que possuem o valor 1 no mapeamento. Quando é realizado o Full Backup , todos os valores são zerados.

O backup diferencial sempre trabalha em conjunto com o backup completo: caso não exista um

backup completo do banco, o SQL Server não permite a criação de um backup diferencial. Graças a integração com o Full Backup , o Differential Backup também é independente do Recovery Model configurado na base de dados.

Por fim, vale ressaltar que o backup diferencial não é a mesma coisa de um backup incremental: cada backup diferencial criado pode substituir todos os backups (Diferenciais e de Log) criados anteriormente até o ultimo backup completo, nos caso de restauração da base de dados.

3. Transaction Log Backup

O Transaction Log Backup (Backup do Log de Transações) trabalha em cima do log ativo, capturando todas as transações finalizadas deste o ultimo backup, qualquer que seja o tipo. Este tipo de backup é incremental: cada vez que é realizado, ele inicia a cópia do ponto em que foi realizado o ultimo backup e copia todas as transações finalizadas gravadas no log. Ao encontrar uma transação em aberto, o SQL Server finaliza a cópia.

Todas as transações que foram copiadas para o backup são marcadas pelo SQL Server. Esta marcação informa ao SQL Server que a transação em questão pode ser substituída por outra nova, ajudando a minimizar os impactos do crescimento do arquivo de log.

4.

Filegroup e File Backup

O Filegroup Backup (Backup do Grupo de Arquivos) e os File Backup (Backup do Arquivo) são

alternativas de backup em bancos que trabalham com múltiplos arquivos de dados. Enquanto todos os métodos de backup apresentados até agora realizam a cópia de toda a base de dados, estes backups permitem que você realize a cópia de cada arquivo e/ou grupo de arquivos pertencentes a um banco de dados de forma isolada. O conjunto de backups de todos os arquivos equivale ao um backup completo da base de dados.

A utilização deste tipo de backup apresenta algumas vantagens:

Recuperação dos Arquivos de uma mídia danificada: Ao utilizar o método de backup de arquivos, a recuperação do banco de dados é mais rápida nos casos de falha parcial. Imagine um servidor com 3 (três) discos, e em cada um deles está armazenado um arquivo de dados do banco. Caso um destes discos falhe, só é necessário realizar a recuperação do arquivo que está na mídia danificada, e não do banco inteiro.

Realização de Backups de Arquivos e do Log simultaneamente: Ao realizar o backup de um arquivo, o SQL Server não realiza a etapa de atualização das transações que foram realizadas no período de criação da cópia, somente a cópia das Extents do banco. Isto permite ao SQL Server a realização dos dois backups de forma independente.

Flexibilidade na política de backup: Trabalhar com backup de arquivos permite ao administrador uma maior liberdade no agendamento das tarefas e no gerenciamento das mídias de armazenamento, principalmente nos casos em que o backup completo pode se tornar impraticável (Bases de dados muito extensas e que trabalham com múltiplos arquivos).

As principais desvantagens da utilização deste tipo de backup são o aumento da carga administrativa e a dependência de todos os backups para restaurar o banco de dados (se a mídia que possui um File ou Filegroup Backup falhar, não é possível a restauração da base de dados).

Filegroup Backup e File Backup requer que o Recovery Model do banco seja Full ou Bulk Logged ,

que são os backups dos logs de transações que manterão a consistência do banco. É possível

criar Full Backups e Differential Backups de cada arquivo ou grupo de arquivos do banco de dados.

Comandos SQL para Backup

1. Comando para criar backup full

backup

database [databasename] to disk = '<diretorio>\<filename>'

with init

2. Comando para criar backup diferencial

backup

database [databasename] to disk = '<diretorio>\<filename>'

with diferential

3. Comando para criar backup de log

backup

log [databasename] to disk = '<diretorio>\<filename>'

with init

4. Comando para criar backup de arquivo específico

backup

database [databasename]

file= '<filename>'

to disk = '<diretorio>\<filename>'

with init

5. Comando para criar backup de filegroup

backup

database [databasename]

filegroup= '<filename>'

to disk = '<diretorio>\<filename>'

with init

Entendendo o processo de Restore no SQL Server 2005

Fonte: http://www.devmedia.com.br/articles/viewcomp.asp?comp=6172

Restaurar um banco consiste, basicamente, em operações que recriam os objetos da base de dados até um ponto específico no tempo. Este ponto é o momento em que a criação do backup foi realizada e finalizada.

Diferente da criação do backup, o processo de restauração é seqüencial. Desta forma, o SQL Server garante a consistência dos dados, mas acaba consumindo mais tempo e recursos do servidor.

Por reescrever todas as páginas de dados, o processo de restauração não apenas pode ser utilizado para fins de substituição de uma base originalmente defeituosa, mas também em processos de transferência de bancos de dados para novos servidores SQL Server.

Além disso, vale lembrar que uma operação de Restore pode se resumir em um único passo onde apenas um Backup Completo é recuperado e o banco passa a esta disponível para os usuários e receber transações. Entretanto, na grande maioria dos casos, o cenário exige que o Administrador restaure um conjunto de backups, possibilitando assim a minimização da perda de dados. Em ambientes de alta disponibilidade, cinco minutos de perda de dados podem significar a eliminação de milhares de registros.

Por fim, uma observação importante: durante todo o processo de restauração, o banco fica inacessível para todos os usuários. Ele só se tornará acessível no momento em que o banco estiver no estado Restored (Restaurado). A única exceção desta regra é o processo Online Restore, que veremos adiante neste artigo.

Métodos de Restauração no SQL Server 2005

Baseado nos métodos de Backups existentes, o SQL Server 2005 oferece quatro métodos de Restore . Estes métodos restauram os seguintes tipos de backup:

Full Backup;

Differential Backup;

Transaction Log Backup;

Partial Backup.

Dependendo da política de criação de backups e do conjunto de cópias existente, cada método possui características e dependências específicas, que organizam e agilizam a recriação do banco de dados.

Restaurando um Full Backup

Na grande maioria dos casos, o primeiro passo no processo de restauração é a recriação completa da base de dados até um ponto específico no tempo, para que então o DBA aplique backups complementares que atualizem o banco para o estado desejado. Este processo começa com a restauração de um Full Backup (Backup Completo) .

No artigo anterior, vimos que o backup completo possui todas as Extents que compõem um banco de dados e, conseqüentemente, todo o seu conteúdo. A operação de restauração, nos processo de reconstrução da base de dados, grava todas as páginas de volta no servidor seguindo a seqüência original do banco. Desta forma, o processo de Restore garante a consistência dos dados, mas acaba consumindo mais tempo.

A restauração do Full Backup é prérequisito para a utilização dos outros tipos de restauração de backup.

Restaurando um Differential Backup

Antes de restaurar um Differential Backup (Backup Diferencial) , duas condições devem ser satisfeitas:

Backup Completo Restaurado: Como o backup diferencial grava todas as Extents alteradas desde o ultimo backup completo, é necessário a restauração do backup completo (ou seja, as Extents originais) para então aplicar o Differential Backup .

A base de dados deve está no modo Recovering: Ao realizar o backup de um arquivo, o SQL Server não realiza a etapa de atualização das transações que foram realizadas no período de criação da cópia, somente a cópia das Extents do banco. Isto permite ao SQL Server a realização dos dois backups de forma independente.

Uma vez estas condições atendidas, o SQL Server 2005 então permite a restauração da cópia de segurança. Durante esta operação, as Extents armazenadas no backup sobrescrevem as existentes no servidor, atualizando assim o conteúdo do banco de dados.

Por fim, vale ressaltar que o backup diferencial substitui todos os backups (Diferenciais e de Log) criados anteriormente. Desta forma, para o Administrador, só há a necessidade de restaurar apenas o ultimo backup diferencial disponível.

Restaurando um Transaction Log Backup

Ao criar um Transaction Log Backup (Backup do Log de Transações), o SQL Server armazena no destino a

seqüência de transações que foram efetuadas desde o ultimo backup até o instante atual. Esta seqüência de transações são ordenadas pelos seu LSN (Log Sequence Number – Número de Seqüência no Log) .

Sendo assim, quando o DBA executa a restauração de um backup do log de transações, o SQL Server

as transações armazenadas na cópia de segurança e as executa no banco de dados, atualizando o até o instante em que esse backup foi criado.

Desta forma, os backups do log só podem ser aplicados após a restauração de outro backup de qualquer tipo (Completo, Diferencial ou de Log).

Como as transações são ordenadas pelo LSN , o Administrador possui a oportunidade de restaurar a base de dados até um ponto específico. Esta característica, aliada ao fato de que o log é independente do banco, possibilita uma maior flexibilidade na hora de restaurar uma base de dados. Para entender as vantagens que este tipo de backup oferece no processo de restauração, apresentaremos algumas situações de restauração.

Imagine a existência de um servidor de dados SQL Server 2005 com uma aplicação CRM (Customer

Relationship Management) . Certo dia, os arquivos de dados ( *.mdf e *.ndf ) desta base são danificados e

o banco torna se inacessível. Após verificar o problema, o Administrador decide então restaurar o banco

de dados. Nesta situação, como minimizar a perda de dados, que o banco está inacessível?

Independente do ultimo backup que o Administrador possua, é possível realizar o backup do log de transações mesmo com a base de dados danificada, que as transações são armazenadas em um arquivo diferente ( *.ldf). Logo, o Administrador consegue realizar um Transaction Log Backup e assim copiar todas as ações que foram efetuadas no CRM até o instante da falha.

De posse deste backup e de um backup completo (lembrese que o backup do log só pode ser efetuado após a criação de, pelo menos, um Full Backup ), o SQL Server permite restaurar o banco para o instante antes da falha e assim minimizar a perda de dados.

Outra utilização do backup do log é a de facilmente reverter, por exemplo, a remoção de uma tabela acidentalmente por um usuário: basta restaurar o banco até o instante anterior ao comando executado pelo usuário. Mas lembrese que, durante o processo de Restore , o banco fica indisponível para todos os usuários.

Nestes casos, para restaurar objetos removidos acidentalmente sem afetar o funcionamento do restante do sistema, recomendase restaurar os backups para um novo banco até o instante anterior da remoção; deste ponto copiar o objeto e colar na base de dados original.

Restaurando um Filegroup e File Backup

A restauração de um Filegroup Backup (Backup do Grupo de Arquivos) ou de um File Backup (Backup do

Arquivo) é efetuada de forma semelhante ao backup completo.

A grande diferença está na possibilidade de restaurar apenas uma parte do banco de dados,

minimizando a inacessibilidade do servidor. Desta forma, o administrador tem a vantagem de só restaurar a parte (arquivo ou grupos de arquivos) danificada, enquanto o restante do banco de dados

continua disponível. Este tipo de restauração também é chamado de Partial Restore (Restauração Parcial).

Entretanto, vale lembrar que, em falha total do banco, todos os backups dos arquivos são necessários para restaurar o banco de dados (se a mídia que possui um File ou Filegroup Backup falhar, não é possível a restauração da base de dados).

Restore Options

Overwrite the existing database: Esta opção permite que o processo de restauração sobrescreva o banco atual com a cópia a ser recuperada. Ao marcar esta opção, o SQL Server substitui as páginas de dados atuais pelas contidas na cópia. Uma consideração importante sobre esta opção é que o banco a ser sobrescrito não necessariamente é o mesmo existente na cópia, mas sim o informado na página General, no campo To Database . Esta ação não pode ser desfeita.

Preserve the replication settings: Em caso de restauração de bancos publicados para replicação (duplicação), o SQL Server permite o Restore deesta bases publicadas em outros servidores diferentes do servidor de origem, trazendo consigo todas as configurações da replicação configurada anteriormente. Esta opção só estará disponível caso o estado de recuperação do banco de dados seja definido como RESTORE WITH RECOVERY .

Prompt before restoring each backup: Ao marcar esta opção, o SQL Server pergunta ao DBA, após a restauração de um backup, se deseja continuar com o processo. Esta opção é utilizada quando o Administrador define a restauração de múltiplos backups na guia General, através da lista Select the backup sets to restore . Propriedade extremamente útil nos casos em que os backups estão distribuídos em várias fitas e seu servidor possui um dispositivo para leitura:

nos momentos de interrupção, o Administrador realiza a troca da fita e clica no botão OK para prosseguir com o processo. Caso o Administrador clique no botão NO, processo será interrompido e o banco ficará no estado de restauração RESTORE WITH NORECOVERY.

Restrict Access to the restored database: Esta opção restringe o acesso ao banco, permitindo apenas que usuários dos papeis db_owner, dbcreator ou sysadmin acessem a base de dados.

Recovery State.

Esta opção define o comportamento do banco de dados após o processo de Restore. São três opções disponíveis:

RESTORE WITH RECOVERY: Esta opção informa ao SQL Server que, após a restauração, o banco de dados recuperado estará disponível para utilização pelos usuários. Esta opção será utilizada nos casos em que a base de dados só possui um backup a ser restaurado. Uma vez restaurado no modo RECOVERY , não é possível aplicar o Restore do Log de Transações, uma vez que a base recebeu novas transações.

RESTORE WITH NORECOVERY: Também chamado de Recovering State , esta opção informa ao SQL Server que o banco de dados ainda receberá outros backups. Neste estado, a base ainda não aceita conexões de usuários, mantendo o intacto até que seja restaurado o último backup com a opção RECOVERY WITH RECOVERY. Utilize esta opção quando o banco a ser restaurado possui vários conjuntos de backups (Exemplo: restaurar um Full Backup e em seguida um Differential Backup : o completo será restaurado como NORECOVERY; o diferencial como RECOVERY).

RESTORE WITH STANDBY: Informa ao SQL Server que a base restaurada estará no modo STANDBY, permitindo acesso no modo somente leitura. Ao escolher esta opção, o DBA define o local do arquivo que permitirá desfazer as alterações realizadas pelo STANDBY. Utilize esta opção no seguinte cenário: o Administrador deseja restaurar o banco para um momento específico, mas ele não possui nenhuma informação precisa sobre este momento (Não tem idéia exata do horário e nem da transação realizada). A solução seria restaurar o banco através com a opção STANDBY. Desta forma, é possível realizar consultas na base de dados para saber se o momento desejado é o atual. Se o momento for posterior, basta realizar a restauração de mais backups com STANDBY até encontrar o ponto desejado. Nos casos do momento desejado ser anterior ao carregado pelo backup, entra em ação o arquivo do STANDBY, que permite desfazer o ultimo backup. Ao encontrar o momento desejado, basta realizar a restauração com a opção RECOVERY .

Perguntas Frequentes sobre o Backup no SQL Server 2005

1. Quando o SQL Server faz um backup ele comprime os dados?

Apesar de fazer backup somente dos dados e do transaction log o SQL Server não comprime o arquivo final de backup independente de qual tipo de backup seja feito (FULL, DIFFERENTIAL ou TRANSACTION LOG). Fiz um pequeno teste com um programa tipo Winzip e consegui uma boa taxa de compactação. devemos ter o cuidado de descompactar o arquivo de dispositivo que contém o backup antes de fazer o restore

2. Tem como fazer um backup de somente uma tabela para depois restaurála?

Quando falamos em backup no SQL Server estamos nos referindo ao resultado gerado pelo comando BACKUP e não a uma cópia física dos arquivos de dados (.mdf ou .ndf ) e Transaction Log (.ldf). Por isso quando fazemos backup's devemos lembrar que a idéia deste backup é evitar a perda de dados e conseguir restaurar o banco de dados em um estado consistente. Por isso não podemos fazer um backup somente de uma tabela ou de alguns registros da mesma, pois o backup trabalha com tanto a estrutura de todos os objetos do banco como dos dados que estão relacionados a estes objetos.

Porém existe como segmentar um banco de dados através do uso de filegroups. Uma vez que o banco de dados possua um filegroup diferente do Primary podemos colocar uma tabela dentro de um filegroup(utilizando a opção ON do comando CREATE TABLE) e conseqüentemente fazer o backup somente deste filegroup que contém somente uma tabela.

Porém não podemos especificar qual linha desta tabela queremos e qual linha não queremos restaurar quando estivermos fazendo o restore deste backup.

3. Ouvi dizer que posso restaurar o backup do meu banco de dados até uma determinada hora ou até uma certa transação. É verdade? Se sim como faço isso?

Sim , podemos restaurar um backup que fizemos até um determinado momento ou até uma certa transação. Porém este tipo de funcionalidade somente é válido para backups de Transaction Log.

Para isso primeiro devemos começar o processo de restore com um backup completo e os demais backups desejados. No último backup de Transaction Log a ser restaurado devemos especificar a opção STOAT para paramos o restore em um determinado ponto no tempo. Um exemplo deste comando RESTORE:

RESTORE LOG DB_TESTE

FORM DISP_LOG

WITH RECOVERY,STOPAT = '12/31/2002 10:00:00'

O comando acima restora o backup de Transaction Log até o momento em que o banco de dados estava quando a data 31 de dezembro de 2002 às 10:00:00 foi alcançada.

Enquanto um backup está sendo executado o banco de dados pode continuar a ser executado normalmente. Somente algumas instrução TransactSQL não devem ser feitas durante o processo de backup como criação, alteração ou deleção de bancos de dados.

O processo de Restore requer que o banco de dados esteja em um modo especial, chamado de single user e ninguém pode estar conectado ao banco de dados que está sendo restaurado. Por padrão o próprio comando RESTORE DATABASE tenta colocar o banco de dados de destino neste modo, emitindo um erro caso não consiga.

5.

Como faço para restaurar um backup do banco de dados master?

Para restaurar um backup full do banco de dados master é preciso subir o serviço do SQL Server em um modo especial para poder restaurar o backup. Siga os seguintes passos:

a) Primeiro programe uma parada do serviço. Isso quer dizer, se possível, você deve avisar os usuários

que estão utilizando o seu banco de dados e fazer isso em um horário que ninguém esteja utilizando o servidor de banco de dados.

b) Pare o serviço do SQL Server através da ferramenta Service Manager.

c) Vá até o DOS (console) e inicie o serviço através do utilitário sqlservr.exe passando um parâmetro

especial –m que indicará que o serviço vai subir em single user admin mode:

sqlservr.exe –m

Este utilitário se encontra geralmente no subdiretório /binn a partir do diretório onde o SQL Server foi instalado

d) Abra somete um Enterprise Manager ou um Query Analyser e restore o backup.

e) Pare o serviço do console com CTRL+C. É preciso confirmar

f) Inicie o serviço normalmente com o Service Manager e avise os usuários que o backup foi restaurado.

6. Através do Enterprise Manager eu não consigo fazer um backup para um driver compartilhado (rede). Tem como isso ser feito?

Tem. Porém vai ser preciso criar um dispositivo permanente através da system stored procedure sp_addumpdevice apontando para o endereço UNC ou para um drive lógico compartilhado. Por exemplo, o comando abaixo:

sp_addumpdevice 'DISK','DISP1','\\SERVIDOR\COMP\DISP1.DAT'

Vai criar um dispositivo de backup permanente apontando para o compartilhamento COMP do computador chamado SERVIDOR. Este dispositivo vai poder ser utilizado para se fazer backup's, mesmo dentro do Enterprise Manager.

7. Para restaurar um backup eu preciso possuir um banco de dados criado ou posso criálo na hora do restore?

Por padrão o comando RESTORE faz um safety check para garantir que não estejamos restaurando um backup que foi feito em um banco de dados A e um banco de dados B. Este safety check verifica várias opções como o nome do banco de dados, os arquivos de dados e de transaction log e outras configurações.

Porém existe a opção REPLACE do comando RESTORE que permite que 'pulemos' o safety check no momento de fazer o restore e também permite a criação de um banco de dados no momento do restore.

Dica da semana: Compactando e Descompactando Arquivos pelo SQL Server

Postado em Segundafeira, 10 de Setembro de 2007 (20:33:00) por niltonpinheiro

Uma dúvida muito comum nos fóruns tem sido sobre a possibilidade de se compactar o arquivo de backup gerado pelo SQL Server. Veja a dica desta semana e saiba como usar as extended stored procedures xp_makecab e xp_unpackcab para compactar e descompactar um arquivo pelo SQL Server.

É muito comum encontrar nos fóruns perguntas sobre a possibilidade de e compactar o backup

realizado pelo SQL Server. Infelizmente o SQL Server não possui nativamente uma maneira de gerar seus backup compactados. No entando na dica desta semana mostro como você pode usar duas extended stored procedures não documentadas para fazer o trabalho de compactação e descompactação de um arquivo.

O SQL Server possui duas extended stored procedures não documentadas chamadas xp_makecab e

xp_unpackcab que você pode usar para respectivamente compactar e descompactar um arquivo pelo SQL Server. A utilização destas xps é bastante simples e o melhor é que você pode usá las para compactar/descompactar não apenas um arquivo de backup do SQL Server, mas com qualquer outro arquivo.

No exemplo abaixo mostro como você pode usar a xp_makecab para compactar o arquivo de backup DBTESTE_BKP.BAK que está localizado

no diretório E:/Backup. Ao final da compactação o arquivo terá o nome de DBTESTE_BKP.cab. Fique atento à extensão .cab pois ela é obrigatória.

‐‐ Compacta o arquivo de backup DBTESTE_BKP.BAK

EXEC master.dbo.xp_makecab

@cabfilename = 'E:/Backup/DBTESTE_BKP.cab',

@compression_mode = 'mszip',

@verbose_level = 0,

@filename1 = 'E:/Backup/DBTESTE_BKP.BAK'

Nota: Não esqueça de alterar a barra (/). Este deve ser a mesma usada para separação de diretórios.

Uma vez tendo um arquivo compactado, você pode usar a xp_unpackcab para descompactar o arquivo. Veja abaixo um exemplo de como usar a xp_unpackcab. Vale destacar que o arquivo será descompactado mantendo seu nome original DBTESTE_BKP.BAK

‐‐Descompactando o arquivo DBTESTE_BKP.cab

EXEC master.dbo.xp_unpackcab

@cabfilename = 'E:/Backup/DBTESTE_BKP.cab',

@destination_folder= 'E:/Backup',

@verbose_level=0

Vantagens

1. Excelente taxa de compactação, compactou um arquivo de 463.76MB para apenas 13.8MB

2. A compactação do arquivo de 463.76 foi feita em menos de 1 minuto em um P4 HT 3.0GHz com 1GB

RAM

Desvantagens

1. Em uma máquina P4 HT 3.0GHz com 1GB RAM, durante a compactação o consumo médio de CPU

ficou constantemente em 53% de utilização. Este pode ser um problema caso pensem em usar esta xp

em um ambiente de produção.

2. Durante a compactação é utilizada a área temporária da conta de usuário que inicia o serviço do SQL

Server. Isso significa que você pode precisar de um bom espaço libre no disco C:

3. Estas xps não existem no SQL Server 2005.

Artigos: Clonando um Banco de Dados com o Utilitário CloneDB

Postado em Segundafeira, 14 de Janeiro de 2008 (7:00:00) por niltonpinheiro

O que você faz quando precisa criar um banco de dados idêntico a um banco existem, mas sem levar os dados? Uma das alternativas mais comum é você gerar os scripts de criação dos objetos e depois executar os scripts na nova base. Sabemos que este processo é trabalhoso e de certa forma requer um certo conhecimento no momento da geração dos scripts. Bom, para resolver este problema conheça o CloneDB, um utilitário bem simples mas que permite executar a atividade com apenas um clique.

Sabemos que no dia a dia de um DBA é muito comum precisar transferir bancos de dados de um servidor para outro ou até mesmo criar um banco de dados a partir de um banco existente. Na maioria das vezes não queremos levar os dados, apenas os objetos, usuários e permissões.

Bom, também sabemos que para executar esta tarefa a meneira mais simples é você gerar um script dos objetos, usuários e permissões no banco de dados existente e depois executar estes scripts no novo banco, certo? Para quem já leu o artigo Gerando Script dos Objetos com o Utilitário SCPTXFR.EXE, certamente dirá que é mais simples usar o utilitário SCPTXFR.EXE e neste caso concordo. No entanto, o utilitário CloneDB torna a coisa muito mais simples, executando todo o trabalho com apenas um clique.

Ao executar o utilitário você deverá informar o nome do servidor, login e senha, nome do banco de dados atual e um nome para o novo banco de dados (o clone).

Ao clicar em Start o utilitário criará o novo banco, gerará um script com todos

Ao clicar em Start o utilitário criará o novo banco, gerará um script com todos os objetos, usuários e permissões do banco de dados existente e executará este script sobre o clone. Ao final você terá dois bancos de dados idênticos, porém, o clone não possui os dados!!

Agora, se o seu objetivo é criar apenas um arquivo de script com todos os

Agora, se o seu objetivo é criar apenas um arquivo de script com todos os objetos, usuários e permissões do banco de dados existente para executar este script em outro servidor/banco de dados ou até mesmo para guardar como um backup, dê uma olhada no diretório onde você colocou o arquivo CloneDB.exe e abra o arquivo DB_TRANSFER_SCRIPT.sql. Está tudo aí !!

Testei este utilitário no SQL Server 2000/2005 e 2008. No SQL Server 2000 ele funcionou sem o menor problema mas descobri que ele não leva procedure que estejam criptografadas (mais que normal certo?). Para o SQL Server 2005 e 2008, ele leva apenas os objetos que estejam no schema dbo e também não gera os statements para criação dos schemas, na verdade, ele trata os schemas como sendo owner dos objetos (com no SQL Server 2000). Nestes casos, tente então o utilitário SCPTXFR.EXE.

Há, este utilitário não foi desenvolvido por mim e também não possuo o código fonte, portanto, a execução deste é de sua inteira responsabilidade :)

Update 20/01/2008

Clique sobre o link para baixar o utilitário CloneDB.exe em formato .zip

http://www.mcdbabrasil.com. br/downloads/CloneDB.zip