Altre operazioni online disponibili ora o presto

Stavo eseguendo alcuni test nel database SQL e ho scoperto almeno una nuova operazione che supporta ONLINE = ON . Questo è su una versione molto recente, tra l'altro – SELECT @@VERSION; continua a produrre un vecchio numero di build, ma la prova è nella data di build:

Questa versione del database SQL di Azure supporta ONLINE = ON opzione per ALTER TABLE ... ALTER COLUMN .

Supponiamo che tu abbia una tabella con una colonna nullable:

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;

E ora decidi di rendere quella colonna non nullable, puoi farlo (supponendo che non ci siano NULL s):

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

Puoi anche fare cose come cambiare le regole di confronto, il tipo di dati o la dimensione della colonna:

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);

Nelle versioni correnti di SQL Server (e nelle versioni precedenti del database SQL di Azure), ONLINE = ON il suggerimento non era supportato per ALTER TABLE e, senza l'opzione, si trattava di un'operazione di blocco e dimensione dei dati. Ad essere onesti, la prima volta che ho eseguito il codice, ho potuto solo provare che la versione con ONLINE = ON ha funzionato correttamente, non che ha funzionato come pubblicizzato.

Ho eseguito questo codice con ONLINE = ON e senza:

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;

Nel --placeholder spot, ho provato alcune cose per determinare eventuali differenze di comportamento (questo era il nostro database SQL di produzione, quindi non volevo usare abbastanza dati o creare abbastanza attività in modo che la differenza fosse ovvia). Volevo verificare in entrambi gli scenari se la pagina era cambiata (che indica una vera operazione online) o se i valori erano stati aggiornati sulle pagine esistenti (un'operazione non così online). Avrei anche potuto ampliare il test per vedere quante nuove pagine sono state create se le pagine erano piene e/o sono stati utilizzati tutti i 255 caratteri, ma ho pensato che sarebbe bastato vedere se le pagine cambiate.

Ho provato DBCC IND() :

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

I risultati qui non sono stati sorprendenti:

E sys.dm_db_database_page_allocations (il sostituto di 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;

Ciò ha prodotto un set di risultati vuoto:credo che sia in base alla progettazione che questa funzione di gestione dinamica non espone alcuna informazione fisica nel database SQL di Azure.

Successivamente, ho provato un trucco con fn_PhysLocCracker , di cui persone come Michelle Ufford (@sqlfool) hanno già scritto sul blog:

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

Successo! Ciò ha restituito i valori per le pagine utilizzate nella scansione rispetto a dbo.a , ed è chiaro che nel ONLINE = ON versione, i dati vengono spostati su nuove pagine (presumibilmente lasciando disponibili le vecchie durante l'operazione) e senza il suggerimento, i dati e i metadati vengono aggiornati sul posto:

Confronto delle pagine con il comportamento ALTER COLUMN standard (a sinistra) con ONLINE =ON (a destra)

Un'altra cosa che volevo confrontare erano i piani di esecuzione. Potrei non vedere molto in Management Studio, ma in SQL Sentry Plan Explorer Pro, posso vedere l'intero stack di chiamate, incluso ciò che accade dietro le quinte di alcuni comandi DDL. Il nostro strumento non ha deluso:sebbene non presentasse un piano effettivo per la variazione dell'aggiornamento sul posto, dimostra anche che esiste una differenza di comportamento significativa quando si utilizza ONLINE = ON :

Confronto dei piani con il comportamento ALTER COLUMN standard (a sinistra) con ONLINE =ON (a destra)

Ovviamente, vedrai questa differenza solo se soddisfi tutte le altre condizioni richieste per le operazioni online (molte sono simili ai requisiti per la ricostruzione dell'indice online) nella documentazione aggiornata di recente.

Ora, se non stai usando il database SQL, come ti aiuta? Dopotutto, questa sintassi non viene analizzata correttamente anche nell'aggiornamento cumulativo n. 6 di SQL Server 2014 (12.0.2480). Ebbene, Microsoft non ha tenuto esattamente a bada il fatto che il modello di sviluppo è diventato "prima il cloud, poi la scatola", come ha recentemente insinuato Mark Souza quando ha twittato sulla nuova funzionalità di sicurezza a livello di riga introdotta per la prima volta nel database SQL di Azure:

Sicurezza a livello di riga. Molto richiesto dalla community di #sqlserver. http://t.co/pp0sNr8Nt5 Cloud prima ma sai cosa significa. Sta arrivando

— Mark Souza (@mark_AzureCAT) 8 febbraio 2015

Ciò significa che queste operazioni online probabilmente arriveranno presto anche alla tua copia locale di SQL Server. Come molte altre operazioni online, tuttavia, tieni presente che queste cose tendono a essere riservate all'edizione Enterprise.