Использование зеркалирования дисков для облегчения резервного копирования

Простым, но эффективным способом сокращения времени резервного копирования является выполнение копирования на отдельный зеркальный диск. ПО Online:DiskSuite предлагает зеркалирование с очень небольшими накладными системными расходами. Если зеркальная копия сделана непосредственно после контрольной точки, или после того как база данных выключена, она действительно становится онлайновой дисковой резервной копией, которая сама может быть скопирована в любое удобное время. Можно даже выполнить рестарт базы данных, чтобы продолжить нормальную обработку, хотя с меньшей избыточностью. Если доступно достаточное количество дисковых накопителей, то может быть использован и второй набор зеркальных дисков, что позволяет сохранить полное зеркалирование даже, когда один набор зеркальных дисков отключается (во время нормальных операций диски будут зеркалироваться по трем направлениям). В этом случае резервное копирование в режиме online может продолжаться после копирования на ленту, что обеспечивает в случае необходимости очень быстрое восстановление. Этот дополнительный набор зеркальных дисков мог бы быть заново подключен перед следующей контрольной точкой, обеспечив достаточно времени (примерно 30 минут), которое позволит этому набору зеркальных дисков синхронизоваться с зеркальными дисками, работавшими в режиме online.

Частота резервного копирования

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

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

Утилиты резервного копирования

При использовании "чистых" дисковых разделов, выбор прост: в действительности единственными командами UNIX, работающими с "чистыми" разделами, являются dd и compress. При хранении таблиц СУБД в файловых системах USF можно выбрать, например, команды tar, cpio и usfdump. Большинство пользователей предпочитают usfdump(1) (dump(1) для Solaris 1.X), или ее эквивалент в Online Backup (hsmdump для Solaris 2.X). Большинство СУБД имеют утилиты для выделения из базы данных "чистых" данных и их копирования на внешний носитель, но эти операции обычно выполняются намного медленнее, чем простое копирование "чистых" разделов диска.

Отслеживание и проверка резервных копий

Резервные копии очень важны. Выполнение процедур резервного копирования должно соответствующим образом отслеживаться, чтобы гарантировать, что они завершились успешно. Также важно документировать и тестировать процедуры восстановления. Момент аварии не слишком удачное время для обнаружения того, что в стратегии резервного копирования пропущены некоторые ключевые элементы.

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

При выборе конфигурации системы приходится рассматривать комбинацию достаточно сложных объектов: аппаратные средства + операционная система + СУБД + приложение. Из-за сложности анализа комбинации этих объектов обычно невозможно определить, будет ли способна данная система поддерживать требуемую нагрузку. Тем не менее, часто возможно сделать некоторые предположения и затем грубо проанализировать основные транзакции чтобы определить, при каких конфигурациях система не будет способной обработать эти основные транзакции. Хотя такой подход полезен только для относительно простых приложений, особенно для приложений с одной или двумя основными транзакциями, он дает неплохое начальное приближение и для больших и более сложных приложений. Вопрос о том, как соотнести конкретные запросы с требованиями пропускной способности дисковой подсистемы уже обсуждался в разделе 2.2.6.1.

В процессе оценки рассматриваются известные ограничения отдельных частей предлагаемой системы и затем производится их сравнение с минимальными потребностями в соответствии с поставленной задачей. Например, известно, что диск емкостью 2.1 Гбайт может выполнить 62 операции произвольного доступа в секунду. На каждую операцию затрачивается примерно 2 мс процессорного времени. Если приложение требует выполнения примерно 700 операций произвольного чтения диска в секунду, то очевидно, что система с одним диском не справится с такой задачей за требуемое время: необходимо по крайней мере 12 накопителей. Более того, практически сразу видно, что однопроцессорная система не может справиться с этой задачей, поскольку для обработки 700 дисковых операций требуется 1400 миллисекунд процессорного времени в секунду (т.е. более 1 секунды). Хотя совершенно ясно, что однопроцессорная система с одним диском не будет способна выполнять это приложение с требуемой скоростью, совсем неочевидно, что двухпроцессорная система с 12 дисками обеспечит требуемую производительность. Это происходит потому, что приложение очень сильно абстрагировано (в этом случае, любой вид работы приложения упрощен!).