Karel, >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.
You don't enable dedupe on the deviceclass level but on the storagepool level so a DB backup to a device class that is also used for a deduded storagepool is no problem. The dedupdev streams the DB backup in such a way that devices such as the IBM Protectier can store them using a smaller footprint than without this dedupdev switch enabled. Regards, Stefan On Wed, Jun 5, 2013 at 3:27 PM, Allen S. Rout <[email protected]> wrote: > 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 >
