| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: core_dump_dest = /dev/null?
Jared,
Here are the results:
SVRMGR>oradebug setorapid 9
Unix process PID: 4143, image oracle_at_shelby TNS(V1-V3)
SVRMGR>oradebug core
statement Processed.
I have not found the trace file in $ORACLE_HOME/rdbms/log but instead I found the trace file in /usr/local/oracle/log/inst/usr, the contents are as follows:
Node name: shelby Release: B.11.00 Version: A Machine: 9000/879
The parameters are set as follows:
inst:SQL>select name,value from v$parameter where name like '%dump%';
NAME VALUE ------------------------------ ------------------------------ shadow_core_dump partial background_core_dump partial background_dump_dest /usr/local/oracle/log/inst user_dump_dest /usr/local/oracle/log/inst/usr max_dump_file_size 10240 core_dump_dest /dev/null
6 rows selected.
initinst.ora values:
user_dump_dest = /usr/local/oracle/log/inst/usr core_dump_dest = /dev/null background_dump_dest = /usr/local/oracle/log/inst max_dump_file_size = 10240 ***************************************************************************
Please let me know the feedback.
Thanks,
-- Janardhana Babu
At 01:16 PM 5/26/00 -0700, Jared Still wrote:
>So now see what happens when you dump a core.
>
>Try this:
>
>login to the database with server manager as internal,
>and run this query:
>
>
> select
> s.username, p.pid ppid
> from v$session s, v$process p
> where p.addr = s.paddr
> and s.username is not null
>
>
>Pick on of the PID's and run these commands:
>
> oradebug setorapid <PID>
> oradebug core
>
>
>This will dump a core without killing the process.
>
>Let's see if your TEST database can withstand this.
>
>
>Jared
>
>
>
>
>On Fri, 26 May 2000, Janardhana Babu wrote:
>
> > Kirti,
> >
> > Iam posting the details that you want. I have no problem starting up the
> > DB. I have problem how to test (ie, generating core dump file ), which
> I do
> > not know.
> >
> > inst:SQL>select name,value from v$parameter where name like '%dump%';
> >
> > NAME VALUE
> >
> > ------------------------------
> > ------------------------------
> >
> > shadow_core_dump partial
> >
> > background_core_dump partial
> >
> > background_dump_dest /usr/local/oracle/log/inst
> >
> > user_dump_dest /usr/local/oracle/log/inst/usr
> >
> > max_dump_file_size 10240
> >
> > core_dump_dest /dev/null
> >
> >
> > 6 rows selected.
> >
> > initinst.ora values:
> > --------------------
> > user_dump_dest = /usr/local/oracle/log/inst/usr
> > core_dump_dest = /dev/null
> > background_dump_dest =
> /usr/local/oracle/log/inst
> > max_dump_file_size = 10240
> >
> > -- Janardhana Babu
> >
> > At 08:55 AM 5/26/00 -0800, Deshpande, Kirti wrote:
> > >Remember, when Oracle dumps core, it will create a file under the dump
> > >directory, And /dev/null is not a directory. So you will get ORA-443 (PMON
> > >not started) and ORA-9924 (directory not created properly) errors if dump
> > >directories settings are pointed to non-directory files. Just try it
> on you
> > >test db.
> > >So, /dev/null may be a good idea but you won't be able to startup the
> > >database !!!
> > >- Kirti
> > >
> > >
> > > > -----Original Message-----
> > > > From: Gilles PARC [SMTP:gparc_at_online.fr]
> > > > Sent: Thursday, May 25, 2000 6:56 PM
> > > > To: Multiple recipients of list ORACLE-L
> > > > Subject: Re: core_dump_dest = /dev/null?
> > > >
> > > > At 05:38 25/05/2000 -0800, you wrote:
> > > > >
> > > > >> Here's an interesting thought - since Oracle very rarely wants
> the core
> > > > >> dump files, and since they can consume a lot of space unless you
> > > > >> routinely clean them up, is there any disadvantage to setting the
> > > > >> core_dump_dest parameter to /dev/null? Has anyone actually tried
> this?
> > > > >> Seems like it should work...
> > > > >
> > > >
> > > > Core_dump_dest is supposed to point to a directory so
> > > > /dev/null will probably not work.
> > > >
> > > > HTH
> > > >
> > > > Gilles Parc
> > > > Email : gparc_at_mail.dotcom.fr
> > > >
> > > > carpe diem !!
> > > > --
> > > >
> > >--
> > >Author: Deshpande, Kirti
> > > INET: Kirti.Deshpande_at_gtedc.gte.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).
> > >
> >
> > --
> > Author: Janardhana Babu
> > INET: jbdonga_at_ucdavis.edu
> >
> > 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).
Received on Fri May 26 2000 - 16:30:50 CDT
 |
 |