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