RE: initjvm and rmjvm failing

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: Peter.Mclarty_at_mincom.com
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)" <Bruce.Reardon_at_comalco.riotinto.com.au>
Sent by: root_at_fatcity.com
17-04-2002 02:48 PM
Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        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: Peter.Mclarty_at_mincom.com
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: Bruce.Reardon_at_comalco.riotinto.com.au

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: ListGuru_at_fatcity.com (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.




Content-Type: text/plain; name="ReadMe.txt"; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The previous attachment was filtered out by the ListGuru mailing
software at fatcity.com because binary attachments are not appropriate
for mailing lists.  If you want a copy of the attachment which was
removed, contact the sender directly and ask for it to be sent to
you by private E-mail.

This warning is inserted into all messages containing binary
attachments which have been removed by ListGuru.  If you have questions
about this message, contact Postmaster_at_fatcity.com for clarification.

--=_mixed 0020D1704A256B9E_=--
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Peter.McLarty_at_mincom.com

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: ListGuru_at_fatcity.com (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).



application/octet-stream attachment: STG63997