Using -i (no integrity) for binary load

Should the -i (no integrity) option be used on a binary load?
Are there data integrity issues when using the -i (no integrity) option on a binary dump and load?

 

In most cases the performance benefit of using no integrity -i is worthwhile. As long as proper planning and dry run testing are carried out beforehand and as long as re-starting the operation from the backup baseline should it fail for any reason is understood.

To ensure data integrity issues do not fail the operation, verify and fix these before carrying out the binary dump. Run full database integrity checks with a DBTOOL database scan for bad record blocks and bad records and an IDXFIX Option 3 to verify key fields and index entries on Primary Indexes or the index that is planned to be used. A binary dump relies (by default) on the primary index and if that index is missing keys then it will not dump those records. If data integrity cannot be fixed, an ASCII or bespoke ABL dump should be used for the affected tables instead.

Data integrity issues are not the only reason that could cause a load to fail and therefore be impacted by the use of -i.  Other reasons are for example when various filesize limits are reached or diskspace is exhausted. 

The risk of using -i versus not using -i in a failure scenario is the time needed to recover. The comparison amount would depend on the scenario that occurred (not just data integrity scenarios). If indexes are built at the same time or after the binary load fail due to corrupt data or running out of disk space for sorting, then it would be necessary to start again regardless of having or not having used -i during the load .

Progress Article

 What benefit does running a database with the No Crash Protection Startup Parmeter (-i) provide?   
 How to Increase Dump/Load Performance Using Binary Dump/Load?