Зараз ви перебуваєте в автономному режимі; очікується повторне підключення до Інтернету

Журнал транзакцій росте несподівано або стає повний в SQL Server

ВАЖЛИВО! Ця стаття перекладена засобами машинного перекладу Microsoft. Статтю можна редагувати в середовищі Community Translation Framework (CTF). Щоб якомога швидше перекласти всі статті у своїй базі знань різними мовами, компанія Microsoft не лише звертається до професійних перекладачів, але й вдається до машинного перекладу, який потім редагується спільнотою. Такі статті можуть містити лексичні, синтаксичні та граматичні помилки. Microsoft не несе відповідальності за будь-які неточності, помилки або збитки, до яких може призвести неправильний переклад статей або їх використання. Докладніше про CTF див. на веб-сторінці http://support.microsoft.com/gp/machine-translation-corrections/uk-ua.

Клацніть тут, щоб переглянути цю статтю англійською мовою: 317375
Підсумки
Якщо на автоматичне Збільшення належним чином установлено Microsoft SQL Server 2005 і пізніших версій SQL Server 2000 та SQL Server 7.0, файли журналу транзакцій може розширити автоматично розміру Максимальна лог-файл з 2 терабайт (ТБ) в лог-файл.

Як правило, розмір файл журналу транзакцій стабілізує, коли він може вмістити максимальну кількість операцій, які можуть виникнути між транзакції журналу truncations, які запускаються на контрольно-пропускних пунктів або резервні копії журналу транзакцій.

Однак, в деяких випадках транзакції увійти травня стали дуже великий і бігти з місця або стати повною. Як правило, з'являється таке протокол IMAP про помилку, коли файл журналу транзакцій використовує доступного дискового простору і не може розширюватися, більше:
Помилка: 9002, тяжкості: 17, держава: 2
Лог-файл для бази даних "%. * ls' заповнено.
Якщо використовується SQL Server 2005, з'являється протокол IMAP про помилку, подібне до такого:
Помилка: 9002, тяжкості: 17, держава: 2
Журнал транзакцій для бази даних "%. * ls' заповнено. Щоб з'ясувати, чому простору в журналі подій не можуть бути використані, побачити sys.databases, стовпець log_reuse_wait_desc
На додаток до цього протокол IMAP про помилку SQL Server може позначити баз даних як підозрюваний через брак місця для розширення журналу транзакцій. Щоб отримати додаткові відомості про те, як відновити з цієї ситуації див "Бракує дискового простору" у SQL Server Books Online.

Крім того, розширення журналу транзакцій може виникнути для однієї з таких причин, або в одному з таких сценаріїв:
  • файл журналу транзакцій дуже великий.
  • Транзакцій може не спрацювати і може почати відкотити.
  • Транзакцій може зайняти багато часу, щоб завершити.
  • Можуть виникнути проблеми з продуктивністю.
  • Блокування може статися.
  • База даних бере участь у послугами AlwaysOn наявність групи.
Додаткові відомості
Розширення журналу транзакцій може виникнути для однієї з таких причин або сценаріїв.


Примітка. В SQL Server 2005 і пізніших версій можна переглянути log_reuse_wait і log_reuse_wait_desc стовпців sys.databases каталог подання елементів визначити, чому простору журналу транзакцій не повторно і чому журнал транзакцій не може бути скорочено.


Незадіяними угода TRIPs
Явні операції залишаються незадіяними, якщо ви не випускати явний команду ЗАВЕРШИТИ або ВІДКОТИТИ. Це відбувається, найбільш часто, коли додаток видає за скасування або оператори Transact-SQL ВБИТИ команду без відповідної команди ВІДКОЧУВАННЯ. Анулювання операції відбувається, але він не відкотити. Таким чином, SQL Server не може скоротити кожної операції, яка виникає після цього, тому що перерваного транзакція – залишається відкритим. За допомогою посилання DBCC OPENTRAN оператори Transact-SQL для перевірки активну операцію в базу даних на певний Вільний час. Щоб отримати додаткові відомості про цього конкретного сценарію клацніть номер статті в базі знань Microsoft Knowledge Base:
295108 Неповні транзакцій може провести велику кількість замків і випадку блокування
171224 Розуміння того, як працює ВБИТИ оператори Transact-SQL команд
Крім того, див "DBCC OPENTRAN" в SQL Server Books Online.

Сценарії, які можуть призвести до незадіяними операцій:
  • Застосування дизайн, який припускає, що всі помилки causerollbacks.
  • Дизайну додатків, які не повністю вважає SQL Server поведінки коли це здійснить відкочування до іменованого угода TRIPs або спеціально вкладені названий угода TRIPs. Якщо ви спробуєте відкотити внутрішнє ім'я обробку транзакції, з'являється таке протокол IMAP про помилку:
    Сервер: Msg 6401, рівень 16, держава 1, лінії 13 неможливо відкотити InnerTran. Знайдено Notransaction або до точки збереження з відповідною назвою.
    Після SQL Servergenerates протокол IMAP про помилку він як і раніше на наступному заяві. Це bydesign. Для отримання додаткової інформації див "Вкладені операції" або "Всередині SQLServer" в SQL Server Books Online.

    Ми рекомендуємо наступне, під Вільний час створення застосунку:
    • перо лише одну трансакцію одиниці (розглянути можливість, що інший процес може викликати твоє).
    • Перевірити @@TRANCOUNT, перш ніж ви оформити за COMMIT, за ВІДКАТ, повернення, або аналогічні команди або заяву.
    • Писати свій код в припущенні, що ще один @@TRANCOUNT може "гніздо" твоє і плану для зовнішніх @@TRANCOUNT для прокату, тому, коли виникає помилка.
    • До точки збереження і Марк параметри рецензування за операції. (Це не звільняє замків!)
    • Виконувати повне приймальні випробування.
  • Програма, що дозволяє для взаємодії з користувачем всередині угода TRIPs. Це викликає транзакції залишатися відкритим протягом тривалого часу, і цієї причини блокування та оцінки ризиків увійти зростання, тому що відкриті транзакцію не вдалося скорочено і нові угода TRIPs буде додано до журналу після відкритого транзакції.
  • Застосунок, який не перевірити @@TRANCOUNT для verifythat там немає відкритих угода TRIPs.
  • Мережі або інші помилки, які закрити applicationconnection клієнта до сервера SQL не попередивши його.
  • Організація пулу з'єднань. Після того, як створюються робочі потоки, SQL Server повторно їх, якщо вони не обслуговування підключення. Якщо підключення користувач починає транзакцію і відключає перед здійсненням або Відкочування транзакції і підключення після того, як що повторно тому ж потоці, попередня угода ще залишається відкритим. Така ситуація призводить до замків, які залишаються відкритими від попередньої операції і запобігає усікання здійснюваних операцій у журналі. Це призводить до великим лог файлу розмірів. Щоб отримати додаткові відомості про організації пулу підключень клацніть номер статті для перегляду статті в базі знань Microsoft Knowledge Base:
    164221 Як включити підключень за допомогою застосунку ODBC


Дуже великі угода TRIPs
Журнал записів у файлах журналу транзакцій скорочуються на основі транзакцій за транзакцію. Якщо транзакції сфера є великими, що транзакції та будь-яких операцій почав після того, як вона не видаляються з журналу транзакцій, якщо він буде завершений. Це може призвести до великих лог-файли. Якщо транзакція є досить великий, лог-файл може використовувати доступного дискового простору і викликати "журнал транзакцій повний" тип повідомлень про помилку помилка 9002. Щоб отримати додаткові відомості про те, що робити в разі отримання такого протокол IMAP про помилку розділі "Додаткові відомості" в цій статті. Крім того, це займає багато часу і SQL Server ВЛ до відкотити значних правочинів.

Операції: DBCC DBREINDEX та створити ПОКАЖЧИК
Через зміни в моделі відновлення в SQL Server 2000 коли ви використовуєте режим повного відновлення і запустити DBCC DBREINDEX, журнал транзакцій може розширити в значно більш порівнянні з SQL Server 7.0 в еквіваленті відновлення режимі з використанням SELECT INTO або копіювання блока даних і з "Trunc. Вийдіть на chkpt.».

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

Вільний час відновлення резервні копії, журнал транзакцій
Це описано в наступній статті бази знань Майкрософт:
232196 Журнал простір, що використовується, як видається, зростати після відновлення з резервної копії

Якщо встановлено SQL Server 2000 використовувати режим навалом увійшли і видавати КОПІЮ НАВАЛОМ або SELECT INTO заяву, кожен змінених мірою позначені і потім архівувати, під Вільний час резервного копіювання журнал транзакцій. Хоча це дозволяє повернутися до журналів транзакцій і оговтатися від невдачі, навіть після того, як ви виконуєте масові операції, таким чином буде додано до розміру журналів транзакцій. SQL Server 7.0 не включає в себе цю функцію. SQL Server 7.0 лише запис А бізнес-партнера, які розміри змінюються, але не записує фактичного розподілення екстентів. Таким чином, ведення журналу використовує значно більше місця в SQL Server 2000, чим в SQL Server 7.0 в режимі групового журналу, але не настільки, як у повному режимі.

Клієнтських застосунків не обробляти всі результати
Якщо видавати запит до SQL Server, і ви не обробляти результати негайно, ви можете Холдинг замки і зменшення паралелізм на сервері.

Припустимо, що ви видавати запит, який вимагає рядки з двох сторінок для заповнення результуючого набору. SQL Server розбирає компілює та виконується запит. Це означає, що спільній замки додаються на дві сторінки, які містять рядки, які ви повинні мати, щоб задовольнити Ваш запит. Крім того, припустимо, що не всі рядки поміщається на 1 пакетика SQL Server TDS (метод, за допомогою якого сервер спілкується з клієнтом). Пакетів TDS заповнені і відправили до клієнта. Якщо всі рядки з першої сторінки вміщується на пакетів TDS, SQL Server релізи спільних блокування на цій сторінці, але залишає спільних блокування на другій сторінці. Потім SQL сервер чекає клієнт просити більше даних (ви можете зробити це за допомогою DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults або FetchLast/FetchFirst наприклад).

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

Запитування тайм-аут, перш ніж журнал транзакцій закінчує розширення, і ви отримаєте помилкових журналу повний протокол IMAP про помилки
У цій ситуації Хоча немає достатньо місця на диску, все одно з'являється протокол IMAP про помилку "бракує місця".

Ця ситуація змінюється для SQL Server 7.0 і SQL Server 2000.

Запит може призвести до автоматично розгортати, якщо журнал транзакцій майже заповнено, журнал транзакцій. Цей процес триватиме додатковий Вільний час, і запит може бути зупинені або може перевищувати його період у зв'язок "один-до-одного" з цим. SQL Server 7.0 повертає помилку 9002 в цій ситуації. Це питання не поширюється на SQL Server 2000.

У SQL Server 2000 якщо не потрібно Автоматичне стискання , ввімкнутий в базу даних, є дуже малий Вільний час, протягом якого журнал транзакцій намагається автоматично розгортати. Однак, не може розширюватися, оскільки функція Автоматичне стискання виконується в той же Вільний час. Це також може викликати помилкові екземпляри помилка 9002.

Як правило, автоматичний розширення файлів журналу транзакцій відбувається швидко. Проте, в таких ситуаціях, це може зайняти більше часу, ніж звичайно:
  • Зростання прирости виглядаються надто малими.
  • Сервер є повільним з різних причин.
  • Дисководи не є досить швидко.


Unreplicated угода TRIPs
Розмір журналу транзакцій бази даних застосунку publisher можна деталізувати, якщо ви використовуєте реплікацію. Операції, які впливають на об'єкти, які реплікуються позначені як "Для реплікації". Ці операції, такі як незадіяними угода TRIPs, не видаляються після контрольно-пропускному пункті, або після того як ви архівувати журнал транзакцій поки читачів журналу завдання копіює операції на розподіл баз даних і скасування позначення їх. Якщо проблему з читачів журналу завдань запобігає його читання цих операцій в базі даних застосунку publisher , розмір журналу транзакцій може продовжувати розширюватися як кількість операцій нереплікованою збільшується. За допомогою посилання DBCC OPENTRAN оператори Transact-SQL для ідентифікації найстаріших нереплікованою транзакції.

Докладніше про усунення unreplicated угода TRIPs перегляньте теми "sp_replcounters" і "sp_repldone" в SQL Server Books Online.

Щоб отримати додаткові відомості, клацніть номер статті в базі знань Майкрософт:
306769 FIX: Журнал транзакцій з опублікованою базою даних знімок не може скорочено
240039 FIX: DBCC OPENTRAN не повідомляти про реплікації відомості
198514 FIX: Відновлення новий сервер викликає угода TRIPs залишаються в журнал


AlwaysOn 'AVAILABILITY_REPLICA', застосовуючи записів журналу транзакцій на речення

У SQL Server 2012 з AlwaysOn наявність групи включений бачите наступні протокол IMAP в журнал помилок SQL:

Помилка: 9002, тяжкості: 17, держава: 9.
Журнал транзакцій для бази даних "%. * ls' є повним завдяки 'AVAILABILITY_REPLICA'

AVAILABILITY_REPLICA log_reuse_wait вказує на вторинному репліки AlwaysOn наявність групи застосування запису журналу транзакцій цю базу даних до відповідного речення.

Є два сценарії, які можуть призвести до зростання увійти бази даних на наявність та на AVAILABILITY_REPLICA' log_reuse_wait:

Сценарій 1: Затримки доставки увійти зміни вторинний

Коли транзакцію виступали на первинні, увійшли блоки повинні бути доставлені і загартовані до лог-файл бази даних в вторинними. Будь-яка затримка запобіжить усікання цих увійшли змін в базі даних в основною реплікою.

Сценарій 2: Повторити затримки

Як тільки загартовані до файлу журналу речення потік присвячений повторити застосовує записів журналу.

Якщо повторити операцію не може йти в ногу з журналу транзакцій генерується, він потенційно може привести до реєструвати зростання. Первинний буде не вдалося скоротити журнал транзакцій, якщо вторинних репліки повторити операцію за цим стоїть у застосуванні ці зміни на відповідні речення. Якщо існує більше одного середніх, щоб визначити базу даних, яку вторинних затримує журналу усікання, порівняння truncation_lsn стовпців подання елементів динамічного керування sys.dm_hadr_database_replica_states різних кілька прояви вторинного сифілісу.

Ви можете скористатися перевагою інформаційною панеллю AlwaysOn і sys.dm_hadr_database_replica_states динамічного керування подання елементів, щоб допомогти контролювати журналі відправляти черги і повторити черги. Деякі ключові поля є:

ПолеОпис
log_send_queue_sizeКількість журнал записів, які не прибули на вторинному репліки
log_send_rateКурс, в яких журнал записів були відправлені до вторинного баз даних
redo_queue_sizeКількість записів журналу в лог-файлах вторинних репліки, яка не ще була перероблена, (Кбайт)
redo_rateШвидкість, з якою записів журналу є перероблено на заданому речення у кілобайтах (Kб) / друга
last_redone_lsnФактична журналу порядковий номер останнього запису журналу, що було перероблено на вторинному бази даних. last_redone_lsn завжди є менше, ніж last_hardened_lsn
last_received_lsnувійти блок ID визначення точки до якого всі журналу блоки були отримані вторинних реплікою, якому розміщено цього речення. Відображає лог блок ID доповнюється з нулем. Це не є фактичним журналу порядковий номер.

Примітка. Щоб отримати додаткові відомості про перегляд sys.dm_hadr_database_replica_states побачити веб-сайту TechNet:

http://TechNet.Microsoft.com/EN-US/Library/ff877972.aspx



Докладні відомості
Журнал транзакцій для будь-якого бази даних управляється як набір віртуальних лог-файли (VLFs). SQL Server визначає розміри файлів VLF всередині країни на основі загальний розмір файлу журналу та приросту зростання, який використовується при розширенні журналу. Журнал завжди розширюється в одиницях весь VLFs, і це тільки може стискати до меж VLF. На VLF може існувати в одному з трьох станів: активний, яку можна виправити і БАГАТОРАЗОВОГО.
  • АКТИВНІ: активну участь журналі починається в мінімальний журналу порядковий номер (LSN) який представляє активні (незадіяними) операції. Активну участь у журналі закінчується в останній написаний LSN. Вважаються будь-які VLFs, що містять будь-яку частину активної журналу активні VLFs. (незайнятого простору в фізичний журнал не є частиною будь-якого VLF.)
  • Можна виправити: частиною журналу, який приходить до найстаріших активну операцію тільки є необхідним для підтримання послідовність журналу резервні копії для відновлення.
  • Багаторазового сценарій виконання: Якщо ви не працюєте резервні копії журналу транзакцій, або якщо youalready архівувати журналу, SQL Server повторно VLFs до найстаріших activetransaction.
Коли SQL Server досягає кінця фізичної лог-файл, він починає, повторне сценарій виконання цього простору у файлі фізичної шляхом видачі КРУЖЛЯТИ назад операції на початок файли. По суті, SQL Server переробляє простору в лог-файл, який не є необхідним для відновлення або архівувати цілей. Не якщо підтримується журналу резервного копіювання послідовності, частиною журналу до мінімуму LSN може бути перезаписаний поки резервного копіювання або зменшіть ті запис А бізнес-партнера журналу. Після того, як ви виконувати архівувати журналу, SQL Server може коло повернутися до початку файлу. Після того, як SQL Server кола назад, до початку вводу записів журналу раніше у файл журналу, багаторазових частиною журналу, то між кінцем логічних журналу та активну участь лага.

Для отримання додаткової інформації див "Операції фізичних архітектура колоди" в SQL Server Books Online. Крім того, ви можете побачити схему та обговорення цього на сторінці 190 "всередині SQL Server 7.0" (Soukup, Рон. Всередині Microsoft SQL Server 7.0, Microsoft Press, 1999) а також на сторінках 182 186 "всередині SQL Server 2000" (Делані, Kalen. Всередині Microsoft SQL Server 2000, Microsoft Press, 2000). Баз даних SQL Server 2000 і SQL Server 7.0 мати варіанти, щоб автоматичне Збільшення належним чином і autoshrink. За допомогою цих параметрів можна допомогти вам стиснути або деталізувати журнал транзакцій.

Для отримання додаткової інформації про те, як ці параметри можуть впливати на сервер, клацніть номер статті в базі знань Microsoft Knowledge Base:
315512 Міркування для автоматичне Збільшення належним чином і Autoshrink конфігурації в SQL Server
Урізання файл журналу транзакцій відрізняється від стиснення файл журналу транзакцій. Коли SQL Server обрізає файл журналу транзакцій, це означає, що вміст цього файлу (наприклад, здійснюваних операцій) видаляються. Однак, під Вільний час перегляду розмір файлу з точки зору дискового простору (наприклад, у провіднику Windows або за допомогою команди dir ), розмір залишається незмінним. Тим не менш, простору всередині .ldf файл тепер може бути повторно нові угода TRIPs. Тільки тоді, коли SQL Server зменшується розмір файлу журналу транзакцій насправді бачиш зміна фізичного розміру лог-файл.

Щоб отримати додаткові відомості про те, як зменшити транзакції журнали клацніть номер статті в базі знань Microsoft Knowledge Base:
256650 Як SQL Server 7.0 журнал транзакцій стиснути
272318 Скорочується SQL Server 2000 з DBCC SHRINKFILE, журнал транзакцій
Докладніше про SQL Server 6.5 транзакції журналу сценарій виконання клацніть номер статті для перегляду статті в базі знань Microsoft Knowledge Base:
110139 Причини SQL журнал транзакцій заповнення

Як знайти запитів, які споживають велику кількість простору журналу в SQL Server 2005 і пізніших версій

В SQL Server 2005 і пізніших версій дає змогу sys.dm_tran_database_transactions подання елементів динамічного керування (DMV) знайдіть запити, які споживають багато простору журналу. Такі стовпці в на sys.dm_tran_database_transactions DMV може бути корисним:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
Sql_handle колона sys.dm_exec_requests DMV, щоб отримати фактичний заяви текст, який споживає багато простору журналу можна запитати. Ви можете зробити це шляхом приєднання sys.dm_tran_database_transactions DMV і sys.dm_tran_session_transactions DMV на transaction_id колонці та додаючи додаткові приєднуються sys.dm_exec_requests session_id колонці.

Щоб отримати додаткові відомості про sys.dm_tran_database_transactions DMV, перейдіть до на sys.dm_tran_database_transactions (оператори Transact-SQL) глобальна мережа Microsoft для розробників (MSDN) сайт.

Щоб отримати додаткові відомості про sys.dm_tran_session_transactions DMV, перейдіть до на sys.dm_tran_session_transactions (оператори Transact-SQL) Веб-сайті MSDN.

Щоб отримати додаткові відомості про sys.dm_exec_requests DMV, перейдіть до на sys.dm_exec_requests (оператори Transact-SQL) Веб-сайті MSDN.

Попередження. Цю статтю переведено автоматично

Властивості

Ідентифікатор статті: 317375 – останній перегляд: 01/15/2014 02:06:00 – виправлення: 3.0

Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL 2005 Server Enterprise, Microsoft SQL Server 2005 Express Edition, Microsoft SQL 2005 Server Workgroup, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition

  • kbsqlsetup kbinfo kbmt KB317375 KbMtuk
Зворотний зв’язок