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

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


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>

*

*