SQL Server. Ведение журнала и восстановление в SQL Server

Одними из самых непонятных составных частей SQL Server являются механизмы ведения журнальчика и восстановления. Складывается воспоминание, что сам факт существования журнальчика транзакций и то, что неверное управление этим журнальчиком может приводить к неполадкам, ставит в тупик многих «невольных админов баз данных» (DBA). Почему журнальчик транзакций может неограниченно возрастать в размере? Почему в неких ситуациях требуется очень много времени для того, чтоб база данных стала доступной после сбоя системы? Почему нереально на сто процентов отключить ведение журнальчика? Почему не удается соответствующим образом вернуть базу данных? Что из себя представляет журнальчик транзакций, и для чего он существует?

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

Что из себя представляет ведение журнальчика?

Ведение журнальчика и процедура восстановления присущи не только лишь SQL Server — во все коммерческие системы управления реляционными базами данных (RDBMS) должны заходить эти средства для обеспечения поддержки разных параметров ACID транзакций. Сокращение ACID обозначает Atomicity (атомарность), Consistency (согласованность), Isolation (изоляция) и Durability (устойчивость), являющиеся базовыми качествами систем обработки транзакций (таких как RDBMS). Подробнее об этом можно прочесть в разделе «Свойства ACID» библиотеки MSDN.

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

Набор из 1-го либо нескольких конфигураций можно сгруппировать (и, практически, так всегда и делается) в транзакцию, обеспечивающую базисную единицу процесса внесения конфигураций (атомарность) в базу данных, когда идет речь о юзерах, разработчиках приложений и DBA. Транзакция заканчивается удачно (фиксация) либо заканчивается аварийно либо отменяется (откат). В первом случае гарантируется, что операции, формирующие транзакцию, отражены в базе данных. Во 2-м случае гарантируется, что операции не будут отражены в базе данных.

Транзакции в SQL Server бывают очевидными и неявными. При очевидной транзакции юзер либо приложение выдает оператор BEGIN TRANSACTION T-SQL, оповещающий о запуске данным сеансом группы связанных конфигураций. Очевидная транзакция удачно заканчивается, когда выдается оператор COMMIT TRANSACTION, оповещающий об успешном выполнении группы конфигураций. Если заместо него выдается оператор ROLLBACK TRANSACTION, все конфигурации, выполненные в данном сеансе с момента выдачи оператора BEGIN TRANSACTION, обращаются (откатываются), и транзакция отменяется. Откат транзакции может быть принудительно вызван наружным событием, к примеру, нехваткой для базы данных свободного места на диске либо выходом из строя сервера. Эти случаи подвергнутся рассмотрению дальше.

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

Вам может показаться, что в этом нет необходимости, так как один оператор T-SQL не может генерировать огромное число конфигураций в структурах хранилища базы данных, но разглядите, к примеру, оператор ALTER INDEX REBUILD. Хотя этот оператор не может содержаться в очевидной транзакции, он может генерировать большущее число конфигураций в базе данных. Потому нужен механизм, обеспечивающий в случае неверного развития событий (к примеру, если отменяется выполнение оператора) соответствующее выполнение воззвания конфигураций.

В качестве примера разглядим, что происходит, если в неявной транзакции обновляется одна строчка таблицы. Представим для себя ординарную неупорядоченную таблицу, содержащую столбец c1 с целочисленными данными и столбец c2 с символьными данными. В таблице имеется 10 000 строк, и юзер посылает запрос на обновление последующим образом.

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE ‘%Paul%’;

Производятся последующие операции.

Странички данных из SimpleTable считываются с диска в память (буферный пул), потому можно делать поиск соответственных строк. Оказывается, что на 3-х страничках данных имеется 5 строк, соответственных предикату предложения WHERE.
Модуль хранилищ автоматом запускает неявную транзакцию.
Эти три странички и 5 строк данных блокируются для выполнения обновлений.
Конфигурации вносятся в 5 записей данных на 3-х страничках данных, находящихся в памяти.
Конфигурации записываются также в записи журнальчика транзакций на диске.
Модуль хранилищ автоматом фиксирует эту неявную транзакцию.

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

Контрольные точки есть по двум причинам — для группирования операций ввода/вывода с целью увеличения производительности и для сокращения вермени, требуемого для восстановления после сбоя. В определениях производительности, если б страничка данных вытеснялясь на диск при каждом ее обновлении, число операций ввода/вывода в интенсивно применяемой системе могло бы превысить способности подсистемы ввода/вывода. Разумнее с некой периодичностью записывать на диск «грязные» странички (те, которые были изменены с момента их считывания с диска), чем записывать на диск странички немедленно после внесения в их конфигураций. Чуток ниже я рассмотрю контрольные точки исходя из убеждений восстановления.

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

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

В чем заключается восстановление?

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

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

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

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

Каким образом процедура восстановления выяснит, что следует делать? Все процедуры восстановления зависят от того факта, что любая запись журнальчика помечена регистрационным номером транзакции в журнальчике (LSN). Регистрационный номер транзакции в журнальчике является растущим номером из 3-х частей, совершенно точно определяющим положение записи журнальчика в журнальчике транзакций. Все записи журнальчика в транзакции хранятся в поочередном порядке в журнальчике транзакций и содержат код транзакции и LSN предшествующей записи транзакции. Другими словами, любая операция, зарегистрированная в качестве части транзакции, имеет оборотную «ссылку» на операцию, конкретно ей предыдущую.

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

Во время восстановления после сбоя механизм более сложен. Тот факт, что странички базы данных не записываются на диск при фиксации транзакции, значит, что нет гарантии того, что набор страничек базы данных на диске точно отражает набор конфигураций, обрисованных в журнальчике транзакций — как для зафиксированных, так и для незафиксированных транзакций. Но, имеется последний кусок паззла, о котором я еще не упоминал — в заголовке странички всех страничек базы данных имеется поле (96-байтная часть 8192-байтной странички, содержащая метаданные с информацией о страничке), содержащее LSN последней записи журнальчика, оказавшей воздействие на страничку. Это дает возможность системе восстановления принять решение относительно определенной записи журнальчика, которую нужно вернуть.

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

Механизм восстановления после сбоя прочитывает журнальчик транзакций и обеспечивает сохранение всех результатов зафиксированных транзакций в базе данных, а результаты всех не зафиксированных транзакций не сохраняются в базе данных — производятся фазы REDO и UNDO, соответственно. По окончании восстановления после сбоя база данных становится согласованной исходя из убеждений транзакций и доступной для использования.

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

Журнальчик транзакций

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

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

Журнальчик транзакций представляет собой особый файл, нужной хоть какой базе данных для соответствующего функционирования. В нем содержатся записи журнальчика, создаваемые в процессе ведения журнальчика, и журнальчик употребляется для повторного чтения этих записей во время восстановления (либо хоть какого другого, упоминавшегося ранее, использования процедуры ведения журнальчика). Так же, как место, занятое фактически записями журнальчика, транзакция в журнальчике транзакций резервирует также место для всех возможных записей журнальчика, которые потребовались бы в случае необходимости отменить транзакцию и выполнить откат. Этим разъясняется поведение, которое можно следить, когда, к примеру, для транзакции, обновляющей 50 МБ данных в базе данных, на самом деле в журнальчике транзакций может потребоваться место в 100 МБ.

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

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

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

SQL Server. Ведение журнальчика и восстановление в SQL Server

Рис. 1 Физическая архитектура журнальчика транзакций

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

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

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

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

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

SQL Server. Ведение журнальчика и восстановление в SQL Server

Рис. 2 Журнальчик транзакций после усечения журнальчика

Активные VLF образуют логический журнальчик, являющийся частью журнальчика транзакций, содержащей активные записи журналов. Сама база данных знает, с какого места процедура восстановления после сбоя должна начинать чтение записей журнальчика в активной части журнальчика — с начала самой старенькой активной транзакции в журнальчике, MinLSN (она хранится в загрузочной страничке базы данных).

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

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

SQL Server. Ведение журнальчика и восстановление в SQL Server

Рис. 3 Повторяющийся нрав журнальчика транзакций

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

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

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

Дополнительные сведения по данной теме см. в записи блога Кимберли Трипп (Kimberly Tripp) «8 Steps to Better Transaction Log Throughput» (8 шагов к увеличению пропускной возможности журнальчика транзакций). Кимберли дискуссирует рациональные методики, относящиеся к планированию объема журнальчика транзакций, усовершенствованию управления и увеличению производительности — эту запись точно стоит прочесть!

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

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

Полный перечень причин и советов по определению предпосылки, мешающей усечению журнальчика, см. в разделе «Factors that Can Delay Log Truncation» (Причины, задерживающие усечение журнальчика) ресурса SQL Server Books Online (Электрические книжки по SQL Server). Не считая этого, я сделал демо видеоклип, в каком показаны последствия неуправляемого разрастания журнальчика транзакций и метод устранения фрагментации VLF — ознакомьтесь с этой видеотрансляцией (и прошлыми трансляциями по вопросам SQL) по адресу technetmagazine.com/videos.

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

Ни в коем случае не следует удалять журнальчик транзакций, пробовать вернуть его при помощи недокументированных команд либо просто обрезать его при помощи характеристик NO_LOG либо TRUNCATE_ONLY команды BACKUP LOG (которая удалена из SQL Server 2008). Эти характеристики приведут или к несогласованности исходя из убеждений транзакций (и, что более возможно, к повреждению файла), или лишат способности соответствующего восстановления базы данных.

Подробнее о методах устранения проблем в переполненном журнальчике транзакций ознакомьтесь с разделом «Troubleshooting a Full Transaction Log (Error 9002)» (Устранение проблем в переполненном журнальчике транзакций (ошибка 9002)) электрической документации.

Модели восстановления

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

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

Модель восстановления BULK_LOGGED обладает таковой же семантикой усечения журнальчика транзакций, как и модель восстановления FULL, но допускает частичную регистрацию неких операций, что именуется малой регистрацией. Примерами являются повторное создание индекса и некие операции массовой загрузки — в модели восстановления FULL регится вся операция.

Но в модели восстановления BULK_LOGGED регистрируются только конфигурации рассредотачивания, что конструктивно уменьшает число создаваемых записей журнальчика и, в свою очередь, уменьшает потенциал разрастания журнальчика транзакций. Подробнее об операциях с малой регистрацией см. в разделе «Operations that Can Be Minimally Logged» (Операции, допускающие наименьшую регистрацию) электрической документации.

Модель восстановления SIMPLE, практически ведет себя исходя из убеждений ведения журнальчика так же, как и модель восстановления BULK_LOGGED, но имеет совсем другую семантику усечения журнальчика транзакций. В модели восстановления SIMPLE невозможны запасные копии журнальчика, что значит, что журнальчик может быть усечен (если ничто не держит записи журнальчика в активном состоянии) при появлении контрольной точки. Для каждой из этих моделей имеются резоны за и против, выраженные в определениях вероятных (либо требуемых) вариантов запасных копий и способности восстановления состояния на различные моменты времени (эти вопросы будут дискуссироваться позже в этом году в другой статье).

Заключение

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

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

В моем блоге содержится намного больше сведений о журнальчике транзакций и факторах, оказывающих на него воздействие — подробнее см. в «Shrinking the database before taking a backup» (Сжатие базы данных перед запасным копированием). Разные разделы электрической документации, относящиеся к журнальчику транзакций, также очень полезны — начиная с раздела Transaction Log Management (Управление журнальчиком транзакций).

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.