SQL Azure Database является "облачным" сервисом баз данных от Microsoft. SQL Azure предоставляет доступную по Интернет функциональность баз данных как сервис. Основанные на "облачных" технологиям решения баз данных, такие как SQL Azure, могут принести множество преимуществ, включая быстрое развертывание, экономичное масштабирование, высокую доступность и сокращение издержек на управление. Этот документ содержит рекомендации для использования доступных в SQL Azure Dynamic Management Views для целей решения проблем.

 Примечание
Если вы хотите принять участие в написании содержания этой страницы, используйте вкладку Edit (необходимо войти в систему). Если же вы хотите предоставить свой отзыв, напишите либо на e-mail azuredocs@microsoft.com либо напишите комментарий

Производительность

SQL Azure является "облачной" реляционной базой данных с движком SQL Server 2008 в качестве ядра. Dynamic Management Views (DMV) были реализованы в SQL Server 2005 и с тех пор стали весьма мощным инструментом для решения различных проблем на всех уровнях производительности - от состояния системы до дедлоков. Хотя большинство из этих DMV были отключены в первом выпуске SQL Azure, в настоящее время они включены в рамках запланированных обновлений (SUS) для SQL Azure. DMV предоставляют информацию на уровне экземпляра. Поскольку SQL Azure является общей моделью инфраструктуры, DMV должны быть изменены для фильтрации вывода и вывода информации только по мере необходимости. Поэтому на первом этапе DMV были включены.

На локальном SQL Server эти DMV обычно нуждались в разрешении типа VIEW SERVER STATE. В случае SQL Azure введен новый уровень разрешений - VIEW DATABASE STATE.

DMV для транзакций

К DMV для транзакций относятся следующие DMV из январского выпуска:

· sys.dm_tran_active_transactions - возвращает информацию о транзакциях для сервера SQL Azure

· sys.dm_tran_database_transactions - возвращает информацию о транзакциях на уровне пользователя базы данных

· sys.dm_tran_locks - возвращает информацию о текущих активных ресурсах менеджера блокировок. Каждая строка представляет активный в данный момент запрос на блокировку менеджера блокировок. Столбцы набора результатов можно разделить на две основные группы: ресурсы и запросы. Группа ресурсов описывает ресурс, на который делается запрос, запросы же описывают запросы на блокировку.

· sys.dm_tran_session_transactions - возвращает коррелирующую информацию взаимосвязанных транзакций и сессий.

DMV, связанные с выполнением

К DMV для выполнения относятся следующие DMV из январского выпуска:  

· sys.dm_exec_connections - возвращает информацию о подключениях к SQL Azure и подробное описание каждого из них.

· sys.dm_exec_query_plan - возвращает showplan в формате XML для пакета, указанного в дескрипторе плана. План может быть либо сохранен в кэше либо выполняться в данный момент.

· sys.dm_exec_query_statsвозвращает суммарную статистику производительности для кэшированных планов запросов. Представление содержит одну строку для каждого запроса в кэшированном плане, время жизни строк связано с самим планом. При удалении плана из кэша соответствующие строки с представления удаляются.

· sys.dm_exec_requests - возвращает информацию о каждом запросе, выполняющемся в SQL Azure.

· sys.dm_exec_sessions - возвращает по записи на каждую аутентифицированную сессию в SQL Azure.

· sys.dm_exec_sql_text - возвращает текст пакета SQL, идентифицируемый sql_handle. Эта функция, возвращающая табличные значения, заменяет системную функцию fn_get_sql.

· sys.dm_exec_text_query_plan - возвращает в текстовом формате showplan для пакета SQL или конкретного запроса в пакете.План может быть либо сохранен в кэше либо выполняться в данный момент. Эта функция похожа на sys.dm_exec_query_plan (Transact-SQL), но имеет несколько отличий:

· Вывод плана запроса - в текстовом формате.

· Вывод плана запроса не ограничивается в размере.

DMV для баз данных

В январском выпуске был опубликован следующий DMV:

· sys.dm_db_partition_statsвозвращает страницы и количество строк для каждого раздела в текущей базе данных.

Затрагивается только информация, которая непосредственно связана с сервером в диапазоне. Столбцы, которые могли бы вернуть информацию о сервере на уровне экземпляра, в SQL Azure вернут NULL . Так что если у вас есть свои запросы для траблшутинга, которые вы уже используете на локальном SQL Server, то вам не нужно изменять эти запросы для выполнения на SQL Azure. Они могут быть без проблем выполнены в SQL Azure.

Определение непроизводительных запросов

SQL Server генерирует план оптимизированного запроса для всех выполняющихся запросов, что позволяет оптимизиатору SQL Server переиспользовать план запроса при выполнении похожих или тех же запросов для запроса данных. При изменении данных и статистики по этим данным изменяются и планы запросов, становясь неэффективными и устаревшими. Поэтому важно определять подобные запросы и подстраивать их для оптимальной производительности приложения и удобства пользователей. Приведенные выше DMV помогают определить проблемные запросы.
Далее приведены некоторые простые запросы для решения проблем плохой производительности запросов:

Excessive recompiles:

select top 25

sql_text.text,

sql_handle,

plan_generation_num,

execution_count,

dbid,

objectid

from

sys.dm_exec_query_stats a

cross apply sys.dm_exec_sql_text(sql_handle) as sql_text

where

plan_generation_num >1

order by plan_generation_num desc

Планы неэффективных запросов

select

highest_cpu_queries.plan_handle,

highest_cpu_queries.total_worker_time,

q.dbid,

q.objectid,

q.number,

q.encrypted,

q.[text]

from

(select top 50

qs.plan_handle,

qs.total_worker_time

from

sys.dm_exec_query_stats qs

order by qs.total_worker_time desc) as highest_cpu_queries

cross apply sys.dm_exec_sql_text(plan_handle) as q

order by highest_cpu_queries.total_worker_time desc

I/O Bottlenecks:

select top 25

(total_logical_reads/execution_count) as avg_logical_reads,

(total_logical_writes/execution_count) as avg_logical_writes,

(total_physical_reads/execution_count) as avg_phys_reads,

Execution_count,

statement_start_offset as stmt_start_offset,

sql_handle,

plan_handle

from sys.dm_exec_query_stats

order by

(total_logical_reads + total_logical_writes) Desc


Ссылки

Автор оригинальной статьи Dinakar Nethi.