2 - 1

2 - 2

2 - 3

These main areas contain the individual functions of the DBA Cockpit, which you can start by double-clicking.

There is a button to hide or reveal the navigation tree.

The DBA Cockpit provides the relevant functionality from the old transaction codes ST04, DB02, DB13, DB12,

DB14, and DB13C.

Old transactions ST04, DB02, DB13 and others are still available, but have been renamed to ST04OLD,

DB02OLD, DB13OLD, and so on. The underlying functions have status ―deprecated‖. ST04N no longer exists.

Prerequisites for implementing the DBA Cockpit:

Certain performance monitors in the DBA Cockpit require special database objects.

These objects are created with an SQL script. You can find the script and more information in Note 706927.

You need BR*Tools 700 patch level 24 or higher for the Planning Calendar.

Some DBA Cockpit functions require the Oracle Active Workload Repository. See Note 1028068 for more

information on how to set this up.

The above prerequisites apply to the local system, which is the system where the DBA Cockpit is running.

See Note 1028624 for more information and details of corrections.

2 - 4

See note 1028624

2 - 5

2 - 6

2 - 7

Locally Managed Tablespaces

A tablespace that manages its own extents maintains a bitmap in each datafile to keep track of the free or

used status of blocks in that datafile. Each bit in the bitmap corresponds to a block or a group of blocks. When

an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status of the

blocks. These changes do not generate rollback information because they do not update tables in the data

dictionary (except for special cases such as tablespace quota information).

Dictionary Managed Tablespaces

If you created your database with an earlier version of Oracle, then you could be using dictionary managed

tablespaces. For a tablespace that uses the data dictionary to manage its extents, Oracle updates the

appropriate tables in the data dictionary whenever an extent is allocated or freed for reuse. Oracle also stores

rollback information about each update of the dictionary tables. Because dictionary tables and rollback

segments are part of the database, the space that they occupy is subject to the same space management

operations as all other data.

Locally managed tablespaces have the following advantages over dictionary managed tablespaces:

Local management of extents automatically tracks adjacent free space, eliminating the need to coalesce

free extents.

Local management of extents avoids recursive space management operations. Such recursive operations

can occur in dictionary managed tablespaces if consuming or releasing space in an extent results in

another operation that consumes or releases space in a data dictionary table or rollback segment. The

sizes of extents that are managed locally can be determined automatically by the system. Alternatively, all

extents can have the same size in a locally managed tablespace and override object storage options.

The LOCAL clause of the CREATE TABLESPACE or CREATE TEMPORARY TABLESPACE statement is

specified to create locally managed permanent or temporary tablespaces, respectively.

2 - 8

2 - 9

initSID.ora parameters to setup AUM:

UNDO_MANAGEMENT

Switches automatic UNDO management on/off

UNDO_TABLESPACE

Defines which automatic UNDO Tablespace is used (PSAPUNDO)

UNDO_SUPPRESS_ERRORS

Suppresses errors if invalid UNDO command is issued

UNDO_RETENTION

Specifies the time in seconds Read Consistency should be guaranteed

SAP Note 600141: UNDO_RETENTION: start with 10800 sec (or more)

2 - 10

Creation of additional tablespaces might be an option for

Larger InfoProvider

Aggregates of larger InfoCubes

PSA Tables

ODS Tables

Maintain tables (see Note 46272) and transport the corresponding entries for DDART, DARTT from development to the productive system

Assign data classes to the objects before activating them in the development system and transport the objects

The tablespaces can differ between development and productive system (correlation between data class and table space is stored in table DDART), but the assignment of data classes to the objects must not.

2 - 11

Mainly there are two reasons to separate objects in its own tablespace: Administration and Performance.

But with new storage technologies the performance issue is less important every day. Furthermore, in the

newest storage systems it's not so easy to separate physical disks to distribute access to data.

In case of administration – for example – it is hardly possible to reorganize i.e. PSAPFACTD if it contains the

whole BW stuff within an acceptable time frame.

2 - 12

2 - 13

2 - 14

See SAP notes 701235, 1109743 (Index compression) and 1289494 (FAQ Compression) and 1231895 (Compress PSA tables)

Please keep in mind that the ABAP Dictionary does not currently support compression. This means that the compression is lost when a compressed table is reorganized.

How does Oracle's table compression feature work? In what situations should table compression be used, and how does it affect performance?

Oracle introduced the table compression feature in Oracle 9i Release 2. Table compression in Oracle is accomplished by eliminating duplicate values within a database block and replacing them with short references to entries in a symbol table. A symbol table, also known as a dictionary, is automatically created in each database block where data has been compressed.

This design makes each database block of a compressed table self-contained, meaning that all information needed to uncompress a database block is available within the block itself. Individual partitions of a partitioned table can be compressed, as can materialized views.

A symbol table is only created in database blocks that have been compressed, and not all blocks of a compressed table are necessarily compressed. Blocks that contain values with little repetition, or very short values, are not compressed by Oracle‘s table compression algorithm.

For tables with a lot of duplicate values, Oracle‘s table compression feature can dramatically reduce the size of the table segment. This can reduce disk space usage and buffer cache requirements, which in turn can reduce misses in the buffer cache. In many cases improvements in I/O efficiency are gained as a result of accessing considerably fewer database blocks for the same amount of data. Full table scans, exports, and database backups are among the operations that benefit the most from table compression.

There is a small CPU overhead involved in reconstructing the compressed blocks. However, the I/O performance gains typically more that make up for it. Table compression is targeted primarily for data warehouse environments, where the tables are read-only or read-mostly. However, tables in others environments may benefit from compression as well. Table compression is not appropriate for tables that participate in DML operations because of the overhead associated with them and limitations on the table compression feature. Only new data that is inserted into a table via a bulk load operation is eligible for compression. Bulk loads are done using SQL*Loader‘s direct path load option, INSERT statements that use the APPEND hint, and the CREATE TABLE AS SELECT statement. Compression only applies to the new data being loaded—the compression status of existing database blocks remains unchanged.

Two ways to compress previously loaded data in existing tables are:

ALTER TABLE t1 MOVE COMPRESS; This moves table t1‘s data into a new segment that is compressed. After the move operation, the indexes become unusable and need to be rebuilt. To compress one partition of a partitioned table, the statement ALTER TABLE t1 MOVE PARTITION p1 COMPRESS is used instead.

CREATE TABLE t2 COMPRESS AS SELECT * FROM t1; This creates a compressed copy of an existing table. Indexes and constraints are left on the original table and need to be created on the new table manually. Other table dependencies such as views, triggers, and foreign keys need to be considered as well.

Note that there are some limitations to the table compression feature. As we already mentioned, only data inserted using a bulk load mechanism gets compressed. Also, LOB columns and index-organized tables cannot be compressed. In addition, tables with bitmap indexes cannot be compressed. (However, bitmap indexes can be dropped and re-created after the table has been compressed.)

Another issue to be aware of is that in Oracle 9i it is not possible to add or drop columns from a compressed table. This limitation has been lifted in Oracle 10g. (Refer to MetaLink note 281472.1 for more information.)

Oracle‘s table compression feature can significantly reduce the amount of space needed to store certain types of data. This can lead to reduced disk storage and buffer cache sizing requirements, and improved performance for certain types of operations. Although primarily intended for data warehouse environments, table compression can be beneficial in many situations where data is usually loaded in bulk and used primarily read-only after that.

2 - 15

2 - 16

2 - 17

The Program Global Area is a private memory region containing data and control information for a server

process. Each time a cursor is executed, a new runtime area is created for that cursor in the PGA memory

region of the server process executing that cursor.

When running under the automatic PGA memory management mode, sizing of work areas for all dedicated

sessions becomes automatic. Thus, the *_AREA_SIZE parameters are ignored by all sessions running in that

mode.

Performance views to monitor PGA performance:

- V$PGASTAT

- V$PROCESS

- V$SQL_WORKAREA_HISTOGRAM

- V$SQL_WORKAREA_ACTIVE

- V$SQL_WORKAREA

2 - 18

How to adjust the PGA_AGGREGATE_TARGET value?

Estimate a reasonable start value

PGA_AGGREAGATE_TARGET = (<Total physical memory> x 80%) x 50%

20% for operating system, 50% of remaining 80% for PGA, other 50% for SGA

additional you can calculate PGA_AGGREAGATE_TARGET >=

(sort_area_size+hash_area_size+..) x (number of shadow processes)/10

division by ten as not all shadow processes will do sort / hash operations simultaneously

also has to be fulfilled

sga_max_size+pga_aggregate_target <= <phys. memory on DB server)

Tune and monitor PGA_AGGREGATE_TARGET

v$pgastat

v$sql_workarea

v$sql_workarea_histogram

v$sql_workarea_active

v$process with new columns pga_used_mem, pga_alloc_mem, pga_max_mem

V$pga_target_advice

v$pga_target_advice_histogram

to fill all views set STATISTICS_LEVEL=ALL or STATISTICS_LEVEL=TYPICAL

2 - 19

Total PGA inuse: actual resource consumption

Aggregate PGA target parameter – This value is derived from the value on the init.ora parameter

pga_aggregate_target.

Some parts of the PGA are used for non-tunable information such as session con information and other

overhead. The rest of the PGA memory footprint is dynamically tunable and is indicated by the aggregate PGA

auto target statistic. The value in the second line (aggregate PGA auto target should not be significantly

smaller than the value in the first line, as it is above. If this value is too small, then Oracle does not have

enough memory to dynamically adjust.

Global memory bound – This statistic measures the max size of a work area, and Oracle recommends that

whenever this statistics drops below one megabyte, then you should increase the value of the

pga_aggregate_target parameter.

Total PGA allocated – This statistic display the high-water mark of all PGA memory usage on the database.

You should see this value approach the value of pga_aggregate_target as usage increases.

Total PGA used for auto workareas – This statistic monitors RAM consumption or all connections that are

running in automatic memory mode. Remember, not all internal processes may use the automatic memory

feature. For example, Java and PL/SQL will allocate RAM memory, and this will not be counted in this

statistic. Hence, we can subtract value to the total PGA allocated to see the amount of memory used by

connections and the RAM memory consumed by Java and PL/SQL.

They are over allocation count and cache hit percentage. If Oracle determines that it cannot honor the setting

for PGA_AGGREGATE_TARGET, then it needs to allocate additional memory. The number of times Oracle

detects this condition since instance startup is noted by the over allocation count statistic. Ideally, this value

should be zero

Estimated PGA memory for optimal/one-pass – This statistic estimates how much memory is required to

execute all task connections RAM demands in optimal mode. Remember, when Oracle9i experienced a

memory shortage, he will invoke the multi-pass operation. This statistics is critical for monitoring RAM

consumption in Oracle9i, and most Oracle DBA‘s will increase pga_aggregate_target to this value

2 - 20

V$SYSSTAT: cumulated values since start of instance

The optimal executions are those operations that were performed entirely in memory. As the name suggests,

this is the most favorable type of execution. If the operation was too big to be performed in memory, then part

of the operation spills onto disk. If only one pass was needed on disk, then this execution is noted in the

onepass statistic. If more than one pass was needed on disk, then this execution is noted in the multipass

statistic. Ideally, all executions should be in the optimal statistic and the statistics for onepass and multipass

should be zero.

2 - 21

2 - 22

2 - 23

Do not schedule the job SAP_ANALYZE_ALL_INFOCUBES any longer. This job causes new entries of BW

tables in table DBSTATC with ignore flag = ‚X‗. To remove those entries you have to run report

SAP_DBSTATC_CLEANUP.

If DBSTATC is not cleaned up then BRCONNECT might not gather all necessary statistics! See SAP Note

129252 for details.

Advantages of DBMS_STATS:

It is possible to use histograms for global statistics of partitioned objects

Table-internal parallel processing is possible (Note 408532)

You can transport statistics to other systems

You can back up and reactivate statistics

Disadvantages of DBMS_STATS:

DBMS_STATS only determines statistical data that is relevant to CBO. It does not include useful columns that

are useful for monitoring purposes, such as AVG_SPACE (See Note 821687), EMPTY_BLOCKS (again, see

Note 821687),AVG_SPACE_FREELIST_BLOCKS or NUM_FREELIST_BLOCKS. As a result, you cannot

make assertions about space utilization and fragmentation on the basis of DBMS_STATS statistics, for

example, or you can only partially do so.

With BI 7.10 und BI 7.00 Support Package 8, the system dynamically checks whether new statistics have to be

created. The heuristics correspond to those of BRCONNECT.

2 - 24

SAP Note 838725 - Oracle 10.2: Dictionary and system statistics

927295

2 - 25

Alternative you can check the statistics by analyzing the log of BRCONNECT (DB14).

2 - 26

2 - 27

Degree:

Degree of Parallelization during Aggregate and Index Building

This parameter sets the number of parallel processes.

The value 0 corresponds to the default value in Oracle configuration ('PARALLEL DEFAULT').

Logging while Index:

Deactivates NOLOGGING while Building Index.

By default, Oracle database logging is deactivated for index structure. This means that indexes cannot be

restored from a database backup. They need to be structured again e.g. with the transaction RSRV.

If this parameter is set, the index structure is written to the database backup. This can lead to a quicker

restoretime but slows down building of the index.

Note: Especially for Recovery and NOLOGGING of Indexes see SAP note 849485

2 - 28

Further details can be found in SAP Note 1047462

2 - 29

2 - 30

2 - 31

2 - 32

2 - 33

2 - 34

2 - 35

2 - 36

See SAP Note 1013912 - FAQ: Oracle BW Performance

SELECT

DECODE(LVL, 1, PARTITION, ' ' || PARTITION) PARTITION,

DECODE(COL, LAG(COL, 1) OVER (ORDER BY COL, LVL, PARTITION), ' ',

COL) COLUMN_NAME, NUM_DISTINCT, NUM_BUCKETS,

LAST_ANALYZED,

DECODE(LAST_ANALYZED, NULL, 'No statistics',

DECODE(SIGN(NUM_DISTINCT - 1), 1,

DECODE(NUM_BUCKETS, 1, 'No histograms', ''), '')) "COMMENT"

FROM

( SELECT 1 LVL, COLUMN_NAME COL, 'TABLE' PARTITION, NUM_DISTINCT, NUM_BUCKETS,

TO_CHAR(LAST_ANALYZED, 'dd.mm.yyyy hh24:mi:ss') LAST_ANALYZED

FROM

DBA_TAB_COLUMNS

WHERE

TABLE_NAME like '/BIC/FWS_STKC0%'

UNION

(SELECT

2 LVL,

COLUMN_NAME COL,

PARTITION_NAME,

NUM_DISTINCT,

NUM_BUCKETS,

TO_CHAR(LAST_ANALYZED, 'dd.mm.yyyy hh24:mi:ss') LAST_ANALYZED

FROM

DBA_PART_COL_STATISTICS

WHERE

TABLE_NAME like '/BIC/FWS_STKC0%') )

ORDER BY

COL,

LVL,

PARTITION;

2 - 37

2 - 38

We say a row in a table is ―chained‖ if the row is stored in two or more data blocks. This can happen because the row was too big to fit in one data block, or because an update of an existing row required additional space and there wasn‘t sufficient space available in the data block. We say a row is ―migrated‖ if, during the course of an update, Oracle moved the entire row to a different data block (with more space) instead of leaving part of the row in the original data block and chaining to a new data block. Index ROWIDs still point to the original location for the row, and a forward address there points to the new location.

Chained or migrated rows in database tables can potentially have a performance impact, depending on how frequently these rows are fetched during a typical workload. To fetch a migrated row, the data block referenced by the ROWID needs to be fetched first in order to obtain the new address of the row. Similarly for chained rows, the head of the chained row contains the address of the next part of the row, which might again contain an address for another part. In effect, multiple I/O operations are required when accessing a chained or migrated row instead of just one.

Migrated rows are special cases of chained rows and are treated the same way by Oracle when statistics are accumulated for them. The effect of reading more than one data block to fetch column data from one row is known as ―table fetch continued row.‖ The value of this statistic in v$sysstat and v$sesstat is increased by one every time a row is fetched this way.

One way to measure the performance impact of row chaining is to determine the percentage of rows fetched either by ROWID or table scan that incurred a ―table fetch continued row‖ since instance startup. The following query calculates this percentage as pct_chained_row:

SELECT C.value / (A.value + B.value) * 100.0 AS pct_chained_row FROM v$sysstat A, v$sysstat B, v$sysstat C WHERE a.name = 'table fetch by rowid‘ AND b.name = 'table scan rows gotten‘ AND c.name = 'table fetch continued row‗; If pct_chained_row is consistently high, excessive row chaining may be degrading system performance and further research might be appropriate.

Note that migrated rows do not impact performance of full table scans; all data blocks up to the table‘s high water mark are scanned and rows in blocks containing reference to migrated rows are ignored because all rows will eventually be read. Chained rows may still need to be fetched as a ―continued row‖ even in a table scan in order to get the address of the rest of the row from the first part. However, in situations where the needed column values are stored in the first block of the chain, the fact that a row is chained will not have a performance impact on either a table scan or access by ROWID.

You can determine the number of chained or migrated rows in a table with the ANALYZE TABLE statement. This statement updates the chain_cnt column in user tables appropriately. (Note that dbms_stats does not update chain_cnt.) To identify which rows are chained or migrated, use the ANALYZE TABLE statement with the LIST CHAINED ROWS clause. By default this populates a table called chained_rows (created by utlchain.sql) with information on the table‘s chained rows. The column head_rowid shows the ROWID that starts the chain for each chained row.

It might not be practical to analyze all tables in the database to identify those with chained rows. Also, chained rows in tables that are rarely used may not degrade performance much. Therefore row chaining and migration do not always represent a problem. Consider the performance impact carefully before hunting down chained rows and trying to fix them.

There are multiple ways to fix chained rows in tables. The best approach in each case depends on factors such as data availability requirements, percentage of rows that are chained, and whether the table has a LONG or LONG RAW column. Some options are:

Move the table with ALTER TABLE MOVE Copy the chained rows to a temporary table and then delete and reinsert them Use the dbms redefinition package to reorganize the table online Export the table, drop it, and re-import it

2 - 39

2 - 40

2 - 41

2 - 42

2 - 43

Hints are no longer generated

2 - 44

2 - 45

2 - 46

2 - 47

2 - 48

2 - 49

2 - 50

2 - 51