Значения 3 в списке нет oracle fusion

Обновлено: 03.07.2024

Oracle Fusion Middleware - семейство связующих технологий Oracle для создания инфраструктуры приложений.

Под брендом Oracle Fusion Middleware корпорация Oracle объединила все интеграционные программные продукты.

Oracle Fusion Middleware включает в себя:

  • всю совокупность продуктов Oracle Application Server, включая все редакции сервера приложений;
  • дополняющие сервер приложений Oracle инструментальные продукты, такие как: Oracle JDeveloper, Oracle TopLink and Application Development Framework (ADF), Oracle Internet Developer Suite, Oracle BI Beans, Oracle Warehouse Builder;
  • семейство интеграционных продуктов: Oracle InterConnect, Oracle B2B, Oracle BPEL Pro-cess Manager, Oracle Business Activity Monitoring (BAM), Oracle Enterprise Service Bus (ESB);
  • семейство концентраторов данных Oracle Data Hubs, таких как: Oracle Customer DataHub, Oracle Financial Consolidation Hub и Oracle Product Information Management Hub;
  • семейство продуктов обеспечения безопасности: Oracle Identity Management, OracleCoreId Access and Identity, Oracle Web Services Manager, Oracle CoreId Federation and CoreId Provisioning;
  • функциональные расширения сервера приложений, такие как: Oracle Portal, OracleBusiness Intelligence (BI), Oracle XML Publisher, Oracle Business Rules, Oracle Mobile,Oracle Sensor Edge Server;
  • Оracle Collaboration Suite и его модули Content Services, RealTime Collaboration,Unified Messaging, Workspaces с новыми функциональными возможностями.

Недавно Oracle выпустила новый программный продукт семейства Fusion Middleware - Data Integrator, предназначенный для интеграции больших объемов данных, поступающих из различных корпоративных приложений. Решение призвано облегчить интеграцию таких критических для управления бизнесом приложений, как бизнес-аналитика (Business Intelligence), хранилище данных (Data Warehouse), управление основными данными (Master Data Management), сервисно-ориентированная архитектура (Service-Oriented Architecture), мониторинг деятельности (Business Activity Monitoring), а также миграция и консолидация ПО (Application Migration and Consolidation).

Oracle Data Integrator обеспечивает интеграцию разнородной информации, производительность при использовании инновационной технологии ELT (Extract, Load, Transform), поддерживает обработку как пакетных заданий, так и работу в режиме реального времени. Кроме того, приложение позволяет снизить стоимость разработки и поддержки интегрированных систем, используя язык декларативных моделей и библиотеки программных кодов, называемые модулями знаний (Knowledge Modules).

Новая разработка основана на технологии, созданной недавно приобретенной компании Sunopsis. Oracle Data Integrator исключает необходимость использования специализированного ETL-сервера, производя операции по трансформации данных либо внутри приложения-источника, либо внутри хранилища данных, что, по утверждению разработчиков, увеличивает скорость обработки и снижает стоимость ПО.

2019: Исправление 37 уязвимостей

17 октября 2019 года стало известно, что компания Oracle исправила 219 опасных уязвимостей в разных линейках продуктов, более 140 из которых могут быть проэксплуатированы удаленно неавторизованным злоумышленником. 19 уязвимостей были обозначены как критические и получили оценку выше 9,0 по шкале CVSS.

Больше всего уязвимостей исправлено в платформе для цифровой трансформации бизнеса на предприятии и в облаке Fusion Middleware — 37 исправлений. Свободная реляционная система управления базами данных MySQL получила 34 исправления уязвимостей. В платформе Java SE исправлено 20 уязвимостей.

Другие продукты, получившие исправления уязвимостей, включают Construction and Engineering (13 исправлений), приложения PeopleSoft (13), Oracle Retail (12), платформы для управления рисками (12), Oracle Database (10), ПО для вирутализации (11), E-Business Suite (10), Enterprise Manager (7), Oracle Financial Services (7) и Oracle Food and Beverage (7).

Также были исправлены уязвимости в Policy Automation (4 исправления), Siebel CRM (4), Oracle Supply Chain (3), GraalVM (3), приложениях Oracle Hospitality (3), Hyperion (3), приложениях Oracle Health Sciences (2), Oracle Support Tools (2), JD Edwards (1) и NoSQL Database (1) [1] .

Сертификация ФСТЭК

8 декабря 2015 года представительство Oracle в Росии объявило о получении сертификата Федеральной службы по техническому и экспортному контролю (ФСТЭК) России на программное обеспечение Oracle Fusion Middleware для оптимизированного программно-аппаратного комплекса Oracle Exalogic.

Сертификат подтверждает: платформа Oracle Fusion Middleware для Oracle Exalogic - программное средство общего назначения, имеющее встроенные средства защиты от несанкционированного доступа к информации, не содержащей сведений, составляющих государственную тайну. Оно соответствует требованиям технических условий. Встроенные средства защиты реализуют функции идентификации и аутентификации, управления доступом, регистрации событий безопасности, обеспечения доступности информации.

Oracle Exalogic Elastic Cloud — оптимизированный программно-аппаратный комплекс, разработанный для обеспечения максимальной производительности, надежности и масштабируемости приложений на платформе Oracle Fusion Middleware, консолидации приложений Oracle и других производителей. Он совместим с продуктами Oracle, Java и другими приложениями, обеспечивает низкую совокупную стоимость владения, пониженные риски, высокую продуктивность пользователей и комплексную поддержку.

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

Модернизировано семейство Fusion Middleware

2 ноября 2015 года корпорация Oracle анонсировала возможности семейства программного обеспечения Fusion Middleware.

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

В составе этой версии корпорация Oracle объявила о выпуске крупнейшего за последнее десятилетие обновления Oracle WebLogic Server и представила первую в мире платформу Java корпоративного класса, предназначенную для использования в облачной среде. Усовершенствованы другие компоненты Oracle Fusion Middleware, включая Oracle BPM Suite, Oracle Data Integration, Oracle SOA Suite, Oracle WebCenter и Oracle Developer Tools.

В этом руководстве описаны шаги, которые нужно выполнить в Oracle Fusion ERP и Azure Active Directory (Azure AD), чтобы настроить автоматическую подготовку и отзыв пользователей и (или) групп в Azure AD для Oracle Fusion ERP.

В этом руководстве рассматривается соединитель, созданный на базе службы подготовки пользователей Azure AD. Подробные сведения о том, что делает эта служба, как она работает, и часто задаваемые вопросы см. в статье Автоматическая подготовка пользователей и ее отзыв для приложений SaaS в Azure Active Directory.

Сейчас этот соединитель доступен в режиме предварительной версии. Дополнительные сведения об общих условиях использования продуктов в предварительной версии см. в документе Дополнительные условия использования предварительных версий Microsoft Azure.

Предварительные требования

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

  • клиент Azure AD; ;
  • учетная запись пользователя Oracle Fusion ERP с разрешениями администратора.

Назначение пользователей для Oracle Fusion ERP

В Azure Active Directory для определения того, какие пользователи должны получать доступ к выбранным приложениям, используется понятие "назначение". В контексте автоматической подготовки синхронизируются только те пользователи и (или) группы, которые были назначены конкретному приложению в Azure AD.

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

Важные замечания о назначении пользователей для Oracle Fusion ERP

Рекомендуется назначить одного пользователя Azure AD для Oracle Fusion ERP, чтобы проверить конфигурацию автоматической подготовки пользователей. Дополнительные пользователи и/или группы можно назначить позднее.

При назначении пользователя для Oracle Fusion ERP в диалоговом окне назначения необходимо выбрать действительную роль для конкретного приложения (если доступно). Пользователи с ролью Доступ по умолчанию исключаются из подготовки.

Настройка подготовки в Oracle Fusion ERP

Прежде чем настраивать автоматическую подготовку пользователей в Azure AD для Oracle Fusion ERP, необходимо включить подготовку SCIM для Oracle Fusion ERP.

Щелкните элемент Navigator (Навигация) в левом верхнем углу. В разделе Tools (Средства) выберите Security Console (Консоль безопасности).

Снимок экрана со страницей Navigator (Навигация) в консоли администрирования Oracle Fusion ERP. На ней выделены элементы Tools (Средства) и Security console (Консоль безопасности).

Перейдите в раздел Users (Пользователи).

Снимок экрана: панель в консоли администрирования Oracle Fusion ERP. На ней выделен элемент Users (Пользователи).

Сохраните имя пользователя и пароль для учетной записи администратора, с которой вы будете входить в консоль администрирования Oracle Fusion ERP. Эти значения нужно ввести в поля Имя администратора и Пароль на вкладке "Подготовка" для приложения Oracle Fusion ERP на портале Azure.

Добавление Oracle Fusion ERP из коллекции

Чтобы настроить автоматическую подготовку пользователей для Oracle Fusion ERP с помощью Azure AD, нужно добавить Oracle Fusion ERP из коллекции приложений Azure AD в список управляемых приложений SaaS.

Чтобы добавить Oracle Fusion ERP из коллекции приложений Azure AD, выполните следующие действия:

На портале Azure в области навигации слева выберите элемент Azure Active Directory.

Кнопка Azure Active Directory

Перейдите в колонку Корпоративные приложения и выберите Все приложения.

Колонка "Корпоративные приложения"

Чтобы добавить новое приложение, в области сверху нажмите кнопку Новое приложение.

Кнопка "Создать приложение"

В поле поиска введите Oracle Fusion ERP и выберите Oracle Fusion ERP на панели результатов.

Oracle Fusion ERP в списке результатов

Настройка автоматической подготовки пользователей в Oracle Fusion ERP

В этом разделе описывается, как настроить службу подготовки Azure AD для создания, обновления и отключения пользователей и (или) групп в Oracle Fusion ERP на основе их назначений в Azure AD.

Вы также можете настроить для Oracle Fusion ERP единый вход на основе SAML, используя инструкции из руководства по единому входу для Oracle Fusion ERP. Единый вход можно настроить независимо от автоматической подготовки пользователей, хотя эти две возможности хорошо дополняют друг друга.

Дополнительные сведения о конечной точке SCIM для Oracle Fusion ERP см. в статье REST API for Common Features in Oracle Applications Cloud (REST API для основных функций облака приложений Oracle).

Для настройки автоматической подготовки пользователей в Azure AD для Fuze выполните следующее:

Войдите на портал Azure. Выберите Корпоративные приложения, а затем Все приложения.

Колонка "Корпоративные приложения"

В списке приложений выберите Oracle Fusion ERP.

Ссылка на Oracle Fusion ERP в списке приложений

Выберите вкладку Подготовка.

Снимок экрана: раздел "Управление" с выделенным параметром "Подготовка".

Для параметра Режим подготовки к работе выберите значение Automatic (Автоматически).

Снимок экрана: раскрывающийся список "Режим подготовки" с выделенным параметром "Автоматически".

Снимок экрана: раздел "Учетные данные администратора". В нем отображаются кнопка "Проверить подключение" и поля "URL-адрес клиента", "Имя администратора" и "Пароль".

Почтовое уведомление

Выберите команду Сохранить.

В разделе Сопоставления выберите Synchronize Azure Active Directory Users to Oracle Fusion ERP (Синхронизировать пользователей Azure Active Directory с Oracle Fusion ERP).

Снимок экрана: раздел "Сопоставления". Под элементом "Имя" выделен элемент для синхронизации пользователей Azure Active Directory с Oracle Fusion ERP

.

Снимок экрана: страница "Сопоставление атрибутов". В таблице перечислены атрибуты Azure Active Directory и Oracle Fusion ERP с указанием приоритета сопоставления.

В разделе Сопоставления выберите Synchronize Azure Active Directory Groups to Oracle Fusion ERP (Синхронизировать группы Azure Active Directory с Oracle Fusion ERP).

Сопоставления групп для Oracle Fusion ERP

Атрибуты групп для Oracle Fusion ERP

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

Чтобы включить службу подготовки Azure AD для Oracle Fusion ERP, измените значение параметра Состояние подготовки на Включено в разделе Параметры.

Состояние подготовки "Включено"

Укажите пользователей и (или) группы для подготовки в Oracle Fusion ERP, выбрав нужные значения в поле Область раздела Параметры.

Область действия подготовки

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

Сохранение конфигурации подготовки

После этого начнется начальная синхронизация пользователей и (или) групп, определенных в поле Область раздела Параметры. Начальная синхронизация занимает больше времени, чем последующие операции синхронизации. Если служба запущена, они выполняются примерно каждые 40 минут. В разделе Сведения о синхронизации можно отслеживать ход выполнения и переходить по ссылкам для просмотра отчетов о подготовке, в которых зафиксированы все действия, выполняемые службой подготовки Azure AD с приложением Oracle Fusion ERP.

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

Продолжение статьи про Real Application Cluster (RAC). Окончание.

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

Взаимодействие узлов. Cache-fusion.

Много экземпляров БД, много дисков. Хлынули пользовательские запросы… вот они, клиенты, которых мы так ждали. =)

Самым узким местом любой БД являются дисковый ввод-вывод. Поэтому все базы данных стараются как можно реже обращаться к дискам, используя отложенную запись. В RAC все так же, как и для single-instance БД: у каждого узла в RAM располагается область SGA (System Global Area), внутри нее находится буферный кэш (database buffer cache). Все блоки, некогда прочитанные с диска, попадают в этот буфер, и хранятся там как можно дольше. Но кэш не бесконечен, поэтому, чтобы оценить важность хранимого блока, используется TCA (Touch Count Algorithm), считающий количество обращений к блокам. При первом попадании в кэш, блок размещается в его cold-end. Чем чаще к блоку обращаются, тем ближе он к hot-end. Если же блок «залежался», он постепенно утрачивает свои позиции в кэше и рискует быть замещенным другой записью. Перезапись блоков начинается с наименее используемых. Кэш узла – крайне важен для производительности узлов, поэтому для поддержания высокой производительности в кластере кэшем нужно делиться (как завещал сами-знаете-кто). Блоки, хранимые в кэше узла кластера, могут иметь роль локальных, т.е. для его собственного пользования, но некоторые уже будут иметь пометку глобальные, которыми он, поскрипев зубами дисками, будет делится с другими узлами кластера.

Технология общего кэша в кластере называется Cache-fusion (синтез кэша). CRS на каждом узле порождает синхронные процессы LMSn, общее их название как сервиса — GCS (Global Cache Service). Эти процессы копируют прочитанные на этом экземпляре блоки (глобальные) из буферного кэша к экземпляру, который за ними обратился по сети, и также отвечают за откат неподтвержденных транзакций. На одном экземпляре их может быть до 36 штук (GCS_SERVER_PROCESSES). Обычно рекомендуется по одному LMSn на два ядра, иначе они слишком сильно расходуют ресурсы. За их координацию отвечает сервис GES (Global Enqueue Service), представленный на каждом узле процессами LMON и LMD. LMON отслеживает глобальные ресурсы всего кластера, обращается за блоками к соседним узлам, управляет восстановлением GCS. Когда узел добавляется или покидает кластер, он инициирует реконфигурацию блокировок и ресурсов. LMD управляет ресурсами узла, контролирует доступ к общим блоками и очередям, отвечает за блокировки запросов к GCS и управляет обслуживанием очереди запросов LMSn. В обязанности LMD также входит устранение глобальных взаимоблокировок в рамках нескольких узлов кластера.


Таблица GRD распределена между узлами кластера. Каждый узел принимает участие в распределении ресурсов кластера, обновляя свою часть GRD. Часть таблицы GRD относится к ресурсам – объектам: таблицы, индексы и.т.п. Она постоянно синхронизируется (обновляется) между узлами.
Когда узел прочел блок данных с диска, он становится master-ом этого ресурса и делает соответствующую отметку в своей части таблицы GRD. Блок помечается как локальный, т.к. узел пока использует его в одиночку. Если же этот блок потребовался другому узлу, то процесс GCS пометит этот блок в таблице как глобальный («опубликован» для кластера) и передаст затребовавшему узлу.

DBA location mode role SCN PI/XI
500 узел №3 shared local 9996 0

  • Data Block Address (DBA): физический адрес блока
  • Location: узел на котором доступен этот блок
  • Resource mode: определяется тем, кто на текущий момент является владельцем блока и какая операция к нему будет применяться
    • null: узел не претендует на изменение этого блока (только select)
    • shared: к блоку осуществляется защищенный множественный доступ только для чтения на нескольких узлах.
    • exclusive: узел собирается изменить (или уже изменил) этот блок. Хотя одновременно в кластере могут содержаться прежние (согласованные) версии этого же блока, менять их нельзя.
    • local: когда узел только прочитал блок с диска, и ни с кем им еще не делился.
    • global: когда узел был изначально считан этим блоком, но после был передан запросившему его узлу в некотором режиме (mode). Теперь этот же блок может присутствовать на других узлах.
    • Past Image (PI): глобальный грязный блок (старая версия, после изменения), хранящийся в кэше узла после того, как узел передал его по сети другому. Блок держится в памяти пока он или более поздняя версия не будет записана на диск, о чем оповестит GCS, когда блок будет больше не нужен.
    • Current Image (XI): текущая последняя копия блока, содержащаяся в последнем узле кластера в цепочке запросов этого блока.
    • как можно реже обращаться к диску, за счет активной работы с кэшем
    • обеспечить consistency read (CR), согласованность по чтению, т.е. данные неподтвержденной транзакции никто никогда не увидит ни в какой (параллельной) сессии

    • Read/read behavior (no transfer).
      Пусть данные таблицы A первым считал узел №4. Он является master этой таблицы и отвечает за соответствующую часть в GRD.
    • На узел №3 пришел запрос на чтение из таблицы A. У узла №3 в кэше нет необходимого блока. Из GRD он узнает, что master таблицы A – это узел №4, и обращается к нему.
    • Узел №4 просматривает GRD на наличие запрашиваемого блока. Если бы он был у него в кэше, то он просто бы передал его. Но допустим, что нужного блока не оказалось. Узел №4 отправит узлы №3 самостоятельно считать этот блок с диска.
    • Узел №3 сам считывает его с диска, пока только для себя и ни с кем блоком не делится (local), но впоследствии может предоставлять к нему доступ другим узлам через посредника — master-а этой таблицы (shared).
    • Узел №3 отчитывается перед master таблицы A узлом №4, и тот вносит соответствующую запись в GRD (на узле №4):

    Без необходимости никаких записей на диск не происходит. Всегда копия блока хранится на узле, на котором он чаще используется. Если определенного блока пока еще нет в глобальном кэше, то при запросе master попросит соответствующий узел прочитать блок с диска и поделиться им с остальными узлами (по мере надобности).

    1. Участвует 2 узла: когда целевому узлу потребовался блок, который хранился в кэше master.
    2. Участвует 3 узла: когда master отправляет запрос промежуточному узлу, и тот передает блок востребованному в нем узлу.

    Taking fire, need assistance! Workload distribution.

    Описанное устройство Cache-fusion, предоставляет кластеру возможность самому (автоматически) реагировать на загрузку узлов. Вот как происходит workload distribution или resource remastering (перераспределение вычислительных ресурсов):
    Если, скажем, через узел №1 1500 пользователей обращается к ресурсу A, и примерно в это же время 100 пользователей обращается к тому же ресурсу A через узел №2, то очевидно, что первый узел имеет большее количество запросов, и чаще будет читать с диска. Таким образом узел №1 будет определен как master для запросов к ресурсу A, и GRD будет создано и координироваться начиная с узла №1. Если узлу №2 потребуются те же самые ресурсы, то для получения доступа к ним он должен будет согласовать свои действия с GCS и GRD узла №1, для получения ресурсов через interconnect.
    Если же распределение ресурсов поменяется в пользу узла №2, то процессы №2 и №1 скоординируются свои действия через interconnect, и master-ом ресурса A станет узел №2, т.к. теперь он будет чаще обращаться к диску.
    Это называется родственность (affinity) ресурсов, т.е. ресурсы будут выделяться тому узлу, на котором происходит больше действий по получению и их блокированию. Политика родственности ресурсов скоординирует деятельность узлов, чтобы ресурсы более доступны были там, где это более необходимо. Вот, кратко, и весь workload distribution.

    Перераспределение (remastering) также происходит, когда какой-то узел добавляется или покидает кластер. Oracle перераспределяет ресурсы по алгоритму называемому «ленивое перераспределение» (lazy remastering), т.к. Oracle почти не принимает активных действий по перераспределению ресурсов. Если какой-то узел упал, то все, что предпримет Oracle – это перекинет ресурсы, принадлежавшие обвалившемуся узлу, на какой-то один из оставшихся (менее загруженный). После стабилизации нагрузки GCS и GES заново (автоматически) перераспределят ресурсы (workload distribution) по тем позициям, где они более востребованы. Аналогичное действие происходит при добавлении узла: примерно равное количество ресурсов отделяется от действующих узлов и назначается вновь прибывшему. Потом опять произойдет workload distribution.
    Как правило, для инициализации динамического перераспределения, загруженность на определенном узле должна превышать загруженность остальных в течение более 10 минут.

    Вот пуля пролетела, и… ага? Recovery.

    1. Часть GRD таблицы с ресурсами упавшего узла «замораживается».
    2. Не вышедший на связь узел помечается как «пропавший», чтобы оставшиеся узлы к нему не обращались зря по interconnect.
    3. Узел, который первым обнаружил пропажу, начинает восстановление информации, которая обрабатывалась на исчезнувшем узле:
      • Понижает темпы обслуживания собственных транзакций, бросая вычислительные ресурсы на восстановление
      • Обращается к общему файловому хранилищу (datastorage), и на себе начинает применять online redo logs, принадлежавшие пропавшему узлу. С учетом порядкового номера SCN блоков, merge их с тем, что хранится в буфере, и «накатывает» (roll-forward) в своем кэше. При этом узел пропускает те устаревшие записи блоков (PI), более поздние версии которых, уже были сброшены на диск. Если у считанных блоков в кластере присутствует master соответствующего ресурса, то узел сообщает список считанных блоков, и master на этих ресурсах выставляет блокировку, чтобы узлы к ним не обращались (пока они восстанавливаются).
      • После чего, вторым прочтением по redo log, учитывая уже undo записи, откатывает (roll-back) незафиксированные транзакции. Происходит это по технологии fast-recovery, т.е. откат транзакций будет производиться отдельным background процессом. Oracle вернет заблокированные незавершенными транзакциями (uncommitted) блоки в согласованное состояние (consistent), к прежним значениям, как только придет запрос на эти блоки. Либо они уже к тому времени будут восстановлены этим самым параллельным background процессом. Таким образом, уже в кластере снимаются блокировки и могут выполняться новые запросы пользователей.
    4. Часть таблицы GRD, принадлежавшая упавшему узлу, размораживается на восстанавливающем узле (теперь он master ресурса). Таким образом, в кластере восстанавливается состояние обрабатываемых транзакций на пропавшем узле на момент «падения».

    Но пока все эти процессы происходят, нетерпеливому клиенту есть что предложить.

    Пока узлы спасают друг друга… Failover.

    Virtual IP (VIP) – логический сетевой адрес, назначаемый узлу на внешнем сетевом интерфейсе. Он предоставляет возможность CRS спокойно запускать, останавливать и переносить работу с этим VIP на другой узел. Listener (процесс, принимающий соединения) на каждом узле будет прослушивать свой VIP. Как только какой-то узел становится недоступным, его VIP подхватывает на себя другой узел в кластере, таким образом, временно обслуживая свои и запросы упавшего узла.

    1. Database VIPs: Клиент подсоединится по VIP, но уже подключится к другому узлу. Временно замещающий узел ответит “logon failed”, несмотря на то, что VIP будет active, нужный экземпляр БД за ним будет отсутствовать. И клиент тут же повторит попытку, но уже к другому экземпляру/узлу кластера из своего списка в конфигурации.
    2. Application VIP: то же, что и прежде. Но только теперь по этому VIP можно будет обратиться к приложению, на каком бы узле оно ни крутилось.

    Если узел восстановится и выйдет в online, CRS опознает это и попросит сбросить в offline на подменяющем его узле и вернет VIP адрес обратно владельцу. VIP относится к CRS, и может не перебросится если выйдет из строя именно экземпляр БД.

    Важно отметить, что при failover переносятся только запросы select, вместе и открытыми курсорами (возвращающими результат). Транзакции не переносятся (PL/SQL, temp tables, insert, update, delete), их всегда нужно будет запускать заново.

    • Connect-time failover and client load-balancing
      В этом случае клиент всегда случайно выбирает к какому узлу кластера подключиться из своего списка конфигурации сетевого подключения. Если узел, выполняющий запрос, выходит из строя, то по TAF клиент выбирает другой узел кластера и переподключается.
    • Preconnect
      В этом случае, клиент всегда при установлении соединения с кластером подключается ко всем узлам, хотя запрос будет запускать только на одном экземпляре. Если же узел выходит из строя, то просто переводит запрос на другой узел. Failover происходит быстрее, но расходует ресурсы на подключение на всех узлах кластера.

    Туда не ходи, сюда ходи… Load-balancing.

    При выполнении любых операций, информацию, относящуюся к производительности запросов (наподобие «отладочной»), Oracle собирает в AWR (Automatic Workload Repository). Она хранится в tablespace SYSAUX. Сбор статистики запускается каждые 60 минут (default): I/O waits, wait events, CPU used per session, I/O rates on datafiles (к какому файлу чаще всего происходит обращение).

    Необходимость в Load-balancing (распределении нагрузки) по узлам в кластере определяется по набору критериев: по числу физических подключений к узлу, по загрузке процессора (CPU), по трафику. Жаль что нельзя load-balance по среднему времени выполнения запроса на узлах, но, как правило, это некоторым образом связано с задействованными ресурсами на узлах, а следовательно оставшимися свободными ресурсам.

    О Client load-balancing было немного сказано выше. Он просто позволяет клиенту подключаться к случайно выбранному узлу кластера из списка в конфигурации. Для осуществления же Server-side load-balancing отдельный процесс PMON (process monitor) собирает информацию о загрузке узлов кластера. Частота обновления этой информации зависит от загруженности кластера и может колебаться в пределе от приблизительно 1 минуты до 10 минут. На основании этой информации Listener на узле, к которому подключился клиент, будет перенаправлять его на наименее загруженный узел.

    • Based on elapsed-time (CLB_GOAL_SHORT): по среднему времени выполнения запроса на узле
    • Based on number of sessions (CLB_GOAL_LONG): по количеству подключений к узлу

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

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

    Классическим примером дерева является иерархия сотрудников на предприятии. Для демонстрации работы с деревьями создадим таблицу и заполним ее данными:

    CREATE TABLE EMPL (
    ID INTEGER PRIMARY KEY,
    NAME VARCHAR(50),
    PARENT_ID REFERENCES EMPL
    );

    Добавим данные в таблицу:

    В распоряжение пользователя, Oracle предоставляет предложение языка PL/SQL - CONNECT BY. Оно позволяет строить иерархию одним запросом, просто и изящно:

    Полученный результат кажется не совсем понятным, но если внимательно посмотреть, то видно, что выстроены все возможные деревья и поддеревья. Теперь добавим в запрос конструкцию START WITH:

    Обратите внимание, что в предложении START WITH использован вложенный запрос для определения кто стоит на самом верху. Обычно, в поле PARENT_ID для узлов, используют NULL или -1. Естественно, что их может быть один и более. Сама конструкция START WIDTH указывает, откуда начинать строить дерево.

    Теперь, наведем немного порядок, упорядочим записи, и покажем кто находится на каком уровне иерархии. Для этого, Oracle предоставляет псевдоколонку LEVEL. Она может быть использована только в том случае, если в запросе присутствует CONNECT BY. Для упрощения укажем >

    Колонка LEVEL может быть использована для отметки записи. Используем оператор конкатенации (//)для добавления пробелов в начале каждой строки:

    Для ограничения вывода можно использовать стандартное условие WHERE. Уберем из вывода сотрудников, у которых уровень меньше, либо равен 3:

    Если вы хотите произвести сортировку, то стоит учитывать, ORDER BY работает не совсем так, как в случае с простыми данными, без иерархии. Продемонстрируем это:

    Как видно, сортировка прошла по колонке LEVEL, и затем уже по имени, но замете, что самое важное, иерархия сохранена, и внутри каждого уровня иерархии уже идет сортировка по имени. А что же будет, если из условия сортировки убрать поле LEVEL?

    Как видно вся иерархия поломалась. Чтобы указать Oracle, что сортировать надо только в пределах одного уровня иерархии, поможет маленькая добавка в виде оператора SIBLINGS. Достаточно изменить условие сортировки на ORDER SIBLINGS BY <поле> - и все встанет на свои места.

    Еще одна очень полезная функция - SYS_CONNECT_BY_PATH().Она принимает два параметра через запятую: название колонки и строку с символом-разделителем. Для иллюстрации ее работы выполним такой запрос:

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

    Топаем дальше. Псевдоколонка CONNECT_BY_ISLEAF. Ее можно использовать так же, как LEVEL. В этой колонке напротив каждой строки проставляется 0 или 1. Если есть потомки - то 0. Если потомков нет, такой узел в дереве называется "листом", тогда и значение в поле CONNECT_BY_ISLEAF будет равно 1.

    Помните такую конструкцию PRIOR, которая позволяла ссылаться на родительскую запись? Так вот, есть такой оператор, CONNECT_BY_ROOT, который ссылается на корень дерева. Для демонстрации работы выполним:

    Если при построении дерева вы получаете ошибку, о том, что найдена петля (цикл), то это означает - дерево неверно спроектировано. На такой случай, есть NOCYCLE. Это позволит вам избежать бесконечных циклов. Для иллюстрации работы, выполним:

    Теперь, программист-стажер подчиняется сам себе. Выполняем:

    И видим, что стажера нет, он выпал из дерева. Oracle не видит пути, и не включает элемент в иерархию. Попробуем заставить его начать со стажера. Для этого немного поменяем условия запроса:

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

    JOIN не работает с CONNECT BY

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

    ERROR at line 4:
    ORA-01437: cannot have join with CONNECT BY

    Обойти эту проблему можно создав представление:

    Колонку LEVEL переименовали, чтобы представление не заканчивалось на зарезервированное слово.

    Сейчас можно выполнить JOIN

    Если обратите внимание, то увидите что выполнено OUTER JOIN, потому что в списке нет большого босса.

    Подзапросы, списки и CONNECT BY

    Вместо VIEW и JOIN можно использовать вложенные запросы в списке выборки:

    Производительность

    Для увеличения производительности, вам потребуется создать индексы на таблицу, которые позволят Oracle быстрее получать ответ на вопрос, "кто является детьми некого родителя Х?":

    Oracle Data Integration, Cloud, Spatial and Analytics (GoldenGate, ODI, Cloud, Spatial, Exadata)

    Я уже писал, что Oracle выпустил новую версию своего Fusion Middleware 11g. В будущем – в течение года-полутора будут выходить компоненты, которые будут разворачиваться на базе этой новой версии. Я решил написать небольшую статейку, поскольку знание компонентов потребуется для использования любого из компонентов. В следующих постах я напишу, как инсталлировать и как правильно разворачивать платформу сервера приложений Oracle.

    1. Что такое Middleware?

    Middleware это программное обеспечение, которое соединяет программные компоненты и корпоративные приложения. Middleware это слой, которое выступает посредником между операционной системой и приожением по обе стороны распределенной корпоративной сети. Обычно, middleware поддерживает работу сложный корпоративных бизнес-приложений.

    Middleware включает Web-серверы, сервера приложений, системы по управлению контентом(CMS), а также другие инструменты, предназначенных для разработки и развертывания приложений.

    2. Функции Middleware

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

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

    3. Oracle Fusion Middleware

    Oracle Fusion Middleware это набор основанных на стандартах программных продуктов, которые включают ряд инструментов и сервисов: Java Enterprise Edition 5 (Java EE)-совместимую среду, инструменты для разработки, интграционные сервисы, бизнес аналитику, средства совместной работы, управления контентом. Oracle Fusion Middleware предлагает исчерпывающую поддержку для разработки, развертывания и управления.

    Ниже показаны компоненты Oracle Fusion Middleware

    Более подробную информацию можно посмотреть в документации по Oracle Fusion Middleware.

    Читайте также: