We are evaluating the potential usefulness of TSM deduplication on our
Version 6 TSM servers. The servers run under zSeries Linux and are
currently at the 6.2.2.0 level. We would not start using deduplication
without upgrading to 6.2.4.0 or higher.

Parts of our workload, such as database backups sent to the servers using
the TSM API, are clearly good candidates for deduplication. Other parts
of the workload, such as large collections of medical images, are
clearly poor candidates. However, there are two major groups of files we
are not sure about.

Most of our Oracle servers regularly write Oracle exports to local disk.
Each set of exports is subsequently backed up using the backup/archive
client. Are exports of a given database done on different days likely to
have significant numbers of matching blocks?

All of our SQL Server hosts perform daily dumps (as our DBAs call them)
or backups (as the vendor now prefers to call them) of database contents
to local disk files. The output files are subsequently backed up using
the backup/archive client. Currently, the database contents are
compressed in most cases. If we could persuade the DBAs to give up the
compression, would dumps of a given database done on different days be
likely to have significant numbers of matching blocks?

Thomas Denier
Thomas Jefferson University Hospital