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é +

Primeiro tenho que registrar que boa parte das pessoas pra quem enviei o desafio responderam corretamente. Achei interessante a interação e o clima da brincadeira; agora tá na hora de oficializar a resposta. Vamos lá:

Normalmente, quando questionam a diferença entre CHAR e VARCHAR a primeira resposta é: um tem tamanho fixo, o outro tem tamanho variável. Mas já que o CHAR tem tamanho fixo, o que acontece quando inserimos um dado que não ocupa todo o espaço reservado? E além disso, quando inserimos um dado num campo CHAR em qual direção o dado é inserido?

Então, ninguém melhor que o Books Online para responder:

Se um valor mais curto que o comprimento da coluna for inserido em uma coluna char NOT NULL, o valor será preenchido à direita, com espaços em branco, até atingir o tamanho da coluna. Por exemplo, se uma coluna estiver definida como char(10) e os dados a serem armazenados forem “music”, o SQL Server armazenará os dados como “music_____”, onde “_” indica um espaço em branco.

Fonte: http://msdn.microsoft.com/pt-br/library/ms175055.aspx

Com as considerações acima, podemos resumir a consulta do desafio a isto:

SELECT

RIGHT(’05 ‘,2) as ‘CHAR’,

RIGHT(’05′ ,2) as ‘VARCHAR’

Como a função RIGHT está extraindo duas posições à direita (contando com o espaço em branco), o Zero (0) do CHAR é ignorado no resultado.

Valeu pela participação dos amigos, em especial a do amigo Léo Lopes que contribuiu na elaboração da resposta utilizando referências do BOL :)

Hoje a tarde meu amigo Adilson Pereira me mandou um desafio bem interessante, vou postar aqui exatamente do modo como ele propôs:

Observem a diferença que dá no resultado de um comando usando o CHAR e o VARCHAR:

 

declare @data datetime

set @data = ’20100310 05:05:05′

SELECT

RIGHT(’0′ + CONVERT(   CHAR(2), DATEPART(mi, @data)), 2) as ‘CHAR’,

RIGHT(’0′ + CONVERT(VARCHAR(2), DATEPART(mi, @data)), 2) as ‘VARCHAR’

 

A solução é interessante :)

E você? Tem um palpite do porque?

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 X 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.

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:

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!

Ao executar a sp_configure sem parâmetros, são exibidas as configurações atuais da instância. Cada registro representa uma configuração e no campo run_value é possível visualizar o valor atual de cada configuração.

Num cenário padrão ao executar a sp_configure o resultado só exibe algumas das inúmeras opções de configuração; isso porque por padrão o SQL Server oculta opções avançadas. Para exibir todas as opções você deve executar:

USE master;

GO

EXEC sp_configure ‘show advanced option’, ’1′;

GO

RECONFIGURE;

sp_configure ‘nome da configuração’, ‘novo valor da configuração’.

Uma das configurações que podemos alterar utilizando a sp_configure é o limite de memória utilizada pelo SQL Server, vamos exemplificar a alteração desta configuração:

Atualmente minha instância está configurada para utilizar no máximo 500 MB de memória. Ao executar o comando sp_configure é possivel verificar que a opção max server memory (MB) está com o valor 500 nos campos config_value e run_value.

Para alterar a quantidade máxima de memória que a minha instância poderá utilizar executo o seguinte comando:

EXEC sp_configure ‘max server memory (MB)’, ’300′;

No comando acima configurei o máximo de memória disponível para a instância para 300 MB, no entanto se executarmos a sp_configure verificaremos que a opção run_value ainda continua com 500. Para efetivar a alteração preciso executar o comando RECONFIGURE; assim a alteração entrará em vigor.

Figura 1 – Monitorando o contador Target Server Memory durante execução do RECONFIGURE.

É importante salientar que apesar do comando RECONFIGURE ser obrigatório, nem todas as configurações são efetivadas somente com a execução do RECONFIGURE, para estas opções a efetivação só ocorre com a reinicialização do serviço do SQL Server. Para verificar quais são estas opções basta consultar a tabela sys.configurations (disponível no SQL Server 2005/2008). As configurações que tiverem o campo is_dynamic igual a 0 (zero) só entrarão em vigor quando o serviço do SQL Server for reiniciado. Note que se o comando RECONFIGURE não for executado, mesmo que a instância seja reiniciada a nova configuração não entrará em vigor.

Outras configurações possíveis através da sp_configure: habilitar a procedure xp_cmdshell,  procedures do Database Mail,  código gerenciado (CLR), configurar o número de processadores utilizados pela instância (paralelismo), configurar memória extendida (AWE), etc.

• RECONFIGURE ou RECONFIGURE WITH OVERRIDE?

Se ao alterar uma configuração o DBA definir um valor que foge às recomendações do SQL Server, ao executar a opção RECONFIGURE o SQL Server irá rejeitar a alteração e notificar o usuário. Por exemplo, na versão 2000 era possível realizar alterações nas tabelas de sistema do SQL Server (isso mudou um pouco nas versões 2005 e 2008), para isso bastava executar o comando:

EXEC sp_configure ‘allow updates’, ’1′.

No entanto, por razões óbvias esta não é uma prática recomendada, então nessas situações, ao executar somente o RECONFIGURE, o SQL Server exibia a seguinte mensagem:

Configuration option ‘allow updates’ changed from 1 to 1. Run the RECONFIGURE statement to install.

Msg 5808, Level 16, State 1, Line 1

Ad hoc updates to system catalogs not recommended. Use the RECONFIGURE WITH OVERRIDE statement to force this configuration.

Logo o DBA só poderia concretizar essa operação se utilizasse o RECONFIGURE WITH OVERRIDE, ou seja, esta é a forma do SQL Server se proteger contra ações indevidas e dizer ao DBA:  “amigo, isso é por sua conta e risco”. Portanto, o WITH OVERRIDE é uma opção a ser evitada e só é recomendada em situações pontuais.

• Conclusão

Conhecer as diferentes formas de configurar uma instância SQL Server dá ao DBA maior liberdade no momento de realizar estas tarefas, neste caso, além das ferramentas gráficas o DBA também poderá utilizar a sp_configure no SQLCMD, OSQL ou agendar alterações de configurações através de jobs e etc.

Para ter acesso a todas as opções de configurações disponíveis na sp_configure, consulte a tabela sys.configurations ou acesse o Books Online.

Bom trabalho, bons estudos.

Como agendar um script ou executá-lo de forma recorrente sem utilizar o SQL Agent?

O SQL possui um comando de controle de fluxo que pode nos auxiliar nessas tarefas: WAITFOR.

Como utilizá-lo?

Digamos que você queira monitorar o crescimento dos logs a cada 5 minutos. Nesse caso podemos utilizar o WAITFOR DELAY junto com uma estrutura de repetição como o while. Veja o exemplo:

declare @i int

set @i = 1

while @i < 12

begin

– coleta informação sobre espaço utilizado pelo log

dbcc sqlperf(logspace)

– aguarda 05 minutos para continuar

waitfor delay ’00:05:00′

set @i = @i + 1

end

Agora imagine um cenário onde você precise “agendar” a execução de um script para as 22h. Veja o exemplo:

– espera até às 22h

waitfor time ’22:00:00′

GO

dbcc sqlperf(logspace)

GO

select getdate() horaExecucao

É importante salientar que este comando não substitui o SQL Agent! Ele normalmente é utilizado em situações pontuais. Por exemplo, para o DBA às vezes é interessante monitorar durante alguns minutos a situação dos locks e para isso não é necessário criar um job e agendá-lo no SQL Agent, é mais simples utilizar o WAITFOR DELAY. Além disso você pode acompanhar o resultado das execuções diretamente no Management Studio, Query Analyser, sqlcmd, etc.

O comando é interessante, mas não veja nele uma forma de implementar uma nova política de backup, ok?

Bom feriadão!

Durante as apresentações era interessante ouvir as novidades que os palestrantes traziam e a reação do público (rolou até aplausos para algumas features).  Em particular gostei muito da nova interface Ribbon. O produto tem sido moldado para ser mais dinâmico e dá pra notar isso em coisas simples como a alteração e classificação (rating) de conteúdo, mudança entre janelas, etc.

Mas o que eu gostei de ver foi a prévia do Office Web Apps!! Fiquei surpreendido! Trabalhar com arquivos do Office, num browser, com a maioria das funcionalidades da versão instalada foi muito legal. E mais, a Microsoft promete isso em QUALQUER browser (isso eu quero conferir pessoalmente, risos). A feature co-autoria também ficou sensacional. A idéia é realmente facilitar a comunicação e ter o cuidado de tornar a experiência do usuário ainda melhor (creio que o Google Docs terá que reformular algumas coisas pra bater o que está vindo por aí).

Infelizmente a palestra de Excel Services e Business Conectivity Services não rolou e  era a que eu mais esperava, mas os organizadores do evento prometeram um vídeo sobre o conteúdo.

Em geral o evento foi bem interessante, muito organizado mas com um clima descontraído que facilitou a interação entre os participantes. Parabéns aos palestrantes e organizadores: Helio Sá Moreira, Rodolfo Roim e  Thiago Cruz Soares!

Agora é só aguardar pela versão definitiva do Sharepoint e do Office pro ano que vem… por enquanto, bom trabalho e bons estudos!

SQL Virtual Database: It’s As Easy As 1, 2, 3.

O anúncio chamou atenção e resolvi dar uma verificada.

Imagine o seguinte cenário: você tem um backup de uma base de dados SQL Server e precisa restaurá-lo pra trabalhar em cima dele. O backup tem aproximadamente 180 GB e você vai precisar de algumas horas pra restaurá-lo.

Imagine agora que você tenha uma forma de “restaurar” esse backup em 10 minutos e trabalhar em cima dele normalmente, como qualquer outra base de dados do SQL Server, executando consultas, procedures, realizando updates, etc. Essa é a idéia da ferramenta SQL Virtual Database desenvolvida pela Idera.

Algumas pessoas poderão dizer, “ah, mas o SQL Server já tem o Database Snapshot”. Sim, a idéia é parecida, mas o Database Snapshot só pode ser gerado na mesma instância da base de origem e só está disponível a partir do SQL Server 2005 em edições Enterprise. O SQL Virtual Database gera uma base de dados virtual em qualquer instância (inclusive SQL Server 2000) a partir de um arquivo de backup.

Achei a idéia inicial muito boa (o programa está na versão beta) e de certa forma fiquei impressionado com os 9 minutos que esperei para ter uma base virtual, baseada num backup de 180 GB, que estava em outra estação da rede. Particularmente achei uma saída muito interessante pra ambientes de desenvolvimento e homologação.

Vou testá-la repetidamente durante os próximos 14 dias (que é o período do Trial) e se tiver mais considerações posto aqui.

Abaixo algumas telas da ferramenta:

1. Tela de instalação

2. Attach do backup na instância MENDES\SQL05

3. Base virtual anexada à instância

Link para download.

Bom trabalho!