ISM issue

jrenaut

2014-02-27 14:48:02 UTC

Post by Malc P
Afternoon!
We're using ISM here to do imported restores in order to copy database instances from one server to another using onbar backup to disk/filesystem, and getting an issue exactly the same as in the presentation D13 at the 2010 Kansas IIUG Conference as shown in
http://presentations.oninit.com/public/2010IIUG/D13-Vega-IDS_Backup_and_Restore_--_New_Features_Tips_and_Insights.pdf
The bit I'm referring to is from slides 44 & 45 regarding the message "scanner: the following save sets continue on another volume:" exactly as described in the presentation, but the slide just mentions "Look in Info Center for complete info
- problem description, prevention, and workarounds" but I don't know which info centre to look in! Nothing on the highly efficient IBM/Informix website of course... could anyonepoint me in the right direction, please?
We can normally recover cleanly but this has happened just now (and I think once before from long ago) and I'm tearing my hair out trying to get round it - I tried 'scanner -i -S <saveset id>' for that saveset but it doesn't help at all, the restore just craps out on one particular 'continued' saveset...
Many thanks (in advance!)

Not sure if you got anything yet, but searching internally, I found the following information...which maybe what you are talking about?

If the ISM catalog needs to be re-created (catalog is lost or in an
imported restore situation), the command "ism_catalog -rectreate_from
<device>" is to be used. This command scans the files (savesets) on
the device to rebuild the catalog. However, internally it does not
use the unique filename to scan the files in the correct order.
Instead it relies implicitly on the file creation time and/or inode
number for the correct order. If the files have been copied in the
wrong order, then these criteria will not establish the correct order
and the command "ism_catalog -recreate_from <device>" will fail to
correctly rebuild the catalog entries for the
storage objects. This is only the case for storage objects larger than
2 GB that have been split into several files.

Workaround to be followed to avoid such a situation:
----------------------------------------------------

Always use a system utility like "tar" or "cpio" to copy or otherwise
archive all the savesets on a device of type file. Never copy single
files. Even though the device is of type file, it is to be treated
like a tape device. Copying single files by separate commands is
equivalent to to cutting a tape to pieces and then putting the pieces
together again in a different order. As this will not work with a
tape, it will in general also not work with a device of type file.

Workaround if such a scenario has already happened:
---------------------------------------------------

Move the files of storage objects larger than 2 GB to give them
different names. The files can remain in the same directory. Simply
use a command like "mv <original_name> <new_name>". (Using the move
command "mv" avoids actual move of large data and instead only
manipulates the existing inode.) For each file create a symbolic link
using a command like "ln -s <original name> <new_name>". But create
these symbolic links in the correct order (as designated by the
filenames). These symbolic links will then have new inodes and
creation times in the correct order. After this run the command
"ism_catalog -recreate_from <device>", which will
then correctly scan the device based on the symbolic link names.

Jacques Renaut
IBM Informix Advanced Support
APD Team