Reorg & SAP R3 Performance

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. 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
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.
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. 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.
Figure 1
A Fragmented Tablespace
PSAPBTABD
Note!
In addition to a reorganization strategy and procedures, a good application performance management plan requires writing efficient queries, proper batch job scheduling, good database design, and other such elements, to name a few.
The strategy was born from dozens of white papers, scripts, newsgroup postings, SAP Notes, technical manuals, and books, and thus reflects the latest in industry best practices and lessons learned. I merely optimized this information for SAP R/3 Oracle databases.
Figure 2
Tablespace After Reorganization
Note!
Tablespaces with Uniform Extent Sizes
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.
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

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. 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. Lets discuss each tactic in more detail.
Tiny for tables that are empty or do not exceed 16MB 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 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.
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:
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.
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 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.
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.
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 Lets now put our strategy into action by planning and performing an actual reorganization.
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. 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. 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.
Preparing to Reorganize
There are three tasks we need to perform in preparation for the reorganization: 1. Analyze the existing tablespaces. 2. Design the new tablespaces. 3. Communicate the reorganization strategy and obtain approval. Well walk through each task in turn in the following sections.
Note!
All of the SQL scripts discussed in the article are available for download at www.SAPpro.com.
Caution!
As I cautioned earlier, only SAP tablespaces are in scope for your reorganization. Reorganizing third-party or Oracle system tablespaces (system, temp, rbs, undo) can interfere with the products operation or support. Even if the third-party vendor does support reorganization, be sure to set up separate sets of tablespaces for your SAP and non-SAP objects. Do not co-mingle SAP and non-SAP data.
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) 16 160 5,120 163,840 ???* Object Total Size (K) 250 Extent Size (K) 4,000 40,000 1,280,000 40,960,000 500 Extent Size (K) 8,000 80,000 2,560,000 81,920,000 1,000 Extent Size (K) 16,000 160,000 5,120,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
9
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.
July/August 2005
Figure 7
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.
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!
For our example, tables have an upper limit of 1,000 extents and a lower limit of 24 extents. Our initial classification of tables will not exceed 250 extents, which represents just a fraction of the total extents that we allow a table to have without being reclassified. This will leave a sufficient amount of room for the table to grow before needing to be reclassified.
Note!
While 16K is the minimum extent size Oracle allows, and works fine for SAP R/3 database objects, a Tiny tables column could require a 24K or 32K minimum extent size if the Tiny table is a large binary object. In these cases, you should reorganize that table into the Small class.
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.
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
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.
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 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
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
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! 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. 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.
July/August 2005
Figure 10
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.
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
Step 3: Select Objects to Reorganize

Now that weve classified the objects into their
Figure 11
Viewing the Tables in Tablespace PSAPSMALLD
Figure 12
Table SAPR3.DSTDB6 in Tablespace PSAPDDICD
July/August 2005
Figure 13
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.
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
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.
Figure 14
Setting Options for the Reorganization
Figure 15
Setting Storage Options
July/August 2005
Figure 16
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
July/August 2005
Figure 19
The Executed Reorganization
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.
Note!
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
July/August 2005
Figure 21
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
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
See SAP Note 154193, SAPDBA: Reorganizations and ABAP-DDIC; this script is adapted from the note. Remember, your SAP schema name might be different.
14
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.
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.
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!
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.
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.
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).
16
The actual script names are MoveObjectsBySize_Without_LR.sql and RebuildIndexesIntoUE_Without_LR.sql.
July/August 2005
Figure 22
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; rem @RebuildIndexesIntoUE_Without_LR.sql /* PSAPSTABD 16K */ alter table SAPR3.VIWEGR move online tablespace PSAPTINYD; rem @RebuildIndexesIntoUE_Without_LR.sql
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:
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.
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.
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.
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.
Keep in mind that this is a very hands-on method,

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:
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.
I strongly caution you to not use this strategy on

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 reorganized into the next lower data class.
Test this strategy thoroughly on a sandbox SAP

database first.
Tables could also be reorganized in-place, in their

same tablespace, to reclaim disk space if archiving or purging has taken place on some tables.
Get familiar with what the scripts are doing and

the information they read or update from the ABAP Dictionary.
Run the shrink files process to reclaim freespace

at the end of the database files.
Acquire and read the articles and SAP Notes referenced in this article.
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.
Dont reorganize tables that are being loaded or

purged. Schedule reorganizations around these activities.
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.
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.
Be aware that LiveReorg executes like it is a data

load process, so it will consume some resources on your database server.
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.

Reorg &amp; SAP R3 Performance

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Reorg &amp; SAP R3 Performance

Загружено:

Авторское право:

Доступные форматы

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

SAP Professional Journal

Tablespace After Reorganization

Tablespaces with Uniform Extent Sizes

SAP Professional Journal

Reorganization Strategy: Three Key Tactics

Classify All Database Objects According to Their Allocated Size

The Database Reorganization Strategy

PSAPBTABD PSAPTINYD 16K Extent

PSAPSMALLD 160K Extent

PSAPMEDIUMD 5MB Extent

PSAPLARGED 160MB Extent

Migrate Like-Sized Objects to Locally Managed Tablespaces of Uniform Extent Size

SAP Professional Journal

Monthly Table Review, Reclassification, and Reorganization

PSAPTINYD 16K Extent

PSAPSMALLD 160K Extent

PSAPMEDIUMD 5MB Extent

PSAPLARGED 160MB Extent

SAP Professional Journal

Step 1: Analyze the Existing Tablespaces

Script for Retrieving Allocated Table Sizes

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

Step 2: Design the New Tablespaces

See SAP Note 43191 for SAPDBA documentation and help.

SAP Professional Journal

Data Class Size Chart

Step 3: Communicate the Reorganization Strategy and Obtain Approval

TAORA Entries for the Example Uniform Extent Data Tablespaces

Step 1: Create the New Tablespaces

Executing the Reorganization

See SAP Note 43191 for SAPDBA documentation and help.

SAP Professional Journal

Step 2: List and Sort the Tablespace Objects

Tablespaces and Object Counts in LiveReorg

Choosing a Database Reorganization Tool

SAP Professional Journal

Viewing the Tables in Tablespace PSAPTINYD

Step 3: Select Objects to Reorganize

Viewing the Tables in Tablespace PSAPSMALLD

Table SAPR3.DSTDB6 in Tablespace PSAPDDICD

SAP Professional Journal

Assign the Table to the PSAPTINYD Tablespace

Setting Options for the Reorganization

Setting Storage Options

SAP Professional Journal

Set Allocations for a Tables Reorganization

Step 4: Launch and Monitor the Reorganization Run

Preview of Changes That Will Result from the Reorganization

Locating and Executing a Reorganization Script in the Job Monitor

SAP Professional Journal

The Executed Reorganization

A Refresh Display Shows Table DSTDB6 in Tablespace PSAPTINYD

Step 5: Update the ABAP Dictionary for SAP Compliance

SAP Professional Journal

Reorganization Without LiveReorg

The actual script names are MoveObjectsBySize_Without_LR.sql and RebuildIndexesIntoUE_Without_LR.sql.

SAP Professional Journal

Example Statements Output by the MoveObjects Script

comfortable with it and to test it thoroughly in your environment first.

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

For tablespaces you have exempted from the

When LiveReorg is building and sorting indexes

Reorg & SAP R3 Performance

Reorg & SAP R3 Performance