МЕНЮ


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

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


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

    одновременно с ним транзакций. Они варьируются от самой "слабой" моды -

    "незафиксированного" (часто называемого "грязного") чтения, при котором

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

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

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

    само наличие всех этих различных мод изоляции в стандарте SQL отражает

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

    возможностями разработчиков СУБД. Пользователей же волнует совсем другое:

    как избежать тех неприятных эффектов, которые могут быть связаны с

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

    Сущность моды изоляции "согласованное чтение", реализуемой сервером

    Oracle состоит в том, что любая операция чтения в Oracle выдает

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

    начала операции. Oracle реализует "согласованное чтение" без использования

    блокировок вообще. Операция чтения в Oracle никогда не блокируется и

    никогда не блокирует других. Данный режим работы является среди

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

    с одной из мод изоляции, принятых в стандарте SQL-92. Она "сильнее" (и

    следовательно покрывает) все моды, кроме "повторяемого чтения", но она

    "слабее" последней. Действительно, при повторе операции в моде

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

    изменится момент времени, по которому синхронизуется "срез" данных. Oracle,

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

    read-only транзакцию, синхронизуя их при этом к одному моменту времени. В

    версии 7.3 Oracle позволяет в явном виде установить моду изоляции

    "repeatable read", причем опять без использования блокировок.

    Функциональные новшества. В Oracle 7.3 появилась возможность читать и

    писать поля таблиц типа Long по частям (на уровне Oracle Call Interface),

    что безусловно полезно, ибо размер таких полей может доходить до 2 Гбайт.

    Расширился набор типов представлений (views), для которых допускается их

    непосредственная модификация. Появился ряд новшеств в языке PL/SQL

    (процедурном расширении SQL), самое заметное из которых - поддержка таблиц,

    хранимых в памяти сервера. Новые алгоритмы обработки запросов. Выполнение

    SQL-запроса - особенно имеющего сложную структуру - обычно распадается на

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

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

    альтернативных решений. Выбор оптимальной их комбинации - задача

    оптимизатора, который на основании как характера запроса, так и имеющейся

    информации о задействованных таблицах и индексах, наличии тех или иных

    системных ресурсов (в Oracle 7.3 расширен набор видов предоставляемой

    оптимизатору информации: теперь он может учитывать частотные гистограммы

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

    Помимо "джентльменского" набора более или менее универсальных методов

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

    которые очень хорошо работают в некоторых ситуациях, но могут быть совсем

    неэффективными (или даже неприменимыми) в других. Несмотря на такой

    недостаток, применение этих методов может дать очень заметный эффект,

    особенно при выполнении сложных запросов над большими объемами данных, что

    характерно для систем поддержки принятия решений (DSS) (хранилищ данных). В

    Oracle 7.3 введен целый ряд таких специализированных алгоритмов.

    • "Звездообразные запросы" (star queries). В DSS-системах довольно часто

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

    фактов) с несколькими маленькими (справочными таблицами). При выполнении

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

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

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

    • "Слияние хэшированием". Альтернативный слиянию сортировкой метод

    выполнения соединений таблиц (еще одна альтернатива - вложенные циклы).

    • Применение битовых строк для индексирования. До версии 7.3 Oracle

    применял для индексирования только B-деревья и хэш-функции (если таблица

    помещалась в хэш-кластер). В версии 7.3 появилась возможность использования

    индексов с битовыми строками (bit-map indexes). Их идея очень проста. Если

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

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

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

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

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

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

    комбинациям), а также выполнять операции агрегирования опять-таки по этому

    полю. Метод эффективен лишь для полей с небольшим количеством допустимых

    значений, неэффективны операции сравнения с предшествованием

    (больше/меньше), неэффективны операции вставки, удаления и модификации

    записей. В действительности "в чистом виде" битовые строки не применяются:

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

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

    потому не устранимы полностью. Oracle позволяет применять bit-map

    индексирование в сочетании с другими методами индексирования на одной и той

    же таблице.

    До версии Oracle 7.3 основным средством администратора являлся Server

    Manager - программный продукт с графическим интерфейсом, но ориентированный

    на управление одной БД (в случае нескольких БД приходилось использовать

    несколько сессий), не имевший удобных средств графического мониторинга

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

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

    контролем СУБД Oracle. Пробел заполнялся достаточно многочисленными

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

    средствах администрирования. Однако обеспечение единообразного

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

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

    администрирования сервера БД.

    В комплекте с сервером версии 7.3 (в вариантах Workgroup и Enterprise)

    поставляется Oracle Enterprise Manager. В состав этого программного

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

    администратора. Через специальный связной процесс - Communication Deamon -

    эта консоль может взаимодействовать с интеллектуальными агентами -

    специальными процессами, функционирующими на компьютерах-серверах,

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

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

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

    консоли с сервером БД). Все управляемые компоненты - БД, серверы (узлы),

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

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

    структуры до нужного уровня. Непосредственно административные функции

    выполняются с помощью явного или неявного вызова соответствующих утилит.

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

    другую, присвоение новой роли пользователю и др.) достаточно "буксировки"

    мышкой.

    Принципиально новой особенностью Enterprise Manager по сравнению с более

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

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

    рамки возможностей самой СУБД (сбросы, команды ОС и т. п.), а также

    возможность заставить систему саму извещать администратора о возникших (или

    даже предполагаемых) проблемах с помощью механизма событий.

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

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

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

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

    выполнения, необходимо, чтобы "агент вышел на связь"). Помимо использования

    набора стандартных типов заданий и их комбинаций администратор может

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

    (Task Control Language). Фактически и "стандартные" типы заданий строятся с

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

    качестве образцов. Интерпретация TCL в конкретной ОС того или иного сервера

    осуществляется соответствующим интеллектуальным агентом, что делает

    управление СУБД почти не зависящим от платформы сервера (а таких платформ

    Oracle поддерживает более 80).

    Набор возможных регистрируемых событий варьирует от самых простых типа

    запуска и останова сервера БД до достаточно "тонких" типа превышения

    частоты обращений к диску заданного администратором порога. События

    регистрируются интеллектуальными агентами и передаются на консоль

    администратора (точнее, на те из консолей, которые "интересуются" данным

    событием), а если потребуется, сообщение о событии может быть послано

    администратору по электронной почте или на пейджер.

    Еще одной важной особенностью Oracle Enterprise Manager является то, что

    он имеет открытые интерфейсы на всех своих уровнях, что открывает

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

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

    всего ориентирована на фирмы, являющиеся поставщиками средств

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

    Отдельного упоминания заслуживают поставляемые Oracle утилиты, входящие в

    Performance Package. В него входят: утилита мониторинга системы (несколько

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

    собственные); утилита, показывающая в наглядной форме физическое

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

    оптимизирующие операции (дефрагментацию); утилита, показывающая информацию

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

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

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

    используемых курсоров и планов выполнения соответствующих им запросов).

    Наконец, есть еще две утилиты, стоящие несколько особняком. Это Oracle

    Trace - управляемая событиями трассировка - и Oracle Expert - экспертная

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

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

    оптимизирующей настройки.

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

    Oracle - его высокая степень масштабируемости: как горизонтальной, так и

    вертикальной. Oracle владеет в настоящий момент абсолютными рекордами

    производительности как в OLTP-тестах TPC-C (причем этот рекорд держится с

    апреля 1996 года), так и в DSS-тестах TPC-D (в варианте с объемом данных

    300 Гбайт). Наиболее широко распространены симметрично-параллельные (SMP)

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

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

    общими для них. Количество процессоров в таких системах, предлагаемых на

    рынке, может доходить до 64. Для SMP-систем часто еще употребляют

    определение "система с полным разделением ресурсов" (shared-everything

    system). Следующий тип параллельной архитектуры - кластер: в нем узлы,

    имеющие свою собственную оперативную память (а возможно и собственные

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

    с разделяемыми дисками" - shared-disks system). Как правило, каждый из

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

    кластерах, предлагаемых на рынке, доходит до 8. Наконец, третий тип

    архитектуры - массивно-параллельный (MPP). В ней узлы живут практически

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

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

    и больше. Безусловно система должна в той или иной степени обеспечивать

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

    менее к системам с данной архитектурой часто применяют определение "система

    без разделения ресурсов" (shared-nothing system).

    Сервер Oracle в любой конфигурации поддерживает параллелизм при

    выполнении потока операций в SMP-архитектуре, для параллельного выполнения

    отдельных запросов требуется установка Parallel Query Option. Для кластеров

    и MPP-систем Oracle предлагает архитектуру, позволяющую всем узлам этих

    систем параллельно осуществлять доступ к одной БД: чтобы добиться этого,

    достаточно установить Parallel Server Option. Для обеспечения параллелизма

    в SMP-системах Oracle предлагает возможность использования многопотоковых

    разделяемых серверных процессов.

    Опция Oracle Parallel Server позволяет нескольким узлам системы

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

    работать с одной БД, находящейся на общих дисках (в MPP-системе это будут

    "виртуальные" общие диски, поддерживаемые ОС). Пользовательские сессии

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

    одними и теми же данными (помимо возможности использования полной мощности

    параллельной системы для работы с БД). Можно заметить, что в Oracle8 даже

    эта операция не обязательна: новая версия сервера позволяет выполнять

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

    прерванные запросы попросту продолжают выполняться после небольшой

    задержки.

    Однако нельзя утверждать, что при применении OPS не возникает никаких

    проблем. По сравнению с SMP-системами возникает одна проблема:

    синхронизация кэшей в оперативной памяти узлов – каждый узел системы

    кэширует данные БД в своей оперативной памяти и может держать их там

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

    модифицировал некую запись БД, но не переписал ее на диск, то при обращении

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

    своей памяти (она уже не актуальна), ни даже считать ее с диска. Для

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

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

    "замок", так что любой другой узел при обращении к этим данным должен

    сначала "снять замок", что включает в себя передачу ему актуальных данных.

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

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

    производительность сервера в целом.

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

    технических ухищрений, ни с помощью альтернативных решений. К счастью, если

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

    записи, то и блокировки параллельного кэша возникают редко. Такой режим

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

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

    различных отделов (филиалов) и пр. Приложения, осуществляющие "хаотичные"

    обращения к большой БД, также имеют слабую тенденцию к порождению

    блокировок параллельного кэша. Тем не менее, распределение пользователей

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

    какими данными и в каком режиме они работают. Как бы то ни было, OPS уже

    достаточно давно и успешно используется - особенно в инсталляциях,

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

    тестах TPC-C поставлен с использованием OPS на кластере (Digital Alpha

    8400). Надо сказать, что до последнего времени понятия "кластер" и

    "параллельный сервер" ассоциировались только с весьма мощными и

    дорогостоящими конфигурациями аппаратуры. Отчасти это было связано с

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

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

    Одним из первых пожирателей ресурсов является менеджер распределенных

    блокировок (Distributed Locks Manager - DLM). Это программный компонент

    (реализованный обычно в виде набора процессов), обычно поставляемый фирмой-

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

    ресурсам на уровне системы в целом. Именно с помощью DLM Oracle реализует

    блокировки параллельного кэша и вообще синхронизацию работы узлов.

    Универсальность DLM в сочетании с тем, что он является "внешней

    составляющей" OPS, приводит к тому, что общее количество блокировок

    параллельного кэша становится критичным ресурсом. Чтобы снизить потребность

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

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

    другой подход к реализации DLM. В частности, по этой причине уже в версии

    Страницы: 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 г.
    При использовании материалов - ссылка на сайт обязательна.