Oracle *

Процесс мышления любого человека с трудом подвергается математизации. Любая бизнес-задача порождает набор формальных и неформальных документов, информация из которых имеет отражение в корпоративном хранилище. Каждая задача, порождающая любой информационный процесс, создает вокруг себя набор документов и логику их обработки, которая мало формализуется в среде корпоративного хранилища. Внутри хранилища данных должны быть структуры для очистки информационного потока. В этом может помочь продукт Oracle Enterprise Data Quality, который призван решать задачи по очистке «грязных» данных. Но этим его применение не ограничивается.

Внутри команды нужно разработать свои стандарты и правила, а оформление документации — это одно из главных правил работы в команде.

Ну, поехали…

Ссылка на сам инструмент pldoc.

По ссылки хорошо все расписано как работать и формировать документацию, но чтобы было проще приведу примеры и скрипты.

Устанавливаем(распаковываем архив) и создаем в корне run.bat

rmdir /s /q "%TOMCAT_HOME%/Tomcat 7.0/webapps/plsqldoc"
call ..\pldoc.bat -verbose -doctitle 'Api shema' -d '%TOMCAT_HOME%/Tomcat 7.0/webapps/plsqldoc' -url jdbc:oracle:thin:@host:port:SID -user API_DOC -password API_DOC -sql SCAPI.%%%%,API.%%%%,SALE.%%%%,BILLING_API.%%%%,BATCH.%%%%,
pause

где:

• -d '%TOMCAT_HOME%/Tomcat 7.0/webapps/plsqldoc' — папка куда будет формировать документация;
• -url jdbc:oracle:thin:@host:port:SID сервер базы данных откуда браться данные;
• -sql API.%%%%T%%%%,SALE.A%%%%,BILLING_API.%%%%
  API.%%%%T%%%% — брать все объекты схемы API содержащие букву Т;
  SALE.A%%%% — брать все объекты схемы SALE начинающиеся на букву A;
  BILLING_API.%%%% — брать все объекты схемы BILLING_API;

Запускаем и получаем готовую документацию, по правилам оформления pl/sql кода описанному ниже.

Добрый день! Мы команда системных аналитиков одного из подразделений управления данными «Ростелекома». В нашей компании насчитывается более 300 неоднородных источников данных — такое многообразие необходимо для поддержки работы Ростелекома по всем многочисленным направлениям. Мы изучаем источники данных и по необходимости частично выгружаем в контур хранилища.


Ровер Curiosity на поверхности. У него тоже много неоднородных источников данных. Картинка позаимствована с therahnuma.com.

В этом процессе выделяется две подзадачи: определение стратегии сбора данных из таблиц источника в зависимости от их свойств и подготовка таблиц-«приемников» хранилища данных. Для этого мы используем различные GUI и средства реверс-инжиниринга. Кроме того, при сборе информации системный аналитик начинает обрастать пулом вспомогательных запросов к информационным таблицам СУБД (преимущественно Oracle). В этой статье я поделюсь «джентльменским набором» таких скриптов, используемых нашей командой.

Что делать, если надо работать с данными, которые по объему еще не Big data, но уже больше того, что умещается в памяти компьютера и для которых достаточно возможностей Excel? Для любителей велосипедостроения ответ очевиден – нужно писать что-то свое (да, мы не ищем легких путей).

Но как быть, если код, написанный тобой в прошлом, ужасен и не дает тебе возможности развивать проект? Отставить в сторонку старые наработки, дать дорогу новому, вечному и светлому (да-да, и тут тоже без вариантов).



Цитата из кф Матрица: “Достаточно одной таблетки, Нео”. Режиссер: братья и сестры Вачовски. 1999. США

В статье опишу использование Spring Data.

Spring Data — дополнительный удобный механизм для взаимодействия с сущностями базы данных, организации их в репозитории, извлечение данных, изменение, в каких то случаях для этого будет достаточно объявить интерфейс и метод в нем, без имплементации.

Содержание:

1. Spring Repository
2. Методы запросов из имени метода
3. Конфигурация и настройка
4. Специальная обработка параметров
5. Пользовательские реализации для репозитория
6. Пользовательский Базовый Репозиторий
7. Методы запросов — Query

В «Ростелекоме», как и в любой крупной компании, имеется корпоративное хранилище данных (ЦХД). Наше ЦХД постоянно разрастается и расширяется, мы строим на нем полезные витрины, отчеты и кубы данных. В какой-то момент мы столкнулись с тем, что некачественные данные мешают нам при построении витрин, получаемые агрегаты не сходятся с агрегатами систем источников и вызывают непонимание бизнеса. Например, данные с Null значениями в внешних ключах (foreign key) не соединяются с данными других таблиц.
Краткая схема ЦХД:



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

Автор статьи – Виктор Варламов(varlamovVp18), OCP.
Оригинал статьи опубликован 07.07.2017.
Отдельное спасибо автору перевода — brutaltag.

В нашей системе подготовки отчетности обычно выполняются сотни длительных запросов, которые вызываются различными событиями. Параметрами запросов служат список клиентов и временной интервал (дневной, недельный, месячный). Из-за неравномерных данных в таблицах один запрос может выдать как одну строку, так и миллион строк, в зависимости от параметров отчета (у разных клиентов — различное количество строк в таблицах фактов). Каждый отчет выполнен в виде пакета с основной функцией, которая принимает входные параметры, проводит дополнительные преобразования, затем открывает статический курсор со связанными переменными и в конце возвращает этот открытый курсор. Параметр БД CURSOR_SHARING выставлен в FORCE.
В такой ситуации приходится сталкиваться с плохой производительностью, как в случае повторного использования плана запроса оптимизатором, так и при полном разборе запроса с параметрами в виде литералов. Связанные переменные могут вызвать неоптимальный план запроса.

И снова добрый вечер!

Запускаем второй поток нашего нового курса «Реляционные СУБД», который мы чуть дотюнили по итогам первого прогона: дополнительные занятия по кластерам MySQL и Postgres, оказался востребованным docker и ещё разные «доработки напильником». Так что ждите открытые уроки (в которые вынесли часть старых тем) и интересные материалы. Сегодня мы покопаемся в техниках Oracle.

Поехали.

Bitmap-индексы Oracle сильно отличаются от стандартных индексов B-дерева. В bitmap-структурах создается двухмерный массив со столбцом для каждой строки в индексируемой таблице. Каждый столбец представляет отдельное значение в bitmap-индексе. Этот двухмерный массив показывает каждое значение индекса, умноженное на количество строк в этой таблице.

Oracle распаковывает bitmap (со скоростью извлечения строки) в буфер данных ОЗУ для быстрого сканирования на предмет совпадения значений. Эти совпадающие значения передаются Oracle в виде списка Row-ID, и значения Row-ID могут напрямую обращаться к необходимой информации.

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

На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.

За прошедшие годы над кодом успело потрудиться несколько поколений программистов, которых регулярно преследовали жесткие дедлайны — и благодаря этому код смог превратиться в настоящий кошмар. Сегодня он состоит из сложных «кусков» кода, отвечающих за логику, управление памятью, переключение контекстов и многое другое; они связаны друг с другом при помощи тысяч различных флагов. Весь код связан между собой загадочным макросом, который невозможно расшифровать, не прибегая к помощи тетради, в которую приходится записывать, чем занимаются релевантные части макроса. В итоге, у разработчика может уйти день или два только на то, чтобы разобраться, чем же в действительности занимается макрос.

Первое, с чем мы сталкиваемся, когда говорим о проактивной оптимизации — не известно, что нужно оптимизировать. «Сделай то, не знаю, что».

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

Основные цели проактивной оптимизации

Основные задачи проактивной оптимизации отличаются от задач реактивной оптимизации и состоят в следующем:

• избавление от узких мест в БД;
• уменьшение потребления ресурсов БД.

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



Если вы работаете с боевыми серверами, то хорошо представляете, что значат инциденты производительности. Нужно всё бросить и быстро решать проблему. ООО РНКО «Платежный центр» работает с многими агентами, и для них очень важно, чтобы таких проблем было как можно меньше. Александр Макаров на HighLoad++ Siberia рассказал, что было сделано, чтобы значительно уменьшить количество инцидентов производительности. На помощь пришла проактивная оптимизация. А почему и как ее производят на боевом сервере, читайте ниже.

Все началось с того, что мы столкнулись с потребностью быстро и правильно формировать структуры EDWEX, JSON, DDL и затем раскатывать их на разных контурах реляционных БД. Под контурами я подразумеваю знакомые всем аббревиатуры — DEV, TST, UAT, PRD.



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

Свершилось! Можно открывать шампанское и закатывать вечеринку — спустя более, чем 7 лет с момента выпуска предыдущего релиза, для скачивания наконец доступна свежайшая Oracle Database 18c XE. Пока только для Linux x64, но версии для других платформ, также как и Docker и Vagrant образы обещают появиться совсем скоро.

• Официальный анонс
• Ссылка на скачивание
• Инструкция по установке и развертыванию
• Информация о лицензировании

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

Новая же, 18-ая версия XE открывает просто небывалый простор для использования данной СУБД, так как в этот раз компания Oracle сменила тактику, и вместо предоставления минимального функционала, включила в эту редакцию практически все самые популярные опции самой дорогой и функциональной редакции Enterprise Edition. Но по-прежнему с ограничениями по используемым ресурсам.

Многократно вычитывая одни и те же данные, встает вопрос оптимизации, данные не меняются или редко меняются, это различные справочники и др. информация, т.е. функция получения данных по ключу — детерминирована. Тут наверно все понимают — нужен Кеш! Зачем всякий раз повторно выполнять поиск данных или вычисление?

Так вот здесь я покажу как делать кеш в Java Spring и поскольку это тесно связанно скорее всего с Базой данных, то и как сделать это в СУБД на примере одной конкретной.

Содержание

• Кеш в Spring
• Кеш в Oracle PL-SQL функции

О настройке доступа к СУБД Oracle, который хранится в файле tnsnames.ora известно каждому, кто работал с этим типом СУБД.

Данные хранятся в файле tnsnames.ora в обычном текстовом виде и легко могут быть изменены с помощью любого текстового редактора. Хорошо если записей в нем не много, а что делать, если в организации сотни баз данных, доступы к которым нужно предоставлять с хостов пользователей различных уровней или с терминальных серверов. А если в один прекрасный момент база переезжает на другой хост, или происходят другие изменения, меняющие параметры доступа к БД, нужно изменить параметры доступа везде.

Решений предложить можно множество, включая редиректы, алиасы и т.п.

Я здесь опишу как установить и настроить единое хранилище для разрешения имен баз данных с помощью Oracle Internet Directory OID, и как обращаться за разрешением имен по LDAP-протоколу. Это гораздо удобнее, чем держать актуальным файл tnsnames.ora в сотни мест.

Привет, Хабр! представляю вашему вниманию перевод статьи «How to use statspack instead of awr in oracle standard edition».

Как использовать STATSPACK вместо AWR в Oracle Standard Edition.

Проблема с отчетами

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

Привет, Хабр!

Меня зовут Маша, я работаю в КРОК. Сегодня я хочу рассказать вам о получении сертификатов Oracle Certified Associate и Oracle Certified Professional.



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

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

Как бы то ни было, есть люди, которым сертификаты нужны. Как для портфолио, так и для себя лично. Под катом я поделюсь впечатлениями от сертификации Oracle по Java: Oracle Certified Associate (1Z0-808) и Oracle Certified Professional (1Z0-809). В мировой практике наличие этих сертификатов является подтверждением определенного уровня квалификации java-разработчика, поэтому многие эту процедуру проходят.

Читая многочисленные статьи на хабре об успешной миграции с Oracle на PostgreSQL у неискушенного читателя может создаться впечатление что PostgreSQL ничем не хуже, а даже лучше Oracle. И выбор очевиден. А Сотни тысяч компаний, которые в итоге платят миллиарды долларов компании Oracle, просто тратят деньги на ветер. Но постараюсь вас разуверить, где-где, а в больших компаниях умеют считать деньги. И их решения отнюдь не ошибочны.

Цель статьи зародить зерно сомнения в душе читателя, который пытается сделать выбор между реляционными БД которые работают в режиме версионника.

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

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

Формулировка задачи: данные поступают на вход с интервалом в 1 секунду в таком формате:

• Название инструмента (код пары USDEUR и пр.),
• Дата и время в формате unix time,
• Open value (цена первой сделки в интервале),
• High value (максимальная цена),
• Low value (минимальная цена),
• Close value (цена последней сделки),
• Volume (громкость, или объём сделки).

Необходимо обеспечить пересчёт и синхронизацию данных в таблицах: 5 сек, 15 сек, 1 мин, 5 мин, 15 мин, и т.д.

Описанный формат хранения данных имеет название OHLC, или OHLCV (Open, High, Low, Close, Volume). Он применяется часто, по нему сразу можно построить график «Японские свечи».


Под катом я описал все варианты, какие смог придумать, как можно прореживать (укрупнять) полученные данные, для анализа, например, зимнего скачка цены биткоина, а по полученным данным вы сразу построите график «Японские свечи» (в MS Excel такой график тоже есть). На картинке выше этот график построен для таймфрейма «1 месяц», для инструмента «bitstampUSD». Белое тело свечи означает рост цены в интервале, чёрное — снижение цены, верхний и нижние фитили означают максимальную и минимальную цены, которые достигались в интервале. Фон — объём сделок. Хорошо видно, что в декабре 2017 цена вплотную приблизилась к отметке 20К.

Решение будет приведено для двух движков БД, для Oracle и MS SQL, что, в некотором роде, даст возможность сравнить их на этой конкретной задаче (обобщать сравнение на другие задачи мы не будем).