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

  • Статья

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

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

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

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

OlTP в памяти поддерживается только на уровне "Премиум" (DTU) и критически важный для бизнеса (vCore) База данных SQL Azure. В памяти OLTP поддерживается, если возвращенный результат имеет значение 1 (не 0):

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

XTP обозначает обработку экстремальных транзакций.

Шаг 2. Определение объектов для миграции в память OLTP

СРЕДА SQL Server Management Studio (SSMS) включает отчет об анализе производительности транзакций, который можно запустить в базе данных с активной рабочей нагрузкой. Отчет определяет таблицы и хранимые процедуры, которые являются кандидатами для миграции в память 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 (необязательный). Миграция хранимых процедур

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

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

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

  • NATIVE_COMPILATION. Это означает, что инструкции Transact-SQL в процедуре компилируются в машинный код для эффективного выполнения.
  • 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'<desired sys.syslanuages.sysname value>'
            )
        ...
        END;
  • Для этого TRANSACTION_ISOLATION_LEVELмоментальный снимок является наиболее распространенным значением для скомпилированной хранимой процедуры, скомпилированной в собственном коде. Однако также поддерживается подмножество других значений:
    • REPEATABLE READ
    • SERIALIZABLE
  • Значение LANGUAGE должно присутствовать в представлении sys.syslanguages в столбце name . Например, N'us_english'.

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

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

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

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

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

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

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

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

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

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

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

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