Зміст файлу журналу транзакцій більш детально

У мене є питання щодо вмісту журналу транзакцій (назвемо його коротко LDF). Я припускаю базу даних з повною моделлю відновлення.

Я прочитав, що файл LDF містить (журнали) кожну операцію з базою даних (тобто в повному режимі відновлення). Чим вона відрізняється від ведення журналу BEGIN TRAN; COMMAND(s); COMMIT? Я прошу, тому що, мабуть, ви можете відмовити транзакції, але не можете відмовити стандартні команди (у повному режимі відновлення).

Я здогадуюсь, що під час транзакції вміст, який увійшов у файл LDF, відрізняється, ніж у звичайних журналах повного відновлення. Це так? Як це відрізняється? Це лише включення операцій "скасувати" для кожної дії?

У відповідній записці я чув, що існують комерційні інструменти для "відкату / скасування" стандартних запитів, використовуючи повний файл відновлення LDF. Як вони це роблять? Чи аналізують вони вміст LDF і намагаються придумати операції обернення / скасування?

Різниця полягає в тому, що те, що ви називаєте "стандартними командами", має неявні транзакції (як у "не явних", а не реальних неявних транзакцій, що означають щось інше ), тому кожен раз, коли ви видаєте INSERTкоманду без явної транзакції, вона відкриє транзакцію, вставити дані та автоматично зробити. Це називається транзакцією автокомісії.

Ось чому ви не можете цього відкатати INSERT: це вже зроблено. Таким чином, правило те саме, що явні транзакції: ви не можете відкатати після їх вчинення .

Ви можете бачити, що я маю на увазі безпосередньо з сервера SQL.

Microsoft постачає SQL Server з DMF, який називається, sys.fn_dblogякий може використовуватися для пошуку в журналі транзакцій для даної бази даних.

Для цього простого експерименту я буду використовувати базу даних AdventureWorks:

USE AdventureWorks2008;
GO

SELECT TOP 10 *
FROM dbo.Person;
GO

INSERT INTO dbo.Person (FirstName, MiddleName, LastName, Gender, Date)
VALUES ('Never', 'Stop', 'Learning', 'M', GETDATE());
COMMIT;

BEGIN TRAN;
INSERT INTO dbo.Person (FirstName, MiddleName, LastName, Gender, Date)
VALUES ('Never', 'Stop', 'Learning', 'M', GETDATE());
COMMIT;
GO

SELECT *
FROM sys.fn_dblog(NULL, NULL);
GO

Тут я роблю дві вставки: одну з і одну без явної транзакції.

У файлі журналу ви бачите, що різниці між ними абсолютно немає:

Червоний - INSERTце операція автокомісії, а синя - INSERTявна транзакція.

Що стосується сторонніх інструментів, які ви згадуєте, так, вони аналізують журнал бази даних і генерують звичайний код T-SQL, щоб "скасувати" або "повторити" операції. Звичайно, я маю на увазі, що вони не роблять нічого іншого, окрім як генерувати сценарій, який матиме ефект, прямо протилежний тому, що є у файлі журналу.

Я поясню, як працюють комерційні інструменти, на прикладі журналу ApexSQL

І на відповідній ноті я чув, що є комерційні інструменти для "відкату / скасування" стандартних запитів, використовуючи повний файл відновлення LDF. Як вони це роблять? Чи аналізують вони вміст LDF і намагаються придумати операції обернення / скасування?

Так, вони читають файл LDF (в Інтернеті чи окремі) та trn-файли (резервні копії журналу транзакцій), знаходять, яка транзакція відбулася, і створюють сценарій, який буде робити те саме чи протилежне.

Зауважте, що сценарій скасування та повторення не повинен бути точно таким же, як виконані, але ефект буде точно таким же.

Наприклад, якщо виконаний сценарій був:

DELETE FROM [Person].[AddressType] WHERE Name  = 'New Loc22'

Журнал транзакцій записує, що рядок у таблиці зі значеннями стовпця 9, "New Loc22", "41BC2FF6-F0FC-475F-8EB9-CEC1805AA0F6", а "2002/06/01 00: 00: 00,000" видалено. З структури таблиці інструмент прочитає, що Первинний ключ - це стовпець AddressType, і створить наступний повторний сценарій:

DELETE FROM [Person].[AddressType] WHERE [AddressTypeID] = 9

Зауважте, що транзакція прив’язана до стовпця Первинний ключ, а не до стовпця, який використовується в оригіналі пункту де. Аналогічно, сценарій скасування буде таким:

INSERT INTO [Person].[AddressType] ([AddressTypeID], [Name], [rowguid], [ModifiedDate]) VALUES (9, N'New loc22' COLLATE SQL_Latin1_General_CP1_CI_AS, '41bc2ff6-f0fc-475f-8eb9-cec1805aa0f6', '20020601 00:00:00.000')

Відмова: Я працюю в ApexSQL як інженер підтримки