Враження від Oracle OLAP 11g. Частина 2., Oracle, Бази даних, статті

Автор: Андрій Пивоваров


LOCKDFN


Цікава особливість більшості об’єктів, які ви створюєте в AWM. Наприклад, візьмемо опис вимірювання PRODUCT:

>dsc product
DEFINE PRODUCT DIMENSION READONLY LOCKDFN TEXT

Можна побачити слова LOCKDFN і READONLY.


Це означає, що тепер об’єкти, створені в AWM не можна міняти за допомогою DML. Ні структуру, ні вміст. Використовувати на читання можна, змінювати не можна. Більш того, не можна навіть додати нове значення еелементов вимірювання за допомогою команди MAINTAIN.

Зроблено це для того, щоб еталон вимірювань і даних куба лежав у таблицях Oracle, звідки вони завантажуються. Тобто, якщо вам потрібно додати значення виміру – вставляєте це значення в таблицю, а потім вже процесі вимірювання. Я думаю, що це було зроблено ще для того, щоб гарантувати, що дані в кубі і вимірах між завантаженнями не змінювалися і таким чином можна робити інкрементального оновлення, без побоювання, що цифри розійдуться. Ще це потрібно для кубічних Materialized View, про які мова далі.


Здавалося б, це забороняє використання OLAP як движка для обчислень. Що ж робити, якщо ви хочете створити свій об’єкт для обчислень в OLAP?


Створюйте його через DEFINE і робіть, що хочете. LOCKDFN поширюється тільки на об’єкти, створені через AWM.


Теж саме стосується написання формул, програм, використання MODEL, FORECAST і т.д. – Це все можна робити.


Єдина проблема – цей об’єкт не буде видно через SQL, тому що він не в стандартній формі.


Хоча, якщо вам не обов’язково додавати і видаляти елементи вимірювання з DML, це обмеження можна обійти. Робиться це так:


Ви створюєте в AWM куб в стандартній формі, який ріжеться тими ж вимірами, що і ваш “нестандартний” об’єкт. А далі створюєте обчислюваний показник і вставляєте в нього посилання на ваш об’єкт. (Приклад як створити формулу буде в наступному пункті)


Після цього ви можете робити все що завгодно з вмістом вашого об’єкта, і його вміст буде видно через SQL.


Обчислювані показники в OLAP 11g


Як я вже написав, через спрощення стандартної форми, стало можливим легко використовувати можливості OLAP DML для створення власних обчислюваних і збережених показників.


Проте, розробники створили і альтернативний варіант, який з’явився ще в 10g, а в 11g розвинувся.


Обчислення будуються через AWM за допомогою візард на самі різні теми, а візард генерує обчислюваний показник в форматі, що нагадує аналітичні функції Oracle SQL. Загалом, досить зручно.


Наприклад, наростаючий підсумок з продажу з початку текщего року отримає наступну формулу:

SUM(sales) OVER HIERARCHY
(global.time.calendar_year BETWEEN UNBOUNDED PRECEDING
AND CURRENT MEMBER WITHIN ANCESTOR
AT LEVEL global.time.calendar_year)

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


Цю формулу можна змінювати, так що якщо вам щось не подобається, можна поправити або переписати з нуля.


У разі, якщо можливостей візард не вистачає, існує спеціальний пункт – Expression, де можна записати довільне обчислення.


Я задався питанням, як вставити обчислення, реалізоване на DML? Виявилося, це зробити досить легко.


Припустимо, у мене є DML формула, яка вважає внесок продукту в процентах (на будь-якому рівні) в продажу. Виглядає ця формула так:

DEFINE F1 FORMULA NUMBER
<TIME PRODUCT CUSTOMER CHANNEL>
EQ units_cube_sales/units_cube_sales(product “TOTAL_TOTAL”)*100

Насправді, таку формулу легко можна закодувати за допомогою візард, але для нашого прикладу це не важливо. Формула може бути і набагато складніше.


Для того, щоб побачити цю формулу в обчислюваному показнику з ім’ям PROD_PROC, потрібно при його створенні вибрати тип Expression, і в поле значення вписати:

OLAP_DML_EXPRESSION(“F1”,NUMBER)

Все, тепер результат обчислення цієї формули буде видно зовні через SQL як колонка під в’юшки UNITS_CUBE_VIEW.PROD_PROC і результат можна використовувати в своїх програмах.


Приблизно так:

select p.LEVEL_NAME,
p.PARENT,
p.LONG_DESCRIPTION,
sales,
round(PROD_PROC, 2) PROD_PROC
from units_cube_view t, product_primary_view p
where t.CHANNEL = “TOTAL_TOTAL”
and t.CUSTOMER = “TOTAL_TOTAL”
and time = “CALENDAR_YEAR_CY2005”
and p.DIM_KEY = t.PRODUCT
and p.LEVEL_NAME in (“TOTAL”, “CLASS”, “FAMILY”)
order by 2 desc, 5 desc;
LEVEL_NAME PARENT LONG_DESCRIPTION SALES PROD_PROC
———- ———– —————– ———- ———-
TOTAL Total Product 136986571. 100
CLASS TOTAL_TOTAL Hardware 124191336. 90.66
CLASS TOTAL_TOTAL Software/Other 12795235.8 9.34
FAMILY CLASS_SFT Accessories 6213535.02 4.54
FAMILY CLASS_SFT Operating Systems 4766857.28 3.48
FAMILY CLASS_SFT Documentation 1814843.51 1.32
FAMILY CLASS_HRD Desktop PCs 74556527.7 54.43
FAMILY CLASS_HRD Portable PCs 18338224.9 13.39
FAMILY CLASS_HRD CD/DVD 16129496.7 11.77
FAMILY CLASS_HRD Memory 5619218.97 4.1
FAMILY CLASS_HRD Modems/Fax 5575725.89 4.07
FAMILY CLASS_HRD Monitors 3972141.78 2.9

SecureFiles


На рівні Oracle аналітичне простір зберігається в таблиці Oracle c BLOB полями. Власне, все OLAP об’єкти лежать саме в BLOB полях.


Давно відомо, що BLOB поля дозволяють зберігати всередині бази неструктуровані об’єкти, такі як бінарні файли. Зберігання всередині бази дає безліч переваг, пов’язаних з безпекою, єдиним підходом до резервного копіювання і відновлення та т.д.


У BLOB тільки одна проблема – вони набагато повільніше у порівнянні з файлами в файловій системі.


І ось в 11g в Oracle з’явилася нова технологія зберігання, яка називається SecureFiles. Читати що це таке можна в документації, Або, наприклад, тут.


Але якщо в двох словах, то це технологія, яка для всіх додатків працює як звичайний BLOB (не потрібно переписувати код), але по швидкості запису на диск працює швидше, ніж запис у файли файлової системи (Засчет складного кешування та ін), а за швидкістю читання – швидкість порівнянна. Це таке нове покоління LOB, яке, мабуть, їх остаточно замінить. Але поки підтримуються і старий і новий формати.


Плюс, там же є компресія, шифрування і дедуплікація (якщо наприклад в SecureFiles зберігаються листи електронної пошти, то ясно, що багатьом адресатам, що стоять в копії листа, приходять фізично одні й ті ж листи, які просто займають зайве місце дублями. Тим більше, якщо вони з пріаттаченнимі файлами. Дедуплікація дозволяє автоматично не зберігати копії одних і тих же файлів). Але ці можливості до OLAP безпосередньо відносини мало мають.


Мені відразу стало цікаво, чи підтримує OLAP технологію SecureFiles?


Виявилося, що так. Причому, начебто навіть нічого робити не потрібно. Десь в документації написано, що якщо ви створюєте аналітичне простір в 11g, воно відразу буде створено з використанням SecureFiles.


Однак, коли я створював свої куби, вони створювалися із застосуванням старих LOB-ів.


Але спасибі Олександру Риндіну за наводку. Як виявилося, в Oracle 11g існує параметр в init.ora під назвою db_securefile, Який за замовчуванням встановлений в значення PERMITTED. Тобто, він в принципі дозволяє використання SecureFiles, але якщо його явно про це просять. Мабуть, AWM при створенні аналітичного простору цього явно не просить.


Установка параметра в значення “ALWAYS” змушує AWM створити AW з використанням SecureFiles:

ALTER SYSTEM SET db_securefile = “ALWAYS”;

У моєму прикладі після пересозданія AW з SecureFiles швидкість завантаження і агрегації куба збільшилася більш ніж в два рази. Швидкість відгуку також збільшилася, але можливо не так радикально, тому що і до цього всі запити відгукувалися досить спритно. Обсяг, займаний кубом на диску змінився незначно, відсотків на 5. Ймовірно через те, що дані в кубі вже стиснуті.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*