Используйте OLTP в памяти для повышения производительности вашего приложения в Базе данных SQL Azure и Управляемом экземпляре SQL Azure

Область применения:База данных SQL Azure Управляемый экземпляр SQL Azure

Выполняющуюся в памяти OLTP можно использовать для повышения производительности обработки транзакций, приема данных и сценариев, связанных с временными данными, в базах данных уровней "Премиум" и "Критически важный для бизнеса", не повышая ценовую категорию.

Выполните следующие действия, чтобы внедрить выполняющуюся в памяти OLTP в существующую базу данных.

Шаг 1. Проверка того, используется ли база данных нужного уровня ("Премиум"или "Критически важный для бизнеса")

Выполняющаяся в памяти OLTP поддерживается только в базах данных уровней "Премиум"и "Критически важный для бизнеса". In-Memory поддерживается, если полученное значение равно 1 (не 0):

SELECT DatabasePropertyEx(Db_Name(), 'IsXTPSupported');

Сокращение XTP обозначает технологию экстремальной обработки транзакций (Extreme Transaction Processing).

Этап 2. Определение объектов для переноса в In-Memory OLTP

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

Для создания отчета в среде SSMS выполните следующие действия:

  • В обозревателе объектовщелкните узел своей базы данных правой кнопкой мыши.
  • Щелкните Отчеты>Стандартные отчеты>Обзор анализа производительности транзакций.

Дополнительные сведения см. в статье Определение, должна ли таблица или хранимая процедура быть перенесена в выполняющуюся в памяти OLTP.

Шаг 3. Создание сопоставимой тестовой базы данных

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

Вам понадобится тестовая копия рабочей базы данных. У тестовой и рабочей баз данных должен быть один уровень служб.

Чтобы упростить тестирование, настройте тестовую базу данных следующим образом.

  1. Подключитесь к новой тестовой базе данных с помощью SSMS.

  2. Чтобы не использовать параметр WITH (SNAPSHOT) в запросах, настройте параметр базы данных, как показано в следующей инструкции T-SQL:

    ALTER DATABASE CURRENT
     SET
         MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
    

Шаг 4. Миграция таблиц

Вам нужно создать и заполнить копию оптимизированной для памяти таблицы, которую вы тестируете. Ее можно создать с помощью:

  • удобного мастера оптимизации памяти в SSMS;
  • вручную с помощью инструкций T-SQL.

Создание таблицы с помощью мастера оптимизации памяти в SSMS

Чтобы использовать этот параметр миграции, сделайте следующее.

  1. Подключитесь к тестовой базе данных с помощью SSMS.

  2. В обозревателе объектов щелкните правой кнопкой мыши таблицу, а затем выберите пункт Memory Optimization Advisor (Помощник по оптимизации памяти).

    Отобразится мастер Помощник по оптимизации памяти таблицы .

  3. В окне мастера щелкните Проверка переноса (или нажмите кнопку Далее). Так вы узнаете, содержит ли таблица функции, которые не поддерживаются в оптимизированных для памяти таблицах. Дополнительные сведения см. в разделе:

  4. Если в таблице нет неподдерживаемых функций, помощник выполнит фактический перенос схемы и данных автоматически.

Создание таблицы вручную с помощью инструкций T-SQL

Чтобы использовать этот параметр миграции, сделайте следующее.

  1. Подключитесь к тестовой базе данных с помощью SSMS (или аналогичной служебной программы).

  2. Получите полный сценарий T-SQL для таблицы и ее индексов.

    • В среде SSMS щелкните правой кнопкой мыши узел таблицы.
    • Щелкните Создать сценарий для таблицы>Используя CREATE>Новое окно запроса.
  3. В окне сценария добавьте в инструкцию CREATE TABLE параметр WITH (MEMORY_OPTIMIZED = ON).

  4. При необходимости измените для индекса параметр CLUSTERED (Кластеризовано) на NONCLUSTERED (Некластеризовано).

  5. Переименуйте существующую таблицу с помощью инструкции SP_RENAME.

  6. Создайте копию оптимизированной для памяти таблицы, выполнив отредактированный сценарий CREATE TABLE.

  7. Скопируйте данные в оптимизированную для памяти таблицу с помощью инструкции INSERT...SELECT * INTO:

INSERT INTO [<new_memory_optimized_table>]
        SELECT * FROM [<old_disk_based_table>];

Шаг 5 (необязательный). Миграция хранимых процедур

Компонент In-Memory также может изменять хранимую процедуру для повышения производительности.

Общие сведения о скомпилированных в собственном коде хранимых процедурах

Скомпилированная в собственном коде хранимая процедура должна иметь следующие параметры в условии T-SQL:

  • NATIVE_COMPILATION
  • SCHEMABINDING — в таблицах хранимых процедур определения столбцов нельзя изменять, если это может повлиять на хранимую процедуру (исключением является удаление хранимой процедуры).

Собственный модуль должен использовать один большой блок ATOMIC для управления транзакциями. Роли для явной транзакции BEGIN TRANSACTION или ROLLBACK TRANSACTION не существует. Если код обнаруживает нарушение бизнес-правила, он может завершить атомарный блок с помощью инструкции THROW .

Стандартная инструкция CREATE PROCEDURE для создания скомпилированных в собственном коде процедур

Как правило, инструкция T-SQL для создания скомпилированной хранимой процедуры имеет следующий вид:

CREATE PROCEDURE schemaname.procedurename
    @param1 type1, …
    WITH NATIVE_COMPILATION, SCHEMABINDING
    AS
        BEGIN ATOMIC WITH
            (TRANSACTION ISOLATION LEVEL = SNAPSHOT,
            LANGUAGE = N'your_language__see_sys.languages'
            )
        …
        END;
  • Для TRANSACTION_ISOLATION_LEVEL значение SNAPSHOT является наиболее распространенным при создании скомпилированной хранимой процедуры. Однако также поддерживается подмножество других значений:

    • REPEATABLE READ
    • SERIALIZABLE
  • Значение LANGUAGE должно присутствовать в представлении sys.languages.

Миграция хранимой процедуры

Этапы миграции

  1. Получите скрипт CREATE PROCEDURE, чтобы создать интерпретируемую хранимую процедуру.

  2. Перезапишите ее заголовок в соответствии с предыдущим шаблоном.

  3. Убедитесь, используются ли в коде T-SQL хранимой процедуры функции, которые не поддерживаются для скомпилированных хранимых процедур. При необходимости устраните эту проблему.

    Дополнительные сведения см. в статье Проблемы миграции, связанные с хранимыми процедурами, скомпилированными в собственном коде.

  4. С помощью SP_RENAME переименуйте старую хранимую процедуру. Или просто удалите ее с помощью DROP.

  5. Запустите измененный сценарий T-SQL CREATE PROCEDURE.

Шаг 6. Запуск рабочей нагрузки в тестовой среде

Запустите рабочую нагрузку в тестовой базе данных, как если бы это была рабочая нагрузка, запущенная в рабочей базе данных. Вы увидите, насколько выросла производительность таблиц и хранимых процедур при использовании компонента In-Memory.

Основные атрибуты рабочей нагрузки:

  • количество одновременных подключений;
  • отношение количества операций чтения и записи.

Чтобы настроить и запустить тестовую рабочую нагрузку, рассмотрите возможность использования удобного инструмента ostress.exe, который проиллюстрирован в этой статье in-memory.

Чтобы свести к минимуму задержки в сети, выполняйте проверку в географическом регионе Azure, в котором расположена ваша база данных.

Шаг 7. Мониторинг после реализации

Рассмотрите возможность отслеживания влияния, оказываемого компонентом In-Memory в рабочей среде.