SQL Server 2016 – Introduktion till Stretch Database

Från och med SQL Server 2016 kommer du att ha möjlighet att lagra delar av en databas i molnet. Denna nya förmåga är känd som Stretch Database och funktionen kommer att vara fördelaktig för dem som behöver behålla transaktionsdata under långa perioder och de som vill spara pengar på lagring. Att sömlöst kunna migrera data till Microsoft Azure Cloud ger dig möjligheten att arkivera data utan att behöva ändra hur dina applikationer frågar efter data.

I SQL Server 2016 Community Technology Preview 2 (CTP2) migrerar Stretch Database hela tabeller. Om din databas redan är inställd för att lagra arkivdata i separata tabeller från nuvarande data, kommer du enkelt att kunna migrera arkivdata till Azure. När du har aktiverat Stretch Database migreras dina data tyst till en Azure SQL-databas. Stretch Database utnyttjar processorkraften i Azure för att köra frågor mot fjärrdata genom att skriva om frågan. Du kommer att se detta som en "remote query"-operatör i frågeplanen.

Ett enkelt sätt att identifiera databaser och tabeller som är kvalificerade för Stretch-aktiverade är att ladda ner och köra SQL Server 2016 Upgrade Advisor och köra Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) skrev nyligen om detta:

• Identifiera kandidattabeller för SQL Server 2016 Stretch-databaser

Begränsningar för Stretch Database

Alla bord kommer inte att vara kvalificerade för Stretch-aktiverade. Vissa tabellegenskaper, data och kolumntyper, begränsningar och index stöds inte, till exempel:

• Minnesoptimerade och replikerade tabeller
• Tabeller som innehåller FILESTREAM-data, använder Ändringsspårning eller Ändringsdata
• Datatyper som tidsstämpel, sql_variant, XML, geografi eller kolumner som alltid är krypterade
• Kontrollera och standardbegränsningar eller främmande nyckelbegränsningar som refererar till tabellen
• XML, fulltext, rumslig, klustrad kolumnlagring och indexerade vyer som refererar till den Stretch-aktiverade tabellen
• Du kan inte köra UPDATE- eller DELETE-satser, eller köra CREATE INDEX- eller ALTER INDEX-operationer på en Stretch-aktiverad tabell

För en fullständig lista över begränsningar kan du besöka:Krav och begränsningar för Stretch Database.

Konfigurera Stretch Database

Att komma igång är ingen komplicerad uppgift. Du behöver ett Azure-konto och aktivera sedan Stretch Database på instansen.

Så här aktiverar du Stretch Database på en instanskörning:

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

För denna demo kommer jag att använda databasen AdventureWorks2014 på en SQL Server 2016 CPT2-instans. Jag börjar med att skapa en ny tabell:

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

Och sedan fyller jag i testtabellen StretchTest med lite data:

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

Jag har nu en tabell som jag kan sträcka ut till Microsoft Azure Cloud. För att göra detta använder jag GUI genom att högerklicka på AdventureWorks2014, välja Tasks och välja Enable Database for Stretch.

Guiden Aktivera databas för Stretch öppnas enligt nedan:

Jag klickar på nästa:

Och logga in på mitt Microsoft Azure-konto:

Jag uppmanas sedan att verifiera vilket konto jag vill använda:

Sedan väljer jag vilken Azure-plats jag vill använda och anger en administratörsinloggning och lösenord. När du gör detta, se till att notera administratörens användarnamn och lösenord eftersom du kommer att behöva detta i framtiden för att återansluta till Azure SQL-databasen om du måste återställa databasen.

Jag klickar sedan på nästa:

Och klicka på Slutför och databasen börjar tillhandahålla till Azure SQL Database Server.

Jag har precis skapat en säker länkad serverdefinition på min lokala server som har den fjärranslutna Azure SQL-databasen som slutpunkt. Jag kan se detta i Serverobjekt, Länkade servrar samt i mitt Azure-konto under SQL-databaser. Observera att endast systemprocesser kan använda denna länkade server; användarinloggningar kan inte skicka frågor via den länkade servern till fjärrändpunkten.

Nu när Stretch Database är aktiverad för instansen och för AdventureWorks2014-databasen kan jag nu sträcka ut min nya tabell. För att sträcka ut tabellen till Azure måste jag ändra tabellen och aktivera fjärrdataarkiv.

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

Förutom nya funktioner med SQL Server 2016 finns det några nya DMV:er också. För att övervaka migreringen av data till Azure kan du fråga sys.dm_db_rda_migration_status. När jag frågade DMV efter att ha aktiverat fjärrdataarkiv kunde jag se att de 6 raderna migrerades:

Säkerhetskopiering och återställning av en Stretch-databas

För närvarande i SQL Server 2016 CTP2 när en databas som är Stretch-aktiverad säkerhetskopieras, skapas en ytlig säkerhetskopia som inte inkluderar data som har migrerats till Azure SQL-databasen. Det förväntas att med RTM-utgåvan av SQL Server 2016 kommer säkerhetskopiering av en Stretch-aktiverad databas att skapa en djup säkerhetskopia som kommer att innehålla både lokal och sträckt data.

När du återställer en databas som är Stretch-aktiverad måste du återansluta den lokala databasen till den fjärranslutna Azure SQL-databasen. Du gör detta genom att köra den lagrade proceduren sys.sp_reauthorize_remote_data_archive som en db_owner.

Om jag nu säkerhetskopierar den Stretch-aktiverade AdventureWorks2014-databasen och återställer den, kommer jag inte längre att kunna fråga StretchTest-tabellen förrän jag återansluter till Azure SQL Database genom att köra:

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

När jag har anslutit igen får jag ett meddelande som liknar det nedan och sedan kan jag fråga efter Stretched data igen: