PASS Summit 2011– Quem vai?

Oi pessoal, como estão as coisas?

Depois de um período longe do blog e da vida social na internet (em breve colocarei um post sobre o assunto) eu estou voltando com uma rápida convocação para os SQLGeeks espalhados por aí. Como acontece todo ano, será realizado o PASS Summit em Seattle, maior evento de SQL Server do planeta, na semana do dia 10 de Outubro de 2011.

No passado eu já falei do evento neste blog (http://luticm.blogspot.com/2010/02/pass-summit-2010-quem-vai.html) e acho que é uma experiência memorável para profissionais que trabalham com SQL Server.

Infelizmente o meu calendário não possibilitou minha ida em 2010, mas 2011 já está planejado e inclusive estou discutindo com algumas pessoas a participação no evento, então se você é um dos interessados, não deixe de se juntar a nós e me envie um e-mail (luciano.moreira@srnimbus.com.br).

Se você fizer o cadastro até o dia 15/01/2010 o evento sai por US$ 995,00 e neste momento não existe desconto para grupos (sim, já conversei com o Shannon), então você pode fazer sua inscrição logo ou esperar até o anúncio dos pacotes em grupo (minha expectativa é por um preço semelhante ao que está em vigor hoje) e, junto com outros interessados, podemos tentar conseguir esse desconto.

Aqui está o site do evento, ainda sem maiores informações: PASS Summit 2011

[]s

Luciano Caixeta Moreira - {Luti}
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm

Instalando o SQL Server 2008 e problema com Setup.rll

Estava instalando o SQL Server 2008 em uma VM que já possui o SQL Server 2008 R2 instalado, quando me deparei com o seguinte erro "SQL Server 2008R2\Resouces\1033\Setup.rll is either not designed to run on Windows or it contains an error tryinstalling the program again using the original installation media". Clicando em OK aparecia outra mensagem: "The loading and initialization of setup.rll failed with error code: 0800700C1".
Nada bom, pesquisei rapidinho na Internet mas nada me ajudou, então resolvi dar uma olhada no que temos e pensar um pouco.

Fui até o diretório informado "C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Release\Resources\1033" e tentei abrir o rll, mas como não é um XML não nos ajuda. Como já instalei o R2 nessa máquina, suspeitei que o arquivo poderia ser de outra versão do SQL Server (já que o R2 tem como versão 100.50), então se procurarmos na mídia de instalação encontraremos um "setup.rll".

Data do arquivo no diretório: 19/07/2009
Data do arquivo na mídia de instalação: 10/07/2008

Bom, muito bom.
Troquei o nome do arquivo mais recente para setup_new.rll e copiei o arquivo da mídia de instalação para o diretório. Executei o setup e tudo funcionou corretamente.

Dica boba, mas espero que ajude alguma alma.

[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br

Sessão: Otimizando carga de dados com o SSIS e SQL Server

Bom dia pessoal.
Devido ao nascimento do meu filho eu não consegui me acertar ao novo ritmo e participar do WOTD (http://www.online.techday.net.br/), um belo evento que aconteceu hoje.

Minha sessão seria: "Otimizando carga de dados com o SSIS e SQL Server". Então para não deixar na mão os que haviam se cadastrado e cumprir o acordado, eu vou marcar um novo horário em novembro e apresentar o meu tema. Será através de uma sessão de live meeting que abrirei (e provavelmente vou passar da hora regulamentar! hahaha).

Fique ligado neste blog e no twitter, pois farei o anúncio em breve.
Me desculpem qualquer transtorno.

[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/

Bernardo

Oi. Não é do meu feitio, mas segue um post pessoal.


Dia 25/10/2010 15:19 nasceu meu primeiro filho, o Bernardo.

Todos comentam da emoção de ser pai, mas não adianta falar, é algo indescritível. Nada chega ao pés de você ver seu filho nascer, segurá-lo no colo e sentir que ele está seguro com você.


Sempre desejamos um mundo melhor, e nesse momento você quer se empenhar mais, ser uma pessoa cada vez melhor, tudo para garantir que seu filho ficará seguro e sempre feliz.

Segue uma foto do meu pequeno, algumas horas depois de nascer.

Não vou esticar aqui e escrever um post muito babão, mas espero que todos possam viver a emoção de ser pai um dia.

Vamos aos poucos construir um mundo melhor para todos nós...

 

[]s

Luciano Caixeta Moreira - {Luti}

luciano.moreira@srnimbus.com.br

www.twitter.com/luticm

www.srnimbus.com.br

Backups de dados vs. Cache de dados

Quer uma formação decente (cansei de brigar com o Blogger vs Live Writer, Word 2010, etc)? Baixe o PDF. :-)



Será que o SQL Server utiliza as páginas que estão em cache para acelerar a realização do backup?

É uma pergunta que já me fizeram algumas vezes, então resolvi colocar um script bem simples para mostrar qual é a resposta à pergunta.
Por simplicidade eu vou colocando os scripts com comentários, então você pode ir acompanhando o que estou fazendo. Em primeiro lugar que tal criarmos um banco para nosso teste e tirarmos um backup para padronizar a brincadeira.

USE
Master
go

-- DROP Database BackupCache

-- Vamos criar uma estrutura simples para brincar...
CREATE
DATABASE BackupCache
go

USE BackupCache
go

CREATE
TABLE TabelaDados
(Codigo INT
IDENTITY(1,1) NOT NULL,
Texto VARCHAR(8000) NOT NULL)
GO

INSERT
INTO TabelaDados
(Texto) VALUES (REPLICATE('Sr. Nimbus', 1000))
go 1000

-- Cria um primeiro backup para deixar o exemplo padronizado
BACKUP
DATABASE BackupCache
TO DISK = 'C:\Temp\BackupCache.bkp'
WITH INIT, Format
go
Como podemos analisar se os dados estão sendo lidos do arquivo físico? Claro, sys.dm_io_virtual_file_stats!
-- Agora vamos a análise
-- Primeiro criamos uma tabela para armazenar filestats...

-- DROP TABLE FileStats

select *, SYSDATETIME() as Hora
INTO FileStats
from sys.dm_io_virtual_file_stats(null,
null) where 1=2

SELECT *
FROM FileStats

-- Qual nosso backup id?
select DB_ID()
-- = 46

-- O arquivo que me interessa mais é o 1 = MDF
SELECT *, SYSDATETIME()
from sys.dm_io_virtual_file_stats(46, null)
Se o backup estiver lendo os dados diretamente do disco vamos ver a quantidade de bytes lidos (num_of_bytes_read) aumentando, então para esse artigo eu estou me preocupando mais com o MDF. Primeiro vamos fazer um teste limpando primeiro a cache de dados...

-- Em um primeiro momento, vamos fazer um backup com a cache fria
DBCC DROPCLEANBUFFERS


INSERT INTO FileStats
SELECT *, SYSDATETIME()
from sys.dm_io_virtual_file_stats(46, null)

-- 1189 pages
BACKUP DATABASE BackupCache
TO DISK = 'C:\Temp\BackupCache.bkp'
WITH INIT, Format

/*
Processed 1184 pages for database 'BackupCache', file 'BackupCache' on file 1.
Processed 5 pages for database 'BackupCache', file 'BackupCache_log' on file 1.
BACKUP DATABASE successfully processed 1189 pages in 1.216 seconds (7.633 MB/sec).
*/

INSERT INTO FileStats
SELECT *, SYSDATETIME()
from sys.dm_io_virtual_file_stats(46, null)
go


Analisando a saída da DMV conseguimos ver que foram lidos 9953280 bytes, exatamente 1215 páginas. Um pouco a mais que o número de páginas processadas, talvez páginas lidas duas vezes ou algo que não vai para backup. O importante aqui é que as páginas foram lidas diretamente do arquivo físico.
Agora vamos testar com as páginas de dados em cache.

-- E se as páginas de dados já estiverem em cache?
-- Notem que o backup NÃO colocou as páginas em cache
select
*
from
sys.dm_os_buffer_descriptors
where database_id = 46


select
*
from TabelaDados


-- 1067 páginas em cache (o número pode variar)
select
*
from
sys.dm_os_buffer_descriptors
where database_id = 46


-- Agora vamos ao backup...
INSERT
INTO FileStats
SELECT
*,
SYSDATETIME()
from
sys.dm_io_virtual_file_stats(46,
null)


-- 1189 pages
BACKUP
DATABASE BackupCache
TO
DISK
=
'C:\Temp\BackupCache.bkp'
WITH
INIT, Format


/*
Processed 1184 pages for database 'BackupCache', file 'BackupCache' on file 1.
Processed 2 pages for database 'BackupCache', file 'BackupCache_log' on file 1.
BACKUP DATABASE successfully processed 1186 pages in 1.442 seconds (6.422 MB/sec).
*/


INSERT
INTO FileStats
SELECT
*,
SYSDATETIME()
from
sys.dm_io_virtual_file_stats(46,
null)
go

Fazendo novamente o cálculo com base nas leituras físicas que foram feitas...

-- Analisando as duas últimas entradas do arquivo de dados (BytesRead)
PRINT (38912000 - 29212672)
= PRINT 9699328 / 8192 = 1184 páginas


-- Foram lidas 1184 páginas do arquivo físico.
-- Alguma página que estava em memória foi utilizada? NÃO!


Então aqui já temos nossa resposta, mas só para deixar a coisa mais divertida, e se tivermos páginas sujas em cache?! Primeiro deixamos as páginas sujas (notem que já foi feito o flush de muitas algumas páginas alteradas, o que já forçou escritas no arquivo e isso pode ser confirmado pelo file stats) e depois realizamos o backup.

-- E com dirty pages? Veja coluna is_modified
select
*
from
sys.dm_os_buffer_descriptors
where database_id = 46
    AND is_modified = 1


UPDATE TabelaDados
    SET Texto =
REPLICATE('Sr! Nimbus', 1000)


-- Flush de dirty pages foi feito e sobraram N páginas sujas... (313 no meu caso)
select
*
from
sys.dm_os_buffer_descriptors
where database_id = 46
    AND is_modified = 1
go


-- Agora vamos ao backup...
INSERT
INTO FileStats
SELECT
*,
SYSDATETIME()
from
sys.dm_io_virtual_file_stats(46,
null)


BACKUP
DATABASE BackupCache
TO
DISK
=
'C:\Temp\BackupCache.bkp'
WITH
INIT, Format


/*
Processed 1184 pages for database 'BackupCache', file 'BackupCache' on file 1.
Processed 2 pages for database 'BackupCache', file 'BackupCache_log' on file 1.
BACKUP DATABASE successfully processed 1186 pages in 1.322 seconds (7.005 MB/sec).
*/


INSERT
INTO FileStats
SELECT
*,
SYSDATETIME()
from
sys.dm_io_virtual_file_stats(46,
null)
go

select
*
from FileStats
-- Analisando as duas últimas entradas do arquivo de dados (BytesRead)
PRINT (48611328 - 38912000)
= PRINT 9699328 / 8192 = 1184 páginas


Analisando os file stats, vemos novamente que o SQL Server leu as páginas do disco! Hhuumm, e as páginas sujas que estavam em memória? Sumiram! Of course my horse, o backup disparou um checkpoint que fez um flush das páginas sujas! Duvida? Veja o log de transação.

-- Aonde foram parar mas minhas páginas sujas??? Somente 4 páginas?
-- Sim, lembra que o backup executa um checkpoint? Flush foi feito...
select
*
from
sys.dm_os_buffer_descriptors
where database_id = 46
    AND is_modified = 1
    
/*
72057594039894016    DATA_PAGE
281474978283520    DATA_PAGE
6488064    FILEHEADER_PAGE
6488064    DIFF_MAP_PAGE
*/
-- O que, não acredita?
SELECT
*
FROM
fn_dblog(null,
null)


/*
Viu o BEGIN_CKPT e END_CKPT?


00000084:00000131:003a    LOP_BEGIN_CKPT    LCX_NULL
00000084:00000148:0001    LOP_END_CKPT    LCX_NULL
00000084:00000149:0001    LOP_BEGIN_XACT    LCX_NULL
00000084:00000149:0002    LOP_MODIFY_COLUMNS    LCX_CLUSTERED
00000084:00000149:0003    LOP_PREP_XACT    LCX_NULL
00000084:0000014a:0001    LOP_COMMIT_XACT    LCX_NULL
00000084:0000014b:0001    LOP_FILE_HDR_MODIFY    LCX_FILE_HEADER
00000084:0000014b:0002    LOP_MODIFY_ROW    LCX_BOOT_PAGE_CKPT
00000084:0000014b:0003    LOP_MODIFY_ROW    LCX_BOOT_PAGE_CKPT
00000084:00000150:0001    LOP_BEGIN_XACT    LCX_NULL
00000084:00000150:0002    LOP_SET_BITS    LCX_DIFF_MAP
00000084:00000150:0003    LOP_INSERT_ROWS    LCX_HEAP
00000084:00000150:0004    LOP_INSERT_ROWS    LCX_HEAP
00000084:00000150:0005    LOP_COMMIT_XACT    LCX_NULL

Ô curioso, se você olhar no log as páginas que sofreram alterações, vai ver 4 páginas.
Nossa, que coincidência com o buffer descriptors! HAHAHAHA. Lindo.
*/

Resumindo a brincadeira, os backups do SQL Server vão ler diretamente as páginas que estão em disco e NÃO vão usar as páginas que estão em cache, independentemente de você tiver 64GB de dados já em memória. Então você deve tomar cuidado com os backups de dados durante o dia, pois eles podem sim impactar diretamente seu subsistema de discos.
Espero que você tenha se divertido.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/