Carlos@Geekbunker

Câmera Digital

Agora eu também faço parte da turma dos que possuem câmera digital :)

Fiz a estréia da câmera ontem no happy-hour dos colegas da Reumatologia da patroa.

As fotos já estão on-line aqui!

Webcast sobre Yukon

Um ótimo WebCast sobre Yukon, CLR e integração com o .Net.

Yukon On-Demand Webcast Available
http://blogs.msdn.com/tims/archive/2004/01/29/64387.aspx

Recovery Models

Uma vez eu fiz um breve resumo de como os recovery models do SQL Server funcionam e suas implicações no arquivo de transaction log. Este resumo foi utilizado como resposta numa dúvida na lista de discussão de SQL Server MSSQL-L.
De tempos em tempos a mesma dúvida surge e para economizar tempo e facilitar a leitura resolvei transformar a resposta num post do blog.

Você tem duas opções com relação ao Arquivo de Transação (Transaction
Log)

1) Utilizar o banco em Recovery Model Simple (truncate log on
checkpoint). Deste modo o arquivo de transação é "reciclado" de tempos
em tempos e você não precisa limpa-lo.
Utilize este modo quando você pode conviver com o último full backup.

2) Utilize o banco em recovery model full ou bulk/insert. Nestes modos
você precisa executar o comando BACKUP LOG a cada X tempos para que o
arquivo de log seja limpo. O SQL faz duas operações importantes no
BACKUP LOG: ele copia os dados do arquivo de transação para um arquivo
de backup e "limpa" o arquivo de backup, liberando espaço para novas
transações. Utilize o modo full quando você precisa utilizar point in
time recovery. Utilize o Bulk/insert quando você pode conviver como
backup do último transaction log.

O comando BACKUP LOG somente pode ser executado em bancos de dados que
estejam com o recovery model em full ou bulk/insert.

O comando BACKUP DATABASE NÃO limpa o arquivo de transaction LOG. Você
deve utilizar o comando BACKUP LOG para limpar o arquivo de transaction
log.

Mais um ponto:
Muitos usam o termo LIMPAR o Transaction log. Este não é um termo
correto e não representa corretamente o procedimento do transaction log.
Explico melhor: o arquivo de LOG (transaction log) é dividido internamente em Virtual Log Files. Imagine então que o transaction log possui 100 VLFs. Uma transação típica com o banco em modo full ocorreria da seguinte forma:

1) a transação ocupa os VLF 1 até 10 durante a sua execução.
2) O SQL executa um processo chamado checkpoint e verefica se as
transações que estão no arquivo de log ja estão também escritas no
arquivo de dados. Se as transações estiverem em ambos os arquivos o SQL
marca os VLFs da transação como candidados a serem liberados. Neste caso
os VLFs 1 a 10 são marcados como candidatos a serem liberados.
3) uma nova transação ocorre e ocupa os VLF de 11 a 90. Ela ocupa estes
VLFs porque os VLFs 1 a 10 não estão liberados, somente marcados como
candidatos a serem liberados.
4) um backup log ocorre e SQL Server copia as VLF 1 a 10 (transações que estão no log que ja sofreram um checkpoint) para um arquivo
de backup. Os VLFs que pertencerem as transações que estiveram marcadas
como candidatas a liberadas (ja estão "comitadas") são marcados como
livres para uso. No nosso caso as transações 1 a 10. As transações 11 a 90 ainda não sofreram o processo de checkpoint por isso ficam no arquivo de transaction log.
5) Uma nova transação ocorre e precisa de 20 VLF, esta transação então
ocupa os VLFs 90 a 100 e os VLFs 1 a 10. Ela ocupou 10 VLFs que estavam
livre e mais 10 VLFs que estam marcados como livres.

O que aconteceria se o backup log não tivesse ocorrido?
a) Se o arquivo de log pudesse crescer fisicamente ele iria
crescer fisicamente
b) Se o arquivo de log não pudesse crescer ele daria um erro de
LOG FULL

No caso de um banco em modo simple ocorre o seguinte:

1) a transação ocupa os VLF 1 até 10 durante a sua execução.
2) O SQL executa um processo chamado checkpoint e verefica se as
transações que estão no arquivo de log ja estão também escritas no
arquivo de dados. Se as transações estiverem em ambos os arquivos o SQL
marca os VLFs da transação como livres. Neste caso os VLFs 1 a 10 são
marcados como livres.
3) uma nova transação ocorre e ocupa os VLFs 11 a 90.
4) Uma nova transação ocorre e precisa de 20 VLFs. O transaction possui
disponível 10 VLFs (91 a 100) e mais 10 VLFs (1 a 10 marcados como
livres).
5) O SQL então utiliza os 10Vls (91 a 100) e "recicla" os VLs 1 a 10 para serem utilizados pela transação.

A diferença entre os recovery models está no último passo, pois no banco full o backup log "guardou" a transação que ocupou os 10Vls no arquivo de backup. No modo simple o SQL "perdeu" estas transações pois o espaço foi reciclado.

É por isso que recomenda-se que bancos de produção utilizem modo full que permite voltar o banco de dados a qualquer momento.
Para ambientes de desenvolvimento ou que podem conviver com backup full recomenda-se a utilização do modo simple.

Algumas referências:

INF: Shrinking the Transaction Log in SQL Server 2000 with
DBCC SHRINKFILE

Truncating the Transaction Log no Books On Line

É muito difícil

Copyright by Piu

Iron Maiden

Sábado tem show do Iron Maiden no Pacaembu e o melhor de tudo é que eu VOU!

Wildest Dreams
Harris/Smith
I'm gonna organize some changes in my life
I'm gonna exorcise the demons of my past
I'm gonna take the car and hit the open road
I'm feeling ready to just open up and go

I'm gonna breakaway

Limpando Bases

Administrar servidores de desenvolvimento é um trabalho que consome tempo e paciência. Nenhum DBA, nem os Juniors, gostam de administrar o servidor de desenvolvimento.
Um dos problemas enfrentados na administração de servidores de desenvolvimento é o uso do espaço em disco. Bases de produção tendem a possuir mais espaço do que precisam, para evitar I/O em momentos de carga ou crescimento. Servidores de desenvolvimento em geral não possuem espaço em disco abundante o que gera uma restrição a ser administrada pelo DBA.

O script abaixo foi criado para resolver o meu problema com administração de espaço em servidores de desenvolvimento. O script executa em todas as User Databases os seguintes passos:
1) Coloca o banco em modo Simple
2) Trunca o log
3) Deixa o banco com 10% de espaço disponível
4) Atualiza as informações de uso do banco de dados, para evitar que o comando sp_spaceused apresente valores negativos.

Eu coloco este script como um JOB no SQL Server para ser executado todos os dias às 03:00AM. Este script me garante que as bases em desenvolvimento terão somente os espaço que precisam, estarão em modo simple (evitando erros de log full) e com as informações atualizadas.

---Inicio do Script
/*
Script para fazer a manutencao de banco de dados de desenvolvimento.
*/

/*Seta as variaveis */
Set Nocount on
Declare @dbname varchar(100)
declare @mail varchar(500)
declare @name sysname

Declare db Cursor For ---cria um cursor para receber os nomes dos bancos de dados
Select name from master.dbo.sysdatabases
Where name not in ('master','model','msdb','tempdb')

Declare @osql varchar(1000)

/*
Criar um cursor para executar os comandos nos bancos de dados.
*/
Open db
Fetch Next from db into @dbname
While @@Fetch_status=0
Begin
---Coloca o banco em mode simple
set @osql = 'sp_dboption '''+@dbname+''',''trunc. log on chkpt.'',''true'''
---Para executar comente o comando print e tire o comentario do exec
print (@osql)
---exec(@osql)

---Trunca o Log
set @osql = 'backup log '+@dbname+' with no_log'
---Para executar comente o comando print e tire o comentario do exec
print (@osql)
---exec(@osql)

---Deixa o banco com 10% de espaço livre
set @osql = 'dbcc shrinkdatabase ('''+@dbname+''',10)'
---Para executar comente o comando print e tire o comentario do exec
print (@osql)
---exec(@osql)

---Atualiza as informacoes de uso de espacao do banco
---evita que o comando sp_spaceused apresente valores negativos
set @osql = 'dbcc updateusage('''+@dbname+''')'
---Para executar comente o comando print e tire o comentario do exec
print (@osql)
---exec(@osql)

Fetch Next from db into @dbname
End
Close db

Deallocate db

---Fim do Script