Skip to Content

Hi,

  1. Optimize runtime of Check data

SAP recommends to run the check data on a system copy to avoid negative influence on the parallel productive work.

SAP systems are getting larger and not each customer can create a system copy only for check data.

So customers more and more decide to run the check data when there is less productive activity on the database server e.g. during the week end.

As larger the systems are getiing as longer the check data was running.

When there is less time left with low workload the check data must be optimized.

To reduce the runtime of check data you can choose the option Check data without index. A corrupted index does not result in a recovery,

indexes can be rebuild if a corruption is detected (Recreate Index).

Check data without index is also recommended to avoid lock situation between index check and Savepoint.

Check Data cannot check one table or Index in parallel. The servertasks are responsible for reading the data into the cache and  execute the check.

By default the number of servertasks is related to the number of data volumes. SAP implemented new functionality to further optimize check data with the following MaxDb Versions:

7.9.08. >= Build 06

7.8.02. >= Build 30

7.6.06. >= Build 23

Read Ahead is used as well for check data. You will find detail information and configuration hints in SAP note https://service.sap.com/sap/support/notes/1837280

(SMP Login required) Check Data runtime optimization.

We did some runtime tests and could reduce the runtime of check data significantly.

2. Check data with Index marks indexes as corrupted by mistake

This problem can only happen if you use 7.8.03. >= 34 or 7.9.08 >= 08 and parameter UseCheckIndexYield is set to YES in your systems.

Please set the parameter UseCheckIndexYield=NO

Regards, Christiane

.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply