Пара вопросов:
а) есть 2 таблицы и 1 процедура, работающая с ними
б) таблицы я конвертнул в In-Memory Optimized Tables, процедуры остались почти нетронутыми.

Этого достаточно? или надо конвертнуть процедуру в Native compiled?

ясно, т.е. можно, желательно, но не обязательно.

Я проверил свою процедуру, там до фига не поддерживаемых моментов для Native Compiled.

Начал переделывать процедуру в Native Compiled и нарвался на такое:

там чтение из обычной таблицы Т, чем заменить?
При этом таблицу менять в memory_optimized пока не получится.

делаю wrapper так:

обычная процедура
читаю данные из обычной таблицы, передаю в параметрах
->NC процедура
->работа с таблицами MEMORY_OPTIMIZED

Так срабатывает.

Чем заменить вызов на первый взгляд безобидной REPLACE?




авторMsg 10794, Level 16, State 93, Procedure usp_2, Line 101 [Batch Start Line 108]
The function 'replace' is not supported with natively compiled modules.

т.е. внутри строки где-то может быть :dobedo:, его надо заменить на :bedobe:

вот, да, крутил-мутил, но придется выносить во враппер

Еще вот вопрос.
Какое значение ставить в BUCKET_COUNT? Что именно это означает?

спасибо! но, видимо, там д.б. "ideally be close to [Х – 2X] " исходя из примера?

Вы правы в целом, но:
хэш-индекс - один из двух доступных для memory optimized tables, так что у меня вариантов нет.
Да, практически существующую, но тоже - существующую структуру, я хочу перевести несколько таблиц и процедур, которые "просятся". А остальные, которые будут в работе большими - и хотел бы, но не вижу вариантов.
Например, есть таблица с несложной структурой, которую можно было бы перевести в мемори оптимизнутые, но там два этажа подчинений:
Т1(мастер)->10 T1N (details)->5 T11M (details)

Так что пока ограничиваюсь малым: парой таблиц и парой процедур.

Еще такой вопрос:
расцепил таблицы TMaster->TDetails
Сделал TDetails MemoryOptimized, а TMaster осталась дисковой .
При попытке вернуть Foreign Key пишет ошибку

авторMsg 10778, Level 16, State 0, Line 41
Foreign key relationships between memory optimized tables and non-memory optimized tables are not supported.
Msg 1750, Level 16, State 1, Line 41
Could not create constraint or index. See previous errors.


Вопрос: как сцепить?

ясно, но, если я конвертирую часть таблиц, то когда-то надо решать.
Может руками, типа триггер прикрутить? если он сработает, конечно.
Т.е. получается, что все эти делете каскаде и т.д. тоже накрываются? как с ними быть в случае дисковой и инмемори таблицы?

понял, но я же не одинок в этом безумном мире, как-то же люди моделируют свяь в таких случаях?
или оставляют свободно болтаться после конвертации да и х.с.н.?

Дальше, есть у меня в триггере, который я делаю NC такая фигня

UPDATE dbo.names SET [hname] = CHECKSUM(idname) where [id] =@Id

Но CHECKSUM не поддерживается.
Куда бежать? Чем заменить?

Вы правы, но "должно быть быстрее" - и это тоже одна из объявленных целей.
Я хочу практически проделать то, о чем было заявлено майкрософтом.
Они, кстати, не ограничивали применение In-memory. В частности, если юзер хочет перевести часть таблиц-процедур-триггеров на In-memory - это допустимо и нормально. Ограничений нет, но есть ограничения на саму технологию, с чем я и борюсь в своих экспериментах

Кстати, вот нашел

авторThe In-Memory OLTP Engine is fully integrated in the SQL Server Database Engine.
You do not need to perform complex system refactoring, splitting data between
in-memory and conventional database servers or moving all of the data from the
database into memory. You can separate in-memory and disk data on a table-by-table
basis, which allows you to move active operational data into memory, keeping other
tables and historical data on disk. In some cases, that migration can even be done
transparently to client applications.


Так что - все ок, идем дальше