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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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).
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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).
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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.
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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
Improve Performance in SAP Application Environments with Space
Manager with LiveReorg
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