How to Study Oracle [The word "study" means "learn" in OracleStudy.txt and "research" in this note.] 4.4.0 If you encounter an oracle error ORA-00600 or ORA-07445, search using the string "ora-600 " or "ora-00600 ", where is the number or string in the first bracket after the error. 4.4.1 Sometimes, especially on 64-bit platform, the first argument could be a very unlikely large number such as in ORA-07445: exception encountered: core dump [000000010191AE50] [SIGSEGV] [Address not mapped to object] [0x000000090] [] [] Search using a string "ora-7445 000000010191AE50" won't return anything. In this case, the only way to search is by the error stack. Following that line in the trace file, we see ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedmp()+328 CALL ksedst()+0 00000000B ? 000000000 ? 000000000 ? 00000004A ? FFFFFFFF7FFF9C98 ? 1031C9718 ? ssexhd()+604 CALL ksedmp()+0 000000000 ? 000103400 ? 0001035CD ? 000102C00 ? ... sigacthandler()+44 ... kxhfNewBuffer()+272 ... qerhjSplit()+772 ... ... opidrv()+736 ... sou2o()+16 ... main()+184 ... _start()+380 ... You shouldn't search for ksedmp or main or _start. Instead use the function names close to the top. I search for "ora-7445 ssexhd" and it returns too much. I search for "ora-7445 ssexhd kxhfNewBuffer" returns nothing with default checkboxes. After I check Bug and Archived Articles, I get 13 bug reports. That's exactly what I want. 5.0 Beyond the normal avenues outlined above to research on an issue, there're some uncommon-sense or esoteric approaches. By no means should you use them to replace Oracle support, or indulge yourself in these explorations and forget about easy, common-sense, or low-hanging-fruit approaches. Also be aware that there's no fixed, single method for research; what I describe here is for one specific case only. 5.1 Take as an example the question raised on news:comp.databases.oracle.server: Why is column archivelog_compression in v$database in 10g undocumented? After I verify it, I search on Google groups, Google Web and Metalink including Bugs and Archived documents for keywords "archivelog compress", "... compression", "archived logs compress", "... compression" with proper use of quotes. Among many messages about home-grown archive logs compression or RMAN backup compression, I see Note:284618.1, an official document that says the archivelog compression feature is not ready in 10gR1. 5.2 With messages like "Archivelog for thread %d sequence %d will be compressed" in Note:284618.1, I search in documentation on tahiti.oracle.com and also my local documentation on my hard drive (using Windows Explorer string search). I didn't find anything related. 5.3 Since it's about a v$ view, I look at v$fixed_view_definition for GV$DATABASE. Unfortunately it doesn't help since the column archivelog_compression comes from x$kccdi.difl2 and I can't find anything about difl2 anywhere (it's an acronym probably for "database information flag2"). 5.4 The next place I look at is database undocumented parameters. Good! We see a parameter _log_archive_compress_enable in 10g, which is set to false. The description is a little scary so I don't want to test it (yet). 5.5 I'm not satisfied with that. So on my 10g database server (since the question is about 10g), I ran "strings -a %oracle_home%\bin\oracle.exe > oracle.strings" (or "strings -a $ORACLE_HOME/bin/oracle > oracle.strings" on UNIX/Linux), where strings.exe is from sysinternals.com. The file oracle.strings contains numerous interesting "paragraphs" related to archivelog compression (separated by 3-dot lines below): ********************************* kcrrcalb.8 Archivelog compression complete. Input: %ld bytes Output: %ld bytes Compression Performance: %.2f percent or %.2f bits per byte ... kcrrprep.6 Archivelog not compressed; compatibility error in logfile header incomplete Detected terminal %srecovery End-Of-Redo indicator ... Archivelog created using compression ... krsl.c Changing dest %d SDI intvno from %d to %d [%s:%d] LGWR: Archivelog for thread %d sequence %d will be compressed LGWR: Archivelog for thread %d sequence %d will NOT be compressed LGWR: SYNC destination found, archivelog for thread %d sequence %d will NOT be compressed LGWR: Archivelog for thread %d sequence %d will NOT be compressed ... Starting block is invalid due to log compression. ********************************* and it also mentions column compressed in view v$archived_log, which I find is also undocumented in Reference manual! 5.6 With the wealth of information dug out of oracle.strings, I start to search on Google, Metalink and tahiti.oracle.com again. Surprisingly, searching on the function names kcrrcalb, kcrrprep and krsl does not show anything relevant or helpful. But if I had missed Note:284618.1 earlier, I would have spotted it this time easily. This oracle.strings file is like a catch-all information repository for Oracle kernel, even more useful than kernel symbol table (`nm $ORACLE_HOME/bin/oracle`). Undocumented parameters like _log_archive_compress_enable could have been missed in Step 5.4. Then you would catch it here. Database events, those with ORA errors from 10000 to 10999, are all in here. It's just that for this specific issue, no relevant events are found. A Practical Use of oracle.strings (i.e. `strings -a $ORACLE_HOME/bin/oracle`): A user complains about frequent crash of his 9i database. Alert.log has ORA-600 [kghsscwrbuf_closed]. But the function kghsscwrbuf_closed is nowhere to find, on Metalink, Google groups or Web, or my 9i oracle.strings. So I gradually cut the last part of the string and search, kghsscwrbuf, kghsscwr, and kghssc. Still nothings turns out on Metalink and Google. But oracle.strings starts to show entries that contain kghssc as partial string, the closest of which I think is kghssc_writebuf. Searching this kghssc_writebuf function returns Bug:4033656.8, where a situation similar to the user's is discussed. Although he's advised to open a Tar with Oracle, knowing something possibly relevant on Metalink is helpful. Yong Huang 2005 in Houston