“Oracle Enterprise Manager includes the Oracle Fusion Middleware component that is affected by this vulnerability. Oracle Enterprise Manager is affected only if the affected Oracle Fusion Middleware version (noted above) is being used. Since a vulnerability affecting Oracle Fusion Middleware versions may affect Oracle Enterprise Manager, Oracle recommends that customers apply the fix for this vulnerability to the Oracle Fusion Middleware component of Oracle Enterprise Manager.”

However, determining the version of each EM Grid technology stack component can be a little tricky as each component has a different way of finding this information. My Oracle Support document 1151602.1 comes to the rescue, showing you the commands used to find the installed version of each of these components:

• WebLogic
• JDeveloper
• Fusion Middleware
• Metadata Services (MDS)

Refer to this document for complete details.

Here’s an example:

SQL> -- create a test table and load it with some rows
SQL> create table EMP
  2  ( id number,
  3    name varchar2(20)
  4  );

Table created.

SQL> declare
  2  begin
  3  for i in 1..500000 loop
  4    insert into emp values (i,'Johnson');
  5  end loop;
  6  end;
  7  /

PL/SQL procedure successfully completed.

SQL> insert into emp values (500001,'Joe');

1 row created.

SQL> commit;

Commit complete.

SQL> -- notice no parenthesis around upper(name)
SQL> create index emp_func_idx on emp upper(name);

Index created.

SQL> -- notice that the resulting index is NOT a function-based index
SQL> select index_type from user_indexes where index_name = 'EMP_FUNC_IDX'; 

INDEX_TYPE
---------------------------
NORMAL

1 row selected.

SQL> drop index emp_func_idx;

Index dropped.

SQL> -- note the extra enclosing parenthesis (in red) are
SQL> -- part of the index definition
SQL> create index emp_func_idx on emp (upper(name)); 

Index created.

SQL> -- now the index is a function-based index
SQL> select index_type from user_indexes where index_name = 'EMP_FUNC_IDX'; 

INDEX_TYPE
---------------------------
FUNCTION-BASED NORMAL

1 row selected.

SQL> -- confirm the functionality of the index by using a function in query
SQL> explain plan for
  2  select * from emp where upper(name) = 'JOE';

Explained.

SQL> @xplan
Plan hash value: 2877811124

--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |  3684 |   133K|   340   (0)| 00:00:05 |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP          |  3684 |   133K|   340   (0)| 00:00:05 |
|*  2 |   INDEX RANGE SCAN          | EMP_FUNC_IDX |  1474 |       |   665   (0)| 00:00:08 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access(UPPER("NAME")='JOE')

SQL> explain plan for
  2  select * from emp where name = 'Joe';

Explained.

SQL> @xplan
Plan hash value: 3956160932

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    14 |   350 |   346   (2)| 00:00:05 |
|*  1 |  TABLE ACCESS FULL| EMP  |    14 |   350 |   346   (2)| 00:00:05 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("NAME"='Joe')

I started by creating a new user, TESTUSR and granted the user the privileges needed to create the view:

SQL> create user testusr identified by secret
  2  default tablespace users
  3  temporary tablespace temp;
User created.
SQL> grant create session to testusr;
Grant succeeded.
SQL> grant create view to testusr;
Grant succeeded.

Next I created a role, R_TESTUSR, and granted SELECT privileges on the table underlying the view (SCOTT.DEPT) to that role:

SQL> create role r_testusr;
Role created.
SQL> grant select on scott.dept to r_testusr;
Grant succeeded.
SQL> grant r_testusr to testusr;
Grant succeeded.

With everything in place, I signed in as the new user, confirmed that I could access the table underlying my view, and then tried to make the view:

SQL> connect testusr/secret
Connected.

SQL> select * from scott.dept;
    DEPTNO DNAME          LOC
---------- -------------- -------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON

4 rows selected.

SQL> create or replace view dept_v as select * from scott.dept;
create or replace view dept_v as select * from scott.dept
                                                     *
ERROR at line 1:
ORA-01031: insufficient privileges

As shown above, even though the user TESTUSR can query the SCOTT.DEPT table using the privileges granted via the R_TESTUSR role, the user cannot create a view on that same table. Granting privileges on the SCOTT.DEPT table directly to TESTUSR (i.e. outside of the role) resolved the issue:

SQL>  connect system/manager
Connected.

SQL> grant select on scott.dept to testusr;
Grant succeeded.
SQL> connect testusr/secret
Connected.
SQL> create or replace view dept_v as select * from scott.dept;
View created

After some searching, I found that this behavior is documented pretty clearly, but this is the first time I’ve bumped into it.

A developer had a need to execute a function in the remote database using the database link. This was the first time that I had run into a situation like this, so I thought I’d share an example of the SQL in case anyone else finds it useful:

SELECT REPMAN.WESTBY.TIMEZONE_ADJ@SD_LINK(REG_CREATED)
FROM SDOV.SERVICECALL@SD_LINK

Where:
- REPMAN is the schema name that owns the Westby PL/SQL package in the remote database.
- WESTBY is the package name that contains the TIMEZONE_ADJ function.
- SD_LINK is the name of the DB link to the remote database.
- REG_CREATED is the name of the column that the function is being applied to.
- SDOV is the schema that owns the SERVICECALL table in the remote database.

You can download the OraSRP utility from the author’s website. The current release is 3.2.2 and is available for Windows, Linux, and Macintosh platforms.

Here’s sample output of a 10046 trace file formatted using the OraSRP utility. This example file contains information for two functionally equivalent SQL statements. The first SQL statement (with the worse response time) uses an OR condition in the WHERE clause, and the second SQL statement replaces that OR condition with a UNION to achieve the same result, only faster.

Compare the output from the two queries in terms of logical and physical I/O, total elapsed response time, execution plans, etc., and you will see that the formatted trace file clearly shows that the version of the SQL statement that uses the UNION in place of the OR has a much better response time, performs far fewer I/Os, and places less overhead on the CPU.

SQL> ALTER TABLE SD_OVO_MSG MOVE TABLESPACE DPIPE_SUMMARY_SEG OVERFLOW TABLESPACE DPIPE_OVERFLOW_SEG;
            *
ERROR at line 1:
ORA-28660: Partitioned Index-Organized table may not be MOVEd as a whole

Checking the error, I found this amusing “action” description:

$ oerr ora 28660
28660, 00000, “Partitioned Index-Organized table may not be MOVEd as a whole”
// *Cause: Attempt to MOVE partitioned IOT as a whole
// *Action: don’t do this. This is not supported

Here’s an example:

SQL> — create a new tablespace
SQL> create tablespace ro_test datafile ‘/u100/oradata/orcl/r0_test01.dbf’ size 10M extent management local;

Tablespace created.

SQL> – create a test table
SQL> create table ro_tab (name varchar2(10)) tablespace ro_test;

SQL> — insert some rows in the test table
SQL> insert into ro_tab values (‘Joe’);

1 row created.

SQL> insert into ro_tab values (‘Martin’);

1 row created.

SQL> insert into ro_tab values (‘Dave’);

1 row created.

SQL> insert into ro_tab values (‘Mike’);

1 row created.

SQL> commit;

Commit complete.

SQL> — make the tablespace read-only
SQL> alter tablespace ro_test read only;

Tablespace altered.

SQL> — confirm that the tablespace is read-only
SQL> select tablespace_name from dba_tablespaces where status = ‘READ ONLY’;

TABLESPACE_NAME
——————————
RO_TEST

SQL> — try to delete from the table, which fails because it is read-only
SQL> delete from ro_tab;
delete from ro_tab
            *
ERROR at line 1:
ORA-00372: file 16 cannot be modified at this time
ORA-01110: data file 16: ‘/u100/oradata/orcl/r0_test01.dbf’

SQL> — try to truncate the table, which fails because it is read-only
SQL> truncate table ro_tab;
truncate table ro_tab
               *
ERROR at line 1:
ORA-00372: file 16 cannot be modified at this time
ORA-01110: data file 16: ‘/u100/oradata/orcl/r0_test01.dbf’

SQL> — try to drop the table, which works!
SQL> drop table ro_tab;

Table dropped.

SQL> — confirm that the tablespace is still read-only
SQL> select tablespace_name from dba_tablespaces where status = ‘READ ONLY’;

TABLESPACE_NAME
——————————
RO_TEST

Why were we able to drop the table even though the tablespace is read only? Because the DROP TABLE command only needs to update the schema metadata in the data dictionary – which is in tables stored in the SYSTEM tablespace, not the read-only RO_TEST tablespace.

This was my first time attending the Hotsos Symposium, and I cannot say enough good things about the experience. The presenters were top-notch and their topics where of exceptional quality and technical depth. If your area of interest or expertise is Oracle performance tuning, then this is the conference you should annually attend. I don’t think I am alone in this belief, as I spoke with several attendees who were covering the cost of the symposium out of their own pockets due to training budget cutbacks at their employers.

While all the presentations were excellent, I particularly enjoyed sessions by Karen Morton, Tanel Poder, Dan Tow, Christian Antognini, Monty Orme, and Jonathan Lewis.