Автор: Андрей Пивоваров
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. Вероятно из за того, что данные в кубе уже сжаты.