Version 6.3.1	SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT

This document contains information related to database performance monitoring and tuning.

The following topics are covered:

• Monitoring Usage of Resources

• Reporting on Usage

• Monitoring Database Control

• Performance Management, Statistics, Tuning

• Command Logging

• showcls (UNIX only)

• showipc (UNIX only)

• Adabas Interprocess Communication (OpenVMS only)

• Preparing Dump Tapes

Monitoring Usage of Resources

It is the responsibility of the DBA to monitor the database environment on a continuing basis in order to ensure that an efficient level of service is provided while maintaining database integrity. This responsibility for monitoring takes the form of a variety of activities and procedures, some of which are covered in this section.

The responsibility of the DBA to maintain database performance at an acceptable level is critical and difficult. The sources of degradation of service are numerous and often difficult to trace, while the process of making adjustments can be complex.

The DBA must implement a set of procedures which are designed to foresee degradation before the event and to adjust the operation or design of the database in an orderly and controlled way. This set of procedures will include the following activities:

• Identifying potential sources of degradation;

• Establishing tools for monitoring database performance;

• Controlling the implementation of adjustments;

• Controlling the implementation or redesign of the database to meet the new requirements.

Reporting on Usage

The DBA should make regular reports on database usage and performance to both data processing and user management. These reports should be as factual as possible, but also include recommendations for the tuning of the database environment as he develops them. It should be remembered that tuning, while benefiting the organization as a whole, may adversely affect the service received by one or more users. Any decision on tuning should, therefore, be taken by all affected users.

Monitoring Database Control

The DBA should establish appropriate controls and monitor them to assist him in ensuring the integrity of the database.

Computer-generated control totals can be checked and cross-footed between computer processing runs or generated reports. Batch responses (or inquiries) may include such information as the exact run time, search parameters, time of last update of data, and the primary parameter controls. This increases the confidence level and helps to ensure the integrity of the database.

The problem of control totals is one which will take on many different guises at different installations. It is not possible to lay down hard and fast rules in this area. However, it is felt appropriate to give some general guidelines.

The DBA should ensure that proper consideration is given to the following areas in the design of each application system which will use the database:

• What controls can be checked on every batch update run? For example, record counts, additions, deletions, updates;

• What controls require a full file pass to check them? For example, value field hash totals;

• What input transactions, Adabas logs, etc. should be retained in order to be able to recover when control totals are found to be wrong at the end of a given period;

• Are 'localized' control totals (e.g., by branch, product group) of any use in identifying the areas affected by a file control total error?

Performance Management, Statistics, Tuning

The following table illustrates some of the monitoring statistics that may be used and what adjustments to (or tuning of) the database environment may result.

When any alteration is made to a production database, great care must be taken to ensure a continued high level of reliability and integrity. Whatever the change, the DBA must make sure that the decision is the right one and that it is properly and accurately implemented. He should retain absolute control over the tuning process and ensure that it follows the formal acceptance procedures.

The DBA must be very careful not to over-react to changes in the items listed in the table. A sudden change in line traffic, response times, etc., may only be a temporary affair. It is far better to wait for a while to see whether this is a permanent trend or a temporary disturbance to the normal way of operating. Another way of viewing the table is that the tuning required may be necessary when a new project will cause a significant change in terminal and line traffic, response times, etc. The DBA can then act in advance to minimize these effects before the new application system is implemented.

Command Logging

The Adabas command log option of the Adabas nucleus may be used to generate information on all the commands issued by users to Adabas.

Some of the information provided is:

• User identification

• Time of day

• What command was used

• Which file was accessed

• Which record was accessed

• What Adabas response code was received

• How long the command took to perform

This information provides a further level of knowledge of the activity against the database. It can be displayed using the utility ADACLP.

showcls (UNIX only)

showcls is a tool that analyses the client queue semaphore of a database. It is called with the following syntax:

showcls <dbid>

showcls displays the status of each client queue element of the database:

showipc (UNIX only)

showipc is a tool that the DBA can use in order to look at the UNIX kernel ipc configuration, and to look at the Adabas/NET-WORK ipc structures and clean them up. For each database, showipc displays the shared memory, the message queues, and the semaphores associated with the database in question.

The following options are available:

showipc [-adfhiksv] [-e<string>] [-g<g_name>] [-r<sec>] [-u<u_name>] [<dbid>...]

One or more <dbid> arguments may be supplied. If <dbid> is omitted, showipc processes the ipc structures for all active databases. In addition to the numeric values that represent valid DBIDs, the strings CSCI, ACS and U can also be supplied. CSCI (client server communication interface) returns information for all ipc elements of CSCI users. ACS returns information about the ipc elements used by NETACS (NET-WORK access server). U indicates all elements that cannot be associated with a database (database unknown).

showipc also supports multiple logical NET-WORK nodes. The NET-WORK ipc structures are identified by the <dbid> zero and a NET-WORK ID. Unless the -a or -e options are used (see below), information is only displayed for the default NET-WORK ID. If the environment variable NET_WORK_ID is set, the corresponding NET-WORK ID will also be processed.

Note:
The information provided above concerning NET-WORK is only relevant for NET-WORK Version 2, which is no longer supported with Adabas Version 6. However, showipc of Adabas Version 6 also supports Adabas Version 5 databases, which can still be used with NET-WORK Version 2.

The following table shows the meanings of the various options that are supported:

Output of showipc

The first column of the default output format contains either "NET" for NET-WORK (followed by the NET-WORK ID if it is not the default NET-WORK ID), or "NACS" for NETACS, or "CSCI" for CSCI, or the numeric DBID of the database in question. This is followed by a list of the ipc elements for the database. The entry for each element consists of an abbreviation to indicate its type, and, separated by a colon, the ipc id of the element. This id can then be used for the "ipcrm" command ("showipc -k <dbid>" is, however, much more convenient). The following abbreviations are used:

shared memory

message queues

semaphores

The verbose output format (-v option) displays additional information for each element. Three tables are displayed for each database: one for shared memory, one for message queues, and one for semaphores. The columns in these tables have the following meanings:

shared memory

message queues

semaphores

For NETACS elements, the column TYPE is replaced by DOMN, which represents the NETACS domain.

Note:
Because showipc reads the kernel memory structures, it must be run with the effective user id of root.

If the running kernel does not have the default name (for example "/hp-ux" for HP-UX,, ...), showipc will abort with an appropriate error message. This can be prevented by setting the environment variable SIP_KERNAM to the correct name, in csh for example "setenv SIP_KERNAM '/mykernel'".

Environment Variables

The following environment variables are used together with showipc:

Messages

The following messages may be received when using showipc:

Examples

showipc

This displays the ipc structures of all Adabas databases and of the default NET-WORK ID.

showipc -av

This displays the ipc structures of all Adabas databases and of all logical NET-WORK IDs in the verbose format.

showipc -ki 127

This removes all of the ipc structures of database 127 if the database nucleus is not running. showipc will ask for confirmation before an ipc structure is removed.

Adabas Interprocess Communication (OpenVMS only)

Beginning with Adabas Version 6.1 on OpenVMS Itanium, Adabas uses a set of techniques for exchanging data data between client and server processes. These IPC (Interprocess Communication) techniques are divided into methods for synchronization, message passing and shared memory data exchange.

Adabas IPC on Open VMS

The IPC types used by Adabas for OpenVMS are implemented in an independent IPC layer, which uses the existing interprocess facilities available on OpenVMS:

Each IPC resource is represented in the system by a key name of 8 bytes length with the following structure:

It is possible to have the same key name for different facilities. For example, Adabas uses the same key name for the ‘common client message queue’ and the ‘common shared area’.

Example: IPC Resources for Database 12

Adabas Tools

The Adabas DBA on the OpenVMS HP Integrity server must be able use IPC methods if emergency situations arise. ADAIPCS and ADAIPCRM are tools that the DBA can use in order to display and maintain IPC resources for each database running on the local node. These tools are necessary in case a database server or a utility are terminated abnormally.

ADAIPCS

The procedure adaipcs.com provides basic information about the IPC facilities of Adabas. It shows the key of the resource and the database ID to which this key belongs.

The following options are available:

ADAIPCS returns a value of 1 if it completes successfully.

Example: Using ADAIPCS to display ICP Resources

The ICP resources of DBID 41 are displayed.

$ @adaipcs
------ Shared Memory Segments --------
key         dbid
ADAB0029     41
ADA00029     41
ADA10029     41
------ Semaphore Arrays --------
key         dbid
ADAC0029     41
ADA10029     41
ADA30029     41
------ Message Queues --------
key         dbid
AD000029     41
ADA00029     41
ADA00129     41

$

ADAIPCRM

The procedure adaipcrm.com removes one or more specified message queues, semaphore sets, or shared memory identifiers of an Adabas database. The database must not be running when IPC resources are removed. If the resource is being held by another process, it will be marked for deletion and remains active until the process in question is terminated.

The following options are available:

ADAIPCRM returns a value of 1 if it completes successfully. It returns a value >1 if any of the operations fail.

Example: Using ADAIPCRM to remove a shared memory key

The value of the shared memory key is determined using ADAIPCS

$ adaipcrm -M ADAB0029
INFO: Global Section ADAB0029 deleted ...

$

ADASHOWIPC

The DBA uses ADASHOWIPC to look at the Adabas IPC structures and clean them up. For each database, ADASHOWIPC displays the shared memory, the message queues, and the semaphores associated with that database. If the resource is being held by another process, it will be marked for deletion and remains active until the process in question is terminated.

The following options are available:

The following abbreviations are used in the output:

Example: Using ADASHOWIPC to display IPC resources

$ adashowipc

         ADASHOWIPC (1.2.5) for Adabas OpenVMS

DBID  Shared Memory    Message Queues   Semaphores
-----------------------------------------------------
 112  GCB CSA ATB      SRV SRV CLM      ENQ CLS SDA
      ATX
 113  GCB CSA ATX      SRV SRV CLM      SDA CLS ENQ
      ATB              CLM CLM CLM
                       CLM CLM CLM
                       CLM

$

Example: Using ADASHOWIPC to remove IPC resources (DB active)

$ adashowipc -k 112

         ADASHOWIPC (1.2.5) for Adabas OpenVMS

Nucleus of DB 112 still running, I do not remove anything.

Example: Using ADASHOWIPC to remove IPC resources (DB not active)

$ adashowipc -k 112

         ADASHOWIPC (1.2.5) for Adabas OpenVMS

DB 112: removing GCB: shared memory ADA10070 ... successful.
DB 112: removing CSA: shared memory ADA00070 ... successful.
DB 112: removing ATB: shared memory ADAB0070 ... successful.
DB 112: removing ATX: shared memory ADAD0070 ... successful.
DB 112: removing SRV: message queue ADA00170 ... successful.
DB 112: removing SRV: message queue ADA00070 ... successful.
DB 112: removing CLM: message queue AD000070 ... successful.
DB 112: removing ENQ: semaphore ADA30070 ... successful.
DB 112: removing CLS: semaphore ADA10070 ... successful.
DB 112: removing SDA: semaphore ADAC0070 ... successful.

Preparing Dump Tapes

How to prepare Problem Information

If a problem should occur at a customer site, Software AG's support team wants to supply solutions as fast as possible. To minimize the time required to analyze a problem and deliver a solution, the support team requires detailed information about the problem.

The standard problem information should contain:

• Problem description:

  • Adabas component or function used

  • error messages (message ID)

  • short description of the problem

• Environment description:

  • Adabas version

  • corrections used

  • operating system version

  • hardware environment (CPU type, disk device types, etc.)

• Can the problem be reproduced ?

  • What are the steps to reproduce it

  • Which data is needed to reproduce it

If the problem is not reproducible, the problem information should contain additionally:

• Where does the problem occur ?

  • on all databases or on a single databases only

  • on databases within a specific environment only

  • environments where the problem does not occur

• When does the problem occur ?

  • always or only sporadically

  • in parallel with other events

  • periods of time when the problem does not occur

  • When did the problem first occur ?

  • changes of the environment around this date

  • last changes of the environment before this date

  • In the case of data corruption problems:

  • date of last successful database verification run

  • utilities used on the corrupted file (checkpoint list)

  • disk problems encountered

Problem Information on tape

Depending on the nature of the problem, information supplied on tape is necessary for problem analysis. A description of the tape's content must be added, so that Software AG support staff can build an optimal environment into which the tape's contents can be copied. This is particularly important when the tape contains large amounts of data, since sufficient disk space has to be allocated for unloading the data. The problem data should be provided and documented in a way that allows files to be copied selectively.

The tape documentation should contain the label(s) of the tape(s) and a list of all files including their sizes. If backups are contained on the tape, the corresponding information should be supplied for each backup.

The problem data you should supply depends on the kind of problem. The problem should be assigned to one of the following problem categories:

• nucleus abort

• nucleus autorestart abort

• utility abort

• data corruption problem

• other problem

Nucleus abort

The following problem data should be supplied on tape:

• ADABAS.xxx global section file

• ADANUC log file and process dump

• ADANUC and ADASHR image

• database layout and file information (ADAREP)

• protection log and command log file (if available)

Nucleus autorestart abort

The following problem data should be supplied on tape:

• files as listed for "Nucleus abort"

• a copy of the WORK containing the autorestart data

Utility abort

The following problem data should be supplied on tape:

• utility output (log file) and process dump

• utility and ADASHR image

• database layout and file information (ADAREP)

• input and output files

Data corruption problem

The following problem data should be supplied on tape:

• protection logs

• utility usage information (checkpoint list)

• information about the kind of corruption (ADAVFY output or information about an abort due to the corruption)

Other problems

The following problem data should be supplied on tape:

• information useful to reproduce the problem

• any other information that might help, please ask your nearest Software AG Support centre for assistance

www.softwareag.com

Copyright © 1987-2013 Software AG, Darmstadt, Germany.

SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT