Още през август 2015 г. написах статия, представяща новата функция Stretch Database в SQL Server 2016. В тази статия обсъдих как да започнете с Stretch Database в SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 беше пуснат на 1 юни 2016 г. и имаше множество актуализации на продукта. Методът за настройка на Stretch Database се промени леко, както и някои от функциите.
Започвайки със SQL Server 2016 придобихме способността да съхраняваме части от база данни в Azure SQL база данни. В по-ранни визуализации, когато сте активирали Stretch за база данни, трябваше да мигрирате цялата таблица, с RTM версията на SQL Server 2016, вече можете да изберете част от таблица. След като активирате разтягането за таблица, тя безшумно ще мигрира вашите данни. Ако не сте запознати с Stretch Database, тя използва процесорната мощност в Azure, за да изпълнява заявки срещу отдалечени данни чрез пренаписване на заявката. Не е нужно да пренаписвате никакви запитвания от своя страна. Ще видите това като оператор „отдалечена заявка“ в плана на заявката.
Лесен начин за идентифициране на бази данни и таблици, които отговарят на условията за активиране на Stretch, е да изтеглите и стартирате SQL Server 2016 Upgrade Advisor и да стартирате Stretch Database Advisor. Аарон Бертран (@AaronBertrand) писа за това преди известно време. Съветникът за надстройка се промени леко след публикацията на Aaron, но процесът е предимно същият:
- Идентифицирайте таблици кандидати за SQL Server 2016 Stretch бази данни
Ограничения за Stretch база данни
Не всички таблици ще отговарят на условията за активиране на разтягане. Определени свойства на таблици, данни и типове колони, ограничения и индекси не се поддържат, като например:
- Оптимизирани за паметта и репликирани таблици
- Таблици, които съдържат данни от FILESTREAM, използват проследяване на промените или улавяне на промяна на данни
- Типове данни като времева марка, sql_variant, XML или география
- Проверете или ограниченията по подразбиране
- Ограничения на външния ключ, които препращат към таблицата
- XML, пълнотекстови, пространствени или клъстерирани индекси за съхранение на колони
- Индексирани изгледи, които препращат към таблицата
- Не можете да изпълнявате оператори UPDATE или DELETE или да изпълнявате операции CREATE INDEX или ALTER INDEX в таблица с активиран Stretch.
За пълен списък с ограничения можете да посетите:Изисквания и ограничения за Stretch Database.
Настройване на Stretch база данни
Първите стъпки с версията на RTM е малко по-различно от по-ранните визуализации. Ще ви трябва акаунт в Azure и след това трябва да активирате Stretch Database в локалния екземпляр.
За да активирате Stretch Database на екземпляр, изпълнете:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
За тази демонстрация ще използвам примерна база данни, която създадох, наречена STRETCH. Започнах, като щракнах с десния бутон върху базата данни, избрах Tasks, Stretch и след това избрах Enable. Това беше с помощта на SQL Server 2016 Management Studio.
Следващият екран ви предлага кои таблици искате да активирате за Stretch:
Избрах таблицата SALES2. Помощникът по подразбиране е „Цяла таблица“, но можете също да промените тази опция, за да мигрирате подмножество от редове.
Ако избирате по редове, трябва да изберете име за вашите критерии и след това можете да изберете коя колона да използвате в изявлението where, както и условието и стойността. На тази екранна снимка избрах редове преди 2016 г. Възможността за избор на част от таблица е огромно подобрение в сравнение с по-ранните визуализации, които ви позволяваха само да разтегнете цялата таблица. За простота в тази демонстрация ще мигрирам цялата таблица, така че щракнах Отказ и след това Напред.
След като изберете вашите таблици и условия, трябва да изберете кой абонамент за Azure ще използвате, вашия регион на Azure и информация за вашия сървър.
След като въведете необходимата информация, щракнете върху Напред.
Ново подобрение използва главния ключ на базата данни за защита на идентификационните данни на Azure за свързване с Azure. Ако все още нямате главен ключ, ще бъдете подканени да създадете такъв, ако вече имате такъв, ще трябва да предоставите паролата. Щракнете върху Напред.
Ще трябва да създадете правило за защитна стена за вашия сървър или можете да въведете IP диапазон на подмрежата. Направете своя избор и щракнете върху Напред.
Това е мястото, където нещата наистина се промениха и ще ме накара да преосмисля използването на тази функция. Microsoft създадоха база данни Stretch Unit (DSU), за да можете да увеличавате или намалявате нивото на производителност, което ви е необходимо за Stretch данни. От юни 2016 г. текущите цени се таксуват както за изчисление, така и за съхранение, които виждате представени на изображението по-горе. За моята 15MB таблица, която беше мигрирала, ще бъда таксуван $61 USD на месец за съхранение, както и минималното ниво на DSU (100) при $912,50 на месец. Нивата на DSU варират от:
| Ниво на DSU | Почасова цена | Максимални месечни разходи (месеци с 31 дни) |
|---|---|---|
| 100 | 1,25$ | $930 |
| 200 | $2,50 | 1860$ |
| 300 | $3,75 | $2790 |
| 400 | $5,00 | 3720$ |
| 500 | $6,25 | 4650$ |
| 600 | $7,50 | $5,580 |
| 1000 | $12,50 | $9,300 |
| 1200 | $15,00 | $11 160 |
| 1500 | $18,75 | $13 950 |
| 2000 | $25,00 | $18 600 |
Защо съветникът ми каза само $912,50, когато в ценовата листа е посочено, че трябва да бъде $900 за юни (или пропорционално въз основа на това колко дни остават през юни)? Вашето предположение е толкова добро, колкото и моето; Опитах различни математически неща и се оказах празен. Можете да научите повече за ценовите модели тук:
- Ценообразуване на SQL Server Stretch база данни
Преди да науча за този нов метод за таксуване за DSU, бих могъл да изкажа аргумента, че използването на Stretch Database би било много рентабилен метод за съхранение на студени данни (неизползвани данни) в облака. Като разтегнете тези данни в Azure, можете да мигрирате голяма част от по-стари данни, което ще намали размера (и по този начин цената) на вашите локални архиви. В случай, че трябва да възстановите база данни, просто ще трябва да установите връзката с Azure за разтегнатите данни, като по този начин елиминирате необходимостта от възстановяването й. Въпреки това, тъй като минималната цена е почти 1000 долара на месец за DSU скалата от ниския клас, много организации ще открият, че е много по-евтино да запазят данните на по-евтино ниво на съхранение в рамките на техния център за данни и да намерят други методи за HA, като напр. огледално копиране, доставка на регистрационни файлове или групи за наличност.
Щракнете върху Готово, за да започнете миграцията.
Поздравления, сега мигрирах таблицата SALES2 в Azure SQL база данни
Деактивирайте таблица за разтягане
В ранните визуализации на Stretch Database, ако искате да деактивирате Stretch таблица, ще трябва да създадете нова таблица и да вмъкнете данните за разтягане в нея. След като всички данни бъдат копирани, тогава ще трябва или ръчно да изключите таблиците, като ги преименувате, или ръчно да обедините разтегнатите данни обратно в производствената таблица. С RTM версията все още можете ръчно да управлявате миграцията, да изберете да оставите данните в Azure или да изберете опция за връщане на данни от Azure.
Независимо кой метод използвате за връщане на данните, вие плащате такси за пренос на данни.
Архивиране и възстановяване на разтеглена база данни
След като мигрирате данни в Stretch база данни, Azure обработва архивирането на Stretch данните. Архивирането се извършва със моментна снимка, правена на всеки 8 часа и моментните снимки се поддържат в продължение на 7 дни. Това ви дава до 21 точки във времето през предходните 7 дни за възстановяване.
Не е нужно да правите никакви промени в текущите си локални процедури за архивиране. Всички направени локални резервни копия ще съдържат всички локални данни и отговарящи на условията данни, които все още не са мигрирани. Това се нарича плитко архивиране и не съдържа данни, които вече са мигрирали към Azure.
DBCC CHECKDB
Не можете също да стартирате CHECKDB срещу данни, които са мигрирани към Azure.
Когато стартирах DBCC CHECKDB в моята база данни STRETCH преди миграцията, получих следните резултати за таблицата SALES2:
DBCC резултати за „SALES2“.Има 45860 реда в 1901 страници за обект „SALES2“.
След миграцията получих следния изход за таблицата SALES2 (подчертавам моя):
DBCC резултати за 'SALES2'.Има 0 редове в 1901 страници за обект "ПРОДАЖБИ2".
Можете да стартирате DBCC CHECKDB срещу Azure SQL база данни, но поради това, че не можете да се свържете директно с разтеглената Azure SQL база данни, понастоящем не можете ръчно да стартирате DBCC CHECKDB конкретно срещу разтегнатите данни. Не мога да намеря никаква документация, в която се посочва, че Azure извършва проверки за последователност спрямо тези бази данни.
Това поражда значителен риск според мен.
Резюме
Stretch Database е лесен начин за мигриране на архивни данни към Microsoft Azure, ако вашата база данни го поддържа. Понастоящем в SQL Server 2016 RTM има много ограничения със свойства на таблици, данни и колони, типове данни и колони, ограничения и индекси. Ако не сте ограничени от тези ограничения, тогава Stretch Database е прост начин да мигрирате исторически данни към Azure SQL база данни, за да освободите локално хранилище и да намалите времето за възстановяване на тези бази данни, ако разходите си струват. Освен това трябва да сте удобни, поне засега, да не можете да стартирате DBCC CHECKDB срещу мигрирани данни. Управлението на възстановяването също ще бъде малко по-сложно, тъй като трябва да се възстанови връзката между базата данни на SQL Server и отдалечената база данни на Azure.
