Thanks Ian, that's good data.
I can quickly add to that a 33GB db export file of a mixed data TSM 5.5
server grew to 55GB on 6.2.3 before dedupe started.
After it deduped 30TB of data the db grew to 205GB in size.
70% space saved due to dedupe btw ..whoohoo!! :-)
On Thu, Nov 3, 2011 at 7:01 PM, Ian Smith <ian.smith AT oucs.ox.ac DOT uk>
wrote:
> On 18/10/11 16:06, Allen S. Rout wrote:
>
>>
>> That's fantastic. Do you chance to recall a first approximation of what
>> your DB sizes were when you left V5?
>>
>> - Allen S. Rout
>>
> Catching up with the list so apologies for being late on this thread ...
>
> We ran server-to-server migrations from v5.5 to 6.1 October last year
> and I've listed the stats we gathered at the time below. The extracted
> figure was the one reported by the extractdb function - the script
> reports at the end something like:
> ANR1389I EXTRACTDB: Wrote xxxx bytes
> This extracted figure was very much lower than the figure we got from a
> quick 'total used pages x 4k' calculation at v5.5 - indicating either a
> significant amount of empty space / fragmentation in the old DB - or
> just a lot of duplicate records/data.
>
> The V6 figure is (if memory serves) the result of the calculation from
> 'q db f=d' of the Total Used Pages on first run up after migration to
> v6 times 16k (page size)
>
> Server Instance
>
>
>
> Extracted (GB)
>
>
>
> V6 DB (GB)
>
> Archive server
>
>
>
> 5.96
>
>
>
> 9.9
>
> Desktop backup 1
>
>
>
> 109.18
>
>
>
> 172.03
>
> Server backup 1
>
>
>
> 114.24
>
>
>
> 197.70
>
> Desktop backup 2
>
>
>
> 104.77
>
>
>
> 165.66
>
> Server backup 2
>
>
>
> 131.03
>
>
>
> 229.22
>
> Desktop backup 3
>
>
>
> 105.25
>
>
>
> 159.91
>
> Server backup 3
>
>
>
> 99.37
>
>
>
> 173.47
>
> Desktop backup 4
>
>
>
> 76.02
>
>
>
> 118
>
> Server backup 4
>
>
>
> 29.38
>
>
>
> 47.3438
>
>
> Hopefully the table above will display properly. There was a mix of
> client data from several versions within each server instance, but with
> a generally 'older' client profile in the Archive server and instances
> #1 with some of this data originating from version 2 clients. Instances
> #4 on the other hand held data only from version 5 clients.
>
> To briefly characterise the data, it was derived from a mix of windows,
> linux, osx, solaris and netware clients (in decreasing numbers
> respectively - windows clients make up around 55% of our client base).
> The desktop backups contained only a few System Object / State type
> backups - these were the only backup groups we support ( i.e. no
> backupsets ). Server backups - consisted of significantly more System
> Objects, plus a handful of backups from SQL-DB and Exchange-DB clients.
> I don't know how, or if, any of the above had any bearing on the sizings
> we saw.
>
> Finally, for validation, we ran a bunch of select count(*) on the v5.5
> and v6.1 dbs , ran them though some sed | grep | awk 'thing' to cleanse
> and standardise the output and then ran diff. We also did some random
> content queries as well. All was well and we were happy.
>
> Finally finally, I accord with the comments on resourcing your TSM DB
> instances - the figures reported in the best practices only ever seem to
> move in one direction ...
>
> HTH
> Ian Smith
> Oxford University Computing Services.
> England
>
|
