Quando usar sort_in_tempdb ao recriar índices?

Estamos discutindo se devemos usar a opção SORT_IN_TEMPDB para nossas tabelas DW. Meu entendimento é que existem mais gravações ao usar esta opção, embora sejam mais seqüenciais. Como temos uma SAN (que às vezes é notoriamente lenta), portanto, no nosso caso, queremos limitar o número de gravações o máximo possível. Acredito que o tempdb esteja em um LUN separado (conjunto de discos).

Temos bastante espaço em disco em nosso arquivo de dados e em nosso arquivo tempdb. Nesse caso, nos beneficiaríamos do uso de SORT_IN_TEMPDB?

Uma coisa que me impressionou foi este comentário sobre esta resposta

Ao recriar um índice, você precisará do dobro do espaço do índice + 20% para a classificação. Portanto, em geral, para reconstruir todos os índices em seu banco de dados, você só precisa de 120% do seu maior índice em seu banco de dados. Se você usa SORT_IN_TEMPDB, ganha apenas 20%, ainda precisa de 100% adicional no seu arquivo de dados. Além disso, o uso da classificação no tempdb aumenta drasticamente sua carga de E / S, pois, em vez de gravar o índice uma vez no arquivo de dados, agora você o grava uma vez no tempdb e depois no arquivo de dados. Portanto, isso nem sempre é o ideal.

Definitivamente, não queremos aumentar nossa carga de E / S com nossa SAN lenta / possivelmente configurada incorretamente.

Qual seria a melhor maneira de testar isso? Simplesmente reconstruindo a tabela com e sem a opção e registrando os horários?

Edit : Temos 8 arquivos tempdb, cada 15 GB. Temos sinalizadores TF 1117/1118 definidos e o IFI está ativado. Atualmente, fazemos uma mistura de reconstrução com a opção sort_in_tempdb e sem ela.

Obrigado!

SQL Server 2012 Enterprise

SORT_IN_TEMPDBsignifica que o SQL Server usará tempdbpara alocar o espaço temporário em vez de alocar espaço no banco de dados do usuário cujo índice está sendo reconstruído. Isso significa que você precisará de menos espaço livre no banco de dados do usuário durante uma operação de reconstrução do índice e mais espaço livre no tempdb.

Ele oferece uma vantagem melhor quando o tempdb está em um conjunto diferente de discos (LUNs) do banco de dados do usuário.

Da opção SORT_IN_TEMPDB - BOL :

Se a opção SORT_IN_TEMPDB estiver configurada como ON e tempdb estiver em um conjunto separado de discos do grupo de arquivos de destino, durante a primeira fase, as leituras das páginas de dados ocorrerão em um disco diferente das gravações na área de trabalho de classificação no tempdb. Isso significa que as leituras de disco das chaves de dados geralmente continuam mais serialmente no disco, e as gravações no disco tempdb também são geralmente seriais, assim como as gravações para criar o índice final. Mesmo se outros usuários estiverem usando o banco de dados e acessando endereços de disco separados, o padrão geral de leituras e gravações será mais eficiente quando SORT_IN_TEMPDB for especificado do que quando não estiver.

Leia os requisitos de espaço em disco quando SORT_IN_TEMPDB estiver ativado .

SAN lenta / possivelmente configurada incorretamente

Você conhece o ponto de dor. Por que você não trabalha com o administrador da SAN para corrigi-lo? A SAN mal configurada e ou lenta causará todos os tipos de problemas, como lentidão .

Alguns pontos importantes a serem observados:

• Use MAXDOP = 1 ao fazer uma reconstrução de índice online - caso contrário, isso causará um aumento na fragmentação.
• Reorganize / reconstrua de forma inteligente seus índices com base no nível de fragmentação e nos fragmentos de página.
• Leia a experiência do SQLFool com a criação de um índice de 60 GB
• Verifique se você configurou o tempdb corretamente - TF 1117 (CRESCE TODOS OS ARQUIVOS EM UM GRUPO DE ARQUIVO Igualmente) e 1118 (SOMENTE EXTENSÕES COMPLETAS) e tenha mais arquivos de dados tempdb .

Qual seria a melhor maneira de testar isso?

Sim, você deve testá-lo analisando as estatísticas de espera ao recriar o índice com e sem SORT_IN_TEMPDB. Avalie também o tempo de execução e, ao fazer no PROD, faça-o durante uma janela de manutenção ou menos atividades do servidor. Verifique também os dados de leitura / gravação e a latência do log .

Não tenho certeza de que você tenha a inicialização instantânea de arquivos , mas ela será beneficiada ao restaurar, durante o crescimento automático de arquivos de dados e ao criar um novo banco de dados (apenas mencionando a integridade).