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 <asr AT ufl DOT edu> 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
>