Linux With Oracle9i

Managing Oracle on Linux
Student Guide
D16511GC20
Edition 2.0
Februrary 2004
Dxxxxx (Applied)
®
Authors Copyright © 2004, Oracle. All rights reserved.
Ric van Dyke This documentation contains proprietary information of Oracle Corporation. It is
Russ Lowenthal provided under a license agreement containing restrictions on use and disclosure and
is also protected by copyright law. Reverse engineering of the software is prohibited.
If this documentation is delivered to a U.S. Government Agency of the Department of
Technical Contributors Defense, then it is delivered with Restricted Rights and the following legend is
and Reviewers applicable:
Sourish Kundu Restricted Rights Legend

James Spiller
Use, duplication or disclosure by the Government is subject to restrictions for
Mark Fuller commercial computer software and shall be deemed to be Restricted Rights software
Mike Hazel under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013,
Wim Coekarts Rights in Technical Data and Computer Software (October 1988).
John Pokotylo
This material or any portion of it may not be copied in any form or by any means
Tom Raes without the express prior written permission of Oracle Corporation. Any other copying
is a violation of copyright law and may result in civil and/or criminal penalties.
Publisher
If this documentation is delivered to a U.S. Government Agency not within the
Joseph Fernandez Department of Defense, then it is delivered with “Restricted Rights,” as defined in
FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).
The information in this document is subject to change without notice. If you find any
problems in the documentation, please report them in writing to Education Products,
Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065.
Oracle Corporation does not warrant that this document is error-free.
All references to Oracle and Oracle products are trademarks or registered trademarks
of Oracle Corporation.
All other products or company names are used for identification purposes only, and
may be trademarks of their respective owners.
Contents
1 Oracle9i on Linux: Overview

Objectives 1-2
Red Hat, SuSE, and UnitedLinux 1-3
Certification Matrix on MetaLink 1-5
Supported and Suggested Configurations 1-6
Oracle9i Versions 1-7
Supported Hardware 1-8
Linux Distribution: Overview 1-9
Packages 1-10
Linux Kernel 1-11
Verifying the Kernel 1-12
Checking for a Tainted Kernel 1-14
Required Software 1-16
Linux Patches 1-18
Oracle9i Architecture: Overview 1-19
Summary 1-20
Practice Overview: Verifying Installed Software 1-21
2 Preparing the Operating System

Objectives 2-2
Linux Shared Memory: Overview 2-3
Shared Memory Parameters 2-4
Setting Kernel Parameters 2-5
Semaphores 2-6
Setting Semaphore Parameters 2-7
Setting the File Handles Parameter 2-8
Setting Other Parameters 2-9
Viewing Resource Usage 2-10
Package Management 2-11
Conflicting Packages 2-13
Required OS Patches for RHEL 3.0 2-14
Optional Packages 2-16
Configuring the Network 2-17
Configuring the X Window System 2-18
Testing the X Window System 2-19
Supported File Systems 2-21
Recommended File Systems 2-22
Disk Partitioning 2-23
Summary 2-25
Practice: Overview 2-26
iii
3 Installing Oracle9i Software
Objectives 3-2
Creating Groups 3-3
Creating and Viewing a Group 3-4
Creating the Oracle Owner 3-5
Creating the apache User 3-7
Choosing a Shell 3-8
Setting Environment Variables 3-9
User File Creation Mask 3-10
Setting Oracle Environment Variables 3-11
Optimal Flexible Architecture 3-12
OFA Characteristics 3-13
Mount Points 3-14
ORACLE_HOME and ORACLE_BASE 3-15
Installing New Releases 3-16
Managing Multiple Versions 3-17
Setting Oracle Environment Variables 3-19
Setting Variables: Example 3-21
Creating Directories 3-22
Mounting the CD-ROM 3-23
Starting the Installer 3-25
Oracle Universal Installer 3-26
File Locations 3-27
Installation Types 3-28
Database Configuration 3-29
Installation Summary 3-30
Changing the CD-ROM 3-31
Setup Privileges 3-32
Database Accounts 3-33
Password Management 3-34
Configuration Tool Error 3-35
Oracle Software Patches 3-36
Oracle Patch Utility 3-37
Oracle Relink Utilitity 3-39
Troubleshooting 3-40
Summary 3-41
Practice: Overview 3-42
4 Creating a Custom Oracle9i Database

Objectives 4-2
Database Configuration Assistant 4-3
Creating a Database by Using the Database Configuration Assistant 4-4
Database Features 4-5
Database Connection Options 4-6
iv
Initialization Parameters 4-7
Completing the Database Creation 4-8
Oracle Net Services Configuration and Administration Tools 4-9
Oracle Net Manager 4-10
Oracle Net Configuration Assistant 4-11
Testing the Connection 4-12
Summary 4-13
Practice Overview: Creating a Database 4-14
5 Installing and Configuring Enterprise Manager

Objectives 5-2
Starting the Enterprise Manager Configuration Assistant 5-3
Configuring an OMS 5-4
Creating a New Repository 5-5
Installing the Intelligent Agent (IA) 5-6
Intelligent Agent: Postinstallation Steps 5-7
Configuring Enterprise Manager Reporting 5-9
Oracle HTTP Server (OHS) 5-10
The REPORTS_USER Administrator 5-11
Configuring the Report Server 5-12
Oracle Enterprise Manager Reporting Home Page 5-14
Viewing a Predefined Report 5-15
Creating a New Report 5-16
Preferred Credentials for Jobs and Events 5-17
Creating a Job 5-18
Create Job: Tasks and Parameters 5-20
Viewing Job Progress 5-21
Creating an Event 5-22
Create Event: Tests 5-23
Create Event: Parameters 5-24
Create Event: Fixit Jobs 5-25
Viewing Event Status 5-26
Summary 5-27
Practice Overview: Install and Configure Enterprise Manager 5-28
6 Customizing the Oracle9i Database

Objectives 6-2
Controlling Oracle9i 6-3
Linux Startup Sequence 6-4
Linux Runlevels 6-7
Database Startup and Shutdown 6-9
Automating Jobs 6-11
OS Scheduling Tools 6-12
v
Enterprise Manager Job System 6-14
Administrative Scripts 6-15
Database Backups 6-17
Backing Up with RMAN 6-18
Initialization Parameter File 6-19
Summary 6-20
Practice Overview: Automating Tasks 6-21
7 Linux Measurement Tools

Objectives 7-2
Basic Tuning Methodology 7-3
Standard Measurement Tools 7-4
Linux-Unique tools 7-6
Common Areas to Tune 7-8
Monitoring and Tuning CPU 7-9
Is the CPU a bottleneck? 7-10
CPU Measurements 7-12
Measuring CPU Activity with vmstat 7-14
Measuring CPU Activity with mpstat 7-15
Measuring CPU Activity with sar 7-16
Measuring CPU Activity with iostat 7-18
Interpreting CPU Measurements 7-19
Reducing CPU Bottlenecks 7-21
Monitoring and Tuning Memory 7-22
Linux Memory 7-23
Linux Virtual Memory 7-24
Swap 7-25
Measuring Memory Usage 7-27
Measuring Total Memory 7-29
Measuring Memory with vmstat 7-31
Measuring Memory with sar 7-32
Interpreting Memory Measurements 7-34
Linux Large Memory Pages 7-36
Reducing Memory Bottlenecks 7-38
Monitoring and Tuning I/O 7-39
Is I/O a Bottleneck? 7-40
I/O Measurements 7-41
Measuring I/O with iostat 7-42
Measuring I/O with sar 7-44
Measuring I/O with vmstat 7-45
Interpreting I/O Measurements 7-46
Reducing I/O Bottlenecks 7-47
Network Traffic 7-48
vi
Interpreting Network Statistics 7-50
Summary 7-51
Practice Overview: Using Linux Measurement Tools 7-52
8 Oracle9i Measurement Tools

Objectives 8-2
Installing and Configuring Statspack 8-3
Automatically Collecting Statistics 8-5
First Page of the Statspack Report 8-6
Statspack Output 8-7
Correlating Statspack Output with OS Measurements 8-9
Basic Tuning Steps 8-10
Tuning CPU 8-11
Tuning Memory 8-12
Tuning I/O 8-13
Starting Top SQL 8-14
Using Top SQL 8-15
OS Statistics with Enterprise Manager 8-16
Tuning the SGA and PGA on Linux 8-17
Using PGA_AGGREGATE_TARGET 8-19
Using Shared Servers 8-20
Summary 8-21
Practice Overview: Using Oracle9i Measurement Tools 8-22
9 Tuning Oracle9i and Linux

Objectives 9-2
I/O Modes 9-3
Comparing File Systems 9-4
File System Characteristics 9-5
Raw Partitions 9-6
ext2 and ext3 9-7
Oracle Clustered File System 9-8
Disk Guidelines 9-9
Managing Tablespaces and Data Files 9-11
Basic Oracle9i Database Optimizations 9-12
Sizing Database Blocks 9-13
LOG_BUFFER and Redo Log File 9-15
Advanced Features of Oracle Server 9-16
Multiple DBWR Processes 9-17
DB Writer Slaves 9-18
Changing SGA Behavior 9-19
Basic Linux Optimizations 9-20
Enterprise Distribution Features 9-21
vii
Implementing Asynchronous I/O 9-22
Choosing a Kernel 9-24
Implementing a Large SGA 9-25
Standard Linux Memory Map 9-26
Modified Linux Memory Map 9-27
Altering the Linux Memory Map 9-28
Modifying shmmax 9-29
Lowering mapped_base 9-30
Relocating the SGA 9-32
Relocating the Database Buffer Cache 9-33
Summary 9-35
Practice Overview: Tuning Oracle9i and Linux 9-36
Appendix A: Practices
Appendix B: Practice Solutions
Appendix C: Basic Linux and vi Commands
Appendix D: FAQ and RAID
Appendix E: Next Steps: Continuing Your Education

Where Do You Go From Here? E-2
Continuing Education Resources E-3
Oracle University E-4
Oracle University Online Library E-5
Oracle Technology Network E-6
Oracle AppsNet E-7
Oracle MetaLink E-8
Thank You! E-9
viii
Oracle9i on Linux: Overview
Copyright © 2004, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to do

the following:
• Select a supported Linux distribution
and version
• Select the proper Oracle database versions
• Identify Enterprise Linux–level distributions
1-2 Copyright © 2004, Oracle. All rights reserved.
Managing Oracle on Linux 1-2

Red Hat, SuSE, and UnitedLinux
Some supported Linux versions are:

• Red Hat Enterprise Linux AS/ES
• SuSE SLESx
• UnitedLinux
• Monta Vista Carrier Grade Linux
• Miracle Linux Standard Edition (Japan only)
• Red Flag DC Server 4.0 (China and Hong Kong
only)
Red Hat, SuSE, and UnitedLinux

Red Hat Enterprise Linux AS/ES
Oracle Corporation and Red Hat are working together to create a core set of enhancements in the
areas of performance, reliability, clustering and manageability, enabling Linux to support our
customer's mission critical deployments.
For example, the scheduling algorithm has been changed to make it a constant time process that
is independent of the number of processes. This is one example of the change that makes Linux
scalable. Changes to the I/O system include eliminating bounce buffering. Bounce buffering is a
condition where data residing in high memory must be copied to a low-memory buffer before it
can be written to disk.
Another change reduces contention on the io_request_lock by having a lock for each
device instead of one lock for the I/O subsystem. Many device drivers have been enhanced to
make use of the change in I/O locking. A kernel configuration is required to make use of some of
the changes to I/O and virtual memory. These configurations are discussed in a later lesson.

Red Hat, SuSE, and UnitedLinux (continued)
Red Hat Enterprise Linux AS/ES (continued)
A result of this partnership is an enterprise-class distribution from Red Hat and a new support
model from Oracle to deliver critical (Priority 1) operating system–level support to joint
customers. For issues below Priority 1 in severity, Oracle works closely with Red Hat to jointly
resolve the issues. Many of the enhancements for various enterprise features are not included in
the personal versions of Red Hat Linux. Although Oracle will support Red Hat Enterprise Linux
AS/ES on any platform that Red Hat supports (as long as the OS [binary] has not been modified),
Oracle recommends use of RedHat Enterprise Linux Advanced Server 2.1 with kernel errata
2.4.9-e.12 or higher. Oracle does not provide any support if products are installed on a Beta or
Developer's Release. Real Application clusters are certified with Red Hat Enterprise Linux.
Some Oracle products are supported on non-AS/ES versions of Red Hat Linux.
SuSE SLES7 SLES8 and SLES9
Novel’s SuSE has implemented many of the enterprise features that Red Hat has using the 2.4.19
Linux kernel (SLES8) and 2.4.19 kernel (SLES9). Some features, such as asynchronous I/O and
Big Pages, were not implemented in the SuSE distribution at SLES7. SuSE SLES8 supports
asynchronous I/O. SuSE SLES9 will support large memory pages.
UnitedLinux
UnitedLinux was the result of a consortium of Linux vendors. It was based on the SuSE SLES8
kernel. Oracle Real Application Clusters (RAC) are certified on UnitedLinux. The following
products are all powered by UnitedLinux and are certified with Oracle as a result of our
certification with UnitedLinux:
• Conectiva Linux Enterprise Edition
• SCO Linux Server 4.0
• SuSE Linux Enterprise Server 8 (SLES 8) (SuSE withdrew from the UnitedLinux
consortium after being purchased by Novell).
• Turbolinux Enterprise Server 8 Advanced and Basic
Oracle has expanded the direct support offering to include UnitedLinux so that joint customers
can get seamless support from Oracle for both Oracle products and the operating system.
All key Oracle products work with all the popular Linux distributions, but are only supported on
specific ones. Oracle Corporation and Red Hat have collaborated to create a core set of
enhancements in the areas of performance, reliability, clustering, and manageability to enable
Linux to support the enterprise-class deployments of our customers. These efforts have been
integrated into the new distribution from Red Hat called the Red Hat Enterprise Linux Advanced
Server. Additionally, Oracle and UnitedLinux have formed a strategic partnership that includes
technology engagement to enhance the functionality of their Linux platform as well. This
collaboration between Oracle Corporation, Red Hat, and UnitedLinux will continue to enhance
the Linux kernel and benefit all Linux distributions.

Certification Matrix on MetaLink
Certification Matrix on MetaLink

The number of supported Linux platforms and vendors continues to increase rapidly. Existing
Linux vendors are improving and enhancing their software as well. For details on selecting a
platform or a vendor, refer to the Certify and Availability section of Oracle’s MetaLink Web site
at http://metalink.oracle.com.
The Oracle9i database is supported with some of the personal version distributions for Red Hat
and SuSE. For example, Oracle8i 8.1.7 is supported on Red Hat 6.2, 7.0, 7.1; SuSE 7.0, 7.1, and
7.2. Refer to MetaLink Note 68857.1 Oracle on Linux Compatibility Matrix for more details.
The Caldera Open UNIX 8 with LKP (Linux Kernel Personality) distribution is supported.
Oracle’s Intel/Linux binaries run without modifications on SCO Open UNIX 8 with LKP.
Oracle9i Release 2 database is supported only on the enterprise versions of Red Hat, SuSE, and
UnitedLinux. The current direction of Oracle Corporation on Linux is to support the enterprise-
level distributions that are revised at approximately 12–18 month intervals, instead of the
personal version distributions that have new releases at 3–6 month intervals. This gives the
enterprise users a longer window for development and deployment on a stable release.

Supported and Suggested Configurations
Oracle products are certified

on various distributions:
• All key Oracle products
are certified on Red Hat
Enterprise Linux AS and
UnitedLinux.
• For an unbreakable
system, Red Hat
Enterprise Linux AS 2.1,
3.0, SuSE Linux SLES8
or UnitedLinux 1.0 are
recommended.
Supported and Suggested Configurations

Does This Mean I Cannot Run Oracle Products on Other Distributions?
No, you can always run Oracle products on other distributions that provide the required modules
and features.
What Is Oracle Corporation’s Strategy on Linux?
Oracle is fully committed to supporting the Linux operating system. The Oracle database was the
first commercial database available on Linux. By supporting Linux with Oracle’s industry
leading products, Oracle Corporation enables you to deploy enterprise-class solutions on
inexpensive hardware and operating system infrastructure. For customers who want open and
cost-effective solutions, Linux is now more attractive than ever with support from Oracle’s
industry-leading products.
For more information about Oracle Corporation’s support with Linux and making Linux
unbreakable, visit http://www.oracle.com/linux.

Oracle9i Versions
Oracle9i has several versions and patch levels:

• Oracle9i Release 2
– Release 9.2.0.1 initial release 2
– Patch 9.2.0.1 or later required for Real Application
Clusters (RAC)
– 9.2.0.4 latest patch release
• Oracle9i
– 9.0.1.0.0 initial release
– 9.0.1.5 latest patch release
Oracle9i Versions
With Oracle9i Release 2, the release numbering changed. The second digit that was used in
earlier releases was dropped. For the original release of Oracle9i and earlier releases of the
Oracle application server, the significance of each digit in the release number 9.0.1.1.2 was as
follows:
9 was the version number.
0 was the new features release number.
1 was the maintenance release number.
1 was the generic patch set number.
2 was the platform-specific patch set number.
For Oracle9i Release 2 and later, the release number is 9.2.0.4.0, in which:
9 is the major database release number
2 is the database maintenance release number
0 is the application server release number
4 is the component-specific release number
0 is the platform-specific release number

Supported Hardware
• Oracle Corporation does not certify hardware;

only OS platforms.
• Customers must check with the OS vendors for
supported hardware.
Supported Hardware
Oracle Corporation supports Red Hat Enterprise Linux AS on any platform or drivers that Red
Hat supports. It is a requirement that the OS (binary) is not modified. Oracle Support Services
(OSS) has a script to run against a customer’s environment to ensure that the binary has not been
modified. If the binary is modified, then customers must support it themselves or call Red Hat
for technical support. OSS supports all versions of Red Hat Linux AS that Red Hat supports.
For more details, visit http://www.oracle.com/linux.
These statements also apply to other distributions that are supported by Oracle Corporation.

Linux Distribution: Overview
• The core parts of the Linux system are:

– Packages
– The kernel
• Certified distributions are made up of packages
that contain programs.
Linux Distribution: Overview

The Linux software distribution consists of a software set that is provided by a vendor. Red Hat
and others provide the software in the form of packages. Various packages are installed based on
the responses in the install dialog. These are precompiled binaries that can be installed on and
removed from your system at any time with a package manager. Packages can provide the
kernel, kernel patches, modules, applications, and file systems.

Packages
The Linux system is made up of software that

is delivered as packages:
• Packages deliver:
– Applications
– The kernel
– Configurations
• Packages are built from:
– Sources
– Patches
Red Hat Enterprise Linux AS, SuSE, and
UnitedLinux use the Red Hat Package
Manager (RPM) package format.
Packages
Modules
The modules in a Linux distribution can be either kernel based or loadable. Kernel-based
modules have to be compiled in, whereas loadable modules can be added without recompiling.
All the stock kernels include support for loadable modules.
Packages
The Linux software for most of the supported distributions is assembled into packages. These are
precompiled binaries that can be installed on and removed from your system with a package
manager. With packages, you can update the kernel, patch, and add functionality. Some third-
party vendors distribute binary modules that are loaded into the kernel. These modules may be
proprietary modules where the source code is not available for Linux developers to investigate. If
there are such modules loaded, then there is, in essence, a kernel extension that can be fixed only
by the vendor. Oracle Corporation, UnitedLinux, and Red Hat cannot fully support environments
where proprietary modules are loaded.

Linux Kernel
The kernel is the core of the operating system. It is:

• Configurable
• Supportable
– Supplied kernel
– Patched by vendor
– No Tainted modules
Linux Kernel
Linux, like most modern operating systems, has a kernel that is loaded at boot time and stays in
the memory. The kernel in Linux, unlike in many other operating systems, can be customized
infinitely. By compiling your own kernel, you can customize the functions of the kernel to your
needs. You can include or exclude modules that make up the kernel, by using the kernel
configuration file and by recompiling.
If the kernel still does not behave to your satisfaction, there is a code available for you to tweak
it to your specification. This leads to a support problem. If you are running a kernel that is
different than the one Oracle Corporation or Red Hat tested, then OSS cannot identify what the
problem might be when you report trouble with your database or OS.
Oracle Corporation supports only stock or untainted kernels. That means only kernels supplied
by the certified distributions are supported. Kernels that are patched by packages by the kernel
vendor are also supported. For more information about kernel support, see note 228374.1, Linux
Operating System Support, on MetaLink.

Verifying the Kernel
• Execute the uname -r command to see the kernel

version number:
# uname -r
2.4.9-e.3
• Check the version name returned in MetaLink

for support.
Verifying the Kernel

When you have the kernel name, you must compare this with the list on MetaLink to verify
whether it is a supported version.

Verifying the Kernel (continued)
The following table is a partial list of the kernel versions of the currently supported Red Hat
Enterprise Linux AS 2.1. If the version of the kernel shown by uname is not listed, then you are
running an unsupported kernel. This is from the MetaLink note: 225710.1, Red Hat AS 2.1: How
to verify you have a supported kernel. The errata version is the last designation. For example:
e.10enterprise is errata version 10 of the enterprise kernel. An smp release is for a
multiprocessor system. When you install Linux, it installs the smp release automatically when
multiple CPUs are detected. The summit version is used for Summit-NUMA architecture
machines.
Name Release Date
----------------- ---------------------------
. . .
2.4.9-e.10 Thu Nov 14 11:09:11 EST 2002
2.4.9-e.10smp Thu Nov 14 10:55:16 EST 2002
2.4.9-e.10enterprise Thu Nov 14 10:28:55 EST 2002
2.4.9-e.10summit Thu Nov 14 10:03:01 EST 2002
2.4.9-e.12 Tue Feb 11 03:12:29 EST 2003
2.4.9-e.12smp Tue Feb 11 02:24:10 EST 2003
2.4.9-e.12enterprise Tue Feb 11 01:29:18 EST 2003
2.4.9-e.12summit Tue Feb 11 00:25:20 EST 2003
2.4.9-e.16 Mon Mar 17 17:14:18 EST 2003
2.4.9-e.16smp Mon Mar 17 16:55:45 EST 2003
2.4.9-e.16enterprise Mon Mar 17 16:37:14 EST 2003
2.4.9-e.16summit Mon Mar 17 16:11:58 EST 2003
2.4.9-e.24 Tue May 27 16:15:51 EDT 2003
2.4.9-e.24smp Tue May 27 16:07:39 EDT 2003
2.4.9-e.24enterprise Tue May 27 15:59:23 EDT 2003
2.4.9-e.24summit Tue May 27 15:51:38 EDT 2003
2.4.9-e.25 Fri Jun 6 18:27:21 EDT 2003
2.4.9-e.25smp Fri Jun 6 18:11:40 EDT 2003
2.4.9-e.25enterprise Fri Jun 6 17:55:13 EDT 2003
2.4.9-e.25summit Fri Jun 6 17:29:49 EDT 2003
2.4.9-e.27 Tue Aug 5 15:59:55 EDT 2003
2.4.9-e.27smp Tue Aug 5 15:49:54 EDT 2003
2.4.9-e.27enterprise Tue Aug 5 15:39:21 EDT 2003
2.4.9-e.27summit Tue Aug 5 15:25:20 EDT 2003
Note: Check this note on MetaLink for the latest supported kernel because the list changes
frequently.

Checking for a Tainted Kernel
Execute the /sbin/lsmod command to see whether

the kernel is tainted:
# /sbin/lsmod
Module Size Used by Not tainted
nfs 87936 0 (autoclean)
lockd 60224 0 (autoclean) [nfs]
sunrpc 79952 0 (autoclean) [nfs
lockd]
iptable_filter 2912 0 (autoclean) (unused)
ip_tables 14080 1 [iptable_filter]
ad1848 23968 0 [cs4232]
ext3 70240 5
jbd 51004 5 [ext3]
Checking for a Tainted Kernel

The lsmod command returns a list of currently loaded modules. When interpreting the output
of this command, the first column is the name of the module, the second column is the size, and
the third column is the use count. The fourth column varies. It may contain a list of dependent
modules in brackets, or it may be maintenance comments such as (autoclean). What you
want to see when running this command is the phrase Not tainted on the first line.
If the word Tainted is listed, then this indicates that the kernel is not supported. The values
listed by Tainted are as follows:
• P means that a proprietary binary module is loaded that does not contain a General Public
License (GPL).
• F means a module has been Force loaded. Force-loaded modules bypass the kernel/module
verification checks.
Here is an example with a proprietary driver loaded (the output has been formatted to fit):
Module Size Used by Tainted: P
nfs 91936 0 (autoclean)
lockd 61184 0 (autoclean) [nfs]
sunrpc 86032 0 (autoclean) [nfs lockd]
autofs 13796 1 (autoclean)
. . .

Checking for a Tainted Kernel (continued)
To discover which module is tainted, obtain the licensing information for the loaded kernel
modules. Execute these commands in a bash shell script:
for i in `cat /proc/modules|awk '{print $1}'` ;
do
x=`/sbin/modinfo -n $i` ;
echo $x;
size $x ;
/sbin/modinfo -l $i ;
/sbin/modinfo -p $i ;
done
The resulting output will look like the following:
# /sbin/modinfo cisco_ipsec
filename: /lib/modules/2.4.9-e.12smp/CiscoVPN/cisco_ipsec
description: <none>
author: <none>
license: <none>
Modules with a license value other than GPL are tainted and not supported. Modules that have a
GPL are open source and are supported by both Red Hat and Oracle Corporation. Modules that
have a GPL are not tainted.
For more information about GPL, refer to the following:
http://www.opensource.org/licenses/gpl-license.php
http://www.gnu.org/philosophy/free-sw.html
After you have found the tainted module, check the output of the lsmod command again. If the
module has no dependents, it can be unloaded from the kernel with the command:
rmmod <module_name>
If the module has a comment such as (autoclean)(unused), then you may also be able to
use the command:
rmmod –a
This is the autoclean command. It removes ALL kernel modules marked autoclean that
have not been used since the last autoclean was executed.

Required Software
Check the kernel and libraries that are installed:

• Identify the distribution.
• Check whether the kernel is acceptable.
• Check the version of glibc.
Required Software
Use the following commands to verify your software.
Identifying Release
Red Hat: Use the command: cat /etc/redhat-release
United/SuSE: Use the command: cat /etc/lsb-release
Identifying the Kernel
You can find out which Linux kernel version you are using by entering the command:
# uname -r
Identifying the Installed Version of glibc
You can find out what version of glibc libraries you are using by entering the RPM command:
# rpm -q glibc
For example:
# rpm -q glibc
glibc-2.2.4-26

Required Software (continued)
Identifying the Installed Version of glibc (continued)
If you do not want to use rpm, you can check the glibc version with the following command:
$ ls -l /lib/libc.so*
lrwxrwxrwx 1 root root 13 Feb 25 10:45 /lib/libc.so.6 -> libc-2.2.4.so
The libc*.so file is installed from the glibc package. Therefore, you can see that the
glibc library is 2.2.4.
Other Distributions
If your OS Linux distribution is not certified, then you must compare the kernel version and C
libraries (glibc) of your Linux distribution with a certified distribution. To find the certified
versions, you can install a certified Linux version or try to find information about Linux Web
sites such as http://www.suse.com and http://www.redhat.com.
If the kernel version and C libraries of your distribution are the same as that of a certified Linux
version, then it is likely that Oracle products will work on that distribution. But there is no
guarantee from Oracle Corporation that any Oracle product will work, and this configuration is
not supported by OSS.

Linux Patches
Apply the patches recommended by the distribution

vendor:
• Red Hat Network supplies patches automatically.
• Other distribution vendors have patch channels.
Linux Patches
Linux distribution vendors do not supply mega-patches like other UNIX vendors, but supply
patches for components. The latest version of all the patches are tested to work together. Each
distribution vendor will have a subscription service and a method for distributing patches. For
example, Red Hat uses the Red Hat Network. SuSE uses the SuSE Update Channel. The latest
patches should be applied; especially the kernel patches and the security patches.

Oracle9i Architecture: Overview
User process
Instance
Database
Oracle9i Architecture
Oracle9i Server consists of a database, an instance, and server processes. The server processes
act on behalf of the user.
The database is a set of files that includes the data files, control files, and redo log files.
The instance is the System Global Area (SGA) and background processes such as LGWR, DBWn,
ARCn, and SMON.
Each server process has a private memory area called Program Global Area (PGA). Server
processes can be dedicated or shared. Each dedicated server process handles only one user
session. Each shared server process handles requests from multiple users.
The Oracle9i Server depends on Linux for the I/O subsystem, memory handling including virtual
memory, swap, and process scheduling.
For more information about Oracle9i architecture, refer to Oracle9i Database Concepts and
enroll in the Oracle9i Database Administration Fundamentals I course.

Summary
In this lesson, you should have learned how to:

• Select a supported Linux distribution
and version
• Select the proper Oracle database versions
• Identify Enterprise Linux–level distributions

Practice Overview:
Verifying Installed Software
This practice covers identifying:

• The installed kernel
• Tainted modules
• The installed library
Practice 1 Overview: Verifying Installed Software

For detailed instructions on performing this practice, see Practice 1 in Appendix A.

Preparing the Operating System

Objectives

the following:
• Configure the operating system (OS) kernel
• Install the required OS patches
• Configure the Linux network
• Select a file system
• Configure the X Window System

Linux Shared Memory: Overview
Shared memory is a system resource used for

interprocess communication. It has the following
characteristics:
• Shared memory is allocated in segments.
• Segments have a maximum size.
• A limited number of segments can be allocated.
Linux Shared Memory: Overview

The shared memory system on Linux works much like the shared memory on other UNIX
platforms. Shared memory is allocated in segments. The maximum number of systemwide
shared memory segments is set by a kernel parameter SHMMNI. The maximum size of each
segment is determined by SHMMAX. A segment is not necessarily as large as the maximum size;
it is only as big as is allocated. If a process needs a larger shared memory area than can be
allocated in one segment, then it may allocate multiple segments.
Database instances often allocate multiple segments to accommodate a large SGA. The
maximum number of segments to which one process may attach is set by SHMSEG.
Refer to MetaLink note 153961.1, Semaphores and Shared Memory – An Overview, for details
about setting shared memory parameters for your Oracle database. For more information, refer to
MetaLink note 15566.1, TECH: Unix Semaphores and Shared Memory Explained.

Shared Memory Parameters
The following are the shared memory parameters in

Linux that are set for Oracle9i Release 2:
• shmmax
– Maximum size of any segment
– Set to a default value greater than half of the real
memory, or 2 GB
• You should leave shmall, shmmni, and shmseg at
their default values.
Shared Memory Parameters

Of the shared memory parameters shmmax is the most important. This parameter limits the size
of all the shared memory segments on the system. shmmax must be equal to or larger than the
largest SGA on the system; otherwise the SGA is made up of multiple memory segments. If an
SGA is made up of more than one segment, then it is less efficient than the one that is in one
segment. The maximum value of this parameter is 4 GB.
Other parameters that influence the use of shared memory must be left to defaults for Oracle9i
Release 2. These parameters include:
• shmall: This defines the maximum amount of shared memory that may be in use at any
time on the system.
• shmmni: This defines the maximum number of shared memory segments across the
system.
• shmseg: This defines the maximum number of shared memory segments to which a single
process can attach.
Refer to MetaLink note 201370.1, LINUX: Quick Start Guide - 9.2.0 RDBMS and Installation
Guide Release 2 (9.2.0.1.0) for UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX, HP
9000 Series HP-UX, Linux Intel, and Sun Solaris for more details.

Setting Kernel Parameters
• For the current run-time environment only:
# cd /proc/sys/kernel
# echo 2147483648 > shmmax
• For every boot up:
# vi /etc/sysctl.conf
…
kernel.shmmax = 2147483648
…
# sysctl -p
Setting Kernel Parameters

To view the current values of kernel parameters, use the utility sysctl:
# sysctl –a
With dynamic parameters, you can set the kernel parameters without having to rebuild the kernel
or reboot. This is done by writing a value into the /proc file system for shmmax. When this is
done, the value changes immediately. You must have root privileges to perform this operation.
This change is not permanent, that is, it does not take effect the next time the system is booted.
To make this change permanent, the kernel must be recompiled with the new parameter value,
but the change may be made on each boot up. A good way to do this is to change the
/etc/sysctl.conf file as shown above. After changes have been made to sysctl.conf,
use the sysctl –p command to reinitialize the kernel with the new values.
Note: Different distributions may use different files for startup. Check the documentation for
your distribution for details. SuSE and UnitedLinux distributions will not normally have a
sysctl.conf file located in /etc, so you will have to create one.
If you make a mistake and your system does not start, then you must start Linux in single-user
runlevel (usually runlevel 1). In single-user runlevel, the /etc/sysctl.conf file is not run.
The different runlevels will be discussed in detail later.

Semaphores
Semaphores control access to critical resources, code,

and shared memory:
• semmsl
– Maximum number of semaphores per set
• semmns
– Total number of semaphores in the system
• semopm
– Maximum number of operations per
semop call
• semmni
– Maximum number of semaphore sets
Semaphores
Semaphores are a robust method of controlling access to critical resources. The Oracle instance
uses semaphores primarily to control access to shared memory. Semaphores are allocated based
on the PROCESSES initialization parameter.
Each Oracle instance tries to allocate one semaphore set at startup. This set must allocate at least
as many semaphores as the value of PROCESSES. If it does not, then the Oracle instance gets
more sets to satisfy the number of semaphores that it needs. If the instance cannot allocate
enough semaphores (either in one set or in multiple sets), then the instance does not start.
For Oracle9i Release 2, the instance momentarily allocates the number of semaphores that is two
times the PROCESSES initialization parameter. This is to ensure that the Oracle instance does
not exhaust a system of its semaphores. This is only for a very short time and half of the
semaphores are then released.
Refer to MetaLink note 153961.1, Semaphores and Shared Memory – An Overview, and
15654.1, Calculating Oracle’s SEMAPHORE Requirements, for details about setting semaphore
parameters for your Oracle instance.

Setting Semaphore Parameters

# echo 250 32000 100 142 > sem
• For every time the system boots up:

…
kernel.sem = 250 32000 100 142
…
# sysctl -p
• The positional meaning of kernel.sem is:
semmsl_value semmns_value semopm_value semmni_value
Setting Semaphore Parameters

Changing the kernel parameters for semaphores works the same way as the shared memory
parameters.
All the semaphore parameters are set in one file, the sem file in the /proc/sys/kernel
directory.
Like shared memory parameters, these are dynamic parameters and must be set during each boot
up. Editing the /etc/sysctl.conf file will force these parameters to be set on each boot up.
Here are some general recommendations for the settings of the semaphore parameters on Red
Hat Enterprise Linux (RHEL) 3.0. You must test and adjust these depending on your system:
For semmsl – 250 or the largest PROCESSES parameter of an Oracle database plus 10
For semmns – 32000 or sum of the PROCESSES parameters for each Oracle database, adding
the largest one twice, and adding an additional 10 for each database
For semopm – 100
For semmni – 142

Setting the File Handles Parameter

# echo 327679 > /proc/sys/fs/file-max

…
fs.file-max = 327679
…
# sysctl -p
Setting the File Handles Parameter

File Handles is the parameter that determines the maximum number of files that each process
can open. The Oracle background database processes open all the database files and keep them
open until the database is closed, so fs.file-max needs to be high enough to contain all the
data files within your database. The Oracle9i Release 2 database can have up to 65,536 data
files.
This value is set in /proc/sys/fs/file-max. The default value of 8192 is not adequate for
databases with many data files. Like all the kernel parameters, you must test and adjust these
depending on your system but the recommended starting point for RHEL 3.0 is 327679.

Setting Other Parameters

# echo 1024 65000 >
/proc/sys/net/ipv4/ip_local_port_range

…
net.ipv4.ip_local_port_range = 1024 65000
• Setting the process limit:

# ulimit -u 16384
Setting Other Parameters

Setting Socket Parameters
An IP port is assigned to a database dedicated server process when it starts. The IP port is used to
communicate with the user process. By default, the range available is 32768 through 61000. In
some databases with a very large number of users, the default range of ports that are available to
nonroot processes may not be adequate. In the example in the slide, set the IP port range from
port 1024 through 65000, these ports may be used for Oracle Net connections. Ports below 1024
are reserved for processes running with root privileges.
Setting the Process Limit
The default of 2047 for the maximum number of processes that a user can start is too low for
many database servers. The Oracle database user owns and starts all the background processes,
server processes, and possibly the parallel query and dispatcher processes. This process limit can
only be set by the root user. The process limit value should be set at boot up or before the
database is started. Place the ulimit command shown above in the /etc/rc.d/rc.local
file, or add it to the automated database startup scripts that are discussed in the lesson titled
“Customize the Oracle9i Database.”

Viewing Resource Usage
Shared memory and semaphore usage on your system

can be viewed with the following commands:
# ipcs -m
# ipcs -s
# ipcs -a
Viewing Resource Usage

When a database creation fails, or when an instance does not start due to a memory or
semaphores error, you should be able to view the shared memory and semaphores allocations on
the system. This helps you detect the error.
• To display the shared memory segments, use: ipcs -m
• To display the semaphore sets, use: ipcs -s
• To display all resources allocated, use: ipcs -a
An example:
# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 524288 oracle 640 4194304 12
0x00000000 557057 oracle 640 201326592 12
0x9808bbd8 589826 oracle 640 205520896 60
0x152464c8 622595 oracle 640 142606336 85

Package Management
Patches for Red Hat, SuSE, and UnitedLinux are

managed with the Red Hat Package Manager (rpm)
utility. This utility is used to install, upgrade, remove,
and query packages
• To determine whether or not a package is
installed:
# rpm –q <package name>
• To install a package:
# rpm –ivh <package name>
• To remove a package:
# rpm –e <package name>
Managing Packages
The recommended method for installing operating system patches and additional functionality is
to apply packages from the distribution vendor. Apply packages with rpm, a command-line
utility with several options for querying, verifying, installing, upgrading, and removing
packages. Despite the name, rpm is used with many Linux distributions, including SuSE and
UnitedLinux. Although other package managers are available, the rpm command-line utility is
the most ubiquitous and easiest-to-use tool.

Managing Packages (continued)
The rpm utility accepts several command-line arguments including:
• -q Queries the system for a package. A special argument, -qa, lists ALL installed packages.
This list can then be filtered by piping to a grep command, for example:
#rpm -qa |grep gcc
gcc-2.96-108.1
• -i Installs the named package. Optional argument –h shows hash marks on the screen to
indicate progress. Optional argument –v returns a verbose output, for example:.
#rpm -ivh my_new_package-1.0-14.i386.rpm
Preparing... ####################################### [100%]
1:my_new_package ####################################### [100%]
• -e Erases/removes the selected package. Optional arguments –h and –v are can also be
used, for example:
# rpm -ev IBMJava2-JRE
• -U Removes the current package and replaces it with a different version (upgrade).
Note: The replacement happens without removing any existing configuration files. This is
used when upgrading kernel packages because you cannot remove the existing kernel
before installing a new one.
rpm -Uh kernel-2.4.9-e.27.i686.rpm
Preparing... ####################################### [100%]
1:kernel-2.4.9-e27 ####################################### [100%]

Conflicting Packages
• Both UnitedLinux and Red Hat Linux 2.1 are

shipped with packages that should be removed
before installing the Oracle database.
– Java Packages
– Apache Packages
# rpm –e IBMJava2-JRE
• Red Hat Linux 3.0 is shipped with the correct Java

packages.
Conflicting Packages
Both Red Hat 2.1 and UnitedLinux 1.0 are shipped with Java Runtime Environment by default.
These should be removed to prevent possible conflicts with the software that will be installed
with the Oracle9i Database. Blackdown JRE 1.1.8 v3 and Sun JDK 1.3.1_02 are required for
Oracle server installations. These are provided with the Oracle9i Release 2 installation software.
For Red Hat Enterprise Linux Advanced Server 2.1, remove the IBM Java Runtime Environment
with the following command:
# rpm -e IBMJava2-JRE
For Red Hat Enterprise Linux 3.0, there are no conflicting packages.
For UnitedLinux 1.0 and SuSE SLES8, remove the following packages (in this order due to
dependencies):
# rpm -e jserv
# rpm -e mod_php4-servlet
# rpm -e jakarta-tomcat
# rpm -e java2
# rpm -e java2-jre

Required OS Patches for RHEL 3.0
When installing on Red Hat Enterprise Linux 3.0,

ensure that the following patches are installed:
• Compatibility packages
• openmotif21-2.1.30-8.i386.rpm
• setarch-1.3-1
• gnome-libs-1.4.1.2.90-34.1
• openmotif21-2.1.30-8
• libcwait.so
# gcc --version
2.96
Required OS Patches for RHEL 3.0

RHEL 3.0 is shipped with a newer version of the C and C++ libraries than version 2.1 or United
Linux 1.0. To successfully install Oracle9i, you must load the compatibility libraries so that
Oracle software can access the older C libraries and compiler:
• compat-db-4.0.14.5
• compat-gcc-7.3-2.96.122
• compat-gcc-c++-7.3-2.96.122
• compat-libstdc++-7.3-2.96.122
• compat-libstdc++-devel-7.3-2.96.122
Note: This partial list includes libraries often overlooked when RHEL 3.0 is initially installed.
There are hundreds of RPMs required to install Oracle9i on RHEL 3.0. If you selected the
“legacy development packages” and “gnome development packages” during your operating
system installation, then the libraries should already be installed.
After installing the compatibility libraries, you must ensure that the correct C and C++ compilers
are used for the installation.
# mv /usr/bin/gcc /usr/bin/gcc323
# mv /usr/bin/g++ /usr/bin/g++323
# ln -s /usr/bin/gcc296 /usr/bin/gcc
# ln -s /usr/bin/g++296 /usr/bin/g++

Required OS Patches for RHEL 3.0 (continued)
Test the compiler version by running the compiler with the --version flag:
# gcc –-version
2.96
# g++ --version
2.96
The version must return 2.96 in order for Oracle9i to install successfully.
setarch-1.3-1 provides libraries required for Oracle’s memory management features. If this
package is not installed, the installation will still be successful, but you may experience problems
during database operation.
The Oracle HTTP server requires openmotif21-2.1.30-8 to start.
The gnome-libs-1.4.1.2.90-34.1 patch provides libdb.so.2, a required C library for the agent and
HTTP server configuration.
Note: This does NOT mean you must use the GNOME desktop, only that the development
libraries must be loaded.
libcwait.so furnishes a c-library required by Oracle Universal Installer (OUI). Unlike the other
OS patches, this library is not furnished by an RPM, but by Oracle Patch number 3006854. You
may download this patch from MetaLink, or you can manually create the library as follows:
gcc -O2 -shared -o /etc/libcwait.so -fpic /labs/libcwait.c
The libcwait.c source code is:
#include <errno.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/wait.h>
pid_t
__libc_wait (int *status)
{
int res;
asm volatile ("pushl %%ebx\n\t"
"movl %2, %%ebx\n\t"
"movl %1, %%eax\n\t"
"int \$0x80\n\t"
"popl %%ebx"
: "=a" (res)
: "i" (__NR_wait4), "0" (WAIT_ANY), "c"
(status), "d" (0), "S" (0));
return res;
}
After the source code has been compiled, ensure that it is preloaded before running the universal
installer by creating the file /etc/ld.so.preload with the following contents:
/etc/libcwait.so
Alternatively, you can preload the libcwait.so library by setting the LD_PRELOAD environment
variable:
LD_PRELOAD=/etc/libcwait.so

Optional Packages
Optional packages that may be installed:

• pdksh: Public domain Korn shell
• ssh: Secure shell
• xosview: X-based OS viewer
• xcpustate: X-based CPU monitor
Optional Packages
The optional packages listed above are usually available on the Red Hat distribution and
UnitedLinux CDs.
To install these, use a package manager or rpm. The following is an example of installing
pdksh:
$ rpm -ivh pdksh-5.2.14-13.i386.rpm
To test the install but not actually install, use the test option:
$ rpm -iv --test pdksh-5.2.14-13.i386.rpm
Warning: Packages that taint the kernel are not supported and make the platform unsupported.

Configuring the Network
The network must be configured for Oracle software to

install properly:
• Use the Linux installation dialog.
• After installation, use tools such as YaST or
redhat-config-network.
• Set the network address:
– Set the domain and domain name server (DNS)
– Set the hosts
Configuring the Network

The Oracle Installer assumes that there is a network interface and, therefore, the network must be
configured before the Oracle Universal Installer is run. Before you install Linux, gather the
required information from your network administrator: the IP address, the domain name, and the
address of the domain name server (DNS). Usually, the Linux installer guides you through the
steps to configure your network.
If DNS is not being used, then the names and addresses of all the other machines that you want
to connect to should be added to the /etc/hosts file. The minimum information that is
required in this file are the name, the aliases, and the address of the machine. If you add network
cards after the installation, additional modules may need to be loaded. The network
configuration can be modified after the Linux installation by using tools such as redhat-
config-network or YaST. Refer to your Linux documentation for details.

Configuring the X Window System
Install and configure the X Window System with the

distribution installation.
• Before the installation:
– Determine the monitor model number
– Determine the graphics card model number or
chipset
• After installation, change the configuration with
the following tools:
– On SuSE, use sax2.
– On Red Hat, use Xconfigurator.
Configuring the X Window System

Oracle Universal Installer (OUI) is a Java-based product, and Java calls the X Window System
on UNIX and Linux operating systems. Even if you want to use the silent install method, the X
Window System must be enabled. This is usually accomplished during the installation of the
Linux distribution.
If the X Window System configuration needs to be changed after the installation, there are
several files such as /etc/X11/XF86Config where the X Window System configuration
information is kept. There are also tools that allow the X Window System to be reconfigured.
SuSE provides the sax2 tool and Red Hat provides Xconfigurator that configure the X
Window System to work with your graphics card and monitor. Some cards and monitors cannot
be probed by the configuration programs to discover their characteristics.
You must know the monitor model number, the graphics card model, the video memory size, and
the chipset before configuring these items. With this information, you are able to configure your
system correctly with the X Window System configuration tool.

Testing the X Window System
Test the X Window System with an X client:

• Set the DISPLAY variable:
– Get the host name of the X server.
– Set and export:
DISPLAY=hostname:0.0
Export DISPLAY
• Check xhosts:
xhost +hostname
• Run xclock:
xclock
Testing the X Window System

The X server is the machine where you are viewing the screen. The X client is a process, running
somewhere, that sends the display to where you will be viewing it. In the case of the OUI, X
server is the machine in which you view the output, and X client is the machine where the
installer runs the database server. To make sure that the installer runs in this configuration, first
verify that the X server has connectivity to the database server, and use telnet to make a
connection. If telnet does not work, check the hardware, the wiring, and the host resolution.
The host names are translated into IP addresses by either a DNS or through the /etc/hosts
file. The ping, host, and dig utilities can provide good diagnostic information for solving
connection problems.
After a telnet connection is established to the database server where the Oracle software will
be installed, you must set and export the DISPLAY variable. This variable directs the Oracle
Installer where to display the install screens. The DISPLAY variable contains the host name or
IP address and the display number.
For the X server to accept the display from another machine, xhost must be executed on the
machine where the display is viewed. As the owner of the display (the logged-in user) execute
xhost +hostname where hostname is the name or IP address of the database server where
the installer is running.

Testing the X Window System (continued)
On the X server, issue a hostname command to find the name of the X server. In the following
example, the machine jspiller-us is the X server where the installer will display the output.
Check which hosts are allowed to connect to the X server machine with xhosts. With xhost
+<hostname> add the name of the database server to the X access control list. In this example,
the machine delphi is the database server where the installer will be running:
$ hostname
jspiller-us
$ xhost
Access control enabled, only authorized clients can connect
$ xhost +delphi
Delphi being added to access control list.
Connect to the database server, with telnet, set the DISPLAY variable and start an X client.
$ telnet delphi
$ DISPLAY=jspiller-us:0.0
$ export DISPLAY
$ xclock
The xclock client should appear on the X server screen or an error message should appear in
the telnet session.
The DISPLAY variable may also be set by using the IP address instead of the name as:
$ DISPLAY=192.168.1.2:0.0
This method is sometimes helpful when the host name resolution must be bypassed.
For further information about the commands used in this lesson, refer to Appendix C, or the man
and info pages on your Linux system.

Supported File Systems
• Linux supports multiple file systems.

• Oracle Corporation does not certify file systems.
• Criteria for choosing a particular file system are:
– Reliability
– Performance
– Security
Supported File Systems

One of the most interesting features of the Linux OS is its support for multiple file systems.
File systems can be defined and built on a partition basis; vfat, ext2, ext3, and reiser file
systems can coexist on the same Linux system, along with several other file systems and raw
partitions. Your choice of which one to use should be based on supportability, reliability,
security, and performance.
Oracle Corporation does not certify file systems, but does certify operating systems. So the file
systems that are supplied with the Red Hat Enterprise Linux AS and supported by Red Hat are
acceptable for Oracle software use. The same is true for the file systems supplied by SuSE and
UnitedLinux. These include ext2, ext3, and reiserfs. To be acceptable for database use,
the file system must perform certain minimum functions such as write acknowledge, write-thru
cache, and file permissions. Examples of file systems that are not normally acceptable for
database use are simple Network File System (NFS), which lacks acknowledge, and Virtual File
Allocation Table (VFAT), which lacks file permissions.

Recommended File Systems
• ext2 file system

• ext3 file system (recommended)
• reiser file system
• Oracle Cluster File System (OCFS)
http://otn.oracle.com/tech/linux/open_source.html
Recommended File Systems

The ext2 file system is a robust file system, and is fully supported.
The ext3 file system is built on the ext2 base. It has good performance characteristics and is
the default file system for the Red Hat Enterprise Linux AS distribution. reiserfs is the
default for UnitedLinux. Both are supported and either can be used. The ext3 file system is
recommended and it is used in the practices for all lessons in this course.
Oracle Cluster File System (OCFS) is a shared file system designed specifically for Oracle Real
Application Clusters (RAC). OCFS eliminates the requirement for Oracle database files to be
linked to logical drives. OCFS volumes can span one shared disk or multiple shared disks for
redundancy and performance enhancements. OCFS is not part of the Red Hat Distribution, but
Oracle Corporation makes it available on the Oracle Technical Network for download at:
http://otn.oracle.com/tech/linux/open_source.html.
Refer to MetaLink notes 220178.1, Installing and setting up OCFS on Linux – Basic Guide, and
236826.1, Supported and Recommended File Systems on Unbreakable Linux for more details.
The performance characteristics of the different file systems are discussed later in the course.

Disk Partitioning
Linux uses disk partitions effectively to segregate

directories and ease recovery:
• /boot
• /
• /var/log
• /tmp
• /home
• /<mount_point>/oracle
Disk Partitioning
Disk partitioning is not required by Linux or by Oracle software. However, disk partitioning can
reduce the time consumed in operations such as planning for recovery, upgrades, and backups.
The larger the partition the longer a file system check (fsck) operation takes on boot up. Much
of this time can be avoided by using a journaled file system such as ext3. Having a small
/boot partition that holds only the current kernels separates the tasks of booting the machine
and recovering a partition. A typical size of this partition is from 10 MB to 100 MB. Red Hat
recommends approximately 50 MB for boot partition.
The / partition should hold only a few directories that are created with the distribution
installation. These directories are overwritten with a new installation or upgrade. (Keep track of
any customized configuration files that you place under this partition, because they will also be
overwritten during a new installation or upgrade).
The /var/log and /tmp should be separate partitions to isolate the effects of runaway
processes. The /tmp partition should be at least 400 MB.

Disk Partitioning (continued)
If these separate partitions get filled up, the process dies or stops logging. If these directories fill
up when they are on the / partition, the system can crash. If /home is a separate partition, it can
be backed up and restored separately. An OS upgrade need not touch this partition.
Oracle software and data files work well with multiple partitions—one for the Oracle software
and others for the database files. With the growing sizes of disk drives, there is a temptation to
make a few very large partitions, such as one per disk drive. This may be appropriate for disks
that are dedicated to database files, but you must consider backup, recovery, and upgrade issues
first.

Summary

• Configure the operating system (OS) kernel
• Install the required OS patches
• Configure the Linux network
• Select a file system
• Configure the X Window System

Practice: Overview
This practice covers the following topics:

• Configuring dynamic kernel parameters
• Configuring and testing the operating system
• Applying patches to the operating system
Practice 2: Overview

Installing Oracle9i Software

Objectives

the following:
• Create the OS user oracle
• Configure the Oracle9i OS environment
• Install Oracle9i software by using the Oracle
Universal Installer (OUI)
• Create a General Purpose database with OUI
• Install patch sets and temporary patches

Creating Groups
Create the groups that are required for your site:

• ORAINVENTORY group:
– Is typically named oinstall
– Administers the Oracle software
• OSDBA group:
– Has the default name dba
– Administers the database files
dba oinstall
Creating Groups
The Oracle installation guide names three group identifiers, ORAINVENTORY, OSDBA, and
OSOPER. The members of OSDBA group own the database files and have the privilege to
connect to the database without a password, using AS SYSDBA through OS authentication. The
OSOPER group uses the same mechanism to connect with AS SYSOPER with a restricted set of
privileges. Each database may have its own OSDBA and OSOPER groups. The ORAINVENTORY
group has privileges on the software. A DBA that is a member of both OSDBA and
ORAINVENTORY has privileges in specific database instances and the ability to access and
upgrade the software through the ORAINVENTORY group.
An OSDBA group must be created to manage the database files. By default this group is dba, but
this name is arbitrary. If only one group of DBAs administers the databases on this server, then
this group may be the same as the ORAINVENTORY group for all the databases on this server.
When there are multiple groups of DBAs, each administering different databases on the same
server, you should create a separate ORAINVENTORY group to own the Oracle software. This
group is commonly called oinstall. For each set of databases that will have a common set of
DBAs, create an additional OSDBA group. This allows each DBA to have privileges in the
database of responsibility but not in other databases.

Creating and Viewing a Group
• To create a group:
# groupadd -g 500 dba
• To view the group:
# grep dba /etc/group

dba:x:500:
Creating and Viewing a Group

In Linux, the root user can execute the groupadd command to create a group. The group ID or
gid must be unique. IDs below 500 are typically reserved for system accounts. The -g is
optional; if the group ID is not specified, then the first available group ID above 499 will be
assigned. This command places an entry in the /etc/group file.
To verify whether the group was created, view the /etc/group file.
In the X Window System environment, there are multiple tools available to manage users and
groups. Red Hat provides redhat-config-user and kuser, the KDE User Manager. SuSE
and UnitedLinux provide YaST and yast2 (yast2 provides a richer interface, but is more
graphics intensive).

Creating the Oracle Owner
Create a user to be the owner of the Oracle software:

• This is the user that runs the Oracle Installer.
• It is commonly named oracle.
• The primary group will be the ORAINVENTORY
group.
• The user must be a member of an OSDBA group.

When the installer runs, it sets the ownership of the Oracle software to the user running the
installer. Do not run the installer as root. The name of this user is commonly oracle, but this
name is arbitrary. In the following examples, this user is named oracle. When this user is
created, the primary group can be set. The primary group is set to the ORAINVENTORY group. If
the OSDBA group is different, then the Oracle user must also be a member of that group. The
primary group is the one listed in the /etc/passwd file. Membership in other groups is set in
the /etc/groups file.

# useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
# useradd –m -g dba -s /bin/bash oracle
# passwd oracle
New password:
Retype new password:
Creating the Oracle Owner (continued)

In Linux, the root user can execute the useradd command to create a user. In this example, a
user named oracle is created with a primary group of dba. The user ID must be unique. If the
user ID is not specified, then the user gets the first available ID above 99, because IDs below 99
are typically reserved for system accounts. If the -D option is used with no other options, then
useradd will show the system defaults. These defaults may be overridden in the command
line, completely specified, or changed with -D followed by the new default. On Red Hat, the
default home directory is /home/<username> which is acceptable. You do not need to
override it with the -D option.
The useradd command places an entry in /etc/passwd and /etc/shadow if shadow
passwords are being used. The –m option creates the user’s home directory and copies a skeleton
set of login profiles from /etc/skel to the home directory. The -g option sets the primary
group. If the group is not specified, then a group with the same name as the user is created and
set as the primary group. The -s option sets the user login shell. In this example, the -s option
is not required because on both UnitedLinux and Red Hat the bash shell is the default shell.
For more information, refer to the man page for useradd.
Most Linux distributions are shipped with a graphical user management tool. For Red Hat Linux,
use redhat-config-users.

Creating the apache User
The HTTP server software should be owned by a

separate user with minimal privileges:
• Create or verify the apache user.
• Change primary group to ORAINVENTORY.
# grep apache /etc/passwd

apache:x:48:48:Apache:/var/www:/bin/false
# usermod -g orainventory apache

# grep apache /etc/passwd
apache:x:48:500:Apache:/var/www:/bin/false
Creating the apache User

On Red Hat Enterprise Linux, the apache user is created with the installation. With SuSE or
UnitedLinux, or if the apache user does not exist, it can be created with the properties mentioned
above with the useradd command:
#useradd -g dba -s /bin/false -d /var/www -u XX apache
Pick a userID value of XX less than 99 that is unused in the /etc/passwd file.
Change the apache User After Installation
The apache user is needed for security reasons with the HTTP server. This user must have
minimal privileges, and must only be a member of the ORAINVENTORY group until the
installation is complete. Then, the group should be changed to a group that holds only the
apache user. On the default Red Hat installation, the apache group is created for this
purpose. Therefore, after the installation is complete, you should change the user back to the
apache group.
#usermod -g apache apache

Choosing a Shell
There are many shells available for Linux:

• Oracle shell scripts are Bourne shell scripts.
• bash is the Bourne-again shell:
– It is Bourne shell compatible.
– It is POSIX compliant.
• Korn is a superset of Bourne:
– The Korn shell is required for certain actions.
• The C shell is preferred by many.
• The working-level shell is a matter of preference.
• Most shell scripts specify the shell that is
required.
Choosing a Shell
Linux has many popular features. One of the most popular feature is that the user interface can
be easily customized. There are at least four different shells in the default installs of SuSE, Red
Hat, and UnitedLinux and there are many more available. The Bourne shell, one of the first
shells that was available on AT&T UNIX, is the standard shell that the Oracle database uses for
scripting. The C shell was the BSD UNIX shell. The C shell has many user-friendly features,
such as command history, that are not available in the Bourne shell. But the C shell was
interpreted, and not compiled like the Bourne shell, and is consequently slower. The Korn shell
is a superset of the Bourne shell with command history, and is compiled. The Bourne-again
shell, bash, was written to be Bourne shell compatible, with features of both the Korn and C
shells. It is intended to be POSIX compliant. Some Oracle install actions require a Korn shell
such as the Oracle Internet Directory configuration script, oidca. The Korn shell, ksh, is not
part of the default installation of Red Hat Enterprise Linux, but the pdksh package that supplies
a ksh is included in the distribution. The Korn shell is installed by default with UnitedLinux.
Most Oracle shell scripts specify the shell that is required in the first line of the script. A first line
of #!/bin/sh indicates that the script uses the Bourne shell. On Linux, the Bourne shell is
usually the Bourne-again Shell (bash).
To view the shell that you are currently in, use the command: echo $0.

Setting Environment Variables
The shells have specific syntaxes for setting

environment variables.
• Bourne, Korn, and bash shell syntax:
ORACLE_SID=orcl; export ORACLE_SID
• C shell syntax:
setenv ORACLE_SID orcl
Setting Environment Variables

Each shell has a specific syntax for setting an environment variable. The most common syntax
for each shell and an example for the ORACLE_SID variable is shown. The environment
variables are session specific and, therefore, must be set at each login. In each shell, there are
specific login scripts that are executed.
• The Bourne shell runs .profile.
• The Korn shell runs .profile and .kshrc.
• The bash shell runs .bash_profile and .bashrc.
• The C shell runs .login and .cshrc.
The Oracle environment variables must be set in the last script to run in each case.
Example: For the bash shell, set ORACLE_SID in the .bashrc script.
Oracle Support recommends that you create a shell script in the same format as the .bashrc
and source it in the shell that will be running the installer. This has the advantage that after
installation the .bashrc or .login script does not need to be edited for ordinary use with the
oraenv script. For example, create a file instenv with the environment variables, do a
chmod 755 so that it can be executed, and then execute '. ./instenv' to run the script
without forking a new shell.

User File Creation Mask
Every file that a user creates has a set of permissions

controlled by a mask.
• View the mask with umask -S.
• Set the mask with umask -S u=rwx,g=rx,o=rx.
User File Creation Mask

Every file that is created by a user receives a default set of permissions. The permissions
determine who can read, write, and execute a file. The example above indicates that the files that
are created have permissions set as follows: read, write, execute for the owner (u); read and
execute permissions for the group (g); and read and execute permissions for the other (o). By
default on SuSE, Red Hat, and UnitedLinux the umask is set to u=rwx,g=rx,o=rx. But if it
is not set to this value it can be changed. In the .bashrc script for the oracle user, place a
line as below:
umask -S u=rwx,g=rx,o=rx
The umask must be verified before running the Oracle Installer and set for the oracle user in
the .bashrc file.

Setting Oracle Environment Variables
For the oracle user, you must set the following shell
variables before the installer is run:
• DISPLAY (required)
– Location of the X Window System server
• PATH (required)
– Location of the OS linker and compiler
– Location of the Oracle database executables

Only two shell variables need to be initialized before the installer is run: the DISPLAY variable
and the PATH variable. Other variables can be initialized to facilitate the installation. The
DISPLAY variable must be set to the location of the X Window System server. If X-based
terminal windows are being used, then the DISPLAY is usually set properly in login scripts.
Before installation, set the PATH variable manually or with a script in the shell where the Oracle
Installer is invoked to include the $ORACLE_HOME/bin directory. If the '$ORACLE_HOME'
string is used instead of a full path to set the PATH variable, then the ORACLE_HOME variable
must be set before its use. Usually, base PATH is set to
/usr/bin:/bin:/usr/bin/X11R6:/usr/local/bin by default. If it is not, then set it
in the .bashrc file.
After the installation, the PATH variable for any database user on Linux must be set by using the
supplied oraenv script. It adds $ORACLE_HOME/bin to the end of the existing PATH
variable.

Optimal Flexible Architecture
OFA was introduced to optimize the relationship

between the database files and the host operating
system. You can use OFA to:
• Distribute files across multiple mount points:
– Balance I/O for performance
– Increase reliability
• Handle large and growing directories
• Administer multiple releases
Optimal Flexible Architecture

Optimal Flexible Architecture (OFA) is a method for configuring the Oracle database and other
databases. OFA makes use of the OS and disk subsystems capabilities to create an easy-to-
administer configuration that allows maximum flexibility for growing and high performance
databases. The methods described here are the basics of OFA.
For details on the goals and implementation of OFA, refer to the Oracle9i Administrator's
Reference Release 2 (9.2.0.1.0) for UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX,
HP 9000 Series HP-UX, Linux Intel, and Sun Solaris Appendix G.

OFA Characteristics
An OFA-compliant database has a set of

characteristics:
• The file system is organized to enable
easy administration.
• I/O loads are distributed.
• New hardware is not required.
• Drive failure impact is isolated.
• Directories are distributed across multiple
disk drives.
OFA Characteristics
These are only five of the OFA characteristics. The OFA characteristics translate into specific
recommendations for the management of database files, and the structure of the host file systems
and directory structure.

Mount Points
To be OFA compliant, the database requires two

mount points:
• Mount points are listed in /etc/fstab.
• Name mount point /pm or /pm/q/db.
– p is a string.
– m is a unique identifier (2 to 4 digit number).
– q indicates Oracle database files (default oradata).
– db is the database name.
• Examples:
– /u01
– /u02/oradata/orcl
– /sales01
Mount Points
A database that is fully OFA compliant has at least two mount points: one for the software and at
least one for database files. The Oracle Installer requests two directories. The installer does not
know if you are supplying mount points or directories. The naming of the database software
directory was covered when you created the ORACLE_HOME environment variable.
Although there are many correct names that you can use, it is usually a good idea to avoid names
that map to hardware. For example, if you choose a name that corresponds to a particular disk
controller, then a later upgrade may result in a name that is deceptive. It is much easier to
separately track hardware to logical name mappings.
You must not use names that suggest that a mount point is devoted to one application’s data
unless it is true. You do not want to neglect your Oracle database files just because they were
stored under a mount point called /backup01.
In the original OFA, the concept of a mount point almost always referred to a single physical
disk, that is, each disk had one mount point. In today’s environment, disks can be very large, and
they are partitioned to useful sizes. Each partition requires a mount point.

ORACLE_HOME and ORACLE_BASE
These are directories to implement an OFA-compliant

installation.
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=$ORACLE_BASE/product/9.2.0
ORACLE_HOME and ORACLE_BASE

What Is ORACLE_HOME Used For?
The ORACLE_HOME directory is used by any user who wants to use the particular database. It
identifies the directory that has the proper release distribution and binaries for the database. It
also identifies the default location of the parameter file that launches the database. The
ORACLE_HOME variable does not have to be preset as an environment variable, it can be set in
the install dialog. The directory does not have to exist but the directory structure above it must
exist and be owned by the user named oracle. The ORACLE_HOME variable is typically in the
ORACLE_BASE directory: ORACLE_HOME=$ORACLE_BASE/product/9.2.0.
What Is ORACLE_BASE Used For?
The ORACLE_BASE directory is typically a higher-level directory than ORACLE_HOME. It is
used by shell scripts that you create. Typically, your data files and administration files are
located below this point. This allows shell scripts to be created that are not dependent on the
particular tree structure, and those scripts continue to work on other machines or reconfigured
machines and possibly on other releases of the database.

Installing New Releases
• Provide a separate tree for each release. This tree

is deleted after an upgrade (when it is no longer in
use).
• Place releases in a directory named h/product/v
where:
– h is the ORACLE_BASE directory
– v is the version identifier or release number
Example:
/u05/app/oracle/product/9.2.0
/u02/app/oracle/product/8.1.7
Installing New Releases

Each new release gets its own directory. As new releases are added, the old release directories
can be removed. Therefore, the release directory should contain only files that are specific to that
release. You must store only files that are installed by the Oracle Installer in the ORACLE_HOME
directory.
Installing a new release often results in multiple databases running under different releases. Each
instance on a machine specifies the release that it uses in the /etc/oratab file. For example:
prod:/u02/app/oracle/product/8.1.7:Y
dev:/u05/app/oracle/product/9.2.0:N
When a database is upgraded to use a different release, change the oratab file so that users
find the proper ORACLE_HOME directory. For example, moving prod to 9.2.0:
prod:/u05/app/oracle/product/9.2.0:Y
When the 8.1.7 database is removed, the directory is no longer needed and can be removed.

Managing Multiple Versions
Set the user environment when several versions of the

database software exist on the same machine.
• Use generic login scripts.
• Use Oracle Corporation–supplied scripts to set
the environment.
PATH=/usr/bin:/bin:/usr/bin/X11/:/usr/local/b
in
ORACLE_SID=orcl
ORAENV_ASK=NO
. oraenv
ORAENV_ASK=
Managing Multiple Versions

You may want to update from your installed version of the Oracle database to the current release.
This creates the problem of how to run multiple releases simultaneously. Often, a small group of
users or developers use the new release initially. Later, everyone else switches over after the
release has been determined to be stable in the environment. You must have a plan to allow easy
configuration for multiple database users. Simply installing to ORACLE_HOME is not sufficient.
An upgrade from one version of the Oracle database to another can be very difficult, if not
planned properly. This is especially true during the period when multiple versions of the
database software are on the system, and possibly several databases on the same machine are
running from different ORACLE_HOME directories. One common problem is to properly set the
user environment to access a particular database. Another problem has to do with providing
proper support libraries for executables (you can execute a program like SQL*Plus from a
different directory, but without the proper version of supporting software libraries defined in
ORACLE_HOME the program will usually fail). These problems and the solution on the
following page apply only to users that have OS logins on the database server machine.

Managing Multiple Versions (continued)
The solution is to embed a call in each user’s login script to a separate file that determines the
environment for the user’s preferred database. This makes the switching over of all users to a
different ORACLE_HOME much simpler. The login script that is used depends on the user login
shell. For the bash shell, the login script would be .bashrc. In the slide, setting
ORACLE_SID and ORAENV_ASK=NO in .bashrc sets a default environment for this user,
without requiring user interaction. Other variations can be set to suit your environment.
Generic Login Script
Each user should have a login script that includes only the environment variables that are
specific to that user, such as the instance SID that the user accesses. A call to the Oracle
Corporation–supplied script oraenv from the login script finds and sets the proper
ORACLE_HOME and other site-specific required environment variables.
oraenv
The oraenv script is provided with the database software and is relocated by the root.sh
script at installation. The default location is /usr/local/bin. If the variable ORAENV_ASK
is not set on entry, then the oraenv script prompts the user for the ORACLE_SID that the user
wants to set, with a default of the ORACLE_SID in the user’s environment. This is a convenient
way for users to change their environments or access multiple databases. If ORAENV_ASK is set
to NO, then oraenv does not prompt the user, but sets ORACLE_HOME and other variables
unless ORACLE_SID is set to a value not specified in the /etc/oratab file, in which case
the user is asked to provide the ORACLE_HOME for the SID. If ORAENV_ASK is set to
anything other then NO (including a blank), then the user will be prompted. Korn, Bourne, and
bash shell users can use the oraenv script; coraenv is provided for C shell users. The
oraenv script should be customized for each site. If the site requirements change, the DBA can
modify oraenv and alter all the users’ environments without changing every login script. The
oraenv script calls another script, dbhome, which looks up the ORACLE_HOME associated
with the ORACLE_SID in the /etc/oratab file. An example of calling oraenv from a login
script is:
PATH=/usr/local/bin:/$PATH
ORACLE_SID=orcl
export PATH ORACLE_SID
ORAENV_ASK=NO
. oraenv
ORAENV_ASK=
Note: The '.' command sources the oraenv script, causing it to run in the current shell. This
allows the oraenv script to set environment variables in this shell. Without the source
command, the parent forks a new shell, the script executes and exits, returning to the calling
shell. The problem is that a child shell cannot change the variables in a parent shell and,
therefore, the environment remains unchanged.

Additional optional environment variables:

• ORACLE_BASE: The root of the Oracle software
directory structure
• ORACLE_SID: The initial instance name (ORCL by
default)
• ORA_NLS33: Location of the character set files
• TMPDIR and TMP: An optional location for temp
space if required
• ORACLE_DOC: Location of Oracle documentation
• LANG: System language

In an OFA-compliant installation, there will be a root directory for all the Oracle software and
database files. This often has the form of /<mount_point>/app/oracle and is
$ORACLE_BASE. OFA is discussed in more detail later in the course. The ORACLE_BASE
variable is set to reduce typing errors during the installation. This directory must exist and be
owned by oracle with group dba before the installer is started. You can set the
ORACLE_SID in the Database Creation Wizard.
ORA_NLS33 is required to be set only if the .nlb message files and character set files are
placed in a directory other than the default directory. The default directory is
$ORACLE_HOME/ocommon/nls/admin/data.
The Oracle Installer uses about 100 MB to 400 MB of space in the /tmp directory, and the OS
commands that are run by the installer can use an additional 100 MB of space. If there is not
enough space in /tmp, then use the TMPDIR variable to direct the OS commands to use an
alternative directory, and the TMP variable to redirect the commands that would normally use the
/tmp directory.
ORACLE_DOC is an optional environment variable that is used to specify the installation
location of the Oracle online documentation.

Setting Oracle Environment Variables (continued)
LANG is a mandatory system environment variable that may optionally be changed for the
Oracle user. Normally, the LANG variable will be set to something like en_US.utf8 when you
install your operating system. For the Oracle user, the characterset (utf8) should be omitted so
that the environment variable is just en_US. Failure to set this variable for the Oracle user will
limit Oracle Enterprise Manager functionality, including:
• The ability to store preferred credentials
• The ability to run jobs
• The ability to access reports
LD_LIBRARY_PATH specifies the path to C libraries. For the Oracle user, that path normally
includes the system default (/usr/lib and /usr/X11R6/lib) as well as:
• $ORACLE_HOME/jdk/jre/lib/i386
• $ORACLE_HOME/jdk/jre/lib/i386/lib
• $ORACLE_HOME/rdbms/lib
• $ORACLE_HOME/lib
Setting Variables: Example
# Oracle Environment variables

ORACLE_BASE=/oracle
ORACLE_HOME=$ORACLE_BASE/ora92
PATH=$PATH:$ORACLE_HOME/bin
LANG=en_US
export ORACLE_BASE ORACLE_HOME PATH LANG
$ env | less
BASH=/bin/sh
…
ORACLE_BASE=/oracle
…
Setting Variables: Example

This is a section of the instenv script file that sets how the Oracle environment variables will
look. To test the environment, log in as the oracle user, source the script, and view the
environment variables with the printenv or env commands. In the example, env can
produce more than one page of output. Therefore, piping the result through less allows the
output to be scrolled. These commands have an advantage over the set command because they
show only variables that are exported to the environment.
Note
• If /usr/bin precedes $ORACLE_HOME/bin in the path when rman is executed from
the command line, then the Linux reverse man program is run rather than Oracle
Recovery Manager. If $ORACLE_HOME/bin precedes /usr/local/bin in the path,
then the original copies of oraenv and dbhome are used instead of the customized copies
residing in /usr/local/bin.
• One solution to this order issue is to put $ORACLE_HOME/bin first in the path, and
rename the original oraenv and dbhome scripts so that they are not run. Therefore,
Linux looks down the path further and accesses your customized copies residing in
/usr/local/bin.

Creating Directories
Create the directories that are used for the Oracle

software and database files:
• The ORACLE_BASE directory:
– /<mount_point>/app/oracle
– /u1/app/oracle
• The ORACLE_HOME directory:
– /<mount_point>/app/oracle/product/9.2.0
– /u1/ app/oracle/product/9.2.0
• Directories for database files:
– /<mount_point>/oradata
– /u2/oradata
Creating Directories
The ORACLE_BASE directory that is used in the example (in the slide) must be created by root.
The ownership of the directory must be assigned to the oracle user and the ORAINVENTORY
group. Following the examples in previous slides, use the command chown oracle:dba
/u1/app/oracle. Repeat this procedure for the directories that are designated to hold
database files. The ORACLE_HOME directory is successfully created by the OUI as long as the
permissions on the ORACLE_BASE directory are correct.
The mount points are not required to be at the root directory. For example, additional partitions
could be mounted below the ORACLE_BASE directory. An ORACLE_BASE of /app/oracle
can have mount points of /app/oracle/product for the software and several mount points
for database files of the form /app/oracle/diskn where n is a disk number. The value of
n may need to be a two- or three-digit number in large database configurations.

Mounting the CD-ROM
To mount the CD-ROM with the Oracle software,
perform the following steps:
1. Insert CD into the CD drive on the server.
2. Click the CD-ROM icon or start the User Mount
tool.
Do not make your working directory the CD
mount point.
Mounting the CD-ROM

Log in as the Oracle software owner. Insert the CD marked Disk 1. Start the User Mount tool or
click the CD-ROM icon. If a file navigator is displayed, close the navigator. During the
installation, the second and third CDs will have to be mounted. The current CD cannot be
unmounted or ejected if any process (including the navigator) is accessing it. Depending on your
access privileges, another terminal session logged in as root may be needed to mount and
unmount the CD-ROM. The commands to mount and unmount a CD-ROM are:
• For Red Hat Linux:
# mount -t iso9660 /dev/cdrom /mnt/cdrom
# umount /mnt/cdrom
• For SuSE or UnitedLinux:
# mount -t iso9660 /dev/cdrom /media/cdrom
# umount /media/cdrom

Mounting the CD-ROM (continued)
If /etc/fstab has the default settings for mounting /dev/cdrom, then the mount
command can be simplified to the following:
• For Red Hat Linux:
# mount /mnt/cdrom
• For SuSE or UnitedLinux:
# mount /media/cdrom
Staging the CDs
On machines that have sufficient disk space, the CDs can be copied to disk. This allows faster
installations and network installations.
Starting the Installer
• Start the OUI from the user home directory.

• At the prompt, issue the runInstaller
command.
$ cd
$ /mnt/cdrom/runInstaller (Red Hat)
$ /media/cdrom/runInstaller (SuSE and UnitedLinux)
Starting the Installer

The cd command with no arguments changes your working directory to your $HOME directory.
Using the oracle user created previously, this would be /home/oracle. Do not run the
runInstaller command from the cdrom mountpoint. If you do, you will not be able to eject
and insert the CDs as requested from the Universal Installer.
Note: The runInstaller command has an uppercase “I” in it.

Oracle Universal Installer
Oracle Universal Installer

The Oracle Universal Installer is Java based and, therefore, it is the same across all platforms
that Oracle supports.
After the Welcome screen and before the File Location screen, you are prompted to do the
following:
1. Provide the Inventory Location. This defaults to $ORACLE_BASE/oraInventory.
2. Provide the Linux DBA Group for the ORAINVENTORY user.
3. Run orainstRoot.sh, from the /tmp directory as root. You must go to a separate
window as root and run this script. Follow the instructions in the pop-up window. If the
installation fails after this script is run, then the file /etc/oraInst.loc must be
removed for successful reinstallation. If there are prior Oracle installations on this server,
do not remove the oraInst.loc file, contact Oracle Support. The oraInst.loc file
contains a pointer to the location of the inventory and the ORAINVENTORY group name.
You require this file for removal or upgrading.
Note: Within the <inventory>/log directory is a file with a name such as
installActions<timestamp of the install>.log. This file contains a record of the choices made
during the installation, the versions of the products being installed, the type of installation
(Enterprise or Standard), and much more.

File Locations
File Locations
The File Locations screen prompts you for the path to set the ORACLE_HOME variable and a
name for this location. The installer supports multiple ORACLE_HOME locations. It is possible to
have multiple versions of the Oracle software running on the same machine for different
databases. An example would be to have a test database running at version 9.2.0 to check the
effects of a new release, while production is still running version 8.1.7.
After the File Location screen and before the Installation Types screen, you are prompted with
the Available Products screen. Your choices are:
• Oracle9i Database
- Installs an optional starter database, product options, management tools, networking,
utilities, and basic client software
• Oracle9i Client
- Installs management tools, networking, development tools, and precompilers
• Oracle9i Management and Integration
- Installs Oracle Internet Directory and associated management tools, networking,
utilities, and basic client software
• Oracle Cluster Manager
- Installs the Oracle Cluster Manager (required for RAC on Linux)

Installation Types
Installation Types
In the Installation Types screen, you can choose the software that is installed. You have the
choice of the Enterprise Edition, the Standard Edition, or a Custom installation. The Custom
option is required to install certain features of the database, such as Connection Manager, Oracle
Names, or Advanced Security Option. All of these can be installed at another time.
For details about the different editions of the Oracle9i Database, refer to Oracle9i Database New
Features Release 2 (9.2).

Database Configuration
Database Configuration
At this point, OUI inquires about the kind of database that is created as part of the install. The
first three choices—General Purpose, Transaction Processing, and Data Warehouse—use a
preconfigured database and initialization parameter file from the available templates. These
templates hold prepopulated data files so that the character set and database block size cannot be
changed.
You can use the Customized option to set initialization parameters, file locations and sizes, and
completely customize the first database.
The Software Only option installs just the Oracle software, and no database is created. This
option is also used to add options to an existing installation, for example, Connection Manager,
Oracle Internet Directory, or Advanced Security Option.

Installation Summary
Installation Summary
Before the installation actually begins, the Installation Summary screen appears with the results
of the choices that you made in the previous screens. Because space requirement is of particular
interest, if enough space is not available, then the installer displays an error message.

Changing the CD-ROM
Changing the CD-ROM

This dialog box appears prompting for the location of the next installation disk. If you have
copied the contents of the installation CDs to directories on a disk drive, then you can browse to
the requested directory, select it, and continue. If the directories are named Disk1, Disk2, and
Disk3 with an uppercase D, then the above prompt does not appear. OUI continues to find the
proper directory automatically.
If you are using a CD drive, then the current CD must be unmounted and ejected before the next
one can be loaded and mounted. If any process is using the currently mounted CD as a working
directory, then CD cannot be unmounted. An attempt to unmount a CD in this situation would
get the error message umount: /mnt/cdrom: device is busy.
To avoid this situation:
• Start the installer from a directory other than the CD-ROM that is using the full path name
• Close any GUI file managers
• Do not change directories to the mount point of the CD or any subdirectories of the mount
point in any terminal window

Setup Privileges
Setup Privileges
Near the end of the installation, you are prompted to run another script as root. This script sets
file permissions, moves utility scripts to the local bin directory, creates the oratab file, and
runs a setup script for other installed products.
It is also recommended that you change the name of this file after the installation is complete.
You may need this file later if permissions get changed. By renaming it, you can keep each
root.sh file for each installation. The file is overwritten for each installation.

Database Accounts
Database Accounts
After you have created the database, you are prompted to set the passwords for the SYS and
SYSTEM accounts to nondefault values. You must do this. Sometimes during the installation
you may not be able to enter passwords. If this happens, click Password Management to change
passwords there.

Password Management
Password Management
All the database accounts are locked by default. In this window, you have the option of
unlocking and setting passwords for any of the default accounts that are accessed. In this slide,
the password for the SCOTT account has been changed.
Note: It is recommended that you unlock the SCOTT user and set the password to TIGER. Other
setup and configuration tools use the SCOTT user to test connections. After all setup and
configuration has completed, it is a good idea to lock and expire the SCOTT user because of
potential security risks. For more information about Oracle database security, see the Oracle9i
Database: Security course.

Configuration Tool Error
Configuration Tool Error

Sometimes there is an error in one or more of the configuration tools. The error details give
information about the error and possible solutions. In this case, the Intelligent Agent failed to
start.
When the Configuration Tools screen appears, the installation is complete. All of these
configuration tools can be run independently after the installation.
During your installation on Red Hat Enterprise Linux 3.0, you will normally encounter three
errors:
• Linking error with the Oracle Intelligent Agent
• Linking error with Oracle Text
• Configuration error with the Oracle Intelligent Agent (shown above)
During the practice for this lesson, you will apply patches to overcome all three of these errors as
you install on Red Hat Enterprise Linux 3.0.
Installations on Red Hat Enterprise Linux 2.1, SuSE SLES8, and UnitedLinux 1.0 do not
normally encounter errors if all preinstallation checks and setup recommendations are
completed.

Oracle Software Patches
Patches are available from MetaLink. There are two

types of patches:
• Temporary Patches
– Oracle Software
– Linux Operating System
• Patch Sets
To install Oracle9i Release 2 on RHEL 3.0, you apply
both types of patches:
• Patch Set 3 (Oracle9iR2 9.2.0.4)
• Operating system temporary patch 3006854
• Oracle temporary patches 3238244 and 2617419
Oracle Software Patches

Oracle provides software updates through patches. There are two types of patches: temporary
patches and patch sets.
Temporary patches (also called interim or one-off patches) are noncumulative patches produced
to correct a specific issue or bug. They are classified as temporary because they do not undergo
complete compatibility testing with other temporary patches. They are only tested for the system
or systems they are produced to correct. Temporary patches should only be applied when
directed by Oracle Support Services in response to a specific problem. Applying a temporary
patch usually does not change the product version.
Because Oracle provides support services for the Linux operating system as well as Oracle
supplied software, you may obtain temporary Linux operating system patches from Oracle.
Patch sets are cumulative compilations of fixes. Unlike temporary patches, they are fully tested
and integrated with the Oracle product stack. Applying a patch set changes the version number
of your Oracle software (for example, if you apply patch set 3 to your Oracle9i Release 2 version
9.2.0.1 database, it becomes version 9.2.0.4). You should apply patch sets to your system as soon
as possible after they are released.
Before applying any patch to a production system, Oracle recommends you test the patch in your
environment and make a complete backup of your system.

Oracle Patch Utility
Install Oracle Patch Utility (Opatch) by applying

temporary patch 2617419. Use OPatch to:
• Apply other temporary patches
• Roll back temporary patches
• List installed Oracle components and temporary
patches
• Attach an installed ORACLE_HOME to a central
inventory
$ opatch apply
...
OPatch succeeded.
Oracle Patch Utility

The Perl-based OPatch allows the application and rolling back of temporary patches. OPatch is
not installed as part of the Oracle9i Database installation, but is shipped as its own temporary
patch. To obtain the latest version of OPatch, download temporary patch 2617419 from
MetaLink.
To install a patch with Opatch, you must have:
• Perl interpreter version 5.005_03 or greater (5.6 preferred) installed. If you installed the
Oracle HTTP Server that is shipped with Oracle9i Release 2, you already have the correct
version of Perl.
• A Java Runtime Environment (JRE). It is automatically installed with Oracle9i Release 2.
• Execute privileges on the fuser utility. OPatch uses fuser to check that no Oracle
database processes are running before it applies a patch. fuser is usually located in
/sbin for Linux distributions and must be copied to the OPatch directory with operating
system permissions changed so the Oracle user can execute it.
• Exclusive control of the Oracle Inventory directory. OPatch updates the inventory to reflect
interim patches. There can be no other instance of OPatch or OUI running in order for
OPatch to succeed.

Oracle Patch Utility (continued)
OPatch allows you to:
List currently installed components: Use the lsinventory command to list all installed
components for your current ORACLE_HOME including any temporary patches already applied
via OPatch.
$ opatch lsinventory –oh <ORACLE_HOME> -all
The -oh <ORACLE_HOME> argument can be omitted if you want to display the inventory for the
ORACLE_HOME defined by $ORACLE_HOME.
The optional -all argument may be used in place of the -oh argument to display the contents
of ALL ORACLE_HOMEs registered with the inventory.
Apply temporary patches: Use the apply command to apply a temporary patch.
$ opatch apply <patch directory> <ORACLE_HOME>
If the <patch directory> argument is not supplied, then OPatch looks for the patch in the current
directory. If the <ORACLE_HOME> argument is not supplied, then OPatch applies the patch to
the ORACLE_HOME defined by $ORACLE_HOME.
Remove temporary patches: Use the rollback command to remove a temporary patch that
has been applied by OPatch.
$ opatch rollback –id <patch id> -ph <patch directory>
By default, OPatch removes the patch from the ORACLE_HOME specified by the
$ORACLE_HOME environment variable. You can add the optional flag –oh
<ORACLE_HOME> if you wish to remove the patch from a different ORACLE_HOME. The
patch ID and patch directory arguments are mandatory to remove a patch.
Attach an installed ORACLE_HOME to a central inventory: Use the attach command to
add an ORACLE_HOME to an existing inventory. This might be necessary if the rdbms
software was transferred from one system to another without the inventory (a nonstandard,
nonsupported installation method).
$ opatch attach –name <OH name> -oh <ORACLE_HOME>
If the ORACLE_HOME is not specified, then OPatch uses the ORACLE_HOME defined by
$ORACLE_HOME.
For help on any of the OPatch commands, use the –help argument:
$ opatch -help
$ opatch attach –help
Oracle Relink Utilitity
To relink Oracle executables:

1. Verify whether ORACLE_HOME is correctly set
2. Set LD_LIBRARY_PATH to include
$ORACLE_HOME/lib
3. Execute the appropriate relink command:
- relink all (relinks all Oracle executables)
- relink oracle (relinks the database executables)
- relink network (relinks listener, cman, names)
- relink oemagent (relinks the Intelligent Agent)
- relink utilities (relinks sqlplus, imp, exp)
- relink ctx (relinks Oracle Text)
Oracle Relink Utility

Oracle9i Database software is not distributed as a group of complete executables. Instead, Oracle
distributes individual object files, library archives of object files, and some source files which
then get “linked” at the operating system level during installation to create usable executables.
This guarantees a reliable integration with functions provided by the OS system libraries.
If the operating system or Oracle object files change, then Oracle executables should be
“relinked” to create updated executables properly integrated with the operating system.
Relinking occurs automatically when a patch set is installed, but must be performed manually
when:
• An OS upgrade has occurred
• A change has been made to the OS system libraries. This can occur during the application
of an OS patch.
• A new install failed during the relinking phase
• An individual Oracle patch has been applied (explicit relink instructions are usually either
included in README or integrated into the patch install script)
To relink, you may use the relink utility as shown above, or manually relink with the make
command. Unlike OPatch, the relink utility does not return positive feedback. Unless you receive
an error message, the relink succeeded.

Troubleshooting
If you have problems during the installation:

• Check the kernel parameter settings
• Check the environment variables
• Check directory permissions
• Verify whether the required packages are installed
Troubleshooting
There are some common problems with the installation. Many are the result of missing a step in
the preinstallation setup.
Kernel parameters errors, often the result of typographic errors, can cause ORA-3113 End of
File on communication channel, or an OS error indicating that there is not enough
shared memory or semaphores. These usually show up when the Database Creation Assistant
tries to start an instance.
Environment variables can lead to a variety of errors again due to incorrect typing. The directory
to be used as the ORACLE_BASE must exist and be owned by the user that is running the
installer. The C compiler and supporting utilities must be installed and the directory must be
included in the PATH variable.
The installer is very convenient to use. The error pop-up windows normally allow you to go to
another window, fix the problem, and click Retry. The only errors that cannot be fixed in this
manner are the environment variables. If you discover that the problem is with environment
variables, then you must exit the installer, change the environment, and restart the installer. The
installer inherits the environment when it starts, and the installer environment cannot be changed
while the installer is running.

Summary

• Create the OS user oracle
• Configure the Oracle9i OS environment
• Install Oracle9i software by using Oracle Universal
Installer (OUI)
• Create a General Purpose database with OUI
• Install patch sets and temporary patches

Practice: Overview

• Creating the Oracle user
• Installing Oracle9i Release 2 software and creating
a General Purpose database
• Installing Oracle9i Release 2 patch set 3 version
9.2.0.4
• Installing the Oracle Patch Utility
• Installing a temporary patch
• Performing postinstallation checks
Practice 3: Overview

Creating a Custom Oracle9i Database

Objectives

the following:
• Create a custom Oracle9i database
• Configure and start Oracle Net components
• Test the Oracle9i components

Database Configuration Assistant

With the Database Configuration Assistant, you can:
• Create a database
• Configure database options
• Delete a database
• Manage templates
- Create new templates by using predefined template settings
- Create new templates from an existing database
- Delete database templates
Some predefined templates are available for use. You can also use an existing database as a copy
to create a new database or template. The database parameters are stored in XML format. For
more information about templates, refer to Oracle Database Configuration Assistant online Help.
To launch the Database Configuration Assistant on Linux, use dbca from the command line.

Creating a Database by Using the
1. Select the create a database option.

2. Specify the type of database:
– Data Warehouse
– General Purpose
– Transaction Processing
– New Database
3. Specify the global database name and the
system identifier (SID).
Creating a Database by Using the Database Configuration Assistant

The first three screens of the Database Configuration Assistant are:
• Operations: Select the “Create a database” option.
• Database templates: Select the type of database that you want to create from the list of
predefined templates. The options that include data files are faster to create, but a little less
flexible. For example, during the creation you cannot add more files, which means you
cannot add tablespaces. The New Database option gives you full control over the creation
of the database, but takes longer to complete, because all the scripts are run (such as
CATALOG.SQL). By highlighting the type of database and by using the Show Details
option, you can view what is created with the database template.
• Database identification: Specify a global database name and SID.

Database Features
4. Select from:
– Oracle Spatial
– Oracle Ultra Search
– Oracle Label Security
– Oracle Data Mining
– Oracle OLAP
– Example Schemas
– Standard features
Database Features
On the Database Features page, you can select the features that you want to install into the
database that you are creating. You can do this if the software for the feature is included in the
base installation.
• Oracle Spatial provides a way to store and retrieve multidimensional data in an Oracle
database.
• Oracle Ultra Search is a text management solution that enables organizations to access text
information sources as quickly and easily as structured data.
• Oracle Data Mining enables data mining to be performed inside the database rather then by
using external data mining tools.
• Oracle OLAP (online analytical processing) provides tools for developing and deploying
Internet-based business intelligence applications.
• Oracle Label Security enables application developers to add label-based access control. For
details, refer to Oracle Label Security Administrator’s Guide Release 2 (9.2).
• Example Schemas provide a set of schemas that are used in training and documentation.
These schemas are used to demonstrate and test the functionality of the database.
You can also see the standard database features that are installed. These are: Oracle JVM, Oracle
interMedia, Oracle Text, and XML Database Protocols.
There is a tab to specify any custom scripts that you want run as part of the database creation.

Database Connection Options
5. Select the database operational mode:

– Dedicated server mode
– Shared server mode
Database Connection Options

Here, you select the way you want the users of the database to connect.
• With the dedicated server mode, each user has a server process that works exclusively for
the one user that is connected to the process. This is a required type of connection for most
administrative tasks, for example, starting up and shutting down the database. It is also
recommended for data warehouse type applications and environments where the number of
users is low.
• With the shared server mode, many users can share work across a pool of server processes.
Generally, this is recommended for online transaction processing environments and where
system resources cannot handle the user load. A shared server is also ideal for most Web
applications because a user typically connects to the database for a very short time only.
The Oracle Internet Directory application can benefit by using shared server connections.
You can have both dedicated server connections and shared server connections into the same
instance.
For more information about the setup of these connection modes, refer to the Oracle9i Net
Services Administrator's Guide.
The Oracle database on Linux fully supports either mode.

Initialization Parameters
6. Specify options for:

– Memory
– Character sets
– Database sizing
– File locations
– Archiving
Initialization Parameters
The initialization parameters describe many aspects of your Oracle database. Here, you set the
parameters that are used at the time of creating the database. Most of these parameters can be
changed later as you tune and modify your database. A few key parameters are:
• Data block size: Under the DB size tab, you can select the data block size used for your
database. For Linux, you must not use a size smaller than 4 KB and larger than 16 KB. If
your data block size is less than 4 KB, it will cause excessive I/O requests because the file
systems use a 4 KB block size at the OS level. An 8 KB block size is a good size for most
databases. This cannot be changed after the database is created.
• Character Sets tab: With the Character Sets tab, you can select the character set for the
database and the national character set. The national character set is used for column data
types of NCHAR, NVARCHAR2, and NCLOB, and must be a Unicode character set.
Although these character sets can be changed later, it is not a simple process. You can only
change to a character set that is a strict superset of the current one. The new character set
must include characters of the same byte count as the original character set. Take time
before creating the database to select the right character set according to your requirements.
For details about supported character sets, refer to the Oracle9i Database Globalization
Support Guide.

Completing the Database Creation
7. Define database storage parameters:

– Change locations
– Add or remove tablespaces, data files, control files,
and redo log files
8. Select option to:
– Create a database
– Save as a template
– Generate a creation script
Completing the Database Creation

Database Storage
On the Database Storage screen, you can change the location of data files, control files, and redo
log files.
To add a tablespace, highlight Tablespaces on the left of the screen and click Add. The Create
Tablespace screen gives you the option to name the tablespace and automatically creates one
data file of the same name. You can change the name of the data file and add more data files if
you need. The storage tab gives you all options for the storage attributes of the tablespace.
Creation Options
On the final screen, you decide what to do with the database you just defined. You can create it
immediately, save it as a template to be used later, or save the creation as a script file that you
can run later. You can select one or all of the options at the same time. This means that you can
create the database immediately and save the definition as a template for later use.

Oracle Net Services Configuration and
Administration Tools
• Oracle Net Manager:

– Is used for configuring and managing Oracle Net
– Is a client- or server-based tool
– Is integrated with Oracle Enterprise Manager
–
$ netmgr
• Oracle Net Configuration Assistant:

$ netca
• Oracle Net Control utilities:

– Listener Control utility
– Oracle Connection Manager Control utility
– Oracle Names Control utility
Oracle Net Services Configuration and Administration Tools

Oracle Net Manager is a graphical user interface (GUI) tool that is used to provide an integrated
environment for configuring and managing Oracle Net. It can be used on either the client or the
server. Oracle Net Manager is also integrated with Oracle Enterprise Manager.
Oracle Net Configuration Assistant is provided primarily to configure basic network components
during installation. It can also be run after installation in a standalone mode to configure naming
method usage, the listener, net service names in the tnsnames.ora file, and directory server
usage.
Oracle Net provides the following command-line tools to help you start, stop, configure, and
control each network component. Use the netca command followed by the keyword help for
the options available. Also see Oracle9i Net Services Administrator’s Guide:
• For the Listener Control utility, the command is lsnrctl.
• For the Oracle Connection Manager Control utility, the command is cmctl.
• For the Oracle Names Control utility, the command is namesctl.
Note: Oracle Connection Manager and Oracle Names are not installed by default.

Oracle Net Manager
Oracle Net Manager

You can use Oracle Net Manager to configure and manage the Oracle networking environment:
• Service naming: You can create or modify network descriptions for database services in a
tnsnames.ora file, a directory server, or an Oracle Names server.
• Listener: You can create or modify a listener, a process on the server that receives and
responds to client connection requests for a database service.
• Profile: You can create or modify a profile, a collection of parameters that determine how
the client connects behave. You can specify parameters for naming methods, logging,
tracing, external naming parameters, and Oracle Advanced Security.
• Oracle Names server: You can create an Oracle Names server, modify its configuration
settings, or control it.

Oracle Net Configuration Assistant
Oracle Net Configuration Assistant

Oracle Net Configuration Assistant is provided primarily to configure basic network components
during installation, including:
• Listener names and protocol addresses
• Naming methods that the client uses to resolve connect identifiers
• Net service names in a tnsnames.ora file
• Directory server access
Oracle Net Configuration Assistant runs automatically during software installation, as described
in your Oracle installation guide.
It can also be run after installation in standalone mode to configure naming method usage, the
listener, net service names in the tnsnames.ora file, and directory server usage.
To start Oracle Net Configuration Assistant in Linux, execute netca from the command line.

Testing the Connection
Test the Oracle Net configuration with Oracle and

Linux tools:
• Use the Net Manager test.
• Use the Net Configuration Assistant test.
• Test service name resolution with tnsping.
• Test tns routing with trcroute.
• Verify connectivity with ping.
• Check IP routing with traceroute.
Testing the Connection

Oracle Corporation and Linux provide tools to test the network. When troubleshooting, it is
customary to start with the tools that are listed at the bottom of the slide and work upward. With
Net Manager, invoke the tool, netmgr, select Local > Service Naming and the service
name that you want to test. Choose Test Service from the menu item Commands. The
test results are displayed, and the login can be changed if the default SCOTT/TIGER does not
exist or is locked.
The Net Configuration Assistant has a similar tool. Invoke netca, choose Local Net
Service Configuration. Choose Test. Select a service name from a pull-down list.
View the results. The default login for netca is SYSTEM/MANAGER. The login for the test can
be changed if SYSTEM/MANAGER is not a valid login. Both these tools do an end-to-end test. If
some part of the system is faulty, the test fails.
The other tools provide a way to test parts of the system to isolate problems. The tnsping tool
checks the service name resolution and attempts to contact the specified listener. The
trcroute tool also does service name resolution but additionally maps all the hops taken by
the tns packet to the destination, or until it cannot be forwarded. To confirm basic IP service
between two machines, use ping, or traceroute. Basic connectivity can be tested with
ping, and traceroute reports on the path that the packet takes from source to destination.
All these tools are invoked from the command line.

Summary

• Create a custom Oracle9i database
• Configure and start Oracle Net components
• Test the Oracle9i components

Practice Overview:
Creating a Database

• Using the Database Configuration Assistant
• Creating a database with scripts
Practice 4 Overview: Creating a Database


Installing and Configuring
Enterprise Manager

Objectives

the following:
• Configure Oracle Management Server (OMS)
• Discover Oracle9i databases and nodes
• Configure the HTTP server and Enterprise
Manager Reporting
• Configure and test jobs and events by using
Oracle Enterprise Manager

Starting the Enterprise Manager
Configuration Assistant
Starting the Enterprise Manager Configuration Assistant

The Enterprise Manager Configuration Assistant starts automatically at the end of an installation
if you install the Oracle software in any one of the following ways:
• Oracle9i Database > Custom
• Oracle9i Management and Integration > Oracle Management Server
• Oracle9i Management and Integration > Custom
The Enterprise Manager Configuration Assistant is started automatically during the
configuration phase of these installations. If you install Oracle Enterprise Manager through any
other installation type, then the Enterprise Manager Configuration Assistant does not start
automatically at the end of the installation; you must manually start the Enterprise Manager
Configuration Assistant when the installation completes.
To start Enterprise Manager Configuration Assistant in Linux, execute the following command
from the command prompt:
$ emca

Configuring an OMS
Configuring an OMS
Configuring an OMS consists mainly of specifying which repository you want the OMS to
connect to. After you choose to configure an OMS, you are asked to create a new repository or
use an existing one.
When creating a repository, the Enterprise Manager Configuration Assistant writes the
repository owner’s username and password (in encrypted format) to the
omsconfig.properties file located in the $ORACLE_HOME/sysman/config
directory.

Creating a New Repository
Creating a New Repository

If you choose the Typical option when creating a new repository, a new database is created for
the storage of the repository. If you do not want to create a new database, then select the Custom
option to select an existing database for the repository.
You can also use the Custom option to create a new database for storing the repository. By using
this option, you can set the system identifier (SID) of the repository, the username and password,
and the default and temporary tablespace for the user.

Installing the Intelligent Agent (IA)
• IA is:
– Shipped with the database
– Installed with the Oracle Universal Installer (OUI):
- From the Enterprise Manager tree
- From the database server tree
• Start the IA and dbsnmpwd on Linux with:
agentctl start agent
Intelligent
Listener
Agent
Database
Node
Installing the Intelligent Agent (IA)

The IA is shipped with the database and can be installed on remotely managed machines under
an ORACLE_HOME environment. By using the OUI, the IA can be selected for installation from
one of the following two locations: the Enterprise Manager tree list or the Database Server tree
list (this option installs the database and the IA). To install the IA as a stand-alone service, select
the IA from the Enterprise Manager tree list.
When you start the IA, another process called dbsnmpwd is also started. The dbsnmpwd
process is a watchdog that is responsible for automatically restarting the IA if it goes down. This
ensures that the IA is running at all times unless explicitly shut down.
On Linux, the dbsnmp master process is started. This process starts a pool of approximately 18
dbsnmp processes. This means that there will always be a process available to respond to
dbsnmp requests.
Use the agentctl command to start, stop, and check these processes:
To start the IA and dbsnmpwd: agentctl start agent
To stop the IA and dbsnmpwd: agentctl stop agent
To check the status of the IA: agentctl status agent

Intelligent Agent: Postinstallation Steps
• Run root.sh to update or create an oratab file.

• Check permissions for the dbsnmp executable.
• Verify whether the ORACLE_HOME and TNS_ADMIN
environment variables have been set.
• Verify whether the catsnmp.sql script has been
run.
Intelligent Agent: Postinstallation Steps

After you have successfully installed the IA, the OUI prompts you to run root.sh. This is a
shell script that updates or creates an oratab file. The oratab file is where the user places
references to all databases to be discovered by the IA and controlled by Enterprise Manager. For
each database that is created, the entry is of the form: <SID>:<$ORACLE_HOME>:[Y/N].
The dbsnmpwd executable is a Linux watchdog script, which ensures that the dbsnmp (IA)
process is always present on monitored targets. It restarts the IA when it exits abnormally. The
permissions for both these processes need to be -rwsr-s--- and the owner must be root.
(An ls –l command should show you the permissions.)
The root.sh script changes the permission on the dbsnmp process. If the root.sh script is
not run, then the dbsnmp process is owned by the Oracle installation user. In this case, the IA
can actually run without a node credential because the IA runs as the Oracle installation user.
This can also happen if you do a recursive chown or chmod command across the entire Oracle
Home.
Note: Do not install and start as root. If you change permissions, you may need to rerun
root.sh. After running the script, you must rename the script. By renaming it, you prevent it
from being overwritten by other installs.

Intelligent Agent: Postinstallation Steps (continued)
Ensure that the ORACLE_HOME and TNS_ADMIN environment variables are set correctly for
your site. The ORACLE_HOME variable defines where the Oracle software and related files are
located. TNS_ADMIN defines where the tnsnames.ora, listener.ora, and
sqlnet.ora files are located if not in the default location.
Also ensure that the catsnmp.sql script is run; normally catalog.sql runs this file. To do
this, you need to see whether the OEM_MONITOR role has been created. One way to do this is to
run the following query:
SQL> SELECT * FROM DBA_ROLES;
If the OEM_MONITOR role is not in the output from this command, then run the catsnmp.sql
script. The script is located in the $ORACLE_HOME/rdbms/admin directory.

Configuring Enterprise Manager Reporting
The Enterprise Manager Web site component must

be installed.
• By default, it is installed with the OMS under the
$ORACLE_HOME/oem_webstage directory.
• It is the same HTTP server that is used by default
for the browser-based Enterprise Manager.
Configuring Enterprise Manager Reporting

To access published reports, ensure that the Enterprise Manager Web site component has been
installed. By default, it is installed with the Management Server under the
Oracle_Home/oem_webstage directory. In addition, the Enterprise Manager Web site
automatically installs a preconfigured HTTP server to act as the reporting Web server. This is the
same HTTP server that is used by default for the browser-based Enterprise Manager.

Oracle HTTP Server (OHS)
• To start the OHS, use this command:
$ORACLE_HOME/Apache/Apache/bin/apachectl start
• To stop the OHS, use this command:
$ORACLE_HOME/Apache/Apache/bin/apachectl stop
• Start and stop the OHS only when you are logged
in as the oracle user.
Oracle HTTP Server (OHS)

By default, the OHS is installed with the Management Server under the
$ORACLE_HOME/oem_webstage/ directory. In addition, the Enterprise Manager Web site
automatically installs a preconfigured HTTP Server to act as its Web server. The Enterprise
Manager Reporting Web site uses the same HTTP Server.
To start the Oracle HTTP Server use:
$ORACLE_HOME/Apache/Apache/bin/apachectl start
To stop the Oracle HTTP Server use:
$ORACLE_HOME/Apache/Apache/bin/apachectl stop

The REPORTS_USER Administrator
You must change the REPORTS_USER administrator

password the first time and set Preferred Credentials:
The REPORTS_USER Administrator

You must change the default password (oem_temp) for the REPORTS_USER administrator
before you use this administrator for the first time. This administrator is the owner of all
predefined reports.
To change the password, perform the following steps:
1. From the Enterprise Manager Console, choose Manage Administrators from the
Configuration menu. The Manage Administrators Accounts dialog box appears.
2. Select REPORTS_USER from the list.
3. Click Edit. The Edit Administrator Preferences property sheet appears.
4. Enter a new password in the Password and Confirm Password fields.
5. Set Preferred Credentials on the appropriate tab for all the targets as needed.
6. Click OK.

Configuring the Report Server
Run the rws script with oemctl configure rws:
Configuring the Report Server

The oemctl configure rws script is a command-line utility that must be run on the
machine where the Management Server and the reporting Web server are installed. Before
executing the script, ensure that the Management Server on the reporting Web server machine is
running.
This script needs to be run so that that the OMS knows what machine the Web server is running
on, which port it is on, and the password to use to connect.
To run the configuration utility:
1. Go to the machine running both the Management Server and the reporting Web server.
2. At the command prompt, enter oemctl configure rws.

Configuring the Report Server (continued)
3. Follow the instructions provided by the utility. You are prompted for the following
information:
- Reporting Web server host name: Enter the full node name. This name must match
the ServerName entry in the httpd.conf file. Even the case must be the same.
The httpd.conf file is the Apache HTTP server configuration file. It is normally
located in $ORACLE_HOME/Apache/Apache/conf.
- Port Number: The default is 3339. Press [Enter] to accept the default value.
- Oracle Management Server host name: Enter the name of the machine that is running
the Management Server. This defaults to the name entered for the Web server.
- Password for the REPORTS_USER: Enter the REPORTS_USER password.
Note: You must change the password of REPORTS_USER from the default of
oem_temp. If you do not change the password, then the oemctl configure
rws script generates an error message.
4. Confirm that you want to proceed with the configuration.
If you choose View Published Reports from any Console menu (or enter the URL) before
running oemctl configure rws, then an error message is generated indicating that you
first need to configure the reporting Web site.

Reporting Home Page
Open a browser and enter the following URL:

http://<hostname>:3339/em/OEMNavigationServlet

Viewing a Predefined Report
Viewing a Predefined Report

There are more than fifty predefined reports ready for use. There are reports identifying the
current status, the setup, and the configuration of the environment. These reports are accessible
from the Console and the central reporting Web site.
From the Console Navigator pane under Network, select Report Definitions. Any report can be
published to a Web site for general viewing after an HTTP server is defined and configured for
use by the reporting system. You can see whether a report definition is published (globe icon
with a plus “+” subscript), not published (globe icon with a red “x” subscript), or scheduled
(globe icon with a clock subscript).
Select the report that you want to view (in the example, it is the Instance report), then right-click
and select View Report. Select your database and click OK.

Creating a New Report
Creating a New Report

In general, the standard predefined report definitions or their user-customized variants should
provide sufficient reporting capability. However, you may want to create your own report
definitions to meet specific monitoring needs. The reporting system provides you with a high
degree of flexibility in extracting data and generating a properly formatted report.
When you have created a custom report definition, it is added to the list of report definitions.
You can view this report just like any predefined report definitions.
To create a new report definition:
1. Right-click the Report Definitions object in the Console Navigator to display the context-
sensitive menu.
2. Choose Create Report. The Create Report property sheet appears.
3. Enter the required information on the various property pages.
4. Click OK to save the report definition.
For more details about creating reports, refer to the Oracle Enterprise Manager Administrator's
Guide.

Preferred Credentials for Jobs and Events
• Node credentials are required.

• By default, jobs and events use preferred
credentials to connect to nodes and databases.
• Preferred credentials can be overridden.
• Ensure that information is entered for each:
– Node: Valid OS username and password
– Database: Valid database username and password
• To set from the console:
– Configuration > Preferences >
Preferred Credentials
Preferred Credentials for Jobs and Events

When jobs are submitted or an event is registered, the IAs connect to machines (nodes) and
databases (if necessary) by using connection information stored as preferred credentials at the
time of job submission or event registration. If the preferred credentials are changed, then these
are not sent to the already submitted jobs or registered events.
If you do not set the node credentials before you submit a job or registered an event, you get an
error that the credentials are not set. The error window has a button, Set Credentials, which you
can click to set the credentials at that time.
You can override the node preferred credential for the entire job or event. The database preferred
credential can be overridden for each database task.

Creating a Job
1. Select Job > Create Job from the menu bar.

2. Complete the five pages of job details.
3. Submit the job, save it in the library, or do both.
Creating a Job
To create a job on any managed node, perform the following steps:
1. Select Create Job from the Job menu, press [Ctrl] + [J], right-click the Job icon in the tree,
or click the Create icon (green box) on the toolbar and then select Job from the tree.
2. Complete the five tabbed pages in the Create Job window:
- Use the General tab to specify the primary attributes of a job, such as the job name,
description, target type (Database, Node, Listener, or HTTP Server), targets, and so
on.
- Use the Task tab to choose the tasks that you want the job to perform.
- Use the Parameters tab to specify parameter settings for the selected job tasks. To set
the parameters for a task, select the task in the Selected Tasks list. The parameters for
the selected task are displayed on the right of the Parameters tabbed page.

Creating a Job (continued)
- Use the Schedule tab to schedule the execution of the job. The choices are
Immediately, Once, On Interval, On Day of Week, On Date of Month, or As a Fixit
Job. A fixit job is used with Events.
- Use the Access tab to allow other administrators to view or modify the job.
Notifications can be assigned on this tabbed page. Any permissions assigned on this
page supersedes any user default permissions that have been assigned with User
Preferences.
3. Decide whether this job needs to be run, saved in the library, or both run and saved in the
library.
4. Click Submit, Add, or Submit and Add to create the job. (The button name changes
depending on whether you have the Submit, Add to Library, or Submit and Add to Library
option selected.)
Note: Use the Help button to get context-sensitive Help on any of the tabbed pages.

Create Job: Tasks and Parameters
Create Job: Tasks and Parameters

The Tasks Tabbed Page
On the Tasks tabbed page, you define the tasks of the job. Each task can also be dependent on
the task before it. For each task, select one of the following:
• Always: Run the task always, whether the previous task succeeds or fails.
• Only on success of: Select the task that must succeed for this task to run. The task is
indented with a green flag. A successful task is defined as a task that receives no operating
system or database error messages.
• Only on failure of: Select the task that must fail for this task to run. The task is indented
with a red flag.
On the right of the page, you can select the tasks for the job. Depending on which target type is
selected on the General tabbed page, you are presented with a list of available tasks appropriate
for the target type.
The Parameters Tabbed Page
On this page, you can enter the appropriate parameters for the given task on the right. In the
example shown in the slide, you can select all the startup options, and select whether you want to
override the preferred credentials.

Viewing Job Progress
Viewing Job Progress

To display job details, select the job to view from the Active tabbed page in the Job window, and
then select Job > Edit Job from the Console or right-click and select Edit Job from the context-
sensitive menu. An Edit Job window appears, with one extra tab than the normal Edit Job
window. The additional tab is the Progress tab.
The Progress page shows what has happened to the job since it was submitted. While the job is
running, you can click the Update Progress button to see the most recent information. After a job
is completed, you can select the line with the final status (either Completed or Failed), and then
click the Show Output button to see additional information.

Creating an Event
1. Select Event > Create Event from the menu bar.

2. Complete the six pages of event details.
3. Register the event, save it in the library, or do
both.
Creating an Event
To access the Create Event window, select Event > Create Event, right-click the event icon and
select Create Event, click the Create icon on the console toolbar (the green box), select Create
from the menu bar, or press [Ctrl] + [E].
You then need to complete the six pages in the Create Event window:
• General: event name, target type, description, and monitored targets
• Tests: number and type of tests available depends on the target type selected on the General
page
• Parameters: parameters required for each chosen test
• Schedule: when and how often the event is evaluated on the targets
• Access: permissions (privileges) that other administrators have for this event
• Fixit Jobs: which (if any) fixit jobs run if the event is triggered
On the bottom of each page you can choose whether this event needs to be registered, saved in
the library, or both.

Create Event: Tests
Create Event: Tests

On this page, you can select the event tests that you want to monitor. Use the Add and Remove
buttons to move a test between the Available Tests and the Selected Tests regions. The order of
the tests can be changed by selecting one of the tests in the Selected Tests field and by using the
up and down arrows on the left of the window.
The Available Tests region displays tests depending on the destination type selected from the
General page. By expanding the tree, you can see the individual tests.
For a full list of all event tests with their descriptions, refer to the Oracle Enterprise Manager
Event Test Reference Manual.

Create Event: Parameters
The number and type of parameters vary based on the

test selected.
Create Event: Parameters

On this page, you specify the parameters that are required for the chosen event. The parameters
change depending on which event task has been selected. Many tests have no parameters.
The parameters specified are then passed as arguments to the appropriate script.
A test parameter may require some logical syntax. For example, the first test shown in the slide
has “*” for the filter, meaning all tablespaces. However, if you want to exclude the system
tablespace, you enter the following in the Set Value column for the tablespace name filter:
!= 'SYSTEM'
If you want only a set of tablespaces, you enter a value such as the following:
IN ('HR_DATA','INDEX01','ROLLBACK01')

Create Event: Fixit Jobs
• To be used as a fixit job, a job must be created
and submitted as a fixit job.
• Fixit jobs can be created and edited from the
Create Event or Edit Event dialog boxes.
Create Event: Fixit Jobs

A fixit job is designed to automatically correct a problem when a particular event condition is
encountered. For example, you may want the IA to run a job to restart a database when the
database instance has shut down unexpectedly. Fixit jobs are created with the job system and
must be designated as fixit jobs. The jobs must be submitted and running on the same destination
that the event is set on.
If a fixit job does not fix the problem that causes an event to be triggered, then it runs whenever
the event is checked (interval).
A fixit job can be used to get more information about the problem. For example, if the Disk Full
event gets triggered, then you can run a job to get a list of the files on the disk.
If no fixit jobs currently exist, then click Create to display the Create Job property sheet.

Viewing Event Status
Viewing Event Status

When an event test exceeds the value of a warning or critical parameter, the event occurrence
can be viewed in the Event and Group windows. Select the event that you are interested in and
right-click or select Event from the Console menu bar:
• Edit or view the event test status.
• Move an event to the History page when the occurrence has been fixed.
• Acknowledge that an event occurrence has been noticed by an administrator.
The Alerts page contains event occurrences that have been issued but not yet fixed. Further event
test information is obtained by viewing the event occurrence.
The Event and Group windows contain event occurrence information. An eyeglass icon under a
flag indicates an unacknowledged event that should be viewed by an administrator. If there is no
eyeglass icon, then the event has already been acknowledged.

Summary

• Configure Oracle Management Server
• Discover Oracle9i databases and nodes
• Configure the HTTP Server and Enterprise
Manager Reporting
• Configure and test jobs and events by using

Practice Overview:
Install and Configure Enterprise Manager

• Using Enterprise Manager Configuration Assistant
to create an Oracle Management Server repository
• Configuring preferred credentials for the Oracle
Management Server
• Configuring the reporting web server
Practice 5 Overview: Install and Configure Enterprise Manager


Customizing the Oracle9i Database

Objectives

the following:
• Create automated startup/shutdown scripts
• Automate tasks using scheduling tools
• Configure Linux startup and shutdown sequence

Controlling Oracle9i
After a server restart, all Oracle processes will be

down by default. In order for the Database Server to be
used, they must be started:
• Manually
• Automatically
Controlling Oracle9i
By default, the database and its related services do not start when the server is started.
Depending on your needs you will want to start all or some of the following services:
• Database Listener
• Database Instance
• Intelligent Agent (IA)
• Oracle Management Server (OMS)
• Oracle HTTP Server
These can be started manually through standard commands:
• lsnrctl start
• sqlplus “/ as sysdba” and then execute the startup command
• agentctl start
• oemctl start oms
• $ORACLE_HOME/Apache/Apache/bin/apachectl start
Or they can be started automatically. The next few pages discuss how to have the Oracle9i
Database and related services start automatically.

Linux Startup Sequence
Kernel
BIOS

Although there are distribution-specific differences, most servers running Linux will start up in
basically the same way.
The first step is to initialize the Built-In Operations System (BIOS). BIOS resides in a ROM
chip, usually on the system motherboard. BIOS initializes the hardware on the motherboard and
much of the hardware that is attached to the motherboard in preparation for loading the actual
operating system. BIOS will also look for a bootable disk, searching in the order defined within
the BIOS program. When it finds a bootable disk it checks the Master Boot Record (MBR) of
that disk for a boot loader. As soon as the boot loader is found, BIOS loads the code into
memory and passes control of the system over to the boot loader. Red Hat, SuSE, and
UnitedLinux use the same boot loader, the Grand Unified Boot Loader (GRUB).
There are other boot loaders available such as the Linux Loader (LILO), but none as flexible as
GRUB, which can load Linux, Windows, OS/2, BeOS, and more. The boot loader displays a
menu of boot options from the MBR (in a dual boot system, this is where you are offered the
chance to select which operating system [OS] will be used). It then uses the settings found in the
MBR to load the selected operating system kernel.

Linux Startup Sequence (continued)
After the kernel is loaded, it checks /sbin and starts the init process. This is process number
one. The init process reads /etc/inittab, which contains instructions telling the kernel to
run a basic setup script that describes actions such as how to set the system clock, where the
swap file is located, and what the global environment variables are.
In Red Hat Linux, that basic setup script is /etc/rc.d/rc.sysinit. In SuSE and
UnitedLinux, it is /etc/init.d/boot.
Here is where you become concerned as the administrator. After the basic setup script is run, the
init process continues reading /etc/inittab and makes its decisions on what to do next
based on which of the seven runlevels you have booted to. The run level you select will
determine who can log on, how many users can be logged on, and what services are available.
The runlevels are described in detail later in the lesson.
In Red Hat Linux, there are a series of directories under /etc/rc.d with names such as
rc0.d, rc1.d…rc6.d. In UnitedLinux and SuSE, these same directories exist under
/etc/init.d. For example, if you were to boot to runlevel 5 (the default), then the init
process would run scripts located in rc0.d, followed by scripts in rc1.d, rc2.d, rc3.d,
rc4.d and finally the scripts in rc5.d. On most systems, you will find that the scripts are not
actually in these directories, rather there are links to the scripts.

rc0.d Power off

/etc/rc.d/rc.sysinit
init
-or- /etc/init.d/boot rc1.d
• Runlevels 1 through 5 are
available on boot. rc2.d
• Runlevel 0 is the system
halt state, entered from rc3.d
runlevels 1–5 before
shutdown. rc4.d
• Runlevel 6 initiates a
system restart. rc5.d
rc6.d
Linux Startup Sequence (continued)

Each runlevel is associated with its own subdirectory. Within any given level’s subdirectory, you
will see scripts with names like these. These files are from rc5.d:
K15httpd K89bcm5820 S56xinetd
K25squid S05kudzu S60lpd
K34yppasswdd S10network S85gpm
K35vncserver S12syslog S90crond
K50snmpd S13portmap S90xfs
K50snmptrapd S17keytable S95anacron
K50tux S20random S95atd
K74ntpd S26apmd S99local
K74ypserv S55sshd S99reset
K74ypxfrd S56rawdevices S99vncserver
The scripts are executed in alphabetical sequence as the runlevel is entered. In this case, as
runlevel 5 is entered, the script K15httpd is executed, then K25squid, and so on until all scripts
have completed. Scripts beginning with a “K” (for “kill”) are intended to stop services, scripts
beginning with an “S” (for “start”) are intended to start services.
Linux allows movement between runlevels through the init command. From runlevels 1–5,
you can move to any other runlevel, including the two special runlevels 0 and 6. Runlevel 6
initiates a system reset, runlevel 0 enters the system halt state (all services stopped) and is used
to properly shut the system down before power off.
Linux Runlevels
Runlevels determine which services are available.

• Red Hat, SuSE, and UnitedLinux runlevels:
– 0 = halt
– 1 = single user
– 3 = multiuser, network
– 5 = multiuser, X
• Default runlevel is usually 5 but may be changed
on startup.
• Runlevels may also be changed with the init
command.
# init 3
Linux runlevels
Linux uses runlevels to determine which services to start or stop. For example, at certain
runlevels the graphic user interface might not be started. The meaning and services started at the
different runlevels is distribution dependent, but for SuSE, Red Hat, and UnitedLinux it is as
follows:
• Runlevel 0: Halt. It is used to shut down the system.
• Runlevel 1: Single-user (maintenance) mode. Only root may log in.
• Runlevel 2: Multiuser mode, text-based console only
• Runlevel 3: Multiuser mode with networking
• Runlevel 4: For custom use in SuSE, Red Hat, and UnitedLinux
• Runlevel 5: The default mode; multiuser with networking and active X session
• Runlevel 6: Reboot. This shuts everything down and then starts it back up.
Booting to a nondefault runlevel
GRUB provides a way to specify the runlevel on startup from the OS selection menu. For SuSE
and UnitedLinux, just hit the spacebar and select the runlevel you want to boot to. For Red Hat
Linux, you press “e” then scroll down to select the kernel, press “e” again, press the spacebar,
enter the runlevel you want to boot to, then press “b”.
Your current and previous runlevel can be found with the runlevel command.

Linux runlevels (continued)
Managing Services with chkconfig
System administrators must create a link in each runlevel directory for each service that should
be available at that runlevel. A manual creation of these links is time consuming and prone to
errors. A tool called chkconfig is provided in the SuSE, Red Hat, and UnitedLinux
distributions modeled after a tool on IRIX, which provides a simple way to add and delete
services to runlevels. You can also use the graphical tools redhat-config-services and
YaST to manage services.
A service script named oracle can have the following comment lines. These comment lines
specify the runlevels and the order numbers for the start and kill.
# chkconfig: 2345 10 90
# description: starts and stops the oracle database
This says that the links to this script should be named S10oracle and K90oracle and be
present at the runlevels 2, 3, 4, and 5.
With these comment lines in place, the command chkconfig --add oracle
adds the links to the script into the appropriate directories. chkconfig --del oracle
removes the links, and chkconfig --list oracle shows the runlevels and the state of
the oracle service at each runlevel.

Database Startup and Shutdown
Create an oracle services script to automate startup

and shutdown.
• Create a script named oracle.
• Place it in the /etc/rc.d/init.d directory.
• Use chkconfig to set the runlevels.
Startup Database Shutdown
Database Startup and Shutdown

Most servers are not shut down often, and the system administrator may not be familiar with the
commands for doing a proper shutdown of the database. Because of this, it is a good idea to
provide a script to shut down the database in each of the runlevel directories. This ensures that
the database does a proper shutdown without DBA involvement. If a server crashes, you want
the database to be open as soon as possible after the machine is started. By placing startup scripts
in each of the proper runlevel directories, the database and related services can be started
automatically.
Create a Script Named oracle
The name of this script is arbitrary. Naming it oracle can be convenient because the name of
the script is echoed to the console during the boot process. This script can start all the database-
related processes as is shown in the example, or the script may be broken into multiple scripts
that start and stop the processes separately. In this example, the order in which the processes are
started is important. Start the listener first, then the databases, then OMS (because it connects to
a repository database on startup), and finally the Intelligent Agent because it attempts to open a
connection to each database on the machine.

Database Startup and Shutdown (continued)
Example Script
# Oracle database startup script
# chkconfig: 2345 99 10
# description: starts and stops the Oracle database
# Since this script runs from root
# the ORA_HOME and ORA_OWNER must be set
# "su -" to the oracle owner account to be sure the
# environment is set
ORA_HOME=/u1/app/oracle/product/9.2.0
ORA_OWNER=oracle
if [ ! -f $ORACLE_HOME/bin/dbstart -o ! -d $ORACLE_HOME ] ; then
echo "Oracle startup: cannot start"
exit
fi
case "$1" in
'start')
ulimit -u 16384
/bin/su - $ORA_OWNER -c "lsnrctl start LISTENER"
/bin/su - $ORA_OWNER -c $ORA_HOME/bin/dbstart
/bin/su - $ORA_OWNER -c "$ORA_HOME/bin/agentctl start"
/bin/su - $ORA_OWNER -c "$ORA_HOME/bin/oemctl start oms"
# create /var/lock/subsys/oracle to make sure the oracle stop command
runs
touch /var/lock/subsys/oracle
;;
'stop')
/bin/su - $ORA_OWNER -c "$ORA_HOME/bin/oemctl stop oms
sysman/oracle“
/bin/su - $ORA_OWNER -c "$ORA_HOME/bin/agentctl stop"
/bin/su - $ORA_OWNER -c "lsnrctl stop LISTENER"
/bin/su - $ORA_OWNER -c $ORA_HOME/bin/dbshut
;;
esac
The stop commands are in sequence and the database is stopped in the end. Any process that is
not stopped here is stopped by the killall command later during the shutdown process. By
stopping the agent and OMS before stopping the database instances, the instances shut down
quickly. You need a password to stop OMS. The scripts in the init.d directory must be
protected with permissions set to 700 (that is read, write, and execute by the owner only). Red
Hat uses a subsystem lock file at /var/lock/subsys/<service_name>. The stop script
runs only if the file exists. SuSE and UnitedLinux have the /var/lock/subsys directory but
will try to stop a service regardless of there being an entry in that directory. Because most
distributions do use the/var/lock/subsys directory to track service status, you should go ahead and
create the lock file regardless of your distribution.

Automating Jobs
Automate the following jobs to leverage your time:

• Backups
• Database startup and shutdown
• Gathering database statistics
• Monitoring database health
• Monitor processes: listener, agent, HTTP server
Automating Jobs
Much of a your work as a DBA must be done outside normal working hours, or at least during
off-peak hours. In many companies, you are asked to support more databases and more hours of
the day or night. Automating routine jobs is a way of reducing the work load. These routine jobs
include:
• Doing backups and maintaining backup scripts
• Starting up and shutting down the database
• Gathering statistics on the database and OS
• Monitoring the health of the database and related processes
Ensure that the database starts up when the machine boots, and more importantly make sure that
the database does a proper shutdown before the machine is shut down. Monitor the database and
related processes so that you are aware of a problem before the users start calling you.

OS Scheduling Tools
Linux offers the standard UNIX tools for scheduling:

• cron and anacron
• at and batch
• Task Scheduler
OS Scheduling Tools
Linux offers several scheduling tools that usually are a variation of the standard cron and at
tools, or a GUI for one of these tools. Task Scheduler is one of these user interfaces that makes
cron and at easier to use.
cron
The system cron daemon is usually started as part of the boot process. Security for cron is
handled by the system administrator by using the /etc/cron.allow and
/etc/cron.deny files. The cron daemon checks the system-level schedule in the
/etc/crontab file and user-level schedules in the /var/spool/cron directory. On Red
Hat, there is also a set of directories /etc/cron.hourly, /etc/cron.daily,
/etc/cron.weekly, /etc/cron.monthly that hold executable scripts. If the system
administrator puts an executable script into one of these directories, then cron runs the script at
the appropriate interval.

OS Scheduling Tools (continued)
cron (continued)
The format of an entry in the crontab file is <minute> <hour> <day> <month>
<weekday> <cmd>. If any of these fields has a “*”, then the meaning is “every.” A crontab
entry to run a backup script might look like
14 22 * * 1-5 su - oracle -c /usr/local/bin/backup.cmd >/dev/null 2>&1.
This command runs 14 minutes after 10 p.m. every weekday of every month, Monday through
Friday. The command says, log in as the oracle owner and execute backup.cmd, sending
the standard out to /dev/null, the bit bucket, and standard error to the same place.
anacron
It is an interesting variation of cron that does not require the system to be running continuously.
The anacron daemon periodically checks the /etc/anacrontab file, and verifies whether
the task has been executed within the time specified in the Period field of the configuration file.
If not, anacron executes the command specified after waiting for the number of minutes
specified in the delay field.
at and batch
The at command executes a command once at a specified time, as opposed to cron that
executes recurring commands. The atd daemon runs the at commands and the batch
commands. The batch commands wait until the system load average drops below 0.8, and then
executes the given commands.
Task Scheduler
There are GUI task schedulers available that are front ends for cron in both the Gnome and the
K(ommon) Desktop Environment (KDE).

Enterprise Manager Job System
The Oracle Enterprise Manager Job system provides a

way to schedule jobs against the database or node.
• You can schedule SQL scripts.
• You can schedule RMAN scripts.
• You can schedule OS commands.
• You can start up and shut down the database, the
listener, or the HTTP server.
Enterprise Manager Job System

In the Enterprise Manager Job system, you can schedule a job to run at a particular time or
interval. You can specify the tasks that are part of that job and whether these tasks depend on one
another. Each task can be run against an instance of a database or a node. A task can be SQL
scripts, OS commands, RMAN scripts, or TCL scripts. The tasks that make up a job are executed
by the Intelligent Agent on the specified node or nodes. The Enterprise Manager Job system
provides a convenient way to centralize all your recurring jobs. You can use the Job Wizard to
create, register, execute, and save jobs.
To use the Enterprise Manager Job system, you must create a repository and connect to an OMS.

Administrative Scripts
Oracle Corporation provides a set of administrative

scripts.
• Set the user environment by using:
– oraenv
– coraenv
– dbhome
• Start up and shut down databases by using:
– dbstart
– dbshut
Administrative Scripts
Oracle Corporation provides a set of scripts to aid the DBA. In some shops the user environment
could be constantly changing. An end user may need to access multiple databases running with
different ORACLE_HOME directories. Databases may be frequently moved or upgraded. These
changes should be transparent to the end user and not a burden on you (the DBA). The scripts
oraenv, coraenv, and dbhome give you the flexibility needed in these situations. The
oratab file found in the /etc or /var/opt/oracle directory lists the instance name, the
ORACLE_HOME directory, and whether this instance participates in automated startup and
shutdown. The dbhome script retrieves the ORACLE_HOME information from the oratab file
based on the ORACLE_SID instance name. When a user logs in, the login script must source
oraenv. The oraenv script prompts the user for the desired instance and sets the
ORACLE_HOME and PATH variables. The oraenv script is also the place to add local
customizations.
Oracle Corporation provides the dbstart and dbshut scripts that must be modified for your
site. One generic change is to replace every SHUTDOWN command with SHUTDOWN
IMMEDIATE in the dbshut script. This ensures that the database shuts down. These scripts
read the oratab file, determine which databases participate in automated startup or shutdown,
and start up or shut down these databases.

Administrative Scripts (continued)
dbstart
The dbstart script that is provided with 9.2.0.1 does not start the instance if a PFILE does
not exist. In Oracle9i, it is recommended that you use an SPFILE. A PFILE is not created by
default when the database is created. An SPFILE is created instead. Two workarounds are
listed.
• Change the dbstart script to test for an SPFILE or create a PFILE. The dbstart
script is found in the $ORACLE_HOME/bin directory. To change the dbstart script,
find the line
PFILE=${ORACLE_HOME}/dbs/init${ORACLE_SID}.ora
and add a line
SPFILE=${ORACLE_HOME}/dbs/spfile${ORACLE_SID}.ora.
Find the line if [ -f $PFILE ] ; then and change it to
if [ -f $PFILE -o -f $SPFILE ] ; then.
These two changes name the location of the SPFILE and force the script to test for either
an SPFILE or a PFILE before attempting to start the instance.
• Create a PFILE that matches the SPFILE. Use the following from SQL*Plus:
SQL> CREATE PFILE = '?/dbs/init@.ora' FROM SPFILE =
'?/dbs/spfile@.ora';
Note: The “?” is a Linux shortcut for $ORACLE_HOME and “@” is a shortcut for
$ORACLE_SID.
dbshut
The dbshut script that is provided with 9.2.0.1 does a shutdown normal. In this mode, the
shutdown will not complete until all the sessions that are accessing the database are
disconnected. When you use this to automate a shutdown, you should change it to shutdown
immediate. This mode terminates all connections, including the IA, and then shuts down the
database. The dbshut script can be modified as follows. Find all the lines that have the
shutdown command (shutdown) and change the command to shutdown immediate.
oraenv
The oraenv script provides a place to insert site customizations (such as adding environment
variables). Find the lines:
#
# Install any "custom" code here
#
Add the site customizations after this. For example: LD_LIBRARY_PATH=$ORACLE_HOME/lib

Database Backups
Database backups are essential. The options for

backing up your database are:
• User-managed backup with OS tools
• User-managed backup with third-party tools
• Server-managed backup with RMAN
Database Backup
Database Backups
Backups are required by most businesses. The method and the frequency are often dictated by
business requirements. The method should be chosen based on availability requirements,
convenience, performance, and Mean Time To Recover (MTTR).
User-Managed Backups with OS Tools
Backups can be created by using standard OS tools such as tar, cpio, and cp. It is the user’s
responsibility to understand the limitations of these tools.
User-Managed Backups with Third-Party Tools
There are several third-party backup solutions. The most important consideration is whether the
tool you choose coordinates with the Oracle database. The database must be shut down, or the
tablespaces put into backup mode before the back up takes place. Many vendors provide an
Oracle database agent module to provide this functionality.
Server-Managed Backups with RMAN
Oracle Corporation provides an integrated tool to perform backups called Recovery Manager
(RMAN). This tool works with the database instance to make reliable backups.
Note: Use the full pathname to invoke RMAN: $ORACLE_HOME/bin/rman. By doing this,
you avoid any path problems. There is a different Linux utility named rman.

Backing Up with RMAN
Recovery Manager is the recommended solution,

because it:
• Provides tight integration with the Oracle database
• Understands raw partitions
• Can be scripted and scheduled
• Allows finer-grained recovery options
RMAN> BACKUP DATABASE;
Backing Up with RMAN

The Recovery Manager tool is bundled with every installation of the Oracle database. It uses the
instance to facilitate the backup. RMAN handles raw partitions in the same manner that the
database instance does. RMAN can be scripted and scheduled from OS schedulers or as an
Enterprise Manager Job. A full database backup can be simple (such as the command shown in
the slide) or complex, depending on your requirement. Recovery Manager has a full range of
commands that allow detailed control of the backup.
You should use the available tools to make the backups self-scripting so that the backup scripts
have zero maintenance.
RMAN backups are covered in detail in the Oracle9i DBA Fundamentals II course and in the
Oracle9i Recovery Manager User's Guide.

Initialization Parameter File
With an Oracle9i database, you can use a server

parameter file SPFILE or the initialization parameter
file PFILE:
• An SPFILE is recommended.
• An SPFILE is maintained by the server.
• The STARTUP command always uses the
same SPFILE.
SPFILE PFILE
Initialization Parameter File

With Oracle9i, you have a choice to use the default SPFILE or the traditional PFILE. It is
recommended that you use the SPFILE. The traditional PFILE is still available and is used to
back up the SPFILE. A PFILE can be imported into an SPFILE with the CREATE SPFILE
FROM PFILE SQL command. The SPFILE can be exported to a PFILE with the CREATE
PFILE FROM SPFILE SQL command.
The SPFILE is maintained by the server. It is a binary file and you must not edit it. To modify
just the SPFILE, use the SQL command ALTER SYSTEM SET <parameter_name> =
<value> SCOPE=SPFILE. The default SCOPE=BOTH modifies the running instance and the
SPFILE.
The STARTUP command without a PFILE option searches the default location
$ORACLE_HOME/dbs on the server for an SPFILE named spfile<ORACLE_SID>.ora.
It then searches for spfile.ora.
If the STARTUP command is executed locally to the instance, then the search continues in the
default location for a PFILE named init<$ORACLE_SID>.ora. If the command is
executed remotely from Instance Manager, then the PFILE must be either available on the
machine where the command was executed or stored as a configuration in the Enterprise
Manager repository.

Summary

• Automate tasks using scheduling tools
• Configure Linux startup and shutdown sequence

Practice Overview:
Automating Tasks

• Making a backup with RMAN by using Enterprise
Manager to schedule the job
• Selecting an initialization parameter file type
• Automating the startup and shutdown of
the database
Practice 6 Overview: Automating Tasks


Linux Measurement Tools

Objectives

the following:
• Identify and use basic measurement tools
• Measure the CPU load
• Gather memory usage statistics
• Gather input/output (I/O) load statistics
• Collect network activity statistics

Basic Tuning Methodology
Tune the database

for the hardware.
Tune the hardware

for the database.
Basic Tuning Methodology

When you tune your system, you have to work in a cycle. In most cases, you start with a given
hardware configuration where you deploy your Oracle database. First you work with this
hardware and tune it for best performance.
Be ready to reevaluate your hardware configuration as system requirements change. When
evaluating new hardware, your primary considerations should be based on memory, storage I/O
capability, and CPU power. For most systems, the requirements should be evaluated in that
order.
Over time, your system requirements change and you need to modify your hardware. For this
you may need to tune your database. This process continues for the life of your system.

Standard Measurement Tools
Linux has measurement tools that are common to

UNIX platforms:
• Top Resource Consumers: top
• System Activity Reporter: sar
• Virtual Memory Statistics: vmstat
• I/O Statistics: iostat
• System Log files: /var/log/messages
Standard Measurement Tools

Linux, like every operating system (OS), has tools available for measuring system performance.
The Open Source community has developed a series of tools that measure almost everything that
you want to measure. Many of those are traditional tools adopted from the Unix environment.
The tools mentioned here are the ones that are available across most Unix and Linux
environments. However, this is not an all-inclusive list. These tools are either installed by default
with your distribution or freely available via the World Wide Web.
Top Resource Consumers: top
The real-time monitoring tool top is available on almost every flavor of UNIX/Linux. It shows
the CPU load averages, memory usage, I/O waits, and a detailed listing of the top processes
sorted by some resource, and CPU utilization, by default. Use top to begin your tuning and then
drill down with other tools.
top is particularly useful for diagnosing CPU and I/O issues, though not as reliable for Oracle
memory issues. Although top’s aggregate memory statistics are dependable, individual process
memory numbers should not be relied upon. Memory statistics for a process show all allocated
memory, including shared memory. Because Oracle processes share the System Global Area
(SGA), it shows up multiple times. The same shared memory segment will show up as belonging
to PMON, SMON, CKPT, and the other Oracle processes.

Standard Measurement Tools (continued)
System Activity Reporter: sar
sar provides a variety of ways to look at the system activity including memory, I/O, and CPU
usage. In addition to viewing snapshots of system activity, sar collects regular samples of
statistics to a file that can be queried for particular activity at particular times. If you are already
familiar with sar from some other UNIX variant, check the man pages to verify the options,
because they are different on Linux. It is usually executed with three arguments:
$ sar <options> <interval> <count>
The <options> flag determines what the output of sar will be. The report can include
statistics on memory use, I/O, system processes, interrupts, network and more.
In addition to providing real-time metrics, sar samples the /proc file system at 10-minute
intervals and records the data in /var/log/sa as a file sa# where # is the day of the month.
A full month’s worth of statistics are retained so that the administrator can use sar to view past
statistics as well as current. For example, to view the CPU statistics for the 23rd of the month:
sar –u 2 4 –f /var/sa/sa23
Virtual Memory Statistics: vmstat
Probably the best tool for monitoring memory usage, the vmstat program reports information
about processes, memory, paging, block IO, traps, and CPU activity. It is usually executed with
two arguments:
$ vmstat <interval> <count>
with <interval> being the number of seconds between statistics samplings and <count>
being the number of samples to take. Unlike sar, the vmstat report allows very little
customization (you can give a –n option before the interval to suppress the report page header).
I/O Statistics: iostat
Disk activity, disk queue lengths, and hot spots are all important pieces of information for tuning
the I/O related to the database. The iostat program provides these statistics, overlapping and
extending the disk statistics available from sar.
System Log Files: /var/log/message ../syslog
The operating system maintains various log files that can be of use in monitoring and tuning the
system.

Linux-Unique tools
Linux also has tools that are unique to this operating

system:
• X-based tools: xosview
• /proc virtual file system
• Free and Used Memory: free
• Distribution-unique tools
– UnitedLinux: ifstat
– Red Hat Linux: System Monitor
Linux-Unique Tools
Graphical Measurement Tools
For Linux systems running X, there are a variety of graphical tools that can be installed to
monitor performance. The biggest advantage of X-based tools is the ease of interpretation.
X-Operating System View: xosview
The xosview tool shows CPU, disk, memory, and network activity. SuSE and UnitedLinux
install xosview by default. The package for xosview is distributed with Red Hat, but is not
part of the default install.
Note: Remember that X-based tools tend to influence the output by their own load on the CPU;
because of this they may not be the most accurate measurements of CPU usage.
Virtual Process File System: /proc
The /proc file system is a virtual file system that provides a look into the background workings
of the operating system. You can think of it as the Linux equivalent to Oracle’s v$ views. The
/proc file system exists in many Unix variants, whereas its contents are greatly expanded under
Linux.
Free Memory: free
The free command displays the total amount of free and used physical and swap memory in
the system, as well as the shared memory and buffers used by the kernel.
Linux-Unique Tools (continued)
Process Tree: pstree
This tool displays the relationship between processes in a tree structure, with parents to the left
and children to the right:
$ pstree
init-+-2*[Xvnc]
|-apmd
|-oafd
|-26*[oracle]
|-perl-+-emagent---emagent---4*[emagent]
`-java---java---52*[java]
Because the init process is system process number 1, it will always appear to the left. In this
snippet from the pstree output, you can see that there are two Xvnc processes running, 26
Oracle process running, and that the perl process has started two children, each of which has
started several other processes.
Resource Limits: ulimit
This tool shows the resources available to your shell. This tool is shell dependent; with the C
shell you would use limit –h instead.
/> bash
# ulimit –a (the –a flag shows all current limits)
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
And many more
If it is measurable, chances are that there is a Linux package already written to measure it. Many
more utilities may be available depending on your distribution and which packages you have
installed. Consult your distribution-specific documentation for more information. Also, Oracle
provides Oracle Enterprise Manager, which provides a great deal of performance monitoring
information about the systems it is monitoring. Oracle Enterprise Manager will be discussed in
greater detail in the lesson titled “Oracle9i Measurement Tools.”

Common Areas to Tune
CPU I/O
Memory
Network
Common Areas to Tune

System performance depends on how efficiently system resources are used. In most systems, the
key resources that affect performance are CPU, memory, disk I/O, and network.
Central Processing Unit (CPU)
The CPU is the heart of your system. If CPU performance is poor it does not matter what else
you tune, your system will be slower than it could be.
Memory
Memory is a common system bottleneck. It is usually divided into two generic categories: real
and virtual (swap). Any running process consumes some memory.
Disk Input/Output (I/O)
Although other device I/O can affect performance, disk I/O is usually the most critical type of
I/O. How fast and reliably can you move data to and from a disk? This is often the slowest factor
in a system, and can be one of the most difficult to tune.
Network
The network is the gateway into your system. Few modern systems are self-contained within a
single server. Most depend on external connections either from clients or middle-tier machines.

Monitoring and Tuning CPU
Tools for monitoring and tuning CPU include:

• top
• pstree
• vmstat
• sar
• xosview
• xload
• System Manager
(Red Hat) xload
Monitoring and Tuning CPU

Before you start tuning the CPU, you must identify if the CPU is a bottleneck for system
performance. For this step, you normally use high-level tools such as top, pstree, or one of the
many graphical utilities available for Linux such as xosview and xload. If CPU is a problem
for your system, then you drill down to find the source of that bottleneck with fine-grained tools
such as sar or vmstat.
/proc Virtual File System
All the tools mentioned above use the /proc virtual file system as a source of performance
information. The raw data contained within /proc exposes a wealth of information about CPU
resources. Interesting files include:
• /proc/cpuinfo
• /proc/stat
• /proc/loadavg

Is the CPU a bottleneck?

• How many CPUs does the machine have?
• What is the load average?
• What is the load factor?
– <1: CPU probably not a bottleneck
– Between 1 and 2: Running at capacity
– >2: CPU may be a bottleneck, investigate
• Partial output from top:
09:11:01 up 59 min, 12 users, load avg: 4.32, 5.03, 4.72
320 processes: 307 sleeping, 12 running, 1 zombie, 0
stopped
cpu states: 69.8% user 4.6% system 1.5% nice 0.0% iowait
23.9% idle

To answer this, you have to know a few things about your system.
• How many CPUs does your machine have? You can find this by checking
/proc/cpuinfo or with commands such as mpstat.
• What is the average load on your system? There are many ways of finding this, but the
easiest is to use top. The output from top shows you the load average for the past 10
minutes with three samples (now, 5 minutes ago, 10 minutes ago).
load average: 4.32, 5.03, 4.72
• What is the load factor for your system? The load average does not mean a lot taken by
itself. It only gives the number of process receiving service from the CPUs at any given
time. These numbers would be a matter for concern on a uniprocessor box (or even a two-
processor box), but would not be something to worry about on a four or more processor
box. Load factor is a more relevant metric. To calculate the load factor, divide the load
average by the number of CPUs:
load average = load factor
#CPUs

Is CPU a bottleneck? (continued)
• If your load factor is:
- <1, you have CPU capacity to spare and it is unlikely that you are CPU bound
- Between 1 and 2, your system is running at capacity
- >2, CPU may be a bottleneck in your system, and you should investigate further using
other tools such as sar or vmstat
Full Output from the top Command
09:11:01 up 59 min, 12 users, load average: 4.32, 5.03, 4.72
320 processes: 307 sleeping, 12 running, 1 zombie, 0 stopped
CPU states: 69.8% user 4.6% system 1.5% nice 0.0% iowait 23.9% idle
Mem: 385112k av, 378740k used, 6372k free, 0k shrd, 37812k buff
287620k actv, 0k in_d, 6384k in_c
Swap: 779144k av, 303648k used, 475496k free 90592k cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
1973 root 25 0 23480 9872 956 R 59.4 2.5 4:28 0 X
2487 oracle 15 0 29596 24M 1576 S 2.5 6.6 1:41 0 jre
2816 susan 15 0 21768 19M 1036 S 2.3 5.1 0:15 0 jre
2126 oracle 16 0 1080 1048 420 S 2.1 0.2 0:56 0 top
3218 root 16 0 1504 1504 860 R 2.1 0.3 0:02 0 top
3028 oracle 25 10 2820 2636 2052 R N 1.5 0.6 0:06 0 sproingies
2061 oracle 15 0 5852 2168 1100 S 0.9 0.5 0:08 0 rhn-applet-gui
1675 root 15 0 1800 728 540 S 0.7 0.1 0:12 0 snmpd
2602 oracle 15 0 8284 6452 1552 S 0.7 1.6 0:30 0 dbsnmp
1426 root 15 0 200 164 116 R 0.5 0.0 0:08 0 syslogd
2329 root 15 0 25876 9M 824 R 0.5 2.6 6:52 0 X
15 root 15 0 0 0 0 SW 0.3 0.0 0:09 0 kjournald
3008 root 15 0 12612 11M 7864 S 0.3 3.0 0:04 0 rhn-applet-gui
2212 root 15 0 26124 10M 812 R 0.1 2.7 9:01 0 X
2262 rlowenth 15 0 5836 2144 1084 S 0.1 0.5 0:12 0 rhn-applet-gui.
Many people do not realize that top is an interactive utility. From within top, you can enter
“?” to see a list of options. One more useful interactive command is “u” which allows you to
identify a single user for the top display output. For example, if you enter “u” and then type in
“oracle” then your list of processes would only include processes started by oracle. The
top displays’ default refresh rate is every two seconds, but you can change that interval with the
“s” command. When top is run by root, you can kill processes directly from within top by
using the “k” command.

CPU Measurements
Identify the following CPU statistics and interpret

them:
• CPU Idle time
• CPU time spent executing user code
• CPU time spent executing system code
• Processes waiting for CPU time (run-queue)
CPU Measurements
Although there are dozens of different CPU measurements that you can look at, the ones listed in
the slide are the most important. These have the same meaning but slightly different labels
depending on the tool that is used to view them.
CPU Idle Time
This indicates the amount of time that CPU is in an idle state. Idle time is labeled %idle in
sar, id (under the CPU heading) in vmstat, and idle in top. If you are experiencing
performance problems, and CPU shows high idle time, then the system is not CPU bound.
CPU Time Spent Executing User and System Codes
These statistics have to be considered together. Together they represent the useful work that is
being done by the CPU. User time indicates the time that is spent in executing code in the user
space. System time measures the time that is spent in executing system calls. Every application
has a characteristic ratio of user to system. With an Oracle database, you should expect a ratio of
approximately 60% user code to 40% system code. If the user code percent is significantly
higher, then there may be inefficiencies in the application code. If the system code percentage is
significantly higher, look for system activity, such as high rates of disk I/O or memory swap.

CPU Measurements (continued)
run-queue size
The run queue size indicates the number of processes that are ready to run. Processes that are
blocked (waiting on I/O or for other reasons) are not counted in the run queue. All the processes
in the run queue are waiting for a time slice of the CPU. If the run queue size is more than one,
performance could probably be increased by adding additional CPUs
Obtaining CPU Measurements
There are several ways to obtain the key CPU metrics. Each of these tools give a slightly
different view of the same information about the CPU activity.
# vmstat <interval> <count>
# mpstat -P <CPU> <interval> <count>
# sar -u <interval> <count>
# sar -q <interval> <count>
# iostat -c <interval> <count>
vmstat, mpstat, and iostat get their information directly from the /proc file system.

Measuring CPU Activity with vmstat
# vmstat <interval> <count>
# vmstat 2 5
procs system cpu
r b w … in cs us sy id
0 0 0 … 11 42 3 1 96
1 0 0 … 106 141 0 1 99
0 0 0 … 109 134 0 0 100
1 0 0 … 103 146 7 1 92
0 0 0 … 107 125 0 0 100
Note: Memory and IO statistics removed for readability
Measuring CPU Activity with vmstat

The output of vmstat shows the key CPU metrics measured over the specified interval and
time period. In the partial listing above:
• cpu / us = CPU time spent executing user code
• cpu / sy = CPU time spent executing system code
• cpu / id = Idle CPU time
• procs / r = Processes waiting for CPU (run-queue size)
Other CPU metrics shown are:
• procs / b = Processes in uninterruptible sleep
• procs / w = Processes swapped out, but runnable
• system / in = Interrupts per second
• system / cs = Context switches per second
A full example of the vmstat command follows:
# vmstat 2 2
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 78748 48720 97540 453688 0 0 4 60 11 42 3 1 96
1 0 0 78748 48716 97540 453688 0 0 0 8 106 141 0 1 99

Measuring CPU Activity with mpstat
# mpstat -P <CPU> <interval> <count>
# mpstat -P ALL 1 1
Linux 2.4.9-e.3enterprise (delphi) 04/01/2003
cpu %user %nice %system %idle intr/s
all 19.50 0.00 31.50 49.00 111.00
0 27.00 0.00 42.00 31.00 111.00
1 12.00 0.00 21.00 67.00 111.00
Measuring CPU Activity with mpstat

Unlike the vmstat command, the mpstat command allows you to drill down into CPU
statistics by processor. In a multiprocessor system, this can give you a more detailed picture of
what your CPUs are doing than vmstat. Unfortunately, mpstat will not show you the run-
queue size. A full example of the mpstat command is as follows:
$ mpstat -P ALL 1 1
08:09:21 AM cpu %user %nice %system %idle intr/s
08:09:22 AM all 19.50 0.00 31.50 49.00 111.00
08:09:22 AM 0 27.00 0.00 42.00 31.00 111.00
08:09:22 AM 1 12.00 0.00 21.00 67.00 111.00

Measuring CPU Activity with sar
# sar -u <interval> <count>
# sar -u 2 5
Linux 2.4.9-e.12smp (delphi) 02/26/2003
cpu %user %nice %system %idle
all 36.25 0.00 1.75 62.00
all 23.75 0.00 1.50 74.75
all 33.25 0.00 1.50 65.25
Average:32.70 0.00 1.50 65.80

You can also use the System Activity Reporter (sar) command to retrieve information about
CPU performance. Like the mpstat command, the sar command returns information about
the division of work within the system.
$ sar -u 2 5
08:12:14 AM cpu %user %nice %system %idle

08:12:16 AM all 30.50 0.00 1.75 67.75
08:12:18 AM all 39.75 0.00 1.00 59.25
08:12:20 AM all 36.25 0.00 1.75 62.00
08:12:22 AM all 23.75 0.00 1.50 74.75
08:12:24 AM all 33.25 0.00 1.50 65.25
Average: all 32.70 0.00 1.50 65.80

# sar -q <interval> <count>
# sar -q 2 3
runq-sz plist-sz ldavg-1 ldavg-5
2 79 1.16 0.98
1 79 1.16 0.98
1 79 1.16 0.98
Average: 1 79 1.16 0.98
Measuring CPU Activity with sar (continued)

To monitor the processor queue, including the run-queue (displayed with sar as runq-sz),
you can use the sar –q command.
#sar -q 2 5
08:12:30 AM runq-sz plist-sz ldavg-1 ldavg-5

08:12:32 AM 1 79 1.17 0.98
08:12:34 AM 1 79 1.17 0.98
08:12:36 AM 2 79 1.16 0.98
08:12:38 AM 1 79 1.16 0.98
08:12:40 AM 1 79 1.16 0.98
Average: 1 79 1.16 0.98
Also show with sar -q are:
plist-sz: Process list size showing the number of processes running in memory
ldavg: The load average for the last minute and last five minutes

Measuring CPU Activity with iostat
# iostat -c <interval> <count>
# iostat -c 2 3
avg-cpu: %user %nice %sys %idle
3.50 0.05 0.83 95.61
41.00 0.00 1.25 57.75
30.00 0.00 1.00 69.00
Measuring CPU Activity with iostat

Although it is normally used to measure data flow to and from disk devices, iostat also
produces basic CPU statistics.
$ iostat -c 2 3

3.50 0.05 0.83 95.61

41.00 0.00 1.25 57.75

30.00 0.00 1.00 69.00

Interpreting CPU Measurements
When interpreting CPU measurements, observe cases

where the system has:
• High idle time with poor response time
• Too much time spent executing user code
• Too much time spent executing system code
• Run-queue size more than double the number of
CPUs
• Extremely high context requests per second
Interpreting CPU Measurements

The key to understanding the CPU measurements is to know that CPU is consumed on behalf of
the application. Therefore, if an Oracle instance and processes are consuming all the CPU
resources, check the database application and tune the SQL. Some key points to consider when
interpreting CPU measurements are:
• High idle time with poor response time indicates that the processes are getting blocked.
This means I/O, network, and swapping should be checked.
• If the %user to %system ratio on the Oracle server processes is much greater than the
60/40 ratio expected, then it indicates that the application code must be tuned. If the ratio is
much lower, meaning %system is larger, look for I/O or virtual memory problems.
• On a properly sized system, the run queue size should seldom be more than the number of
CPUs. If the run queue size is greater than two times the number of CPUs available, then
check sar -wW or vmstat for swapping and switching activity. A large run queue size
indicates a CPU bottleneck. This could indicate an undersized system or possibly
insufficient memory.

Interpreting CPU measurements (continued)
• Each process takes virtual memory. When more process memory is required than is
available in real memory, paging takes place. As more processes are added, more memory
is required, and more CPU overhead is required to process the paging and context
switching requests. This can continue until the CPU spends most of its time paging and
switching. This situation is called thrashing.

Reducing CPU Bottlenecks
If you determine that CPU is the limiting factor in your

system:
• Increase CPU resources
• Decrease CPU demand
• Schedule CPU demand more efficiently
Reducing CPU Bottlenecks

CPU is usually a finite resource. Sometimes it is possible to increase CPU resources (upgrade the
processor or add additional processors), but it is usually difficult or expensive unless you are
working in a grid system. Therefore, you usually concentrate on either using existing resources
more efficiently or offloading unnecessary work to other systems.
Using Your CPU More Efficiently
There are some basic things you can do to get more efficient use from your CPU:
• Schedule non-time-critical jobs to run during times when CPU is less loaded. For example,
database backups, index rebuilds, optimizer statistics collection, and batch jobs could run at
night rather than during the day.
• Employ a resource management system (such as Oracle Resource Manager) to ensure that
your most important jobs are serviced first, and that too many batch jobs cannot be started
simultaneously. The use of system process priority manipulation to assign resources to
more important processes is not recommended for Oracle processes as Oracle has its own
built-in process management system.
• Reduce the demand on your CPU by eliminating unnecessary work or offloading work to a
different server.

Monitoring and Tuning Memory
Tools for monitoring and tuning memory include:

• top
• free
• vmstat
• sar
• xosview
• System Monitor
“There is never enough RAM”

Red Hat Enterprise Linux: Introduction
to System Administration Gnome System Monitor
Monitoring and Tuning Memory

In addition to the tools listed above, a great deal of information about system memory use can be
obtained from the /proc virtual file system.
Note: This discussion is based on the Intel 32-bit architecture.
Memory is the resource where you can get the greatest performance improvement for your
hardware expenditure. In the Linux/Intel world, memory is subdivided into four categories:
• L1 (part of the CPU chip) primary cache. Fixed at 16K for data, 16K for instructions.
• L2 (usually part of the motherboard) secondary cache. The size depends on the
motherboard and ranges from 0 to 2M with 512K being the most common.
• L3 RAM, also known as main system memory. This is normally the only memory that can
be increased without a major expenditure.
• Swap is the virtual memory where data is stored on the drive.
There is a direct correlation between process throughput and memory.
• Processes executed in L1 cache operate at 1 iteration per CPU clock cycle.
• Processes executed in L2 cache operate at 1 iteration per 10 CPU clock cycles (except for
XEON and some AMD processors, which access L2 cache at L1 speed).
• Processes executed in L3 RAM operate at 1 iteration per 100 CPU clock cycles.
• Processes paged out to swap need 1000 clock cycles for 1 iteration.

Linux Memory
• There are two types of memory:

– Real
– Virtual
• Linux will only address 4 Gb of memory by default.
– Enabling Physical Address Extensions (PAE) allows
addressing up to 64 Gb of memory.
– Hardware must support PAE. Kernels compiled with
PAE will not run on non-PAE machines.
– PAE consumes 3 to 6 percent of CPU performance.
– Individual process memory is limited to 4 Gb
regardless of PAE.
Linux Memory
Linux supports both real memory (RAM) and virtual memory (swap). A good rule of thumb is to
configure your swap space to be twice the size of real memory. For best performance, keep the
Oracle processes in RAM rather than swap.
Memory Limts
Linux on X86 architecture can only support 4 Gb of RAM by default (232=4,294,967,296). There
are a couple of ways around this limitation that will be discussed in a later chapter.
Note: These limits are based on IA-32 bit architecture. IA64 (Itanium) will address significantly
larger areas of memory

Linux Virtual Memory
Each process is assigned a contiguous address space

in virtual memory that maps process memory
allocations to the real memory.
• It is limited to 4 GB per process by default.
• With PAE, you can use up to 64 GB of physical
memory.
• User address space is a contiguous set of pages.
Linux Virtual Memory

In the standard kernel, the SGA is limited to about 1.7 GB. With any Red Hat, SuSE or
UnitedLinux Enterprise Linux kernel, the virtual address space can be remapped to allow an
SGA of about 2.7 GB. The enterprise kernel physical memory can access up to 64 GB. This is
discussed further in the lesson titled “Tuning Oracle9i and Linux.”
User Address Space
Each process on a Linux system gets a virtual address space. This user address space is a map of
user pages called a page table. Frequently accessed portions of the page table are mapped into
the Translation Look-aside Buffer (TLB) in the CPU. The TLB acts as a very fast cache. The
page tables are held in memory, and can have up to three levels. A page table is like a scratch
pad that maps the user space pages to the physical pages in memory. As the process accesses the
pages of the user virtual space, the TLB redirects the process to physical memory. A context
switch occurs each time the CPU stops working on one process and starts on another. The user
space map for the new process must be loaded into the TLB as part of this context switch.
Note: This discussion is based on IA-32 bit architecture.

Swap
Swapped-in pages
Physical
memory (RAM)
Swapped-out pages
Virtual
memory Swap space (disk)
Swap
Virtual Memory
The total amount of virtual memory is the sum of physical memory and swap space. Each
process can use more memory than what physically exists. The process runs as long as the
process memory requirements fit in the virtual memory space. Linux uses swap space very
sparingly, and runs with little swap space. The swap partition must never be less than the size of
real memory, and it is recommended that the swap be twice the size of real memory. The amount
of swap that your application needs depends on the number of concurrent processes and the
amount of memory that each process requires. Linux uses a 4 KB page size by default (like most
things in Linux, this can be changed if needed). Red Hat Enterprise Linux supports very large
page sizes through its “bigpages” capability.
Page Out
If a page residing in memory is not used, it ages. The older a page, the more likely it is to be
overwritten. The swap looks for the oldest pages in each process every few seconds. If there is a
demand for free pages, swap overwrites the old pages. These pages are moved to the swap
cache in memory if they are dirty, or discarded if they are not dirty. If a page is needed again
before being moved from the cache to disk, then it is reloaded from the cache. Otherwise, it gets
flushed from the cache to the disk after a period of time.

Swap (continued)
Page In
If the process tries to access a page that is not mapped into physical memory, a page fault occurs.
A page fault causes the process to suspend. The page is read from a disk or a swap cache. The
page is loaded into a free page of memory. This page is mapped to the TLB. Then the process is
placed on the run queue. To bring a page in to memory, a free page must exist. The swap
process works to keep a pool of free pages available for these “page in” operations.

Measuring Memory Usage
Measure memory utilization and paging. Significant

memory statistics include:
• Total memory
• Context switches
• Pages in and out
• Inactive pages
• Demand rate
Page out
Page in
Measuring Memory Usage

The instance uses SGA memory to increase performance. Linux uses the buffer cache and page
cache memory to increase performance. A well-tuned memory reduces the I/Os by caching
frequently used pages. Poorly tuned or insufficient memory often shows up first as an I/O
bottleneck with high activity on the swap partition.
Total Memory
Use free, top, or cat /proc/meminfo to find the total memory on your system. Physical
memory is labeled mem in these tools.
Context Switches
Context switches can be seen in vmstat under the system group of columns. They are in the
column labeled cs. A context switch takes place each time the CPU starts working on a different
process. In a context switch, the TLB is reloaded for the new process, and other housekeeping
details are taken care of.

Measuring Memory Usage (continued)
Pages Out
Pages out and pages in are measured in 1 KB blocks, even though the memory page size is 4 KB.
Pages out are seldom zero, and should not be a cause for concern as some “page out” activity is
normal. The swap process frequently moves a few pages out to swap to be sure that free pages
are always available for page in operations. As more pages of real memory are needed, the
number of pages moved to swap increases.
Pages In
The number of pages in is a good measure of RAM shortage. A page in operation occurs when a
memory page is pulled from virtual memory back to RAM. As processes access pages that are
not mapped or have been paged out, a page in is registered. Ideally, the average pages in over
time is near zero. This means that all the processes fit in real memory. As more processes start
and require memory, the pages in increase. This is a key measurement when adjusting the SGA
size for the database. If the pages in increases significantly after an increase in SGA size, it may
indicate that the SGA is too large.
Inactive Pages
Also known as free or freeable memory. Inactive “clean” pages can be immediately replaced by
other memory pages. Inactive “dirty” pages are free but must be written to disk before they can
be used.
Demand Rate
Also known as “Inactive Page Target.” This is one of the most important memory statistic. It is
shown as the inatarpg column with sar -B. The value shown is the average number of
pages per second, within the last minute, the system needed to make “free” to meet memory
demands. This value may also be seen as inact_target in /proc/meminfo. This is the
goal the kernel tries to reach to make sure that there are enough inactive pages available.

Measuring Total Memory
#top
#free
#cat /proc/meminfo
Measuring Total Memory

The top command gives an excellent overview of the system activity. In the header portion, the
Mem line shows total physical memory, memory used, free memory, shared memory, amount of
memory in the buffer cache, and amount of memory in the page cache in kilobytes. Remember
that individual process memory reported with top is meaningless for Oracle processes because
shared memory is reported for each process.
#top
9:12pm up 15:44, 4 users, load average: 1.02, 0.65, 0.33
235 processes: 231 sleeping, 4 running, 0 zombie, 0 stopped
cpu states: 40.2% user, 59.7% system, 0.0% nice, 0.0% idle
Mem: 512284K av, 508348K used, 3936K free, 5200K shrd, 67428K buff
Swap:522072K av, 115088K used, 406984K free 242740K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1017 root 15 0 5944 5544 4360 S 0.7 1.0 2:10 Xvnc
20866 oracle 15 0 86360 67M 54228 S 0.5 13.4 0:10 java
1212 root 16 0 1188 1188 832 R 0.3 0.2 0:00 top
1 root 15 0 508 460 460 S 0.0 0.0 0:04 init
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 keventd

Measuring Total Memory (continued)
The free command also shows total memory and swap usage. The -/+ buffers/cache
line indicates the adjustment to free and used memory by the kernel’s disk buffers and page
cache (how much a process could get if it requested it—the kernel will dump its own page cache
and disk buffers to support running processes):
#free
total used free shared buffers cached
Mem: 512284 506880 5404 5200 68196 239984
-/+ buffers/cache: 198700 313584
Swap: 522072 114884 407188
All the utilities that collect statistics, gather information from the /proc file system. The virtual
meminfo “file” gives an instantaneous snapshot of memory usage.
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 1054806016 1029685248 25120768 0 136949760 617668608
Swap: 534601728 22032384 512569344
MemTotal: 1030084 kB
MemFree: 24532 kB
MemShared: 0 kB
Buffers: 133740 kB
Cached: 585920 kB
SwapCached: 17272 kB
Active: 674312 kB
ActiveAnon: 214892 kB
ActiveCache: 459420 kB
Inact_dirty: 0 kB
Inact_laundry: 159476 kB
Inact_clean: 14016 kB
Inact_target: 169560 kB
HighTotal: 130524 kB
HighFree: 2032 kB
LowTotal: 899560 kB
LowFree: 22500 kB
SwapTotal: 522072 kB
SwapFree: 500556 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB
A few key statistics from the meminfo output are:

• Mem: The current state of physical RAM in the system, including a full breakdown of
total, used, free, shared, buffered, and cached memory utilization in bytes.
• MemFree: The amount of physical RAM left unused by the system. It is usually very low.
• Active: The total amount of buffer or page cache memory that is in active use.
• Inact_dirty: Buffers that might need writing to disk or swap. It should be relatively low.
• Inact_target: Demand Rate. This is the goal the kernel tries to reach to make sure that there
are enough inactive pages available.
• SwapFree: The total amount of swap free. It should not stay below 20% of SwapTotal.

Measuring Memory with vmstat
# vmstat <frequency> <count>
# vmstat 2 5
vmstat
The vmstat command has two parameters: frequency and count. Frequency is the number of
seconds between samples, and count is number of samples to take.
In this example, vmstat samples every two seconds for a total of five samples. The first output
line of vmstat shows all the activity since the last reboot. The following example shows a
loaded system, but with little swapping. Pages in are represented by “si” and pages out are
shown with “so.”
Note: The first line of output includes all activity since the last vmstat report.
# vmstat 2 5
1 0 0 296004 3092 73268 61324 0 3 11 51 135 588 10 4 86
1 0 0 296004 3076 73268 61324 0 0 0 2 109 372 66 34 0
1 0 0 296004 3076 73268 61324 0 0 0 32 109 199 59 41 0
1 0 0 296004 3072 73268 61316 0 0 0 24 110 331 40 60 0
1 0 0 296004 3076 73268 61300 0 0 2 10 107 373 51 49 0

Measuring Memory with sar
#sar -B <frequency> <count>
#sar -R <frequency> <count>
#sar -B 2 3
#sar -R 2 3
sar
The System Activity Reporter (sar) has many options.
The -B option shows pages in and pages out per second (pgpgin/s, pgpgout/s); the
number of active pages (activepg); and the inactive dirty, inactive clean, and inactive target
pages (inadtypg, inaclnpg, inatarpg). The inactive target is the demand rate.
# sar -B 2 3
Linux 2.4.9-e.3 (EDD1R28P1) 02/26/2003
08:19:03 PM pgpgin/s pgpgout/s activepg inadtypg inaclnpg inatarpg

08:19:05 PM 1994.00 126.00 85630 18848 4802 32733
08:19:07 PM 2934.00 11680.00 85968 23722 3605 32733
08:19:09 PM 940.00 420.00 88629 4175 20266 32733
Average: 1898.80 5554.40 87859 12015 12492 32733

sar (continued)
The -R option shows the number of pages freed per second, the number of additional shared
memory pages, buffer pages, and cache pages used, frmpg/s, shmpg/s, bufpg/s, and
campg/s. Negative values indicate fewer pages used.
# sar -R 2 3
Linux 2.4.9-e.3 (EDD1R28P1) 02/26/2003
08:18:47 PM frmpg/s shmpg/s bufpg/s campg/s

08:18:49 PM 0.50 0.00 0.00 -109.50
08:18:51 PM 3.50 0.00 -1.50 140.50
08:18:53 PM -4.00 0.00 -4.00 -93.00
Average: 0.10 0.00 -1.10 -61.30

Interpreting Memory Measurements
When interpreting memory measurements, observe

cases where the system has:
• High swap memory usage
• Kernel file cache continues to be allocated despite
low system memory
• High page ins/page outs
• Low inactive pages
Interpreting Memory Measurements

Remember that a single measurement is meaningless. The key to using memory statistics is
measurement over a period of time. You can use the average demand rate (when the system
performance is acceptable) as a baseline to compare with when the system performs poorly.
This, along with the pages in over the same time periods, may indicate memory problems.
High Swap Memory Usage
Indicates memory demand is too high for the available RAM. If this is consistently high, then
consider adding RAM.
Kernel File Cache Continues to Be Allocated Despite Low System Memory
This may be an indication of kernel problems (earlier Linux kernels did not release file cache
quickly enough). If you are using Red Hat Enterprise Linux 2.1AS, then ensure that your kernel
is patched to at least 2.4.9-e.25. If you are using United Linux, then ensure that you have patched
your kernel to at least 2.4.21-17 (service pack 3).

Interpreting Memory Measurements (continued)
High page ins
This can indicate that the SGA is too large for available memory, or that the SGA needs to be
“locked” into RAM. If you are using a supported enterprise distribution, then use the bigpages
feature (see next page). If using a nonenterprise kernel, then set lock_sga=true to lock the
SGA into RAM. Note that this requires the Oracle user to have the CAP_IPC_LOCK privilege
granted through and advanced permissions management system such as the Linux Intrusion
Detection System (LIDS). Oracle recommends SuSE SLES, UnitedLinux, or Red Hat Enterprise
Linux.
Low Inactive Pages
This indicates you do not have enough memory. The best solution is to increase RAM.

Linux Large Memory Pages
Performance can be improved with the use of larger

memory pages.
• Default page size is 4 KB
• Large Pages (bigpages)
– Reduce the number of pages required to hold SGA
– Are not paged out to virtual memory
– Reduce the TLB miss rate
– Reduce the page table size
Linux Large Memory Pages

Linux normally handles memory in page units of 4 KB. With the enterprise Linux distributions,
it is possible to configure larger memory pages, and for the Oracle instance you should do so.
Large memory pages are also known as bigpages (Red Hat 2.1) or hugepages (Red Hat 3.0).
Large memory pages enhance performance by decreasing the time required to find a page in
memory. A kernel running with 4 GB of RAM using 4 KB memory pages requires a page table
of 4 GB/4 KB (one million entries). A page table of this size affects performance every time it is
searched for a memory page, so reducing the size of the page table can improve performance
fairly significantly. A smaller page table allows a faster lookup of the page mapping, and a larger
percentage of the page table can reside in TLB.
Enabling large memory pages gives a performance boost to large memory configurations by
reducing the size of the page table. The bigpages parameter allows the memory to be allocated in
units of 2 MB (enterprise kernel) or 4 MB (SMP kernel), thus reducing the page table for 4 GB
of RAM to one thousand entries. In addition to reducing the size of the page table, large memory
pages are not swapped out of memory. This, in effect, locks the SGA in memory.
If your distribution supports large memory pages, then you should almost always use them.

Linux Large Memory Pages (continued)
Bigpages improve memory access for the SGA, but do so at the cost of making less memory
available for database user connections.
Enabling bigpages is a two-step process:
1. Reserve memory for bigpages by editing /etc/lilo.conf (or grub.conf depending
on which boot loader you are using) and add a line:
bigpages=<size>MB
2. Set /proc/sys/kernel/shm-use-bigpages to a value of 2:
echo 2 > /proc/sys/kernel/shm-use-bigpages
When determining the amount of memory that will be reserved for use by bigpages you should:
• Determine total available memory in megabytes by checking /proc/meminfo
(remember to divide by 1,024). Subtract 1 GB (only high memory is used for bigpages).
• Deduct 20% of total memory for use by the kernel.
• Deduct memory that will be reserved by user connections (allow ~10 MB per connection
depending on various database parameter settings) and other programs.
• Round off the remaining memory down to the next lower multiple of 4 MB (the setting for
bigpages must be a multiple of 4 MB).
bigpages = ((total memory – 1 GB) – (memory reserved for user connections)*0.8)
The result is the amount of memory available for bigpages.
1. Add 'bigpages=<size>MB' to the boot loader file in either /etc/lilo.conf or
/boot/grub/grub.conf, depending on your system configuration. For the lilo boot
loader, add append = "bigpages=4100MB" to /etc/lilo.conf as follows:
image=/boot/vmlinuz-2.4.9-e.3smp
label=linux
initrd=/boot/initrd-2.4.9-e.3smp.img
read-only
root=/dev/hda6
append=“bigpages=4100MB”
2. Run # /sbin/lilo or /sbin/grub (depending on which loader you use).
3. Restart the system.
4. Run the following command:
# echo 2 > /proc/sys/kernel/shm-use-bigpages
5. Make the change occur on boot up. Add the line
kernel.shm-use-bigpages = 2 to /etc/sysctl.conf.

Reducing Memory Bottlenecks
If you determine that memory is the limiting factor in

your system, then:
• Increase memory resources
• Decrease memory demand
Reducing Memory Bottlenecks

All the solutions are in the form of Use less memory or Get more memory.
• Identify nonessential memory consumption and eliminate it. Look for running non-Oracle
processes and eliminate those you can do without.
• Use Linux bigpages.
• Reducing the SGA is not usually acceptable, but check the installation and configuration.
Are you using the Java Virtual Machine (JVM)? If not, reduce JAVA_POOL_SIZE to
zero. Can your buffer cache be reduced without affecting performance? Although the SGA
would not complain about excessive pool sizes (within reason), your server certainly will!
• Reduce the number of user processes. Without restricting the number of users, the number
of user processes can be reduced by using shared servers if the workload supports them.
• Reduce the amount of process memory with PGA_AGGREGATE_TARGET.
• Add memory to your server.

Monitoring and Tuning I/O
You should monitor the I/O across all devices to

balance which device gives the best overall
performance. Tools for monitoring I/O include:
• /proc filesystem
• sar
• Iostat
• vmstat
• xosview
xosview
Monitoring and Tuning I/O

Which tools you use to tune disk I/O really depend on your storage system. Tools such as sar
and iostat are common, but tend to show I/O measurements from the operating system’s point
of view rather than from a hardware standpoint. If your hardware includes large storage arrays
from vendors, such as EMC, Network Appliance, HP/Compaq, and Veritas, then you will
normally use monitoring tools provided by your vendor. If you are using the Just a Bunch Of
Disks (JBOD) technology, then the information provided by operating system tools, such as sar
and iostat, should be sufficient.

Is I/O a Bottleneck?
Is I/O a bottleneck?
• Take and retain baseline I/O measurements.
• Individual measurements (snapshots) are usually
of little value. I/O monitoring should be done over
time.
• I/O issues with the swap partition should be
treated as memory problems first.
Is I/O a Problem?
With databases, disk I/O is a primary concern. Disk I/O is the single largest performance cost.
Most I/O measurements are meaningless without a baseline, so ensure that you capture and retain
that. When you notice performance degradation, look for high queue and wait statistics to
determine if I/O is the culprit.
Remember that virtual memory is maintained on disk, and will also show up as I/O. If you spot
high I/O statistics on the swap partition, you should troubleshoot it as a memory issue first, then
address it as an I/O issue.

I/O Measurements
I/O measurements concentrate on volume and speed:

• Read I/O operations
• Write I/O operations
• Request queue size
• Transfer rate
• Wait time
• Service Time
I/O Measurements
I/O measurements usually concentrate on either the volume of data being handled or the speed
with which that data is handled.
Volume
Obviously, the more work that is being done the longer it will take to do that work. When you
measure volume, look at read and write volume separately. Also, if your tools allow you to view
it, monitor sequential operations as compared with random access. It is usually quicker to write
1MB of sequential data than to write 20K in multiple locations on the disk because of the time
required for disk head positioning.
Speed
When monitoring speed, look for transfer rate (bytes per second), wait time (how much time was
spent waiting for I/O to respond), and service time (how long does each I/O operation take from
start to finish). Of these three, the most important from a database performance standpoint is wait
time.

Measuring I/O with iostat
I/O measurements concentrate on volume and speed:

• Read I/O operations
• I/O statistics by device
iostat -d <interval> <count>
#iostat –d 2 2
Linux 2.4.9-e.27 (HOSTNAME)
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
dev3-0 4.91 19.48 116.28 13536148 80797647
• I/O activity by partition

iostat –d -x <interval> <count>
Measuring I/O with iostat

The iostat command is used for monitoring system I/O device loading by observing the time
the devices are active in relation to their average transfer rates. The first report provides statistics
concerning the time since the system was booted. Subsequent reports cover the time since the
previous report.
To view I/O statistics by device, use (the –d option suppresses CPU statistics):
iostat -d <interval> <count>
Transfer rate is shown by the tps, Blk_read/s and Blk_wrtn/s columns. Volume
measurements for read and write operations can be seen in the blk_wrtn and blk_read
columns.
To see I/O activity by partition, use (the –x option displays extended statistics):
iostat –d -x <interval> <count>
The iostat -x command presents the I/O statistics by partition with the same statistics that
can be seen from V$FILESTAT on database files.
Speed measurements are shown in three ways: merged requests as rrqm/s and wrqm/s (how
many operations were performed), requests as r/s and w/s (how many requests were made
of the I/O system), and sectors handled per second as rsec/s and wsec/s.

Measuring I/O with iostat (continued)
Volume statistics are shown including average requests size avgrq-sz. await gives the
average wait time for requests. avgqu-sz is a key metric that shows the length of the request
queue (this is the I/O equivalent of CPU load). Service time, another key metric, appears as
svctm. %util is the percentage of time the CPU spends handling I/O requests.
The output of the following command has been reformatted to fit the page.
# iostat –d -x 2 2
Linux 2.4.9-e.3 (EDCDR28P1) 04/01/2003
0.11 0.00 0.11 99.78
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
hda 4405.97 1099.50 166.67 49.25 36569.15 9205.97
hda1 0.00 0.00 0.00 0.00 0.00 0.00
hda2 0.00 0.00 0.00 0.00 0.00 0.00
hda3 0.00 0.00 0.00 0.00 0.00 0.00
hda4 0.00 0.00 0.00 0.00 0.00 0.00
hda5 4405.97 1099.50 166.67 49.25 36569.15 9205.97
<would normally appear on same line as above>
Device: avgrq-sz avgqu-sz await svctm %util
hda 151.44 1.11 1480.36 31.04 0.23
hda1 1.01 0.00 6.56 6.56 0.00
hda2 2.00 0.00 41.67 41.67 0.00
hda3 2.00 0.00 33.33 33.33 0.00
hda4 2.00 0.00 100.00 100.00 0.00
hda5 152.72 1.10 1488.20 31.25 0.23
As you can see in the above example, hda5 is the only partition that is really affecting system
performance. You would want to monitor it over several reporting samples to see if await and
avgqu-sz continue to be high.

Measuring I/O with sar
sar with the –b option reports I/O statistics:
# sar -b 5 5
02:48:15 PM tps rtps wtps bread/s bwrtn/s
02:48:20 PM 2.40 0.00 2.40 0.00 147.20
02:48:25 PM 7.60 0.00 7.60 0.00 88.00
02:48:30 PM 2.60 0.00 2.60 0.00 94.40
02:48:35 PM 6.20 0.00 6.20 0.00 180.80
02:48:40 PM 1.80 0.00 1.80 0.00 41.60
Average: 4.12 0.00 4.12 0.00 110.40
Measuring I/O with sar

sar –b shows transfer rate as tps. The transfers are broken down into read/write with
rtps/wtps showing the number of requests per second and bread/s & bwrtn/s showing
the number of data blocks per second.
sar –d shows transfer rates and blocks per second per device.
# sar -d 2 2
02:57:44 PM DEV tps blks/s
02:57:46 PM dev3-0 6.50 96.00
02:57:46 PM DEV tps blks/s

02:57:48 PM dev3-0 1.50 112.00
Average: DEV tps blks/s

Average: dev3-0 4.00 104.00
Remember that sar can show history information for up to one month in the past, so this tool
allows you to easily compare current rates with historical figures.

Measuring I/O with vmstat
vmstat gives information on the volume of disk I/O:

• bo: Blocks sent to the storage array (write)
• bi: Blocks received from the storage array (read)
# vmstat 3 3
procs io system cpu
r b w bi bo in cs us sy id
1 0 0 10 58 3 31 12 5 24
2 0 0 0 11 107 451 1 0 99
3 0 0 0 56 110 451 1 0 99
Measuring I/O with vmstat

vmstat provides information on overall I/O throughput.
# vmstat 3 3
1 0 0 424800 12540 84636 376516 0 0 10 58 3 31 12 5 24
2 0 0 424800 12536 84636 376516 0 0 0 11 107 451 1 0 99
3 0 0 424800 12536 84636 376516 0 0 0 56 110 451 1 0 99

Interpreting I/O Measurements
Look for changes from baseline measurements,

especially in queue size or wait times:
• High volume or queue size across multiple
devices
• High volume or queue size for one device
• High wait times without corresponding high queue
sizes
Interpreting I/O Measurements

Like memory measurements, the key to using I/O statistics is measurement over a period of time.
Take periodic measurements of I/O volume and speed so that when performance degrades, you
can identify probable problem devices.
High Request Volume or Queue Size Overall
Indicates that the I/O devices are unable to handle the rate of I/O requests. This indicates there
are either not enough channels to I/O devices or that existing channels are too slow.
High Request Rolume or Queue Size for One Device
It indicates that I/O may not be properly balanced across available devices.
High Wait Times
If wait times are high and queue size is not, verify whether asynchronous I/O is being used if the
storage arrays supports it. If not, ensure that I/O slaves are in use. This may also be indicative of
hardware problems.

Reducing I/O Bottlenecks
To reduce I/O as a bottleneck:

• Reduce the volume of I/O through application and
memory tuning
• Increase I/O throughput by parallelizing I/O
– Multiple disk controllers
– Multiple disks
– Multiple data bus adapters
• Select your hardware carefully, and build your
storage arrays with performance in mind
• Separate redo, data, and index files
Reducing I/O Bottlenecks

A good rule of thumb is to tune the application and memory to reduce or eliminate I/O as much
as possible. When this is accomplished, balance the remaining I/O across all the available drives
and controllers. In general, the more disks and controllers you are working with, the greater your
I/O performance can be.
Carefully consider how your storage arrays are built. If you mix drives with different
performance characteristics, keep the fastest drives on a different bus than the slowest drives.
The controller bus speed is limited to the speed of the slowest device. More data channels means
more data bandwidth. Consider adding additional Host Bus Adapters (HBAs).
If you are using Redundant Arrays of Inexpensive Disks (RAID), choose hardware-based RAID
over software-managed RAID. Software-managed RAID consumes CPU and memory resources
and seldom performs as well as hardware-based RAID. Additionally, RAID 5 generally performs
well for read operations, but poorly for write due to the parity calculations required. Try to
minimize the number of stripe columns in RAID 5. More columns means more calculations to
generate the parity bit.
Remember to place files with different requirements on different disks. For example, your redo
log members should be placed on separate disks (away from data and control files) and should be
on your fastest disks, bus, and controllers.

Network Traffic
Network traffic is another load on the system. Check

the following sources of network traffic:
• Oracle Net
• Network file system
• Samba
• HTTP server
Network Traffic
Remember to view the network as one continuous pipe extending from the server all the way to
the client. Any bottlenecks along the way will affect the passage of network traffic over the
entire pipe.
Network traffic takes resources just as other I/O activities. The netstat -a | grep
ESTABLISHED command shows all active connections and the ports that are being used.
$netstat -a | grep ESTABLISHED
. . .
tcp 0 0 EDCDR38P1:44583 EDCDR38P1:1521 ESTABLISHED
tcp 0 0 EDCDR38P1:1521 EDCDR38P1:44583 ESTABLISHED
tcp 0 2 EDCDR38P1.us.ora:telnet 141.144.98.224:1865 ESTABLISHED
. . .
This command shows the connections, the ports, and the protocols. Consider the sources of your
traffic when the system is performing poorly.
To see the TCP statistics, use netstat -sp tcp and compare the values between runs. This
command produces a very large output. The sar command (in the following page) produces a
much more compact result but not nearly as detailed.

Network Traffic (continued)
The sar command has a -n option that simplifies the netstat style collection. This example
command shows statistics by device (dev keyword), two times at one second intervals. For each
interface, it shows the received and transmitted packets per second (rxpck/s, txpck/s), the
received and transmitted bytes per second (rxbyt/s, txbyt/s), and the received and
transmitted compressed packets per second.
# sar -n DEV 1 2
Linux 2.4.9-e.3 (EDCDR38P1) 03/17/2003
01:56:32 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmps

01:56:33 PM lo 7.00 7.00 365.00 365.00 0.00 0.0
01:56:33 PM eth0 4.00 1.00 334.00 95.00 0.00 0.0
01:56:33 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmps

01:56:34 PM lo 0.00 0.00 0.00 0.00 0.00 0.0
01:56:34 PM eth0 6.00 1.00 556.00 335.00 0.00 0.0
Average: IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmps

Average: lo 3.50 3.50 182.50 182.50 0.00 0.0
Average: eth0 5.00 1.00 445.00 215.00 0.00 0.0
There are many other tools that can be used. One is snort, a popular Intrusion Detection
System that works well as a sniffer. Snort has many options. Consult the documentation for
details. Snort is available at http://www.snort.com.

Interpreting Network Statistics
When interpreting network statistics, observe cases

where:
• Network traffic is higher than normal
• Network port usage is higher than normal
• Network throughput is slower than normal
Interpreting Network Statistics

The number of packets and bytes has very little meaning without a baseline measurement of your
system. Take a measurement when your system is under a normal load and is performing well.
High traffic is often a system architecture issue. Consider the following:
• Does the HTTP server really need to run on the same box as the database?
• Does the database machine need to be a Samba file server? Print server? Dynamic host
configuration protocol (DHCP) server?
• Can domain name services (DNS) be moved to another machine?
• Are there network file system (NFS) files being mounted or exported?
Functions and services should be isolated. That is, each machine should provide a specific
service. Consider the impact of providing multiple services from a single machine. By doing this
your should see that:
• The tuning becomes easier because the differing requirements do not have to be balanced
• The security and patching issues are also isolated to the individual machines
• Moving machines to different subnets is easier
• Isolating machines for security reasons is easier
One of your key reasons for selecting Linux was probably the inexpensive hardware. Oracle
recommends that the database server machine be used exclusively for the Oracle database.

Summary

• Measure and evaluate CPU usage
• Measure and evaluate memory usage
• Measure and evaluate disk I/O loads
• Measure and evaluate network usage

Practice Overview:
Using Linux Measurement Tools
This practice covers using:

• sar to measure CPU loads
• vmstat to measure memory usage
• iostat to measure disk I/O loads
Practice 7 Overview: Using Linux Measurement Tools


Oracle9i Measurement Tools

Objectives

the following:
• Use Statspack with operating system (OS) tools
• Use Oracle Enterprise Manager tools with OS tools
• Configure and measure System Global Area (SGA)
and Program Global Area (PGA) usage

Installing and Configuring Statspack
• Install Statspack with the spcreate.sql script.

• Collect statistics with the statspack.snap
procedure.
• Produce a report with the spreport.sql script.
• Collect timing information, set
STATISTICS_LEVEL = TYPICAL.
Installing and Configuring Statspack

Statspack can collect statistics over a period of time and store the statistics in the database. This
collection offers you the opportunity to compare statistics over different periods of time. Hard
copy reports can be generated from a set of two snapshots. In addition to the instance statistics,
Statspack also generates information on SQL statements that are present in the Library Cache
when the snapshots were taken.
Installing the Statspack Package
Installing the Statspack utility creates the perfstat user, who owns all PL/SQL code and
database objects created (including the Statspack tables, the constraints, and the Statspack
package). During the installation, you are prompted for the perfstat user’s default and
temporary tablespaces.
When you install the Statspack package, you need around 80 MB of free space in the
perfstat user’s default tablespace. The tables storing snapshot information may cause this to
grow.

Installing and Configuring Statspack (continued)
Collecting Statistics
To take a snapshot of performance data, log onto SQL*Plus as the perfstat user, and then
execute the statspack.snap procedure. This stores the current performance statistics in the
Statspack tables, which can be used as a baseline snapshot for comparison with another snapshot
taken at a later time.
Producing a Report
To examine the change in statistics between two time periods, execute the spreport.sql file
while you are being connected to the perfstat user. You are shown a list of collection
periods, from which you can select a start and an end period. The difference between the
statistics at each end point is then calculated and put into a file that you name. It is not correct to
specify begin and end snapshots where the begin snapshot and end snapshot were taken from
different instance startups. That is, the instance must not have been shut down between the times
that the begin and end snapshots were taken.
Timing Information
To see timing information in the Statspack collections, set STATISTICS_LEVEL =
TYPICAL in the initialization parameter file. This parameter is dynamic and can be set by using
the ALTER SYSTEM command. In database versions before Oracle9i Release 2, set the
parameter TIMED_STATISTICS = TRUE.
For more details on Statspack, refer to Oracle9i Database Performance Tuning Guide and
Reference Release 2 (9.2).

Automatically Collecting Statistics
Automatic collection of statistics by using the

spauto.sql script:
variable jobno number;
variable instno number;
begin
select instance_number into :instno
from v$instance;
dbms_job.submit(:jobno, 'statspack.snap;',
trunc(sysdate+1/24,'HH'),
'trunc(SYSDATE+1/24,''HH'')', TRUE, :instno);
commit;
end;
/
Automatically Collecting Statistics

To compare the performance of a day with the next day’s performance, you must have multiple
snapshots taken over a period of time. (You can also compare the performances of a week or an
year with that of the next week’s or next year’s.) The best method to gather snapshots is by
automating the collection at regular time intervals.
The spauto.sql script makes use of the dbms_job package to provide an automated
method for collecting statistics. The supplied script schedules a snapshot every hour, on the hour.
This can be changed to suit the requirements of the system. For example, if you would rather
collect statistics every half hour, change the 1/24 to 1/48 in the submit statement.
For details about the dbms_job package, refer to the Oracle9i Supplied PL/SQL Packages and
Types Reference.

First Page of the Statspack Report
Information found on the first page:

• Database and instance name
• Time at which the snapshots were taken
• Current sizes of the caches
• Load profile
• Efficiency percentages of the instance
• Top five wait events
First Page of the Statspack Report

The first page summarizes the report. The items found on this page include most of the
information that the DBA requires for enhancing performance. Any of these areas could indicate
performance problems. You can then drill down in the report to the detail of the area in question.
• Cache Sizes
The current size of the buffer cache, the shared pool, and the log buffer are shown here in
kilobytes. The value of the primary block size is also included here.
• Load Profile
You see two values for each statistic: one is per second and the other is per transaction.
What is shown includes the redo size and the physical reads and physical writes that are
performed during the snapshot period.
• Instance Efficiency Percentages
The items listed here are the ones that are most often used for tuning a database. These
statistics are used to indicate that workloads have changed on the database.
• Top Five Wait Events
The full list of wait events appears later in the report and can be dealt with as needed. The
top contention items are listed under this heading.

Statspack Output
Information found in the remainder of the document:

• Complete list of wait events
• Information on SQL statements currently in
the pool
• Instance activity statistics
• Tablespace and file input/output (I/O)
• Buffer pool statistics
Statspack Output
Wait events are also ordered by wait time so as to put the most problematic events at the top.
Statspack also attempts to put the wait events that are not problematic (for example, pmon
timer) at the end of the list, regardless the time value.
SQL Statements
Statspack gives information about the SQL statements that are stored in the shared SQL area.
You use this section to determine which statements provide the best return on the time invested
in tuning SQL statements.
Several different ordered lists of SQL statements are given. SQL statements are sorted in order
of number of executions, number of parse calls, number of buffer gets, and number of reads. By
ordering the SQL statements by these different columns, it is easier to determine which
statements are causing the heavy workload. These statements should then be tuned first to get the
highest return on the time spent.

Statspack Output
Information found in the remainder of the document:

• Undo segment statistics
• Latch activity
• Dictionary cache statistics
• Library cache statistics
• SGA statistics
• Startup values for initialization parameters
Statspack Output (continued)

Undo Segment Statistics
For your undo segments, you are provided with details of how much undo has been used during
the collection period. Among these are undo blocks, the number of transactions, and the number
of snapshots to old (ora-1555) messages. Statspack also reports rollback segment statistics for
backward compatibility.
SGA Statistics
This is made up of two lists: a memory summary and a breakdown of each area.
Startup Values for Initialization Parameters
Because many initialization parameters are dynamic (can be changed without stopping and
starting the database), there is no guarantee that the current value is used when the system is
restarted. Parameters may also change during the time period covered by the snapshots. For this
reason, Statspack reports the parameter values at the begin and end snapshots.

Correlating Statspack Output with OS
Measurements
The OS and database statistics must be collected at

the same time periods to have a meaningful
comparison.
• Use cron to schedule both.
• Run sar and Statspack continuously.
• Use the Oracle Enterprise Manager Performance
Manager tool to view and record OS statistics.
Correlating Statspack Output with OS Measurements

When you determine the source of a performance problem, you must have statistics that are
collected at the same time period for both the OS and the database. You must plan before you
collect these statistics. Two ways of accomplishing this are:
• Start both from the same scheduler (for example, cron), or use the Oracle Enterprise
Manager Job system. The Statspack snapshot times correspond to the sar report times.
• Run both continuously, use sar to record statistics to a file, and then use the sar
reporting capability to print reports over the time period of interest. Configure Statspack to
make automatic collections and use the snapshot times to set the sar report interval.
Both of the above ways give you the ability to correlate the OS statistics with the database
statistics over arbitrary time frames.
The Performance Manager tool (a part of the Diagnostics Pack) of Oracle9i Release 2 Enterprise
Manager can capture, record, and present most of the OS statistics that can be gathered with any
of the OS tools. For details about Performance Manager, refer to Oracle Enterprise Manager
Getting Started with the Oracle Diagnostics Pack Release 9.0.1.

Basic Tuning Steps
The statistics show a problem. What should be done?

1. Define the problem.
2. Gather the statistics.
3. Model the problem.
4. Make a change.
5. Measure the result.
Basic Tuning Steps

The statistics have been gathered. There are several basic problems that are common to tuning a
database server. The procedure for all of them should be similar.
1. Define the problem and goal in objective and measurable terms. For example “Page ins are
too high, reduce paging by 10%.”
2. Gather statistics for both the database and the OS. Capture load information if possible.
top or ps -ef can help find OS processes that may be generating part of the load.
3. Model the problem conceptually. Create a change and testing plan. If the server cannot be
stopped for testing, then use a duplicate machine and load for testing.
4. Make the change. By making changes in small increments, the effects can be clearly seen.
5. Measure the result.
Change only one parameter at a time, so that you can know the effect of each.

Tuning CPU
The statistics can show the following problems:

• Large run queue size:
1. Move processes to a different time.
2. Move OS services to other machines.
3. Consider adding more CPUs.
• High %system:
1. Check memory statistics.
2. Tune application SQL.
• High %idle:
1. Check I/O statistics including network.
2. Check memory statistics.
Tuning CPU
The CPU only works on behalf of an application. Some process is asking for high usage. The
problem is to discover which processes are asking for high usage. The CPU shows a high load
average or a larger run queue, whereas top gives a detailed view of which processes are using
the machine resources. In most cases, the first step in tuning the CPU should be to tune the SQL.
Each database read involves several CPU cycles. By tuning the SQL, both CPU and I/O
problems can be reduced.
With a large run queue, the goal is to reduce the number of processes or make the processes
more efficient to use less CPU. Some jobs can be shifted to a time when there is little load, and
the batch scheduler can be used to hold a job until the load average drops below .8. Some
processes may be moved to other servers.
If the processes that are running are using a high %system, then they are spending time in the
kernel or system calls. This indicates memory problems or inefficient code for other system
functions such as I/O. Each application has a characteristic percentage. The characteristic for
Oracle Server processes are 40/60, %user/%system.
A high %idle prompts you to look somewhere else, because this is not a CPU problem.
Processes often get blocked on I/O or paging, possibly on network I/O. When processes get
blocked, they are not on the run queue, and the CPU is idle.

Tuning Memory
The statistics show a problem: High pages in and

demand rate
• Tune the application SQL for sorts.
• Tune PGA usage PGA_AGGREGATE_TARGET.
• Reduce the number of processes with shared
servers.
• Reduce the size of SGA.
• Move OS service to other machines.
• Move processes to a different time.
Tuning Memory
The demand rate is higher than your baseline measurements, and pages in is showing a
consistently higher rate. These would indicate that the processes are allocating more memory
than they were when the baseline was created. And that extra allocation does not fit in real
memory.
Again, tuning the SQL must be the first step. Reducing sorts in the SQL reduces the memory
usage. Tuning the PGA areas is discussed further by using PGA_AGREGATE_TARGET or shared
servers later in this lesson. Processes can be moved off the database server, or can be scheduled
when there are fewer processes running, to reduce memory demands.
Note: For more details on SQL Tuning, attend the Oracle9i Database: SQL Tuning Workshop
course.

Tuning I/O
The statistics can show the following problems:

• High activity on a few devices – hotspots:
1. Check memory utilization.
2. Move very active files to striped partitions.
3. Check I/O for OS processes.
• Consistently high queue lengths:
1. Tune the application SQL to reduce I/O.
2. Tune SGA to cache more buffers.
• High database I/O waits:
1. Tune the application SQL to reduce I/O.
2. Use asynchronous I/O.
Tuning I/O
I/O problems tend to fall into a few areas: disk contention, large I/O queues, and large I/O waits.
A single problem may show symptoms in one or all of these areas.
The goal is to balance the I/O across all the available disks and controllers. If there is high
activity, blocks per second, or transfers per second on a particular device, there are often long
waits and large queues as well. Find the file or the combination of files that are being accessed,
and resolve the problem. Moving an active file to a striped partition increases the I/O bandwidth
that is available for that file. Memory issues can at first appear to be I/O issues. The swap device
shows high activity because of increased paging.
Tuning the SQL to reduce I/O, benefits the I/O subsystem with reduced requests, and reduces the
waits for I/O. It also improves the performance of the tuned statements. Tuning the SGA to hold
more of the frequently used database blocks also reduces I/O. Server processes check the SGA
for requested blocks before making an I/O request.
Multiple enterprise distributions now support asynchronous I/O. How to configure asynchronous
I/O to reduce I/O waits is discussed in the lesson titled “Tuning Oracle9i and Linux.”

Starting Top SQL
• Start it from the Enterprise Manager console by
using:
– The Tools menu option
– Diagnostics toolbar drawer
• Select the Top SQL chart from Performance
Manager.
Starting Top SQL

As the DBA, it is not your responsibility to tune application SQL statements. Your concern is
overall database performance. Therefore, identifying which SQL statements are using the most
system resources helps you in your overall tuning effort. When you identify the statements that
need tuning, and have statistics to support the need, you can work with your application
developers to tune the statement for optimal performance.
Top SQL takes all the SQL statements and statistics from V$SQLAREA. The V$SQLAREA view
lists statistics on shared SQL areas and contains one row per SQL string. It provides you with
statistics on SQL statements that are in memory, parsed, and ready for execution, or that might
have been executed already.
Top SQL can be accessed from the Enterprise Manager console by using the tools menu option,
the diagnostics toolbar drawer, or by right-clicking a database and select Top SQL from related
tools.
Top SQL (like all the Performance Manager tools on Linux) does not allow direct connections
but must connect using the Intelligent Agent (IA).

Using Top SQL
• Identity SQL statements that need to be tuned.

• Sort on any column.
• Drill down to see the Explain Plan.
Using Top SQL

You can use Top SQL to define which SQL statements you want to tune. The Buffer Gets Per
Execution is a key column that helps you decide what to tune. Because each buffer has to come
from a disk at some point, this can be a guide on what the potential I/O would be for a given
statement. However, you must consider the Executions column as well.
For example, even if you have a SQL statement with a very high number of buffer gets, but
executed very infrequently, you may get only a marginal return on your tuning of that statement.
By selecting a statement on the chart, you can select the Explain Plan from the Drilldown
window to see the details of the execution of the selected statement.
For more information about using Top SQL, refer to Oracle Enterprise Manager Database
Tuning with the Oracle Tuning Pack Release 9.0.1.

OS Statistics with Enterprise Manager
$ oemapp pm
OS Statistics with Enterprise Manager

By using Performance Manager in Enterprise Manager, you can monitor OS statistics as well as
database statistics. You can display these statistics in a number of formats, including tables, strip
charts, horizontal and vertical bar charts, and pie charts. You can drill down for more detail on
some predefined charts. For more details about Performance Manager, refer to Oracle Enterprise
Manager Getting Started with the Oracle Diagnostics Pack.
To start Performance Manager from the console, select Tools > Diagnostics Pack > Performance
Manager. You can also select the Diagnostics Pack icon, and then select Performance Manager.
In Linux, use oemapp pm from the command line. The oemapp executable is in
$ORACLE_HOME/bin. You are given the choice of what mode to run Performance Manager in:
• Enterprise mode: This requires a connection to an Oracle Management Server (OMS) with
a repository. This mode also allows for statistic charts to be recorded.
• Standalone mode: This does not require a connection to an OMS. You are not able to
record any statistics.

Tuning the SGA and PGA on Linux
Set and monitor the memory used by each instance.

• Size the SGA:
– Use the SGA_MAX_SIZE parameter.
• Size the PGA:
– Use the PGA_AGGREGATE_TARGET parameter with
dedicated servers.
– Use the LARGE_POOL_SIZE parameter with shared
servers.
• Monitor instance performance and paging.
Tuning the SGA and PGA on Linux

Size the Instance Memory Allocation
The starting point for the SGA size is 50% of the real memory. If there is more than one instance
on a machine, then all the SGAs should fit in 50% of the real memory. The PGA + SGA memory
should be set to less than 100% of the real memory. This is just a starting point. The sizes of
SGA and PGA can be adjusted when the database and memory utilization is monitored.
Size the SGA
The SGA_MAX_SIZE parameter can be used to allocate virtual memory when the database
starts. If this memory allocation is larger than what is consumed by the various DB_*_CACHE
and *_POOL parameters, then the unused memory is allocated in the virtual memory map, but is
not mapped to physical memory until it is used. If SGA_MAX_SIZE is greater than the used
SGA memory, then the DBA can dynamically make the cache and pool sizes larger without
having to restart the instance. SGA_MAX_SIZE is a static parameter and cannot be changed after
the instance is started. If SGA_MAX_SIZE is not set explicitly, then at startup the instance
calculates the size of the SGA from the other parameters and sets SGA_MAX_SIZE.

Tuning the SGA and PGA on Linux (continued)
Size the SGA (continued)
From the Oracle Enterprise Manager console, there is advice available for DB Cache and Shared
Pool sizing. To see this, open a database in the navigator, highlight Instance and go to the
Memory tab. Then click Advice. To verify the amount of memory that is being used for SGA,
use the SELECT sum(values) FROM V$SGASTAT command.
Size the PGA
A PGA is a memory region that contains data and control information for a server process. It is a
nonshared memory region created when a server process is started. The server process has
exclusive access to it. The total PGA memory allocated by each server process that is attached to
a database instance is also called the aggregated PGA memory allocated by the instance. The
PGA is made up of the following: Private SQL Area, Cursors and SQL Areas, Session Memory,
and SQL Work Areas.
Monitor Instance Performance and Paging
The OS-level memory statistics must be considered when changing the database instance
parameters. Increasing the memory used by the instance could affect overall performance if the
change causes more paging. The important statistics are pages in and the demand rate. If
increasing the instance memory allocation helps the database performance and does not affect
the paging statistics, then the memory sizes may be increased again. If the paging statistics
increase or no performance benefit is seen on an increase, revert to the previous instance
memory allocations.

Using PGA_AGGREGATE_TARGET
Manage global allocation of SQL work areas

automatically for dedicated servers by:
• Setting target memory size
• Monitoring actual usage
• Adjusting as needed
Using PGA_AGGREGATE_TARGET
You can globally manage the size of SQL work areas automatically. Specify the amount of
memory to be dedicated to PGA use for the instance. Set the PGA_AGGREGATE_TARGET
initialization parameter to the specified number (for example, 2 GB). This is the global target for
the instance. The database instance tries to limit the total PGA memory allocated across all
dedicated server processes to this target value. By using this feature, you can use the unused
memory from one process in another process, based on the work area space needed.
PGA_AGGREGATE_TARGET is dynamic at the instance level.
Note: PGA_AGGREGATE_TARGET is now used in place of the many *_AREA_SIZE
parameters of earlier releases.
Monitoring PGA Memory Usage
To monitor the amount of memory allocated to PGA, use the following command:
SQL> SELECT sum(pga_alloc_mem) FROM V$PROCESS;
This shows the total memory allocated to PGA instancewide at the time the command is
executed. Run this command several times while the system is under heavy load to get an
average value. If the value here is consistently higher than your setting for the
PGA_AGGREGATE_TARGET parameter, consider raising PGA_AGGREGATE_TARGET.

Using Shared Servers
Shared servers reduce memory usage:

• Fewer processes
• SQL work areas are allocated from SGA
– Configure large pool
– Monitor usage
– Adjust as needed
Using Shared Servers

A shared server configuration reduces memory usage by reducing the number of server processes
needed. A common value is 10 users for each shared server process. When using shared server
connections, portions of the PGA memory (including work areas) are allocated from the SGA.
These portions are called user global area (UGA). By default, this memory is taken from the
shared pool. If a large pool is configured with the LARGE_POOL_SIZE parameter, then the
memory needed is allocated from the large pool area instead of the shared pool. It is
recommended that you use the large pool with shared servers, because this gives you better
control over system resources. To monitor this memory usage, you can use the following
command:
SQL> SELECT sum(value) FROM v$sesstat, v$statname
2 WHERE name = 'session uga memory'
3 AND v$sesstat.statistic# = v$statname.statistic#;
For shared servers, the amount of used space must be smaller than the setting of
LARGE_POOL_SIZE. If the value returned is a high percentage of the large pool, consider
increasing the size of the large pool. You need extra space in the large pool because other
processes use the large pool. For example: Parallel query processes and Recovery Manager
(RMAN).

Summary

• Use Statspack with OS tools
• Use Oracle Enterprise Manager tools with OS tools
• Configure and measure SGA and PGA usage

Practice Overview:
Using Oracle9i Measurement Tools

• Installing Statspack
• Configuring a job to gather statistics
• Comparing statistical snapshots
Practice 8 Overview: Using Oracle9i Measurement Tools


Tuning Oracle9i and Linux

Objectives

the following:
• Evaluate file systems
• Tune supported file systems
• Configure initialization parameters
• Implement asynchronous input/output (I/O)
• Implement advanced memory management
techniques

I/O Modes
I/O can be written to disk in several ways by using

different system calls.
• Standard I/O
• Synchronous I/O
• Asynchronous I/O
Write Flush
Process Buffer cache Disk file
I/O Modes
In Linux, there are multiple methods of writing to disk.
The standard method writes the data to the operating system buffer cache, then the buffer is
written to disk by a kernel process at a later time. If the machine crashes or loses power before
the buffer is written to disk, the data is lost. This method is fast, but not acceptable for Oracle
Database file I/O because of the potential for data loss.
Synchronous I/O, also known as write-thru-cache, writes the data to the buffer but also forces an
immediate write to the file system. The process that makes the write request will be suspended
until the write is completed. The completion is signaled by the disk controller when the buffer is
written to disk. On some disk subsystems with large caches, the controller signals a completion
when the buffer is written into the subsystem cache. Although synchronous writes are slow, they
are the default method for DBWR and LGWR processes to do their writes because this I/O method
is supported on all distributions.
Asynchronous writes allow instance background processes to make multiple write requests
without being suspended after each request. The completion must still be signaled back to the
process. This permits a much larger throughput, because the background process can continue
work without waiting on the disk I/O to complete. The standard Linux kernel does not allow for
asynchronous writes, but SuSE, Red Hat, and UnitedLinux have implemented changes to support
asynchronous writes in their enterprise distributions.

Comparing File Systems
Linux supports multiple file systems:

• Operating system (OS) is file system independent.
• Multiple file systems can be on the same server.
– Cross-platform compatibility
– Performance
– Special requirements: Oracle Cluster File System
(OCFS)
Comparing File Systems

The Linux kernel is file system independent. It has a file system API. If the file system uses the
API, it can be supported. A variety of file systems are available with the standard distribution.
Some are just for compatibility with other systems, such as FAT32 for MS Windows
compatibility. Others are included for historical reasons, such as minix which was the first file
system supported by Linux. The most popular file systems are ext2, ext3, and reiser. All
are included in the UnitedLinux, SuSE, and Red Hat distributions. reiser is the default for
UnitedLinux and SuSE SLES8, ext3 for Red Hat and SuSE SLES9. Older distributions (2.2
kernel) used ext2 as the default file system. There are other file systems available from various
sources. Most of these should be considered experimental. Oracle Corporation provides the
Oracle Clustered File System (OCFS). The OCFS is designed for use with Linux Clusters
running the Real Application Clusters database. This file system overcomes the limitations of
raw devices on Linux. OCFS is fully supported by Oracle Corporation for use with database
files. It is not supported for general files.
Storage Area Network and network file system (NFS) may also be considered for performance,
reliability, high availability, or just to bolster the storage area available to a database. Not all
implementations meet the database requirements for a file system.
Oracle recommends the ext3 file system for database files if OCFS is not going to be used.

File System Characteristics
Certain characteristics are better for database use:

• Write-thru-cache ability
• Write acknowledgement
• Security
• Journaling
• High Performance
File System Characteristics

In choosing a file system, performance is important, but not the primary consideration. It does
not matter how fast the file system is if the data is corrupted, lost, or compromised. To achieve
this end, the Oracle database does not support database files on file systems that do not have a
write-thru-cache capability. Supported file systems must acknowledge writes. For example,
standard Network File System (NFS) uses the User Datagram Protocol (UDP). UDP does not
include an acknowledgment. One vendor that supplies a supported NFS file system is Network
Appliance using a modified NFS protocol. There are security requirements as well. Oracle server
and the database files require special file permissions that are not available on certain file
systems (such as VFAT). When these file permissions are not set correctly, the Oracle server
does not function properly. Data files should be accessible only to the database owner, and all
other access should be controlled by the database itself.
Journaling is a popular characteristic. The major benefit is that the changes to the file system are
recorded in a journal file similar to database redo logs. If the server crashes or shuts down
without synchronizing the disks, then the journal file can be applied to the file system, thus
restoring the file system integrity very quickly. This effect can be seen on boot up. The fsck
command checks journaled file systems more quickly than nonjournaled file systems.

Raw Partitions
Raw partitions have been considered the high

performance solution.
• Raw reads and writes do not use the OS buffer
cache.
• Raw reads and writes can move larger buffers
than file system I/Os.
• Using raw partitions complicates administration.
Write
Read
Process Disk file
Raw Partitions
Raw partitions have long been considered the ultimate in I/O performance. When new file
systems are benchmarked, they are frequently compared to raw partitions. The main benefit of
raw partitions is the lack of caching. Oracle server caches its own database blocks, and for the
normal reads in an online transaction processing (OLTP) environment, the simple read ahead
that is done by the file system is not effective. By avoiding the OS cache, the raw reads and
writes are not copied in memory, and the application doing the reads and writes can choose much
larger buffers for the data transfers than are allowed by the file system.
The penalties of using raw partitions are mostly administrative. Raw partitions can have only one
data object on a partition. So each data file, control file, and redo log file needs its own raw
partition. Linux has a limit of 255 raw partitions and a practical limit of 14 partitions per disk.
Because raw partitions do not have a file system, many file manipulation tools, such as ls, cp,
cpio, and mv, are not available. The only transfer tool available for raw partitions in Linux is
dd. Because of its interface, dd is considered by some to be not user friendly.
Until recently, raw partitions were the only way to share disk storage between nodes of a cluster
under most operating systems (VMS and Tru64 are exceptions to this rule). Because of this, you
were usually required to use raw partitions for Oracle Real Application Clusters. OCFS can now
be used for Oracle Real Application Clusters instead of raw partitions.

ext2 and ext3
The ext2 and ext3 file systems are closely related.

• ext2 can be converted to ext3.
• ext3 can be mounted as an ext2 file system.
• ext3 is a journaled file system.
• ext3 has several performance enhancements.
ext2 and ext3

The differences between the ext2 and ext3 file systems are important. ext2 has, in computer
terms, a long history of improvements and reliability. ext3 starts with the same base and adds
journaling and speed. In general, journaling is slower than nonjournaled file systems, but ext3
optimizes the disk head movement to give excellent performance. In several tests that compared
ext2, ext3, reiser, and raw, ext3 was the fastest.
ext3 has three journaling levels that may be set with the -o option in the mount command or
in the options section of /etc/fstab. The highest level—the one that does the most
journaling is data=journal—writes the journal entries for all the data and metadata changes.
The lowest level, which does the least journaling, is data=writeback with only metadata
being written. The default is data=ordered, where metadata with increased integrity is
written.
Comparing ext3 at different journaling levels has not been as thoroughly documented, but
preliminary results indicate that setting data=journal is the fastest and most reliable. The
other levels of journaling, data=writeback (the lowest) and data=ordered (the default),
would be expected to yield performance benefits at the expense of reliability, but do not seem to
be faster.

Oracle Clustered File System
Oracle Corporation makes OCFS available under the

General Public License (GPL) for use with Linux.
• OCFS allows a file system to be shared between
nodes of a cluster.
• OCFS is supported for database files only.
• OCFS may be downloaded from:
http://oss.oracle.com
• More information about OCFS and other products
from Oracle’s Linux Projects Development group
can be found at Oracle’s home for Open Source
projects, http://oss.oracle.com, and the Oracle
Technology Network http://otn.oracle.com
Oracle Clustered File System

Oracle Clustered File System (OCFS) is designed for use with Oracle Real Application Clusters,
but is not limited to that use. Oracle Corporation supports the OCFS for use with database files
only. OCFS is not a journaled file system, but does have very good performance metrics. Its
performance is less then 5% slower than raw, and in most tests only 2% slower.

Disk Guidelines
• Balance I/Os across all disks and controllers.

• Size the I/O subsystem for bandwidth.
• Match controllers to disk.
• Create mirrors for high availability.
• Practice the SAME concept for Unbreakable
Oracle on Linux.
For an Unbreakable system, Stripe and Mirror Everything
Disk Guidelines
Balance the I/Os Across All the Available Disks and Controllers
For best performance, balance the I/Os. That requires eliminating hot spots, and spreading the
data files across more than one disk. Tablespaces can be manually striped by putting data files on
different disks. You can also stripe data files with OS or hardware utilities such as Redundant
arrays of inexpensive disks (RAID). By striping all the files across all the available disk drives,
the goal of balancing I/Os is automatically met, but the cost of redistributing the stripes can be
high when more disks are added.
Size for the Required Bandwidth
With the disk capacity increasing faster than the I/O bandwidth, the number of disks and
controllers must be chosen based on the transfer rate required rather than the amount of data to
be stored. It is possible to store a 150 GB database on a single drive, but usually not advisable
due to performance considerations. To have sufficient bandwidth, the number of disks and the
number of controllers must be considered. A transfer rate of 500 MB per second with 20 MB per
drive requires at least 25 drives.

Disk Guidelines (continued)
Match Controllers to Disks
Twenty disks with a 20 MB per second transfer rate on two controllers with 80 MB per second
transfer rate, creates a bottleneck for the controllers. The I/O bandwidth of disks and controllers
must be matched. For example, a SCSI controller with a maximum transfer rate of 80 MB per
second must not have more than six drives with transfer rates of 20 MB per second. It is better to
have four drives.
Mirror for High Availability
Mirror the data to prevent data loss and reduce downtime. The easiest way to do this is to mirror
at the partition level and then stripe over multiple partitions. But if the partition is just part of a
drive, and the drive fails, then all the partitions on that drive are lost. Data files work well in this
configuration. Redo log files, archive log files, and control files should also be multiplexed at the
database level for maximum protection by simply having multiple instances of the files. When
using database multiplexing, different copies of the files should be on separate file systems, on
different physical drives, different controllers, and separate Redundant Array of Inexpensive
Devices (RAID) arrays if possible.
Use the SAME concept
For an Unbreakable system, Oracle recommends that you “Stripe And Mirror Everything,” also
referred to as the “SAME” concept.

Managing Tablespaces and Data Files
Follow OFA principles to manage the data files that are

associated with tablespaces.
• Create logical volumes across multiple disks.
• Create the data files on the striped volume.
• Move the data files from one volume to another
striped volume.
Managing Tablespaces and Data Files

The principles and guidelines from the preceding pages should lead to a careful layout of data
files on the available drives. To balance I/Os across all drives, at times you need to create data
files or move data files to different physical drives. This movement can be reduced by creating
tablespaces with multiple data files and by placing the data files on separate drives. The problem
can be further reduced by using hardware striping (if available) or OS striping with a Logical
Volume Manager (LVM) utility such as Veritas.
For example, to relocate file /u01/oradata/findb/indx01.dbf to a less loaded mount
point on /u04, you would:
sql> alter database datafile ‘/u01/oradata/findb/indx01.dbf’ offline;
sql> host mv /u01/oradata/finadb/indx01.dbf /u04/oradata/findb/indx01.dbf
sql> alter database rename file ‘/u01/oradata/findb/indx01.dbf’ to
‘/u04/oradata/findb/indx01.dbf’;
sql> alter database datafile ‘/u04/oradata/findb/indx01.dbf’ online;
Note that even after the move we retain the Optimal Flexible Architecture (OFA) structure to
facilitate easier administration.

Basic Oracle9i Database Optimizations
• Use locally managed tablespaces (default).

• Use a larger database buffer cache (within
reason).
• Use an appropriately sized database block.
• Use a larger redo log buffer.
• Use multiple database writer processes on SMP
machines.
Basic Oracle9i Database Optimizations

The Oracle9i database has a set of well-known (but often overlooked) features that enhance
performance.
Locally Managed Tablespaces
Locally Managed Tablespaces (LMT) are the default in Oracle9i. With Oracle9i Release 2, even
the system tablespace may be locally managed. LMT reduces I/O by managing the extent
allocation within a file with a bitmap in that data file instead of updating tables in the data
dictionary. This decreases the I/O requirements for the system tablespace. Performance increases
of 2% to 15% have been documented using LMT, depending on the application.
Larger Database Buffer Cache
The database instance caches the most recently used blocks in the database buffer cache. The
larger the cache, the more data blocks can be cached. Because a disk access takes much longer
than a memory access, each database block that can be cached and reused improves
performance. Size the cache according to the db_cache_advice feature in Oracle Enterprise
Manager. Do not make the cache so large that paging increases or (in extreme cases) it takes
longer to search for a block in memory than it would have to just read the block from disk.
Performance gains depend on the amount of reuse in the data blocks.

Sizing Database Blocks
The DB_BLOCK_SIZE parameter should be set

according to the type of application:
• 8 KB block size gives good overall performance.
• Smaller blocks give better concurrency with
OLTP applications.
• Larger blocks reduce the amount of overhead for
data warehouse/decision support system
(DW/DSS) applications.
Sizing Database Blocks

The size of the database block has a large impact on the performance of the application. Tests
have shown that the best block size is usually 8 KB. The database block must always be the same
size or a multiple of the memory page size. On Linux, the page size is 4 KB but, as discussed in
the lesson titled “Linux Measurement Tools,” can be increased to 2 or 4 MB using bigpages.
The database block should also be the same size or a multiple of the file system block size. The
block size on the ext3 file system is 4 KB. Other file systems may use other block sizes.
OLTP Applications
An OLTP application is characterized by a large number of concurrent users and relatively small
transactions. As the blocks get larger, the probability of two or more users requesting access to
the same block simultaneously also increases. This leads to “buffer busy” waits, because only
one process can access a block at a time. Smaller blocks reduce the number of rows in the block,
which then reduces the likelihood of concurrent access. If your application has these
characteristics, then consider setting DB_BLOCK_SIZE to 4 KB.

Sizing Database Blocks (continued)
DSS/DW Applications
Data warehouse type applications are characterized by large data sets, and frequent full table
scans. Because the data sets are so large that the database buffer cache cannot hold the full set,
the set must be read from disk. In this case, use the largest block size available (16 KB on 32-bit
Linux). This reduces the percentage of space used by block headers, and increases the number of
rows per block, thus reducing the number of I/Os by packing more data into the same number of
bytes.
Effect of Block Size on Indexes
In databases with large tables and small database blocks, consider a very large OLTP application
such as credit card processing. The indexes may get quite large. Index lookups are always done
serially: first the root block is accessed, then the first-level branch block is accessed. This
process continues to the n-1 level branch, finally reaching the leaf block, which is the nth level.
This lookup may require n I/Os for an n-level index, if the blocks needed are not already in the
cache. Ideally, the index is no more than three levels deep, meaning n should be three or less.
In the following example, a 20-level index is chosen to simplify the mathematics. Realistically,
an index would seldom get that large.
To illustrate the effect of the block size on an index, assume a 2 KB block size and a 20-level
index. If this index was in a database with 4 KB block size, then each leaf would hold at least
twice as many index row entries, so that half as many leaf blocks would be used. The first-level
branch blocks would hold twice as many leaf pointers, but there would be only half as many leaf
blocks, so the number of first-level branch blocks would be reduced to 1/4 of the original index.
Continuing with this exponential reduction in branches would reduce the number of levels to
five. The first index required 20 reads for an index lookup, and the rebuilt index requires five
reads. This significantly improves the performance of index lookups.
Because of this, you may want to use a larger block size if the application has very large indexes,
or consider using partitioned indexes.

LOG_BUFFER and Redo Log File
Increasing the size of the redo log components can

help the performance of high data manipulation
language (DML) applications.
• Examine Statspack reports for waits on the redo
log components.
• Tune the redo log file and archive log file
transfers first.
• Increase the size of the LOG_BUFFER parameter.
LOG_BUFFER and Redo Log File

Every DML statement produces some amount of redo information. This data must be written to
the redo log files on commit. The server process does not report Commit complete to the user
until the redo information has been written to the redo log file. When the current log file is full, a
log file switch occurs.
If the LGWR process cannot write to the log files fast enough to clear space in the log buffer for
other processes that are attempting to do DML, then various wait statistics are incremented.
Increasing the size of the LOG_BUFFER can reduce or eliminate these waits. The minimum
LOG_BUFFER size is 64 KB. An optimal setting for LOG_BUFFER varies with application.
High-volume DML applications can benefit from a LOG BUFFER set to 5 MB (note that redo
log buffer sizes greater than 5 MB seldom improve performance).
Sizing redo log files is dependent on the speed at which redo is generated. If the switch is
delayed for any reason, the processes trying to write into the LOG_BUFFER have to wait, and a
wait event log file completion is recorded. You want to eliminate these waits and at the
same time, do not want to size the files so large that they become unmanageable. Redo log files
in the range of tens to hundreds of megabytes are considered reasonable. A tentative guideline is
to size them such that the log file switch occurs every 20–30 minutes. For details, enroll in the
Oracle9i Database Performance Tuning course and see the Oracle9i Database Performance
Tuning Guide and Reference Release 2 (9.2).

Advanced Features of Oracle Server
There are a few advanced initialization parameters that

affect performance on Linux:
• DB_WRITER_PROCESSES
• DBWR_IO_SLAVES
• PRE_PAGE_SGA
Advanced Features of Oracle Server

The parameters listed here are considered advanced parameters. Very few initialization
parameters depend on the OS. The parameters listed in the slide are the ones that are most
affected by the OS.

Multiple DBWR Processes
DB_WRITER_PROCESSES
• Set to no more than CPU_COUNT, up to 20.
• Multiple DBWR processes write from LRU to disk.
• These processes can use asynchronous I/O.
• These processes are best used in OLTP
environments.
LRU lists
DBWR processes
Multiple DBWR Processes

In high-volume OLTP databases, the standard configuration of the DBWR process may not be
able to write changed data blocks back to the disk fast enough to maintain the pool of free
buffers for new blocks coming into the database buffer cache. The usual first step is to increase
the DB_CACHE_SIZE, but this may not be enough.
The next step is to increase the number of DB_WRITER_PROCESSES. This starts the specified
number of DBWR processes. This can be up to 20 with Oracle9i, Release 2. Each DBWR process
handles one or more LRU lists moving dirty buffers to the disk for those lists. If asynchronous
I/O is turned on, then all the DBWR processes make use of it.
The default value for DB_WRITER_PROCESSES is (CPU_COUNT+7)/8. For example, with
between one and eight CPUs, DB_WRITER_PROCESSES is set to one. If your CPU_COUNT =
20, then DB_WRITER_PROCESSES is set to three. The value of DB_WRITER_PROCESSES
must be adjusted incrementally. When increasing the number of DB_WRITER_PROCESSES,
consider the number of disk controllers that are available and monitor the disk I/O queues. Too
many DB_WRITERS_PROCESSES can cause contention for the controller channel.

DB Writer Slaves
DBWR_IO_SLAVES
• Used to simulate asynchronous I/O
• One DBWR, multiple writers to disk
Buffer
cache DBWR
I/O slaves
DB Writer Slaves
On systems without asynchronous I/O capability, the database instance provides a way to
simulate asynchronous I/O with the DBWR_IO_SLAVES. Asynchronous I/O is only available on
Red Hat Enterprise Linux AS and the Enterprise version of UnitedLinux and SuSE at this time.
Set this parameter to no more than two times the number of disks that the database is spread
across. When increasing DBWR_IO_SLAVES, consider the number of disk controllers and
monitor the disk I/O queues for contention. Also, when increasing the number of slaves, add only
a few at a time, because each of these processes have an overhead cost. If you add too many at
once, the overhead of all the processes may outweigh the benefit of the additional processes.
Each slave must have a communication area for I/O buffers. This area is taken from the large
pool if it is configured, or from the shared pool if the large pool does not exist. Turning on
DBWR_IO_SLAVES forces DB_WRITER_PROCESSES to one, and sets the number of slave
processes used by the ARCH and LGWR processes to four. Even though I/O slaves are generally
used to simulate asynchronous I/O, the slaves use asynchronous I/O if it is turned on.
Note: The use of multiple DBWR processes and I/O slaves are mutually exclusive.

Changing SGA Behavior
• Normally, unused memory allocated to the System

Global Area (SGA) is not mapped to physical
memory until it is used, and infrequently used
pages are paged out.
• To touch all the SGA at startup, use
PRE_PAGE_SGA:
– The SGA is mapped to physical memory.
– The SGA could slow connection processing.
Changing SGA Behavior

The normal behavior is that shared memory up to SGA_MAX_SIZE is allocated and set up in
virtual memory at startup. Unused pages in the SGA are not mapped to physical memory until
they are used, and pages in the SGA that are not frequently used may be paged out.
The PRE_PAGE_SGA initialization parameter causes each server process that starts to touch
every page of the SGA. This has the advantage of mapping all the SGA pages to physical
memory, so that when they are required later, they will already be mapped. The disadvantage is
that with a large number of pages each server process that starts touches all the pages, thus
increasing the connection time. If some pages are swapped out, those pages have to be swapped
in for the touch. This in turn may force other more active pages to swap, further reducing
performance. Set PRE_PAGE_SGA = true only when there is sufficient real memory to hold
the entire SGA.

Basic Linux Optimizations
Basic changes to the Linux default setup can give

some performance improvements.
• Use the latest supported kernel.
• Turn off last time read updates for
the database files.
Basic Linux Optimizations

Apply the latest supported kernel patches through the .rpm files provided by the distribution
vendor. This ensures that you are using the most efficient kernel available.
By default, the last time read attribute (atime) is updated every time a file is read. For database
files, this is not an important statistic and you can turn it off to reduce the number of I/Os. This
parameter can be set for a file with chattr +A <filename> or for a directory with
chattr -R +A <directory name>. To make this change persistent across reboots,
change it for a file system by changing the /etc/fstab file and adding the noatime option
to the fourth column.
/dev/hdb7 /u3/app/oracle/ ext3 rw,noatime 1 1

Enterprise Distribution Features
• Asynchronous I/O
• Advanced memory configurations
– Modified memory map
– Shared memory file system
Enterprise Distribution Features

Oracle Corporation continues to contribute to the Open Source Community with kernel
enhancements and packages similar to the Oracle Clustered File System. Oracle Corporation has
worked with Red Hat to include several of these enterprise-level features into the enterprise
distribution. These features are under GPL and are available to other distributions. All of these
features are also available under UnitedLinux and SuSE SLES.
Asynchronous I/O
With normal synchronous I/O, the process that is making the write request waits for the
completion of the write before continuing. With asynchronous I/O, the process can make
thousands of write requests without having to wait for completion of a prior request. No write is
considered complete until the OS reports a completion message back to the requesting process.
Advanced Memory Configurations
By making use of the underlying changes to the Linux memory system, you can create an SGA
beyond the 1.7 GB limits imposed by most Linux kernels. This allows a theoretical SGA size of
up to 62 GB. Practical limitations make that limit closer to 20 GB. The Linux OS and Oracle
database have been tested with SGA sizes up to 16 GB on Red Hat Enterprise Linux AS 2.1 and
24 GB under UnitedLinux 1.0.

Implementing Asynchronous I/O
The Oracle server executables must be relinked to

make use of asynchronous I/O.
• Data files must reside on a file system that
supports asynchronous I/O.
• Relink the RDBMS.
• Set initialization parameters:
– DISK_ASYNCH_IO (for raw devices)
– TAPE_ASYNCH_IO
– FILESYSTEMIO_OPTIONS (for file systems)
• Set maximum asynchronous I/O size.
Implementing Asynchronous I/O

The file system where the database files reside must support asynchronous I/O, such as the ext3
file system. Oracle server executables must be relinked with the following options. Before
relinking, stop all database processes by using the same $ORACLE_HOME.
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk async_on
Verify that the initialization parameters that control asynchronous I/O are set to their default
values:
disk_asynch_io = true (for raw devices)
tape_asynch_io = true
filesystemio_options=asynch (for file systems )
The default I/O mode for the Oracle server is synchronous I/O. To restore the default behavior,
repeat the above commands with:
$make -f ins_rdbms.mk async_off
If the Oracle server binary is linked with the async_on option, then the following parameter
turns off asynchronous I/O operations:
disk_asynch_io=false

Implementing Asynchronous I/O (continued)
Adjusting Asynchronous I/O Maximum Size
To get better I/O throughput with DSS workloads, the /proc/sys/fs/aio-max-size
should be increased from the default 1,31,072 bytes (128 KB) to equal to or greater than
10,48,576 bytes (1 MB). You cannot enter values with a K or M qualifier, because the kernel
only understands the number as bytes.
# echo 1048576 > /proc/sys/fs/aio-max-size
To make the change persistent after system restarts, add the following to sysctl.conf:
fs.aio-max-size = 1048576
For OLTP workloads, the default size of 1,31,072 should suffice, because these workloads
typically perform very small writes.

Choosing a Kernel
Choose the appropriate kernel for best performance:

• If you have more than 4 GB of physical memory,
the use the enterprise kernel.
• If you have more than one CPU, then use the smp
kernel.
• Otherwise, use the uniprocessor kernel.
Choosing a Kernel
The Linux installers tend to make good choices about which kernel to install, and install the
kernel that uses your hardware and gives a good performance. If you have to choose which
kernel to use, follow these guidelines.
For machines with more than 4 GB of physical memory, an enterprise kernel is required.
The enterprise kernel includes the Physical Address Extensions (PAE) that is required to
address more than 4 GB of physical memory. This includes a three-level memory page table, so
if you have less than 4 GB of physical RAM, then the three-level page table is an extra overhead
that is not required. Red Hat identifies the enterprise kernel with the word “enterprise” in
the kernel version name, for example 2.4.9-e.3enterprise.
For multiprocessor machines, the installer chooses an smp kernel. The smp kernel has the
required extensions to handle scheduling processes on more than one CPU. An example of the
Red Hat smp kernel is 2.4.9-e.3smp.
The uniprocessor kernel handles up to 4 GB of physical memory on a single processor. An
example of the uniprocessor name is 2.4.9-e.3. (Note that there is no special designator.)
An enterprise or smp kernel may be used on an uniprocessor machine, but has extra
overhead associated with the unused features.

Implementing a Large SGA
There are two methods to implement a large SGA

under Linux:
• Alter the Linux memory map so the SGA can use
more than 1.7 GB (up to about 2.7 GB)
• Relocate the Database Buffer Cache so it uses a
memory-based file system (up to 60 GB)
These methods can be combined, enabling very large
SGAs. The theoretical limit for a Linux SGA is 62 GB,
practical limitations are closer to 20 GB

There are two Linux memory limitations that affect the maximum size of the SGA. One of those
is a process limitation, the other is a kernel limitation.
Kernel Limitations
A 32-bit processor cannot access more than 232 bytes (4 GB) of RAM without assistance. That
assistance comes in the form of PAE that breaks up the memory into chunks that can be handled
by the 32-bit processor. Those chunks are accessed through an extra layer of memory address
translation (that three-level page table mentioned earlier).

Standard Linux Memory Map
4.0 GB
OS Disk Buffer
Kernel use and Page cache
2.98 GB
Process memory Oracle SGA
1.25 GB
Shared libraries lib*.so
1.0 GB mapped_base
Application code Oracle Executables,

user processes
128 MB
Kernel (not paged)
Standard Linux Memory Map

With 4 GB of RAM, the Linux kernel will normally divide it up as shown above. The kernel
takes up a fairly small amount of RAM at the base of the memory map (the diagram above is not
to scale). The kernel will also reserve the top portion of the memory map for disk buffer caching
and memory page table maintenance. The area in-between is left for applications such as the
Oracle Database.
The application area is divided into three sections: a section for application code, a section for
application memory, and a section for shared libraries. With Oracle, user processes and
background processes, such as PMON, SMON, and DBWn, reside in the application code area,
whereas the SGA resides in the application memory area. The starting point in the memory map
for shared libraries and process memory is controlled by mapped_base. As you can see,
process memory can occupy the section from about 1.25 GB to 2.98 GB, giving the SGA a
maximum size of around 1.7 GB. The only way to make more room for the SGA is to take away
room from other application area sections.

Modified Linux Memory Map
4.0 GB
OS Disk Buffer
Kernel use and Page cache
2.98 GB
Process memory Oracle SGA
336 MB
Shared libraries lib*.so mapped_base
256 MB
Oracle Executables,
Application code
128 MB user processes
Kernel (not paged)
Modified Linux Memory Map

It is possible to modify the Linux memory map and allocate more memory to the SGA. The
kernel will still take up about 128 MB at the base of the map as well as the upper 1 GB, but the
three application areas can be redistributed by changing the mapped_base.
As you can see above, lowering mapped_base expands the area available to the SGA at the
expense of room for shared libraries and application code. The theoretical limit for the SGA
using this method is approximately 2.7 GB.
From a practical standpoint, you have to worry about shrinking the space for application code
too much, because it does little good to have a large SGA if your users cannot create sessions to
access it. Ensure that you leave enough room below mapped_base for your applications to
run.

Altering the Linux Memory Map
These steps are required for alter the Linux Memory

Map and implement an SGA between 1.7 GB and 2.7
GB.
1. Modify shmmax.
2. Modify a shell for starting the database instance
by lowering mapped_base.
3. Relocate the SGA:
a. Modify ksms.s.
b. Relink the database executables.
Altering the Linux Memory Map to accommodate a larger SGA

This procedure is used for setting an SGA larger than 1.7 GB and smaller than 2.7 GB on a
machine with 4 GB or less of real memory. Remember that you need to leave room for
application code, so even as this example maximizes the SGA in real life you would probably set
the mapped_base higher. This is not especially difficult, but you have to be careful. If you
perform these steps incorrectly, you will receive unexpected error messages (ORA-3113, attach
errors, or server processes just dying, and so on).
Lowering mapped_base and Relocating the SGA Method
Advantages:
• You can increase the SGA from the default of 1.7 GB up to 2.7 GB.
• It works with any 8.1.7, 9.0.1 or 9.2.x database.
• The entire SGA (shared pool, buffer cache, and so on) can be increased in size.
Disadvantages:
• Local startup/shutdown of the database is allowed only from a modified Linux shell.
• It requires a thorough understanding to be implemented correctly.
• Less virtual memory remains available for the PGA, so things like sorting need to be tuned
differently.

Modifying shmmax
Set the shmmax parameter to hold the entire SGA.

• This can be done for real memory up to 4 GB.
• For this boot:
# echo 3000000000 > /proc/sys/kernel/shmmax
• For future boot ups change sysctl.conf:
kernel.shmmax = 3000000000
Modifying shmmax
The shmmax parameter can be changed dynamically, but unless you want to have to repeat the
change every time you reboot the server you should enter the change in the
/etc/sysctl.conf file. The previous rule of thumb of limiting shmmax to half of real
memory does not apply here. It is assumed that the amount of SGA needed has already been
determined. The amount of process memory needed is also known. The sum of the SGA, the
process memory, and the kernel and OS caches must be sized to be allocated without excessive
paging.

Lowering mapped_base
The mapped_base parameter is set at the process

level, and can only be set by root.
• Start a shell as the oracle user.
– Find the oracle user shell process ID:
$ echo $$
• Start a shell as the root user.

– Set the mapped_base for the oracle user shell:
# echo 268435456 > /proc/<pid>/mapped_base
• In the oracle user’s shell:

– Start the database
– Start the listener
Lowering mapped_base
The mapped_base is an address in virtual memory where the mmap starts looking for a chunk
of memory to allocate to the shared memory. The larger memory addresses are considered lower
in memory. By starting the search at a lower address, a larger shared memory allocation up to 2.7
GB is possible. The mapped_base parameter is set on a per process basis, so it cannot be set
during boot up, or for the entire system.
Lowering the mapped base is a requirement for every shell that spawns an Oracle server process
on the server. This includes any shell that is used to connect locally to the database and the shell
used to start the listener (this way, listener-spawned processes inherit a lowered
mapped_base). This step will have to be performed EVERY TIME you start the instance. This
means you will not be able to start the instance using Oracle Enterprise Manager or other tools.
The mapped_base parameter is inherited by any process spawned by a shell that has the
mapped_base lowered.
Start a shell as the oracle user. In the shell, find the process ID by using ps or echo $$.
Start another shell as the root user and lower the mapped_base with the following command:
# echo 268435456 > /proc/<your process ID>/mapped_base
where 268435456 is decimal for 0 x 10000000.

Lowering mapped_base (continued)
Automate Lowering of mapped_base
Lowering mapped_base must be repeated for every shell that starts any process that attaches
to the SGA. A small program can be called from the .bash_profile of the oracle user to
automate the lowering of the mapped_base. A program like the following one should be
compiled, and then called from the .bash_profile. If the following code is in a file named
lowermap.c, then it may be compiled with gcc -o lowermap lowermap.c producing
an executable named lowermap.
/* lowermap.c */
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <string.h>
#define DEFAULT_MAPPED_BASE 0x10000000
int main(int argc, char *argv[])
{
pid_t ppid;
char buf[256];
unsigned long mapped_base;
int ret;
ppid = getppid();
mapped_base = DEFAULT_MAPPED_BASE;
if (argc == 2)
{
mapped_base = strtoul(argv[1], 0, 0);
}
sprintf(buf, "echo %lu >/proc/%u/mapped_base", mapped_base,
ppid);
setuid(0);
ret = system(buf);
if (ret == 0)
printf("Lowering mapped base of pid=%u to 0x%X\n", ppid,
mapped_base);
else
printf("Unable to lower mapped base. You might need to:\n"
" chmod 4755 lowermap\n chown root.root lowermap\n");
exit(-ret);
}

Relocating the SGA
Execute the following commands as the Oracle

software owner:
$ cd $ORACLE_HOME/rdbms/lib
$ cp ksms.s ksms.s_orig /* if ksms.s exists,
back it up first.*/
$ genksms -s 0x15000000 > ksms.s
$ make -f ins_rdbms.mk ksms.o

$ make -f ins_rdbms.mk ioracle
Relocating the SGA

In this procedure, the ksms.s library is modified, and the database executable is relinked to use
a lowered address for the SGA. The address of 0X15000000 is safe, and lower addresses may be
usable down to about 0x12000000, but these lower addresses must be thoroughly tested. Other
Oracle Corporation–supplied executables may use addresses below 0X15000000 and can be
incompatible with these changes.
After these changes have been made, an SGA of approximately 2.7 GB can be allocated.
Reversing the Change
If things go wrong and you want to return to your original values, then you can do one of the
following:
• If ksms.s existed before you began this process:
$ cp ksms.s_orig ksms.s
• If ksms.s did not exist, use the following command to return to the default installed
value:
$ genksms > ksms.s
After you restore or regenerate ksms.s:
$ make -f ins_rdbms.mk ksms.o
$ make -f ins_rdbms.mk ioracle

Relocating the Database Buffer Cache
These steps relocate the database buffer cache so that

instead of occupying a portion of the application area
within memory, it resides in a virtual file system. To do
this:
1. Use the enterprise kernel and Oracle 9iR2.
2. Set shmmax to hold the entire SGA.
3. Enable bigpages for performance boost.
4. Enable shared memory file system.
5. Set the initialization parameters and restart the
instance (dynamic SGA parameters are not
available)
Relocating the Database Buffer Cache

It is possible to relocate the position of the database buffer cache so that it does not occupy space
with the rest of the SGA in the application area of the memory map. This not only allows for
MUCH larger database buffer caches, but also frees up memory with the 2.7 GB limit for other
areas of the SGA such as the shared or Java pools.
Use the enterprise kernel
Your kernel must support PAE for this process to work. For both Red Hat and UnitedLinux that
means using the enterprise kernel. Relocating the database buffer cache to a shared file system is
supported only with Oracle 9i Release 2 or later.
Set shmmax to hold the entire SGA
From any root Linux shell, set the shmmax kernel parameter to half the size of physical
RAM available on your system. The value for shmmax cannot exceed 4294967295, 4 GB:
# echo 4000000000 > /proc/sys/kernel/shmmax
Again, set it at boot up by setting kernel.shmmax in /etc/sysctl.conf.
Ensure that bigpages are enabled
Ensure that bigpages are enabled as discussed in the lesson titled “Linux Measurement
Tools.”

Relocating the Database Buffer Cache (continued)
Mount a Shared Memory File System (SHMFS)
As root, mount a shared memory file system and mount it at every boot up by changing the
/etc/fstab file:
# mount -t shm shmfs -o size=8g /dev/shm
Add the following line to the /etc/fstab file:
none /dev/shm tmpfs size=8g 0 0
This creates an shmfs file system on /dev/shm of 8 GB size. The size parameter accepts the
“k”and “m” multipliers as well. When the database instance is started with the extended buffer
cache feature enabled, a file is created in /dev/shm that corresponds to the SGA database
buffer cache.
Configure the Instance to Use the Shared Memory File System
Set the following initialization parameters, assuming an 8 KB block size, and 3.8 GB cache:
USE_INDIRECT_BUFFERS = TRUE
DB_BLOCK_BUFFERS = 475000
Note: Multiple database buffer cache block sizes and the dynamic SGA buffer cache parameters
cannot be used with INDIRECT_BUFFERS. The database buffer cache size must be set with
DB_BLOCK_BUFFERS.
Verify whether the following initialization parameters are NOT set:
DB_CACHE_SIZE
DB_2K_CACHE_SIZE
DB_4K_CACHE_SIZE
DB_8K_CACHE_SIZE
DB_16K_CACHE_SIZE
DB_32K_CACHE_SIZE
Start up the Oracle9i Release 2 instance. If you are using this method in conjunction with
altering the Linux memory map, then do not forget to reset mapped_base before starting the
instance. Memory allocated to DB_BLOCK_BUFFERS will now be consumed from the shared
file system located at (in this example) /dev/shm leaving up to 2.7 GB for other SGA areas.

Summary

• Evaluate file systems
• Tune supported file systems
• Configure initialization parameters
• Implement asynchronous I/O
• Implement advanced memory management
techniques

Practice Overview:
Tuning Oracle9i and Linux

• Implementing the noatime file system option
• Measuring the impact of the noatime option
• Implementing asynchronous I/O
Practice 9 Overview: Tuning Oracle9i and Linux


Next Steps
Continuing Your Education

Where Do You Go From Here?
“To stay competitive in the tech industry, never stop

learning. Always be on the lookout for better ways of
doing things and new technologies. Our industry does
not reward someone who lets themselves stagnate”
--John Hall, Senior Vice President, Oracle Corporation
Here are a few resources to help you with continuing

education.
E-2 Copyright © 2004, Oracle. All rights reserved.
Managing Oracle on Linux E-2

Continuing Education Resources
Resources to learn more about managing Oracle on

Linux include:
• Oracle University web site
• Oracle University Online Library
• http://www.unitedlinux.com
• http://www.redhat.com
• http://oss.oracle.com
• http://otn.oracle.com
• http://metalink.oracle.com

Oracle University
Learn Oracle from Oracle! No one knows Oracle

Technology better than Oracle University.
• Worldwide education services
• Consistently high customer satisfaction
• Learn with the format that best suits your needs
– Instructor-Led Inclass Training
– Instructor-Led Online
– Self-Study CD-ROMs
• Recommended Follow-on classes:
– Managing Real Application Clusters on Linux
– Oracle9i Database: Security
– Oracle Enterprise Manager 9i http://education.oracle.com
Oracle University
Oracle University is the world’s largest corporate educator with education centers around the
globe. Boasting one of the highest customer satisfaction ratings in the industry (over 95%), our
instructors are experts on Oracle technology and can help you get the most from your software.

Oracle University Online Library
Extend your learning with the Online Library, providing

access to thousands of hours of training on everything
from fundamental SQL to advanced database topics
• Access during the weeks following this class at no
additional charge with a substantial discount for
follow-on subscriptions
• Topics of interest include:
– Oracle9i: Performance and Scalability
Enhancements
– Oracle9i: Security Concepts in an Internet
Environment
– Latches and Tuning
– OCA and OCP
Preparation material http://ilearning.oracle.com
Oracle University Online Library

Oracle Corporation’s Online Library contains thousands of hours of content on a variety of
topics. This content can be accessed 24x7 via the web and is a great way to refresh your memory
on things you may not have worked with for a while, or to pick up new concepts.
Additional content for the Online Library is being developed continuously, so be sure to check
back often to see what’s new.

Oracle Technology Network
Oracle Technology Network is a free resource with

information on the core Oracle software products
including Database, Application Server, Collaboration
Suite and Development Tools.
• Technology Centers
• Discussion Forums
• Software Downloads
• Online Documentation
• Oracle By Example
• Code Samples
and much more! http://technet.oracle.com
Oracle Technology Network

The Oracle Technology Network hosts the latest news about Oracle technology and products.
Additionally, OTN provides peer-to-peer forums, white papers, security bulletins, and other vital
information for the Oracle professional.
In addition to tips, tricks, and techniques for getting the most out of your Oracle software, OTN
allows you to download that software. Remember, All software downloads are free, and each
comes with a development license that allows you to use full versions of the products only while
developing and prototyping your applications.

Oracle AppsNet
Oracle Technology Network is another free resource

for Oracle Applications users and implementers.
• Small Business Suite
• Human Resources
• Financials
• Marketing
• Business Intellingence
• Learning Management
and much more!
http://appsnet.oracle.com
Oracle AppsNet
The Oracle AppsNet is a clearinghouse for information on Oracle applications. Here you will
find information about the most powerful, best integrated, fastest growing applications suite,
Oracle e-Business applications.
With everything from Oracle 11i documentation to upgrade tips to white papers and technical
presentations, AppsNet is a must if you are using Oracle Applications.

Oracle MetaLink
Access to Oracle MetaLink is included as part of your

annual support maintenance fees. In addition to the
most up-to-date technical information available,
MetaLink gives you access to:
• Technical Assistance Requests (TARs)
• Certification Matrices
• Technical Forums monitored by Oracle experts
• Software Patches
• Bug reports
http://metalink.oracle.com
Oracle MetaLink
Oracle MetaLink is your gateway to Oracle’s Support resources. Here you will find answers to
the most common issues facing Oracle administrators and developers, as well as the resources to
solve many of those issues.
Like the Oracle Technology Network, MetaLink includes up-to-the-minute headlines about
issues that affect the Oracle professional.

Thank You!
We hope your experience with Oracle University has

been enjoyable. We welcome your feedback on how
we can improve to better meet your needs.
• End-Of-Course evaluations
• Oracle University Office of Customer Satisfaction
• Oracle Education Services
We hope to see you in class again soon.
Thank You!
Oracle University’s mission is to enhance the adoption of Oracle technology. Our goal is to
partner with you, providing information that is pertinent, timely, and relevant to your needs.
Please take a minute to complete the end of course evaluation and let us know how we can serve
you better. If something comes to mind after you leave us, feel free to e-mail our office of
customer satisfaction at:
customersat_us@oracle.com
If you have questions about continuing your Oracle education, need help finding a class, or want
to arrange for on-site training at your company, please contact Oracle Education Services for
assistance. In the US, dial 800.529.0165. For contact numbers outside the United States, check:
http://www.oracle.com/education/index.html?contact.html
Thanks again, hope to see you in another class!

Linux With Oracle9i

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Linux With Oracle9i

Caricato da

Copyright:

Formati disponibili

Managing Oracle on Linux

Sourish Kundu Restricted Rights Legend

1 Oracle9i on Linux: Overview

2 Preparing the Operating System

4 Creating a Custom Oracle9i Database

5 Installing and Configuring Enterprise Manager

6 Customizing the Oracle9i Database

7 Linux Measurement Tools

8 Oracle9i Measurement Tools

9 Tuning Oracle9i and Linux

Appendix B: Practice Solutions

Appendix C: Basic Linux and vi Commands

Appendix D: FAQ and RAID

Appendix E: Next Steps: Continuing Your Education

Copyright © 2004, Oracle. All rights reserved.

After completing this lesson, you should be able to do

1-2 Copyright © 2004, Oracle. All rights reserved.

Managing Oracle on Linux 1-2

Some supported Linux versions are:

1-3 Copyright © 2004, Oracle. All rights reserved.

Red Hat, SuSE, and UnitedLinux

Managing Oracle on Linux 1-3

Managing Oracle on Linux 1-4

1-5 Copyright © 2004, Oracle. All rights reserved.

Certification Matrix on MetaLink

Managing Oracle on Linux 1-5

Oracle products are certified

1-6 Copyright © 2004, Oracle. All rights reserved.

Supported and Suggested Configurations

Managing Oracle on Linux 1-6

Oracle9i has several versions and patch levels:

1-7 Copyright © 2004, Oracle. All rights reserved.

Managing Oracle on Linux 1-7

• Oracle Corporation does not certify hardware;

1-8 Copyright © 2004, Oracle. All rights reserved.

Managing Oracle on Linux 1-8

• The core parts of the Linux system are:

1-9 Copyright © 2004, Oracle. All rights reserved.

Linux Distribution: Overview

Managing Oracle on Linux 1-9

The Linux system is made up of software that

1-10 Copyright © 2004, Oracle. All rights reserved.

Managing Oracle on Linux 1-10

The kernel is the core of the operating system. It is:

1-11 Copyright © 2004, Oracle. All rights reserved.

Managing Oracle on Linux 1-11

• Execute the uname -r command to see the kernel

• Check the version name returned in MetaLink

1-12 Copyright © 2004, Oracle. All rights reserved.

Verifying the Kernel

Managing Oracle on Linux 1-12

Managing Oracle on Linux 1-13

Execute the /sbin/lsmod command to see whether

1-14 Copyright © 2004, Oracle. All rights reserved.

Checking for a Tainted Kernel

Managing Oracle on Linux 1-14

Managing Oracle on Linux 1-15

Check the kernel and libraries that are installed:

1-16 Copyright © 2004, Oracle. All rights reserved.

Managing Oracle on Linux 1-16

Managing Oracle on Linux 1-17

Apply the patches recommended by the distribution

1-18 Copyright © 2004, Oracle. All rights reserved.