1 Administering Oracle on UNIX

Oracle Database Environment Variables

Table 1-1 shows the syntax required by the environment variables used with Oracle Database, and provides examples of their values.

UNIX Environment Variables

Table 1-2 shows the syntax required by the UNIX environment variables used with Oracle Database and provides examples of their values.

Setting a Common Environment

This section describes how to set a common UNIX environment.

You use a different script, depending on your default shell:

• For the Bourne, Bash, or Korn shell, use the oraenv command.

• For the C or tcsh shell, use the coraenv command.

Setting the System Time Zone

The TZ environment variable sets the time zone. It enables you to adjust the clock for daylight saving time changes or different time zones. The adjusted time is used to time-stamp files, produce the output of the date command, and obtain the current SYSDATE.

Oracle recommends that you do not change your personal TZ value. Using different values of TZ such as GMT+24 might change the date a transaction is recorded. This changed date affects Oracle applications that use SYSDATE. To avoid this problem, use sequence numbers to order a table instead of date columns.

Maximum Value of DB_BLOCK_SIZE Initialization Parameter

The DB_BLOCK_SIZE initialization parameter specifies the standard block size for the database. This block size is used for the SYSTEM tablespace and by default in other tablespaces.

The maximum value to which you can set the DB_BLOCK_SIZE parameter differs on UNIX platforms, as listed in the following table:

Operating System Specific Default Values for ASM_DISKSTRING

Table 1-3 lists the operating system specific default values for the Automatic Storage Management ASM_DISKSTRING initialization parameter.

Maximum Value for ASYNC in LOG_ARCHIVE_DEST Initialization Parameter

The maximum value that you can set for ASYNC in the LOG_ARCHIVE_DEST initialization parameter differs on UNIX platforms, as listed in the following table:

CLUSTER_INTERCONNECTS Initialization Parameter

In a Real Application Clusters environment, you can use the CLUSTER_INTERCONNECTS initialization parameter to specify an alternative interconnect for the private network.

The CLUSTER_INTERCONNECTS parameter requires the IP address of the interconnect instead of the device name. It allows you to specify multiple IP addresses, separated by colons. Oracle Real Application Clusters network traffic is distributed between all of the specified IP addresses.

The CLUSTER_INTERCONNECTS parameter is useful only in an Oracle Real Application Clusters environment where UDP IPC is enabled. It enables users to specify an interconnect for all IPC traffic that includes Oracle Global Cache Service (GCS), Global Enqueue Service (GES), and Interprocessor Parallel Query (IPQ).

Overall cluster stability and performance might improve when you force Oracle GCS, GES, and IPQ over a different interconnect by setting the CLUSTER_INTERCONNECTS parameter. For example, to use the network interface whose IP address is 129.34.137.212 for all GCS, GES, and IPQ IPC traffic, set the CLUSTER_INTERCONNECTS parameter as follows:

CLUSTER_INTERCONNECTS=129.34.137.212

Use the ifconfig or netstat commands to display the IP address of a device. This command provides a map between device names and IP addresses. For example, to determine the IP address of a device on Tru64 UNIX, enter the following command as the root user:

# /usr/sbin/ifconfig -a 
fta0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX> 
      inet 129.34.137.212 netmask fffffc00 broadcast 129.34.139.255 ipmtu 1500

lo0:  flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM> 
      inet 127.0.0.1 netmask ff000000 ipmtu 4096 

ics0:  flags=1100063<UP,BROADCAST,NOTRAILERS,RUNNING,NOCHECKSUM,CLUIF> 
      inet 10.0.0.1 netmask ffffff00 broadcast 10.0.0.255 ipmtu 7000 

sl0:  flags=10<POINTOPOINT> 

tun0: flags=80<NOARP>

In the preceding example, the interface fta0: has an IP address of 129.34.137.212 and the interface ics0: has an IP address of 10.0.0.1.

Note the following important points when using the CLUSTER_INTERCONNECTS initialization parameter:

• The IP addresses specified for the different instances of the same database on different nodes should belong to network adaptors that connect to the same network. If you do not follow this rule, internode traffic might pass through bridges and routers or there might not be a path between the two nodes at all.

• Specify the CLUSTER_INTERCONNECTS parameter in the parameter file, setting a different value for each database instance.

• If you specify multiple IP addresses for this parameter, list them in the same order for all instances of the same database. For example on Tru64 UNIX, if the parameter for instance 1 on node 1 lists the IP addresses of the alt0, fta0 and ics0 devices in that order, the parameter for instance 2 on node 2 should list the IP addresses of the equivalent network adaptors in the same order.

• If the interconnect IP address specified is incorrect or does not exist on the system, Oracle Database uses the default cluster interconnect device. On Tru64 UNIX, for example, the default device is ics0.

Oracle Software Owner Account

The Oracle software owner account, usually named oracle, is the account that you use to install the Oracle software. You can use different Oracle software owner accounts to install the software in separate Oracle home directories. However, for each Oracle home directory, you must use the same account that installed the software for all subsequent maintenance tasks on that Oracle home directory.

Oracle recommends that the Oracle software owner has the Oracle Inventory group as its primary group and the OSDBA group as its secondary group.

OSDBA, OSOPER, and Oracle Inventory Groups

Table 1-4 describes the special UNIX groups required by Oracle Database.

Oracle Database uses several features of the UNIX operating system to provide a secure environment for users. These features include file ownership, group accounts, and the ability of a program to change its user ID upon execution.

The two-task architecture of Oracle Database improves security by dividing work (and address space) between the user program and the oracle program. All database access is achieved through the shadow process and special authorizations in the oracle program.

Groups and Security

Oracle programs are divided into two sets for security purposes: those executable by all (other in UNIX terms), and those executable by DBAs only. Oracle recommends that you take the following approach to security:

• The primary group for the oracle account should be the oinstall group.

• The oracle account must have the dba group as a secondary group.

• Although any user account that requires the SYSDBA privilege can belong to the dba group, the only user accounts that should belong to the oinstall group are the Oracle software owner accounts, for example, oracle.

External Authentication

If you choose to use external authentication, you must use the value of the OS_AUTHENT_PREFIX initialization parameter as a prefix for Oracle user names. If you do not explicitly set this parameter, the default value on UNIX is ops$, which is case sensitive.

To use the same user names for both operating system and Oracle authentication, set this initialization parameter to a null string, as follows:

OS_AUTHENT_PREFIX=""

Running the orapwd Utility

You can use a password file to identify users that can use the SYSDBA and SYSOPER privileges when connecting to the database. If you use the Database Configuration Assistant (DBCA) to create a database, it creates a password file for the new database. If you create the database manually, create the password file for it as follows:

1. Log in as the Oracle software owner.

2. Use the orapwd utility to create the password file, as follows:

   $ $ORACLE_HOME/bin/orapwd file=filename password=password entries=max_users
   
   

   The following table describes the values that you must specify in this command:

Password Management

When using the Database Configuration Assistant to create a database, users must change the SYS and SYSTEM account passwords. You cannot use the default CHANGE_ON_INSTALL and MANAGER passwords.

For security reasons, the Database Configuration Assistant locks most Oracle user accounts after it creates the database. It does not lock the SYS or SYSTEM accounts. You must unlock any locked accounts and change their passwords before logging into them.

To change the passwords in the DBCA, click the Password Management button in the Database Configuration Assistant Summary window.

Alternatively, use SQL*Plus to connect to the database as SYS and enter the following command to unlock an account and reset its password:

SQL> ALTER USER username IDENTIFIED BY passwd ACCOUNT UNLOCK;

Creating Additional UNIX Accounts

If necessary, create additional UNIX accounts. Users must be members of the OSDBA or OSOPER groups to connect to the database with administrator privileges.

Configuring the Accounts of Oracle Users

Update the startup files of the oracle user and the UNIX accounts of Oracle users, specifying the appropriate environment variables in the environment file.

For the Bourne, Bash or Korn shell, add the environment variables to the .profile file, or on Red Hat Enterprise Linux, the .bash_profile file.

For the C or tcsh shell, add the environment variables to the .login file.

Guidelines for Using Raw Devices

Raw devices (raw partitions or raw volumes) have the following potential disadvantages when used on UNIX:

• Raw devices might not solve problems with file size writing limits.

  
  

  Note: To display current file size limits: For the Bourne, Bash, or Korn shell, enter: $ ulimit -a For the C or tcsh shell, enter: % limit

  
  

• Small client systems might not be able to use sufficiently large partitions or volumes for the raw devices.

• If a particular disk drive has intense I/O activity and performance would benefit from movement of an Oracle data file to another drive, it is likely that no acceptably sized partition or volume exists on a drive with less I/O activity. It might not be possible to move files to other disk drives if you are using raw devices.

• Raw devices are more difficult to administer than data files stored on a file system or in an Automatic Storage Management (ASM) disk group.

Consider the following issues when deciding whether to use raw devices:

• Oracle Real Application Clusters installation

  Each instance of Oracle Real Application Clusters (RAC) has its own log files. Therefore, in addition to the devices required for the tablespaces and control files, each instance requires a minimum of two partitions for the log files. All of the files must be on disks that can be shared by all nodes of a cluster.

• Raw disk partition availability

  Use raw partitions for Oracle files only if you have at least as many raw disk partitions as Oracle data files. If disk space is a consideration and the raw disk partitions are already created, match data file size to partition size as closely as possible to avoid wasting space.

  You must also consider the performance implications of using all of the disk space on a few disks as opposed to using less space on more disks.

• Logical volume manager

  Logical volume managers manage disk space at a logical level and hide some of the complexity of raw devices. With logical volumes, you can create logical disks based on raw partition availability. The logical volume manager controls fixed-disk resources by:

  • Mapping data between logical and physical storage

  • Allowing data to span multiple disks and to be discontiguous, replicated, and dynamically expanded

  For RAC, you can use logical volumes for drives associated with a single UNIX system, as well as those that can be shared with more than one system of a UNIX cluster. Shared drives allow for all files associated with a RAC database to be placed on these shared logical volumes.

• Dynamic performance tuning

  To optimize disk performance, you can move files from disk drives with high activity to disk drives with less activity. Most hardware vendors who provide the logical disk facility also provide a graphical user interface that you can use for tuning.

• Mirroring and online disk replacement

  You can mirror logical volumes to protect against loss of data. If one copy of a mirror fails, dynamic resynchronization is possible. Some vendors also provide the ability to replace drives online in conjunction with the mirroring facility.

Raw Device Setup

Keep the following items in mind when creating raw devices:

• When creating the devices, ensure that the owner is the Oracle software owner user (oracle) and the group is the OSDBA group (dba).

• The size of an Oracle data file created in a raw partition must be at least two Oracle block sizes smaller than the size of the raw partition.

  
  

  See Also: Fore more information about creating raw devices, see your operating system documentation.

  
  

Raw Device Datafiles on AIX or Tru64 UNIX Systems

On AIX and Tru64 UNIX systems, datafiles on raw logical volumes may have offsets for the first block of the Oracle data. This offset is required by the logical volume manager.

You can use the following utility to determine the offset value, for example, if you want to transfer the datafile to a different device:

$ORACLE_HOME/bin/offset

Trace Files

Each server and background process writes to a trace file. When a process detects an internal error, it writes information about the error to its trace file. The file name format of a trace file is sid_processname_unixpid.trc, where:

• sid is the instance system identifier

• processname is a three or four-character abbreviated process name identifying the Oracle Database process that generated the file (for example, pmon, dbwr, ora, or reco)

• unixpid is the UNIX process ID number

A sample trace file name is $ORACLE_BASE/admin/TEST/bdump/test_lgwr_1237.trc

All trace files for background processes are written to the destination directory specified by the BACKGROUND_DUMP_ DEST initialization parameter. If you do not set this initialization parameter, the default directory is $ORACLE_HOME/rdbms/log.

All trace files for user processes are written to the destination directory specified by the USER_DUMP_DEST initialization parameter. If you do not set the USER_DUMP_DEST initialization parameter, the default directory is $ORACLE_HOME/rdbms/log. Set the MAX_DUMP_FILE initialization parameter to at least 5000 to ensure that the trace file is large enough to store error information.

Alert Files

The alert_sid.log file stores information about significant database events and messages. Events that affect the database instance or database are recorded in this file. This file is associated with a database and is located in the directory specified by the BACKGROUND_DUMP_DEST initialization parameter. If you do not set this initialization parameter, the default directory is $ORACLE_HOME/rdbms/log.