N o.
1 2 O R A C L E – S A P NEWS 2 0 0 3
ABB shows HP Tru64™ UNIX and Oracle9i
Real Application Clusters are ready for
business-critical SAP® applications
ABB is a leader in power and automation techno-
logies that enable utility and industry customers
to improve performance while lowering environ-
mental impact. The ABB Group of companies
operates in more than 100 countries and employs
around 146,000 people. ABB is a recognized global
Oracle for SAP ® ®
is safe, reliable
and scalable. Reliab
le
le
ab
al
Sc
Safe
Content:
ABB shows HP Tru64 TM and Oracle9i RAC for SAP
Oracle9i RAC Network Technology
Oracle9i Online Data Reorganization
Delta Consulting
Oracle Collaboration Suite
Oracle Internet Directory 9.2. for SAP
Diagnosing Performance Bottlenecks using Statspack
Pressing the “famous button” SAP on Oracle at Kodak
Oracle RAC and Fujitsu Siemens
Oracle9i Release2 for Intel Itanium2 Systems
IT – Energy for Halliburton
The SAP Special Interest Group (SIG) at IOUG
Successful migration from DB2 to Oracle
Effectiveness of Oracle9i Table Compression in SAP BW
SAP Server Consolidation – flexibility with low TCO
SBS and Oracle Real Application Clusters
mySAP Solutions Running Oracle9i RAC and Linux
Oracle for SAP – Release Matrix
for SAP – reducing your TCO
RAC
leader in all of its core areas of competence: power
technologies (products, services and solutions for
power transmission and distribution), oil, gas and
petrochemicals (oil and gas drilling onshore and
offshore, offshore production installations, refine-
ries and petrochemical plants), automation techno-
1 logies (products, systems, software and services
for the automation and optimization of industrial,
2 commercial and utility operations) and financial
services (financing, sales support, risk management
4 services and insurance for internal and external
8 customers). To support these varied lines of busi-
ness, ABB has approximately 20 SAP productive
9 systems. These systems are accessed by some
10,000 users worldwide. Storage Area Networks
10
(SAN) and standby databases are used to achieve
the desired levels of availability.
11
14 More for less
15
ABB was keen to increase manageability, availa-
bility and scalability, at the same time cutting
15
costs by scaling out its SAP deployment. A SAN
16 coupled with clustered servers offers various
advantages but also has certain drawbacks.
17 Failover clusters do not enable load balancing,
18 and database recovery takes several minutes or
more in the event of server failure. Additionally,
19
like many other companies, ABB found it diffi-
cult to justify the cost of standby servers. All
25
going well, these powerful, expensive machines
may sit idle for months on end without providing
26
any additional processing power or capacity.
27
cont. page 2
28
® ®
Editorial
Dear SAP customer,
The latest Oracle for SAP Technology Update,
published by the Oracle/SAP Global Technology
Center, will help you better understand Oracle
technology used by SAP, Oracle‘s service offe-
rings, Oracle/SAP release combination, real life
customer stories and more:
• Successful implementation of Oracle Real Ap-
plication Clusters Technology for SAP at ABB
• SAP customer story: database migration from Gerhard Kuppler
DB2 to Oracle Director Corporate SAP Account
• Oracle9i Online Reorganisation, Oracle Internet Oracle Corporation
Directory for SAP
• Cost savings by using Oracle9i table compres-
sion for SAP BW
Oracle9i Real Applications Clusters provides both
scalability and availability as a single, easy to
manage database product. And that means de-
creasing the Total Cost of Ownership. SAP is com-
mitted to develop, port and migrate their appli-
cations to function optimally with Oracle database
and Real Application Clusters technologies.
The 15 year Oracle/SAP technology partnership
delivers great value to mutual customers by pro-
viding the most proven, stable, reliable and scala-
ble database technology platform for SAP systems
running on Windows, Unix and Linux.
“SAP on Oracle” means customer satisfaction and
proof of a functioning technology partnership for
more than 39000 joint mySAP, SAP R/3 and BW
installations worldwide. However, “SAP on Oracle”
also stands for global cooperation in database
reselling – development and support services in
Walldorf and Redwood Shores to be able to supply
shared customers with an optimized and custo-
mized combination of products.
Oracle’s innovative database technologies (e.g.
milestones like Row Level Locking, Partitioning,
Real Application Clusters) are an important con-
tribution in enabling SAP applications to be
embedded in a world-wide accepted and supported
DB technology platform.
Please don’t hesitate to contact us, eMail:
saponoracle_de@oracle.com
For more information please see also
www.oracle.com/newsletters/sap
Sincerely
Gerhard Kuppler
 from page 1
The answer
The answer presented itself in the form of
Oracle9i Real Application Clusters. Real
Application Clusters exploit modern hardware
and software clustering technologies to provide
the most flexible cluster database platform.
Instead of having idle standby systems, Real
Application Clusters harness the processing
power of all servers in the cluster.
9i
Key to cluster scalability, HP memory channel
acts as the cluster interconnect between the Real
Application Cluster nodes. It leverages high band-
width and low latencies for fast communication
and efficient messaging.
Tru64™ UNIX TruCluster™ Server software from
HP is one of the enabling technologies for Oracle9i
Real Application Clusters. The Cluster File Sy-
stem, a key component of HP’s Tru64 UNIX
TruCluster, enables all files to be simultaneously
Oracle9i RAC The unbreakable approach for deploying Oracle9i ™
Real Application Clusters
Network Appliance™ Filer Technology Helps
Unleash the Power of Oracle® Technology
D ATA B A S E
9
D ATA B A S E
9
D ATA B A S E
9
CLUSTER
CLUSTER
2 CLUSTER
accessed by all clustered servers. This vastly sim-
plifies management of clustered storage. HP
TruCluster Server software allows system admi-
nistrators to manage clustered systems as easily
as a single server. That’s because only TruCluster
Server software presents a single system image
where the operating system environment is sha-
red across all servers in the cluster.
First customer to run SAP on Oracle9i Real
Application Clusters
Keen to see how Real Application Clusters inte-
grate with their SAP systems and fit into their
overall SAP hosting strategy, ABB decided to
put Oracle9i Real Application Clusters to the test.
In close consultation with Hewlett-Packard,
Oracle and SAP, they organized a proof-of-con-
cept pilot project running SAP R/3 4.6C across
HP Tru64 UNIX 5.1A clusters on an HP Alpha-
Server™ platform.
Network Technology
Executive Overview
The demands being placed on data centers are
increasing. High availability is becoming a must-
have requirement for companies that cannot
afford system downtime. Global businesses need
to serve customers around the clock and often
rely on IT solutions to buy, sell, and service those
customers. This business pressure can be costly
when a system is not available, whether through
planning or not. In response, many companies
are turning to the Oracle9i Real Application
Clusters (RAC) solution, which enables them to
run Oracle databases on clusters of servers, and
Phased approach
On July 24, HP supplied ABB with a pilot plat-
form for the tests. ABB decided in favor of a pha-
sed test roadmap in order to measure the exact
impact of Real Application Clusters. The first
phase of the project involved copying the entire
database (which ran under Oracle8.1.7) to the
test system provided by HP. This was followed
by a series of baseline tests to assess performance
before the upgrade. ABB then upgraded the
database to Oracle9 and repeated the baseline
tests. The final phase involved upgrading to
Oracle9i Real Application Clusters – a straight-
forward procedure involving the simple addition
of a second node. This was again followed by
thorough functional tests that included all
management and monitoring tools. The results
were impressively conclusive.
Proof-of-concept
Although ABB did not manage to push the HP
platform to its performance limits, the paralle-
lization of jobs did not result in any degradation
of SAP performance. With minimum additions
to the hardware infrastructure (one additional HP
AlphaServer was required) and no adjustments to
the SAP system, ABB succeeded in creating a
highly available, high-performance infrastructure
with almost linear scalability at a fraction of the
cost of standard clusters. This was recently con-
firmed by an SAP benchmark proving almost lin-
ear scalability across up to four nodes. Particularly
in challenging times, the cost efficiencies of scaling
out and redeploying existing resources presents
the company with a valuable competitive advan-
tage. In fact, the project was so successful that
ABB is now the first customer live with SAP R/3
on HP Tru64 UNIX with Oracle9i Real Appli-
cation Clusters.
thereby achieve higher levels of system availabi-
lity and flexibility. To get the full benefit of the
Oracle technology, however, companies need sto-
rage that “matches” the powerful capabilities
offered by clustered servers and databases.
Like Oracle9i RAC, NetApp® storage technolo-
gies enhance the high availability, manageabili-
ty, and scalability of an IT environment. In addi-
tion, research shows that NetApp’s unique archi-
tecture and innovative approach to network-cen-
tric storage offer a significantly lower total cost
of ownership, compared to traditional storage
solutions. Overall, NetApp solutions give IT
departments using Oracle9i RAC a cost-effective
way to have a total clustered solution that sup-
ports the high availability and flexibility needed
in a rapidly changing business environment.
Oracle9i RAC Server
(Node 1)
Figure 2: Trends in computing power, storage capacity.
Storage: Completing the Picture
Over the last decade or so, the computing power of
most platforms has doubled every 18 months, the
storage capacity has doubled every 12 months,
and the network speeds have doubled every 8 to
9 months. This leads to a very important conver-
gence in the three most important aspects of a
corporate IT infrastructure. Storage, which was
dependent on the bandwidth of the network, can
now leverage the network to deliver and store
information without causing as much as a hiccup
in the infrastructure.
Network Speed
Storage Capacity
Computing Power
Figure 2) Trends in computing power, storage capacity.
Corporations are now in a position to leverage
this convergence to deliver the scalability and
availability demands placed on mission-critical
applications. Oracle9i RAC brings new levels of
availability, performance, and scalability to the
data center. But, to realize the full benefit of the
technology, companies need to take an end-to-
end view of data management that looks beyond
the database and server, and considers data stora-
ge technology, as well. They need an approach to
data storage that supports and enables the clu-
stered database by providing the same levels of
availability, performance, and scalability – and
which does so cost-effectively.
Just such an approach can be found in network-
centric storage technology from NetApp. The
NetApp architecture separates storage from the
server, makes use of existing open-standard net-
Oracle9i RAC Server
(Node 2)
Database
working infrastructure, and puts it on appliances,
such as its NetApp filers. These filers are dedicated
storage systems that handle a focused set of tasks,
rather than the range of interrelated functions
handled by the operating systems of servers.
Such specialization has made it possible to opti-
mize NetApp filers to handle storage tasks with
speed and efficiency, and to build storage specific
intelligence and tools into the system. In essence,
the NetApp storage technology supports the
Oracle9i RAC architecture by simplifying the
Doubling Every 8-9 Months
Doubling Every 12 Months
Doubling Every 18 Months
storage layer and providing high availability,
horizontal scaling, and manageability – the same
qualities delivered by the Oracle solution.
NetApp Filers
NetApp provides several technologies that help
companies align their storage layer with the
Oracle9i RAC solution. The NetApp family of
filers encompasses a wide range of appliances,
from high-end devices designed for the corporate
data center and e-business applications to systems
designed for small and medium businesses and
machines for departmental use. Because they are
separate appliances, NetApp filers can be deployed
in a true plug-and-play fashion, and brought
online in a matter of minutes. They are essenti-
ally building blocks: capacity can be added to a
system on-the-fly in small increments without any
downtime, and NetApp filers can scale from 50GB
to multiple terabytes. According to a recent study
from INPUT, 200GB can be added to a NetApp
filer in about 10 minutes, as opposed to the 4
hours it typically takes with storage area network
(SAN) solutions. Overall, companies can start
small with NetApp, buying only the capacity they
need, and then expand storage to stay in step
with the business. NetApp filers provide greater
than 99.99% data availability. They incorporate
many redundant hardware features and built-in
RAID that protects against downtime resulting
from disk failures – if a disk fails; automatic
reconstruction takes place on a hot spare disk.
Several high-availability models incorporate an
architecture that enables two filers to work in an
active /active Clustered Failover configuration.
The Underlying Software
NetApp filers rely on two key building blocks:
the Data ONTAP™ operating system and the
patented NetApp Write Anywhere File Layout
(WAFL(r)) file system.
Data ONTAP supports a wide range of protocols,
including NFS, CIFS, SCSI, HTTP, FTP, and the
Direct Access File System (DAFS) used by
Oracle9i. It allows the simultaneous use of multi-
ple protocols; thus, providing a truly uniform
storage infrastructure that can be accessed by
UNIX®, NT, and Web-based servers and clients.
The WAFL file system enables dynamically ex-
pandable data storage and supports data integrity
with block-level checksum capability. It incor-
porates the functions of file system, volume
manager, and RAID subsystems, so that there is
a high level of integration between those three
layers.
Unlike traditional file systems, it is not initiali-
zed: It can use any space that is available to it on
disk, and determine which disks to use based on
the actual geometry of the array. Administrators
can modify the amount of space available to the
system on-the-fly.
The WAFL file system does not overwrite exi-
sting blocks of data – instead, it always writes a
new block. When a new block is created, the
WAFL file system updates the “pointers” that
indicate the location of that block – that is, it
essentially takes a freeze-frame Snapshot™ of the
pointers at a specific point in time. It then makes
the frozen versions of the file system available via
special subdirectories that appear in the current,
or active, file system. Up to 31 of these versions
can be maintained concurrently. Several of these
can be viewed simultaneously, which means that
many data management tasks can be performed
while the system is in use – even if users or appli-
cation servers are heavily accessing and updating
the data. NetApp has created several data mana-
gement tools based on the WAFL file system's
freeze frame capability, including:
• Snapshot – enables backups and the recovery
of accidentally damaged or deleted data without
disruption of service.
3
 • SnapRestore® – allows any system to revert back
to a specified data volume for instant file-system
recovery, in minutes, without going to tape.
• SnapMirror® – provides remote mirroring at
high speeds over a LAN or WAN. The asyn-
chronous mirroring can be used for disaster re-
covery, replication, backup, or testing on a non-
production system.
The Right Fit for Oracle9i RAC
Together, NetApp’s network-centric architecture,
dedicated filer appliances, and sophisticated opera-
ting and file systems “complete the picture” for
Oracle9i RAC installations. The NetApp approach
complements the Oracle solution by extending
the benefits of the clustered solution into the sto-
rage layer. As does Oracle9i RAC, the NetApp
approach provides:
• High Availability. According to a study from
INPUT that examined Oracle production environ-
ments at 63 enterprises, NetApp technology
provides data availability of 99.99+% – one of
the highest rates in the industry.
• Manageability. The simplicity of NetApp archi-
tecture and its suite of database management
tools save time for DBAs and system admini-
strators.
• Scalability. NetApp filers can be scaled up in
small increments to handle the largest enterprise
workloads – giving IT departments a cost-effec-
tive, “pay-as-you go” capability.
• Affordability. NetApp’s storage technologies
offer a 70% lower total cost of ownership (TCO),
compared with competitive storage solutions
from HP, EMC, and Hitachi Data Systems,
according to the INPUT study. NetApp’s techno-
logies demonstrated a lower TCO in three areas:
acquisition costs for hardware and software,
operational costs in terms of people and time,
and business costs due to downtime.
Conclusion
Oracle9i RAC provides efficient, reliable, secure
data management for high-end applications such
as high-volume online transaction processing
(OLTP environments), query-intensive data ware-
houses, and demanding Internet applications.
Advanced options like Oracle9i RAC provide un-
limited scalability and high availability for any
packaged or custom application by exploiting
clustered configurations with the simplicity and
ease of use of a single system image. Oracle9i RAC
allows access to a single database from multiple
nodes of a cluster system configuration to insulate
application and database users from hardware and
software failures, while providing performance
that scales with the hardware environment.
NetApp delivers solutions for today’s IT challen-
ges. Deploying Oracle9i RAC on NetApp tech-
nology helps customers overcome many of chal-
lenges facing IT today most notably, the growing
volumes of data and the ability to manage and
keep it safe and secure. Deploying Oracle9i RAC
on NetApp storage lowers your overall TCO.
NetApp storage solutions provide simple, fast,
centrally managed data protection and optimized
performance for Oracle9i RAC installations,
(allowing Oracle database administrators to per-
4 form complex tasks quickly).
Oracle9i Online Data Reorganization
Oracle9i
SUMMARY
Requirements have changed. Only a few years
ago, it was acceptable for most customers that
reorganizing an index or a table caused the (base)
table to be locked and that no DML operation
(insert, update, delete) was allowed until the
reorganization was completed. In many of today's
mission-critical environments continuous data-
base availability has become one of the admini-
strator's top goals.
This is why the Oracle database server has chan-
ged as well. Both Oracle8i and Oracle9i have
introduced features that help reduce the frequen-
cy and minimize the impact of data reorganizati-
ons:
• New features such as locally managed tablespaces
(Oracle8i) and support for multiple block sizes
(Oracle9i) help avoid table or index fragmenta-
tion and chained rows – two main reasons for
reorganization.
• Oracle8i introduced online index reorganization,
meaning that users can continue to update and
query the base table while an index is being
reorganized. The reorganization can be
accomplished either in place (online index
defragmentation) or by creating a new copy of
the index (online index rebuild). Oracle8i also
introduced limited online table reorganization
capabilities. These were limited, because they
were restricted to index-organized tables (IOTs).
• Oracle9i further extended Oracle’s online capa-
bilities with a new feature called online data
redefinition. This functionality supports all types
of tables. It can be used to perform a simple
online table reorganization. However, it is much
more powerful, because it allows administrators
to change the structure and the storage
characteristics of a table online.
• Oracle Services for SAP have recently proposed
solutions for some special cases. Of particular
interest is a strategy that uses Oracle partitio-
ning in order to reduce the amount of reorgani-
zation needed after SAP archiving runs.
Oracle’s online maintenance capabilities improve
data availability, query performance, response
time and disk space utilization, all of which are
important in a mission-critical environment. As
several white papers that are circulating among
Oracle/SAP customers take no notice of these
functionalities and solutions, this article is inten-
ded to provide a detailed overview of the current
options.
REASONS AND NON-REASONS FOR REORGA-
NIZATION
The database administrator will consider reorga-
nization in order to reduce or avoid segment-
level, block-level or row-level fragmentation. The
minimal reorganization goal is to reduce existing
fragmentation as much as possible by creating a
new copy of an object while leaving its storage
characteristics unchanged. This is mostly true for
index rebuilds. The maximum goal is to avoid
future fragmentation by changing the object’s
storage characteristics. This is true for most table
reorganizations.
An important rule is, that the administrator should
aim to reduce fragmentation, because it hurts data-
base server performance, but only in measure as it
hurts database server performance.
Segment-Level Fragmentation
The term “segment-level fragmentation” means
that a data segment (table) or an index segment
(index) consists of too many extents. The obvious
question is: How many are too many?
In Oracle versions before 7.3 the number of
extents that could make up one single segment
was limited. The value depended on the database
block size, so it was not exactly one static limit,
but once the block size was chosen (during data-
base creation), the corresponding limit was effec-
tive. If the limit was reached, one extent more
was too many. In that case the segment had to be
reorganized using export and import in order to
decrease the number of extents and allow for
further growth.
Version 7.3 has removed this limitation. Begin-
ning with Oracle 7.3, it is allowed to specify
MAXEXTENTS=UNLIMITED in the storage
clause of SQL statements that create or modify
segments. Nevertheless, some customers decided
to leave the limit in place. There is nothing wrong
with such a decision as long as customers simply
want an additional control mechanism and are
not affected by the single extent myth.
In a white paper called Myths and Folklore about
Oracle Performance Tuning Gaja Krishna Vaidyanatha
(Quest Software Inc.) calls the opinion that “the
optimum number of extents for every object is
one” the single extent myth. In contrast to this
myth, he correctly states that “having 1,000
extents for an object by itself does not pose any
performance problems, so long as the extents are
sized as a multiple of
(DB_FILE_MULTI-BLOCK_READ_COUNT
* DB_BLOCK_SIZE)” and that “periodic reorga-
ni-zation efforts to get objects back to 1 extent
create significant free space fragmentation pro-
blems” due to the “various extent sizes within a
tablespace”. Considering these points, a reasona-
ble space management strategy would be to defi-
ne very few standard extent sizes (ideally in diffe-
rent tablespaces) and use them according to seg-
ment size and growth.
This is exactly what locally managed tablespaces
offer. Traditional or dictionary managed tablespa-
ces use data dictionary tables to log allocations
and deallocations of extents. Locally managed
tablespaces use bitmaps to keep track of the free
or used status of blocks in Oracle data files. Due
to the simplified internal algorithms, locally
managed tablespaces offer better performance
than dictionary managed tablespaces. In addition,
administrators can choose between two extremely
simple and efficient extent size management stra-
tegies: UNIFORM means that all extents within
one single tablespace are created with the same size,
AUTOALLOCATE means that extent sizes are
determined by the system which chooses between
few standard sizes according to segment size and
growth. There is no maximum number of extents
for locally managed tablespaces.
With the introduction of locally managed table-
spaces, segment-level fragmentation is no issue
anymore. That's why SAP has adopted this tech-
nology and recommends using it for Oracle/SAP
systems (see OSS notes 387946 and 409376).
Block-Level Fragmentation
The term “block-level fragmentation” indicates
that space is wasted within data or index blocks,
because after numerous inserts and deletes unused
space can not (or not efficiently) be reused for new
inserts. The details are different for indexes and
tables:
• If records are deleted from a table, the corre-
sponding index entries are not always deleted as
well. Especially if a delete operation involves
many records (mass deletes), the corresponding
index entries are only marked as deleted (logi-
cally), but do still exist (physically) and consu-
me space that cannot be reused. This behavior
was chosen, because it avoids the overhead of
frequently rebalancing the index tree structure.
However, due to the “islands of wasted space”
the index information is stored inefficiently,
because it is spread across more Oracle blocks
than it should be. This, in turn, leads to addi-
tional I/O requests, increased memory con-
sumption and ultimately to performance degra-
dation. Eventually, the administrator will have
to reorganize the index in order to improve
block density and utilization (see picture 1).
Picture 1:
Block-level
fragmentation in
index segments
• Delete operations from the table itself are
always physical deletes. The space previously
used by the deleted records is freed immediately
and is available for new inserts unless that is
prevented by the storage parameter PCTUSED.
So, strictly speaking, there is no block-level
fragmentation for tables. However, in special
cases it can happen that after several cycles of
insert and delete operations data is stored less
efficiently than in the beginning. This situation
is discussed in more detail in the last section.
The number one reason for block-level fragmen-
tation in Oracle/SAP systems is archiving. How-
ever, this does not mean that each archive run
should be followed by a reorganization of all seg-
ments involved. The following rules should be
considered:
• As archiving is basically a mass delete, it will
inevitably lead to block-level fragmentation
within index segments. So the indexes on the
tables involved in the archive operation should
be analyzed carefully. Reorganization of indexes
with many logically deleted rows is the most
important and most efficient measure to ensure
a good performance of the system after archiving.
Oracle has recognized this and consequently in-
troduced online index reorganization as the first
of all online reorganization functionalities (see
below).
• Table reorganizations should be performed cau-
tiously, they can easily turn out to be unnecessary
as well as detrimental. For normal, periodic archi-
ving runs, as a rule, table reorganization is not
necessary, because the space freed by archiving
will be refilled between this and the next archive
run (see picture 2a). Reorganization that decreases
the number of extents allocated will result in
additional extent allocation operations when the
segment is growing again.
There are only two cases where table reorganiza-
tions should be considered. The very first archive
run probably frees much more space than will be
refilled until the next regular run, so reorganization
could be used to shrink the segments involved (see
picture 2b).
Selective archiving can cause data to be stored less Picture 2b:
efficiently, so reorganization of the affected tables, Effects of first archive
combined with additional measures designed to run on the deallocation
prevent the negative impact of selective archiving and reallocation
in the future, might be useful (see last section of
this article).
Row-Level Fragmentation
“Row-level fragmentation” or “row chaining”
occurs, if a row does not fit completely within one
single Oracle block and two ore more pieces of it
are stored in two ore more blocks. There are two
possible reasons for this behavior:
• The size of the record is such that it could fit
within one single block. If, nevertheless, the
record is split and stored in multiple blocks, it
Picture 2a:
Effects of
regular archiving
on the deallocation
and reallocation
is because of an inappropriate value of the stor-
age parameter PCTFREE. As SAP has provided
appropriate storage parameter configurations,
this is a rather rare problem in Oracle/SAP
systems.
• The size of the record is such that it cannot pos-
sibly fit within one single block. This does not
cause performance problems. Nevertheless,
Oracle9i allows multiple block sizes within one
database. So the administrator can create a
tablespace with blocks bigger than the standard
block size and move tables containing long
records to that tablespace.
ONLINE INDEX REORGANIZATION
As the previous section has shown, the main rea-
son for reorganization in Oracle/SAP systems is
block-level fragmentation in index segments that
occurs after archiving. Accordingly, when Oracle8i
introduced online reorganization, the first step
was support for online index reorganization. This
comes in two flavors: online index rebuild, which
creates a copy of the index to be reorganized, and
online index defragmentation, which is an in-place
5
 reorganization. Both methods improve database
availability by providing users full access to data
in the base table during an index reorganization.
Online Index Rebuild
Online index rebuild creates a copy of the index to
be reorganized. No table or row locks are requi-
red for that operation, so users can continue to
update and query the base table while the index
is being created. If changes to the base table during
the rebuild process require changes to the index
as well, these changes are recorded in a journal
table the contents of which are merged into the
new index at the completion of the operation (see
pictures 3a and 3b).
Picture 3a: Online index rebuild (step 1: index copy, journal table)
Picture 3b: Online index rebuild (step 2: switch to new index)
The operation is initiated via the SQL command
ALTER INDEX <index_name> REBUILD
ONLINE. It can be used to create a new copy
with the same storage characteristics as the old
one, but it also supports modifications like chan-
ges of the extent size or a relocation of the index,
i.e. its move to an other tablespace. These online
operations also support parallel processing and
can act on some or all of the partitions of a parti-
tioned index.
Starting with version 6.10, online index rebuild
can also be initiated using SAPDBA (see pictures
4a and 4b).
The option to modify storage characteristics is the
most important advantage of online index reorgani-
zation over online index fragmentation. The
obvious disadvantage is that more disk space is
6 needed, as the original and the new copy have to be
Picture 4a: Online index rebuild using SAPDBA
Picture 4b: Online index rebuild using SAPDBA
stored on disk as long as the reorganization ope-
ration has not yet completed.
Online Index Defragmentation
Online index defragmentation, or index coalescing,
is similar to the online index rebuild operation.
Both reorganize an index and improve space utiliza-
tion and query performance. The major difference
is that online index defragmentation is an in-place
reorganization and does not require additional
storage space, so it is to be preferred, if storage
space for rebuilding the index is limited.
The operation is initiated via the SQL command
ALTER INDEX <index_name> COALESCE. As
online index rebuild, online index defragmentati-
on supports parallel processing and partitioning.
ONLINE TABLE REORGANIZATION
Oracle supports two basic types of tables. The
“classic” type is called heap-organized (or simply heap)
table. A heap-organized table is just an unordered
set of records. If a search tree for fast access of
individual records is required, the user will have
to create an index in addition to the table. An
index-organized table (IOT) combines table data
and search tree within one single segment. Index-
organized tables were introduced with Oracle8i
(see Oracle for SAP Technology Update, vol. 10,
p. 12).
Although index-organized tables are less com-
mon, they are discussed first, because online table
move and reorganization, a reorganization mecha-
nism for index-organized tables only, is supported
since Oracle8i. Online data redefinition, a reorgani-
zation mechanism for all table types (including
heap-organized tables), was introduced with
Oracle9i. Performing one of these operations en-
sures that users continue to receive both optimal
performance and continuous data availability.
Online Table Move and Coalesce for
IOTs
Oracle8i and Oracle9i allow index-
organized tables (IOTs) to be reorga-
nized while users are accessing and
updating the data in the table. As
IOTs are basically indexes that con-
tain the complete table data, it proba-
bly comes as no surprise that the
administrator can choose between the
two options that are available for
indexes: online table move creates a new
copy of the IOT to be reorganized,
whereas online table coalesce is an in-
place reorganization.
Online table move is initiated via the
SQL command ALTER TABLE
<iot_name> MOVE ON-LINE. It
can be used to create a new copy of
the IOT with or without modification
of the storage characteristics. Changes
to the table during the operation are
recorded in a journal table and mer-
ged with the table at the completion
of the operation.
Online table coalesce is initiated via the
SQL command ALTER TABLE
<iot_name> COALESCE. No ONLI-
NE clause is needed, because the
coalesce operation is an online operation by
default. It locks a few blocks at a time, and quick-
ly frees them as soon as the coalesce on the blocks
is completed. The operation reorganizes the
search tree structure, reduces block-fragmentati-
on and thus frees up space, resulting in improved
storage utilization and query performance.
Both operations can be performed on a complete
IOT or on a single partition in a partitioned IOT.
As enhancements to these Oracle8i features,
Oracle9i added online reorganization support for
IOT secondary indexes (i.e. indexes other than
the primary key index) and additional index
types. Oracle9i added support for reverse key,
functional and key compressed index types.
Online Data Redefinition
From the perspective of this article, what is mis-
sing is an online reorganization mechanism for
heap-organized tables. Online data redefinition
provides this missing mechanism, however it is
much more. As the name suggests, it allows
administrators to redefine the structure and stor-
age characteristics of tables online. This includes:
• converting a non-partitioned table to a parti-
tioned table and vice versa
• switching a heap-organized table to an index-
organized table and vice versa
• dropping non-primary key columns
• adding new columns
• adding or removing parallel support
• modifying storage parameters or moving the
table to a new tablespace.
It is not likely that SAP customers will make use
of all these options. However, it can be seen easily
that online data redefinition is a very powerful
TWO FOR SPEED AND STABILITY

The HP and SAP alliance keeps your business above water -

no matter how far or how fast you are moving.
Over 30.000 joint installations reflect our shared
commitment to customer success.

SAP is the world’s leading provider of e-business software solutions. HP is the leading provider of
comprehensive services and robust infrastructures for one-stop e-business solutions.

www.hp.com/go/sap
 mechanism designed for online maintenance of
all table types and that, for this mechanism, online
reorganization of heap tables is one of the easy
jobs.
Prior to Oracle9i table redefinition was only pos-
sible using (1) export/import, which meant the
table was offline during the process, or (2) the
ALTER TABLE MOVE command which locked
DML during the operation (no ONLINE option
available for heap-organized tables). Neither of
these methods is suitable for large OLTP tables,
as the downtime can be considerable. To solve
this problem, Oracle9i has introduced online table
redefinition using the DBMS_REDEFINITION
package.
The process is similar to online rebuilds of inde-
xes in that the original table is left online while a
new copy of the table is built. The original table
is accessible by all read and write operations
during the redefinition process. The results of
DML operations are stored in a temporary table
for interim updates. Once the new table is com-
plete, the interim updates are merged into it and
the names of the original and the new table are
swapped in the data dictionary. This step requires
a DML lock, however the switch process is very
brief and is independent of the size of the table or
the complexity of the redefinition. Once the
switch is completed, all DML is processed against
the new table.
ADVANTAGES OF PARTITIONING
As already stated in the section on block-level frag-
mentation, no table reorganizations are necessary
after regular, periodic archiving runs, because the
space freed will be refilled afterwards. However,
this statement presupposes that the selection of
the records to be archived is purely time-based
(e.g. all records created within a period of 3 or 6
months). If such a criterion is chosen, it is very
likely that Oracle blocks are freed completely.
When, later on, a new group of related records
(such as several positions of an order) are to be
inserted, they can be inserted together into one
single block (see picture 5a).
Using additional archiving criteria (such as plants
or cost centers) will probably result in a large
number of data blocks only being partially emp-
tied. Groups of new records will then frequently
not fit within one single block, so they need to be
spread across two or more blocks. This is, of cour-
se, not block-level fragmentation in the strict
8 sense; nevertheless, these records are stored ineffi-
ciently, because if later on a user needs to read all
positions of the order, two or more I/O requests
are necessary (instead of one), two ore more blocks
need to be stored in memory (instead of one), and
this will end up in performance degradation (see
picture 5b).
An efficient way to solve this issue can be based
on Oracle partitioning. Partitioning is particu-
larly interesting for tables that have a direct or
indirect time key. Examples are VBRK, VBRP
and VBFA. The indirect time key of these tables
consists of the VBELN field (or fields associated
with it). Since the entries in these fields are incre-
mented sequentially with a sequential time, they
can be used as a range partitioning key.
The idea is to create a separate partition for each
specific realm of VBELN numbers, so each parti-
tion contains exactly one of these realms (e.g. a
month). If, then, an archiving run is performed,
data is deleted from the affected partition(s) only,
whereas all other partitions are not affected at all.
In this case, half-empty blocks are not an issue,
because, due to the partitioning key, no new ins-
erts are directed into that partition. Also, a reor-
ganization of one partition or few partitions is
much easier and faster than a reorganization of a
whole table.
Since partitions are dealt with as independent
storage objects within Oracle, these partitions can
be deleted or merged very simply after the archi-
ving runs. If, in addition, the individual partitions
Picture 5a:
Time-based archiving frees
blocks completely, so a group
of related records later on
can be inserted into one
single block
are created in separate files or tablespaces, the
disk space can be released at file system level as
well.
An initial reorganization (online data redefiniti-
on) is required to convert the non-partitioned
table to a partitioned table. Also, a new partition
needs to be available for each new time period
(e.g. month), because the partitioning key conti-
nually changes. This is not an issue, however,
because a large number of partitions can be created
in advance.
Picture 5b:
Selective archiving
does not free blocks completely,
so a group of related records
later on must be inserted into
several blocks.
9i
Delta Consulting
Delta Consulting is an SAP-focused consultancy
committed to providing innovative yet practical
solutions that combine real-world business ex-
pertise with world-class e-business technologies
designed to extend and enhance the performance
of SAP.
Our consultants average over eight years of SAP-
specific experience that spans all SAP solutions
and business disciplines such as supply chain
optimization, finance and cost accounting, and
merger and acquisition accounting. In addition,
we provide services that address the functional,
technical and infrastructure requirements of an
SAP solution.
Founded in 1998 by a small group of former SAP
executives, Delta draws upon knowledge gained
from involvement in over 200 SAP implementa-
tions. As a National Implementation Partner,
Accelerated SAP Partner and member of the
mySAP marketplace, SAP lies at the core of
Delta’s solutions and services.
As a member of the Oracle PartnerNetwork
(OPN), Delta Consulting is able to deliver Oracle
technology as part of a world-class SAP e-business
solution for its customers in all industries, while
also capitalizing on Oracle’s expanded offerings
in the CPG and financial services industries.
For additional information regarding Delta
Consulting, please visit their website at www.go-
delta.com or contact Jack Tomb, VP of Business
Development at 610-558-1730.
 Oracle Collaboration
Suite
Communication, content management, and colla-
boration – via email, voicemail, file sharing, and
Web conferencing – have become critical to every
organization. Unfortunately, technology has not
kept up with needs. More and more customers are
suffering from poor reliability and security, unm-
anageable information storage, inadequate inte-
gration of voice and data systems, and skyrocketing
costs.
Oracle Collaboration Suite, Release Two, addresses
these issues with an Internet architecture that
tightly integrates communications and informa-
tion, and incorporates intelligence to deliver the
right information when and where it’s needed, via
email, voicemail, calendaring, file sharing, search,
and wireless access. In addition, Release Two fea-
tures real-time communication including Web
conferencing, white boarding, and instant messa-
ging all built on a single scalable collaboration
platform for Web conferencing, as well as improved
group productivity, new messaging capabilities,
and further reduction of total cost of ownership.
Add in the Unbreakable Oracle9i infrastructure,
and Oracle Collaboration Suite Release Two is
uniquely positioned to meet the communication
and collaboration requirements of modern enter-
prises.
Oracle Collaboration Suite includes several well-
established and successful Oracle technologies,
each addressing a different aspect of communica-
tions, content, or context. In fact, Oracle Colla-
boration Suite consists of the next generation of
technologies that Oracle Corporation itself uses
for its own business. More importantly, however,
customers are already using these solutions success-
fully today.
Email
Oracle Email is the most cost effective, reliable
and secure messaging system in the marketplace.
Save on administration, hardware and software by
consolidating distributed email systems into a
single enterprise mail store. At the same time,
enjoy reliable messaging that withstands machi-
ne and site failures. Use any desktop client to
access the industry standard mail servers.
Take advantage of superior virus protection and
eradication capabilities. Access all your messages
anytime, anywhere using any device.
Voicemail & Fax Wireless and Voice Access
Oracle Voicemail provides true unified messaging Oracle Collaboration Suite gives your mobile
by storing all messages – including email, voice- employees full access to all of their corporate
mail, and fax – in the same Oracle database. This
eliminates the need to synchronize message stores
and the chore of administering multiple stores
information anywhere, from any device. Its com-
plete set of capabilities lets users access email,
calendar, tasks, files, and corporate directories via
that each contain different message types. Oracle their voice, PDAs, Web-enabled mobile phones,
Collaboration Suite users can access and manage and pagers. Oracle Collaboration Suite will alert
all messages from the interface of their choice, your employees of important events and emails. It
including a Web browser, phone, PDA, and fax. lets you define where you are right now (in other
words, your context), so that alerts get routed to
Meeting your desktop, mobile phone, or other device.
With the addition of the new Oracle iMeeting
Oracle Collaboration Suite is built on one infra-
technology in Release Two, online collaboration
structure, managed by the same tools, and fully
activities such as co-browsing, Web conferences,
integrated. Oracle Collaboration Suite gives your
voice streaming, meeting playback and even
enterprise a way out of the cycle of data fragmen-
casual communications such as instant messaging,
tation and systems integration.
can be consolidated and centralized. The iMeeting
functionality in Oracle Collaboration Suite acts as
For more information please see
a foundation for integrating enterprise content,
http://www.oracle.com/collaboration
commerce and comprehensive business flows and
allows users to capture and act on information
before, during and after online meetings.
Calendar
Oracle Calendar provides calendaring, scheduling
and personal information management (PIM)
capabilities through desktop clients, the Web and
any mobile device. The scalable calendar architec-
ture allows companies to utilize sophisticated
group calendars and resource scheduling across an
entire enterprise.
Files
Oracle Files can replace dozens or hundreds of file
servers in an enterprise with one scalable, reliable
file server for everyone to use. Built for large-scale
collaboration, Oracle Files makes your file system
more manageable for both your data center and
your users. Users also know exactly where they
should be storing, sharing, and collaborating on
documents. Self-service management features let
users create workspaces to secure, author, and
publish content among them, and they can use all
their favorite productivity tools and network
protocol servers.
Search
Oracle Ultra Search provides an enterprise Web
search engine that empowers employees to locate
valuable information in your organization’s intranet
or extranet. Oracle Ultra Search gathers and indexes
all documents including Web sites, databases,
files, mailing lists, portals and a variety of user
defined sources including applications. 9
 Oracle Internet Directory 9.2. for SAP
SAP announces the certification of Oracle Internet Directory 9.2 (OID) as a component of a
security solution within the mySAP technology interface (directory interface for user mana-
gement via LDAP).
The support of the Lightweight Directory Access Protocol (LDAP) enables SAP to use exter-
nal directories to centrally administer the data of several SAP or third party systems. These
central directories can contain informa-
tion such as user data, security details,
details for system resources and confi-
guration parameters.
With this certification, enquiries
such as “Can OID be used with SAP”
or “Does OID support SAP” can be
answered positively. What is im-
portant is that the integration of
OID and SAP AS 6.1 is an SAP and
not an ORACLE functionality.
Apart from the integration of MS
Active Directory mysap repre-
sents another widespread plat-
form that works together with
OID.

10

Diagnosing Performance Bottlenecks
Statspack
Using Statspack
Introducing Statspack
Statspack is a performance data gathering tool
which first shipped with Oracle8i release 8.1.6.
Statspack gathers data from the memory-resident
v$ views, and stores that data in Oracle tables for
later analysis. Although similar to its predecessor
(BSTAT/ESTAT), Statspack simplifies performance
diagnosis by presenting the performance data in a
manner which is effective for pinpointing bott-
lenecks.
THE IMPORTANCE OF BASELINES AND
STATISTICS
One of the biggest challenges for performance
engineers is determining what changed in the
system to cause a satisfactory application to start
having performance problems. The list of possibi-
lities in a modern complex system is extensive.
Historical performance data is crucial in elimina-
ting as many variables as possible. This means
that you should collect operating system, database,
and application statistics starting from the
system’s testing phase onwards, or at least from
the first day an application is rolled out into pro-
duction. This applies even if the performance is
unsatisfactory. As the application stabilises and the
performance characteristics are better understood,
a set of statistics become the baseline for future
reference. These statistics can be used to correlate
against a day when performance is not satisfactory,
and can assist in quantifying subsequent impro-
vements made. They are also essential for future
capacity and growth planning.
Oracle statistics are queried from the v$ views
using a snapshot method such as Statspack.
Statistics which should be gathered include:
• Wait events
• SQL statistics and SQL Plans
• Overall systems statistics (shared pool, buffer
cache, resource such as latches, locks, file IO)
Using Statspack to Identify Bottlenecks
Statspack provides a simple way of collecting
Oracle performance data and identifying bottle-
necks. The reports pre-compute many useful
statistics, and eliminate misleading statistics.
There are two Statspack reports.
The first, spreport.sql, is an overall instance per-
formance report. The first page of this report con-
tains an instance performance summary, which
concentrates a complete view of instance health.
Subsequent pages include sections which report
detailed statistics on the various tuning areas.
The instance performance report is used when
investigating an instance-wide performance pro-
blem.
The instance performance summary page always
indicates the biggest bottleneck to investigate,
and hence the place to start when examining
Oracle performance data. The summary page is
broken down into these areas (in order of impor-
tance):
• Top 5 Wait Events
• Load Profile
• Instance Efficiency
The remaining sections of the Statspack instance
report are used to gather additional data. The
high-load SQL sections are always scanned irre-
spective of the problem, as they provide insight
into the SQL executing at the time the problem
occurred, and the application in general.
If a level 5 or above snapshot is taken, the SQL
report (sprepsql.sql) which is new in Oracle9i,
provides in-depth information for a single SQL
statement. The SQL report includes all of the SQL
statistics for a particular hash value, the complete
text of the SQL statement. Additionally, if a level 6
snapshot or above was taken the SQL execution
plans are also included. This report is frequently
used to tune problems identified as local to a spe-
cific program.
This remainder of this paper focuses on how to
use the instance report (spreport.sql).
Statspack Strategy
• Use the Top 5 Wait Events on page 1 to identify
the events with most wait time by percentage1.
These events are preventing the majority of
server processes from being productive, and so
are likely2 the bottleneck. Check whether the
top events are related. Are the events consi-
stent with any OS statistics?
There may be one event which greatly
outranks the others, in which case this should
be considered the bottleneck: focus on this
event. Alternatively, there may be a set of rela-
ted events which again indicate one primary
area of contention. A third possibility is there
is a set of disjointed events which may rank
closely for the greatest wait time. In this case,
you may want to look at each one in turn.
Ignore events in the Top 5 listing which do not
comprise a significant portion of the wait time.
• Considerations while gathering additional data.
The purpose of gathering additional data is to
help build up an understanding of the charac-
teristics of the instance and to identify the
application code executing, at the time the
problem occurred. Gathering additional data
usually requires skipping backwards and for-
wards through the report to check statistics
which may be of interest. You can gather some
additional data up-front, and while drilling
down. The data gathered may portray a consis-
tent picture of one bottleneck, or a series of
bottlenecks. You will find interesting data along
the way which may not be related to the primary
bottleneck; in this case, note the data, but
ignore it, as it will not help in significantly
reducing response time.
• Begin gathering additional data. Look at:
• the Wait Events and Background Wait Events
sections for the average wait time for the high-
est ranking events (this column is identified
by the heading Ave wait(ms)). This data can
sometimes provide insight into the scale of
the wait. If it is relevant to do so, also cross-
check the event times with any other appli-
cable Statspack or OS data. For example, if
the events are IO related, is the Oracle data
consistent with the OS read times, or does
the OS data indicate the disks containing the
datafiles are overly busy?
• the Load Profile and Instance Efficiency sections
on page 1, specifically at any statistics or
ratios which are related to the top wait
events. Is there a single consistent picture?
If not, note other potential issues to investi-
gate while looking at the top events, but
don’t be redirected away from the top wait
events. Scan the other statistics. Are there
any statistics in the Load Profile which are
unusually high for this site, or any ratios in
the Instance Efficiency section which are atypi-
cal for this site?
• Drill-down for additional data to the appro-
priate section in the Statspack report.
The relevant sections to examine are indicated
by the top wait event. For example, if the top
events are IO related, look at the SQL ordered by
Reads, and the Tablespace IO Stats, and File IO
Stats sections. Is the data in these sections con-
sistent with the wait events? What other infor-
mation does the drill-down data provide (que-
stions to ask include: Are the number of times
a resource was used high or low? Are there any
related resources which when pieced together
form a pattern?)
• Also note that it is vital to examine the SQL
sections of the Statspack report, to identify
what the application was requesting of the
instance which caused this performance regres-
sion. The SQL sections also sometimes identify
tunable high-load SQL, or SQL statements
which are avoidable.
• Significantly less important to scan through
are the Library Cache Activity and Dictionary
Cache Stats sections, although they may provi-
de some insight.
• In some situations, there may not be sufficient
data within the Statspack report, which will
necessitate gathering additional statistics
manually.
1 Idle events are omitted from this list. Also, if timed_statistics
is true, the events are ordered by the amount of time each event
was waited for; this ordering gives the best indication of where
most of the time was lost, and therefore where the biggest bene-
fits can be gained. If timed_statistics is false, the order is by the
number of waits. Oracle recommends setting timed_statistics
to true for best performance diagnosis.
2 Note that in a healthy, well performing system, the top wait
events are usually IO related. This is an example of a case where
the statistics alone do not accurately indicate whether there is a
problem, which is why the most important indicator of perfor-
mance is user perception. 11
 By this stage, candidate problems, and conten-
ded-for resources have been identified (with the
highest priority issues dictated by the top-5 wait
events). This is when the data should be analyzed.
Consider whether there is sufficient data to build
a sound theory for the cause and resolution of the
problem.
Use the Oracle9i Performance Guide and Reference
as a resource to assist identifying the cause, and
the resolution of the contention. The manual
includes detailed descriptions of how to:
• diagnose causes and solutions of Wait Events
• optimally configure and use Oracle to avoid the
problems discovered
Even while following the strategy outlined above
to analyze the problem, it is still possible to fall
into the traps outlined in Performance Tuning
Wisdom.
Performance Tuning Wisdom
Below are a list of traps, and some wisdom which
may help you find a faster, or more accurate dia-
gnosis.

EXAMPLE OF USING STATSPACK REPORT

The following example comes from a scalability benchmark for a new OLTP application. Excerpts of the Statspack report have been included, rather than
the complete report. The requirement was to identify how the application could be modified to better support a greater concurrent user load. The instance
was running Oracle8i release 8.1.7, and the Statspack snapshot duration was 50 minutes.
The intent of using a specific Statspack report is not to identify how to fix these specific problems, rather to provide an example of the technique described above.
DENTIFY THE LARGEST WAIT EVENTS, BY TIME STARTING IN THE TOP-5 Observations:
In this case, the most significant wait events are
Top 5 Wait Events distributed over enqueue, latch free, and buffer busy
~~~~~~~~~~~~~~~~~ Wait % Total waits, with enqueue being the most prominent.
Event Waits Time (cs) Wt Time There is no obvious correlation between these
-------------------------- ---------- ------------- -------------- events, which implies there are probably three
enqueue 482,210 1,333,260 36.53 separate problems to investigate.
latch free 1,000,676 985,646 27.01 The most important wait event to investigate is
buffer busy waits 736,524 745,857 20.44 enqueue.
log file sync 849,791 418,009 11.45 • Problem 1: enqueue: Drill down to the En-
log file parallel write 533,563 132,524 3.63
queue activity data.
Although the only focus should be on the primary bottleneck, it is sometimes necessary to investigate the next most important issues, while the solution for the
first bottleneck is being addressed. These are:
• Problem 2: latch free: Which latch? Why used? Check the Latch Activity and Latch Misses sections
• Problem 3: buffer busy waits: Which files and buffers? Why? Check the Buffer Waits section and the Tablespace IO and File IO sections
Before jumping to the drill-down sections, gather additional background data which will provide context for the problem, and details on the application.

Additional Information - Wait Events Detail Pages

Check the Wait Events and Background Wait Events detail sections for the average time waited (Avg wait (ms))for the top events. Identify the magnitude of
the wait, and if possible, compare Oracle statistics to any relevant OS data (e.g. check whether the average read time for the event db file sequential read,
and the OS read time for the disk containing that datafile are consistent, and as expected).
Avg
Total Wait wait Waits
Event Waits Timeouts Time (cs) (ms) /txn
------------------------------------------ ----------- -------------- ---------- --------
enqueue 482,210 50 1,333,260 28 0.8
latch free 1,000,676 751,197 985,646 10 1.6
buffer busy waits 736,524 3,545 745,857 10 1.2
log file sync 849,791 13 418,009 5 1.4
log file parallel write 533,563 0 132,524 2 0.9
SQL*Net break/reset to clien 535,407 0 20,415 0 0.9
db file sequential read 22,125 0 6,330 3 0.0
...
Observations:
• None of the wait times are unusual, and there are currently no relevant Oracle or OS statistics to compare against.

Additional Information - Load Profile

Examine other statistics on the summary page, beginning with the load profile.
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 1,316,849.03 6,469.71
Logical reads: 16,868.21 82.87
Block changes: 5,961.36 29.29
Physical reads: 7.51 0.04
Physical writes: 1,044.74 5.13
User calls: 8,432.99 41.43
Parses: 1,952.99 9.60
Hard parses: 0.01 0.00
Sorts: 1.44 0.01
Logons: 0.05 0.00
Executes: 1,954.97 9.60
Transactions: 203.54
12 % Blocks changed per Read: 35.34 Recursive Call %: 25.90
Rollback per transaction %: 9.55 Rows per Sort: 137.38
Observations:
• This system is generating a lot of redo (1mb/s), with 35% of all blocks read being updated.
• Comparing the number of Physical reads per second to the number of Physical writes per second shows the physical read to physical write ratio is very low (1:49).
Typical OLTP systems have a read-to-write ratio of 10:1 or 5:1 – this ratio (at 1:49) is quite unusual.
• This system is quite busy, with 8,432 User calls per second.
• The total parse rate (Parses per second) seems to be high, with the Hard parse rate very low, which implies the majority of the parses are soft parses.
The high parse rate may tie in with the latch free event, if the latch contended for is the library cache latch, however no assumptions should be made.

Additional Information – Instance Efficiency

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 98.56 Redo NoWait %: 100.00
Buffer Hit %: 99.96 In-memory Sort %: 99.84
Library Hit %: 99.99 Soft Parse %: 100.00
Execute to Parse %: 0.10 Latch Hit %: 99.37
Parse CPU to Parse Elapsd %: 58.19 % Non-Parse CPU: 99.84

Shared Pool Statistics Begin End

------ ------
Memory Usage %: 28.80 29.04
% SQL with executions>1: 75.91 76.03
% Memory for SQL w/exec>1: 83.65 84.09

...

Observations:
• The 100% soft parse1 ratio indicates the system is not hard-parsing. However the system is soft parsing a lot, rather than only re-binding and re-
executing the same cursors, as the Execute to Parse % is very low. Also, the CPU time used for parsing is only 58% of the total elapsed parse time
(see Parse CPU to Parse Elapsd). This may also imply some resource contention during parsing (possibly related to the latch free event?).
• There seems to be a lot of unused memory in the shared pool (only 29% is used). If there is insufficient memory allocated to other areas of the database
(or OS), this memory could be redeployed.

Additional Information – SQL Sections

It is always a good idea to glance through the SQL sections of the Statspack report. This often provides insight into the bottleneck at hand, and may also
yield other (less urgent) tuning opportunities.

SQL ordered by Gets for DB: XXX Instance: XXX Snaps: 46 -48
-> End Buffer Gets Threshold: 10000

Buffer Gets Executions Gets per Exec % Total Hash Value

--------------- ------------ ---------------- --------- ---------------
8,367,163 766,718 10.9 16.4 38491801
INSERT INTO EMPLOYEES VALUES(:1,:2,:3,:4,:5,:6)

3,695,306 798,317 4.6 7.2 1836999810

SELECT DEPARTMENT FROM PAYROLL WHERE COST_CENTER = :"SYS_B_00"
AND FNO = :"SYS_B_01" AND ORG_ID != :"SYS_B_02"

...

2,951,100 65,580 45.0 5.8 2714675196

select file#, block# from fet$ where ts#=:1 and file#=:2

Observations:

• The majority of the SQL statements were well tuned, and do not require many logical or physical reads.
• Most of the activity was INSERT or SELECT, with significantly fewer updates.
• The modification of fet$ (this is the data dictionary Free ExTent table) implies there is dynamic space allocation. This has been executed 65,000 times
during the report interval of 50.48 minutes, which is on average, 21 times per second! This can easily be avoided, by using locally managed tablespaces.

3
For definitions of hard parse, and soft parse, please see the Oracle9i Performance Guide and Reference.

13
 SQL ordered by Executions for DB: XXX Instance: XXX Snaps: 46 -48
-> End Executions Threshold: 100

Executions Rows Processed Rows per Exec Hash Value

------------ ---------------- ---------------- ------------
766,718 536,313 0.7 38491801
INSERT INTO EMPLOYEES VALUES(:1,:2,:3,:4,:5,:6)

275,327 275,305 1.0 3906762535

SELECT MANAG_MRD_ID_SEQ.NextVal FROM dual

275,327 275,305 1.0 341630813

INSERT INTO MANAG_MRD_IDENTITY VALUES(:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:1
1,:12,:13,:14,:15,:16,:17,:18,:19,:20,:21,:22,:23,:24,:25,:26,:2
7,:28,:29,:30)

258,595 258,566 1.0 3303454348

SELECT PROD_ID_SEQ.NextVal FROM dual

258,595 258,561 1.0 4222973129

INSERT INTO PROD_IDENTITY VALUES ( :1,:2,:3,:4,:5,:6,:7,:8,:9,:10,
:11,:12,:13,:14,:15,:16,:17,:18,:19,:20 )

914 914 1.0 1425443843

update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,
order$=:6,cache=:7,highwater=:8,audit$=:9 where obj#=:1

Observations:
• There was nothing of any interest in SQL ordered by reads section, which implies the application is well tuned to avoid unnecessary IO.
• A significant proportion (30%) of the INSERTs into the EMPLOYEES table in failing, which is evident by comparing the number of Rows Processed to
the Executions.
• Many of the INSERTs are executed the same number of times as the SELECT from a similarly named sequence number. This implies the sequence number
is used as a column value in the insert. Possibly a key value?
• The update of seq$ (this is the SEQuence number data dictionary table) is performed 18 times per minute, which is once every 3 seconds. Unless this
data coincides with the SQ (SeQuence number) enqueue being contended for, this is not the largest bottleneck. However, for additional efficiency it may
be useful to increase the cache size for frequently modified sequence numbers.

SAP on Oracle at Kodak with over 30 Oracle databases in conjunction with

Pressing the “famous
button”
“You press the button, we do the rest”. With this
slogan, George Eastman made picture taking
popular for hundreds of thousands of amateurs
and professionals around the globe. Eastman reco-
gnized the potential of the world market for ama-
teur photographers. The genius of his invention
was that it took a complicated and cumbersome
process and made it easy to use and accessible to
nearly everyone.
By 1900, distribution outlets had been established
in England, France, Germany, Italy and other
countries outside the U.S. Today, Kodak products
and services are marketed by subsidiary companies
to people in more than 150 countries.
Being part of the digital age
The combination of traditional photography with
digital technology is the major step to produce
systems that bring levels of utility and fun to the
taking and utilization of images.
Therefore Kodak manages an IT infrastructure
14
the SAP applications and hundreds of non-SAP
The key to solving business problems
“Kodak’s global business relies upon the availabi-
Oracle databases. It was Kodak’s experiences with
the safe, reliable and scalable Oracle corporate data-
lity of the central SAP environment. Oracle’s
availability and reliability has been key in mee-
base standard that lead Kodak to select the Oracle
database under SAP.
ting our business and technical objectives”, says
Karen Schuh, IT architect in Kodak’s Architecture
The company’s ERP efforts and SAP implemen- Strategy and Planning group.
tation activities were launched in 1996 and the
initial go live took place in September 1997. Oracle’s hot standby capability has been the key
to solving business problems at Kodak. Initially,
The system supports 10000 named users and 2200
concurrent users at a time. Actually Oracle 8.1.7 hot standby was used as the cornerstone of a disaster
recovery implementation to meet the business
is in use, anticipating an Oracle 9.2 upgrade as
soon as SAP completes the certification process. needs for less than 8-hour availability in the event
of a declared disaster. Over time, hot standby was
The overall size of the SAP R/3 Oracle Database
is around 2 terabytes with additional 700 giga- extended to include graceful failover and this
capability was used to support a move of Kodak’s
bytes for the production SAP BW database.
production data center and to facilitate major
SAP R/3 3.1I is in use and will be upgraded to changes to the storage architecture.
R/3E. Further upgrades are planed for SAP BW
from 2.1c to 3.0b and SAP B2B from 3.0 to 3.1. Hardware Platforms
Each flavor of SAP (OLTP, BW, HR, CRM, B2B)
consists of multiple environments. Database E10K 64x400 MHz CPU
Two servers in a high availability cluster
All UNIX servers used in this environment are
Central Instance E4500 8x400 MHz CPU
Sun Solaris systems. The Oracle Business Ware-
Two servers in a high availability cluster
house (BW) Database and central instances are
installed on an E6500 system with ten 400 MHz Application Mix of E3000, E3500, and V880
CPUs, where two servers represent a high availa-
bility cluster. Another two systems E3500 operate The entire configuration except of high availability is duplicated
at the disaster recovery site.
as Application Servers.
 Oracle and Fujitsu Siemens A unique
combination of state-of-the-art technologies
Oracle and Fujitsu Siemens Computers evalua-
te the use of Oracle9i RAC in cooperation with
FlexFrame for mysap
Operation of complex mysap landscapes becomes
possible on a simple, clear and flexible IT infra-
structure with FlexFrame for mysap – including
significant TCO savings. This innovative deve-
lopment by SAP, Network Appliance and Fujitsu
Siemens Computers revolutionizes the introduc-
tion and operation of complex mySAP environ-
ments.
What is behind FlexFrame for mysap?
It is the combination of several coordinated inno-
vative components which makes this new solution
so special. These include for example, standardized
server modules, blade servers, the virtualization
of the SAP software, snapshot functions of the
NetApp filer and the built-in configuration-free
high availability. All this guarantees rapid scaling
and expansion whilst in operation and service
availability 24/7. In addition there are the functions
contained in the control nodes for back-up, cluste-
ring, monitoring, and remote access for the entire
mysap landscape.
A combination of Oracle9i RAC and FlexFrame
enables further significant benefits:
• Maximum availability of the SAP systems
• Increased flexibility for operation and expan-
sion
• Simplification of administration, in particular
in the back-up/restore area
Therefore Oracle and Fujitsu Siemens Computers
have started a joint evaluation project to test and
optimize the cooperation of blade servers, Oracle9i
RAC and @Network @Appliance filers within the
framework of FlexFrame for mysap. Oracle9i RAC
enables the operation of several parallel database
nodes to enhance availability and performance.
The MCOD concept (Multiple Components in One
Database), also in combination with OLTP and
OLAP (e.g. R/3 and Business Warehouse), can only
be fully used with Oracle9i RAC. In particular,
the dynamic use of servers as DB or APP servers
as required can be enabled by using FlexFrame for
mysap in order to efficiently employ available IT
resources.
FlexFrame is particularly interesting for cost-con-
scious customers whose requirements are fre-
quently and rapidly changing in their existing
mysap environment. This new offer is also ideal
for consolidation projects and customers who
would like to change from R/3 to mysap. The
aims of FlexFrame are clearly defined: businesses
can achieve flexible and uninterrupted operation
and “SAP software services on demand” with this
new business-critical computing solution. Major
advantages are maximum security, scalability,
high availability and central control and monito-
ring of the system. Significant benefits can be
achieved through Oracle9i RAC in cooperation
with FlexFrame for mysap.
For more information contact
Fujitsu Siemens Computers GmbH
Email: ccsap@fujitsu-siemens.com
Phone: +49 (0) 6227 73 1800
Fax: +49 (0) 6227 73 1801
http: www.fujitsu-siemens.com/sap
Oracle9i Release2 for
Intel Itanium2 Systems
9i
The Itanium 2 processor is the second generation
of a 64-bit processor by Intel. The 64-bit processor
architecture is ideal for running Oracle9i data-
bases and mysap business applications. These areas
require as much information as possible to be
administered in a computer’s RAM. The more
data that can be held in the RAM, the higher the
throughput of transactions in a SAP system with
the Oracle9i database. The Itanium 2 processor’s
64-bit architecture allows an unlimited amount
of data from mysap applications and Oracle9i
databases to be administered in the main memory.
To date the 32-bit architecture was only able to
hold up to 4 gigabytes in the RAM.
According to IDC the only growing operating systems are Linux and
Windows holding a market share of about 70% in the enterprise than.
The trend is clearly moving to standard based infrastructures, where
Intel provides the building blocks.
The Itanium2 architecture scaling well over 8, 16, 32, and more pro-
cessors provides world class performance in recent TPC-C and SAP-SD
benchmark for non clustered 4 way machines using Oracle databases, by
far outperforming competitive hardware architectures with over 80000
tpm/c’s and costs under 5$/tpm-c.
Server consolidation doesn’t necessarily mean big boxes. With Intel’s
32bit environment in combination with Oracle9i RAC, enterprises
can consolidate their IT infrastructure and adapt the hardware as needed.
Most of the benefits of server consolidation are achieved through
centralization and data consolidation, meaning storing data at a central
place. Oracle9i RAC on Linux Xeon MP Servers are a very good archi-
tectural concept to achieve this.
Werner Schueler, Alliance Manager Intel Europe
Oracle was quick to realize the advantages of 64-
bit architectures and correspondingly optimized
its database architecture for 64-bit systems.
Oracle9i Release 2 is now available on all 64-bit
platforms of the various manufacturers.
It comes as no surprise that the first 64-bit version
of SAP R/3 in 1999 was realized with an Oracle
database. Oracle’s technological lead in the 64-bit
technology is now being continued by providing
Oracle9i for Linux64, HP-UX and Windows .NET
Server on Intel Itanium 2 hardware.
The close cooperation between SAP and Oracle’s
development departments allows SAP applications
with Oracle9i to be tested on Itanium 2 systems
at a very early stage. To date successful tests have
been conducted for SAP R/3 4.6C with Oracle9i
Release 2 on Itanium 2 systems under the opera-
ting systems Linux64, Windows .NET Server and
HP-UX.
According to current planning, mysap products
with Oracle9i Release 2 on Linux64, HP-UX,
Windows .NET Server for Intel Itanium 2 systems
will be available summer 2003.
15

IT– Energy
for Halliburton
Managing Massive Volumes in SAP
Founded in 1919, Halliburton is one of the world’s
largest providers of products and services to the
petroleum and energy industries. Halliburton
employs 85,000 people in more than 100 countries
working in two major operating groups. Halli-
burton’s energy services group (ESG) offers a broad
array of products and services to the upstream oil
and gas industry while the KBR group provides
engineering and construction services to the
downstream energy industry.
In 1996, Halliburton initiated a global ERP im-
plementation project. Aiming at resolving Y2K
system issues and standardizing business processes
across the organization, Halliburton selected SAP
as its ERP system.
During 1998 and 1999 Halliburton rolled out
the complete suite of SAP R/3 modules and new
streamlined business processes to its Energy
Services Group (ESG) and to a subset of the KBR
engineering and construction group. The SAP
system and the new business processes were sta-
bilized during the next two years and in Novem-
ber 2001 the system was upgraded to SAP 4.6c.
In 2002 SAP was implemented to several addi-
tional business units that had been acquired while
the initial deployment was underway. At the same
time Halliburton initiated an Enterprise Buyer
Professional (EBP) e-procurement pilot to further
streamline its purchasing processes.
The SAP Operating Environment
The resulting system is one of the largest SAP
deployments in the world operating on a single
Oracle database. Halliburton has approximately
14,500 SAP users worldwide, and that number is
expected to reach about 17,000 during the first
quarter of 2003.
On average, Halliburton’s SAP system handles
70,000,000 transactions per month; 120,000
background jobs per month; and 3 to 3.5 million
dialog steps per day. These numbers continue to
increase as the business continues to grow. To
meet the high volume database performance
requirements of their SAP environment, Halli-
burton chose Oracle as their database provider.
“At the time Halliburton chose Oracle as our
database, it was the only safe choice on the
market to meet our requirements,” said Mike
Perroni, director of Halliburton’s ERP Center of
Expertise. “Six years later, we still see it as being
the only safe choice for our large environ-
ment.”
A 3 terabyte Oracle database supports the primary
production instance of SAP R/3. The production
database, which is growing at a rate of 60 GB per
month, is expected to reach well over 4 terabytes in
size by the end of 2003. Halliburton also utilizes
16
Oracle to support a 350 gigabyte implementation
of SAP’s Business Information Warehouse (BW)
module. In addition to the R/3 and BW produc-
tion instances there is also a read-only reporting
instance of R/3 – a nightly copy of the production
database – and a number of other test and deve-
lopment instances used to support the production
environment.
Despite the incredible demands placed on its
capabilities, SAP system performance is measured
at just above a half second internal response time
on average, with peaks during the monthly close
at less than one second internal response time. Mike Perroni, Director of Halliburton’s ERP Center
The Oracle database technology is integral to of Expertise.
ensuring this level of performance.
“We are excited about Oracle’s new technolo-
The Future of Halliburton, SAP, and Oracle gies such as RAC which we believe can lower
Challenges facing Halliburton in the future in- our total cost of ownership while meeting our
clude further simplifying business processes,
improving efficiencies, and lowering costs. The growing demands”.
company has started to introduce some of the
mySAP components to meet these additional
business challenges, but naturally, this is making
the system landscape even more complex.
To buffer this complexity and reduce operating
costs, Halliburton is investigating Oracle’s RAC
technology for potential use in its SAP R/3 and
data warehouse environments. RAC could be used
as a means to lower cost while improving avail-
ability of these environments.
Additionally, using Oracle’s database replication
features to replace EMC’s SRDF data replication
facility could offer better partitioning for segment-
ing transactions in Oracle’s data warehouse envi-
ronment.
3 Terabyte SAP Oracle Database
14,500 SAP Users Growing to 17,000
3 – 3.5 Million SAP Dialog Steps per Day
70,000,000 SAP Transactions per Month
120,000 Background Jobs per Month
2 HP Data Center Locations
in Toronto, Canada (24x7)
30 Sun Unix Servers (294 CPUs)
including 2 SunFire 15k servers
14 NT Servers
63 Terabytes (4 EMC Symmetrix Frames)
4.5 Terabytes Sun Storage
The SAP Operating Environment
 The SAP Special Interest Group (SIG) at IOUG
AG and Oracle. The benefits of SAP SIG mem- For more information please contact

I UG
INTERNATIONAL ORACLE USERS GROUP – AMERICAS
bership include providing profile and survey
information, offering open forums for discussion
and providing networking opportunities among
members.
Thomas Stickler
e-mail: thomas.stickler@oracle.com
Fax: 610-408 4815 (USA)

The IOUG sponsors Special Interest Groups (SIGs) Membership

designed to assist members with specific Oracle
products and products that are tightly integrated
with the Oracle products they use. The goal of
the IOUG SIGs is to offer technical information
and peer-to-peer collaboration in order to facilitate
the effective implementation of products. This is
achieved with technical resources, tips, links, and
list serves.
Membership in the SAP SIG comes with your
IOUG membership.
SAP SIG Events
The main events for the SAP SIG are held at the
yearly IOUG conference. Each year there is a
business meeting and information exchange, a

The SAP SIG specifically provides a forum of
open discussion and education on Oracle related
issues associated with SAP running on an Oracle
database. During the 1998 IOUG conference a
group of about 40 attendees started as a roundta-
ble to surface issues and solutions to common
problems. The group has grown every year since
and officially became an IOUG SIG in 1999.
IOUG SAP SIG Mission
The mission of the SAP SIG is to provide a forum
for open discussion, education and networking to
meet the challenges of implementing, and main-
taining Oracle SAP R/3 environments. In additi-
on, the SAP SIG facilitates raising issues and
providing enhancement suggestions to both SAP
IOUG
SAP SIG survey and report of the previous year's
survey, a vendor forum panel discussion with re-
presentatives from both SAP and Oracle, lunch
time opportunities for informal discussion, and
formal technical sessions on various SAP/Oracle
issues.
The SAP SIG also sponsors quarterly technology
forums. The forums are one hour dial-in calls and
each forum focuses on a specific topic of interest
to the SIG. Developers from both SAP and Oracle
participate with product updates and are avai-
lable to answer questions.
Web Site
The SAP SIG web site can be accessed from
the IOUG web site: www.ioug.org.

I UG
INTERNATIONAL ORACLE USERS GROUP – AMERICAS
Position: DBA Manager Developer Basis
Other ________________________________
Database: Oracle Other _______________________
R/3 Version: –––––––––––
SURVEY 2003
Please complete a copy of the survey and send via fax to the attention of Thomas Stickler: 610-408 4815 (USA)
You can also complete this Survey on-line by visiting our website: www.ioug.org and go to the SAP SIG page.

This is the fourth iteration of our survey on issues that surround Oracle and
SAP installations. Using the 5 point scale provided, please rate each item on the
following list with respect to its overall importance within your organization.
Use the numbers between 1 and 5 as many times as you like. The anchors for
the scale appear below. The results will be made available to the membership
of the IOUG Oracle on SAP Special Interest Group.
(1= not important at all; 2 = slightly important, 3 = moderately important,
4 = very important, 5 = extremely important)
Importance Issue
____ Impact on ERP/DB as Internet solutions proliferate in the business
environment
____ Deciding on a data warehousing strategy and making it work
____ Planning and predicting growth of the database to assure no down time
____ Identifying performance bottlenecks in the database
____ Backing up the system off line in a 24-7 environment
____ Retaining trained staff over time
____ Restructuring the tablespaces when transporting tablespaces between
instances
____ Providing the ERP/DB infrastructure to support Enterprise Application
Integration (EAI)
____ Tuning the SAP database: can’t use regular Oracle methods
____ Really understanding how Oracle and SAP work together
____ Gathering and using Oracle metrics to analyze capacity and troubleshoot
problems
____ Tuning ABAP SQL
____ Cross-training staff so all skills have a back-up person
____ Archiving to and/or interfacing with data warehouses
____ Developing a strategy to handle database re-organizations
____ Integration of Oracle Enterprise Manager with SAPDBA and other SAP utilities
____ Integration tools which assist getting SAP data into Oracle data warehouses
What other issues or challenges (that are not on this list) do you face in using SAP
in an Oracle Database environment?
Of all the issues presented here, which would IOUG-SAP Special Interest Group be able
to help most?
Please complete the survey and send via fax to Thomas Stickler: 610-408 4815
You can also complete this Survey on-line by visiting our website: www.ioug.org
17
and go to the SAP SIG page.
 from DB2
Successful migration from DB2 to Oracle in just
four days reduce TCO for Continuous Availability
Every day is newsstand day – which makes downtime for the commercial R/3 SAP system not some-
thing Europe’s biggest media retailer would wish to contemplate. That is why the short migration time
was a major success factor in the changeover from a DB2 to an Oracle database. Oracle’s sound migra-
tion advice and experience contributed greatly to bringing this challenging project to its successful con-
clusion in a mere four days.
Kiosk AG operates 1,320 retail outlets, serving more than a million customers daily.
The figures speak for themselves: Every day more
than a million customers shop at Kiosk AG’s
1,300 retail outlets in German and Italian-spea-
king Switzerland for virtually everything the
heart desires while traveling and in-between
times. A plethora of 6,000 food and non-food
products ranging from candies to tobacco pro-
ducts to incidentals, are available to customers in
a hurry, not to mention more than 4,000 media
products and 5,500 book titles. In addition to
its own retail outlets, Kiosk AG also serves more
than 4,500 outside retailers, such as supermarket
newsstands. An immense amount of merchandise
is moved day after day, not to mention the
purchasing and sales data generated to move it.
According to SAP platform migration project
manager and Kiosk AG Oracle database admini-
strator Stefan Reitinger, “Volumes such as these
really tax our logistics and IT capabilities”.
But Kiosk AG has it all under control with two
commercial data processing systems: A proprie-
tary software package running on an IBM AS/400
helps manage media products – about one third
of overall sales – and an SAP R/3 system for tob-
acco and non-media products, order processing,
financial and cost accounting, which until the
changeover ran on another AS/400. When the
overall data volume exceeded 730 gigabytes, this
became a bottleneck.
Time is money
In early 2000, IT management addressed the pro-
blem. Since it was designed for considerably less
data and a lower data growth rate, the old AS/400
system simply wasn’t up to this kind of volume.
Even add-on outside, high-performance storage
and backup systems failed to produce the perfor-
18
mance needed. This is when the planners first
began to contemplate a systems change, a pursuit
that led inexorably to casting about for a database
system good enough to answer present and future
needs. Stefan Reitinger: “For reasons of economy
we first toyed with the idea of retaining our DB2
environment, but time constraints made this
unfeasible.” The switch from AS/400 to RS/6000
entailed a new operating system and a system
architecture change from EBCDIC to ASCII.
Oracle proved to be the best-performing database
platform. As daily newsstand turnover generated
ever more data, the migration process had to be
completed in record time, a fact that severely
limited the choice of migration tools.
The Kiosk team wanted the optimum solution for
its volume of data. So they went to Oracle’s SAP
competence center in Walldorf and to IBM
Switzerland for information about possible confi-
gurations. In late 2000, in cooperation with IBM
implementation partners Gate Informatic AG, con-
figuration of the RS/6000 platform began to take
shape. Part of the equation entailed forsaking a
monolithic solution in favor of a modular system
that incorporates several computer nodes. It soon
emerged that the data had to be managed in three
stages, data export using SAP-certified migration
tools, transfer of export data to the target platform,
and import into the target platform’s Oracle data-
base. “Original migration time projections ran-
ged from six to fourteen working days”, said
Stefan Reitinger. “Nobody was willing to stick
their neck out any further and nobody thought a
shorter time span was possible.” The plan was
risky because not having the commercial R/3
environment available for an extended time period
could cost Kiosk AG a small fortune.
Stefan Reitinger,
SAP platform
migration project
manager.
Careful testing before migration
The decision in favor of the Oracle database plat-
form in mid-January was made for two reasons,
time and the guaranteed performance of the
Oracle database engine in conjunction with the
database, migration tool and SAP release.
Another factor in favor of Oracle was that Kiosk
AG already had a number of Oracle supported
applications and time critical logistics applicati-
ons running, which meant that the firm disposed
of DB administrator know-how – important for
the future.
Once the decision was made, action followed
action in rapid succession:
Two test platforms were created, one the in-house
AS/400 test computer running the new RS/6000
hardware, the other the serious computer power
available at IBM’s benchmark center in Mont-
pellier, France. According to Stefan Reitinger,
”The tests ran more or less concurrently. While the
Montpellier tests failed to produce the hoped-for results,
the first in-house export conducted in Muttenz was more
promising – it was accomplished in just 96 hours”.
One reason no further migration tests were con-
ducted in Montpellier was problems with data
transfer quality to the South of France and back.
Consequently the migration team, with the sup-
port of partners East AG in Switzerland,
Germany’s Realtech AG and Oracle Germany’s
own SAP Competence Center team, confined it-
self to testing in-house data export and import
into the new system. Anticipation went up ano-
ther couple of notches when, prior to the live
migration, the second test export was concluded
in an unbelievable 52 hours.
When Easter 2001 came around, everything was
ready. The final physical migration, consisting of
data export, transfer and import, took just 48
hours; then the test team checked out the func-
tionality of all SAP features, which took an addi-
tional ten hours. The many interfaces of Kiosk
AG’s complex, heterogeneous system environ-
ment were closely scrutinized at the same time.
Having started the Wednesday before Easter, the
migration team had good reason to pop champa-
gne corks as early as Saturday evening. This
meant that, including post-processing, the
migration took just four days. On Easter Monday,
all processes were tested from each of the depart-
ments and when staff returned to work from the
Easter holiday on Tuesday morning, every Kiosk
AG department had full use of its SAP environ-
ment. Stefan Reitinger summed it up this way:
“The changeover equaled our best-case scenario … we
continue to reap the benefits of this robust, balanced con-
figuration and we have reached all our objectives: no
more resource bottlenecks and we are optimally prepared
for continued growth and any SAP upgrades down the
road.”

Effectiveness
Effectiveness
Executive Overview
Of Oracle9i Table Compression in SAP BW
Data stored in relational databases grows as a result
of business requirements for more information. A
significant portion of the cost associated with
maintaining large amounts of data is the cost of
disk systems, and the resources utilized in mana-
ging that data. Oracle9i Release2 Enterprise
Edition introduces a unique way to deal with this
cost by compressing data stored in relational
tables. There is virtually no negative impact on
query time against that data, thereby enabling
substantial cost savings. This white paper docu-
ments a test conducted with data generated from
a project initiated by SAP, Sun Microsystems and
Oracle in summer 2002. The type of data used
was the result of a customer survey conducted by
SAP and the amount of data was approximately
5.5 terabyte.
The test results show that a reduction in the data-
base size could be more than 2 Terabytes, and the
operational data was compressed by a factor bet-
ween 2 and 3 times. This space saving was achieved
without the usual impact on the systems perfor-
mance.
Even by using the worst-case scenarios for the
compression feature, the overall performance was
slightly increased. Nevertheless the focus for
customers using this new Oracle9i feature should
clearly be the space saving aspects.
Introduction
Commercially available relational database systems
have not relied on compression techniques for data
stored in relational tables because the trade-off
between time and space for compression has not
always been attractive. A typical compression
technique may offer space savings, but only at the
cost of greatly increased query response times.
Oracle9i Release2 Enterprise Edition introduces a
unique compression technique that is very attrac-
tive for large data warehouses. The reduction of
disk space can be significant compared with stan-
dard compression algorithms because it is opti-
mized for relational data, has virtually no negative
impact on the performance of queries against
Kiosk AG
Please contact the Oracle Services and Support team for further
information about database migration programs for SAP!
e-mail: Saponoracle_de.oracle.com, or Fax: +49 6227 8398-199
compressed data, and may have a significant posi-
tive impact on queries accessing large amounts of
data. Furthermore, customers should experience
improved performance of data management opera-
tions such as backup and recovery and Oracle9i
compression techniques ensure that compressed
data is never larger than uncompressed data.
How it Works
Oracle9i Release2 compresses data by eliminating
duplicate values in a database block. Compressed
data stored in a database block is self-contained,
that is, all the information needed to recreate the
uncompressed data in a block is available within
that block. Duplicate values in all the rows and
columns in a block are stored once at the begin-
ning of the block, in a symbol table for that block.
All occurrences of such values are replaced with a
short reference to the symbol table. Compressed
database blocks look very much like regular data-
base blocks, with the exception of a symbol table
at the beginning.
Program modifications done in the server to allow
for compression were very localized. Only the
portions of the program dealing with formatting
the block, and accessing rows and columns needed
to be modified. As a result, all database features
and functions that work on regular database blocks
also work on compressed database blocks.
What can be Compressed
Database objects that can be compressed in
Oracle9i Release2 include tables and materialized
views. For partitioned tables, it is possible to
choose compression for some or all partitions. The
compression attribute can be declared for a table-
space, a table, or a partition of a table.
If compression is declared at the tablespace level,
then all tables created in that tablespace will use
compression. But it is possible to alter the com-
pression attribute for a table or a partition within
a tablespace with a different compression attribute,
and the change will only applied to new data going
into that table or partition. As a result, a single
table or partition may contain some compressed
blocks and some regular blocks. The fact that a
table may contain mixed blocks is utilized to
9i
guarantee that data size will not increase as a
result of compression. In situations where com-
pression could increase the size of a block, it is
simply not applied to that block.
Compression occurs while data is being bulk in-
serted or bulk loaded. These operations include:
• Direct Path SQL*Loader
• CREATE TABLE … AS SELECT statement
• Parallel INSERT (or serial INSERT with an
APPEND hint) statement
Existing data in the database can also be com-
pressed by moving it into compressed form
through ALTER TABLE…MOVE statement.
This operation takes an exclusive lock on the table,
and therefore prevents any updates, and loads until
it completes. If this is not desirable, Oracle9i’s
online redefinition utility (dbms_redefinition plsql
package) can be used to override the exclusive lock.
Data compression works for all data types except
all variants of LOBs and data types derived from
LOBs, such as VARRAYs stored out of line or the
XML data type stored in a CLOB. Releases prior
to Oracle9i Release2 already had the ability to
compress indexes, both Bitmap and B*tree, as
well as Index Organized Tables.
Cost and Benefit Analysis
The primary benefit of compression is the space sa-
vings achieved. The ratio of the size of uncompres-
sed data to compressed data is often referred to as
the compression ratio. For example, a compression
ratio of 2 indicates that uncompressed data takes
twice as much disk space as compressed data.
When a high compression ratio can be achieved
for large amounts of data, the resulting benefit is
a significant savings of disk space. Often this
translates into indirect benefits when accessing
data. For example, if the access involves a table
scan, the operation will be much faster because
compression made the table much smaller.
Additionally, compression allows greater amo-
unts of data to be kept in the database cache.
When compressed tables are accessed through an
19
 index, there may be a performance advantage
because it increases the chance of finding more of
the table data in the database cache. An inherent
advantage of the compressed tables is that they
tend to have a better clustering factor for adjacent
indexes.
Cost of Compression in General
With Oracle’s unique compression technique,
there is no expensive decompression operation
needed to access compressed table data. Data
compression is performed during bulk loading of
data and the overhead associated with compressing
data is compensated by the reduction in free
block-search operations of the mass data.
If rolling window partitioning techniques are used
for loading data, then increased load time may be
less of an issue, because the impact of load on other
data warehouse workload is minimal. Once the
data is loaded, compressed tables or partitions can
be used like any other Oracle tables or partitions.
Data can be modified using INSERT, UPDATE,
and DELETE commands.
Note: data, which is modified without using bulk
insertion or bulk loading techniques, may no
longer be compressed. Data is not compressed
when conventional inserts are used, rather it is
compressed only doing bulk load or when using
the append-hint.
Deleting compressed data is as fast as deleting
uncompressed data and inserts are also fast but
not compressed. Following inserts are also as fast,
because data is not compressed in case of conven-
tional insert.
Updating compressed data may be somewhat slo-
wer in some cases. It is possible to cause frag-
mentation and waste disk space when modifying
compressed data.
In some cases, updating compressed data may be
somewhat slower and no disk fragmentation may
occur when modifying compressed data. For
example, if a row is deleted, the space occupied
by a deleted row becomes block fragmentation
free in that block. But, since a conventional insert
does not go through compression a future row to
be inserted is likely not to fit into the space relea-
sed by a compressed row.
Data compression is more suitable for Data Ware-
housing applications than OLTP applications
because many modifications to the compressed
data might result in greater space wasting versus
the space saved through compression. In such a
case, it would be necessary to recompress the data.
Also, data should be organized so that read only
or infrequently changing portions of the data
(e.g. historical data) should be kept compressed.
Compression Ratio
Oracle has tested compression with several real
world customers’ data across different industries.
The typical compression ratio for large data
warehouse tables range from 2:1 to 4:1. Higher
compression ratios have also been observed. For
example, call detail data from a major telecom
company produced 12:1 compression.
In our SAP BW test scenario the compression of
20 the main targeting objects achieved a ratio of
approximately 1:3 “Out-Of-The-Box”. Oracle’s
compression algorithm is based upon eliminating
duplicate values in each block, in most situations;
there are additional techniques, which can improve
the compression ratios.
First, the data can be loaded in order to maximize
the duplication of values within a database block.
Due to the fact that this would require a coding
effort for the SAP BW software, we decide to use the
“easiest” way of testing the feature, in order to
flatten hurdles for a fast (first-step) implementation
of this technology by the SAP BW development
team. For that reason any kind of aggregated data
that contains summarized data is an ideal candi-
date for compression, because the GROUP BY
clause in the generation of such an aggregated
data segment has the side effect of generating
partially sorted data. Also, larger block sizes may
yield better compression in general.
This may happen for two reasons: First, there is
an increased probability of duplicate values in a
larger amount of data. Second, space taken by the
symbol table in each compressed block is amortized
over more data fitting in a larger block.
In our testing environment the Oracle block size
was set to 32 KB, and we did not take advantage
of the sorting option during our test. The reason
is simple: To get this optimization implemented
at SAP BW customer sites it would be necessary
to change the code in the BW loading code. This
might be possible in the future, but we did not
want our results to be dependent on an SAP
development effort.
Nevertheless a quick test showed we would have
been able to save an additional 10-20% of space
consumption when data was sorted during inser-
tion in favor of the compression needs.
Storage attributes of a table affects compression
ratio, for example, a large PCTFREE will lead to
low compression ratios. Since frequent updates
are not expected on compressed tables, setting
PCTFREE to 0 is recommended for all tables
storing compressed data.
Note: PCTFREE is automatically set to 0 for all
tables created with the COMPRESS attribute.
Performance Impact on Loads and DML in General
Compressing data has a performance impact on
loads, DML statements, and queries. Oracle has
run numerous experiments to measure the perfor-
mance characteristics of compression.
Compression overhead is most visible during bulk
loading, for example, simple loads; compressing
data may cause twice the CPU usage on average.
If run on a system with unlimited I/O bandwidth,
this may translate into doubling the load time
when considering only the database layer.
However, two facts usually guarantee that this
slowdown will never be observed in real SAP BW
customer systems. The first is, that bulk loads are
I/O-bound on most systems. In those cases, since
compression reduces the amount of data blocks
that have to be read in first and written down
later, there would be some benefit in terms of
elapsed load time to equalize the cost of additio-
nal CPU usage. Secondly, loading data into a SAP
BW mostly involves complex data transformations,
which alone take a significant amount of time.
Compression overhead, as a percentage of the entire
load process is less. In the step of creating com-
pressed aggregated table data from a compressed
source tables, we measured overheads of more
than 80% on the database layer compared to non-
compressed scenarios. SAP BW customers, who
carry out the complete task on their BW layer will
see less than 5% overhead in total. So taking the
application layer into account is essential to get
the correct picture, when assessing the impacts
for SAP BW customers.
There is no measurable difference in the perfor-
mance of non-bulk INSERT operations on com-
pressed and uncompressed data. The reason is
that a conventional INSERT operation does not
go through compression. However, bulk INSERT
operations, such as parallel INSERT or CREATE
TABLE … AS SELECT operations, and INSERT
with an APPEND hint (a.k.a. direct path INS-
ERT) go through compression, and are subject to
the same bulk load performance characteristics as
outlined above.
DELETE operations are 10% faster for compressed
tables. The benefit comes from the fact that the
compressed rows are smaller, so that there is less
data to be logged. No extra work, such as cleaning
up of symbol tables when appropriate, is currently
done during this operation.
UPDATE operations are 10-20% slower for com-
pressed tables on average, mainly due to some
complex optimizations that have been implemented
for uncompressed tables and not yet implemented
for compressed tables but these may be implemen-
ted in a future release of Oracle.
Querying on compressed data is generally faster
than querying uncompressed data. For I/O-bound
queries, accessing compressed data may be signifi-
cantly faster, while queries that gets all its data
from the buffer cache might get only slight ad-
vantages or even suffers on the compression, in the
worst case of running in a CPU bounded environ-
ment.
SAP BW Test Results
Our tests were conducted on the same system
used by SAP and Sun Microsystems in the BW 5
terabyte project. Detailed descriptions of this test
with the configuration information, business
model, and workflow details can be found in the
project report white paper at:
http://www.sun.com/solutions/thirdparty/-sap/-
collateral/index.html or http://service.sap.com
(section BW/Media Center).
The project was audited by the Winter Corpora-
tion, and the corresponding report can be handed
out on request. Briefly the test was done on Sun
Microsystems E15000 server with 72 CPUs and
24 T3 storage arrays. The software used was SAP
BW 3.0, Oracle9i R2 and the operating system
was Solaris 9.
Compression testing was conducted on almost all
steps from the original project. The only exception
was the step involving the transfer of data between
the Persistent Staging Area (PSA), which acted as a
staging area, to the compressed InfoCube, that
represented the fact tables. In addition to the
compressed flag at table level Oracle requires either
a bulk insert or append hint on individual state-
ments, this could not be implemented in the
application layer with ease. But the result can be
derived from the step of transferring data between
Making the Grade …
SAP Solutions on Dell

Dell has made the grade as the recent recipient of the SAP Pinnacle Award for Excellence in

Customer Satisfaction and Support! Dell leverages its business model and core competency in

build-to-order delivery to help accelerate and enhance the deployment of SAP solutions. Through the

use of Dell™ PowerEdge™, PowerVault™ and Dell/EMC® solutions, Dell and SAP work together

to optimize successful implementations.

• SAP Global Technology Partner … for Successful Implementations

• SAP Competence Centers … for Sizing Assistance

• Certified PowerEdge Servers … for Reliable Platforms

• Dell Business Model … for High ROI

• SAP Pinnacle Award Winner 2002 … for Dell’s Excellence in Customer Satisfaction

Easy as

Visit www.dell.com/sap for more information.

Dell cannot be responsible for errors in typography or photography. SAP is a registered trademark of SAP AG. EMC is a registered trademark of EMC Corporation in the United States of America.
Dell, the DELL logo, PowerEdge, and PowerVault are trademarks of Dell Computer Corporation. Dell disclaims any proprietary interest in the marks and names of others. © 2002 Dell Computer Corporation.
All rights reserved. Printed in the USA. Reproduction in any manner whatsoever without the written permission of Dell Computer Corporation is strictly forbidden. November 2002, Cho.

the InfoCubes and the aggregates. These tasks
end up in very similar types of SQL statements
and database tasks with similar data.
Loading ASCII File Data Into Persistent Staging
Area (PSA) Tables
The Persistent Staging Area (PSA) is a set of
transparent database tables that acts as the initial
storage area of data where requested data unchan-
ged from the source system is saved according to
the structure defined in the DataSource.
For the process of loading 960 ASCII files with
R/3 operational data into the PSA tables, an R/3
central instance has been set up with 3 batch
processes and 20 additional application servers
each with 4 batch processes resulting in 83 batch
processes in total, which were loaded in parallel.
It took 44:50:25 hours to load 11,680,000,000
records into the uncompressed PSA tables, which
implies a throughput of more than 260 million
records per hour. The average time required by a
single InfoPackage with 12 million records was
3:47:34 hours. During the load the average CPU
consumption was approximately 70%, and the
average disk usage was more than 95% on the
disks holding the ASCII files, and 10% on the
disks storing the database files.
Clearly the load process was I/O bound on rea-
ding the ASCII data. Using compression on the
targeting PSA tables have had an enormous
impact on the storage requirements, while the 80
PSA tables originally filled up 3.5 terabytes; we
measured only 1.1 terabyte with activated com-
pression. This was the main area of interest,
because 70% of all data was stored in the PSA
objects and these savings have been achieved
without any significant performance impact.
Customer sites should experience an increased
advantage, because in productive systems addi-
tional source data of the same type is stored in
OSD tables that tend to be larger than the PSA
by several factors, and have absolute identical
compression characteristics.
Regarding load performance, no measurable
effect will happen because source data reading and
verifying are the dominating and bottlenecking
tasks in the phase. Because we see most of the
space saving potential in the area of PSA and
OSD tables, it was decided to start some measure-
ments regarding migration speed from non-com-
pressed objects to compressed ones. Due to some
specific reasons the test probably did not use the
fastest method of using ALTER TABLE MOVE
statements. But even with normal parallel insert
mechanisms we reached a runtime throughput of
roughly 1.5 million rows per second.
This would migrate a 146 million row InfoCube
in 90 seconds. All big tables of the test scenario
(80 InfoCubes and 80 PSA tables) would have
had a core database migration time between 4
and 5 hours only! Taking into account that to
22 achieve this speed would require at least the test
system, in our tests the 72 Sparc III CPU’s were
fully loaded, and 500 MB/sec random read/write
activity pass through the storage system. The
bottom line of this quick and non-comprehensive
test; it seems possible SAP BW customers that
run into the limits of their storage space require-
ments should consider migration to compressed
tables “On-The-Fly”. Of course some work with
SAP BW development has to be done, but tech-
nically it seems possible to migrate huge BW
databases in a time window of less than 8 hours.
Creating Indexes on the Persistent Staging
Area (PSA) Tables
In order to speed up the load into PSA, the indexes
on the PSA tables have been dropped. Since the
indexes will be needed for loading the data from
the PSA into the cubes, they must be recreated.
To avoid disk sorts, the Oracle sort area size was
increased from 10 to 70 MB, then the index
creation was scheduled with 10 parallel processes
directly at the database level.
Creating all indexes on the uncompressed PSA
tables took approximately 15:30 hours. The index
creation on compressed PSA tables was even
faster, with a runtime of 10:15 hours. The overall
performance of this step improved after the original
measurements, and new runtimes came down to
about 6 hours for uncompressed PSA tables and 4
hours for compressed PSA tables.
Creating Database Statistics on the Persistent
Staging Area (PSA) Tables
Therefore, database statistics on the PSA tables
were created using 10 parallel jobs for 10 diffe-
rent PSA tables. In total this phase took approxi-
mately 19:30 hours to create all PSA table stati-
stics when tables were uncompressed. The same
task on the compressed PSA table structures could
have been speed up to only 7:30 hours. Again,
after finishing the project, improvements lead to
runtimes of about 7 hours for uncompressed and
2:45 hours on compressed PSA tables. The huge
difference in favour of the compressed object can
be explained by the I/O bounding of this task.
Keep in mind that the compressed objects are
only about 1/3 in size of the original ones.
Loading Data from PSA Tables into InfoCubes
and ODS Objects
The next large step in the 5 TB data warehouse
was the loading of the PSA table data into the
corresponding InfoCubes and ODS objects. Since
loading data from the PSA tables into the
InfoCubes is more CPU-intensive than loading
the data from flat files to the PSA tables, this task
is more compression-sensitive in terms of possible
runtime drawbacks. The central instance was set
up to have 3 batch processes and 25 application
servers were set up to have 4 batch processes each,
resulting in total of 103 batch processes.
In this phase, 1152 load requests needed to be
processed; 12 load requests for each of the 80
InfoCubes, and 48 requests for each of the 4 ODS
objects. In total, more than 14 billion records were
written to the data targets and required 65:17:19
hours for this step. The average throughput was
214,677,532 records per hour and the average
processing time for a single request was 5:52:35
hours. During the loading phase an average CPU
load of 94% and disk activity of 30% was observed.
Using compressed PSA tables had no impact on
the runtime of this step. This can mainly be explai-
ned by the fact that the majority of CPU work
was done in the application layer and the system
load of reading few compressed blocks or even
three times more uncompressed PSA blocks
seems to be the same (all dominated by application
CPU workload).
As already mentioned, we were not able to mea-
sure the runtimes for compressed target tables,
because that would need complex application
code changes. Nevertheless, regarding the data-
base task we have a similar step when transferring
data from the InfoCube table to the aggregate
tables later on. This phase was investigated deeply,
so that these results can be transferred to this
step. As only slight slowdowns on the database
level can be expected, the total impact in this
application CPU bounded task will be in a range
below one percent, if at all measurable.
Creating Indexes on the InfoCubes
As in the case of loading the PSA tables, all indexes
on the InfoCube tables were dropped prior to the
load. Recreating all indexes on 80 uncompressed
InfoCubes (8 indexes per cube) required 2:53:00
hours. A maximum of 32 indexes were generated in
parallel application jobs, each using 4 to 6 parallel
Oracle shadow processes. Creating the 800 indexes
on compressed InfoCubes took roughly the same
amount of runtime. Note that we never used com-
pression features for the index structures. Usually it
should be possible to get very good buffer hit ratios
on indexes at customer sites, and the space savings
in this area can be ignored.
Generating Database Statistics of InfoCubes
To make sure that the Oracle optimizer chooses
the best access path to the data when aggregates
are created or queries are executed directly on
InfoCubes, it is necessary to have up to date sta-
tistics not only on the InfoCube tables, but also
on master data tables, etc. Therefore the complete
Oracle database schema has been analyzed at this
point. The analysis of the schema and creation of
all relevant database statistics took approximately
6 hours.
Using compressed tables was very effective in this
step, because analyzing more or less the whole
database was an I/O intensive task, and reading
approximately 2/3 less database blocks will speed
up the process significantly, so a runtime of
approximately 4 hours was achieved.
Note: Our testing environment tended to be I/O
bottlenecked at this point. So customers that run
their BW on only 4 or 8 CPUs might observe
no improvements depending on the system and
the detail level of the statistics and performance
degradation is also possible.
Creating Aggregates and their Indexes
Aggregates dramatically improve runtimes of
queries, which retrieve sums from a set of records
by storing pre-summarized data. Based on the
queries defined for the InfoCube, 10 aggregates
have been designed for each cube, which help to
optimize the query response times. The aggregates
were created in parallel; a maximum of 5 aggrega-
tes were created at a time. However, a parallel
degree of 12 on the Oracle database level has been
used, which means, for each aggregate, 12 parallel
query slave processes were reading data from the
InfoCube fact tables and writing to the aggregate
tables at the same time.
The creation of 800 aggregates took 14:14:45
hours when reading from uncompressed InfoCube.
Gathering the source data from compressed
Infocube resulted in a slightly longer runtime of
about 3%. The performance difference at this step
was heavily dependent on the kind of aggregate
that had to be built.
If aggregates do not massively summarize the
source data, then this step tends to be more I/O
sensitive and therefore compression should be
advantageous. On the other hand the CPU over-
head of uncompressing the source data will
impact negatively if the aggregation itself uses all
the CPU power that it can get.
Another interesting point in this phase was the
test that investigated the potential on space savings
at the aggregate level. As aggregates are normal
tables from the database point of view, they can
easily be compressed like other non-redundant
tables. Because of the different information
abstraction layer of those objects, it’s is interesting
to observe that the compression ratio potential
was almost the same as the one of their under-
lying InfoCubes.
The resulting number of one typical, big aggregate
(/BIC/E100966) was that the table shrank from
66016 blocks to 31214 blocks after compression.
Investigating the potential of compression on the
aggregate level has a different background than
the compression tests done on the larger InfoCube
and PSA/OSD tables. Because only a small per-
centage of the overall storage of the warehouse
was occupied by the aggregates, there won’t be a
significant space saving at the disk level.
What makes the compression of aggregates an
interesting target for investigation is the fact that
customers will do most of their reporting on
these tables. And because they are aggregated
there is a good probability to reach good buffer
hits ratios in the SGA. Getting a compression
ratio of approximately 2 for the aggregates, can
lead to a significant improvement in the buffer
hit ratio and consequently performance improve-
ments at the query level.
In SAP BW, aggregates technically are stored in
the same way as InfoCubes. The considerations
regarding indexes on the tables made above apply
to aggregates as well. Therefore aggregate indexes
were dropped prior to their population and recreated
after loading the aggregates. The time required to
create indexes on uncompressed aggregates was
0:52:12 hours. The same runtime was measured
when aggregates run through compression before.
User Queries
This test was probably the most difficult; in order
to match “real-world-scenarios” SAP has conduc-
ted customer surveys gathering information
about the type and the amount of query types
that typically can be expected on the system.
However, unlike other phases of the test these
results can hardly reach stages of general validity.
As already mentioned, it would have been easy to
generate tests, where compression takes advanta-
ge of improved buffer hit ratios in the database
buffer cache. These scenarios would not suffer on
realism, however our defined goal was slightly
different. Because it is impossible to simulate a
scenario that represents the majority of all custo-
mer queries, we were more interested in looking
at a worst-case scenario when using the compres-
sion option.
This should be an environment where no I/O
saving can be achieved with compression, because
all blocks are already loaded to the buffer cache.
Surprisingly enough, this test showed a clear
advantage for the compressed tables. Additionally,
it appears the way compression affects memory-
only queries is data dependent and therefore not
generally foreseeable.
Using our test environment, a query that has to
touch all data from an InfoCube using a Full-
Table-Scan finished in 11 seconds on an uncom-
pressed InfoCube table. The buffer cache hit ratio
was 100% and Parallel-Query-Slave processes
used all 72 CPUs exhaustively.
Under the same conditions the query took about
8 seconds, when running on the compressed
InfoCube. Proofing the results of a previously
completed test, which used a more realistic I/O
load, performance was improved as expected when
using compression.
Uncompressed InfoCube full table scan runtime
was almost twice as high as the compressed scena-
rio; 31 seconds compared to 17 seconds. The query
in this test was obtained from the aggregate crea-
tion step, because this simulates what happens at
productive customer sites, when an ad-hoc query
hits the system that has no prepared aggregation
table, like typical reporting queries do.
Queries that used index based access plans have
also been tested. Doing I/O for the InfoCubes the
uncompressed target took 313 seconds – much
longer than the less I/O intensive 254 seconds
running the same query on compressed targets.
Not only a better buffer hit ratio for the query can
be assumed because of the higher density, but
also inherently better clustering factors are
characteristic for indexes on compressed tables.
Conclusion
The cost of disk STORAGE systems can be a
large portion of building and maintaining large
data warehouses like SAP BW. Oracle9i Release 2
helps to reduce this cost by compressing the data
stored in the database, and it does so without the
typical trade-offs in run time performance.
The test case demonstrated that a space saving
factor from 2 to 3 could be accompanied by a
slight performance advantage. The database size
was reduced from 5 terabytes to less than 2 tera-
bytes and the overall runtime performance was
improved by approximately 10%. However, the
performance impacts cannot be generalized in the
same manner that the space saving potential can
be.
Depending on the specific system environment
these can be the object of change. But, because of
the pessimistic assumption used in the test it is
unlikely that customers will see performance deg-
radations.
Our tests were conducted without using special
SGA sizing that favors compressed data seg-
ments. With regard to the compression option we
tried to simulate a worst-case scenario, that is,
either all data had to be read from disk (in cases
where huge tables were fully scanned) or all data
(even the uncompressed data) was held in the buffer
cache (for tasks that only involve small aggregated
tables and/or indexed data).
In real customer scenarios, you will usually be
between these extreme situations, and so the
reduction of space requirements will improve
your buffer hit ratios and consequently your per-
formance. Consequently, this project shows that
SAP BW customers using Oracle9i Release 2 and
the compression option for table segments should
be able to massively reduce their storage space
requirements without negatively impacting run-
time performance.
This is valid for tasks of warehouse maintenance as
well as for warehouse query workload. Customers
can expect some performance improvements, but the
main focus should clearly target the space saving
aspects.
23
 SAP Server Consolidation – combining high
flexibility with low TCO
It’s a fact that the use of SAP solutions in companies is increasing on a steady pace. However, the
implementation of additional mySAP application components also demands challenges for existing IT
infrastructures. For various reasons enterprises view the “add another server” approach critically – and
focus consequently on consolidated SAP solutions. Dr. Michael Missbach from HP SAP Competence
Center Walldorf, Germany explains the main advantages of an SAP server consolidation for the user
and outlines the concept of SAP consolidation.
? Why is SAP consolidation in the spotlight
now ?
Missbach: In the past larger client-server systems
had to be distributed due to CPU and memory
restrictions. Today, we have immense CPU power
available, and with the 64-bit SAP core also the
address space to allocate sufficient memory
resources – even for a large number of users on a
single computer. As a result, the number of servers
needed for an SAP system can be significantly
reduced, despite increasing performance require-
ments. In addition we have partitioning technolo-
gies on hand to grant resources on demand to
multiple SAP systems hosted together on one
single computer.
? Why do companies think about SAP/server
consolidation? What are the driving forces ?
Missbach: Under the current economic conditi-
ons enterprises put priority on cost reductions,
primarily in maintenance and operating costs.
However, there is also a need for greater flexibility
in the deployment of mySAP components. Both
can be achieved by SAP server consolidation,
providing resources in a flexible way – where they
are needed. Furthermore, consolidation provides
additional performance due to optimal load
balancing. Nevertheless, companies having faced
the proliferation of a huge number of servers go
for consolidation in order to reduce the complexity
of their infrastructure and make them “manageable”
again.
? One possible retort is that IT infrastructure
manufacturers have brought up the subject of
SAP server consolidation simply to generate
more new sales ?
Missbach: That is absolutely not the case. The
customers drive the subject, in particular IT
managers responsible for data centres. They are
looking for possible solutions in order to accom-
plish a controllable and efficiently manageable
number of servers despite the increasing number
of users and applications, something along the
lines of mySAP. Incidentally, SAP supports con-
solidation actively for example with initiatives
like “Multiple Components, One Database
(MCOD)”.
? Which cost savings can be expected with SAP
server consolidation ?
Missbach: That is different for each SAP instal-
lation. However, in general a consolidation of an
older system with dedicated database and several
application servers into a single central system,
can be expected to have a redemption period of
about six months, simply through the savings on
maintenance and operating costs; consequently
the return of investment is extremely good.
If this is taken one step further, consolidation of
several SAP systems onto a single server results in
further cost saving, and increased flexibility
because every computer that is no longer neces-
sary for the SAP landscape reduces the operation
effort by two to three working days per month
plus the maintenance costs. In many cases, enter-
prises operate environments with over 100 com-
puters just for SAP today. The benefits achieved
by the reduction of such an environment to only
four to six servers through consolidation can be
seen very clearly.
? Does this relate to Unix as well as NT infra-
structures ?
Missbach: The principle is basically applicable
to all SAP IT infrastructures. However, the 64-
bit SAP core is the key to SAP server consolidati-
on, which until now has only been available from
Unix for common operating systems. There are
also still some differences in the partitioning
capabilities of the various operating systems.
Consequently, consolidation on 32-bit computers
and operating systems has only been possible
with a very small number of users in the past.
This is now changing with the availability of 64-
bit Itanium systems and the corresponding SAP
64-bit core for NT and Linux. The excellent per-
formance of these new Itanium systems could
already be demonstrated by running SAP SD and
ATO benchmarks based on the Oracle9i database
(see SAP benchmark certification 2002069*)
? You said before that greater flexibility is also
achieved by SAP server consolidation. Could
you explain this aspect in more detail ?
Missbach: Running multiple mySAP components
on a server with partitioning enables flexible
allocation of resources to applications. Without
consolidation, dedicated extra power has to be
implemented for the peak load on every system.
In a consolidated environment, these “extras” can
be shared flexibly. The art of consolidation is to
achieve a maximum of flexibility on the one hand
while guaranteeing the necessary degree of
isolation on the other hand. Here, the various par-
titioning methods come into play. For example,
with HP-UX, we have an unrivalled wide range
of various possible partitioning technologies. I
will mention only resource, virtual and hard par-
titions. Through this, we are able to combine the
various methods in order to achieve the optimum
for the customer.
? Could you briefly outline an example of when
it could be beneficial to freely allocate resources
on demand ?
Missbach: In a world of mergers and acquisitions
where the performance demands can’t be predic-
ted over longer periods the benefits of flexibility
is obvious. Typical examples are mySAP compo-
nents with temporary performance peaks, like
CRM during Christmas business or Financials
during year end closing. With a consolidated
system, all the available resources, which are not
necessarily needed by other components at the
same time, could be thrown into the battle.
However, it is important that this allocation is
dynamic as well as transparent for the mySAP
components, i.e. that it can be done without a re-
boot of the SAP system. The combination of run-
ning HPUX and Oracle9i for example is a very
important area where CPU and memory resources
can be used dynamical.
? By what means is an SAP server consolidation
project carried out ?
Missbach: Due to the fact that SAP server conso-
lidation does not involve changes within the
application logic, such a project is relatively
unspectacular. In a joint workshop the customers
define their requirements and our consolidation
specialists introduce the corresponding technical
solutions. This includes an evaluation of the exis-
ting environment from a sizing perspective as
well as concepts to grant the necessary level of
system availability and isolation. After the conso-
lidated approach is approved, the new hardware is
installed and the applications are moved to the
consolidated environment.
For a couple of years, this has been our daily
business, expenditure and possible escalation pro-
cedures being well under control. Longer project
duration periods don’t have to be expected.
25
 ? With a logical consolidation of SAP applicati-
ons, however, things are different, aren’t
they ?
Missbach: In contrast to a technical consolidati-
on, a merger or fusion of SAP systems involves
also the business processes. Therefore we establis-
hed cooperation with the SAP landscape optimi-
zation (LSO) group providing application exper-
tise and tools. Such a project however, is in the
range between the Euro conversion and a R/2 –
R/3 migration. According to our experience, enter-
prises start with technical consolidation, in order
to achieve rapid ROI and providing the technical
pre-conditions for the next step. This is then fol-
lowed by an appropriate logical consolidation
project over a longer period. Using this method,
we already have successfully carried out several
hundred SAP technical as well as logical consoli-
dations worldwide.
? Can many servers be reduced to just one
single server through an SAP consolidation ?
Missbach: In theory, yes – but in practice this
makes little sense. For mission critical systems
like SAP you always have to answer the question:
“how can we maintain high availability?” –
because even for a consolidated system you should
never put all eggs in one basket. Our recommen-
dation is therefore not to consolidate a bunch of
servers into a single one, but to consolidate many
into a few. With a concept we call redundant
array of consolidated servers (RACS) we can
achieve maximum flexibility combined with high-
est availability and lowest TCO.
? What does an SAP server consolidation mean
for specialists in system operation, in the com-
puter centre ?
Missbach: From a technical point of view, not
too much. It’s more a change in the paradigm
that an SAP system has to consist of distinct data-
base and application server. Since we have made
the consolidation of SAP systems a reality some
years ago, this paradigm change was launched.
Today, there are many satisfied HP customers
who have implemented an SAP server consolida-
tion with our support. The fact that we hear litt-
le from these installations is a good sign for us,
because it simply means that everything is o.k.
*Certification Number. 2002069
The SAP ATO (Assemble-to-Order) standard 4.6 C
application benchmark performed on November 25,
2002 by HP in Cupertino, California, USA, was cer-
tified on December 13, 2002 with the following data:
Fully business processed Assembly Orders/hour(*): 3,090
CPU utilization central server: 94%, Operating System:
HP-UX 11i
RDBMS: Oracle 9i, R/3 Release: 4.6 C, Total disk
space: 528 GB
Configuration: 1 Central Server: hp rx5670, 4-way
SMP, Itanium II, 1 GHz,
3 MB L3 cache, 24 GB main memory (*) Assembly
Order: Request to assemble pre-manufactured parts and
assemblies to finished products according to an existing
26 sales order.
Database Architecture Consulting (SAP)
SBS and Oracle Real
Application Clusters
Information technology is the lifeblood of vir-
tually all business operations. Information
systems are used to interact with customers, to
sell products, to track inventory, and to make
strategic decisions that can significantly affect the
future course of operations.
This package is of relevance for nearly every SAP
IT departments must be able to maintain their customer of the relevant size.
systems to avoid impacting the flexibility of their Various database availability concepts are evalua-
company’s business operations. In today’s rapidly ted for customers on the basis of their system
changing market, this imperative means that landscapes. Interdependencies with other soft-
systems must be able to sustain rapid growth in ware clusters or I/O technologies are examined
demand as well as being consistently available. and assessed. Integration with system manage-
ment is also analyzed. The existing database
As a company expands their operations, either backup and recovery concept is adapted.
through customer growth, demand growth or
entering into new areas of business, their systems RAC Workshop
must be able to easily grow with them. As opera- Management workshop on RAC and its introduc-
tions become more global and customer-interac- tion.
tive, the systems that support these operations • RAC Technology Workshop
must be available all the time. And no business Technical workshop for administrators.
can afford a crushing maintenance burden to sup-
port these new demands. • RAC Introduction
Turnkey introduction of RAC.
Oracle9i Real Applications Clusters provides
• Database Cluster Tuning
both scalability and availability as a single, easy Tuning of database clusters and applications
to manage database product. A recent study by
running on them.
the Hurwitz Group on total cost of ownership
found that almost 60% of companies identified • OPS / RAC Turnkey Migration
scalability or availability would result in an esti- Integration of RAC for OPS customers,
mated 185 savings in the total cost of ownership from concept creation to acceptance.
over three years.
• RAC Operational Support
Siemens Business Services has now gained a very Maintenance and operation of RAC clusters!
high level of market acceptance in IT and is a
major service partner in the SAP arena. A primary For more information please contact
focus of its activity consists of consulting and E-Mail: Ulrich.wilmsmann@siemens.com
E-Mail: eduard.port@siemens.com
project implementation on the topics of availabi-
lity and scalability.
The issue of scalability plays an especially impor-
tant role, in particular in the SAP arena. Whereas
the number of application servers can be increa-
sed virtually as desired, the database server is
always the only non-transparent scalable resource.
To date, server power has most often been used as
the estimate of the transaction performance of a
database. Particularly in the SAP R/3 environ-
ment, the database server constituted the actual
weak point as regards scalability in large applica-
tions. RAC is one option for increasing the over-
all performance of the database and the servers
involved.
And for the first time, smaller SAP customers
now also have opportunity of creating an afforda-
ble, highly available database infrastructure.
3-Tier Architecture for SAP R/3 Applications
Siemens Business Services offers service packages
in the RAC environment that are of particular
interest to SAP customers.
 my SAP Solutions Running
Oracle9i RAC and Linux
Mission-Critical Applications with Scalability and High-
Availability: A Technical Demonstration
The Challenge: Enterprise solutions such as mySAP® applications from SAP demand
high-availability and easy scalability regardless of the size of the customer’s organization.
SAP users require uninterrupted database access whether hardware and software
failures occur or not. Businesses and organizations grow, and their IT requirements can
change rapidly. Adding capacity or changing workloads to SAP systems that includes re-
configuring or replacing the database server is disruptive and increases system down-time
and raises cost.

The Solution: Working closely with SAP, Oracle, Intel, and Red Hat, Dell has leveraged
Oracle9i ™ RAC technology to demonstrate the technical viability of running mySAP
on Linux in a robust, highly available, and scalable environment, allowing organizations
to optimize their return on IT investment using flexible, industry-standards based solutions.

Configuration Example:
• 2 x Dell PowerEdge 2650 servers, each with two Intel® Xeon™ processors,
as Linux based nodes of the Oracle9i RAC database (Node #1 and #2)
• 1 x Dell PowerEdge 2650, with two Intel® Xeon™ processors, as SAP central
instance/application server
• 1 x Dell|EMC fibre channel storage unit providing the resilient repository
for the SAP data
• Gigabit Ethernet as cluster-interconnect for Oracle9i RAC
• Oracle9i RAC Release 2 version 9.2.0.1
• Operating System: Red Hat® Linux Advanced Server 2.1
• SAP 4.6C with 4.6D kernel

How it works:
When a user logs onto the SAP system using the SAPGui, the SAP central instance/appli-
cation server connects to the Oracle9i database via one of the Oracle9i RAC nodes
(assume it is Node #1) and can work normally in the SAP system. Simulating a database
node failure, Node #1 of the Oracle9i RAC cluster is brought down suddenly. The existing
database connection of the application server is redirected to the surviving node (Node #2)
by means of the Oracle TAF (Transparent Application Failover) feature, and continues to work.
For the user, the system continues to run and he can work normally. The failure of Node #1
does not result in having to restart the Oracle9i database, because the database connection to
the failed node is routed to a surviving node.

©2002 Dell Computer Corporation. Dell, the Dell logo, and PowerEdge, are registered trademarks or trademarks of Dell Computer Corporation. Oracle and the Oracle logo are registered trademarks and Oracle9i is a trademark of Oracle
Corporation. Intel and Pentium are registered trademarks; Xeon is a trademark of Intel Corporation. Red Hat and the Shadowman logo are registered trademarks of Red Hat Inc. Linux is a registered trademark of Linus Torvalds. SAP and mySAP
are registered trademarks or trademarks of SAP AG. Dell disclaims proprietary interest in the marks and names of others.

27
 Oracle for SAP – Release Matrix
Current Database-SAP R/3 Release Matrix
SAP R/3 Version 3.1I, 4.0B, 4.5B, 4.6B:
8.1.7 32-bit:
Intel NT/Windows2000/XP, Intel Linux,
IBM AIX, HP-UX, Reliant UNIX, Solaris
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX, Reliant UNIX,
Solaris
9.2 32-bit
Intel NT, Windows2000/XP, Intel Linux
9.2 64-bit
HP Tru64, HP-UX PA-RISC, HP-UX IA-64,
IBM AIX 5L, Solaris (SUN and Fujitsu-
Siemens), Windows2003 (planned for May)
SAP R/3 Version 4.6C/D:
8.1.7 32-bit:
Intel NT/Windows2000/XP, Intel Linux,
IBM AIX, HP-UX, Reliant UNIX, Solaris
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX, Reliant UNIX,
Solaris
9.2 32-bit
Intel NT, Windows2000/XP, Intel Linux
9.2 64-bit
HP Tru64, HP-UX PA-RISC, HP-UX IA-64,
IBM AIX 5L, Solaris (SUN and Fujitsu-
Siemens), Windows2003 (planned for May)
SAP R/3 Enterprise:
8.1.7 32-bit:
Intel NT, Windows2000/XP, Intel Linux
8.1.7 64-bit:
HP Tru64, IBM AIX, Solaris (SUN and
Fujitsu-Siemens)
9.2 32-bit
Intel NT, Windows2000/XP, Intel Linux
9.2 64-bit
HP Tru64, HP-UX PA-RISC, HP-UX IA-64,
IBM AIX 5L, Solaris (SUN and Fujitsu-
Siemens), Windows2003 (planned for May)
SAP Business Information Warehouse 2.0B/2.1C
8.1.7 32-bit:
Intel NT/Windows2000/XP, Intel Linux,
IBM AIX, HP-UX, Solaris (SUN and
Fujitsu-Siemens)
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX, Solaris
(SUN and Fujitsu-Siemens)
9.2 32-bit
Intel NT, Windows2000/XP, Intel Linux
9.2 64-bit
HP Tru64, HP-UX PA-RISC, HP-UX IA-64,
IBM AIX 5L, Solaris (SUN and Fujitsu-
28 Siemens), Windows2003 (planned for May)
SAP Business Information Warehouse 3.0B:
8.1.7 32-bit:
Intel NT, Windows2000/XP, Intel Linux
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX,
Solaris (SUN and Fujitsu-Siemens)
9.2 32-bit:
Intel NT, Windows2000/XP, Intel Linux
9.2 64-bit:
HP Tru64, HP-UX PA-RISC, HP-UX IA-64,
IBM AIX 5L, Solaris (SUN and Fujitsu-
Siemens), Windows2003 (planned for May)
SAP Business Information Warehouse 3.1:
9.2 32-bit:
Intel NT/ Windows2000/ XP, Intel Linux
9.2 64-bit:
HP Tru64, HP-UX PA-RISC, HP-UX IA-64,
IBM AIX 5L, Solaris (SUN and Fujitsu-
Siemens), Windows2003 (planned for May)
Oracle9i Real Application Clusters
SAP R/3 4.6 C/D: April/ 2003:
(controlled availability planned)
HP Tru64
Oracle Desupport Dates:
8.0.6 Sept. 30, 2001
8.1.7 Dec. 31, 2003
9.2 Dec. 31, 2005 (planned)
End of Maintenance for SAP R/3 Releases:
standard additional support fee
3.1I 12/2003 12/2004
4.0B 12/2003 12/2004
4.5B 12/2003 12/2004
4.6C 3/2006
(planned)
Imprint
Oracle for SAP Global Technology Center
Altrottstr. 31
69190 Walldorf, Germany
Tel. ++49 (0) 62 27-83 98 - 0
Fax ++49 (0) 62 27-83 98 - 199
E-Mail: saponoracle_de@oracle.com
Albrecht Haug
albrecht.haug@oracle.com
Internet: http://www.oracle.com/newsletters/sap
http://www.sap.com/partners/directories/technology.asp
Reproduction allowed only with the publisher’s express permission
Oracle, Oracle8i, Oracle9i, Oracle Express, Discoverer, Designer, Developer, and the Oracle Logo are trademarks or registered trade-
marks of Oracle Corporation.
SAP, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trade-
marks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service
names mentioned are the trademarks of their respective companies.
This publication is provided “as is“ without warranty of any kind, either express or implied, including, but not limited to, the implied
warranties of merchantability, fitness for a particular purpose, or non- infringement. This publication could include technical inaccuracies
or typographical errors. Changes are periodically added to the information herein; these changes will be incorporated in new editions
of the publication. Oracle Corporation. may make improvements and/ or changes in the product(s) and/ or the program(s) described
in this publication at any time. Oracle Corporation has intellectual property rights relating to technology described in this document.
In particular, and without limitation, these intellectual property rights may include one or more patents or pending patent applications
in the U. S. or other countries.No part of this publication may be reproduced or transmitted in any form or for any purpose without
the express permission of Oracle. The information contained herein may be changed without prior notice. Some software products
marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries,
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM
are trademarks of IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product
names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts
Institute of Technology.
JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used
under license for technology invented and implemented by Netscape
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
All trademarks and registered trademarks are the sole property of their respective owners.
© Copyright 2003 Oracle Corporation. All rights reserved.