Mundança de Domínio
Fala Pessoal,
Por diversos motivos resolvi criar meu próprio domínio.
Agora o endereço do meu blog é http://fabriciolima.net/blog/
Atualizem seus feeds por favor.
Espero por vocês lá!
Atualizado dia 24/10/2012
Para quem tiver interesse, agora estou realizando um serviço de consultoria remota. Aos interessados, segue o link abaixo para maiores informações:
http://fabriciolima.net/blog/consultoria-remota/
Abraços,
Fabrício França Lima
Querys do Dia a Dia – Acompanhando as querys mais demoradas do Banco de Dados
Esse post foi transferido para o novo domínio do Blog. Clique aqui para acessá-lo.
Querys do Dia a Dia – Como encontrar um texto em Functions, Views e Procedures
Material para as certificações MCTS e MCITP do SQL Server 2008
Esse post foi transferido para o novo domínio do Blog. Clique aqui para acessá-lo.
Querys do Dia a Dia – Monitoramento do Banco de Dados – Who is Active
Esse post foi transferido para o novo domínio do Blog. Clique aqui para acessá-lo.
Retrospectiva 2010
Não iria escrever esse post, mas aproveitando um post pronto que recebi do wordpress, vou acrescentar algumas palavras.
Até o inicio de 2010, eu era um DBA que estudava apenas pelos training kits(quando tinha alguma prova marcada), só entrava em um fórum quando precisava resolver algum problema e só acompanhava blogs quando pesquisava no google procurando por um assunto específico que estava precisando naquele momento, com exceção do site mcdbabrasil que sempre acompanhei.
Até que no início do ano, li dois posts do Fabiano Amorim (Twitter): Post1 e Post2.
Depois de ler esses posts, percebi que não estudava 5% do que deveria estudar (Valeu Fabiano!!!). Na mesma hora acrescentei todos os blogs que o Fabiano indicou no meu google reader e comecei a acompanhá-los(fazendo um filtro de alguns assuntos devido ao tempo), com isso, já conseguia identificar os feras em SQL Server aqui do Brasil. Também recebo todas as dúvidas dos fóruns do technet sobre SQL Server via google reader, onde acompanho os problemas e as soluções propostas. Comprei dois livros com o objetivo de estudar mais a fundo essa ferramenta, além de ler alguns ebooks e whitepappers que existem disponíveis.
Depois de ver muitas dicas em blogs, resolvi compartilhar algumas rotinas que possuo em meu ambiente e ainda não tinha visto em outros blogs, além de algumas dicas e experiências que tenho no meu dia a dia.
Em março criei meu blog no spaces, em junho cheguei as semifinais da copa microsoft(ganhei uma technet subscription), cheguei até a fazer um webcast sobre SQL Server 2008 R2 (quem diria?) e ainda escrevi um artigo para uma REVISTA, a codificando.NET.
Além disso, conheci(online) MUITAS pessoas da área e agora tenho acessível via msn, e-mail e twitter diversos profissionais referências em SQL SERVER e de outras áreas. Profissionais totalmente acessíveis, que perdem um pouco do curto tempo que possuem, tirando dúvidas e ajudando a outros profissionais.
É isso, com uma nova rotina de estudos(sendo um DBA de verdade), acredito que aprendi MUITO esse ano. Entretanto, não da para calcular, mas acho que ainda não sei 10% do que eu deveria saber sobre SQL Server.
Então, bora estudar mais em 2011 e aumentar esse percentual. Ótimo ano para todos.
Segue abaixo o E-mail que recebi com as estatísticas do meu blog em 2010 (desde 03/10/2010):
Os duendes das estatísticas do WordPress.com analisaram o desempenho deste blog em 2010 e apresentam-lhe aqui um resumo de alto nível da saúde do seu blog:
O Blog-Health-o-Meter™ indica: Uau.
Números apetitosos
Um Boeing 747-400 transporta 416 passageiros. Este blog foi visitado cerca de 3,000 vezes em 2010. Ou seja, cerca de 7 747s cheios.
Em 2010, escreveu 27 novos artigos, nada mau para o primeiro ano! Fez upload de 30 imagens, ocupando um total de 2mb. Isso equivale a cerca de 3 imagens por mês.
O seu dia mais activo do ano foi 27 de dezembro com 91 visitas. O artigo mais popular desse dia foi Casos do Dia a Dia – Diminuíndo um problema de memória no SQL Server.
De onde vieram?
Os sites que mais tráfego lhe enviaram em 2010 foram devmedia.com.br, silasmendes.com, profissionaisti.com.br, mcdbabrasil.com.br e twitter.com
Alguns visitantes vieram dos motores de busca, sobretudo por conhecendo as dmv do sql server gargalo de disco, sql server 11, configuração de memoria no mssqlserver 2008 r2, tuning dba livros e fabricio lima
Atracções em 2010
Estes são os artigos e páginas mais visitados em 2010.
Casos do Dia a Dia – Diminuíndo um problema de memória no SQL Server dezembro, 2010
4 comentários
Free ebooks sobre SQL Server para Download dezembro, 2010
6 comentários
Criando um CheckList Automático do Banco de Dados março, 2010
6 comentários
Passo a passo para encontrar as querys mais demoradas do Banco de Dados – Parte 1 junho, 2010
12 comentários
Utilização de mais de 3GB de memória no SQL Server em um ambiente 32 bits agosto, 2010
4 comentários
Casos do Dia a Dia – Diminuíndo um problema de memória no SQL Server
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?
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
Fabrício Lima 
