[IT168 Server Academy] Журналы транзакций — очень важная, но часто игнорируемая часть структуры базы данных. Поскольку он не так активен, как схема в базе данных, на журнал транзакций мало кто обращает внимание.
Журнал транзакций представляет собой запись изменений базы данных. Он может записывать любые операции с базой данных и сохранять результаты записи в отдельный файл. Для каждого процесса транзакции в журнале транзакций имеются подробные записи, и на основе этих записей файлы данных могут быть восстановлены до состояния, существовавшего до транзакции. С самого начала действия транзакции журнал транзакций находится в состоянии записи. Любые операции с базой данных во время транзакции находятся в пределах области записи. Запись не завершается, пока пользователь не нажмет кнопку «Отправить» или «Назад». Каждая база данных имеет как минимум один журнал транзакций и один файл данных.
Из соображений производительности SQL Server сохраняет пользовательские изменения в кеше. Эти изменения немедленно записываются в журнал транзакций, а не в файл данных. В журнале транзакций используется точка маркировки, чтобы определить, записала ли транзакция данные из кэша в файл данных. При перезапуске SQL Server он проверит последнюю точку отметки в журнале и удалит записи транзакций после этой точки, поскольку эти записи транзакций фактически не записывают данные из кэша в файл данных. Это предотвращает изменение файлов данных прерванными транзакциями.
Ведение журнала транзакций.
Поскольку многие люди часто забывают журнал транзакций, это также может вызвать некоторые проблемы в системе. По мере того, как система продолжает работать, будет записываться все больше и больше записей журнала, а размер файлов журнала также будет становиться все больше и больше, что в конечном итоге приведет к нехватке доступного дискового пространства. Если журналы не очищаются часто в ходе повседневной работы, файлы журналов в конечном итоге займут все доступное пространство в разделе. Конфигурация журнала по умолчанию — неограниченная емкость. Если вы работаете в этой конфигурации, он будет продолжать расширяться и в конечном итоге займет все доступное пространство. Обе ситуации могут привести к тому, что база данных перестанет работать.
Регулярное резервное копирование журналов транзакций может эффективно предотвратить использование файлов журналов чрезмерного дискового пространства. Процесс резервного копирования отсекает части журнала, которые больше не нужны. Метод усечения заключается в том, чтобы сначала пометить старые записи как неактивные, а затем перезаписать новые журналы на месте старых журналов, предотвращая тем самым увеличение размера журнала транзакций. Если регулярное резервное копирование журнала невозможно выполнить, лучше всего установить для базы данных «простую модель восстановления». В этом режиме система будет принудительно усекать журнал транзакций каждый раз при записи точки отметки, перезаписывая старый журнал новым.
Процесс усечения происходит при резервном копировании или пометке старых точек как неактивных, что позволяет перезаписывать старые записи транзакций, но не уменьшает фактическое дисковое пространство, занимаемое журналом транзакций. Даже если журнал больше не используется, он все равно будет занимать определенное количество места. Поэтому во время обслуживания журнал транзакций также необходимо сжимать. Журналы транзакций сжимаются путем удаления неактивных записей, тем самым уменьшая пространство на физическом жестком диске, занимаемое файлами журналов.
Файл журнала транзакций текущей базы данных можно сжать с помощью оператора DBCC SHRINKDATABASE. Оператор DBCC SHRINKFILE используется для сжатия указанного файла журнала транзакций. Кроме того, в базе данных также можно активировать операцию автоматического сжатия. При сжатии журнала старые записи сначала помечаются как неактивные, а затем записи, помеченные как неактивные, полностью удаляются. В зависимости от используемого метода сжатия вы можете не увидеть результаты сразу. В идеале работы по сжатию следует выполнять в периоды, когда система не очень загружена, иначе это может повлиять на производительность базы данных.
Восстановление
резервной копии записей транзакций базы данных можно использовать для восстановления базы данных до заданного состояния, но самой резервной копии записей транзакций недостаточно для выполнения задачи восстановления базы данных, и файлы данных из резервной копии также должны участвовать в работе по восстановлению. При восстановлении базы данных первым шагом является восстановление файлов данных. Не переводите весь файл данных в завершенное состояние до тех пор, пока весь файл данных не будет восстановлен, иначе журнал транзакций не будет восстановлен. Когда восстановление файла данных будет завершено, система восстановит базу данных до состояния, желаемого пользователем, посредством резервной копии журнала транзакций. Если после последней резервной копии базы данных существуют резервные копии нескольких файлов журналов, программа резервного копирования восстановит их последовательно в соответствии со временем их создания.
Другой процесс, называемый доставкой журналов, может обеспечить более надежные возможности резервного копирования базы данных. Если настроена доставка журналов, можно скопировать всю базу данных на другой сервер. В этом случае журналы транзакций также периодически отправляются на резервный сервер для восстановления данных. Это сохраняет сервер в состоянии горячего резервного копирования, обновляя его по мере изменения данных. Другой сервер называется сервером мониторинга и может использоваться для мониторинга сигналов доставки, отправляемых через определенные интервалы времени. Если в течение указанного времени сигнал не будет получен, сервер мониторинга занесет это событие в журнал событий. Благодаря этому механизму доставка журналов часто используется в планах аварийного восстановления.
Журнал транзакцийоптимизации производительности
играет важную роль в базе данных, а также оказывает определенное влияние на общую производительность системы. С помощью нескольких опций мы можем оптимизировать производительность журнала транзакций. Поскольку журнал транзакций представляет собой непрерывный процесс записи на диск, во время этого процесса чтение не происходит. Поэтому размещение файла журнала на независимом диске сыграет определенную роль в оптимизации производительности.
Другая мера оптимизации связана с размером файла журнала. Мы можем установить размер файла журнала, не превышающий нескольких процентов места на жестком диске, или определить его размер. Если он установлен слишком высоким, это приведет к пустой трате дискового пространства, а если он установлен слишком маленьким, файл журнала будет постоянно пытаться расшириться, что приведет к снижению производительности базы данных.
Файл журнала транзакций Файл журнала транзакций — это файл, используемый для записи обновлений базы данных, с расширением ldf.
В SQL Server 7.0 и SQL Server 2000, если установлена функция автоматического увеличения, файл журнала транзакций будет автоматически расширяться.
Как правило, размер журнала транзакций является стабильным, если он может вместить максимальное количество транзакций, происходящих между усечением журнала транзакций, которое инициируется контрольной точкой или резервным копированием журнала транзакций.
Однако в некоторых случаях журнал транзакций может стать настолько большим, что ему не хватит места или он заполнится. Обычно, когда файл журнала транзакций заполняет все доступное дисковое пространство и его больше нельзя расширить, вы получаете сообщение об ошибке, подобное следующему:
Ошибка: 9002, уровень серьезности: 17, состояние: 2.
Файл журнала базы данных "%.*ls" заполнен.
В дополнение к этому сообщению об ошибке SQL Server может пометить базу данных как ПОДОЗРИТЕЛЬНУЮ из-за нехватки места для расширения журнала транзакций. Дополнительные сведения о том, как выйти из этой ситуации, см. в разделе «Недостаточно места на диске» в онлайн-справке по SQL Server.
Кроме того, расширение журнала транзакций может вызвать следующие ситуации:
· Очень большие файлы журнала транзакций.
· Транзакция может завершиться неудачей и начать откат.
· Завершение транзакции может занять много времени.
· Могут возникнуть проблемы с производительностью.
· Может произойти блокировка.
Причина Расширение журнала транзакций может произойти по следующим причинам или ситуациям:
· Незафиксированные транзакции · Очень большие транзакции · Операции: DBCC DBREINDEX и CREATE INDEX
· При восстановлении из резервной копии журнала транзакций · Клиентское приложение не обрабатывает все результаты · Время ожидания запроса истекает до завершения расширения журнала транзакций, и вы получаете ложное сообщение об ошибке «Журнал полон» · Разрешение нереплицированных транзакций, вызванное тем, что файл журнала полный Если база данных SQL не может выполнить запись в файл, доступны два метода:
Один из способов: очистить журнал.
1. Откройте анализатор запросов и введите команду DUMP TRANSACTION имя базы данных с NO_LOG.
2. Снова откройте Enterprise Manager — щелкните правой кнопкой мыши базу данных, которую вы хотите сжать — Все задачи — Сжать базу данных — Сжать файлы — Выберите файл журнала — В режиме сжатия выберите «Сжать до XXM» и Разрешение на сокращение будет дано здесь. Чтобы достичь минимального числа M, введите это число напрямую и подтвердите.
Другой метод имеет определенные риски, поскольку файл журнала SQL SERVER не записывается сразу в основной файл базы данных. Если он не будет обработан должным образом, это приведет к потере данных.
1: Удалить ЖУРНАЛ
Отсоединить базу данных Enterprise Manager -> Сервер -> База данных -> Щелкните правой кнопкой мыши -> Отсоединить базу данных 2: Удалить файл журнала Прикрепить базу данных Enterprise Manager -> Сервер -> База данных -> Щелкните правой кнопкой мыши -> Присоединить базу данных Этот метод создает новый журнал, размер составляет всего более 500 тыс.
Примечание. Рекомендуется использовать первый метод.
Если в будущем вы не захотите, чтобы он стал больше.
Используется под SQL2000:
Щелкните правой кнопкой мыши базу данных->Свойства->Параметры->Восстановление после отказа-Модель-Выбрать-Простая модель.
Или используйте оператор SQL:
изменить базу данных, набор имен баз данных, восстановление, простое
Кроме того, как показано на рисунке выше, в свойствах базы данных есть две опции, связанные с ростом журнала транзакций:
Обрезать журнал на контрольной точке
(Эта опция используется в SQL7.0. В SQL 2000 модель восстановления после сбоя выбрана как простая модель)
При выполнении команды CHECKPOINT содержимое файла журнала транзакций очищается, если оно превышает 70 % его размера. При разработке базы данных всегда устанавливайте для этого параметра значение True.
Автоматическое сжатие
Регулярно проверяйте базу данных. Когда неиспользуемое пространство файла базы данных или файла журнала превышает 25% от его размера, система автоматически уменьшает размер файла до 25%. Если размер файла не превышает исходный размер. при создании он не будет. Уменьшенный файл также должен быть больше или равен исходному размеру. Уменьшение файла журнала транзакций можно выполнить только при его резервном копировании или если для параметра «Усечь журнал на контрольной точке» установлено значение «Истина».
Примечание. Как правило, свойства базы данных, созданной Ли Ченгом, установлены по умолчанию, но в случае непредвиденных обстоятельств свойства базы данных изменяются. Очистите журнал, а затем проверьте указанные выше свойства базы данных, чтобы предотвратить появление журнала транзакций. снова пополняюсь.