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

Oracle BPM предлагает такие механизмы взаимодействия, которые способны поддерживать сложную коммуникационную среду из разнородных приложений и процессов, где, к примеру, параллельно выполняющиеся потоки работ могут свободно «общаться» друг с другом по ходу выполнения. Т.о. можно выстроить цепочку связей из взаимозависимых задач разных процессов, широко применяя т.н. модульный подход. Модульный подход, в свою очередь, позволяет сэкономить массу времени при разработке и сопровождения решений, т.к. модули могут разрабатываться и тестироваться независимо друг от друга и многократно использоваться в разных частях процесса.

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

OCCI (Oracle C++ Call Interface) — достаточно удобная объектно-ориентированная оболочка над OCI (Oracle Call Interface), позволяющая подключаться и работать с СУБД Oracle из C++ практически с той же легкостью, какую обеспечивают интерпретируемые языки программирования вроде Perl. Однако, OCCI имеет и свои недостатки. В частности, числа в Oracle представлены типом Number, обеспечивающим максимальную точность до 38 значащих цифр, но в OCCI нет метода, позволяющего преобразовать этот тип в 64-битное целое число. Есть возможность преобразовывать в обычное целое число (32 бита), в double (число с плавающей точкой, 64 бита) и long double (число с плавающей точкой, 80 бит (по стандарту С)), но не в 64-битное целое.

Вариант с преобразованием в double и последующим преобразованием в long long может устроить многих пользователей, но далеко не всех, так как он обеспечивает только 52-битную точность (хранимая мантисса числа в типе double имеет размер 52 бита) и, как следствие, возможную потерю точности при больших числах. Казалось бы, проблему могло бы решить промежуточное преобразование в long double, но здесь в игру вступает ограничение компилятора от Microsoft — он не поддерживает 80-битные числа с плавающей точкой и воспринимает тип long double аналогом типа double.

В то же время OCI, лежащий в основе OCCI, проводить преобразование из Number в long long умеет. Для этого в нем есть следующая функция:

Я, как и вы, знаю, что Джеймс Гослинг — великий человек, гигант, такой же, как Керниган, Ричи и Страуструп — начал разработку нового языка Oak 24 года назад. Я так же, как и вы, знаю, что активная жизнь нового языка началась 19 лет назад, когда в Интернете появилась его первая официальная версия от Sun Microsystems, и все мировые софтверные разработчики начали приобретать лицензии на Java 1.0. Но я праздную именно 20-летие Java. Возможно, я сентиментален, но для меня Java — это Java, а не какой-нибудь дуб. И для меня важно, что язык Java получил свое настоящее имя именно 20 лет назад. В честь вот этой вот чашечки кофе:

Подождите, подождите. Я же не написал в заголовке «Как обойтись без резервного копирования». Обойтись без резервного копирования нельзя, об этом знает любой первокурсник. А вот навсегда забыть о резервном копировании — это, пожалуй, мечта любого ИТ-менеджера. Но мечта эта до сих пор казалась несбыточной. Потому что даже если на вашем предприятии прекрасно налажено резервное копирование, вы вспомните о нем сразу после большого отказа, и далеко не добрым словом. Вы скажете не что-нибудь вроде «Как же здорово, что у нас каждую ночь работает бэкап», а скорее: «Сколько часов прошло после бэкапа?»

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

Принципы решения

При интеграции корпоративных систем возникает задача управления справочными данными. Для решения этой задачи часто используется Master Data Managment(MDM). MDM — это хранилище, которое содержит “эталонные” справочные данные, так называемые “золотые записи”. Справочники в MDM содержат очищенные полные и непротиворечивые данные.

Часто MDM используется как платформа для централизованного ведения справочников. Ввод и валидация справочных данных производится в MDM, а оттуда они реплицируются в IT-системы. Такой подход имеет несколько проблем

• Создать эталонную модель данных, которая подойдет всем системам не так-то просто.
• Справочные данные становятся оторванными от приложений.
• Репликация данных из MDM часто требует серьезной доработки систем. Для систем “из коробки” такая доработка может быть очень дорогой.

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

В последние годы логический момент для этого, казалось бы, настал. Стоимость оперативной памяти падала, падала, и упала совсем. Еще в начале века казалось, что 256 МБ памяти для сервера — это нормально, и даже много. Сегодня нас не удивишь параметром 256 ГБ оперативной памяти на сервере начального уровня, а с промышленными серверами вообще настал полный коммунизм, любой благородный дон может набрать хоть терабайт оперативной памяти на сервере, если захочет.

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

Не буду вас долго мучить — Oracle BPM может и все это, и многое другое. Бизнес-процесс можно запускать веб-сервисом (синхронным или асинхронным вызовом), посредством использования Java Message Service, при помощи API BPM Process Engine, сообщением электронной почты, наступлением определенного момента времени по таймеру, а также по подписке на определенные события, причем независимо от того, какой интерфейс использует система источника сообщений.

Сегодня я бы хотел поговорить о векторах атак на СУБД Oracle на разных стадиях: как прощупать слабые места базы снаружи, проникнуть и закрепиться внутри плюс как все это дело автоматизировать с помощью специализированного софта. Архитектура и возможности базы данных весьма интересны, занимательных моментов немало, а значит, немало и способов все испортить. Однако не забывай: ломать — не строить, поэтому вся дальнейшая информация предоставлена исключительно с целью выявить недочеты в защищенности тестируемых систем и повысить безопасность.

Традиционно статья написана тезисно. Более подробное содержание можно найти в приложенном внизу статьи видео с записью лекции про триггеры Oracle.

• Общие сведения о триггерах Oracle
• DML triggers
  
  • Псевдозаписи
  • Instead of dml triggers
  • Instead of triggers on Nested Table Columns of Views.
  • Составные DML триггера (compound DML triggers)
    
    • Структура составного триггера
  • Основные правила определения DML триггеров
  • Ограничения DML триггеров
  • Ошибка мутирования таблицы ORA-04091
• Системные триггеры (System triggers)
  
  • Триггеры уровня схемы (schema triggers)
  • Триггеры уровня базы данных (database triggers)
  • Instead of create triggers
  • Атрибуты системных триггеров
  • События срабатывания системных триггеров
• Компиляция триггеров
• Исключения в триггерах
• Порядок выполнения триггеров
• Включение/отключение триггеров
• Права для операций с триггерами
• Словари данных с информацией о триггерах

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

Статья имеет довольно таки тезисный стиль. Более подробное содержание можно найти в приложенном внизу статьи видео с записью лекции по коллекциям Oracle.

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

Таким же образом коллекции используются и в Oracle.

Содержание статьи

• Общие сведения о коллекциях в pl/sql
• Типы коллекций
• Ассоциативный массив
• Varray
• Nested table
• Set operations с nested tables
• Логические операции с коллекциями
• Методы коллекций
  • Delete
  • Trim
  • Extend
  • Exists
  • First и Last
  • Count
  • Limit
  • Prior и Next
• Bulk Collect
• Цикл forall
  
  • Exceptions in forall
• Collection exceptions
• DBMS_SESSION.FREE_UNUSED_USER_MEMORY

Тот, кто несет фонарь, спотыкается чаще,
чем тот, кто идет следом
Жан Поль

Предисловие

В данной статье я хочу рассказать о том, чем я занимаюсь последние 5 лет. Информации скопилось очень много и я попытался изложить её в простой и доступной форме. Схема системы:

Так уж случилось, что с Oracle организация наша работает давно и плотно. Сам я познакомился с Oracle Database ещё во времена 6-ой версии и, с тех пор, какого либо дискомфорта не испытывал. Всё испортили рыночные отношения. С недавних пор, мы начали замечать, что Заказчик гораздо благосклоннее смотрит на наши проекты если в них используются бесплатные СУБД. О портации одного из таких проектов и будет мой рассказ... 

Почему использование HTML в составе SQL-запросов для Interactive Report может быть опасно? Посмотрите на скриншоты! Неострожное использование HTML может повлечь за собой неочевидные на первый взгляд проблемы:



Проблема 1: С точки зрения бизнес-пользователя отфильтрованные строки не содержат слова «default» (это слово содержится внутри HTML-тега)
Проблема 2: При фильтрации по статусу вместо понятного пользователю текста он получает HTML-выражение, которое выглядит для него как абракадабра



Экспорт тоже выглядит ужасно.
Как лучше все поправить?

На конференции OpenWorld 2014 корпорация Oracle объявила о том, что она работает над собственным Node.JS-драйвером для своей базы данных. На прошлой неделе был открыт его исходный код под лицензией Apache 2.0.

Драйвер включает в себя не только стандартные средства для исполнения SQL-запросов и PL/SQL-кода, но и инструменты для прозрачной работы с объектами JavaScript и массивами, продвинутые средства для работы с транзакциями и встроенными в Oracle инструментами масштабирования. Например, можно быстро прервать неудачную транзакцию на событие от сервера о невозможности корректно закончить работу, позволяя Node.js-приложению быстро переключиться на другую базу данных без потери пользовательских данных.

Оптимизатор в Oracle может применять различные способы трансформации запросов для улучшения их производительности. Одним из таких способов является join elimination. В официальной документации Oracle Database SQL Tuning Guide об этом способе сказано достаточно мало, в отличие от других.
Приглашаю читателей под кат, чтобы поговорить об этом способе поподробнее.

Oracle кластер умер, да здравствует кластеризация!

_{Здесь и далее имеется в виду cluster хранения данных, а не Oracle Real Application Custer}

Проблематика

Большим информационным системам свойственно постоянное поступление различной информации, которая накапливается, обсчитывается и архивируется. Мы рассмотрим вариант структурированных данных, хранящихся на сервере RDBMS Oracle и в качестве примера возьмём таблицу, содержащую CDR записи (т.е. записи о вызовах) для абонентов оператора связи.
Данные о звонках поступают хаотично, т.е. не упорядоченно, как вы понимаете, по атрибутам абонентов. Все данные имеют свой жизненный цикл — оперативные, актуальные и архивные. Со временем частота обращений и требования по скорости доступа к данным меняются (т.е. падают). Т.о. записи годичной давности вполне можно хранить на медленных дисках, активные — на дисках с высокой скоростью доступа и без претензий на производительность операций записи, а вот вновь поступающим данным свойственно требование к максимально высокой скорости записи и чтения.

Что делать, если после апгрейда или инсталляции APEX вместо стартовой страницы браузер показывает сообщение об ошибке или пустую белую страницу? В данной статье собраны наиболее частые причины и методы решения подобных проблем.

Предыстория (2008 г.)

По работе часто приходилось разбираться с производительностью серверов БД Oracle. После выхода Oracle 10g задача по мониторингу и диагностике проблем с производительностью значительно упростилась – с помощью истории активных сессий (Active Session History, ASH) стало возможно узнать, что происходило с БД в прошлом, что творится на сервере в данный момент, и даже прогнозировать, что будет происходить с нагрузкой в будущем.

Но, во-первых, процесс миграции на новую версию достаточно длительный, и некоторые заказчики продолжали использовать старые версии. А во-вторых, средства визуализации истории активных сессий от Oracle, которые имелись в наличии:

• Требовали некоторых телодвижений по их установке и настройке – это Oracle Enterprise Manager Console (DB Console) или Oracle Enterprise Manager Grid Control (сейчас Oracle Enterprise Manager Cloud Control). DB Console из моей (и не только) практики требовал для установки применения очень сильных админских заклятий. Также в целях экономии ресурсов не все хотят ставить на сервера БД дополнительные сервисы или разворачивать на своей площадке отдельную инфраструктуру для мониторинга;
• Обладали рядом архитектурных недостатков. К примеру, в случае зависания сервера БД доступ к информации из истории активных сессий посредством Oracle Enterprise Manager Console становился невозможным, и оперативно выяснить, что «что-то пошло не так» (с) было практически нереально;
• Отсутствовала функциональность в части сохранения данных мониторинга и последующего его анализа на своей площадке.

Из сторонних бесплатных средств, похожая функциональность была реализована в утилите ASHMON за авторством Kyle Hailey. Но функционал был только для просмотра, и работала она под одну платформу – Windows.

В общем, после рассмотрения всех доступных на тот момент вариантов, было принято волевое решение собирать свой «велосипед» из подручных материалов.