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

SELECT DB_NAME (ddlsu.databasejd)
AS DatabaseName, databasejd,
CAST ((ddlsu.total_log_sizeJn_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. Результат выполнения моих запросов с плохой производительностью показан на рисунке ниже.


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

Можно привести множество примеров, иллюстрирующих типы мониторинга, которые стали доступными после обновления vl2. Так, до выпуска vl2 чтобы определить, входит ли 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.cpuJicks/CONVERT (FLOAT, (dosi.cpujicks /dosi.msjicks)))
— 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/
Total VirtualAddressSpace) [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, чтобы выяснить, возникнут ли проблемы с памятью.

Как вы уже поняли, типов подобного мониторинга может быть множество, а следовательно используется он повсеместно во всех сферах, так или иначе связанных с электронными базами данных. К примеру, вы можете купить сканер штрихкодов (http://sb-sale.ru/catalog/scanner/) и опробовать функционал Azure SQL Database, что называется, на практике. Дело в том, что принцип работы большинства устройств данного типа напрямую связан с обращением к базам данных товаров, которые хранятся на облачных серверах, самым популярным среди которых как раз таки и является SQL Azure.

---

Читать дальше...