How to scan databases using the latest Hotfix for 10.2B0864
Scanning databases before migrating to higher OpenEdge version.
Is it recommended to scan production database(s) in the latest hotfix before migrating to higher version ?
Highly recommend to scan production database(s) in the latest hotfix before migrating to higher version.
 

To assure a successful migration, it is highly recommended to scan the OpenEdge database(s) before migrating to higher version.

Follow the steps on this section to Install OpenEdge 10.2B, apply the service pack, hotfix, and then scan the database in order to migrate it without any potential corruption.

It is also typically recommended to have a backup of the Progress / OpenEdge installation prior to application of a service pack or hotfix in case it is necessary to revert to the state before the SP or Hotfix was applied. 

Using another machine the service pack and hotfix can be applied to the copy without disturbing the running production processes.

1. Install OpenEdge 10.2B. 
2. Install the 10.2B08 Service Pack
3. Apply the HotFix and change any necessary owner, group, or permissions
4. Use ./proenv.sh to set environment variables properly.
5. Go to production and make a backup of the database.
6. Restore the database in the second environment.
7. Start up this environment and scan the database.
8. Any corruption found then needs to be specifically addressed against the production environment.

When dealing with a copy of a production database, the following tools should be used:

1. DBTOOL - Option 3 (Record Validation). 

Command:  dbtool dbname

This option of dbtool can impact database performance and that is why it is typically reserved for scanning a back up or a copy of a production database. 

This option performs a record level validation.  It puts the records together in an effort to ensure that the record is properly formatted and accessible in every block.
It does not validate missing record fragmentation in Large Objects(LOBs).
It does report warning messages if the first record fragment < 10 bytes which needs to be corrected. Refer to Article:

•  10.1B and later Database crashes with System error 822

2.  IDXFIX - Option 3

Command:  proutil dbname -C idxfix

For verification of indexes, use idxfix option 3 which does
This option for idxfix will check database records and indexes to determine whether an index is corrupt or a record has a missing or incorrect index.  This utility can also repair corrupted indexes.

3.  IDXCHECK - Option 3

When the database has storage area's that straddle the 32-bit/64-bit boundary, it is imperative the OpenEdge 10.2B0864 is used which was released to address PSC00350688 for indexes that span the 32/64-bit boundary. This is a Generally Available HF, associated with critical alert:   Critical Alert – Index manager defect can corrupt large indexes where dbkeys straddle 32/64-bit boundary.  

Progress Articles:

 Upgrading an OpenEdge database from version 10.x to 11.x with conv1011  
 What tools / utilities can I run to check the integrity of a database or check for corruption?
 How to optimize deployment of service pack or hotfix in a production environment on Unix?
 How to install Progress/ OpenEdge Hotfix