Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
курсач2.doc
Скачиваний:
14
Добавлен:
21.11.2018
Размер:
273.41 Кб
Скачать
      1. Жесткий сбой системы (аварийный отказ аппаратуры).

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

  • Отказ ЦП (CPU), памяти или шины (магистрали) данных. Эти отказы обычно приводят к аварийному отказу системы. После замены неисправного компонента и перезапуска системы SQL Server автоматически выполняет воспроизведение базы данных. Собственно база данных не затрагивается таким отказом, поэтому ее восстановление (с резервной копии) не требуется; SQL Server просто должен воспроизвести потерянные транзакции

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

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

      1. Человеческие ошибки

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

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

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

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

    1. Устройства, предназначенные для резервного копирования

      1. Устройства хранения резервных копий

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

самый лучший с технической точки зрения, но и самый дорогой вариант — это использование ленточных библиотек. Эти устройства отличаются высокой скоростью работы и надежностью. Часто с ними поставляется специальное программное обеспечение для проведения резервного копирования. Главный недостаток очевиден: не каждое предприятие может приобрести устройство стоимостью в десятки тысяч долларов. Поэтому обычно ленточные библиотеки используются только для серверов баз данных, на которых работают критически важные приложения.

Наиболее традиционный вариант — проведение резервного копирования на стриммер (устройство записи с магнитной лентой), подключенный локально к компьютеру, на котором работает SQL Server 2005.

Третий вариант — проведение резервного копирования на жесткий диск или RAID-массив, подключенный либо локально к тому компьютеру, на котором работает SQL Server, либо к другому компьютеру. Во втором случае резервное копирование может производиться по сети.

Конечно, если есть возможность, лучше всего приобрести ленточную библиотеку. Если же бюджет IT-подразделения таких расходов не предусматривает, выбор между стриммером и жестким диском может оказаться непростой задачей. В пользу стриммера говорит его дешевизна, простота и надежность, удобство замены и транспортировки (например, в специальное хранилище за пределами офиса). Главный аргумент в пользу жесткого диска — скорость работы. Даже не очень быстрые диски с IDE-интерфейсом все равно работают намного быстрее, чем стриммеры. Выигрыш по скорости достигается и за счет того, что жесткий диск — это устройство произвольного, а не последовательного доступа, как магнитные ленты (не надо ничего перематывать). Кроме того, на жесткие диски помещается больше информации. На момент написания этой книги жесткие диски IDE размером 200—300 Гбайт продавались по ценам, вполне доступным не только предприятиям, но и домашним пользователям, а такого объема вполне достаточно для проведения резервного копирования большинства баз данных.

Самое лучшее решение — это объединить преимущества жестких дисков и магнитных лент. Имеет смысл всегда производить резервное копирование только на жесткий диск (локально или по сети), и всегда хранить на жестком диске только последнюю резервную копию (или несколько последних копий). А уже с этого жесткого диска можно производить копирование данных на магнитную ленту.

При этом достигаются сразу несколько целей:

  • резервное копирование (и восстановление последней резервной копии) производится только с использованием диска, а, значит, очень быстро;

  • архивные копии (на начало месяца, квартала и т. п.) будут храниться на дешевых и приспособленных для длительного хранения стриммерах;

  • перенос данных на стриммер (который иногда требует смены картриджей) можно производить в дневное время, не мешая работе SQL Server.

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