Gartner 2016 – Magic Quadrant – DBMS

Galera,

Pelo segundo ano a Microsoft continua como líder na categoria de Operational Database Management Systems no quadrante mágico do Gartner com o SQL Server, Azure SQL Database, Azure DocumentDB e Azure Tables.

screen-shot-2016-10-07-at-02-23-49

Para quem quiser conferir o relatório completo, segue abaixo o link:

Gartner 2016 – Operational Database Management Systems

SQL Server 2014 Service Pack 2

Galera,

Foi liberado hoje o Service Pack 2 do SQL Server 2014.

O download já está disponível através do link abaixo.

Quem quiser pode conferir as principais alterações incluídas no Service Pack 2:

anúncio do SQL Server 2014 SP2 foi feito hoje no blog oficial do SQL Server.

Verificando databases com Log Shipping desativado

Já precisou conferir se todas as databases estavam com Log Shipping configurado?

Teve que entrar nas propriedades de cada database e conferir?

Então baixe o script abaixo da galeria da TechNet agora!

Download Script – Databases sem Log Shipping

O script irá retornar apenas as databases que estão com o recurso de Log Shipping desativado. Ele será ótimo se você precisar conferir se esqueceu de ativar o recurso em alguma database ou até mesmo em rotinas de verificação do ambiente.

 

Faça hoje o download do SQL Server Developer Edition!

Já faz um bom tempo (quase 3 meses), mas sempre é bom lembrar.

Pra quem não sabe desde 31 de Março deste ano a edição Developer do SQL Server é free a partir da versão 2014 para os membros do programa Visual Studio Dev Essentials.

Lembrando que a edição Developer deve ser utilizada apenas em ambientes de desenvolvimento e teste e nunca em ambientes de produção.

Não perde tempo! Baixe agora a edição Developer do SQL Server para fazer aqueles testes e laboratórios!

Post do anúncio no blog da TechNet

Link para download do SQL Server 2014 Developer Edition with Service Pack 1

Como remover um plano de execução específico do cache do SQL Server

Tudo está indo bem, o seu servidor de SQL está com baixa utilização de CPU, PLE alto, poucos índices fragmentados e as estatísticas atualizadas, quando de repente a utilização de CPU sobe para 100% e você nota que existem várias sessões de uma mesma aplicação executando a mesma consulta, que até então nunca tinha apresentado problema, demorando demais para retornar o resultado e estão bombardeando o SQL Server.

Screen Shot 2016-06-17 at 11.53.55 PM

Respire fundo. Muita calma. Há uma saída.

Primeiramente você precisa do conteúdo do campo sql_handle ou plan_handle da consulta que está com problemas para remover o seu plano de execução do cache.

Para capturar o sql_handle ou plan_handle da consulta você pode utilizar apenas uma DMV e uma DMFsys.dm_exec_query_statssys.dm_exec_sql_text. Você pode filtrar utilizando um trecho da consulta que você sabe que está com problemas e/ou até mesmo ordenar por um dos campos de total de utilização de CPU ou de tempo de duração, conforme exemplo abaixo:


SELECT TOP 10
execution_count,
total_elapsed_time / 1000 as totalDurationms,
total_worker_time / 1000 as totalCPUms,
total_logical_reads,
total_physical_reads,
t.text,
sql_handle,
plan_handle
FROM sys.dm_exec_query_stats s
CROSS APPLY sys.dm_exec_sql_text(s.sql_handle) as t
WHERE t.text LIKE '%linq%'
ORDER BY total_elapsed_time DESC

Screen Shot 2016-06-17 at 11.52.10 PM

Copie o conteúdo do campo plan_handle ou sql_handle da consulta exata que está com problemas.

Insira o conteúdo copiado dentro dos parênteses do comando DBCC FREEPROCCACHE, conforme exemplo abaixo:


DBCC FREEPROCCACHE (0x0600060020527003B0928B53CC01000001000000000000000000000000000000000000000000000000000000)

Screen Shot 2016-06-18 at 12.24.18 AM

Pronto! O plano de execução da sua consulta foi removido com sucesso do cache do SQL Server e provavelmente o seu servidor irá diminuir a alta utilização de recursos e voltar a responder normalmente. Depois deste susto procure melhorar o desempenho da sua consulta e entender o que fez com que o plano de execução tenha sofrido alteração.

Observações:

  1. Utilize este procedimento como uma solução de contorno e não como uma solução definitiva para o problema. Procure melhorar o desempenho da consulta e entender o que está fazendo com que o plano de execução sofra alteração ou tenha um desempenho ruim.
  2. Nunca utilize o comando DBCC FREEPROCCACHE sem nenhum conteúdo dentro dos parênteses, principalmente em ambientes de produção, pois isto irá remover TODOS os planos de execução do cache.

 

É isso galera! Espero que tenham gostado. Até a próxima!

SQL Server Storage: Como visualizar o tamanho dos blocos de todos os volumes

Em certas ocasiões durante a instalação de uma nova instância de SQL Server ou até mesmo para revisar um ambiente precisamos verificar todos os volumes dos nossos servidores para obter os tamanhos de blocos de cada um por motivos de desempenho do SQL Server ou apenas para revisar as configurações de storage do SQL Server.

IMPORTANTE: Lembre-se sempre de formatar os seus discos em blocos de 64K para melhor desempenho do SQL Server.

Vou mostrar pra vocês uma alternativa simples para obter o tamanho do bloco de todos os volumes existentes em um servidor.

Em vez de executar o comando “fsutil fsinfo ntfsinfo C:” para cada volume e ficar olhando para a linha “Bytes per cluster”, você só precisa executar o script abaixo.

Abra uma nova janela do Powershell como administrador e digite o seguinte script:

Captura de Tela 2016-03-31 às 21.40.01

Para facilitar você pode fazer o download deste script no link abaixo da TechNet Gallery:

https://gallery.technet.microsoft.com/PowerShell-Get-Volumes-ac89376b

Após a execução do script você terá uma lista completa de todos os seus volumes e o tamanho do bloco de cada um:

Captura de Tela 2016-03-31 às 19.32.39

É isso galera! Espero que tenham gostado. Até a próxima!

Atraso no truncamento do Transaction Log: Snapshot Replication

Galera,

Algumas vezes podemos nos deparar com cenários aonde o Transaction Log de uma database configurada com Recovery Model FULL não para de crescer e o mesmo nunca é truncado, mesmo que os backups de transaction log ocorram com frequência. Este comportamento pode ocorrer por várias razões: transações ativas, backups/restores em andamento, replicação, entre outros motivos, os quais você pode conferir neste link.

Neste post vamos falar de um motivo específico no atraso do truncamento do log de transação: REPLICATION. Mais especificamente SNAPSHOT REPLICATION e de como aplicar uma possível solução de contorno para situações de emergência.

Para conferirmos o motivo da não reutilização do log de transação podemos sempre utilizar a coluna log_reuse_wait_desc da tabela de sistema sys.databases, conforme consulta abaixo:

01

Como podemos conferir na imagem abaixo o motivo do nosso log não ser truncado/reutilizado é devido a uma replicação configurada na instância do SQL Server.

02

Se esta replicação configurada for do tipo SNAPSHOT, seu log de transação estiver cheio, você estiver sem espaço em disco e não souber o que fazer, comece executando o comando abaixo na sua database:

03

Captura de Tela 2016-02-24 às 00.28.29

Se o resultado do comando DBCC OPENTRAN for semelhante ao retorno exibido acima há uma saída.

Na sua base de dados que está com o log de transação cheio e não pode ser reutilizado devido a replicação, conforme conferido anteriormente na coluna log_reuse_wait_desc execute o comando abaixo:

05

Após a execução deste comando as pendências de replicação devem estar resolvidas e o seu log de transação poderá ser reutilizado. Agora você deve garantir que a replicação está replicando todas alterações de estrutura para garantir a integridade da mesma.

Atenção: O comando sp_repldone deve ser utilizado apenas em situações de emergência. Esta não deve ser considerada como a solução definitiva do problema e sim apenas uma solução de contorno.

 

Referências:

https://msdn.microsoft.com/pt-br/library/ms173775(v=sql.120).aspx

http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx