(Возврат на основную страницу)

Содержание номера за Сентябрь 2008 год

SQL Server
для администраторов

Сентябрь 2008

№ 9 (27)

Робин Пейдж, Фил Фактор

Предупреждения SQL Server: Soup to Nuts

Шон Калдерон

Недорогой мониторинг вашего SQL Server средствами Службы Отчетов (SQL Server Reporting Services). Часть 2

Майк Рутраф, Санджай Мишра и др.

Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008

Стюарт Озер, Санджай Мишра и др.

Сколько файлов должно быть в базе данных? Часть 1: рабочие нагрузки OLAP

Предупреждения SQL Server: Soup to Nuts

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

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

Недорогой мониторинг вашего SQL Server средствами Службы Отчетов (SQL Server Reporting Services). Часть 2*

*См. Шон Калдерон. Недорогой мониторинг вашего SQL Server средствами Службы Отчетов (SQL Ser­ver Repor­ting Ser­vices) Часть 1 // SQL Server для администраторов. 2008. № 8.

Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008

Сжатие резервной копии — это новая возможность, появившаяся в версии SQL Server 2008, которая может помочь уменьшить размер резервной копии и сократить время, затрачиваемое на резервное копирование. Данная статья представляет собой руководство, в котором описывается, как настроить соответствующие опции, чтобы повысить производительность резервного копирования. Вся информация и представленные здесь результаты тестирования были получены при использовании возможностей сжатия резервных копий, представленных в версии SQL Server 2008; однако они находят более широкое применение в условиях любого сценария резервного копирования, независимо от того, используется в этих сценариях сжатие резервных копий или нет. Полученные сведения и результаты тестов применимы также и к операциям восстановления; однако в этой статье восстановление подробно рассматриваться не будет. Чтобы познакомиться с возможностями сжатия резервных копий, обратитесь к документации SQL Server Books Online, к разделу Backup Compression.

Преимущества, которые обеспечивает сжатие резервных копий

Самое главное преимущество, которое обеспечивает сжатие резервных копий, — это экономия места. Размер сжатой резервной копии меньше, чем размер резервной копии, не подвергавшейся сжатию, что ведет не только к экономии места, но также к общему сокращению количества операций ввода­вывода во время резервного копирования и восстановления. Объем сэкономленного пространства зависит от данных, хранящихся в базе данных, а также от ряда других факторов, например, сжаты или нет таблицы и индексы в базе данных, зашифрованы или нет данные. Чтобы оценить эффективность сжатия резервных копий, можно воспользоваться следующим запросом:

SELECT
 b.database_name ‘Database Name’,
 CONVERT (BIGINT, b.backup_size / 1048576 ) ‘UnCompressed Backup Size (MB)’,
 CONVERT (BIGINT, b.compressed_backup_size / 1048576 ) ‘Compressed Backup Size (MB)’,
 CONVERT (NUMERIC (20,2), (CONVERT (FLOAT, b.backup_size) /
 CONVERT (FLOAT, b.compressed_backup_size))) ‘Compression Ratio’,

 DATEDIFF (SECOND, b.backup_start_date, b.backup_finish_date) ‘Backup Elapsed Time (sec)’
FROM
 msdb.dbo.backupset b
WHERE
 DATEDIFF (SECOND, b.backup_start_date, b.backup_finish_date) > 0
 AND b.backup_size > 0
ORDER BY
 b.backup_finish_date DESC

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

В случае выполнения операции резервного копирования без сжатия коэффициент сжатия равен 1, и значение, указанное в столбце «Размер сжатой резервной копии», совпадает со значением, указанным в столбце «Размер несжатой резервной копии». Чем больше коэффициент сжатия, тем больше экономия пространства. Для своей тестовой базы данных мы добились коэффициента сжатия 3,05 и сэкономили приблизительно 67% пространства, необходимого для резервной копии.

Рис. 1 иллюстрирует преимущества резервного копирования со сжатием в смысле пространства и времени. В случае баз данных, использующих возможность прозрачного шифрования данных (Transparent Database Encryption ­ TDE), которую обеспечивает версия SQL Server 2008, получить такие высокие показатели, возможно, не удастся (в большинстве случаев коэффициент сжатия будет близок к 1) из­за того, что шифрованные данные плохо сжимаются.

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

Тестовая рабочая нагрузка и тестовое окружение

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

Для тестирования использовалась следующая аппаратура: сервер DELL 6950 с четырьмя двухъядерными процессорами и дисковый массив EMC Clariion (CX700) с кэшем объемом 4 Гб, 80% которого выделено для операций записи. Конфигурация том/LUN показана в табл. 2.

Для каждого дискового тома, показанного в табл. 2, использовались свои физические диски. Всего имелось 32 диска для данных, восемь для журнала и 16 для файлов резервной копии.

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

Оценка максимальной производительности, достижимой в случае резервного копирования со сжатием

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

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

BACKUP DATABASE [BCTEST] TO DISK = ‘NUL’ WITH COMPRESSION

BACKUP DATABASE [BCTEST] TO DISK = ‘NUL’ WITH COMPRESSION, BUFFERCOUNT = 50

По умолчанию значение параметра BUFFERCOUNT определяется динамически сервером SQL Server и рассчитывается, исходя из количества томов базы данных и количества устройств ввода­вывода. Значения, принятые для параметра BUFFERCOUNT по умолчанию, выбираются так, чтобы их можно было использовать в самых разных средах, вот почему в высокопроизводительных (high end) системах, чтобы добиться оптимальной производительности, возможно, потребуется уточнить эти значения.

Дополнительные сведения о настройке параметра BUFFERCOUNT будут приведены в этой статье позже. Соответствующая информация содержится также в разделе BACKUP в документации SQL Server Books Online.

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

• Суммарная занятость ЦП составляет почти 100%.

• Пропускная способность дисковой подсистемы остается неизменной по мере возрастания времени ожидания.

Если суммарная занятость ЦП близка к 100% для всех ядер, это и есть ограничивающий производительность ресурс. Если суммарная занятость ЦП меньше 100%, максимум пропускной способности, которого можно достичь, — это наблюдаемая пропускная способность операций чтения. Получив это значение, можно выполнить резервное копирование на реальное устройство вывода. Если производительность ниже, чем в случае использования резервного копирования BACKUP на устройство NUL, узкое место — это пропускная способность операций записи на устройство вывода.

Рис. 2 иллюстрирует пропускную способность, которой мы добились, наращивая значение параметра BUFFERCOUNT при выполнении тестового резервного копирования BACKUP на устройство NUL.

Аналогично, график мониторинга производительности, показанный на рис. 3, иллюстрирует тот факт, что лимитирующим ресурсом является ввод­вывод на устройство чтения. Результаты мониторинга производительности вносились в журнал постоянно на всех итерациях нашего тестирования. Мы добились того, что пропускная способность составила примерно 400 Мб/сек, прежде чем ввод­вывод превратился в сдерживающий фактор для операций чтения.

Обратите внимание на то, что поблизости от места пересечения прямых линий черного цвета наблюдается падение уровня пропускной способности (счетчик Disk Read Bytes/sec — скорость чтения с диска, байт/сек), тогда как время ожидания (счетчик Avg. Disk sec/Read — среднее время чтения с диска, сек) продолжает расти. Это свидетельствует о том, что узким местом являются ресурсы ввода­вывода. В конечном счете, такова была пропускная способность, которой мы добились в своих тестах с использованием реального устройства ввода­вывода, что означает: узким местом оказалась производительность операций ввода­вывода использованных нами входных устройств.

Факторы, учитываемые при настройке резервного копирования с целью повышения производительности

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

• Распределение пространства на дисковом томе базы данных и устройстве резервного копирования.

• Объем операций ввода­вывода и количество невыполненных запросов ввода­вывода.

• Аппаратная конфигурация.

Том базы данных и разметка устройства резервного копирования

Том базы данных и разметка устройства для хранения резервной копии влияют на производительность резервного копирования безотносительно того, является ли создаваемая резервная копия сжатой. При выполнении операций резервного копирования выделяется по одному потоку чтения (reader thread) на каждый том базы данных (букву диска или точку подключения тома) и по одному потоку записи (writer thread) на каждое устройство резервного копирования. Рис. 4 иллюстрирует различия в производительности при выполнении резервного копирования со сжатием, которые наблюдаются при использовании перечисленных ниже конфигураций. В данной статье устройство резервного копирования — это синоним файла.

• Резервное копирование одного тома (M) на одно устройство резервного копирования.

• Резервное копирование одного тома (M) на четыре устройства резервного копирования.

• Резервное копирование четырех томов (P, Q, R и S) на четыре устройства резервного копирования.

На рис. 4 сокращение BC обозначает параметр BUFFERCOUNT, а сокращение MTS обозначает параметр MAXTRANSFERSIZE. Позже эти параметры рассматриваются в данной статье подробнее. Как показано на рис. 4, наличие нескольких устройств резервного копирования повышает производительность операции резервного копирования. Мы наблюдали очень незначительный рост производительности, когда использовали несколько устройств резервного копирования, размещенных на отдельных томах. Вероятно, это объясняется тем, что при проведении нашего теста ограничения накладывала пропускная способность операций чтения, как показано на рис. 3.

При получении результатов, показанных на рис. 4, для параметров BUFFERCOUNT и MAX­TRANS­FERSIZE были сохранены значения, принятые по умолчанию. Согласно нашим наблюдениям, принятое по умолчанию среднее значение для параметра MAXTRANSFERSIZE составляет 512 Кб, а значение параметра BUFFERCOUNT равно было 13 и 28 для одного и для четырех устройств соответственно. По умолчанию SQL Server определяет значение для параметра BUFFERCOUNT, основываясь на количестве томов чтения (reader volumes) и устройств вывода. Использование нескольких устройств резервного копирования приводит к неявному возрастанию значения параметра BUFFERCOUNT.

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

Количество потоков, используемых для операций сжатия, определяется динамически, а берутся они из пула потоков операционной системы SQL Server (SQLOS). В нашем случае, к увеличению пропускной способности и к большему распараллеливанию операций сжатия приводило или 1) более высокое значение параметра BUFFERCOUNT с одним устройством вывода, или 2) использование нескольких устройств вывода. Как показано на рис. 5, любой из этих факторов повышает степень параллелизма и общую занятость ЦП для всех ЦП нашего сервера. Использование в большем количестве устройств резервного копирования приводит к росту производительности операции резервного копирования. Однако при этом возрастает сложность управления. Теперь необходимо следить за возросшим количеством файлов резервной копии. В случае утраты одного из этих файлов бесполезной оказывается вся резервная копия.

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

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

Объем операций ввода-вывода и количество буферов, используемых в процессе резервного копирования

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

• Оперативная память, используемая для буферов резервного копирования, берется из пространства виртуальных адресов, которое находится вне буферного пула. Потенциально, объем памяти, используемой для этих операций, определяется как произведение MAXTRANSFERSIZE * BUFFERCOUNT. В 32­разрядных системах следует действовать осторожно, потому что задание для этих параметров слишком больших величин может привести к ошибкам нехватки памяти, поскольку объем пространства выделяемых виртуальных адресов ограничен. В 32­разрядных системах объем виртуального адресного пространства за пределами буферного пула по умолчанию равен 256 Мб.

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

• За исключением очень маленьких баз данных и резервных копий моментальных снимков сверхбольшой базы данных (VLDB), использующих технологии VDI, принятое по умолчанию значение параметра MAXTRANSFERSIZE равно 1 Мб.

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

• Объем операций ввода­вывода, выполненных для операций резервного копирования или восстановления, лежит в диапазоне от 64 Кб до MAX­TRANS­FERSIZE и зависит от распределения данных внутри файла данных. Значение параметра MAXTRANSFERSIZE определяет объем операций ввода­вывода, выполненных для чтения данных из файлов базы данных. На диске считываются только непрерывные области данных. Непрерывность базовых страниц данных влияет на размер операций ввода­вывода. Следовательно, объем операций ввода­вывода, наблюдаемый в реальных условиях, может быть меньше, чем указанное значение параметра MAXTRANSFERSIZE. Значение, предусмотренное для параметра MAXTRANSFERSIZE по умолчанию, равно 1 Мб.

Рис. 6 дополняет рис. 4 и включает параметры MAXTRANSFERSIZE и BUFFERCOUNT. На рис. 6 показана продолжительность резервного копирования и занятость ЦП для шести различных конфигураций. Как видно на рис. 6, пропускная способность, сравнимая с той, которая достигается при использовании нескольких устройств, может быть получена при использовании одного устройства LUN за счет уточнения значений параметров MAXTRANSFERSIZE и BUFFERCOUNT.

Резервное копирование со скоростью свыше 1 Гб/сек. Второй вариант применения резервного копирования со сжатием SQL2008

Реализованный в версии SQL2008 механизм резервного копирования со сжатием функционирует очень хорошо, и использование этой возможности не вызывает никаких затруднений. Вы могли бы либо использовать предложение «With Compression» вместе с командой «Backup», либо просто активизировать резервное копирование со сжатием в том варианте, как это предусмотрено по умолчанию, с помощью хранимой процедуры sp_configure, указав для опции ‘backup compression default’ значение, равное 1. Этот способ очень удобен для резервного копирования крупных баз данных в практических условиях в среде наших заказчиков.

Несколько вещей, которые можно было бы сделать, чтобы улучшить работу механизма резервного копирования со сжатием. Мы использовали следующую аппаратуру: 32­процесорный сервер HP Super­dome и дисковый массив Sto­rage­Works XP12000.

Тест, позволяющий определить оптимальное количество устройств резервного копирования

Первая база данных, резервное копирование которой мы выполнили, имела объем 1,27 Тб, 12 файлов базы данных (на 12­ти устройствах LUN). Вторая база данных имела объем 2,95 Тб и 76 файлов базы данных, размещенных на 45­ти устройствах LUN. Мы протестировали операцию резервного копирования, используя разное количество файлов резервной копии (8, 16, 26 и 32), и самую высокую производительность в нашей среде продемонстрировали 16 устройств резервного копирования. В табл. 3 представлены размер базы данных, продолжительность резервного копирования и суммарный объем всех файлов резервной копии. В этой базе данных не используются сжатые страницы или строки, а устройства резервного копирования являются локальными.

Резервное копирование в локальной сети (8 x 1G Ethernet, два файла на сетевой адаптер NIC)

• Помогают пакеты Jumbo Frame — мы использовали 9014.

• Set Buffer Count = 512.

Тома резервного копирования — это пара жестких дисков 500GB SATA 7200 RPM, сконфигурированных как зеркальный дисковый массив RAID 1 каждый, подключенных через четыре контроллера как 16 дисковых полок.

В ходе нашего тестирования резервная копия объемом 1,27 Тб в локальной сети была получена за 24,5 минуты (862 Мб/сек). Операция резервного копирования интенсивно использует операции ввода­вывода. В случае резервного копирования со сжатием на диск записывается меньшее количество страниц, нежели в случае резервного копирования без сжатия. До тех пор, пока ваша система не начнет сталкиваться с ограничениями, налагаемыми ЦП, резервное копирование со сжатием должно выполняться быстрее, чем резервное копирование без сжатия. Надеемся, эта новая возможность SQL­сервера вас порадует, и вы добьетесь еще большей производительности для операций резервного копирования.

Хотя уточнение значения параметра MAXTRANS­FERSIZE может привести к незначительному повышению пропускной способности, изменение этого значения ведет также к значительному увеличению объема операций ввода­вывода. Возрастание объема операций ввода­вывода для операций резервного копирования в сочетании с параллельной рабочей нагрузкой OLTP может привести к снижению общих временных показателей отклика операций ввода­вывода. Рекомендуется сначала уточнить значение параметра BUFFERCOUNT, а затем определить, обеспечит ли уточнение значения параметра MAXTRANSFERSIZE какое­либо дополнительное преимущество в смысле производительности. Выбирая значение для этого параметра, помните о том, что его увеличение может увеличить объем ввода­вывода при ограниченном росте общей пропускной способности. Использование нескольких устройств ввода­вывода в противоположность настройке указанных параметров, возможно, окажется более простым способом, позволяющим повысить пропускную способность. Однако этот способ может также привести к дополнительным накладным расходам на администрирование в связи с необходимостью следить за несколькими файлами резервной копии. Из­за недостатка времени мы в своем сценарии не тестировали все возможные конфигурации.

На рис. 7 демонстрируется пропускная способность чтения и записи, достигнутая при проведении указанных тестов. Пропускная способность записи меньше, чем пропускная способность чтения по причине сжатия.

Аппаратная конфигурация

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

Рекомендации

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

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

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

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

• Изменение значения параметра MAXTRANSFERSIZE следует рассматривать как вспомогательный способ настройки. На практике в наших тестах этот способ обеспечил небольшой выигрыш в сравнении с ситуацией, когда операция BACKUP использовала значение, принятое для этого параметра по умолчанию.

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

• Во время тестирования ведите мониторинг операций ввода­вывода и занятости ЦП, чтобы убедиться, что все встретившиеся узкие места не связаны с аппаратурой.

• Будьте осторожны при наращивании значения параметра BUFFERCOUNT в 32­разрядных системах, потому что задание слишком больших значений для этого параметра может привести к ошибкам нехватки памяти (out­of­memory errors) из­за того, что доступный объем выделяемого виртуального адресного пространства ограничен. В 32­разрядных системах, предусмотренный по умолчанию объем виртуального адресного пространства вне буферного пула составляет 256 Мб.

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

Заключение

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

Приложение A: Аппаратура и программное обеспечение для тестирования

Сервер

DELL PowerEdge 6950

•     Четыре двухъядерных процессора.

•     AMD Opteron 2,8 ГГц.

•     x64.

•     32 Гб ОЗУ.

Хранение

EMC Clariion CX700

•     Жесткие диски 10K SCSI.

•     Кэш объемом 4 Гб (80% запись, 20% чтение).

•     Два хост­адаптера (HBA).

Программное обеспечение

•     Windows Server 2003 Enterprise Edition Service Pack 2 x64.

•     SQL Server 2008 February CTP x64.

Табл. 1. Сравнение операций резервного копирования с использованием сжатия и без него

Табл. 2.
Конфигурация дисковых томов для тестов резервного копирования со сжатием

 Табл. 3

Сколько файлов должно быть в базе данных? Часть 1: рабочие нагрузки OLAP

Вопрос «сколько файлов должно быть в базе данных» задается часто. Ответ, разумеется, таков: «зависит от». Но от чего же это зависит?

Предпосылки

Если группа файлов SQL Server состоит из нескольких файлов, SQL Server будет «нарезать» (stripe) отводимое файлам пространство с помощью алгоритма пропорционального заполнения. Если все файлы в группе имеют одинаковый размер (что мы рекомендуем), то размещение, по сути, сводится к выделению пространства по карусельному (round­robin) прин­ципу. Размер «полосы» (stripe size) при таком выделении по кругу по умолчанию равен одному экстенту — 64 Кб. Как следствие, первый размещенный экстент предназначен для первого файла из группы, второй экстент — для второго файла, и так далее. Такой механизм «нарезки» действительно может принести пользу, потому что вы получаете возможность распределить ввод­вывод между несколькими LUN, назначая каждому логическому устройству свой файл данных. Следует стремиться к тому, чтобы все файлы в группе имели одинаковый размер. В статье Using Files and Filegroups (http://msdn.microsoft.com/en­us/library/ms187087.aspx), опубликованной на сайте TechNet, содержится дополнительная информация о принципах создания групп файлов и их размещении.

У каждого файла базы данных есть свои собственные страницы PFS, GAM и SGAM. Эти специальные «страницы администрирования» обеспечивают «слежение» за свободным пространством и за тем, как оно распределяется в файле. Каждый раз, когда осуществляется очередное выделение файлового пространства, непременно выполняется обращение к странице PFS, а в некоторых случаях также и к страницам GAM или SGAM. (Дополнительные сведения об этом можно почерпнуть в книге Кален Делани (Kalen Delaney) «Inside SQL Server 2005: The Storage Engine»).

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

(Возврат на основную страницу)