• Другие части статьи:
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• вперед »

Сжатие файла лога и почему такой операции не существует.

Итак, мы выходим на финишную прямую: второй заключительный раздел знаменует собой и окончание всего цикла статей. Автор, с его точки зрения, очень грамотно оставил самое «сладкое» на закуску. «Стабильно растет лог — что делать?», «лог не сжимается вообще», «режу лог — а он не режется!» ну и тому подобное. Кто из нас не видел таких и подобных топиков на различных IT-форумах? Не заметить их очень сложно, число их определенно выражается десятками, если не сотнями. Одним словом — вопрос «мега-популярен». И как раз его мы рассмотрим в лучших традициях данного блога: не спеша, вдумчиво и всесторонне. А так же, разумеется, отмечая некоторые «мифы и предания» с данным вопросом связанные. Полный список таких «мифов» составить малореально в виду многочисленности последних, но самые яркие «баллады» мы все же попробуем не упустить. Поехали!

Усечение журнала транзакций.

Сразу же расставим все точки «над ё» в механизме играющем в этом завершающем разделе роль неоспоримо центральную. Автор говорит, разумеется, об усечении лога, или, на языке оригинала, о log truncation. На самом деле, читатели изучающие данный цикл с первой части (навигатор по частям цикла — в верхнем правом углу каждой из частей, это на всякий случай), аккуратно воспроизводящие представленные скрипты, вдумчиво анализирующие отчеты этих скриптов, уже знают о названном процессе абсолютно все. Просто объяснения не были «концентрированными» поскольку в тех частях статьи наш фокус внимания приходился на иные вопросы, а усечение лога шло «фоном», просто потому что не упомянуть о нем было невозможно. Тем не менее о нем, об усечении, сказано решительно все и максимум что может автор — собрать эти «фоновые» упоминания в одном месте для вашего удобства. Это — пожалуйста.

Конечная задача обсуждаемого процесса чрезвычайно проста для понимания (если, конечно, предыдущие части статьи не избежали вашего внимания): пометить некоторые из «активных» VLF-ов как «неактивные». Или, переводя разговор в более техническое русло, сменить у некоторых VLF значение их колонки Status с 2 на 0. Ну а уж вдаваясь совсем в нюансы — сменить у некоторых VLF их текущий статус Recoverable на статус Reusable, как о том и говорит вот эта наша табличка. Да, в ней показано, что причиной смены статусов Recoverable → Reusable является именно усечение, но только для simple recovery model. А для двух альтернативных моделей восстановления то же самое изменение случается, вроде как, по иной причине — нет? Все верно, однако все становится на места, если мы выясним вопрос «а когда, собственно, это самое усечение лога имеет место быть»? Так вот причин вызывающих усечение, к радости тех кто любит все упрощать, только и ровно две:

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

Так что строго говоря VLF-ы переводятся из Recoverable в Reusable всегда только усечением, не важно какая модель восстановления задействована. Различаются лишь точки времени, когда такое усечение случается.

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

Так же разобран нами и вопрос какие из VLF-ов являются «годными» для перевода из одного статуса в другой. Те, что не содержат ни одной записи в диапазоне (MinLSN-MaxLSN), или, что эквивалентно, те из них что не относятся к активному логу. Однако — обратите внимание на нюанс: строго говоря все записи левее левой границы диапазона (т.е. левее MinLSN) могут рассматриваться как «не нужные» и подлежащие затиранию. Однако усечение работает исключительно на уровне отдельного VLF. А не на уровне записи этого VLF. Таким образом, даже если MinLSN уже расположилась на самом правом краю данного VLF, и 99.9% его записей уже, фактически, не нужны — статус сменен не будет. Вот когда MinLSN окончательно «покинет» границы VLF-а... Но не до этого момента! Если бы усечение умело работать на уровне отдельных записей не было бы проблемы слишком больших по объему VLF. А она, проблема эта — есть.

Не менее понятным должен быть факт, что при усечении не случается «принудительного зануления» тех VLF что высвобождаются для повторной записи. Если бы такое происходило, то, во-первых, работа с нашим сервером представляла бы из себя значительно более печальное зрелище, а, во-вторых, не ясно было бы назначение механизма «бит четности сектора». Тогда бы этот последний был как «пятое колесо», точка остановки чтения лога при процессе crash recovery была бы и так гарантированно очевидной, без всяких битов.

Наконец, почетный титул «миф всех сезонов» отходит той точке зрения, что усечение лога должно приводить к изменениям размера физического LDF-файла. Читателям данных строк бредовость этой мысли должна быть совершенно очевидна: как изменение статуса (по сути изменение значение байта, а может и бита, в заголовке каждого VLF) может влиять на размер хоть чего либо, а уж тем более на размеры физических объектов? Вот и автору это неизвестно. Однако миф на удивление стоек. Справедливости ради отметим повторно (хотя в части седьмой цикла это уже подчеркивалось) большую спорность того термина, что авторы обсуждаемого процесса выбрали для своего детища. На «бытовом уровне» «усечь» — эквивалент «сделать короче». Ну что тут скажешь? Не все бытовые аналоги применимы в такой сложной штуке как SQL Server.

Проявление данного механизма хорошо видны в трех последовательных отчетах прошлой части. Поскольку скрипт эти отчеты генерирующий устанавливает для тестовой базы данных модель SIMPLE, то усечение случается автоматически, вместе с каждым CHECKPOINT-ом. И последние, кстати, тоже происходят автоматически — мы не используем в цикле одноименную T-SQL команду. По сути от нас не требуется ничего, кроме как «не раздувать» активный лог от края до края физического лога. Тогда все происходит вполне ожидаемо: статусы VLF-ов (колонка Status) меняются с 2 на 0 и обратно, бит четности (колонка Parity) — с 64 на 128 и обратно, логический номер VLF (колонка FSeqNo) — монотонно возрастает. Обратите, кстати, внимание, что один и тот же физический VLF в разные моменты времени может иметь разные логические номера. Скажем первый из VLF-ов в первом отчете имеет номер 73, а в последнем, он же, уже 77-й. В этом нет никаких проблем. Если VLF-у 73-му в принципе разрешено менять свой номер это означает только одно: ни одна запись лога из содержащихся в этом VLF к текущему моменту нам более не нужна. То есть вообще не нужна, ни для каких целей. А стало быть и 73-й VLF как целое нам тоже не нужен.

Сжатие журнала транзакций.

Ну а вот теперь поговорим о процессе, который многими DBA понимается (точнее — подразумевается) когда последние произносят фразу «усекаю это я лог». На самом же деле они хотят обсудить его сжатие (shrink). Вот здесь, в отличии от процесса предыдущего, речь идет исключительно и именно об изменении (причем, очевидно, в меньшую сторону) физического размера LDF-файла, а одним из несомненных критериев человека со статусом «грамотный SQL администратор» является способность четко эти два процесса разделять и понимать ту пропасть что отделяет один от другого.

Что нам известно о сжатии лога? То что оно, сжатие это, безусловно доступно с технической точки зрения — с командой DBCC SHRINKFILE «страждущие» обретут искомое. А так же известно, что при соблюдении ряда условий свою «мета-задачу» (уменьшить размер LDF-файла) указанная команда выполняет. Но почему же автор в заглавии этой заключительной части цикла утверждает что такой операции якобы не существует? Потому что вам она — не нужна.

По сути, все «внешнее» управление лог-файлом сводится к двум простым пунктам (а в случае базы в модели SIMPLE вообще к одному):

• выработка четкой и продуманной стратегии увеличения размера лог-файла. Весь предыдущий раздел рассматривал, так или иначе, различные аспекты этой стратегии. Ну и конечно, этот пункт подразумевает не менее четкую реализацию утвержденной стратегии на практике;
• (только для баз данных с моделями восстановления bulk-logged / full) регулярное выполнение бэкапов лога. Периоды этой регулярности могут быть очень разными и описание подбора правильных их значений заслуживают отдельной заметки, если не статьи. Факт в том, что указанная «регулярность» должна быть «достаточной» для именно вашей системы.

А что плохого в сжатии как таковом? Почему автор данных строк настолько против этой «безобидной» команды? А к тому у него есть две причины: техническая (менее важная) и психологическая (более важная). Начнем с первой — технической.

Зачем на нормально (важно!) работающей системе DBA вообще может захотеть уменьшить лог? «Потому что он большой, а реально записей там мало». OK, а как так в принципе получилось? «А мы на прошлой неделе закрывали год, вот там гиговые транзакции и полетели, он и разбух (FILEGROWTH сработал). А в следующий раз мы год закрывать будем через 12 месяцев». Да, сценарий понятный: всегда был лог 200MB, а тут раз — 10GB!! Возникает «зуд» 9, а лучше 9.5 гигабайт «отмотать обратно». Хорошо, допустим сократили размер до приемлемых 400MB, что дальше? А дальше перед нами встает главный закон всех современных вычислительных систем: объем данных, в них хранящихся, растет не линейно, и даже не по закону степени, а согласно экспоненциальному закону. Это данные. А у нас с вами — лог, то бишь протокол изменения этих данных (напомню, что сами данные в этот протокол прекрасно включаются, наряду с прочими вещами). Так что ваши 10GB будут вновь с вами вовсе не через год, как вам мечтается, а хорошо если не через 3 месяца. А самый критичный момент во всем этом, что вот этот повторный рост 200MB → 10GB (возможно, что с «промежуточными остановками», конечно) приведет к повторному занулению 10 гигабайт. И эта работа, подчеркиваю еще раз, будет сделана по «второму кругу». Не глупо ли? С точки зрения автора — бред. Одним словом, учитывая что:

• объем транзакций один раз достигшей своей максимальной отметки X вернется вновь к этой же отметке с вероятностью 120%, вопрос лишь во временном промежутке разделяющих эти два события;
• «лишнее» место в лог-файле не сказывается на быстродействии системы вообще никак, недостаток места по воздействию на систему диаметрально противоположен ему;
• HDD на один терабайт стоит дешевле 100$ (на момент написания статьи). Это притом, что уж если мы говорим о транзакциях ТАКИХ масштабов, то речь однозначно не идет ни о home-, ни о small- офисах, а только о предприятии с серьезным числом сотрудников. А купить такой диск нужно однократно;

автор решительно отказывается обсуждать вопрос «как шринкуется файл лога». Никак не шринкуется. Точка.

Но есть и вторая причина, пожалуй и посерьезнее первой. Допустим, мы утвердили такую стратегию роста для нашего лог-файла: изначально — 10GB, максимум — 700GB, приращение — 0.9 от текущего размера, вручную, FILEGROWTH «на подстраховке». Плюс разработали правильную стратегию бэкапов вообще, и бэкапов лога в частности (наша база, как большинство баз промышленных, находится, само собой, в модели FULL). Как будет выглядеть типичная эксплуатация такого лога на нормально (снова важно!) работающей системе? А вот как:

• работа с логом в 10GB в течении трех месяцев;
• ручное увеличение лога до 19GB;
• работа с логом в 19GB в течении четырех месяцев;
• ручное увеличение лога до 36GB;
• работа с логом в 36GB в течении трех месяцев;
• ...

То есть, в течении довольно большого промежутка времени размер LDF-файла полностью статичен. Правильно функционирующее усечение лога обеспечивает всех наших пользователей не просто достаточным, а, как правило, избыточным местом под любые их мыслимые транзакции. Лог просто «ходит по кругу», не требуя к себе никакого дополнительного внимания. Затем, просто в силу того факта, что данных становится все больше (вновь экспоненциальный закон включается в действие), места перестает хватать и мы, дождавшись «часа затишья», спокойно увеличиваем лог до следующего «порога». Вся история повторяется заново до следующего расширения лога и т.д.

Что случается у адептов команды SHRINKFILE? У них, в 99.9% случаев, происходит ровно один и тот же «затык», у всех, как под копирку: «ломается» усечение лога! То есть нарушается нормальный цикл «круговорота» журнала транзакций и LDF-файл начинает, по выражению этих самых адептов, «расти на ровном месте». А почему это у них происходит? В чем причина «поломки»? Увы, вот тут уже никаких «копирок», каждый случай либо вообще индивидуален, либо, как минимум, со своими нюансами. Начиная от «а я никогда бэкапы лога и не делаю! а надо, что ли?» и заканчивая ооочень тонкими моментами связанными, скажем, с сессией зеркального отображения базы данных. «Покрыть» и разобрать абсолютно все возможные причины не представляется возможным даже если автор задумает еще один цикл статей, по объему равный циклу текущему. А уж если к тому же рассматривать пути решения этих проблем, то это будет что-то типа BOL-mini, поскольку придется разобрать едва ли не каждую заметную технологию предлагаемую SQL Server. Нельзя сказать, что производитель, т.е. всеми нами горячо любимый Microsoft, бросает нас в такую «тяжкую годину» на «произвол судьбы». Во-первых, у нас есть очень неплохая статья (и на русском, заметим) Факторы, могущие вызвать задержку усечения журнала, описывающая обсуждаемые причины до некоторой степени подробности. Во-вторых, у нас есть замечательная колонка log_reuse_wait_desc системного представления sys.database, описанная в той же статье. Значения этой колонки окажут вам неоценимую помощь в, как минимум, начале расследования инцидента. Автор без колебаний рекомендует означенную статью вашему пристальному вниманию, однако сразу предупреждает: в большинстве случаев и сама статья, и подходы в ней излагаемые, максимум покажут вам вектор «куда рыть». А вот именно «рыть» придется самостоятельно. Еще раз увы — потенциальных причин «затыка» усечения журнала — куча, все со своими предпосылками, все совершенно разноплановы, все требуют различных методик как «детектирования», так и исправления. Не вызывает сомнения лишь одна вещь, вот какая:

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

Разумеется, автор далек от мысли что любое применение команды SHRINKFILE — однозначный «криминал». Бывают ситуации когда она совершенно необходима по объективным причинам. Допустим, мы совершенно конкретно ошиблись с выбором стратегии увеличения размера лог-файла. То есть мы стали прирезать его слишком маленькими кусками и слишком часто. Теперь у нас 1000 VLF по 1MB каждый. Тогда идея «сжать лог по максимуму» (что, фактически, «выкинет» из него все неактивные виртуальные файлы журналов) и начать прирезание по стратегии «большие куски и редко» (кою и следовало избрать с самого начала) выглядит весьма здраво. Однако, согласитесь, это, во-первых, все-таки наш собственный «фэйл». А, во-вторых, обстоятельства подобные описанному не меняют «генеральной» картины мира: нормальной системе находящейся в нормальной эксплуатации сжатие лога не требуется никогда. Еще раз точка.

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

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

• отключать (detach) базу данных, физически удалять поврежденный (или даже просто переполненный) LDF-файл, и подключать (attach) один MDF-файл. Отдельные личности всерьез верят, что при этом SQL Server «пересоздаст валидный лог»;
• создавать многофайловые журналы транзакций «потому что тогда записи ведутся в несколько потоков, сразу в несколько LDF-файлов»;
• «оптимизировать», «перестраивать» и прочим образом «улучшать» лог утилитами третьих фирм. Помните, что с большой степенью вероятности внутренняя структура журнала на 100% известна только Microsoft и никому более;
• делать бэкап лога только с усечением, не создавая реального бэкапа (BACKUP LOG ... WITH TRUNCATE_ONLY) потому что это «быстро решает проблему переполненного лога». По счастью, начиная с SQL Server 2008 этот «дурацкий совет» не получится реализовать чисто технически, опции WITH TRUNCATE_ONLY / WITH NO_LOG просто удалены как элементы синтаксиса команды BACKUP LOG;
• разновидность предыдущего пункта доступная, разумеется, лишь «просветленным DBA» — делать бэкап лога на NUL устройство (т.е. команда типа BACKUP LOG TO DISK='NUL:'). К досаде автора вот этот бред продолжает синтаксически поддерживаться и в сервере 2008-м;
• сжимать (SHRINKFILE) лог. Да, в отличии от предыдущих пунктов нельзя сказать что это — «категорическое нет», но все же «почти всегда нет»;
• сжимать (SHRINKFILE) лог на регулярной основе, по расписанию. А вот это — необсуждаемый, совершенно полный и законченный бред. Даже продуманное и обоснованное однократное сжатие лога следует рассматривать как ситуацию чрезвычайную и как попытку предотвратить надвигающуюся катастрофу. Делая же это по расписанию вы признаете, что не прочь поработать «пожарником» на постоянной основе, вместо того что бы один раз тщательно потушить все «очаги возгорания» имеющиеся во вверенной вашим заботам системе.

Хотя, пожалуй, нет — автор все же нарушит данное им обещание не комментировать данный список и сделает исключение для его первого пункта. Дело в том, что в последние пару лет его буквально «забодали» всяческие «доброхоты» широко рекламирующие способ «сжатие-через-удаление-файла». Статьи о том как это делать «правильно» (угу) множатся просто как грибы, причем как в EN- так и в RU- сегменте SQL-сообщества. В статьях все красиво: скриншоты студии, контекстные меню, «умные» T-SQL команды... И даже «теоретическая база», да, а как же! Утверждается что процесс отключения (detach) базы обеспечивает «чистое закрытие» последней, после чего ее подключение не требует файла лога. В доказательство приводится аргумент FOR ATTACH_REBUILD_LOG команды CREATE DATABASE, в описании которого прямо сказано:

На это автор имеет заявить следующее.

Да, термин «чистое выключение» (или «чистое закрытие»), он же clean shutdown не является «самопалом», а имеет статус термина официального на 100%. Означает этот термин что при его старте база никем не используется (активных транзакций нет и начать новую уже невозможно), а абсолютно завершающим шагом (т.е. активностью) базы данных перед уходом её в off-line является контрольная точка (CHECKPOINT). Тогда при подключении такой базы обратно (через CREATE DATABASE с опцией ATTACH_REBUILD_LOG, а равно и при более привычном sp_attach_db) она будет успешно подключена и без LDF-файла. Считается, что отключение (detach, sp_detach_db) базы гарантирует именно «чистое закрытие», после которого LDF-файл можно «удалять официально». Собственно, это ключевой момент на котором построена вся эта «реклама» с «доступным удалением». Так вот этот самый момент — ошибочен. Факт успешного отключения базы не гарантирует «чистоту закрытия». Хотите «пруфлинк»? Да с нашим удовольствием!

Пока все отлично: создали базу, поработали... И готовы провести «чистое закрытие»:

На выходе:

Только подождите кричать «ага, так ведь это ж не чистое закрытие»!! Автор вовсе не утверждал вам что не будет никаких сообщений, он всего лишь заявил что факт успешного отключения базы не гарантирует «чистоту закрытия». Проверим логику?

• имеем ли мы факт успешного отключения (именно отключения, а не текстового подтверждения онного)? Вполне! Базы TstLog более нет на сервере, ее файлы никем и ничем не блокируются и находятся в полном вашем распоряжении;
• а имеем ли мы «чистое закрытие»? Сами-то как думаете?

Вывод: первое не гарантирует второе. Точно как и обещал автор. Только не надо «смешных» заявлений «а я всегда буду на экран внимательно смотреть». Конечно! И никогда в жизни не отвлечетесь на звонок, Skype, срочное e-mail сообщение, призыв «кофе попить» и т.п. А оставляя на время отпуска за себя коллегу по команде (вы в отпуск вообще не ходите?! так это ж другое дело! но большинство таки ходят...) вы, разумеется, «строго-настрого» накажете ему «внимательно смотреть туда же». В общем: человеческий фактор в данной, с позволения сказать, «технологии» не просто велик, а огромен. Что делает ее всю абсолютно не пригодной для систем с показателем критичности «низкий». Про системы средней и высокой критичности как-то неудобно и говорить даже...

И самое главное, хочется спросить у «рекламщиков»: «а просто усечение лога отремонтировать? Никак?»

Да, и что бы завершить с примером... Получив сообщение об ошибке сделайте вид, что вы отвлеклись и его пропустили. Затем переключайтесь в ваш любимый файловый менеджер и спокойно «сносите» TstLog_Log.ldf. Затем возвращайтесь в студию и подключайте нашу «чисто выключенную» базу:

После это на личном опыте убеждайтесь что «не все йогурты...». А уж реклама и подавно:

Снова — не поймите автора неправильно. Один-два раза в жизни подобный «финт ушами» сработает с вероятностью 99.99%. Но беда в том, что статьи об этом самом «финте» вовсе не говорят «это разовая акция, применять с осторожностью!». Если б такая цитата была первым предложением, да красным 72-м шрифтом — нет вопросов, в критических ситуациях все легальные (и даже полу-) методы хороши. Но в том-то и беда, что авторы таких публикаций сами пребывают в уверенности что предлагаемая ими методика должна рассматриваться как «нормальное, ежедневное обслуживание базы» и учат тому же своих читателей, и даже подчас прямо это рекомендуют. И ВОТ ЭТО — кошмар. И тихий ужас.

Заключение.

Что же, наше «небольшое погружение» в тему «как работает журнал транзакций» подошло к концу. Автор надеется, что каждый из читателей извлек для себя что-то полезное, и что этот замечательный механизм (а он и в самом деле замечателен по большинству своих параметров) открылся ему с новой стороны. Нельзя сказать что нами рассмотрены все аспекты журналирования транзакции, нет конечно. Указанная тема неисчерпаема по определению, и автор, несомненно, будет время от времени к ней возвращаться. Во-первых, ему есть что добавить к вопросу вообще, а, во-вторых — жизнь не стоит на месте. Тот же SQL Server 2012 привнес пару весьма примечательных улучшений в работу лога (хотя, казалось бы — как можно улучшить то, что и так лучшее? а — вот, нет предела совершенству) которые сами по себе заслуживают отдельного рассказа. В тоже время, автору хотелось бы верить, что данный цикл уже самодостаточен и что он закладывает «уверенный фундамент» на основе которого дальнейшее самообразование по указанной теме будет занятием значительно более простым. Думается, что теперь даже самые сложные статьи, главы книг и разделы BOL посвященные логу и вопросам вокруг него крутящимся, покажутся читателям простыми и понятными.

Итак, что же мы узнали из каждой части цикла? Если попробовать составить такое своеобразное «оглавление частей» (а навигация по ним, напомню, находится в начале и конце каждой части) то мы увидим, что нами последовательно и планомерно были изучены:

• Часть 1. Введение, основы журналирования транзакций, понятие о write-ahead logging.
• Часть 2. Физическая структура страниц данных, недокументированная команда DBCC PAGE и ее отчет, определение «чистоты» страницы данных, проверка текущего размера лог-файла.
• Часть 3. Физическая структура журнала транзакций, понятие о виртуальных лог-файлах (VLF), недокументированная команда DBCC LOGINFO и ее отчет, недокументированная команда DBCC LOG и ее отчет.
• Часть 4. Операция контрольной точки (checkpoint) и ее воздействие на журнал транзакций, понятие о возобновлении (recovery) и восстановлении (restore) базы данных, понятие о возобновлении при восстановлении базы данных, понятие о возобновлении при рестарте сервера, три фазы процесса возобновления, понятие о fast recovery.
• Часть 5. Периодичность автоматических контрольных точек, описание опции сервера recovery interval, понимание воздействия контрольной точки на «грязные» страницы.
• Часть 6. Понятие о цикличности журнала транзакций, влияние отката транзакции (rollback) на журнал транзакций, а так же влияние отката на систему в целом.
• Часть 7. Понятие о статусах виртуальных лог-файлов, определение минимального регистрационного номера восстановления в журнале транзакций (MinLSN), определение места MinLSN в журнале транзакций.
• Часть 8. Обсуждение процесса изменения статусов виртуальных лог-файлов, события вызывающие эти изменения, сравнение «больших» и «малых» транзакций по их воздействию на журнал, переполнение журнала транзакций, причины ведущие к разрастанию лог-файла, формат идентификатора записи журнала (LSN), понятие о буфере записей журнала.
• Часть 9. Понимание влияния буфера записей журнала на размер блоков виртуальных лог-файлов, проблема разноформатных LSN, фиксация LSN последней инструкции менявшей содержимое страницы данных и понимание нужности этой информации для фазы analysis процесса crash recovery.
• Часть 10. Размер физического LDF-файла и контроль его роста, понимание роли бита четности в секторе лог-файла, понимание необходимости зануления LDF-файла при создании и приращении.
• Часть 11. Понимание невозможности использования опции instant file initialization для файла лога, типичные ошибки в стратегии приращения лог-файла, понимание важности поддержания баланса в числе и объеме виртуальных лог-файлов.
• Часть 12. Понятие об усечении журнала, о сжатии журнала и о различии этих двух концепций; понятие о фактической избыточности операции сжатия журнала, понимание важности процесса усечения и поддержке нормального течения этого процесса, определение причин мешающих усечению журнала, типичные заблуждения связанные с журналом транзакций.

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

• Другие части статьи:
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• вперед »