Monitoring backup performance:
Sometimes it is difficult to know why the backup process is slow down. So for that we need continuous monitoring on backup process. Here we present some scenarios and monitoring steps to monitor the backup process in db2.
Starting with DB2 V10.1 FixPack 2, every successful backup or restore operation logged into the db2diag.log file. This feature also exists in DB2 V9.7, but must be enabled by using the DB2_BAR_STATS registry variable.
==> BM - The db2bm EDU ID.
==> Total - EDU existed time.
==> I/O - Time that was spent performing read or write I/O.
==> MsgQ - Waiting time for an I/O buffer.
==> WaitQ - Waiting time for a state machine control message.
==> Buffers - Number of I/O buffers that were processed.
==> Kbytes - Quantity of data that was processed.
==> MC - The db2med EDU ID.
If the backup was performed using the COMPRESS option:
==> Compr - Time spent to perform the compression operation.
==> Compr Bytes - Quantity of uncompressed data that was compressed.
Scenario - 1:
The following example depicts a scenario in which the db2bm EDUs spend more than optimal time waiting on a free buffer:
In this scenario the db2bm EDUs spend 27% (31.95/116.66) of the time waiting on a free buffer (MsgQ). There are two potential options to address this issue:
1. Increase the number of buffers. Result in more, smaller I/O operations due to reducing the size of the buffers.
2. By specifying more devices in the TO clause of the backup database command we have to allocate more db2med EDUs.
Scenario - 2:
The following example depicts a scenario in which the db2bm EDUs spend more than optimal time compressing data:
In this scenario, the db2bm EDUs are spending 53% (28.28/53.58) of the time compressing data. To eliminate the need of compression during every backup we have the alternative to use table-level compression so that the tables are stored in compressed format in the database.
Scenario - 3:
The following example depicts a scenario in which the db2bm EDUs spend too much time in WaitQ:
In this scenario, 2 out of 3 db2bm EDUs spend almost all of the time in WaitQ. A high WaitQ value indicates that the db2bm EDU was idle for most of the backup. The number of Buffers processed is also heavily skewed to one db2bm EDU, which indicates that there was one table space in this database that was significantly larger than the rest. Redistributing data so that the table spaces are equally sized improves backup performance.
While making a deposit in your Binance account through verified MasterCard do you encounter any trouble that panic as well as annoys you? Most of the Binance users are unable to deal with the errors due to less information about the Binance features. Under such situations, you can speak to the team of Binance Support Number elite professionals via dialing Binance support number which is the gateway to submit your queries in front of the experts who will fix all your queries in the least possible time.
ReplyDeleteDo you face hardship while selling the bitcoin in your Gemini account? To resolve such errors, you can always contact the team of professionals who are there to assist you. Dial Gemini support number and avail the best solution from the professionals who are there to handle your queries. Talking to the team is the best decision as they are always occupied with plenty Gemini Support Number of solutions that are difficult to resolve. Connect with the team and get the verified answers from professionals who are there to listen to your queries and give accessible remedies.
ReplyDelete