Вимкнути журнал транзакцій


79

Oracle має команди SQL, які можна видавати, щоб транзакція не реєструвалась. Чи є щось подібне для SQL Server 2008?

Мій сценарій: нам потрібні журнали Tx на серверах (Dev, QA, Prod), але, можливо, ми можемо обійтися без них на машинах розробників.


1
ви пробували використовувати представлення даних для обчислених даних?

Вибачте, що захопили ваше запитання, але як відключити реєстрацію транзакцій в Oracle для процедури / запиту particualr? Дякую!
Віктор

3
@Kaushik, тобі краще не задавати це, оскільки це власне питання.
Raj More

" так що транзакція не реєструється " це не відповідає дійсності, якщо ви посилаєтесь на NOLOGGEDопцію.
a_horse_with_no_name

@RajMore Чи ти ще щось дізнався з цієї теми? У нашому випадку ми виконуємо масове завантаження, і було дивно, що стільки даних перекидається на диск в режимі ПРОСТО. Тепер я розумію, чому, але мені цікаво, наскільки продуктивність може зрости, якщо журналювання транзакцій можна було б усунути.
D-Klotz

Відповіді:


124

Без журналів транзакцій у SQL Server не обійтися ні за яких обставин. Двигун просто не працюватиме.

Ви МОЖЕТЕ встановити модель відновлення ПРОСТО на ваших машинах розробників - це запобіжить здуття журналу транзакцій, коли не виконуються резервні копії журналів транзакцій.

ALTER DATABASE MyDB SET RECOVERY SIMPLE;

18
Просто ВЕЛИКИЙ голос: ця відповідь на 100% технічно правильна. Але це виключно те, що ви хотіли б використовувати на своїх машинах DEVELOPER, або коли ви НЕ турбуєтесь про можливість резервного копіювання даних. Для отримання додаткової інформації та передумов див. Sqlservervideos.com/video/logging-essentials та sqlservervideos.com/video/shrinking-log-files .
Michael K. Campbell

Або для баз даних на RDS (або еквівалентних службах), де стратегія резервного копіювання використовує знімки, а не журнали транзакцій.
bsplosion

або db побудований з іншого джерела, наприклад, джерело подій, тому немає транзакцій і не потрібно реєструвати журнал
Ентоні Джонстон,

45

Для роботи SQL Server потрібен журнал транзакцій.

При цьому існує два режими роботи журналу транзакцій:

  • Простий
  • Повна

У повному режимі журнал транзакцій продовжує зростати, доки ви не зробите резервну копію бази даних. У простому режимі: простір у журналі транзакцій "переробляється" кожною контрольною точкою .

Дуже мало людей потребують запуску своїх баз даних у моделі повного відновлення. Єдиний сенс у використанні моделі Full полягає в тому, що ви хочете робити резервні копії бази даних кілька разів на день, а резервне копіювання всієї бази даних займає занадто багато часу - тому ви просто робите резервну копію журналу транзакцій.

Журнал транзакцій постійно зростає протягом усього дня, а ви продовжуєте його резервне копіювання. Тієї ночі ви робите повне резервне копіювання, і SQL Server потім усікає журнал транзакцій і починає повторно використовувати простір, виділений у журналі журналу транзакцій.

Якщо ви коли-небудь виконуєте лише повне резервне копіювання бази даних , ви не хочете режиму повного відновлення.


Це трохи неправильно: вам потрібно зробити резервну копію журналу, щоб (сподіваємось) зупинити зростання журналу транзакцій. Звичайно, якщо у вас відкрита транзакція або величезна транзакція, тоді журнал буде рости, оскільки внутрішні розподіли файлів журналу (VLF) не можна використовувати повторно або вам потрібно більше. Це короткий огляд до речі, а не розділ і вірш
gbn

1
@gbn Ви не робите резервну копію журналу, щоб зупинити зростання журналу. я маю на увазі, що ви робите , але це не суть функції. Корпорація Майкрософт не створила журнал транзакцій для того, щоб грати в гру "споживайте весь жорсткий диск, тому що ви забули зробити резервну копію журналу" . Причина журнал продовжує зростати (а потім вимагає резервного копіювання , щоб зупинити його від вирощування), так що ви можете створити резервну копію всього журналу.
Ian Boyd

44

Існує третій режим відновлення, про який не згадувалося вище. Режим відновлення в кінцевому рахунку визначає, наскільки великими стають файли LDF і як часто вони записуються. У випадках, коли ви збираєтеся робити будь-які типи масових вставок, вам слід встановити для БД значення "BULK / LOGGED". Завдяки цьому об’ємні вставки швидко рухаються, і їх можна змінювати на льоту.

Робити так,

USE master ;
ALTER DATABASE model SET RECOVERY BULK_LOGGED ;

Щоб повернути його назад:

USE master ;
ALTER DATABASE model SET RECOVERY FULL ;

У дусі додавання до розмови про те, чому хтось не хоче LDF, я додаю наступне: Ми робимо багатовимірне моделювання. По суті, ми використовуємо БД як великий накопичувач змінних, які обробляються масово за допомогою зовнішніх програм. Ми НІКОЛИ не вимагаємо відкатів. Якби ми могли отримати підвищення продуктивності, перевернувши ВСІ журнали, ми б взяли це в серце.


1
Дякую за це. Ми використовуємо БД точно так само. Ми не могли дбати про те, щоб мати можливість відкотитися назад. Ми чекаємо чистої роботи
Ден,

Для цього сценарію ви можете розглянути іншу базу даних, таку як Mongo (дозволяє вимкнути журнали) або в пам'яті (redis та інші)
Тім,

2

У чому ваша проблема з журналами Tx? Вони ростуть? Потім просто встановіть усічення на пункті контрольної точки.

З документації Microsoft:

У SQL Server 2000 або SQL Server 2005 "проста" модель відновлення еквівалентна "скороченню журналу контрольної точки" у попередніх версіях SQL Server. Якщо журнал транзакцій скорочується кожного разу, коли контрольна точка виконується на сервері, це заважає використовувати журнал для відновлення бази даних. Ви можете використовувати лише повне резервне копіювання бази даних для відновлення даних. Резервні копії журналу транзакцій вимикаються, коли використовується "Проста" модель відновлення.


1
Ну, космічні проблеми - деякі розробники мають старі машини, і ми можемо обійтися без них. До речі, мені цікаво, чи це взагалі можливо! У мене склалося враження, що параметр "Урізати журнал контрольної точки" встановлено лише за допомогою режиму простого відновлення в SQL 2008. Чи існує інший спосіб?
Радж Море

1
@Tapori, це одне і те ж. Вони перейменували його у 2000 р.
zvolkov

0

Якщо це лише для машин розробників, щоб заощадити місце, просто перейдіть у простий режим відновлення, і у вас все буде добре.

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

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

Як я можу повернути запит UPDATE в SQL Server 2005?

Прочитайте файл журналу (*. LDF) у SQL Server 2008

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.