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
