Did this article resolve your question/issue?



What is -DbCheck -AreaCheck -TableCheck and -IndexCheck?

« Go Back


TitleWhat is -DbCheck -AreaCheck -TableCheck and -IndexCheck?
URL NameP128290
Article Number000126073
EnvironmentProduct: OpenEdge
Version: 10.1B03, 10.2x, 11.x, 12.x
OS: All supported platforms
Question/Problem Description
What is -DbCheck?
When should -DbCheck be used?
How to enable physical consistency checks on record and index blocks ?
When -DbCheck; -AreaCheck; -TableCheck and -IndexCheck are enabled which takes precedence?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Optional database startup parameters were added to enable physical consistency checks on record and index blocks in OpenEdge 10.1B02.  These checks are performed on index or record write operations only.  

The checks are offered at different levels to allow flexibility:
  • Database level: "-DbCheck"
Enables a consistency check that will be applied to all index blocks and record blocks (except BLOB blocks) in the entire database. If using the -DBCheck and the database makes use of 64-bit dbkeys, upgrade to OpenEdge 10.2B08,11.2.1,11.3.0 before setting it. Refer to Article: 
Enables a consistency check that will be applied to all index blocks and record blocks (except BLOB blocks) in the specified area.
  • Index level: "-IndexCheck <index name>"
Enables a consistency check that will be applied to all index blocks of the specified index.  This check is for index blocks only.
  • Table level: "-TableCheck <table name>"
Enables a consistency check that will be applied to all  record blocks (except BLOB blocks) of the specified table. This check is for record blocks only.

The following precedence rules apply when enabling multiple parameters at the same time:
  1. Each option can only be enabled once. For example, the following parameters are invalid:  -AreaCheck "Customer Area" -AreaCheck "Order Area"
  2. If "-DbCheck" option is used with any other options, "-DbCheck" will have precedence and the consistency check will be applied on the whole database.
  3. "-AreaCheck <area name>", "-IndexCheck <index name>" and "-TableCheck <table name>" can be used at the same time. The consistency check will be enabled for the superset of these options.  
Syntax for using runtime and roll forward physical checking:

    On the database primary login broker:
          _mprosrv <dbname> -S 5768 -B 100000 -L 100000 -DbCheck

Shared memory client connections (which directly interact with the buffer pool) should also use the -DbCheck startup parameter if -DbCheck is enabled for the database broker(s).

    For a single user session:
          _progres <dbname> -p info.p -DbCheck
          _progres <dbname> -p info.p -AreaCheck "CustomerData"

    When using proutil:
         proutil <dbname> -DbCheck

    During roll forward:
          _rfutil dbname   -C roll forward -a /vfs/work/dbname.a1 -IndexCheck ""
          _rfutil dbname   -C roll forward -a /vfs/work/dbname.a1 -TableCheck "Pub.Customer"

Physical consistency checks -DbCheck; -AreaCheck; -TableCheck and -IndexCheck may also be enabled online via the PROMON Administrative Functions Menu:
promon <dbname>
Option 4 (Administrative Functions...)
Option 8 (Enable/Disable block level consistency check)

Enable/Disable Block Consistency Check screen:
          OpenEdge Release Monitor (R&D)
          Enable/Disable block consistency check
           This option is used to enable/disable block consistency check.
           Current consistency check status:
                    1. -MemCheck:      disabled
                    2. -DbCheck:       disabled
                    3. -AreaCheck:     disabled
                    4. -IndexCheck:    disabled
                    5. -TableCheck:    disabled
          Enter the option to enable/disable a consistency check:

When should physical consistency checking be enabled?

These parameters (-DbCheck, -TableCheck, -IndexCheck) should only be used when there is some expectation of a problem in the database.  Examples of places where these parameters may be useful (but are not limited to) performing crash recovery or roll forward upon the database.  Errors detected when running with these parameters will be written to the database log file.

When errors are found they will not necessarily bring the database down unless a corruption is really found, but if a corruption is found, database integrity is preserved by forcing an Emergency shutdown.  The advantage of the physical checking is that corruption are likely to be found at the time as opposed to later when next accessed. When corruption are detected, the current operation will be halted and the routine will produce messages detailing the nature of the corruption to the lg file of the database.  In part these are 'proactive' utilities to help diagnose If there is a potential of overwriting memory or corrupt block. In effect, decrease the time needed to find (and fix) corruption when a crash issue results (usual utilites: dbrpr scans, idxfix, idxbuild dbtool etc) 


Usr 5: Invalid Record Block Detected
Usr 5: 15: D RL_RMCHG (PL) adbkey: 6/21504 updctr: 8 difLen: -1 flags:  recnum: 0 logOp: 1 recsz: 179 newsz: 200

Usr 6: Invalid Index Block Detected
Usr 6: 268: D RL_CXINS (PL) adbkey: 6/20768 updctr: 35 objDbkey: 64 root: 20768 offset: 3 cs: 0 extracs: 4 attr: 1

Performance Impact of enabling physical consistency checks:

Enabling -DbCheck will result in a performance loss around 5% impacting operations requiring writes to the database. 
Performance losses from specific -AreaCheck, -TableCheck and -IdxCheck are smaller than -DbCheck (which is database wide)
Last Modified Date11/9/2021 3:43 PM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.