oracle database: the database of choice for deploying sap solutions · oracle database: the...

An Oracle White Paper

August 2009

Oracle Database: The Database of Choice for Deploying SAP Solutions

Oracle Database: the Database of Choice for Deploying SAP Solutions

Executive Overview ................................................................................................ 2

Introduction............................................................................................................ 1

Database MARKET SHARE for Enterprise Applications ................................... 1

Oracle-SAP Technology Relationship................................................................... 2

Oracle 11g for SAP ................................................................................................ 3

SAP Standard Applications Benchmarks ............................................................. 3

Scalability and Performance ................................................................................. 4

Reliability................................................................................................................ 4

Platform neutrality................................................................................................. 4

High Availability and Scalability with RAC for SAP ........................................... 5

Disaster Recovery with Data Guard for SAP........................................................ 7

More Oracle features Important for SAP Customers........................................... 8

Table and Index Partitioning........................................................................... 9

Index Key Compression ................................................................................. 10

Addressing Backup and Recovery................................................................. 10

Flashback database......................................................................................... 11

Manageability.................................................................................................. 12 Automatic Workload Repository .................................................................. 12

DBA Cockpit ................................................................................................ 13

BR*Tools Studio........................................................................................... 13

Patching of Oracle Databases and Real Application Clusters ...................... 14

Oracle Advanced Security.............................................................................. 14

Database Vault ................................................................................................ 15

Oracle Expertise in the SAP environment .......................................................... 16

Conclusion............................................................................................................ 16

Appendix............................................................................................................... 17

Executive Overview For almost 20 years Oracle has been the database of choice as the development

platform for SAP applications. A contract between Oracle and SAP had been signed in

November 1999 to ensure the future cooperation and the position of Oracle as “tier one”

platform for SAP. The contract was last renewed in January 2008.

SAP R/3 was originally developed on Oracle, and the companies have a deep

relationship at the technical level. Subsequent SAP products, such as SAP Business

Information Warehouse (BW) have also been developed using the Oracle database.

Oracle’s assistance during incorporation of new database features, performance testing,

bug fixing and customer problem escalations has been invaluable to the large number of

SAP customers running on Oracle.

Years ago, Oracle implemented the industry’s best concurrency model with non-

escalating row-level locking and multi-version read consistency; innovative features such

as self-tuning database components and enhanced indexing and partitioning schemes

have maintained Oracle’s reputation for performance and scalability for enterprise

applications. And Oracle has shown itself to be a leader in database availability and

security as well – an important consideration for managing critical data in an SAP system.

For our customer this means:

• There is plenty of Oracle expertise in SAP´s development, support and consulting

divisions.

• All certified SAP applications are optimized for Oracle database


1

Introduction This paper covers the business and technology factors driving customers to choose

Oracle as the underlying database for their SAP deployments. In the following sections

we discuss Oracle’s market position among databases for SAP applications, the SAP-

Oracle technology relationship including adoption of new Oracle database features by

SAP.

Oracle database features important for SAP customers in the areas of

• Scalability

• Reliability

• High Availability

• Manageability

• Security

Database MARKET SHARE for Enterprise Applications

Analysts are unanimous in saying that the Oracle database enjoys dominant market share for

enterprise applications, including SAP.

Almost two third of SAP implementations are based on an Oracle database. Note that the bigger

the system (i.e. more users, more data) the higher the requirements are with regard to security

and high availability, the higher is the share of Oracle based systems. Very large systems are

almost exclusively based on Oracle.

Oracle dominates the SAP database market across operating systems, with success on various

flavors of Unix and Linux as well as on Windows.

Oracle’s market position has real advantages for customers considering database choices for their

SAP system. A large installed base indicates that Oracle is able to meet the database needs of

SAP customers across industries and geographies.

It also means that a large group of customers has tested the SAP-Oracle combination in

situations that no QA group at SAP could ever recreate. Both Oracle and SAP have learned from

this experience in the field, and both products have been enhanced as a result. Customers

choosing Oracle for SAP now will get the accumulated benefits of years of product testing in the

real world. The impressive large customers basis translates into several advantages:


2

• Proven technology

• Widest choice of solutions and systems

• Highest consulting expertise on the market

• Best cooperation with hardware and tool vendors

Oracle-SAP Technology Relationship

Oracle has dedicated teams working with SAP in many different areas, including joint software

development, pre-sales and technology evangelism, customer technical support and professional

services. The Oracle-SAP technology is deep and goes back to 1988, when SAP R/3 was first

developed:

Table 1: Milestones in SAP-Oracle Technology Relationship

The Oracle development team working at SAP HQ in Walldorf, Germany assists SAP in:

• Performance testing of each release with the Oracle database to ensure there is no degradation

of response time, throughput and scalability between SAP versions.

• Fixing database bugs found during SAP functional testing, and including SAP enhancement

requests in the database product roadmap

• Incorporating new Oracle features in SAP releases

• Optimize each new release of the DBMS and new versions of SAP applications


3

• Responding to escalated customer problems, when related to database issues

All SAP products are currently certified with Oracle 10g Database Release 2, 10g Real

Application Clusters has been certified in December 2006 and is general available for SAP

customers.

SAP is an enthusiastic adopter of new features in the Oracle database. We will discuss an extract

of the features supported by SAP later in this paper showing the main differentiators of Oracle

Database from DB2 and SQL Server.

Oracle 11g for SAP

SAP AG has participated in Oracle Database Beta Programs for many years. The joint Oracle

and SAP development teams in Walldorf, Germany, have completed extensive tests of Oracle

Database 11g Release 1 Beta and is testing with Oracle Database 11g Release 2 Beta.

The release strategy of SAP AG for Oracle Database versions is to certify only the terminal

release of a new database version. This strategy is based on the overall requests of the SAP

customer community to minimize the number of version upgrades in complex SAP

environments. It has been proven a successful roll out process with previous terminal release

certifications of Oracle Database Versions 8i, 9i and 10g.

Therefore, SAP AG will skip Oracle Database 11g Release 1 and certify Oracle Database 11g

Release 2, at least 12 months before Oracle Database Release 10g goes into the extended support

cycle. According to the current planning SAP systems based on SAP Kernel 6.40 and higher will

be certified for Oracle 11g. Oracle Database 11g Release 2 will contain various specific

functionality designed and implemented for the needs of the SAP Application Product Suite.

SAP Standard Applications Benchmarks

SAP has created several standard benchmarks to compare the performance of various solutions

and components across different hardware platforms and technology stacks and to assist in sizing

customer systems. The most “popular” SAP standard application benchmarks are SAP Sales and

Distribution (SAP SD), Assemble-to-Order (ATO), SAP Business Information Warehouse (SAP

BW) and Advanced Planning and Optimization (SAP APO). SAP SD comes in three flavors: 2-

tier (database and SAP application on same server), 3-tier (database and SAP application on

different servers) and Parallel (3-tier with a clustered database). ATO has two flavors: 2-tier and

3-tier.

A Head-to-Head Comparison finds Oracle on Top with 3,600 More SAP SD Users than

Microsoft SQL Server 2005 on Identical Fujitsu Hardware, (Oracle/Linux certification number

2006071, SQL Server/Windows certification number 2006068, see Appendix). Another

benchmark comparison on identical HP Hardware, Oracle Database could serve 34% more SD

users than SQL Server (Oracle/Linux certification number 2008064, SQL Server/Windows


4

certification number 2008026, see Appendix). This comparison shows that Oracle 10g was even

better than SQL Server 2008.

In November 2007, Oracle announced a world-record result on the SAP® Sales and

Distribution-Parallel (SD-Parallel) Standard Application Benchmark running on the SAP® ERP

6.0 application (Certification Number 2008013, see Appendix) with 37,040 SD users. With this

result, Oracle Database with Oracle Real Application Clusters continues to demonstrate

exceptional grid computing capabilities, delivering excellent performance, scalability, and value.

Scalability and Performance

A production SAP system sees fluctuating user loads, contention on frequently used tables, a mix

of reads and writes, and occasional heavy batch jobs. The database platform for the system needs

to be able to scale easily on this mixed workload without requiring frequent and extensive DBA

intervention. SAP standard benchmark results as well as customer experience show that the

Oracle RDBMS distinguishes itself through an optimal usage of available system resources. SAP

certified a series of benchmarks that demonstrate the impressive scalability of Oracle Real

Application Clusters (RAC): The throughput increased by a factor of 1.9 whenever the number

of nodes was doubled (Certification number 2008010 with 2 nodes Cluster and Certification

number 2008012 with 4 nodes Cluster, see Appendix)

Reliability

Oracle was developed to minimize planned as well as unplanned downtime: • Administrators can perform most management and maintenance jobs while the system is

online and full data access is possible.

• The individual components of an Oracle database server are extremely stable. Users can

access the database even if parts of it are unavailable.

• Should a system failure occur (e.g. because of hardware problems), recovery of an Oracle

database is fast and fully automatic in RAC environment.

• The management tools provided by Oracle can identify and solve potential problems before

they affect data availability.

Platform neutrality

Oracle has always been a platform-neutral database. Oracle 9i/10g Database were released

simultaneously on all major platforms, and the database is the same across all platforms. Oracle’s

support for the major Unix platforms, Windows and Linux gives customers the assurance that

they can switch hardware vendors and operating systems with no penalty. SQL Server and, to a


5

slightly lesser extent, DB2, force the customer to pick a specific operating system or hardware

vendor. A SAP system on Oracle can scale up by moving to a different, larger hardware

configuration; the choices are far fewer for SQL Server or DB2 based systems.

Oracle has maintained platform-neutrality even as new chips and operating systems are

developed:

• Oracle Database provides unique portability across all major platforms

• Oracle is transparent to SAP (no application modification needed by changing the Operating

System)

• Oracle code base is identical across platforms

• Oracle has the same functionality on all Operating Systems

• Oracle has the same admin tools for all Operating Systems

• Easy migration to Oracle

High Availability and Scalability with RAC for SAP

Oracle Database 10g comes with an integrated set of High Availability (HA) capabilities that help

organizations ensure business continuity by minimizing the various kinds of downtime that can

affect their businesses. These capabilities take care of most scenarios that might lead to data

unavailability, such as system failures, data failures, disasters, human errors, system maintenance

operations and data maintenance operations

The cornerstone of Oracle’s high availability solutions that protects from system failures is

Oracle Real Application Clusters (RAC). Oracle RAC is a cluster database with a shared cache

architecture that overcomes the limitations of traditional shared-nothing and shared-disk

approaches, to provide a highly scalable and available database solution for SAP applications.

RAC supports the transparent deployment of a single database across a cluster of active servers,

providing fault tolerance from hardware failures or planned outages. RAC supports mainstream

business applications of all kinds – these include popular packaged products such as SAP, as well

as custom applications. RAC provides very high availability for these applications by removing

the single point of failure with a single server. In a RAC configuration, all nodes are active and

serve production workload. If a node in the cluster fails, the Oracle Database continues running

on the remaining nodes. Individual nodes can also be shutdown for maintenance while

application users continue to work.

A RAC configuration can be built from standardized, commodity-priced processing, storage, and

network components. RAC also enables a flexible way to scale applications, using a simple scale-

out model. When more processing power is needed by a particular application service, another

server can be added easily and dynamically, without taking any of the active users offline. Based


6

on customer configurations, SAP Dialog instances and users connected to can be routed to

dedicated nodes in the RAC cluster.

Oracle Clusterware complements RAC, providing an integrated cluster software solution for

enterprise grids, for thousands of customer sites around the world.

RAC affordable scalability

Oracle RAC is designed on the principles of horizontal scalability, distributing the total database

workload across many smaller servers or Hardware (logical or physical) partitions. As demand

increases, additional servers are added to the cluster, a process that is seamless to both users and

applications. Oracle RAC uses a shared-storage cluster architecture, where every node in the

architecture enjoys concurrent and equal access to a single common database. Any node can add,

edit, or delete data. A single database means there are no replication or segmentation issues, no

ownership or redirection of SQL requests. Every node is equally capable of handling any

transaction directly.

Inherent High Availability

In an Oracle RAC, each node in the cluster has equal access and authority to database tasks and

resources. With built-in load balancing, clients of failed nodes are automatically redirected to

another node in the cluster. Surviving nodes have continuous access to the database while they

reconcile the shared transition logs of failed nodes. Returning the database to full update

functionality takes a fraction of the time of a manual restart and recovery, or even an automated

Failover to a standby sever, because the database is never down.

Contrary to Failover Cluster where every SAP instance is connected to a single database instance,

with an Oracle RAC cluster one or more SAP instances can be connected to each Oracle RAC

instance. If one RAC node crashes, the users connected to the other nodes will not be affected

since they are connected to a different database instance. The SAP dialog instances that were

connected to the crashed database instance (node1) will be automatically reconnected to a

surviving database instance (node2) within seconds. The Failover happens quickly because only

the service within Oracle Clusterware and assigned to each SAP instance has to be started on a

surviving Database instance. One more advantage for SAP customers is the SAP high availability

of the Enqueue and the message server and even the Failover of any other SAP dialog instance,

made possible with SAPCTL, which is based on Oracle Clusterware. This eliminates the need for

3rd party software to make SAP high available.

Simplified Administration

Multiplying the number of components in a solution can potentially increase the maintenance

burden. However, Oracle RAC features minimize this possibility. Resources, servers, and storage

can be managed as a single entity within a cluster-wide environment. Because the database

appears as a standard, single instance to applications and administrators, the same maintenance

tools and practices can be used. All standard backup and recovery operations work transparently


7

with RAC. Maintenance is simplified because RAC provides rapid, automatic Failover for users if

any server crashes. This automatic Failover capability overcomes the need to execute the

complex operations required to restore database access.

Disaster Recovery with Data Guard for SAP

Oracle Data Guard is the most effective and comprehensive data availability, data protection, and

disaster recovery solution for enterprise databases. It provides the management, monitoring, and

automation software infrastructure to create and maintain one or more synchronized standby

databases to protect data from failures, disasters, errors, and corruptions.

Data Guard standby databases can be located at remote disaster recovery sites thousands of miles

away from the production data center, or they may be located in the same city, same campus, or

even in the same building. If the production database becomes unavailable because of a planned

or an unplanned outage, Data Guard can switch any standby database to the production role,

thus minimizing downtime and preventing any data loss.

Data Guard delivers:

• Reliability– optimum data protection and availability. You always know the state of your

standby database and it can very quickly (in seconds), assume the primary role.

• Lower cost and complexity – Data Guard's mature capabilities and rich management interface

are included features of Oracle Enterprise Edition.

• Maximum return on investment – All standby databases can be utilized for production

purposes while in standby role. Idle resources are eliminated.

• Preventing data corruptions due to human errors (due to flashback and delay)

• Support of multiple Standby databases assigned to the same primary database

• Seamless back-and-forth conversion between a read-write database and a standby database

• Standby database that can be used for backup to offload the primary database

• Primary and standby databases can be Real Application Clusters and/or single-instance Oracle

• Integrated management interface

• For more information see “Addressing Disaster Recovery”

Some of Oracle Database10g Data Guard new features are:


8

• Improved Redo Transmission: Several enhancements have been made in the redo transmission

architecture to make sure redo data generated on the primary database can be transmitted as

quickly and efficiently as possible to the standby database(s).

• Easy conversion of a physical standby database to a reporting database: A physical standby

database can be activated as a primary database, opened read/write for reporting purposes, and

then flashed back to a point in the past to be easily converted back to a physical standby

database. At this point, Data Guard automatically synchronizes the standby database with the

primary database. This allows the physical standby database to be utilized for read/write

reporting and cloning activities.

• Real Time Apply: With this feature, redo data can be applied on the standby database (Redo

Apply) as soon as they have written to a Standby Redo Log (SRL). Prior releases of Data

Guard require this redo data to be archived at the standby database in the form of archive logs

before they can be applied.

The Real Time Apply feature allows standby databases to be closely synchronized with the

primary database, enabling up-to-date and real-time reporting. This also enables faster

switchover and Failover times, which in turn reduces planned and unplanned downtime for the

business.

The impact of a disaster is often measured in terms of Recovery Point Objective (RPO - i.e.

how much data can a business afford to lose in the event of a disaster) and Recovery Time

Objective (RTO - i.e. how much time a business can afford to be down in the event of a

disaster). With Oracle Data Guard, when Maximum Protection is used in combination with

Real Time Apply, businesses get the benefits of both zero data loss as well as minimal

downtime in the event of a disaster and this makes Oracle Data Guard the only solution

available today with the best RPO and RTO benefits for a business.

• Integration with Flashback Database: Oracle’s Flashback Database quickly rewinds the

database to a previous time, to correct any problems caused by logical data corruptions or user

errors. Flashback Database is like a 'rewind button' for your database. It provides database

point in time recovery without requiring a backup of the database to first be restored. When

you eliminate the time it takes to restore a database backup from tape, database point in time

recovery is fast.

More Oracle features Important for SAP Customers

The Oracle database has succeeded as a platform for enterprise applications because it provides

the scalability, high availability and ease of management that are important for mission-critical

systems. Managing a complex application like SAP already requires significant effort on the part

of application administrators and business analysts; customers prefer a database that will

perform, scale and stay up without adding much administration overhead or technical risk. Sound


9

architectural decisions made in early Oracle releases and a record of continued innovation have

allowed Oracle to give customers this assurance.

Table and Index Partitioning

Partitioning addresses key issues in supporting very large tables and indexes by letting you

decompose them into smaller and more manageable pieces called partitions. SQL queries and

DML statements do not need to be modified in order to access partitioned tables. However, after

partitions are defined, DDL statements can access and manipulate individuals partitions rather

than entire tables or indexes. This is how partitioning can simplify the manageability of large

database objects. Also, partitioning is entirely transparent to SAP applications.

The SAP BI application that uses Oracle table partitioning by default benefits from performance

and manageability (e.g. dropping partitioned objects, a frequently used operation in SAP BW).

Oracle table partitioning for non-BI systems and especially SAP ERP has been supported since

SAP R/3 4.6C (note 742243), but its implementation in ERP systems was a consulting based

solution offered by Oracle for a while. SAP has now integrated so-called “Partitioning Engine”

for ERP into SAP’s Database administration tools. The Partitioning Engine will be made

available starting with SAP Web AS 6.20 and its general availability for SAP customers is planned

for Q3/2009. The SAP “Partitioning Engine” will help to analyze the candidate tables and

indexes and to offer suitable partitions ranges before running the online redefinition.

Table partitioning enhances scalability in a number of different ways:

• Data can be partitioned across time, thus providing the ability to store more historical data in

the analytic workspace without affecting performance or manageability.

• Calculations can be easily limited to a subset of dimension members, or they can be

parallelized. For example, aggregations, allocations and other calculations can be performed

on time periods within a particular partition.

• Data loading can be parallelized.

• When partitioned by the logical model, for example, by level of summarization, the definition

of the variable can be adjusted to account for changes in sparsity between detail data and

summary data.

• Disaster recovery tasks can be performed on subsets of data and can be parallelized.

• Partitioned variables can be partitioned across different data files and disks to minimize I/O

bottlenecks.

While Oracle provided Range partitioning for many years, SQL Server 2005 does this for the first

time and DB2 is actually supporting it since DB2 version 9. But it is unusable because:

• “The SAP Dictionary does not support range partitioning. During a conversion, range

partitioning settings are always lost.


10

• Range partitioning cannot be activated by the SAP Dictionary; you can only use native DB2

tools for this purpose.

• Range partitioning can lead to problems in the SAP upgrade.”(SAP note 930487 as of

September 09, 2007)

Index Key Compression

Key compression allows repeating values for columns in a B*Tree index to be replaced by

shorter tokens in the index blocks. Key compression looks at the values of the leading columns

of the index and replaces repeating values by shorter tokens. To get the maximum benefit out of

key compression you need to compute the optimal mix of the length of the repeating values in

the leading columns of an index and the selectivity of these repeating values in the leading part of

an index.

The advantages of key compression:

• Saves disk space for indexes and reduces total database size on disk: Customer experiences

show that up to 75% less disk space is needed for key compressed indexes. Even after index

reorganizations have taken place an additional up to 20% total disk space reduction for the

whole database can be achieved using index compression. Without any reorganizations done

before the total space savings for the complete database may be higher than 20% using index

compression as index compression implicitly reorganizes any index (Real world example: The

size of the of index 'GLPCA~1' index was reduced from 18GB to 4.5GB).

• Reduces physical disk I/O and logical buffer cache I/O improving buffer cache quality

• Higher CPU consumption: Every compression technique comes with higher CPU

consumption. The higher CPU consumption is more than compensated by doing less logical

I/O for index blocks in the database buffer cache.

• Improved overall database throughput: Early customer experiences have shown a 10-20%

better database throughput for an SAP system by using index key compression in a non CPU

bound environment.

• For implementation information see SAP note 1109743

Addressing Backup and Recovery

One of the major value propositions for Oracle 10g is a significant reduction in cost and time of

deploying and maintaining an Oracle-based solution. A number of major developments in this

area incorporate new techniques and methodologies across the entire database platform.

Very important features has been released, including:

• Backup Compression: If disk space is an issue, or your media-management software does not

support compression, RMAN provides the ability to compress RMAN backup sets.


11

• Incrementally Updated Backups: You can now apply an RMAN incremental backup to a data

file image backup. This results in reduced recovery time, because fewer logs need to be applied,

and reduced time to back up the database, because you do not always have to back up the

whole database.

• Full Database begin/end Backup Command: It is no longer necessary to issue a separate

command to place each tablespace in hot backup mode. You can now use the ALTER

DATABASE statement to place all tablespaces in backup mode. Also the BEGIN BACKUP

command now runs faster than before.

• Change-Aware Incremental Backups: By using a new type of log file to track blocks that have

changed in the database, RMAN can avoid scanning the entire data file during an incremental

backup. Instead the amount of data scanned is proportional to the amount of data changed.

Block change tracking is supported in the SAP environment as of Oracle 10.2.0.2 and

BR*Tools 7.00 (note 964619)

Flashback database

The Flashback Database capability is similar to conventional point-in-time recovery in its effects

and it is accessible from both RMAN and SQL*Plus by using the FLASHBACK DATABASE

command, which has also been integrated into the BR*TOOLS (SAP notes: 1125923, 966117,

966073). To enable the Flashback Database capability a DBA configures the Flash Recovery

Area. The Flash Recovery Area is a new feature in Oracle Database 10g that provides a unified

storage location for all recovery related files and activities in an Oracle database.

Flashback provides Data Guard with an easy-to-use method to correct user errors. Flashback

Database can be used on both the primary and standby database to quickly revert the databases

to an earlier point in time to back out user errors. If the administrator decides to Failover to a

standby database, but those user-errors were already applied to the standby database (for

example, because Real Time Apply was enabled), then the administrator may simply flashback

the standby database to a safe point in time.

Flashback database on the productive database server: SAP customers may be required to revert

the database to an earlier state if a logical data corruption occurred due to an application error,

user error, or administrator error.

Flashback Database also lends itself for cases where you anticipate a database reset in advance,

for example; if the import of an SAP Support Package or an SAP or Oracle upgrade to a new

patch set fails, which means that the database must be reset so you can repeat the process.

Flashback database on the standby Server: We can take advantage of Flashback Database

together with a Physical Standby in order to open the Standby Database in write mode, perform

testing/reporting activities, and once these activities are completed we can reinstate the standby

and synchronize it with the primary database. See:

http://blogs.oracle.com/AlejandroVargas/gems/PhysicalStandbyActivatedRead.pdf


12

Oracle Segment Shrinking

Segment shrinking offers the possibility of recovering the free storage space that is occupied by a

table without reorganizing it, whereby the entries within the segment are “moved together”.

Online segment shrinking is the preferred method for defragmenting a segment and recovering

free storage space (note 910389).

Database copy using transportable tablespace

This new function allows customers to copy an SAP Oracle database between different hardware

platforms. This represents an alternative to the procedures that are based on Oracle

export/import or SAP's R3load utilities, and can offer advantages in terms of time (note

1035051).

Manageability

Oracle Database 10g comes with a large set of optimizations, making the database run faster on

any type of hardware on which the database has been deployed. The database now has the

capability to use fibers, large pages, and Non Uniform Memory Access (NUMA) systems. Fibers

improve overall database performance and throughput. Large pages boost performance for

memory-intensive database applications, especially in cases when the buffer cache is several

gigabytes in size, a typical scenario for SAP configurations. Oracle Database 10g can

automatically detect NUMA hardware and optimize it self by efficiently utilizing NUMA node

affinities.

With every release, Oracle has included more features to automate database administration. Some

features that distinguish Oracle from its competitors and are often adopted by SAP customers to

enhance the manageability of their SAP systems include: Automatic Shared Memory

Management and Automatic Workload Repository.

Automatic Shared Memory

Oracle Database 10g introduces Automatic Shared Memory Management. DBAs can just specify

the total amount of SGA memory available to an instance using the new parameter

SGA_TARGET. The database server then automatically distributes the available memory among

various components as required. The Automatic Shared Memory Management feature is based

on a sophisticated algorithm internal to the database that continuously monitors the distribution

of memory and changes it periodically as needed, according to the demands of the workload.

Automatic Workload Repository

One of the most positive aspects of the current Oracle release is the area of diagnosability and

supportability. Compared to any other database platform Oracle version 10.2 offers the most

sophisticated options for in depth analysis. The evaluation of the data provided by the Oracle

Advanced Workload Repository (AWR) and the Advanced Session History (ASH) allows root


13

cause analysis on every desired level. This is a huge benefit every time you run in e.g. a

performance problem or any other error situation. The SAP and Oracle support lines can act

very effectively based on those features. This situation is hardly measurable in numbers and

proven by several statements received from our support colleagues. The Automatic Workload

Repository (AWR) collects, processes, and maintains performance statistics for problem

detection and self-tuning purposes. This data is both in memory and stored in the database. The

gathered data can be displayed in both reports and views.

An excerpt of the statistics collected and processed by AWR include:

• Object statistics that determine both access and usage statistics of database segments

• SQL statements that are producing the highest load on the system, based on criteria such as

elapsed time and CPU time

• Active Session History (ASH) statistics, representing the history of recent sessions activity

AWR automatically generates snapshots of the performance data once every hour and collects

the statistics in the workload repository. You can also manually create snapshots, but this is

usually not necessary. The data in the snapshot interval is then analyzed by the Automatic

Database Diagnostic Monitor (ADDM).

AWR compares the difference between snapshots to determine which SQL statements to capture

based on the effect on the system load. This reduces the number of SQL statements that need to

be captured over time.

DBA Cockpit

The DBA Cockpit is a platform-independent tool that you can use to monitor and administer

your Oracle database and Real Applications Clusters. It provides a graphical user interface (GUI)

for all actions and covers all aspects of handling a database system landscape. It provides the

relevant functionality from the old transaction codes ST04, DB02, DB13 (DBA Planning

Calendar), DB12, DB14, and DB13C and also includes several monitors, particularly for Oracle

10g. DBA Cockpit includes the monitoring of Oracle RAC and remote Oracle databases, and

even the monitoring of non-Oracle databases (both ABAP and non-ABAP systems) is possible

with MultiConnect. The DBA Cockpit uses the Oracle “Diagnostic Package” including Active

Session History (ASH), Automatic Workload Repository (AWR), and Automatic Database

Diadnostic Monitor (ADDM).

BR*Tools Studio

One of the essential elements of any SAP system landscape is the relational database system,

which contains and administers all persistent data of the SAP system. SAP already offers

BR*Tools, which is a powerful text-based database administration (DBA) package for Oracle

databases. With BR*Tools Studio, SAP is now providing a new front end in the form of a


14

modern graphical user interface (GUI), which has a variety of additional features and is designed

to make daily maintenance of the database system easier.

BR*Tools Studio is a browser-based web application that lets you select the database tasks

known from BR*Tools and then instructs BR*Tools to run the chosen task on the relevant

database.

To download the SAP BR*Tools Studio and the white paper related to, please use

https://www.sdn.sap.com/irj/sdn/ora

Patching of Oracle Databases and Real Application Clusters

MOPatch (SAP note 1027012) is a specially-packaged wrapper utility around Opatch (SAP note

839182) by simplifying the task of installing multiple Oracle database patches into an Oracle

Home. It automates the process of unpacking the patches and calling opatch apply for each of

them.

MOPatch is developed by Oracle’s SAP integration development team and is available for

download from SAP Service Marketplace. It is now integrated with the deployment procedures

of Enterprise Manager Grid Control to automate the orchestration of patching on Oracle

Databases. This automation significantly reduces time and effort involved in the manual patching

activity, see: http://www.oracle.com/newsletters/sap/products/database/oradb4sap_howto.html

Oracle Advanced Security

The Oracle Advanced Security Option for Oracle Database 10g Release 2,released in February

2007, helps SAP customers address regulatory compliance requirements by protecting sensitive

data whether in transit or at rest from unauthorized disclosure. Transparent Data Encryption

seamlessly encrypts sensitive columns within the database, without any changes to the

application.

Oracle Advanced Security offers the following Transparent Data Encryption (individual columns

on data files and backup level). TDE is key based access control system where the data stored in

selected table columns is encrypted on disk. The keys for all tables containing encrypted columns

are themselves encrypted using a Database Master Key and stored in a dictionary table.

Oracle Advanced Security provides an easy to deploy and comprehensive solution for protecting

communication to and from the Oracle Database using both standards based network

encryption, and robust native encryption/integrity algorithms. SSL based encryption is available

for businesses that have deployed Public Key Infrastructure. For businesses with no PKI

deployment, Oracle Advanced Security provides native encryption and data integrity algorithms

to protect data in transit. The Oracle Database can be configured to reject connections from

clients with encryption turned off, or optionally allow unencrypted connections for deployment

flexibility. Configuration of network security is simplified using the Oracle Network


15

Configuration administration tool, allowing businesses to easily deploy network encryption, as

there are no changes required in the application

Database Vault

Outsourcing, application consolidation, and increasing concerns over insider threats have

resulted in an almost mandatory requirement for strong controls on access to sensitive

application data. In addition, regulations such as Sarbanes-Oxley (SOX), Payment Card Industry

(PCI), and the Health Insurance Portability and Accountability Act (HIPAA) require strong

internal controls to protect sensitive information such as financial, healthcare, and credit cards

records. Oracle Database Vault enforces real-time preventive controls and separation-of-duty in

the Oracle Database to secure the SAP application data.

Oracle Database Vault Protection for SAP (is in controlled availability as described in SAP Note

1355140) enables SAP customers to prevent access to application data by privileged database

users, enforce separation-of-duty, and provide stronger access control with multi-factor

authorization. Database Vault enforces security controls even when a database user bypasses the

application and connects directly to the database. Database Vault certification with SAP

applications benefits customers by:

• Preventing privileged user access to application data using protection realms for the SAP ABAP

stack and the SAP Java stack

• Enforcing separation of duty in the Oracle Database while allowing SAP administrators to

perform their duties and protecting their SAP administration roles

• Providing SAP specific Database Vault protection policies for SAP BR*Tools

• Implementing all Database Vault protections transparently and without any change to the SAP

application code

Preventing Privileged User Access: Database administrators hold highly trusted positions within

the enterprise. With Database Vault realms, enterprises increase security by preventing access to

application data even if the request is coming from privileged users. This is especially important

when a privileged account is compromised or accessed outside normal business hours or from an

un-trusted IP address. The regular tools used by administrators to help manage and tune the

Oracle database continue to work as before, but they can no longer be used to access SAP

application data.

Enforcing Separation-of-Duty: Database Vault helps administrators manage operations more

securely by providing fine-grained controls on database operations such as creating accounts,

granting. For more information and White Paper see:

http://www.oracle.com/newsletters/sap/products/dbvault.html


16

Oracle Expertise in the SAP environment

The Solution Center SAP Support and Service – located in Walldorf – offers SAP

customers the following services:

• Advanced Customer Services (ACS)

• Performance Analysis and Tuning

• Development of concepts for Backup/Restore/Recovery, and High Availability, Administration

• Security concepts

• Optimizing of ABAP/4 programs (performance improvement)

• Migration service for customers, who want to use Oracle as the database for SAP applications

(from Informix, MaxDB, DB2, or SQL Server to Oracle).

• Migration services from “Oracle to Oracle” (e.g. Tru64 to HP_UX)

• Integration-Products and –Services

• Oracle Database: The Database of Choice for Deploying SAP Solutions

Conclusion

Oracle has a large and growing share of the market for databases used to deploy SAP. This is not

an accident – both companies invest in making Oracle technology work well for SAP, and Oracle

has a long track record of delivering the de facto standard database for enterprise applications.

SAP customers continue to choose Oracle because of the Scalability, High Availability,

Manageability and Security benefits they obtain.


17

Appendix

Certification Number 2006071: The SAP SD standard mySAP ERP 2004 application benchmark performed on August 19, 2006 by Fujitsu in Paderborn, Germany was certified on August 31, 2006 with the following data: 12,500 SD (Sales and Distribution) Benchmark users, 1.83 seconds average dialog response time, 1,268,000 fully processed order line items per hour, 3,804,000 dialog steps per hour, 63,400 SAPS, 0.014 seconds/0.046 seconds average database request time (dia/upd), 85 percent CPU utilization of central server. Configuration of the central server was as follows: Fujitsu PRIMEQUEST 580, 32 processors / 64 cores / 128 threads, Dual-Core Intel Itanium 2 9050, 1.6 GHz, 32 KB(I) + 32 KB(D) L1 cache, 2 MB(I) + 512 KB(D) L2 cache, 24 MB L3 cache, 512 GB main memory. The server was running the SuSe Linux Enterprise 9 operating system, Oracle Database 10g, and SAP ECC 5.0.

Certification Number 2006068: The SAP SD standard mySAP ERP 2004 application benchmark performed on August 5, 2006 by Fujitsu in Paderborn, Germany was certified on August 31, 2006 with the following data:: 8,900 SD (Sales and Distribution) Benchmark users, 1.95 seconds average dialog response time, 893,670 fully processed order line items per hour, 2,681,000 dialog steps per hour, 44,680 SAPS, 0.043 seconds/0.042 seconds average database request time (dia/upd), 90 percent CPU utilization of central server. Configuration of the central server was as follows: Fujitsu PRIMEQUEST 580, 32 processors / 64 cores / 128 threads, Dual-Core Intel Itanium 2 9050, 1.6 GHz, 32 KB(I) + 32 KB(D) L1 cache, 2 MB(I) + 512 KB(D) L2 cache, 24 MB L3 cache, 512 GB main memory. The Server was running Windows Server 2003 Datacenter Edition, SQL Server 2005 database, and SAP ECC 5.0

Certification Number 2008064: The SAP SD standard SAP ERP 6.0 (2005) application benchmark performed on November 05, 2008 by HP in Marlboro, MA, USA was certified on November 12, 2008 with the following data: 7,010 SD (Sales and Distribution) Benchmark users, 1.88 seconds average dialog response time, 708,000 fully processed order line items per hour, ,2,124,000 dialog steps per hour, 35,400 SAPS, 0.016 seconds/0.022 seconds average database request time (dia/upd), 90 percent CPU utilization of central server. Configuration of the central server was as follows: HP ProLiant DL785 G5, 8 processors / 32 cores / 32 threads, Quad-Core AMD Opteron Processor 8384, 2.7 GHz, 128 KB L1 cache and 512 KB L2 cache per core, 6 MB L3 cache per processor, 128 GB main memory. The server was running the SuSe Linux Enterprise Server 10 operating system, Oracle Database 10g, and SAP ECC 6.0.

Certification Number 2008026: The SAP SD standard SAP ERP 6.0 (2005) application benchmark performed on April 22, 2008 by HP in Houston, TX, USA was certified on May 5, 2008 with the following data: 5,230 SD (Sales and Distribution) Benchmark users, 1.99 seconds average dialog response time, 523,670 fully processed order line items per hour, 1,571,000 dialog steps per hour, 26,180 SAPS, 0.030 seconds/0.028 seconds average database request time (dia/upd), 92 percent CPU utilization of central server. Configuration of the central server was as follows: HP ProLiant DL785, 8 processors / 32 cores / 32 threads, Quad-Core AMD Opteron processor 8360 SE, 2.5 GHz, 128 KB L1 cache and 512 KB L2 cache per core, 2 MB L3 cache per processor, 128 GB main memory. The Server was running Windows Server 2003 Enterprise Edition, SQL Server 2008 database, and SAP ECC 6.0

Certification Number: 2008013: The SAP SD Parallel Standard Application benchmark performed on November 26, 2007 by IBM in Beaverton, OR, USA, was certified by SAP on March 25, 2008 with the following data: 37,040 SAP SD-Parallel Benchmark users, 1.86 seconds average dialog response time, 3,749,000 fully processed order line items per hour, 11,247,000 dialog steps per hour, 187,450 SAPS. Server configuration: 5X IBM System p 570, 8 processors/16 cores/32 threads, POWER6, 4.7 GHz, 128 KB L1 cache and 4 MB L2 cache per core, 32 MB L3 cache per processor,


18

128 GM main memory, running AIX 5L version 5.3, Oracle 10g Real Application Clusters and SAP ERP 6.0.

Certification Number: 2008010: The SAP SD Parallel Standard Application benchmark performed on November 26, 2007 by IBM in Beaverton, OR, USA, was certified by SAP on March 25, 2008 with the following data: 15,520 SAP SD-Parallel Benchmark users, 1.94 seconds average dialog response time, 1,559,330 fully processed order line items per hour, 4,678,000 dialog steps per hour, 77,970 SAPS. Server configuration: 5X IBM System p 570, 8 processors/16 cores/32 threads, POWER6, 4.7 GHz, 128 KB L1 cache and 4 MB L2 cache per core, 32 MB L3 cache per processor, 128 GM main memory, running AIX 5L version 5.3, Oracle 10g Real Application Clusters and SAP ERP 6.0.

Certification Number: 2008012: The SAP SD Parallel Standard Application benchmark performed on November 26, 2007 by IBM in Beaverton, OR, USA, was certified by SAP on March 25, 2008 with the following data: 30,016 SAP SD-Parallel Benchmark users, 1.86 seconds average dialog response time, 3,036,000 fully processed order line items per hour, 9,108,000 dialog steps per hour, 151,800 SAPS. Server configuration: 5X IBM System p 570, 8 processors/16 cores/32 threads, POWER6, 4.7 GHz, 128 KB L1 cache and 4 MB L2 cache per core, 32 MB L3 cache per processor, 128 GM main memory, running AIX 5L version 5.3, Oracle 10g Real Application Clusters and SAP ERP 6.0.

Oracle Database: The Database of Choice for

Deploying SAP Solutions

February 2009

Author: Abdelrhani Boukachabine

Contributing Authors: Thomas Stickler

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright © 2009, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and

the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other

warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or

fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are

formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any

means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective

owners.

0109

oracle database: the database of choice for deploying sap solutions · oracle database: the...

Documents