Dedup issue on only one DB?

[david_stabler]

I have a single database, and not one you might think, that won't client-side dedup like it should. After a full happens, I send another, and the full transmission happens again. I'll freely admit the DB is on the large side, but could that be the factor? All the other databases on this SQL server are deduping just fine!

This log is from the most recent full backup that was attempted.

Type: SQL Server
Action: Legacy Backup
Components: [redacted DB name, 28 characters long]
Status: Successful

Total SQL backups selected: 1
Total SQL backups attempted: 1
Total SQL backups completed: 1
Total SQL backups excluded: 0
Total SQL backups inactivated: 0
Total SQL backups deduplicated: 1

Throughput rate: 25,891.50 Kb/Sec
Total bytes inspected: 664,055,230,336
Total bytes transferred: 664,055,230,336
Total LanFree bytes transferred: 0
Total bytes before deduplication: 23,936
Total bytes after deduplication: 23,936
Data compressed by: 0%
Deduplication reduction: 0.00%
Total data reduction ratio: 0.00%
Elapsed processing time: 25,046.49 Secs

Any guesses?

 

[rowl]

There is a setting CLIENTDEDUPTXNLIMIT which I read defaults to 50GB. I suspect you are running up against that.

The CLIENTDEDUPTXNLIMIT option specifies the maximum size of a transaction when client-side deduplicated data is backed up or archived.

You may be able to work around this by backing up the DB with multiple streams so that each stream sends less than the maximum.

-Rowl

 

[david_stabler]

I used SETOPT to update the option file (didn't work), then just restarted TSM. After I did, the next backup came in just fine with a very nice dedup rate (strangely, after doing a few fulls in a row, I got this result:

Total bytes before deduplication: 658,224,118,656
Total bytes after deduplication: 28,760,376,005
Data compressed by: 0%
Deduplication reduction: 95.64%
Total data reduction ratio: 95.64%
Elapsed processing time: 16,363.29 Secs

Much Better! Thanks!

)