SQL 2017 въведе възможността за пауза и възобновяване на операциите за възстановяване на индекса по време на поддръжка на база данни. Тази функция предлага по-голяма гъвкавост на администраторите на бази данни, тъй като им позволява да избират между офлайн и онлайн преиндексиране, заедно с пауза и възобновяване на възстановяването на индекса, когато е необходимо.
Преди пускането на възобновяемия индекс, администраторите на база данни биха могли да изпълнят възстановяване на индекс офлайн ионлайн .
Офлайн предлага по-бързо изпълнение, тъй като таблицата е заключена за всяко четене или пишете операция, а новият индекс се изгражда от стария индекс. По време на този процес не е разрешена операция за четене или запис. Когато операцията е извършена, заключването на таблицата се освобождава и операциите за четене и запис са разрешени отново. Офлайн опцията е естествено по-бърза.
Онлайн поддържа таблицата отворена за четене и пишете операции. Направено е друго копие на индекса и всички операции за възстановяване на индекса са в това копие. Всички операции с нови редове се записват и в двата индекса. Когато възстановяването приключи, превключването е завършено и новото индексно копие се използва. Онлайн rebuild позволява операции по възстановяване, докато базата данни е онлайн. Времето за престой е минимално.
Имайте предвид, че функцията за възобновяем индекс е налична само в изданието SQL Server Enterprise и безплатното издание за разработчици. Ако имате тази опция на масата, можете да си поиграете с нея, да направите прост тест и да видите дали тази функция е полезна във вашия случай.
Документацията на Microsoft посочва следните аспекти, които трябва да имате предвид:
- Можете да управлявате, планирате и разширявате прозорците за поддръжка на индекса. Можете да поставите на пауза и да рестартирате операциите по създаване или възстановяване на индекс, когато трябва да напаснете прозорците за поддръжка.
- Можете да се възстановите от неуспехите при създаване или възстановяване на индекса (като например при отказ на база данни или изчерпване на дисково пространство).
- Обърнете внимание, че когато операцията с индекс е на пауза, както оригиналният индекс, така и новосъздаденият ще изискват дисково пространство. Ще трябва да ги актуализирате по време на DML операциите.
- Можете да активирате съкращаването на регистрационните файлове на транзакциите по време на операциите за създаване или възстановяване на индекс.
- Обърнете внимание, че опцията SORT_IN_TEMPDB=ON не се поддържа
Нека тестваме възобновяемото възстановяване на индекса. Ще използвам изображение на контейнер, работещо с изданието SQL 2019 Server Developer. Освен това ще създам малка таблица само с няколко колони и ще вмъкна около милион реда в тази таблица. Можете да увеличите таблицата с повече редове.
Тъй като използвам Linux машина и не мога да инсталирам SQL Server Management Studio, ще използвам клиента Azure Data Studio, за да се свържа с моя SQL Server. Разгледайте екранната снимка на моите свойства на SQL Server:
Ще създадем примерна база данни, таблица и индекс с по-долу T-SQL скриптове. Можете да ги изпълните безупречно с SSMS или dbForge Studio за SQL Server:
-- Create a new database called 'DatabaseName'
-- Connect to the 'master' database to run this snippet
USE master
GO
-- Create the new database if it does not exist already
IF NOT EXISTS (
SELECT [name]
FROM sys.databases
WHERE [name] = N'dbatools'
)
CREATE DATABASE dbatools
GO
Use dbatools
-- Create a new table called '[TableName]' in schema '[dbo]'
-- Drop the table if it already exists
IF OBJECT_ID('[dbo].[TabletoIndex]', 'U') IS NOT NULL
DROP TABLE [dbo].[TabletoIndex]
GO
-- Create the table in the specified schema
CREATE TABLE [dbo].[TabletoIndex]
(
[Id] INT NOT NULL PRIMARY KEY, -- Primary Key column
[ColumnName1] NVARCHAR(50) NOT NULL
-- Specify more columns here
);
GO
За да попълните таблицата с произволни данни, изпълнете следния скрипт:
--populate the table
SET NOCOUNT ON
Declare @Id int
Set @Id = 1
While @Id <= 1000000
Begin
Insert Into TabletoIndex values (@Id, 'Name - ' + CAST(@Id as nvarchar(10))) Set @Id = @Id + 1
End
SELECT count(*) from TabletoIndex
С готова попълнена таблица можем да продължим към възобновяемия индекс. Нека започнем със създаването на този индекс:
-- Create a nonclustered index with or without a unique constraint -- Or create a clustered index on table '[TableName]' in schema '[dbo]' in database '[DatabaseName]'
CREATE UNIQUE INDEX IX_ID_Name ON [dbo].[TabletoIndex] (ID desc, [ColumnName1] DESC) WITH (SORT_IN_TEMPDB = OFF, RESUMABLE=ON, ONLINE = ON, MAX_DURATION=1) GO
Забележете нови опции/параметри в горната команда. RESUMABLE=ON означава, че искаме да имаме възобновяема операция с индекс. Макс.продължителност е стойността в минути, определяща колко дълго искаме да се изпълнява индексирането.
Докато горната команда работи, отворете друга сесия и изпълнете командата T-SQL по-долу за ПАУЗА текущата дейност по възстановяване:
--Rebuild WITH RESUMABLE functionality
ALTER INDEX IX_ID_Name ON [dbo].[TabletoIndex] PAUSE
GO
Ако ПАУЗА командата е успешна, поставяме на пауза текущата операция по индексиране, започната преди около минута. Въпреки това, когато се върнете към предишната сесия за командата за повторно изграждане с resumable=ON , връща грозна грешка. ъъъъ Но да, това е очакваното поведение.
С това възобновяемо възстановяване на индекса, SQL Server въведе и нов DMV sys.index_resumable_operations за проверка на спрени операции. Нека се опитаме да разгледаме този DMV:
Заявката за резултат DMV връща моята команда за възстановяване на индекса, процентът завършен е страхотно нещо и още. Когато всички ваши операции за възстановяване на индекса са извършени, DMV връща празно:
Доста спретнато, а?
Но какво ще стане, ако промените мнението си за масата? Ами ако има промяна в изискванията и трябва да направите промени в дизайна на базата данни? Нека се опитаме да оставим таблицата:
Ще даде друго грозно, дълго съобщение за грешка:
Съобщение 10637, ниво 16, състояние 1, ред 1
Не може да се извърши тази операция върху „обект“ с идентификатор 581577110, тъй като един или повече индекси в момента са в състояние на възобновяване на възстановяване на индекс. Моля, вижте sys.index_resumable_operations за повече подробности.
Общо време за изпълнение:00:00:00.018
Оттук нататък ще разберете, че нямате друг избор, освен да ПРЕКРАТЕТЕ напълно операцията или да ВЪЗОБНОВИТЕ и да оставите възстановяването да завърши.
Вижте командата T-SQL, за да възобновите или прекратите операцията. След това можете успешно да пуснете таблицата:
ALTER INDEX IX_ID_Name ON [dbo].[TabletoIndex] RESUME
ALTER INDEX IX_ID_Name ON [dbo].[TabletoIndex] ABORT
Същата грешка ще възникне и ако трябва да извършите други операции, като пълно изтриване на индекса или унищожаване на текущата сесия.
Но вие се питате възобновяемата опция ли е на първо място? Отговорът е НЕ. За SQL 2019 цялото създаване на индекс е с RESUMABLE=ON по подразбиране. Това се дължи на тези 2 изявления за обхват:
ALTER DATABASE SCOPED CONFIGURATION SET ELEVATE_ONLINE=WHEN_SUPPORTED ALTER DATABASE SCOPED CONFIGURATION SET ELEVATE_RESUMABLE=WHEN_SUPPORTED Резюме
Въздействието от използването на опцията за възобновяване върху производителността не се различава от използването на нормалната операция за повторно индексиране. SQL Server просто ви дава повече контрол върху операциите по поддръжка на вашата база данни.
Що се отнася до изискванията за възстановяване на индекса на периодичната таблица, най-добрата практика все още е да изпълнявате операции с индекси офлайн или поне в непиковите часове, за да осигурите минимално въздействие върху бизнеса.
