Базовые принципы резервирования для администратора. Часть III

Содержание:
1. Часть I;
2. Часть II;
3. Часть III (Вы читаете данный раздел);
4. Часть IV;
5. Часть V.

Эффект режима восстановления и журнал транзакций

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

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

Как сокращается и растет журнал транзакций

Операции записи в журнал транзакций (для обработки транзакций в файлах данных) и считывания данных из этого журнала (в целях восстановления) осуществляются на линейной шкале времени, но в режиме «кольца» — данный механизм чем-то похож на принцип работы смс шлюза: в обычных обстоятельствах, когда процесс доходит до конца физического файла, он возвращается обратно, к началу журнала транзакций. Иными словами, файл журнала регистрации вновь и вновь заполняется повторно при условии, что использованная ранее часть журнала помечается как предназначенная для повторной записи (иначе говоря, для усечения). Такое усечение неявным образом осуществляется и в режиме восстановления Simple.

А вот в режимах Full и Bulk-Logged подобное усечение может быть выполнено только с помощью резервной копии журнала регистрации транзакций, в которой для этого выделяется часть журнала, сохраненная в целях восстановления. Здесь я описываю данный процесс в упрощенном виде, ибо все, что вам нужно знать об этом на начальном уровне, сводится к следующему: усечение обеспечивает возможность повторного использования журнала регистрации транзакций, и единственный способ усечения этого журнала состоит в том, чтобы воспользоваться его резервной копией. Вот почему я акцентирую внимание на необходимости формирования резервных копий журнала регистрации транзакций при работе в режимах Full и Bulk-Logged. Без усечения с помощью резервных копий журнала регистрации транзакций этот журнал никогда не будет обслуживаться по принципу карусели. Он будет постоянно прирастать с конца до тех пор, пока либо вы не сделаете резервную копию этого журнала, либо закончится дисковое пространство, выделенное для соответствующего тома.

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