SAP R/3 Performance Reorganization - Oracle DB Reorganization

This article appeared in the July/Aug 2005 issue of SAP Professional Journal, www.sappro.com, and appears here with permission of the magazine’s publisher, WIS, www.wispubs.com.

Charles Davis is theDatabase AdministrationManager for Rohm and HaasCompany in Philadelphia,Pennsylvania. He has over19 years of experience withCA-IDMS, DB2, SQL Server,and Oracle, and has beenworking with very large SAP Oracle databases for the past five years. He can be reached [email protected].

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 it’s true, even for medium-sized SAP installations.

To understand why, have a look at Figure 1 on the next page. Itshows the state of a typical Oracle tablespace (PSAPBTABD in theexample) after several months of SAP R/3 use. The boxes within thetablespace represent “extents” — Oracle’s word for a chunk of diskspace. The smallest boxes represent small extent sizes and the largerboxes represent large extent sizes. In this case, the PSAPBTABDtablespace has many extents of many different sizes, and chunks of freespace of many different sizes are distributed randomly throughout thetablespace. This free-space distribution is called Tablespace FreespaceFragmentation (TFF), and while it is unavoidable, TFF can significantlydegrade SAP system performance if not periodically corrected. Imaginethis on the scale of a modern SAP R/3 database (at Rohm and HaasCompany, our databases each have over 25,000 table definitions, 30,000index 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 insize, which makes it much easier for the Oracle database to manageobject growth within a given tablespace.1

TFF can harm more than just performance; it can affect objectgrowth, disk space allocations, database maintenance, and backups,

Boost SAP R/3 Performance

by Reorganizing Your Oracle

Database: A Proven

Reorganization Strategy

Charles Davis

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 alot of wasted space.

http://www.sappro.com


http://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 wastedin the process. In fact, overly fragmented tablespaceswill cause CRITICAL_SEGMENT warnings withinSAPBRCONNECT 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.

This article presents the database reorganizationstrategy I devised and successfully use to manage TFF for 24x7 SAP R/3 4.5 and higher environmentsusing Oracle 8i and 9i.2 Adapting this strategy, fullyor even partially, can improve your SAP database performance, reduce your database disk spacerequirements, maintain full SAP compliance for your support agreement, and lighten your databaseadministration team’s workload by enabling youroperations staff to run the reorganizations, as I did at Rohm and Haas.

Fragmentation naturally happens to Oracle table-spaces that store objects of many different extent sizes such as PSAPBTABD. It is neither a productmalfunction nor the result of a poor implementation.Even after you reorganize your tables as described in this article, you’ll have to periodically perform subsequent reorganizations because tables constantlychange sizes.

�� Note!

In addition to a reorganization strategy andprocedures, a good application performancemanagement plan requires writing efficientqueries, proper batch job scheduling, gooddatabase design, and other such elements, to name a few.

��

Figure 1 A Fragmented Tablespace

2 The strategy was born from dozens of white papers, scripts, newsgrouppostings, SAP Notes, technical manuals, and books, and thus reflectsthe latest in industry best practices and lessons learned. I merely opti-mized this information for SAP R/3 Oracle databases.



Boost SAP R/3 Performance by Reorganizing Your Oracle Database: A Proven Reorganization Strategy


�� Note!

This article assumes some background in databasemanagement. For this reason, and because such a large body of knowledge already exists on thistopic,3 I will not discuss database management in detail in this article. Also, the screenshots Iprovide are a high-level demo of Quest Software’sLiveReorg, an SAP-approved third-party tool thatwe use at Rohm and Haas. The strategy presentedin the article does not require LiveReorg, but usingLiveReorg lets you run reorganizations on a livesystem. You might also use BMC’s Space Experttool for a live reorg capability. Later in thearticle, I’ll talk about using Oracle SQL scripts to implement this strategy in a near-live manner.

��

Figure 2 Tablespace After Reorganization

3 For starters, see Oracle white paper #711 (How to Stop Defragmentingand Start Living: The Definitive Word on Fragmentation) available atwww.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.”

4 See SAP Note 741688 (Integration Assessment for LiveReorg fromQuest Software Inc.): “SAP is satisfied that deploying LiveReorg inSAP production environments possesses no risk to SAP customers andthat such deployment will not affect support agreements between SAPand its customers.”

� Caution!

Although I’ve tested the reorganization strategypresented in this article extensively at Rohm and Haas, as with all procedures on mission-critical 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 beforeattempting any reorganization, and always have a fallback plan in case something unexpectedhappens. Using SAP-approved tools such asLiveReorg maintains full compliance with theABAP Dictionary and will not invalidate your SAP support agreement.4





Reorganization Strategy:Three Key TacticsSimply put, our strategy is that all SAP objects will bestored together in tablespaces based solely upon thesize of the object. In other words, we will reorganizethe database so that like-sized objects (i.e., tables) willshare the same tablespace, and we will periodicallyrebalance things as tables change in size.

Operationally, the strategy consists of three key tactics:

• Classify all database objects according to theirallocated size.

• Migrate like-sized objects to locally managedtablespaces of uniform extent size.

• Periodically reanalyze the database and migrateobjects that have grown or shrunk outside of their classification.

Let’s discuss each tactic in more detail.

� Caution!

As you will see, it’s important to include only SAPtablespaces in your reorganization unless you have express clearance from third-party vendorsfor their tablespaces. Reorganizing third-party or Oracle system tablespaces can interfere withyour SAP system’s operation or support. It’s alsoimportant to separate SAP and non-SAP databaseobjects into different tablespaces. In an upcomingsection, I will show you how to differentiate SAPfrom non-SAP tablespaces.

Classify All Database Objects According toTheir Allocated Size

Classify your SAP tables based on their allocated size.The five classes I suggest are:

• Tiny for tables that are empty or do not exceed16MB

• Small for tables between 16MB and 160MB

• Medium for tables between 160MB and 5GB

• Large for tables between 5GB and 160GB

• Singular for tables over 160GB

Tiny, Small, Medium, and Large tables will beplaced in corresponding tablespaces created specifi-cally for them. Singular tables will be placed in tablespaces created and sized uniquely for them on an as-needed basis. Figure 3 shows this classificationapplied to the fragmented tablespace introduced earlierin Figure 1 (note that a Singular tablespace is notshown in Figure 3 due to size constraints).

�� Note!

The suggested size limits originate from Oracle’srecommendations in the white paper on databasefragmentation.5 The white paper proposes threesizes of classes that I’ve termed Small, Medium,and Large. I created the Tiny class with thesmallest allowable Oracle extent size to betteraccommodate the myriad tiny and empty tables in an SAP R/3 database. I’ve also added theSingular class for the few very large tables thatwould exceed the upper limit of extent counts I want to manage in the Large class.

�� Note!

After this strategy is fully implemented, all SAP-installed original tablespaces will be kept emptyand minimally sized to maintain support packagecompatibility.

5 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.





Migrate Like-Sized Objects to Locally ManagedTablespaces of Uniform Extent SizeCreate 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 isrequired by SAP. You create individual tablespacesfor objects in the Singular class if necessary. Once the tablespaces are created, you migrate the classifiedobjects to the new tablespaces.

�� !"��

��#�$$� !%"��

��#��#�&#��

��$�'(�� !%#��

��

)*��+�,��+��+��-��+��

Figure 3 The Database Reorganization Strategy





The important points to remember here are:

• Our approach is to classify the data objectsaccording to their allocated size.

• After the reorganization, all database objects willbe in our new set of tablespaces.

• The SAP tablespaces will be empty after the reorganization.

• We will update the ABAP Dictionary during thereorganization process to reflect the new organization.

The last point is critical to avoid problems whileapplying SAP support packages, OSS messages, etc.

�� Note!

Although we will empty the standard SAP tablespaces,we will not delete them. Support packagesoccasionally contain new SAP-issued tables that areset up to be stored in original SAP tablespaces, so they must still exist in order to receive a new table.

Periodically Reanalyze the Database andMigrate Objects That Have Grown or ShrunkOutside of Their Classification

While a one-time reorganization will go a long waytoward improving performance and simplifying admin-istration, to keep your system humming you need tomonitor database table sizes and reorganize them peri-odically. After all, SAP databases are quite transient:with business process changes (and even regular use),objects can jump size classes rather rapidly.

�� Note!

Don’t forget! Large objects are sometimes purgedand become small tables (e.g., following a dataarchiving run).

The periodic reorganization is almost identical tothe initial reorganization with two key differences:

1. It takes substantially less time to plan and execute.

2. You should use extent counts rather than allocatedsize for classification. Recall that for the initialreorganization I suggested that you classifyobjects based on their current total allocated size.After the initial reorganization, however, I recom-mend switching your attention to table extentcounts. This will greatly simplify monitoringbecause the same extent count limits are used for each tablespace class. In the LiveReorg tourlater in this article, you’ll see where to find theextent 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 glancemonthly at the extent counts for each of the newtablespace 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 appropriateclass.6 Figure 4 illustrates this monthly reorg mainte-nance process.

Review the extent counts for the tables in eachtablespace. Counts greater than 1,000 extents wouldforce the table to be reclassified and moved into thenext higher class. Counts less than 24 extents forcethe table to be reclassified and moved into the nextlower class. All others optionally can be reorganizedwithin their current tablespace to reclaim deleted rowspace and to rebuild indexes.

6 For reclassification, tables cannot be smaller than Tiny or bigger thanSingular, so disregard these classes for a moment. Later we’ll see thatthe Large class extent size is 32 times the size of the Medium classextent, which is 32 times the size of the Small class extent. So, forexample, a Medium table with only 24 extents would reclassify down to a Small table of 768 extents. Later the table would have to grow to1,000 extents before it would again classify as a Medium table of about32 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 possibleextent count.





Strategy Summary

To summarize the reorganization strategy, we classifyand divide all database objects into Tiny, Small,

Medium, Large, and Singular tablespaces based ontheir current allocated size. Data and indexes aredivided into separate sets of these tablespaces perSAP’s requirement. We then periodically migrate

�� !"��

��#�$$� !%"��

��#��#�&#��

��$�'(�� !%#��

��-.��/��

Figure 4 Monthly Table Review, Reclassification, and Reorganization





objects that have grown or shrunk into differentclasses subject to predefined tolerance limits accord-ing to analysis of their extent counts. The resultingdatabase will make the best use of available diskspace, perform significantly better (queries will runfaster), and ensure that tables will always be able tofind an available chunk of space into which to expand.7

Let’s now put our strategy into action by planningand performing an actual reorganization.

Preparing to ReorganizeThere are three tasks we need to perform in pre-paration for the reorganization:

1. Analyze the existing tablespaces.

2. Design the new tablespaces.

3. Communicate the reorganization strategy andobtain approval.

We’ll 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.

Step 1: Analyze the Existing Tablespaces

As mentioned in the strategy overview, the first step to planning your reorganization is to determine whichtables belong in which size class. To do this, we needto capture a list of the current SAP tablespaces in thedatabase. The easiest way to get this list for Oracle

databases is to query table SAPR3.TAORA8 usingSQL*Plus. SAPR3.TAORA is maintained by theSAPDBA utility and contains a list of all data table-spaces for your SAP system, both SAP-standard andnon-SAP user tablespaces. Figure 5 shows the queryyou’ll need to run in SQL*Plus, as well as some sample output from our system at Rohm and Haas.

A key field to look for in this table is TABART —it suggests the origin of each tablespace. Valuesbeginning with USR or USER are custom tablespacescreated by your database administration team forinstallation of bolt-ons or complementary solutions,etc. All other TABART values, such as APPL0, areSAP-standard installed tablespaces. For example,in Figure 5, tablespace PERFSTAT — needed forOracle’s StatsPack utility — has a TABART value of USR22. In contrast, tablespaces PSAPBTABD and PSAPPOOLD are SAP-standard tablespaces.Tablespace PSAPGLPCAD in the example is aSingular tablespace created for a very large tablecalled GLPCA as part of a previous reorganization.

Once you’ve run the query, save its output byeither copying and pasting it into a Microsoft Worddocument or spooling it to a disk file on your Oracleserver. We’ll refer to it later when we update theABAP Dictionary.

� Caution!

As I cautioned earlier, only SAP tablespaces are in scope for your reorganization. Reorganizingthird-party or Oracle system tablespaces (system,temp, rbs, undo) can interfere with the product’soperation or support. Even if the third-partyvendor does support reorganization, be sure to set up separate sets of tablespaces for your SAPand non-SAP objects. Do not co-mingle SAP and non-SAP data.

7 The tablespace will always provide space for objects to expand up to the point that it is 100% full and cannot automatically extend itself.

8 Your SAP schema name may be different. In this article, I use SAPR3in all script examples.





Step 2: Design the New Tablespaces

We will use the SAPDBA9 utility to create new locallymanaged uniform extent tablespaces for the new data classes.

Figure 6 shows my suggested values for the fivesize classes we defined earlier. As you can see, I’ve pro-posed using a 16KB extent size for Tiny tables, 160KBfor Small tables, 5,120KB for Medium tables, and160MB for Large tables. Tablespaces of the Singular

class will be sized as needed to fit the tables they con-tain. The Uniform Extent Size (KB) column will beused when we actually create the new tablespaces.

Additionally, Figure 6 shows the size of a tablewhen it has 250 extents; this is the target size for classifying tables by size (indicated by the boldfacefont). Tables in the classes can grow to 500 or even1,000 extents; Figure 6 shows these sizes10 too forillustrative purposes.

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 40APPL1 PSAPBTABD 0000 1 1 10 40APPL2 PSAPPOOLD 0000 1 1 10 40

<< some output was omitted >>USER PSAPUSER1D 0000 1 1 10 40USER1 PSAPUSER1D 0000 1 1 10 40USR22 PERFSTAT 0 1 1 10 40USER3 PSAPGLPCAD 0 1 1 10 40

9 See SAP Note 43191 for SAPDBA documentation and help.

TablespaceClass

Uniform ExtentSize (KB)

Object Total Size (K)

250 Extent Size (K) 500 Extent Size (K) 1,000 Extent Size (K)

Tiny 16 4,000 8,000 16,000

Small 160 40,000 80,000 160,000

Medium 5,120 1,280,000 2,560,000 5,120,000

Large 163,840 40,960,000 81,920,000 163,840,000

Singular ???*

* Remember that Singular objects are created on an as-needed basis, and their sizes depend on the tables they must contain. Singularobjects can be quite large, yet we still don’t want to exceed 1,000 extents after they’re reorganized. To compute an extent size for aSingular 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.

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

10 Note that in Figure 6, KB is based on 1,024, but K is based on 1,000 toproduce nice round numbers.





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 sizeand 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 areSmall tables; tables sized 40,001K to 1,280,000K are Medium tables; tables sized 1,280,001K to40,960,000K are Large tables; and all tables largerthan 40,960,000K are Singular in size.

Applying these classification rules will result inall the tables having no more than 250 extents, whichwill leave them room to grow to their 1,000 extentlimit before they must be reclassified.

Using these values, we can now determine how many tablespaces we’ll need. To simplify this task, I developed a SQL*Plus script —CountObjectsBySize.sql — to count the objectsfalling into each of the defined classes (the script isavailable for download at www.SAPpro.com). Thescript will tell you, for example, how many Singulartablespaces you need, and if you can omit any of thestandard classes (not likely). Figure 7 shows the out-put when run against our example database. Recallthat we will be creating a separate set of tablespacesfor indexes, so the number of indexes in each class isreported separately.

As you can see, a disproportionate number of theSAP R/3 database objects in our example database areTiny (this is likely the case in your own database aswell), which supports our strategy of putting them alltogether into their own tablespace.

With this information in hand, there’s one thingleft to do before actually creating the tablespaces andexecuting the reorganization: quantifying the benefitsfor and obtaining approval from stakeholders.

Step 3: Communicate the ReorganizationStrategy and Obtain Approval

A final step before proceeding with the reorganizationis getting buy-in from management and other stake-holders. I list this requirement at this point, asopposed to before the planning stage, because in

Figure 7 Data Class Size Chart

OBJ_TYPE TINY SMALL MEDIUM LARGE SINGULAR-------------------------------------------------------------------------INDEX 29774 935 734 111 0TABLE 25334 611 463 126 4

�� Note!

For our example, tables have an upper limit of1,000 extents and a lower limit of 24 extents. Ourinitial classification of tables will not exceed 250extents, which represents just a fraction of the totalextents that we allow a table to have without beingreclassified. 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 Oracleallows, and works fine for SAP R/3 databaseobjects, a Tiny table’s column could require a 24K or 32K minimum extent size if the Tiny table is a large binary object. In these cases, you shouldreorganize that table into the Small class.





order to estimate the benefits (or to see if you shouldpropose a reorganization effort at all), it’s wise to collect all the facts and devise a strategy first.

�� Note!

When pitching the reorganization initiative, expecta lot of initial pushback. Until you can convincethem that this strategy is sound, tested, and approvedby SAP, managers and other stakeholders will bejustifiably suspicious and resistant. Beforeapproaching anyone with this idea, compile anarsenal of SAP Notes about moving tables betweentablespaces, information on third-party tools thatSAP has certified, and the results of the analysisperformed in Step 2. You’ll then have an easier timemaking the case that this type of reorganization isendorsed by SAP, and the reorganization will just beperformed on a grand scale.

Executing the Reorganization With a plan in place and stakeholder buy-in secured,it’s 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.

5. Update the ABAP Dictionary for SAP compliance.

The first step will be to create the new tablespacesdesigned earlier.

Step 1: Create the New Tablespaces

We will use the SAPDBA11 utility to create newlocally managed uniform extent tablespaces for thenew object classes.

When adding the new tablespaces to the database,first allocate a data tablespace and then its index table-space, as SAP requires. I suggest PSAP<class>D(PSAPTINYD, for example) as your naming con-vention 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 you’ve created all of the tablespaces, querytable TAORA as you did earlier when analyzing thetablespaces. You should see the new tablespaces listedwith a TABART value of USER*. Figure 8 shows theTAORA entries for the uniform extent data table-spaces defined for the example. As you can see,I have also included a Singular class tablespace namedPSAPDRAOD that holds a 360GB DRAO table.

11 See SAP Note 43191 for SAPDBA documentation and help.

Figure 8 TAORA Entries for the Example Uniform Extent Data Tablespaces

TABART TABSPACE PCTI OFR OF OP OP-------------------------------------------------------USER7 PSAPTINYD 0 1 1 10 40USR02 PSAPSMALLD 0 1 1 10 40USR03 PSAPMEDIUMD 0 1 1 10 40USR23 PSAPLARGED 0 1 1 10 40USER5 PSAPDRAOD 0 1 1 10 40





�� Note!

Remember, it is very important that the indextablespaces not consist of uniform extents. Indexsizes are variable, so they will fit best into atablespace that can handle varying extent sizes.

Once the target tablespaces are created, the nextsteps are to list and sort the tablespace objects, run the

reorganization, and update the ABAP Dictionary.We’ll cover these tasks in the remaining steps. Notethat these remaining steps must be repeated on each“in-scope” tablespace until the objects are reorganizedinto the new tablespaces and the original tablespacesare empty.

Step 2: List and Sort the Tablespace Objects

We next need to launch LiveReorg (see the sidebar on choosing a reorganization tool). Figure 9 shows

Figure 9 Tablespaces and Object Counts in LiveReorg





LiveReorg’s Explorer screen after connecting to ourexample Oracle database and retrieving a list of table-spaces and object counts. The Explorer is divided intothree areas: an overview pane on the left, a subobjectslist pane on the bottom right, and a panel with specificobject details at the top. As you can see in Figure 9,I’ve selected the database in the overview pane. Asexpected, the complete list of subobjects (tablespaces)is displayed in the subobjects list pane. Clicking on anyof the tablespaces in the subobjects list pane brings upits storage, object count, and allocated vs. free spacestatistics on the detail panel at the top. You can easily

view similar information for specific tables by clickingon a tablespace in the overview pane.

Notice the variety of tablespaces in the standardSAP R/3 database. For example, tablespacePSAPBTABD 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-SAPtablespaces named PSAPBSISD and PSAPDCLSDare single-table tablespaces. We will reorganize andempty each of these tablespaces and later drop them to reclaim disk space. Doing so will improve ouroverall disk space utilization.

Choosing a Database Reorganization Tool

I use Quest Software’s 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 thangenerating and running Oracle DDL scripts to perform the reorganization. Aside from LiveReorg’s abilityto run reorganizations with no downtime, its client software lets you easily sort and re-sort lists of tablesby 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 thismethodology is so simple to implement that our operations staff runs the reorganizations by followingsimple written instructions. The LiveReorg tool’s 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” reorganizationtools, such as BMC. Research these products and get one of them, they are well worth the money. Theyeliminate downtime, which your management and users will love, database administration time and effortwill be greatly reduced, and reorganization success will be greatly increased. After all, if your databaseadministrators are dealing with many terabytes of databases, and many instances of SAP databases, you need the speed and accuracy of a reorganization tool.

�� Note!

In Figure 9, you are looking at a database while itsinitial reorganization is in progress, so you can seethe new tablespaces along with the original SAPtablespaces.

�� Note!

Another thing to notice in Figure 9 is that SAPchooses to separate data and index tablespaces,just as we intend to. You can tell because datatablespaces predictably end with a D and indexspaces have an I.





To inspect the details of individual tables within a tablespace, have a look at Figure 10 andFigure 11. In Figure 10, I’ve scrolled down in the left pane of the Explorer window and clicked on tablespace PSAPTINYD in order to review its sub-objects (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, I’ve navigated to the PSAPSMALLDtablespace and sorted its tables from largest to smallest.Notice that the largest object is 230 extents totaling36,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 we’ve classified the objects into their

appropriate size classes, the next step is to use theReorg 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 appropriateSingular tablespace

To keep things simple, I will show you how to set up and execute a reorganization run for a singleTiny table, SAPR3.DSTDB6, located in tablespacePSAPDDICD.

Figure 12 shows the details for this table, alongwith other tables in tablespace PSAPDDICD. As you

Figure 10 Viewing the Tables in Tablespace PSAPTINYD





Figure 11 Viewing the Tables in Tablespace PSAPSMALLD

Figure 12 Table SAPR3.DSTDB6 in Tablespace PSAPDDICD





can see, the current size of table SAPR3.DSTDB6 is 16KB. Since it’s 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-clickon the table name in the subobjects list pane and select Reorg Manager from the context menu.LiveReorg will chug a bit as it gathers informationfrom Oracle about the table definition and its indices,and then present a series of screens to control the reorganization process. Let’s review each screen in more detail.

�� Note!

Remember that this is a high-level demo ofLiveReorg and I will not be discussing all ofLiveReorg’s 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 fordata 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, we’re setting some basic options here —e.g., Parallel Query Option — but mostly just accept-ing 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 13 Assign the Table to the PSAPTINYD Tablespace





Figure 14 Setting Options for the Reorganization

Figure 15 Setting Storage Options





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 TablespaceDefaults option. All extent attributes will thereafter be inherited from the tablespace, greatly simplifyingmaintenance.

The Customize Object Allocations Screen

The Customize Object Allocations screen (Figure 16)can be used to set all sorts of different parameters foreach object. The example shown in the screenshot isfor only one table, but there could be 100 tables in theobject list. Keep in mind, however, that changingparameters for each table can get tedious because you have to click on each object to set specific sizingoptions for it, such as Pct Free and Pct Used, so be judicious about undertaking this task.

LiveReorg will eventually create a lengthy scriptthat 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 makeFind/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) summa-rizes the planned database movements to be made bythe reorganization run. A few clicks after this screen,you are finally asked to name and save the reorganiza-tion script.12

Step 4: Launch and Monitor the ReorganizationRun

Once a script is saved, it appears in the Job Monitor.To execute the script, right-click on it, as shown inFigure 18, and then select Execute.

Figure 16 Set Allocations for a Table’s Reorganization

12 LiveReorg scripts get saved into a dedicated LiveReorg tablespace in thedatabase.





Figure 17 Preview of Changes That Will Result from the Reorganization

Figure 18 Locating and Executing a Reorganization Script in the Job Monitor





In this case, the script runs very quickly and theresult 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. TheExplorer window appears again. Refresh the display by pressing F5. You’ll see that table DSTDB6 is

�� Note!

During a full-scale reorganization you coulddefine additional reorganization scripts withseveral tables in each script and subsequentlylaunch them concurrently.

Figure 19 The Executed Reorganization

�� Note!

LiveReorg created its own proprietaryreorganization script and process log for theexample. Both are too large to be printed here,but they are available for download fromwww.SAPpro.com. The file names areLR_Script.sql and LR_Script.log.





gone from its original tablespace PSAPDDICD (notshown). Clicking on the PSAPTINYD tablespace (see Figure 20) reveals that table DSTDB6 is in thenew tablespace.

Step 5: Update the ABAP Dictionary for SAPCompliance

After you have reorganized several tables, you need

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 theTablespace 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 spacethat 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 lessthan 5MB in size. The script doesn’t actually shrink the Oracle files, but it generates DDL syntax that can be used toshrink the files. You will need to feed this syntax to SQL*Plus.





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 atwww.SAPpro.com) does this. It finds all the tablesstored in the new tablespaces and updates the ABAPDictionary,13 specifically table SAPR3.DD09L.14

You should run this script after a reorganization has just finished.

After some time, let’s suppose you have reached a point where the PSAPBTABD tablespace is empty

because you’ve moved all its tables into the new table-spaces. Two things need to happen at this point:

1. The ABAP Dictionary needs a special update forthe empty tablespace because there may be tablesdefined in the dictionary that are assigned to thistablespace but were not created in the Oracle data-base. You will assign these non-existing tables tothe Tiny class. The required script is shown inFigure 21 and is available at www.SAPpro.comunder the name ABAP_Remaining_Tables.sql.

2. Decide if the empty tablespace gets dropped ordownsized. Let’s refer to the SAPR3.TAORA listing you saved at the very beginning of thisprocess (Figure 5). If the empty tablespace’sTABART value starts with USER or USR, thendrop it; you don’t need it. However, if the 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.

Figure 21 Assign ABAP Dictionary Tables to the Tiny Class for the PSAPBTABD Tablespace

update sapr3.dd09lset 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 fromSAPR3.TAORA, causing it to have a TABART of USER* when you re-add the tablespace, which will adversely affectsupport packs. Instead, use Oracle Enterprise Manager to drop and re-create these tablespaces with a minimal diskspace of 50MB.





tablespace’s TABART is anything other thanUSER or USR, then it is an SAP-installed table-space. The tablespace will be kept and will haveno tables stored in it, so it will be greatly down-sized to save disk space. The fastest way to down-size the tablespace is to drop it and thenimmediately create it again.

That’s it! You’ve now completed the databasereorganization and made the necessary updates to the ABAP Dictionary to ensure a high-performing,smooth-running system. In the next section, I’ll showyou how you can complete these same tasks withoutusing the LiveReorg tool.

Reorganization WithoutLiveReorgAs I stated earlier, LiveReorg (or a similar third-partytool15) is not required to use the reorganization strategyoutlined in this article, it just makes it easier.Technically, you can execute reorganizations usingjust Oracle SQL scripts and utilities. After all, movingSAP tables between tablespaces isn’t that complicatedof a procedure — the vast majority of SAP tables canbe moved using a simple SQL “alter table…move”statement in SQL*Plus.

�� Note!

The scripts I’ve provided with this section(available at www.SAPpro.com) replace only theLiveReorg portion of this article. All the otherpieces of the strategy remain intact, including the ABAP Dictionary update scripts. After all,SAP does not care how the tables get movedaround between tablespaces — it just cares thatthe ABAP Dictionary and database are in sync.

�� Exception!

The tables that cannot be moved this way containcolumns based on the LONG data type; these haveto be moved using Oracle’s export and importutilities due to restrictions in Oracle SQLlanguage.

The use of Oracle scripts and utilities instead ofLiveReorg, however, means you must take your SAPsystem offline while doing reorganizations. If you canlive without this “live” capability, this “barebones”method may suffice.

I’ve included two scripts16 — MoveObjects and RebuildIndexesIntoUE (available atwww.SAPpro.com) — to mimic the core behavior ofLiveReorg. For safety, both scripts as delivered makeno changes to your SAP database. I’ve commentedout those parts, so you’ll need to uncomment them touse the scripts productively.

Script MoveObjects classifies your SAP tables bysize, creates SQL statements to move each table into its assigned tablespace, and spools all of this into areorganization script named x.sql that you can then runin SQL*Plus to actually perform the reorganization.

Script RebuildIndexesIntoUE is called within the x.sql script after each table is moved and it movesthe indexes into the assigned index tablespace byrebuilding it.

�� Tip

The great thing about Oracle’s SQL*Plus is thatyou 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.

15 BMC’s 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).

16 The actual script names are MoveObjectsBySize_Without_LR.sql andRebuildIndexesIntoUE_Without_LR.sql.





Figure 22 shows samples of the SQL reorganiza-tion statements created as output from executing theMoveObjects script. Notice how the three tables from tablespace PSAPSTABD are Tiny and get movedinto the PSAPTINYD tablespace. Also notice thateach table yields two SQL statements: one to movethe table, and a second commented line to run thescript to move its indexes by rebuilding them. Thesecond 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 thetables first and then rebuild all the indexes afterward;just run the RebuildIndex script once at the end of thex.sql script.

If you can’t get downtime but want a “near-live”reorganization, move a table and then immediatelyrebuild its indexes by running the RebuildIndex scriptafter 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 reorgani-zation script on a sandbox SAP database to get

�

comfortable with it and to test it thoroughly inyour environment first.

Tables that cannot be moved by the script (i.e.,those with a LONG data type column) will give anoutput error; these tables must be moved withOracle’s export/import utility. The exporting and importing of tables cannot be done “live,”so you’ll need to schedule an outage for the SAP system and prepare the export/import process todo this final move.

For tablespaces you have exempted from the reorganization strategy, edit the MoveObjectsscript and add the tablespace names, such asPERFSTAT, etc. I did not use these scripts to

�

�

Figure 22 Example Statements Output by the MoveObjects Script

/* PSAPSTABD 16K */ alter table SAPR3.”VIWB70” move online tablespacePSAPTINYD;rem @RebuildIndexesIntoUE_Without_LR.sql /* PSAPSTABD 16K */ alter table SAPR3.”VIWEGB” move online tablespacePSAPTINYD; rem @RebuildIndexesIntoUE_Without_LR.sql /* PSAPSTABD 16K */ alter table SAPR3.”VIWEGR” move online tablespacePSAPTINYD; rem @RebuildIndexesIntoUE_Without_LR.sql

�� Note!

“Near-live” refers to how Oracle will mark atable’s index as “unusable” when a table ismoved. Basically it’s like pulling the rug out fromunder the indexes; the indexes point directly intothe table. When the table is moved all the index’spointers 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 theavailability of the tables to SAP and is what I call “near-live.”

17 I use a Microsoft Windows-based text editor called UltraEdit, a “cheapand cheerful” solution for folks like me that find the Unix “vi” editorincomprehensible. UltraEdit has a built-in FTP to move text files fromand to Unix servers and a Notepad-style text editor. The Emacs andTextpad editors are also fine tools.





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,and that only database administrators should per-form the required tasks.

Tips for SuccessHere are some final things to keep in mind to makeyour reorganization process go smoothly:

I strongly caution you to not use this strategy onyour SAP BW databases. It is a completely different beast from SAP R/3 with regard to object creation and tablespace assignment.

Test this strategy thoroughly on a sandbox SAPdatabase first.

Get familiar with what the scripts are doing andthe information they read or update from theABAP Dictionary.

Acquire and read the articles and SAP Notes ref-erenced in this article.

Don’t reorganize tables that are being loaded orpurged. Schedule reorganizations around theseactivities.

When adding new tablespaces to an SAP systemthat is the source for transports, make sure to alsoadd the new tablespaces to the target systems ofthe transports. Transports sometimes look for the TABART values to store tables, so they mustexist on the target SAP systems, otherwise thetransport fails.

Be aware that LiveReorg executes like it is a dataload process, so it will consume some resourceson your database server.

�

�

�

�

�

�

�

�

When LiveReorg is building and sorting indexeson tables, it will compete with SAP for thesaptemp tablespace, especially when reorganizingLarge tables and their indexes.

Succeeding with Ongoing Reorganizations

On a periodic basis you are going to look at the extentcounts of all the tables in the new tablespaces andmove some tables. Here are some tips for success:

Tables with more than 1,000 extents could bereorganized into the next higher data class.

Tables with less than 24 extents could be reorgan-ized into the next lower data class.

Tables could also be reorganized in-place, in theirsame tablespace, to reclaim disk space if archivingor purging has taken place on some tables.

Run the “shrink files” process to reclaim freespaceat the end of the database files.

Review the SAP default tablespaces, such asPSAPBTABD and others. You will likely find oneor two tables in there as a result of support pack-ages and OSS messages, etc. They should be classified by size and reorganized into the new tablespaces. Be sure to run the ABAP update script.

ConclusionYou’ve learned by now that a large SAP R/3 databasecan be relatively easy to reorganize when a clear strategy is combined with good skills and good tools.Download all the scripts I’ve provided and you’ll soonbe prepared to try this on a sandbox instance by usingthe MoveObjects script method.

�

�

�

�

�

�





Keep in mind that this strategy will continue to evolve as future Oracle versions bring us ever-improving disk space management capabilities. Oneday soon you may be reorganizing all of these newtablespaces into a single “big-file” tablespace inOracle 10g to have Oracle manage the fragmentation,and when that time comes you will be well preparedto start taking advantage of the benefits. You can even

adapt this strategy for any non-SAP Oracle databasesimply by omitting the ABAP update step.

Database reorganizations are an essential part of good database performance. Complement yourinvestment in the SAP application by acquiring gooddatabase administration tools and reap the rewards ofthis proven strategy.



Documents

SAP R/3 Performance Reorganization - Oracle DB Reorganization