Thanks Bruce 
The initjvmaux.sql was the key to the cleanup and increasing the 
Java_shared_pool to 50M got it going properly

The metalink notes that I had read suggested 30 so I had 35MB


Cheers


--
=================================================
Peter McLarty               E-mail: [EMAIL PROTECTED]
Technical Consultant        WWW: http://www.mincom.com
APAC Technical Services     Phone: +61 (0)7 3303 3461
Brisbane,  Australia        Mobile: +61 (0)402 094 238
                            Facsimile: +61 (0)7 3303 3048
=================================================
A great pleasure in life is doing what people say you cannot do.

    - Walter Bagehot (1826-1877 British Economist)
=================================================
Mincom "The People, The Experience, The Vision"

=================================================







"Reardon, Bruce (CALBBAY)" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
17-04-2002 02:48 PM
Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
        cc: 
        Fax to: 
        Subject:        RE: initjvm and rmjvm failing


Peter,

On NT 817 I haven't succeeded in getting JVM to deinstall cleanly and have 
had to end up rebuilding databases.
That said, have a look at bugs 1955536 and 1751857 for details of problems 
with deinstalling JVM and potential workarounds

>From bug 1955536:
"So, the first thing to try here is probably to
.
1) restart the database
2) start a different session that the one the started the database
3) run initjvmaux.sql
4) run rmjvm.sql
5) do the following from bug 1751857
.
 drop trigger JIS$ROLE_TRIGGER$; 
 delete from ducs$ where owner='SYS' and pack='JIS$INTERCEPTOR$' and 
proc='USER_DROPPED'; 
 delete from aurora$startup$classes$ where 
classname='oracle.aurora.mts.http.admin.RegisterService'; 
  delete from aurora$dyn$reg; 
.
6) restart the database - if you get trigger errors, ignore them
   make sure java_pool_size is at least 50MB
7) start a new session
8) try initjvm.sql
.
Keep spool files of everything."
and then
"Note also that not only does running initjvm after rmjvm require a new
session, it requires restarting the database instance.  The newer versions
of initjvm attempt to enforce this by exiting immediately if it can be
detected that rmjvm has run in the same instance."

HTH,
Bruce Reardon

-----Original Message-----
Sent: Wednesday, 17 April 2002 14:08
Hi All

I am trying to add Java support to one of the databases and it keeps 
failing. It seems that after the first run it didn't get it right and 
rmjvm doesn't seem to run properly after. there still appears to be a 
large bunch of objects in the database. Any ideas as to how to clean it up 


I can rebuild it if i need to, this is more of a learning task, I normally 

create them with Java in the first place.

Any ideas
8.1.7 on Solaris 8
Thanks
=================================================
Peter McLarty               E-mail: [EMAIL PROTECTED]
Technical Consultant        WWW: http://www.mincom.com
APAC Technical Services     Phone: +61 (0)7 3303 3461
Brisbane,  Australia        Mobile: +61 (0)402 094 238
                            Facsimile: +61 (0)7 3303 3048
=================================================
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Reardon, Bruce (CALBBAY)
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




-- 
This transmission is for the intended addressee only and is confidential information.  
If you have received this transmission in error, please delete it and notify the 
sender.  The contents of this e-mail are the opinion of the writer only and are not 
endorsed by the Mincom Group of companies unless expressly stated otherwise.

Attachment: STG63997
Description: Binary data

Reply via email to