Arquivo

Posts Tagged ‘Tuning’

Querys do Dia a Dia – Acompanhando as querys mais demoradas do Banco de Dados

26 de janeiro de 2011 Deixe um comentário

Esse post foi transferido para o novo domínio do Blog. Clique aqui para acessá-lo.

Anúncios

Querys do Dia a Dia – Monitoramento do Banco de Dados – Who is Active

10 de janeiro de 2011 Deixe um comentário

Esse post foi transferido para o novo domínio do Blog. Clique aqui para acessá-lo.

Categorias:Querys do Dia a Dia Tags:,

Casos do Dia a Dia – Diminuíndo um problema de memória no SQL Server

25 de dezembro de 2010 9 comentários

 

Esse post foi transferido para o novo domínio do Blog. Clique aqui para acessá-lo.

Casos do Dia a Dia – Você sabia que um arquivo de Log do SQL Server se fragmenta?

19 de dezembro de 2010 2 comentários

Fala Pessoal,

Vou ser sincero com vocês, até pouco tempo eu não tinha a menor idéia que um arquivo de log do SQL Server se fragmentava. Nunca tinha lido sobre o assunto. Entretanto, para isso que servem os mais 100 Blogs de SQL Server cadastrados no meu google reader e os vários profissionais SQL Server que sigo no twitter e que também divulgam dicas de excelentes artigos, whitepapers e etc.

Pouco tempo atrás, alguém “twitou” esse excelente artigo 8 Steps to better Transaction Log throughput.

Nesse artigo Kimberly L. Tripp (Blog|Twitter) da uma série de dicas para serem aplicadas nos arquivos de log do SQL Server.  Uma dessas dicas (a de número oito) é para checar e corrigir a fragmentação interna desses arquivos. Ela ainda disse que essa dica resolveu um problema de um cliente na Turquia.

Caso o seu arquivo de log tenha sofrido muitos autogrowths, ele pode ficar internamente fragmentado. O arquivo de log do SQL Server é dividido em pequenos pedaços chamados VLF(Virtual Log Files) que crescem a medida que seu arquivo de log cresce. Segundo Kimberly, geralmente, a maioria dos arquivos de logs devem ter somente entre 20 e 30 VLF. 50 ainda é aceitável dependendo do tamanho do seu arquivo de log.

Um número excessivo de VLF pode causar um impacto negativo em todas as atividades do transaction log e além disso, ainda pode ocorrer uma degradação da performance enquanto um backup do log está sendo executado. Para conferir quantos VLF você tem em uma database, basta verificar o número de linhas retornadas pelo comando DBCC LOGINFO conforme a figura abaixo:

Nesse caso, o arquivo de log dessa database possui 4 VLFs.

Seguindo o procedimento do artigo, realizei os seguintes passos para desfragmentar o arquivo de log:

 1 – Esperei por um período de pouco movimento e limpei o transaction log realizando um backup do mesmo. Caso você utilize o recovery model SIMPLE, você não precisa realizar um backup do log, ao invés disso, você limpará o transaction log rodando um CHECKPOINT.

            BACKUP LOG databasename TO devicename

2 – Realizei um Shrink no log para que ele ficasse com o menor tamanho possível (por isso que ele é limpo no passo 1).

            DBCC SHRINKFILE(transactionloglogicalfilename, TRUNCATEONLY)

3 – Alterei o arquivo de log da database para um tamanho apropriado onde ele necessite crescer apenas em alguns casos raros.

            ALTER DATABASE databasename
            MODIFY FILE
            ( NAME = transactionloglogicalfilename,
              SIZE = newtotalsize ) 

No meu ambiente eu possuía uma database com 275 VLF e as maiores estavam todas com mais de 150 VLF. Após realizar os passos acima, todas as databases estão com menos de 20 VLF, sendo que dentre elas, mantenho arquivos de log com 4 GB devido a algumas operações e manutenções que ocorrem durante a madrugada.

Com relação a performance, em um dos meus servidores, faço um backup do log a cada 7 minutos para minhas 5 principais databases, com isso, possuo um grande número de backups do log. Como eu monitoro toda query que demora mais de 3 segundos, constantemente a query que fazia backup do log demorava para ser executada e era armazenada no meu log. Após a realização dos passos descritos acima, é muito raro um backup do log  entrar nesse trace. Essa melhora foi bem perceptível no meu ambiente.

Então, cabe a vocês verificarem a quantidade de VLF de suas databases pois é um procedimento bem simples.

Abraços,

Fabrício França Lima



Casos do Dia a Dia – Exclusão de um índice grande e pouco utilizado

30 de novembro de 2010 5 comentários

Fala pessoal, 

Algum tempo atrás, compartilhei uma experiência que tive no Blog do Fabrício Catae (Blog|Twitter), mas também resolvi deixar registrado por aqui.

Muitos de vocês já utilizaram a dmv sys.dm_db_index_usage_stats para verificar a utilização e atualização dos índices de uma tabela. Também sabemos que essa dmv tem seus dados reiniciados quando o serviço do SQL Server é reiniciado. Assim, como os servidores do meu ambiente de banco de dados possuem uma atualização mensal de segurança, os servidores são reiniciados mensalmente e os dados dessa dmv seriam perdidos. Ou seja, eu só teria essas valiosas informações sobre os índices durante o período de um mês.

Para resolver esse problema, criei uma tabela que armazena diariamente a utilização dos índices. Com isso, posso analisar durante um período muito grande, a utilização dos meus índices antes de excluí-los. Eu já possuo mais de 1 ano de baseline já que o espaço ocupado por essas informações é pequeno.

Para quem quiser possuir um histórico dessas informações, o script abaixo cria uma tabela de histórico e insere as informações de utilização dos índices nessa tabela.

CREATE TABLE [dbo].[Historico_Utilizacao_Indices](
                               [Id_Historico_Utilizacao_Indices] [int] IDENTITY(1,1) NOT NULL,
                               [Dt_Historico] [datetime] NULL,
                               [Nm_Servidor] [varchar](30) NULL,
                               [Nm_Database] [varchar](30) NULL,
                               [Nm_Tabela] [varchar](50) NULL,
                               [Nm_Indice] [varchar](50) NULL,
                               [User_Seeks] [int] NULL,
                               [User_Scans] [int] NULL,
                               [User_Lookups] [int] NULL,
                               [User_Updates] [int] NULL,
                               [Ultimo_Acesso] [datetime] NULL )

INSERT INTO Historico_Utilizacao_Indices(Dt_Historico, Nm_Servidor, Nm_Database, Nm_Tabela, Nm_Indice,  User_Seeks, User_Scans,User_Lookups, User_Updates, Ultimo_acesso)
SELECT getdate(), @@SERVERNAME, db_name(db_Id()), o.Name, i.name, s.user_seeks,s.user_scans,s.user_lookups, s.user_Updates,  isnull(s.last_user_seek,isnull(s.last_user_scan,s.last_User_Lookup)) Ultimo_acesso
FROM sys.dm_db_index_usage_stats s
             join sys.indexes i on i.object_id = s.object_id and i.index_id = s.index_id
             join sys.sysobjects o on i.object_id = o.id
WHERE s.database_id = db_id()
ORDER BY o.Name, i.name, s.index_id

Para armazenar as informações, criei um job que roda essa query de INSERT para cada database que eu defini guardar os históricos.

Assim, eu utilizo essa tabela de histórico para analisar uma possível exclusão dos índices que são pouco utilizados ou que não são utilizados. Agora, compartilhando a experiência que tive, eu possuo uma tabela com muitas consultas e alterações que armazena 50 milhões de registros. Nessa tabela, tenho um índice em um campo chamado Fl_Situacao que pode possuir os valores 0, 1, 2, 3 ou 4.

Sempre acompanhei esse índice e verifiquei que tinha algumas utilizações somente no inicio do mês. Um certo dia, resolvi excluir esse índice seguindo o raciocínio de que o índice era pouco seletivo, a tabela é muito grande e o índice era pouco utilizado, não valendo a pena o custo de manutenção do mesmo. Após excluir o índice, acompanhando meu trace com as querys que demoram mais de 3 segundos, verifiquei que nenhuma query apresentou problema de lentidão.

Show de bola, diminuí uma operação de manutenção de um índice em uma tabela muito utilizada.

Entretanto, no inicio do mês, existia uma query com uma condição “where Fl_Situacao = 2” dentre outras restrições. Quando essa query rodou sem o índice que eu excluí, a mesma fez um clustered index scan nessa tabela, me causando um grande problema de lentidão no banco de dados. Isso aconteceu pois, dos 50 milhões de registros existentes na tabela, apenas 1.000 registros possuíam o campo Fl_Situacao = 2, o que tornava o índice existente nessa coluna extremamente eficiente para essa query. 

Resultado, como não dava para alterar a consulta, tive que recriar o índice na mesma noite.

Mais uma vez eu digo, vivendo e aprendendo!!! Meu maior aprendizado está no meu dia a dia de trabalho.

Abraços, 

Fabrício França Lima

E-Book SQL Server DMV Started Pack

13 de julho de 2010 2 comentários

Pessoal, estou um pouco sumido do blog pois estou em uma fase de estudos para atualizar meu título de MCITP Database Administrator para o SQL Server 2008(lendo o training kit 70-432) e em paralelo também estou estudando a parte de Tuning dos livros SQL Server MVP Deep Dives e Microsoft SQL Server 2008 Internals. Logo, o tempo está um pouco curto. Entretanto, estou adquirindo mais conhecimentos para futuramente compartilhar mais posts no blog que possam ajudar a alguém.

Esse post é para divulgar outro excelente E-book disponibilizado pela Red Gate e escrito por Glenn Berry, Louis Davidson e Tim Ford, com o título SQL Server DMV Started Pack. Na minha opinião, as DMV’s foram um dos melhores recursos disponibilizados pela microsoft a partir do SQL Server 2005, por isso, todo artigo onde vejo a palavrinha mágica dmv já me desperta muito interesse. Logo, acredito que esse E-Book seja uma leitura obrigatória para um DBA, ele é para imprimir, encadernar e colocar na sua biblioteca pessoal.

Para realizar o download totalmente gratuito clique aqui.

Abraços,

Fabrício França Lima

Categorias:Livros Tags:,

Passo a passo para encontrar as querys mais demoradas do Banco de Dados – Parte 2

5 de junho de 2010 2 comentários
 Esse post foi transferido para o novo domínio do Blog. Clique aqui para acessá-lo.