Finalmente na versão 2008 a Microsoft adicionou uma solução nativa para compactação de backups, no entanto esta opção só estava disponível na edição Enterprise.

Com a chegada do 2008 R2 a Microsoft estendeu a funcionalidade para a edição Standard; ou seja, a coisa tá ficando mais acessível.

“Mão na massa”

Para compactar o backup o processo é bem simples, basicamente precisamos adicionar a opção WITH COMPRESSION no comando de backup:

BACKUP DATABASE AdventureWorks
TO DISK = 'C:\AdventureWorks_compactado.BAK'
WITH COMPRESSION;

Agora o mais interessante: comparando backups da base AdventureWorks, um compactado e outro sem compactação, temos os seguintes números:

Vemos que o arquivo compactado tem cerca de 25% do tamanho do arquivo sem compactação. Bem bacana, não é?

Se você deseja que a compactação de backup seja Default na sua instância, altere a configuração backup compression default para 1:

EXEC sp_configure 'backup compression default', '1';
RECONFIGURE;

Assim, quando você realizar um backup, mesmo que não utilize explicitamente a opção WITH COMPRESSION (ou esqueça de utilizá-la) seus backups serão compactados.

Bom trabalho!

Na época em que o MSDE estava em alta, muitos amigos vinham pedir dicas de como criar uma rotina automática de backups e etc, o maior impasse era sempre a falta de uma interface gráfica.

Ao contrário das novas versões do SQL Server Express, o MSDE possuía o serviço SQL Agent que permite agendar rotinas, backups, etc, e isso era ótimo, mas a barreira era saber como utilizar essa funcionalidade sem uma ferramenta.

Mas enfim, o foco desse texto não é o MSDE, até porque, com o tempo foram disponibilizadas algumas ferramentas para suprir algumas necessidades. A idéia principal é verificarmos como criar uma nova tarefa (job) e automatiza-la utilizando scripts no SQL Server.

Analisando um pouco veremos que precisamos apenas de 4 procedures para criação de um job: sp_add_job, sp_add_jobstep, sp_add_jobserver e sp_add_jobschedule. No nosso texto vamos utilizar como exemplo um cenário onde precisamos automatizar o backup da base de dados Master. Vamos analisar agora cada uma das procedures:

• sp_add_job

Esta procedure adiciona um novo registro à tabela sysjobs, em linhas gerais, este registro é o nosso job, porém um job sem qualquer funcionalidade e sem agendamento. Inicialmente um job nessas condições não tem qualquer utilidade. Abaixo podemos verificar a criação de um job vazio com o título Backup MASTER:

execute sp_add_job @job_name = 'Backup MASTER'

• sp_add_jobstep

Para darmos “vida” ao job criado anteriormente, precisamos adicionar funcionalidades a ele, por exemplo: um passo onde será executado o script de backup.  Para adicionar funcionalidades ao job Backup MASTER precisamos conhecer seu código gravado na sysjobs, para isso podemos executar o seguinte comando:

select  job_id
from  sysjobs
where name = 'Backup MASTER'

O resultado será um big código! Isso porque o código gerado é do tipo UNIQUEIDENTIFIER, popularmente conhecido como Identificador Universal.  O resultado da minha consulta é: 7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31 (é mais prático trabalhar com conteúdos deste tipo armazenando-o numa variável, porém, neste texto iremos aborda-lo explicitamente em cada passo dos exemplos).

Ok. Agora vamos utilizar este big-código junto com a sp_add_jobstep para adicionarmos funcionalidade ao nosso JOB:

-- Adiciona função ao Job
execute sp_add_jobstep @job_id = '7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31',
     @step_name = 'Script Backup Master',
     @command = 'backup master to disk = ''c:\master.bak'''

Observe que utilizamos três parâmetros junto à sp_add_jobstep: o código do job (@job_id), o nome da funcionalidade (@step_name) e finalmente o script de backup no parâmetro @command.

É interessante esclarecer que um job pode ter inúmeros passos/tarefas, logo você poderá utilizar esta procedure quantas vezes forem necessárias para adicionar novos passos a um mesmo job.

• sp_add_jobserver

Agora vem o passo mais “abstrato” desse processo. Após criarmos o job e definir suas funções precisamos definir em qual servidor ele irá operar. Pressupõe-se que se o job foi criado no servidor <strong>X</strong> que ele deverá ser executado no contexto deste servidor, porém, aqui nós temos que explicitar isto, logo, precisaremos executar a procedure sp_add_jobserver e configurar o job para rodar no contexto do servidor local:

execute sp_add_jobserver
     @job_id = '7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31',
     @server_name = N'(local)'

Pronto!

Neste momento nosso job já tem uma forma e já pode ser executado.

Se quisermos testar a execução manualmente, podemos executar o seguinte comando:

 sp_start_job 'Backup MASTER'

Resultado:

Job ‘Backup MASTER’ started successfully.

Vejam que nosso job foi executado com sucesso e que o arquivo foi criado:

• sp_add_jobschedule

Considerando que a principal funcionalidade do SQL Server Agent e seus jobs é automatizar tarefas, não há muito sentindo em executar jobs manualmente, logo, precisamos criar um agendamento para nosso job e assim partimos para a última etapa deste processo onde recorremos à procedure sp_add_jobschedule:

execute sp_add_jobschedule
     @job_id = '7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31',
     @name = N'Agenda Backup',
     @freq_type = 4,
     @active_start_time = 120000,
     @freq_interval = 1

O comando pode parecer complexo, mas analisando com calma veremos que é bem tranquilo. Vamos analisar cada um dos parâmetros separadamente:

No @job_id definimos para qual job estamos criando o agendamento utilizando o “big-código”.

Em @name atribuímos um nome para o nosso agendamento.

Em @freq_type temos as seguintes possibilidades:

No nosso script @freq_type = 4, logo, o comando indica que o job será executado diariamente.

Em @active_start_time definimos o horário da execução, no nosso exemplo 12:00:00, sem os sinais de separação entre horas, minutos e segundos. Se o conteúdo desse parâmetro fosse 215600, o job seria executado às 09:56 da noite.

Por fim temos o parâmetro @freq_interval que está diretamente atrelado ao parâmetro @freq_type e foi definido como 1 porque nosso backup será executado todos os dias.

(Pode ser complexo definir valor para o parâmetro @freq_interval, mas não iremos nos aprofundar nele neste momento. Para entender sua composição consulte: http://msdn.microsoft.com/pt-br/library/ms366342.aspx)

Para verificar todos os parâmetros das procedures listadas acima, digite por exemplo:

 sp_help sp_add_jobschedule 

• CONCLUSÃO

Neste texto podemos notar que automatizar tarefas via script não é uma tarefa tão árdua, mas sem dúvidas, na maioria
dos cenários, a utilização de uma ferramenta gráfica proporcionará maior produtividade; porém se um dia você se deparar com um MSDE ou situação semelhante, irá lembrar que com basicamente 4 passos é possível automatizar suas rotinas.

Uma estratégia de backup é algo muito particular de cada negócio; em alguns ambientes críticos é inadimissível a perda de um minuto de informação, já em outros lugares, na ocasião de uma falha, um backup do dia anterior é a solução ideal; logo, a forma como mesclar os diferentes tipos de backups é uma questão a ser analisada (e testada!) com muito critério.

No entanto de uma coisa temos certeza: toda estratégia de backup incluirá um backup completo (comumente chamado de backup FULL) e neste texto iremos focar na recuperação (via script) de um backup completo no SQL Server; para isso utilizaremos como base dois cenários:

• O primeiro cenário abordará o restore de um backup FULL sobre a base original (do backup), por exemplo, sua base de dados atual sofreu alterações inadequadas e agora precisa da restauração do último backup para reaver os dados anteriores.
• No segundo cenário iremos visualizar um DBA que recebe um backup completo de um cliente e precisa restaurá-lo em outro ambiente, por exemplo, para sua equipe de desenvolvimento.

CENÁRIO 1

Temos aqui um arquivo de backup chamado AdventuresWorks_FULL.bak. Antes de restaurá-lo precisamos verificar qual o conteúdo desse arquivo físico e se o backup existente irá atender a necessidade do restore; para isso utilizaremos o seguinte comando:

restore headeronly from disk ='C:\LabRestore\AdventuresWorks_FULL.bak'

Veja o resultado:

No resultado da execução do comando RESTORE HEADERONLY podemos identificar que o arquivo em questão contém três backups (sim! um arquivo físico pode conter inúmeros backups de uma mesma base). Observe a posição de cada backup dentro do arquivo (campo Position), o tamanho de cada um (BackupSize)  e suas respectivas datas (BackupStartDate).

No nosso exemplo vamos restaurar o backup do dia 03 de Fevereiro, logo, o backup a ser restaurado será o da posição 2 (dois). Vamos ao script:

USE MASTER

GO

RESTORE DATABASE AdventureWorks

FROM DISK = 'C:\LabRestore\AdventuresWorks_FULL.bak'

WITH FILE = 2, REPLACE, STATS = 10

A base de dados a ser restaurada é a AdventureWorks, o arquivo de backup está localizado no endereço: C:\LabRestore\AdventuresWorks_FULL.bak. O backup que será restaurado está na posição 2 deste arquivo (FILE = 2). Como a base já existe é necessário sobrescrevê-la, para isto utilizamos a opção REPLACE. O STATS mostrará o progresso da restauração em intervalos de 10 em 10%.

Importante: Numa operação de restore a base não deve estar em uso por nenhum usuário (inclusive você), por isso antes de iniciar o script direcionamos a sessão para o database Master. Se a base estiver em uso, a seguinte mensagem de erro será exibida:

Msg 3101, Level 16, State 1, Line 1

Exclusive access could not be obtained because the database is in use.

Se tudo estiver ok, ao final da execução do script você verá uma mensagem similar a esta:

RESTORE DATABASE successfully processed 22514 pages in 10.209 seconds (18.065 MB/sec).

CENÁRIO 2

Neste cenário o DBA deverá restaurar um backup completo recebido de um cliente externo. O arquivo de backup está identificado como SistemaX_FULL.bak e será restaurado no ambiente de desenvolvimento que é composto por um servidor com um único disco (C:\).

Vamos analisar o conteúdo do arquivo com o RESTORE HEADERONLY:

restore headeronly from disk = 'C:\LabRestore\SistemaX_FULL.bak'

Veja o resultado:

No resultado acima verificamos que existe um único backup neste arquivo. A base do cliente (campo DatabaseName) está identificada por SistemaX e podemos verificar também outros dados como o tamanho do backup e data.

Até aqui tudo bem, mas neste cenário precisamos analisar novos elementos, isso porque a base em questão ainda não existe e ao efetuar a restauração o SQL Server irá trazer além dos objetos deste banco (tabelas, procedures, triggers) suas configurações originais como: endereço dos arquivos físico de dados e log, modo de recovery, etc. Para verificar o estado de algumas destas propriedades podemos utilizar o comando RESTORE FILELISTONLY:

restore filelistonly from disk = 'C:\LabRestore\SistemaX_FULL.bak'

Veja o resultado:

Observe que a base do cliente e seus respectivos arquivos de dados e log estão localizados em discos diferentes. Neste caso, se o DBA realizar um restore comum (como o script utilizado no exemplo anterior) o SQL Server tentará alocar estes arquivos em seus caminhos de origem, logo precisamos alterar este comportamento, já que neste cenário o servidor onde será realizado o restore só possui um disco. Veja o comando:

USE MASTER

GO

RESTORE DATABASE SistemaX
FROM DISK = 'C:\LabRestore\SistemaX_FULL.bak'
WITH
MOVE 'SistemaX' TO 'C:\LabRestore\SistemaX.mdf',
MOVE 'SistemaX_log' TO 'C:\LabRestore\SistemaX_log.ldf',
STATS = 10

A base de dados a ser restaurada é a SistemaX e o arquivo de backup está em: C:\LabRestore\SistemaX_FULL.bak. Observe que adicionamos a opção MOVE; esta opção direciona os arquivos de dados e log para um novo caminho. O restante não muda; continuo utilizando o STATS e desta vez não precisamos do REPLACE já que a base não existia.

É importante destacar que os comandos RESTORE FILELISTONLY e RESTORE HEADERONLY não são obrigatórios num processo de restauração de banco; eles são comandos que recuperam informações sobre os arquivos de backup e estas informações podem auxiliar o DBA no processo de restauração.

Existem outros comandos similares, como o RESTORE VERIFYONLY que verifica se o arquivo de backup está legível.

CONCLUSÃO

Como podemos verificar, o restore de um backup full, via script não é difícil, basta conhecer os comandos certos para recuperar informações sobre o conteúdo do arquivo de backup; estas informações  irão auxiliar o usuário na construção do comando de restore.

Nos próximos posts iremos abordar o restore de backups diferenciais e log. Até +

Bom trabalho!

A solução mais rápida? Enviei para o datacenter o procedimento de execução dos scripts via SQLCMD.

Mas o que é isso?

O SQLCMD é uma ferramenta que você utiliza para acessar instâncias SQL Server via prompt de comando (vulgo DOS). Não existem segredos, uma vez conectado, através de scripts você pode fazer tudo o que faria utilizando o Query Analyser ou o Management Studio. Apesar de ser uma excelente ferramenta, o SQLCMD tem suas limitações “gráficas”, no entanto em alguns cenários é a ferramenta ideal!

Os exemplos que vou apresentar foram executados na minha estação de trabalho. Nela tenho instalado um SQL Server 2005. Minha instância é uma instância nomeada e é identificada como SQL05.

Pra começar a conversa vamos ao prompt de comando (menu Iniciar > Executar > cmd).

No prompt de comando, para conectar no meu SQL local (localhost), utilizando o SQLCMD, devo digitar o seguinte comando:

sqlcmd –E  –S  LOCALHOST\SQL05

No comando acima estou conectando no SQL Server utilizando a autenticação Windows (-E) na instância SQL05 (-S), mas se for necessário conectar utilizando a autenticação do SQL Server, ficaria assim:

sqlcmd  –U SA –P senhateste –S  LOCALHOST\SQL05

No exemplo acima, estou conectando no SQL utilizando o login SA  do SQL Server (-U) com a senha  senhateste (-P).

Se a conexão for realizada com sucesso o prompt do SQLCMD ficará similar à imagem abaixo:

Se o seu SQL Server foi instalado como uma instância padrão a conexão é ainda mais simples, pois você não precisa especificar o nome da instância. No exemplo abaixo estamos conectando numa instância padrão do SQL Server, utilizando autenticação Windows.

sqlcmd –E

Uma vez conectado, para sair do SQLCMD podemos utilizar os clássicos EXIT ou CTRL + C.

Dentro do SQLCMD é importante saber que suas instruções sql só serão executadas quando você digitar um GO e confirmar com um ENTER. No exemplo abaixo eu mudei o contexto para a base de dados Northwind e logo depois executei uma consulta. Veja que ao fim de cada instrução eu adicionei um GO.

Note que a cada GO a numeração das linhas recomeça.

Uma vez conectado, como já citado, você poderá executar qualquer instrução SQL desde selects, updates, até a criação de bancos e tabelas ou a execução de procedures do sistema que te auxiliem a monitorar seu SQL Server, como:

Ler log do SQL Server

sp_readerrorlog

go

Verificar conexões na instância:

sp_who

go

Etc…

Combinado a isto, é possível também executar comandos do DOS dentro do SQLCMD. Para listar o C:\ basta digitar

!!dir C:\

Se quiser dar uma limpada na tela, digite:

!!cls

Como você pode notar todos os comandos do prompt DOS são precedidos por dois pontos de exclamação (!!).

Ok…

Mas digamos agora que você tenha aí um script pronto e deseja executá-lo no SQLCMD, além disso deseja gravar o resultado da execução deste script num arquivo txt. Vamos exemplificar esta situação utilizando o script abaixo que será salvo na unidade c:\ num arquivo identificado como teste.sql.

USE northwind

– lista todas as colunas da tabela Categories da base Northwind

SELECT

table_name nomeTabela,

column_name nomeColuna,

data_type tipoDaColuna,

isnull(character_set_name, ‘NoUnicode’) campoUnicode

FROM

information_schema.columns

WHERE

table_name = ‘Categories’

Veja como fica a linha dessa chamada utilizando o SQLCMD:

sqlcmd -E -S LOCALHOST\SQL05 -i”c:\teste.sql” -o”resultado.txt”

O parâmetro –i indica o arquivo de entrada (INPUT),  que contém o script que será executado. O parâmetro –o indica qual será o arquivo de saída (OUTPUT), que conterá o resultado da execução.

Como qualquer assunto no SQL Server, este é mais um que poderíamos discorrer por páginas e mais páginas… mas por enquanto ficamos por aqui. Creio que essa introdução é o suficiente pra entendemos o potencial desta ferramenta.

Para obter mais informações sobre os parâmetros do SQLCMD, no prompt do DOS digite sqlcmd -? Se esse help parecer um pouco confuso você poderá acessar este link e ter informações mais detalhadas.

É importante lembrar que o SQLCMD está disponível para o SQL Server 2005 e 2008. Para versões anteriores utilize o OSQL ou ISQL.

Bom trabalho, bons estudos!

Mendes

O artigo abaixo foi escrito por Lynn Pettis para o site www.sqlservercentral.com. O texto original pode ser lido aqui.

Como calcular a idade de uma pessoa? Isto pode tornar-se um tema polêmico e com inúmeras soluções. Mas antes de criticar este tópico considere que ele pode ajudar a definir algumas regras a serem utilizadas na criação de um algoritmo que calcule a idade.

A parte mais difícil é saber o que fazer com os anos bissextos. Quando é que uma pessoa (objeto/documento) torna-se um ano mais velha? Neste pequeno artigo iremos definir que isto ocorre em 28 de fevereiro de anos não-bissextos.

Antes de mergulhar nos cálculos, vamos fazer alguns cálculos simples usando o SQL Server 2005.

Primeiro, vamos ver o que acontece quando adicionamos um ano às datas: 28/02/2008 e 29/02/2008:

declare @data1 datetime, @data2 datetime

set @data1 = ’20080228′

set @data2 = ’20080229′

select dateadd(yy, 1, @data1), dateadd(yy, 1, @data2)

Resultado:

2009-02-28 00:00:00.000  2009-02-28 00:00:00.000

Observem que adicionar um ano para ambas as datas, resultam na mesma data. Vamos ver então o que acontece quando adicionamos 4 anos:

declare @data1 datetime,@data2 datetime

set @data1 = ’20080228′

set @data2 = ’20080229′

select dateadd(yy, 4, @data1), dateadd(yy, 4, @data2)

Resultado:

2012-02-28 00:00:00.000  2012-02-29 00:00:00.000

Veja que agora as datas são diferentes. Isto é o que esperávamos.

Agora vamos ver a função DATEDIFF e ver um pouco como ela trabalha:

declare @data datetime,@date2 datetime

set @data = ’20080229′

set @date2 = ’20090228′

select datediff(yy, @data, @date2)

Resultado:

1

Ok, mas qual o resultado da próxima consulta?

declare @data1 datetime,@data2 datetime

set @data1 = ’20081231′

set @data2 = ’20090101′

select datediff(yy, @data1, @data2)

Resultado:

1

Espere…Isso não está certo, não existe um ano de diferença entre essas datas, alguma coisa deve estar errada.

Como você pode ver a função DATEDIFF retornou o numero da diferença entre os anos e não o número real de anos entre as duas datas.

Nós podemos usar esta informação para criar um T-SQL simples:

declare @data_nascimento datetime, @idade int, @data_atual datetime

set @data_atual = ’2008-02-28′

set @data_nascimento = ’2007-03-01′

set @idade = datediff(yy,@data_nascimento,@data_atual) - case when @data_atual < dateadd(yy,datediff(yy,@data_nascimento,@data_atual), @data_nascimento) then 1 else 0 end

select @idade

Conclusão

Este é apenas um método para calcular a idade de uma pessoa. Existem outras inúmeras formas que podem ser usadas. Tudo o que posso sugerir é que você use o método que melhor lhe atenda em cada situação.