огромными растровыми изображениями или графическими объектами, которые реплицируются по узлам? Однако следует иметь в виду, что это ограничение может повлиять на структуру таблиц. Например, вы можете хранить BLOB-данные на внешнем сервере и разработать свою программу для вытягивания этих данных по требованию.

Пакетные обновления

Если ожидается, что в системе будут иметь место периоды интенсивного обновления (например, к концу финансового года или квартала), то нужно yiecTb дополнительные затраты, связанные с распределенной архитектурой, и разработать план сведения их к минимуму. Например, если используются снимки и на главном узле каждый вечер запускается мощная пакетная программа, то разумно перед запуском этой программы отключить механизм снимков, а после прогона - выполнить полную их регенерацию. Это не так просто, как кажется, поскольку регенерация должна инициироваться с узлов-снимков. Как бы там ни было, мы считаем, что периодически проводить согласование данных вручную полезно для их здоровья!

Распределение данных: резюме

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

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

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

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

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

Архитектура сетевых вычислений (NCA) корпорации Oracle

Пока Oracle? развивается, а мы ждем появления OracleS, корпорация Oracle анонсировала новую архитектуру - Network Computing Architecture (NCA). В самом простом варианте архитектура сетевых вычислений включает компоненты трех типов:

средства управления клиентами и представлением данных;

средства управления приложениями;

средства управления данными.

Эти три компонента общаются друг с другом по программной шине , которая представляет собой модернизированную версию сетевых транспортных сервисов Oracle. Пользовательское содержимое каждого из этих компонентов поставляется в картриджах, которые можно программировать на самых разных языках - от Традиционных С и С++ до новейших языков Java и JavaScript Поддерживаются также Visual Basic и ActiveX от Microsoft.

Основываясь на результатах своего первоначального знакомства с NCA, мы можем сказать, что эта новая архитектура не изменила ни одного из тех выводов, которые мы сделали относительно проектирования для Oracle. Хотя уровни прозрачности, предлагаемые картриджами, и могут несколько упростить процесс исправления многих ошибок, допущенных при проектировании. Наиболее ясно новая архитектура демонстрирует только то, что Oracle готова явно поддерживать п-уровневые среды Как только задача координации данных переносится с сервера данных на сервер приложений, мы, вероятно (может быть, даже обязательно), обнаружим, что с ней переходит и ответственность за координацию двухфазной фиксации, даже если все задействованные базы данных - БД Oracle. Однако картину несколько путает то, что уже появляются картриджи, которые можно вызывать из PL/SQL на сервере данных Oracle и которые могут обшаться с внешними хранилищами данных, потенциально оставляя координацию на сервере данных.

В NCA нет ничего, что сделает традиционные средства разработки на базе SQL устаревшими, но намерение понятно - со временем новые средства разработки должны двигаться в направлении использования картриджей.

в этой /лаве:

Почему лртшлпща <)<шпых?

Что такое xpntm.umi,e данных?

Вопросы проентароватя для Х])пт1ли1ц дтишх

Извлечение а загрузка данных

Метадттые

Типы и .методы трансфор.шщин данных

> Выбо/жа датшх

путем исе.чедованнн

и с П0Л10Н1,Ы0

ОЬАР-инешрументов

Проектироеание для хранилищ данных

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

Почему хранилища данных?

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