Correções para o problema de reconstrução de índice online do SQL Server 2012 e 2014

Soluções para o avesso ao hotfix/CU

• Você pode parar de realizar reconstruções até que haja um novo service pack disponível para sua ramificação (talvez você possa ficar com REORGANIZE por enquanto). Infelizmente, se você estiver em uma empresa "somente service pack", suas opções são muito limitadas:você pode lutar mais para mudar essa política ou pode esperar pelo SQL Server 2012 Service Pack 3 (que pode levar muito tempo ou pode simplesmente nunca vem – veja a FAQ nº 21 aqui) ou SQL Server 2014 Service Pack 1 (que provavelmente não veremos antes de 2015 chegar).
• Você pode definir o max degree of parallelism em toda a instância para 1, no entanto, isso pode ter um efeito negativo no restante de sua carga de trabalho - pense em coisas como DBCC multithread, consultas paralelas em ou entre tabelas particionadas e outras operações em que você pode querer reduzir o paralelismo, mas não eliminá-lo completamente. Além disso, essa configuração não afetará uma reconstrução online com, digamos, um MAXDOP = 8 explícito codificado no comando, pois isso substituirá o sp_configure configuração.
  
• Você pode adicionar o WITH (MAXDOP = 1) opção manualmente para todos os seus comandos de reconstrução. (Observação:você não precisa fazer isso para índices XML, pois eles executam inerentemente single-thread, mas eu apenas aplicaria a todas as reconstruções para consistência e para evitar qualquer lógica condicional desnecessária.)
  
• Você pode definir seus trabalhos de manutenção de índice para serem executados como um login específico e, em seguida, usar o Resource Governor para criar um grupo de carga de trabalho que limite o MAX_DOP desse login para 1, independentemente do que eles estão fazendo. Tenho um exemplo disso no white paper de 2008 que escrevi com Boris Baryshnikov, Using the Resource Governor, na seção intitulada "Limiting Parallelism for Intensive Background Jobs".
  
• Se você estiver usando a solução de manutenção de índice de Ola Hallengren, poderá adicionar o @MaxDop parâmetro para suas chamadas para dbo.IndexOptimize :
  

  EXEC dbo.IndexOptimize
      /* other parameters */
      @MaxDop = 1;

• Se você estiver usando o SQL Sentry Fragmentation Manager, poderá ditar o nível de MAXDOP para usar em Configurações - e você pode fazer isso em toda a empresa, por instância, por banco de dados ou até mesmo por índice individual (neste caso, você provavelmente deseja definir isso por instância, para todas as instâncias sem uma correção disponível):
  
  
  Configurações do Gerenciador de fragmentação para a instância (esquerda) e um índice individual (direita).
  
• Se você estiver usando Planos de Manutenção para suas recompilações de índice, terá que alterá-los para usar Executar Tarefas de Instrução T-SQL e escrever seu ALTER INDEX ... WITH (ONLINE = ON, MAXDOP = 1); comandos manualmente (assim pode mudar para uma solução automatizada). Veja, a tarefa de reconstrução de índice não tem uma propriedade exposta para MAXDOP , embora tenha sido solicitado várias vezes (mais recentemente em 2012, por Alberto Morillo, e já em 2006, por Linchi Shea). E veja todas essas outras propriedades úteis que eles expõem, como AdvSortInTempdb , ObjectTypeSelection e TaskAllowesDatbaseSelection [sic!]:
  
  
  Todas essas opções, mas ainda não há cura para MAXDOP.