Приветствую

Есть такая проблема, при наличии в базе таблиц InMemory (DURABILITY = SCHEMA_ONLY) значительно увеличивается время начального включения базы. Например, база размером в 500 Мб с файловой группой Inmemory (160 пустых таблиц) объемом 30 Мб стартует 11-12 секунд; если дропнуть inmemory таблицы, то практически мгновенно.
Ситуация ухудшается, если на инстансе несколько таких баз и recovery происходит параллельно. До трех баз время старта сервера растёт линейно, начиная с четырех - растёт сразу до десятков минут (на более крупных базах - до часов).

Пока базы не пришли в онлайн, sql server занимает cpu максимально, до 100%. Память свободная при этом есть

флаг -t 9944 не помог, права серверу на volume maintenance tasks тоже

В связи с этим два вопроса:
1. как это лечится?
2. так как базы по одной из offline стартовать можно относительно быстро, есть ли способ после выключения сервера указать ему, чтобы на старте некоторые базы сервер сразу выводил в offline?

Спасибо

invm https://support.microsoft.com/en-us/help/4090789/in-memory-oltp-database-takes-a-long-time-to-recover-in-sql-server
2017 (RTM-CU9)

помогло добавить на виртуалку много ядер, чтоб их стало больше, чем таких баз на инстансе; время старта снова стало примерно как сумма восстановления отдельных баз.
но решение явно не во всех случаях подойдет и не закрыт вопрос с тем, что база с inmemory таблицами сама по себе стартует существенно дольше, чем без них

[quot alexeyvg]Владислав Колосовсервер же должен отгрузить объекты и данные с диска память и скомпилировать процедуры, как я понимаю. Не просто сервис запустить и ждать команд, как с физическими таблицами.Только загрузить объекты и скомпилировать процедуры. Без данных, потому что DURABILITY = SCHEMA_ONLY
[quot]
да, вот именно поэтому и возникают вопросы


a_voroninInMemory любит процессорыно странною любовью.

одним из выходов выглядит запретить серверу поднимать базы параллельно. но такого способа тоже не нашел

alexeyvgНо почему то вторая база стартует медленнее.

Это было признано МС багом, был выпущен фикс, но в данном случае он не подействовал.
Может, в следующем кумулятивном апдэйте его просто не добавили, может, это потерянный фикс?

более того, фиксов по похожим проблемам с разными причинами было несколько
https://support.microsoft.com/en-us/help/4055727/recovering-a-database-with-memory-optimized-tables-takes-a-long-time
https://support.microsoft.com/en-hk/help/4090789/in-memory-oltp-database-takes-a-long-time-to-recover-in-sql-server
https://support.microsoft.com/en-us/help/3171001/fix-slow-database-recovery-in-sql-server-2016-due-to-large-log-when-yo
возможно, есть ещё какой-то не покрытый заплатками случай

alexeyvgShakillВ связи с этим два вопроса:
1. как это лечится?Если это действительно критично для бизнеса, можно дропать таблицы перед перезагрузкой (вручную, или как то автоматизировать), и создавать при старте базы.
Получится хоть как то решить проблему, пока МС будет править баг :-)
если перезагрузка плановая, то это решается выведением баз в оффлайн перед выключением сервера
а вот если с сервером что-то случилось, то выходит, что момент упущен и получаем долгий старт
спасибо за вариант с мастерфайлом, посмотрю, насколько это может быть удобно в использовании