През последната година представих много сесии за Azure SQL база данни, както и автор на множество статии и блогове. Често ме питат дали поддръжката на база данни все още е важен фактор при използване на Azure SQL база данни. Да – задачи като поддръжка на индекси, актуализации на статистиката и проверка на последователността все още са важни и от DBA зависи да планира тези задачи. Объркването произтича от това, че Azure SQL база данни е платформа като услуга и Microsoft отговаря за инфраструктурата, както и за обработката на архивите. Докато някои аспекти на физическата корупция могат да бъдат отчетени, логическата корупция в базата данни не е така. Поради тази причина все още препоръчвам на клиентите да изпълняват DBCC CHECKDB за да се гарантира, че са напълно защитени.
Проблемът, който възниква при всеки нов DBA, работещ с Azure SQL база данни, е, че няма вграден SQL Server Agent, както сме свикнали с SQL Server Standard и Enterprise Editions.
За да планирате задачи по поддръжката на Azure SQL база данни, имате няколко опции:
- Свързани сървъри
- Планове за поддръжка на база данни
- Powershell
- Услуги на Azure
- Еластични работни места
Следните демонстрации предполагат, че вече сте конфигурирали акаунти за влизане, правила за защитна стена и други настройки за сигурност за отдалечен достъп до вашите Azure SQL бази данни.
Свързани сървъри
Свързването с Azure SQL база данни с помощта на свързан сървър е много често срещан подход, тъй като повечето администратори на база данни вече са запознати със създаването и управлението на свързани сървъри. Двата най-често срещани начина, по които съм виждал клиенти, използващи свързани сървъри, е или с SQL Server Native Client, или с доставчик на Microsoft OLE DB за ODBC драйвери като доставчик. Ако използвате собствения клиент, ще трябва да предоставите името на сървъра като източник на данни; ако обаче използвате ODBC драйвера, тогава ще трябва да получите низа за връзка и да го използвате като низ на доставчика. И двете от тези стойности могат да бъдат намерени в Azure Portal за вашата база данни. След като щракнете върху вашата база данни, ще видите името на сървъра и опция за показване на низовете за връзка с базата данни. Това име на сървъра, sqlperformance.database.windows.net, бих използвал за източника на данни на SQL Server Native Client.
Когато щракнете върху „Показване на низове за връзка с базата данни“, в момента имате опции за ADO.NET, JDBC, ODBC и PHP. За да видите низа за връзка за ODBC, щракнете върху раздела ODBC.
След това ще трябва да създадете свързания сървър в SSMS. Под „Обекти на сървъра“ щракнете с десния бутон върху „Свързани сървъри“, изберете „Нов свързан сървър“ и въведете необходимата информация в зависимост от избора на доставчик на източник на данни.
След това кликнете върху „Сигурност“ и определете предпочитанията си. Обикновено виждам опцията „Да се направи с помощта на този контекст за сигурност“ с предоставени отдалечено вход и парола.
След като сте дефинирали всичко това, щракнете върху OK. Вече можете да щракнете с десния бутон върху вашия нов свързан сървър и да тествате връзката.
Вече можете да препращате към свързания сървър, за да извикате всякакви съхранени процедури, като оптимизиране на индекса на Ola Hallengren и DatabaseIntegrityCheck директно срещу Azure SQL база данни в стъпка на задание на SQL агент.
Планове за поддръжка на база данни
Ако планирате да използвате план за поддръжка на база данни за вашата поддръжка, процесът е малко по-лесен. За да започнете, просто създайте своя план за поддръжка ръчно или с помощта на съветника. Ако използвате съветника, след като създадете плана за поддръжка, можете да редактирате плана и след това да добавите връзката Azure. След това променяте всяка задача, за да използвате новата връзка. Екранът ви за връзка трябва да изглежда подобно на следното:
Вече можете да планирате плановете си за поддръжка на база данни да се изпълняват по време на прозореца за поддръжка.
PowerShell
PowerShell е отлична опция за работа с повтаряща се задача и използването на PowerShell с Azure SQL база данни е просто. Можете да използвате функцията Invoke-SqlCmd, за да заявявате или изпълнявате изрази срещу вашите бази данни.
Често срещан подход е използването на скрипт, подобен на:
$params = @{
'Database' = 'YourDatabase'
'ServerInstance' = 'instance.database.windows.net'
'Username' = 'UserName'
'Password' = 'ComplexP@$$word'
'Query' = 'Your Query Here'
}
Invoke-Sqlcmd @params За вашата заявка можете да използвате проверките за оптимизиране на индекса и последователността на Ola Hallengren или всеки персонализиран скрипт, който сте използвали. След това ще трябва да планирате своите PowerShell скриптове, като използвате какъвто и планировчик, който използвате за вашата организация.
Услуги Azure
Вградена в платформата Azure е Azure Automation и за да започнете, трябва да създадете акаунт за автоматизация. Ще трябва да предоставите име за акаунта, да изберете своя абонамент, група ресурси, местоположение и да определите дали искате да създадете акаунт в Azure Run As.
След като създадете своя акаунт, можете да започнете да създавате runbooks. Можете да правите почти всичко с runbooks. Съществуват множество съществуващи книги за изпълнение, които можете да преглеждате и променяте за ваша собствена употреба, включително осигуряване, наблюдение, управление на жизнения цикъл и други.
Можете да създадете runbooks офлайн или с помощта на Azure Portal и те са създадени с помощта на PowerShell. В този пример ще използваме повторно кода от демонстрацията на PowerShell и също така ще демонстрираме как можем да използваме вградения планировчик на Azure Service, за да изпълняваме съществуващия си PowerShell код и да не се налага да разчитаме на локален планировчик, планировчик на задачи или Azure VM за насрочване на работа.
Започнете, като щракнете върху Runbooks
След това кликнете върху „Добавяне на runbook“
Щракнете върху „Създаване на нов runbook“
Предоставете име и тип runbook, избрах PowerShell за моята демонстрация.
След това сте в екран за редактиране на новия си runbook. Тук можете да конфигурирате подробностите и да изградите своя runbook. За тази демонстрация просто изпълнявам скрипт на PowerShell за извикване на съхранена процедура срещу база данни. След като изработите целия си код, можете да публикувате и запишете своя runbook.
От тук можете да стартирате runbook и да потвърдите, че всичко работи съответно, както и да планирате стартирането на runbook в определени часове. Нека преминем през този процес, като щракнем върху „График“
Ще трябва да щракнем върху „Свързване на график с вашия runbook“ и тъй като не сме създавали никакви графици преди, ще трябва да дефинираме нов, като щракнем върху „Създаване на нов график“.
Точно както правим в SQL Server Agent, посочете име на график, описание, ако желаете, кога да започнете и колко често трябва да се изпълнява. Зададох това да се случва всеки ден в 2 сутринта.
Вече имам публикуван runbook, планиран да се изпълнява всяка вечер в 2 часа сутринта, за да извършва поддръжка на индекса на една от моите бази данни.
Еластични работни места
Elastic Jobs все още е в предварителен преглед, така че няма да навлизам в големи подробности поради високата вероятност екраните и функционалността да се променят.
Използването на Elastic Jobs изисква да сте дефинирали еластичен пул от база данни и да зададете поне една база данни към пула, за да изпълнявате задачи. След като създадете еластичния пул и добавите база данни, можете да щракнете върху създаване на задание.
Дайте на работата си описателно име и посочете потребителското име и паролата, с които да се свържете с базите данни, както и скрипта, който искате да стартирате. Щракнете върху запазване и вече имате еластична работа.
След това можете да изберете да стартирате заданието, да прегледате скрипта или да отмените заданието, ако се изпълнява.
Въпреки че има определени неща, които можете да правите чрез Azure Portal с еластичните задачи, реалните опции за мощност и конфигурация са достъпни чрез PowerShell API. За да планирате задание, трябва да използвате командлета New-AzureSQLJobSchedule. Повече подробности за допълнителните функции и как да планирате работни места можете да намерите тук:
- Създавайте и управлявайте еластични задачи за SQL база данни с помощта на PowerShell
Като цяло харесвам функцията за еластични работни места и се надявам, че когато стане общодостъпна, повече функционалност ще бъде вградена в Azure Portal, без да се налага да я управлявате с PowerShell. Харесва ми, че можете да стартирате T-SQL директно, без да се налага да го стартирате в PowerShell и как може да работи срещу всички бази данни в пула.
Резюме
Когато става въпрос за Azure SQL бази данни, да, вие все още носите отговорност за определена поддръжка на вашите бази данни. Имате множество методи за планиране на работни места и в зависимост от вашите нужди и размера на вашата среда, определени опции дават по-добри решения. Свързаните сървъри и плановете за поддръжка на бази данни са бързи и лесни методи, ако имате локални или Azure VM с вече конфигуриран SQL сървър и малко внедряване на Azure. PowerShell винаги е добър вариант, просто трябва да намерите решение за насрочване на изпълнение на скриптовете. Автоматизацията на Azure е много стабилно решение, което ви позволява да създавате runbooks, за да постигнете почти всичко и лесно да планирате runbooks и еластичните задачи е друго страхотно базирано на Azure решение, ако имате задачи, които трябва да изпълнявате срещу група бази данни в еластичен пул.
