Oracle Performance For SAP

Boost SAP R/3 Performance
by Reorganizing Your Oracle

Database: A Proven
Reorganization Strategy
Charles Davis
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.
Charles Davis is the

Database Administration
Manager for Rohm and Haas
Company in Philadelphia,
Pennsylvania. He has over
19 years of experience with
CA-IDMS, DB2, SQL Server,
and Oracle, and has been
working with very large
SAP Oracle databases
for the past five years.
He can be reached at
CharlesDavis@rohmhaas.com.
To understand why, have a look at Figure 1 on the next page. It

shows the state of a typical Oracle tablespace (PSAPBTABD in the
example) after several months of SAP R/3 use. The boxes within the
tablespace represent extents Oracles word for a chunk of disk
space. The smallest boxes represent small extent sizes and the larger
boxes represent large extent sizes. In this case, the PSAPBTABD
tablespace has many extents of many different sizes, and chunks of free
space of many different sizes are distributed randomly throughout the
tablespace. This free-space distribution is called Tablespace Freespace
Fragmentation (TFF), and while it is unavoidable, TFF can significantly
degrade SAP system performance if not periodically corrected. Imagine
this on the scale of a modern SAP R/3 database (at Rohm and Haas
Company, our databases each have over 25,000 table definitions, 30,000
index definitions, and 80 tablespaces!). Contrast this with Figure 2,
which shows tablespaces after the type of reorganization proposed in
this article. Free-space fragments, when they do occur, are uniform in
size, which makes it much easier for the Oracle database to manage
object growth within a given tablespace.1
TFF can harm more than just performance; it can affect object
growth, disk space allocations, database maintenance, and backups,
1
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.
SAP Professional Journal
July/August 2005
because an object may not be able to find a free

chunk of the proper size, and because space is wasted
in the process. In fact, overly fragmented tablespaces
will cause CRITICAL_SEGMENT warnings within
SAPBRCONNECT CHECK reporting. If TFF is
not addressed, it can cause object unable to extend
errors in the Oracle Alert Log, possibly causing
SAP to protect your system by putting itself into
read-only mode.
Figure 1
A Fragmented Tablespace
PSAPBTABD
This article presents the database reorganization

strategy I devised and successfully use to manage
TFF for 24x7 SAP R/3 4.5 and higher environments
using Oracle 8i and 9i.2 Adapting this strategy, fully
or even partially, can improve your SAP database
performance, reduce your database disk space
requirements, maintain full SAP compliance for
your support agreement, and lighten your database
administration teams workload by enabling your
operations staff to run the reorganizations, as I did
at Rohm and Haas.
Fragmentation naturally happens to Oracle tablespaces that store objects of many different extent
sizes such as PSAPBTABD. It is neither a product
malfunction nor the result of a poor implementation.
Even after you reorganize your tables as described
in this article, youll have to periodically perform
subsequent reorganizations because tables constantly
change sizes.
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.
Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy
Figure 2
Tablespace After Reorganization
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.
See SAP Note 741688 (Integration Assessment for LiveReorg from

Quest Software Inc.): SAP is satisfied that deploying LiveReorg in
SAP production environments possesses no risk to SAP customers and
that such deployment will not affect support agreements between SAP
and its customers.
July/August 2005
Reorganization Strategy:
Three Key Tactics
Tiny for tables that are empty or do not exceed

16MB
Small for tables between 16MB and 160MB
Simply put, our strategy is that all SAP objects will be

stored together in tablespaces based solely upon the
size of the object. In other words, we will reorganize
the database so that like-sized objects (i.e., tables) will
share the same tablespace, and we will periodically
rebalance things as tables change in size.
Medium for tables between 160MB and 5GB
Large for tables between 5GB and 160GB
Singular for tables over 160GB
Operationally, the strategy consists of three

key tactics:
Classify all database objects according to their

allocated size.
Migrate like-sized objects to locally managed

tablespaces of uniform extent size.
Periodically reanalyze the database and migrate

objects that have grown or shrunk outside of
their classification.
Tiny, Small, Medium, and Large tables will be

placed in corresponding tablespaces created specifically for them. Singular tables will be placed in
tablespaces created and sized uniquely for them on
an as-needed basis. Figure 3 shows this classification
applied to the fragmented tablespace introduced earlier
in Figure 1 (note that a Singular tablespace is not
shown in Figure 3 due to size constraints).
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.
Lets discuss each tactic in more detail.
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.
Classify All Database Objects According to

Their Allocated Size
Classify your SAP tables based on their allocated size.
The five classes I suggest are:
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.
Figure 3
The Database Reorganization Strategy
PSAPBTABD
PSAPTINYD
16K Extent
PSAPSMALLD
160K Extent
PSAPMEDIUMD
5MB Extent
PSAPLARGED
160MB Extent
Objects are classified by their total allocated size and then

reorganized into the Uniform Extent Tablespace
Migrate Like-Sized Objects to Locally Managed

Tablespaces of Uniform Extent Size
Create eight tablespaces Tiny, Small, Medium,
and Large tablespaces for data objects, and Tiny,
Small, Medium, and Large tablespaces for indexes.
Separating data objects from indexes in this way is

required by SAP. You create individual tablespaces
for objects in the Singular class if necessary. Once
the tablespaces are created, you migrate the classified
objects to the new tablespaces.
July/August 2005
The important points to remember here are:
Our approach is to classify the data objects

according to their allocated size.
After the reorganization, all database objects will

be in our new set of tablespaces.
The SAP tablespaces will be empty after the

reorganization.
We will update the ABAP Dictionary during the

reorganization process to reflect the new
organization.
The last point is critical to avoid problems while

applying SAP support packages, OSS messages, etc.
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.
Periodically Reanalyze the Database and

Migrate Objects That Have Grown or Shrunk
Outside of Their Classification
While a one-time reorganization will go a long way
toward improving performance and simplifying administration, to keep your system humming you need to
monitor database table sizes and reorganize them periodically. After all, SAP databases are quite transient:
with business process changes (and even regular use),
objects can jump size classes rather rapidly.
The periodic reorganization is almost identical to

the initial reorganization with two key differences:
1. It takes substantially less time to plan and execute.
2. You should use extent counts rather than allocated
size for classification. Recall that for the initial
reorganization I suggested that you classify
objects based on their current total allocated size.
After the initial reorganization, however, I recommend switching your attention to table extent
counts. This will greatly simplify monitoring
because the same extent count limits are used
for each tablespace class. In the LiveReorg tour
later in this article, youll see where to find the
extent counts for each object.
But how often should one reevaluate table sizes?
And when should a database reorganization be
triggered? A realistic strategy would be to glance
monthly at the extent counts for each of the new
tablespace classes.
Apply predefined size tolerance limits e.g.,
tables that exceed upper limit extent counts (1,000)
or fall below lower limit extent counts (24) would
be reclassified and reorganized into the appropriate
class.6 Figure 4 illustrates this monthly reorg maintenance process.
Review the extent counts for the tables in each
tablespace. Counts greater than 1,000 extents would
force the table to be reclassified and moved into the
next higher class. Counts less than 24 extents force
the table to be reclassified and moved into the next
lower class. All others optionally can be reorganized
within their current tablespace to reclaim deleted row
space and to rebuild indexes.
Note!
Dont forget! Large objects are sometimes purged
and become small tables (e.g., following a data
archiving run).
For reclassification, tables cannot be smaller than Tiny or bigger than

Singular, so disregard these classes for a moment. Later well see that
the Large class extent size is 32 times the size of the Medium class
extent, which is 32 times the size of the Small class extent. So, for
example, a Medium table with only 24 extents would reclassify down
to a Small table of 768 extents. Later the table would have to grow to
1,000 extents before it would again classify as a Medium table of about
32 extents. If an object seems to waver on the edge between classes,
choose the higher class and leave it there to give it the lowest possible
extent count.
Figure 4
Monthly Table Review, Reclassification, and Reorganization
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,
Medium, Large, and Singular tablespaces based on

their current allocated size. Data and indexes are
divided into separate sets of these tablespaces per
SAPs requirement. We then periodically migrate
July/August 2005
objects that have grown or shrunk into different

classes subject to predefined tolerance limits according to analysis of their extent counts. The resulting
database will make the best use of available disk
space, perform significantly better (queries will run
faster), and ensure that tables will always be able to
find an available chunk of space into which to expand.7
databases is to query table SAPR3.TAORA8 using

SQL*Plus. SAPR3.TAORA is maintained by the
SAPDBA utility and contains a list of all data tablespaces for your SAP system, both SAP-standard and
non-SAP user tablespaces. Figure 5 shows the query
youll need to run in SQL*Plus, as well as some
sample output from our system at Rohm and Haas.
Lets now put our strategy into action by planning

and performing an actual reorganization.
A key field to look for in this table is TABART

it suggests the origin of each tablespace. Values
beginning with USR or USER are custom tablespaces
created by your database administration team for
installation of bolt-ons or complementary solutions,
etc. All other TABART values, such as APPL0, are
SAP-standard installed tablespaces. For example,
in Figure 5, tablespace PERFSTAT needed for
Oracles StatsPack utility has a TABART value
of USR22. In contrast, tablespaces PSAPBTABD
and PSAPPOOLD are SAP-standard tablespaces.
Tablespace PSAPGLPCAD in the example is a
Singular tablespace created for a very large table
called GLPCA as part of a previous reorganization.
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.
Once youve run the query, save its output by

either copying and pasting it into a Microsoft Word
document or spooling it to a disk file on your Oracle
server. Well refer to it later when we update the
ABAP Dictionary.
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.
Step 1: Analyze the Existing Tablespaces

As mentioned in the strategy overview, the first step
to planning your reorganization is to determine which
tables belong in which size class. To do this, we need
to capture a list of the current SAP tablespaces in the
database. The easiest way to get this list for Oracle
The tablespace will always provide space for objects to expand up to

the point that it is 100% full and cannot automatically extend itself.
Your SAP schema name may be different. In this article, I use SAPR3
in all script examples.
Figure 5
Script for Retrieving Allocated Table Sizes
select * from sapr3.taora;

TABART TABSPACE
PCTI OFR OF OP OP
------------------------------------------------------APPL0 PSAPSTABD
0000 001 01 10 40
APPL1 PSAPBTABD
0000 1
1 10 40
APPL2 PSAPPOOLD
0000 1
1 10 40
<< some output was omitted >>
USER
PSAPUSER1D
0000 1
1 10 40
USER1 PSAPUSER1D
0000 1
1 10 40
USR22 PERFSTAT
0
1
1 10 40
USER3 PSAPGLPCAD
0
1
1 10 40
Figure 6
Tablespace
Class
Tiny
Small
Medium
Large
Singular
Data Class Size Chart (KB = 1,024; K = 1,000)

Uniform Extent
Size (KB)
Object Total Size (K)

250 Extent Size (K)
500 Extent Size (K)
1,000 Extent Size (K)
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.
Step 2: Design the New Tablespaces

We will use the SAPDBA9 utility to create new locally
managed uniform extent tablespaces for the new
data classes.
Figure 6 shows my suggested values for the five
size classes we defined earlier. As you can see, Ive proposed using a 16KB extent size for Tiny tables, 160KB
for Small tables, 5,120KB for Medium tables, and
160MB for Large tables. Tablespaces of the Singular
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
See SAP Note 43191 for SAPDBA documentation and help.
Note that in Figure 6, KB is based on 1,024, but K is based on 1,000 to

produce nice round numbers.
Figure 7
July/August 2005
Data Class Size Chart
OBJ_TYPE
TINY
SMALL
MEDIUM
LARGE
SINGULAR
------------------------------------------------------------------------INDEX
29774
935
734
111
0
TABLE
25334
611
463
126
4
For the initial reorganization of the database,

the 250 Extent Size (K) column in the table shows
us the breakpoints for classifying the tables by size
and assigning them to one of the new tablespaces.
Based upon Figure 6, we could say that all tables
that are sized from 0K to 4,000K are Tiny tables;
all tables that are sized from 4,001K to 40,000K are
Small tables; tables sized 40,001K to 1,280,000K
are Medium tables; tables sized 1,280,001K to
40,960,000K are Large tables; and all tables larger
than 40,960,000K are Singular in size.
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.
Applying these classification rules will result in

all the tables having no more than 250 extents, which
will leave them room to grow to their 1,000 extent
limit before they must be reclassified.
Using these values, we can now determine
how many tablespaces well need. To simplify
this task, I developed a SQL*Plus script
CountObjectsBySize.sql to count the objects
falling into each of the defined classes (the script is
available for download at www.SAPpro.com). The
script will tell you, for example, how many Singular
tablespaces you need, and if you can omit any of the
standard classes (not likely). Figure 7 shows the output when run against our example database. Recall
that we will be creating a separate set of tablespaces
for indexes, so the number of indexes in each class is
reported separately.
As you can see, a disproportionate number of the
SAP R/3 database objects in our example database are
Tiny (this is likely the case in your own database as
well), which supports our strategy of putting them all
together into their own tablespace.
With this information in hand, theres one thing
left to do before actually creating the tablespaces and
executing the reorganization: quantifying the benefits
for and obtaining approval from stakeholders.
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.
Step 3: Communicate the Reorganization

Strategy and Obtain Approval
A final step before proceeding with the reorganization
is getting buy-in from management and other stakeholders. I list this requirement at this point, as
opposed to before the planning stage, because in
Figure 8
TAORA Entries for the Example Uniform Extent Data Tablespaces
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
order to estimate the benefits (or to see if you should

propose a reorganization effort at all), its wise to
collect all the facts and devise a strategy first.
5. Update the ABAP Dictionary for SAP

compliance.
The first step will be to create the new tablespaces
designed earlier.
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.
Executing the Reorganization

With a plan in place and stakeholder buy-in secured,
its time to explore the reorganization procedure,
which consists of the following five steps:
1. Create the new tablespaces.
2. List and sort the tablespace objects.
3. Select objects to reorganize.
4. Launch and monitor the reorganization run.
Step 1: Create the New Tablespaces

We will use the SAPDBA11 utility to create new
locally managed uniform extent tablespaces for the
new object classes.
When adding the new tablespaces to the database,
first allocate a data tablespace and then its index tablespace, as SAP requires. I suggest PSAP<class>D
(PSAPTINYD, for example) as your naming convention for data tablespaces and PSAP<class>I
(PSAPTINYI, for example) for index tablespaces.
Create the data tablespaces as locally managed
tablespaces with the uniform extent sizes listed
in Figure 6. Create index tablespaces as extent
management of local auto-allocate and manual
segment space management.
After youve created all of the tablespaces, query
table TAORA as you did earlier when analyzing the
tablespaces. You should see the new tablespaces listed
with a TABART value of USER*. Figure 8 shows the
TAORA entries for the uniform extent data tablespaces defined for the example. As you can see,
I have also included a Singular class tablespace named
PSAPDRAOD that holds a 360GB DRAO table.
11
See SAP Note 43191 for SAPDBA documentation and help.
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.
reorganization, and update the ABAP Dictionary.

Well cover these tasks in the remaining steps. Note
that these remaining steps must be repeated on each
in-scope tablespace until the objects are reorganized
into the new tablespaces and the original tablespaces
are empty.
Step 2: List and Sort the Tablespace Objects

Once the target tablespaces are created, the next
steps are to list and sort the tablespace objects, run the
Figure 9
We next need to launch LiveReorg (see the sidebar

on choosing a reorganization tool). Figure 9 shows
Tablespaces and Object Counts in LiveReorg
Choosing a Database Reorganization Tool

I use Quest Softwares LiveReorg tool to implement the database reorganization strategy presented
in this article. Remember that the strategy does not require LiveReorg; it just makes it easier than
generating and running Oracle DDL scripts to perform the reorganization. Aside from LiveReorgs ability
to run reorganizations with no downtime, its client software lets you easily sort and re-sort lists of tables
by their sizes so that you can, en masse, reorganize many tables with very little effort.
In fact, my database administration team is too few to handle all of the reorganizations we need, but this
methodology is so simple to implement that our operations staff runs the reorganizations by following
simple written instructions. The LiveReorg tools ease-of-use and the simplicity of this strategy makes
this possible.
This is not an endorsement of the Quest tool, however. Other vendors also have live reorganization
tools, such as BMC. Research these products and get one of them, they are well worth the money. They
eliminate downtime, which your management and users will love, database administration time and effort
will be greatly reduced, and reorganization success will be greatly increased. After all, if your database
administrators are dealing with many terabytes of databases, and many instances of SAP databases,
you need the speed and accuracy of a reorganization tool.
LiveReorgs Explorer screen after connecting to our

example Oracle database and retrieving a list of tablespaces and object counts. The Explorer is divided into
three areas: an overview pane on the left, a subobjects
list pane on the bottom right, and a panel with specific
object details at the top. As you can see in Figure 9,
Ive selected the database in the overview pane. As
expected, the complete list of subobjects (tablespaces)
is displayed in the subobjects list pane. Clicking on any
of the tablespaces in the subobjects list pane brings up
its storage, object count, and allocated vs. free space
statistics on the detail panel at the top. You can easily
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.
view similar information for specific tables by clicking

on a tablespace in the overview pane.
Notice the variety of tablespaces in the standard
SAP R/3 database. For example, tablespace
PSAPBTABD has over 4,000 tables in it, and
at the moment, the bar graph shows PSAPBTABD
as only about half utilized. In contrast, two non-SAP
tablespaces named PSAPBSISD and PSAPDCLSD
are single-table tablespaces. We will reorganize and
empty each of these tablespaces and later drop them
to reclaim disk space. Doing so will improve our
overall disk space utilization.
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.
Figure 10
July/August 2005
Viewing the Tables in Tablespace PSAPTINYD
To inspect the details of individual tables

within a tablespace, have a look at Figure 10 and
Figure 11. In Figure 10, Ive scrolled down in the
left pane of the Explorer window and clicked on
tablespace PSAPTINYD in order to review its subobjects (i.e., tables). I then clicked on the Extents
column to sort them by size, largest to smallest.
Notice how the extent size is 16K for all objects,
indicative of the uniform extent size tablespace.
In Figure 11, Ive navigated to the PSAPSMALLD
tablespace and sorted its tables from largest to smallest.
Notice that the largest object is 230 extents totaling
36,800KB.
Similarly, list and sort the objects by size for
each tablespace to be reorganized. Then apply the
250 Extent Size (K) cutoff size from the size chart
(Figure 6) to classify the objects accordingly.
Step 3: Select Objects to Reorganize

Now that weve classified the objects into their
appropriate size classes, the next step is to use the

Reorg Manager to reorganize:
Tiny objects into the PSAPTINYD (data)

and PSAPTINYI (indexes) tablespaces
Small objects into the PSAPSMALLD (data)

and PSAPSMALLI (indexes) tablespaces
Medium objects into the PSAPMEDIUMD

(data) and PSAPMEDIUMI (indexes) tablespaces
Large objects into the PSAPLARGED (data)

and PSAPLARGEI (indexes) tablespaces
Singular objects and indexes into the appropriate

Singular tablespace
To keep things simple, I will show you how to

set up and execute a reorganization run for a single
Tiny table, SAPR3.DSTDB6, located in tablespace
PSAPDDICD.
Figure 12 shows the details for this table, along
with other tables in tablespace PSAPDDICD. As you
Figure 11
Viewing the Tables in Tablespace PSAPSMALLD
Figure 12
Table SAPR3.DSTDB6 in Tablespace PSAPDDICD
Figure 13
July/August 2005
Assign the Table to the PSAPTINYD Tablespace
can see, the current size of table SAPR3.DSTDB6

is 16KB. Since its a Tiny table according to our
classification system, it should be reorganized into
the target tablespace PSAPTINYD.
To add this table to the Reorg Manager, right-click
on the table name in the subobjects list pane and
select Reorg Manager from the context menu.
LiveReorg will chug a bit as it gathers information
from Oracle about the table definition and its indices,
and then present a series of screens to control the
reorganization process. Lets review each screen
in more detail.
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.
The Select Reorganization Method Screen

The Select Reorganization Method screen (Figure 13)
asks for three key things: a reorganization method,
a data movement method, and target tablespaces for
data and indexes.
Select the new tablespaces as shown in the figure,
and then click on Next.
The Choose Scripting Options Screen
The Choose Scripting Options screen (Figure 14)
consists of mostly database administration stuff,
such as statistics, commit counts, and so on.
Again, were setting some basic options here
e.g., Parallel Query Option but mostly just accepting the defaults. Click on Next again.
The Define Storage Strategy Screen
The Define Storage Strategy screen (Figure 15)
asks us to define key storage information, including
Figure 14
Setting Options for the Reorganization
Figure 15
Setting Storage Options
Figure 16
July/August 2005
Set Allocations for a Tables Reorganization
whether fixed or variable extents will be used vs.

whether they will be compressed.
Our strategy is to define this at the tablespace (vs.
object) level, however, so select the Use Tablespace
Defaults option. All extent attributes will thereafter
be inherited from the tablespace, greatly simplifying
maintenance.
The Customize Object Allocations Screen
The Customize Object Allocations screen (Figure 16)
can be used to set all sorts of different parameters for
each object. The example shown in the screenshot is
for only one table, but there could be 100 tables in the
object list. Keep in mind, however, that changing
parameters for each table can get tedious because
you have to click on each object to set specific sizing
options for it, such as Pct Free and Pct Used, so be
judicious about undertaking this task.
LiveReorg will eventually create a lengthy script
that it will use to run the reorganization. I skip this
screen here for simplicity, but you can open the

script later if you wish and use it to easily make
Find/Replace changes to objects, such as setting
all Pct Used values to the same percentage.
The Review Space Usage Screen

The Review Space Usage screen (Figure 17) summarizes the planned database movements to be made by
the reorganization run. A few clicks after this screen,
you are finally asked to name and save the reorganization script.12
Step 4: Launch and Monitor the Reorganization

Run
Once a script is saved, it appears in the Job Monitor.
To execute the script, right-click on it, as shown in
Figure 18, and then select Execute.
12
LiveReorg scripts get saved into a dedicated LiveReorg tablespace in the

database.
Figure 17
Preview of Changes That Will Result from the Reorganization
Figure 18
Locating and Executing a Reorganization Script in the Job Monitor
Figure 19
July/August 2005
The Executed Reorganization
Note!
Note!
LiveReorg created its own proprietary

reorganization script and process log for the
example. Both are too large to be printed here,
but they are available for download from
www.SAPpro.com. The file names are
LR_Script.sql and LR_Script.log.
During a full-scale reorganization you could

define additional reorganization scripts with
several tables in each script and subsequently
launch them concurrently.
In this case, the script runs very quickly and the

result is shown under the Status Message column
(see Figure 19).
To review the results, close the Job Monitor

by clicking on the lower window close box. The
Explorer window appears again. Refresh the display
by pressing F5. Youll see that table DSTDB6 is
Figure 20
A Refresh Display Shows Table DSTDB6 in Tablespace PSAPTINYD
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.
gone from its original tablespace PSAPDDICD (not

shown). Clicking on the PSAPTINYD tablespace
(see Figure 20) reveals that table DSTDB6 is in the
new tablespace.
Step 5: Update the ABAP Dictionary for SAP

Compliance
After you have reorganized several tables, you need
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.
to update the ABAP Dictionary to tell SAP R/3

that those tables are now stored in the new
tablespaces.
Script ABAP_Update.sql (available at
www.SAPpro.com) does this. It finds all the tables
stored in the new tablespaces and updates the ABAP
Dictionary,13 specifically table SAPR3.DD09L.14
You should run this script after a reorganization
has just finished.
After some time, lets suppose you have reached
a point where the PSAPBTABD tablespace is empty
13
See SAP Note 154193, SAPDBA: Reorganizations and ABAP-DDIC;

this script is adapted from the note.
14
Remember, your SAP schema name might be different.
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
tablespaces TABART is anything other than

USER or USR, then it is an SAP-installed tablespace. The tablespace will be kept and will have
no tables stored in it, so it will be greatly downsized to save disk space. The fastest way to downsize the tablespace is to drop it and then
immediately create it again.
Thats it! Youve now completed the database
reorganization and made the necessary updates to
the ABAP Dictionary to ensure a high-performing,
smooth-running system. In the next section, Ill show
you how you can complete these same tasks without
using the LiveReorg tool.
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.
The use of Oracle scripts and utilities instead of

LiveReorg, however, means you must take your SAP
system offline while doing reorganizations. If you can
live without this live capability, this barebones
method may suffice.
Ive included two scripts16 MoveObjects
and RebuildIndexesIntoUE (available at
www.SAPpro.com) to mimic the core behavior of
LiveReorg. For safety, both scripts as delivered make
no changes to your SAP database. Ive commented
out those parts, so youll need to uncomment them to
use the scripts productively.
Script MoveObjects classifies your SAP tables by
size, creates SQL statements to move each table into
its assigned tablespace, and spools all of this into a
reorganization script named x.sql that you can then run
in SQL*Plus to actually perform the reorganization.
Script RebuildIndexesIntoUE is called within
the x.sql script after each table is moved and it moves
the indexes into the assigned index tablespace by
rebuilding it.
The scripts Ive provided with this section

(available at www.SAPpro.com) replace only the
LiveReorg portion of this article. All the other
pieces of the strategy remain intact, including
the ABAP Dictionary update scripts. After all,
SAP does not care how the tables get moved
around between tablespaces it just cares that
the ABAP Dictionary and database are in sync.
15
BMCs Space Expert is another fine product that can run

reorganizations live (see www.bmc.com/products/
proddocview/0,2832,19052_19429_23278_7784,00.html).
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
The actual script names are MoveObjectsBySize_Without_LR.sql and

RebuildIndexesIntoUE_Without_LR.sql.
Figure 22
July/August 2005
Example Statements Output by the MoveObjects Script
/* PSAPSTABD 16K */ alter table SAPR3.VIWB70 move online tablespace

PSAPTINYD;
rem @RebuildIndexesIntoUE_Without_LR.sql
/* PSAPSTABD 16K */ alter table SAPR3.VIWEGB move online tablespace
PSAPTINYD;
/* PSAPSTABD 16K */ alter table SAPR3.VIWEGR move online tablespace
PSAPTINYD;
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
I use a Microsoft Windows-based text editor called UltraEdit, a cheap

and cheerful solution for folks like me that find the Unix vi editor
incomprehensible. UltraEdit has a built-in FTP to move text files from
and to Unix servers and a Notepad-style text editor. The Emacs and
Textpad editors are also fine tools.
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.
comfortable with it and to test it thoroughly in

your environment first.
Tables that cannot be moved by the script (i.e.,

those with a LONG data type column) will give an
output error; these tables must be moved with
Oracles export/import utility. The exporting
and importing of tables cannot be done live,
so youll need to schedule an outage for the SAP
system and prepare the export/import process to
do this final move.
For tablespaces you have exempted from the

reorganization strategy, edit the MoveObjects
script and add the tablespace names, such as
PERFSTAT, etc. I did not use these scripts to
run my reorganizations, because I use LiveReorg,

but they have been unit tested and work well.
Keep in mind that this is a very hands-on method,
When LiveReorg is building and sorting indexes

on tables, it will compete with SAP for the
saptemp tablespace, especially when reorganizing
Large tables and their indexes.
and that only database administrators should perform the required tasks.
Succeeding with Ongoing Reorganizations
Tips for Success

Here are some final things to keep in mind to make
your reorganization process go smoothly:
I strongly caution you to not use this strategy on
On a periodic basis you are going to look at the extent

counts of all the tables in the new tablespaces and
move some tables. Here are some tips for success:
Tables with more than 1,000 extents could be

reorganized into the next higher data class.
your SAP BW databases. It is a completely

different beast from SAP R/3 with regard to
object creation and tablespace assignment.
Tables with less than 24 extents could be reorgan-
Test this strategy thoroughly on a sandbox SAP
Tables could also be reorganized in-place, in their
database first.
Get familiar with what the scripts are doing and

the information they read or update from the
ABAP Dictionary.
Acquire and read the articles and SAP Notes referenced in this article.
Dont reorganize tables that are being loaded or

purged. Schedule reorganizations around these
activities.
ized into the next lower data class.
same tablespace, to reclaim disk space if archiving

or purging has taken place on some tables.
Run the shrink files process to reclaim freespace

at the end of the database files.
Review the SAP default tablespaces, such as

PSAPBTABD and others. You will likely find one
or two tables in there as a result of support packages and OSS messages, etc. They should
be classified by size and reorganized into the
new tablespaces. Be sure to run the ABAP
update script.
When adding new tablespaces to an SAP system

that is the source for transports, make sure to also
add the new tablespaces to the target systems of
the transports. Transports sometimes look for
the TABART values to store tables, so they must
exist on the target SAP systems, otherwise the
transport fails.
Be aware that LiveReorg executes like it is a data

load process, so it will consume some resources
on your database server.
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.
July/August 2005
Keep in mind that this strategy will continue

to evolve as future Oracle versions bring us everimproving disk space management capabilities. One
day soon you may be reorganizing all of these new
tablespaces into a single big-file tablespace in
Oracle 10g to have Oracle manage the fragmentation,
and when that time comes you will be well prepared
to start taking advantage of the benefits. You can even
adapt this strategy for any non-SAP Oracle database

simply by omitting the ABAP update step.
Database reorganizations are an essential part
of good database performance. Complement your
investment in the SAP application by acquiring good
database administration tools and reap the rewards of
this proven strategy.

Oracle Performance For SAP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Performance For SAP

Uploaded by

Copyright:

Available Formats

Boost SAP R/3 Performance

by Reorganizing Your Oracle

Charles Davis is the

To understand why, have a look at Figure 1 on the next page. It

SAP Professional Journal

because an object may not be able to find a free

This article presents the database reorganization

Tablespace After Reorganization

See SAP Note 741688 (Integration Assessment for LiveReorg from

SAP Professional Journal

Tiny for tables that are empty or do not exceed

Small for tables between 16MB and 160MB

Simply put, our strategy is that all SAP objects will be

Medium for tables between 160MB and 5GB

Large for tables between 5GB and 160GB

Singular for tables over 160GB

Operationally, the strategy consists of three

Classify all database objects according to their

Migrate like-sized objects to locally managed

Periodically reanalyze the database and migrate

Tiny, Small, Medium, and Large tables will be

Lets discuss each tactic in more detail.

Classify All Database Objects According to

The Database Reorganization Strategy

Objects are classified by their total allocated size and then

Migrate Like-Sized Objects to Locally Managed

Separating data objects from indexes in this way is

SAP Professional Journal

The important points to remember here are:

Our approach is to classify the data objects

After the reorganization, all database objects will

The SAP tablespaces will be empty after the

We will update the ABAP Dictionary during the

The last point is critical to avoid problems while

Periodically Reanalyze the Database and

The periodic reorganization is almost identical to

For reclassification, tables cannot be smaller than Tiny or bigger than

Monthly Table Review, Reclassification, and Reorganization

Medium, Large, and Singular tablespaces based on

SAP Professional Journal

objects that have grown or shrunk into different

databases is to query table SAPR3.TAORA8 using

Lets now put our strategy into action by planning

A key field to look for in this table is TABART

Once youve run the query, save its output by

Step 1: Analyze the Existing Tablespaces

The tablespace will always provide space for objects to expand up to

Script for Retrieving Allocated Table Sizes

select * from sapr3.taora;

Data Class Size Chart (KB = 1,024; K = 1,000)

Object Total Size (K)

500 Extent Size (K)

1,000 Extent Size (K)

Step 2: Design the New Tablespaces

See SAP Note 43191 for SAPDBA documentation and help.

Note that in Figure 6, KB is based on 1,024, but K is based on 1,000 to

SAP Professional Journal

Data Class Size Chart

For the initial reorganization of the database,

Applying these classification rules will result in

Step 3: Communicate the Reorganization

TAORA Entries for the Example Uniform Extent Data Tablespaces

order to estimate the benefits (or to see if you should