SQL Server 2016 – Introduktion til Stretch Database

Fra og med SQL Server 2016 vil du have mulighed for at gemme dele af en database i skyen. Denne nye evne er kendt som Stretch Database, og funktionen vil være gavnlig for dem, der har brug for at opbevare transaktionsdata i lange perioder, og dem, der ønsker at spare penge på opbevaring. At være i stand til problemfrit at migrere data til Microsoft Azure Cloud vil give dig mulighed for at arkivere data uden at skulle ændre den måde, dine applikationer forespørger på dataene.

I SQL Server 2016 Community Technology Preview 2 (CTP2) migrerer Stretch Database hele tabeller. Hvis din database allerede er konfigureret til at gemme arkivdata i separate tabeller fra aktuelle data, vil du nemt kunne migrere arkivdataene til Azure. Når du aktiverer Stretch Database, migrerer den lydløst dine data til en Azure SQL-database. Stretch Database udnytter processorkraften i Azure til at køre forespørgsler mod fjerndata ved at omskrive forespørgslen. Du vil se dette som en "fjernforespørgsel"-operatør i forespørgselsplanen.

En nem måde at identificere databaser og tabeller, der er kvalificerede til at blive Stretch-aktiveret, er at downloade og køre SQL Server 2016 Upgrade Advisor og køre Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) skrev om dette for nylig:

• Identificer kandidattabeller til SQL Server 2016 Stretch-databaser

Begrænsninger for Stretch-database

Ikke alle borde vil være kvalificerede til at være Stretch-aktiverede. Visse tabelegenskaber, data- og kolonnetyper, begrænsninger og indekser understøttes ikke, såsom:

• Hukommelsesoptimerede og replikerede tabeller
• Tabeller, der indeholder FILESTREAM-data, bruger ændringssporing eller ændringsdata
• Datatyper såsom tidsstempel, sql_variant, XML, geografi eller kolonner, der altid er krypteret
• Tjek og standard begrænsninger eller fremmednøgle begrænsninger, der refererer til tabellen
• XML, fuldtekst, rumlig, klynget kolonnelager og indekserede visninger, der refererer til den Stretch-aktiverede tabel
• Du kan ikke køre UPDATE- eller DELETE-sætninger eller køre CREATE INDEX- eller ALTER INDEX-operationer på en Stretch-aktiveret tabel

For en komplet liste over begrænsninger kan du besøge:Krav og begrænsninger for Stretch Database.

Opsætning af Stretch-database

At komme i gang er ikke en kompliceret opgave. Du skal bruge en Azure-konto og derefter aktivere Stretch Database på instansen.

Sådan aktiverer du Stretch Database på en instanskørsel:

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

Til denne demo vil jeg bruge AdventureWorks2014-databasen på en SQL Server 2016 CPT2-instans. Jeg starter med at oprette en ny tabel:

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

Og så vil jeg udfylde testtabellen StretchTest med nogle data:

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

Jeg har nu en tabel, som jeg kan strække til Microsoft Azure Cloud. For at gøre dette bruger jeg GUI'en ved at højreklikke på AdventureWorks2014, vælge Tasks og vælge Aktiver Database for Stretch.

Guiden Enable Database for Stretch åbnes som nedenfor:

Jeg klikker på næste:

Og log ind på min Microsoft Azure-konto:

Jeg bliver derefter bedt om at bekræfte, hvilken konto jeg vil bruge:

Derefter vælger jeg, hvilken Azure-placering jeg vil bruge, og angiver et admin-login og adgangskode. Når du gør dette, skal du sørge for at notere administratorbrugernavnet og adgangskoden, fordi du skal bruge dette i fremtiden for at genoprette forbindelsen til Azure SQL-databasen, hvis du skal gendanne databasen.

Jeg klikker derefter på næste:

Og klik på Udfør, og databasen begynder at klargøre til Azure SQL Database Server.

Jeg har lige oprettet en sikker linket serverdefinition på min lokale server, der har den eksterne Azure SQL-database som slutpunkt. Jeg kan se dette i Server Objects, Linked Servers samt i min Azure-konto under SQL Databases. Bemærk, at kun systemprocesser kan bruge denne linkede server; brugerlogins kan ikke udstede forespørgsler gennem den forbundne server til det eksterne slutpunkt.

Nu hvor Stretch Database er aktiveret for instansen og for AdventureWorks2014-databasen, kan jeg nu strække min nye tabel. For at strække tabellen til Azure skal jeg ændre tabellen og aktivere fjerndataarkiv.

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

Ud over nye funktioner med SQL Server 2016 er der også nogle nye DMV'er. For at overvåge migreringen af ​​data til Azure kan du forespørge sys.dm_db_rda_migration_status. Da jeg spurgte DMV'en efter at have aktiveret fjerndataarkiv, kunne jeg se, at de 6 rækker blev migreret:

Sikkerhedskopiering og gendannelse af en Stretch-database

I øjeblikket i SQL Server 2016 CTP2, når en database, der er Stretch-aktiveret, sikkerhedskopieres, oprettes en lavvandet sikkerhedskopi, som ikke inkluderer de data, der er blevet migreret til Azure SQL-databasen. Det forventes, at med RTM-udgivelsen af ​​SQL Server 2016 vil sikkerhedskopiering af en Stretch-aktiveret database skabe en dyb backup, der vil indeholde både lokale og strakte data.

Når du gendanner en database, der er Stretch-aktiveret, skal du genoprette den lokale database til den eksterne Azure SQL-database. Du gør dette ved at køre den lagrede procedure sys.sp_reauthorize_remote_data_archive som en db_owner.

Hvis jeg nu sikkerhedskopierer den Stretch-aktiverede AdventureWorks2014-database og gendanner den, vil jeg ikke længere være i stand til at forespørge StretchTest-tabellen, før jeg genopretter forbindelse til Azure SQL Database ved at køre:

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

Når jeg har oprettet forbindelse igen, får jeg en meddelelse, der ligner den nedenfor, og så er jeg i stand til at forespørge på de udstrakte data igen: