A transaction is defined as the unit of work exchanged between the client and server. The log records for a given DB transaction are moved into stable storage when the transaction is committed. The database information that is stored on disk remains consistent because the server ensures that the recovery log records, which represent the updates to these database pages, are written to disk.
During restart-recovery, the server uses the active and archive log information to maintain the consistency of the server by redoing and, if necessary, undoing ongoing transactions from the time that the server was halted. The transaction is then committed to the database.
Transaction commit is a function of all the log records for that transaction being written to the recovery log. This function ensures that the necessary redo and undo information is available to replay these transaction changes against the database information.
A transaction that contains multiple files or directories is called a transaction group. Using the TXNGROUPMAX server option, you can specify the number of files or directories that are contained within a transaction group. You can use the TXNGROUPMAX option to increase performance when Tivoli® Storage Manager writes to tape. This performance increase can be considerable when you transfer multiple small files.
Also Read: How TSM Server determines the eligibility of files during different types of backup ?
If you increase the value of TXNGROUPMAX by a large amount, monitor the effects on the recovery log. A larger value for the TXNGROUPMAX option can have the following impact:
Also consider the number of concurrent sessions to be run. It might be possible to run with a higher TXNGROUPMAX value with a few clients running. However, if there are hundreds of clients running concurrently, you might need to reduce the TXNGROUPMAX to help manage the recovery log usage and support this number of concurrent clients. If the performance effects are severe, they might affect server operations.
The following examples show how the TXNGROUPMAX option can affect performance throughput for operations to tape and the recovery log
During restart-recovery, the server uses the active and archive log information to maintain the consistency of the server by redoing and, if necessary, undoing ongoing transactions from the time that the server was halted. The transaction is then committed to the database.
Transaction commit is a function of all the log records for that transaction being written to the recovery log. This function ensures that the necessary redo and undo information is available to replay these transaction changes against the database information.
How TXNGROUPMAX Server Option works
The client program can move multiple files or directories between the client and server before it commits the data to server storage.A transaction that contains multiple files or directories is called a transaction group. Using the TXNGROUPMAX server option, you can specify the number of files or directories that are contained within a transaction group. You can use the TXNGROUPMAX option to increase performance when Tivoli® Storage Manager writes to tape. This performance increase can be considerable when you transfer multiple small files.
Also Read: How TSM Server determines the eligibility of files during different types of backup ?
If you increase the value of TXNGROUPMAX by a large amount, monitor the effects on the recovery log. A larger value for the TXNGROUPMAX option can have the following impact:
- Affect the performance of client backup, archive, restore, and retrieve operations.
- Increase utilization of the recovery log, as well as increase the length of time for a transaction to commit.
Also consider the number of concurrent sessions to be run. It might be possible to run with a higher TXNGROUPMAX value with a few clients running. However, if there are hundreds of clients running concurrently, you might need to reduce the TXNGROUPMAX to help manage the recovery log usage and support this number of concurrent clients. If the performance effects are severe, they might affect server operations.
The following examples show how the TXNGROUPMAX option can affect performance throughput for operations to tape and the recovery log
- The TXNGROUPMAX option is set to 20. The MAXSESSIONS option, which specifies the maximum number of concurrent client/server sessions, is set to 5. Five concurrent sessions are processing, and each file in the transaction requires 10 logged database operations. This would be a concurrent load of:
20*10*5=1000
This represents 1000 log records in the recovery log. Each time a transaction commits the data, the server can free 200 log records.
- The TXNGROUPMAX option is set to 2000. The MAXSESSIONS option is set to 5. Five concurrent sessions are processing, and each file in the transaction requires 10 logged database operations, resulting in a concurrent load of:
2000*10*5=100 000
Also Read: TSM Server Performance Tuning Parameters
Over time and as transactions end, the recovery log can release the space that is used by the oldest transactions. These transactions complete, and the log space usage increases.
Based on the previous two examples, five concurrent transactions with a TXNGROUPMAX setting of 2000 consume much more space in the recovery log. This increase in log space usage also increases the risk of running out of recovery log space.
The following table shows a comparison of the examples of the preceding TXNGROUPMAX settings. This example becomes more significant if a given log record takes 100 bytes.
| TXNGROUPMAX Setting | Number of Log Bytes Consumed |
|---|---|
| TXNGROUPMAX=20 | 100,000 |
| TXNGROUPMAX=2000 | 10,000,000 |
You can use several server options to tune server performance and reduce the risk of running out of recovery log space:
- Use the THROUGHPUTTIMETHRESHOLD and THROUGHPUTDATATHRESHOLD options with the TXNGROUPMAX option to prevent a slower performing node from holding a transaction open for extended periods.
- Increase the size of the recovery log when you increase the TXNGROUPMAX setting.
Evaluate the performance and characteristics of each node before increasing the TXNGROUPMAX setting. Nodes that have only a few larger objects to transfer do not benefit as much as nodes that have multiple, smaller objects to transfer.
Also Read: How to increase TSM restore performance
For example, a file server benefits more from a higher TXNGROUPMAX setting than does a database server that has one or two large objects. Other node operations can consume the recovery log at a faster rate. Be careful when increasing the TXNGROUPMAX settings for nodes that often perform high log-usage operations. The raw or physical performance of the disk drives that are holding the database and recovery log can become an issue with an increased TXNGROUPMAX setting. The drives must handle higher transfer rates to handle the increased load on the recovery log and database.
Also Read: How to increase TSM restore performance
For example, a file server benefits more from a higher TXNGROUPMAX setting than does a database server that has one or two large objects. Other node operations can consume the recovery log at a faster rate. Be careful when increasing the TXNGROUPMAX settings for nodes that often perform high log-usage operations. The raw or physical performance of the disk drives that are holding the database and recovery log can become an issue with an increased TXNGROUPMAX setting. The drives must handle higher transfer rates to handle the increased load on the recovery log and database.
You can set the TXNGROUPMAX option as a global server option value, or you can set it for a single node. For optimal performance, specify a lower TXNGROUPMAX value (between 4 and 512). Select higher values for individual nodes that can benefit from the increased transaction size.
0 Comment to "Use TXNGROUPMAX server option to send multiple files in a single transaction"
Post a Comment