Още онлайн операции са налични сега или скоро

Изпълнявах някои тестове в SQL база данни и открих поне една нова операция, която поддържа ONLINE = ON . Между другото, това е в съвсем скорошна версия – SELECT @@VERSION; продължава да дава стар номер на компилация, но доказателството е в датата на изграждане:

Тази версия на Azure SQL база данни поддържа ONLINE = ON опция за ALTER TABLE ... ALTER COLUMN .

Да приемем, че имате таблица с колона, която може да бъде нула:

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;

И сега решите да направите тази колона да не може да бъде нула, можете да направите това (ако приемем, че няма NULL s):

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

Можете също да правите неща като промяна на съпоставянето, типа данни или размера на колоната:

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

В текущите версии на SQL Server (и предишни версии на Azure SQL база данни), ONLINE = ON намек не се поддържаше за ALTER TABLE и без опцията това беше операция за блокиране и размер на данни. За да бъда честен, първия път, когато стартирах кода, можех да докажа само, че версията с ONLINE = ON работи успешно, не че работи както се рекламира.

Изпълних този код с ONLINE = ON и без:

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;

В --placeholder на място, опитах няколко неща, за да определя някаква разлика в поведението (това беше нашата производствена SQL база данни, така че не исках да използвам достатъчно данни или да създавам достатъчно активност, за да е очевидна разликата). Исках да проверя и в двата сценария дали страницата се е променила (което показва истинска онлайн операция) или дали стойностите са актуализирани на съществуващите страници (не толкова онлайн операция). Можех също да разширя теста, за да видя колко нови страници бяха създадени, ако страниците бяха пълни и/или всичките 255 знака бяха използвани, но реших, че само да видя дали страниците са променени, ще бъде достатъчно.

Опитах DBCC IND() :

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

Резултатите тук не бяха изненадващи:

И sys.dm_db_database_page_allocations (замяната на 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;

Това даде празен набор от резултати – вярвам, че по замисъл тази функция за динамично управление не разкрива никаква физическа информация в Azure SQL база данни.

След това опитах трик с fn_PhysLocCracker , за който хора като Мишел Уфорд (@sqlfool) са писали преди:

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

Успех! Това върна стойности за страниците, използвани при сканирането срещу dbo.a , и е ясно, че в ONLINE = ON версия, данните се преместват на нови страници (вероятно оставяйки старите налични по време на операцията) и без намек, данните и метаданните се актуализират на място:

Сравняване на страници при стандартно поведение ALTER COLUMN (вляво) с ONLINE =ON (вдясно)

Друго нещо, което исках да сравня, бяха плановете за изпълнение. Може да не виждам много в Management Studio, но в SQL Sentry Plan Explorer Pro мога да видя пълния стек от обаждания, включително това, което се случва зад кулисите на някои DDL команди. Нашият инструмент не разочарова – въпреки че не представи действителен план за варианта на актуализацията на място, той също демонстрира, че има значителна разлика в поведението при използване на ONLINE = ON :

Сравняване на планове при стандартно поведение ALTER COLUMN (вляво) с ONLINE =ON (вдясно)

Разбира се, ще видите тази разлика само ако отговаряте на всички други условия, необходими за онлайн операции (много са подобни на изискванията за възстановяване на онлайн индекс) в наскоро актуализираната документация.

Сега, ако не използвате SQL база данни, как ви помага това? В крайна сметка този синтаксис не се анализира правилно дори в SQL Server 2014 Кумулативна актуализация #6 (12.0.2480). Е, Microsoft не пази точно факта, че моделът на разработка е станал „първо облак, след това кутия“ – както Марк Соуза наскоро намекна, когато туитира за новата функция за сигурност на ниво ред, въведена първо в Azure SQL база данни:

Сигурност на ниво ред. Искан много от общността на #sqlserver. Първо http://t.co/pp0sNr8Nt5 Облак, но знаете какво означава това. Идва

— Марк Соуза (@mark_AzureCAT) 8 февруари 2015 г.

Това означава, че тези онлайн операции вероятно скоро ще дойдат и във вашето локално копие на SQL Server. Подобно на много други онлайн операции обаче, имайте предвид, че тези неща обикновено са запазени за Enterprise Edition.