Professional Documents
Culture Documents
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
If you are not reorganizing your SAP R/3 database once or twice a year,
your system is not performing as well as it could be. A bold statement,
but its true, even for medium-sized SAP installations.
Uniform sizing works best in everyday life, too. A carton of eggs contains all the same size eggs.
A case of soda contains either cans or bottles, but not both cans and bottles, which would leave a
lot of wasted space.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
July/August 2005
Figure 1
A Fragmented Tablespace
PSAPBTABD
Note!
In addition to a reorganization strategy and
procedures, a good application performance
management plan requires writing efficient
queries, proper batch job scheduling, good
database design, and other such elements, to
name a few.
The strategy was born from dozens of white papers, scripts, newsgroup
postings, SAP Notes, technical manuals, and books, and thus reflects
the latest in industry best practices and lessons learned. I merely optimized this information for SAP R/3 Oracle databases.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 2
Note!
This article assumes some background in database
management. For this reason, and because such
a large body of knowledge already exists on this
topic,3 I will not discuss database management
in detail in this article. Also, the screenshots I
provide are a high-level demo of Quest Softwares
LiveReorg, an SAP-approved third-party tool that
we use at Rohm and Haas. The strategy presented
in the article does not require LiveReorg, but using
LiveReorg lets you run reorganizations on a live
system. You might also use BMCs Space Expert
tool for a live reorg capability. Later in the
article, Ill talk about using Oracle SQL scripts
to implement this strategy in a near-live manner.
Tablespaces with
Uniform Extent Sizes
Caution!
Although Ive tested the reorganization strategy
presented in this article extensively at Rohm
and Haas, as with all procedures on missioncritical systems, both diligence and prudence
are warranted. For example, double (or triple)
your efforts and downtime estimates until you
gain experience, back up your database before
attempting any reorganization, and always have
a fallback plan in case something unexpected
happens. Using SAP-approved tools such as
LiveReorg maintains full compliance with the
ABAP Dictionary and will not invalidate your
SAP support agreement.4
For starters, see Oracle white paper #711 (How to Stop Defragmenting
and Start Living: The Definitive Word on Fragmentation) available at
www.oracle.com/technology/deploy/availability/pdf/defrag.pdf.
Books by Tom Kyte and Don Burleson are also good resources,
and you can find a wealth of information simply by Googling for
Oracle Space Management.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
July/August 2005
Reorganization Strategy:
Three Key Tactics
Note!
The suggested size limits originate from Oracles
recommendations in the white paper on database
fragmentation.5 The white paper proposes three
sizes of classes that Ive termed Small, Medium,
and Large. I created the Tiny class with the
smallest allowable Oracle extent size to better
accommodate the myriad tiny and empty tables
in an SAP R/3 database. Ive also added the
Singular class for the few very large tables that
would exceed the upper limit of extent counts
I want to manage in the Large class.
Caution!
As you will see, its important to include only SAP
tablespaces in your reorganization unless you
have express clearance from third-party vendors
for their tablespaces. Reorganizing third-party
or Oracle system tablespaces can interfere with
your SAP systems operation or support. Its also
important to separate SAP and non-SAP database
objects into different tablespaces. In an upcoming
section, I will show you how to differentiate SAP
from non-SAP tablespaces.
Note!
After this strategy is fully implemented, all SAPinstalled original tablespaces will be kept empty
and minimally sized to maintain support package
compatibility.
See Oracle white paper #711 (How to Stop Defragmenting and Start
Living: The Definitive Word on Fragmentation) at www.oracle.com/
technology/deploy/availability/pdf/defrag.pdf.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 3
PSAPBTABD
PSAPTINYD
16K Extent
PSAPSMALLD
160K Extent
PSAPMEDIUMD
5MB Extent
PSAPLARGED
160MB Extent
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
July/August 2005
Note!
Although we will empty the standard SAP tablespaces,
we will not delete them. Support packages
occasionally contain new SAP-issued tables that are
set up to be stored in original SAP tablespaces, so
they must still exist in order to receive a new table.
Note!
Dont forget! Large objects are sometimes purged
and become small tables (e.g., following a data
archiving run).
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 4
PSAPTINYD
16K Extent
PSAPSMALLD
160K Extent
PSAPMEDIUMD
5MB Extent
PSAPLARGED
160MB Extent
Singular Class
Strategy Summary
To summarize the reorganization strategy, we classify
and divide all database objects into Tiny, Small,
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
July/August 2005
Preparing to Reorganize
There are three tasks we need to perform in preparation for the reorganization:
1. Analyze the existing tablespaces.
2. Design the new tablespaces.
3. Communicate the reorganization strategy and
obtain approval.
Well walk through each task in turn in the
following sections.
Note!
All of the SQL scripts discussed in the article
are available for download at www.SAPpro.com.
Caution!
As I cautioned earlier, only SAP tablespaces are
in scope for your reorganization. Reorganizing
third-party or Oracle system tablespaces (system,
temp, rbs, undo) can interfere with the products
operation or support. Even if the third-party
vendor does support reorganization, be sure to
set up separate sets of tablespaces for your SAP
and non-SAP objects. Do not co-mingle SAP
and non-SAP data.
Your SAP schema name may be different. In this article, I use SAPR3
in all script examples.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 5
Figure 6
Tablespace
Class
Tiny
Small
Medium
Large
Singular
16
4,000
8,000
16,000
160
40,000
80,000
160,000
5,120
1,280,000
2,560,000
5,120,000
163,840
40,960,000
81,920,000
163,840,000
???*
* Remember that Singular objects are created on an as-needed basis, and their sizes depend on the tables they must contain. Singular
objects can be quite large, yet we still dont want to exceed 1,000 extents after theyre reorganized. To compute an extent size for a
Singular object, divide its current allocated size (in GB) by 750, multiply that by 1,000, then round the product to the next highest hundred.
A 350GB table works out to a 500MB extent size. After reorganizing, its tablespace will be 75% utilized, leaving room to grow.
class will be sized as needed to fit the tables they contain. The Uniform Extent Size (KB) column will be
used when we actually create the new tablespaces.
Additionally, Figure 6 shows the size of a table
when it has 250 extents; this is the target size for
classifying tables by size (indicated by the boldface
font). Tables in the classes can grow to 500 or even
1,000 extents; Figure 6 shows these sizes10 too for
illustrative purposes.
10
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Figure 7
July/August 2005
OBJ_TYPE
TINY
SMALL
MEDIUM
LARGE
SINGULAR
------------------------------------------------------------------------INDEX
29774
935
734
111
0
TABLE
25334
611
463
126
4
Note!
For our example, tables have an upper limit of
1,000 extents and a lower limit of 24 extents. Our
initial classification of tables will not exceed 250
extents, which represents just a fraction of the total
extents that we allow a table to have without being
reclassified. This will leave a sufficient amount
of room for the table to grow before needing to
be reclassified.
Note!
While 16K is the minimum extent size Oracle
allows, and works fine for SAP R/3 database
objects, a Tiny tables column could require a
24K or 32K minimum extent size if the Tiny table
is a large binary object. In these cases, you should
reorganize that table into the Small class.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 8
TABART TABSPACE
PCTI OFR OF OP OP
------------------------------------------------------USER7 PSAPTINYD
0
1
1 10 40
USR02 PSAPSMALLD
0
1
1 10 40
USR03 PSAPMEDIUMD
0
1
1 10 40
USR23 PSAPLARGED
0
1
1 10 40
USER5 PSAPDRAOD
0
1
1 10 40
Note!
When pitching the reorganization initiative, expect
a lot of initial pushback. Until you can convince
them that this strategy is sound, tested, and approved
by SAP, managers and other stakeholders will be
justifiably suspicious and resistant. Before
approaching anyone with this idea, compile an
arsenal of SAP Notes about moving tables between
tablespaces, information on third-party tools that
SAP has certified, and the results of the analysis
performed in Step 2. Youll then have an easier time
making the case that this type of reorganization is
endorsed by SAP, and the reorganization will just be
performed on a grand scale.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
July/August 2005
Note!
Remember, it is very important that the index
tablespaces not consist of uniform extents. Index
sizes are variable, so they will fit best into a
tablespace that can handle varying extent sizes.
Figure 9
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Note!
Another thing to notice in Figure 9 is that SAP
chooses to separate data and index tablespaces,
just as we intend to. You can tell because data
tablespaces predictably end with a D and index
spaces have an I.
Note!
In Figure 9, you are looking at a database while its
initial reorganization is in progress, so you can see
the new tablespaces along with the original SAP
tablespaces.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Figure 10
July/August 2005
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 11
Figure 12
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Figure 13
July/August 2005
Note!
Remember that this is a high-level demo of
LiveReorg and I will not be discussing all of
LiveReorgs parameters and capabilities in
the following sections. Contact the vendor
for detailed product information.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 14
Figure 15
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Figure 16
July/August 2005
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 17
Figure 18
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Figure 19
July/August 2005
Note!
Note!
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 20
Tip
As the tables are moved into the new tablespaces, they leave behind free-space extents and greatly increase the
Tablespace Freespace Fragmentation (TFF). It is possible to reclaim free space at the end of each data file,
however. You can try to shrink down tablespaces as you move objects out of them so that you can free up disk space
that can be allocated to the new tablespaces. Script ShrinkFilesHighFreeSpace.sql (available at www.SAPpro.com)
can be used to reduce the data file sizes to free up disk space on file systems. It ignores chunks of free space less
than 5MB in size. The script doesnt actually shrink the Oracle files, but it generates DDL syntax that can be used to
shrink the files. You will need to feed this syntax to SQL*Plus.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Figure 21
July/August 2005
Assign ABAP Dictionary Tables to the Tiny Class for the PSAPBTABD Tablespace
update sapr3.dd09l
set
tabart = (select tabart from sapr3.taora where tabspace = 'PSAPTINYD'
and rownum = 1)
where
tabart in (select tabart from sapr3.taora where tabspace = 'PSAPBTABD')
and as4local = 'A';
Caution!
You must first alter the script to name the tablespace you just emptied, which appears in boldface type in Figure 21.
Caution!
Do not use SAPDBA to drop/create the tablespaces that should be downsized. SAPDBA may delete its row from
SAPR3.TAORA, causing it to have a TABART of USER* when you re-add the tablespace, which will adversely affect
support packs. Instead, use Oracle Enterprise Manager to drop and re-create these tablespaces with a minimal disk
space of 50MB.
14
because youve moved all its tables into the new tablespaces. Two things need to happen at this point:
1. The ABAP Dictionary needs a special update for
the empty tablespace because there may be tables
defined in the dictionary that are assigned to this
tablespace but were not created in the Oracle database. You will assign these non-existing tables to
the Tiny class. The required script is shown in
Figure 21 and is available at www.SAPpro.com
under the name ABAP_Remaining_Tables.sql.
2. Decide if the empty tablespace gets dropped or
downsized. Lets refer to the SAPR3.TAORA
listing you saved at the very beginning of this
process (Figure 5). If the empty tablespaces
TABART value starts with USER or USR, then
drop it; you dont need it. However, if the empty
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Reorganization Without
LiveReorg
As I stated earlier, LiveReorg (or a similar third-party
tool15) is not required to use the reorganization strategy
outlined in this article, it just makes it easier.
Technically, you can execute reorganizations using
just Oracle SQL scripts and utilities. After all, moving
SAP tables between tablespaces isnt that complicated
of a procedure the vast majority of SAP tables can
be moved using a simple SQL alter tablemove
statement in SQL*Plus.
Note!
Exception!
The tables that cannot be moved this way contain
columns based on the LONG data type; these have
to be moved using Oracles export and import
utilities due to restrictions in Oracle SQL
language.
15
Tip
The great thing about Oracles SQL*Plus is that
you can write SQL statements that create new
SQL syntax that you feed back into SQL*Plus to
do some work for you, and do it all in one
smooth process.
16
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Figure 22
July/August 2005
Figure 22 shows samples of the SQL reorganization statements created as output from executing the
MoveObjects script. Notice how the three tables
from tablespace PSAPSTABD are Tiny and get moved
into the PSAPTINYD tablespace. Also notice that
each table yields two SQL statements: one to move
the table, and a second commented line to run the
script to move its indexes by rebuilding them. The
second statement is commented by design, so you
will need to edit17 the generated x.sql script to
remove the comment on the lines that rebuild the
table indexes.
If you can get scheduled downtime, move all the
tables first and then rebuild all the indexes afterward;
just run the RebuildIndex script once at the end of the
x.sql script.
If you cant get downtime but want a near-live
reorganization, move a table and then immediately
rebuild its indexes by running the RebuildIndex script
after each table is moved; uncomment all references
to RebuildIndex in the x.sql script.
A few final thoughts when using these scripts:
Schedule some time to run the generated reorganization script on a sandbox SAP database to get
17
Note!
Near-live refers to how Oracle will mark a
tables index as unusable when a table is
moved. Basically its like pulling the rug out from
under the indexes; the indexes point directly into
the table. When the table is moved all the indexs
pointers are immediately invalid so the index
must be rebuilt. Oracle marks the index status
unusable and the SAP application will not
be able to use the table until the indexes are
built. This is a brief service interruption in the
availability of the tables to SAP and is what I
call near-live.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
and that only database administrators should perform the required tasks.
database first.
Acquire and read the articles and SAP Notes referenced in this article.
Conclusion
Youve learned by now that a large SAP R/3 database
can be relatively easy to reorganize when a clear
strategy is combined with good skills and good tools.
Download all the scripts Ive provided and youll soon
be prepared to try this on a sandbox instance by using
the MoveObjects script method.
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.
July/August 2005
This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazines publisher, WIS, www.wispubs.com.