>> On Thu, 26 Jan 2006 20:24:40 +0100, Dirk Kastens <[EMAIL PROTECTED]> said:
> That's interesting. I just made some tests on our new server. At first I
> defined three big dbvolumes (using raw logical volumes), each on a
> separate hdisk (AIX 5.3), and each being mirrored by TSM on another
> hdis
Hi,
Tab Trepagnier schrieb:
The bottom line is that I/O Wait time was cut in half. While expiration
still takes approximately the same time as on the old setup, the reduction
in I/O Wait time means the server has more cycles for other work. So even
with a heavy workload, the server still prov
Lloyd,
My experience matches yours.
TSM 5.1.10.0 on AIX 5.2 on 2-way 6H1.
For the last several years we've implemented our DB vols on individual
disks, relying on TSM mirroring. The disks were 18 GB SCSI disks which
each reported 50 MB/s streaming write performance on the outer edge. We
define
cc
<[EMAIL PROTECTED]
.EDU> Subject
Re: DB & LOG Volume layout - new
01/24/2006 05:01
PM
Please respond to
&q
Paul
-Original Message-
From: ADSM: Dist Stor Manager on behalf of Richard Rhodes
Sent: Tue 1/24/06 18:26
To: ADSM-L@VM.MARIST.EDU
Cc:
Subject: Re: DB & LOG Volume layout - new
I don't think you will e
>> On Tue, 24 Jan 2006 15:26:27 -0500, Richard Rhodes <[EMAIL PROTECTED]> said:
> [ stripe ]
> So, there you have it . . . another way to set it up.
My neurotic tendencies have prevented me from striping that
aggressively. I envision one failed RAID taking out... well,
_everything_.
Mine is p
o
Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
Dist Stor cc
Manager"
<[EMAIL PROTECTED] Subject
.EDU> Re:
I've been watching this thread with interest, as some of the posts
contradicted what I thought I knew.
Using nmon, I've watched a couple of systems (AIX, TSM 5.2) running
expiration and DBbackups that have the DB vols set up according to the
"one volume per spindle" premise that appeared to have s
>> On Tue, 24 Jan 2006 15:43:57 +0100, Dirk Kastens <[EMAIL PROTECTED]> said:
> How do you get the occupancy of a database volume? With Q DBVOL I only
> see the available space (size of the formatted volume) and the allocated
> space (what is assigned to the database). In my case both are the same
Hi,
Allen S. Rout schrieb:
Paul's got it. Even with a non-new server, take a look at Q DBVOL
f=d. It'll be quite unusual to have more than one volume partially
full. If TSM assigned pages round-robin, then the usual case would be
(fairly) even byte occupancy per volume.
How do you get the
>> On Mon, 23 Jan 2006 17:16:06 -0500, Paul Zarnowski <[EMAIL PROTECTED]> said:
> At 06:56 AM 1/23/2006, Dirk Kastens wrote:
>> Paul Zarnowski schrieb:
>>> TSM does not do round-robin allocation
>>> of DB pages across it's volumes. It fills up one, then works on the
>>> next.
>> Are you shure? I
At 06:56 AM 1/23/2006, Dirk Kastens wrote:
Paul Zarnowski schrieb:
TSM does not do round-robin allocation
of DB pages across it's volumes. It fills up one, then works on the
next.
Are you shure? I think this only applies to log volumes.
That's the way it was explained to me years ago. Easy
Hi,
Paul Zarnowski schrieb:
TSM does not do round-robin allocation
of DB pages across it's volumes. It fills up one, then works on the
next.
Are you shure? I think this only applies to log volumes.
--
Viele Gruesse,
Dirk Kastens
Universitaet Osnabrueck, Rechenzentrum (Computer Center)
Albre
anager [mailto:[EMAIL PROTECTED] On Behalf Of Allen S.
Rout
Sent: Saturday, January 21, 2006 10:19 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: DB & LOG Volume layout - new
>> On Fri, 20 Jan 2006 14:02:28 -0500, David Longo <[EMAIL PROTECTED]> said:
> I've just done a re
>> On Fri, 20 Jan 2006 14:02:28 -0500, David Longo <[EMAIL PROTECTED]> said:
> I've just done a reconfig of my DB and LOG volumes that flies in the
> face of conventional wisdom - but it works!
[...]
I think that most TSM admins tend to prefer as many ways to keep their
pants up as can be arran
This is what it buys you:
1. I/O is better spread across multiple drive heads. Not so
important for writes, if you have a good-sized write-cache, but
especially helpful for reads. TSM does not do round-robin allocation
of DB pages across it's volumes. It fills up one, then works on the
next.
Just curious, and playing a little devils advocate, but does it buy
anything to mirror over raid5? Wouldn't it be more efficient (processor
on the san, and storage) just to put volumes out there and let TSM
manage them? You would want to have the mirrored volumes on separate
physical drives (pref
On Jan 20, 2006, at 3:04 PM, Paul Zarnowski wrote:
Details: We have a rack which contains our TSM AIX server along with
a CISCO SAN Director. The rack has 4 power circuits. All equipment
had dual power supplies, however - due to a human oversight - two of
the RIO drawers had their redundant p
Phillip raises a valid point, which I can reinforce. We also have
configured our TSM DB and LOG volumes on IBM FAStT (900s), using
RAID5 LUNs. We mirror pairs of them using TSM mirroring. We
recently had a convoluted situation that caused our server to crash,
and it would not come up due to a c
I believe there is still a reason to mirror at the TSM level. If you mirror
at the hardware level only and TSM writes a corrupt entry to the DB or log,
you are hosed since the hardware mirror will write it to both copies. If
TSM is doing the mirror, it can see that it had a problem writing to one
20 matches
Mail list logo
