Bom dia pessoal.
Hoje participarei da semana de webcasts SQL Server com a comunidade MCITP SC, evento organilzado pelo Marcos Freecia (@SqlFreccia), onde vou falar um pouquinho sobre confiabilidade de pacotes no SSIS...
Palestrante: Luciano Moreira (Luti) (@luticm)
Palestra: Confiabilidade dos pacotes no SSIS
Descrição: Apenas criar um pacote com um alguns controles e data flows é suficiente para uma solução robusta? Provavelmente não! Nesta sessão serão apresentados recursos que podem ser empregados para aumentar a confiabilidade do pacote, como utilização de transações, checkpoints, database snapshots, tratamento de erros no data flow e eventos. No fim da apresentação você será capaz de entender cada um deles e analisando os pontos fortes e fracos de cada um, saber qual melhor se encaixa na sua solução.
Horário: 20:00 a 21:00
O link para inscrição está aqui: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032504533&Culture=pt-BR
Se interessa por SSIS? É hoje 20:00h!
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Mostrando postagens com marcador Virtual PASS BR. Mostrar todas as postagens
Mostrando postagens com marcador Virtual PASS BR. Mostrar todas as postagens
terça-feira, 7 de fevereiro de 2012
terça-feira, 31 de janeiro de 2012
Pesquisa: Desperdício no data cache
Parte da análise dos servidores SQL Server que nós fazemos está em olhar com carinho para o data cache, afinal de contas, é ele que ajuda o SQL Server a manter um bom desempenho e é quem consome boa parte do BPool.
Escrevi rapidinho uma pequena consulta que mostra quanto do BPool está sendo “desperdiçado” com fragmentação interna das páginas carregadas. Já tenho uma ideia da média de alguns servidores que tenho contato, mas gostaria de publicar um número, resultado de muitos outros servidores, para TODOS os DBAs terem uma ideia dessa média.
Para me ajudar basta executar essa consulta me enviar (ou colocar no comentário deste post) o resultado que aparece na linha do “Total”. Abaixo um exemplo de saída...
DatabaseID TotalUtiliadoMB EspacoLivreMB PercentualDesperdicado
Total 7404.281250 1212.929668423 0.163814640
Note que dependendo do tamanho do BPool o SQL Server pode ler muitas páginas, mas isso não deve causar nenhum grande impacto no ambiente, dado que a DMV não espera por um latch que está prendendo a página (http://blogs.msdn.com/b/psssql/archive/2009/01/21/how-it-works-sys-dm-os-buffer-descriptors.aspx), mas nos dará uma boa média.
E aí, gostou da ideia? Então vamos ajudar os outros DBAs e executar a consulta. Depois publico o resultado aqui...
!! UPDATE !!
Enquanto conversava com o Fabiano pelo Lync, buscando algumas coisas sobre hobt_id e partition_id, esbarramos com dois posts do Paul Randall, publicados no ano passado, fazendo o mesmo que pedi para vocês. Coincidência é pouco!
Mesmo assim o resultado dos servidores de vocês ainda é bem vindo, fico no aguardo de mais dados.
Aqui estão os links para ver o resultado dele: http://www.sqlskills.com/BLOGS/PAUL/post/Survey-how-much-server-memory-is-being-wasted-(code-to-run).aspx e http://www.sqlskills.com/BLOGS/PAUL/post/Performance-issues-from-wasted-buffer-pool-memory.aspx
No post de fechamento vou citar algumas coisas importantes, mas como o Paul já falou muito vou aproveitar para mostrar algo diferente do que ele cita no fim do artigo, onde sys.dm_db_index_physical_stats vai estar bem diferente do coletado no data cache.
Acho que isso foi um sinal, quem sabe no futuro a Sr. Nimbus não estará a altura do SQLSkills??!!! HEHEHE
E eu ACHO que existe a chance deles conseguirem mais dados de servidores do que nós. :-)
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Escrevi rapidinho uma pequena consulta que mostra quanto do BPool está sendo “desperdiçado” com fragmentação interna das páginas carregadas. Já tenho uma ideia da média de alguns servidores que tenho contato, mas gostaria de publicar um número, resultado de muitos outros servidores, para TODOS os DBAs terem uma ideia dessa média.
WITH DataCache AS (
SELECT ISNULL(CAST(database_id AS VARCHAR), 'Total') AS DatabaseID
, ((COUNT(page_id) * 8192.0) / 1024.0) / 1024.0 AS TotalUtilizadoMB
, (SUM(CAST(free_space_in_bytes AS BIGINT)) / 1024.0) / 1024.0 AS EspacoLivreMB
FROM sys.dm_os_buffer_descriptorsGROUP BY GROUPING SETS ((database_id), ()))
SELECT DataCache.*
, EspacoLivreMB / TotalUtilizadoMB AS PercentualDesperdicado FROM DataCacheORDER BY EspacoLivreMB DESC
Para me ajudar basta executar essa consulta me enviar (ou colocar no comentário deste post) o resultado que aparece na linha do “Total”. Abaixo um exemplo de saída...
DatabaseID TotalUtiliadoMB EspacoLivreMB PercentualDesperdicado
Total 7404.281250 1212.929668423 0.163814640
Note que dependendo do tamanho do BPool o SQL Server pode ler muitas páginas, mas isso não deve causar nenhum grande impacto no ambiente, dado que a DMV não espera por um latch que está prendendo a página (http://blogs.msdn.com/b/psssql/archive/2009/01/21/how-it-works-sys-dm-os-buffer-descriptors.aspx), mas nos dará uma boa média.
E aí, gostou da ideia? Então vamos ajudar os outros DBAs e executar a consulta. Depois publico o resultado aqui...
!! UPDATE !!
Enquanto conversava com o Fabiano pelo Lync, buscando algumas coisas sobre hobt_id e partition_id, esbarramos com dois posts do Paul Randall, publicados no ano passado, fazendo o mesmo que pedi para vocês. Coincidência é pouco!
Mesmo assim o resultado dos servidores de vocês ainda é bem vindo, fico no aguardo de mais dados.
Aqui estão os links para ver o resultado dele: http://www.sqlskills.com/BLOGS/PAUL/post/Survey-how-much-server-memory-is-being-wasted-(code-to-run).aspx e http://www.sqlskills.com/BLOGS/PAUL/post/Performance-issues-from-wasted-buffer-pool-memory.aspx
No post de fechamento vou citar algumas coisas importantes, mas como o Paul já falou muito vou aproveitar para mostrar algo diferente do que ele cita no fim do artigo, onde sys.dm_db_index_physical_stats vai estar bem diferente do coletado no data cache.
Acho que isso foi um sinal, quem sabe no futuro a Sr. Nimbus não estará a altura do SQLSkills??!!! HEHEHE
E eu ACHO que existe a chance deles conseguirem mais dados de servidores do que nós. :-)
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Corrupção de database snapshots
O DBA em última instância tem que proteger o dado da sua organização. “O dado é o bem mais importante da nossa empresa”, essa frase retumba os corredores de muitas empresas, mesmo elas não fazendo droga nenhuma para cuidar deles ou investir em recursos necessários para suportar a infraestrutura que justifique a frase.
Então você DBA deve realizar a importância do papel que desempenha na empresa e em última instância deve garantir que os dados não serão perdidos, e que estarão íntegros e consistentes. Se ainda não se deu conta da sua importância, pense novamente.
Depois deste pequeno preâmbulo, vamos ao acontecido. Segunda-feira cedo, meu telefone toca e um cliente menciona estar com um problema em um processo que criamos, impedindo que este continue a executar.
Neste ambiente nós trabalhamos com o snapshot de um banco de dados específico, que faz parte do funcionamento do procedimento de importação diário de uma massa considerável de dados, e é a maneira pela qual o ambiente garante a consistência dos dados nesta base. Um snapshot é criado, o arquivo é importado (podendo tocar inúmeras tabelas) e caso algum problema aconteça, podemos reverter o banco de dados à sua imagem original e trabalhar no problema, garantindo que não haverá meio arquivo importado e nem que teremos transações monstras com milhares de operações. Chamo este padrão do SSIS de consistência extrema e apresentei-o no evento em 2009, o virtual 24hs PASS LATAM.
Analisando o estado do ambiente podemos verificar que se tratava de uma corrupção do database snapshot, seguem alguns registros. Os nomes foram trocados por XXXXX para garantir o sigilo do cliente.
Log do SQL Server:
Seguindo o procedimento normal de importação automático, foi criado um snapshot para a importação do arquivo XXXXX, a importação dos dados começou normalmente e um segundo depois tivemos um problema relacionado ao subsistema de disco. Como não havia mais espaço disponível no disco, a operação de I/O que guarda os dados no snapshot não pode acontecer e o snapshot entrou em estado suspect.
Foi possível verificar que o arquivo de snapshot chegou a 6,71 MB, então efetivamente recebeu páginas que foram alteradas no banco de dados de origem. Consultando a tabela afetada notamos que alguns registros do arquivo haviam sido importados para o banco de dados, colocando o banco de dados em um estado inconsistente para o negócio.
Porém a partir desse momento o procedimento de recuperação automática do processo de importação falhou, pois não foi possível reverter o banco de dados para o estado original, dado que o snapshot estava corrompido. Abaixo alguns exemplos das tentativas de utilizar o snapshot, com a respectiva mensagem de erro:
USE 'XXXXX_20120129063004_XXXXX
GO
Msg 926, Level 14, State 1, Line 1
Database 'XXXXX_20120129063004_XXXXX ' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
RESTORE DATABASE XXXXX
FROM DATABASE_SNAPSHOT = 'XXXXX_20120129063004_XXXXX'
Msg 3137, Level 16, State 1, Line 1
Database cannot be reverted. Either the primary or the snapshot names are improperly specified, all other snapshots have not been dropped, or there are missing files.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Uma curiosidade da interface do SSMS é que ela não indica que um database snapshot está marcado como suspect, da mesma forma que é feito para outros bancos de dados, então se você olhar pelo object explorer aparentemente está tudo ok. Consultando a sys.databases vemos o status 4, SUSPECT.
Diferente de outros bancos de dados, as medidas de recuperação não podem ser aplicadas para o database snapshot.
Consultando a documentação do produto podemos ver claramente o que deve ser feito neste caso: “Database snapshots consume disk space. If a database snapshot runs out of disk space, it is marked as suspect and must be dropped. (The source database, however, is not affected; actions on it continue normally.)”. Para confirmar que efetivamente não existe possibilidade, buscamos outra referência (que não sabe quase nada de DR e teste de consistência em um banco de dados) sobre o problema: http://www.sqlmag.com/blog/sql-server-questions-answered-28/sql-server/why-can-a-database-snapshot-run-out-of-space-137145.
Como não podemos utilizar o snapshot, foi necessária uma intervenção manual. Apagamos o snapshot que estava corrompido e foram removidos do banco de dados todos os registros relativos a este arquivo. Depois disso o arquivo foi reprocessado com sucesso, bem como todos os outros arquivos que estavam parados por conta do snapshot que estava impedindo a importação automática de ocorrer.
Felizmente no nosso caso o problema aconteceu com um arquivo simples e a intervenção manual foi bem tranquila e em pouco tempo já tínhamos colocado o banco em estado consistente, com os arquivos importado, e pronto para ser utilizado por outras aplicações.
Porém suponhamos que o problema tivesse acontecido em outro arquivo mais complexo ou em um processamento pesado que devesse ter acontecido durante a janela da madrugada, provavelmente teríamos impactado o ambiente, que não teria os dados disponíveis dentro do SLA do serviço, ou pior, que a intervenção manual não fosse possível para colocar a base em um estado consistente, exigindo um restore... Nada bom.
Sinceramente, não acho que este post tenha uma grande relevância técnica. Mostra que em casos de falta de espaço em disco um snapshot pode se corromper facilmente e o banco de origem continua funcionando normalmente, ignorando o snapshot que passa a ser um arquivo inútil. O que eu gostaria de ressaltar são alguns pontos para reflexão...
A culpa do problema foi do DBA?
De bate-pronto muitos poderiam responder que sim, pois ele deixou acabar o espaço em disco. Mas acho que não podemos ser tão simplistas...
E se eu disser que durante o capacity planning para este servidor fui eu quem escreveu um documento recomendando o dobro de espaço que nos foi disponibilizado? E como fazemos com os procedimentos de manutenção? Deixamos rebuild de lado? Ou fazemos um rebuild de índice a índice, seguindo de um shrink após cada rebuild? (QUE IDEIA FANTÁSTICA! Potencialmente levando a uma fragmentação lógica do índice que acabou de ser reconstruído).
O DBA neste caso tem que fazer malabarismos com o ambiente que lhe foi entregue, tentando gerenciar a escassez dos recursos e, claro, será cobrado se o ambiente ficar fora do ar ou houver perda de dados (e têm que ser cobrado por isso!). Simples? Nem um pouco, é uma baita responsabilidade que não sei se todos os DBAs percebem. Então você DBA têm que continuar aprimorando seus conhecimentos, seu ambiente, e tratando dele com muito carinho e cuidado. Se esse cenário fosse uma extrema exceção à regra, ótimo, o problema é que parece ser muito comum. No fim acho que muitos DBAs têm que receber bem, quem sabe, muito bem...
Termino com uma pérola que ouvi de um gerente de infraestrutura. “Senhor C3PO, precisamos trabalhar com alta disponibilidade dado que nosso ambiente é crítico”, em resposta “Fica tranquilo, a máquina nova é um R2D2 com N processadores XWING, 999999999 de memória e ligado na storage”... Depois de um momento de perplexa reflexão eu gostaria de ir até a sala do gerente e perguntar “Também é feito de adamantium?”.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Então você DBA deve realizar a importância do papel que desempenha na empresa e em última instância deve garantir que os dados não serão perdidos, e que estarão íntegros e consistentes. Se ainda não se deu conta da sua importância, pense novamente.
O Cenário
Depois deste pequeno preâmbulo, vamos ao acontecido. Segunda-feira cedo, meu telefone toca e um cliente menciona estar com um problema em um processo que criamos, impedindo que este continue a executar.
Neste ambiente nós trabalhamos com o snapshot de um banco de dados específico, que faz parte do funcionamento do procedimento de importação diário de uma massa considerável de dados, e é a maneira pela qual o ambiente garante a consistência dos dados nesta base. Um snapshot é criado, o arquivo é importado (podendo tocar inúmeras tabelas) e caso algum problema aconteça, podemos reverter o banco de dados à sua imagem original e trabalhar no problema, garantindo que não haverá meio arquivo importado e nem que teremos transações monstras com milhares de operações. Chamo este padrão do SSIS de consistência extrema e apresentei-o no evento em 2009, o virtual 24hs PASS LATAM.
O Problema
Analisando o estado do ambiente podemos verificar que se tratava de uma corrupção do database snapshot, seguem alguns registros. Os nomes foram trocados por XXXXX para garantir o sigilo do cliente.
Log do SQL Server:
| 1/29/2012 6:30:04 AM | Starting up database 'XXXXX_20120129063004_XXXXX'. |
| 1/29/2012 6:30:05 AM | E:\Data\XXXXX_20120129063004_XXXXXXX.NDF: Operating system error 112(There is not enough space on the disk.) encountered. |
| 1/29/2012 6:30:05 AM | Database snapshot 'XXXXX_20120129063004_XXXXX' has failed an IO operation and is marked suspect. It must be dropped and recreated. |
Seguindo o procedimento normal de importação automático, foi criado um snapshot para a importação do arquivo XXXXX, a importação dos dados começou normalmente e um segundo depois tivemos um problema relacionado ao subsistema de disco. Como não havia mais espaço disponível no disco, a operação de I/O que guarda os dados no snapshot não pode acontecer e o snapshot entrou em estado suspect.
Foi possível verificar que o arquivo de snapshot chegou a 6,71 MB, então efetivamente recebeu páginas que foram alteradas no banco de dados de origem. Consultando a tabela afetada notamos que alguns registros do arquivo haviam sido importados para o banco de dados, colocando o banco de dados em um estado inconsistente para o negócio.
Porém a partir desse momento o procedimento de recuperação automática do processo de importação falhou, pois não foi possível reverter o banco de dados para o estado original, dado que o snapshot estava corrompido. Abaixo alguns exemplos das tentativas de utilizar o snapshot, com a respectiva mensagem de erro:
USE 'XXXXX_20120129063004_XXXXX
GO
Msg 926, Level 14, State 1, Line 1
Database 'XXXXX_20120129063004_XXXXX ' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
RESTORE DATABASE XXXXX
FROM DATABASE_SNAPSHOT = 'XXXXX_20120129063004_XXXXX'
Msg 3137, Level 16, State 1, Line 1
Database cannot be reverted. Either the primary or the snapshot names are improperly specified, all other snapshots have not been dropped, or there are missing files.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Uma curiosidade da interface do SSMS é que ela não indica que um database snapshot está marcado como suspect, da mesma forma que é feito para outros bancos de dados, então se você olhar pelo object explorer aparentemente está tudo ok. Consultando a sys.databases vemos o status 4, SUSPECT.
Solução do problema
Diferente de outros bancos de dados, as medidas de recuperação não podem ser aplicadas para o database snapshot.
Consultando a documentação do produto podemos ver claramente o que deve ser feito neste caso: “Database snapshots consume disk space. If a database snapshot runs out of disk space, it is marked as suspect and must be dropped. (The source database, however, is not affected; actions on it continue normally.)”. Para confirmar que efetivamente não existe possibilidade, buscamos outra referência (que não sabe quase nada de DR e teste de consistência em um banco de dados) sobre o problema: http://www.sqlmag.com/blog/sql-server-questions-answered-28/sql-server/why-can-a-database-snapshot-run-out-of-space-137145.
Como não podemos utilizar o snapshot, foi necessária uma intervenção manual. Apagamos o snapshot que estava corrompido e foram removidos do banco de dados todos os registros relativos a este arquivo. Depois disso o arquivo foi reprocessado com sucesso, bem como todos os outros arquivos que estavam parados por conta do snapshot que estava impedindo a importação automática de ocorrer.
Conclusão
Felizmente no nosso caso o problema aconteceu com um arquivo simples e a intervenção manual foi bem tranquila e em pouco tempo já tínhamos colocado o banco em estado consistente, com os arquivos importado, e pronto para ser utilizado por outras aplicações.
Porém suponhamos que o problema tivesse acontecido em outro arquivo mais complexo ou em um processamento pesado que devesse ter acontecido durante a janela da madrugada, provavelmente teríamos impactado o ambiente, que não teria os dados disponíveis dentro do SLA do serviço, ou pior, que a intervenção manual não fosse possível para colocar a base em um estado consistente, exigindo um restore... Nada bom.
Sinceramente, não acho que este post tenha uma grande relevância técnica. Mostra que em casos de falta de espaço em disco um snapshot pode se corromper facilmente e o banco de origem continua funcionando normalmente, ignorando o snapshot que passa a ser um arquivo inútil. O que eu gostaria de ressaltar são alguns pontos para reflexão...
A culpa do problema foi do DBA?
De bate-pronto muitos poderiam responder que sim, pois ele deixou acabar o espaço em disco. Mas acho que não podemos ser tão simplistas...
E se eu disser que durante o capacity planning para este servidor fui eu quem escreveu um documento recomendando o dobro de espaço que nos foi disponibilizado? E como fazemos com os procedimentos de manutenção? Deixamos rebuild de lado? Ou fazemos um rebuild de índice a índice, seguindo de um shrink após cada rebuild? (QUE IDEIA FANTÁSTICA! Potencialmente levando a uma fragmentação lógica do índice que acabou de ser reconstruído).
O DBA neste caso tem que fazer malabarismos com o ambiente que lhe foi entregue, tentando gerenciar a escassez dos recursos e, claro, será cobrado se o ambiente ficar fora do ar ou houver perda de dados (e têm que ser cobrado por isso!). Simples? Nem um pouco, é uma baita responsabilidade que não sei se todos os DBAs percebem. Então você DBA têm que continuar aprimorando seus conhecimentos, seu ambiente, e tratando dele com muito carinho e cuidado. Se esse cenário fosse uma extrema exceção à regra, ótimo, o problema é que parece ser muito comum. No fim acho que muitos DBAs têm que receber bem, quem sabe, muito bem...
Termino com uma pérola que ouvi de um gerente de infraestrutura. “Senhor C3PO, precisamos trabalhar com alta disponibilidade dado que nosso ambiente é crítico”, em resposta “Fica tranquilo, a máquina nova é um R2D2 com N processadores XWING, 999999999 de memória e ligado na storage”... Depois de um momento de perplexa reflexão eu gostaria de ir até a sala do gerente e perguntar “Também é feito de adamantium?”.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
segunda-feira, 9 de janeiro de 2012
[SQLServerDF] Encontro XII - Por dentro dos wait types (versão estendida)
Bom dia pessoal, tudo bem?
Ano novo, gás renovado, então que tal retomarmos os nosso encontros do SQLServerDF?
Para iniciar nosso ano quero apresentar um dos assuntos que mais gostei de falar no ano passado: waits no SQL Server.
Fiz uma palestra de uma hora sobre esse assunto no SQLSat #100, mas quem esteve presente pode perceber que a sessão foi bem corrida, então vou aproveitar um maior tempo dos encontros do SQLServerDF para fazer uma introdução com mais calma, explorarmos as demonstrações com mais detalhes e, quem sabe, até analisarmos outros wait types?
Fiz uma palestra de uma hora sobre esse assunto no SQLSat #100, mas quem esteve presente pode perceber que a sessão foi bem corrida, então vou aproveitar um maior tempo dos encontros do SQLServerDF para fazer uma introdução com mais calma, explorarmos as demonstrações com mais detalhes e, quem sabe, até analisarmos outros wait types?
As informações sobre o encontro são:
Local: Auditório da Microsoft - Edifício Corporate Financial Center, sala 302 - Brasília
Data e horário: 19/01/2012, 17:00h ~ 19:30h
Tema: Por dentro dos Wait Types (versão estendida)
Descrição: Essa sessão têm por objetivo explicar o que são wait types, discutir um pouco do funcionamento da engine do SQL Server, qual quais os wait types mais comuns e seu significado. Se você cansou de olhar para a sys.dm_os_wait_stats sem entender direito o que o SQL Server está te informando, essa sessão é para você.
Nota: não é uma sessão introdutória, então se usarmos xEvents ou outros recursos do SQL Server, provavelmente não teremos tempo de explicá-las em detalhes.
Palestrante: Luciano Caixeta Moreira
Mini-bio:
Quer participar? Então mande para o grupo SQLServerDF um e-mail confirmando sua presença, pois a capacidade do auditório é limitada, portanto atendemos por ordem de recebimento de e-mails!
Para aqueles que perguntam: vai ser transmitido ao vivo? Não. Gravado: talvez. Estou pensando na ideia de colocar o Camtasia gravando a sessão, o problema fica sempre por conta do áudio... O SQLServerDF aceita doações de microfones bluetooth ou qualquer equipamento bacana que possa nos ajudar a conduzir melhor os encontros do grupo. :-)Luciano Caixeta Moreira é fundador da empresa Sr. Nimbus, onde atua como consultor e instrutor SQL Server/.NET. Trabalhou na Microsoft Brasil entre Janeiro de 2006 e Março de 2009, onde atuou como Premier Field Engineer de SQL Server e especialista em desenvolvimento. Formado em ciência da computação pela Universidade de Brasília, ele atua com desenvolvimento, consultoria e treinamento de tecnologias Microsoft desde 2000, sempre focado no desenvolvimento de soluções e banco de dados. Luciano obtém as certificações MCP, MCAD .NET, MCSD .NET, MCDBA, MCTS (SQL Server 2005/2008, .NET 3.5, ADO.NET 3.5 e ADO.NET 4.0), MCITP (SQL Server 2005/2008) e MCT, nomeado MVP de SQL Server em Julho/2010, também e escreve em seu blog: http://luticm.blogspot.com
Quer participar? Então mande para o grupo SQLServerDF um e-mail confirmando sua presença, pois a capacidade do auditório é limitada, portanto atendemos por ordem de recebimento de e-mails!
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
sábado, 26 de novembro de 2011
SQL Saturday #100: Por dentro dos wait types no SQL Server
Boa tarde pessoal, hoje no fim da manhã eu fiz minha apresentação para o SQL Saturday #100.
Tentei manter uma apresentação um pouco puxada (nível 400) e demonstrar para o pessoal alguns cenários com wait types mais comuns (mas não menos problemáticos). Consegui terminar mais ou menos no tempo certo e ainda contei com alguns minutinhos extras para tirar dúvidas.
Para não voltar à rotina e ficar devendo os scripts (ok, ok, ainda vou publicar os scripts do TechEd 2011, shame on me!), aqui estão...
PPT da apresentação:
Scripts da apresentação:
O bom do twitter que é difícil alguém ficar reclamando da sua palestra, e pelo que acompanhei, parece que o pessoal gostou. :-)
Comentários são sempre bem vindos!
Como eu disse no twitter, viajar, preparar a apresentação, noites mal dormidas, investmento do próprio bolso, tudo é cansativo e complicado. Mas depois que você encontra os amigos, faz uma apresentação interessante e vê a empolgação do pessoal, lembra que tudo isso vale mmmuuiittoo a pena.
Quem sabe até o próximo SQLSaturday no Brasil...
[]s
Luciano Caixeta Moreira - {Luti}luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Tentei manter uma apresentação um pouco puxada (nível 400) e demonstrar para o pessoal alguns cenários com wait types mais comuns (mas não menos problemáticos). Consegui terminar mais ou menos no tempo certo e ainda contei com alguns minutinhos extras para tirar dúvidas.
Para não voltar à rotina e ficar devendo os scripts (ok, ok, ainda vou publicar os scripts do TechEd 2011, shame on me!), aqui estão...
PPT da apresentação:
Scripts da apresentação:
O bom do twitter que é difícil alguém ficar reclamando da sua palestra, e pelo que acompanhei, parece que o pessoal gostou. :-)
Comentários são sempre bem vindos!
Como eu disse no twitter, viajar, preparar a apresentação, noites mal dormidas, investmento do próprio bolso, tudo é cansativo e complicado. Mas depois que você encontra os amigos, faz uma apresentação interessante e vê a empolgação do pessoal, lembra que tudo isso vale mmmuuiittoo a pena.
Quem sabe até o próximo SQLSaturday no Brasil...
[]s
Luciano Caixeta Moreira - {Luti}luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
sexta-feira, 8 de julho de 2011
[Artigo] O caso dos snapshots e data cache thrashing
Segue mais um artigo!
Data cache e database snapshots! Gostei bastante de escrevê-lo.
Oriundo de uma dúvida na DL do SQLServerDF, já estou começando a escrever outro post sobre Database Snapshots. Legal ou não?
https://skydrive.live.com/?cid=e145f7753042d628&sc=documents&uc=1&id=E145F7753042D628%211068
PS: já que esse artigo surgiu de uma última conversa com o Luan Moreno como funcionário da Nimbus, que agora está ajudando outra empresa com suas habilidades de DBA, fica aqui o meu obrigado para esse amigo e que possamos ter muitas outras conversas!
Sucesso Luan! Fica rico e depois volta para a Nimbus.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Data cache e database snapshots! Gostei bastante de escrevê-lo.
Oriundo de uma dúvida na DL do SQLServerDF, já estou começando a escrever outro post sobre Database Snapshots. Legal ou não?
https://skydrive.live.com/?cid=e145f7753042d628&sc=documents&uc=1&id=E145F7753042D628%211068
PS: já que esse artigo surgiu de uma última conversa com o Luan Moreno como funcionário da Nimbus, que agora está ajudando outra empresa com suas habilidades de DBA, fica aqui o meu obrigado para esse amigo e que possamos ter muitas outras conversas!
Sucesso Luan! Fica rico e depois volta para a Nimbus.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
sexta-feira, 27 de maio de 2011
Balanced Data Distributor para o SSIS
Estava navegando pelos meus RSSs e encontrei algo fantástico para o SSIS. Um blog de performance do SQL Server, parado a mais de um ano, publicou um post sobre o Balanced Data Distributor que você pode ler aqui: http://blogs.msdn.com/b/sqlperf/archive/2011/05/25/the-balanced-data-distributor-for-ssis.aspx.
Olha que bacana, agora podemos colocar no data flow um componente que quebra o fluxo de dados em diferentes fluxos de saída (potencialmente com uma distribuição homogênea), permitindo utilizar um maior paralelismo no seu pacote e melhorar o desempenho na carga dos dados.
O post do Len Wyatt já dá uma explicação legal, discutindo possíveis casos de gargalos, então não vou ficar muito na teoria. Para alimentar o espírito geek eu baixei o BDD e fiz um pequeno teste no SSIS.
Cenário: criei um raw file com 30.000 registros e disparei da minha máquina (um dual core) o pacote. Este vai pegar esses registros e fazer 30.000 lookups contra um servidor SQL Server (nada parrudo, uma máquina bbeeemmm simples), inserindo os campos originais mais um campo retornado pelo lookup em uma tabela de destino (deixei como uma heap).
Minha intenção é conseguir paralelizar os lookups e ver o ganho de desempenho, já que o lookup é uma operação cara (ainda mais com a forma padrão que o SSIS trabalha).
Abaixo temos as três figuras, mostrando o BDD trabalhando com um, dois e quatro fluxos de dados.
Executei cada teste duas vezes e registrei os tempos de execução de cada pacote…
1 fluxo de dados
Tempo 1: Finished, 1:12:38 PM, Elapsed time: 00:01:00.123
Tempo 2: Finished, 1:15:12 PM, Elapsed time: 00:00:53.493
2 fluxo sde dados
Tempo 1: Finished, 1:17:07 PM, Elapsed time: 00:00:38.376
Tempo 2: Finished, 1:18:32 PM, Elapsed time: 00:00:33.650
4 fluxos de dados
Tempo 1: Finished, 1:21:04 PM, Elapsed time: 00:00:24.804
Tempo 2: Finished, 1:22:00 PM, Elapsed time: 00:00:23.962
Com o paralelismo do BDD e quatro fluxos o tempo caiu de quase um minuto para 24 segundos! E isso que as máquinas não são boas ou massivamente paralelas, imagine isso rodando em um servidor feroz.
Outro detalhe interessante do BDD que já dá para perceber pelos testes é a forma que ele trabalha. Ele não vai jogar uma linha para um fluxo, depois outra linha para outro fluxo e assim sucessivamente, o BDD pega o conteúdo do buffer e vai jogando para cada fluxo. Na figura 3 podemos notar que depois de já ter distribuido 28.671 registros, somente sobraram 1.329 para o quarto ramo. Uma implementação bem eficiente que nos dá indício que ainda podemos tirar vantagem de alguns ajustes do tamanho do buffer no pipeline.
Antes desse componente poderíamos tentar algo bem menos efetivo, fazendo um gatinho (mmiiaauuu) com o conditional split. Mas aí você deveria definir como são distribuídos os fluxos e a lógica teria que ser muito eficiente para não haver um desbalanceamento nos ramos… Algo como um campo que tivesse uma distribuição homogênea para os registros e estes intercalados, para garantir a distribuição igualitária durante o processamento dos buffers, senão você teria um ramo sendo usado primeiro, depois outro, etc. (sem um paralelismo efetivo). Isto é, antes do BDD a ideia é factível, mas improvável de ser implementado de forma eficiente.
E não, esse não é um componente que está no Denali, pelo menos eu ainda não vi nada a respeito sobre a inclusão dele e os CTPs não possuem esse componente… Mas bem que poderia ser incluído!
Eu me diverti, e você?
Atualização
{
A dúvida do Rodrigo é muito pertinente! A diferença do BDD para o multicast NÃO está no paralelismo, pois o multicast também pode usufruir de múltiplas thread, mas normalmente com os ramos fazendo operações diferentes entre si ou populando destinos diferentes.
Supondo que no multicast você têm 12 regsitros no pipeline, os mesmo 12 registros vão fluir em cada ramo. Então supondo 4 ramos, se você inserisse tudo na mesma tabela iria acabar com 48 registros, cada um aparecendo 4 vezes.
Com o BDD os 12 registros que entram no pipeline serão distribuídos entre os ramos, deixando 3 registros para cada ramo (exemplo hipotético, já que no fundo a divisão é feita pela quantidade de registros que cabe em um buffer do pipeline). Se inseridos em uma única tabela, como foi o meu exemplo, você teria os 12 registros sem duplicatas.
Espero ter sido claro, qualquer coisa grita!
}
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/
Olha que bacana, agora podemos colocar no data flow um componente que quebra o fluxo de dados em diferentes fluxos de saída (potencialmente com uma distribuição homogênea), permitindo utilizar um maior paralelismo no seu pacote e melhorar o desempenho na carga dos dados.
O post do Len Wyatt já dá uma explicação legal, discutindo possíveis casos de gargalos, então não vou ficar muito na teoria. Para alimentar o espírito geek eu baixei o BDD e fiz um pequeno teste no SSIS.
Cenário: criei um raw file com 30.000 registros e disparei da minha máquina (um dual core) o pacote. Este vai pegar esses registros e fazer 30.000 lookups contra um servidor SQL Server (nada parrudo, uma máquina bbeeemmm simples), inserindo os campos originais mais um campo retornado pelo lookup em uma tabela de destino (deixei como uma heap).
Minha intenção é conseguir paralelizar os lookups e ver o ganho de desempenho, já que o lookup é uma operação cara (ainda mais com a forma padrão que o SSIS trabalha).
Abaixo temos as três figuras, mostrando o BDD trabalhando com um, dois e quatro fluxos de dados.
Figura 01 – Somente um fluxo de dados
Figura 02 – Dois fluxos de dados
Figura 03 – Quatro fluxos de dados
1 fluxo de dados
Tempo 1: Finished, 1:12:38 PM, Elapsed time: 00:01:00.123
Tempo 2: Finished, 1:15:12 PM, Elapsed time: 00:00:53.493
2 fluxo sde dados
Tempo 1: Finished, 1:17:07 PM, Elapsed time: 00:00:38.376
Tempo 2: Finished, 1:18:32 PM, Elapsed time: 00:00:33.650
4 fluxos de dados
Tempo 1: Finished, 1:21:04 PM, Elapsed time: 00:00:24.804
Tempo 2: Finished, 1:22:00 PM, Elapsed time: 00:00:23.962
Com o paralelismo do BDD e quatro fluxos o tempo caiu de quase um minuto para 24 segundos! E isso que as máquinas não são boas ou massivamente paralelas, imagine isso rodando em um servidor feroz.
Outro detalhe interessante do BDD que já dá para perceber pelos testes é a forma que ele trabalha. Ele não vai jogar uma linha para um fluxo, depois outra linha para outro fluxo e assim sucessivamente, o BDD pega o conteúdo do buffer e vai jogando para cada fluxo. Na figura 3 podemos notar que depois de já ter distribuido 28.671 registros, somente sobraram 1.329 para o quarto ramo. Uma implementação bem eficiente que nos dá indício que ainda podemos tirar vantagem de alguns ajustes do tamanho do buffer no pipeline.
Antes desse componente poderíamos tentar algo bem menos efetivo, fazendo um gatinho (mmiiaauuu) com o conditional split. Mas aí você deveria definir como são distribuídos os fluxos e a lógica teria que ser muito eficiente para não haver um desbalanceamento nos ramos… Algo como um campo que tivesse uma distribuição homogênea para os registros e estes intercalados, para garantir a distribuição igualitária durante o processamento dos buffers, senão você teria um ramo sendo usado primeiro, depois outro, etc. (sem um paralelismo efetivo). Isto é, antes do BDD a ideia é factível, mas improvável de ser implementado de forma eficiente.
E não, esse não é um componente que está no Denali, pelo menos eu ainda não vi nada a respeito sobre a inclusão dele e os CTPs não possuem esse componente… Mas bem que poderia ser incluído!
Eu me diverti, e você?
Atualização
{
A dúvida do Rodrigo é muito pertinente! A diferença do BDD para o multicast NÃO está no paralelismo, pois o multicast também pode usufruir de múltiplas thread, mas normalmente com os ramos fazendo operações diferentes entre si ou populando destinos diferentes.
Supondo que no multicast você têm 12 regsitros no pipeline, os mesmo 12 registros vão fluir em cada ramo. Então supondo 4 ramos, se você inserisse tudo na mesma tabela iria acabar com 48 registros, cada um aparecendo 4 vezes.
Com o BDD os 12 registros que entram no pipeline serão distribuídos entre os ramos, deixando 3 registros para cada ramo (exemplo hipotético, já que no fundo a divisão é feita pela quantidade de registros que cabe em um buffer do pipeline). Se inseridos em uma única tabela, como foi o meu exemplo, você teria os 12 registros sem duplicatas.
Espero ter sido claro, qualquer coisa grita!
}
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/
terça-feira, 24 de maio de 2011
Intellisense do SQL Server 2008 R2 e o SP1 do Visual Studio 2010
Bom dia pessoal.
Nesse fim de semana formatei a minha máquina e aproveitei para deixar o SQL Server 2008 R2 como instância default, atualizar o VS 2010 com o SP1 e finalmente instalar o Win7 SP1.
Quando fui trabalhar na segunda-feira descobri que o intellisense do SQL Server Management Studio não estava funcionando. Fiz o troubleshooting básico de configuração do SSMS e nada! Pesquisando um pouquinho acabei por descobrir o culpado disso tudo: o Service Pack 1 do Visual Studio 2010!
A solução dada pela Microsoft é instalar o Cumulative Update 7 do SQL Server 2008 R2 para solucionar o problema. Eu instalei e tudo voltou a funcionar normalmente.
Algumas referências para o acontecido:
FIX: The IntelliSense feature in SSMS 2008 R2 may stop working after you install Visual Studio 2010 SP1
Cumulative Update package 7 for SQL Server 2008 R2
E um KB legal de acompanhar: The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released
Eu vi que algumas pessoas tiveram um problema com projetos do DBPro depois de instalado do CU#7, mas não aconteceu comigo.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/
Nesse fim de semana formatei a minha máquina e aproveitei para deixar o SQL Server 2008 R2 como instância default, atualizar o VS 2010 com o SP1 e finalmente instalar o Win7 SP1.
Quando fui trabalhar na segunda-feira descobri que o intellisense do SQL Server Management Studio não estava funcionando. Fiz o troubleshooting básico de configuração do SSMS e nada! Pesquisando um pouquinho acabei por descobrir o culpado disso tudo: o Service Pack 1 do Visual Studio 2010!
A solução dada pela Microsoft é instalar o Cumulative Update 7 do SQL Server 2008 R2 para solucionar o problema. Eu instalei e tudo voltou a funcionar normalmente.
Algumas referências para o acontecido:
FIX: The IntelliSense feature in SSMS 2008 R2 may stop working after you install Visual Studio 2010 SP1
Cumulative Update package 7 for SQL Server 2008 R2
E um KB legal de acompanhar: The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released
Eu vi que algumas pessoas tiveram um problema com projetos do DBPro depois de instalado do CU#7, mas não aconteceu comigo.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/
terça-feira, 19 de abril de 2011
[SQLServerDF] Encontro XI - Recursos avançados do Service Broker
Bom dia pessoal, tudo bem?
Vamos com mais um encontro do grupo SQLServerDF...
As informações sobre o encontro são:
Local: Auditório da Microsoft - Edifício Corporate Financial Center, sala 302
Data e horário: 10/05/2011, 17:00h ~ 19:00h
Tema: Recursos avançados do Service Broker
Agenda:
- Utilizando o SQL Service Broker e Mensageria de dados no SQL Server em cenários distribuídos
- Uma aplicação prática do Service Broker em cenários de múltiplos bancos em instâncias diferentes
Descrição: Essa é uma apresentação sobre implementações avançadas do Service Broker que apresentará o uso dessa feature em cenários complexos envolvendo processamento distribuído em várias instâncias. Trata-se de uma continuação da sessão do encontro anterior que fez uma apresentação do Service Broker.
Palestrante: Gustavo Maia Aguiar
Gustavo Maia Aguiar é pós-graduado em bancos de dados e trabalha com SQL Server desde 2003 possuindo larga experiência em projetos de implementação e manutenção banco de dados nessa plataforma. Possui as certificações MCP, MCDBA, MCITP, MCT e MVP em SQL Server. É membro ativo e moderador dos fóruns MSDN, Technet e das comunidades SQL Server Brasil e SQL Brasil (Orkut) e posta artigos técnicos em seu blog: http://gustavomaiaaguiar.wordpress.com
Favor mandar para o grupo um e-mail confirmando sua presença para luan.moreno@srnimbus.com.br, pois a capacidade do auditório não é ilimitado.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Vamos com mais um encontro do grupo SQLServerDF...
As informações sobre o encontro são:
Local: Auditório da Microsoft - Edifício Corporate Financial Center, sala 302
Data e horário: 10/05/2011, 17:00h ~ 19:00h
Tema: Recursos avançados do Service Broker
Agenda:
- Utilizando o SQL Service Broker e Mensageria de dados no SQL Server em cenários distribuídos
- Uma aplicação prática do Service Broker em cenários de múltiplos bancos em instâncias diferentes
Descrição: Essa é uma apresentação sobre implementações avançadas do Service Broker que apresentará o uso dessa feature em cenários complexos envolvendo processamento distribuído em várias instâncias. Trata-se de uma continuação da sessão do encontro anterior que fez uma apresentação do Service Broker.
Palestrante: Gustavo Maia Aguiar
Gustavo Maia Aguiar é pós-graduado em bancos de dados e trabalha com SQL Server desde 2003 possuindo larga experiência em projetos de implementação e manutenção banco de dados nessa plataforma. Possui as certificações MCP, MCDBA, MCITP, MCT e MVP em SQL Server. É membro ativo e moderador dos fóruns MSDN, Technet e das comunidades SQL Server Brasil e SQL Brasil (Orkut) e posta artigos técnicos em seu blog: http://gustavomaiaaguiar.wordpress.com
Favor mandar para o grupo um e-mail confirmando sua presença para luan.moreno@srnimbus.com.br, pois a capacidade do auditório não é ilimitado.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
[SQLServerDF] Encontro X - Introdução ao Service Broker
Bom dia pessoal, tudo bem?
Vamos com mais um encontro do grupo SQLServerDF...
As informações sobre o encontro são:
Local: Auditório da Microsoft - Edifício Corporate Financial Center, sala 302
Data e horário: 27/04/2011, 17:00h ~ 19:00h
Tema: Introdução ao Service Broker
Agenda:
- Introdução ao SQL Service Broker e Mensageria de dados no SQL Server
- Uma aplicação prática do Service Broker em cenários de vários bancos de dados na mesma instância
Descrição: Essa é uma apresentação sobre o Service Broker e aplicações de mensageria utilizando o SQL Server onde serão apresentados os fundamentos de aplicações baseadas em mensageria, conceitos e benefícios do Service Broker bem como um cenário prático de utilização do mesmo. Essa sessão irá servir de introdução para o próximo encontro, onde serão apresentados recursos e implementações envolvendo instâncias diferentes.
Palestrante: Gustavo Maia Aguiar
Gustavo Maia Aguiar é pós-graduado em bancos de dados e trabalha com SQL Server desde 2003 possuindo larga experiência em projetos de implementação e manutenção banco de dados nessa plataforma. Possui as certificações MCP, MCDBA, MCITP, MCT e MVP em SQL Server. É membro ativo e moderador dos fóruns MSDN, Technet e das comunidades SQL Server Brasil e SQL Brasil (Orkut) e posta artigos técnicos em seu blog: http://gustavomaiaaguiar.wordpress.com
Favor mandar para o grupo um e-mail confirmando sua presença para luan.moreno@srnimbus.com.br, pois a capacidade do auditório não é ilimitado.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Vamos com mais um encontro do grupo SQLServerDF...
As informações sobre o encontro são:
Local: Auditório da Microsoft - Edifício Corporate Financial Center, sala 302
Data e horário: 27/04/2011, 17:00h ~ 19:00h
Tema: Introdução ao Service Broker
Agenda:
- Introdução ao SQL Service Broker e Mensageria de dados no SQL Server
- Uma aplicação prática do Service Broker em cenários de vários bancos de dados na mesma instância
Descrição: Essa é uma apresentação sobre o Service Broker e aplicações de mensageria utilizando o SQL Server onde serão apresentados os fundamentos de aplicações baseadas em mensageria, conceitos e benefícios do Service Broker bem como um cenário prático de utilização do mesmo. Essa sessão irá servir de introdução para o próximo encontro, onde serão apresentados recursos e implementações envolvendo instâncias diferentes.
Palestrante: Gustavo Maia Aguiar
Gustavo Maia Aguiar é pós-graduado em bancos de dados e trabalha com SQL Server desde 2003 possuindo larga experiência em projetos de implementação e manutenção banco de dados nessa plataforma. Possui as certificações MCP, MCDBA, MCITP, MCT e MVP em SQL Server. É membro ativo e moderador dos fóruns MSDN, Technet e das comunidades SQL Server Brasil e SQL Brasil (Orkut) e posta artigos técnicos em seu blog: http://gustavomaiaaguiar.wordpress.com
Favor mandar para o grupo um e-mail confirmando sua presença para luan.moreno@srnimbus.com.br, pois a capacidade do auditório não é ilimitado.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
quinta-feira, 14 de abril de 2011
ADO.NET SqlParameter vs. Plan Cache
Oi pessoal, escrevi um novo artigo sobre o uso efetivo do SqlParameter e seu efeito no plan cache do SQL Server. Depois eu penso em atualizar o blog com o texto (sim, não tenho muita paciência para formatação), mas publiquei o PDF no skydrive.
Espero que vocês gostem...
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/
Espero que vocês gostem...
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/
Assinar:
Postagens (Atom)