|
|
|
|
|
|
System Information - MIMINFO
The MIMINFO program is used to obtain information from a Mimer SQL database server which is useful for system control, system tuning and trouble-shooting analysis.
Information can be generated from an active Mimer SQL database server as well as from the SQLPOOL and Bufferpool dump files produced by using MIMCONTROL, see Controlling the Database Server - MIMCONTROL.
The output from MIMINFO can be displayed on the screen and may also be directed to a file.
The following reports may be obtained from MIMINFO (further details on each report can be found in the sub-sections that follow):
MIMINFO Syntax
The MIMINFO program is controlled by flagged information specified on the command-line.
The overall syntax for MIMINFO (expressed in UNIX-style) is:
miminfo [-o file] -u | -p | -s [database] miminfo [-o file] -u | -p | -m | -s -fMIMINFO Command-line Arguments
UNIX-style
VMS-style
Function
A detailed description of each of the MIMINFO reports follows.
The Users List
miminfo [-o file] -u [database] | -fA users list can be generated from an active database or from a dump file produced using MIMCONTROL.
The users list shows the name of each ident connected to the database, the channel number used by the connection, the state of the connection, transaction number, the name of the operating user, the network communication protocol (or 'local') and node identification information for connected machine.
The channel number may be used in conjunction with MIMCONTROL to kill a user.
The following is an example of a users list report:
Username Channel State Trans. no OS user Prot From ============ ========== ===== ========== ============ ====== ==== SYSADM 16387 Busy 3 TCP 204.71.200.67 SYSADM 16388 Busy SARA Local 00019120The Performance Report
miminfo [-o file] -p [database] | -fThe Performance report (MIMSERV) can be used by the system administrator to monitor performance parameters during Mimer SQL use. The Performance report can be generated from an active database or from a dump file produced using MIMCONTROL.
The Performance report presents five kinds of statistical information which may be useful for system tuning (statistics for page management, transactions, background threads, databank and table usage).
Note: When a Performance report is used as an aid to system tuning, it is important that the report is generated when the database is in full use. The output from several executions over a period of a few hours or days can provide valuable information on fluctuations in system usage.
The Performance report contains the following information:
- General Statistics
- Page Management Statistics
- Transaction Management Statistics
- Background Threads
- Databank Statistics
- Table Statistics
General Statistics
- Current date and time
- Current hardware and operating system
- Current MIMER/DB version
- Name of database
- Starting date and time
- System status
If system status is in an error state, a database dump is usually made automatically. It can be made manually by using the "-A" option in MIMCONTROL. The dump directory created should be saved for use by Mimer Support personnel. The database server can then be restarted.
The database server log, see Database Server Log, should also be inspected to help find the cause of the failure.
- Error count
Number of errors that have been written to the database server log. This value should normally be zero.
- No. of request threads
Number of request threads started, see Number of Request Threads.
- No. of background threads
Number of background threads started, see Number of Background Threads.
- No. of I/O threads
Number of I/O threads (typically zero on most machines where separate threads are not needed for I/O processing).
Page Management Statistics
- No. of pages written to disk
- No. of file extend operations
The total number of times databank files have been dynamically extended since the latest startup. The value should preferably be as low as possible for performance reasons.
It is possible to check databank size usage with the DESCRIBE command in BSQL. A databank can be extended by using the commands ALTER DATABANK ADD... or ALTER SHADOW ADD....
- Buffer size 2K (16K, 64K)
The bufferpool is divided into a region with 2K buffers, one region with 16K buffers, and one region with 64K buffers. The following information is given for each region:
- No. of page buffers
This is the number of page buffers allocated to this bufferpool region.
- No. of page buffers per sorter
Total number of Mimer SQL pages that a request thread performing a sort operation may utilize.
- No. of remaining sorters
The initial value specifies the number of concurrent sort/merge steps that are allowed.
- No. of page partitions
Each region in the bufferpool is divided into separate partitions. Each partition can be accessed concurrently by the Mimer SQL request threads. In tightly coupled multi-processor systems it is desirable, for performance reasons, to have at least as many partitions as there are CPUs. The number of partitions may be increased by increasing the region size.
- No. of page requests
Total number of access operations to pages in the buffer region since the latest system start-up.
- No. of page faults
Total number of page access requests that resulted in disk read operations. If this value is more than about 2% of the total number of page requests, performance may be improved significantly by increasing the bufferpool size. (For a recently started system this figure may be higher than 2% due to initial bufferpool read operations).
- No. of pages swapped out
Total number of pages which were written to disk when they were swapped out of the buffer region.
Transaction Management Statistics
- No. of transaction commits
Total number of successful read/write transaction commits since the latest system start-up.
- No. of read commits
Total number of successful read-only transaction commits since the latest system start-up.
- No. of transaction checks
A high proportion of transaction checks in relation to the total number of transactions may indicate ill-designed application programs, with long transactions that are more likely to give rise to transaction conflicts.
- No. of transaction aborts
Total number of transactions aborted by the optimistic concurrency protocol since the latest system start-up. User requested transaction aborts are not counted.
- No. of pending restarts
This is an indication of how much information is stored in TRANSDB. Number of restarts is counted for each databank used in a transaction. This figure grows larger when shadows are set offline.
If all databanks have been accessed and there are no offline shadows there should not be any pending restarts.
Background Threads
- SWA
- State
State of the background thread. If the background thread is currently working with a transaction, "active" is displayed. If the background thread is not doing anything, "inactive" is displayed. "I/O processing" means that the background thread is flushing one or more transactions to disk and "unused" means that the background thread is allocated but not currently running (i.e. the thread is not started or closed down).
- Trans-no
- Trans-count
The number of transactions processed by the background thread.
- Pending background thread requests
This indicates how many transactions have not yet been processed by the background threads. If there are too few background threads this value will grow.
- Application waiting for trans-no
For certain operations (SET DATABANK OFFLINE, for example) the application has to wait for the background threads to complete their operations.
If there are too few background threads it may take some time before this operation is complete. By comparing this trans-no with the trans-no being handled by the background threads it is possible to see how many transactions are left before the operation is completed. (Note that the example report shown in Section 4.3.3.1 does not show this statistic because the application is not waiting for transactions to complete.)
Databank Statistics
- Name
- DBANKID, SEQNO
Databank identification. These two values correspond to the columns DATABANK_SYSID and DATABANK_SEQNO in the data dictionary table SYSTEM.DATABANKS.
- Type
The databank option NULL, TRANS, or LOG. See Re-creating TRANSDB, LOGDB and SQLDB.
The SQLDB databank has the type WORK, and shadows have the type SHADOW.
- Users
- Access
Access mode by which the databank was opened. The possible values are: "Read", "Write", "Shared" and "Exclusive". If the databank is open but not referenced by any active statement, "None" is displayed.
- DB-Check
The DB-Check field indicates the progress of a databank check. The possible values are "Init", "Working" (foreground processing, typically index check), "Wait B." (foreground ready, waiting for background entrance), "Backgr." (background processing), "Aborting", "Aborted" or "Complete".
- Note: After the DB-Check field, a field for additional information may show up. The values here can be the shadow state "offline", or the online backup states "backup in progress" or "backup completion".
- No. of databanks currently open
- Max number of databanks open concurrently
This is defined by a parameter in the local database definition, see The Local Database, or possibly by a limit in the operating system.
- Databank verification count
Databank verification is automatically performed when a databank is re-opened without having been correctly closed. Each time this happens a log entry is written to the database server log. When a databank is verified the databank verification count is incremented. The count is cleared when the system is started, and a databank is only verified once per session.
- Running background verifications...
- Pending background verifications...
These information messages indicate the number of active databank verifications.
- Databank verification is only done on index pages...
- Databank verification is performed on all pages...
These information messages indicate the databank verification mode as defined in the local database definition, see The Local Database.
Table Statistics
- No. of tables currently open
This shows the number of tables open in both master and shadow databanks. Also included are the read and write sets used by each user.
- Max number of tables open concurrently
This number is set as a parameter in the local database definition, The Local Database.
Performance Report Example
The following example output is from a Mimer SQL system which is not being limited by the bufferpool size (page faults, in 2K region, are only about 1% of page requests).
The number of transaction checks is low, indicating either that concurrent user update requests are infrequent or that transaction handling in application programs is well-designed.
The 64K region has not been used at all. It is possible to adjust the sizes of the different regions depending on the requirements of the system.
The error count has a value of 4 which indicates that 4 errors have been written to the database server log, see Database Server Log.
The databank SYMDB has an error status. The database server log will contain further information.
The shadow CASE5_S1 has been set offline as indicated at the end of the line describing the shadow.
# miminfo -p hotel M I M E R / M I M I N F O Version 8.2.1A Oct 9 2000 *** MIMER/DB runtime statistics 2000-10-18 15:48:12 *** Hardware, operating system UNIX 32 Current MIMER/DB version is 8.2.1A Oct 9 2000 Database name: HOTEL System started at 2000-10-18 15:47:54 System status is up Error count : 4 No. of request threads : 2 No. of background threads : 2 No. of I/O threads : 0 Page management statistics ========================== No. of pages written to disk : 1774 No. of file extend operations : 0 Buffer size 2K -------------- No. of page buffers : 2614 No. of page buffers per sorter : 135 No. of remaining sorters : 2 No. of page partitions : 9 No. of page requests : 40859 No. of page faults : 432 1 % No. of pages swapped out : 0 Buffer size 16K --------------- No. of page buffers : 164 No. of page buffers per sorter : 72 No. of remaining sorters : 2 No. of page partitions : 1 No. of page requests : 44817 No. of page faults : 7 0 % No. of pages swapped out : 0 Buffer size 64K --------------- No. of page buffers : 54 No. of page buffers per sorter : 17 No. of remaining sorters : 2 No. of page partitions : 1 No. of page requests : 0 No. of page faults : 0 No. of pages swapped out : 0 Transaction management statistics ================================= No. of transaction commits : 1336 No. of read commits : 0 No. of transaction checks : 1436 No. of transaction aborts : 103 No. of pending restarts : 18 Background threads ================= SWA State Trans-no Trans-count 253 Inactive slave 0 11985 267 Inactive 0 1394 Pending background thread requests : 0 Databank statistics =================== Name DBANKID SEQNO Type Users Access DB-Check TESTDBM1 310 0 TRANS 1 Shared Complete TESTDBM2 311 0 TRANS 1 Shared Complete SYSDB 1 0 LOG 2 Shared Complete TRANSDB 2 0 TRANS 1 Shared Complete LOGDB 3 0 LOG 1 Shared Complete SQLDB 4 0 WORK 1 Shared Complete SYMDB 285 0 TRANS 1 Shared Complete Databank error status: -16142 CASE5 279 0 LOG 1 Shared Complete CASE5_S1 279 1 SHADOW 1 Shared Init Offline No. of databanks currently open : 6 Max number of databanks open concurrently: 100 Databank verification count : 0 Running background verifications : 0 Pending background verifications : 0 Databank verification is performed on all pages Table statistics ================ No. of tables currently open : 36 Max number of tables open concurrently : 4000 #Bufferpool Report
miminfo [-o file] -m -fThe Bufferpool report (MIMDUMP) is used by Mimer Support personnel for trouble-shooting when database problems are reported by customers.
SQLPOOL Report
miminfo [-o file] -s [database] | -fA SQLPOOL report is useful when the server is malfunctioning due to a memory problem. SQL pool memory allocated is the amount of memory allocated from the operating system for the SQLPOOL. A part of that memory is in use by the server and is displayed on the row SQL pool memory used.
The following is an example of a SQLPOOL report:
SQLPOOL report ============== SQL pool memory allocated (KB): 1656 SQL pool memory used (KB): 554
 Upright Database Technology AB Voice: +46 18 780 92 00 Fax: +46 18 780 92 40 dbtechnology@upright.se |
|
|
|
|
|
|