Situation
A table was truncated, need to recover the data. The tablespace has three files, one datafile is missing from the
backup and cannot be restored.
DUL Background
DUL can unload in several ways. It needs to know which blocks to read for a table. The default behaviour is to use the extent maps in the segment header, the alternative is to use a DUL built extent map. The extent maps are built with the DUL> scan database; command. To activate its use set USE_SCANNED_EXTENT_MAP=TRUE in the init.dul parameter file.
1. The first way is easiest and default. It produces errors for bad or missing blocks, giving an impression of the reliability/quality/completeness of the recovered data.
2. The second way must be used if the segment header does not match the data you want to unload or if it is missing or bad.
Standard DUL against the incomplete backup
Will work if the segment headers and extent map blocks are in the backup. You will miss the not restored datafile, errors will be produced for missing blocks.
DUL against the current production database
The segment headers and the dictionary no longer match the data blocks you want to unload. You need to use
DUL> scan database;
and USE_SCANNED_EXTENT_MAP=TRUE but you also need to make your own unload statement
as the dictionary no longer matches the data blocks.
DUL> unload table emp ( empno number , .... ) storage (segobjno <old data obj#>);
(You can find with using DUL> scan tables; or from the backup, or from block dumps, or a DUL describe table name when bootstrapped with the restored dictionary.
DUL against the mix of the restored database and the current file That is use the restored files available, dictionary and datafiles, and add current file for missing one)
The dictionary would be ok, the segment headers can be ok, depending in which file they live. You do not need the hand crafted statement as the dictionary is ok.
Morale of the Story
Just think about where DUL gets it information from, and if that is correct yes or no.