Какво е регистър на транзакциите?
В системите за релационни бази данни има изискване транзакциите да са трайни. Това е „D“ в свойствата на ACID на транзакциите. Системата трябва да гарантира, че ако се случи внезапен срив, транзакцията може да бъде възпроизведена. SQL Server изпълнява това изискване, като улавя всички транзакции във физически файл, наречен регистрационен файл на транзакциите .
По същество, всеки път, когато транзакция е ангажирана, SQL Server записва промените, направени от тази транзакция, в регистър на транзакциите. Дори ако транзакцията не е била запазена във файла с данни, тя е налична в регистъра на транзакциите и може да бъде възпроизведена отново в случай на внезапен срив.
Модели за възстановяване и регистрационни файлове на транзакциите
SQL Server работи под три модела за възстановяване – пълен, групово регистриран и прост.
В режима на пълно възстановяване ВСИЧКИ транзакции се регистрират. По този начин базата данни може да бъде напълно възстановена, ако се случи срив. Това също означава, че резервното копие на базата данни може да бъде възстановено до определен момент от време, ако транзакцията или свързаното архивиране са налични. В режимите на пълно и групово възстановяване регистрационните файлове на транзакциите се съкращават всеки път, когато има изпълнено архивно копие.
В режима на Simple Recovery ВСИЧКИ транзакции все още се записват. Въпреки това, операцията в регистъра на транзакциите се съкращава всеки път, когато базата данни изпълнява контролната точка.
Контролна точка се случва, когато SQL Server записва мръсни буфери във файла с данни. Мръсните буфери са основни страници, съхранявани в паметта, които са били променени от транзакции, като например състоянието в паметта не съвпада със състоянието на диска. Тук обаче няма да обсъждаме това. В режим Simple Recovery, SQL Server улавя всички тези промени в дневника на транзакциите, за да ги запази, докато не бъдат запазени.
Структурата на регистрационния файл на транзакциите
Регистърът на транзакциите е физически файл, видим на слоя на ОС на сървъра, където се хоства базата данни на SQL Server. Всяка база данни има един регистър на транзакциите, но е възможно да се конфигурират повече. Работата е там, че наличието на множество транзакционни SQL регистрационни файлове не носи никакви предимства в производителността. SQL Server записва в регистъра на транзакциите последователно – един файл трябва да е пълен, преди следващият файл да започне да се използва. Въпреки това, множество файлове, разположени на отделни дискове, може да спасят деня, ако първият файл се запълни.
Вътрешно регистрационният файл на транзакциите е поредица от виртуални регистрационни файлове. Размерът и броят на тези файлове оказват влияние върху времето, необходимо за архивиране на базата данни или пренасянето й онлайн. Винаги е добра идея да оразмерите правилно дневника на транзакциите и да гарантирате, че настройките за автоматичен растеж отговарят на очакваното ниво на активност. Тогава нарастването на файловете няма да се случва твърде често.
Какво кара дневника да расте?
Нека започнем със създаване на малка база данни, използвайки кода в листинг 1. Файлът с данни е с размер 4MB, регистрационният файл е 2MB за начало. Вашите производствени бази данни никога няма да имат такъв размер, особено с популярната практика на предварително разпределение . Избрахме такива размери само за демонстрационни цели.
-- Listing 1: Create a Small Database
create database tranlogexperiment
on primary
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go
В тази база данни създаваме единична таблица за допълнителните изрази на езика за манипулиране на данни (DML) (листинг 2).
-- Listing 2: Create a Table
use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)
Като изпълним кода в листинг 3, ние проверяваме и потвърждаваме какво сме направили.
-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';
select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');
Обърнете внимание на Размера на файла колона. Продължаваме да извикаме растежа на регистъра на транзакциите, като стартираме INSERT и DELETE 100 000 пъти (листинг 4).
-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000
Списък 4 вмъква един ред в txn_log таблица и изтрива същия ред, повтаряйки това действие 100 000 пъти.
Като цяло таблицата не нараства поради тази дейност, но регистрационният файл на транзакциите нараства значително. Когато повторим заявката в листинг 3, след като изпълним DML израза от листинг 4, виждаме колко е нараснал регистърът на транзакциите:
Регистърът на транзакциите нарасна от 4MB на 40MB поради тази дейност, въпреки че размерът на файла с данни не е променен. Това ясно ни показва, че размерът на регистрационния файл на транзакциите няма много общо с размера на данните. Въздействието върху размера е от дейността (DML), която се случва в базата данни.
Как управляваме регистрационните файлове на транзакциите?
Администраторите на бази данни, които управляват локални екземпляри на SQL Server на IaaS инсталации, трябва редовно да архивират архивирането на регистрационните файлове на транзакциите. Полезно е да имате конфигурации за възстановяване при бедствия, като Изпращане на регистрационни файлове или AlwaysOn AG . Такива конфигурации правят резервните копия автоматично.
В режим на пълно възстановяване резервното копие на регистрационния файл на SQL Server ще съкрати частите на дневника на транзакциите, които вече не са необходими за възстановяване. Съкращаването на журнала изтрива неактивните виртуални регистрационни файлове. По този начин изчиства място в регистрационните файлове на транзакциите за повторна употреба.
Кодът в листинг 6 показва размера на регистъра на транзакциите и колко свободно място имаме в него.
-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name],
name AS [Logical File Name],
type_desc,
size/128.0 AS [Current Size (MB)],
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);
Можем също да свием физическия дневник на транзакциите, като използваме кода в листинг 7. Преди да свиете, уверете се, че имате резервно копие на дневника на транзакциите. В производството е най-добре да планирате архивирането на регистрационни файлове, за да избегнете неконтролиран растеж на физически регистрационни файлове и да гарантирате запазването на данните. С опцията за възстановяване при бедствия като Изпращане на дневници или AlwaysOn AG конфигуриран, това вече е разрешено.
Можем да направим заявка за log_reuse_wait_desc колона в sys.databases изглед на каталог, за да определите всички условия, които предотвратяват свиването на регистъра на транзакциите. Забележете, че направихме заявка за тази колона в листинг 3.
Такива условия могат да бъдат чакаща контролна точка, чакащо архивиране на регистрационни файлове, текущо архивиране или възстановяване, активна продължителна транзакция и подобни дейности в базата данни.
-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO
Използваме кода в листинг 8, за да архивираме базата данни. В нашия конкретен случай първо трябва да направим пълно архивиране, тъй като архивирането на регистрационни файлове винаги препраща към пълно архивиране. „Последното“ пълно архивиране стартира веригата, когато се занимава с възстановяване в даден момент.
-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';
Когато стартирате база данни в режим Simple Recovery, дневникът на транзакциите се съкращава при всяка контролна точка . В този режим архивирането на регистрационни файлове не е възможно.
Местоположението на регистрационния файл на транзакциите трябва да бъде оразмерено правилно, за да побере дългосрочните транзакции, които се случват от време на време. В противен случай регистърът на транзакциите все още може да запълни дисковото пространство. Фигура 4 показва какво се случва с дневника вътрешно, когато се направи резервно копие. Забележете, че физическият файл все още е 40 MB, но вече имаме около 37 MB свободно пространство.
Какво се случва в прост режим на възстановяване?
Сега нека зададем tranlogexperiment база данни в режим на просто възстановяване.
-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;
Когато изпълним кода, представен по-рано в листинг 4, ще получим малко по-различно поведение.
Фигура 6 показва нарастването на регистрационния файл на транзакциите в режим Simple Recovery, когато изпълняваме кода в листинг 4. Размерът на физическия регистрационен файл е само 15 MB. Това е наполовина по-малко, отколкото беше при модела за пълно възстановяване по-рано. Също така, обърнете внимание на свободното пространство от 11,5 MB.
Това означава ли, че е имало по-малко нарастване на дневника?
Не. Фигура 7 показва, че докато сесията се изпълняваше, нашият SQL Server също изпълнява няколко контролни точки. Това съкрати дневника и даде място на транзакциите да възобновят нарастващия дневник на интервали.
Заключение
Регистърът на транзакциите е изключително важен компонент на база данни на SQL Server. Той засяга всичко, което изисква или разчита на възстановяване – архивиране, възстановяване, възстановяване при бедствия и така нататък. Можете също да регистрирате db активност.
В тази статия обсъдихме естеството на регистрационния файл на транзакциите, аспектите на правилното му управление и демонстрирахме поведението на DML в бази данни с режим на пълно или просто възстановяване. Въпреки това, има още много какво да научите за регистъра на транзакциите. Записите в препратките биха били добра отправна точка за вас.
Справка s
- Регистър на транзакциите
- SQL сървърни бази данни и съхранение
Прочетете също
Значение на регистъра на транзакциите в SQL Server
