Some info can be found in the DP Installation Guide, read this first.
The following document will enrich the given information.
Introduction:
Let´s take the file names of the backed up files to explain the difference in the pre DP 8 and the post DP 8 IDB.
In DP 7 and older, the names of the files that have been backed up are stored in the fnames.dat file (and extensions).
In DP 8 and later, this information is stored in the new DCBF files (version 2).
What happens during an update from DP 6/7 to DP 8/9?
When updating DP 6/7 to DP 8/9, these file names are not converted from the old IDB files to the new DCBF files of version 2.
The DP code is able to read these old files, although the old database engine is not installed anymore.
So we have a fully functional IDB after the update and detail file browsing for restore is possible.
What will happen after the update?
New media will get a DCBF file of version 2.
Old media that is appended will have 2 DCBF files, an old one of version 1 and a new one of version 2.
Old media that is full will expire over the time and the DCBF files that belong to it will be deleted by DailyMaintenance.
Old media that is permanently protected will not expire and keep the old DCBF file and will depend on the old fnames.dat file for restore file browsing.
What is the recommended way to deal with this?
In case no permanent protected media is used, it would be possible to wait until all old media is expired.
After the old media is expired, the DCBF files are gone anyway and after the last media is expired,
the fnames.dat file (and it´s friends) are not needed anymore and can moved to a safe location first and deleted after some time.
See the last part of "How can a DCBF file migration be done?" on how to remove them.
In case permanent protected media (or media that is protected over a long period of time) is used, it is recommended to do a DCBF file migration.
How to determine the current status?
The following commands give an overview and show what media is pending migration:
# omnimigrate.pl -report_old_catalog
Old Detail Catalog Binary Files size:
DCBF ( 268 files): 4573 MB
Old filename data files: 6373 MB
Total: 10947 MB
# omnimigrate.pl -report_old_catalog media
Media that require old Detail Catalog Binary Files:
Medium ID Protected Until
================================================================================
c0a83220:4d3e9a36:55eb:0029 Permanently
c0a87804:4271e7b1:1550:0003 Permanently
...
c0a83206:54899f86:20aa:0009 2016-1-8 2:50:1
Total number of media: 268
How can a DCBF file migration be done?
omnimigrate.pl -start_catalog_migration will start the migration.
It can be monitored by omnimigrate.pl -report_catalog_migration_progress
After the migration of the DCBF files, you can use the following command to check for any remaining DCBF files:
# omnimigrate.pl -report_old_catalog
Old Detail Catalog Binary Files size:
DCBF ( 0 files): 0 MB
Old filename data files: 6373 MB
Total: 6373 MB
Once we see 0 old DCBF files, omnimigrate.pl -remove_old_catalog can be used to remove the old filename data files.
The global parameter SupportOldDCBF=0 must be set to prevent that the DBSM process attempts to read the old filenames data files (even if they do not exist anymore).
Not setting this parameter can lead to delays during restore browsing activity.
Troubleshooting
Logs can be found in the default DP log directory. They are named omnimigrate*.log
In case of trouble while conversion of a specific DCBF file, the migration can be run only for this DCBF file in debug mode.
Example syntax: omnimm -upgrade_dcbf c0a83220:4d3e9a36:55eb:0029 -debug 1-500 mig.txt