Отчет о выполнении 1 этапа Государственного контракта № п 1116 от 26 августа 2009 г


Копирование данных и восстановление БД из резервной копии



страница15/17
Дата31.07.2016
Размер1.18 Mb.
ТипОтчет
1   ...   9   10   11   12   13   14   15   16   17

4.4.3.2 Копирование данных и восстановление БД из резервной копии

Как известно, одним из основных методов сохранения данных является их дублирование. Вопрос дублирования может быть решен несколькими способами. Это дублирование путем ведения “теневой” базы (shadowing), т.е. когда запись ведется в два Банка Данных – один основной (master) другой теневой или дополнительный (shadow). Сразу заметим, что не все банки данных могут иметь теневую копию. Банки данных, для которых транзакции не фиксируются в банке TRABSDB, не могут иметь теневую копию. К таким банкам относится банк SQLDB.

К другой особенности теневой базы (банка) относится то, что никакие прикладные программы и пользователи не могут использовать теневой банк до тех пор, пока он не станет основным.

На рисунке 15 проиллюстрирована запись в два банка – главный и дополнительный.




Рисунок 15 - Пример организации теневого банка данных.

Переход системы от основного банка к теневому происходит автоматически в случае, когда СУБД зафиксирует сбой основного банка, который не допускает его восстановление, например при крахе дисковода. При таком подходе, время восстановление работоспособности системы определяется временем определения состояния неисправности, когда система сама способна перейти на резервную (теневую) базу.

Заметим, что ведение теневых банков данных не устраняет необходимости регулярного создания копий сохранения – backup copy. Процедура создания последний освобождает ресурсы в банках LOGDB и TRANSDB, и обеспечивает дополнительную надежность сохранения данных.

Конечно, ведение теневых банков данных требует дополнительных ресурсов, в частности, наличия свободных дисковых накопителей – нет смысла вести теневую копию на том же устройстве, где и основная. Другой способ состоит в регулярном копировании данных на внешние, по отношению к рабочей базе, носители3. Это могут быть дисковые, ленточные накопители, или носители типа CD. Восстановление информации в этом случае состоит в исправлении оборудования и обратной перегрузки данных на восстановленный рабочий носитель.

Другим подходом к вопросу дублирования является накопление ее в промежуточных пунктах концентрации данных и повторной передачи ее в случае обнаружения сбоя. В описанном выше протоколе передачи данных CD 1.1 и, соответственно EF UDP, на передающей станции должны сохраняться непрерывные данные до момента подтверждения их приема. Однако, ничто не мешает потребовать сохранения уже переданных данных более длительный срок. Поскольку непрерывные данные сохраняются только определенное время – время до окончания обработки, то такой способ хранения копии данных на передающих пунктах тоже может рассматриваться как вариант сохранения копии данных. Механизм использования копии данных в этом случае может быть тот же протокол, и, соответственно, программное обеспечение его поддержки, что и для передачи непрерывных данных. Хотя, в этом случае, потребуется некоторая доработка ПО в части управления перезапросом данных. Для этого случая в протоколе предусмотрены пакеты управления (“командные” пакеты).

4.4.3.3 Временные базы данных

Кроме вопросов аварийного восстановления данных для продолжения штатной работы системы, может возникнуть необходимоcть использовать “исторические” данные, таких которые уже были обработаны раньше и переведены из активной базы на внешние носители. В этом случае, исторические данные не могут быть сохранены (восстановлены) в активной или рабочей базе, поскольку это нарушит ее целостность. Для работы с такими данными требуется создавать временную или временные банки. Перевод данных из активной базы на внешние носители описан выше, в разделе 8 “Порядок архивирования НГИ”

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

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


4.4.3.4 Система Управления Базами Данных

В качестве Системы Управления Базами Данных (СУБД) предложено использовать коммерческую СУБД Mimer SQL, разработанную компанией Mimer International Technology AB, Uppsala, Sweden [].

Mimer SQL имеет ряд уникальных технологических решений поддерживающих наиболее проблемные функции обслуживания баз данных. Например, Mimer SQL поддерживает одновременный доступ к таблицам данных исключающий появление “объятий смерти” (deadlock problem). Это резко упрощает использование и управление данными и позволяет практически неограниченно увеличивать производительность СУБД во время резкого увеличения нагрузки.

Другой важной технической инновацией является механизм хранения данных, который непрерывно оптимизирует структуру хранимых данных, чтобы поддерживать высокую производительность и не требует “ручного” вмешательства на всех этапах жизненного цикла данных. Хранение данных в банках, данных в виде, B-дерева обеспечивает практически равный по времени доступ к записям таблиц во время модификации данных и их поиска и выборки. Для ускорения поиска и выборки данных используется «оптимистичный» алгоритм доступа.

Mimer SQL обладает широкими возможностями расширения базы. Mimer SQL доступна для всех распространенных компьютерных платформах, включая многопроцессорные системы UNIX (включая Linux), все платформы Windows, OpenVMS, и идеально подходит для “открытых систем”, где коммутативность и взаимозаменяемость платформ (interoperability) очень важна4.

Эта СУБД наиболее полно удовлетворяет исходным требованиям проектируемой системы и требованиям, выработанным при выполнении данного проекта. Кроме того, эта СУБД дает наиболее выгодное соотношение в парах цена/качество и цена/стоимость обслуживания, в сравнении с другими подобными продуктами.

Предлагаемая БД с использованием СУБД Mimer, позволяет достаточно просто организовать распределенную БД, которая обеспечивает доступ к данным с любого компьютера, включенного в систему. Более того, физически БД сама может быть распределена по нескольким компьютерам, т.е. различные таблицы БД могут располагаться на различных компьютерах, а доступ к ним может быть выполнен в виде одного SQL обращения.

СУБД Mimer обеспечивает стандарт SQL:1999Collocation, который, в частности, обеспечивает возможность сортировки текстов на русском языке.

СУБД Mimer обеспечивает достаточно быстрое (< 10 минут) восстановление работоспособности БД при сбоях оборудования, где осуществляется хранение данных – диски и другое оборудование. Для этого необходимо тщательное планирование структуры БД и ее распределения по аппаратуре хранения данных – дисковым накопителям.

СУБД Mimer обеспечивает хранение двоичных данных в виде полей таблиц. Это позволяет хранить в таблицах базы “пакеты исходных данных” в том виде как они передаются по IP сетям в сетевом формате (в формате IP сети). При использовании таких данных в программе нет необходимости обращать внимание на то, где хранятся данные, а использовать обычные в таких случаях процедуры переформатирования данных их сетевого формата в “host” формат5.

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


Каталог: docs -> otchety


Поделитесь с Вашими друзьями:
1   ...   9   10   11   12   13   14   15   16   17


База данных защищена авторским правом ©uverenniy.ru 2019
обратиться к администрации

    Главная страница