Now that you mention it, I may have forgotten to drop XMLCONCAT first.
The pool sizes were fine.
I'll try the next upgrade (that I can spend extra time on) without dropping xmlconcat
and see what happens.
Thanks,
Jared
| Stefan Jahnke <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 10/07/2003 01:59 AM
|
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject: AW: 9.2.0.4 patch on linux |
Hi Jared
Did you extend your pool sizes ?
Users who have JVM (Java enabled) or JVM and XDB installed on their Oracle9i release 2 databases should ensure the init.ora parameters SHARED_POOL_SIZE and JAVA_POOL_SIZE are each 150 MB or more before running the catpatch.sql upgrade script.
Did you drop XMLCONCAT before patching ?
Drop the xmlconcat function by running the following commands:
C:\> sqlplus / NOLOG
SQL> connect / AS SYSDBA
SQL> drop public synonym XMLCONCAT;
SQL> drop function XMLCONCAT;
Regards, Stefan
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 6. Oktober 2003 22:39
An: Multiple recipients of list ORACLE-L
Betreff: 9.2.0.4 patch on linux
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
