Главная
О нас
Наши собаки
- Репортаж
- Фотоальбом
- Видео
Информация
- Новости
- Статьи
- Ветеринария
- Разное
Юмор
Форум
Контакты

Это интересно

ОКД
ЗКС
ИПО
КНПВ
Мондиоринг
Большой ринг
Французский ринг
Аджилити
Фризби

Опрос

Какой уровень дрессировки необходим Вашей собаке?

	Элементарное послушание в быту
	Чёткое выполнение команд
	Спорт и соревнования

Полезные ссылки

РКФ

Все о дрессировке собак

Стрижка собак в Коломне

Поиск по сайту

Журнал транзакций для базы данных заполнен. Чтобы узнать, почему пространство в журнале нельзя использовать повторно, см. Столбец log_reuse_wait_desc в sys.databases. Журнал транзакций для базы данных

sql-server - Журнал транзакций для базы данных "databasename" заполнен.

Наиболее вероятным ответом является выполнение резервных копий журнала или существует открытая транзакция.

Вот еще немного, чтобы помочь вам...

Запустите этот script на своем сервере:

-- last FULL backup ;with FULLBUs as ( select d.name, max(b.backup_finish_date) as 'Last FULL Backup' from sys.databases d join msdb.dbo.backupset b on d.name = b.database_name where b.type = 'D' group by d.name ), -- last LOG backup for FULL and BULK_LOGGED databases LOGBUs as ( select d.name, max(b.backup_finish_date) as 'Last LOG Backup' from sys.databases d join msdb.dbo.backupset b on d.name = b.database_name where d.recovery_model_desc <> 'SIMPLE' and b.type = 'L' group by d.name ) -- general overview of databases, recovery model, and what is filling the log, last FULL, last LOG select d.name, d.state_desc, d.recovery_model_desc, d.log_reuse_wait_desc, f.[Last FULL Backup], l.[Last LOG Backup] from sys.databases d left outer join FULLBUs f on d.name = f.name left outer join LOGBUs l on d.name = l.name where d.name not in ('model', 'TempDB') order by d.name

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

Посмотрите на столбец с надписью log_reuse_wait_description. Скорее всего, он говорит BACKUP. Следующая наиболее вероятная причина - TRANSACTION.

Если это BACKUP, вот некоторая информация:

В основном, для ваших простых баз данных каждый день запускайте ПОЛНУЮ резервную копию. Для ваших FULL баз данных каждый день выполняйте полную резервную копию и резервную копию журнала. Отрегулируйте частоту ваших баз данных LOG, чтобы они соответствовали вашей способности потерять данные, сохраняя при этом вашу работу.

Самый простой способ управления резервными копиями - использовать скрипты обслуживания Ola Hallengren. Посетите его веб-сайт и попробуйте использовать их.

Если вы видите TRANSACTION, попробуйте запустить:

dbcc opentran

И отследите, кто имеет открытые транзакции.

qaru.site

sql - Журнал транзакций для базы данных заполнен sql-server sql-server-2008

У меня есть длительный процесс, который открывает транзакцию на полную длительность.

У меня нет контроля над тем, как это выполняется.

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

Таким образом, процесс выходит из строя с ошибкой "The transaction log for database 'xxx' is full" .

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

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

Есть идеи?

Если кому-то интересно, процесс представляет собой импорт организации в Microsoft Dynamics CRM 4.0.

Существует много дискового пространства, у нас есть журнал в режиме простого ведения журнала и резервное копирование журнала до начала процесса.

- = - = - = - = - UPDATE - = - = - = - = -

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

Я получаю следующую ошибку ...

Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception: System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Поэтому после этого совета я пошел в log_reuse_wait_desc column in sys.databases « log_reuse_wait_desc column in sys.databases » и в нем было указано значение « ACTIVE_TRANSACTION ».

Согласно Microsoft: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

Это означает следующее:

Транзакция активна (все модели восстановления). • Долгосрочная транзакция может существовать в начале резервного копирования журнала. В этом случае для освобождения пространства может потребоваться другая резервная копия журнала. Дополнительные сведения см. В разделе «Длительные активные транзакции» далее в этом разделе.

• Отложенная транзакция (только для SQL Server 2005 Enterprise Edition и более поздних версий). Отложенная транзакция - это фактически активная транзакция, откат которой заблокирован из-за некоторого недоступного ресурса. Для получения информации о причинах отложенных транзакций и способах их перемещения из состояния отложенного платежа см. Раздел Отложенные транзакции.

Я что-то неправильно понял?

- = - = - = - ОБНОВЛЕНИЕ 2 - = - = - = -

Просто начался процесс с первоначальным размером файла журнала, установленным в 30 ГБ. Это займет пару часов.

- = - = - = - Окончательное ОБНОВЛЕНИЕ - = - = - = -

Проблема была вызвана тем, что файл журнала потребляет все доступное дисковое пространство. В последней попытке я освободил 120 ГБ, и он все еще использовал все это и в конечном итоге потерпел неудачу.

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

Спасибо всем за ваш вклад.

code-examples.net

Введение в базы данных | Журнал транзакций

Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая Журналом транзакций.

Однако назначение журнала транзакций гораздо шире. Он предназначен для обеспечения надежного хранения данных в БД.

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

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

- результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;

- результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

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

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

- стандартной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK;

- аварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLBACK, но физически имеет иной механизм выполнения;

- принудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. В подобном случае для выхода из тупика данная транзакция может быть выбрана в качестве «жертвы» и принудительно прекращено ее выполнение ядром СУБД.

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

- при аварийном выключении электрического питания;

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

- восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

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

Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных.

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

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

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

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

Рис. 6.7. Журнал транзакций

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

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

Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций:

1. Когда транзакция Т1 начинается, в протокол заносится запись

2. На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: <T1,ID_RECORD, атрибут, новое значение ... >. Здесь ID_RECORD – уникальный номер записи.

3. Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится <Т1 СОММIT>.

4. После того как транзакция фиксирована, записи протокола, относящиеся к Т1, используются для внесения соответствующих изменений в БД.

5. Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи <Т1 BEGIN TRANSACTION и <Т1 СОММIТ>. БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется некоторая системная процедура REDOQ, которая заменяет все значения элементов данных на новые, просматривая протокол в прямом порядке.

6. Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново.

Альтернативный механизм с немедленным выполнением предусматривает внесение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит <Т1, ID_RECORD, атрибут новое значение старое значение ...>. При этом запись в журнал предшествует непосредственному выполнению операции над БД. Когда транзакция фиксируется, то есть встречается команда <Т1 СОММIТ> и она выполняется, то все изменения оказываются уже внесенными в БД и не требуется никаких дальнейших действий по отношению к этой транзакции.

При откате транзакции выполняется системная процедура UNOOO, которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды BEGIN TRANSACTION.

Для восстановления при сбое используется следующий механизм:

1. Если транзакция содержит команду начала транзакции, но не содержит команды фиксации с подтверждением ее выполнения, то выполняется последовательность действий как при откате транзакции, то есть восстанавливаются старые значения.

2. Если сбой произошел после выполнения последней команды изменения БД, но до выполнения команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит. Работа происходит только на уровне протокола.

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

3ys.ru

sql-server - Журнал транзакций для базы данных заполнен. Чтобы узнать, почему пространство в журнале нельзя использовать повторно, см. Столбец log_reuse_wait_desc в sys.databases

Как сказал Дэмиен, вы должны выяснить причину, почему ваш журнал растет. Отметьте эту должность для объяснения: Повторное использование журнала транзакций Подождите

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

С одной стороны, BACKUP LOG... WITH TRUNCATE_ONLY - это вообще очень плохая идея. Если вы находитесь в режиме полного восстановления, это приведет к поломке цепочки резервных копий и не позволит вам выполнить восстановление в определенный момент времени. Если вам не нужна восстанавливаемость по времени, используйте вместо этого параметр восстановления "простой". В противном случае возьмите резервную копию журнала и сохраните его вместе с другими файлами резервных копий.

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

источник поделиться

qaru.site

Полный журнал транзакций для базы данных

У меня есть длительный процесс, который содержит транзакцию на полную длительность.

У меня нет контроля над тем, как это выполняется.

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

Таким образом, процесс выходит из строя с ошибкой "The transaction log for database 'xxx' is full".

Любые идеи?

Если кому-то интересно, то процесс импорта организации в Microsoft Dynamics CRM 4.0.

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

- = - = - = - = - ОБНОВЛЕНИЕ - = - = - = - = -

Спасибо всем за комментарии до сих пор. Ниже то, что привело меня к мысли о том, что журнал не будет расти из-за открытой сделки:

Я получаю следующее сообщение об ошибке ...

Так следуя этому совету я пошел в «log_reuse_wait_desc column in sys.databases» и он держал значение «ACTIVE_TRANSACTION».

Согласно Microsoft: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

Это означает следующее:

транзакция активна (все модели восстановления). • Долгосрочная транзакция может существовать в начале резервной копии журнала. В этом случае для освобождения пространства может потребоваться другая резервная копия журнала. Дополнительные сведения см. В разделе «Длительные активные транзакции» далее в этом разделе.

Я что-то не понял?

- = - = - = - ОБНОВЛЕНИЕ 2 - = - = - = -

Просто стартовал процесс с начальным размером файла журнала, установленным в 30GB. Это займет пару часов.

- = - = - = - Final ОБНОВЛЕНИЕ - = - = - = -

Вопрос был фактически вызван лог-файл, потребляющего все доступное дисковое пространство.В последней попытке я освободил 120 ГБ, и он все еще использовал все это и в конечном итоге потерпел неудачу.

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

Спасибо всем за ваш вклад.

stackoverrun.com

Jimbo: Журнал транзакций для базы данных заполнен - Найдено 7 ответов

У меня есть длительный процесс, который содержит транзакцию на полную длительность. Р>

У меня нет контроля над тем, как это выполняется. Р>

Поскольку транзакция остается открытой в течение всего времени, когда журнал транзакций заполняется, SQL Server не может увеличить размер файла журнала. Р>

Таким образом, процесс выходит из строя с ошибкой "The transaction log for database 'xxx' is full" .

Не уверен, что я должен попробовать дальше. Процесс работает в течение нескольких часов, поэтому играть в пробную версию и ошибки непросто. Р>

Любые идеи?

Если кому-то интересно, процесс представляет собой импорт организации в Microsoft Dynamics CRM 4.0.

Существует много места на диске, у нас есть журнал в режиме простого ведения журнала и резервное копирование журнала до начала процесса.

- = - = - = - = - UPDATE - = - = - = - = -

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

Я получаю следующую ошибку ...

Итак, после этого совета я пошел в « log_reuse_wait_desc column in sys.databases », и он держал значение « ACTIVE_TRANSACTION ».

Согласно Microsoft: Ссылка

Это означает следующее:

Операция активна (все модели восстановления). • Долгосрочная транзакция может существовать в начале резервного копирования журнала. В этом случае для освобождения пространства может потребоваться другая резервная копия журнала. Дополнительные сведения см. В разделе «Длительные активные транзакции» далее в этом разделе.

Я что-то не понял?

- = - = - = - ОБНОВЛЕНИЕ 2 - = - = - = -

Только что начался процесс с первоначальным размером файла журнала, установленным в 30 ГБ. Это займет пару часов.

- = - = - = - Final UPDATE - = - = - = -

Проблема была вызвана тем, что файл журнала потребляет все доступное дисковое пространство. В последней попытке я освободил 120 ГБ, и он все еще использовал все это и в итоге потерпел неудачу.

Спасибо всем за ваш вклад.

askdev.info

Журнал транзакций - Карпова Т. С.

Журнал транзакцийРеализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая Журналом транзакций. Однако назначение журнала транзакций гораздо шире. Он предназначен для обеспечения надежного хранения данных в БД. А это требование предполагает, в частности, возможность восстановления согласованного состояния базы данных после любого рода аппаратных и программных сбоев. Очевидно, что для выполнения, восстановлений необходима некоторая дополнительная информация.

В подавляющем большинстве современных реляционных СУБД такая избыточная дополнительная информация поддерживается в виде журнала изменений базы данных, чаще всего называемого Журналом транзакций. Итак, общей целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Поскольку основой поддержания целостного состояния базы данных является механизм транзакций, журнализация и восстановление тесно связаны с понятием транзакции. Общими принципами восстановления являются следующие: •результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных; •результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных. Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных. Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных. •Индивидуальный откат транзакции. Этот откат должен быть применен в следующих случаях: oстандартной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK; oаварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLBACK, но физически имеет иной механизм выполнения; oпринудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. В подобном случае для выхода из тупика данная транзакция может быть выбрана в качестве «жертвы» и принудительно прекращено ее выполнение ядром СУБД. •Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть в следующих случаях: oпри аварийном выключении электрического питания; oпри возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т. д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти. •Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных. Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции. Для восстановления непротиворечивого состояния БД при мягком сбое необходимо восстановить содержимое БД по содержимому журналов транзакций, хранящихся на дисках. Для восстановления согласованного состояния БД при

жестком сбое надо восстановить содержимое БД по архивным копиям и журналам транзакций, которые хранятся на неповрежденных внешних носителях. Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных. Возможны два основных варианта ведения журнальной информации. В первом варианте для каждой транзакции поддерживается отдельный локальный журнал изменений базы данных этой транзакцией. Такие журналы называются локальными журналами. Они используются для индивидуальных откатов транзакций и могут поддерживаться в оперативной (правильнее сказать, в виртуальной) памяти. Кроме того, поддерживается общий журнал изменений базы данных, используемый для восстановления состояния базы данных после мягких и жестких сбоев. Этот подход позволяет быстро выполнять индивидуальные откаты транзакций, но приводит к дублированию информации в локальных и общем журналах. Поэтому чаще используется второй вариант — поддержание только общего журнала изменений базы данных, который используется и при выполнении индивидуальных откатов. Далее мы рассматриваем именно этот вариант. Общая структура журнала условно может быть представлена в виде некоторого последовательного файла, в котором фиксируется каждое изменение БД, которое происходит в ходе выполнения транзакции. Все транзакции имеют свои внутренние номера, поэтому в едином журнале транзакций фиксируются все изменения, проводимые всеми транзакциями. Каждая запись в журнале транзакций помечается номером транзакции, к которой она относится, и значениями атрибутов, которые она меняет. Кроме того, для каждой транзакции в журнале фиксируется команда начала и завершения транзакции (см. рис. 11.3). Для большей надежности журнал транзакций часто дублируется системными средствами коммерческих СУБД, именно поэтому объем внешней памяти во много раз превышает реальный объем данных, которые хранятся в хранилище. Имеются два альтернативных варианта ведения журнала транзакций: протокол с отложенными обновлениями и протокол с немедленными обновлениями. Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций: 1.Когда транзакция Т1 начинается, в протокол заносится запись 2.На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: >. Здесь ID_RECORD — уникальный номер записи. 3.Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится .

4.После того как транзакция фиксирована, записи протокола, относящиеся к Т1, используются для внесения соответствующих изменений в БД. 5.Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи . БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется некоторая системная процедура REDOQ, которая заменяет все значения элементов данных на--новые, просматривая протокол в прямом порядке. 6.Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново. Рис. 11.3. Журнал транзакций Альтернативный механизм с немедленным выполнением предусматривает внесение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит . При этом запись в журнал предшествует непосредственному выполнению операции над БД. Когда транзакция фиксируется, то есть встречается команда и она выполняется, то все изменения оказываются уже внесенными в БД и не требуется никаких дальнейших действий по отношению к этой транзакции. При откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды BEGIN TRANSACTION. Для восстановления при сбое используется следующий механизм:

•Если транзакция содержит команду начала транзакции, но не содержит команды фиксации с подтверждением ее выполнения, то выполняется последовательность действий как при откате транзакции, то есть восстанавливаются старые значения. •Если сбой произошел после выполнения последней команды изменения БД, но до выполнения команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит. Работа происходит только на уровне протокола. •Однако следует отметить, что проблемы восстановления выглядят гораздо сложнее приведенных ранее алгоритмов, с учетом того, что изменения как в журнал, так и в БД заносятся не сразу, а буферируются. Этому посвящен следующий раздел. Журнализация и буферизацияЖурнализация изменений тесно связана не только с управлением транзакциями, но и с буферизацией страниц базы данных в оперативной памяти. Если бы запись об изменении базы данных, которая должна поступить в журнал при выполнении любой операции модификации базы данных, реально немедленно записывалась бы во внешнюю память, это привело бы к существенному замедлению работы системы. Поэтому записи в журнале тоже буферизуются: при нормальной работе очередная страница выталкивается во внешнюю память журнала только при полном заполнении записями. Проблема состоит в выработке некоторой общей политики выталкивания, которая обеспечивала бы возможность восстановления состояния базы данных после сбоев. Проблема не возникает при индивидуальных откатах транзакций, поскольку в этих случаях содержимое оперативной памяти не утрачено и можно пользоваться содержимым как буфера журнала, так и буферов страниц базы данных. Но если произошел мягкий сбой и содержимое буферов утрачено, для проведения восстановления базы данных необходимо иметь некоторое согласованное состояние журнала и базы данных во внешней памяти. Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) — «пиши сначала в журнал» и состоит в том, что если требуется записать во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать запись во внешнюю память журнала транзакций записи о его изменении. Другими словами, если во внешней памяти базы данных находится некоторый объект базы данных, по отношению к которому выполнена операция модификации, то во внешней памяти журнала обязательно находится запись, соответствующая этой операции. Обратное неверно, то есть если во внешней памяти журнале содержится запись о некоторой операции изменения объекта базы данных, то сам измененный объект может отсутствовать во внешней памяти базы данных. Дополнительное условие на выталкивание буферов накладывается тем требованием, что каждая успешно завершившаяся транзакция должна быть реально зафиксирована во внешней памяти. Какой бы сбой не произошел, система должна быть в состоянии восстановить состояние базы данных, содержащее результаты всех зафиксированных к моменту сбоя транзакций. Простым решением было бы выталкивание буфера журнала, за которым следует массовое выталкивание буферов страниц базы данных, изменявшихся данной транзакцией. Довольно часто так и делают, но это вызывает существенные накладные расходы при выполнении операции фиксации транзакции. Оказывается, что минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией. При этом последней записью в журнал, производимой от имени данной транзакции, является специальная запись о конце транзакции. Рассмотрим теперь, как можно выполнять операции восстановления базы данных в различных ситуациях, если в системе поддерживается общий для всех транзакций журнал с общей буферизацией записей, поддерживаемый в соответствии с протоколом WAL. Индивидуальный откат транзакцииДля того чтобы можно было выполнить по общему журналу индивидуальный откат транзакции, все записи в журнале по данной транзакции связываются в обратный список. Началом списка для незакончившихся транзакций является запись о последнем изменении базы данных, произведенном данной транзакцией. Для закончившихся транзакций (индивидуальные откаты которых уже невозможны) началом списка является запись о конце транзакции, которая обязательно вытолкнута во внешнюю память журнала, Концом списка всегда служит первая запись об изменении базы данных, произведенном данной транзакцией. Обычно в каждой записи проставляется уникальный идентификатор транзакции, чтобы можно было восстановить прямой список записей об изменениях базы данных данной транзакцией. Итак, индивидуальный откат транзакции (еще раз подчеркнем, что это возможно только для незакончившихся транзакций) выполняется следующим образом: •Выбирается очередная запись из списка данной транзакции. •Выполняется противоположная по смыслу операция: вместо операции INSERT выполняется соответствующая операция DELETE, вместо операции DELETE вы полняется INSERT и вместо прямой операции UPDATE обратная операция UPDATE, восстанавливающая предыдущее состояние объекта базы данных. •Любая из этих обратных операций также заносится в журнал. Собственно, для индивидуального отката это не нужно, но при выполнении индивидуального отката транзакции может произойти мягкий сбой, при восстановлении после которого потребуется откатить такую транзакцию, для которой не полностью выполнен индивидуальный откат. •При успешном завершении отката в журнал заносится запись о конце транзакции. С точки зрения журнала такая транзакция является зафиксированной. Восстановление после мягкого сбояК числу основных проблем восстановления после мягкого сбоя относится то, что одна логическая операция изменения базы данных может изменять несколько физических блоков базы данных, например, страницу данных и несколько страниц индексов. Страницы базы данных буферизуются в оперативной памяти и выталкиваются независимо. Несмотря на применение протокола WAL, после мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, то есть часть страниц внешней памяти соответствует объекту до изменения, часть — после изменения. К такому состоянию объекта неприменимы операции логического уровня. Состояние внешней памяти базы данных называется физически согласованным, если наборы страниц всех объектов согласованы, то есть соответствуют состоянию объекта либо до его изменения, либо после изменения. Будем считать, что в журнале отмечаются точки физической согласованности базы данных — моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память. Немного позже мы рассмотрим, как можно достичь физической согласованности. Назовем такие точки tpc (time of physical consistency) — точками физического согласования. Тогда к моменту мягкого сбоя возможны следующие состояния транзакций: •транзакция успешно завершена, то есть выполнена операция подтверждения транзакции COMMIT и для всех операций транзакции получено подтверждение ее выполнения во внешней памяти; •транзакция успешно завершена, но для некоторых операций не получено подтверждение их выполнения во внешней памяти; •транзакция получила и выполнила команду отката ROLLBACK; •транзакция не завершена. Физическая согласованность базы данныхКаким же образом можно обеспечить наличие точек физической согласованности базы данных, то есть как восстановить состояние базы данных в момент tpc? Для этого используются два основных подхода: подход, основанный на использовании теневого механизма, и подход, в котором применяется журналиаация постраничных изменений базы данных. При открытии файла таблица отображения номеров его логических блоков в адреса физических блоков внешней памяти считывается в оперативную память. При модификации любого блока файла во внешней памяти выделяется новый блок. При этом текущая таблица отображения (в оперативной памяти) изменяется, а теневая — сохраняется неизменной. Если во время работы с открытым файлом происходит сбой, во внешней памяти автоматически сохраняется состояние файла до его открытия. Для явного восстановления файла достаточно повторно считать в оперативную память теневую таблицу отображения. Общая идея теневого механизма показана на рис. 11.4. Рис. 11.4. Использование теневых таблиц отображения информации В контексте базы данных теневой механизм используется следующим образом. Периодически выполняются операции установления точки физической согласованности базы данных (checkpoints). Для этого все логические операции завершаются, все буферы оперативной памяти, содержимое которых не соответствует содержимому соответствующих страниц внешней памяти, выталкиваются. Теневая таблица отображения файлов базы данных заменяется на текущую (правильнее сказать, текущая таблица отображения записывается на место теневой). Восстановление к tpc происходит мгновенно: текущая таблица отображения заменяется на теневую (при восстановлении просто считывается теневая таблица отображения). Все проблемы восстановления решаются, но за счет слишком большого перерасхода внешней памяти. В пределе может потребоваться вдвое больше внешней памяти, чем реально нужно для хранения базы данных. Теневой механизм — это надежное, но слишком грубое средство. Обеспечивается согласованное состояние внешней памяти в один общий для всех объектов момент времени. На самом деле достаточно иметь совокупность согласованных наборов страниц, каждому из которых может соответствовать свои временные отсчеты. Для выполнения такого более слабого требования наряду с логической журна-лизацией операций изменения базы данных производится журнализация постраничных изменений. Первый этап восстановления после мягкого сбоя состоит в постраничном откате незакончившихся логических операций. Подобно тому как это делается с логическими записями по отношению к транзакциям, последней записью о постраничных изменениях от одной логической операции является запись о конце операции. В этом подходе имеются два метода решения проблемы. При использовании первого метода поддерживается общий журнал логических и страничных операций. Естественно, наличие двух видов записей, интерпретируемых абсолютно по-разному, усложняет структуру журнала. Кроме того, записи о постраничных изменениях, актуальность

которых носит локальный характер, существенно (и не очень осмысленно) увеличивают журнал. Поэтому все более популярным становится поддержание отдельного (короткого) журнала постраничных изменений. Такая техника применяется, например, в известном продукте Informix Online. Предположим, что некоторым способом удалось восстановить внешнюю память базы данных к состоянию на момент времени tpc (как это можно сделать — немного позже). Тогда: •Для транзакции Т1 никаких действий производить не требуется. Она закончилась до момента tpc, и все ее результаты отражены во внешней памяти базы данных. •Для транзакции Т2 нужно повторно выполнить оставшуюся часть операций (redo). Действительно, во внешней памяти полностью отсутствуют следы операций, которые выполнялись в транзакции Т2 после момента tpc. Следовательно, повторная прямая интерпретация операций Т2 корректна и приведет к логически согласованному состоянию базы данных (поскольку транзакция Т2 успешно завершилась до момента мягкого сбоя, в журнале содержатся записи обо всех изменениях, произведенных этой транзакцией). •Для транзакции ТЗ нужно выполнить в обратном направлении первую часть операций (undo). Действительно, во внешней памяти базы данных полностью отсутствуют результаты операций ТЗ, которые были выполнены после момента tpc. С другой стороны, во внешней памяти гарантированно присутствуют результаты операций ТЗ, которые были выполнены до момента tpc. Следовательно, обратная интерпретация операций ТЗ корректна и приведет к согласованному состоянию базы данных (поскольку транзакция ТЗ не завершилась к моменту мягкого сбоя, при восстановлении необходимо усхранить все последствия ее выполнения). •Для транзакции Т4, которая успела начаться после момента tpc и закончиться до момента мягкого сбоя, нужно выполнить полную повторную прямую интерпретацию операций (redo). •Наконец, для начавшейся после момента tpc и не успевшей завершиться к моменту мягкого сбоя транзакции Т5 никаких действий предпринимать не требуется. Результаты операций этой транзакции полностью отсутствуют во внешней памяти базы данных. Восстановление после жесткого сбояПонятно, что для восстановления последнего согласованного состояния базы данных после жесткого сбоя журнала изменений базы данных явно недостаточно. Основой восстановления в этом случае являются журнал и архивная копия базы данных. Восстановление начинается с обратного копирования базы данных из архивной копии. Затем для всех закончившихся транзакций выполняется redo, то есть операции повторно выполняются в прямом порядке. Более точно, происходит следующее: •по журналу в прямом направлении выполняются все операции; •для транзакций, которые не закончились к моменту сбоя, выполняется откат.

На самом деле, поскольку жесткий сбой не сопровождается утратой буферов оперативной памяти, можно восстановить базу данных до такого уровня, чтобы можно было продолжить даже выполнение незакончившихся транзакций. Но обычно это не делается, потому что восстановление после жесткого сбоя — это достаточно длительный процесс. Хотя к ведению журнала предъявляются особые требования по части надежности, в принципе возможна и его утрата. Тогда единственным способом восстановления базы данных является возврат к архивной копии. Конечно, в этом случае не удастся получить последнее согласованное состояние базы данных, но это лучше, чем ничего. Последний вопрос, который мы коротко рассмотрим, относится к производству архивных копий базы данных. Самый простой способ — архивировать базу данных при переполнении журнала. В журнале вводится так называемая «желтая зона», при достижении которой образование новых транзакций временно блокируется. Когда все транзакции закончатся и, следовательно, база данных придет в согласованное состояние, можно производить ее архивацию, после чего начинать заполнять журнал заново. Можно выполнять архивацию базы данных реже, чем переполняется журнал. При переполнении журнала и окончании всех начатых транзакций можно архивировать сам журнал. Поскольку такой архивированный журнал, по сути дела, требуется только для воссоздания архивной копии базы данных, журнальная информация при архивации может быть существенно сжата.

topuch.ru

Это интересно

Опрос

Полезные ссылки

Поиск по сайту

sql-server - Журнал транзакций для базы данных "databasename" заполнен.

sql - Журнал транзакций для базы данных заполнен sql-server sql-server-2008

Введение в базы данных | Журнал транзакций

sql-server - Журнал транзакций для базы данных заполнен. Чтобы узнать, почему пространство в журнале нельзя использовать повторно, см. Столбец log_reuse_wait_desc в sys.databases

Полный журнал транзакций для базы данных

Jimbo: Журнал транзакций для базы данных заполнен - Найдено 7 ответов

Журнал транзакций - Карпова Т. С.

Смотрите также