Що робити, якщо журнал транзакцій не очищається, навіть після DUMP TRAN WITH NO_LOG, MS SQL Server, Бази даних, статті

sql.ru

За матеріалами статті Q184499 «INF Transaction Log Still Full After DUMP TRAN WITH NO_LOG».
Зміст цієї статті належить до Microsoft SQL Server 6.0, 6.5

Після отримання повідомлення про помилку 1105, вказує на те, що журнал транзакцій (Transaction log) повністю заповнений, Ви повинні виконати наступну команду, яка усікається transaction log:

dump transaction <db> with no_log

Де – ім’я бази даних, зазначеної в повідомленні про помилку 1105.

Ця стаття розглядає кроки, які Ви повинні зробити, якщо вищезгадана команда не очищає transaction log.
Якщо, після виконання цієї команди, transaction log все ще залишається заповненим, Вам необхідно переконатися, що інформація про вільне місце в журналі транзакцій, отримана за допомогою SQL Enterprise Manager (SEM), Windows NT Performance Monitor або sp_spaceused, дійсно вірна і актуальна. Неправильне відображення інформації про величину заповнення журналу викликано існуванням помилки, яка описана в статті:
Q183100: PRB: Incorrect Log Size Reported in SEM or Performance Monitor
Розглянемо питання оновлення інформації про заповнювання журналу до актуального стану, в Як маленького відступу.
Суть статті Q183100 в тому, що після усічення переповненого transaction log, інформація про кількість вільного місця журналу, що зберігається в системній таблиці sysindexes, може не відповідати реальному стану. Викликано це, по перше, тим, що таблиця sysindexes не оновлюється безперервно, оскільки це могло привести до істотного падіння ефективності. По друге, Оновлення інформації в цій таблиці, як і будь-який інший таблиці бази даних, є реєстрованої в transaction log операцією. Коли transaction log переповнюється, модифікація sysindexes стає неможливою, в чому і полягає причина неточності міститься в ній інформації.
Щоб вирішити цю проблему, виконайте наступну інструкцію після усікання файлу реєстрації:

DBCC CHECKTABLE (syslogs)

У відповідь, Ви отримаєте звіт, приклад якого представлений нижче:

Checking syslogs
The total number of data pages in this table is 1.
The number of data pages in Sysindexes for this table was 4. It has been corrected to 1.
The number of rows in Sysindexes for this table was 128. It has been corrected to 12.
*** NOTICE: Space used on the log segment is 0.00 Mbytes, 0.10.
*** NOTICE: Space free on the log segment is 2.05 Mbytes, 99.90.
Table has 12 data rows.
DBCC execution completed. If DBCC printed error messages, see your System Administrator.

Використовуване і вільне місце в журналі, після цього, буде показано правильно, тому що DBCC CHECKTABLE простежить всі фактичні ланцюжка сторінки transaction log. Зверніть увагу на цей рядок звіту:

The number of rows in Sysindexes for this table was 128. It has been corrected to 12.

Це говорить про те, що DBCC CHECKTABLE також оновлює та значення таблиці sysindexes. Команда DBCC CHECKTABLE повинна виправити інформацію про вільний місці в базах і журналах, яка відображається в SQL Enterprise Manager або Performance Monitor. Однак, іноді Вам потрібно для отримання правильного результату виконати ще одну інструкцію:

DBCC UPDATEUSAGE (<db_name>)

ЗВЕРНІТЬ УВАГА: DBCC UPDATEUSAGE може працювати дуже довго. Ця команда поновлює значення dpages в sysindexes для всіх таблиць в базі даних, не тільки для syslogs.

Після цієї інструкції, відображення займаного місця повинно бути точним. Якщо це не так, пробуйте запустити команду CHECKPOINT, щоб зафіксувати ті зміни, які ще знаходяться в кеші. Також, можна використовувати кнопку Recalculate в SQL Enterprise Manager. Зверніть увагу, що ця кнопка запустить автоматичне виконання DBCC UPDATEUSAGE, що може зажадати тривалого виконання. Для отримання детальної інформації про вільне місце в базах даних і журналах, використовуйте команду:

DBCC SQLPERF (logspace)

На цьому наше маленьке відступ можна вважати закінченим, і ми повернемося до початкової теми цієї статті.

Якщо після застосування перерахованих вище команд:

USE <databasename>
GO
DBCC CHECKTABLE (syslogs)
GO
DBCC UPDATEUSAGE (<db_name>)
GO
CHECKPOINT
GO
DBCC SQLPERF (logspace)
GO

Ви все-таки бачите, що журнал транзакцій переповнений (99.99 відсотків), перевірте можливі причини, наслідком яких могло стати це переповнення. Можливі причини та способи їх усунення були представлені в минулому випуску розсилки, в статті Причини заповнення журналу транзакцій SQL серверів 4.2x, 6.0, 6.5, 7.0

ЗВЕРНІТЬ УВАГА: Якщо dump transaction НЕ усікається більшу частину Вашого transaction log, причиною цього можете бути відкрита транзакція. Визначити наявність відкритих / активних транзакцій можна за допомогою:

USE <databasename>
GO
DBCC OPENTRAN (<databasename>)
GO

У відповідь, Ви отримаєте звіт, приклад якого представлений нижче:

Transaction Information for database: pubs
No active open transactions.
Replicated Transaction Information:
Oldest Distributed RID_____: (0 , 0)
Time Stamp______________: 0001 0000000E
Oldest Non-Distributed RID_: (589 , 26)
Time Stamp______________: 0001 0000363E
DBCC execution completed. If DBCC printed error messages, see your System Administrator.

У представленому прикладом звіті відкритих транзакцій не зафіксовано, але якщо такі будуть виявлені, необхідно дочекатися їх завершення і повторити спробу очищення журналу транзакцій. Зауважте, що звіт вказує на відсутність відкритих транзакцій, але в блоці Replicated Transaction Information є рядки додаткової інформації, які показує, що база даних була відзначена для реплікації. Якщо буде видана інформація про реплікації, переконайтеся, що значення Oldest Distributed Transaction RID близько до Oldest Non-Distributed RID. Їх відмінність говорить про те, що існує реплікація, що виконується в Нині для цієї бази даних. Кількісне відмінність буде засновано на ряді змінних, що відносяться до реплікації, які виходять за рамки цієї статті. Вам достатньо зрозуміти, що база даних відзначена для реплікації і існують записи в transaction log, які цієї реплікацією використовуються.

ВАЖЛИВО: При виявленні активної реплікації, Ви спочатку повинні визначити, чому транзакції, відмічені для реплікації, не завершені. Продовжити подальшу роботу з очищення журналу Ви можете тільки після того, коли забезпечите і переконайтеся, що ця база даних не бере участь в реплікації. Для отримання додаткової інформації, див SQL SERVER BOOKS ONLINE або статтю в
Microsoft Knowledge Base: Q89937: INF: Getting Started with Microsoft SQL
Server Replication.

Для перевірки відсутності активної реплікації, виконайте наступний сценарій:

USE master
GO
sp_helpserver
GO

У відповідь, Ви отримаєте звіт, приклад якого представлений нижче:

name_______network_name_____status________id
—————————————————————–
CYGNUS____CYGNUS_________pub,sub,dis___0

Звіт відобразить роль Вашого сервера в реплікації. Якщо поле status пусте, сервер в реплікація не бере участь. Пам’ятайте, що сервер може брати участь в реплікації, але Ви повинні переконатися, що база даних з переповненим журналом в цих реплікація не бере участь:

SELECT name, category FROM master..sysdatabases
WHERE name = ‘<databasename>’
GO
USE <databasename>
GO
–The query will return all objects that are published (32) or
–replicated (64)
SELECT category FROM sysobjects
WHERE type = ‘U’ and category & 32 = 32 or category & 64 = 64

У відповідь, Ви отримаєте звіт, приклад якого представлений нижче:

name_______category<
————————–
pubs________0

(1 row(s) affected)

Інформація, яка відображається в полі category, показує, як база даних бере участь в реплікації. Якщо поле категорії містить 0, це означає, що база даних не видається.
Поле category видає інформацію про об’єкти. Якщо Ви отримуєте нульове кількість рядків, як показано нижче, це означає, що жодна з таблиць не включений в реплікацію.

name_______category
—————————

(0 row(s) affected)

Пам’ятайте, що Ви не видаляєте реплікацію, а тільки перевіряєте, що не існує ніяких об’єктів в цій базі, які зазначені для реплікації. Якщо такі об’єкти існують, Ви не повинні намагатися очистити transaction log; Ви повинні спочатку визначити, чому транзакції, відмічені для реплікації, не завершені.
Якщо реплікація для цієї бази даних все-таки була завершена, Ви, можливо, маєте на transaction log розподілені транзакції. Це може залишитися від реплікації, яка була встановлена ​​на цьому сервері раніше, і вона не була видалена повністю. Щоб вирішувати цю проблему, спробуйте наступний сценарій:

USE master
GO
sp_configure ‘allow’, 1
GO
reconfigure with override
GO
BEGIN TRAN
UPDATE master..sysdatabases set category = 1 where name = ‘<databasename>’
— verify that the correct row has been changed by running
— select name, category from sysdatabase where name = ‘<databasename>’
— if the correct row is changed then run the following
COMMIT TRAN

Цим Ви відзначили базу даних, як бере участь у реплікації. Ви можете визначати будь-які транзакції в журналі, що б вказати їх для реплікації, як розподілені.

sp_repldone 0, 0, NULL, 0, 0, 1

Ця процедура, що зберігається, добре описана в SQL SERVER BOOKS ONLINE. Розглянемо те, що ця команда робить:
Коли page = 0, row = 0 і reset = 1 все Реплікаційний транзакції в журналі відзначаються, як розподілені. Це корисно, коли є Реплікаційний транзакції в transaction log, від яких потрібно позбавиться (наприклад, реплицируемой таблиця була видалена), після чого, Ви хочете зробити усічення журналу транзакцій. Наприклад, після того, як зазначена вище процедура, що зберігається успішно відпрацювала, Ви можете спробувати очистити transaction log за допомогою:

DUMP TRAN <databasename> WITH NO_LOG

Для перевірки стану журналу транзакцій, виконайте наступну команду:

DBCC CHECKTABLE(syslogs)

Transaction log повинен тепер бути порожній.

ЗВЕРНІТЬ УВАГА: оскільки Ви очистили transaction log, Ви повинні виконати повне резервне копіювання вашої бази даних, інакше записи журналу не можливо буде виносити в резервну копію. Зверніться до SQL SERVER BOOKS ONLINE для отримання додаткової інформації по відновленню і резервування баз даних.
Після завершення очищення журналу необхідно повернути змінені настройки в початковий стан:

— Set any object marked for replication as not published or replicated
UPDATE sysobjects set category = category & ~32
UPDATE sysobjects set category = category & ~64
USE master
GO
— Set the database as not published update sysdatabases set category = 0 where name = ‘<databasename>’
sp_configure ‘allow’,0
GO
RECONFIGURE with override
GO

ЗАУВАЖЕННЯ АВТОРА ПЕРЕКЛАДУ: Але, якщо навіть після всіх, представлених вище маніпуляцій, Ваш журнал транзакцій залишиться не очищеним, можна застосувати зовсім вже кардинальне засіб. Спробуйте зменшити розмір бази даних засобами Enterprise Manager до мінімально – можливого розміру. Якщо вільного місця в базі багато, але Enterprise Manager не дає значно зменшити розмір, це говорить про високу фрагментації даних. Вам доведеться провести дефрагментацію даних, варіанти якої вже розглядалися в розсилці. Після цього зменшення розміру бази повинно бути значним. Далі, увійдіть або перестартуйте сервер і поверніть розмір бази до первісного стану. Якщо після цього повторити описані в статті Микрософт процедури, журнал реєстрації транзакцій повинен очиститися. Не знаю чому, але іноді тільки така струс дозволяє позбавиться від застряглих в журналі записів.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*