SAP Basis CCMS

Monitoring in the CCMS
PDF download from SAP Help Portal:
http://help.sap.com/saphelp_nw70/helpdata/en/49/073e674cab209ce10000000a42189d/content.htm
Created on January 28, 2015
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing subtopics.
© 2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 1 of 101

Table of content
1 Monitoring in the CCMS
1.1 CCMS: Informix
1.2 Choosing an Action Pattern in the DBA Planning Calendar
1.3 Archiving or Backing Up the Database in the DBA Planning Calenda
1.4 Backing Up the Logical Log in the DBA Planning Calendar (Informi
1.5 Backing Up the Logical Log (Automatic) in the DBA Planning Calen
1.6 Updating Statistics in the DBA Planning Calendar (Informix)
1.7 Checking Statistics in the DBA Planning Calendar (Informix)
1.8 Checking the DB System in the DBA Planning Calendar (Informix)
1.9 Monitoring the Database with the Alert Monitor (Informix)
1.10 Checking Physical Consistency in the DBA Planning Calendar (Info
1.11 Scheduling Actions in the DBA Planning Calendar
1.12 SAP Database Guide: Informix (BC-DB-INF-DBA)
1.13 ON-Archive for Data Recovery
1.14 Configuration of ON-Archive
1.15 Configuring ON-Bar
1.16 ON-Bar for Data Recovery
1.17 Recovery Report with SAPDBA
1.18 Configuring the Monitoring Architecture
1.19 The Alert Monitor
1.20 CCMS Agents
1.21 Operating System Monitor
1.22 Database Monitor
1.22.1 SAP/Oracle Database Monitor (New)
1.22.1.1 Main Monitor
1.22.1.2 Viewing History Information
1.22.1.3 Overall Activity
1.22.1.3.1 Buffer Busy Waits
1.22.1.3.2 Filesystem Requests
1.22.1.3.3 System / Wait Events
1.22.1.3.4 Undo Statistics
1.22.1.3.5 Automatic Segment Space Management
1.22.1.3.6 Online Redefinition Tables
1.22.1.3.7 Resumable Space Allocation
1.22.1.3.8 Parallel Query
1.22.1.3.9 Performance Database
1.22.1.4 Resource Consumption
1.22.1.4.1 Oracle Session Monitor
1.22.1.4.2 SQL Request
1.22.1.4.3 Top SQL Statements
1.22.1.4.4 Table Access Monitor
1.22.1.4.5 Latch Monitor
1.22.1.4.6 PGA Monitor
1.22.1.4.7 SGA Monitor
1.22.1.5 Exceptional Conditions
1.22.1.5.1 Enqueue Monitor
1.22.1.5.2 Lock Monitor
1.22.1.5.3 Database Message Log
1.22.1.6 Additional Functions
1.22.1.6.1 Display V$/GV$ Views
1.22.1.6.2 Parameter Configuration
1.22.1.6.3 Arbitrary Monitoring
1.22.1.6.4 System Statistics for the CBO
1.22.1.6.5 Checkpoints
1.22.1.6.6 Data Guard
1.22.2 SAP/Oracle Database Monitor (Old)
1.22.2.1 SAP/Oracle Database Monitor: Introduction
1.22.2.2 SAP/Oracle Database Monitor: Main Screen
1.22.2.2.1 Sorts (Oracle)
1.22.2.2.2 Time Statistics (Oracle)
PUBLIC
Page 2 of 101

1.22.2.2.3 Table Scans/Table Fetch (Oracle)
1.22.2.2.4 Redo Log Buffer (Oracle)
1.22.2.2.5 Calls (Oracle)
1.22.2.2.6 Data Buffer (Oracle)
1.22.2.2.7 Shared Pool (Oracle)
1.22.2.2.8 Detailed Analysis (Oracle)
1.22.2.2.9 Detail Analysis Menu (Oracle)
1.22.2.2.10 File System Requests (Oracle)
1.22.2.2.11 Buffer Busy Waits (Oracle)
1.22.2.2.12 Wait Events (Oracle)
1.22.2.2.13 Dictionary Buffer (Oracle)
1.22.2.2.14 SAP Client (Oracle)
1.22.2.2.15 Oracle Sessions
1.22.2.2.16 SQL Request (Shared SQL Area)
1.22.2.2.17 Exclusive Lockwaits (Oracle)
1.22.2.2.18 Database Message Log (Oracle)
1.22.2.2.19 Display V$ Tables (Oracle)
1.22.2.2.20 Historical Database Performance Statistics (Oracle)
1.22.2.2.21 State on Disk (Oracle)
1.22.2.2.22 Parameter Changes (Oracle)
1.22.2.3 Table Scans: Problem Analysis (Oracle)
1.22.2.4 Checking for Full Tablespaces (Oracle)
1.22.2.5 Storage Management Errors (Oracle)
1.22.2.6 Checking for Freespace Problems (Oracle)
1.22.2.7 Checking Storage Parameters (Oracle)
1.22.2.8 Problems with Maximum Number of Extents (Oracle)
1.22.2.9 Displaying the Oracle Table Statistics
1.22.2.10 SAP/Oracle Database Monitor: Status of the Data
1.22.2.11 Consistency Checks
1.22.2.11.1 Database - ABAP Dictionary Consistency
1.22.2.11.2 Database Tables without a Unique Index
1.22.2.11.3 Creating Objects in the Database
1.22.2.11.4 Displaying Object Definitions
1.22.2.11.5 Naming Conventions for Indexes
1.22.2.12 Extent Analysis (Oracle)
1.22.2.13 Tablespace Analysis (Oracle)
1.22.2.14 Tables/Index Analysis (Oracle)
1.22.2.15 Missing Indexes
1.22.2.16 SAP/Oracle Performance Monitoring Strategies
1.22.2.16.1 Monitoring the Data Buffer (Oracle)
1.22.2.16.2 Monitoring the Shared Pool (Oracle)
1.22.2.16.3 Monitoring the Redo Log Buffer (Oracle)
1.22.2.16.4 Monitoring Calls (Oracle)
1.22.2.16.5 Monitoring Table Access Methods (Oracle)
1.22.2.16.6 Monitoring Sorting (Oracle)
1.22.2.17 Diagnosing SAP/Oracle Performance Problems
1.22.2.17.1 A Transaction is Running Very Slowly (Oracle)
1.22.2.17.2 Monitoring the Shared SQL Area (Oracle)
1.22.2.17.3 Monitoring Table and Index Fragmentation (Oracle)
1.22.2.17.4 All Transactions are Running Slowly (Oracle)
1.22.2.17.5 Checkpoint Monitoring (Oracle)
1.22.2.17.6 Checking the Optimizer Mode (Oracle)
1.22.2.17.7 Monitoring Oracle Resources
1.22.2.17.8 No Applications Can Run (Frozen System)
1.22.2.18 Important init.ora Parameters (Oracle)
1.22.2.18.1 DB_BLOCK_BUFFERS (Oracle)
1.22.2.18.2 DB_BLOCK_SIZE (Oracle)
1.22.2.18.3 DB_WRITERS (Oracle)
1.22.2.18.4 LOG_ARCHIVE_START (Oracle)
1.22.2.18.5 LOG_BUFFER (Oracle)
1.22.2.18.6 LOG_CHECKPOINT_INTERVAL (Oracle)
1.22.2.18.7 ROW_CACHE_CURSORS (Oracle)
PUBLIC
Page 3 of 101

1.22.2.18.8 SHARED_POOL_SIZE (Oracle)
1.22.2.18.9 SORT_AREA_SIZE (Oracle)
1.22.2.18.10 TIMED_STATISTICS (Oracle)
1.22.2.19 Data for the Oracle Database Monitor
1.22.2.19.1 Database Collector in Background Processing
1.22.2.19.2 Data for the Main Screen of the Database Monitor
1.22.2.19.3 Data for the Screen: Database Performance: Tables and Indexes
1.22.2.19.4 Data for the Database Alert Monitor
1.22.3 Performance: Overview
1.22.3.1 Memory
1.22.3.2 Disk Space Usage
1.22.3.3 Dynamic Values in Current Activity Sub Screen
1.22.3.4 Detail Analysis Menu
1.22.4 SAP on IBM DB2 for Linux, UNIX, and Windows: Database Monitor
1.22.5 Table Analysis
1.24 Computing Center Management System (CCMS)
1.25 Archive and Backup Monitor in CCMS (Informix)
1.26 DBA Planning Calendar (Informix)
1.27 Troubleshooting in the DBA Planning Calendar (Informix)
1.28 Getting Started in CCMS with Informix DBA
1.29 Using the Archive and Backup Monitor in CCMS (Informix)
1.31 Parameters for RSSTAT80/83 and RSSTAT87/88/89
1.32 The CCMS System Component Repository
1.32.1 Displaying Information from the Repository
1.32.2 Filling and Updating the Repository
1.32.3 Checking the Repository for Processing Errors
PUBLIC
Page 4 of 101

1 Monitoring in the CCMS
The CCMS provides a range of monitors for monitoring the SAP environments and its components. These monitors are indispensable for understanding and
evaluating the behavior of the SAP processing environment. In the case of poor performance values, the monitors provide you with the information required to fine
tune your SAP system and therefore to ensure that your SAP installation is running efficiently.
Implementation Considerations
For central monitoring, that is, for the monitoring of a system landscape from one system, you must perform various configuration steps yourself. These are outlined
in Configuring the Monitoring Architecture.
Features
The CCMS analysis monitors provide functions for:
Checking the system status and the operating modes
Detecting and correcting potential problems as quickly as possible
An early diagnosis of potential problems, such as resource problems in a host or database system, which could affect the SAP system
The analysis and fine tuning of the SAP system and its environment (host and database system) to optimize the throughput of the SAP system
You can either use the following applications independently or execute them as analysis methods in the alert monitor:
Global Work Process Overview
Workload Monitor
Global Workload Monitor
Operating System Monitor
Operating System Collector
SAP Buffer
Database Monitor
1.1 CCMS: Informix
Purpose
This component enables you to manage your Informix database using the Computing Center Management System (CCMS). With CCMS, you get extensive
support in database administration (DBA) for the Informix database and can perform many DBA functions from within the SAP system.
SAP recommends you to use CCMS for Informix DBA where possible. CCMS is supported for Informix databases on both UNIX and Windows platforms.
For each area of administration, the table below in "Integration" shows the available tools. In general, you should use CCMS or SAPDBA as first choice, followed
by the other Informix tools. The reasons for this are as follows:
● CCMS uses the familiar SAP interface, can be used directly from your SAP session and is perfectly adequate for many routine functions.
● SAPDBA is tailored for use with the SAP system running on Informix databases and can also be used when the SAP system is down. With SAPDBA, you
can perform a wide range of DBA functions (but not archive and backup).
● The Informix tools have the disadvantage that they are not designed specifically to run with the R/3 System, and furthermore some of these tools have a less
advanced interface than SAPDBA or CCMS.
There are some overlaps in functionality between CCMS and SAPDBA. In general, however, they complement one another, as their strengths lie in different
areas. For example, CCMS is more suited for shared memory parameters, whereas SAPDBA is better for monitoring and tuning in the area of space
management.
These are only guidelines as to the best tool for the task. The exact nature of the task determines which tool you should use.
Integration
There are many different tasks involved in Informix database administration, only some of which you can carry out using CCMS, as shown in the following table:
Area of administration Can Be Performed Using
Installation SAPinst
Archive and backup CCMS, ontape, ON-Archive, ON-Bar
Reorganization SAPDBA
Update statistics CCMS, SAPDBA, Informix tools
Performance tuning CCMS, SAPDBA, Informix tools
Monitoring CCMS, SAPDBA, Informix tools
Space management SAPDBA, Informix tools
PUBLIC
Page 5 of 101

System checks SAPDBA, Informix tools, CCMS
Other SAPDBA, Informix tools
Features
The main features for Informix DBA in CCMS are as follows:
Area of Administration Can Be Performed in CCMS Using
Scheduling archive, backup, update statistics, DB system checks, physical consistency
checks, and other tasks
DBA Planning Calendar
Reviewing results of archive and backup Archive and Backup Monitor in CCMS
Update Statistics Update Statistics
Performance tuning and monitoring Database Monitor and Database Alert Monitor
System checks (that is, configuration and performance) DB System Check
There is some overlap between these tools.
Constraints
You have to perform certain DBA functions outside the SAP system, that is, using tools supplied by Informix and SAP. For example, to perform a reorganization,
you have to use SAPDBA.
See also:
SAP Database Guide: Informix
Choosing an Action Pattern in the DBA Planning Calendar
Use
The DBA Planning Calendar provides easy-to-use predefined action patterns specific to each database platform. You specify a reference time, on the basis of
which all schedules are defined. It is possible later to delete an action pattern. For more information about how to change actions in a pattern, see Scheduling
Actions in the DBA Planning Calendar. However, SAP recommends you to use a predefined action pattern.
If you started the DBA Planning Calendar using Local Calendar from the Central DBA Planning Calendar, you can choose action patterns for all
remote systems running on the same platform and with the same characteristics. This assumes that you have already defined the remote
systems to the Central DBA Planning Calendar.
For example, assume that you call the DBA Planning Calendar from the Central DBA Planning Calendar on system FUD, which runs Oracle
version 8. You can then choose action patterns for all other Oracle systems running Oracle version 8. If the actions in the action pattern that you
want to schedule also run on Oracle version 7, then you can also schedule that action pattern for all systems running Oracle version 7.
This only applies if you started the local calendar from the Central DBA Planning Calendar.
Prerequisites
● You are ready to use CCMS. Refer to Getting Started in CCMS with Informix DBA.
● If you have started the DBA Planning Calendar using Local Calendar from the Central DBA Planning Calendar, you can choose action patterns for all
systems on the same platform and with the same characteristics.
For example, assume that you call the DBA Planning Calendar on system FUD, which is an Oracle system running Oracle version 8. You can then set up
an action pattern for all other Oracle systems running Oracle version 8.
This only applies if you started the calendar from the Central DBA Planning Calendar.
Procedure
1. Choose CCMS → DB Administration → DBA Planning Calendar → Calendar → Action Pattern .
2. Select a predefined action pattern.
3. Enter the time at which the key action is to be carried out.
The system suggests an appropriate time, which you can accept if you want. The system uses this time to work out the schedule for the activities in the
action pattern.
If there are conflicts between the action pattern you have chosen and activities that are already scheduled in the Planning Calendar, then the system
presents a list of the conflicts.
4. If there are conflicts, do the following:
a. Print the list with the key combination. Then choose Cancel . No activities from the new action pattern are scheduled.
b. Review and eliminate the conflicts before trying to schedule the action pattern again.
5. To delete a predefined action pattern, you have to delete the next scheduled occurrence of the action that was scheduled as part of an action pattern. All future
scheduling of the action is deleted.
6. Make sure that the required resources are available when an action is scheduled to run.
Shift-F1
PUBLIC
Page 6 of 101

Result
The activities in the action pattern are automatically inserted into the planning calendar. The system also schedules background jobs for executing the activities.
All jobs are scheduled for periodic repetition according to the schedule in the action pattern.
See also:
Checking the Results of Actions in the DBA Planning Calendar
Archiving or Backing Up the Database in the DBA Planning
Calendar (Informix)
Use
You can use the DBA Planning Calendar in the Computing Center Management System (CCMS) to schedule database backups (ON-Bar) or archives (ON-
Archive) for the Informix database. For more information about database backup or archive, see:
● Database Backup (ON-Bar)
● Archive (ON-Archive and ontape)
Prerequisites
· You are ready to use CCMS. Refer to Getting Started in CCMS with Informix DBA.
● You know how to use the DBA Planning Calendar.
For more information about scheduling an action (for example, a database backup) in the DBA Planning Calendar, see Scheduling Actions in the DBA
Planning Calendar.
● Your storage devices are ready and have media loaded with enough available space. For example, if using tape, your tape device is ready to receive data
and you have loaded a tape with enough available space.
Procedure
1. Choose CCMS → DB Administration → DBA Planning Calendar .
2. Choose the day when you want the database backup or archive to take place.
3. Choose Create action .
4. Select an Action from the list as follows:
ON-Archive
Select ToPerform
Database full archive A full archive of all dbspaces of the database
Incremental archive level 1 An incremental archive of all dbspaces changed since the last full archive
Incremental archive level 2 An incremental archive of all dbspaces changed since the last incremental archive at
level-1
For more information about archiving with ON-Archive outside CCMS, see Creation of an Archive (ON-Archive).
ON-Bar
Select ToPerform
Database backup (dbspaces) A full backup of all or selected dbspaces of the database
Incremental database backup (dbspaces) An incremental backup of dbspaces changed since the last database backup
Whole system backup (serial) A full backup of all dbspaces and the logical log, executed serially
Incremental whole system backup (serial) An incremental backup of all dbspaces changed since the last database backup and a
logical-log backup, executed serially
For more information about backing up the database with ON-Bar outside CCMS, see Creation of a Database Backup (ON-Bar).
5. Enter data as required in the fields Start Time , Period (weeks) , and Calendar . For more information, see Scheduling Actions in the DBA Planning
Calendar.
6. Choose Continue .
If your chosen action requires more parameters, the system prompts for them.
For example, with ON-Archive, you have to select the Vset name (that is, volume set name) for the archive. SAP recommends that you use volume set
DBTAP for archives. For more information, see Volume Sets and Volumes for ON-Archive.
7. Enter data as required and choose Continue .
If either of the following conditions applies, a full (level-0) database backup or archive is executed, even though you scheduled an incremental
(level-1 or level-2) backup or archive:
· There is no successfully executed level-0 database backup or archive.
· You have altered the dbspace structure since the last level-0 database backup or archive. In other words, you have added or deleted non-temporary dbspaces.
A prompt warns you of this when you start the DBA Planning Calendar.
PUBLIC
Page 7 of 101

If you enter more than one volume set for an archive with ON-Archive, the archive runs in parallel. CCMS automatically determines the allocation
of dbspaces to volume sets. For more information about planning parallel archives, see Parallel Archive Approach (ON-Archive).
Result
The database backup or archive is now scheduled. It will be created at the scheduled date and time. For more information about looking at the results of the
database backup or archive, see Using the Archive and Backup Monitor in CCMS (Informix).
Backing Up the Logical Log in the DBA Planning Calendar
(Informix)
Use
You can use the DBA Planning Calendar in the Computing Center Management System (CCMS) to schedule logical-log backups for the Informix database. You
can follow this procedure if you use the Informix data recovery tools ON-Bar or ON-Archive.
You can create a logical-log backup for the Informix database with the DBA Planning Calendar in the Computing Center Management System (CCMS) by using
the following methods:
● Normal scheduled logical-log backup
With this you can back up the logical log including the currently used log file at the scheduled time. This is the method described in this section.
● Automatic logical-log backup
With ON-Archive you can use this method to trigger logical-log backup. This works by detecting the fill level of the logical log. When a pre-defined level is
reached, the backup job triggered to run. Therefore, you must make sure that the correct tape volume is always mounted. This method offers you an extra
level of security to avoid the logical log filling up.
For more information, see Backing Up the Logical Log (Automatic) in the DBA Planning Calendar (Informix).
SAP recommends that you use both methods for extra security. Always keep a dedicated tape drive free when backing up logs automatically.
If the logical logs are not backed up before they completely fill, you need to perform an emergency backup. This is complex, time-consuming and
leads to unplanned downtime for your system. You can avoid this by devising a sensible backup schedule with the Calendar. Always make sure
that the correct empty tape is loaded in the appropriate tape drive. See Preventing Emergency Logical-Log Backup.
If you need to execute a logical-log backup immediately, see Scheduling Actions in the DBA Planning Calendar.
For more information about logical-log backup, see Logical-Log Backup.
Prerequisites
· You are ready to use CCMS. Refer to Getting Started in CCMS with DBA Tasks for Informix.
● You know how to use the DBA Planning Calendar. For more information, see:
For more information about scheduling an action (for example, a logical-log backup) in the DBA Planning Calendar, see Scheduling Actions in the DBA
Planning Calendar.
Procedure
2. Choose the day when you want the logical-log backup to take place.
4. Select Logical-Log Backup (ON-Bar) or Logfile Backup (ON-Archive).
For more information about creating a logical-log backup outside CCMS, see:
· Creation of a Logical-Log Backup (ON-Bar)
· Creation of a Logical-Log Backup (ON-Archive)
Calendar.
If your chosen action requires more parameters, the system prompts for them.
For example, with ON-Archive, you have to select the Vset name (that is, volume set name) for the logical-log backup. SAP recommends that you use
volume set LOGTAP for logical-log backups. For more information, see Volume Sets and Volumes for ON-Archive.
7. Enter data as required and choose Continue .
Result
The logical-log backup is now scheduled. It will be created at the scheduled date and time. For more information about looking at the results of the logical-log
backup, see Using the Archive and Backup Monitor in CCMS (Informix).
PUBLIC
Page 8 of 101

Backing Up the Logical Log (Automatic) in the DBA Planning
Calendar (Informix)
Use
To avoid the logical-log files of an Informix database filling up, you can activate a triggered automatic logical-log backup in the DBA Planning Calendar, which is
part of the Computing Center Management System (CCMS). You can only follow this procedure if you use the Informix data recovery tool ON-Archive.
You can create a logical-log backup for the Informix database with the DBA Planning Calendar in the Computing Center Management System (CCMS) by using
the following methods:
● Normal scheduled logical-log backup
With this you can back up the logical log including the currently used log file at the scheduled time. For more information, see Backing Up the Logical Log in
the DBA Planning Calendar (Informix).
● Automatic logical-log backup
With ON-Archive you can use this method to trigger logical-log backup. This works by detecting the fill level of the logical log. When a pre-defined level is
reached, the backup job triggered to run. Therefore, you must make sure that the correct tape volume is always mounted. This method offers you an extra
level of security to avoid the logical log filling up.
This is the method described in this section.
SAP recommends that you use both methods for extra security. Always keep a dedicated tape drive free when backing up logs automatically.
If the logical logs are not backed up before they completely fill, you need to perform an emergency backup. This is complex, time-consuming and
leads to unplanned downtime for your system. You can avoid this by devising a sensible backup schedule with the Calendar. Always make sure
that the correct empty tape is loaded in the appropriate tape drive. See Preventing Emergency Logical-Log Backup.
If you need to execute a logical-log backup immediately, see Scheduling Actions in the DBA Planning Calendar.
For more information about logical-log backup, see Logical-Log Backup.
Prerequisites
For more information about scheduling an action (for example, a logical-log backup) in the DBA Planning Calendar, see Scheduling Actions in the DBA
Planning Calendar.
Procedure
2. Choose Calendar → Automatic Logsave .
3. Enter the percentage fill level to trigger a backup and choose Continue .
The percentage fill level is how full the logical-log files must be in order for a backup to be performed. A typical value might be 50%. To turn off the automatic
logsave, enter 0%.
4. Choose the Vset name (that is, the volume set name) to be used for the triggered backup.
For more information, see Volume Sets and Volumes for ON-Archive.
Result
The automatic logical-log backup is now scheduled. A logical-log backup will be created when the logical log reaches the fill level you specified. For more
information about looking at the results of the logical-log backup, see Using the Archive and Backup Monitor in CCMS (Informix).
Updating Statistics in the DBA Planning Calendar (Informix)
Use
You can use the DBA Planning Calendar in the Computing Center Management System (CCMS) to schedule update statistics for the Informix database. You can
update statistics for all tables in the database or only for one table.
You can also schedule a check statistics in the DBA Planning Calendar. Refer to Checking Statistics in the DBA Planning Calendar (Informix).
For more information about update statistics – which you can also perform with SAPDBA (that is, outside CCMS) – see Update Statistics with SAPDBA.
Prerequisites
PUBLIC
Page 9 of 101

For more information about scheduling an action (for example, check statistics) in the DBA Planning Calendar, see Scheduling Actions in the DBA Planning
Calendar.
Procedure
2. Choose the day when you want the statistics to be updated.
4. Select one of the following:
○ Update Optimizer Statistics (all tables)
○ Update Optimizer Statistics (one table)
Calendar.
7. If you are scheduling update statistics for one table, enter the Table name.
8. Enter the parameters to specify the update statistics:
Parameter Meaning
Threshold for Update Statistics The statistics for a table are only updated when the optimizer value for the number
of rows in the table deviates from the current (that is, correct) number of rows in the
table by more than a certain value, that is, the "threshold". You can either use the
default value of 10% or enter a value of your own.
Execution strategy To optimize the run time for update statistics, you can choose an execution strategy that
performs update statistics in parallel. You can determine how many parallel processes
are started for update statistics.
The default for this parameter is the number of CPU VPs configured in your system. The
number of CPU VPs is specified in the ONCONFIG parameter NUMCPUVPS. If you
choose a value less than 2, update statistics is performed sequentially. For more
information, see NUMCPUVPS (Informix).
With update statistics for all tables, processing is performed in parallel at table level. If the
statistics for an individual table need to be updated, processing is performed in parallel at
column level.
Application Monitor Statistics The default for this parameter is “no” (that is, the box is not selected). If you select this to
activate the parameter, additional space statistics are calculated for each table. These can
be displayed by the application monitor.
Since this calculation is very time-consuming, SAP recommends that you only activate
this parameter if you work with the application monitor.
Maximum Runtime The default for this parameter is “no limit”. If you want to make sure that the update
statistics does not last too long, you can specify a maximum runtime in minutes. When
this limit is reached, the update statistics ends after the current table.
Log file Using this parameter, you can enter the directory and file name of the log file for update
statistics. The default is $INFORMIXDIR/sapreorg/updstat_<SID>.log. If the
directory you enter does not exist, the default directory is used. If the default directory
does not exist, the log is written to /tmp/updstat_<SID>.log.
Detailed The system writes additional information for each table to the log. The default is to write
only overview information to the log.
If you perform update statistics with an R/3 release prior to 3.1G, it runs as follows:
■ Default threshold value (10%)
■ No parallel processing
■ Calculation of application monitor data is activated
■ No runtime limit
■ Log file defaults to $INFORMIXDIR/sapreorg/updstat_<SID>.log, or (if the required directory does not exist) to
/tmp/updstat_<SID>.log.
If you want to change this, you must delete the planned actions and re-schedule them with R/3 Release 3.1G or later. However, note that parallel
processing and the specification of the log file are only available for jobs scheduled with R/3 Release 4.0B or later.
Result
The update statistics is now scheduled for execution at the scheduled date and time. For more information about looking at the results of the update statistics, see
Checking the Results of Actions in the DBA Planning Calendar.
Checking Statistics in the DBA Planning Calendar (Informix)
Use
You can use the DBA Planning Calendar in the Computing Center Management System (CCMS) to schedule a check to see whether the statistics on the Informix
PUBLIC
Page 10 of 101

You can use the DBA Planning Calendar in the Computing Center Management System (CCMS) to schedule a check to see whether the statistics on the Informix
database need updating. You can only schedule check statistics for all tables in the database.
The information generated by this function is evaluated for the “Optimizer Statistics” alert. Refer to Monitoring Optimizer Statistics (Informix). For more information,
see SAP Note 64210.
You can also schedule an update statistics in the DBA Planning Calendar. Refer to Updating Statistics in the DBA Planning Calendar (Informix).
For more information about update statistics – which you can also perform with SAPDBA (that is, outside CCMS) – see Update Statistics with SAPDBA.
Prerequisites
For more information about scheduling an action (for example, check statistics) in the DBA Planning Calendar, see Scheduling Actions in the DBA Planning
Calendar.
Procedure
2. Choose the day when you want the statistics to be checked.
4. Select Check: upd. stat. needed (for all tabs) .
Calendar.
Result
The check statistics is now scheduled. It will be executed at the scheduled date and time. For more information about looking at the results of the check statistics,
see Checking the Results of Actions in the DBA Planning Calendar.
Checking the DB System in the DBA Planning Calendar (Informix)
Use
You can use the DBA Planning Calendar in the Computing Center Management System (CCMS) to schedule database system checks against your Informix
database. These check the configuration and performance of the database.
For more information about configuration and performance checks, see DB System Checks in CCMS (Informix).
Prerequisites
For more information about scheduling an action (for example, check DB system) in the DBA Planning Calendar, see Scheduling Actions in the DBA
Planning Calendar.
Checks that you schedule from the DBA Planning Calendar are executed as follows:
● Using the settings current at execution time
For more information about how to modify the settings for database system checks before running them in the DBA Planning Calendar, see Configuring DB
System Checks in CCMS (Informix).
● All checks are executed
That is, you cannot specify that only certain checks are executed for a given run.
Procedure
2. Choose the day when you want the check to be started.
4. Select Database Configuration Check .
Calendar.
Result
The check is now scheduled. It will be executed at the scheduled date and time, using the settings current at execution time. For more information about looking at
the results, see Checking the Results of Actions in the DBA Planning Calendar.
For more specific information about how to see the results of the checks, see Viewing DB System Checks in CCMS: Informix.
PUBLIC
Page 11 of 101

Monitoring the Database with the Alert Monitor (Informix)
Use
Using the alert monitor, you can monitor the following database alerts:
● Space management – reorganization and space monitoring
● DB system check – consistency and profile
● Backup/restore
The alerts described in this section are all triggered automatically from DB System Checks in CCMS (Informix).
Prerequisites
● Changing the default thresholds
Although SAP recommends that you do not normally change the default thresholds, you can set thresholds yourself for most of the database alerts.
● Deactivating an alert
You can deactivate an alert, but only do this for a particular reason and for a short time.
For more information, see Configuring DB System Checks in CCMS (Informix).
Procedure
1. Start the alert monitor.
2. Choose SAP CCMS Monitor Templates .
3. Choose Entire System .
4. Open the Database monitoring tree element (MTE).
For each instance, the alerts are displayed with color coding to indicate severity. The following alerts are possible in the Database MTE:
MTE Meaning For more information, see
SpaceManagement Monitors the space situation in your database Management of Database Growth
Reorganization Checks if reorganization or application data archive
required, due to tables running out of extents or running
out of allocated pages
Reorganization with SAPDBA
Application Data Archiving
Analyzing Tables by Fill Level, Size, and Extents with
SAPDBA
SpaceMonitoring Checks if dbspace fill level OK and if tables can be
extended correctly
Listing Dbspaces with SAPDBA
Analyzing Tables for Critical Next Extent Size with
SAPDBA
See also next step.
DBSystemCheck Checks key aspects of your database system DB System Checks in CCMS (Informix)
DB Consistency Checks if chunk sizes are within limit, if raw devices are
overlapping, and if logging mode OK
Listing Chunks with SAPDBA
Logging Mode with SAPDBA
DB Profile Checks value of settings in the ONCONFIG file Editing the ONCONFIG File for ON-Archive
Backup Checks aspects affecting database backup and archive Database Backup (ON-Bar)
Archive (ON-Archive and ontape)
Restore Checks number of
chunks for a dbspace
Listing Chunks with SAPDBA
To get up-to-date and detailed information about what the alerts mean and how you should react, use the online help.
5. If you have the SpaceMonitoring alert for a dbspace, choose Start analysis tool to extend the dbspace.
Result
By using the database alert monitor continually during productive database operation, you can find out quickly and easily whether your database has problems.
The result is a more highly tuned database and reduced system downtime.
Checking Physical Consistency in the DBA Planning Calendar
(Informix)
Use
You can use the DBA Planning Calendar in the Computing Center Management System (CCMS) to schedule checks on the physical consistency of your Informix
database. SAPDBA is called to perform the checks, which do not change database data and do not require storage space.
PUBLIC
Page 12 of 101

For more information about consistency checks, see Data Consistency with SAPDBA.
Prerequisites
For more information about scheduling an action (for example, check physical consistency) in the DBA Planning Calendar, see Scheduling Actions in the
DBA Planning Calendar.
● In general, schedule consistency checks immediately before a database backup (ON-Bar) or archive (ON-Archive). This means that the backup or archive
contains data checked for consistency.
● If you use the ONCHECK methods (see table below), be aware that table locks might occur. Therefore, it is best to schedule the check when the database is
not in productive use.
Procedure
1. Choose Tools → CCMS → DB Administration → DBA Planning Calendar .
2. Choose the day when you want the physical consistency to be checked.
4. Select Physical Consistency Check .
Calendar.
7. Select the type of check you want and enter data as required:
Type of check Description
Unload to '/dev/null' checks More thorough check method
○ for table Checks a single named table
○ for dbspace Checks a single named dbspace
- for t ables with 'BLOB' fields Checks all tables with "blob" fields
○ for all tables of database Checks all tables of the database, so can take a long time
ONCHECK Less thorough check method – schedule when database not in productive use because
of table locks
○ ONCHECK -cI Checks the indexes of tables with "blob" fields
○ ONCHECK -CD Checks the data of tables with "blob" fields
For more information, see Type and Frequency of Data Consistency Checks with SAPDBA (the same principles apply to checks performed in
the DBA Planning Calendar).
"Blob" data is most likely to have consistency problems. Therefore, it is sensible to schedule checks on blob data more often than on other types
of data.
8. Choose Continue to plan the check.
Result
The check is now scheduled. It will be executed at the scheduled date and time. For more information about looking at the results, see Checking the Results of
Actions in the DBA Planning Calendar and Using the DB Operations Monitor.
If there are problems with the consistency check, you can look at the log written by SAPDBA. Refer to Log for Data Consistency with SAPDBA.
Scheduling Actions in the DBA Planning Calendar
Use
This section tells you how to schedule actions in the DBA Planning Calendar, which is part of the Computing Center Management System (CCMS).
Prerequisites
● If you want to change or delete an action, it must be in the state SCHED (that is, not already executed).
● If you want to insert an action, you must choose today or a later day, and if you choose today, you must choose a time after the current time.
● If an action has already been executed, you can only display it. See Checking the Results of Actions in the DBA Planning Calendar.
If you started theDBA Planning Calendar using Local Calendar from the Central DBA Planning Calendar, you can schedule actions for all remote
systems running on the same platform and with the same characteristics. This assumes that you have already defined the remote systems to the
Central DBA Planning Calendar.
PUBLIC
Page 13 of 101

For example, assume that you call the DBA Planning Calendar from the Central DBA Planning Calendar on system FUD, which runs Oracle
version 8. You can then schedule actions for all other Oracle systems running Oracle version 8. If the action you want to schedule also runs on
Oracle version 7, then you can also schedule that action for all systems running Oracle version 7.
This only applies if you started the local calendar from the Central DBA Planning Calendar.
Procedure
1. Choose CCMS → DB Administration → DBA Planning Calendar to start the DBA Planning Calendar.
2. Choose the day you want, by double clicking on the day’s header bar.
The system displays actions already scheduled on the chosen day.
3. To insert a new action, do the following:
a. Choose Create action .
The system displays the actions supported by the Planning Calendar for your database platform.
b. Select the action you want to schedule.
The system shows the basic parameters currently set for the action.
c. Enter the basic parameters for the action as follows:
Parameter What toEnter Example
Start time · The time when the action is to start, using 24-hour clock
notation.
· Choose Start immediately , if you are entering an action
for today and want to start the action immediately.
17:00
The job is to be executed at 5 o'clock in the afternoon.
Period The interval for the action, in weeks. The action is repeated
at the interval you enter. If you do not enter a value, the
action is run once only.
2
The action is to be repeated on the same day and time
every two weeks.
Calendar Select the calendar for your country or area. US
The calendar for the United States is to be used.
The system warns you if there is a conflict with an existing action. If so, you must choose another time for the action.
Depending on the action you are inserting, the system may prompt for further input parameters.
4. If necessary, enter further input parameters.
5. Choose Continue to insert the action.
6. To change an existing action, do the following:
a. Select the action you want to change.
b. Choose Change action .
The system shows the basic parameters currently set for the action.
c. If required, change the basic parameters for the action. Refer to the table shown in the previous step.
The system warns you if there is a conflict with an existing action. If so, you must choose another time for the action.
d. If required, choose Parameters to change the parameters specific to the action (for example, the tape volume to use for a backup).
e. Choose Continue to save your changes.
7. To delete an existing action, do the following:
a. Select the action you want to delete.
b. Choose Delete action .
The system asks you to confirm the deletion.
c. Confirm the deletion.
The system deletes the action, including the corresponding background job. Deletion of the job also stops automatic periodic repetition of the action, if that
was scheduled.
If an action is one of a sequence, you can only change or delete the next scheduled occurrence of the action. If you do this, the system also
deletes all future occurrences of the action in the same sequence.
For example, you cannot change or delete an action scheduled to run in six weeks’ time, if the next action of the same sequence is scheduled to
run next week. Instead, you have to change or delete the occurrence for next week.
8. If you have inserted a new action or changed an existing one, make sure that any resources required by your change or insertion are available.
Result
The schedule of the DBA Planning Calendar is updated with the results of your insertion, change, or deletion.
See also:
Choosing an Action Pattern in the DBA Planning Calendar
SAP Database Guide: Informix (BC-DB-INF-DBA)
Purpose
This component lets you administer your Informix database with the SAP system. Read this documentation to make sure that you administer your database as
efficiently as possible, which helps your company get the most from its SAP System.
You can find up-to-date information on Informix with the SAP system on SAP Service Marketplace at:
service.sap.com/dbainf
PUBLIC
Page 14 of 101

· For more information about installing the Informix database with the SAP system, see:
○ Installation Guide – <SAP Component> on UNIX: Informix
○ Installation Guide – <SAP Component> on Windows: Informix
You can find these on SAP Service Marketplace at:
service.sap.com/instguides
· For more information if you are new to SAP database administration (DBA) with Informix, see Getting Started with Informix and SAP. This includes checklists
with links to other topics that tell you, for example, how to get started with data recovery and how to get started with SAPDBA, the SAP tool for Informix database
administration.
Integration
SAP simplifies Informix database administration for you by providing various DBA functions in the Computing Center Management System (CCMS) of the SAP
system. You can use this to schedule database archives, database backups, logical-log backups, database system checks, and update statistics. For more
information, see CCMS: Informix.
Features
● Management of Informix Database Growth
This helps you administer disk space in your database as it grows.
● Data Recovery for Informix
This helps you with routine archives and backups of your database, as well as restores in the event of database failure. The Informix tools for data recovery –
that is, ON-Bar, ON-Archive, and ontape – are described.
● SAPDBA for Informix
This helps you use SAPDBA, which automates many DBA tasks and is designed specially for Informix databases with the SAP system. For example, you
can use this to manage your dbspaces.
● Solutions for Top Informix Problems
This helps you fix problems that occur most often with Informix databases for the SAP system.
See also:
Informix documentation at www.informix.com
1.13 ON-Archive for Data Recovery
Use
ON-Archive is one of a number of tools for data recovery (that is, database archive, logical-log backup, and restore) with your Informix database. ON-Archive
is only available on UNIX platforms. ON-Archive provides the following functions:
· Archive database (including archive of selected dbspaces)
· Back up logical-log files
· Restore data from archives and backups (including restore of selected dbspaces)
You can perform unattended and parallel database archives and logical-log backups with ON-Archive. SAP and Informix provide scripts making it easier to use
ON-Archive.
Integration
If you choose ON-Archive as your data recovery tool, you must do all your logical-log backups and database archives with it.
The archives and backups written by ON-Bar, ON-Archive, and ontape are not compatible. You cannot mix tapes from these tools. Do not
use one tool to back up the logical log and the other to archive the database.
Compared to the other tools available, ON-Archive offers a wide range of functions but is complex. For the latest Informix tool, allowing you to use third-party
storage managers, choose ON-Bar. For a data recovery tool that is easier to use but with reduced functionality, choose ontape. For more information about the
differences between the Informix data recovery tools, see Comparison of ON-Bar, ON-Archive, and ontape for Data Recovery.
When using ON-Archive, SAP recommends that you use the following tools:
· SAP scripts
These make it easier to set up and use ON-Archive.
· The DBA Planning Calendar
This is part of the Computing Center Management System (CCMS) in the SAP System and helps you to easily schedule database archives and logical-log
backups.
Prerequisites
PUBLIC
Page 15 of 101

If you are new to ON-Archive, see Getting Started with ON-Archive. Before you start using ON-Archive for data recovery, you must:
· Work out your approach to data recovery with ON-Archive. Refer to Approach to Archive (ON-Archive) and Approach to Logical-Log Backup (ON-Archive).
· Configure ON-Archive according to the requirements of your chosen approach. Refer to Configuration of ON-Archive.
Features
Some of the important features of ON-Archive are:
· Database archive and logical-log backup to either tape or disk
· Parallel operation in both archive and recovery mode
· Unattended mode (that is, operator-free)
· Tracking database archive and logical-log backup events in sysmaster database
· Access control for data recovery operations
See also:
Informix documentation at http://www.informix.com
1.14 Configuration of ON-Archive
Purpose
This section contains essential information for you to make sure that ON-Archive works correctly with your Informix database running with the SAP System. ON-
Archive is relatively complex and it pays to make sure that you have completed all the necessary configuration tasks before you start database archives and
logical-log backups on your production database.
Prerequisites
You must have a UNIX platform, because ON-Archive is not available for NT platforms.
Before you start configuration, make sure you have worked out your approach to database archive and logical-log backup with ON-Archive. Refer to:
· Approach to Archive (ON-Archive)
· Approach to Logical-Log Backup (ON-Archive)
To see how this process fits in with the overall process of using ON-Archive for data recovery, see ON-Archive for Data Recovery. If you are new to ON-
Archive, see Getting Started with ON-Archive.
Process Flow
1. You read the Informix documentation for ON-Archive.
2. If you are using the SAP scripts, you prepare the scripts.
3. You edit the configuration files for ON-Archive. Make sure you also define the required devices in the config.arc file (how you do this depends on whether you
are using the SAP scripts or not).
4. You set up the required volume sets and volumes (how you do this depends on whether you are using the SAP scripts or not).
Result
Now you can use ON-Archive for database archives and logical-log backups with your production database. Refer to:
· Archive (ON-Archive and ontape)
· Logical-Log Backup
See also:
1.15 Configuring ON-Bar
Use
Before you start using ON-Bar for data recovery with your Informix database, you need to make sure that it is correctly set up. You specify configuration
information for ON-Bar in the ONCONFIG file and as environment variables.
PUBLIC
Page 16 of 101

Prerequisites
How you configure ON-Bar partly depends on your approach to data recovery. Therefore, make sure that you have worked out your approach first. Refer to
Approach to Database Backup (ON-Bar) and Approach to Logical-Log Backup (ON-Bar).
Procedure
1. Decide what kind of storage manager you intend to use with ON-Bar.
You can use the Informix Storage Manager (ISM), which comes with your Informix database server, or a third-party storage manager. You must make sure
that the storage manager you choose is compatible with:
· Your storage devices (that is, disk and tape drives, and so on)
· Your version of ON-Bar
For more information about storage managers, including how to configure ISM, see the Informix documentation and SAP Note 74440.
ISM is more tightly integrated in ON-Bar than third-party storage managers. Therefore, if you use ISM, be sure to complete the next few steps.
2. Set the environment variables required by ON-Bar, depending on which storage manager you are using.
If you are using ISM, set the environment variables ISM_COMPRESSION and ISM_ENCRYPTION, which determine how ISM backs up data. For more
information, see the Informix documentation.
3. Set the required variables in the ONCONFIG file, depending on which storage manager you are using. For more information, see the Informix documentation.
Summary of ONCONFIG File Parameters for ON-Bar
Parameter Determines
BAR_MAX_BACKUP Degree of parallelism used by ON-Bar
BAR_ACT_LOG Path to the ON-Bar activity log
BAR_DEBUG_LOG Path to the ON-Bar debug log
BAR_DEBUG Degree of detail held in the ON-Bar debug log
BAR_RETRY How often ON-Bar retries to send data to or receive data from the storage manager
BAR_XFER_BUF_SIZE Size of the buffer used for exchange between ON-Bar and the storage manager
BAR_NB_XPORT_COUNT Number of buffers used for exchange between ON-Bar and the storage manager
BAR_BSALIB_PATH Path of the shared library used as interface between ON-Bar and the storage
manager
LTAPEDEV Whether or not logging is switched on. See caution below.
ALARMPROGRAM Event alarm, for example, used to start a logical-log backup when logs reach a
certain fill level.
LOG_BACKUP_MODE Mode for logical-log backup.
LBU_PRESERVE This is the most important prevention against emergency logical-log backups. If other
measures fail, this parameter always prevents the logical log filling completely. It
specifies how many logical-log files the database server always preserves (that is, avoids
writing logging data to). Set it as follows:
LBU_PRESERVE 1
Do not set LTAPEDEV to blank or /dev/null (UNIX) or nul (NT) if you want to be able to perform a restore of your system up to the time of
failure. If you specify a null value, logical-log backups are not performed and are therefore not available if a restore is necessary.
When you have finished editing the ONCONFIG file, you have to stop and restart both the SAP System and the Informix database server for the changes to
take effect. You can check the contents of the file in SAPDBA. Refer to Listing System Information with SAPDBA.
The entries in your ONCONFIG file relevant to ON-Bar should look similar to the following example for UNIX:
# Backup/Restore Variables for ON-Bar
BAR_ACT_LOG /tmp/bar_act.log # path of ON-Bar activity log
BAR_MAX_BACKUP 0 # Maximum no. of parallel onbar_d processes
BAR_RETRY 1 # Number of times to retry failures
BAR_NB_XPORT_COUNT 10 # No. of transport buffers
BAR_XFER_BUF_SIZE 31 # Size of each transport buffer
RESTARTABLE_RESTORE OFF # Enables restartable restore
# Use either LOG_BACKUP_MODE in IECC or ALARMPROGRAM, not both
LOG_BACKUP_MODE CONT # Use IECC to set value: CONT or MANUAL
ALARMPROGRAM /usr/informix/etc/log_full.sh
BAR_BSALIB_PATH /usr/lib/ibsad001.so # XBSA shared lib path
#Informix Storage Manager Variables
ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs
#Log Archive Tape Device
# Do not set LTAPEDEV to blank or /dev/null
LTAPEDEV /dev/tapedev
LTAPEBLK 16
LTAPESIZE 10240
PUBLIC
Page 17 of 101

If you are using ISM, check especially the parameters towards the end of the file marked Informix Storage Manager Variables in the
above example.
4. If you use a storage manager other than ISM, follow the configuration instructions supplied. Make sure that the location of the XBSA library is specified to ON-
Bar. For more information, see the Informix documentation.
5. Check the contents and location of the main files for ON-Bar.
Main Files for ON-Bar
File Name Comments
Informix message log Contains all messages generated by database server. Allows you to determine if a
problem is on the database server side or the client side (that is, ON-Bar or the
storage manager).
Use Listing System Information with SAPDBA to view the message log. The name
of the file is specified by the MSGPATH parameter in the ONCONFIG file.
ONCONFIG file Contains general configuration information for the database server, including
parameters prefixed BAR_, which are specific to ON-Bar (see the example above).
Use Listing System Information with SAPDBA to view the ONCONFIG file. The
name of the file is normally onconfig.<hostname>.sid and it is normally in
the directory $INFORMIXDIR/etc (UNIX) or %INFORMIXDIR%etc (NT).
ON-Bar activity log Contains all messages about activity in ON-Bar. It is very useful for solving
problems.
The name of the file is specified by the BAR_ACT_LOG parameter in the ONCONFIG
file.
ON-Bar debug log Contains detailed debugging information to help you solve a problem together with
the Informix hotline.
The name of the file is specified by the BAR_DEBUG_LOG parameter in the
ONCONFIG file.
ON-Bar emergency boot file Contains backup information similar to that in the ON-Bar catalog files for use in a
restore.
The file is called ixbar.<server number>
Server boot file Contains information required to start the database server.
The file is called
oncfg_<server name>.<server number>
For more information, see the Informix documentation and SAP Note 78884.
6. Test ON-Bar with your chosen storage manager before you go live.
For more information, see the Information documentation and SAP Note 78884. This note contains important information that you must read before going live
with ON-Bar.
Result
You can now start using ON-Bar to create backups of your database and logical log. Refer to:
· Approach to Database Backup (ON-Bar)
· Approach to Logical-Log Backup (ON-Bar)
See also:
SAP Notes 74440 and 78884
1.16 ON-Bar for Data Recovery
Use
ON-Bar is one of a number of Informix database tools for data recovery (that is, whole-system backup, storage-space backup, logical-log backup, and restore).
ON-Bar provides the following functions on both UNIX and Windows platforms:
· Back up database (including selected dbspaces and whole system)
· Back up logical-log files
· Restore data from backups (including restore of selected dbspaces)
Unlike the other Informix data recovery tools (that is, ontape and ON-Archive), ON-Bar does not communicate directly with storage devices, such as tape
drives. Instead, it passes control of storage devices to third-party storage managers using the X/Open Backup Services Application (XBSA) Programmer's
Interface. You can select your own storage manager (for example, ISM, Legato/Networker, HP OmniBack, IBM/ADSM) and so exploit a wide range of intelligent
and high-capacity storage devices (for example, auto loaders, robotic loading systems, or optic disks).
With ON-Bar, you can easily implement fast parallel backups and restores, so improving the availability of your database. Therefore, ON-Bar is well suited for
large databases (larger than about 50 GB).
With ON-Bar, the terminology used by Informix changed. The new term "storage spaces" refers to dbspaces and blobspaces. The process of
making a copy of the data and control information managed by the Informix server, formerly called an archive, is now called a “storage space
PUBLIC
Page 18 of 101

backup” or a "whole system backup". For more information, see Informix Whole-System and Storage-Space Backups or the Informix
documentation.
The term “logical-log file backup” – often shortened to “logical-log backup” or even “log backup” – remains the same.
In summary, backup is the ON-Bar term for all copies of the database taken for recovery purposes.
For more information on ON-Bar, see the white paper The Informix Backup and Restore Product Strategy in SAPNet.
Integration
If you choose ON-Bar as your data recovery tool, you must do all your backups and restores with it.
The backups written by ON-Bar are not compatible with the archives and backups from ontape and ON-Archive. You cannot mix tapes from
these tools.
Compared to the other tools available, ON-Bar is easy to use and has wide functionality (but the functionality depends on the storage manager you are using). For
more information about the differences between the Informix data recovery tools, see Comparison of ON-Bar, ON-Archive, and ontape for Data Recovery.
The following diagram shows how ON-Bar is integrated with the database server and storage manager:
You can think of ON-Bar as processing data to and from the database, whereas the storage manager handles data to and from the backup media.
Prerequisites
To implement ON-Bar in a production system, you must have the following:
· Informix Version 7.23UC3 (delivered as standard starting with SAP Release 3.1H) or a later version (see SAP Note 50157)
· An Informix-certified storage manager for ON-Bar, such as the Informix Storage Manager (ISM), which is delivered with Informix Version 7.3
To find up-to-date information on these requirements, see SAP Note 78884.
Before you start using On-Bar for data recovery with production data, you must:
· Configure ON-Bar according to your requirements. Refer to Configuring ON-Bar.
· Work out your approach to data recovery with ON-Bar. Refer to:
- Approach to Database Backup (ON-Bar)
- Approach to Logical-Log Backup (ON-Bar)
· Perform a whole-system backup using ON-Bar with the SAP System down. Refer to Performing a Manual Database Backup (ON-Bar).
Features
· Parallel backup and restore
· Automatic backup of logical logs
· An open interface for communication with third-party storage managers
· Support for intelligent storage devices using XBSA.
Use onsmsync to delete old backup and restore details created by ON-Bar or to regenerate a corrupt ixbar emergency boot file.
See also:
SAP Note 78884
PUBLIC
Page 19 of 101

1.17 Recovery Report with SAPDBA
Use
You can use SAPDBA for Informix to create a report that provides essential information if you need to recover your database after failure with data loss. Recovery
means restoring database data that you have previously stored in archives and backups. With the recovery report, you can more quickly and easily restore your
database.
Once correctly installed, SAPDBA automatically generates an up-to-date report after every archive and logical-log backup. You can only use this procedure with
ON-Archive, as the recovery reports are not available for ontape or ON-Bar.
The information given here applies if you are using an Informix version later than 6.0.
For more information if you are using Informix version 6.0, see Creation of Recovery Report with SAPDBA (Informix 6.0).
Integration
The recovery report is fully integrated in SAPDBA. You can use this functionality for databases running on UNIX and NT operating system platforms.
Prerequisites
· You know how to use SAPDBA and have set it up correctly. Refer to Getting Started with SAPDBA.
· You are using an Informix version later than 6.0 with ON-Archive.
Activities
1. You prepare for the recovery report (you do this once only).
SAPDBA then creates the recovery report automatically after every archive and logical-log backup.
2. You view the recovery report if you need to perform a restore (that is, in the event of database failure with data loss).
See also:
Informix documentation
1.18 Configuring the Monitoring Architecture
Purpose
The monitoring of a system landscape is a complex task of significant importance for every company that operates one or more SAP systems. The complexity
increases with every additional system, component, or extension.
With the monitoring architecture of the Computing Center Management System (CCMS), SAP provides a flexible and universally-usable infrastructure with
which you can centrally monitor your entire IT landscape and which reports problems quickly and reliably.
The monitoring architecture is delivered free of cost with every SAP Web Application Server. The architecture runs on every SAP Web Application Server and
can easily be extended to include additional SAP and non-SAP components.
The concept of the monitoring architecture is that all required information is available in a central monitoring system (CEN), and therefore makes the work of the
administrators easier. Problems are displayed as soon as they occur; all log files are also accessible from a central location, which reduces the time for error
identification and correction. In this way, the monitoring architecture enables greater efficiency with lower costs.
Additional configuration steps allow advanced technologies such as notifications, meaning that administrators no longer need to actively investigate systems for
alerts.
This guide outlines the configuration steps required to monitor a system landscape based on SAP NetWeaver 04. It is a prerequisite for this that you have already
completed the installation of the corresponding components.
To configure the monitoring, perform the following processes in the specified sequence:
· Configuring a Central Monitoring System (CEN)
· Monitoring: Configuring ABAP Instances
· Monitoring: Configuring Java Instances
· Monitoring: Configuring Other SAP NetWeaver Components
· Configuring Alert Triggering and Alert Reactions
PUBLIC
Page 20 of 101

Purpose
The monitoring architecture, a solution within SAP NetWeaver, centrally monitors any IT environments – from individual systems through networked SAP
NetWeaver solutions, to complex IT landscapes incorporating several hundred systems. It is provided in SAP NetWeaver and can be used immediately after
installation. You can easily extend the architecture to include SAP and non-SAP components.
Alerts form a central element of monitoring. They quickly and reliably report errors – such as values exceeding or falling below a particular threshold value or that
an IT component has been inactive for a defined period of time. These alerts are displayed in the Alert Monitor; this reduces the workload for the system
administration, since they now only need to watch the error messages, instead of endless system data.
The Alert Monitor is therefore the central tool with which you can efficiently administer and monitor distributed SAP NetWeaver solutions or client/server systems.
The Alert Monitor displays problems quickly and reliably.
If you want to use the Alert Monitor for central monitoring (that is, you want to monitor the systems of your IT landscape from a central monitoring system), you must
perform various configuration steps yourself. These are described under Configuring the Monitoring Architecture.
Features
The Alert Monitor provides the following functions:
· You can use the Alert Monitor to perform complete and detailed monitoring of all SAP and non-SAP systems, the host systems, and the database.
· All errors generate alerts, which are displayed in a tree structure.
· The alerts contain a status indicator with a color and a numerical value. Yellow means a warning, red means a problem, and the numerical value shows the
severity of the reported error. In the tree structure, the most severe alerts are passed upward in the display hierarchy. If a tree node is not displaying an alert,
there is also no error in the entire branch below it.
· You can assign certain analysis and auto-reaction methods to the alerts, which contribute to faster processing of the error. If you double-click an alert, the
monitoring architecture starts the assigned analysis method (such as the job administration transaction for a prematurely terminated job). An auto-reaction
method, on the other hand, starts automatically as soon as the alert occurs. This includes executing operating system commands and sending an e-mail or an
SMS message to the system administration.
· The Alert Monitor contains various view in which either the current or the open (that is, the unanalyzed) problem messages are displayed. Alerts are also
archived.
· Threshold values, methods, and detailed help for many monitoring attributes and three extensive monitor sets with monitors for all aspects of system
management are predefined on the basis of Best Practices in the monitoring architecture and are available in every SAP system.
· You can adjust all settings individually, and configure your own monitors.
See also:
Concept of the Monitoring Architecture
Operating the Alert Monitor
Customizing the Alert Monitor
1.20 CCMS Agents
Purpose
The Monitoring Architecture provides an infrastructure for monitoring your IT environment and its components. Monitoring data is stored in the shared memory of
every server with a running SAP instance or a running agent.
Read and write access from the central monitoring system is possible in two different ways:
· Using a defined ABAP interface, in the case of an SAP instance
· Using the CCMS agent, in the case of any server on which the agent is installed and active
CCMS agents are independent processes with an interface through RFC to a central monitoring system and an interface to the shared memory. They therefore
allow you to:
· Include SAP components that do not have an ABAP interface, such as the J2EE Engine or the Internet Transaction Server (ITS)
· Include components that are not part of the SAP environment
· Make available an alternative connection route to a shared memory segment
· Optimize performance when reading and writing monitoring attributes and alerts, by using the push technology
· Connect to a shared memory segment without requiring a free work process
Agents also make entirely new monitoring functions possible within the monitoring architecture:
· You can monitor any log files.
· You can monitor processes at operating system level. The actual monitoring is performed using the operating system collector SAPOSCOL. For detailed
information about it, see Operating System Collector SAPOSCOL.
· You can create central auto-reactions in which an auto-reaction method is started in the central monitoring system as a reaction to an alert in a monitored
system. For detailed information about this, see Setting up Central Auto-Reaction Methods.
Agents monitor network data, including:
¡ The configuration of the network environment, such as an interface or Domain Name System (DNS)
¡ Network metrics, such as the length of time taken for a DNS address resolution
PUBLIC
Page 21 of 101

You require CCMS agents for central monitoring, since the monitoring data is primarily transferred between the monitored components and the central monitoring
system using the CCMS agents. For information about configuring central monitoring, see Configuring the Monitoring Architecture.
Purpose
An SAP instance runs within an operating system. The operating system provides the instance with the following resources:
Virtual memory
Physical memory
CPU
File system management
Physical disk
Network
Bottlenecks in these areas can significantly affect the performance of the SAP system. You can monitor these resources using the CCMS operating system
monitor.
The operating system monitor helps you locate the cause of a performance problem. If the source of the problem is in the operating system, you can analyze it
further and resolve it using external tools or other external means.
Performance indicators are:
Average load of and utilization of the CPU
Memory utilization
Paging in and out of data to and from the memory (replaced by pool data in the OS/400 operating system monitor)
Disk utilization information
LAN activity
Operating system configuration parameters
See Also:
Calling the Operating System Monitor
Operating System Monitor Data: CPU
Operating System Monitor Data: Memory Management
Operating System Monitor Data: File System and LAN
1.22 Database Monitor
Purpose
The database monitor checks important performance indicators in the database system, such as the database size, quality of the database buffer, and the
database indexes.
The database monitor works with any database system supported by SAP. The monitor uses statistics that are provided by the database system with which you
are working. You can access most of these statistics for the database system using the performance monitoring of the Computing Center Management Systems
(CCMS).
You can use the Database Monitor to:
● Check the database during the operation of a production SAP system
● Analyze various problems
● Fetch information required for the database system settings
Integration
Although the database monitor accesses and evaluates database-specific statistics tables, it usually has the same appearance, regardless of which database
system you are using.
You can call the database monitor from any application server of the SAP system. The same data is displayed by the database monitor is the same on all
application servers.
Features
SAP/Oracle Database Monitor (New)
SAP/Oracle Database Monitor (Old)
SAP/SQL Server Database Monitor
SAP/MaxDB Database Monitor
PUBLIC
Page 22 of 101

1.22.1 SAP/Oracle Database Monitor (New)
Use
You can use the SAP/Oracle database monitor to monitor your database running with Oracle 9i or Oracle 9i Real Application Cluster (RAC) or later. It is an expert
tool.
The documentation in this section refers to the new SAP/Oracle Database Monitor based on transaction ST04N.
For more information on the old SAP/Oracle Database Monitor, based on ST04, see SAP/Oracle Database Monitor (Old).
Integration
The monitor obtains information from the Oracle performance views (V$, GV$, and DBA-views).
Prerequisites
To generate history information for the monitor, you must have planned the jobs RSORAHIST or RSORAHCL using transaction SM36.
To display full historical information, you must not have restarted the database during the relevant period.
You need to apply SAP Note 706927 before using the database monitor.
Features
The monitor:
· Gives a general overview of database performance
· Provides different ways of looking at the monitoring information:
¡ A main monitor with an overview of the database, from which you can drill down to see more information
¡ Detailed analyses using submonitors, grouped as follows:
§ Overall activity
§ Resource consumption
§ Exceptional conditions
§ Additional Functions
· Fully supports Oracle Real Application Cluster (RAC)
· Does not support Multiple Components in One Database (MCOD)
Activities
1. To start the monitor you choose Administration → CCMS → Control/Monitoring → Performance Menu → Database → Activity .
Alternatively, you can use transaction st04n.
2. The monitor displays the overview on start-up or when you choose Detailed Analyses → Main Monitor .
The following steps are generally valid for all screens, including screens in the submonitors.
3. If your SAP system uses Oracle RAC, in DB Instances you double-click the required RAC instance or Total for all RAC instances.
4. To see monitoring information for a specific history period, in Selected History you double-click Since and Up to and set them as required.
For more information, see Viewing History Information.
5. To refresh the display, choose Refresh .
1.22.1.1 Main Monitor
Definition
This is the main screen in the SAP/Oracle Database Monitor. It gives you an overview of the Oracle database.
Use
You choose Detailed Analyses → Main monitor to get an overall picture of how the database is functioning.
You can right-click a field and choose:
· Help for more information on the meaning of the field
· Details to see the values for each instance if you are running an Oracle Real Application Cluster (RAC)
If you are running RAC, you choose in DB Instances whether to display overview information for one RAC instance or for the total of all RAC instances.
The appearance of a yellow or red light indicates that the difference in percent for the value of at least one instance from the average of all
PUBLIC
Page 23 of 101

instances exceeds a certain limit. The limit values are maintained in table ST04N_LIM.
Structure
The fields are grouped as follows:
· General information , data source is V$INSTANCE
Field Description
DB instance Name of the current database instance
This is the SAP-SID in non-RAC environments.
DB node Host name of the selected DB node
This is the database server in non-RAC environments.
DB release Release of the current database
Day, time Current day and time
Start up at Date and time when the current database instance started
Sec. since start Seconds since start of the current database instance
· Data buffer
Field Description
Size Size of the data buffer in KB
· Non-RAC or RAC detail: data buffer size of the current instance
· RAC total: total instance-related database buffers
Data source: V$SGA
Quality Data buffer quality, calculated as follows:
100% – ((physicalreads – physicalreads_direct –
physicalreads_directlob) / (sess_logicalreads – physicalreads_direct
– physicalreads_directlob))
Non-RAC or RAC detail: data buffer quality of the current instance
RAC total: average of quality for all instance-related data buffer
Data source: V$SYSSTAT
Logical reads Number of logical read operations
· Non-RAC or RAC detail: logical reads of the current instance
· RAC total: total logical read operations for all instances
Physical reads Number of physical read operations
· Non-RAC or RAC detail: physical reads of the current instance
· RAC total: total physical read for all instances
Physical writes Number of physical write operations
· Non-RAC or RAC detail: physical writes of the current instance
· RAC total: total physical write operations for all instances
Buffer busy waits Number of buffer busy wait situations
· Non-RAC or RAC detail: total waitstat counters of the current instance
· RAC total: total waitstat counters for all instances
Data source: V$WAITSTAT
Buffer wait times (s) Sum of buffer busy wait times
· Non-RAC or RAC detail: sum of wait times for all wait counters of the current
instance
· RAC total: sum of wait times for all wait counters for all instances
Data source: V$WAITSTAT
· Shared pool
Field Description
Size (kB) Shared pool size in KB
· Non-RAC or RAC detail: shared pool size of the current instance
· RAC total: total shared pool size for all instances
Data source: V$SGA_DYNAMIC_COMPONENTS
DD-cache quality (%) Data dictionary cache quality as percentage, calculated as follows:
100% – (totalget_misses / totalgets)
· Non-RAC or RAC detail: data buffer quality of the current instance
· RAC total: average cache quality for all instances
Data source: V$ROWCACHE
SQL area getratio (%) Ratio of gethits to gets as a percentage, calculated as follows:
sum (gethits) / sum (gets) x 100
· Non-RAC or RAC detail: get ratio of the current instance
· RAC total: average of all instance-related get ratios
Data source: V$LIBRARYCACHE
PUBLIC
Page 24 of 101

SQL area pinratio (%) Ratio of pinhits to pins as a percentage, calculated as follows:
sum (pinhits) / sum (pins) x 100
· Non-RAC or RAC detail: pin ratio of the current instance
· RAC total: average of all instance-related pin ratios
SQLA Reloads/pins (%) Ratio of reloads to pins as a percentage, calculated as follows:
sum (reloads) / sum (pins) x 100
· Non-RAC or RAC detail: reloads per pin ratio of the current instance
· RAC total: average of all instance-related pin ratios
· Log buffer
Field Description
Size (kB) Size of the redo log buffer in KB
· Non-RAC or RAC detail: redo log buffer size of the current instance
· RAC total: total instance-related redo log buffer sizes
Data source: V$SGA
Entries Number of redo log buffer entries
· Non-RAC or RAC detail: redo log buffer entries of the current instance
· RAC total: sum of all instance-related redo log buffer entries
Allocation retries Number of redo buffer allocation retries
· Non-RAC or RAC detail: allocation retries of the current instance
· RAC total: total instance-related log buffer allocation retries
Alloc fault rate (%) Redo buffer allocation retries as a percentage of redo entries
· Non-RAC or RAC detail: allocation fault rate of the current instance
· RAC total: average of all instance-related allocation fault rates
Redo log wait (s) Redo log wait in seconds
· Non-RAC or RAC detail: Redo log wait time of the current instance
· RAC total: sum of instance-related redo log wait times
Log files (in use) Number of active log files
· Non-RAC or RAC detail: active log files for the current instance
· RAC total: total active log files
The figure in brackets refers to the number of active log files in use.
Data source: V$LOGFILE
· Calls
Field Description
User calls Number of user calls
· Non-RAC or RAC detail: user calls for the current instance
· RAC total: total user calls for all instances
User commits Number of user commits
· Non-RAC or RAC detail: user commits for the current instance
· RAC total: total user commits for all instances
User rollbacks Number of user rollbacks
· Non-RAC or RAC detail: user rollbacks for the current instance
· RAC total: total user rollbacks for all instances
· Time Statistics
Field Description
Busy wait time (s) Busy wait time in seconds, calculated as the sum of the time waited for all non-idle
events.
· Non-RAC or RAC detail: busy wait time for the current instance
· RAC total: total instance-related busy wait times
Data source: V$SESSION_EVENT
CPU time session (s) CPU time session in seconds, calculated as sum of CPU time used by this session
· Non-RAC or RAC detail: total CPU time for the current instance
· RAC total: total CPU time for all instances
Time/User call (ms) Time for each user call in milliseconds, calculated as follows:
(busy wait time + CPU time) / user calls
· Non-RAC or RAC detail: time for the current instance
PUBLIC
Page 25 of 101

· RAC total: average time for all instances
Data source: V$SESSION_EVENT and V$SYSSTAT
Sessions busy (%) Busy sessions as a percentage, calculated as follows:
(busy wait time + CPU time) / total wait time
· Non-RAC or RAC detail: percentage for the current instance
· RAC total: average percentage for all instances
Data source: V$SESSION_EVENT and V$SYSSTAT
CPU usage (%) CPU usage as a percentage, calculated as follows:
CPU time / (elapsed time x CPU count)
· Non-RAC or RAC detail: percentage for the current instance
· RAC total: average percentage for all instances
Data source: V$SYSSTAT, V$INSTANCE, and V$PARAMETER
Number of CPUs Number of CPUs
· Non-RAC or RAC detail: CPUs for the current instance
· RAC total: total CPUs for all instances
Data source: V$PARAMETER
· Redo Logging
Field Description
Redo writes Number of redo log writes
· Non-RAC or RAC detail: redo log writes for the current instance
· RAC total: total redo log writes for all instances
OS blocks written Number of operating system redo blocks written
· Non-RAC or RAC detail: redo blocks written for the current instance
· RAC total: sum of written redo blocks for all instances
Latching time (s) Redo writer latching time in seconds
Non-RAC or RAC detail: redo writer latching time for the current instance
RAC total: total latching time for all instances
Redo write time (s) Redo write time in seconds
· Non-RAC or RAC detail: redo write time for the current instance
· RAC total: total redo write time for all instances
MB written Number of MB written
· Non-RAC or RAC detail: redo log data written for the current instance
· RAC total: total redo log data written for all instances
· Table scans and fetches
Field Description
Short table scans Number of short table scans
· Non-RAC or RAC detail: short table scans for the current instance
· RAC total: total short table scans for all instances
Long table scans Number of long table scans
· Non-RAC or RAC detail: long table scans for the current instance
· RAC total: total long table scans for all instances
Table fetch by rowid Number of table fetches by row ID
· Non-RAC or RAC detail: table fetches by row ID for the current instance
· RAC total: total table fetches by row ID for all instances
Fetch by contin. row Number of fetches by continued row
· Non-RAC or RAC detail: table fetches by continued row for the current
instance
· RAC total: total table fetches by continued row for all instances
· Sorts
Field Description
Sorts (memory) Number of sorts in memory
· Non-RAC or RAC detail: sorts in memory for the current instance
· RAC total: total sorts in memory for all instances
Sorts (disk) Number of sorts in disk
· Non-RAC or RAC detail: sorts on disk for the current instance
PUBLIC
Page 26 of 101

· RAC total: total sorts on disk for all instances
Sorts (rows) Number of sorted rows
· Non-RAC or RAC detail: sorted rows in memory for the current instance
· RAC total: total rows for all instances
WA exec. optim. mode Number of work area executions in optimal mode
· Non-RAC or RAC detail: work area executions in optimal mode for the
current instance
· RAC total: total work area executions in optimal mode for all instances
WA exec. one pass m. Number of work area executions in one-pass mode
· Non-RAC or RAC detail: work area executions in one-pass mode for the
current instance
· RAC total: total work area executions in one-pass mode for all instances
WA exec. multipass m. Number of work area executions below the one-pass memory requirement
· Non-RAC or RAC detail: work area executions in multipass mode for the
current instance
· RAC total: total work area executions in multipass mode for all instances
· Instance Efficiency
Field Description
Soft parse ratio Soft parse ratio is calculated as follows:
1 – (parse count hard / parse count total)
This shows whether there are many hard parses on the system. The ratio should be
compared to the raw statistics to ensure accuracy. For example a soft parse ratio of 0.2
typically indicates a high hard parse rate. However, if the total number of parses is low,
you can disregard the ratio.
· Non-RAC or RAC detail: ratio of the current instance
· RAC total: average ratio for all instances
In-memory sort ratio In-memory sort ratio is calculated as follows:
sorts in memory / (sorts in memory + sorts on disk)
This shows the proportion of sorts that are performed in memory. Optimally, in an
operational online transaction processing (OLTP) system, most sorts are small and can
be performed solely as in-memory sorts.
· RAC total: average ratio for all instances
Source: V$SYSSTAT
Parse to exec. ratio Parse to execute ratio is calculated as follows:
1 – (parse count total / execute count)
In an operational environment, optimally a SQL statement should be parsed once and
executed many times. Therefore an ideal value is close to 1.
· RAC total: average ratio of all instances
Source: V$SYSSTAT
Parse CPU to total Parse-CPU-to-total ratio is calculated as follows:
1 – (parse time CPU / CPU used by this session)
This shows how much of the total CPU time used was spent on activities other than
parsing. When this ratio is low, the system is performing too many parses.
Source: V$SYSSTAT
PTime CPU / PT elps Parse time CPU / parse time elapsed ratio is calculated as follows:
parse time CPU / parse time elapsed
This can often indicate latch contention. The ratio indicates whether the time spent
parsing is allocated to CPU cycles (that is, productive work) or whether the time spent
parsing was not spent on CPU cycles. Time spent parsing not on CPU cycles usually
indicates that the time was spent sleeping due to latch contention.
Source: V$SYSSTAT
1.22.1.2 Viewing History Information
Use
You can view history information – or “snapshot” data – when using many of the submonitors in the SAP/Oracle Database Monitor. You can specify a “since” and
PUBLIC
Page 27 of 101

an “up to” date and time.
Prerequisites
You are using a submonitor that offers history information.
Not all submonitors offer history information.
Procedure
Specify Since and Up to in the screen area Selected History to get the required result in the submonitor display as follows:
Since Up To Result in Submonitor Display
DB start Now Displays the changes from database start to the current
time
Your selected snapshot Now Displays the changes from your selected snapshot to the
current time.
DB start Your selected snapshot Displays the changes from database start to your selected
snapshot.
Your selected snapshot Your selected snapshot Displays the changes between your selected snapshots.
1.22.1.3 Overall Activity
These submonitors in the SAP/Oracle Database Monitor show overall activity in the database.
1.22.1.3.1 Buffer Busy Waits
Definition
This submonitor in the SAP/Oracle Database Monitor lets you check buffer busy waits in the Oracle database.
A buffer busy wait indicates that there are some buffers in the buffer cache that multiple processes are attempting to access concurrently. This event happens
because one of the following is true:
· An Oracle block is being read into the buffer cache by another session and the session is waiting for that read to complete.
· The buffer is already in the buffer cache but in an incompatible mode (that is, some other session is changing the buffer)
Use
You choose Detailed Analyses → Overall activity → Buffer Busy Waits .
You can view history information in this monitor.
Structure
Entries marked “RAC only” appear only for Oracle Real Application Cluster (RAC).
Buffer Busy Waits
This tab page contains information on buffer busy waits:
Column Description
Inst Id
RAC only
Database instance ID
Class Class of block
Ttl waits Total number of waits due to this class of block
Tm Wait (ms) Total of all wait times for all waits due to this class of blocks in milliseconds.
Avg Tm wait (ms) Average duration of wait due to this class of block in milliseconds
%BBW/Inst Percentage of waits due to this class of block for each instance
% of Time of BBW/Inst Percentage of time spent waiting due to this class of block for each instance
%BBW Percentage of waits due to this class of block for all instances
% of Time of BBW Percentage of time spent waiting due to this class of block for all instances
PUBLIC
Page 28 of 101

In single-instance – that is, non-RAC – environments, the following is true:
· %BBW/Inst shows the same value as %BBW
· % of Time of BBW/Inst shows the same value as % of Time of BBW
· RAC only: Buffer Busy Waits with Total Lines
This tab page shows the same information as in the table above plus Total lines for each Class of buffer busy wait. This helps you identify a buffer cache
contention problem that is not caused by a specific instance.
1.22.1.3.2 Filesystem Requests
Definition
This submonitor in the SAP/Oracle Database Monitor lets you check filesystem requests in the Oracle database. It monitors the activity of filesystem requests
with the Oracle GV$FILESTAT view
Use
You choose Detailed Analyses → Overall activity → Filesystem requests .
This monitor helps you to minimize the time needed to read or write data from or to a file, so that you can identify the frequently used data files and put them on
separate disks to avoid contention, if necessary. Data file activity has an important effect on database performance.
You cannot view history information in this monitor. Instead, you can choose the following history functions:
Reset + Since Reset
Since Reset
Since DB Start
You can view the information in graphical form by choosing Graphics (Top 30) to show the 30 tablespaces with the most activity, sorted in descending order for
the chosen parameter ( Reads , Block Reads , Blocks per Read and so on).
Structure
Entries marked “RAC only” appear only for Oracle Real Application Cluster (RAC).
IO per File
This tab page displays current statistics on physical file accesses per data file:
Column Description
File# File number
Inst id
RAC only
Instance ID
Full path Full file name including path
Reads Number of reads
Blk Reads Number of block reads
Blk/Rd Number of blocks per read
Rd Avg(ms) Read average time in milliseconds
Rds/File(%) Percentage of reads per file
Sgl Blk Rds Number of single block reads
Sgl Blk Rds Avg(ms) Average time for single block reads in milliseconds
Writes Number of writes
Blk wrts Number of block writes
Wrt Avg(ms) Average time for writes in milliseconds
BBW Number of buffer busy waits
Avg BBW(ms) Average buffer busy wait time in milliseconds
BBW/File(%) Percentage of buffer busy waits per file
· I/O per File With Total Lines – RAC only
This tab page displays the same information as in the table above plus Total lines for each Full path . This helps you identify a filesystem request problem
that is not caused by a specific instance.
· Total per Device
This tab page displays current statistics on total physical file accesses per disk device. There are also entries for each file on the device.
Column Description
PUBLIC
Page 29 of 101

File# File number
Inst id
RAC only
Instance ID
Name / Device Full file name including path
Blk Rds Number of block reads
% of Ttl Blk Rds Percentage of total block reads
Sgl Blk Rds Avg(ms) Average for single block reads in milliseconds
· I/O per Path
This tab page displays current statistics about total physical file accesses per path.
Column Description
Path File number
Blk Rds Number of block reads
% of Ttl Blk Rds Percentage of total block reads
Sgl Blk Rds Avg(ms) Average for single block reads in milliseconds
1.22.1.3.3 System / Wait Events
Definition
This submonitor in the SAP/Oracle Database Monitor lets you check the following wait events and system events in the Oracle database:
· Busy waits summary
· Wait event details
· Oracle view GV$SYSTEM_EVENT
Use
You choose Detailed Analyses → Overall activity → System / Wait Events and the required tab page Busy Waits Summary , Wait event details , or
GV$SYSTEM_EVENT .
You can view history information in this monitor.
Structure
PUBLIC
Page 30 of 101

Entries marked “RAC only” appear only for Oracle Real Application Cluster (RAC)
· Busy Waits Summary
This tab page displays a summary of busy waits:
Column Description
Inst Id
RAC only
Session type Type of session.
For example, BACKGROUND for system sessions, USER for application sessions.
User Name Name of the user connected to the database. For example, SAP applications connect as
user SAPR3.
PName Process name
Sessions Number of sessions connected to the database
Busy wait time (ms) Wait time spent busy in milliseconds
Total wait time (ms) Total time waiting for an event in milliseconds
Busy W (%) Busy wait time as percentage of Total wait time
· Wait event details
This tab page displays details of wait events:
Column Description
Inst ID
RAC only
Event Name of the event that caused the wait
Wait time (ms) Time waiting for the event in milliseconds
% of non-idle Percentage of non-idle waiting time caused by this event
% of tot. resp. Percentage of total response time caused by this event
Waits Number of waits
Timeouts Number of timeouts
Avg. WT (ms) Average wait time in milliseconds
· GV$SYSTEM_EVENT
This tab page displays details from the Oracle view GV$SYSTEM_EVENT:
Column Description
Event Name of the event that caused the wait
Inst ID
RAC only
Wait time (ms) Time waiting for the event in milliseconds
Wait% Inst/Evt. Percentage of time spent waiting for an event
Waits Number of waits
Timeouts Number of timeouts
Avg. WT (ms) Average wait time in milliseconds
This tab page shows events and wait times per instance in descending order of the event’s total wait time.
In a RAC environment, you see by default the wait times for each instance and the total wait times for all instances. If required, you can restrict the
display to a single instance.
1.22.1.3.4 Undo Statistics
Definition
This submonitor in the SAP/Oracle Database Monitor lets you check the undo statistics provided by the Oracle view GV$UNDOSTAT. You can see:
· Daily summaries
· Undo statistics: daily and average values
· Maximum space consumption for undo tablespaces
PUBLIC
Page 31 of 101

SAP Basis CCMS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to SAP Basis CCMS

Similar to SAP Basis CCMS (20)

Recently uploaded

Recently uploaded (20)

SAP Basis CCMS