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 71<br />

all operations. But the reality is that sometimes it was much more convenient to issue the<br />

administrative startup comm<strong>and</strong> from within SQL*Plus on the database server machine itself<br />

during the course of some administrative task, so we ended up with multiple parameter files<br />

again: one on the management server <strong>and</strong> one on the database server. These parameter files<br />

would then proceed to get out of sync with each other, <strong>and</strong> people would wonder why the<br />

parameter change they made last month “disappeared,” but seemingly r<strong>and</strong>omly made a<br />

reappearance.<br />

Enter the server parameter file (SPFILE), which can now be a single source of truth for the<br />

database.<br />

Server Parameter Files (SPFILEs)<br />

SPFILEs represent a fundamental change in the way <strong>Oracle</strong> accesses <strong>and</strong> now maintains<br />

parameter settings for the instance. An SPFILE removes the two serious issues associated<br />

with legacy parameter files:<br />

• It removes the proliferation of parameter files. An SPFILE is always stored on the database<br />

server; the SPFILE must exist on the server machine itself <strong>and</strong> cannot be located<br />

on the client machine. This makes it practical to have a single source of “truth” with<br />

regard to parameter settings.<br />

• It removes the need (in fact, it removes the ability) to manually maintain parameter files<br />

using text editors outside of the database. The ALTER SYSTEM comm<strong>and</strong> allows you to<br />

write values directly into the SPFILE. Administrators no longer have to find <strong>and</strong> maintain<br />

all of the parameter files by h<strong>and</strong>.<br />

The naming convention for this file by default is<br />

spfile$ORACLE_SID.ora<br />

spfile%ORACLE_SID%.ora<br />

(Unix environment variable)<br />

(Windows environment variable)<br />

I strongly recommend using the default location; doing otherwise defeats the simplicity<br />

SPFILEs represent. When an SPFILE is in its default location, everything is more or less done<br />

for you. Moving the SPFILE to a nondefault location involves you having to tell <strong>Oracle</strong> where<br />

to find the SPFILE, leading to the original problems of legacy parameter files all over again!<br />

Converting to SPFILEs<br />

Suppose we have a database that is using a legacy parameter file described previously. The<br />

move to an SPFILE is quite simple; we use the CREATE SPFILE comm<strong>and</strong>.<br />

■Note You can also use a “reverse” comm<strong>and</strong> to create a parameter file (PFILE) from an SPFILE.<br />

(I’ll explain shortly why you might want to do that.)

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

Saved successfully!

Ooh no, something went wrong!