it-swarm.com.ru

Как настроить Azure SQL для автоматического перестроения индексов?

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

Как я могу настроить его в Azure SQL DB?

P.S: Я пробовал это раньше, но так как я не мог найти никаких вариантов для этого, я подумал, что, может быть, они делают это автоматически, пока я не прочитал этот пост и попробовал:

SELECT
 DB_NAME() AS DBName
 ,OBJECT_NAME(ps.object_id) AS TableName
 ,i.name AS IndexName
 ,ips.index_type_desc
 ,ips.avg_fragmentation_in_percent
 FROM sys.dm_db_partition_stats ps
 INNER JOIN sys.indexes i
 ON ps.object_id = i.object_id
 AND ps.index_id = i.index_id
 CROSS APPLY sys.dm_db_index_physical_stats(DB_ID(), ps.object_id, ps.index_id, null, 'LIMITED') ips
 ORDER BY ps.object_id, ps.index_id

И узнал, что у меня есть индексы, которые нужно поддерживать  enter image description here

4
Ashkan Sirous

Я укажу, что большинству людей вообще не нужно пересматривать индексы в SQL Azure. Да, индексы B + Tree могут стать фрагментированными, и да, это может привести к некоторой перегрузке пространства и некоторой загрузке ЦП по сравнению с идеально настроенными индексами. Итак, есть несколько сценариев, когда мы работаем с клиентами для перестройки индексов. (Основной сценарий - это когда клиенту может не хватить места, так как дисковое пространство в SQL Azure несколько ограничено из-за текущей архитектуры). Поэтому я призываю вас сделать шаг назад и подумать, что использование модели SQL Server для управления базами данных не является «неправильным», но может стоить или не стоить ваших усилий.

(Если вам в конечном итоге понадобится перестроить индекс, вы можете использовать модели, опубликованные здесь другими авторами, - они обычно являются хорошими моделями для сценариев задач. Обратите внимание, что управляемый экземпляр SQL Azure также поддерживает агент SQL, который вы также можете использовать создавать задания для операций обслуживания сценариев, если вы того пожелаете).

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

  • Ссылка, на которую вы ссылались, взята из публикации 2013 года. Архитектура для SQL Azure была полностью переделана после этой публикации. В частности, аппаратная архитектура перешла от модели, основанной на локальных вращающихся дисках, к модели, основанной на локальных твердотельных накопителях (в большинстве случаев). Таким образом, руководство в оригинальном посте устарело.
  • В текущей архитектуре могут быть случаи, когда вам не хватает места с фрагментированным индексом. У вас есть возможность перестроить индекс или на некоторое время перейти к большему размеру резервирования (что будет стоить больше денег), что поддерживает выделение большего дискового пространства. [Поскольку локальное пространство SSD на машинах ограничено, размеры резервирования примерно связаны с пропорциями машины. Поскольку мы получаем более новое оборудование с более крупными/большими дисками, у вас появляется больше возможностей для масштабирования].
  • Влияние фрагментации SSD относительно низкое по сравнению с вращающимися дисками, поскольку стоимость случайного IO на самом деле не выше, чем последовательного. Затраты CPU на обход нескольких промежуточных страниц B + Tree скромны. Я обычно видел максимальные накладные расходы, возможно, 5-20% максимум в среднем случае (что может или не может оправдать регулярные перестройки, которые оказывают гораздо большее влияние на рабочую нагрузку при перестроении)
  • Если вы используете хранилище запросов (которое по умолчанию включено в SQL Azure), вы можете оценить, помогает ли конкретное перестроение индекса заметно повысить производительность. Вы можете сделать это в качестве теста, чтобы увидеть, улучшается ли ваша рабочая нагрузка, прежде чем потратить время на самостоятельную сборку и управление операциями перестроения индекса.
  • Обратите внимание, что в настоящее время в SQL Azure отсутствует управление ресурсами внутри базы данных для пользовательских рабочих нагрузок. Таким образом, если вы начнете перестроение индекса, вы можете в итоге потреблять много ресурсов и влиять на вашу основную рабочую нагрузку. Конечно, вы можете попытаться рассчитать время, которое нужно выполнить в нерабочее время, но для приложений с большим количеством клиентов по всему миру это может оказаться невозможным.
  • Кроме того, я отмечу, что у многих клиентов есть задания по перестроению индекса «потому что они хотят, чтобы статистика обновлялась». Нет необходимости перестраивать индекс только для перестройки статистики. В последних версиях SQL Server и SQL Azure алгоритм обновления статистики стал более агрессивным для больших таблиц, а модель оценки количества элементов в тех случаях, когда клиенты запрашивают недавно вставленные данные (с момента последнего обновления статистики), была изменена в более поздней совместимости. уровни. Таким образом, часто бывает так, что клиенту даже не нужно вообще обновлять статистику вручную.Наконец, я отмечу, что исторически сложившееся влияние статистики было на то, что вы получите регрессию выбора плана. Для повторных запросов значительная часть этого влияния была смягчена введением функции автоматической настройки над хранилищем запросов (которое вызывает предварительные планы, если оно замечает значительный регресс в производительности запросов по сравнению с предыдущим планом).
  • Официальная рекомендация, которую я даю клиентам, - не беспокоиться о перестройках индекса, если у них нет приложения уровня 1, в котором они продемонстрировали реальную потребность (выгоды перевешивают затраты) или если они являются SaaS независимым разработчиком ПО, где они пытаются настроить рабочую нагрузку на многие базы данных/клиентов в эластичных пулах или в мультитенантной структуре базы данных, чтобы они могли уменьшить свои COGS или избежать нехватки дискового пространства (как упоминалось ранее) в очень большой базе данных. В крупнейших клиентах, которые у нас есть на платформе, мы иногда видим ценность в том, чтобы выполнять операции индексации вручную с клиентом, но нам часто не нужно иметь постоянную работу, когда мы выполняем такую ​​операцию «на всякий случай». , Цель команды SQL заключается в том, что вам вообще не нужно об этом беспокоиться, вместо этого вы можете просто сосредоточиться на своем приложении. Конечно, всегда есть вещи, которые мы можем добавить или усовершенствовать в наших автоматических механизмах, поэтому я полностью допускаю возможность того, что отдельная база данных клиентов может нуждаться в таких действиях. Я не видел никого, кроме упомянутых мной случаев, и даже они редко являются проблемой. 

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

Удачи - независимо от вашего результата, надеюсь, это поможет вам сделать правильный выбор.

С уважением, Конор Каннингем Архитектор, SQL.

Sincerely,Conor CunninghamArchitect, SQL

7
Conor Cunningham MSFT

Вы можете использовать Azure Automation для планирования задач обслуживания индексов, как описано здесь: Восстановление индексов базы данных SQL с помощью Azure Automation

Ниже приведены шаги:

1) Создайте учетную запись автоматизации, если у вас ее нет, перейдя по адресу https://portal.Azure.com и выберите «Создать»> «Управление»> «Учетная запись автоматизации». 

 enter image description here

2) После создания учетной записи Automation откройте детали и нажмите Runbooks> Browse Gallery

 enter image description here

Введите в поле поиска слово «индексы» и запустите «Таблицы индексов в базе данных Azure, если они имеют высокую степень фрагментации»:

 enter image description here

4) Обратите внимание, что автором книги Runbook является SC команда разработчиков продуктов автоматизации в Microsoft. Нажмите на Импорт:

 enter image description here

5) После импорта книги запусков теперь давайте добавим учетные данные базы данных в ресурсы. Нажмите Активы> Учетные данные, а затем нажмите кнопку «Добавить учетные данные…» .  enter image description here

6) Установите учетные данные (которые будут использоваться позже в модуле запусков), имя пользователя базы данных и пароль:

 enter image description here

7) Теперь снова нажмите Runbooks, затем выберите «Update-SQLIndexRunbook» из списка и нажмите кнопку «Edit…». Вы сможете увидеть скрипт PowerShell, который будет выполнен: 

 enter image description here

8) Если вы хотите протестировать скрипт, просто нажмите кнопку «Тестовая панель», и откроется окно теста. Введите необходимые параметры и нажмите «Пуск», чтобы выполнить перестройку индекса. Если возникает какая-либо ошибка, она регистрируется в окне результатов. Обратите внимание, что в зависимости от базы данных и других параметров, это может занять много времени:

 enter image description here

9) Теперь вернитесь в редактор и нажмите кнопку «Опубликовать», чтобы включить Runbook. Если мы нажмем «Пуск», появится окно с запросом параметров. Но так как мы хотим запланировать эту задачу, мы вместо этого нажмем кнопку «Расписание»:

 enter image description here

10) Нажмите на ссылку Расписание, чтобы создать новое расписание для Runbook. Я указывал один раз в неделю, но это будет зависеть от вашей рабочей нагрузки и от того, как ваши индексы со временем увеличивают свою фрагментацию. Вам нужно будет настроить расписание на основе ваших потребностей и выполнения начальных запросов между выполнениями: 

 enter image description here

11) Теперь введите параметры и запустите настройки:

 enter image description here

ПРИМЕЧАНИЕ: вы можете поиграть с разными расписаниями с разными настройками, то есть с определенным расписанием для конкретной таблицы.

С этим вы закончили. Не забудьте изменить настройки ведения журнала по желанию:

 enter image description here

6
Alberto Morillo

Azure Automation хороша, и цены также незначительны.

 enter image description here

Некоторые другие варианты у вас есть

1. Создайте задачу «Выполнить SQL» и запланируйте ее с помощью агента SQL. Задача «Выполнить SQL» должна содержать код перестроения индекса вместе с перестроением статистики. 

2.Вы также можете создать связанный сервер с SQLAZURE и создать задание агента SQL. Чтобы создать связанный сервер с Azure, вы можете увидеть эту ссылку SO: Мне нужно добавить связанный сервер в MS Azure. SQL Server

1
TheGameiswar