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

70
CHAPTER 3 ■ FILES
It should be noted that the parameter file does not have to be in any particular location.
When starting an instance, you may use the pfile=filename option to the startup command.
This is most useful when you would like to try out different init.ora parameters on your database
to see the effects of having different settings.
Legacy parameter files can be maintained by using any plain text editor. For example, on
UNIX/Linux, I would use vi; on the many Windows operating system versions, I would use
Notepad; and on a mainframe, I would perhaps use Xedit. It is important to note that you are
fully responsible for editing and maintaining this file. There are no commands within the
Oracle database itself that you can use to maintain the values contained in the init.ora file.
For example, when you use the init.ora parameter file, the issue of an ALTER SYSTEM command
to change the size of an SGA component would not be reflected as a permanent change
in the init.ora file. If you would like that change to be made permanent—in other words, if
you would like it to be the default for subsequent restarts of the database—it is up to you to
make sure all init.ora parameter files that might be used to start this database are manually
updated.
The last interesting point of note is that the legacy parameter file is not necessarily
located on the database server. One of the reasons the stored parameter that we’ll discuss
shortly was introduced was to remedy this situation. The legacy parameter file must be present
on the client machine attempting to start the database, meaning that if you run a UNIX
server, but administer it using SQL*Plus installed on your Windows desktop machine over the
network, then you would need the parameter file for the database on your desktop.
I still remember how I made the painful discovery that the parameter files are not stored
on the server. This goes back many years to when a brand-new tool called SQL*DBA was introduced.
This tool allowed us to perform remote operations (specifically, remote administrative
operations). From my server (running SunOS at the time), I was able to connect remotely to a
mainframe database server. I was also able to issue the “shutdown” command. However, it
was at that point I realized that I was in a bit of a jam—when I tried to start up the instance,
SQL*DBA would complain about not being able to find the parameter file. I learned that these
parameter files—the init.ora plain text files—were located on the machine with the client,
not on the server. SQL*DBA was looking for a parameter file on my local system with which to
start the mainframe database. Not only did I have no such file, but I also had no idea what to
put into one to get the system started up again! I didn’t know the db_name or control file locations
(even just getting the correct naming convention for the mainframe files would have
been a bit of stretch), and I didn’t have access to log into the mainframe system itself. I’ve not
made that same mistake since; it was a painful lesson to learn.
When DBAs realized that the init.ora parameter file had to reside on the client’s machine
that starts the database, it led to a proliferation of these files. Every DBA wanted to run the
administrative tools from his desktop, and so every DBA needed a copy of the parameter file
on his desktop machine. Tools such as Oracle Enterprise Manager (OEM) would add yet
another parameter file to the mix. These tools would attempt to centralize the administration
of all databases in an enterprise on a single machine, sometimes referred to as a “management
server.” This single machine would run software that would be used by all DBAs to start
up, shut down, back up, and otherwise administer a database. That sounds like a perfect
solution: centralize all parameters files in one location and use the GUI tools to perform