Więcej operacji online dostępnych teraz – lub wkrótce

Przeprowadzałem testy w bazie danych SQL i odkryłem co najmniej jedną nową operację, która obsługuje ONLINE = ON . Nawiasem mówiąc, jest to bardzo aktualna wersja – SELECT @@VERSION; nadal daje stary numer kompilacji, ale dowód znajduje się w dacie kompilacji:

Ta wersja Azure SQL Database obsługuje ONLINE = ON opcja dla ALTER TABLE ... ALTER COLUMN .

Załóżmy, że masz tabelę z kolumną dopuszczającą wartość null:

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;

A teraz decydujesz, aby ta kolumna nie była dopuszczalna do wartości null, możesz to zrobić (zakładając, że nie ma NULL s):

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

Możesz także zrobić takie rzeczy, jak zmiana sortowania, typu danych lub rozmiaru kolumny:

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

W bieżących wersjach SQL Server (i poprzednich wersjach Azure SQL Database) ONLINE = ON wskazówka nie była obsługiwana dla ALTER TABLE , a bez opcji była to operacja blokowania i określania rozmiaru danych. Szczerze mówiąc, przy pierwszym uruchomieniu kodu mogłem tylko udowodnić, że wersja z ONLINE = ON działał pomyślnie, ale nie działał tak, jak w reklamie.

Uruchomiłem ten kod z ONLINE = ON i bez:

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;

W --placeholder na miejscu, próbowałem kilku rzeczy, aby określić jakąkolwiek różnicę w zachowaniu (to była nasza produkcyjna baza danych SQL, więc nie chciałem używać wystarczającej ilości danych ani tworzyć wystarczającej aktywności, aby różnica była oczywista). Chciałem sprawdzić w obu scenariuszach, czy strona się zmieniła (wskazując na prawdziwą operację online) lub czy wartości zostały zaktualizowane na istniejących stronach (operacja nie tak online). Mogłem również rozszerzyć test, aby zobaczyć, ile nowych stron zostało utworzonych, jeśli strony były pełne i/lub zostały użyte wszystkie 255 znaków, ale pomyślałem, że wystarczy zobaczyć, czy strony się zmieniły.

Próbowałem DBCC IND() :

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

Wyniki tutaj nie były zaskakujące:

I sys.dm_db_database_page_allocations (zamiennik dla 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;

Dało to pusty zestaw wyników — uważam, że zgodnie z projektem ta funkcja dynamicznego zarządzania nie ujawnia żadnych fizycznych informacji w Azure SQL Database.

Następnie wypróbowałem sztuczkę z fn_PhysLocCracker , o których ludzie tacy jak Michelle Ufford (@sqlfool) pisali już wcześniej na blogu:

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

Powodzenie! Zwróciło to wartości dla stron użytych w skanowaniu względem dbo.a , i jasne jest, że w ONLINE = ON wersji, dane są przenoszone na nowe strony (prawdopodobnie pozostawiając stare dostępne przez cały czas trwania operacji) i bez podpowiedzi dane i metadane są aktualizowane na miejscu:

Porównywanie stron ze standardowym zachowaniem ALTER COLUMN (po lewej) z ONLINE =ON (po prawej)

Kolejną rzeczą, którą chciałem porównać, były plany egzekucyjne. Może nie widzę wiele w Management Studio, ale w SQL Sentry Plan Explorer Pro widzę pełny stos wywołań, w tym to, co dzieje się za kulisami niektórych poleceń DDL. Nasze narzędzie nie zawiodło — chociaż nie przedstawiło rzeczywistego planu dla odmiany aktualizacji w miejscu, to również pokazuje, że istnieje znacząca różnica w zachowaniu podczas korzystania z ONLINE = ON :

Porównywanie planów w ramach standardowego zachowania ALTER COLUMN (po lewej) z ONLINE =ON (po prawej)

Oczywiście zobaczysz tę różnicę tylko wtedy, gdy spełnisz wszystkie inne warunki wymagane dla operacji online (wiele z nich jest podobnych do wymagań dotyczących odbudowy indeksu online) w ostatnio zaktualizowanej dokumentacji.

Teraz, jeśli nie korzystasz z bazy danych SQL, w jaki sposób może ci to pomóc? W końcu ta składnia nie jest poprawnie analizowana nawet w aktualizacji zbiorczej programu SQL Server 2014 nr 6 (12.0.2480). Cóż, Microsoft nie strzegł dokładnie tego, że wzorzec programistyczny stał się „najpierw chmura, potem pudełko” – jak niedawno zasugerował Mark Souza, gdy napisał na Twitterze o nowej funkcji zabezpieczeń na poziomie wiersza, wprowadzonej po raz pierwszy w Azure SQL Database:

Bezpieczeństwo na poziomie wiersza. Często proszony przez społeczność #sqlserver. Najpierw http://t.co/pp0sNr8Nt5 Chmura, ale wiesz, co to oznacza. Nadchodzi

— Mark Souza (@mark_AzureCAT) 8 lutego 2015

Oznacza to, że te operacje online prawdopodobnie wkrótce pojawią się również w Twojej lokalnej kopii programu SQL Server. Podobnie jak w przypadku wielu innych operacji online, należy jednak pamiętać, że te rzeczy są zwykle zarezerwowane dla wersji Enterprise.