Поделиться через

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

  • Статья

Применимо к: База данных SQL Azure

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

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

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

OlTP в памяти поддерживается, если результатом следующего запроса является 1 (не 0):

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

XTP обозначает крайнюю обработку транзакций, которая является неофициальным именем функции OLTP в памяти.

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

СРЕДА SQL Server Management Studio (SSMS) включает отчет об анализе производительности транзакций, который можно запустить в базе данных с активной рабочей нагрузкой. В отчете определены таблицы и хранимые процедуры, которые подходят для миграции в компонент In-Memory OLTP.

Чтобы создать отчет в SSMS, выполните следующие действия.

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

Дополнительные сведения об оценке преимуществ OLTP в памяти см. в разделе "Определение необходимости переноса таблицы или хранимой процедуры в память OLTP".

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

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

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

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

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

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

    ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

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

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

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

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

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

  2. В обозреватель объектов щелкните таблицу правой кнопкой мыши и выберите помощник по оптимизации памяти.

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

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

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

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

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

  1. Подключитесь к тестовой базе данных с помощью SSMS.
  2. Получите полный скрипт T-SQL для таблицы и его ограничений и индексов.
    • В среде SSMS щелкните правой кнопкой мыши узел таблицы.
    • Выберите таблицу скриптов как>CREATE в>новом окне запроса.
  3. В окне скрипта добавьте WITH (MEMORY_OPTIMIZED = ON) инструкцию CREATE TABLE . Дополнительные сведения см. в разделе Синтаксис оптимизированных для памяти таблиц.
  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 (необязательный). Миграция хранимых процедур

OLTP в памяти также поддерживает скомпилированные в собственном коде хранимые процедуры, которые могут повысить производительность T-SQL.

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

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

  • NATIVE_COMPILATION. Это означает, что инструкции Transact-SQL в процедуре компилируются в машинный код для эффективного выполнения.
  • SCHEMABINDING: это означает, что таблицы, на которые ссылается хранимая процедура, не могут изменяться в любом случае, если хранимая процедура не будет удалена.

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

Пример скомпилированной хранимой процедуры в собственном коде

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

CREATE PROCEDURE schemaname.procedurename
    @param1 type1, ...
    WITH NATIVE_COMPILATION, SCHEMABINDING
    AS
        BEGIN ATOMIC WITH
            (
            TRANSACTION ISOLATION LEVEL = SNAPSHOT,
            LANGUAGE = N'<desired sys.syslanuages.sysname value>'
            )
        ...
        END;
  • Для этого TRANSACTION_ISOLATION_LEVELSNAPSHOT является наиболее распространенным значением для скомпилированных в собственном коде хранимых процедур. Однако также поддерживается подмножество других значений:
    • REPEATABLE READ
    • SERIALIZABLE
  • Значение LANGUAGE должно присутствовать в представлении sys.syslanguages в столбце name . Например, N'us_english'.

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

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

  1. CREATE PROCEDURE Получите скрипт для обычной (интерпретируемой) хранимой процедуры.
  2. Перезапишите ее заголовок в соответствии с предыдущим шаблоном.
  3. Определите, использует ли код T-SQL хранимую процедуру любые функции, которые не поддерживаются для скомпилированных в собственном коде хранимых процедур. При необходимости устраните эту проблему. Дополнительные сведения см. в разделе "Проблемы миграции" для скомпилированных в собственном коде хранимых процедур.
  4. Переименуйте старую хранимую процедуру с помощью sp_rename или удалите ее.
  5. Выполните измененный CREATE PROCEDURE скрипт T-SQL.

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

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

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

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

Чтобы настроить и запустить тестовую рабочую нагрузку, рассмотрите возможность использования ostress.exe средства из группы служебных программ RML. Дополнительные сведения см. в примере в памяти в База данных SQL Azure.

Чтобы свести к минимуму задержку в сети, запустите ostress.exe в том же регионе Azure, что и база данных.

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

Рассмотрите возможность мониторинга влияния производительности реализации OLTP в памяти в рабочей среде:

Связанный контент