In simple terms, a database parameter may be thought of as a key/value pair. You saw an important parameter, db_name, in the preceding chapter. The db_name parameter was stored as db_name = ora11g.
The key here is db_name and the value is ora11g. This is our key/value pair. To see the current value of an instance parameter, you can query the V$ view V$PARAMETER. Alternatively, in SQL*Plus you can use the SHOW PARAMETER command, for example:
ops$tkyte%ORA11GR2> select value 2 from v$parameter
3 where name = 'db_block_size' 4 /
VALUE
--- 8192
ops$tkyte%ORA11GR2> show parameter db_block_s
NAME TYPE VALUE
--- --- --- db_block_size integer 8192
Both outputs show basically the same information, although you can get more information from V$PARAMETER (there are many more columns to choose from than displayed in this example). But SHOW PARAMETER wins for me in ease of use and the fact that it “wildcards” automatically. Notice that I typed in only db_block_s; SHOW PARAMETER adds % to the front and back.
■
Note All V$ views and all dictionary views are fully documented in the Oracle Database Reference manual.Please regard that manual as the definitive source of what is available in a given view.
If you were to execute the preceding example as a less-privileged user (OPS$TKYTE has been granted the DBA role for purposes of this book), you would see instead:
CHAPTER 3 ■ FILES
70
ops$tkyte%ORA11GR2> connect scott/tiger Connected.
scott%ORA11GR2> select value 2 from v$parameter
3 where name = 'db_block_size' 4 /
from v$parameter *
ERROR at line 2:
ORA-00942: table or view does not exist
scott%ORA11GR2> show parameter db_block_s ORA-00942: table or view does not exist
“Normal” accounts are not granted access to the V$ performance views by default. Don’t let that get you down, however. There is a documented API typically available to all users that permits you to see the contents of V$PARAMETER; this little helper function helps you see what is set as a parameter. For example:
scott%ORA11GR2> create or replace
2 function get_param( p_name in varchar2 ) 3 return varchar2
4 as
5 l_param_type number;
6 l_intval binary_integer;
7 l_strval varchar2(256);
8 invalid_parameter exception;
9 pragma exception_init( invalid_parameter, -20000 );
10 begin 11 begin
12 l_param_type :=
13 dbms_utility.get_parameter_value 14 ( parnam => p_name,
15 intval => l_intval, 16 strval => l_strval );
17 exception
18 when invalid_parameter 19 then
20 return '*access denied*';
21 end;
22 if ( l_param_type = 0 ) 23 then
24 l_strval := to_char(l_intval);
25 end if;
26 return l_strval;
27 end get_param;
28 /
Function created.
CHAPTER 3 ■ FILES
If you execute this function in SQL*Plus, you’ll see:
scott%ORA11GR2> exec dbms_output.put_line( get_param( 'db_block_size' ) );
8192
PL/SQL procedure successfully completed.
Not every parameter is available via the dbms_utility.get_parameter_value API call. Specifically, the memory-related parameters such as sga_max_size, db_cache_size, pga_aggregate_target and the like are not visible. We deal with that in the code on lines 17 through 21—we return ‘*access denied*’ when we hit a parameter that we are not allowed to see. If you are curious about the entire list of restricted parameters, you can (as can any account that has been granted EXECUTE on this function) issue the following query:
ops$tkyte%ORA11GR2> select name, scott.get_param( name ) val 2 from v$parameter
3 where scott.get_param( name ) = '*access denied*';
NAME VAL
--- --- sga_max_size *access denied*
shared_pool_size *access denied*
…
olap_page_pool_size *access denied*
24 rows selected.
■
Note You’ll see different results for this query on different versions. You should expect the number and values of inaccessible parameters to go up and down over time as the number of parameters changes.If you were to count the number of documented parameters you can set in each of the database versions—9i Release 2, 10g Release 2, 11g Release 1 and 11g Release 2—you’d probably find 258, 259, 294, and 342 different parameters, respectively (I’m sure there could be additional parameters available on an operating system–specific 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 and before—back to version 6 of Oracle—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. In fact, attempting to use that parameter with subsequent releases raises an error. For example:
ops$tkyte%ORA11GR2> 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
CHAPTER 3 ■ FILES
72
If you would like to review the parameters and get a feeling for what is available and what each parameter does, refer to the Oracle Database Reference manual. The first chapter of this manual examines every documented parameter in detail. On the whole, the default value assigned to each parameter (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, various memory-related parameters, and so on, 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 because 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 backward-compatibility 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:
_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. As we’ll see, with the advent of external tables in Oracle 9.0.1 and above, we need not use even this parameter to permit access to trace files.
■
Note _TRACE_FILES_PUBLIC allows trace files to be read by anyone. Trace files can and do contain sensitive information; in a production database, this parameter should not be set to true for security purposes.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 you might find in a trace file, such as SQL and even data values (see the upcoming section titled “Trace Files”) and ask yourself, “Do I really want any end user to have read access to that data?” The answer is most likely no.
■
Caution Use undocumented parameters only at the request of Oracle Support. Their use can be damaging to a database, and their implementation can—and will—change from release to release.You may set the various parameter values in one of two ways: either just for the current instance or persistently. It is up to you to make sure that the parameter files contain the values you want them to.
When using legacy init.ora parameter files, this is a manual process. To change a parameter value persistently, to have that new setting be in place across server restarts, you must manually edit and
CHAPTER 3 ■ FILES
modify the init.ora parameter file. With server parameter files, you’ll see that this has been more or less fully automated for you in a single command.