Расчёт
выделяемого дискового пространства для новой базы
данныхЗащита
целосности данныхСоздание
базы данныхПараметры
базы данныхЗаконы
Мэрфи для баз данныхИзменение
баз данныхЗаконы
Мэрфи для журналов транзакцийМанипуляции
базами данныхОтказоустойчивостьФайлгруппыВопросы
для повторения
Расчёт выделяемого дискового пространства для новой базы
данных
Для того, что бы Вы могли верно, и на долго рассчитать тот
объём дискового пространства, который потребуется вновь
создаваемой базе данных (БД) в отведённые сроки её работы,
потребуется уяснить некоторые принципы организации хранения
данных и журналирования транзакций.
Новая БД, с точки
зрения операционной системы, представляет собой набор файлов:
*.mdf - главные файлы данных; *.ndf - вспомогательные файлы
данных; *.ldf - файлы журналов транзакций. Именам файлов SQL
Server сопоставляет свои логические имена. Разумеется, по
своей природе данные и журналы транзакций отличаются по типу
доступа/записи (первые - случайный доступ, вторые -
последовательный доступ) и поэтому располагаются у Вас на
разных дисковых массивах. Следовательно, расчёт занимаемого
места БД и журналов должен выполняться с учётом наличия
свободного дискового пространства на этих массивах. Опасность
того, что сервер исчерпает выделенное для него пространство на
диске, остаётся, не смотря на динамическое управление размером
файлов баз данных. Фундаментального изменения по сравнению с
версией сервера 6.5 не произошло, там тоже можно было
растянуть размер файла на всё доступное дисковое пространство.
Зато всё сильно усложняется, если на одном дисковом массиве у
Вас "живут" несколько файлов баз данных. Если Вы не можете
точно прогнозировать возможное увеличение объёма каждой из
этих баз, прогнозирование момента добавления/приобретения
дискового пространства превращается в задачу с несколькими
неизвестными. Кроме того, появятся неприятные факторы снижения
эффективности дисковых операций связанные с фрагментацией
файлов. Может быть, удачным выходом, при таком раскладе,
станет возврат к испытанному в предыдущих версиях методу
фиксации размера файлов баз данных.
Последовательное
создание файлов БД позволит избежать их файловой фрагментации,
а периодическая перестройка индексов позволит упорядочить
данные внутри.
БД содержит в себе копию базы данных model,
которая включает в себя системные таблицы, а также таблицы
данных и индексы к ним.
Отсюда вытекает первое правило:
хорошая БД не может быть меньше, чем model.
Таблицы
и индексы БД располагаются в т.н. экстентах (экстент - 8
смежных страниц, страница - 8 КБ последовательно расположенных
блоков диска, в 1 МБ помещается 16 экстентов или 128
страниц).
Если таблица меньше размера экстента, то он может
разделяться между несколькими таблицами. Таблицы состоят из
строк, которые не могут превышать размер страницы и даже
немного меньше.
Из 8 КБ на строку отводится не более 8060
байт, остальное - накладные расходы на её хранение.
Защита целосности данных
Любое изменение данных, которое осуществляется через
исполнение соответствующих операторов T-SQL, должно быть
защищено от всякого рода неожиданностей (например, веерное
отключение электричества местными энергетиками) и исполняться
только в том виде, в каком оно представлено логикой приложения
и сервера баз данных. Иначе нарушится целостность и
согласованность данных, а восстановление окажется невозможным.
Т.о. нам необходимо зафиксировать состояние данных до внесения
изменений, провести необходимые операции и убедиться, что всё
получилось. Иначе, первоначальное состояние должно быть
восстановлено. SQL сервер предоставляет нам такой механизм, а
цепочки логически связанных блоков операторов T-SQL, которые
могут быть выполнены только целиком или не выполняться вообще,
называются транзакциями.
Разумеется, транзакций происходит
в каждый момент очень много и параллельно, поэтому их
приходится журналировать. Существует, правда, опасность того,
что не спасёт даже этот замечательный механизм. Например, не
верная конфигурация RAID контроллера (когда не отключено его
собственное кэширование) может привести к тому, что изменения
в журнале транзакций не успеют записаться на диск, поскольку
застрянут в кэше контроллера. Изменения данных, не отражённые
в журнале, откатить не получится. Есть операторы, которые
неявно (для нас) составляют сами целую транзакцию. Естественно
это: DELETE, UPDATE и INSERT. Обычные же транзакции
обрамляются операторами BEGIN TRNSACTION и COMMIT TRNSACTION.
Следовательно, если Вы или Ваши разработчики напичкаете между
ними очень много всякого "действа", то и получите
соответствующую утилизацию журнала транзакций. Уж тогда
позаботьтесь, что бы на диске было достаточно места для его
"разбухания". В обычном случае, как это предустановленно по
умолчанию, хватает 25% от размера основной базы. Но нельзя
забывать и про индексы, они (в зависимости от фантазии
создателя) могут включать в себя разнообразные наборы полей и,
как правило, имеют тенденцию плодиться. С другой стороны,
большинство прикладных применений не создаёт чрезмерной
утилизации журналов. Большая нагрузка на них может случаться
во время массовых операций (например, подгрузка данных или
нечто подобное), которые осуществляются не часто. Измерение
размеров журналов во время "спокойной" работы сервера может
быть чревато неприятностями, когда на Вас обрушится лавина
инсёртов.
Ещё одним фактором, косвенно влияющим на размер
журнала транзакций, является интервал появления контрольной
точки. Для понимания этого влияния, углубимся немного в
транзакционный механизм. Прежде, чем данные изменятся, сервер
вытаскивает их в буферный кэш. Все операторы и их
параметры/значения в режиме опережающей записи записываются
вначале в журнал, а уже потом происходит изменение данных.
Данные записываются не сразу и не при первой возможности
сервера предоставить для этого соответствующие ресурсы, а
только когда сервером, в соответствии с заданной в
конфигурации установкой, инициализируется процесс контрольной
точки. До этого момента данные не изменяются, хотя транзакция
уже выполнила COMMIT TRNSACTION. В случае неприятностей, Вы
такую транзакцию не потеряете. Механизм автоматической
регенерации выполнит её после восстановления нормальной работы
сервера. Откату в исходное состояние подлежат только те
транзакции, у которых не зафиксирован маркер COMMIT
TRNSACTION. Теперь, можем себе представить типовую российскую
фирму, старающуюся изо всех сил сэкономить на "железе" для
сервера баз данных. DBA (как правило, "гуру" в своём деле),
стараясь сбалансировать загрузку "камня" и I/O, вполне может
сделать время появления контрольной точки достаточно большим.
Далее, вспомним, какие меры принимаются для того, что бы до
следующей перегрузки сервера вы не заполнили свой журнал до
конца. Естественно, транзакции резервируются на
соответствующее устройство, и это происходит с предусмотренной
тем же DBA периодичностью. Получается вилка, чем дольше не
появляется контрольная точка, тем больше данных мы не можем
забрать из журнала на резервную копию. В наших, особых
условиях не исключено, что Вы в такую вилку попадёте.
Создание базы данных
Для того, что бы создать новую базу данных, Вам, в первую
очередь, нужно придумать ей имя. (Как именовать базы и их
объекты Вы могли прочитать в 7 рассылки от 4 июля 2000г.). Под
этим именем информация о Вашей базе данных будет помещена в
таблицу sysdatabases базы master. При создании новой базы
данных SQLS7 использует, как образчик, специальную базу model,
которая просто копируется с переименованием. Те параметры и
настройки, которые Вы установили для базы model, автоматически
наследуются вновь созданными базами. Но одного только имени
базы данных Вам будет не достаточно. Поскольку база будет
расположена в файле/файлах операционной системы, нужно и им
придумать, как логические имена (NAME), так и имена файлов
(FILENAME). Кроме того, мы уже знаем, что база данных может
располагаться в нескольких файлах, которые, в свою очередь,
можно раскидать по разным дискам. Разумеется, есть самый
первый файл (PRIMARY), входящий в главную группу файлов
(*.mdf) и в котором есть ссылки на все остальные файлы (*.ndf
и *.ldf), которые есть у базы данных.
Главная группа файлов
предназначена для хранения всех системных таблиц базы и тех
объектов, которые не назначены пользовательским группам
файлов. Возможность "крошить" файл баз данных на кусочки,
кроме очевидного усложнения администрирования, может послужить
и во благо. Например, Вы можете поместить в разные файловые
группы таблицы, отличающиеся по типу доступа (последовательный
или случайный), а сами файлы разместить на разных дисковых
массивах. Всё это будет очень похоже на разделение баз и
журналов или информации OLAP и OLTP. Для журнала регистрации
транзакций новой базы данных Вам также нужно будет придумать
имя NAME и FILENAME.
Для баз и журналов допустима аналогия
с SQL сервером 6.5 - имя устройства и файла. Впрочем, как и в
6.5 нужно указать некоторую информацию о размерах новой базы.
Поскольку новая база получается путём копирования model, то
главный файл не может быть меньше её размера. Учтите это при
задании стартового размера базы (SIZE). Размеры предлагается
задавать в мегабайтах, причём меньше 512 КБ задать нельзя. По
умолчанию, задаётся 1 МБ. Кроме того, вспомните о чём писалось
в прошлом выпуске рассылки по поводу фрагментации файлов
(когда на одном диске у вас могут жить несколько динамически
изменяющихся файловых групп), и исходя из этого, задайте
минимальный SIZE и максимальный (MAXSIZE) размер файлов. Если
MAXSIZE не задан, база будет динамически расширять файл до
заполнения им всего свободного дискового пространства.
Разумеется, динамическое изменение размера файла не
подразумевает плавное изменение. Во-первых, сервер не умеет
изменять его размер на величину меньшую/некратную размеру
экстента (64КБ). Вы можете регулировать величину приращения
файла (FILEGROWTH) от 0 до MAXSIZE устанавливая значения в
мегабайтах или килобайтах, которое будет автоматически
округлятся до величины кратной размеру экстента. Кроме того,
можно задать приращение в процентах, по умолчанию (если
FILEGROWN не указан) установлено 10 процентов.
Все
вышеперечисленные соображения действительны, как для файлов
базы данных, так и для её файлов журнала транзакций. Создать
новую базу Вы можете в SQL SEM или воспользуйтесь
оператором:
CREATE DATABASE "ИМЯ_БАЗЫ"
[ON
{[PRIMARY] (NAME =
"Логическое_Имя_Файла_Базы"
FILENAME =
'Полное_Имя_Файла_Операционной_Системы'
[, SIZE =
"РАЗМЕР"]
[, MAXSIZE = "МАКСИМАЛЬНЫЙ_РАЗМЕР"]
[,
FILEGROWTH = "ПРИРАЩЕНИЕ"])
} [,...n]
]
[LOG ON{(NAME
= "Логическое_Имя_Файла_Журнала"
FILENAME =
'Полное_Имя_Файла_Операционной_Системы'
[, SIZE =
"РАЗМЕР"])
} [,...n]
]
[FOR RESTORE]
Из осторожности, сделайте резервные копии до, и после
создания новой базы.
Параметры базы данных
В процессе разработки и создания баз данных Вам может
понадобится изменить некоторые её параметры, для обеспечения
специальных ограничений на разные этапы установки и
эксплуатации. Параметры позволяет менять MS SQL SEM или
sp_dboption.
Если Вы находитесь на этапе разработки базы,
логично ограничить доступ всем другим установкой параметра
dbo_use_only, т.е. сделать её доступной только
владельцу.
Если Вы хотите исключить изменение данных кем бы
то ни было, установите ей reade_only.
Процесс наполнения
таблиц информацией из внешних источников (BCP) или массовое
копирование (SELECT INTO) не желательно журналировать,
что решается установкой select into/bulkcopy.
Некоторые
операции можно выполнить в однопользовательском режиме single
user, помните только, что MS SQL SEM зачастую использует два
подключения.
Когда Вам без надобности резервировать
транзакции и Вас устраивает, что после каждой контрольной
точки они будут удаляться из журнала, установите trunc. log on
chkpt.
Если у вас проблемы с дисковым пространством, а
количество данных может уменьшаться (вынос в долговременный
архив), поставьте autoshrink, и база будет уменьшаться
автоматически.
Когда вы создаёте много схожих баз данных,
можно установить параметры для model и тогда, все установки
для этой базы данных будут наследоваться вновь
созданными.
Посмотреть, какие параметры (кроме
перечисленных выше) можно настроить для Ваших баз данных, Вы
можете с помощью sp_dboption.
Список всех баз можно
получить от sp_helpdb, а указание в качестве параметра этой
процедуры имени базы данных позволит получить только для неё:
размер, владельца, sid, дату создания, параметры, список
файлов. Если Вас заинтересует, сколько места занимает база или
её журнал на диске, используйте sp_spaceused [имя-объекта].
Законы Мэрфи для баз данных
1. Если Вы создали новую базу данных, набили её данными,
привязали к ней пользователей и т.д., тут же выяснится, что
структуру и состав данных надо менять.
2. Если вы
запланировали объём базы данных на ближайшую перспективу и,
исходя из этого, рассчитали требуемое< дисковое
пространство, не показывайте цифры шефу, пока не умножите их
на два (а лучше на три - с учётом поправки на Microsoft).
Помните, дискового пространства для данных не бывает много.
Отрезок времени, на который Вы рассчитали время стопроцентной
утилизации дискового пространства вашими данными, нужно
поделить на два. После этого, поделите на три то время,
которое Вы считаете можно жить спокойно.
Поэтому, давайте сразу рассмотрим, как вносить изменения в
базу данных.
Изменение баз данных
Поскольку, самым злейшим врагом любой современной СУБД
является рост файлов данных, научимся управлять этим
процессом. В предыдущих номерах мы уже (слегка) касались этой
темы. Разумеется, можно разрешить файлу расти автоматически.
После этого, Вам придётся, возможно, только изредка,
поглядывать на остаток дискового пространства на той/тех
дисковой системе, где у Вас положен файл/файлы данных. Здесь,
оптимальным кажется получение неких алармов при уменьшении
пространства до некоего порогового значения. Можно просто
контролировать заполнение файлов и, при необходимости (если не
прозеваете) увеличивать их вручную. А если у Вас уже не
осталось места или нет денег на RAID, можно прицепить к
основному файлу вспомогательный на дополнительном диске или
массиве. Все эти возможности доступны через MS SQL SEM или
через оператор ALTER DATABASE. Для автоматизации процесса, Вам
потребуется задать некоторый набор параметров, не всегда
обязательных. Это могут быть: начальный размер, максимальный
размер, величина приращения. Мы уже знаем, что если не
задавать максимальный размер, файл будет расти, пока не
заполонит собой всё, а нулевое приращение не позволяет файлу
расти автоматически. Отказ от автоматики вынудит Вас, в случае
увеличения файла, воспользоваться возможностями графического
интерфейса Enterprise Manager или освоить синтаксис оператора
ALTER DATABASE, краткое описание которого ниже:
ALTER DATABASE ИмяБазыДанных
{ADD FILE
<описание_файла> [TO FILEGROUP имя_файлгруппы]
[FOR RESTORE]
| ADD LOG FILE
<описание_файла>
| DROP FILE логическое_имя_файла
| CREATE FILEGROUP
имя_файлгруппы
| DROP
FILEGROUP имя_файлгруппы
|
MODIFY FILE <описание_файла>
}
Здесь для нас ключевым параметром является MODIFY FILE
<описание_файла>. Через него, устанавливая значения для
описателей: NAME, FILE NAME, SIZE, MAXSIZE и т.п., можно
осуществить обозначенные выше действия. Причём, как Вы,
наверное, заметили, безразлично какой файл Вы расширяете,
данных или журнала. Единственное отличие (не синтаксическое),
в том, что поведение журнала транзакций труднее предсказать.
Эта "головная боль", пожалуй, требует отдельного упоминания.
Законы Мэрфи для журналов транзакций
1. Расчёт оптимального размера журнала транзакций не
поддаётся здравому смыслу.
2. Если кто - либо может, без
Вашего ведома, закачать в индексированную таблицу уйму данных,
он это сделает.
3. Если Ваша БД может хранить в полях
таблиц (или иным образом) большие объекты (изображения, MP3,
офисные документы, текстовые данные), то всегда найдётся
пользователь, который захочет загрузить свой (несколько
гигабайтный) архивчик за один присест.
4. Если прикладное
ПО для Вашей базы данных пишет кто - ни будь другой
(разумеется, не Вы), помните, ни один программист не знает,
что в таких операторах, как INSERT, UPDATE, или DELETE есть
предложение WHERE. И даже Гуру в набивании кода, не часто
помнят, что предложение WHERE нельзя оставлять в слишком общем
виде.
5. Между двумя операторами BEGIN TRNSACTION и
COMMIT TRNSACTION программист поместит максимально
большое количество кода.
Как видите, для журналов "законов" побольше получилось...
Остаётся только посочувствовать DBA, у которого набор данных в
базе разношёрстный. Тут даже Microsoft разводит форточками в
стороны и, стыдливо, отсылает Вас к Performance Monitor, за
которым Вы должны неусыпно выслеживать безумства своих юзеров.
Названия счётчиков приводить нет смысла, они легко обнаружимы
и их не больше, чем пальцев на левой задней ноге марсианина.
Если же у Вас с данными всё "тихо", Вы можете просто
посматривать на заполненость лог - файла в MS SQL SEM. Но, на
всякий случай, держите ухо востро, или временно увеличьте
размер журналов, когда:
- происходит массовая загрузка по
индексу в таблицу, вследствие чего, все вставки/изменения
индекса журналируются;
- необходимо выполнить изменение
текстовых или иных громоздких данных в таблицах посредством
операторов WRITETEXT или UPDATETEXT при включённой регистрации
изменений с помощью WITH LOG.
Если Вы планируете нечто не
ординарное, убедитесь, что у Вас хватит места в журнале для
всех индексов таблицы, а потом вспомните упомянутые законы
Мэрфи. И тогда, считайте, что у Вас дело началось
хорошо...
Манипуляции базами данных
Кроме уже известного Вам механизма автоматического
уменьшения размера базы данных, существует возможность
выполнять эту операцию вручную. Самым удобным способом
является использование MS SQL SEM. Альтернативный вариант,
использование операторов SHRINKFILE и SHRINKDATABASE утилиты
DBCC. Поскольку DBCC действует достаточно "тупо", существуют
некоторые ограничения на эти операции.
В задачу
представляемых операторов не входит изменять существующую
структуру распределения данных внутри файлов базы, а,
следовательно, перемещать строки в не распределённые страницы.
По этому, перемещение данных возможно только в случае
опустошения файла с переносом данных в другие файлы его
файл-группы.
Естественной границей, до которой возможно
уменьшение файлов или базы, является область размещения
данных. Таким образом, база данных будет уменьшаться до
первого встречного заполненного экстента. Кроме того, сервер
помнит минимальное, стартовое значение размера базы данных,
которое вводилось через параметр SIZE оператора CREATE
DATABASE (который, в свою очередь, не может быть меньше
размера model) и не даст Вам уменьшить базу до размера
меньшего, чем SIZE (только для SHRINKDATABASE). Если Вы
изначально фиксировали размер базы, воспользуйтесь SHRINKFILE.
При высокой степени фрагментации данных внутри файлов базы,
может понадобится их предварительное упорядочивание
(переиндексация к примеру) для того, что бы повысить степень
"сжатия" базы.
После выполнения указанных операторов,
уменьшение базы или файлов не происходит мгновенно. Эти
манипуляции осуществляются в отложенном режиме и потребуют,
возможно, продолжительного времени.
Высвобождающееся
дисковое пространство может быть передано операционной системе
(флаг TRUNCATEONLY, или по умолчанию) или нет (NOTRUNCATE). Во
втором случае уменьшение файлов не происходит, изменяется
только область размещения внутри них базы или журналов.
До
выполнения описываемых манипуляций, настоятельно рекомендуется
создать резервные копии master и самих (уменьшаемых) баз
данных.
Синтаксис оператора SHRINKFILE следующий:
DBCC SHRINKFILE
({file_name |
file_id}
{[,
target_size]
| [,
{EMPTYFILE | NOTRUNCATE |
TRUNCATEONLY}]
}
)
ГДЕ:
File_name - логическое имя файла.
File_id -
идентификатор файла, соответствующий записи в таблице sysfiles
текущей базы данных.
Target_size - желаемый размер, до
которого хотелось бы уменьшить размер файла. Должен быть целым
числом. Если этот аргумент опустить, файл будет сжиматься до
"упора".
Флаг EMPTYFILE говорит о том, что из указанного файла
данные должны быть перемещены в другие файлы той же группы.
Больше этот файл использоваться сервером не будет и его можно
удалить с помощью оператора ALTER DATABASE.
Синтаксис оператора SHRINKDATABASE следующий:
DBCC
SHRINKDATABASE
(database_name [,
target_percent]
[,
{NOTRUNCATE | TRUNCATEONLY}]
)
Кроме имени базы, Вам предлагается ввести процент желаемого
свободного пространства.
Последний аргумент будет
игнорироваться, если используется флаг TRUNCATEONLY, который
отдаст операционке всё, что возможно.
Уменьшение размера
файлов журнала транзакций выполняется в рамках отложенной
операции, причём так, как будто это один файл. Все файлы
журнала сбрасываются, и сервер начинает манипулировать их
размерами, для того, что бы итоговый размер как можно ближе
соответствовал заданному Вами значению аргумента
target_percent.
Если же у Вас возникло желании сократить размер базы данных
так, что бы от неё ничего не осталось, Вы можете её удалить
воспользовавшись:
DROP DATABASE database_name [,...n]
Список удаляемых баз данных (а их, через запятую
указывается сколько угодно) можно легко получить из таблицы
sp_helpdb базы master. Удалять базы данных, которые были
созданы при инсталляции сервера не рекомендуется. Например,
база msdb может пригодиться если Вы будете использовать: SQL
Server Agent, репликации, мастер создания WEB-узлов или
DTC.
Не пытайтесь удалить базу, если с ней кто - либо
работает или она публикует свои таблицы в процессе репликации,
а также когда эта база восстанавливается. У Вас ничего не
получится! После удаления базы, сделайте копию master.
Отказоустойчивость
В официальном курсе Microsoft вопросы отказоустойчивости
сведены к стандартному набору возможностей операционной
системы Windows NT. Речь идёт об использовании избыточных
массивов недорогих дисков (RAID), которые можно
конфигурировать средствами Disk Manager. Надеюсь, читатели
понимают, что этот вариант приемлем только из великой
бедности, в виду невероятно большого отвлечения ресурсов
операционки на поддержание подобного сервиса. Поскольку
решение на базе аппаратного RAID контроллера не приводит к
значительному удорожанию проекта в целом (исключая варианты, в
которых необходимо достигать очень высоких показателей
доступности и готовности, т.е. определённого уровня
толерантности), совершенно бессмысленно возлагать на ОС не
свойственные для неё задачи. Кроме того, действительно высокий
уровень отказоустойчивости достигается путём значительных
инвестиций в дублирование и резервирование не только дисков,
но и всех составляющих систем аппаратно - программного
комплекса. Тут следует подумать о кластеризации серверов,
дублировании RAID контроллеров и дисковых массивов,
резервирование сетевых соединений и каналов связи, а также об
обеспечении резервного копирования на магнитные ленты,
организованные в RAID массив. Но не малую роль играет и
собственная отказоустойчивость серверов. Архитектура
современного сервера может обеспечить Вам должную защиту от
выхода из строя процессоров, памяти, контроллеров,
вентиляторов, источников питания и т.п.
Возвращаясь к
официальному курсу, рассмотрим обеспечиваемые Windows NT
возможности организации отказоустойчивых дисковых массивов.
Для этого Вам понадобятся минимум два диска. Уровень RAID-0
обеспечит чередование дисков, причём данные пишутся и читаются
одновременно на всех дисках, по блоку на каждом и по порядку.
Производительность самая высокая, а отказоустойчивость даже
хуже, чем у одного диска. Поскольку при сбое любого диска
теряются все данные в текущей цепочке чередования.
Уровень
RAID-1 представляет собой зеркалирование дисков/разделов при
котором все изменения на основном диске отображаются на
"зеркало". Ценой потери половины дискового пространства
достигается сокращение до минимума времени восстановления
работоспособности системы в случае выхода из строя одного из
дисков.
Уровень RAID-5 представляет собой чередование
записи блоков по дискам (а их уже не менее трёх) с контролем
чётности по каждой цепочке чередования. Из трёх дисков (если
их всего три), один теряется на хранение блоков контроля
чётности. При увеличении количества дисков потери дискового
пространства на поддержание RAID-5 сокращаются. При этом,
отказоустойчивость сопоставима с RAID-1. Поддержка RAID-5, в
силу необходимости выполнять/рассчитывать контроль чётности,
отнимает больше ресурсов ОС чем RAID-1 и RAID-0, а в случае
выхода диска из строя, производительность резко упадёт т.к.
потребуется рассчитывать значения каждого блока этого дика по
контрольным значениям чётности цепочки чередования. Потеря
производительности будет сопровождать, как весь процесс замены
вышедшего из строя диска, так и довольно продолжительное время
после этого, пока значения всех блоков нового диска не будут
рассчитаны и восстановлены.
Кроме вопросов обеспечения
отказоустойчивости дисков с помощью аппаратных средств, в
официальном курсе опущены возможности обеспечения минимального
уровня отказоустойчивости файловой системы NTFS, которая,
между тем, рекомендуется для размещения баз данных. Нужно
отметить, что NTFS резервирует часть дискового пространства
для автоматической замены "плохих" блоков. При потере блока, в
NTFS происходит подстановка вместо него нового блока из
зарезервированной области. Так что, потери дискового
пространства за счёт обеспечения отказоустойчивости могут
превысить 50% (RAID-1). В общем, и целом, по заверению
Microsoft, повышение отказоустойчивости за счёт средств
Windows NT ведёт к снижению производительности и наоборот. В
учебнике приводится пример (который меня сильно смутил)
организации "оптимальной" по этим критериям системы управления
базами данных. Суть его в размещении файлов последовательного
доступа (журналов транзакций) на специально выделенном зеркале
RAID-1, а файлы случайного доступа (файловые группы баз
данных) предлагается разместить на RAID-0. Вам обещают, что
если Вы будете регулярно и часто делать резервные копии, с
помощью такой конфигурации будет обеспечена максимальная
производительность сервера без использования аппаратных RAID.
Честно говоря, я бы купил на один диск меньше, а на оставшиеся
деньки приобрёл RAID - контроллер. С моей точки зрения,
использование аппаратных, не зависящих сильно от ресурсов
операционной системы, RAID - контроллеров позволит достичь
одновременно и высокой производительности и
отказоустойчивости. Кроме того, современные контроллеры
дисковых массивов позволяют иметь резервный диск, который
автоматически заменяет собой вышедший из строя. Зачастую, в
"продвинутых" контроллерах можно организовать дублирование,
как дисковых массивов, так и самих RAID - контроллеров в
пределах одного устройства. Эта отрасль компьютерной индустрии
бурно развивается в последние 15 лет и предлагает свои решения
не только для Intel - платформы, но и для «больших» серверов.
По существу, одни и те же отказоустойчивые дисковые массивы
используются в решениях масштаба предприятия и крупных
хранилищ данных.
Файлгруппы
Введение понятия групп файлов является очень полезным
новшеством в седьмой версии SQL сервера. Наряду с технологией
RAID, размещение фалов данных в разных группах файлов
открывает новые перспективы повышения гибкости и
производительности сервера баз данных. Использование сервером
нескольких логических дисков, расположенных на разных дисковых
массивах (а лучше, что бы они имели и разные контроллеры)
позволит Вам разместить на них разные файлы по принципу
организации доступа к данным. Например, файлы, относящиеся к
одной группе и принадлежащие базе данных, которая обслуживает
OLAP и OLTP приложения, могут содержать таблицы
специализирующиеся только в одном направлении, что в сочетании
с разнесением их на разные дисковые массивы может существенно
поднять производительность приложений.
По умолчанию, SQL
сервер помещает все новые объекты в одну, главную группу
файлов, которая представляет собой именованный набор файлов
баз данных содержащих данные и индексы. Журналы транзакций в
файлгруппы не входят и являются обособленным понятием. В
главную файлгруппу входят все системные таблицы, поэтому очень
важно правильно рассчитать размер дискового пространства,
которое этой группе отводится. В случае исчерпания главной
файлгруппой дискового пространства работа сервера может быть
полностью парализована. Кроме главной группы, могут быть
созданы пользовательские. Создание таких групп возможно через
MS SQL SEM или с помощью оператора ALTER DATABASE через ключи
FILEGROUP и FILE. Сведения о файлгруппах и их объектах можно
получить с помощью системных хранимых процедур sp_helpfile и
sp_helpfilegroup. При оценке размера дискового пространства,
которое будет отведено группам файлов необходимо учитывать
сколько места занимает база model вместе с системными
таблицами; объём данных; количество и размер индексов, размер
значения ключа, число строк и коэффициент их заполнения.
Оценив фактические затраты дискового пространства, вам следует
также построить прогноз роста файлов. Если у вас используются
таблицы, которые размещаются в собственных файлах, то размер
такого файла можно прогнозировать по планируемому изменению
размера таблицы. Поскольку заполнение страниц таблицы может
осуществляться не полностью, а с учётом заданного
коэффициента, задача расчёта занимаемого таблицей дискового
пространства не является линейной. Выполнить такую оценку
можно зная следующие параметры: число строк, размер строки и
число строк на странице. Число записей, которое может
содержать таблица вашей базы данных можно прогнозировать на
основе статистики ввода данных за время существования сервера.
Оценить число страниц таблицы можно посчитав количество байт в
записи (сумма фиксированных длин полей средних длин полей
переменной длинны). Разделив 8060 на длину записи, а потом,
разделив общее число записей на это значение, Вы получите
искомое значение. Помните только, что длина записи не может
превышать страницу, а страницы могут заполняться не
полностью.
Ещё одним, неоспоримым, преимуществом файлгрупп
является возможность определения индивидуальных правил
резервного копирования для каждой группы файлов. Таким
образом, разместив в отдельных группах файлов редко изменяемые
данные, вы можете реже отвлекать ресурсы сервера на создание
их резервных копий.
Вопросы для повторения
ВОПРОС
Вы создаете базу данных, в которой
предполагается выполнять большой объем операций INSERT, UPDATE
и DELETE. Достаточно ли будет принять предлагаемый по
умолчанию размер журнала транзакций - 25% от общего размера
базы данных? Что необходимо учесть, если базу данных
планируется использовать главным образом для обслуживания
запросов?
ОТВЕТ
Если база данных будет
интенсивно обновляться, лучше увеличить размер журнала
транзакций. В базах данных, используемых главным образом для
обслуживания запросов, обычно не обязательно иметь слишком
большой журнал транзакций. Имеет смысл сократить размер
журнала примерно до 10% от общего размера базы
данных.
ВОПРОС
Вы создаете базу данных на
нескольких дисках. В эти данные пользователи будут постоянно
вносить изменения. Что можно предпринять для повышения
производительности и избежания конфликтов из-за ресурсов
дисков?
ОТВЕТ
Для повышения производительности
можно использовать средства чередования дисков (технология
RAID); журнал транзакций следует хранить отдельно от файлов
базы данных, чтобы избежать конфликтов доступа к дискам при
попытке сервера SQL Server изменить базу данных и одновременно
зарегистрировать эти действия в журнале. Второй путь
заключается в использовании групп файлов для повышения
производительности, особенно в том случае, когда лишь часть
файлов базы данных требует частого проведения резервного
копирования вследствие активного внесения
изменений.
ВОПРОС
Следя за использованием файлов
базы данных и журналов транзакций, вы заметили, что журнал уже
почти заполнен. Что произойдет, когда он будет полон? Что
можно предпринять, чтобы избежать нехватки свободного места в
журнале?
ОТВЕТ
Если журнал транзакций полностью
заполнен, вы не сможете изменить содержимое базы данных до тех
пор, пока журнал не будет архивирован или расширен. Во
избежание переполнения регулярно отслеживайте свободное место
в журнале и расширяйте журнал по мере необходимости; можно
ввести режим автоматического роста журнала, а также задать
выдачу предупреждения о том, что размер свободного
пространства журнала стал ниже определенного уровня.