SQL Server - Pare de usar DBCC DBREINDEX & Use ALTER INDEX

Já faz mais de uma década que a instrução DBCC DBREINDEX foi descontinuado, no entanto, de vez em quando ainda os encontro em alguns clientes. Na semana passada, ao revisar o plano de manutenção de um dos clientes, notamos que eles ainda estão usando a sintaxe mais antiga, em vez de usar a nova sintaxe do ALTER INDEX.

Diga Não ao DBCC DBREINDEX

Microsoft sempre muito clara por anos que, se algum recurso é marcado como obsoleto e o recurso de substituição aparece, é preciso começar a planejar a transição. Realmente não faz sentido continuar usando o recurso que será removido pela equipe do produto nas futuras versões.

No entanto, geralmente recebo um pouco de resistência quando tentamos solicitar aos desenvolvedores ou analistas que usem um novo recurso, em vez do recurso que eles estão usando há muitos anos. Eu entendo totalmente a filosofia de Se não está quebrado, não conserte. 

Mas há muitos motivos para mudar do DBCC DBREINDEX e usar o ALTER INDEX. 
Estas são as três limitações principais do DBCC DBREINDEX.

• Ele não suporta a opção de reconstrução online
• Sem suporte para índices recuperáveis
• Não há suporte para compactação de dados

Não é que ele não suporte apenas as três opções acima, mas muitos outros aprimoramentos desde o lançamento do SQL Server 2008.

Sintaxe do ALTER INDEX

Aqui está a sintaxe do índice ALTER INDEX Rebuilding.

1	ALTER INDEX IndexName ON TableName REBUILD;

É uma sintaxe muito simples. Aqui está outra sintaxe para reorganizar o índice.

1	ALTER INDEX IndexName ON TableName REORGANIZE;

Bem é isso. Esta ainda é a minha pergunta para você - você ainda usa o DBCC DBREINDEX
para recriar seus índices. Existe algum motivo específico para continuar usando o recurso
que foi marcado como obsoleto por tantos anos? Será útil saber o motivo de todos
e podemos compartilhar se você publicar sua resposta como um comentário do blog.

Grande abraços

Referência:  Pinal Dave

SQL SERVER - Opções de energia, planos de energia e desempenho do banco de dados.

     Recentemente acabei por um cenário muito interessante, o servidor de dados estava funcionando perfeitamente por um tempo considerável e não estava enfrentando nenhum problema de desempenho. No entanto, de repente, sem fazer nenhuma alteração, o desempenho do servidor caiu. Eles imediatamente nos acionaram e, começamos sistematicamente a verificar o desempenho do SQL Server e percebemos que eles não tinham problemas de CPU, I/O ou muito menos memória. Além disso, todos os trabalhos de manutenção também estavam funcionando de forma eficiente (jobs noturnos - reindexação - etc). Isso nos levou a finalmente considerar problemas do sistema operacional (Windows Server).

Opções de energia de alto desempenho - Power Option (High performance)

O maior quebra-cabeça à nossa frente era estranho. Tivemos uma query que era executada em 1 segundo e agora leva mais de 8 segundos. Nós também investigamos mais de 10 querys diferentes e descobrimos que todas elas estavam rodando muito lentas.

Como todos os benchmarks de minhas verificações de integridade do SQL Server estavam limpos. Eu decidi olhar para a configuração do Windows. Depois de olhar para o antivírus, abrimos a Opção de Energia para então descobrir que ela foi alterada de Alto Desempenho / Balanceada.

No Windows Server 2008 e superiores, defina o plano de energia " Alto Desempenho " no  Painel de Controle -> Opções de Energia -> OK . Por padrão, o Windows Server define o plano de energia “Equilibrado”, que permite a conservação de energia dimensionando o desempenho do processador com base na utilização atual da CPU.

Se um servidor exigir uma latência ultra baixa, frequência de CPU INvariável ou os níveis de desempenho mais altos, como servidores de banco de dados, talvez não seja útil que os processadores continuem alternando para estados de desempenho inferior (Equilibrado).

Por fim depois que mudamos a opção de energia para o alto desempenho, conseguimos restaurar o desempenho do sistema para um desempenho de referência anterior.

Eu recomendo fortemente que todos que estão executando o SQL Server em servidores gerenciados Windows Server mantenham seu Plano de Energia default como um Plano de "Alto Desempenho" para evitar qualquer degradação de performance não desejada.

Os principais problemas de desempenho no SQL SERVER

Quais foram as causas dos últimos problemas de desempenho de SQL Server, que você enfrentou?

"Como podemos observar, os 2 problemas mais comuns são o código T-SQL e a indexação.
4 dos 6 problemas mais comuns estão todos diretamente relacionados ao T-SQL, índices, código,
e estrutura dos dados. Para obtermos melhorias em desempenho devemos olhar primeiro para área de acesso a dados, incluindo design de banco de dados, design de consulta, e design de índice.

Claro, se considerar a configuração de hardware e atualizações, podemos obter um ganho de desempenho satisfatório. No entanto, uma consulta SQL incorreta enviada pela aplicação pode consumir todos os recursos de hardware disponíveis, não importa o quanto recurso tenha."

Fonte: Grant Fritchey
Grafton, Massachusetts,

SQL Studio Management - Expanding Databases muito lento.

SQL Studio Management - Expanding Databases muito lento.

Em um de nossos clientes durante a implementação, identificamos uma situação atípica,uma performance muito lenta, abaixo do aceitável. Em atividades simples, apenas dentro do SQL Server Studio Management. Notamos que simples ações, como por exemplo de expandir o menu Databases.

Demorou em torno de 2 a 3 minutos, para exibir o nó de Bancos existentes.

Não me lembro exatamente quando começou. Mas eu acho que já fazem vários meses.
Era fácil demais ignorar, já que eu poderia usar o alt-tab e fazer outras atividades enquanto aguardava o atraso.

Hoje decidi pesquisá-lo e concluímos em duas opções:

Opção 1) Ocorre porque alguns bancos têm a opção de auto_close ativado;
Isso faz com que o servidor SQL tenha que inicializar cada banco de dados, antes de poder renderizá-lo no Nó menu de bancos. Isso cria um atraso muito significativo, quando você tem vários bancos de dados configurados para auto_close.

Uma maneira rápida de corrigir todos eles de uma só vez, quando possível ....
É configurar o modo de recuperação para = simple (qualquer coisa mais é inútil no ambiente de desenvolvimento), use este script:

USE MASTER

Declare

    @isql varchar(2000),

    @dbname varchar(64)

    declare c1 cursor for select name from master..sysdatabases where name not in ('master','model','msdb','tempdb')

    open c1

    fetch next from c1 into @dbname

    While @@fetch_status <> -1

        begin

        select @isql = 'ALTER DATABASE @dbname SET AUTO_CLOSE OFF'

        select @isql = replace(@isql,'@dbname',@dbname)

        print @isql

        exec(@isql)

        select @isql = 'ALTER DATABASE @dbname SET RECOVERY SIMPLE'

        select @isql = replace(@isql,'@dbname',@dbname)

        print @isql

        exec(@isql)

        select @isql='USE @dbname checkpoint'

        select @isql = replace(@isql,'@dbname',@dbname)

        print @isql

        exec(@isql)

        fetch next from c1 into @dbname

        end

    close c1

    deallocate c1

Opção 2) Um configuração pré definida, do proprio SQL Studio gerou problemas não apenas em expandir databases. Mas em todas as ações executadas dentro do Management.

No Management Studio, no Menu (Tools)Ferramentas, selecione (Options) Opções e clique em "Designers".  Há uma opção chamada "Override connection string time-out value for table designer updates:"

Valor de tempo limite, da cadeia de conexão para atualizações de designer de tabela:
Transaction time-out after: modifique para 0 seconds

Este segunda opção foi a mais eficiente em diversos clientes, principalmente em ambiente de produção.Quando não é possível modificações em modo de recuperação. Não há relação entre as opções mas foram alternativas funcionais.

Sugestões e explicações mais detalhadas estamos a disposição.
Fontes referencias: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms190181(v=sql.105)

CHECKDB rodando a cada minuto? SQL-Server

Dias atrás eu me deparei com uma pergunta nos fóruns onde o usuário estava recebendo essa mensagem no log de erro do SQL Server a cada minuto.

CHECKDB for database 'DBName' finished without errors on [date and time].
This is an informational message only; no user action is required.

Starting up database 'DBName'

Ele não agendou o CHECKDB para rodar a cada minuto e queria saber o que significa esta mensagem? Uma rápida olhada na mensagem informativa indica claramente que o SQL Server não está reportando os resultados do DBCC CHECKDB . Essa mensagem é relatada no log de erros sempre que um banco de dados é iniciado. Este é um recurso adicionado no antigo SQL Server 2005 em diante. Na terceira linha na mensagem acima confirma que o banco de dados está realmente iniciando a cada minuto.

Por que o banco de dados é iniciado a cada minuto?

Isso ocorre porque a propriedade AutoClose para esse banco de dados é definida como True .

Com essa propriedade definida como True , quando a última conexão do usuário é desconectada, o banco de dados é fechado. Quando um usuário se conecta de volta ao banco de dados, o banco de dados é iniciado novamente e a mensagem informativa é registrada no Log de Erros do SQL Server. Quando um banco de dados é inicializado, os recursos são atribuídos a ele e, quando ele é fechado, os recursos são liberados. A opção AutoClose é útil em um banco de dados que não é usado com frequência, como em um banco de dados em execução no SQL Server Express Edition. Mas se essa propriedade estiver configurada como True em um banco de dados OLTP ocupado, isso terá um impacto negativo no desempenho da instância.

Até mesmo eu encontrei alguns bancos de dados no ambiente do meu cliente onde a propriedade AutoClose estava definida como True . Como esses bancos de dados eram pequenos em tamanho e não tinham muita importância, não houve impacto. Essa propriedade pode ser desativada usando o diálogo Propriedades do Banco de Dados no SSMS ou usando a consulta a seguir.

ALTER DATABASE [DBName] SET AUTO_CLOSE OFF

SQL SERVER (SP_WHO2) - Entenda a diferença entre status Running, Pending, Runnable, Suspended, Sleeping ...

SQL SERVER  (SP_WHO2) - Entenda a diferença entre status, pendente, executável, suspenso, suspenso.

Uma das perguntas mais populares que recebo durante o dia-a-dia no cotidiano, principalmente dos desenvolvedores é, qual a diferença entre os status em sp_who2. Hoje vamos entendê-los e detalhar no que diz respeito à CPU e I/O.

Primeiro, vamos ver a definição:

Em Execução (Running) - A sessão com este status está realmente executando os batches e consumindo os ciclos da CPU. 

Runnable - A sessão com este status é, na verdade, atribuída a um thread, mas espera que o ciclo da CPU esteja disponível. 

Pendente (Pending)  - A sessão com este status ainda não foi atribuída a um threads e está aguardando a disponibilidade dos threads. 

Suspenso (Suspended)  - A sessão com esse status geralmente está aguardando a disponibilidade dos recursos. Eu já vi isso com mais conclusão de operação de E / S sobre problemas de CPU. 

Dormir (Sleeping) - A sessão com esse status não está realmente fazendo nada. Muitas vezes vejo esse status quando todas as tarefas relacionadas aos threads são concluídas, mas a conexão ainda está aberta. (Você pode abrir uma nova conexão no SQL Server Management Studio e não executar nada lá. Em seguida, verifique o status do SPID e você notará que o status está em Suspensão). Então, desta vez, quando você executar sp_who2, você saberá rapidamente o que cada thread significa.

Então, da próxima vez, quando executar sp_who2, saberá rapidamente o que cada thread significa.

Confira as últimas atualizações disponíveis para cada versão do SQL Server

Últimas atualizações disponíveis para as versões atualmente suportadas do SQL Server.

Observação

Agora a versão prévia do SQL Server 2019 está disponível. Para obter mais informações, consulte Novidades no SQL Server 2019.

Versão	Pacote de serviços mais recente	acumulativas

SQL Server 2017	None	CU13 para 2017(14.0.3048.4 – dezembro de 2018)	Compilações de SQL Server 2017
SQL Server 2016	SQL Server 2016 SP2 (13.0.5026.0 – abril de 2018)	CU5 para 2016 SP2(13.0.5264.1 – janeiro de 2019) CU13 para 2016 SP1(13.0.4550.1 – janeiro de 2019) CU9 para 2016 RTM (13.0.2216.0 – novembro de 2017)	Compilações de SQL Server 2016
SQL Server 2014	SQL Server 2014 SP3 (12.0.6024.0 – outubro de 2018)	CU2 de 2014 SP3(12.0.6214.1– fevereiro de 2019) CU16 de 2014 SP2 (12.0.5626.1– fevereiro 2019) CU13 de 2014 SP1 (12.0.4522.0 – agosto de 2017)	Compilações de SQL Server 2014
SQL Server 2012	SQL Server 2012 SP4(11.0.7001.0 – setembro de 2017)	CU10 para SP3 2012 (11.0.6607.3 – agosto de 2017) CU16 para o SP2 de 2012 (11.0.5678.0 – janeiro de 2017) CU16 de 2012 SP1(11.0.3487.0 - maio de 2015)	Compilações de SQL Server 2012
SQL Server 2008 R2	SP3 do SQL Server 2008 R2(10.50.6000.34 – setembro de 2014)Observação: Versão final e mais recente para esta versão	None	Compilações do SQL Server 2008 R2
SQL Server 2008	SQL Server 2008 SP4(10.0.6000.29 – setembro de 2014)Observação: Versão final e mais recente para esta versão	None	Compilações do SQL Server 2008
SQL Server 2005	SQL Server 2005 SP4(9.00.5000.00 – dezembro de 2010)	None	Compilações de SQL Server 2005