ADSM-L

Re: [ADSM-L] vtl versus file systems for pirmary pool

2011-11-03 14:10:36
Subject: Re: [ADSM-L] vtl versus file systems for pirmary pool
From: Ian Smith <ian.smith AT OUCS.OX.AC DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 3 Nov 2011 18:01:26 +0000
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

<Prev in Thread] Current Thread [Next in Thread>