Почему SQL Server так привязан к журналам транзакций

Question

ОК, здесь идет. Я не гуру базы данных или администратор. На самом деле, помимо некоторой случайной настройки индекса / запроса, я не слишком часто копаюсь в базах данных. Одна из вещей, которая часто ускользает от меня - это журнал транзакций SQL Server. Я знаю, для чего он нужен, что он содержит и как он работает (по крайней мере, концептуально), но я думаю, что не понимаю , почему SQL Server, похоже, так привязан к журналам транзакций .

Вот первый вопрос . Поправьте меня, если я ошибаюсь, но мне кажется, что по умолчанию журналы транзакций будут просто содержать всю историю всех изменений в базе данных. Есть два признака того, что это действительно так. Когда я создаю новую базу данных, максимальный размер ее журнала устанавливается на «неограниченный рост». Вторая причина заключается в том, что я часто имел дело с крошечными базами данных с огромными журналами транзакций, которые нельзя было уменьшить независимо от того, что я делал. Кажется, это так странно, я не могу поверить, что это правда. Зачем мне вообще нужна вся история по умолчанию? Все, что меня волнует, - это последняя версия данных в согласованном состоянии. Что ж, я подозреваю, что на это могут быть веские причины, но в некоторых случаях это можно назвать дополнительным вариантом.

Мой второй вопрос Почему так сложно избавиться от журнала переходов ? Это только у меня так или нет прямого способа сделать это? Совсем недавно я пытался избавиться от 100 МБ + журнала базы данных объемом 5 МБ, и самым простым способом, который я нашел, было отключение базы данных, удаление журнала и повторное присоединение его снова (и даже этот SQL-сервер немного жаловался). Я попробовал команду shrink со всеми возможными вариантами, которые я смог найти, но я смог сжать только до 50%. База данных не использовалась (нет активных соединений), и я, честно говоря, не заботился о каких-либо прошлых переходах вообще. Я заметил, что, возможно, есть и другие «способы», как это сделать; некоторые, включающие резервное копирование и восстановление.

Я старательно пытался прочитать документацию MSDN и узнать что-то еще о переходах, но примерно через 15 минут, когда мне хотелось ходить по грязи в кругах, я сдался. Я знаю, что для администраторов баз данных и гуру мои вопросы будут звучать глупо. Я ценю любые отзывы.

Редактировать: После первых ответов я понял, что, возможно, я недостаточно ясен. Я знаю, как работает журнал транзакций во время транзакций, и почему это важно, и что его можно использовать в целях резервного копирования. Я думаю, что хотел бы спросить больше с точки зрения разработчика. Большую часть времени я имею дело с подготовкой / тестированием временных баз данных, которые не нуждаются в резервном копировании, и которые никто не использует, кроме меня, и я часто испытываю необходимость передавать их, и наличие огромного журнала переходов является ненужным неудобством в этой ситуации. .

Answer 1

Журнал базы данных не является чем-то после записи истории, как журнал IIS. В базах данных с Запись с записью в очередь журнал является основным источником восстановления, восстановления и отмены и для всех целей является официальным источником данных. Удаление или замена журнала - одно из худших решений, которое может принять администратор базы данных. В данный момент ваша база данных может быть повреждена.

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

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

Общие сведения о ведении журнала и восстановлении в SQL Server
Неправильные представления о журнале и резервном копировании журнала: как убедить себя
Внутри механизма хранения: подробнее о круговой природе бревна

Answer 2

Журналы транзакций существуют по двум основным причинам

1 - разрешить БД "откатить" текущую транзакцию 2 - чтобы аварийная БД могла восстановить свое состояние до последней совершенной транзакции перед сбоем

1 кратковременный, если у вас нет активных транзакций, он будет занимать мало места. 2 однако, как вы думаете, продолжает расти со временем, может быть, без ограничений.

Идея заключается в том, что вы часто делаете резервную копию журнала транзакций в файл дампа. Файл дампа - это полный снимок состояния БД, из которого вы можете восстановить ВСЮ БД в определенный момент времени. После этого журнал транзакций усекается и снова начинается с пустого.

Если впоследствии происходит сбой БД, вы загружаете снимок БД из файла дампа, а затем применяете журнал транзакций, который содержит инкрементальных изменений с момента последнего снимка, сверху для восстановления состояния. По этой причине журналы транзакций должны храниться в хранилище с высокой отказоустойчивостью, иначе вы не сможете восстановить БД.

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

Есть еще один вариант, который я бы не рекомендовал: отключать журналы транзакций в вашей БД. Это в основном устраняет 2 выше, поэтому журнал транзакций не растет со временем. Конечно, если ваша БД дает сбой, вы можете восстановиться только после последней полной резервной копии / дампа, так что эта опция несет значительный риск, если вы выполняете что-либо даже полузадачное.

НТН.

Answer 3

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

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

В случае, когда файл журнала больше, чем база данных, и после того, как резервная копия не может быть сокращена, в системе может быть открытая транзакция с активным активом VLF, которая не позволяет ему повторно использовать пространство.

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

Считается, что плохо, что в течение 2005 года есть даже флаг, который вы не можете изменить, что указывает на то, что вы это сделали. Служба поддержки MS может проверить, не были ли вы после их помощи с потенциальной ошибкой в ​​SQL.

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

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

Answer 4

(это MS-SQL, верно?)

Да, держу пари, сервер действительно жаловался, когда вы отсоединили и удалили журнал вручную.

Если вы не хотите вести T-журнал, измените режим восстановления каталога на «Простой» (в свойствах каталога), чтобы обрезать журнал при успешном завершении транзакций.

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

(Журналы транзакций, FTW!)

Answer 5

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

Прошло много времени с тех пор, как я работал с SQL Server, поэтому я не могу ответить, почему так сложно избавиться от журнала транзакций. В SQL Server 7, SQL Server 2000 дней, полная резервная копия базы данных по умолчанию обрезает журнал транзакций.