05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 3 ■ FILES 85<br />

_qerixAllocate+4155<br />

_qknRwsAllocateTree+281<br />

_qknRwsAllocateTree+252<br />

_qknRwsAllocateTree+252<br />

_qknRwsAllocateTree+252<br />

_qknDoRwsAllocate+9<br />

...<br />

Here we see a couple of important pieces of information. First, we find the SQL statement<br />

that was executing when the internal error was raised, which is very useful for tracking down<br />

what application(s) was affected. Also, since we see the SQL here, we can possibly start investigating<br />

possible work-arounds—trying different ways to code the SQL to see if we can quickly<br />

work around the issue while working the bug. Furthermore, we can cut <strong>and</strong> paste the offending<br />

SQL into SQL*Plus <strong>and</strong> see if we have a nicely reproducible test case for <strong>Oracle</strong> Support<br />

(these are the best kinds of test cases, of course).<br />

The other important pieces of information are the error code (typically 600, 3113, or 7445)<br />

<strong>and</strong> other arguments associated with the error code. Using these, along with some of the stack<br />

trace information that shows the set of <strong>Oracle</strong> internal subroutines that were called in order,<br />

we might be able to find an existing bug (<strong>and</strong> work-arounds, patches, <strong>and</strong> so on). For example,<br />

we might use the search string<br />

ora-00600 12410 ksesic0 qerixAllocate qknRwsAllocateTree<br />

Using MetaLink’s advanced search (using all of the words, search the bug database), we<br />

immediately find the bug 3800614, “ORA-600 [12410] ON SIMPLE QUERY WITH ANALYTIC<br />

FUNCTION”. If we go to http://metalink.oracle.com <strong>and</strong> search using that text, we will discover<br />

this bug, see that it is fixed in the next release, <strong>and</strong> note that patches are available—all<br />

of that information is available to us. I find many times, the error I receive is an error that has<br />

happened before <strong>and</strong> there are in fact fixes or work-arounds for it.<br />

Trace File Wrap-Up<br />

You now know the two types of general trace files, where they are located, <strong>and</strong> how to find<br />

them. Hopefully, you’ll use trace files mostly for tuning <strong>and</strong> increasing the performance of<br />

your application, rather than for filing iTARs. As a last note, <strong>Oracle</strong> Support does have access<br />

to many undocumented “events” that are very useful for dumping out tons of diagnostic information<br />

whenever the database hits any error. For example, if you believe you are getting an<br />

ORA-01555 when you absolutely feel you should not be, <strong>Oracle</strong> Support can guide you<br />

through the process of setting such diagnostic events in order to help you track down precisely<br />

why that error is getting raised, by creating a trace file every time that error is encountered.<br />

Alert File<br />

The alert file (also known as the alert log) is the diary of the database. It is a simple text file<br />

written to from the day the database is “born” (created) to the end of time (until you erase it).<br />

In this file, you will find a chronological history of your database—the log switches; the internal<br />

errors that might be raised; when tablespaces were created, taken offline, put back online;

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!