SQL Server 2014 представил функцию In-Memory OLTP, которая предлагает значительное улучшение производительности. Однако важно учитывать потенциальные недостатки использования этой функции. Один из аспектов, который нужно оценить, это влияние на время запуска и восстановления экземпляра.

Для проверки этой теории мы можем создать таблицу, которая использует функцию In-Memory OLTP. Перед созданием таблицы нам нужно создать файловую группу для хранения данных In-Memory. После настройки файловой группы мы можем использовать следующий код T-SQL для создания нашей таблицы In-Memory:

CREATE TABLE testtable_inmemory (
    [col1] [int] NOT NULL primary key nonclustered,
    [col2] [int] NULL,
    [col3] [int] NULL,
    [col4] [varchar](50) NULL
) WITH (MEMORY_OPTIMIZED=ON);

Наш тестовый сценарий включает загрузку данных в таблицу и выполнение перезапуска экземпляра. Мы будем выполнять ручной CHECKPOINT перед каждым перезапуском, чтобы убедиться, что все данные записаны в файловую группу filestream, минимизируя время запуска. Мы также сравним результаты с и без CHECKPOINT.

Вот пример кода T-SQL для загрузки данных в таблицу:

DECLARE @val INT
SELECT @val=1
WHILE @val < 2500000
BEGIN  
   INSERT INTO testtable_inmemory (col1, col2, col3, col4) 
       VALUES (@val,@val % 10,@val,'TEST' + CAST(@val AS VARCHAR))
   SELECT @val=@val+1
END
GO

CHECKPOINT
GO

После каждой итерации мы можем проверить журнал ошибок SQL, чтобы узнать, сколько времени занимает запуск базы данных. Журнал будет отображать строку, подобную следующей: “Восстановление завершено для базы данных test (ID базы данных 5) за 1 секунду (анализ 3 мс, восстановление 2 мс, отмена 1833 мс).”

Анализируя результаты, мы можем заметить, что с увеличением размера таблицы увеличивается и время запуска/восстановления. Между размером таблицы и продолжительностью существует почти линейная зависимость. Это указывает на то, что использование функции In-Memory OLTP может повлиять на время, необходимое для запуска базы данных SQL Server.

Давайте проведем аналогичный тест без CHECKPOINT и сравним результаты. Мы начнем с пустой таблицы и загрузим 2 000 000 записей. Вот код T-SQL для этих шагов:

CREATE TABLE testtable_inmemory (
    [col1] [int] NOT NULL primary key nonclustered,
    [col2] [int] NULL,
    [col3] [int] NULL,
    [col4] [varchar](50) NULL
) WITH (MEMORY_OPTIMIZED=ON);

DECLARE @val INT
SELECT @val=1
WHILE @val < 2000000
BEGIN  
   INSERT INTO testtable_inmemory (col1, col2, col3, col4) 
       VALUES (@val,@val % 10,@val,'TEST' + CAST(@val AS VARCHAR))
   SELECT @val=@val+1
END

После выполнения перезапуска экземпляра мы можем сравнить метрики с предыдущим тестом. Мы также включим размер журнала транзакций, так как транзакции таблицы In-Memory все равно используют файл журнала. Мы можем использовать команду DBCC SQLPERF(logspace), чтобы проверить использование журнала транзакций.

Анализируя результаты, мы можем подтвердить, что отсутствие CHECKPOINT приводит к похожим результатам, как и в оригинальном тесте. Это говорит о том, что функция In-Memory OLTP действительно влияет на время запуска/восстановления, даже при работе в режиме простого восстановления.

Важно отметить, что эти результаты были получены на стандартной настольной машине. Если вы используете более производительное оборудование уровня предприятия, ваши цифры могут отличаться. Однако важно учитывать влияние функции In-Memory OLTP на время запуска/восстановления при принятии решения о ее использовании или оставлении исходной структуры таблицы на основе диска.

Понимание потенциальных недостатков функций SQL Server является важным для принятия обоснованных решений относительно их реализации. Оценивая влияние In-Memory OLTP на время запуска/восстановления, вы можете обеспечить оптимальную производительность вашей базы данных во всех сценариях.