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.

78<br />

CHAPTER 3 ■ FILES<br />

C:\oracle\oradata\ora9ir2w\CONTROL02.CTL,<br />

C:\oracle\oradata\ora9ir2w\CONTROL03.CTL<br />

....<br />

pga_aggregate_target = 25165824<br />

aq_tm_processes = 1<br />

PMON started with pid=2<br />

DBW0 started with pid=3<br />

From this section, you can easily create a PFILE to be converted into a new SPFILE using<br />

the CREATE SPFILE comm<strong>and</strong>.<br />

Parameter File Wrap-Up<br />

In this section, we covered all of the basics of managing <strong>Oracle</strong> initialization parameters <strong>and</strong><br />

parameter files. We looked at how to set parameters, view parameter values, <strong>and</strong> have those<br />

settings persist across database restarts. We explored the two types of database parameter<br />

files: legacy PFILEs (simple text files) <strong>and</strong> SPFILEs. For all existing databases, using SPFILEs<br />

is recommended for the ease of administration <strong>and</strong> clarity they bring to the table. The ability<br />

to have a single source of parameter “truth” for the database, coupled with the ability of the<br />

ALTER SYSTEM comm<strong>and</strong> to persist the parameter values, make SPFILEs a compelling feature.<br />

I started using them the instant they became available <strong>and</strong> haven’t looked back.<br />

Trace Files<br />

Trace files are a source of debugging information. When the server encounters a problem, it<br />

generates a trace file full of diagnostic information. When a developer sets SQL_TRACE=TRUE, the<br />

server generates a trace file full of performance-related information. Trace files are available to<br />

us because <strong>Oracle</strong> is a heavily instrumented piece of software. By “instrumented,” I mean that<br />

the programmers who wrote the database kernel put in debugging code—lots <strong>and</strong> lots of it.<br />

And they left it in, on purpose.<br />

I’ve met many developers who consider debugging code to be overhead—something that<br />

must be ripped out before it goes into production in a vain attempt to squeeze every ounce of<br />

performance out of the code. Later, of course, they discover that their code has “a bug” or it<br />

“isn’t running as fast as it should” (which end users tend to call “a bug” as well. To an end user,<br />

poor performance is a bug!). At that point, they are really wishing that the debug code was still<br />

in there (or had been in there if it never was), especially since they cannot drop debug code<br />

into the production system—that is an environment where new code must be tested first, not<br />

something you do at the drop of a hat.<br />

The <strong>Oracle</strong> database (<strong>and</strong> Application Server <strong>and</strong> <strong>Oracle</strong> applications) is heavily instrumented.<br />

Signs of this instrumentation in the database are<br />

• V$ views: Most V$ views contain “debug” information. V$WAITSTAT, V$SESSION_EVENT,<br />

<strong>and</strong> many others are there solely to let us know what is going on in the bowels of the<br />

kernel.<br />

• The auditing comm<strong>and</strong>: This comm<strong>and</strong> allows you to specify what events the database<br />

should record for later analysis.

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

Saved successfully!

Ooh no, something went wrong!