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).