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

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

Настройка журнала регистрации транзакций

В этой статье мне хотелось бы, не слишком углубляясь, разъяснить для читателей концепцию автоматического роста (auto growth) и файловых настроек для журнала регистрации транзакций SQL Server. Вы можете иметь более одного журнала регистрации транзакций, но веских оснований для подобной настройки базы данных не существует. SQL Server не будет использовать несколько файлов журналов транзакций по принципу чередования. Система перейдет к следующему файлу, если таковой существует, и не будет «закольцовываться» на начало первого журнала до тех пор, пока не дойдет до конца последнего журнала регистрации транзакций, с учетом всех оговорок, касающихся усечения журналов. Как правило, журнал регистрации транзакций размещается на самой высокопроизводительной платформе хранения данных, отформатированной для оптимального выполнения операций записи с избыточностью для «зеркального» дублирования и чередования. Возможно, система RAID-5 будет самым экономичным вариантом, но ее использование приводит к непроизводительным затратам на операции записи четности, неоптимальным с точки зрения скорости записи. Система RAID-5 не очень подходит для форматирования дисков. Однако она сплошь и рядом используется при подготовке к работе средств хранения данных.

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

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

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

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

Возможно, вы обратили внимание на то, что переменная max_size_mb имеет значение NULL. Это объясняется тем, что данное значение не было задано. Теоретически оно «не ограничено», но в действительности, разумеется, ограничено объемом соответствующего тома устройства хранения.