Отключить журнал транзакций


79

В Oracle есть команды SQL, которые можно выполнить, чтобы транзакция не регистрировалась. Есть ли что-то подобное для SQL Server 2008?

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


1
вы пробовали использовать представления для расчетных данных?

Извините за захват вашего вопроса, но как отключить ведение журнала транзакций в Oracle для конкретной процедуры / запроса? Спасибо!
Виктор

3
@Kaushik, тебе лучше задать это, потому что это собственный вопрос.
Raj More

" чтобы транзакция не регистрировалась " это неверно, если вы имеете в виду эту NOLOGGEDопцию.
a_horse_with_no_name

@RajMore Вы узнали что-нибудь еще по этой теме? В нашем случае мы выполняем массовую загрузку, и было удивительно видеть, как так много данных выгружается на диск в режиме SIMPLE. Теперь я понимаю, почему, но мне интересно, насколько могла бы повыситься производительность, если бы можно было исключить ведение журнала транзакций.
D-Klotz

Ответы:


124

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

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

ALTER DATABASE MyDB SET RECOVERY SIMPLE;

18
Просто БОЛЬШОЙ заголовок: этот ответ на 100% технически правильный. Но это исключительно то, что вы хотели бы использовать на своих машинах РАЗРАБОТЧИКА или когда вы НЕ заботитесь о возможности резервного копирования своих данных. См. Sqlservervideos.com/video/logging-essentials и sqlservervideos.com/video/shrinking-log-files для получения дополнительной информации и справочной информации.
Майкл К. Кэмпбелл,

Или для баз данных в RDS (или аналогичных службах), где стратегия резервного копирования использует моментальные снимки, а не журналы транзакций.
bsplosion


45

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

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

  • просто
  • Полный

В полном режиме журнал транзакций продолжает расти, пока вы не создадите резервную копию базы данных. В простом режиме: пространство в журнале транзакций «повторно используется» на каждой контрольной точке .

Очень немногим людям нужно запускать свои базы данных в модели полного восстановления. Единственный смысл в использовании полной модели - это если вы хотите делать резервную копию базы данных несколько раз в день, а резервное копирование всей базы данных занимает слишком много времени, поэтому вы просто создаете резервную копию журнала транзакций.

Журнал транзакций продолжает расти весь день, и вы продолжаете делать резервные копии только его. Этой ночью вы делаете полную резервную копию, а затем SQL Server обрезает журнал транзакций и начинает повторно использовать пространство, выделенное в файле журнала транзакций.

Если вы когда-либо делаете только полные резервные копии базы данных , вам не нужен режим полного восстановления.


Это немного неправильно: вам нужно сделать резервную копию журнала, чтобы (надеюсь) остановить рост журнала транзакций. Конечно, если у вас есть открытая транзакция или огромная транзакция, журнал будет расти, потому что внутренние распределения файлов журнала (VLF) не могут быть повторно использованы или вам нужно больше. Кстати, это краткий обзор, а не глава и стих
gbn

1
@gbn Вы не делаете резервную копию журнала, чтобы предотвратить его рост. я имею в виду, что вы делаете , но не в этом суть функции. Microsoft не создавала журнал транзакций для того, чтобы играть в игру, «потребляющую весь жесткий диск, потому что вы забыли сделать резервную копию журнала» . Причина журнал продолжает расти (а затем требует резервного копирования , чтобы остановить его от выращивания), так что вы можете создать резервную копию всего журнала.
Ян Бойд

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. Есть ли другой способ?
Raj More

1
@Tapori, это одно и то же. Его переименовали в 2000 году.
zvolkov

0

Если это только для машин разработчиков, чтобы сэкономить место, просто перейдите в простой режим восстановления, и все будет хорошо.

Однако на производственных машинах я настоятельно рекомендую держать базы данных в режиме полного восстановления. Это гарантирует, что при необходимости вы сможете выполнить восстановление на определенный момент времени.

Кроме того, наличие баз данных в режиме полного восстановления может помочь вам отменить случайные обновления и удаления путем чтения журнала транзакций. См. Ниже или более подробную информацию.

Как я могу откатить запрос UPDATE в SQL Server 2005?

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

Если на производственных машинах не хватает места, просто часто создавайте резервные копии журнала транзакций.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.