I'm unable to open a TAR for you, but here is what a
quick Metalink search has produced:
Oracle Server-Enterprise and Standard Edition Technical Forum
Displayed below are the messages of the selected thread.
Thread Status: Active
before applying patch
RDBMS Version: 8.1.6
Operating System and Version: solaris 2.6
Error Number (if applicable): ora 7442
Product (i.e. SQL*Loader, Import, etc.):
Product Version: 8.1.6
database crashing with ora 7445; would like input from other people before
applying patch
Hi there,
We've had several db's crash periodically with one or the other of the
following errors:
ORA-07445: exception encountered: core dump[kghfrmrg()+88] [SIGSEGV]
[Address
not mapped to object] [2219483628] [][]
ORA-07445: exception encountered: core dump [kghfrmrg()+488]
[SIGSEGV][Address
not mapped to object] [2216410208] [] []
I've posted a tar and the reponse has been to apply the Solaris patch
8.1.6.2 Before applying this patch I'd like some feedback from folks out
there in the field.
I've seen several other posts on Metalink reporting the same problem but
have not seen any resolutions. (If I've overlooked one, I apologize and
would appreciate someone pointing me to it). Some of the proposed
resolutions were to upgrade to 8.1.6 (obviously it's not fixed in 8.1.6).
If anyone out there has had this problem and has upgraded to a patch for
8.1.6 I would really appreciate some feedback. We cannot recreate the
problem consistently but it's happening frequently enough to cause problems
on our production db's. However, I have not gotten any indication that this
patchset corrects the problem. I do not like to apply patches and see if it
corrects a problem, especially when it's a problem that has been reported as
often as this error.
Thanks for any info you can provide.
Richard.
----------------------------------------------------------------------------
----
people before applying patch
Hi. Was there a bug number referenced for your scenario which is fixed in
the 8.1.6.2 patchset release? I would need to see the trace file associated
with this error as well as an excerpt from the alert.log showing a timeframe
from the last startup of the database through the time of the error and
subsequent database crash. You can e-mail those to me at:
[EMAIL PROTECTED] Please reference the subject and date of your
thread in the e-mail.
ORA-7445 is a generic error which signals that an unhandled exception
occurred somewhere within the Oracle environment for some reason. The cause
of one occurrence may or may not be related to another occurrence.
Sometimes, the exception occurs due to previous errors. Do all occurrences
of the ORA-7445 which initiates the crash look just like the one you list
with [kghfrmrg] as the first arguement?
Regards,
Helen
Oracle Support Services
----------------------------------------------------------------------------
----
people before applying patch
Richard
We have encountered similar messages in our alert log. These were caused by
the use of %rowtype in pl/sql. This is not fixed in the 8.1.6.2 patch, and
is in fact still a problem in 8.1.7. So, if it is possible that this could
be causing your problems, I would not advise applying the patch.
However, we have applied the 8.1.6.2 patch for another 8.1.6 problem - a bug
with degree of parallelism and unions. We have encountered many more
problems with the patch than without. Oracle have said it is likely we would
have encountered these problems with 8.1.6.0, we just hadn't got that far.
They also said that the patch was the only option for our problem at that
time. It also appears that most of the bugs we have encountered in 8.1.6.2
have been related to parallel query, so if you are not using parallel query,
you may be OK with the patch.
Have Fun with this one!
Thanks
Tracey Widdall
----------------------------------------------------------------------------
----
people before applying patch
Hi. Unfortunately, I am unable to confirm that this is fixed in the 8.1.6.2
as I am unable to pinpoint a bug that you are encountering. Both of the
scenarios you provided show a session performing an 'alter database backup
controlfile to trace' followed by a shutdown immediate.' The ORA-7445 error
is signalled to the session upon the ALTER DATABASE CLOSE which is fatal.
PMON then encounters the same error when attemping the cleanup. How is this
backup of the controlfile and shutdown controlled? Do you have a script
which executes this every night? Would it be possible to alter the sequence
of events so that the session which performs the backup of the controlfile
exits, then starts a new session to execute the shutdown immediate?
Regards,
Helen
Oracle Support Services
----------------------------------------------------------------------------
----
people before applying patch
Hi Helen,
Thanks for the feedback. There is a script that runs every night to do the
backups (shuts each db down, does a cold backup, restarts the db). I didn't
write the script but I can talk to the guy who did and see if that's a
possibility. Just to clarify, when you talk about exiting the session and
starting a new one, I'm assuming you mean getting out of svrgmrl / sqlplus
nolog (not sure which one is used at the moment) and then getting back in to
do the shutdown immediate.
I should add one thing. One possibility I've considered is that this has to
do with sniped sessions. We have an idle-time limit of 60 minutes and
periodically sessions do get sniped. Though the errors produced don't seem
to exactly match the ones reported for this problem. Is this a possible
cause for the errors I sent you? (If so, that's a big concern since we are
being told that we have to set the idle-time at 15 minutes, which will cause
a lot more sniped sessions).
Thanks.
Richard.
----------------------------------------------------------------------------
----
other people before applying patch
Hi. Your assumption of "getting out of svrgmrl / sqlplus nolog and then
getting back in to do the shutdown immediate" is correct. I have no
information to point to sniped sessions being associated with this based on
information so far.
Please let me know about the shutdown. Also, if you could provide details of
how it functions (i.e. sqlplus, svrmgrl, etc.).
Regards,
Helen
Oracle Support Services
Mladen Gogala
Oracle DBA
Phone:(203) 459-6855
Email:[EMAIL PROTECTED]
-----Original Message-----
Sent: Monday, July 21, 2003 6:00 PM
To: Multiple recipients of list ORACLE-L
Oh no! I have to wait for 9iBF? I'll be retired by
then, and I'm only ... well ... never mind how old
I am. I don't wanna wait that long.
Cheers,
Mike
-----Original Message-----
Sent: Monday, July 21, 2003 2:35 PM
To: Multiple recipients of list ORACLE-L
He needs to contact oracle support, because the dump came from the
oracle server process. If he's lucky, the one-off patch is already published
and he only needs to download it from Metalink and apply it. If not,
then he has to wait for oracle 9BF (BF = Bug Free)
Mladen Gogala
Oracle DBA
Phone:(203) 459-6855
Email:[EMAIL PROTECTED]
-----Original Message-----
Sent: Monday, July 21, 2003 5:20 PM
To: Multiple recipients of list ORACLE-L
SIGSEGV = Segment Violation = invalid address = bad code
Sounds like you need to contact SAP and/or Oracle support.
Jared
"Vergara, Michael (TEM)" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/21/2003 02:04 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: HP-UX 11i/9.2.0.3/Strange Executions
Hi Everyone!
HELP!
I upgraded my SAP *PRODUCTION* instance to 9.2.0.3 over the weekend.
Everything up until now has been OK. However, I now have some
SAP Transactions (read: data entry forms) that are abending
unexpectedly.
What's strange is that when we run the transaction on our Stage
server the explain plan is different, and the query succeeds. In
PRD, the query is a single-step, and in stage it gets broken out
into sub-queries and executed there.
I created a report of all the database parameters. There is no
difference that cannot be explained by the difference in CPUs,
database name, or application paths. They are fundamentally
identical.
But the query aborts on PRD. I am attaching the top few lines
of a typical trace file. ANY help, RTFM references, suggestions,
incantations, incense, or holy water will be appreciated.
Thanks,
Mike
*** 2003-07-21 14:52:06.921
*** SESSION ID:(326.5957) 2003-07-21 14:52:06.886
Exception signal: 11 (SIGSEGV), code: 0 (unknown code), addr:
0x800000016ede9f30, PC: [0x4000000001331c0c, kghfrmrg()+596]
Registers:
r1: 800000010000d9e8 r22: 6e6178d8 sr4: 7df0c00
rp: 0 arg3: 800000016ede9f28 sr0: 67c9c00
r3: 40000000013319b8 arg2: c00000006e615fa0 sr1: d7db000
r4: 0 arg1: 6e615fa0 sr2: 0
r5: 0 arg0: c0b38f0000001131 sr3: 0
r6: 7ffffffc dp: 80000001000ca608 sr5: 6930000
r7: 0 ret0: 0 sr6: a814c00
r8: 80000001007d3798 ret1: 800000000000000 sr7: 67c9c00
r9: 80000001007d3780 sp: 800003ffbfff6880 cr0: 0
r10: 0 r31: 6 cr8: 77f6368
r11: 0 sar: 38 cr9: 77f6378
r12: 0 pcoqh: 4000000001331c0f ccr: 0
r13: 10000 pcsqh: 6930000 cr12: 494c008
r14: 800003ffbfff48c0 pcoqt: 4000000001331a93 cr13: 4a2b008
r15: 800003ffbfff48c8 pcsqt: 6930000 cr24: 4a2c808
r16: 40000000003f85d0 eiem: ffffffffffffffff cr25: 4a2a808
r17: af0 iir: 72f50010 cr26: 4a2c808
r18: 0 isr: a814c00 mpsfu_hi:
80000001000e36c8
r19: 800000010000d9e8 ior: 800000016ede9f30 mpsfu_lo: 0
r20: 0 ipsw: ff080cff1f mpsfu_ov: 41
r21: 80000001007d2650 goto: 97f68 pad: 0
*** 2003-07-21 14:52:07.811
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [kghfrmrg()+596] [SIGSEGV]
[unknown code] [0x800000016EDE9F30] [] []
Current SQL statement for this session:
SELECT T_00 . "MATNR" , T_00 . "PRDHA" , T_01 . "MAKTX" FROM "MARA" T_00 ,
"MAKT" T_01 WHERE ( T_01 . "MANDT" = :A0 AND T_01 . "MATNR" = T_00 . "MA
TNR" ) AND T_00 . "MANDT" = :A1 AND ( ( T_00 . "MATNR" BETWEEN :A2 AND :A3
OR T_00 . "MATNR" BETWEEN :A4 AND :A5 OR T_00 . "MATNR" BETWEEN :A6 AND
:A7 OR T_00 . "MATNR" BETWEEN :A8 AND :A9 OR T_00 . "MATNR" BETWEEN :A10
AND :A11 OR T_00 . "MATNR" BETWEEN :A12 AND :A13 OR T_00 . "MATNR" BETWEEN
:A14 AND :A15 OR T_00 . "MATNR" BETWEEN :A16 AND :A17 OR T_00 . "MATNR"
BETWEEN :A18 AND :A19 ) OR T_00 . "MATNR" IN ( :A20 , :A21 , :A22 , :A23 ,
:A24 , :A25 , :A26 , :A27 , :A28 , :A29 , :A30 , :A31 , :A32 , :A33 ,
:A34 , :A35 , :A36 , :A37 , :A38 , :A39 , :A40 , :A41 , :A42 , :A43 , :A44
,
:A45 , :A46 , :A47 , :A48 , :A49 , :A50 , :A51 , :A52 , :A53 , :A54 ,
:A55 , :A56 , :A57 , :A58 , :A59 , :A60 , :A61 , :A62 , :A63 , :A64 , :A65
,
:A66 , :A67 , :A68 , :A69 , :A70 , :A71 , :A72 , :A73 , :A74 , :A75 ,
:A76 , :A77 , :A78 , :A79 , :A80 , :A81 , :A82 , :A83 , :A84 , :A85 , :A86
,
:A87 , :A88 , :A89 , :A90 , :A91 , :A92 , :A93 , :A94 , :A95 , :A96 ,
:A97 , :A98 , :A99 , :A100 , :A101 , :A102 , :A103 , :A104 , :A105 , :A106
,
:A107 , :A108 , :A109 , :A110 , :A111 , :A112 , :A113 , :A114 , :A115 ,
:A116 , :A117 , :A118 , :A119 , :A120 , :A121 , :A122 , :A123 , :A124 , :A
125 , :A126 , :A127 , :A128 , :A129 , :A130 , :A131 , :A132 , :A133 ,
:A134 , :A135 , :A136 , :A137 , :A138 , :A139 , :A140 , :A141 , :A142 ,
:A143
, :A144 , :A145 , :A146 , :A147 , :A148 , :A149 , :A150 , :A151 , :A152 ,
:A153 , :A154 , :A155 , :A156 , :A157 , :A158 , :A159 , :A160 , :A161 ,
:A162 , :A163 , :A164 , :A165 , :A166 , :A167 , :A168 , :A169 , :A170 ,
:A171 , :A172 , :A173 , :A174 , :A175 , :A176 , :A177 , :A178 , :A179 ,
:A1
80 , :A181 , :A182 , :A183 , :A184 , :A185 , :A186 , :A187 , :A188 , :A189
, :A190 , :A191 , :A192 , :A193 , :A194 , :A195 , :A196 , :A197 , :A198
, :A199 , :A200 , :A201 , :A202 , :A203 , :A204 , :A205 , :A206 , :A207 ,
:A208 , :A209 , :A210 , :A211 , :A212 , :A213 , :A214 , :A215 , :A216 , :
A217 , :A218 , :A219 , :A220 , :A221 , :A222 , :A223 , :A224 , :A225 ,
:A226 , :A227 , :A228 , :A229 , :A230 , :A231 , :A232 , :A233 , :A234 ,
:A23
5 , :A236 , :A237 , :A238 , :A239 , :A240 , :A241 , :A242 , :A243 , :A244
, :A245 , :A246 , :A247 , :A248 , :A249 , :A250 , :A251 , :A252 , :A253 ,
:A254 , :A255 , :A256 , :A257 , :A258 , :A259 , :A260 , :A261 ) ) AND
T_01 . "SPRAS" = :A262
----- Call Stack Trace -----
---
===========================================================================
Michael P. Vergara
Oracle DBA
Guidant Corporation
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Vergara, Michael (TEM)
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Gogala, Mladen
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Vergara, Michael (TEM)
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Gogala, Mladen
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
