Our record was 260 GB client/user file space on a single 3590 tape!
(with hardware compression on the tape drive)
Now that the clients have set "compression on" and "compressalways no"
we only see 9.8 GB per 3590 tape (but 22 : 9.8GB tapes, client
compressed is a 1 TB oracle data base).
Below is our current library(s) tape status report
(the names have been removed for security, sigh)
2 environments are set collocate yes
1 environment is set collocate filespace
9 are set collocate no
So as seen below, if collocate yes were set to no we would have an
extra 350-ish scratch tapes and if the collocate file were set to no
we would have an extra 500-ish scratch tapes... our collocates are
costing us around 850 scratch tapes BUT adsm will still use them in a
crunch (remember volume selection rules), so waste might have been a
poor choice of words.
61 SCRATCH and 299 PRIVATE volumes of which 19 are filling, the rest are full.
8 SCRATCH and 628 PRIVATE volumes of which 27 are filling, the rest are full.
39 SCRATCH and 749 PRIVATE volumes of which 27 are filling, the rest are full.
31 SCRATCH and 312 PRIVATE volumes of which 21 are filling, the rest are full.
46 SCRATCH and 378 PRIVATE volumes of which 152 are filling, the rest are full.
81 SCRATCH and 742 PRIVATE volumes of which 32 are filling, the rest are full.
268 SCRATCH and 181 PRIVATE volumes of which 21 are filling, the rest are full.
182 SCRATCH and 75 PRIVATE volumes of which 21 are filling, the rest are full.
84 SCRATCH and 16 PRIVATE volumes of which 22 are filling, the rest are full.
289 SCRATCH and 605 PRIVATE volumes of which 22 are filling, the rest are full.
44 SCRATCH and 10 PRIVATE volumes of which 18 are filling, the rest are full.
26 SCRATCH and 677 PRIVATE volumes of which 523 are filling, the rest are full.
35 SCRATCH and 512 PRIVATE volumes of which 237 are filling, the rest are full.
______________________________ Reply Separator _________________________________
Subject: Betr.: Re: NT restore performance for small files
Author: Matthias.Hensel (Matthias.Hensel AT Schering DOT DE) at unix,mime
Date: 2/3/99 4:10 AM
Dwight,
wo do you achieve 73 GB per tape?
We are at ca. 8GB physical mb (using client compression) so that we
may have up to 24 GB on 3590.
concerning collocation file, I do not agree that you will waste
tapes.
Using your 73 GB/tape capacity ok, but seperating the NT server
into
filespaces of 10 GB and our experienced tape capacity the waste
would
(as I hope) be acceptable.
Am I right?
Matthias
____________________________ Antwort-Abtrennung
________________________________
Betreff: Re: NT restore performance for small files
Autor: ,Dwight Cook [SMTP:decook AT AMOCO DOT COM] bei BE2183
Datum: 02.02.99 23:09
COLLOCATION FILE would cure the problem (almost a waste of tapes)
COLLOCATION YES would still load up multiple tapes where with
active
and inactive versions, plus expired version dead space in the
tapes.
Say 100 GB server, 80% capacity => 80 GB, 50% changes weekly => 40
GB
and 25% changes monthly => 20 GB, and the other 25% changes yearly
20GB... at any give time after say a months running you might
expect
20GB + 20GB*2 + 40GB*4 => 220 GB of data, say at a 3/1 compression
ratio on 3590 tape that's 73 GB raw data,
that's 7.3 3590's for just that node...
So you could fire off multiple restore requests and let adsm manage
access to the resources.
been there, done that, it works...
but actually out of our 12 production aix adsm servers using 3494's
we
have 1 collocate file, 2 collocate yes, and the other 9 collocate
no
but those 9 adsm servers receive archives from big DB servers that
end
up just about performing collocation anyway... one client fills 20+
3590's a day. (what? you ask where I got my twitch from...)
______________________________ Reply Separator
_________________________________
Subject: Re: NT restore performance for small files
Author: Diana.Cline (Diana.Cline AT ROSSNUTRITION DOT COM) at unix,mime
Date: 2/2/99 2:14 PM
Yea, but what if you are using co-location. All these different threads
can't
use one tape! Right?
ADSM-L AT VM.MARIST DOT EDU on 02/02/99 03:10:40 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ RPDINET
To: ADSM-L AT VM.MARIST DOT EDU @ RPDINET
cc:
Subject: Re: NT restore performance for small files
Sure it provides an easy way to split restores...!
Now backups will run faster as a single thread (multiple concurrent
incrementals lock contend with each other to much) BUT with restore
processing... you can launch multiple concurrent dsmc restore
processes and specify the level of a file system or logical volume
(what ever platform your client is on) say with NT
dsmc restore g:\* -subdir=yes -replace=yes -pass=xxx
dsmc restore h:\* -subdir=yes -replace=yes -pass=xxx
with unix
dsmc restore /d001/* -subdir=yes -replace=yes -pass=xxx
dsmc restore /d002/* -subdir=yes -replace=yes -pass=xxx
if your file systems are so big you might need multiple concurrent
tasks with a single file system break it up with the adsm option
"VIRTUALMOUNTPOINT"
Or just piss off the bean counters and make them buy more servers
prior to them getting to a bazillion GB in size ;-)
later,
Dwight
______________________________ Reply Separator
_________________________________
Subject: Re: NT restore performance for small files
Author: fr.maes (fr.maes AT CGER DOT BE) at unix,mime
Date: 2/2/99 3:11 AM
Hello Matthias,
This is a very very good question !
Sorry but I have just the same kind of problems and no solution.
We are using an ADSM V3 MVS server and ADSM V3 NT, AIX and DEC-UX
clients.
Some NT servers are big lan servers with 80 to 100 GB of disk space.
We have also a restore transfer rate at 1.5 to 2GB / hour / process.
Our "big" lan servers are now connected via ATM. The restore transfer
speed
is increased at +/- 4GB / hour.
Max # of backup versions = 8
Max retention only version = 800 days
DB size = 51 GB (83% full)
I mean that the actual version of ADSM is not the perfect way to restore
big
NT filespaces (more than 20GB).
ADSM offers no easy way to split backup and restore of a "big" NT
filespace
thru multiple processes.
Will be better in a future release, comme d'habitude!
Courage.
Francis.
-----Message d'origine-----
De : Hensel, Matthias <Matthias.Hensel AT SCHERING DOT DE>
De : Hensel, Matthias <Matthias.Hensel AT SCHERING DOT DE>
A : ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
Date : lundi 1 fevr. 1999 17:36
Objet : NT restore performance for small files
> I would like to know how I can achieve acceptable restore times in
> case of disaster of an very big LAN server. We had great
>expectations
> to get better preformance when moving to V3 server/client because
>of
> better tape algorithms and FatPipes etc. Now when we had our first
> really big disaster we were kind of disillusioned when seeing the
>poor
> restore "speed".
>
> How can I handle it to get performance beyond 1.5 - 2 GB/h per
>session
> for LAN Server data? Having LAN servers up to 100 GB data
capacity,
>
> you can imagine with 3 to 4 sessions that we easily reach restore
> times of about 15 hours.
>
> Is this adequate to todays needs? Am I doing something wrong?
>
> I know that it is no problem to restore very big database files
>when
> tape drives are streaming, but what to do with the vast amounts of
> small files?
>
> Does it make sense to decrease the number of backup versions to
>keep,
> to get less space (due to inactive files) between two active files
>to
> be restored?
>
> Is it an idea to do an export node filedata=backupactive and
>reimport
> as a new node and then start the restore from this new node?
>
> What are you doing to keep performance up to date?
>
> Matthias
>
|
