Category Archives: Dicas

O que é SQL?

Pra começar você precisa saber que SQL não é um banco de dados; SQL é um idioma (entre especialistas costumamos substituir o termo “idioma” por “linguagem”). A sigla SQL significa Structured Query Language; em português: linguagem de consulta estruturada. Destaquei o “consulta” porque o foco dela é justamente isso: consultar!

Os bancos de dados (ou gerenciadores de bancos de dados) nasceram antes da linguagem SQL e cada qual tinha sua própria linguagem de consulta. Logo os usuários e fabricantes notaram que essa torre de babel não era interessante e optaram pela criação de um único idioma para consultar bancos de dados relacionais (em outra oportunidade falaremos sobre os bancos dimensionais). O órgão American National Standards Institute (ANSI) ficou responsável pela padronização desta linguagem e de tempos em tempos realiza encontros entre fabricantes para discutir a linguagem SQL e propor melhorias; no entanto esta padronização não impede que cada fabricante personalize a linguagem SQL para atender suas necessidades, e é aí que surgem os dialetos.  Por exemplo, o “dialeto” do gerenciador de banco de dados Oracle é o PL/SQL; o do SQL Server é o T-SQL (transact SQL) e etc.

Agora é importante que você não confunda a linguagem SQL com gerenciadores de banco de dados! Isso é um erro muito comum!

Por exemplo, o gerenciador de banco de dados Microsoft SQL Server (como o nome já diz), é um programa que gerencia bancos de dados. A arquitetura dos sistemas gerenciadores de bancos de dados (SGBDs) é definida de forma que os dados possam estar sempre consistentes e que sejam recuperados da forma mais rápida possível! Digamos que estes são itens de série de qualquer SGBD. Para tornar os gerenciadores de bancos de dados ainda mais atraentes, os fabricantes adicionam outras inúmeras funcionalidades para facilitar o trabalho dos DBAs, aumentar a segurança, a disponibilidade e etc.

Hoje existem diversos gerenciadores de bancos de dados disponíveis no mercado, como o Oracle, o Microsoft SQL Server, o PostgreSQL, entre outros. Todos utilizam a linguagem SQL para consultar dados.

A grande dúvida que paira na cabeça de alguns profissionais de TI é: qual o melhor banco de dados? SQL Server? Oracle?! DB2?

O que eu digo é o seguinte: o melhor gerenciador de banco de dados é aquele que atende adequadamente o seu negócio. É como comprar um carro: você compraria uma Ferrari para fazer rally?! Compraria um Fusca para fazer uma longa viagem pelo Brasil?

Conclusão

SQL é uma linguagem de consulta a bancos de dados relacionais. No mercado atual existem inúmeros sistemas gerenciadores de bancos de dados relacionais (comumente chamados apenas pela sigla SGBD); podemos citar como exemplo o Oracle, Microsoft SQL Server, DB2, etc. Estes gerenciadores de bancos de dados utilizam a linguagem SQL para consultar os dados; porém, adicionam à esta linguagem soluções para atender suas particularidades e aí nascem dialetos como o PL/SQL, PL/pgSQL e o T-SQL.

Nos próximos posts falaremos mais sobre a linguagem SQL e os gerenciadores de bancos de dados.

Para conhecer mais detalhes sobre a linguagem SQL, dê uma olhada nesse post e fique familiarizado com outras siglas populares no mundo SQL como: DDL e DML!

Até +

Backup FULL reinicia sequência do LOG. Mito?

Olá,

No mês de Abril fiz o curso de SQL Server Internals com o Luciano Moreira, mais conhecido na comunidade como Luti; não vou me estender muito neste assunto, mas se você é um DBA SQL Server, recomendo fortemente que faça este curso. Excelente…

Mas vamos ao foco do nosso post. Durante o curso de internals alguns mitos foram por água abaixo; um deles foi  “Ao realizar um backup full, perdemos a sequência do log”.

Verdade? Sim ou Não?

Bom, confesso que eu sempre tive isso como verdade absoluta e tenho certeza que outros inúmeros DBAs SQL Server pensam o mesmo; mas a verdade é que não, realizar um backup full não quebra a sequência do seu log. Mas falando assim não tem graça né, vamos testar a brincadeira:

Primeiro criamos um banco para nosso teste (no fim do post está o script completo do nosso teste):

CREATE DATABASE testeBackup

Por padrão o SQL Server criar o banco com o recovery model FULL (exceto na edição Express). Isto é importante para o nosso teste já que iremos realizar backup do log. Para confirmar:

-- Recovery Model = FULL
SELECT recovery_model_desc
FROM sys.databases
WHERE NAME LIKE 'testeBackup'

Vamos criar uma tabela para nossos testes e realizar nosso primeiro backup FULL:

USE testeBackup

-- Cria tabela
CREATE TABLE registroBackup
	(id INT IDENTITY,
	registro VARCHAR(50))

-- Realiza backup FULL
BACKUP DATABASE testeBackup
TO DISK = 'C:\testeBackupFULL.bak' WITH INIT

Agora utilizando uma estrutura de repetição inserimos 1 registro na tabela e realizamos um backup de log. Isso repetirá por 5 vezes:

DECLARE @i INT

SET @i = 1

WHILE @i <= 5
BEGIN
	-- Insere registro
	INSERT INTO registroBackup
	VALUES ('Antes do '+CAST(@i AS VARCHAR(2))+'º backup de LOG')
	-- Realiza backup de log
	BACKUP LOG testeBackup
	TO DISK = 'C:\testeBackupLOG.bak'
	WITH NOINIT
	-- Incrementa contador
	SET @i = @i + 1
END

Verificamos então os registros inseridos na tabela:

SELECT * FROM registroBackup

Resultado:

E verificamos os nossos backups de log:

RESTORE HEADERONLY FROM DISK = 'C:\testeBackupLOG.bak'

Resultado:

Como verificamos temos aí 5 registros e 5 backups de log.

Agora realizamos um novo backup FULL:

BACKUP DATABASE testeBackup
TO DISK = 'C:\testeBackupFULL_2.bak' WITH INIT

E repetimos a execução do laço:

DECLARE @i INT

SET @i = 6

WHILE @i <= 10
BEGIN
	-- Insere registro
	INSERT INTO registroBackup
	VALUES ('Antes do '+CAST(@i AS VARCHAR(2))+'º backup de LOG')

-- Realiza backup de log
	BACKUP LOG testeBackup
	TO DISK = 'C:\testeBackupLOG.bak'
	WITH NOINIT

-- Incrementa contador
	SET @i = @i + 1
END

Ao fim temos 10 registros em nossa tabela, 10 backups de LOG e 2 backups FULL.

Agora entra a figura do estagiário que exclui o segundo arquivo de backup FULL… (sacanagem, rss)

Segundo a lenda, isso inválida todos os backups de log posteriores e teríamos que realizar um backup FULL imediatamente, porque ao realizar o segundo backup FULL perderíamos a seqüência do log.  Certo? Bom… vamos testar:

Excluímos  a base de dados:

USE MASTER
GO
DROP DATABASE testeBackup

E restauramos os backups (FULL + LOGs) ignorando o segundo backup FULL:

RESTORE DATABASE testeBackup
FROM DISK = 'C:\testeBackupFULL.bak' -- primeiro backup FULL
WITH NORECOVERY

-- Restauramos os 10 arquivos de log

DECLARE @i INT
SET @i = 1

WHILE @i <= 10
BEGIN

	RESTORE LOG testeBackup
	FROM DISK = 'C:\testeBackupLOG.bak'
	WITH FILE = @i, NORECOVERY

	SET @i = @i + 1

END

	RESTORE DATABASE testeBackup
	WITH RECOVERY -- colocamos a base em operação

Verifique que restauramos os 10 registros de nossa tabela:

USE testeBackup
SELECT COUNT(*) FROM registroBackup

Resultado:

Enfim, note que a realização do 2º backup FULL não quebrou a seqüência dos nossos backups de log!

Agora a pergunta que não quer calar: qual a função do parâmetro de backup COPY_ONLY lançado a partir do SQL Server 2005?!

Um backup diferencial tem total dependência do último backup FULL; logo, se você perder o backup FULL anterior, não será possível restaurar o diferencial, mesmo com um FULL mais antigo. Então pense numa situação que você precise de um backup FULL adicional, mas não deseja que ele afete seus próximos backups diferenciais (que deverão continuar utilizando como referência o backup FULL anterior), então aqui utilizaríamos o COPY_ONLY.

Resumindo: Os backups diferenciais posteriores iram ignorar um backup FULL com COPY_ONLY.

CONCLUSÃO

Backup FULL não altera a sequência dos backups de LOG. Se você perdeu seu último backup FULL, mas tem um do mês passado e de lá pra cá todos os seus backups de LOG estão intactos, não se desespere! Você conseguirá restaurar seu backup.

PS: Obrigado Luti pela super dica :D

Disponibilizei o script completo deste teste aqui.

Até +

Movimentando arquivos da base de dados

Uma das atividades que pontuam a rotina de um DBA é a movimentação de arquivos de bancos de dados; normalmente resultado de falta de espaço em disco, mudança de arquitetura, otimização e etc.

Nosso cenário: Os arquivos de dados e log da base de dados MoveArquivo estão no mesmo disco. Para otimizar a performance decidimos movimentar o arquivo de log para outro disco.

Existem diversos meios de realizar esta tarefa, a seguir iremos analisar uma delas (e a que particularmente acho mais prática):

“Mão na massa”

Primeiro, precisamos ter algumas informações em mãos; por exemplo, o nome lógico do arquivo que será alterado e o local atual do arquivo de log de nossa base de dados:

Para isso podemos utilizar o comando sp_helpdb:

Ok; já sabemos onde está nosso arquivo de log. Agora precisamos alterar este endereço e para isto utilizamos o seguinte comando:

USE MASTER
GO
ALTER DATABASE MoveArquivo
MODIFY FILE (NAME = 'MoveArquivo_log', FILENAME = 'E:\SQLDbs\Log\MoveArquivo_log.ldf')
GO

Após execução do comando temos a seguinte mensagem:

The file “MoveArquivo_log” has been modified in the system catalog. The new path will be used the next time the database is started.

Temos então, numa tradução livre, o alerta: “O novo caminho só será utilizado após reinicialização da base”. Então fique atento! Este comando não alterou efetivamente o endereço físico do arquivo; para concluir a operação precisamos reiniciar a base.

Para não afetarmos a operação dos outros bancos da instância e para reduzirmos o tempo de parada, não vamos mexer com o serviço do SQL Server; vamos apenas alterar o estado da base de dados, deixando-a offline:

ALTER DATABASE MoveArquivo
SET offline
GO

Após execução deste comando a base fica indisponível para qualquer usuário e agora podemos copiar fisicamente o arquivo de log para seu novo endereço. Neste momento, através de um CTRL + C, CTRL+ V (ou qualquer outro meio de copiar um arquivo no Windows) copiamos o arquivo para seu novo endereço.

Atenção: tenha certeza de copiar o arquivo para o mesmo endereço informado no primeiro comando ALTER DATABASE.

Finalizada a cópia, podemos reiniciar nossa base de dados com o seguinte comando:

ALTER DATABASE MoveArquivo
SET online
GO

Pronto! Arquivo de log movimentado para novo endereço.

O mesmo procedimento pode ser utilizado para outros tipos de arquivos (como arquivos de dados). Para as bases de sistema (MASTER, TEMPDB, etc) não será possível utilizar a opção SET ONLINE/OFFLINE; neste caso teremos que reiniciar o serviço do SQL Server, afetando a disponibilidade de toda instância.

Até +

Oportunidade: Students to Business

Dica de última hora!!!

Pra você que é estudante e quer ficar mais próximo do mercado de TI, vai aí uma dica bem interessante:

Até o dia 28/09/2010, a Microsoft recebe inscrições para a 7º edição do Microsoft Students to Business; esse é um programa que pretende aproximar os estudantes para o mercado de TI, fornecendo um super treinamento de 84 horas… e o melhor de tudo: gratuito.

O público alvo são alunos do ensino médio, cursos técnicos, superior e pós-graduação… e o estudante pode optar pelas seguintes áreas: desenvolvimento de sistemas, infraestrutura, banco de dados, Expression Web e Dynamics CRM.

Então fique ligado:

Inscrições até o dia 28/09/2010.

Mais informações no site: http://proform.msdnbrasil.com.br/PortalS2B/

Boa sorte!

Backup compactado

A compressão de backups sempre foi um dilema para quem lida com grandes bases de dados no SQL Server. Muitos DBAs criaram rotinas para compactar arquivos de backup utilizando o bom e velho RAR, outros utilizavam soluções mais interessantes como o SQL Backup da RedGate.

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!

T-SQL – Mesclando dados

O SQL Server 2008 trouxe para o T-SQL um comando brilhante que realmente facilita a vida de muita gente; o comando em questão é o MERGE. A idéia deste comando é mesclar dados, logo você pode comparar duas tabelas e utilizar o comando MERGE para sincronizá-las.

Vamos a um exemplo simples:

Primeiro criamos duas tabelas com estrutura idêntica. A chave primária destas tabelas é o campo CPF:

create table Tabela1 (
Nome varchar(50),
Idade int,
CPF char(11) primary key);

create table Tabela2 (
Nome varchar(50),
Idade int,
CPF char(11) primary key);

Agora inserimos dados nas tabelas. Observe que os dados estão diferentes, alguns tem diferença no nome, outros registros estão sobrando ou faltando em ambas tabelas:

insert into Tabela1 values
('Silas Mendes' , 29, '08148338716'),
('Maria José'   , 49, '55978913269'),
('Pedro Ribeiro', 53, '05899714732'),
('Joana Silva'  , 18, '74105689623');

insert into Tabela2 values
('SILAS Mendes'       , 29, '08148338716'),
('Maria Jose'         , 49, '55978913269'),
('Pedro Ribeiro Souza', 53, '05899714732'),
('Carlos Mania'       , 19, '12345678999');

Agora precisamos sincronizar as tabelas, vamos analisar passo-a-passo a construção do comando MERGE (o comando completo está disponível no fim do texto) .

A tabela de destino (target) é a tabela2; a tabela de origem (source) é a tabela1. A chave primária das tabelas será utilizada na comparação:

merge into tabela2 as target
using (select nome, idade, cpf from tabela1)
  as source (nome, idade, cpf)
  on (target.cpf = source.cpf)

Quando os números dos CPFs forem encontrados em ambas tabelas então atualizamos os dados na tabela alvo (target):

when matched then
		 update set target.nome = source.nome,
					target.idade = source.idade,
					target.cpf = source.cpf

Quando os números dos CPFs não forem encontrados na tabela de destino, então inserimos os dados da tabela de origem:

when not matched by target then
		 insert (nome, idade, cpf) values (nome, idade, cpf)

E finalmente, quando existirem números de CPFs no destino que não existem na origem, apagamos os registros que sobram:

when not matched by source then
		 delete;

Veja o código completo do comando MERGE:

merge into tabela2 as target
using (select nome, idade, cpf from tabela1)
  as source (nome, idade, cpf)
  on (target.cpf = source.cpf)

-- Atualiza registros diferentes
when matched then
		 update set target.nome = source.nome,
					target.idade = source.idade,
					target.cpf = source.cpf

-- Insere registros que não existem no destino
when not matched by target then
		 insert (nome, idade, cpf) values (nome, idade, cpf)

-- Se existir no destino e não existir na origem é apagado
when not matched by source then
		 delete;

Por fim realizamos o SELECT nas duas tabelas para verificar o resultado após a sincronização:


select * from Tabela1;
select * from Tabela2;

Bom trabalho, bom estudo!

SQL Server 2008 R2 Express Edition

A cada nova versão do SQL Server a Microsoft torna suas edições gratuitas ainda mais atrativas. Já abordei anteriormente por aqui sobre a instalação do SQL Server 2008 Express; então se você está procurando informações sobre SQL Server 2008 Express, aproveite esse texto para se atualizar sobre o segundo release (R2) do SQL Server 2008 Express Edition.

De cara, a principal novidade é que SQL 2008 R2 Express permite gerenciar bases de dados com até 10 GB. Na última versão o limite eram 4 GB por base de dados. Uma melhoria interessante não é?

As limitações de CPU e memória continuam as mesmas, sendo 1 CPU e 1GB RAM. No caso da CPU lembre-se que a limitação é por chip; logo, se você tiver um chip Six-Core seu SQL irá utilizar os 6 núcleos deste chip.

Para este release são ofertados três opções de instalação: a instalação SQL Server 2008 R2 Express instala somente a engine do SQL, ou seja, o serviço principal do SQL Server onde é possível rodar bancos de dados, criar ou alterar objetos e etc, porém sem nenhuma ferramenta gráfica. A instalação SQL Server 2008 R2 Express with Tools Edition oferece a engine e adiciona também o Management Studio que é uma ferramenta gráfica para gerenciamento das instâncias; na SQL Server 2008 R2 Express with Advanced Services além da engine e do Management Studio é oferecido também o Reporting Services para o desenvolvimento de relatórios no SQL Server. Ambas instalações estão disponíveis para as plataformas de 32 e 64 bits.

Os pré-requisitos continuam os mesmos: se você for instalar somente a Engine desta versão (sem nenhuma ferramenta gráfica), será necessário somente o Framework 2.0; se for utilizar as ferramentas gráficas o Framework 3.5 SP1 é um pré-requisito. Assim como na última versão o Windows Installer 4.5 e Windows Power Shell 1.0 são necessários para a instalação.

O processo de instalação continua bem similiar ao que publiquei aqui no ano passado, portanto se desejar um passo-a-passo da instalação básica acesse este link.

E pra finalizar segue o link de download do R2 Express: http://www.microsoft.com/express/Database/InstallOptions.aspx

Até +

MCTS SQL Server 2008

Eu estava reagendando esta prova a mais de um mês. Toda vez que eu folheava o Training Kit me deparava com uma novidade do SQL Server 2008 que me fazia olhar e querer entender mais os detalhes, e assim eu reagendava o exame pois achava que não estava preparado. No fim de semana estabeleci que faria a prova na segunda-feira (ontem) e que não iria adiar mais.

A questão é que o foco do 70-432 não são os detalhes, você precisa ter o conhecimento das novas features, entender suas principais finalidades e os pré-requisitos para implementá-las.

O exame me surpreendeu porque eu esperava um grau maior de dificuldade… mas foi uma boa prova; o grande foco está nas novidades, mas em algumas questões você tem que utilizar soluções de versões anteriores. Ao contrário da 70-431 não teve o teste prático (que eu achava interessante) e foram quase duas horas para responder aproximadamente 40

questões. Comparando os dois exames, para mim o 70-432 está mais fácil.

Se você está preocupado com a complexidade das novas features do SQL Server 2008, eu te encorajo dizendo que este não é o exame que irá abordar detalhes. Foque na visão geral da administração e encare a prova.

Tenho que acrescentar também que esta foi a primeira vez que fiz uma prova na Brás Figueiredo e a experiência foi muito agradável: ambiente silencioso, ar-condicionado numa temperatura adequada, um bom equipamento, enfim, recomendo.

Depois de escrever tudo isso tenho que complementar que fui aprovado :)

A sensação de não utilizar a “Segunda Chance” é sempre boa (não posso negar) e eu só posso desejar o mesmo a todos vocês.

Bom trabalho e bom estudo!

Copa Microsoft 2010

Já está rolando a Copa Microsoft, uma ótima oportunidade para atualizar seu conhecimento nas novas ferramentas da Microsoft. Além da atualização o participante concorre a prêmios bem interessantes como uma LED 42’’, XBOXs, BluRay, Technet Plus e etc.

Inicialmente é possível ganhar pontos indicando amigos e baixando os softwares; depois vem as provas online para as quais você poderá se preparar assistindo aos webcasts… isso é só o começo, depois vem treinamentos e provas na Microsoft e a preparação de um vídeo onde o participante deverá demonstrar em 3 minutos a utilização de uma das novas tecnologias. A final é uma prova surpresa :D

Já rolaram duas provas online: Windows Server 2008 R2 e Exchange 2010; mas pra quem tá interessado, ainda dá tempo de se inscrever e correr atrás!

http://www.talentosmicrosoft.com.br/

To lutando pra garantir meu 12º lugar… mas tá difícil, risos, a concorrência é pesada :)

Bom jogo!

UPDATE em 22/07/2010:

Infelizmente não consegui ir muito longe no jogo, justamente durante a última prova da 3° etapa (que por sinal era a de SQL Server) meu Internet Explorer travou…  consegui chegar às quartas de final, mas a pontuação acumulada não foi suficiente pra avançar… a decepção foi grande, mas tudo bem.  Parabéns aos ganhadores! No ano que vem tem mais :)

Automatizando tarefas via script


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:

@freq_type Frequência de Execução
1 somente uma vez
4 Diariamente
8 Semanalmente
16 Mensalmente

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.

Restaurar Backup via Script

Existem três tipos básicos de backups no SQL Server: o backup completo, o backup diferencial e o backup incremental. O dois últimos sempre trabalham em conjunto com o backup completo.

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:

01fig

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:

02fig

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:

03fig

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!