Skip to Main Content
  • Questions
  • Using Types in Read Only databases results in error when invoked for the first time

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Anusha.

Asked: November 21, 2016 - 5:09 am UTC

Last updated: November 22, 2016 - 1:03 am UTC

Version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

Viewed 1000+ times

You Asked

Following is a query that results in an error -- "ORA-16000: database or pluggable database open for read-only access", when invoked for the 1st time.
But subsequent calls to the query are successful. The query runs successfully as long as its in the SGA, post which the 1st invokation again results in the above error.

Following the query, that gets called as a part of a stored proc.

with max_pub_dates as
(select business_date, max(publication_datetime) max_pubdate
from eqbproduct.version_details
where business_date = pi_business_date
AND upper(VERSION_NAME) LIKE UPPER('%' || LV_VERSION)
and comments = LV_COMMENT
group by BUSINESS_DATE)
select mcap.product_security_id,
mcap.business_date,
mcap.business_date as pro_forma_business_date,
CAST(COLLECT(obj_cur_mcap(mcap.iso_currency_symbol,
mcap.adj_market_cap,
mcap.unadj_market_cap_today,
mcap.initial_mkt_cap,
mcap.sec_idx_eod00d,
mcap.company_full_mkt_cap)) AS
nt_cur_mcap) MCAP
from eqbproduct.security_market_cap mcap, max_pub_dates mpd
where mcap.publication_datetime = mpd.max_pubdate
and mcap.business_date = mpd.business_date
and mcap.product_security_id =
nvl(pi_security_code, mcap.product_security_id)
group by mcap.product_security_id, mcap.business_date;

Type is created as follows:

create TYPE eqbproduct.obj_cur_mcap as object
(
ISO_CURRENCY_SYMBOL VARCHAR2(20),
ADJ_MARKET_CAP NUMBER,
UNADJ_MARKET_CAP_TODAY NUMBER,
INITIAL_MKT_CAP NUMBER,
SEC_IDX_EOD00D NUMBER,
COMPANY_FULL_MKT_CAP NUMBER
)
/

create type eqbproduct.nt_cur_mcap is table of obj_cur_mcap;


These types and procs are created in the primary (read-write database). Using ADG (Active Data Guard) the data is synced to a read only secondary database.
All application queries run out of the secondary database and all are just select statements.
Only the procs that use the "type" objects result in errors ( "ORA-16000: database or pluggable database open for read-only access")when the proc is run on the secondary database (which is read only database).

Please advise.

and Connor said...

Check to see if any object in your read-only database has a status of INVALID. Because if that is the case, then we will attempt to silently recompile/revalidate that object when first accessed. A compilation means attempting to *write* to the database.

So make sure all of your objects are valid.

Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Anusha M, November 21, 2016 - 11:28 am UTC

Thanks for taking the time to look into the question.

None of the objects are in INVALID state.

Also this issue occurs only in procs that you the "type" object. No other proc errors out.

Connor McDonald
November 22, 2016 - 1:01 am UTC

Couple of things to try

1) simple trace

alter system set events '10046 trace name context forever, level 12';

and then run your proc. Look in the trace file for any DML (which will fail)

or for more detail

alter system set events '16000 trace name errorstack level 10';

and then run your proc.

You *may* be hitting a bug - but something is trying to run DML. The tracefile can help locate that, or can be used to raise a support call.

System generated dependencies ?

Rajeshwaran, Jeyabal, November 21, 2016 - 12:46 pm UTC

Team,

Since they have been using COLLECT aggregated functions, could this error may be due to system generated type dependencies ?

demo@ORA12C> create or replace type emp_typ
  2  is object(empno int, ename varchar2(20));
  3  /

Type created.

demo@ORA12C>
demo@ORA12C> create or replace type emp_tab
  2  is table of emp_typ;
  3  /

Type created.

demo@ORA12C>
demo@ORA12C> select name,type
  2  from user_dependencies
  3  where referenced_name ='EMP_TYP';

NAME                                               TYPE
-------------------------------------------------- ------------------
EMP_TAB                                            TYPE

1 row selected.

demo@ORA12C>
demo@ORA12C> column emp_details format a40 trunc
demo@ORA12C> select deptno,cast( collect(emp_typ(empno,ename)) as emp_tab) emp_details
  2  from emp
  3  group by deptno;

    DEPTNO EMP_DETAILS(EMPNO, ENAME)
---------- ----------------------------------------
        10 EMP_TAB(EMP_TYP(7782, 'CLARK'), EMP_TYP(
        20 EMP_TAB(EMP_TYP(7369, 'SMITH'), EMP_TYP(
        30 EMP_TAB(EMP_TYP(7499, 'ALLEN'), EMP_TYP(

3 rows selected.

demo@ORA12C> select name,type
  2  from user_dependencies
  3  where referenced_name ='EMP_TYP';

NAME                                               TYPE
-------------------------------------------------- ------------------
EMP_TAB                                            TYPE
SYSTPr02ssMmSRAmRCaqXMO908w==                      TYPE

2 rows selected.

demo@ORA12C>

Connor McDonald
November 22, 2016 - 1:03 am UTC

nice input and a potential cause.

More to Explore

Multitenant

Need more information on Multitenant? Check out the Multitenant docs for the Oracle Database