Controlando como a atividade do tempdb é dividida entre as unidades (tempdb em unidades de estado sólido e giratórias)

Estou vendo o seguinte comportamento de E/S do tempdb durante um período de uma hora:

Há uma boa quantidade de E/S de disco gerada por várias cargas de trabalho de DW em execução na máquina, algumas das quais não cabem nos aproximadamente 280 GB de memória alocada para SQL. Um aspecto interessante é que grande parte da E/S está concentrada nas unidades de disco giratórias (E) em vez das unidades de estado sólido (F e G) que lidam com a E/S com muito mais eficiência.

Pré-alocamos 300 GB completos cada (600 GB no total) nas unidades F e G para tempdb (usando 12 arquivos) e pré-alocamos 1,3 TB para tempdb na unidade E (atualmente 1 arquivo). Os dados de E/S acima sugerem que o uso de tempdb é distribuído entre arquivos com base no tamanho atual do arquivo. Não consegui encontrar documentação sobre isso, mas também executei uma consulta como a seguinte para investigar mais a fundo:

-- While running this query, writes to tempdb are distributed to E/F/G drives
-- in proportion to their current size.  This was shown by both
-- sys.dm_io_virtual_file_stats and the space used on the tempdb files before and after
SELECT TOP 100000000 *
INTO #temp
FROM [A_Really_Big_Table]

O comportamento ideal seria que F e G fossem usados ​​exclusivamente, a menos que ambos estivessem cheios, caso em que a unidade de disco giratória deve fornecer espaço tempdb adicional para que cargas de trabalho ocasionais muito grandes possam ser atendidas sem esgotar o espaço tempdb.

Estamos no caminho certo ao observar que o uso do tempdb é distribuído entre os arquivos com base no tamanho atual dos arquivos? Foi um pouco surpreendente ver esse tipo de distribuição em vez de ver um uso igual de cada arquivo (o que provavelmente foi a suposição de quem configurou esse hardware e decidiu alocar apenas um para tempdb no disco giratório).

Com base no comentário de Paul White em resposta a esta pergunta , estamos pensando na seguinte abordagem:

• Reduza os arquivos tempdb no disco giratório. Com base em nosso teste inicial, isso deve mudar a distribuição atual do trabalho mais para as unidades de estado sólido
• Configure os arquivos tempdb de estado sólido para pré-alocar seu espaço (como já fazemos agora)
• Configure os arquivos tempdb do disco giratório para iniciar sem alocação. Certifique-se de que a inicialização instantânea do arquivo esteja ativada. O Tempdb aumentará no disco giratório apenas conforme necessário (o que provavelmente ocorrerá no máximo uma vez por semana).
• Crie um plano de manutenção que reduza os arquivos tempdb no disco giratório após períodos de pico de carga, colocando a distribuição de volta em favor dos arquivos tempdb de estado sólido.

Isso parece razoável? Existem abordagens alternativas ou problemas potenciais a serem considerados? Obviamente, testaremos a abordagem na medida do possível, mas não poderemos fazê-lo em hardware de teste completamente equivalente.