|
Мэтью Харт
Роберт Фриман
Настройка производительности для операций резервного копирования и восстановления RMAN
(Performance tuning RMAN backup and recovery operations,
by Matthew Hart, Robert Freeman
Matthew Hart and Robert Freeman)
Источник: Oracle Tips, 02.20.2007, Рейтинг: -4.29- (из 5),
http://searchoracle.techtarget.com/tip/0,289483,sid41_gci1244428,00.html
Предлагаемый материал является выдержкой из главы 16 написанной Мэтью Хартом и Робертом Фриманом книги “Oracle Database 10g: Резервное копирование и восстановление с помощью RMAN” (copyright 2007, издательство Oracle Press, подразделение McGraw-Hill). Чтобы прочитать полный текст главы, кликните здесь
http://searchoracle.techtarget.com/tip/0,289483,sid41_gci1244428,00.html.
На самом деле, RMAN работает вполне прилично сразу же после установки, и вы, как правило, приходите к мнению, что для него требуется очень небольшая настройка. Однако имеется множество других вещей, которые должны быть вписаны в архитектурную проблему RMAN. Когда все такие вещи объединяются, вы иногда обнаруживаете, что должны где-то “здесь” или “там” для достижения наилучшей производительности, которую можно получить от используемых вами процессов резервирования, провести некоторую подстройку. Вообще-то, заканчиваемая вами настройка RMAN, которую обычно приходится делать, вынуждена иметь дело с неэффективностью в логическом или физическом дизайне базы данных, настройкой Media Management Library (MML) или настройкой RMAN и уровня MML, чтобы лучше сосуществовать с физическим устройством, на которое выполняется копирование.
Если вы использовали RMAN еще до Oracle Database 10g, вы найдете в связанных с производительностью командах некоторые изменения. По нашей оценке, эти изменения в целом делают процесс настройки более простым для понимания. В этой главе мы рассмотрим, что вы должны настроить прежде, чем начать настройку самого RMAN. После этого мы предложим некоторые опции настройки для RMAN.
Прежде чем приступить к настройке RMAN
Если на создание резервных копий RMAN требуются многие часы, это, вероятно, вовсе не ошибка RMAN. Более чем вероятно, что это некоторая проблема с вашей базой данных или с MML. Когда Вы в последний раз управляли вашим автомобилем в час пик, думали ли вы, что медленное движение – это проблема с вашим автомобилем? Конечно, нет. Проблема была в одном из слишком большого числа автомобилей, пытающихся двигаться по магистрали, испытывающей недостаток в количестве полос для движения. Это пример проблемы пропускной способности или критического параметра. Города пытаются решить свои проблемы часа пик, расширяя систему магистралей или, возможно, добавляя линии метро, автобусы или узкоколейку.
Тот же самый вид проблем существует, когда дело доходит до настройки RMAN и процессов резервного копирования и восстановления. Хотя в этом часто обвиняют RMAN, часто это вовсе не является ошибкой RMAN. Более чем вероятно, что проблема заключается в недостаточной пропускной способности системы в целом, или некоторого компонента инфраструктуры, которая неправильно сконфигурирована. На RMAN часто падают начальные обвинения, но в конце концов оказывается, что он только жертва.
Как только Вы получите правильно работающую архитектуру, большая часть настройки RMAN, в действительности, окажется уже осуществленной в процессе настройки вашей базы данных Oracle. Чем лучше работает база данных, тем лучше будут выполняться резервные копии RMAN. На тему настройки баз данных Oracle было уже написано очень много больших книг, так что мы только бегло обратимся к этим вопросам. Если вам требуется большее количество подробной информации по вопросам настройки производительности базы данных Oracle, мы предлагаем вам другую книгу издательства Oracle Press: Oracle Wait Interface: A Practical Guide to Performance Tuning & Diagnostics by Richmond Shee, Kirtikumar Deshpande and K. Gopalakrishnan (2004) [Интерфейс событий ожидания Oracle: практическое руководство по настройке производительности и диагностике, авторы: Ричмонд Ши, Киртикумар Дешпанде и К. Гопалакришнан (2004 г.)].
ПРИМЕЧАНИЕ: В этой главе и в других местах этой книги мы делаем некоторые рекомендации по настройке. Удостоверьтесь, что вы проверили наши рекомендации на своей системе, прежде чем принять решение "запустить и забыть" (в смысле, сделать изменение, не проверяя, что изменение дало позитивный результат). Хотя определенные конфигурации могут работать для нас в наших средах, вы можете обнаружить, что для вас они не работают столь же хорошо.
Производительность RMAN: что может быть достигнуто?
Так какого же уровня производительности RMAN можно достичь с помощью доступных в настоящее время технологий? Корпорация Oracle в своем официальном документе "Диспетчер восстановления Oracle: испытание производительности в центре аттестации клиентов Sun" (октябрь 2001 г.), который можно найти в OTN, показала, что при записи на магнитную ленту возможна скорость резервного копирования или восстановления 1 терабайт (TB) в час. Поскольку технологии резервного копирования на магнитную ленту продолжают улучшаться, вполне вероятно, что уже возможны скорости, превышающие это значение.
Располагайте правильными аппаратными средствами
Если вы хотите получить высокую производительность резервного копирования, то первая вещь, которую необходимо рассмотреть – это имеющиеся в вашем распоряжении аппаратные средства резервирования. К их числу относятся устройства типа накопителей на магнитной ленте, связанная с ними инфраструктура, например, кабели, автоматизированные (робототехнические) ленточные интерфейсы и любое программное обеспечение уровня MML, которое вы можете захотеть использовать.
Аппаратные средства носителей резервных копий предоставят вам заданную скорость, на которой устройство будет читать и писать. Конечно, чем быстрее пишет устройство, тем быстрее пойдет ваш процесс резервного копирования. Кроме того, чем для большего числа устройств проводится запись, тем лучше будут результаты тестирования резервного копирования. Об этом было ясно сказано в официальном документе Oracle, посвященном производительности RMAN, о котором упоминалось в предыдущем разделе. Удвоение числа дисков, на которые RMAN может вести запись, приводит к почти линейному росту производительности как операций резервного копирования, так и операций восстановления. Возможность распараллеливания процесса резервного копирования по многим каналам (или устройствам для записи резервных копий) является критической для быстрого копирования большой базы данных Oracle.
RMAN способен извлечь выгоду из параллельных ресурсов центральных процессоров, но отдача от добавления центральных процессоров уменьшается намного быстрее, чем от добавления физических резервных устройств. Таким образом, “в сухом остатке” получаем, что в большинстве случаев наличие большого числа резервных устройств окажет намного большее положительное воздействие на процессы создания резервной копии и восстановления, чем добавление центральных процессоров.
Вы найдете, что большинство резервных устройств являются асинхронными, а не синхронными. Асинхронное устройство позволяет процессам сервера резервного копирования выполнять команды I/O, не требуя, чтобы процессы сервера резервного копирования ожидали завершения I/O. Например, асинхронная операция позволяет процессу сервера выполнить команду записи на ленту и в то время пока эта команда выполняется, перейти к заполнению буфера памяти в процессе подготовки к выполнению следующей операции записи. Синхронное устройство, напротив, должно было бы ждать завершения операции резервирования, прежде чем оно могло бы выполнить любую другую работу. Таким образом, в нашем примере синхронный процесс должен будет ждать завершения ленточного I/O, прежде чем оно сможет начать заполнять буфера памяти для следующей операции. Таким образом, асинхронное устройство более эффективно, чем синхронное.
Поскольку асинхронные операции предпочтительнее, у вас может появиться желание узнать о некоторых их параметрах. Параметр BACKUP_TAPE_IO_SLAVES (значение по умолчанию которого равно FALSE) может сделать весь ленточный I/O асинхронным по природе. Мы предлагаем вам установить этот параметр на TRUE, чтобы разрешить асинхронный I/O на ваших ленточных устройствах (если эта установка поддерживается). После того как этот параметр установлен, вы можете определить размер буферов памяти, которые используются при использовании параметра parms команды выделения канала (allocate channel) или команды конфигурирования канала (configure channel).
Размер буфера ленты устанавливается при конфигурировании канала. Значение размера этого буфера по умолчанию зависит от операционной системы, но, как правило, он равен 64 Кбайт. Используя команду выделения канала, вы можете сконфигурировать этот размер таким образом, чтобы он был выше или ниже этого значения по умолчанию. Для достижения наилучшей производительности мы предлагаем вам сконфигурировать это значение равным 256 Кбайт или выше, как показано здесь:
allocate channel c1 device type
sbt parms="blksize=262144, ENV=(NB_ORA_CLASS=RMAN_db01)"
Если вы выполняете копирование на диск, то необходимо определить, действительно ли ваша OS поддерживает асинхронный I/O (в наши дни большая часть современных OS делает именно так). Если OS поддерживает асинхронный I/O, то Oracle будет автоматически использовать эту особенность. Если же она не делает этого, Oracle предлагает параметр DBWR_IO_SLAVES, который, если его установить на значение, отличное от нуля, заставляет Oracle моделировать асинхронный I/O на диски, запуская для этого много процессов DBWR.
Когда сконфигурирован один из параметров – DBWR_IO_SLAVES или BACKUP_TAPE_IO_SLAVES – вы можете также пожелать создать большой пул. Это должно помочь устранить проблемы, связанные с конкуренцией за использование разделенного пула и ошибками при распределении памяти, которые могут сопровождать использование разделяемого пула, когда активирован параметр BACKUP_TAPE_IO_SLAVES. Если вы будете использовать в 10g средство автоматического управления разделяемой памятью (Automatic Shared Memory Management – ASMM), то Oracle будет сам управлять для вас распределением памяти разделяемого пула. Если вы желаете вручную установить размер большого пула, полный размер дисковых буферов ограничен 16 Мбайт на канал. Формула для установления параметра LARGE_POOL_SIZE для резервной копии имеет следующий вид:
LARGE_POOL_SIZE = (число выделенных каналов) *
(16MB + (размер ленточного буфера))
ПРИМЕЧАНИЕ: Если параметры DBWR_IO_SLAVES или BACKUP_TAPE_IO_SLAVES не сконфигурированы, то RMAN не будет использовать большой пул. Вообще, в том случае, если ваша OS не поддерживает “напрямую” асинхронный I/O, вы не должны конфигурировать эти параметры настройки, чтобы получить от RMAN хорошую производительность.
Настройте базу данных
Плохо настроенная база данных может оказать существенное отрицательное воздействие на время резервного копирования. Определенные проблемы с настройкой базы данных могут также иметь существенное воздействие на время восстановления. В этом разделе мы кратко рассмотрим то, каковы некоторые из этих проблем настройки, включая настройку I/O, настройку памяти и настройку SQL.
Кликните здесь
http://media.techtarget.com/searchOracle/downloads/ch16.pdf, чтобы прочитать остальную часть этой главы.
Об авторах
Мэтью Харт является соавтором трех книг, вышедших в издательстве Oracle Press. Он работал с технологиями высокой доступности в Oracle, начиная с версии 7.3, и работал с RMAN с самого момента его появления. Он провел значительное время, совершенствуя стратегии резервного копирования и восстановления для заказчиков Oracle. В настоящее время Мэтью работает и живет в Канзас-Сити, шт. Миссури.
АБД Oracle Роберт Фриман также создал пользующиеся высоким спросом книги: “Новые возможности Oracle Database 10g”, “Резервное копирование и восстановление с помощью RMAN в Oracle9i” и “Новые возможности Oracle9i”, а также вышедшую в издательстве Oracle Press книгу “Oracle: машинонезависимый АБД”. В свое свободное время Роберт летает на самолетах и работает в местном ATA Каратэ-центре.
|
