С течение на времето все повече компании мигрират към или поне оценяват базата данни Azure SQL като алтернатива на високата цена за използване на SQL Server на място.
Проверка на съвместимост
Един от първите аспекти на преместването на вашата база данни в Azure SQL база данни е да проверите за съвместимост и Microsoft ви предоставя много начини да направите това за Azure SQL база данни V12 (наричана по-долу просто „V12“). Един от тези методи е използването на SQL Server Data Tools за Visual Studio (SSDT), който използва най-новите правила за съвместимост за откриване на V12 несъвместимости. В SSDT можете да импортирате схемата на вашата база данни и да изградите проект за внедряване на V12 и ако бъдат открити някакви несъвместимости, те могат да бъдат коригирани в рамките на SSDT и след това да се синхронизират обратно с изходната база данни.
Можете също да използвате инструмент от командния ред, наречен SqlPackage, който може да генерира доклад за проблеми със съвместимостта (и винаги да се уверите, че имате най-новата версия). SQL Server Management Studio е друг начин за това, като се използва функцията за приложение на ниво Export Data, която може да открива и докладва грешки на екрана. Ако не бъдат открити грешки, тогава можете да мигрирате вашата база данни към V12. Ако бъдат открити несъвместимости, те могат да бъдат коригирани с помощта на SSMS преди миграцията.
Помощникът за миграция на данни е самостоятелен инструмент (лесно се бърка с помощника за миграция на SQL Server), който може да се използва за намаляване на усилията за надграждане и замества прегледа на SQL Server 2016 Upgrade Advisor. DMA може също да препоръча подобрения на производителността и надеждността. Друг инструмент, SQL Azure Migration Wizard (SAMW), е инструмент Codeplex, който използва правилата за съвместимост на Azure SQL Database V11, за да открие несъвместимости на V12. SAMW може също да завърши миграцията към V12 и да коригира някои проблеми със съвместимостта. Нещо, което трябва да имате предвид, когато използвате SAMW, е, че той може да открива несъвместимости, които не е необходимо да се коригират.
Мигриране на данни
След като вашата база данни премине проверката за съвместимост, трябва да определите най-добрия метод за мигриране. Някои от по-често срещаните методи включват използване на съветника за миграция на SSMS, експортиране към BACPAC, използване на репликация на транзакции или ръчно скриптиране на базите данни и вмъкване на вашите данни.
Използването на съветника за миграция на SSMS е чудесно за SQL Server 2005 и по-нови бази данни, които са от малък до среден размер. Можете да активирате този съветник в SSMS 2016, като щракнете с десния бутон върху база данни, изберете Задачи и след това Разгръщане на база данни в Microsoft Azure SQL база данни. В SSMS 2014 се нарича Разгръщане на база данни в Windows Azure SQL база данни. Използването на този съветник ви позволява да посочите базата данни за мигриране, да се свържете с вашия абонамент за Azure, да изберете местоположението за файла .bacpac, името на новата база данни и към кое ниво да мигрирате. Когато щракнете върху завършване, съветникът ще извлече и потвърди схемата и след това ще експортира данните. След като данните бъдат експортирани, той ще създаде план за внедряване и ще започне да импортира данните в новата база данни V12.
Много подобно на съветника за миграция на SSMS е приложението на ниво експорт на данни. За да изберете тази опция, щракнете с десния бутон върху базата данни, изберете Задачи и след това Експортиране на приложение на ниво данни. В настройките за експортиране посочвате къде искате да създадете .bacpac файла. Можете да запишете това локално или да го запишете директно във вашия акаунт за съхранение в Azure. Има и разширен раздел, където можете да изберете кои таблици да включите. Това е полезно, ако вашата локална база данни съдържа копия на таблици, които не желаете да мигрирате към V12. Когато изберете Готово, той ще експортира вашите данни. След това можете да се свържете с вашия Azure сървър чрез SSMS и да изберете Импортиране на приложение на ниво данни. Ще посочите местоположението на файла, името на базата данни и нивото на Azure SQL база данни. Когато изберете край, базата данни ще започне да импортира. Този метод ви дава малко повече контрол върху процеса, тъй като разделя експортирането от импортирането. Освен това ви дава възможност да съхранявате файла .bacpac във вашия акаунт за съхранение в Azure, така че по-уязвимият процес на импортиране да не зависи от вашата интернет връзка.
Опция, когато използвате съветника за миграция на SSMS или приложението на ниво експорт на данни, е да създадете Azure VM със SQL Server и да настроите доставката на регистрационни файлове. Това ще подготви предварително вашата база данни в облака Azure, за да помогне за минимизиране на времето за импортиране на базата данни. Когато дойде време да извършите миграцията, просто възстановявате окончателните архивни копия на регистрационните файлове на вторичния и след това премахвате доставката на регистрационни файлове. За да пренесете базата данни онлайн, извършете възстановяване с възстановяване. Това по същество ще елиминира времето, необходимо за копиране на вашата база данни от вашия център за данни в центъра за данни на Azure.
Транзакционната репликация е друг метод за намаляване на времето за престой при мигриране към V12. Това е най-добрият вариант, ако имате изключително малък прозорец за поддръжка, за да преминете към V12, ако базата данни може да поддържа репликация на транзакции. Настройката на репликация на транзакции изисква първични ключове за всяка публикувана таблица, което може да бъде проблематично за много бази данни. Конфигурирането на репликация на транзакции също може да бъде сложно, тъй като трябва да настроите базата данни за разпространение, да настроите издателя и абоната и да наблюдавате заданията.
Можете също да мигрирате ръчно, като използвате съветника за генериране на скриптове и скриптирате схемата и/или данните на базата данни. След това можете да създадете празна база данни в Azure и да импортирате вашата схема и/или данни, като изпълните скрипта. Чувал съм за някои хора, използващи този метод, за да създадат празната база данни и след това ръчно да вмъкват своите данни една по една таблица, използвайки SSMS и свързан сървър. Този метод може да работи за вас, но също така може да бъде много сложен, ако имате много конструкции на схеми като връзки с външни ключове и колони за идентичност, в който случай другите методи по-горе биха били по-надеждни и ефективни.
Други съображения за миграция
Когато планирате да мигрирате на локални бази данни към V12, размерът на базата данни е огромен фактор за това колко време ще отнеме миграцията. Експортирането на базата данни, прехвърлянето на данните и импортирането ще се увеличат пропорционално на размера на базата данни.
Друг голям фактор за времето за възстановяване/импортиране при преместване на вашите бази данни към V12 е нивото на производителност, което също възстановявате. Процесът на възстановяване/импорт изисква много конски сили, така че за да ускорите миграцията си, трябва да помислите за възстановяване до по-високо ниво на производителност. Когато базата данни е онлайн, можете лесно и бързо да се спуснете до по-ниско ниво, което отговаря на вашите ежедневни нужди от производителност. Възможността да променяте нивата на производителност с няколко щраквания на мишката е едно от големите предимства на Azure SQL база данни.
Мониторинг
Важна част от администрирането на всяка база данни е наблюдението. Ако не следите нещо, не можете да го измерите. Ако не знаете какви са вашите показатели, когато нещата работят нормално, как ще разберете кои неща са по-лоши, когато производителността се влоши? С локалните бази данни имаме познати инструменти:SQL Server Management Studio, Performance Monitor, Task Manager, DMV и т.н. Когато преместим нашите бази данни към V12, ние губим възможността да наблюдаваме от гледна точка на ОС и други концепции също се променят малко. Вече имаме тази метрика, наречена DTU, с която да работим, което означава единици за транзакции на база данни. Мислете за това като за комбинация от процесор, данни и вход/изход на дневника на транзакциите и памет. Порталът Azure включва диаграма за наблюдение, която по подразбиране има проверен процент на DTU и можете да редактирате тази диаграма, за да включва допълнителни показатели, като например:
- Блокиран от защитната стена
- CPU %
- Ограничение на DTU
- Използва се DTU
- % за вход/изход на данни
- Размер на базата данни %
- Застой
- Неуспешни връзки
- % OLTP хранилище в паметта
(преглед)
- Процент на входно/изходно записване
- % сесии
- Успешни връзки
- Общ размер на базата данни
- % работници
Като минимум бих добавил процент на процесора, процент на вход/изход на данни, блокиране и процент на размера на базата данни. Понастоящем тази диаграма показва предишния час на използване на ресурсите.
Мониторингът от DMV не се промени много, освен че има няколко нови DMV, свързани с индивидуалните показатели на базата данни и как да се изчисли размерът на базата данни. Една от предишните ми статии тук, Първи стъпки за настройка на производителността в Azure SQL база данни, обхваща някои от разликите в общите скриптове, които се използват за събиране на латентности на диска и статистика за чакане във връзка с Azure SQL база данни.
Инструментите на трети страни също започнаха да включват куки в Azure SQL база данни, като SentryOne с DB Sentry. DB Sentry ви дава възможност да наблюдавате производителността и да управлявате събития, които се случват във вашата система. Една страхотна функция е функцията Top SQL, която ви позволява да видите заявките, които имат най-голямо влияние върху цялостната ви производителност, за да можете да настроите/поправите всички проблеми с тази заявка. Друг е графика на DTU във времето и визуализирането му на табло за управление заедно с други важни показатели.
 Топ SQL в клиента SentryOne |  Използване на DTU на таблото за управление на DB Sentry |
Тези показатели се съхраняват в специална база данни, като ви предоставят възможност за изходно ниво и тенденция към ефективността във времето, което е много по-добре от ограничените диаграми, които понастоящем получавате в Azure Portal.
Резюме
Има много предимства от мигрирането към Azure SQL Database V12, ако вашата база данни е съвместима, така че се възползвайте от един от наличните инструменти, за да проверите съвместимостта си с V12. Ако вашата база данни е съвместима или може лесно да бъде променена, за да стане съвместима, тогава можете лесно да мигрирате към Azure SQL Database V12 и да започнете да тествате и сравнявате вашите приложения и работни натоварвания.
