Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

Ускорено възстановяване на база данни в SQL Server 2019

Преглед на традиционното възстановяване

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

SQL Server реализира тази възможност, използвайки регистъра на транзакциите. Промените, направени от всички операции за манипулиране на данни в SQL Server, се записват в регистъра на транзакциите, преди да бъдат приложени към файловете с данни (чрез процеса на контролна точка), в случай че е необходимо да се върнете назад или напред.

Трифазният процес на възстановяване при срив в SQL Server е както следва:

  • Анализ – SQL Server чете регистрационния файл на транзакциите от последната контролна точка до края на регистъра на транзакциите

  • Повторете – SQL Server възпроизвежда дневника от най-старата незаети транзакция до края на дневника

  • Отмяна – SQL Server чете дневника от края на дневника до най-старата незаети транзакция и връща всички транзакции, които са били активни по време на срива

Опитните администратори на база данни биха имали в един или друг момент от кариерата си обезсърчаващото изживяване да чакат безпомощно възстановяването при срив да бъде завършено в много голяма база данни. Транзакцията ROLLBACK използва подобен механизъм като процеса на възстановяване при срив. Microsoft подобри значително процеса на възстановяване в SQL Server 2019.

Ускорено възстановяване на база данни

Ускореното възстановяване на база данни е нова функция, базирана на версията, която значително увеличава скоростта на възстановяване в случай на ОТМЕНАНЕ или възстановяване от срив.

В SQL Server 2019 три нови механизма в механизма на SQL Server променят начина, по който се обработва възстановяването и ефективно намаляват времето, необходимо за извършване на връщане назад/напред.

  • Съхранение на постоянни версии (PVS) – Улавя версии на редове в рамките на въпросната база данни. Съхранението на постоянни версии може да бъде дефинирано в отделна файлова група поради причини за производителност или размер

  • Логически връщане – Използва версиите на редове, съхранени в PVS, за извършване на връщане назад, когато се извика връщане за конкретна транзакция или когато се извика фазата на отмяна на възстановяване при срив.

  • sLog – Това вероятно означава вторично дневник . Това е поток от регистрационни файлове в паметта, използван за заснемане на операции, които не могат да бъдат версии. Когато ADR е активиран в базата данни, sLog винаги се възстановява по време на фазата на анализ на възстановяване при срив. По време на повторяването фаза, sLog се използва, а не действителният регистър на транзакциите, което прави процеса по-бърз, тъй като се намира в паметта и съдържа по-малко транзакции. Традиционният процес на възстановяване обработва транзакции от последната контролна точка. sLog се използва и по време на отмяна фаза.

  • Почистващо средство – Премахва ненужните версии на редове от PVS. Microsoft също така предоставя съхранена процедура за ръчно принудително почистване на ненужни версии на редове.

-- LISTING 1: INVOKE THE BACKGROUND CLEANER

USE TSQLV4_ADR
GO
EXECUTE sys.sp_persistent_version_cleanup;

USE master
GO
EXECUTE master.sys.sp_persistent_version_cleanup 'TSQLV4_ADR';

Ускореното възстановяване на база данни е ИЗКЛЮЧЕНО по подразбиране

Фактът, че ADR е изключен в SQL Server 2019 по подразбиране, може да изглежда изненадващ за някои администратори на база данни, като се има предвид, че изглежда е толкова страхотна функция. ADR използва версията в потребителската база данни, в която е активирана. Това може да повлияе значително на размера на базата данни. Освен това може да се наложи да планирате растежа на базата данни, както и възможното местоположение на PVS, за да осигурите добра производителност, ако ADR е активиран. Така че има смисъл умишлено да активирате тази функционалност.

Експериментът:подготвителна фаза

Настроихме експеримент, за да изследваме новата функция и да видим влиянието на ADR върху размера на регистрационния файл на транзакциите, както и върху скоростта на ROLLBACK. В нашия експеримент създаваме две идентични бази данни, използвайки един резервен набор и след това активираме ADR само в една от тези бази данни. Списък 2 показва подготвителните етапи за задачата.

[expand title =”Код”]

-- LISTING 2: PREPARE THE DATABASES AND CONFIGURE ADR

-- 2a. Backup a sample database and restore as two identical databases

BACKUP DATABASE TSQLV4 TO DISK='TSQLV4.BAK' WITH COMPRESSION;

-- Restore Database TSQLV4_NOADR (ADR will not be enabled)
RESTORE DATABASE TSQLV4_NOADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_NOADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_NOADR_LOG.LDF';

-- Restore Database TSQLV4_ADR (ADR will be enabled)
RESTORE DATABASE TSQLV4_ADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_ADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_ADR_LOG.LDF';

-- 2b. Enable ADR in TSQLV4_ADR
USE [master]
GO

-- First create a separate filegroup and add a file to the filegroup
ALTER DATABASE [TSQLV4_ADR] ADD FILEGROUP [ADR_FG];
ALTER DATABASE [TSQLV4_ADR] ADD FILE ( NAME = N'TSQLV4_ADR01', FILENAME = N'C:\MSSQL\Data\TSQLV4_ADR01.ndf' , 
SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [ADR_FG]
GO

-- Enable ADR
ALTER DATABASE TSQLV4_ADR SET ACCELERATED_DATABASE_RECOVERY = ON (PERSISTENT_VERSION_STORE_FILEGROUP = ADR_FG);
GO

-- 2c. Check if all ADR is enabled as planned
SELECT name
, compatibility_level
, snapshot_isolation_state_desc
, recovery_model_desc
, target_recovery_time_in_seconds
, is_accelerated_database_recovery_on FROM SYS.DATABASES
WHERE name LIKE 'TSQLV4_%';


-- 2d. Check sizes of all files in the databases
SELECT DB_NAME(database_id) AS database_name
, name AS file_name
, physical_name
, (size * 8)/1024 AS [size (MB)]
, type_desc
FROM SYS.master_files
WHERE DB_NAME(database_id) LIKE 'TSQLV4_%';


-- 2e. Check size of log used

CREATE TABLE ##LogSpaceUsage (database_name VARCHAR(50)
, database_id INT, total_log_size_in_bytes BIGINT
, used_log_space_in_bytes BIGINT
, used_log_space_in_percent BIGINT
, log_space_in_bytes_since_last_backup BIGINT)

INSERT INTO ##LogSpaceUsage
EXEC sp_MSforeachdb @command1='
IF ''?'' LIKE ("TSQLV4_%")
SELECT DB_NAME(database_id), * FROM ?.SYS.dm_db_log_space_usage;'

SELECT * FROM ##LogSpaceUsage;

DROP TABLE ##LogSpaceUsage;

[/expand]

Фиг. 1 показва изхода на SQL израза в листинг 2 раздел 2c. Ние също така уловихме размера на файловете на базата данни и използването на регистрационния файл на транзакциите. (виж Фиг. 3).

Фиг. 1 Потвърдете, че ADR е конфигуриран

Фиг. 2 Прегледайте размерите на файловете с база данни с данни

Фиг. 3 Проверете размера на дневника, използван и за двете бази данни

Експериментът:Фаза на изпълнение

След като заснеме подробностите, от които се нуждаем, за да продължим, изпълняваме на етапи SQL кода от листинги 3 и 4. Двата списъка са еквивалентни, но ние ги изпълняваме в две идентични бази данни поотделно. Първо правим INSERT (листинг 3, 3a), след това изпълняваме DELETE (листинг 3, 3b), което впоследствие ще върнем обратно. Забележете, че както в INSERT, така и в DELETE сме капсулирали операциите в транзакции. Също така, имайте предвид, че INSERT се изпълнява 50 пъти. На всеки етап от изпълнение, т.е. между 3a, 3b и 3c, ние улавяме използването на дневника на транзакциите с помощта на кода в листинг 2,2e. Това е същото за раздели 4a, 4b и 4c.

-- LISTING 3: EXECUTE DML IN TSQLV4_NOADR DATABASE

-- 3a. Execute INSERT Statement in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_noadr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_noadr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;

-- 3b. Execute DELETE in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_noadr]
GO

-- 3c. Perform Rollback and Capture Time
ROLLBACK;

Фиг. 4 и 5 ни показват, че операцията SELECT INTO отне 6 милисекунди повече в базата данни TSQLV4_ADR, където активирахме ускорено възстановяване на база данни. Също така виждаме на Фиг. 6, че имаме по-голямо използване на дневника на транзакциите в базата данни TSQLV4_ADR. Бях особено изненадан от това, така че повторих експеримента няколко пъти, за да се уверя, че получавам този резултат последователно.

Фиг. 4 Въведете време за изпълнение за TSQLV4_NOADR

Фиг. 5 Въведете време за изпълнение за TSQLV4_ADR

Фиг. 6 Използване на дневника на транзакциите след вмъкване 

-- LISTING 4: EXECUTE DML IN TSQLV4_ADR DATABASE

-- 4a. Execute INSERT Statement in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_adr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_adr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;


-- 4b. Execute DELETE in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_adr]
GO

-- 4c. Perform Rollback and Capture Time
ROLLBACK;

Фиг. 7 и 8 ни показват, че операцията DELETE отне значително повече време, за да бъде завършена в базата данни TSQLV4_ADR, където активирахме ускорено възстановяване на база данни, въпреки че същият брой редове беше изтрит и в двете бази данни. Този път обаче имаме по-голямо използване на регистрационния файл на транзакциите в базата данни TSQLV4_NOADR.

Фиг. 7 Изтриване на времето за изпълнение за TSQLV4_NOADR

Фиг. 8 Изтриване на времето за изпълнение за TSQLV4_ADR

Фиг. 9 Използване на дневника на транзакциите след изтривания

Досега ставаше очевидно, че DML операциите отнемат повече време в бази данни с активиран ADR. Това отчасти обяснява защо функцията е изключена на първо място. Като се замисля задълбочено, има смисъл, тъй като SQL Server трябва да съхранява версиите на редовете в PVS, докато се изпълнява операция за вмъкване, актуализиране или изтриване. Каквото и време да отнеме DML, откриваме, че издаването на ROLLBACK с включен ADR отнема по-малко от 1 милисекунда (вижте фиг. 10 – 13). В някои случаи бързото връщане може да компенсира излишните разходи за самия DML, но не във всички случаи!

Фиг. 10 Време за изпълнение за ROLLBACK (след DELETE) на TSQLV4_NOADR

Фиг. 11 Време за изпълнение за ROLLBACK (след DELETE) на TSQLV4_ADR

Фиг. 12 Време за изпълнение за ROLLBACK (след INSERT) на TSQLV4_NOADR

Фиг. 13 Време за изпълнение за ROLLBACK (след DELETE) на TSQLV4_ADR

Заключение

Ускореното възстановяване на база данни е една от страхотните функции, пуснати в SQL Server 2019. Въпреки това, както при всички изключително хубави неща в живота, някой трябва да плати за това. ADR може да има отрицателно въздействие върху производителността в определени сценарии, така че е важно внимателно да оцените сценария си, преди да приложите ADR във вашата производствена база данни. Microsoft специално препоръчва ускорено възстановяване на база данни за бази данни, поддържащи натоварвания с много продължителни транзакции, прекомерен растеж на регистрационните файлове на транзакциите или чести прекъсвания, свързани с продължително възстановяване.

Препратки

  1. Ускорено възстановяване на база данни

  2. Как работи ускореното възстановяване на база данни?

  3. Ускорено възстановяване на база данни


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Лесен начин за транспониране на колони и редове в SQL?

  2. Низови функции на SQL Server (пълен списък)

  3. Съхранение и анализ на документи във файлова система на Windows със семантично търсене на SQL Server – част 2

  4. Вникване в уникалните ограничения на SQL Server

  5. Потребителска група на Charlotte SQL Server:Коригиране на бавни заявки. Бърз.