Тёмная сторона SQL Server In-Memory OLTP

[Tzimie]

Ого. Весьма нетривиально.

[somurzakov]

что-то даже расхотелось вообще использовать эти таблицы после прочитанного, лучше уж сразу редис/мемскл какой-нибудь, да даже sqlite в памяти получше будет

[unfilled]

Ну, целью поста было предупредить тех, кто планирует использовать In-Memory OLTP, или использует, но ещё не столкнулся с описанным, а не сказать, что технология фуфло и использовать её не стоит. Те или иные проблемы будут с любым решением.

[AlanDenton]

Спасибо за пост. Реально полезно. Никогда не доводилось In-Memory с FULL моделью восстановления использовать, а то что на SIMPLE было так сильно не приводило к росту In-Memory файловой группы, но ее легко не фринкнуть и это большая проблема.

И докину еще одну проблему с которой столкнулся давно (сейчас не знаю исправили или нет, но было до 2016 SP2) когда таблица In-Memory обернута в Native Compile хранимку то если нет плана выполенения… план генерируется но сам запрос падает по ошибке. Повторный запрос выполняется корректно потому что план уже в кеше. И когда памяти не хватало было весьма занимательно разбираться почему отваливались транзакции в рамках таких вот конструкций.

[unfilled]

Спасибо!

[wickedru]

А вы проверяли размер файлов относящихся к этой базе с помощью, прошу прощения, файлового менеджера? Если мне не изменяет память Filestream это просто pipeline для данных, которые могут храниться как на диске так и в памяти (In-Memory OLTP).

[unfilled]

А вы проверяли размер файлов относящихся к этой базе с помощью, прошу прощения, файлового менеджера?

На диске занимает столько же, сколько я получаю запросом к sys.database_flies. Воспроизвести эту ситуацию и посмотреть размер на диске с помощью вашего любимого файлового менеджера вы можете минуты за 3 с использованием скриптов в посте.

[wickedru]

В файловом менеджере я как раз вижу файл размером 4КБ. В sys.database_files для файлстрима отображается:

For FILESTREAM filegroup containers, size reflects the current used size of the container.

[unfilled]

ну можно же взять скрипты целиком и проверить

[wickedru]

Из вашего поста использовал часть t-sql скриптов. Файлы нашел, признаюсь честно, просто не достаточно глубоко копнул. Спасибо и извините за беспокойство.

[4eS]

Причём, если у вас больше 16 ГБ ОЗУ — файлы будут по 128 МБ, если меньше (как у меня сейчас) — по 16 МБ. Ну а в каких-то случаях, начиная с SQL Server 2016, могут использоваться «large checkpoint» по 1 ГБ!

Это, кстати, занятная штука очень.
Столкнулись с ней, когда с небольшого prod-сервера база уезжала по log shipping на сервер со всякой аналитикой.
И вот на prod у нас скромный каталог с этими файлами по 16Мб. А на сервере аналитики (где памяти в избытке было) эти же самые файлы превращаются в элегантные шорты в пачку по 128Мб.

И второй момент с In-Memory и log shipping'ом.
На получателе recovery баз увеличился очень значительно. При этом в логе видно, что сам файл trn поднимается быстро, а recovery базы потом длится по 30-40 минут.
Какого-либо воркэраунда не нашли и пришлось страдать. Есть подозрение, что это связано всё с теми же файлами.

[unfilled]

Мы хотим попробовать выкинуть in-memory таблицу в отдельную бд на том же сервере, где вообще нет не-inmemory таблиц. В основной базе таблицу грохнуть и создать под её именем синоним, который будет смотреть на таблицу в новой бд. Если получится, такую базу и в ag можно будет включить, чтобы вместе ездили в случае файловера.