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

68
CHAPTER 3 ■ FILES
operating system–by–operating system basis). In other words, the number of parameters (and
their names) varies by release. Most parameters, like DB_BLOCK_SIZE, are very long lived (they
won’t go away from release to release), but over time many other parameters become obsolete
as implementations change.
For example, in Oracle 9.0.1 there was a DISTRIBUTED_TRANSACTIONS parameter that could
be set to some positive integer and that controlled the number of concurrent distributed
transactions the database could perform. It was available in prior releases, but it is not found
in any release subsequent to 9.0.1 and, in fact, attempting to use it with subsequent releases
will raise an error:
ops$tkyte@ORA10G> alter system set distributed_transactions = 10;
alter system set distributed_transactions = 10
*
ERROR at line 1:
ORA-25138: DISTRIBUTED_TRANSACTIONS initialization parameter has been made
obsolete
If you would like to review these parameters and get a feeling for what is available and
what each parameter does, you should refer to the Oracle Database Reference manual. The first
chapter of this manual examines each and every documented parameter in detail. I would like
to point out that in general, the default value assigned to these parameters (or the derived
value for parameters that obtain their default settings from other parameters) is sufficient for
most systems. In general, the values of parameters, such as the CONTROL_FILES parameter
(which specifies the location of the control files on your system), DB_BLOCK_SIZE, and various
memory-related parameters, need to be set uniquely for each database
Notice I used the term “documented” in the preceding paragraph. There are undocumented
parameters as well. You can identify these by the fact that their names begin with an
underscore (_). There is a great deal of speculation about these parameters. Since they are
undocumented, some people believe they must be “magical,” and many people assume that
they are well known and used by Oracle “insiders.” In fact, I find the opposite to be true.
They are not well known and they are hardly ever used. Most of these undocumented parameters
are rather boring, actually, as they represent deprecated functionality and backwardcompatibility
flags. Others help in the recovery of data, not of the database itself; for example,
some of them enable the database to start up in certain extreme circumstances, but only long
enough to get data out. You have to rebuild after that.
Unless you are so directed by Oracle Support, there is no reason to have an undocumented
parameter in your configuration. Many have side effects that could be devastating.
In my development database, I use only one undocumented setting, if any:
_TRACE_FILES_PUBLIC = TRUE
This parameter makes trace files readable by all, not just the DBA group. On my development
database, I want my developers to use SQL_TRACE, TIMED_STATISTICS, and the TKPROF
utility frequently (well, I demand it actually); hence they need to be able to read the trace files.
With the advent of external tables in Oracle 9.0.1 and above, we’ll see that we need not use
even this parameter to permit access to trace files.
In my production database, I don’t use any undocumented settings. In fact, the seemingly
“safe” undocumented parameter just mentioned can have undesirable side effects in a live
system. Think about the sensitive information that you might find in a trace file, such as SQL