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


Порядок приема непрерывных геофизических данных



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

4.4.2 Порядок приема непрерывных геофизических данных

Для обеспечения доступа к непрерывным данным в реальном времени, введено понятие сегмент данных. Сегментом данных называется один или несколько блоков данных. Число блоков данных в сегменте определяется при запуске системы загрузки непрерывных данных в реальном времени. Каждый раз, когда в базе накапливается сегмент данных, всем процессам, запросившим получение информации об этом событии, посылается сигнал. При использовании функций доступа к непрерывным данным из указанной выше библиотеки, выполнение программы, запросившей отсутствующие данные, блокируется автоматически до получения очередного сегмента данных. На рис. 13 показаны связи программы загрузки непрерывных данных и функций, выполняющих запрос к непрерывным данным (на рисунке отмечены как DB access functions lib.).

С учетом выполнения указанной процедуры, для хранения непрерывных данных в схеме базы данных предусмотрены следующие таблицы:

Таблица хранения пакетов данных. Кроме пакетов данных, которые хранятся в базе в виде поля BINARY, в таблице имеются поля, указывающие число отсчетов в поле данных, начальное время – время первого отсчета, идентификатор станции.




Рисунок 13 - Схема взаимодействия программы загрузки данных в БД и обрабатывающего процесса.

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

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

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

Следует отметить, что при завершении периода хранения непрерывных данных (операция чистки от устаревших данных), соответствующие записи из всех трех таблиц убираются или модифицируются так, чтобы начальное время в записи соответствовало реально имеющимся в базе данным.

Обеспечение хранения данных других (не сейсмологических) полей обеспечивается рассмотренной на примере сейсмологических полей библиотекой функций.


4.4.3 Контроль над составом и целостностью информации в базе данных

Понятия контроль и целостность информации подразумевают сохранение полноты, непротиворечивости данных, принятых или рассчитанных и хранящихся в БД центра обработки и мониторинга. Все качественные характеристики обеспечения надежности хранения информации, в том числе время восстановления после сбоя, время между проведением регламентных работ, требующих остановки приема данных и др. характеристики, должны иметь количественное выражение. Эти количественные значения могут быть контрольными точками достижения ПТХ на этапе ОКР.

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

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

Очевидно, что от используемой СУБД зависит тот набор средств, который может быть использован при работе с базой данных. В качестве примера использована СУБД MIMER, хорошо известная, как наиболее защищенная и наиболее полно отвечающая текущему стандарту SQL. В разделе 4 приведено подробное обоснование выбора этой СУБД.

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



4.4.3.1 Особенности организации баз данных и защищенность данных

Перед детальным рассмотрением проблемы сохранения полноты и целостности, сохраняемых в БД данных, сделаем важное терминологическое уточнение.

При использовании для хранения данных реляционных баз, данные хранятся в нескольких “банках данных”. В банке данных размещаются таблицы, каждая из которых содержит записи, в свою очередь состоящие из полей. С точки зрения операционной системы банк данных есть файл.

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

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

База данных представляет собой совокупность файлов операционной системы, в которых записана информация. Информация записывается в виде реляционных таблиц. Вся информация распадается на два типа – системная и пользовательская (прикладная) информация. Каждый файл БД называется Банк Данных.

Для СУБД MIMER различаются четыре системных банка данных и пользовательские банки (не меньше одного).

Системные банки:



  1. SYSDB – обеспечивает хранение всей системной информации, включая структуру пользовательских банков, пользователей системы, пароли и коды доступа и словари. Таким образом, этот банк является ключевым, при его утере дальнейшая эксплуатация БД невозможна;

  2. LOGDB – банк данных, который фиксирует все изменения, внесенные в базу данных за время после последнего сохранения содержимого базы на внешнем по отношению к файлам БД – операция backup. После сохранения базы, записанная в этом банке информация стирается, банк очищается2;

  3. TRANSDB – этот банк данных содержит все незаконченные транзакции. Информация из этого банка совместно с данными из банка LOGDB используется для восстановления БД после сбоев;

  4. SQLDB – это служебный банк, используется при работе с запросами в качестве рабочего пространства СУБД. Сохранение этого банка не требуется, обязательно только его наличие, возможно и пустого.

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

Рассмотрим принцип восстановления БД после сбоя. Ни рисунке 14 приведена схема работы БД до момента системного сбоя (System crash на рисунке). Рассмотрим, как происходит восстановление информации и какие банки и когда используются для этого.

Стандартной операцией, с которой начинается процесс восстановления информации, является использование последней копии БД (backup copy) – момент T2 – и при помощи последовательности модификаций, записанных в банке LOGDB, восстанавливается содержимое БД до момента T3. При старте системы (СУБД) банк TRANSDB используется для автоматического восстановления банков данных до момента сбоя (System crash).

В случае если сохраненная в момент T2 копия не может быть использована, используется предыдущая копия – момент T1.



Рисунок 14 - Сценарий работы БД, оканчивающийся системным сбоем.


Таким образом, восстанавливаются данные до момента T2, при этом, используется, записанное в этой копии, содержание банка LOGDB. Дальнейшее восстановление производится с использованием текущих банков TRANSDB и LOGDB.

Отсюда видно, какую важную роль играют банки TRABSDB и LOGDB. Отсюда же следует, что везде, где это возможно, эти банки следует располагать на независимых дисковых накопителях.

В случае, когда отсутствует дополнительный (третий) дисковод, прикладной (-ные) банк(и) следует располагать на накопителе, где расположен банк TRANSDB.


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


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


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

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