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.sm...@oucs.ox.ac.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 >
