About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review your options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.
Hi. The db2dart message is confusing and I believe not the right one to be displayed. I will look to update this in a future release to match what I had mentioned before.
Thanks.
I understand in the case of something goes wrong with business as usual and it is required to "revert" the data it is not going to be possible, because with db2dart or "/dev/null" it was improver way of handling backups. By the way I only use backup to "/dev/null" when I move data from production to test machines. I never ever take shortcuts when we are dealing with production. Some people must smarther then me have figure it out what should be proper procedure to not lose data and I always follow it.
Neverless the db2dart command like I understand it, it is not warning of potential data loss if there is a need to revert transactions (like take restore of full offline backup + rollforward logs), but it is warning to DATA INTEGRITY in existing database and warning for REFERENTIAL INTEGRITY of data. Like I understand "referential integrity" is foreign keys integritiy between two tables of data.
Yes, as a reminder that by-passing a database backup when one is being asked for can result in data loss, if anything were to go wrong with the database.
Correct command is:
db2dart <dbname> /CHST /WHAT DBBP OFF
Command returns:
The requested DB2DART processing has completed successfully!
But it returns very scary warning:
IMPORTANT:
After resetting the database backup pending state, IBM no longer
guarantees data integrity or the referential integrity of the data.
To ensure the referential integrity of the data, all user tables
should be exported, the database dropped and recreated and all
user tables imported back into the new database.
Yes, this is correct. We recommend to always have a database backup as a base for any database changing to recoverable. For those who want to by-pass this recommendation, the db2dart mechanism can be used.
You can already do this with:
db2dart <dbname> /CHST /WHAT /DBBP OFF
This will provide a better customer experience.