Flere online operationer tilgængelige nu - eller snart

Jeg kørte nogle tests i SQL Database og opdagede mindst én ny operation, der understøtter ONLINE = ON . Dette er i øvrigt på en meget nyere version – SELECT @@VERSION; fortsætter med at give et gammelt byggenummer, men beviset er i byggedatoen:

Denne version af Azure SQL Database understøtter ONLINE = ON mulighed for ALTER TABLE ... ALTER COLUMN .

Lad os sige, at du har en tabel med en nullbar kolonne:

CREATE TABLE dbo.a(id INT PRIMARY KEY, x VARCHAR(255));
 
INSERT dbo.a(id, x) SELECT TOP (1) [object_id], name FROM sys.all_objects;

Og nu beslutter du dig for at gøre den kolonne ikke nullbar, du kan gøre dette (forudsat at der ikke er nogen NULL s):

ALTER TABLE dbo.a
  ALTER COLUMN x VARCHAR(255) NOT NULL
  WITH (ONLINE = ON);

Du kan også gøre ting som at ændre sorteringen, datatypen eller størrelsen på kolonnen:

ALTER TABLE dbo.a 
ALTER COLUMN x NVARCHAR(510)    -- changed data type and length
  COLLATE Albanian_BIN NOT NULL -- changed collation and nullability
  WITH (ONLINE = ON);

I nuværende versioner af SQL Server (og tidligere versioner af Azure SQL Database) er ONLINE = ON tip blev ikke understøttet for ALTER TABLE , og uden muligheden var dette en blokerings- og datastørrelsesoperation. For at være retfærdig, første gang jeg kørte koden, kunne jeg kun bevise, at versionen med ONLINE = ON kørte med succes, ikke at det fungerede som annonceret.

Jeg kørte denne kode med ONLINE = ON og uden:

CREATE TABLE dbo.a(id INT PRIMARY KEY, x VARCHAR(255));
 
INSERT dbo.a(id, x) SELECT TOP (1) [object_id], name FROM sys.all_objects;
 
-- placeholder;
 
ALTER TABLE dbo.a 
  ALTER COLUMN x NVARCHAR(510)
  COLLATE Albanian_BIN NOT NULL 
  -- WITH (ONLINE = ON);
 
-- placeholder;
 
DROP TABLE dbo.a;

I --placeholder spot, prøvede jeg et par ting for at bestemme enhver forskel i adfærd (dette var vores produktions SQL-database, så jeg ønskede ikke at bruge nok data eller skabe nok aktivitet til, at forskellen ville være indlysende). Jeg ønskede i begge scenarier at kontrollere, om siden var ændret (hvilket indikerer en ægte online-operation), eller om værdierne var opdateret på plads på de eksisterende sider (en ikke-så-online-operation). Jeg kunne også have udvidet testen for at se, hvor mange nye sider der blev oprettet, hvis siderne var fyldte og/eller alle 255 tegn var brugt, men jeg tænkte, at det ville være nok at se om siderne blev ændret.

Jeg prøvede DBCC IND() :

DBCC IND(N'dbname', N'dbo.a', 1, 1);

Resultaterne her var ikke overraskende:

Og sys.dm_db_database_page_allocations (erstatningen for DBCC IND ):

SELECT allocated_page_page_id
  FROM sys.dm_db_database_page_allocations(DB_ID(),OBJECT_ID(N'dbo.a'),1,1,N'LIMITED')
  WHERE is_iam_page = 0;

Dette gav et tomt resultatsæt – jeg tror, ​​det er designmæssigt, at denne dynamiske administrationsfunktion ikke afslører nogen fysisk information i Azure SQL Database.

Dernæst prøvede jeg et trick med fn_PhysLocCracker , som folk som Michelle Ufford (@sqlfool) har blogget om før:

SELECT l.page_id FROM dbo.a
  OUTER APPLY sys.fn_PhysLocCracker(%%PhysLoc%%) AS l;

Succes! Dette returnerede værdier for de sider, der blev brugt i scanningen mod dbo.a , og det er klart, at i ONLINE = ON version, flyttes dataene til nye sider (hvilket formentlig efterlader de gamle tilgængelige under hele operationen), og uden antydningen bliver data og metadata opdateret på plads:

Sammenligning af sider under standard ALTER COLUMN-adfærd (venstre) med ONLINE =ON (højre)

En anden ting, jeg ville sammenligne, var udførelsesplanerne. Jeg ser måske ikke meget i Management Studio, men i SQL Sentry Plan Explorer Pro kan jeg se hele opkaldsstakken, inklusive hvad der foregår bag kulisserne af nogle DDL-kommandoer. Vores værktøj skuffede ikke – selvom det ikke præsenterede en egentlig plan for den lokale opdateringsvariation, viser det også, at der er en betydelig adfærdsforskel ved brug af ONLINE = ON :

Sammenligning af planer under standard ALTER COLUMN-adfærd (venstre) med ONLINE =ON (højre)

Selvfølgelig vil du kun se denne forskel, hvis du opfylder alle de andre betingelser, der kræves for online-operationer (mange svarer til kravene til online-indeksgenopbygning) i den nyligt opdaterede dokumentation.

Nu, hvis du ikke bruger SQL Database, hvordan hjælper det dig så? Når alt kommer til alt, parser denne syntaks ikke korrekt, selv i SQL Server 2014 Cumulative Update #6 (12.0.2480). Nå, Microsoft har ikke ligefrem vogtet over, at udviklingsmønsteret er blevet "sky først, så boks" - som Mark Souza for nylig antydede, da han tweetede om den nye sikkerhedsfunktion på rækkeniveau, der først blev introduceret i Azure SQL Database:

Sikkerhed på rækkeniveau. Bedt om meget af #sqlserver-fællesskabet. http://t.co/pp0sNr8Nt5 Cloud først, men du ved, hvad det betyder. Det kommer

— Mark Souza (@mark_AzureCAT) 8. februar 2015

Dette betyder, at disse online-operationer sandsynligvis også kommer til din lokale kopi af SQL Server på et tidspunkt snart. Ligesom mange andre online-operationer skal du dog huske på, at disse ting har tendens til at være reserveret til Enterprise Edition.