Przegląd tradycyjnego odzyskiwania
Podobnie jak w przypadku wszystkich relacyjnych systemów baz danych, SQL Server gwarantuje trwałość danych poprzez implementację odzyskiwania po awarii. Trwałość w akronimie ACID, który odnosi się do cech transakcji w relacyjnych bazach danych, oznacza, że możemy być pewni, że jeśli baza danych nagle ulegnie awarii, nasze dane są bezpieczne.
SQL Server implementuje tę możliwość przy użyciu dziennika transakcji. Zmiany wprowadzone przez wszystkie operacje manipulacji danymi w SQL Server są rejestrowane w dzienniku transakcji przed zastosowaniem do plików danych (poprzez proces punktu kontrolnego) na wypadek konieczności wycofania lub wycofania.
Trójfazowy proces odzyskiwania po awarii w SQL Server wygląda następująco:
Analiza – SQL Server odczytuje dziennik transakcji od ostatniego punktu kontrolnego do końca dziennika transakcji
Ponów – SQL Server odtwarza dziennik od najstarszej niezatwierdzonej transakcji do końca dziennika
Cofnij – SQL Server odczytuje dziennik od końca dziennika do najstarszej niezatwierdzonej transakcji i cofa wszystkie transakcje, które były aktywne podczas awarii
Doświadczeni administratorzy baz danych mieliby w pewnym momencie swojej kariery przygnębiające doświadczenie bezradnego oczekiwania na zakończenie odzyskiwania po awarii na bardzo dużej bazie danych. Transakcja ROLLBACK wykorzystuje podobny mechanizm jak proces odzyskiwania po awarii. Microsoft znacznie ulepszył proces odzyskiwania w SQL Server 2019.
Przyspieszone odzyskiwanie bazy danych
Przyspieszone odzyskiwanie bazy danych to nowa funkcja oparta na wersjonowaniu, która znacznie zwiększa szybkość odzyskiwania w przypadku ROLLBACK lub odzyskiwania po awarii.
W SQL Server 2019 trzy nowe mechanizmy w silniku SQL Server modyfikują sposób obsługi odzyskiwania i skutecznie skracają czas wymagany do wykonania wycofywania/przywracania zmian.
Przechowywanie wersji trwałych (PVS) – Przechwytuje wersje wierszy w danej bazie danych. Magazyn wersji trwałych można zdefiniować w oddzielnej grupie plików ze względu na wydajność lub rozmiar
Przywrócenie logiczne – Używa wersji wierszy przechowywanych w PVS, aby wykonać wycofanie, gdy wywoływane jest wycofanie dla określonej transakcji lub gdy wywoływana jest faza cofania odzyskiwania po awarii.
sDziennik – To prawdopodobnie oznacza drugorzędne dziennik . Jest to strumień dziennika w pamięci używany do przechwytywania operacji, których nie można wersjonować. Gdy ADR jest włączony w bazie danych, sLog jest zawsze odbudowywany w fazie analizy odzyskiwania po awarii. Podczas ponawiania sLog jest używany zamiast rzeczywistego dziennika transakcji, co przyspiesza proces, ponieważ znajduje się w pamięci i zawiera mniej transakcji. Tradycyjny proces odzyskiwania obsługuje transakcje z ostatniego punktu kontrolnego. sLog jest również używany podczas cofania faza.
Oczyszczacz – Usuwa niepotrzebne wersje wierszy z PVS. Microsoft zapewnia również procedurę składowaną, aby ręcznie wymusić czyszczenie niepotrzebnych wersji wierszy.
-- 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';
Przyspieszone odzyskiwanie bazy danych jest domyślnie WYŁĄCZONE
Fakt, że ADR jest domyślnie wyłączone w SQL Server 2019, może wydawać się zaskakujący dla niektórych administratorów baz danych, biorąc pod uwagę, że wydaje się to tak świetną funkcją. ADR korzysta z wersji w bazie danych użytkowników, w której jest włączony. Może to znacząco wpłynąć na rozmiar bazy danych. Ponadto może być konieczne zaplanowanie wzrostu bazy danych, a także ewentualnej lokalizacji PVS w celu zapewnienia dobrej wydajności, jeśli jest włączone ADR. Dlatego celowe włączenie tej funkcji ma sens.
Eksperyment:faza przygotowawcza
Zorganizowaliśmy eksperyment, aby zbadać nową funkcję i zobaczyć wpływ ADR na rozmiar dziennika transakcji, a także na szybkość ROLLBACK. W naszym eksperymencie tworzymy dwie identyczne bazy danych za pomocą jednego zestawu kopii zapasowych, a następnie włączamy ADR tylko na jednej z tych baz. Listing 2 pokazuje etapy przygotowania do zadania.
[rozwiń tytuł =”Kod”]
-- 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; [/rozwiń]
Rys. 1 przedstawia dane wyjściowe instrukcji SQL z Listingu 2, sekcja 2c. Przechwyciliśmy również rozmiar plików bazy danych i wykorzystanie pliku dziennika transakcji. (patrz rys. 3).
Rys. 1 Potwierdź, że ADR jest skonfigurowany
Rys. 2 Przejrzyj rozmiary plików danych bazy danych
Rys. 3 Sprawdź rozmiar dziennika używanego dla obu baz danych
Eksperyment:faza wykonania
Gdy zdobędziemy szczegółowe informacje, które musimy kontynuować, wykonujemy etapami kod SQL z Listingu 3 i 4. Te dwie listy są równoważne, ale wykonujemy je osobno na dwóch identycznych bazach danych. Najpierw wykonujemy INSERT (Listing 3, 3a), a następnie wykonujemy DELETE (Listing 3, 3b), które następnie cofamy. Zauważ, że zarówno w INSERT, jak i DELETE zawarliśmy operacje w transakcjach. Zwróć również uwagę, że INSERT jest wykonywane 50 razy. Na każdym etapie realizacji, tj. między 3a, 3b i 3c, rejestrujemy wykorzystanie dziennika transakcji za pomocą kodu z Listingu 2,2e. To samo dotyczy sekcji 4a, 4b i 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;
Rys. 4 i 5 pokazują, że operacja SELECT INTO zajęła 6 milisekund więcej w bazie danych TSQLV4_ADR, w której włączyliśmy przyspieszone odzyskiwanie bazy danych. Widzimy również na rys. 6, że mamy większe wykorzystanie dziennika transakcji w bazie danych TSQLV4_ADR. Byłem tym szczególnie zaskoczony, więc powtórzyłem eksperyment kilka razy, aby upewnić się, że otrzymuję ten wynik konsekwentnie.
Rys. 4 Wstaw czas wykonania dla TSQLV4_NOADR
Rys. 5 Wstaw czas wykonania dla TSQLV4_ADR
Rys. 6 Wykorzystanie dziennika transakcji po wstawieniu
-- 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;
Rys. 7 i 8 pokazują, że operacja DELETE zajęła znacznie więcej czasu w bazie danych TSQLV4_ADR, w której włączyliśmy przyspieszone odzyskiwanie bazy danych, mimo że w obu bazach usunięto tę samą liczbę wierszy. Tym razem jednak mamy większe wykorzystanie dziennika transakcji w bazie danych TSQLV4_NOADR.
Rys. 7 Usuń czas wykonania dla TSQLV4_NOADR
Rys. 8 Usuń czas wykonania dla TSQLV4_ADR
Rys. 9 Wykorzystanie dziennika transakcji po usunięciu
Do tej pory stało się oczywiste, że operacje DML trwają dłużej w bazach danych z włączonym ADR. To częściowo wyjaśnia, dlaczego ta funkcja jest wyłączona. Głębokie zastanowienie się nad tym ma sens, ponieważ SQL Server musi przechowywać wersje wierszy w PVS podczas wykonywania operacji wstawiania, aktualizowania lub usuwania. Niezależnie od tego, ile czasu zajmuje DML, okazuje się, że wydanie WYCOFANIA Z WŁĄCZONYM ADR zajmuje mniej niż 1 milisekundę (patrz Rys. 10–13). W niektórych przypadkach szybkie wycofanie może zrekompensować obciążenie samego DML, ale nie we wszystkich przypadkach!
Rys. 10 Czas wykonania dla ROLLBACK (po DELETE) na TSQLV4_NOADR
Rys. 11 Czas wykonania ROLLBACK (po DELETE) na TSQLV4_ADR
Rys. 12 Czas wykonania dla ROLLBACK (po INSERT) na TSQLV4_NOADR
Rys. 13 Czas wykonania ROLLBACK (po DELETE) na TSQLV4_ADR
Wniosek
Przyspieszone odzyskiwanie baz danych to jedna z najlepszych funkcji udostępnionych w SQL Server 2019. Jednak, podobnie jak w przypadku wszystkich niezwykle fajnych rzeczy w życiu, ktoś musi za to zapłacić. ADR może mieć negatywny wpływ na wydajność w niektórych scenariuszach, dlatego ważne jest, aby dokładnie ocenić scenariusz przed wdrożeniem ADR w produkcyjnej bazie danych. Firma Microsoft szczególnie zaleca przyspieszone odzyskiwanie baz danych w przypadku baz danych obsługujących obciążenia z bardzo długimi transakcjami, nadmiernym wzrostem dziennika transakcji lub częstymi awariami związanymi z długotrwałym odzyskiwaniem.
Odniesienia
Przyspieszone odzyskiwanie bazy danych
Jak działa przyspieszone odzyskiwanie bazy danych?
Przyspieszone odzyskiwanie bazy danych
