Мониторинг хранилища OLTP в памяти в База данных SQL Azure
Применимо к: База данных SQL Azure
При использовании OLTP в памяти данные в таблицах, оптимизированных для памяти, и переменные таблицы находятся в хранилище OLTP в памяти, которое является частью памяти базы данных, отложенной для данных в памяти.
- Базы данных и эластичные пулы в уровнях служб Premium (DTU) и критически важный для бизнеса (vCore) поддерживают OLTP в памяти.
- Уровень служб Гипермасштабирования поддерживает подмножество объектов OLTP в памяти, но не включает оптимизированные для памяти таблицы. Дополнительные сведения см. в разделе об ограничениях гипермасштабирования.
Как определить, соответствует ли объем данных ограничениям хранилища выполняющейся в памяти OLTP
Определите ограничения хранилища различных целей службы. Каждая цель службы "Премиум" и критически важный для бизнеса имеет максимальный размер хранилища OLTP в памяти.
- Ограничения ресурсов для отдельной базы данных на основе DTU
- Ограничения ресурсов для эластичных пулов на основе DTU
- Ограничения ресурсов для отдельной базы данных при использовании модели на основе виртуальных ядер
- Ограничения ресурсов для эластичных пулов при использовании модели на основе виртуальных ядер
Оценка требований к памяти для таблицы, оптимизированной для памяти, выполняется одинаково как на сервере SQL Server, так и в Базе данных SQL Azure. Проверьте требования к памяти.
Строки табличных и табличных переменных, а также индексы, подсчитывают в сторону крышки. Кроме того, ALTER TABLE
для создания новой версии всей таблицы и его индексов требуется достаточно памяти.
После достижения ограничения операции вставки и обновления могут начаться сбоем. На этом этапе необходимо либо удалить данные для освобождения памяти, либо увеличить масштаб цели службы базы данных или эластичного пула. Дополнительные сведения см. в статье "Исправление ситуаций хранения OLTP в памяти" — ошибки 41823 и 41840.
Мониторинг и оповещение
Вы можете отслеживать использование в памяти OLTP-хранилища в процентах от ограничения хранилища для цели службы в портал Azure:
- На странице обзора базы данных SQL выберите диаграмму на странице мониторинга. Или в меню навигации найдите "Мониторинг" и выберите "Метрики".
- Выберите Добавить метрику.
- В разделе "Базовый" выберите процент хранилища OLTP в памяти.
- Чтобы добавить оповещение, выберите поле "Использование ресурсов", чтобы открыть страницу метрик, а затем выберите новое правило генерации оповещений. Следуйте инструкциям по созданию правила генерации оповещений метрик.
Кроме того, используйте следующий запрос, чтобы отобразить использование хранилища в памяти:
SELECT xtp_storage_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;
Устранение ошибок вне памяти с помощью OLTP в памяти
Достижение ограничения хранилища OLTP в памяти в базе данных или эластичном пуле может привести к INSERT
UPDATE
ALTER
CREATE
сбою инструкций с ошибкой 41823 (для отдельных баз данных) или ошибкой 41840 (для эластичных пулов). Обе ошибки приводят к прерыванию активной транзакции.
Ошибки 41823 и 41840 указывают на то, что размер оптимизированных для памяти таблиц и переменных таблицы в базе данных или эластичном пуле достиг максимального размера хранилища OLTP в памяти.
Чтобы устранить эти ошибки, выполните следующие действия:
- Удалите данные из таблиц, оптимизированных для памяти. Это позволит разгрузить данные с помощью традиционных дисковых таблиц.
- Обновите цель службы до одного с достаточным объемом хранилища OLTP в памяти для данных, которые необходимо сохранить в оптимизированных для памяти таблицах и переменных таблиц.
Примечание.
В редких случаях ошибки 41823 и 41840 могут оказаться временными, то есть имеется достаточный объем хранилища выполняющейся в памяти OLTP, и повторное выполнение операции завершается успешно. Поэтому рекомендуется отслеживать общий доступный объем хранилища выполняющейся в памяти OLTP и повторять операцию при первом возникновении ошибки 41823 или 41840. Дополнительные сведения о логике повтора см. в разделе Обнаружение конфликтов и логика повторных попыток.
Отслеживание с помощью динамических административных представлений
Отслеживая потребление памяти упреждающим образом, вы можете определить, как растет потребление памяти и сколько головного помещения вы оставили в сторону ограничений ресурсов. Определите, сколько памяти используется объектами в вашей базе данных или экземпляре. Вы можете использовать sys.dm_db_xtp_table_memory_stats или sys.dm_os_memory_clerks динамические административные представления.
Вы можете найти потребление памяти для всех пользовательских таблиц, индексов и системных объектов, запрашивая
sys.dm_db_xtp_table_memory_stats
:SELECT object_name(object_id) AS [Name], * FROM sys.dm_db_xtp_table_memory_stats;
Память, выделенная подсистеме OLTP в памяти, и оптимизированные для памяти объекты управляются так же, как и другие потребители памяти в базе данных. Кликеры памяти учетной записи типа
MEMORYCLERK_XTP
для всей памяти, выделенной подсистеме OLTP в памяти. Используйте следующий запрос, чтобы найти всю память, используемую подсистемой OLTP в памяти, включая память, выделенную для определенных баз данных.-- This DMV accounts for all memory used by the In-Memory OLTP engine SELECT [type], [name] , memory_node_id , pages_kb/1024. AS pages_MB FROM sys.dm_os_memory_clerks WHERE [type] LIKE '%xtp%';
type name memory_node_id pages_MB -------------------- ---------- -------------- -------------------- MEMORYCLERK_XTP Default 0 18 MEMORYCLERK_XTP DB_ID_5 0 1358 MEMORYCLERK_XTP Default 64 0
Дополнительные сведения об ошибках в памяти можно получить в База данных SQL Azure с помощью динамического представления управления sys.dm_os_out_of_memory_events. Например:
SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;