Базы данных Oracle - статьи
Разделение информации в GRID
Информация хранится в GRID в базах данных и файлах. Множество узлов GRID должно иметь доступ к этой информации, поэтому необходимо организовать разделение информации между узлами. Существует три способа разделения информации:
централизация информации в единой БД;
работы с множеством самостоятельных независимых БД и файлов (федерирование);
временный вынос необходимой информации на узлы, где она будет обрабатываться (propelling);
Централизация информации – самый простой способ. Вся информация из различных источников собирается в одной БД Oracle и далее кластер Oracle прекрасно решает множество задач, работая с этой БД.
Работа с множеством самостоятельных БД тоже хорошо реализована в Oracle. Механизм работы с распределенными БД реализован в Oracle давно, причем узлы этой распределенной БД могут быть реализованы не только на основе СУБД Oracle, но и на основе других СУБД, с использованием шлюзов Oracle Gateway к этим СУБД. При этом каждая БД существует самостоятельно в своей части GRID, живет, обновляется, администрируется своими приложениями, но если необходимо в одном приложении работать с информацией из различных БД, то пользователь (или приложение) просто выполняет распределенный запрос к этой распределенной БД. Если какие-либо объекты данных (таблицы) переносятся из одной БД в другую или из централизованной БД разносятся по различным БД, то доступ к ним не требует переписывания запроса (приложения). Администратору БД достаточно лишь создать синонимы для перенесенных данных и приложение продолжит работу.
Согласованность работы с распределенной БД обеспечивается за счет реализации алгоритмов двухфазной фиксации изменений (2 phase commit), который Oracle реализует автоматически (при создании пользовательских приложений не надо заботиться о том, в единой или разных БД находятся объекты). Тем самым обеспечивается “прозрачность” работы с распределенной БД [7].
Oracle умеет распознавать распределенные запросы и оптимизировать их выполнение с учетом характеристик используемых узлов и БД. Если надо организовать работу с структурированным объектом (таблицей), части которого хранятся в различных БД, то с помощью оператора объединения UNION можно создать виртуальное представление всего объекта и работать с ним, а уж Oracle преобразует операции с объектом в операции с его частями в разных БД.
Работа с распределенной БД требует, чтобы в момент выполнения операций существовала хорошая связь со всеми используемыми БД. Если связь прервется, то запрос выполнен не будет. Кроме того, если БД сильно удалены друг от друга, необходимо иметь очень хорошие быстрые сети передачи данных для доступа к этим БД.
Поэтому часто используется механизм создания в каждой группе узлов GRID своей локальной БД, содержащей копии объектов основной БД. Для создания таких локальных БД надо обеспечить две вещи:
быстрый перенос части данных из одной БД в другую;
постоянную синхронизацию данных.
Быстрый перенос из одной БД в другую больших объемов данных можно осуществить в Oracle с помощью механизма транспортируемых табличных пространств
(Transportable tablespace). Вместо того, чтобы экспортировать данные из БД в файл, перемещать файл к другой БД, импортировать данные из файла в новую БД (а все это занимает очень много времени), мы можем просто скопировать (например, с помощью средств FTP) файлы операционной системы, которые образуют табличное пространство, содержащее необходимые нам большие объекты данных. Далее достаточно перенести с помощью экспорта-импорта из одной БД в другую лишь маленький объем метаинформации о перемещенном табличном пространстве. Механизм транспортируемых табличных пространств работает намного быстрее, чем экспорт-импорт.
Перемещаемые файлы можно, например, записать на СD диск и подключать к различным БД в виде набора открытых только на чтение таблиц (например, справочников). В Oracle 10G реализована возможность транспортировки табличных пространств между различными операционными системами. Например, мы можем со скоростью работы по FTP протоколу переместить большие таблицы из БД на Windows в БД на Linux или Unix. Это делается с помощью утилиты RMAN.
Для переноса небольших таблиц из БД в БД в Oracle 10G можно использовать новую утилиту Data Pump. Ее функциональность аналогична тому, что умели делать старые утилиты экспорта-импорта, но работает она намного быстрее. Так импорт данных выполняется в Data Pump в 20-30 раз быстрее, чем раньше, используется механизм распараллеливания вычислений, возможен рестарт работы утилиты с той точки, где она прервала свою работу. Data Pump позволяет выполнить прямой перенос данных из одной БД в другую без создания промежуточных файлов на диске.
Для синхронизации данных, хранящихся в различных БД, может использоваться как старый механизм репликации, так и новый, более универсальный механизм Oracle Streams
[5]. Streams позволяет разделять между узлами как сообщения (messaging), так и операции с БД на основе единого универсального механизма. Все заказанные изменения в исходной БД захватываются из журналов БД (это не нагружает эксплуатационную БД) и складируются в едином универсальном формате в области хранения (Stage). Все узлы, которым необходимо получить и применить эту информацию об изменениях, подписываются на получение информации об изменениях из области хранения. При появлении новой информации об изменениях в области хранения, подписавшиеся узлы получат нужную им информацию и смогут ее применить.
Захват и применение информации об изменениях могут быть легко сконфигурированы и далее выполняются автоматически. При захвате, перемещении и применении информации об изменениях, она может быть преобразована с помощью пользовательских процедур.
Единый универсальный механизм Oracle Streams позволяет реализовать репликацию нужных таблиц, передачу сообщений (Advanced Queuing), передачу извещений о событиях (Notification), оперативную подпитку хранилищ данных, упрощая конфигурирование и администрирование этих механизмов. В случае захвата информации обо всех изменениях в исходной БД и применения их к копии этой БД, мы можем реализовать механизм поддержания резервной БД (StandBy Database).
Механизм StandBy Database позволяет поддерживать в нескольких частях GRID копии одной и той же БД. Причем в случае логического StandBy эти копии могут использоваться для выполнения операций чтения к этим БД. Например, на них можно печатать отчеты, выполнять приложения, связанные с анализом данных, и т д.
Oracle Streams позволяет исключить дублирование информации, передаваемой по сети в разные узлы, обеспечить гибкую маршрутизацию потоков данных, гарантированную доставку изменений. С помощью Oracle Streams легко обеспечить двустороннюю репликацию данных и разрешение возникающих конфликтов репликации (имеются встроенные алгоритмы разрешения конфликтов).
Часто необходимо перенести данные из целевой БД в удаленную БД лишь на время, для их обработки там. Это позволяет сделать механизм Self Propelling, реализованный в Oracle 10G. Практически это объединение механизма транспортируемых табличных пространств и механизма Oracle Streams. С помощью всего одной команды можно организовать перенос информации в другую БД и запуск механизма ее синхронизации с копией в источнике. Таким образом мы можем вынести данные и их обработку на менее загруженные узлы GRID.
Механизм Self Propelling позволяет оперативно приблизить данные к месту их обработки, снизить нагрузку на сеть, уменьшить число проблем и ошибок, связанное с работой в среде распределенной БД.
В GRID часто информация может храниться не в БД, а в файлах операционной системы. Механизм Oracle External Table позволяет использовать средства работы с БД для работы с информацией файлов. Файлы определяются в словаре БД как внешние (external) таблицы и далее с ними можно работать на чтение (и на запись в Oracle 10G) как с обычными таблицами БД. Более того, можно выполнять операции, одновременно работающие с реляционными таблицами БД и информацией файлов операционной системы.
СУБД Oracle поддерживает тип данных Bfiles. Если Вы создадите в БД таблицу с колонкой типа Bfile, то в этой колонке будут храниться лишь ссылки на файлы операционной системы, а сами данные, помещаемые в эту колонку, будут храниться в файлах ОС. Это еще один механизм для работы с файлами операционной системы. Понятно, что и файлы ОС и их описания в словаре БД можно копировать и перемещать между узлами GRID, обеспечивая разделение информации.
