DP 8.x DCBF Slasher

Hi,

when upgrading to 8.x from an older installation (in my case, 6.21 that was formerly upgraded from 6.00 via 6.11 and moved from W2003R2 to W2008R2 in the process), you might end up with the following dilemma:

• Catalog migration will not move converted DCBFs from the db40 to the db80 hierarchy, but leave them in the DCBF directories below db40;
• You can manually copy them to the new hierarchy and omnidbutil -remap_dcdir as usual, but new DCBF files might be created in the db40 hierarchy even after you just emptied it;
• Removing the old db40 DCBF directories will fail without (GUI) or with useless empty error messages (CLI).

According to This great article on Daniels blog the ultimate reason for this is that the new dcbf_directory fields in the PostgreSQL IDB (referring to db80) are encoding backslashes in Windows path names as slashes, while the old ones (referring to db40) use backslashes (properly quoted by other backslashes). While both are syntactically Ok, the statement to remove a DCBF dir apparently doesn't manage to hit the quoted-backslash variant and consequently fails to delete the entries.

The blog article describes a way to fix this: Dump the IDB to a text representation, edit the path names to replace the quoted backslashes with single slashes, restore the IDB from the text. I found that I don't like this path, given editing a 136MB text file on Windows with unclear semantics for line breaks and character set encoding was something I found too hot to attempt in the middle of a customer upgrade. Instead, I fixed the path names using an ad-hoc SQL query. Here's how:

First, find out the exact DCBF path names and their seq_id numbers using this query:

select db_uuid, seq_id, dcbf_directory from dp_catalog_dcbf_directory where dcbf_directory like '%db40%';

 Save that query to a file, let's call it dcbf_slasher.sql, and run the query as such:

omnidbutil –run_script dcbf_slasher.sql –detail

 From the output, determine the dcbf_directory instances still using backslashes and their corresponding sequence IDs, then add the necessary update statements to dcbf_slasher.sql. In my case, the result looked like this:

select db_uuid, seq_id, dcbf_directory from dp_catalog_dcbf_directory where dcbf_directory like '%db40%';

update dp_catalog_dcbf_directory set dcbf_directory = 'C:/Program Files/OmniBack/db40/dcbf' where seq_id = 2001;
update dp_catalog_dcbf_directory set dcbf_directory = 'C:/Program Files/OmniBack/db40/dcbf2' where seq_id = 2002;
update dp_catalog_dcbf_directory set dcbf_directory = 'C:/Program Files/OmniBack/db40/dcbf3' where seq_id = 2003;
update dp_catalog_dcbf_directory set dcbf_directory = 'C:/Program Files/OmniBack/db40/dcbf4' where seq_id = 2004;

select db_uuid, seq_id, dcbf_directory from dp_catalog_dcbf_directory where dcbf_directory like '%db40%';

 Your directories and/or IDs will very likely be different, but the way to adapt the updates should be obvious. I'm also not a DBA and the update might well be written in a simple, generic way instead of my micro managed "editing by SQL" statements, but I wanted something fool-proof (for me) instead of a fancy disaster. Feel free to improve on this if you know the magic. The final line is there to immediately show the success of the updates, if any.

Running that again through omnidbutil worked correctly for me on the first attempt, I could remove the old DCBF directories through the GUI and now everything lives in db80, and only there, as expected.

Obviously, only attempt open heart SQL surgery on the IDB if you know what you are doing, or how to deal with catastrophic failure. Don't blame me if you trash your IDB. Have a text dump of it at least, or better yet, a full IDB backup (ideally, both).

HTH,

Andre.