МЕНЮ


Фестивали и конкурсы
Семинары
Издания
О МОДНТ
Приглашения
Поздравляем

НАУЧНЫЕ РАБОТЫ


  • Инновационный менеджмент
  • Инвестиции
  • ИГП
  • Земельное право
  • Журналистика
  • Жилищное право
  • Радиоэлектроника
  • Психология
  • Программирование и комп-ры
  • Предпринимательство
  • Право
  • Политология
  • Полиграфия
  • Педагогика
  • Оккультизм и уфология
  • Начертательная геометрия
  • Бухучет управленчучет
  • Биология
  • Бизнес-план
  • Безопасность жизнедеятельности
  • Банковское дело
  • АХД экпред финансы предприятий
  • Аудит
  • Ветеринария
  • Валютные отношения
  • Бухгалтерский учет и аудит
  • Ботаника и сельское хозяйство
  • Биржевое дело
  • Банковское дело
  • Астрономия
  • Архитектура
  • Арбитражный процесс
  • Безопасность жизнедеятельности
  • Административное право
  • Авиация и космонавтика
  • Кулинария
  • Наука и техника
  • Криминология
  • Криминалистика
  • Косметология
  • Коммуникации и связь
  • Кибернетика
  • Исторические личности
  • Информатика
  • Инвестиции
  • по Зоология
  • Журналистика
  • Карта сайта
  • Создание клиентских частей SQL БД под ОС Windows'95 и WindowsNT

    7.3 Oracle постепенно переходит к реализации DLM собственными средствами в

    составе ядра сервера - окончательно этот процесс завершен в Oracle 8. Как

    бы то ни было, уже в релизе Oracle 7.3.3 существует параллельный сервер для

    кластеров, функционирующих под управлением таких "легковесных" ОС, как SCO

    UnixWare и Windows NT (последняя - как для платформы Intel, так и для DEC

    Alpha).

    При параллелизме, в задачах типа DSS, при выполнении отдельных операций

    оптимизатор выбирает один из возможных алгоритмов выполнения запросов (при

    этом важно, что в Oracle он с самого начала при оценке стоимости того или

    иного решения учитывает заданную для данного запроса степень параллелизма),

    затем каждый шаг алгоритма разбивается на несколько параллельных потоков.

    Координатор выполнения запроса запускает нужное число процессов (при этом

    используются все наличные процессоры - включая различные узлы кластера или

    MPP-системы) и обеспечивает как внутриоперационный (параллельные потоки

    внутри шага алгоритма), так и межоперационный параллелизм. В список

    операций, подлежащих распараллеливанию, помимо просмотра таблиц включены

    также все алгоритмы соединения (и "антисоединения") таблиц, сортировки,

    операции агрегирования, вложенные подзапросы, объединения и некоторые

    другие. Кроме того, возможно параллельное выполнение таких операций, как

    создание таблицы по результатам запроса, загрузка данных, сброс и

    восстановление БД, выполнение операций тиражирования данных. В Oracle8 к

    этому списку добавятся операции INSERT, UPDATE и DELETE.

    Одним из наиболее фундаментальных вопросов, которые приходится решать при

    реализации параллельного выполнения запросов, является выбор метода

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

    операций, как полный просмотр таблиц. Самым простым (и исторически

    реализованным первым - фирмой Tandem) методом является "привязка"

    параллелизма к статическому разбиению нужных таблиц на разделы, проводимому

    по правилу, заданному администратором системы. Этот метод и до сих пор

    является краеугольным камнем параллелизма в ряде СУБД.

    В идее разбиения таблиц на разделы безусловно есть серьезные

    положительные стороны, особенно когда это разбиение осуществляется на

    основе диапазонов значений содержательных параметров либо функций от них.

    Тогда, во-первых, может быть облегчена работа администратора БД в случае,

    когда таблица содержит большой объем данных (например, если разбить таблицу

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

    раздела таблицы), во-вторых, становится возможным исключение разделов при

    выполнении запросов, содержащих условие на параметр разбиения. Однако когда

    параллелизм в выполнении запросов ставится в зависимость от статичного

    разбиения таблиц, это приводит к ряду проблем. Дело в том, что для

    достижения оптимального параллелизма в этом случае требуется (по очевидным

    причинам), чтобы данные были распределены по разделам равномерно. В

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

    раздел по циклическому алгоритму (round-robin). Но в этом случае, как

    нетрудно заметить, полностью теряются указанные выше два преимущества. И

    наоборот, если выполнять разбиение по содержательному критерию, то весьма

    часто получается, что данные распределяются по разделам неравномерно, что

    неизбежно приводит к тому, что, закончив свою работу, параллельные процессы

    ждут "отстающего товарища", которому не повезло с разделом. Если речь идет

    об устоявшихся (т. е. фактически не обновляемых) данных и о конкретном

    запросе с небольшими вариациями, то практически всегда можно найти некий

    компромиссный вариант разбиения, но в реальных системах типа DSS запросы

    как правило носят нерегламентированный характер (ad-hoc), а данные - опять-

    таки как правило - периодически обновляются. Все это как минимум приводит к

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

    становится попросту обязательным, если требуется сменить степень

    параллелизма), но даже это не гарантирует оптимального параллельного

    выполнения запросов.

    Такие соображения побудили разработчиков Oracle7 отказаться от принципа

    "статичного" параллелизма и реализовать алгоритм динамического разбиения

    таблиц при параллельном выполнении запросов. Упрощенно его суть в том, что

    таблица логически "разбивается" непосредственно при выполнении запроса в

    соответствии с заданной степенью параллелизма. Это не означает, впрочем,

    что она попросту делится на равные части произвольным образом - все гораздо

    изощреннее. Дело в том, что скорость обработки одного и того же объема

    данных в разных разделах может быть различна в зависимости как от характера

    запроса, так и от того, на каких физических устройствах располагается

    динамический раздел, да и от других порой трудно предсказуемых причин.

    Поэтому таблица делится реально на число разделов гораздо большее, чем

    степень параллелизма (и разделы эти бывают различного размера), а их

    назначение параллельным процессам регулируется динамически в зависимости от

    того, с какой скоростью они справляются с уже порученной работой.

    Надо сказать, что алгоритм динамического разбиения таблиц весьма непрост,

    и было бы нечестно утверждать, что в нем с самого начала все было сделано

    самым оптимальным образом. Однако одно из самых важных преимуществ этого

    алгоритма в его гибкости, поэтому в него постоянно вносились

    усовершенствования на основании накопленного опыта эксплуатации в реальных

    инсталляциях, в результате чего от релиза к релизу Oracle7 добивался все

    более оптимальных характеристик параллелизма в выполнении запросов. К

    примеру, в релизе 7.3 основные усовершенствования были связаны с поддержкой

    MPP-архитектур. Дело в том, что в них диски не равноценны по скорости

    доступа для каждого из узлов системы (к "своим" дискам доступ

    осуществляется быстрее, чем к "чужим"), поэтому и динамические разделы

    стали выделяться параллельным процессам преимущественно на локальных для

    соответствующих узлов дисках (преимущественно - опять-таки потому, что,

    завершив свою "локальную" работу, процесс не прекращает деятельность, а

    начинает помогать "отстающим").

    Как бы то ни было, сейчас можно с уверенностью констатировать, что метод

    динамического разбиения таблиц оправдал себя, позволив при минимальной

    дополнительной нагрузке на администратора БД добиться, тем не менее,

    практически оптимального распраллеливания выполнения запросов. Высокая

    масштабируемость Oracle в параллельном выполнении запросов на системах с

    различной архитектурой иллюстрируется также и тем фактом, что Oracle 7.3

    сумел показать рекордные параметры в TPC-D тесте (в варианте с объемом

    данных 300 Гбайт) как среди MPP-систем (на IBM SP/2), так и среди SMP-

    систем (на Sun Enterprise Server 10000).

    Oracle 7, к сожалению, не включает в себя явной операции построения

    статических разделов таблицы (эта возможность вводится в Oracle 8), но в

    неявном виде это тем не менее можно сделать с помощью имитации разделов

    отдельными таблицами, объединенными в единое представление с помощью

    операции UNION ALL. При выполнении запросов к такому представлению

    оптимизатор Oracle7 трактует его именно как таблицу, разбитую на разделы, в

    частности выполняет исключение разделов, если это возможно.

    Oracle традиционно славится как поставщик СУБД для крупных инсталляций,

    однако в связи с этим бытует (и активно поддерживается конкурентами) также

    и мнение о том, что для небольших систем Oracle слишком тяжеловесен,

    сложен, дорог и пр. Oracle прикладывает немало усилий, чтобы по всем

    параметрам (включая цены) утвердиться в качестве основного поставщика во

    всех сегментах рынка СУБД, начиная с небольших рабочих групп. С 1994 года

    помимо уже привычного "сервера масштаба предприятия" поставляются другие

    его варианты: "сервер для рабочих групп" (Workgroup server) и "персональный

    Oracle" (Personal Oracle) в двух редакциях - полной и "облегченной"

    (Personal Oracle Lite). В этих продуктах особый упор сделан на их

    относительную дешевизну, простоту установки и сопровождения. При этом все

    варианты сервера Oracle функционально идентичны, за исключением некоторых

    опций (только в нынешней версии Personal Oracle Lite отсутствует часть

    базовой функциональности: он не поддерживает многопользовательские схемы

    данных и процедурные расширения SQL).

    Oracle 7 в одинаковой степени может быть оптимизирован и для OLTP-

    приложений, и для приложений DSS, причем их вполне можно исполнять

    одновременно, не беспокоясь о дополнительных блокировках, модах изоляции и

    прочих темах, способных вызвать головную боль у знакомых с ними на практике

    специалистов при одном только их упоминании. Это не означает впрочем, что

    оба режима будут одинаково оптимальны при одном и том же выборе параметров

    системы. Безусловно, по крайней мере часть параметров требуют разного

    подхода при их оптимизации для OLTP- и DSS-систем. По этой причине

    поддержка "смешанного" режима обязательно сопряжена с некоторым

    компромиссом, и не следует трактовать приведенное утверждение как

    рекомендацию совмещать оперативную систему с хранилищем данных. Более

    разумно на практике говорить о том, что, скажем, если основной режим

    системы - OLTP, то совсем не обязательно дожидаться ночной паузы в работе,

    чтобы выполнить на ней сложный - но срочный - отчет, и Oracle гарантирует,

    во-первых, корректность результатов отчета, во-вторых, что его выполнение

    не повлияет сколько-нибудь заметно на работу пользователей.

    Oracle поддерживает любой тип данных. В сущности, речь идет о расширении

    стандартного набора типов данных, характерного для РСУБД, а в перспективе о

    переходе к объектно-реляционной модели СУБД. В свою очередь, эта задача

    может быть разделена на две:

    - поддержка поставщиками СУБД дополнительных "базовых" типов данных;

    - возможность расширять набор типов данных за счет модулей третьих

    производителей или самими пользователями.

    Oracle развивает свой сервер в обоих направлениях. В версии 7.3 уже

    поддерживается несколько новых типов данных: неструктурированные тексты,

    пространственные данные, видеоданные. Собственно говоря, хранить такие

    данные в БД и осуществлять к ним доступ можно было и раньше: новизна в том,

    что если раньше этот доступ осуществлялся через самостоятельно работающие

    серверные процессы, и для работы с ними требовалось использование

    специального интерфейса на уровне приложений, то теперь данная

    функциональность интегрирована в "базовый" сервер.

    Опция для работы с пространственными данными (Spatial Data Option)

    фактически вводит тип данных "пространственная точка" и операции над ним в

    СУБД, позволяя хранить соответствующие данные в таблицах оптиальным образом

    и на порядок (а порой и на два) ускорять выполнение запросов.

    Что касается видеоданных, то соответствующая им опция - Video Option -

    единственная, "живущая самостоятельной жизнью" по отношению к серверу РСУБД

    (но не к БД). Более того, рекомендуется конфигурация, в которой Video

    Server запускается на отдельном компьютере от сервера БД. Связано это с

    тем, что воспроизведение видеофрагментов в реальном времени (особенно по

    нескольким каналам) - что как раз и обеспечивает Video Server - трудно

    совместимо на современных массово производимых компьютерах с

    функционированием сервера СУБД из-за чисто аппаратных ограничений. Тем не

    менее приложение, работающее с Video Server, может осуществлять поиск

    видеофрагментов по описательным атрибутам и воспроизведение этих фрагментов

    - как единую интегрированную операцию.

    Относительно Web Option, пожалуй, не совсем правильно говорить о

    функциональных расширениях сервера, поскольку, в сущности, главная задача

    опции - обеспечение интерфейса с Web Application Server и соответственно

    через него с пользователями Intranet/Internet.

    Oracle OLAP Option едва ли можно было рассматривать как интегрированную

    компоненту сервера Oracle (продукты OLAP работают с собственным -

    многомерным - представлением данных, хранимым отдельно) до недавнего

    времени, когда с помощью Access Manager появилась возможность устанавливать

    динамическую связь многомерного куба OLAP с реляционными данными, стирая

    тем самым грань между MOLAP и ROLAP (для аналитика, работающего с

    приложениями OLAP, стало совершенно незаметно, работает ли он с

    предварительно сформированным многомерным кубом или с динамическим

    многомерным представлением реляционных данных).

    Развитие подхода в Oracle 8. В отличие от Oracle 7 восьмая версия сервера

    Oracle не просто предоставляет расширенный набор встроенных типов данных,

    но и позволяет конструировать новые типы данных со спецификацией методов

    доступа к ним. Это означает фактически, что разработчики получают в руки не

    просто систему для хранения и обработки, скажем, видеоданных (что, понятно,

    нужно далеко не в каждом приложении), а и инструмент, позволяющий строить

    структурированные типы данных, непосредственно отображающие сущности

    предметной области. Влияние этого фактора на возможности разработчиков

    можно сравнить с эффектом от перехода на реляционные СУБД в начале 80-х

    годов.

    Oracle8 фактически опирается на новый стандарт SQL, позволяющий описывать

    определения новых типов объектов, состоящих из атрибутов (скалярных - т. е.

    других типов, множеств объектов, ссылок на объекты), и обладающих

    ассоциированными с ним методами. Любая колонка таблицы может быть любого

    типа, поддерживаются также вложенные таблицы и массивы объектов переменной

    длины.

    Что касается методов доступа, то они могут быть определены несколькими

    способами. Более простой из них предполагает контроль ядра сервера за

    выполнением метода: это достигается, если методы реализуются на PL/SQL

    (который также расширен для поддержки объектно-реляционных структур) или

    Java. Поскольку PL/SQL практически не уступает по своей функциональности

    универсальным языкам программирования, для подавляющего большинства

    составных типов данных таких возможностей будет достаточно. Если же новый

    тип данных требует специальной обработки, не реализуемой стандартными

    средствами ядра СУБД (к примеру, работа с мультимедийными данными,

    хранимыми в BLOB-полях в БД), можно использовать вызовы внешних процедур

    (call-outs), которые могут быть написаны, допустим, на языке C.

    При использовании внешних процедур возникает серьезная проблема

    организации их взаимодействия с ядром сервера. Наиболее соблазнительная -

    на первый взгляд - идея включения их непосредственно в ядро таит в себе

    угрозу нарушения стабильности этого ядра, поскольку оно оказывается

    незащищенным перед "чужим" кодом, и, следовательно, при любом сбое (или

    неправильном функционировании) становится практически невозможно

    определить, явилось ли это следствием ошибки в самом ядре, или же это

    "наведенный" эффект от внешней процедуры. Поэтому Oracle изначально

    отказался от такой идеи и реализует взаимодействие ядра сервера с внешними

    процедурами в защищенном режиме (т. е. в различных адресных пространствах).

    Для реализации такого взаимодействия и для доступа из внешних процедур к

    данным БД требуется наличие специального программного интерфейса. Oracle в

    данном вопросе пошел по пути поддержки имеющегося стандарта интерфейса

    Corba, позволяя оформлять расширения ядра сервера как "картриджи данных"

    (Data Cartridges), входящие в более общую архитектуру сетевых вычислений

    (Network Computing Architecture).

    Для обеспечения постепенной миграции приложений и данных в новую объектно-

    реляционную среду введены объектные представления (object views), которые

    позволяют использовать в новых приложениях объектный интерфейс, работая при

    этом с обычными реляционными таблицами (т. о. сохраняя работоспособность

    старых приложений).

    Новые возможности в администрировании Oracle 8 - управляемые сервером

    сбросы и восстановления (собственно говоря, это расширенная интеграция

    применявшейся в Oracle 7 утилиты Enterprise Backup), централизованное

    хранение паролей (в Oracle 7 достигалось при использовании Advanced

    Networking Option или при идентификации пользователей через ОС, имеющую

    соответствующую функциональность), контроль за назначением и устареванием

    паролей (в Oracle7 - при идентификации пользователей через ОС). Новые

    режимы взаимодействия с сервером - поддержка очередей приоритетных

    сообщений, задающих описание транзакции или ее части (эта функциональность,

    кстати, может быть использована мониторами транзакций), возможность

    мультиплексирования сессий как на физических, так и на логических каналах

    связи. Фактическое снятие ограничений на количество BLOB-колонок в

    таблицах, возможность их тиражирования. Возможность разбиения BLOB-полей и

    их отдельного хранения (даже вне БД). Расширение функциональных

    возможностей тиражирования данных, введение программного интерфейса

    тиражирования, позволяющего реализовать поддержку репликации с самыми

    разнообразными системами хранения данных. Поддержка таблиц, целиком

    хранимых в индексах. Это далеко не полный список. Большая часть новшеств

    возникла не на пустом месте, а скорее представляет собой развитие тех черт,

    которые уже содержались в том или ином виде в Oracle7. Это не случайность:

    Oracle гарантирует совместимость версий сервера снизу вверх, при переходе к

    Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15


    Приглашения

    09.12.2013 - 16.12.2013

    Международный конкурс хореографического искусства в рамках Международного фестиваля искусств «РОЖДЕСТВЕНСКАЯ АНДОРРА»

    09.12.2013 - 16.12.2013

    Международный конкурс хорового искусства в АНДОРРЕ «РОЖДЕСТВЕНСКАЯ АНДОРРА»




    Copyright © 2012 г.
    При использовании материалов - ссылка на сайт обязательна.