Improve Performance in SAP Application Environments with Space

Improve Performance in SAP Application Environments with Space Manager with LiveReorgand Ales Zeman, Senior Presales Consultant
Quest Software, Inc.
Improve Performance in SAP Application Environments with Space Manager with LiveReorg®
WPD-SpaceManagerwithLiveReorg-SAP-US-AG
© 2009 Quest Software, Inc. ALL RIGHTS RESERVED.
This document contains proprietary information, protected by copyright. No part of this document may be reproduced or transmitted for any purpose other than the reader's personal use without the written permission of Quest Software, Inc.
WARRANTY
The information contained in this document is subject to change without notice. Quest Software makes no warranty of any kind with respect to this information. QUEST SOFTWARE SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTY OF THE MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Quest Software shall not be liable for any direct, indirect, incidental, consequential, or other damage alleged in connection with the furnishing or use of this information.
TRADEMARKS
All trademarks and registered trademarks used in this guide are property of their respective owners.
World Headquarters 5 Polaris Way Aliso Viejo, CA 92656 www.quest.com e-mail: [email protected]
Please refer to our Web site (www.quest.com) for regional and international office information.
Updated—March 4, 2009
BLOCK FRAGMENTATION .................................................................................. 2 High Water Mark Effect ............................................................................ 2 Inappropriate PCTFREE and PCTUSED Settings ............................................ 3
ROW CHAINING ............................................................................................ 3 STAGNATED INDEXES ..................................................................................... 4 DATA PARTITIONING ...................................................................................... 4
2. THE AVAILABILITY CHALLENGE ..............................................................5 3. THE CAPACITY CHALLENGE .....................................................................6
Locally Managed Tablespace Autoallocate ................................................... 8 THE SOLUTION: SPACE MANAGER WITH LIVEREORG® ................................9 1. PROBLEM DETECTION ...........................................................................10
TABLESPACE MAPS....................................................................................... 10 EXCEPTION REPORTS.................................................................................... 10 PREDICTED REORGANIZATION BENEFIT REPORT .................................................... 10
INDEX REORGANIZATION ............................................................................... 12 TABLESPACE REORGANIZATION ........................................................................ 13
Option #1: Reorganize a Tablespace in Place ............................................ 13 Option #2: Reorganize a Tablespace Using External Space.......................... 13 Option #3: Full Tablespace Defragmentation............................................. 13
SORTED REORGANIZATIONS ........................................................................... 14 FAST, FLEXIBLE REORGANIZATIONS................................................................... 14
CONCLUSION ............................................................................................23 APPENDIX: SAP EVALUATION ...................................................................24 ABOUT THE AUTHOR .................................................................................25 ABOUT QUEST SOFTWARE, INC. ................................................................26
1
CHALLENGES
With today’s databases growing faster than ever, the typical database administrator (DBA) must spend a significant amount of time performing space management and reorganization to achieve optimal performance, capacity, and availability. Achieving these goals in dynamic database environments—especially large, active sites such as those running Oracle under SAP R/3, SAP ECC (ERP Central Component)— presents many challenges. The following sections look at performance, availability, and capacity challenges in turn.
Improve Performance in SAP Application Environments with Space Manager with LiveReorg
2
1. PERFORMANCE CHALLENGES
Optimal performance means optimal application response time. But response time can degrade due to a number of space management issues. The four primary issues are:
• Block fragmentation
• Row chaining
• Stagnated indexes
• Data partitioning
Block Fragmentation
When data is not efficiently packed inside table blocks, the table has block fragmentation. Block fragmentation leads to excessive I/O, which slows query performance and application response time.
There are two main causes of underutilized space inside table blocks: the high water mark effect and inappropriate PCTFREE and PCTUSED settings.
High Water Mark Effect
Every Oracle table contains a pointer called the high water mark, which indicates the point at which the table is filled. Before data is loaded in a table, the table is empty and the high water mark points to the beginning of the table. As data is inserted into the table, the high water mark rises. It can only rise; even if data is deleted, the high water mark does not go down.
In a full table scan, Oracle scans up to the high water mark rather than to the end of the entire allocation, and this can cause inefficiencies. For example, consider a table that is given an initial allocation of 40 MB and is then loaded with 20 MB of data. Even if we delete all the rows after the load, the high water mark will continue pointing to the 20 MB mark. Therefore, when the table is scanned, 20 MB will be read to the buffer cache, although no rows will be returned.
Alternatively, suppose we subject the table to high delete and insert activity. The high water mark will continue to rise over time since the inserted data does not vacate the spot once occupied by the deleted data. Eventually the area scanned by each full table scan could easily be more than half empty. To reset the high water mark, we must either truncate or reorganize the table.
Technical Brief
Inappropriate PCTFREE and PCTUSED Settings
The second cause of wasted space is inappropriate PCTFREE and PCTUSED settings. Together, PCTFREE and PCTUSED regulate the amount of free space in a block, allowing it to expand and contract cyclically.
Problems arise when the PCTUSED setting is too low (PCTUSED is set to 40% by default) and only PCTFREE space remains free. No new rows can be inserted into a block until the percentage used falls below the PCTUSED setting.
Tables that are maintained frequently, especially those that undergo a lot of inserts and deletes (as opposed to updates), will eventually reach a state where the percentage of the block used is just above the 40% PCTUSED mark in most blocks. When a table reaches this state, Oracle must perform a great deal more I/O to access data, especially for index range scans and full table scans. The result is performance degradation. The only way to adjust the PCTFREE and PCTUSED settings is to reorganize the table.
Row Chaining
The second important issue that affects performance is row chaining. Oracle distinguishes between two types of chained rows: spanned rows and migrated rows:
• A spanned row is one that is larger than a single database block. Oracle divides each spanned row between multiple blocks.
• A migrated row is one that no longer fits into its original block due to horizontal record growth. Oracle will move such a row to a block with enough free space to accommodate the expanded record; the original row location will contain only a pointer to the new location.
Migrated rows impose a performance penalty on both full table scans and index range scans. To retrieve a migrated row, Oracle first retrieves the original block, which contains only a pointer. It then uses the pointer to retrieve the block that contains the migrated row. Therefore, to access a series of migrated rows, Oracle must perform twice the number of read operations as for unchained rows.
4
Stagnated Indexes
The third major performance challenge is stagnated indexesindexes that have become large and sparsely populated. This condition can severely degrade the performance of index range scans. It can also waste a substantial amount of disk space.
Stagnation occurs as the result of heavy updates to indexes. Oracle indexes are structured as B-trees. When an indexed value is updated in a table, the old value is deleted from one index node and the new value is added to another index node. The space released inside the first index node may never be used again. As a result, indexes on volatile tables become stagnated. It is not uncommon for indexes on heavily updated tables to become 50% “empty.”
Data Partitioning
The final major performance challenge is data partitioning. When objects that are frequently accessed reside in the same datafile, I/O bottlenecks can result. To better distribute I/O requests among various datafiles and disks, it is advisable to place heavily accessed tables in separate tablespaces. For the same reason, it is often recommended that tables and their indexes be placed in separate tablespaces. With the advent of Oracle 8, table and index partitioning has become a popular way of distributing I/O between datafiles.
Optimal placement of database objects not only improves performance, it also improves the recoverability of a database. A good example is a situation where one small table in a tablespace is corrupted and the entire tablespace must be recovered. If only small tables reside in the tablespace, the recovery will take less time than if large and small tables reside there together. Another example is a situation where only one index in a tablespace is corrupted. If the index resides in a separate tablespace from its table, it is not necessary to recover the tablespace; instead, the index can be dropped and recreated.
However, moving objects from one tablespace to another often involves extensive SQL scripting, and partitioning non-partitioned objects and resizing existing partitions generally involves a great deal of tedious calculation and SQL scripting.
Technical Brief
2. THE AVAILABILITY CHALLENGE
Maximizing application availability is a key concern for DBAs. The challenge here is that application availability can be compromised as objects run out of space. In fact, this is one of the leading causes of downtime. Space-related downtime occurs when objects hit their MAXEXTENT limit (on Dictionary Managed Tablespaces) or when there is insufficient free space in the tablespace for an object to extend. The second condition is especially hard to predict.
6
3. THE CAPACITY CHALLENGE
Maintaining sufficient capacity requires planning. Successful capacity planning means knowing how fast individual database objects and the database as a whole are growing. It also means predicting future disk space requirements, which is vital in budgeting disk space and planning hardware upgrades.
With today’s larger databases, disk space is always at a premium and recovery of wasted space is critical. Wasted space can be found in several places:
• Any tablespace
Wasted space can occur in tablespaces for many reasons:
• A table can have wasted space if rows are deleted from the table and the vacated space is not re-used by inserted rows.
• A table or an index can have wasted space if it was built with an excessive PCTFREE value.
• An index can have wasted space with “sparse” deletes. If you delete all the rows in an index block, then the index block will be reused. However, if you delete all the rows except one in an index block, the index block will not be reused. The space may be reused if you insert rows with keys that can fit in the almost-empty index block, but if you have a monotonically increasing index value, for example, you will never have values that can fit in almost-empty index blocks used in the past.
• An index can also have wasted space if many key values are identical (that is, you are indexing on a row with little selectivity). An extreme example is an index on the “gender” column, which always contain either M or F (male or female). Whenever Oracle inserts a new row with gender F, it will look for the last index leaf block with an F in it, or the first index leaf block with an M, and insert the entry for the new F row somewhere between those two entries. If there are many half-full index blocks near the beginning of the index containing rows for F values, Oracle will skip all those blocks because it will try to put the newest row after the last F and before the first M.
Technical Brief
Wasted Space Due to Too Many Extents
The problem of wasted space is not nearly as bad in locally managed tablespaces as it was with dictionary managed tablespaces. In a dictionary managed tablespace, dropping a table with many extents would cause a very large number of updates to fet$ and uet$ (the data dictionary tables containing extent information), which would slow down any process trying to allocate or deallocate extents. Dropping a table could take hours or even days. In a locally managed tablespace, dropping a table means modifying a bitmap in a file header, so there is no contention with other processes doing extent allocation in other datafiles. However, a table with 100,000 index entries listing extents is not as efficient as a table using 10 index entries listing extents.
An index range scan will benefit greatly if the index has a low clustering factor, meaning that the table rows are in the same order as the index values FOR THAT INDEX. Of course you should first verify that there is a query whose execution plan shows that index being used for an index range scan. To improve the clustering factor for the index, you must rebuild the table, not the index, because the clustering factor depends on the order of the rows in the table.
Wasted Space in Locally Managed Tablespaces
Wasted space also occurs if a segment is placed in a tablespace with extent sizes inappropriate for the segment, because some segments will not use up all the space in an extent. Consider the following extreme case: I build a tablespace with uniform extents of 100 MB for my large order entry tables, and someone creates in that tablespace a state code table with 50 2-character state codes. The state code table, which should be minuscule, will use up 100 MB of space. Another example: I build a tablespace with 100 MB uniform extents, and I create in there a table that needs 101 MB. The table will use two extents, or 200 MB, almost half of which is wasted.
In addition, one extent’s worth of space can be wasted if you don’t leave room for the header block when you create the tablespace. For example, suppose I create a locally managed uniform tablespace with 100 MB extents, and I create a datafile exactly 2000 MB in size. The tablespace will have 1900 MB of usable space, and 100 MB minus 64K of unusable space (64K is reserved for the bitmap header, and the remainder is not enough for a uniform extent.) I should have built the datafile at 2000MB + 64K (or 2000MB + 128K if the blocksize is 32K).
8
Locally Managed Tablespace Autoallocate
Since Oracle uses different extent sizes depending on 1) segment size at creation time and 2) segment growth, small segments will use small extents, and large segments will use large extents. In fact, fast growing segments can start with small extents and switch to large extents once Oracle sees that the segment is getting big. However, you may run into a different problem: tablespace fragmentation. It will not occur as frequently as it does in a dictionary managed tablespace, but it may occur.
Consider the following extreme case: I fill a 62 MB tablespace by sequentially creating tables T001, T002, … T991, each 64K (the smallest size possible in a locally managed autoallocate tablespace). Then I delete the even-numbered tables T002, T004, … T990. I now have 31 MB of free space, but in individual 64K chunks. By looking at the free space—31 MB—I would think I could easily build a 2MB table. But if I try to build a table with STORAGE (INITIAL 2MB), the Oracle algorithm for allocating extents in an autoallocate tablespace will not find the blocks it wants and I will get error ora-01658. I may also be unable to allocate new extents for an existing table because Oracle could be looking for free extents bigger than 64K in size and the tablespace doesn’t have any free extents bigger than 64K, even though the total free space is 31 MB.
You may need to reorganize if any of the following factors apply:
• You need to move objects from a dictionary managed tablespace into locally managed tablespaces.
• You need to move large, heavily used tables into their own tablespaces.
• You need to move heavily used table partitions into their own tablepspaces.
• You have fragmented tables or indexes.
Technical Brief
THE SOLUTION: SPACE MANAGER WITH LIVEREORG®
Space Manager with LiveReorg® from Quest Software provides a comprehensive space management and reorganization solution to all the challenges described above. Space Manager with LiveReorg can help you with all of the following:
• Space-use problem detection and optimization: Detect space related problems in the database and size objects for optimal space usage.
• Reorganization: Reorganize fast, either offline or, with the LiveReorg functionality, while applications and users remain online
• Monitoring scripts: Follow the progress of reorganization jobs
• Capacity planning:
∗ Track the growth and condition of database objects ∗ Predict “out of space” conditions ∗ Provide capacity planning and database growth analysis and reporting
• SAP considerations: Get the best performance in SAP environments by optimizing I/O and taking advantage of parallelism.
10
1. PROBLEM DETECTION
Space Manager with LiveReorg provides a set of tools to detect space-use problems that impact database capacity and performance. Tablespace Maps and Exception reports identify objects that need to be reorganized, repaired, partitioned or relocated. The Predicted Reorganization Benefit report identifies the benefit of reorganizing these tables or indexes.
Tablespace Maps
Tablespace maps help you visualize space use in a tablespace. Color-code squares represent data blocks, so you can quickly determine the extents allocated to each object, how space is allocated sequentially, and how much space is free. Tablespace maps reveal the severity of space-use problems in a tablespace. They also show you how extents are allocated to different types of objects in a tablespace and expose tablespace fragmentation.
Exception Reports
Exception reports enable you to quickly identify objects that are degrading performance due to space-use problems. For example, you can identify:
• Tables that need reorganization
• Indexes that need reorganization
• Tables with chained rows
• Nonselective indexes
Space Manager identifies tables that need to be reorganized based on the following criteria:
• Excessive free space inside table blocks (high water mark too high)
• Overextension (too many extents)
Predicted Reorganization Benefit Report
Once you have used Tablespace Maps or Exception reports to identify problematic objects, you can use the Predicted Reorganization Benefit report to see the amount of space you can reclaim if you reorganize a particular table or index. You can right- click objects in the report to automatically reorganize them.
Technical Brief
• Reorganize individual tables and their indexes
• Reorganize multiple objects or an entire tablespace
• Relocate tables, indexes, and individual partitions to a different tablespace
• Rebuild indexes
• Repair chained rows
Space Manager with LiveReorg’s reorganization is performed entirely inside the database using SQL. The necessary SQL scripts are generated automatically and can handle all constraints and dependencies. To achieve the fastest possible reorganizations, Space Manager with LiveReorg supports UNRECOVERABLE mode and two types of parallel processing: Oracle’s PARALLEL query option and multiple Quest Server Agent processes (available for indexes).
Table Reorganization
Table Reorganization Methods
Space Manager with LiveReorg provides two options for reorganizing tables inside the database: you can choose to use free space inside a table’s current tablespace or free space inside another tablespace. Which option you use depends on the amount of free space inside the current tablespace and the size of the object being reorganized.
Option #1: Reorganize using temporary space inside the current tablespace
If you choose this option, data is moved from the original table to a temporary table inside the same tablespace. The original table is then dropped and the temporary table is renamed or exchanged with the original table’s name. This option is fast because data is moved only once, but it requires free space in the tablespace equal to the original table’s current size. Therefore, this option may not be suitable for large tables. Large tables can be relocated to a different tablespace altogether.
Option #2: Reorganize using temporary space inside another tablespace
With this option, data is moved twice, first from the original table to a temporary table inside a different tablespace, and then back to the original table. Therefore, Option #2 is not as fast as Option #1. However, no free space is required inside the original table’s own tablespace. Instead, you can use free space inside a different tablespace (the free space must be equal to the original table’s current size).
12
LONG and LONG RAW Tables
Space Manager with LiveReorg supports reorganization of tables that contain LONG and LONG RAW data columns. To reorganize tables with such columns, Space Manager with LiveReorg uses PL/SQL for LONG and LONG RAW data columns up to 32 Kbytes in size. For LONG and LONG RAW data columns larger than 32 Kbytes and up to two gigabytes in size, Space Manager with LiveReorg uses Quest Software’s own proprietary FastCopy data movement method to perform the reorganization.
Partitioned Objects Reorganize entire partitioned objects or individual partitions
Space Manager with LiveReorg supports reorganization of individual partitions or entire partitioned objects. If reorganization includes one or more partitioned objects, partitions, or subpartitions, you can specify whether the partitions or subpartitions are to be reorganized individually or as part of an entire partitioned object.
If you choose the latter method, all partitions or subpartitions in an object are reorganized as a single object, which can be faster than reorganizing each partition or subpartition individually. If this method is selected for a table, all indexes on the table are also dropped and recreated.
Partition, repartition, add partitions or remove partitions
Space Manager with LiveReorg also provides a Partitioning Wizard that allows you to quickly partition, repartition, add partitions or remove partitions while applications and users remain online. The wizard provides a graphic interface that lets you easily visualize a partitioning scheme and specify partitioning options. The wizard also automates tasks such as setting partitioning key values, sizing partitions, and selecting tablespaces for I/O balancing.
Partitioning allows tables, indexes, and index-organized tables to be divided into smaller pieces, enabling the objects to be managed and accessed smaller individual units. Each partition can be assigned its own storage attributes, allowing the partitions to be placed in different tablespaces on thus different storage devices. Partitioning can improve the performance of queries and database administration and maintenance tasks. Partitioning allows database administrators to take their databases to a whole new level of availability while increasing data storage capacity.
Index Reorganization
Space Manager with LiveReorg not only provides a report to identify stagnated indexes, it offers three ways to reorganize them:
• Drop and recreate indexes.
• Rebuild the indexes using the Oracle REBUILD command. Rebuilding an index is considerably faster than recreating it. Moreover, with the REBUILD command, the old index is still available for queries (but not for DML) while the rebuild is in progress.
• Rebuild the indexes using the Oracle REBUILD ONLINE command. This command allows for both queries and DML while the rebuild is in progress.
Technical Brief
Tablespace Reorganization
Space Manager with LiveReorg’s targeted approach to table and index reorganization is designed to minimize the need for intrusive tablespace reorganizations. However, if it becomes necessary to reorganize an entire tablespace, Space Manager provides three options for doing so.
Options #1 and #2 maximize data availability during reorganization. Because these options reorganize only one object at a time, only one object is unavailable at any point during reorganization. Option #3 optimizes tablespace layout; however, this option moves all objects to a temporary tablespace, so all objects are unavailable during reorganization.
All three of the options currently available for tablespace reorganizations can also be used for other multi-object reorganizations, such as reorganizing part of a tablespace.
Option #1: Reorganize a Tablespace in Place
This option allows you to reorganize multiple objects using free space inside the tablespace being reorganized. Only one object is unavailable at any point because each object is reorganized in turn.
This type of reorganization can be especially fast because data is moved only once. However, it requires free space in the tablespace equal to the space currently occupied by the largest object being reorganized.
Option #2: Reorganize a Tablespace Using External Space
This option allows you to reorganize multiple objects using free space inside another tablespace. Only one object is unavailable at any point because each object is reorganized in turn. First, data is copied from an object to temporary space in the other tablespace. Then the object is re-created in the original tablespace and the data is moved back.
Since temporary space from another tablespace is used, this option does not impose free space requirements on the tablespace being reorganized, as in Option #1. However, it is somewhat slower than Option #1 because the data is moved twice.
Option #3: Full Tablespace Defragmentation
This option helps to optimize database layout by coalescing free space, which fixes the “honeycomb” fragmentation caused by nonstandard extent sizes common in Dictionary Managed Tablespaces and Locally Managed Tablespaces with non- uniform extent sizes. Because all objects are moved to a temporary tablespace at the same time, all are unavailable throughout reorganization.
14
Option #3 works as follows:
1. All objects in the tablespace to be reorganized are moved to a temporary tablespace.
2. The free space in the original tablespace (now empty) is coalesced.
3. All the objects are moved back to their original tablespace.
Sorted Reorganizations
Space Manager with LiveReorg’s solution for better data proximity consists of support for sorted reorganizations. You can have the program select the best sort key or you can specify the sort key to use (one or more columns). You should pick an index with good selectivity—that is, an index most often used by query access. You might choose to use this option before month-end or year-end batch reporting processes, for example, to optimize the execution of these processes.
Fast, Flexible Reorganizations
Speed
Oracle made it possible to perform extremely fast reorganizations inside the database using SQL and the PARALLEL and UNRECOVERABLE options. Benchmark results show that such reorganizations are generally faster than those driven by a “fast unload.”
Both the PARALLEL and UNRECOVERABLE options greatly speed up movement of data during table and index reorganizations, and index rebuilds. Space Manager supports both options.
• The PARALLEL option allows Oracle to use multiple processes to move data in parallel. From Space Manager, you can specify the degree of parallelism in accordance with the number of CPUs available on a server.
• The UNRECOVERABLE option turns off writing to Oracle redo logs and rollback segments during reorganization. While this means increased speed, it also means there are no records to use for data recovery. Because of this, it is advisable to make a hot backup immediately after reorganizing with the UNRECOVERABLE option.
Flexibility
Space Manager with LiveReorg brings flexibility to space management by allowing you to perform reorganizations at your convenience and with your specifications. Reorganization scripts can be executed on demand directly from the Space Manager with LiveReorg client or they can be scheduled for execution on the server.
Space Manager with LiveReorg does not have the capability to reorganize a tablespace from multiple data files into one datafile, as SAPDBA does.
Technical Brief
Optimal placement of tables, partitions, and indexes in tablespaces improves database performance. For example, placing heavily accessed tables and individual partitions in separate tablespaces better distributes I/O requests among various datafiles and disks. However, moving objects from one tablespace to another often involves extensive SQL scripting.
Space Manager with LiveReorg automatically generates all the necessary SQL to move tables, partitions, and indexes to a different tablespace. To maximize speed for object relocations, Space Management moves data inside the database and supports the PARALLEL and UNRECOVERABLE options.
SAP Tables
The number of objects in SAP databases is significant—in excess of 150K in the latest releases. Every SAP system has all the tables no matter what SAP module (Sales and Distribution, Materials Management, Controlling and Profitability Analysis, etc.), language, or other option is implemented. A single tablespace will have several thousand tables and, in most recent releases, over one hundred thousand tables and table partitions or sub-partitions.
Cautions
You can relocate the most active tables from tablespaces such as PSAPBTABD, but you should not relocate all the objects and drop any native SAP tablespaces. SAP upgrade procedures refer to and use standard SAP tablespace names and errors could result. In any case, such changes should not be necessary. Many objects in tablespace PSAPBTABD, for example, will not grow and are not used because there is no business use for them; therefore, there is no need to manipulate the location of those objects.
The objects in tablespaces with the SAP release name in their tablespace name (such as PSAPES46BD and PSAPEL46BD) should not be relocated. These tablespaces have objects related to SAP releases used. When an SAP upgrade is undertaken, these tablespaces will be dropped at the end of upgrade. New tablespaces for future releases are created at the start of the upgrade process and loaded with new objects.
16
Job Monitoring
To help you follow the progress of reorganization jobs, Space Manager with LiveReorg provides a Job Monitor and Live Reorganization Details. The Job Monitor shows transaction and operation statistics for the stages of a live reorganization as they are performed so that you can estimate when the table switch will occur. It lets you see which stages are complete and which stage is underway. It also provides execution logs, error logs, and error handling.
Job Alerts
You can choose to receive e-mail notifications that alert you immediately when scheduled execution fails, so you can monitor jobs even when you are away from the Space Manager client computer. Each e-mail specifies the script name, execution error, execution start and stop times, database server hostname, and Oracle SID for the database.
Technical Brief
4. CAPACITY PLANNING
Space Manager’s capacity reports help forecast your future space needs. Based on the information they provide, you can perform preventative maintenance and avoid the sudden out-of-space conditions that can lead to database downtime.
Tracking Space Usage
The Tablespace Failure Prediction report shows space allocation and predicts when tablespaces will run out of space and fail. This report also predicts when extents will be allocated, how large the extents will be, and how large objects will be after each allocation. Predicted object growth can be viewed in graph and table formats.
Trending Space Usage
The Trend Analysis report projects growth trends over a date range you specify for one or more objects, such as the objects in a certain tablespace or the largest objects in a database. This report can project growth based on current or hypothetical growth rates. Projections can be displayed in either tabular or graphical format, and all readings can be exported to popular spreadsheet packages for further analysis.
18
5. SAP CONSIDERATIONS
I/O is a concern on any production system. Space Manager with LiveReorg takes advantage of dynamic session settings that allow more “work” to be done in memory instead of disk. Not only does this alleviate I/O, it makes the script run much faster. In addition to these memory settings, we can load the tables and indexes using parallelism for an even faster script.
Depending on your Oracle version, you can set the following options:
• sort_area_size (not used when pga_agregated_target is set) – This parameter controls the maximum amount, in bytes, of memory for each sort. If the sort area is too small, an excessive amount of I/O will result. If sort area is too large, the OS paging rate will be too high. It is especially important to consider this when using a high degree of parallelism to build indexes, since that total amount of sort area used will be [((degree of parallelism *2) + 1) * sort_area_size]. 1-2 M is a good rule of thumb when using PQO. If you are not using parallelism, consider setting sort_area_size to the size of the largest index being reorganized.
• sort_area_retained_size (not used when pga_agregated_target is set) – This parameter controls the maximum amount, in bytes, of user global area memory retained after a sort run completes. If you are using parallel query, set this to the same value as sort_area_size. Otherwise, set it to the same or one half of sort_area_size, depending on available memory. Note that excess memory is not returned to the operating system.
• db_file_multiblock_read_count – This parameter controls the number of data blocks read for each read request during a full table scan. If you are using LVM or striping, this parameter should be set so that <db_block_size * db_file_multiblock_read_count> is a multiple of the LVM stripe size.
If you are not using LVM or striping, <db_block_size * db_file_multiblock_read_count> should equal the maximum operating system read buffer. On many UNIX systems this is 64 KB. In any case, db_file_multiblock_read_count cannot be larger than <db_block_buffers / 4>. The maximum read buffer is generally higher on raw file systems. It varies from 64K (on AIX) to 128K (on Solaris) to 1MB (on HP-UX). On a UNIX file system, it is usually possible to read only one buffer per I/O, usually 8K. On 32-bit Windows, the buffer is 256K.
Properly tuning this parameter will significantly increase the performance of reorganization. For example, suppose the OS read buffer is 64 KB, the database block size is 4 KB, and db_file_multiblock_read_count is set to 8. During a full table scan, each I/O operation will read only 32 KB. If db_file_multiblock_read_count is instead set to 16, performance will almost double because twice as much data can be read in each I/O operation.
Technical Brief
Managing the Time of Switch of the T-LOCK Method
During the Table Switch stage in a T-Lock LiveReorg, the original table is replaced with the reorganized copy table and the original indexes are replaced with reorganized copy indexes. At the start of the switch, both tables are locked with a T-lock (trigger lock) to prevent changes and preserve referential integrity.
There are three ways to schedule the switch: automatic, during time window, and upon approval. The safest practice is to switch the table during a maintenance window when the SAP application is down for user access (note that a maintenance window is not needed with the ONLINE switch method.) Another choice is to choose the period of switch carefully, while user activity on the system is at a minimum and the SAP application is up, and combine the switch with utilization of SAP transaction SM13. With SM13 you can deactivate the update process; however, note that deactivating the update process works only for asynchronous update processing, and not all the updates in SAP system are executed with asynchronous update mechanism. Suspending updates via SM13 offers no protection from direct updates executed from dialog and background work processes.
If any DML activity is encountered during the table switch, an SAP ABAP short dump will result. Short dumps can be monitored with SAP transaction ST22.
The Importance of a TEMPORARY Tablespace
In general, the tablespace of type TEMPORARY is critical for supporting index sorts that cannot be handled in memory. The index builds will be very slow if adequate TEMPORARY tablespace is not available. To reduce temporary segment lock allocation contention and save the costs involved in temporary segment allocation (equivalent to approximately ten insert, update, or delete statements), make sure that you have designated a tablespace with TEMPORARY contents. Check the ‘contents’ field in DBA_TABLESPACES to view the status of your tablespaces. The size of this tablespace should be, at minimum, as big as your biggest index. The default temporary tablespace is named PSAPTEMP. You can create an alternative tablespace, such as PSAPTEMP_REORG, of type TEMPORARY.
SAP generally recommends setting the status of the temporary tablespace to PERMANENT. You can check with SAP for the latest recommendation. Usually in SAP environments, tablespaces are created with content permanent and the parameters for initial/next are set to the same value and pctincrease to 0. Setting pctincrease to 0 (zero) causes SMON not to coalesce the free space; although the temporary table is dropped, new users don't have to waste time breaking up a large extent into a smaller one they need. They will find an exact sized extent in the tablespace. (obsolete)
Using Locally Managed Tablespaces
For better performance and ease of administration, starting with Oracle 8.1.7 or higher and SAP R/3 4.6 or higher, it is recommended to create new tablespaces as locally managed (LMTs) in the Oracle database (see OSS note 409376, “Use of locally managed tablespaces for SAP R/3”). Starting with SAP R/3 6.10, LMTs are the default configuration for new SAP installations; any tablespace is created as LMT. The other tablespaces can remain unchanged.
20
Automatic Segment Space Management (ASSM)
The new ASSM function is available as of Oracle Release 9i. Up to Oracle 9i, MANUAL was the only method that Oracle provided for segment space management. This method uses free storage lists (free lists). If you use this method, it is possible (and sometimes required) to explicitly set and tune the PCTUSED, FREELISTS, and FREELIST_GROUPS storage parameters.
As of Oracle 10g, ASSM is already contained in the standard system, and new tablespaces are by default created as ASSM tablespaces. Oracle uses bitmaps as storage structures for managing free space in ASSM tablespaces. It is no longer required to tune the PCTUSED, FREELISTS, and FREELISTGROUPS storage parameters manually; you can simply select “use tablespace defaults” in the global storage option section in the reorg manager. Advantages of ASSM are improved reuse of free space and scalability with both the number of users and the number of RAC instances.
To be able to use ASSM, first create new tablespaces with ASSM using BR*Tools. Afterwards, move the objects from the old DMTS or LMTS to the ASSM tablespace that you created.
For more information see Note 620803.
New Tablespace Layout
In order to use locally managed tablespaces and automatic segment space management, you have to create new tablespaces. As of SAP Web Application Server Release 6.10 and above, this is the new tablespace layout instead of the classical one with ca.20 tablespaces PSAP<TABART>D/I with TABART like BTAP, STAB, DDIC, etc.
The new tablespace layout contains the following tablespaces:
• SYSTEM (tablespace for the Oracle dictionary)
• SYSAUX (additional tablespace as of Oracle database 10g)
• PSAPTEMP (default tablespace for database sort operations)
• PSAPUNDO/PSAPROLL (default tablespace for segment undo/rollback)
• PSAP<SCHEMA_ID> (default tablespace for all SAP objects of the ABAP stack)
• PSAP<SCHEMA_ID>DB (default tablespace for all SAP objects of the Java stack)
• PSAP<SCHEMA_ID>USR (default tablespace for all customer objects)
• PSAP<SCHEMA_ID><REL> (default tablespace for release-dependent data)
• PSAP<SCHEMA_ID><NAME> (Additional tablespace for example, for large tables)
The SCHEMA_ID is now fully independent of the SAP SID or Oracle SID.
For more information see Note 355771, “Oracle: Explanation of the new tablespace layout.”
Technical Brief
Relocating Objects
The new tablespace PSAP<SCHEMA_ID><NAME> should be used for large tables. The number of extents in local managed tablespaces no longer impacts performance because all extent management operations are done in the tablespace extent bitmap and not in the data dictionary. For administrative purposes, it is recommended to move very large tables to separate tablespaces with objects > 60GB to local managed tablespaces with UNIFORM EXTENT. (Note: be careful if you are moving a large table from an old data dictionary managed tablespace with 10K+ extents, because dropping such a table can take hours and during that time, your data dictionary will be locked. Therefore, use downtime to drop the renamed original table.)
In SAP databases, an object has a data class. This information is stored in tables TSORA, TAORA, and IAORA. This information is used, for example, for creating new tables or indices and during upgrade procedures. Each data class is assigned a tablespace where objects of this class are stored.
When relocating objects with Space Manager with Live Reorg, it is recommended to update the DD09L data classes and tablespace assignment information as described in Note 154193, “SAPDBA: Reorganization using external tools.” SAPDBA or BR*Space adjusts the SAP ABAP Dictionary when relocating a object. If you use Space Manager with LiveReorg, you should execute the SQL statements described in the note after successfully relocating the tables to the target tablespaces. This note is not relevant if a table is reorganized only and not relocated.
Heavy Loaded Systems
On heavy loaded systems, it is necessary to consider how much free space you need in the archive log directory. Look at how much redo volume your system produces per hour. Count the number and size of your redo logs, including the number of redo switches per hour on average and during peak hours. Depending on the reorganization method and parallelism option you choose, your redo volume can increase from 2 to 30 GB/hour. On production systems and systems with standby database where you cannot use the NOLOGGING option, set the degree of parallelism accordingly. Make sure that your backup strategy can keep up with copying and deleting archive logs, especially if you reorganize tables larger than 300 GB, where the reorg job will run into peak hours. Monitor the archive space and, if necessary, cancel or pause the job.
22
Reorg or Not to Reorg
Space Manager with LiveReorg gives you information about the need for reorganization. There are some special considerations in a SAP environment. To find objects needing reorganization, you can use appropriate reports or the graphical view in the Tablespace Map. The percentage of wasted space with the allocation gives you information about how much space you can save. The need ratio parameter indicates how much you will gain from the reorganization compared to the effort (based on the size of the object and the cost to reorg it). A good rule of thumb is to reorg everything with a need ratio above 10.
This data is calculated from the raw data collected by statistics runs. BR*Tools uses DBMS_STATS as the default collection method. This method does not collect all the necessary data, such as the number of chained rows and the average space and empty blocks for LONG and LONG RAW columns, so the space saving could be over- weighted. A possible way to get good data for the analysis is to use QAS system, which is the exact copy of your PROD system, and use the ANALYZE command to gather the statistics there. It is not recommended to use ANALYZE in production because of its long run time, its lack of ability to parallelize, and the short locks on your objects.
Another item to consider is the parameter PCTFREE. In SAP, PCTFREE defaults to 10, which reserves 10% of free space in the data blocks. You may want to set this parameter to 0 on tables and table partitions that have already been archived and for which no new updates are expected. Do not set the parameter lower than 10 on living tables (that is, those for which UPDATEs are still possible); otherwise, increased row chaining may result.
Technical Brief
Space Manager provides more than just space reorganization. Successful space management must include problem detection; preventive maintenance (through object sizing and capacity planning); high-speed reorganizations and relocations; and problem prediction.
Every aspect of space management can be performed easily and efficiently with Space Manager with LiveReorg. It provides the DBA with a comprehensive solution that meets all the challenges of achieving optimal performance, availability, and capacity.
24
APPENDIX: SAP EVALUATION
SAP Labs has successfully conducted an integration assessment for Space Manager with LiveReorg.
SAP is satisfied that deploying Space Manager with LiveReorg in a SAP production environment poses no risk to SAP customers and that such deployment will not affect the support agreement between SAP and its customers. This conclusion is documented in OSS note 1285268.
Technical Brief
ABOUT THE AUTHOR
Lenka Vanek is a Director of Software Development for Quest Software, responsible for the company’s database products related to design, development, administration and availability. She has 20 years of experience in both the information technology and business arenas.
Ales Zeman is a Senior Presales Consultant for Quest Software, working for nine years there in the area of application and database management solutions. He leads reorganization and migration projects for customers in SAP and Oracle production environments. Alex has a Technology Consultant Certificate for SAP NetWeaver Web and more than 13 years of IT experience
26
ABOUT QUEST SOFTWARE, INC.
Quest Software, Inc., a two-time winner of Microsoft’s Global Independent Software Vendor Partner of the Year award, delivers innovative products that help organizations get more performance and productivity from their applications, databases Windows infrastructure and virtual environments. Quest also provides customers with client management through its ScriptLogic subsidiary and server virtualization management through its Vizioncore subsidiary. Through a deep expertise in IT operations and a continued focus on what works best, Quest helps more than 100,000 customers worldwide meet higher expectations for enterprise IT. Quest’s Windows management solutions simplify, automate secure and extend Active Directory, Exchange Server, SharePoint, SQL Server, .NET and Windows Server as well as integrating Unix, Linux and Java into the managed environment. Quest Software can be found in offices around the globe and at www.quest.com.
Contacting Quest Software
Email: [email protected]
Mail: Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA 92656 USA
Web site: www.quest.com
Please refer to our Web site for regional and international office information.
Contacting Quest Support
Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have a valid maintenance contract. Quest Support provides around the clock coverage with SupportLink, our web self-service. Visit SupportLink at http://support.quest.com
From SupportLink, you can do the following:
• Quickly find thousands of solutions (Knowledgebase articles/documents). • Download patches and upgrades. • Seek help from a Support engineer. • Log and update your case, and check its status.
View the Global Support Guide for a detailed explanation of support programs, online services, contact information, and policy and procedures. The guide is available at: http://support.quest.com/pdfs/Global Support Guide.pdf
Contents
Challenges
Row Chaining
Stagnated Indexes
Data Partitioning
Wasted Space in Locally Managed Tablespaces
Locally Managed Tablespace Autoallocate
1. Problem Detection
Partitioned Objects
Index Reorganization
Tablespace Reorganization
Option #2: Reorganize a Tablespace Using External Space
Option #3: Full Tablespace Defragmentation
Sorted Reorganizations
The Importance of a TEMPORARY Tablespace
Using Locally Managed Tablespaces
Relocating Objects
Conclusion

Documents

Improve Performance in SAP Application Environments with Space