Azure sql database v12: приклади нових функцій моніторингу в v12

Відео: Reviewing Azure SQL Database v12

Почнемо з невеликого прикладу. У 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 ASDECIMAL (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_countFROM sys.dm_exec_query_profiles AS deqpCROSS APPLY sys.dm_exec_sql_text (deqp.sql_handle) AS destCROSS APPLY sys.dm_exec_query_plan (deqp.plan_handle) AS deqpl-

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

Відео: How to Import Data from Microsoft Excel to Windows Azure SQL Database - SQL Training Online

При кожному повторному виконанні запиту можна побачити, як змінюються значення 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 RingBufferAS (SELECT CAST (dorb.record AS XML) AS xRecord, dorb.timestampFROM 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, x r.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 `) ASAvailableExtendedVirtualAddressSpace 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, щоб з`ясувати, чи виникнуть проблеми з пам`яттю.

Як ви вже зрозуміли, типів подібного моніторингу може бути безліч, а отже використовується він повсюдно у всіх сферах, так чи інакше пов`язаних з електронними базами даних. Наприклад, ви можете купити сканер штрихкодів (https://sb-sale.ru/catalog/scanner/) і випробувати функціонал Azure SQL Database, що називається, на практиці. Справа в тому, що принцип роботи більшості пристроїв даного типу безпосередньо пов`язаний зі зверненням до баз даних товарів, які зберігаються на хмарних серверах, найпопулярнішим серед яких як раз таки і є SQL Azure.

---