А если сделать файлы темпдб сразу максимального размера и отключить им расширение :-)

Мля... Высказал "Умный мысля", и, через неделю приложился фейсом об тейбл!

На одном из серверов с sql2014 была создана "ассиметричная" tempdb.
Сама tempdb была на RAM-диске, размером 32 ГБ, на физическом сервере 256 Гб ОЗУ, и стоит standard версия. Поэтому под, собственно , MSSQL отдано 80 Гб ("чтобы удовлетворить его потребности на неограниченное время"), а остальная память отдана под приложения и RAMDISK.
Ha рамдиске 4 файла по 8 Гб, с отключенным авторасширением, и 5 файл - "кэтчер", на физическом диске, с начальным размером в 1 Мб, ну, и ненулевым авторасширением.
Подразумевается, что до тех пор, пока в больших файлах на рамдиске есть место, сервер будет работать с ними, а если они вдруг переполнятся - то начнет расширяться кэтчер, и запрос не упадет, а доработает до конца.
Правда, если кэтчер раздуется до размера больше основных файлов - то система начнет работать в основном с ним, и производительность - обвалится.
Для этого к кэтчеру приделан сторожок в виде заббикса.
(Мопед не мой, я такую систему унаследовал от прежнего дба, поэтому с удовольствием выслушаю то, что вы об этом думаете. Но я не трогал, и оно работает).

Я теперь так понимаю, что эту схему на 2016++ я перетащить не смогу?
Оно, конечно радует, что 2019 в стандарте может использовать 128 Гб, но я не уверен, что это меня спасет.