Ferramentas para Migração: Upgrade advisor

Migrar um ambiente de banco de dados, mesmo que seja um upgrade de versão não é fácil e muitas vezes temos diversos problemas por features descontinuadas, sintaxes alteradas e assim por diante.
E achar ferramentas que auxiliem essas migrações de forma eficaz é complicado.
Vou aproveitar que estou no meio de um projeto de atualização de versão de um ambiente inteiro (win. Server 2003 para 2008 e 2012  / SQL Server 2005 para 2012 ) para passar algumas ferramentas que podem auxiliar nas migrações.
Começando pela mais simples: o Upgrade Advisor!
O upgrade é uma ferramenta para auxiliar na migração de Banco de Dados ao qual o maior segredo é onde baixa-lo. Ele fica dentro do Feature Pack, e você pode encontar aqui para o 2008 e aqui para o 2012 – nesta página, encontre o tópico que fala apenas de upgrade advisor. Caso decida baixar o pacote todo, o upgrade fica na pasta: \X64\Redist\Upgrade Advisor. Existem também versões x86 e Itanium do Upgrade Advisor sob as pastas \X86 e \IA64, respectivamente.

Após instala-lo (instalação padrão. Não vou demonstrar para não alongar muito), abra o upgrade advisor. Ele da a tradicional tela de boas vindas da microsoft e explica um pouco do que será analisado.
O Upgrade realiza uma avaliação de diversos objetos, configurações, DLL, etc em seu ambiente e gera um report com essas informações.

Aponte para o servidor que deseja analisar.

 

Sim, voce pode ter o upgradeinstalado em 1 servidor e analisar outro. Mas atenção, alguns recursos como o Reporting services só podem ser analisados se a ferramenta for local.

Selecionado os recursos, você deve agora escolher a instância  a ser analisada.

Escolha os databases que passarão pela análise. Você pode optar por escolher um trace ou algum script.

Como escolhi analisar também meu Integration services, passo pela tela de configuração para ele também. Você pode escolher analisar todos,  ou algum específico. E vale lembrar que para analisar os encriptados, a senha deve ser colocada nesta tela.

Verifico as informações e inicio a análise. O tempo de duração da análise é variável. Terminando a análise, ele nos informa o que está ok e o que não está.

Ele gera um report , ao qual podemos ver direto por essa tela.

O Report indica os pontos criticos, de atenção. Aponta em que momento essa solução precisará ser aplicada e descreve cada ponto de atencao.

Abrindo o link de objetos afetados, ele lista base e campo ou objeto referente ao erro detectado.
E na sessão de “diga mais sobre isso” temos o link para o Books Online onde descreve o erro e ainda encontramos exemplos de código (se for o caso) para corrigirmos.

E assim conseguimos mapear diversos pontos que devem ser ajustados para uma atualização. Esse tipo de report, ajuda muito a minimizar problemas pós migração, deixando tudo alinhado com a nova versão.

Para mais informações: Acesse o MSDN

 

É isso pessoal.
Espero ter ajudado =)
Até mais !

Coletando Queries Lentas via SQL Profiler

Identificar query lenta é um ponto muito importante para mapearmos nosso ambiente, entender o comportamento e melhorar a performance de aplicações e do próprio ambiente de banco de dados.
Hoje vamos falar de um dos vários modos que existem para coletar query lentas: um profiler no SQL Server.
Vale lembrar que, o que pode ser lenta para um ambiente, pode não ser lenta para outros. Tudo depende de como o seu ambiente é utilizado e o quanto você gostaria que ele fosse otimizado.
E vale lembrar também que o profiler pode judiar da performance do servidor, então utilize com consciência!

Vamos ao que interessa!

Primeiro, abra o profiler do sql server.

Em seguida, abra um novo profile, e conecte-se ao servidor ao qual deseja realizar a coleta

Vamos começar a configurar! Atenção a alguns detalhes importantes: de um nome a seu profiler,  e eu recomendo que salve os resultados da coleta em uma tabela, para que possa consultar os dados posteriormente.

Ao solicitar para salvar em uma nova tabela, ele irá pedir uma nova conexão a um servidor, para que possa criar uma tabela e salvar os registros. Conecte-se a o ambiente que desejar (pode ser o mesmo ao qual quer realizar a coleta) e configure as informações de: database, schema e nome da tabela que será criada.

Vamos para a aba  ‘event information’ para realizar as configurações de coleta.
Esta aba é completamente personalizavel e permite que se defina diversos parâmetros para sua coleta ou qualquer outra função que esteja utilizando no profiler.
Para pegar os campos que queremos , selecionei os campos de ‘show all events’ e ‘show all columns’, abrindo assim todas as possibilidades de configuração.

Como farei apenas uma coleta basica, deixei apenas alguns eventos e campos selecionados. Para esse tipo de coleta, acredito que login, database name, hostname, aplication name, text e duration são fundamentais. Os demais depende da necessidade. Em seguida, já iremos configurar alguns filtros para a coleta.

Você irá observar que o campo de aplication name já está com um filtro configurado. É um filtro do nome do SQL Profiler, adicionado automaticamente para que o profiler que está sendo criado não fique aparecendo, juntando uma informação inútil à sua coleta.
Nesse caso adicionei um filtro apenas no campo ‘duration’ que é o campo que irá coletar as consultas de acordo com o tempo que estimarmos.
Vale lembrar que o duration é um campo em milissegundos, então atenção ao configurar este campo!

Todos os campos podem ser personalizados, de acordo com suas características e vocês podem implementsr filtros de acordo com a necessidade.
Após adicionar os filtros, hora de colocar nosso profiler para funcionar. No exemplo, executei uma query mais pesada para passar e 5 segundos e apsrecer no tracert. Ela me passa todas as informações que preciso para identificar e a partir dai realizar tunning em suas consultas.

Lembra no início do tutorial, onde pedimos para salvar o profiler em uma tabela? Pois bem, uma vez que a coleta seja concluída, pare o profiler e feche (por que ele também pode refletir na lentidão de um ambiente) mas os dados coletados estão a salvo na tabela, e uma simples consulta na tabela criada, e lá estao as informações que precisamos.

A partir dai, utiliza seus conhecimentos de tunning (e algumas dicas que passamos aqui) e deixe seu ambiente cada vez melhor!

Espero ter ajudado =)
Até mais!

Manutenção no distribution

Muitas vezes temos tantos problemas na administração dos bancos que utilizamos em aplicações que esquecemos os databases e sistema, fundamentais para o funcionamento de nossos servidores.
Eles são pequenos e não ficam gritando na sua frente, mas as vezes podemos ter problemas que envolvem o uso destes dbs e é fundamental para um dba conhecer cada detalhe e saber utiliza-los. São muitos os problemas que podemos ter, aos poucos vamos relatando alguns por aqui.

Recentemente, analisando alguns servidores, encontramos um comportamento anormal do database distribution. Seu tamanho estava em aproximadamente 90Gb.

Realizando uma análise nas tabelas e tamanhos (utilizando a proc que ensinamos aqui) encontramos a tabela “MSrepl_commands”. Pesquisas e mais pesquisas e descobrimos que essa tabela funciona como um log das replicações.
Ela armazena os comandos executados das replicações, armazenando um historico, que mais cedo ou mais tarde você terá problemas com ela.
Descobrimos então um modo de realizar esta limpeza garantindo o funcionamento das replicações, mas sem ter problemas.
Primeiramente verifique se a rotina ‘Distribution clean up: distribution” existe em sua intância.

Este job é o ressponsável pela limpeza e manutenção destas tabelas.
Caso o job não exista, experimente executar o comando:

EXEC dbo.sp_MSdistribution_cleanup @min_distretention = 0 , @max_distretention = 72

Go

 

Onde @max_distretention é o tempo máximo de tempo que os registros serão retidos pelo database. Esse número é representado em horas. (72 é um número padrão).
Caso sua tabela já esteja muito grande, este comando devera ser executado diversas vezes, baixando aos poucos o log, caso contrario você terá grandes problemas de performance. Deixe em tempo bem maior e va diminuindo aos poucos (ou seja, as 72h, podem ser valores maiores para diminuir aos poucos)

Recomendo adicionar esta execução em um job, e programa-lo para executar de acordo com sua necessidade. Assim você cria uma manutenção contante no seu database, o que te poupa de ter uma solução temporária, e passa a ter uma manutenção preventiva.

Espero ter ajudado =)
Até mais!

Rápidinha: usar (nolock) ou with (nolock) ?

Muita gente já me perguntou: da na mesma usar somente o (nolock) ou o with (nolock) né?
Pois bem, como sou formada pelo 2008, o correto é o uso do ‘with’. Mas já vi muito uso do (nolock) sozinho.

Então a resposta é, sim, tanto faz. Se você usar SQL 2000 ou anterior.
E não, não é a mesma coisa se usar o 2005 ou posterior.

O SQL aceitava e fazia funcionar o nolock sem o uso do with.
No 2005 ele aceita, mas não funciona. Ele gera lock ainda sim.

Então pessoal, vale a pena ficar ligeiro. Adotem o uso do with e garanta a performance das suas consultas usando o with (nolock)

Espero ter ajudado.
Até mais =)

Coletando tamanho de tabelas de um database – SQL Server

Pessoal, há algum tempo recebi um pedido de ajuda para realizarem uma coleta de informações do tamanho de tableas de um database.
Como sabem no SQL conseguimos executar um SP_DATABASES e conseguimos informações do tamanho de um database mas esse tipo de informação detalhada referente a tabelas não temos em uma proc de sistema.

Sabendo disso, encontramos uma procedure que faz esse trabalho, e ao executa-la saberemos o tamanho de cada tabela. Segue a proc:

create proc dba_sp_espacotabela
as

declare @vname sysname

declare @tmpTamTabela table (
name sysname null
, rows int null
, reserved varchar(25) null
, data varchar(25) null
, index_size varchar(25) null
, unused varchar(25) null
)

declare cp1 cursorlocalfast_forwardread_onlyfor
select name
from sysobjects
where type = ‘U’
order by name

open cp1

while 1 = 1

begin
fetchnextfrom cp1 into @vname
if @@fetch_status <> 0 
break

insertinto @tmpTamTabela (name, rows, reserved
, data, index_size, unused )
exec sp_spaceused @vname

end

close cp1
deallocate cp1

select name as ‘Nome’
, rows as ‘Linhas’
, convert (int,replace (reserved,‘ KB’,”) ) as ‘Tamanho total’
, convert (int,replace (data,‘ KB’,”) ) as ‘Dados’
, convert (int,replace (index_size,‘ KB’,”) ) as ‘Index’
, convert (int,replace (unused,‘ KB’,”) ) as ‘Não utilizado’
from @tmpTamTabela
order by convert (int, replace (reserved,‘ KB’,”) ) desc
go

See you amiguinhos.