Database disk image is malformed refers to physical corruption: (invalid 0s and 1s on the disk) But what’s happening now is “logical” corruption: data is correctly written but is wrong. Did you take a back-up before making these changes? Because changing the uniqueness constraint allowed logical corruption to be written.
If we add VolumeID to the BlockHashSize index, or we just drop the index entirely, then backups seem to finish with no errors.
It finished “with no errors” because the protection against writing erroneous, logically corrupt data was removed.
Here’s why adding the volumeid allowed invalid, corrupt data to be written.
Example:
CREATE TABLE a ( pk int, ak int, val text );
CREATE UNIQUE INDEX a_indx on a (pk);
INSERT INTO a (pk, ak, val) values (1, 2, 'abcdef');
RESULT:
|pk|ak|val|
|1|2|abcdef|
INSERT ITO a (pk, ak, val) values (1,4,'ghij');
-- Unique key constraint on PK column, hence: blocked.
DROP INDEX a_indx;
CREATE UNIQUE INDEX a_indx on a (pk, ak);
INSERT ITO a (pk, ak, val) values (1,4,'ghij');
RESULT:
|pk|ak|val|
|1|2|abcdef|
|1|4|ghij|
By adding the second condition to the uniqueness a compound unique key constraint was created. To violate the constraint BOTH values need to be unique across the entire table. This modified index does not protect against repetaedly writing pk = 1. So, in the simple demo above we couldn’t’ve written that, and ak = 2 a second time. However we can create pk=1 and ak=4 which is (for the purposes of argument) logically corrupt.
Could you provide the exact error messages and the exact output of the pragma integrity_check; as well as the exact drop and create statements?
Adding and removing the unique key constraint index will not eliminate the issue of the system trying to insert a row that violates the index. (However: removing the index and allowing the system to proceed will have dire consequences. Changing the index uniqueness condition allowed)