Oracle ACE Director,
сооснователь компании Rittman Mead,
Oracle Gold Partner
Источник статьи в оригинале: Oracle Magazine, январь-февраль 2015
http://www.oracle.com/technetwork/issue-archive/2015/15-jan/o15ba-2398995.html
Опция In-Memory добавляет в базу данных Oracle Database поколоночную обработку данных целиком в оперативной памяти, повышая производительность аналитических запросов на больших наборах данных. Эта опция вводит дополнительный формат хранения данных столбцами в оперативной памяти наряду с традиционным, основанным на дисковом хранилище, построчным форматом записи.
Когда для таблицы базы данных, материализованного представления или набора столбцов включается опция In-Memory, Oracle Database автоматически создает в памяти копию данных, синхронизированную с их построчной записью, а затем использует этот новый оптимизированный поколоночный формат данных, чтобы выполнять запросы, связанные с процессами бизнес-аналитики. Поскольку Oracle Database In-Memory не требует никаких изменений на уровне приложений, то при использовании решений Oracle Business Intelligence легко воспользоваться преимуществами Oracle Database In-Memory без какой-либо адаптации существующих отчетов, процедур загрузки или способов хранения данных.
В этой статье мы загрузим в Oracle Database 12c Release 1 (12.1.0.2.0) набор данных BI AIRLINES, который входит в состав последней версии Oracle Business Intelligence Enterprise Edition 11g SampleApp (SampleApp v406 по ссылке oracle.com/technetwork/middleware/bi-foundation/obiee-samples-167534.html). Используя эти данные, мы создадим простой репозиторий и анализ, для которого сохраним план выполнения запроса и время отклика перед тем, как опция Oracle Database In-Memory будет включена. Затем мы подключим Oracle Database In-Memory, загрузим таблицы в память и выполним те же тесты снова, чтобы продемонстрировать, как эта новая опция базы данных значительно повышает производительность таких аналитических запросов.
Если вы хотите самостоятельно выполнить тестовые примеры из этой статьи, вам потребуется загрузить и установить следующее программное обеспечение и настроить сетевое подключение между двумя серверами:
Кроме того, если вы используете Oracle Business Intelligence на платформе UNIX или Linux, вам потребуется окружение клиента Microsoft Windows, чтобы запустить утилиту администрирования Oracle Business Intelligence для создания репозитория BI.
Чтобы читателям не пришлось загружать целиком образ SampleApp v406 VirtualBox ради получения набора данных BI AIRLINES, я выделил этот набор данных из базы даных SampleApp v406 как файл экспорта Oracle Database и сделал доступным для скачивания в заархивированном и сжатом виде по ссылке bit.ly/flights_data.
Размер загружаемого файла — 355 Мб, и чтобы скачать и распаковать его, потребуется около 3,5 Гб свободного места в файловой системе вашего сервера базы данных, а также еще 2,5 Гб места в базе данных для размещения импортированного набора данных.
Чтобы загрузить и установить набор данных SampleApp v406 в вашу Oracle Database 12c Release 1 (12.1.0.2.0), надо выполнить следующие шаги:
tar -zxvf flights_data.dmp.tar.gzВ результате у вас появится файл экспорта базы данных flights_data.dmp.
sqlplus / as sysdba create user flights_data identified by welcome1 quota unlimited on users; grant connect, resource to flights_data; grant select on v_$im_segments to flights_data; exit
imp system/password file=./flights_data.dmp fromuser=BI_AIRLINES touser=FLIGHTS_DATA
sqlplus flights_data/welcome1 select table_name from user_tables;
Примечание: Предыдущие шаги даны в предположении, что база данных Oracle Database 12c Release 1 (12.1.0.2.0) установлена на сервере под управлением Linux.
Ожидается, что читатели этой статьи в достаточной степени знакомы с процессом создания репозитория BI и анализа. Если вам требуется более подробное описание этих действий, обратитесь к Oracle Fusion Middleware Metadata Repository Builder’s Guide для Oracle Business Intelligence Enterprise Edition и Oracle Fusion Middleware User’s Guide для Oracle Business Intelligence Enterprise Edition.
В этом разделе мы опишем, как создать репозиторий BI для тестирования производительности до и после включения Oracle Database In-Memory.
Connection Type: OCI 10g/11g Data Source Name: <<имя вашего TNS сервиса, например, orcl_inmem>> User Name: flights_data Password: welcome1Нажмем Next, чтобы продолжить.
В созданной бизнес-модели откроем логическую таблицу PERFORMANCE и удалим все столбцы, кроме ARRDELAY, DEPDELAY и FLIGHTS. Затем дважды щелкнем на каждом из оставшихся измерений, перейдем на вкладку Aggregation в диалоговом окне Properties и выберем Count в качестве типа агрегации по умолчанию для FLIGHTS, а Avg для ARRDELAY и DEPDELAY. Перетащим бизнес-модель FLIGHTS_DATA целиком на панель Presentation и создадим новую предметную область для отчетов так, чтобы новая физическая база данных, бизнес-модель и предметная область выглядели как на рис. 1.
Рис. 1. Тестовые данные с репозиторием
Сохраните репозиторий командой File -> Save, и если вы работаете с репозиторием онлайн, то проверьте его на целостность перед окончанием сохранения. Если вы работаете с репозиторием оффлайн, с помощью инструмента Fusion Middleware Control в составе Oracle Enterprise Manager загрузите ваш репозиторий на сервер Oracle Business Intelligence и перезапустите ваш экземпляр Business Intelligence, чтобы репозиторий стал доступен пользователям.
Также надо убедиться, что в вашем экземпляре Business Intelligence отключено кэширование запросов. Войдите в Fusion Middleware Control и отключите кэширование, если оно было включено. (Если кэширование не будет отключено, то при повторном запуске тестового отчета сервер Oracle Business Intelligence Server не будет посылать новый физический SQL-запрос к базе данных, а вместо этого возьмет результаты анализа из кэша запросов.) Более подробное руководство по проверке и отключению кэширования запросов читатель найдет в Oracle Fusion Middleware System Administrator’s Guide для Oracle Business Intelligence Enterprise Edition.
Для демонстрации эффекта, которого достигает на наборе данных сжатое поколоночное хранение данных в памяти, мы сначала создадим анализ на данных, которые хранятся в построчном формате на диске.
С помощью веб-браузера откроем стартовую страницу Oracle Business Intelligence по адресу http://[server_name:port]/analytics (например, http://obi11gserver:9704/analytics). Авторизуемся и создадим следующий новый анализ, используя предметную область FLIGHTS_DATA:
OBIEE_GEO_ORIG.AIRPORT is equal to/is in SFO; ORD; LAX; DEN OBIEE_GEO_DEST.TR_STATE_NAME is equal to / is in Florida; Texas
Рис. 2. Тестовый анализ
Обратите внимание, как долго выполняется запрос. В моем экземпляре Oracle Database 12c, с 6 миллионами записей о полетах в главной таблице фактов, результаты запроса отобразились в браузере только через 10 секунд. Этот запрос относится в точности к тому типу запросов, которые могут быть оптимизированы с Oracle Database In-Memory. А именно, с опцией In-Memory можно повысить производительность следующих типов операций над базой данных:
Это в точности такие типы запросов, которые генерируются решениями Oracle Business Intelligence при отображении информации на информационных панелях и в анализах. Теперь посмотрим, что требуется, чтобы включить для наших четырех таблиц обработку в оперативной памяти с помощью Oracle Database In-Memory.
Прежде чем сделать наши четыре таблицы доступными для хранения и обработки в оперативной памяти, вам или вашему администрату базы данных потребуется включить Oracle Database In-Memory, выделив неоходимый объем памяти для поколоночного хранения таблиц из системной глобальной области SGA. При этом вы, возможно, решите увеличить общий объем SGA, чтобы компенсировать количество памяти, выделенное для поколоночного хранения.
Чтобы проверить объем SGA в Oracle Database 12c Release 1 (12.1.0.2.0), увеличить его на 1 Гб и выделить эту дополнительную память для поколоночного хранения, выполним следущие шаги:
sqlplus sys/password@orcl as sysdba
SHOW PARAMETER sga_targetЧтобы увеличить объем SGA, например, с 7056 Мб до 8080 Мб (на 1024 Мб — количество памяти, которое мы отведем для поколоночного хранения таблиц), следующей командой увеличим общий размер SGA_TARGET:
ALTER SYSTEM SET sga_target = 8080M SCOPE = spfile;
ALTER SYSTEM SET inmemory_size = 1024M SCOPE = spfile;
shutdown immediate; startup;База данных перезапустится и отобразит новые размеры статических пулов в SGA, включая область для поколоночного хранения, которую мы только что выделили. Вот пример такого отчета:
SQL> startup ORACLE instance started. Total System Global Area 7398752256 bytes Fixed Size 2941528 bytes Variable Size 1207963048 bytes Database Buffers 5100273664 bytes Redo Buffers 13832192 bytes In-Memory Area 1073741824 bytes Database mounted. Database opened.
Теперь все готово для хранения и анализа в памяти схемы FLIGHTS_DATA.
Для поколоночного хранения в памяти можно выбрать отдельные столбцы из таблицы или материализованного представления, а также, если ваша база данных разбита на разделы, для поколоночного хранения можно выбрать все или некоторые разделы. В нашем примере мы скопируем таблицы в память целиком и установим приоритету загрузки значение HIGH, чтобы копирование выполнялось с максимальной скоростью.
Можно выбрать, оставить ли данные в поколоночном хранилище без сжатия или применить одну из степеней сжатия, оптимизированную по скорости работы либо объему. В нашем примере мы оставим степень сжатия по умолчанию, MEMCOMPRESS FOR QUERY LOW — степень сжатия, наиболее оптимизированная по производительности выполнения запросов.
Чтобы сделать наши таблицы доступными для поколоночного хранения и анализа в памяти с такими настройками, с помощью SQL*Plus выполним следующие шаги:
ALTER TABLE obiee_geo_orig inmemory priority high; ALTER TABLE obiee_geo_dest inmemory priority high; ALTER TABLE unique_carriers inmemory priority high; ALTER TABLE performance inmemory priority high;
SELECT table_name , inmemory , inmemory_priority , inmemory_compression FROM user_tables;
SELECT v.owner , v.segment_name name , v.populate_status status , v.bytes , v.inmemory_size , v.bytes_not_populated missing_bytes FROM v$im_segments v;Обратите внимание, что если вы захотите получить доступ к этому динамическому представлению характеристик от имени пользователя без привилегий SYSDBA, вам потребуется получить доступ на запрос SELECT к представлению V$IM_SEGMENTS, полученный от одного из пользователей с привилегиями SYSDBA, например, от пользователя SYS.
Выполнив последний запрос, мы вероятно увидим, что таблицы меньших размерностей уже загружены в память, а для полной загрузки в память таблицы PERFORMANCE придется подождать около минуты. База данных Oracle Database в дальнейшем будет автоматически загружать эти таблицы в память при каждом своем перезапуске или при первом доступе к таблице (если параметру приоритета загрузки установлено значение NONE).
Теперь вернемся в Oracle Business Intelligence к нашему анализу и заново запустим запрос, исходные данные для которого теперь находятся в памяти в сжатом формате, оптимизированном в сторону скорости выполнения запросов. Результаты будут готовы намного быстрее, чем при первом запуске.
Когда я запустил запрос для данных в памяти, он выполнился приблизительно вдвое быстрее, чем выполнялся до того, как данные были загружены в память. А именно, выполнение заняло 5 секунд против 10 секунд, которые требовались до включения опции Oracle Database In-Memory, и все это без каких-либо изменений в репозитории BI, отчетах или модели данных.
Опция Oracle Database In-Memory размещает ваши наиболее востребованые для отчетов данные в оптимизированном поколоночном хранилище в памяти, которое автоматически синхронизируется с построчным хранилищем данных, и такое поколоночное размещение в памяти может значительно уменьшить время отклика для запросов, генерируемых решениями Oracle Business Intelligence. База данных Oracle Database 12c автоматически управляет поколоночным хранилищем в памяти, получая данные для отчетов, анализов и информационных панелей, не требуя каких-либо изменений в репозитории BI или пользовательских отчетах.