Представления динамического управления в Azure SQL Database v12

С тех пор как в SQL Server 2005 появились представления динамического управления (DMV), в нашем распоряжении оказались удобные инструменты, позволяющие наблюдать работу внутренних механизмов SQL Server с использованием самого распространенного языка, T-SQL. До выпуска Azure SQL Database v12 существовало около 148 представлений динамического управления, которые были в локальной (не «облачной») версии, но отсутствуют в Azure SQL Database. В Azure было реализовано 13 представлений динамического управления, которые отсутствовали в локальном продукте. Одновременно с выпуском v12 в Azure SQL Database было добавлено более 100 DMV, отсутствовавших в предыдущей версии. На момент подготовки данной статьи из-за изменений в Azure в локальной версии SQL Server доступно только 16 уникальных DMV. 14 уникальны для Azure SQL Database v12. Имеется 166 представлений динамического управления в локальной версии SQL Server и 132 в Azure SQL Database (между действительными и уникальными числами существует небольшое расхождение).

Однако главное не количество. Важнее расширенная функциональность Azure SQL Database для сбора информации о базах данных. Давайте посмотрим на представления динамического управления, по-прежнему находящиеся в локальной версии, но не в Azure, и поговорим о данных, просто неприменимых к версии SQL Server для PaaS (платформа как услуга), которую представляет Azure SQL Database. В PaaS отсутствуют зеркалирование и кластеры, так как эти функции выполняются самой платформой. Поэтому отсутствие соответствующих DMV не вызывает проблем.

С точки зрения традиционных запросов большинство необходимых DMV давно существует. Уже много лет назад можно было направлять запросы sys.dm_exec_requests, чтобы увидеть запросы, выполняемые вашей базой данных. Их можно было соединить с sys.dm_exec_sql_text или sys.dm_exec_query_plan для извлечения соответствующей информации из представлений динамического управления в Azure SQL Database. Большинство функций, необходимых для проверки и мониторинга системы, были доступны. Однако теперь наши возможности значительно расширились.

Примеры новых функций мониторинга в v12

Начнем с небольшого примера. В SQL Server важно отслеживать размер транзакций при использовании журнала транзакций. Посмотрим на файл журнала с помощью DMV sys.dm_db_log_space_usage (появившегося в SQL Server 2012) в Azure SQL Database. Выполните следующий код:

SELECT DB_NAME (ddlsu.database_id)
   AS DatabaseName,
database_id,
CAST ((ddlsu.total_log_size_in_bytes/
   1048576.0)
   AS DECIMAL (10, 1))
AS LogSizeMB,
CAST ((ddlsu.used_log_space_in_bytes/
   1048576.0) AS DECIMAL (10, 1))
AS LogSpaceUsedMB,
CAST (ddlsu.used_log_space_in_percent
   AS
   DECIMAL (10, 1)) AS PercentLogSpace
FROM sys.dm_db_log_space_usage AS
   ddlsu;

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

Регулирование может вызвать затруднения внутри Azure SQL Database, если производительность системы невысока. Поэтому необходимо разобраться с длительно исполняемыми запросами. С помощью реализованного в SQL Server 2014 представления dm_exec_query_profiles можно увидеть состояние запроса в плане выполнения. Будет показано число строк, обработанных в операторе, число повторных использований внутреннего цикла (rewind) и сбросов на начало (rebind), которые пришлось выполнить, а также состояние запроса в активном динамическом выполнении. Теперь это возможно и в Azure SQL Database:

SELECT dest.text,
deqpl.query_plan,
deqp.physical_operator_name,
deqp.row_count
FROM sys.dm_exec_query_profiles AS deqp
CROSS APPLY sys.dm_exec_sql_text
   (deqp.sql_handle) AS dest
CROSS APPLY sys.dm_exec_query_plan
   (deqp.plan_handle) AS deqpl;

Для очень коротких транзакций sys.dm_exec_query_profiles не работают столь же успешно или вовсе неприменимы. Захват плана выполнения должен происходить одновременно с выполнением запроса. Данное DMV предназначено для диагностики действительно неудачных запросов, которые выполняются долго и могут регулироваться Azure SQL Database. Результат выполнения моих запросов с плохой производительностью показан на экране 1.

Экран 1. Список запросов с низкой производительностью

При каждом повторном выполнении запроса можно увидеть, как меняются значения row_count в операторах. Но знать особенности работы вовсе не обязательно, важно наличие такой функциональности в Azure SQL Database. Мы добиваемся абсолютного равенства с локальной версией SQL Server на всех типовых задачах и большинстве нетипичных, для которых требуется поддержка DMV.

Можно привести множество примеров, иллюстрирующих типы мониторинга, которые стали доступными после обновления v12. Так, до выпуска v12 чтобы определить, входит ли DMV в состав Azure, достаточно было взглянуть на его имя. Если оно начиналось с sys.dm_os_, то представление наверняка отсутствовало в Azure SQL Database. Сейчас положение изменилось. Теперь их 35, от sys.dm_os_buffer_descriptors до sys.dm_os_workers. В результате мы можем составлять запросы, которые выполняют следующие действия:

WITH RingBuffer
AS (SELECT CAST (dorb.record AS XML)
   AS xRecord,
dorb.timestamp
FROM sys.dm_os_ring_buffers AS dorb
WHERE dorb.ring_buffer_type =
   'RING_BUFFER_RESOURCE_MONITOR'
)
SELECT xr.value
   (' (ResourceMonitor/Notification) [1]',
   'varchar (75)')
AS RmNotification,
xr.value (' (ResourceMonitor/
   IndicatorsProcess) [1]', 'tinyint')
AS IndicatorsProcess,
xr.value (' (ResourceMonitor/
   IndicatorsSystem) [1]', 'tinyint')
AS IndicatorsSystem,
DATEADD (ss,
(-1 * ((dosi.cpu_ticks/CONVERT
   (FLOAT, (dosi.cpu_ticks
/dosi.ms_ticks)))
— rb.timestamp)/1000), GETDATE ()) AS
   RmDateTime,
xr.value (' (MemoryNode/TargetMemory) [1]',
   'bigint')
AS TargetMemory,
xr.value (' (MemoryNode/ReserveMemory)
   [1]', 'bigint')
AS ReserveMemory,
xr.value (' (MemoryNode/CommittedMemory)
   [1]', 'bigint')
AS CommitedMemory,
xr.value (' (MemoryNode/SharedMemory) [1]',
   'bigint')
AS SharedMemory,
xr.value (' (MemoryNode/PagesMemory) [1]',
   'bigint')
AS PagesMemory,
xr.value (' (MemoryRecord/
   MemoryUtilization) [1]', 'bigint')
AS MemoryUtilization,
xr.value (' (MemoryRecord/
   TotalPhysicalMemory) [1]', 'bigint')
AS TotalPhysicalMemory,
xr.value (' (MemoryRecord/
   AvailablePhysicalMemory) [1]', 'bigint')
AS AvailablePhysicalMemory,
xr.value (' (MemoryRecord/TotalPageFile) [1]',
   'bigint')
AS TotalPageFile,
xr.value (' (MemoryRecord/
   AvailablePageFile) [1]', 'bigint')
AS AvailablePageFile,
xr.value (' (MemoryRecord/
   TotalVirtualAddressSpace) [1]', 'bigint')
AS TotalVirtualAddressSpace,
xr.value (' (MemoryRecord/
   AvailableVirtualAddressSpace) [1]',
'bigint') AS AvailableVirtualAddressSpace,
xr.value (' (MemoryRecord/
   AvailableExtendedVirtualAddressSpace)
   [1]',
'bigint') AS
   AvailableExtendedVirtualAddressSpace
FROM RingBuffer AS rb
CROSS APPLY rb.xRecord.nodes ('Record')
   record (xr)
CROSS JOIN sys.dm_os_sys_info AS dosi
ORDER BY RmDateTime DESC;

Теперь мы можем заглянуть в кольцевые буферы внутри Azure, чтобы выяснить, возникнут ли проблемы с памятью.

Уникальные функции мониторинга Azure SQL Database

Здесь речь идет не только о возможности выполнять действия, уже доступные в локальном продукте. Нужно обращать особое внимание на уникальные сведения, необходимые внутри собственно Azure. Например, один из способов понять, какие именно неполадки произошли на сервере, — это обратиться к sys.dm_os_wait_stats. В Azure есть другое DMV, sys.dm_db_wait_stats (база данных PaaS). Вывод показан на экране 2.

Экран 2. Статистика времени ожидания в базе данных PaaS

Однако возникает интересный вопрос. До появления v12 таким образом проводился мониторинг статистики ожидания в Azure. Но теперь имеется sys.dm_os_wait_stats, и непонятно, одинаковы ли они. Я выполнил следующий запрос:

SELECT *
FROM sys.dm_os_wait_stats AS dows
WHERE dows.wait_type =
   'PAGEIOLATCH_SH';
SELECT *
FROM sys.dm_db_wait_stats AS ddws
WHERE ddws.wait_type =
   'PAGEIOLATCH_SH';

Полученные результаты показаны на экране 3.

Экран 3. Сравнение времени ожидания

На самом деле мне неизвестно, почему они разные. Max_wait_time_ms идентичны в обоих представлениях динамического управления. В дальнейшем я постараюсь выяснить причину различия, а пока будем придерживаться sys.dm_db_wait_stats, специфической для Azure.

Еще одна уникальная особенность Azure SQL Database — возможность просто организовывать параметры GeoLocation для баз данных. У вас есть несколько способов обеспечить доступность и защиту данных, не только локально в вашем собственном центре обработки данных, но и на всем земном шаре. Но нужно ли отслеживать все эти действия? Конечно, да. Поэтому вам пригодятся представления динамического управления, такие как sys.dm_operation_stats.

С появлением представлений динамического управления в Azure SQL Database v12 мы получили среду с чрезвычайно мощной функциональностью для мониторинга состояния баз данных, работающих на этой платформе, и наши возможности нисколько не уступают функциям локального продукта. Кроме того, расширился круг задач, решаемых с помощью уникальной функциональности базы данных SQL Azure. Благодаря этим усовершенствованиям устраняются препятствия на пути в новый мир, открывающийся пользователям Azure SQL Database.