On 06/05/2013 02:10 AM, Karel Bos wrote:
> Hi,
>

> I think doc stated not to use dev=file shared=yes for TSM db backups.

This, I totally get.  And I also totally get why you wouldn't want to
use TSM dedupe on a FILE devclass from which you expect to do a DB restore.

They fall into the same class: "Storage that you can't access safely
without a running TSM server".    For a SHARED devclass, you need some
sort of hokey-pokey to determine who's messing with what files, and for
a TSM-deduped volume, the data simply isn't there.  (or rather, not
guaranteed to be there.  It could be over in some other file).

That's pretty clear as you walk through what the DB2 instance has to do
to restore that database;  you want simple (possibly multi-volume) DB2
backup files, sitting in a directory.   No testy negotiations with
possible other users of the dir, and no extent references to a dedupe
table. :)


> From memory it didn't specify why, but easy to setup dedicated file
> dev for tsm db backup only. DDM doesn't care anyways, it does dedup
> over all data stored in it.

I know;  and it seems that optimizing the file layout for dedupe
processing can only help.  That's why I'm wondering why it's recommended
against.

- Allen S. Rout