16 нояб. 2014 г.

Oracle Database 12c: функции с правами вызывающего в представлениях

До Oracle Database 12c, если мы вызываем функцию внутри представления (неважно каким способом: в предикате фразы WHERE, либо в вычисляемом столбце), этот вызов всегда происходит с правами создателя (DEFINER RIGHTS), независимо от того как была определена функция.
Рассмотрим следующий пример.
Предположим, что у нас в Oracle Database 11g есть функция определенная с правами вызывающего:

[oracle@rac1 ~]$ sqlplus rscott/rtiger

SQL*Plus: Release 11.2.0.4.0 Production on Sat Nov 10 13:09:00 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP
and Data Mining options

SQL> CREATE OR REPLACE FUNCTION getClosedAccounts(v_pBranchId IN NUMBER) RETURN VARCHAR2
AUTHID CURRENT_USER IS
  v_xRes NUMBER(9);
BEGIN
  SELECT 
    count(a.rowid)
  INTO
    v_xRes
  FROM
    accounts a
  WHERE
    a.branch_id = v_pBranchId and
    a.Status    = 'CLOSED';

  RETURN v_xRes;
END;
/

Function created.
SQL> 
Вызов этой функции под другим пользователем, как и положено, будет сделан с правами вызывающего:

SQL> grant execute on getClosedAccounts to hr;

Grant succeeded.

SQL> connect hr/hr
Connected.

SQL> select rscott.getClosedAccounts(123) from dual;
select rscott.getClosedAccounts(123) from dual
       *
ERROR at line 1:
ORA-00942: table or view does not exist
ORA-06512: at "RSCOTT.GETCLOSEDACCOUNTS", line 5

SQL> 
Все правильно: вызов произошел с правами вызывающего, а пользователь HR не имеет прав не чтение таблицы accounts. А теперь попробуем вызвать эту же функцию под пользователем HR, но уже внутри представления:


SQL> conn rscott/rtiger
Connected.

SQL>CREATE OR REPLACE VIEW v$Branches_Closed_Accounts AS
   SELECT
     b.Id,
     getClosedAccounts(b.Id) as Closed_Count
   FROM
     branches b;

View created.


SQL> GRANT SELECT ON v$Branches_Closed_Accounts TO hr;

Grant succeeded.

SQL> conn hr/hr
Connected.
SQL> SELECT * FROM rscott.v$Branches_Closed_Accounts;

 ID  CLOSED_COUNT
---  ---------------------------------------------------------------------
  1  0
Функция внутри представления была вызвана без всякой ошибки! До Oracle Database 12c вызов функции внутри представления всегда происходит с правами создателя, даже если функция была определена как с правами вызывающего.

В Oracle Database 12c, в определении представления, указывается фраза BEQUEATH, которая определяет, как будут вызывать PL/SQL-функции используемые в запросе: DEFINER или CURRENT_USER.

Переключимся на Oracle Database 12c и перепишем наше представление по другому, указав что наша функция должна быть вызвана с правами вызывающего:

[oracle@localhost]$ sqlplus rscott/rtiger

SQL*Plus: Release 12.1.0.2.0 Production on Sun Nov 16 20:57:49 2014

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Last Successful login time: Sun Nov 16 2014 20:56:22 +03:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> CREATE OR REPLACE VIEW v$Branches_Closed_Accounts 
  BEQUEATH CURRENT_USER AS
   SELECT
     b.Id,
     getClosedAccounts(b.Id) as Closed_Count
   FROM
     branches b;

View created.

SQL> conn hr/hr
Connected.
SQL> SELECT * FROM rscott.v$Branches_Closed_Accounts;
SELECT * FROM rscott.v$Branches_Closed_Accounts
                       *
ERROR at line 1:
ORA-00942: table or view does not exist
ORA-06512: at "RSCOTT.GETCLOSEDACCOUNTS", line 5
SQL> 
Теперь функция в представлении вызывается с правами вызывающего!

По умолчанию, в Oracle Database 12 представление будет создаваться с неявной фразой BEQUEATH DEFINER, то есть поведение будет как в предыдущих версиях - функции в представлениях будут вызываться с правами создателя.

Важно отметить, что если в определении функции был указан режим вызова с правами создателя, то фраза BEQUEATH CURRENT_USER в представлении игнорируется:

SQL> conn rscott/rtiger
Connected.
SQL> CREATE OR REPLACE FUNCTION getClosedAccounts(v_pBranchId IN NUMBER) RETURN VARCHAR2
AUTHID DEFINER IS
  v_xRes NUMBER(9);
BEGIN
  SELECT 
    count(a.rowid)
  INTO
    v_xRes
  FROM
    accounts a
  WHERE
    a.branch_id = v_pBranchId and
    a.Status    = 'CLOSED';

  RETURN v_xRes;
END;
/

Function created.

SQL> conn hr/hr
Connected.
SQL> SELECT * FROM rscott.v$Branches_Closed_Accounts;

 ID  CLOSED_COUNT
---  ---------------------------------------------------------------------
  1  0

4 нояб. 2014 г.

Oracle JavaVM Component 12.1.0.2.1 Database PSU

Продолжается стабилизация релиза Oracle 12c R1 (12.1.0.2). В октябре, как и положено, вышел первый PatchSet Update (PSU 1).
Вместе с знакомыми нам патчами: для БД (DB PSU) и для Grid Infrastructure (GI PSU) появился новый вид PSU - Oracle JVM Component Database PSU. Этот пакет исправлений содержит исправления ошибок для виртуальной Java-машины работающей внутри БД.
Следует заметить, что перед установкой Oracle JVM Database PSU, на базе данных предварительно уже должен стоять соответствующий Database PSU, в данном случае - Database PSU1.

Таким образом, теперь процедура установки патчей PSU на базу данных выглядит следующим образом:

  • обновляем утилиту OPatch до последней версии - здесь ничего необычного: всегда рекомендовалось скачать ее свежую версию (Patch 6880880);

  • устанавливаем DB PSU - здесь тоже все по старому: в каталоге распакованного архива с патчем запускаем утилиту opatch c параметром apply (это знает любой школьник! :-));


    Рис.1 Установка патча Oracle Database 12.1.0.2 PSU 1

  • затем необходимо обновить словарь, - теперь это делается с помощью утилиты datapatch (никаких catcpu.sql!), эта утилита выполняет все SQL-скрипты, необходимые для корректной установки патча;

    Рис.2 Обновление словаря для DB 12.1.0.2 PSU 1 с помощью команды $O_H/OPatch/datapatch -verbose


  • устанавливаем DB OJVM PSU, - точно также выполняем: opatch apply;

    Рис.3 Установка патча Oracle Database 12.1.0.2 OJVM PSU 1


  • наконец, обновляем словарь для DB OJVM PSU, - точно также выполняем: datapatch -verbose;

    Рис.4 Обновление словаря для DB 12.1.0.2 OJVM PSU 1

    Процедура установки патчей на СУБД Oracle Database 12c претерпела изменения: теперь нам не нужно вручную запускать post-install SQL-скрипты, также следует не забывать об установке нового вида PSU - Database PSU JVM Component.

    P.S. Выпущенный в сентябре большой MLR-патч для Oracle In-Memory (patch 19615705), к сожалению, конфликтует с DB PSU 12.1.0.2.1. В ближайшее время будет выпущен такой же MLR, но для 12.1.0.2.1 (on Top 12.1.0.2.1).
  • 17 окт. 2014 г.

    Oracle 12c: grant roles to PL/SQL units

    В Oracle Database 12c появилась интересная новая возможность: назначать роли непосредственно PL/SQL-объектам.
    Для чего это нужно? Это дает возможность давать доступ к таблицам (вообще к любым объектам БД) только через вызовы PL/SQL-объектов созданных с правами вызывающего.
    Предположим, у нас есть очень секретная таблица с остатками по счетам:
    [oracle@rac1 ~]$  sqlplus rscott/rtiger
    
    SQL*Plus: Release 12.1.0.2.0 Production on Sat Oct 18 05:57:08 2014
    
    Copyright (c) 1982, 2014, Oracle.  All rights reserved.
    
    Last Successful login time: Thu Oct 16 2014 08:26:35 +04:00
    
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
    Advanced Analytics and Real Application Testing options
    
    SQL> CREATE TABLE acc_amounts
      (
        Acc_Id   NUMBER(9),
        Acc_Date DATE,
        Amount   NUMBER(22,2)
      );
    Table created.
    
    SQL> INSERT INTO acc_amounts VALUES(1,trunc(sysdate),100);
    
    1 row created.
    
    SQL> INSERT INTO acc_amounts VALUES(2,trunc(sysdate),200);
    
    1 row created.
    
    SQL> COMMIT;
    
    И есть функция, которая возвращает остаток по счету на определенную дату. Для того, чтобы не давать делать вызов с потенциально более высокими правами создателя (definer right) - владельца объектов БД, функция создана с правами вызывающего (invoker rights):
    SQL> CREATE OR REPLACE FUNCTION getAccAmount(v_pAccId IN NUMBER,
      2                                          v_pAccDate IN DATE) RETURN NUMBER
      3   AUTHID CURRENT_USER IS
      4        v_xRes acc_amounts.Amount%type;
      5      BEGIN
      6        SELECT
      7          Amount
      8        INTO
      9          v_xRes
     10        FROM
     11          rscott.acc_amounts
     12        WHERE
     13          Acc_Date = trunc(v_pAccDate);
     14
     15       RETURN v_xRes;
     16     END;
     17  /
    
    Function created.
    
    SQL>
    Для того, чтобы прикладной пользователь мог вызывать эту функцию, необходимо дать ему права на чтение этой таблицы, иначе возникает ошибка:
     
    SQL> GRANT EXECUTE ON getAccAmount TO user1;
    
    Grant succeeded.
    
    SQL> conn user1/oracle
    Connected.
    
    SQL> SELECT rscott.getAccAmount(1,sysdate) FROM dual;
    select rscott.getAccAmount(1,sysdate) from dual
           *
    ERROR at line 1:
    ORA-00942: table or view does not exist
    ORA-06512: at "RSCOTT.GETACCAMOUNT", line 6
    
    SQL>
    Казалось бы нет проблем: нужно дать права пользователю на чтение этой таблицы. После этого все будет работать:
     
    SQL> conn rscott/rtiger
    Connected.
    SQL> GRANT SELECT ON acc_amounts TO user1;
    
    Grant succeeded.
    
    SQL> conn user1/oracle
    Connected.
    SQL> SELECT rscott.getAccAmount(1,sysdate) FROM dual;
    
    RSCOTT.GETACCAMOUNT(1,SYSDATE)
    ------------------------------
                               100
    SQL>
    Но теперь пользователь имеет полный доступ к таблице, и может посмотреть остаток по любому счету!
     
    SQL> SELECT * FROM rscott.acc_amounts;
    
        ACC_ID ACC_DATE      AMOUNT
    ---------- --------- ----------
             1 17-OCT-14        100
             2 17-OCT-14        200
    SQL>
    В Oracle Database 12c мы можем дать права на чтение таблицы непосредственно самой функции. Теперь пользователь не будет иметь непосредственного доступа к таблице:
     
    SQL> conn rscott/rtiger
    Connected.
    SQL> REVOKE SELECT ON acc_amounts FROM user1;
    
    Revoke succeeded.
    
    SQL> GRANT SELECT ON acc_amounts TO FUNCTION getaccamount;
     GRANT SELECT ON acc_amounts TO FUNCTION getaccamount
    *
    ERROR at line 1:
    ORA-28700: Only roles can be attached to or detached from program units.
    
    REM Дать права PL/SQL-объекту можно только через роль!
    SQL> CREATE ROLE getAccAmount_role;
    
    Role created.
    
    SQL> GRANT SELECT ON acc_amounts TO getAccAmount_role;
    
    Grant succeeded.
    
    SQL> GRANT getAccAmount_role TO FUNCTION getaccamount;
    
    Grant succeeded.
    SQL>
    После этого пользователь успешно может вызывать функцию получения остатка, доступ к которому мы регламентируем через параметры (передавая в вызов функции на стороне приложения текущий идентификатор пользователя). При этом пользователь не имеет прямого доступа к таблице и вынужден использовать наш PL/SQL API:
     
    SQL> conn user1/oracle
    Connected.
    SQL> SELECT * FROM rscott.acc_amounts;
    SELECT * FROM rscott.acc_amounts
                         *
    ERROR at line 1:
    ORA-00942: table or view does not exist
    
    
    SQL> SELECT rscott.getAccAmount(1,sysdate) FROM dual;
    
    RSCOTT.GETACCAMOUNT(1,SYSDATE)
    ------------------------------
                               100
    SQL>
    
    Выдача прав на объекты непосредственно PL/SQL-объектам позволяет повысить защищенность вашего приложения от несанкционированного доступа к конфиденциальным данным. Прекрасно сочетаясь с другой возможностью Oracle 12c - ограничением места вызова PL/SQL-объектов, эта технология позволяет четко регламентировать доступ к данным через прикладной программный интерфейс вашего приложения!

    5 окт. 2014 г.

    Oracle ILM 12 and custom business rules

    В Oracle Database 12c появилась новая и очень мощная технология автоматизации жизненного цикла информации - Automatic Data Optimization. С помощью политик ILM (атрибуты сегмента, задаваемые через команду ALTER TABLE ADD ILM POLICY), мы устанавливаем политики для сжатия и перемещения данных между разными уровнями системы хранения, например: c SSD-дисков на SAS-накопители, и далее на SATA-диски.

    Вообще, базовые технологии для реализации такого автоматического ILM, уже давно были в СУБД Oracle еще до версии 12с: Partitioning, сжатие Advanced Compression и Hybrid Columnar Compression. Не было самого механизма отслеживания и автоматического выполнения политик ILM - приходилось их реализовывать в коде приложения, и в виде собственных скриптов и заданий (job-ов СУБД).
    Наконец, в Oracle Database 12c появилась технология Automatic Data Optimization.

    Уже пара заказчиков задали мне вопрос: а чем, собственно, это отличается от того, что уже давно есть внутри систем хранения?

    Действительно: подобная функциональность уже давно есть в многих массивах. Система хранения, отслеживая статистику обращения к данным, может производить автоматическое их перемещение между разными типами дисковых полок.
    Например, в массивах EMC Symmetrix V-Max есть технология Virtual LUN. Отдельного обсуждения заслуживает тема негибкости и сложности такой реализации ILM: поскольку массив ничего не "знает" про таблицы БД, миграция данных происходит на основе виртуальных разделов, - на каждый такой раздел нужно создавать свою ASM-группу.

    Рис 1. Перещение виртуальных разделов на массивах EMC Symmetrix V-Max

    Есть два важных отличия технологии Automatic Data Optimization от реализации ILM на системе хранения.
    Первое: подобная функциональность есть как правило только в СХД Hi-End класса, и стоит отдельных, довольно значительных денег.
    Второе, и самое важное отличие: в случае автоматизации ILM средствами системы хранения, отсутствует связь с бизнес-правилами, что может привести к ложному срабатыванию политик на СХД.

    Рассмотрим следующий простой случай.
    Мы определили на уровне системы хранения, что для таблицы с заказами, если к данным не было обращения на запись более 5 дней (то есть заказ оплачен, доставлен и закрыт), то к нему не нужен быстрый доступ - нужно переносить их с SSD-полки на другой уровень системы хранения на основе SATA-дисков.
    Все замечательно будет работать до тех пор, пока не появятся заказы, по которым на срок более 5-ти дней была задержана оплата или поставка. Система хранения честно переместит эти данные на SATA-диски. Когда же потребуется произвести изменение заказов при поступлении оплаты, мы получим большое время доступа, поскольку данные уже лежат на медленных дисках!

    В случае использовании технологии Automatic Data Optimization мы можем задать не просто временные рамки, но собственную логику контроля перемещения данных, которая основывается на бизнес-логике приложения. Подобное, никакая система хранения, конечно сделать не сможет.

    Рассмотрим пример.
    Пусть у нас есть таблица заказов, секционированная по годам:
    [oracle@localhost Desktop]$ sqlplus rscott/rtiger
    
    SQL*Plus: Release 12.1.0.2.0 Production on Sun Oct 5 21:45:32 2014
    
    Copyright (c) 1982, 2014, Oracle.  All rights reserved.
    
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
    
    SQL> create table orders
    (
      Id          number(9) generated as identity,
      Customer_id number(9),
      pay_date    date,
      amount      number,
      status      varchar2(15) invisible default on null 'ACTIVE' 
    )
    partition by range (pay_date)
     (
      partition year_old     values less than (to_date('01.01.2001','dd.mm.yyyy')) nocompress,
      partition year_2001    values less than (to_date('01.01.2002','dd.mm.yyyy')) nocompress,
      partition year_2002    values less than (to_date('01.01.2003','dd.mm.yyyy')) nocompress,
      partition year_current values less than (maxvalue)                           nocompress
     )
    tablespace rscott_data;
     
    Table created.
    
    
    Заполним секцию за 2001 год - вставим 1млн записей:
    SQL> begin
      for i in 1..1000000
      loop
        insert into orders(Customer_id,pay_date,amount)
        values(1,to_date('02.01.2001','dd.mm.yyyy'),100);
      end loop;
    
      commit;
    end;
    /
    
    PL/SQL procedure successfully completed.
    
    Секция за 2001 год занимает 40 мегабайт и расположена в табличном пространстве RSCOTT_DATA, которое находится на SAS-дисках:
    SQL> SELECT bytes,tablespace_name FROM user_segments WHERE PARTITION_NAME ='YEAR_2001';
    
         BYTES TABLESPACE_NAME
    ---------- ------------------------------
      41943040 RSCOTT_DATA
    
    Мы хотим определить правило, согласно которому, если в секции все заказы проплачены (поле status = 'PAID'): включать для нее сжатие на уровне строк (OLTP compression). Поскольку мы знаем, что после этого данные в заказе не будут часто меняться.
    После того как все заказы в секции будут закрыты (поле status = 'CLOSED'): переносить секцию в другое табличное пространства RSCOTT_ARCHIVE, расположенное на дисковых полках с SATA-дисками.

    Функция, которую мы будем использовать для проверки ILM-политики, должна иметь строго определенную сигнатуру: входной параметр object_number-номер объекта для которого нужно проверить правило, возвращаемое значение - типа boolean.

    Определим две вспомогательные функции:
    SQL> /**
     * Функция возвращает TRUE, если ВСЕ заказы в секции находятся в определенном состоянии 
     *
     * @param v_pPartitionName - название секции
     * @param v_pStatus        - состояние заказа
     * @return TRUE, если ВСЕ заказы в секции находятся в  состоянии определенном в переменной v_pStatus
     */
    create or replace function getOrdersStatusInPart(v_pPartitionName in varchar2,
                                                     v_pStatus        in varchar2) return boolean is
      v_xCount         number(9);
    begin
      execute immediate
        'select count(rowid) from orders partition (' || v_pPartitionName || ') where status != :v_pStatus'
      into v_xCount
      using
        in v_pStatus;
    
      return (v_xCount=0);
    end;
    /
    
    Function created.
    
    SQL> /**
     * Функция возвращает название секции таблицы orders по Object_Id этой секции
     *
     * @param v_pPartitionObjectId - Object Id секции
     * @return название секции
     */
    create or replace function getPartitionNameById(v_pPartitionObjectId in number) return varchar2 is
      v_xResult user_tab_partitions.partition_name%type;
    begin
      select
        subobject_name
      into
        v_xResult
      from
        user_objects
      where 
        object_id = v_pPartitionObjectId;
    
      return v_xResult;
    end;
    /
    Function created.
    
    Определяем функцию для проверки ILM-политики, которая возвращает TRUE, если все заказы в секции проплачены:
    SQL> create or replace function orders_is_paid(object_number in number) return boolean is
    begin
      return getOrdersStatusInPart(getPartitionNameById(object_number),'PAID');
    end;
    /
    
    Function created.
    
    И, наконец, определим функцию для проверки ILM-политики, которая возвращает TRUE, если все заказы в секции закрыты:
    SQL> create or replace function orders_is_closed(object_number in number) return boolean is
    begin
      return getOrdersStatusInPart(getPartitionNameById(object_number),'CLOSED');
    end;
    /
    
    Function created.
    
    Определяем ILM-политику для сжатия строк, когда все заказы в секции оплачены. За проверку срабатывания ILM-правила отвечает наша функция orders_is_paid:
    SQL> ALTER TABLE orders ILM ADD POLICY
      ROW STORE COMPRESS ADVANCED 
      SEGMENT
      ON orders_is_paid;
    
    Table altered.
    
    Имитируем ситуацию оплаты всех заказов в секции за 2001 год:
    SQL>update orders partition(year_2001) set status='PAID';
    
    1000000 rows updated.
    
    SQL> commit;
    
    Commit complete.
    Автоматическое задание для выполнения ILM-политик выполняется в окне сопровождения (MAINTANCE_WINDOW).
    Для проверки, вызовем его вручную:
    SQL> declare
      v_xExecId number;
    begin
      dbms_ilm.execute_ilm (ilm_scope      => dbms_ilm.scope_schema,
                            execution_mode => dbms_ilm.ilm_execution_offline,
                            task_id        => v_xExecId);
    end;
    /
    
    PL/SQL procedure successfully completed.
    Проверим атрибут сжатия у секций таблицы orders:
    SQL> select compression,compress_for,partition_name,tablespace_name from user_tab_partitions where TABLE_NAME ='ORDERS';
    
    COMPRESS COMPRESS_FOR PARTITION_NAME   TABLESPACE_NAME
    -------- ------------ --------------   ---------------
    DISABLED              YEAR_OLD         RSCOTT_DATA
    ENABLED  ADVANCED     YEAR_2001        RSCOTT_DATA
    DISABLED              YEAR_2002        RSCOTT_DATA
    DISABLED              YEAR_CURRENT     RSCOTT_DATA
    Как видите, наша ILM-политика отработала и для секции заказов за 2001 год включилось OLTP-сжатие! Определяем ILM-политику для переноса секции в табличное пространство расположенное RSCOTT_ARCHIVE на медленном носителе (SATA-диски), если все заказы в секции закрыты. За проверку срабатывания ILM-правила отвечает наша функция orders_is_closed:
    SQL> ALTER TABLE orders ILM ADD POLICY 
      TIER TO rscott_archive ON orders_is_closed;
    
    Table altered.
    
    Имитируем ситуацию закрытия всех заказов в секции за 2001 год:
    SQL> update orders partition(year_2001) set status='CLOSED';
    
    1000000 rows updated.
    
    SQL> commit;
    
    Commit complete.
    Для проверки, снова запускаем задание по выполнению ILM-политик вручную:
    SQL> declare
      v_xExecId number;
    begin
      dbms_ilm.execute_ilm (ilm_scope      => dbms_ilm.scope_schema,
                            execution_mode => dbms_ilm.ilm_execution_offline,
                            task_id        => v_xExecId);
    end;
    Выясним размер секции за 2001 год и табличное пространство в котором оно расположено:
    SQL> SELECT bytes,tablespace_name FROM user_segments WHERE PARTITION_NAME ='YEAR_2001';
    
         BYTES TABLESPACE_NAME
    ---------- ------------------------------
      16777216 RSCOTT_ARCHIVE
    Размер секции уменьшился в два с половиной раза (c 40 мегабайт до 16), и теперь она расположена в табличном пространстве RSCOTT_ARCHIVE!

    Технология Automatic Data Optimization, которая появилась в Oracle Database 12c, позволяет не просто автоматизировать политики ILM, а интегрировать правила их выполнения c бизнес-логикой приложения.
    Это выгодно отличает эту технологию от реализации ILM-политик на уровне системы хранения.

    2 окт. 2014 г.

    Как Ларри Элиссон искал Путина. Записки in-memory скептика

    На OOW очень много говорят об опции database in-memory option. Игорь про нее рассказывал. Она ускоряет работу аналитических приложений без их переписывания. Ускорение достигается за счет многих механизмов - одновременное построчное и поколоночное хранение табличек в памяти, использование векторных команд процессора, новые алгоритмы построения агрегирующих отчетов, прунинг (storage index), преобразование join в набор операций фильтрации колонок, bloom filters и т д.
    На всех выступлениях говорят про ускорение аналитических запросов в 100 раз, а потом показывают слайды, где приложения ускоряются в 1000, 2000, 3000 раз. Как такое может быть? Конечно механизмы понятные и работу Select ускоряют, ну в 2-3 раза, ну в 5-10 раз, но как может быть тысяча, непонятно. Я даже подумал, что это достигается за счет неявного result cache - сначала запрос считался час, а потом результат взяли за секунду - вот и тысячи. Но оказалось все не так

    Прослушал несколько докладов не от Oracle, ребята детально потестировали опцию в разных режимах и вот что получилось

    Взяли таблицы с миллионами записей и написали простой запрос - соединение, условие на выбор диапазона значений и сумма по колонкам
    Тестировали на Exadata. Вначале честно отключили все механизмы ячеек (offload) и In-memory. Были только обычные индексы. Запрос работал 4,5 мин. Потом заставили делать чтение вперед и full buffering, стало работать быстрее, но все равно основное время шло на ввод-вывод
    Потом включили механизмы Exadata - стал работать 2 секунды
    А потом включили еще и In-memory - все выполняется за 0,1 сек. Т е с 4.5 мин до 0.1 сек и без трюков и фокусов (хотя in-memory cache конечно разогрели) Результаты впечатляют

    Теперь про Путина. Ларри демонстрировал как быстро работает запрос с In-memory. Закачали в БД кучу данных об упоминании разных людей в прессе. Миллионы записей. И сделали поисковую системку. Вводишь имя и на экране появляется график кол упоминаний в час для каждого дня года.
    На экране было 2 области - в верхней показывали результат, полученный с in-memory, а в нижней - тот же запрос работал без нее. Результат поиска всегда был одинаков. В верхнем окне график появлялся мгновенно, в нижнем медленно и лениво полз от даты к дате.
    Вначале Ларри поискал инфо по упоминанию Федерера. In-memory отработал мгновенно, потом поискал еще кого-то, результат тот-же. А потом сказал, для тех кто не верит давайте поищем инфо еще о ком-то. И тут из зала ему сказали Путин. Ларри набрал в поисковой строке putin и результат с in-memory опять появился мгновенно, а на нижнем графике он полз, полз, и в конце концов начали искать еще кого-то

    Т е In-memory option действительно работает и действительно драматически ускоряет работу существующих аналитических приложений

    28 сент. 2014 г.

    Oracle Open World 2014. Что сказал Ларри

    Начался новый OOW, как всегда много народа, будет куча презентаций и демонстраций (выбрать сложно)
    Открыл OOW как всегда Ларри (после коротких выступлений маркетинга, Сафры и тетки из Intel)и сказал следующее:
    Сначала долго говорил про наши апсы в публичном облаке Oracle, их там уже сотни и прибавляются все новые, мы переди планеты всей, в день заходят более 40 млн пользователей, все построено на единой облачной платформе, включающей СУБД, WebLogic + Social, Mobility, IDM. Т к Бд содержит Multitennant, In-Memory, надежность, безопасность и т д, то и все приложения это имеют в облаке. Кроме, того, в отличие от конкурентов эти приложения можно развивать используя возможности платформы. Простор для ISV. Короче все потихоньку идет в облако

    Наконец сделали в публ облаке нормальный DBaaS и Web Logic. Я подозреваю, что это вирт машины с СУБД или WL, но во всяком случае это не схема в БД, как раньше, а полноценная БД и сервер приложений. Пользователь может их сам администрировать (будут тулзы) или отдать администрирование в Oracle. При заказе БД можно выбрать разные наборы опций, с стендбаем или без, с RAC (будет позже) Т е есть набор стандартных сервисов с разной ценой
    Ларри много раз повторил, что теперь одной кнопкой можно перенести БД или приложение Java или любое приложение в облако или из облака в свой ЦОД. Где та кнопка я не знаю, может сделают инструмент. Переносить БД и Java можно т к теперь в облаке та же полноценная СУБД и WL что и в ЦОД, а под переносом любых других приложений он понимает IaaS (называется compute service) Т е заказываем вирт машину из шаблона, а в нее ставим что хотим

    Анонсы Ларри оставил на закуску

    Запускается ZDLRA - Zero data loss and recovery appliance - устройство для бэкапирования и восст БД. В отличие от других средств он не файлы бэкапит, а знает структуру БД.На самом деле используется тот же механизм, что и для Standby - передаются только Redo entry и копятся на этом appliance в ячейках Exadata. В любой момент можно попросить бэкап на любой момент времени в прошлом и Appliance его реконструирует из копии Бд и этих redo. Один appliance для бэкапирования всех БД организации. Трафик минимальный, восстановления на произвольный момент (а не на прошлый бэкап как сейчас)

    В Exalitics поставили БД 12С с inmemory

    Главное - в след году выйдут процы М7 с встроенными в железо (силикон) командами БД Соответств енно производительность БД опять взлетит. 12с будет поддерживать. В М7 зашиты команды для ускорения работы СУБД (какие не ясно, но как минимум работа по сканированию колонок in-memory), декомпресия сжатых данных, безопасность Впервые в мире на уровне железа будут проверять доступ к областям памяти. Если это не память этого приложения, то туда не пустят, не дадут испортить данные или их считать Ларри показал select count(*) с несколькими условиями и сказал, что он весь будет выполняться на процессоре

    Да, еще запускают какую то стойку SAN с SSD дисками. Называется FS1 Дешевле и быстрее, чем EMC

    Ну вот, то что вспомнил, остальное см прессрелизы (еще BI для Hadoop будет, BI в облаке, улучшения в RAT, In-memory adviser и т д и т п)

    The same code for Oracle 11g and 12c

    В настоящий момент некоторые компании-разработчики объявили о поддержке Oracle Database 12c в своих приложениях.
    Мне довелось принять участие в конференции, посвященной этой грядущей поддержке в решениях компании ЦФТ: Миграция банковских комплексов ЦФТ на СУБД Oracle 12с.

    В ходе последующего общения с разработчиками ЦФТ возник вопрос о сложности сопровождения кода в промежуточный период: когда будет необходимо поддерживать одновременно и Oracle 11g и Oracle 12c.

    В решении этой задачи, на мой взгляд, может помочь условная компиляция PL/SQL. C помощью определенных в стандартном встроенном PL/SQL-пакете DBMS_DB_VERSION символов условной компиляции (логических констант), мы можем указывать части кода которые будут работоспособны только в Oracle 12c.
    В этом пакете есть логическая константа VER_LE_11_2, истинное значение которой указывает на то, что компиляция кода производится в версии не более чем Oracle 11g Release 2.

    Рассмотрим в качестве примера одну из новых технологий Oracle 12c - возможность определять UDF-функции, и тем самым значительно снижать затраты на переключение контекста в SQL-запросах.
    Идея очень проста: директиву компиляции UDF мы обрамляем в символ условной компиляции.
    CREATE OR REPLACE FUNCTION inc_amount(v_pValue in number) RETURN number is
      $if not dbms_db_version.ver_le_11_2 $then
    PRAGMA UDF;
      $end
      v_xValue number(9);
    BEGIN
      v_xValue := v_pValue;
      
      return v_xValue+10;
    END;
    
    Далее, в момент компиляции этого кода, исходный текст будет препроцессирован. Если текущая версия БД - Oracle 12c, в код, который в итоге будет скомпилирован, попадет UDF-прагма PL/SQL-компилятора. Если БД имеет версии ниже, чем Oracle 12c - перед компиляцией, из исходного текста будет удалена строка с определением прагмы.

    Важно отметить, что нам не нужно обрабатывать версию СУБД на уровне патчера нашего приложения и проводить собственный препроцессинг: компиляция этого кода на обеих версиях БД проходит без ошибок.
    Компилируем код в Oracle 11.2:
    -bash-4.1$ sqlplus scott/tiger
    
    SQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 28 20:06:36 2014
    
    Copyright (c) 1982, 2013, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning and Real Application Testing options
    
    SQL> CREATE OR REPLACE FUNCTION inc_amount(v_pValue in number) RETURN number is
      $if not dbms_db_version.ver_le_11_2 $then
        PRAGMA UDF;
      $end
      v_xValue number(9);
    BEGIN
      v_xValue := v_pValue;
      
      return v_xValue+10;
    END;
    /
    
    Function created.
    
    SQL> 
    
    Теперь тот же самый код компилируем в Oracle 12c R1:
    [oracle@localhost Desktop]$ sqlplus scott/tiger
    
    SQL*Plus: Release 12.1.0.2.0 Production on Sun Sep 28 20:10:13 2014
    
    Copyright (c) 1982, 2014, Oracle.  All rights reserved.
    
    Last Successful login time: Sun Sep 28 2014 19:35:23 +04:00
    
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
    
    SQL> CREATE OR REPLACE FUNCTION inc_amount(v_pValue in number) RETURN number is
      $if not dbms_db_version.ver_le_11_2 $then
        PRAGMA UDF;
      $end
      v_xValue number(9);
    BEGIN
      v_xValue := v_pValue;
      
      return v_xValue+10;
    END;
    /
    
    Function created.
    
    SQL> 
    
    Таким образом, мы имеем единую версию исходных текстов нашего приложения, который работоспособен сразу в нескольких версиях СУБД, получая преимущества от использования новых версий!

    18 сент. 2014 г.

    Материалы семинара "Новые возможности Oracle Database 12с для обеспечения высокой доступности"

    Материалы семинара "Новые возможности Oracle Database 12с для обеспечения высокой доступности", который прошел сегодня 18 сентября 2014 года в Санкт-Петербурге можно скачать по этой ссылке (архив zip, 5Mb).

    Архив включает в себя все презентации и описание демонстрации технологии Application Continuity, включая исходный код демонстрационного приложения.

    11 сент. 2014 г.

    "Новые возможности Oracle Database 12с для обеспечения высокой доступности: - Санкт-Петербург 18 сентября 2014 года





    Компания Oracle совместно со своим партнером компанией COMPAREX приглашают Вас посетить БЕСПЛАТНУЮ конференцию: «Новые возможности Oracle Database 12с для обеспечения высокой доступности».Вы узнаете о последних достижениях компании Oracle в области СУБД Oracle 12c. Презентации будут сопровождаться демонстрациями технологий Oracle.

    Мероприятие пройдет 18 сентября 2014 года, г. Санкт-Петербург, с 10:00 до 15:30
    Мероприятие будет интересно: администраторам баз данных, техническим специалистам.





    Программа семинара:
    Время
    Тема выступления
    10:00 – 10:30
         Регистрация, приветственный кофе
    10:30 – 11:15
    ·        Увеличие производительности и масштабируемости системы благодаря технология Flex RAC для построения кластера. Новая архитектура Oracle RAC 12c: Flex Cluster, Flex ASM.
    11:15 – 12:00
    ·        Решение проблем сбоя БД во время транзакции при помощи Transaction Guard и Application Continuity
    12:00 – 13:00
         Ланч
    13:00 – 13:45
    ·        Global Data Services. Технология «Данные как сервис» в новой версии СУБД.
    13:45 – 14:30
    ·        Обзор технологии Active Data Guard 12с для разгрузки первого сервера от работы с отчетами.
    14:30 – 15:30
    ·        Сессия вопросов и ответов. Кулуарное общение.

    Участие в семинаре бесплатное.
    Регистрация на мероприятие является обязательной!
    Количество мест ограничено!

    27 авг. 2014 г.

    Материалы семинара "Особенности обновления СУБД на Oracle Database 12c"

    Материалы семинара "Особенности обновления СУБД на Oracle Database 12c".

    Общий архив с всеми презентациями: ссылка (zip-архив, 15Mb).

    Презентации по отдельности:

    Подготовка к переходу на Oracle Database 12c и обновление
    Игорь Мельников, Ведущий консультант, Oracle

    Переход на Oracle Database 12c с помощью Full Transportable Database и другие способы обновления. Переход в контейнерную архитектуру Oracle Database 12c
    Борис Пищик, Старший консультант, Oracle

    Образовательные программы от Oracle University
    Анна Гуляева,Менеджер по продажам обучения, Oracle

    Особенности Oracle Database 12c: новые процессы, параметры, утилиты и т.д.
    Андрей Забелин, Ведущий консультант, Oracle

    Настройка производительности в Oracle Database 12c: управление планами SQL-запросов, изменения в оптимизаторе и т.д.
    Борис Пищик, Старший консультант, Oracle

    Лучшие практики по переходу на Oracle Database 12c
    Андрей Забелин, Ведущий консультант, Oracle

    23 авг. 2014 г.

    Cеминар "Особенности обновления СУБД на Oracle Database 12c" - 28 августа

    Поскольку в ближайший год у заказчиков встанет задача обновления БД до версии Oracle Database 12c, мы решили провести семинар посвященный этой теме.
    Это мероприятие состоится 28 августа 2014 года в офисе Oracle.

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

    Ссылка на регистрацию

    Программа семинара:
    10:00 - 11:00 Регистрация участников, утренний кофе
     
    11:00 - 11:45 Подготовка к переходу на Oracle Database 12c
    Игорь Мельников, Ведущий консультант, Oracle
     
    11:45 - 12:30 Обновление с помощью Oracle Database Upgrade Assistant
    Игорь Мельников, Ведущий консультант, Oracle
     
    12:30 - 12:45 Перерыв
     
    12:45 - 13:30 Переход на Oracle Database 12c с помощью Full Transportable Database и другие способы обновления
    Борис Пищик, Старший консультант, Oracle
     
    13:30 - 14:10 Обед
     
    14:10 - 14:20 Образовательные программы от Oracle University
    Анна Гуляева,Менеджер по продажам обучения, Oracle
     
    14:20 - 15:10 Особенности Oracle Database 12c: новые процессы, параметры, утилиты и т.д.
    Борис Пищик, Старший консультант, Oracle
     
    15:10 - 15:45 Настройка производительности в Oracle Database 12c: управление планами SQL-запросов, изменения в оптимизаторе и т.д.
    Андрей Забелин, Ведущий консультант, Oracle
     
    15:45 - 16:00 Перерыв
     
    16:00 - 17:15 Лучшие практики по переходу на Oracle Database 12c
    Андрей Забелин, Ведущий консультант, Oracle
    

    Oracle Database 11.2 - Premier Support end after 5 month!

    Да-да: через 5 месяцев (в январе следующего года заканчивается Premier Support СУБД Oracle Database 11g Release 2!
    Для заказчиков использующих Oracle Database 11.2.0.4, первый год Extended-поддержки не потребует дополнительных затрат, - то есть ее стоимость не возрастет как обычно на 20%.

    Более подробную информацию об этом, и почему не стоит ждать выходе второго релиза Oracle Database 12с (12.2) - в блоге Майка Дитриха.

    Как Вы знаете, месяц назад вышел первый патчсет к Oracle Database 12c R1 - 12.1.0.2, который помимо устранения ошибок и недочетов, также привносит много новых возможностей, прежде всего технологию Oracle Database In-Memory. Об этой технологии мы подробно недавно рассказывали на нашем семинаре "Oracle Database In-memory" - новая технология обработки в памяти

    10 авг. 2014 г.

    Семинар "Oracle Database In-memory" - новая технология обработки в памяти (14 августа)

    ORACLE SUMMER TECH DAYS: НОВАЯ ТЕХНОЛОГИЯ ОБРАБОТКИ ДАННЫХ В ПАМЯТИ СУБД ORACLE DATABASE

    В настоящий момент резкое увеличение объема оперативной (Random Access Memory - RAM) памяти у аппаратных серверов стало реальностью. Развитие аппаратного обеспечения привело к тому, что даже сервер начального уровня может иметь на борту 1 Тб и более RAM.
    Вместе с тем, традиционная архитектура промышленного ПО (прежде всего СУБД), в плане принципов работы с памятью, остались прежними – память используется только для кэширования. Основной проблемой традиционных СУБД является увеличение накладных расходов на сопровождение буферного КЭШа больших объемов.

    Ответом на эти вызовы явилась технология вычислений в памяти – In-Memory Computing. Технология In-Memory Computing рассматривает память не просто как область для КЭШа, а включает в себя специализированные алгоритмы обработки данных в памяти.

    Oracle Database In-Memory является опцией базы данных Oracle и позволяет увеличить в десятки и сотни раз производительность аналитических запросов в приложениях бизнес-анализа и в приложениях смешанного типа. За счет отказа от индексов, которые ранее были необходимы для аналитических запросов, также возрастает скорость выполнения транзакций в приложениях смешанного типа (mixed applications).

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

    Участие в семинаре – бесплатное при условии предварительной регистрации и получения подтверждения от организаторов.

    Ссылка на регистрацию

    Программа:
    14 августа 2014 года
    10:00 – 11:00 Регистрация участников, утренний кофе 11:00 – 11:30 Введение в In-Memory Option Игорь Мельников, Ведущий консультант, Oracle СНГ 11:30 – 12:00 Особенности использования In-Memory Option Игорь Мельников, Ведущий консультант, Oracle СНГ 12:00 – 12:30 Демонстрация Игорь Мельников, Ведущий консультант, Oracle СНГ 12:30 – 13:00 Мониторинг использования In-Memory Option с помощью Oracle Enterprise Manager Cloud Control 12c Андрей Забелин, Ведущий консультант, Oracle СНГ 13:00 – 13:40 Обед 13:40 – 15:10 Новые технологии управления буферным КЭШем: Automatic Big Table Cache и Full Database Cache Mode Борис Пищик, Старший консультант, Oracle СНГ 15:10 – 15:25 Демонстрация Борис Пищик, Старший консультант, Oracle СНГ

    27 июн. 2014 г.

    Материалы семинара "Oracle Multitenant Option"

    По нижеприведенным ссылкам Вы можете скачать материалы семинара "Oracle Multitenant Option" который был посвящен практическим аспектам консолидации БД с помощью этой технологии.
    Данный семинар проходил в офисе Oracle 29 мая и 26 июня 2014 года.

    Практические аспекты консолидации БД с использованием Multitenant Option
    Особенности работы технологий СУБД Oracle в Multitenant-среде
    Oracle Dataguard & Мultitenant

    18 июн. 2014 г.

    Markhot и Edition Base Redefinition

    Для снижения конкуренции (событие ожидания "library cache: mutex X") за объекты в библиотечном кэше предназначена процедура MARKHOT системного пакета DBMS_SHARED_POOL. Данная процедура производит размножение (создает копии) указанного объекта (пакета, процедуры, курсора и т.д.) в библиотечном кэше, и тем самым снижает конкуренцию за мьютексы.

    Недавно, общаясь с одним очень крупным заказчиком, высоконагруженные БД которого работают на больших Hi-End серверах, была затронута тема использования технологии Edition Base Redefinition для безостановочного обновления приложений. Этот заказчик очень активно использует процедуру MARKHOT в своих БД.
    Основной вопрос, который волновал заказчика, заключался в поддержке процедурой MARKHOT технологии Edition Base Redefiniton: работает ли вышеописанное размножение объектов в кэше для разных версий (editions) объекта?
    В явном виде в процедуре MARKHOT не фигурирует версия объекта (edition в которой он был определен). Давайте разберемся в этом вопросе. Поскольку в данный момент заказчик использует Oracle Database 11.2.0.3, проверим именно на этой версии СУБД.

    Создадим отдельного пользователя и новую версию (edition), выдав права на использование этой версии и включив потенциальную версионируемость в вновь созданной схеме:
    [oracle@localhost ~]$ sqlplus / as sysdba
    
    SQL*Plus: Release 11.2.0.3.0 Production on Wed Jun 18 10:58:48 2014
    
    Copyright (c) 1982, 2011, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    With the Partitioning, Automatic Storage Management, OLAP, Data Mining
    and Real Application Testing options
    
    rem Coздаем пользователя
    SQL> CREATE USER test_markhot 
      2    IDENTIFIED BY oracle;
    
    User created.
    
    SQL> GRANT connect, resource TO test_markhot;
    
    Grant succeeded.
    
    rem Coздаем новую версию (edition), которая наследуется от ORA$BASE
    SQL> CREATE EDITION version_2 AS CHILD OF ora$base;
    
    Edition created.
    
    rem Даем права пользователю на использование версии (edition)
    SQL> GRANT USE ON EDITION version_2 TO test_markhot;
    
    Grant succeeded.
    
    rem Включаем для созданной схемы потенциальную версионируемость
    SQL> ALTER USER test_markhot ENABLE EDITIONS;
    
    User altered.
    
    Далее подключимся к БД под вновь созданным пользователем test_markhot и создадим две версии одной и той же процедуры: в версиях ORA$BASE и version_2 соответственно.
    SQL> conn test_markhot/oracle
    Connected.
    
    rem Проверяем версию, в которую мы вошли (должна быть по умолчанию - ORA$BASE)
    SQL> show edition
    
    EDITION
    ------------------------------
    ORA$BASE
    SQL> 
    SQL> create or replace procedure myproc is
      k simple_integer := 0;
    begin
      k := 1;
    end;
     /
    
    Procedure created.
    
    rem Переключаемся в версию VERSION_2
    SQL> ALTER SESSION SET EDITION=version_2;
    
    Session altered.
    SQL> show edition
    EDITION
    ------------------------------
    VERSION_2
    
    rem Создадим новую версию нашей процедуры myproc
    SQL> create or replace procedure myproc is
      k simple_integer := 0;
    begin
      k := 2;
    end;
     /
    Procedure created.
    
    Далее, для удобства откроем отдельную сессию под пользователем SYS, и проверим наличие нашей процедуры MYPROC в библиотечном кэше помеченной как "горячий" объект, то есть для которой был выполнен вызов DBMS_SHARED_POOL.MARKHOT:
    [oracle@localhost ~]$ sqlplus / as sysdba
    
    SQL*Plus: Release 11.2.0.3.0 Production on Wed Jun 18 12:25:50 2014
    
    Copyright (c) 1982, 2011, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    With the Partitioning, Automatic Storage Management, OLAP, Data Mining
    and Real Application Testing options
    
    SQL> SELECT 
      kglnaown, 
      kglnaobj, 
      kglhdnsp, 
      kglnahsh,
      kglhdadr, 
      kglhdobj, 
      kglobprop,
    decode(bitand(KGLHDFLG, 1024), 1024, 'ROOT',
           decode(bitand(KGLHDFLG, 33554432), 33554432, 'COPY', null)) typhot
    FROM 
      x$kglob
    WHERE 
      (bitand(KGLHDFLG, 1024) = 1024 or bitand(KGLHDFLG, 33554432) = 33554432) and 
      kglnaobj='MYPROC';
    
    no rows selected
    
    SQL> 
    
    Все верно: поскольку мы еще не вызывали процедуру MARKHOT, - процедуры MYPROC в списке "горячих" нет. Для удобства сохраним вышеприведенный запрос в файле hotlist.sql
    Находясь под пользователем SYS в версии ORA$BASE пометим нашу нашу процедуру как горячую:
    SQL> show edition
    
    EDITION
    ------------------------------
    ORA$BASE
    
    SQL> EXEC dbms_shared_pool.markhot('TEST_MARKHOT','MYPROC',1);
    
    PL/SQL procedure successfully completed.
    
    
    SQL @hotlist.sql
    KGLNAOWN       KGLNAOBJ               KGLHDNSP   KGLNAHSH KGLHDADR         KGLHDOBJ         KGLOBPROP  TYPH
    -------------- -------------------- ---------- ---------- ---------------- ---------------- ---------- ----
    TEST_MARKHOT   MYPROC                        1 3513693258 0000000085E5F538 00               HOT        ROOT
    
    
    Как Вы видите, - наша процедура MYPROC была помечена как горячая. При этом вызов dbms_shared_pool.markhot создал handler на процедуру MYPROC в библиотечном кэше.
    Попробуем выполнить процедуру MYPROC в версии ORA$BASE (под владельцем - пользователем test_markhot):
    SQL> ALTER SESSION SET edition=ora$base;
    
    Session altered.
    
    SQL> show edition
    
    EDITION
    ------------------------------
    ORA$BASE
    
    SQL> EXEC myproc
    
    PL/SQL procedure successfully completed.
    
    SQL> 
    и проверим содержимое библиотечного кэша (в другой сессии конечно, - под пользователем SYS):
    SQL> @hotlist
    KGLNAOWN       KGLNAOBJ               KGLHDNSP   KGLNAHSH KGLHDADR         KGLHDOBJ         KGLOBPROP  TYPH
    -------------- -------------------- ---------- ---------- ---------------- ---------------- ---------- ----
    TEST_MARKHOT   MYPROC                        1 3513693258 0000000085E5F538 00               HOT        ROOT
    TEST_MARKHOT   MYPROC                        1 4205431051 0000000085E27C58 00000000853780B0 HOTCOPY1   COPY
    
    Пока все работает штатно: в кэше были создана копия нашей процедуры. Теперь собственно самая главная часть нашего эксперимента: пометим нашу процедуру как горячую в версии VERSION_2 и проверим содержимое library cache.
    SQL> ALTER SESSION SET edition=version_2;
    
    Session altered.
    
    SQL> EXEC dbms_shared_pool.markhot('TEST_MARKHOT','MYPROC',1);
    
    PL/SQL procedure successfully completed.
    
    SQL> @hotlist
    
    KGLNAOWN       KGLNAOBJ               KGLHDNSP   KGLNAHSH KGLHDADR         KGLHDOBJ         KGLOBPROP  TYPH
    -------------- -------------------- ---------- ---------- ---------------- ---------------- ---------- ----
    TEST_MARKHOT   MYPROC                        1 3513693258 0000000085E5F538 00               HOT        ROOT
    TEST_MARKHOT   MYPROC                        1 2382213173 0000000085E20EA0 00               HOT        ROOT
    TEST_MARKHOT   MYPROC                        1 4205431051 0000000085E27C58 00000000853780B0 HOTCOPY1   COPY
    
    В кэше появился новый объект помеченный как "горячий"! Вызовем нашу процедуру myproc в версии VERSION_2:
    SQL> ALTER SESSION SET edition=version_2;
    
    Session altered.
    
    SQL> EXEC myproc;
    
    PL/SQL procedure successfully completed.
    
    и еще раз проверим содержимое library cache:
    SQL> @hotlist
    KGLNAOWN       KGLNAOBJ               KGLHDNSP   KGLNAHSH KGLHDADR         KGLHDOBJ         KGLOBPROP  TYPH
    -------------- -------------------- ---------- ---------- ---------------- ---------------- ---------- ----
    TEST_MARKHOT   MYPROC                        1 1543374076 0000000085E1FB68 00000000876D80B0 HOTCOPY1   COPY
    TEST_MARKHOT   MYPROC                        1 3513693258 0000000085E5F538 00               HOT        ROOT
    TEST_MARKHOT   MYPROC                        1 2382213173 0000000085E20EA0 00               HOT        ROOT
    TEST_MARKHOT   MYPROC                        1 4205431051 0000000085E27C58 00000000853780B0 HOTCOPY1   COPY
    
    Теперь в кэше началось размножение процедуры myproc новой версии!

    Процедура dbms_shared_pool.markhot, которая предназначена для установки метки на горячие объекты в library cache, полностью учитывает версии объектов и ее можно совместно использовать с технологией обновления приложений на лету - Edition Base Redefinition!

    Хочу выразить большую благодарность Сергею Томину за помощь в подготовке этого примера!