List,
I ran into some difficulties today while applying the 9.2.0.4 patch to a
9.2.0.1 db on RH 8.0, and was curious if anyone else had seen
similar problems.
After installing the 9.2.0.4 sw ( after installing the 2.2.0.18 OUI of course ) , I
started the database via 'startup migrate' and then ran catpatch.sql.
An ORA-3113 would consistently occur when the following statement was
reached in the catmetx.sql script:
create or replace force view sys.ku$_xmlschema_view of sys.ku$_xmlschema_t
with object identifier (owner_name, url) as
select '1','0',
u.user#, u.name, extractvalue(VALUE(s), '/schema/@schemaURL'),
s.sys_nc_oid$,
case when under_path(value(r), '/sys/schemas/PUBLIC') = 1
then 0 else 1 end,
s.getclobval(), -- unstripped
xdb.dbms_xdbutil_int.XMLSchemaStripUsername(XMLTYPE(s.getClobVal()),
u.name) -- stripped
from sys.user$ u, xdb.xdb$schema s, xdb.xdb$resource r
where extractvalue(VALUE(r), '/Resource/XMLRef') = ref(s)
and u.user# = sys_op_rawtonum(extractvalue(VALUE(r),'/Resource/OwnerID'))
AND (SYS_CONTEXT('USERENV','CURRENT_USERID') IN (u.user#, 0) OR
EXISTS ( SELECT * FROM session_roles
WHERE role='SELECT_CATALOG_ROLE' ))
Running this statement from the command line netted the same results.
Querying the dba_registry view didn't reveal anything unusual: XML stuff was in
the 'LOADED' or 'LOADING' state.
Poking around MetaLink a bit revealed the others had at times had different trouble
with XDB, and had resolved them by recreating the XDB schema.
After running catnoqm.sql ( drops the XDB user ), catpatch.sql was again ran, and
everything finished to completion. ( catpatch calls catproc, which eventually calls
catqm.sql, which recreates XDB if needed )
Have any of you experienced similar problems with XDB while patching or upgrading?
Jared
