Estou tentando migrar várias tabelas muito grandes no meu data warehouse para o novo esquema de partição (o esquema de partição mais antigo era baseado em uma RANGE LEFTfunção que não era dividida regularmente e os dados mais recentes são pesados no último grupo de arquivos) . As tabelas são suficientemente grandes (5 bilhões de linhas, 400 GB de espaço de dados), que estou desconfiado para tentar uma reconstrução de índice clusterizado por medo de espaço de log insuficiente.
Estou tentando carregar a nova tabela executando várias INSERT...(WITH TABLOCK) SELECT...WHERE <check constraint predicate> (OPTION MAXDOP 4)instruções em tabelas de teste idênticas, uma por grupo de arquivos no esquema que mais tarde mudarei para a tabela de substituição. Eu coordeno a execução desse carregamento em massa falso por trabalhos SSA individuais para aproveitar a leitura antecipada/carrossel.
Tudo funciona muito bem nas tabelas relativamente pequenas, com todos os trabalhos sendo executados simultaneamente. No entanto, na primeira tabela grande, a maioria dos trabalhos SSA tem RESOURCE_SEMAPHOREesperas enquanto o trabalho com a primeira partição está em andamento.
Se meu servidor tiver 768 GB de RAM, 24 núcleos (hyperthreaded) e estiver trabalhando em uma tabela de 400 GB, devo ajustar meu MAXDOPpara baixo para liberar mais concessões ou habilitar o governador de recursos para reduzir a concessão máxima para obter mais trabalhos SSA e trabalhar em paralelo?
Eu tentei inicialmente o BULK_LOGGEDmodelo de recuperação, mas fui para SIMPLE. O tamanho da transação ainda é enorme; Gerei mais de 1 TB de log copiando 15 GB (deve ser devido às divisões de página se o conjunto de dados não foi classificado, estou usando compactação de página e estava executando diferente de MAXDOP 1).
Estou trabalhando em um equipamento FTDW (matriz SSD local com taxa de transferência de cerca de 5 GB/s, matriz PureStorage com pico de 11 GB/s), portanto, espero que a latência do disco não seja um problema. Estou escrevendo os trabalhos da SSA com a SMO.
Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)
28 de outubro de 2016 18:17:30
Direitos autorais (c) Microsoft Corporation
Enterprise Edition: licenciamento baseado em núcleo (64 bits)
no Windows Server 2012 R2 Standard 6.3 (Build 9600: )
Se você der uma olhada na minha resposta aqui , menciono uma nova dica de consulta (ish) chamada
MAX_GRANT_PERCENTque você pode usar para controlar ainda mais as concessões de memória no nível da consulta.A documentação está aqui .
Supondo que as consultas estejam no
defaultpool e você não as alterou, agora elas podem solicitar 25% de seus 768 GB de RAM. É muita memória.Você terá que jogar com a redução da porcentagem até encontrar um equilíbrio entre simultaneidade e não derramar para a capacidade de disco.
Espero que isto ajude!