Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

SQL Server 2016 – Въведение в Stretch база данни

Не, това не е участъкът, който търсите

Започвайки със SQL Server 2016, ще имате възможността да съхранявате части от база данни в облака. Тази нова способност е известна като Stretch Database и функцията ще бъде полезна за тези, които трябва да съхраняват транзакционни данни за дълги периоди от време и тези, които искат да спестят пари за съхранение. Възможността за безпроблемно мигриране на данни към Microsoft Azure Cloud ще ви даде възможност да архивирате данни, без да се налага да променяте начина, по който вашите приложения заявяват данните.

В SQL Server 2016 Community Technology Preview 2 (CTP2), Stretch Database мигрира цели таблици. Ако вашата база данни вече е настроена да съхранява архивни данни в отделни таблици от текущите данни, ще можете лесно да мигрирате архивните данни към Azure. След като активирате Stretch Database, тя безшумно ще мигрира вашите данни към Azure SQL база данни. Stretch Database използва процесорната мощност в Azure за изпълнение на заявки срещу отдалечени данни чрез пренаписване на заявката. Ще видите това като оператор "отдалечена заявка" в плана на заявката.

Лесен начин за идентифициране на бази данни и таблици, които отговарят на условията за активиране на Stretch, е да изтеглите и стартирате SQL Server 2016 Upgrade Advisor и да стартирате Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) написа за това наскоро:

  • Идентифицирайте таблици кандидати за SQL Server 2016 Stretch бази данни

Ограничения за Stretch база данни

Не всички таблици ще отговарят на условията за активиране на разтягане. Определени свойства на таблици, данни и типове колони, ограничения и индекси не се поддържат, като например:

  • Оптимизирани за памет и репликирани таблици
  • Таблици, които съдържат данни от FILESTREAM, използват проследяване на промените или промяна на данни
  • Типове данни като клеймо за време, sql_variant, XML, география или колони, които са винаги криптирани
  • Проверете и ограниченията по подразбиране или ограниченията на външния ключ, които препращат към таблицата
  • XML, пълен текст, пространствено, клъстерирано хранилище за колони и индексирани изгледи, които препращат към таблицата с активиран Stretch
  • Не можете да изпълнявате оператори UPDATE или DELETE или да изпълнявате операции CREATE INDEX или ALTER INDEX в таблица с активиран Stretch.

За пълен списък с ограничения можете да посетите:Изисквания и ограничения за Stretch база данни.

Настройване на Stretch база данни

Да започнете не е сложна задача. Ще ви трябва акаунт в Azure и след това активирате Stretch Database в екземпляра.

За да активирате Stretch Database при стартиране на екземпляр:

EXEC sys.sp_configure N'remote data archive', '1';
RECONFIGURE;
GO

За тази демонстрация ще използвам базата данни AdventureWorks2014 на екземпляр на SQL Server 2016 CPT2. Ще започна със създаване на нова таблица:

USE [AdventureWorks2014];
GO
 
CREATE TABLE dbo.StretchTest
(
  FirstName VARCHAR(50),
  LastName  VARCHAR(50)
);
GO

И тогава ще попълня тестовата таблица StretchTest с някои данни:

USE [AdventureWorks2014];
GO
 
INSERT INTO dbo.StretchTest(FirstName, LastName)
VALUES('Paul', 'Randal'),  ('Kimberly', 'Tripp'),('Jonathan', 'Kehayias'),
      ('Erin', 'Stellato'),('Glenn', 'Berry'),   ('Tim', 'Radney');
GO

Вече имам таблица, която мога да разширя до Microsoft Azure Cloud. За да направя това, ще използвам графичния интерфейс, като щракна с десния бутон върху AdventureWorks2014, избера Задачи и избера Активиране на база данни за разтягане.

Съветникът за активиране на база данни за разтягане ще се отвори, както следва:

Ще щракна по-нататък:

И влезте в моя акаунт в Microsoft Azure:

След това получавам подкана да проверя кой акаунт искам да използвам:

След това избирам кое местоположение на Azure искам да използвам и посочвам потребителско име и парола за администратор. Когато направите това, не забравяйте да запишете потребителското име и паролата на администратора, защото ще ви трябват в бъдеще, за да се свържете отново с базата данни Azure SQL, ако трябва да възстановите базата данни.

След това щраквам върху следващото:

И щракнете върху Готово и базата данни ще започне да се предоставя на Azure SQL Database Server.

Току-що създадох дефиниция на защитен свързан сървър на моя локален сървър, който има отдалечената база данни на Azure SQL като крайна точка. Мога да видя това в сървърни обекти, свързани сървъри, както и в моя акаунт в Azure под SQL бази данни. Имайте предвид, че само системните процеси могат да използват този свързан сървър; потребителските влизания не могат да издават заявки през свързания сървър към отдалечената крайна точка.

Сега, когато Stretch Database е активирана за екземпляра и за базата данни AdventureWorks2014, вече мога да разтягам новата си таблица. За да разширя таблицата до Azure, трябва да променя таблицата и да активирам отдалечен архив на данни.

USE [AdventureWorks2014];
GO
 
ALTER TABLE [StretchTest]
ENABLE REMOTE_DATA_ARCHIVE WITH ( MIGRATION_STATE = ON );
GO

В допълнение към новите функции със SQL Server 2016, има и някои нови DMV. За да наблюдавате миграцията на данни към Azure, можете да запитате sys.dm_db_rda_migration_status. Когато попитах DMV след активиране на отдалечен архив на данни, успях да видя, че 6-те реда са мигрирани:

Архивиране и възстановяване на разтеглена база данни

Понастоящем в SQL Server 2016 CTP2, когато се архивира база данни, която е активирана Stretch, се създава плитко архивиране, което не включва данните, които са мигрирани към базата данни на Azure SQL. Очаква се, че с RTM версията на SQL Server 2016 архивирането на база данни с активиран Stretch ще създаде дълбоко архивиране, което ще съдържа както локални, така и разтегнати данни.

Когато възстановявате база данни, която е активирана за разтягане, ще трябва да свържете отново локалната база данни към отдалечената база данни Azure SQL. Можете да направите това, като стартирате съхранената процедура sys.sp_reauthorize_remote_data_archive като db_owner.

Ако сега архивирам базата данни AdventureWorks2014 с активиран Stretch и я възстановя, вече няма да мога да заявя таблицата StretchTest, докато не се свържа отново с Azure SQL база данни, като изпълня:

USE [AdventureWorks2014];
GO
 
EXEC sys.sp_reauthorize_remote_data_archive @azure_username, @azure_password;
GO

След като се свържа отново получавам съобщение, подобно на това по-долу и след това мога да потърся отново разтегнатите данни:

Копиране на отдалечена база данни 'RDAAdventureWorks201467B6D9D4-E8E0-4C54-B3EF-7C2D3F1326C4' към отдалечена база данни 'RDAAdventureWorks2014660B555C-8DD1-4750-9A04-26 завършване на отдалечена база данни />
завършване на отдалечена база данни />
D04-26. br />Отдалечената база данни „RDAAdventureWorks2014660B555C-8DD1-4750-9A04-2868CD1C646D“ завърши копирането и вече е онлайн.

Когато възстановявате база данни с активиран Stretch в друг екземпляр, този екземпляр трябва да има „активиран отдалечен архив на данни“. След като възстановите базата данни и активирате „отдалечен архив на данни“, всичко, което се изисква, е повторно свързване към Azure SQL база данни чрез стартиране на съхранената процедура sys.sp_reauthorize_remote_data_archive.

Резервните копия за Azure SQL бази данни за базови, стандартни и премиум нива на услуги се правят на всеки час. Периодът на запазване на резервното копие варира в зависимост от нивото на услугата. Към момента на писане за основния е 7 дни, стандартен 14 дни, а premium е 35 дни. Можете да възстановите Azure SQL бази данни, като използвате уеб портала на Microsoft Azure.

Отмяна на мигрирането на данни

За да мигрирате данни обратно в локално хранилище от Azure SQL база данни, ще трябва да създадете нова локална таблица със същата схема като таблицата с активиран Stretch. След това трябва да копирате данните от таблицата с активиран Stretch в новата локална таблица. След като данните се копират, пускате таблицата с активиране на разтягане и преименувате новата локална таблица на името на таблицата с активиран разтягане, която току-що е изпусната.

Можете да деактивирате Stretch за база данни само след като всички таблици с активиран Stretch бъдат премахнати. Ако махнете база данни, активирана за Stretch, локалната база данни се премахва, но отдалечените данни не са; ще трябва да изхвърлите отдалечената база данни от портала за управление на Azure.

Резюме

Stretch Database е лесен начин за мигриране на архивни данни към Microsoft Azure, ако вашата база данни го поддържа. Понастоящем в SQL Server 2016 CTP2 има много ограничения със свойства на таблици, данни и колони, типове данни и колони, ограничения и индекси. Ако не сте ограничени от тези ограничения, тогава Stretch Database е прост начин да мигрирате исторически данни към Azure SQL база данни и да освободите ценно локално хранилище. Управлението на архивиране ще стане малко по-сложно, тъй като вашите данни ще бъдат разделени между на място и в облака.

Очаквам с нетърпение тези ограничения да бъдат премахнати в RTM версията и съм сигурен, че много от вас ще могат да се възползват от тази страхотна функция.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как NTILE() работи в SQL Server

  2. Упътване:Настройка на висока наличност на SQL Server

  3. Избройте акаунтите, свързани с пощенски профил на база данни в SQL Server

  4. Начини за мигриране на база данни на SQL Server към Azure SQL база данни

  5. Получаване на динамично генерирана обобщена таблица във времева таблица