When
no-integrity (-i) and AI are used together on the source database, the resulting AI files cannot be used for
rollforward except when:
a.) There is no crash or abnormal shutdown and
b.) The last AI log is complete and
c.) The last AI log has no active transactions at the end
d.) It is not needed to run : rfutil -C rollforward retry
It is not possible to know in advance that it will turn out this way beforehand. If it does turn out this way, you're unlikely to be needing the ai files or the target database transition anyway.
For the same reason an
online backup is incompatible with no-integrity mode (there is not enough information in the BI file to get through crash recovery since the various notes that are missing make REDO impossible); AI files created while running the database with no-integrity mode are not reliable. One should not expect integrity using a feature explicitly named: "
no-integrity".
This is the underlying red-flag that is implied in -i, no integrity: if you can run end to end with no crash/failure, you may well be okay, otherwise, you're simply not okay and must to go back to your previous baseline. The only time no integrity -i should be used is if some sort of bulk maintenance operation needs to be undertaken where you are prepared (read: have a backup) and willing to delete the database if the operation fails or a crash occurs. There are no exceptions or other backend means of recovering this situation.
In the event of a crash, when rolling forward AI notes, there is no indication which AI files were created during a no-integrity session, it is important to take note of this fact before doing so in production.
The subsequent roll forward or access to the roll forwarded database may then fail due to the fact that the notes generated to support physical backout (depending on each different database activity) would not be present so the update counters in the blocks would not match. This is because during a no-integrity session only those notes required for dynamic backout are recorded.
In the event of a crash, if those AI Blocks are processed to the target database, it’s possible that the target will then also be unrecoverable. If they have not, for the same reasons as above, it is possible that the target database will fail transition and also be unusable.
All the above having been said:
The no-integrity (-i) option should not be used with a database that has AI enabled.
It is unintentional that the no-integrity option is allowed on a database when after-imaging is enabled, as it will not always work even if the notes can be rolled forward successfully nor access to the database after they have been rolled forward successfully.
When for whatever reason no-integrity is being used, take a verified valid backup beforehand which you are prepared to use and disable AI before undertaking whatever no-integrity actions need to be carried out. Having AI enabled not only adds extra overhead while carrying out the no-integrity actions, but the resultant AI files created during the no-integrity session cannot be relied upon to restore the database (from roll forward or target transition methods).
"If Progress does not explicitly prohibit the usage/generation of AI files while database is started in no-integrity mode, should I stop doing it?"Absolutely. (refer above)
