This is almost certainly the 32-bit signed integer problem. Unless ADSM is
specifically written for the new 64-bit file system at AIX 4.2.1 or later
(which I doubt), then 2GB is the largest database size possible. The fault
is that when doing an lseek (this is a AIX/Unix low level function to
position the current pointer in a file), the offset is a 32 bit signed
integer, whose limits are -2GB through +2GB-1.
Peter Gathercole.
Trevor Foley wrote:
> Hi,
>
> I'll just add a warning here after a bad experience over this past
> weekend. We've been running for 2GB database volumes for quite a while
> now. Over the weekend we did some reconfiguration on one of our ADSM
> servers that involved blowing away the ADSM database. When we recreated
> it, we decided to go for 4GB volumes. All well and good in theory, and
> with dsmfmt. But the dsmserv format command failed. I can't remember the
> exact message now but part of it was a very big negative number which
> suggested that something had overflowed. We've logged a call with IBM
> but haven't heard anything back as yet.
>
> Trevor
>
> > -----Original Message-----
> > From: Dwight Cook [SMTP:decook AT AMOCO DOT COM]
> > Sent: Tuesday, July 28, 1998 11:51 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: database volumes
> >
> > With volumes in general under adsm you'll notice ADSM spreads its
> > work
> > out across what is defined to it...
> > If we flash back to 4.5GB disks and a 2GB file limit, one would
> > have
> > likely defined 2-2GB files and 1-0.5GB file per physical device.
> > ADSM, in an attempt to spread out work, would have one task for
> > each
> > defined volume and a dispatching task to load up their queues.
> > What
> > was seen was, if you had 9 physical volumes that each contained 3
> > adsm
> > defined volumes and you had 6 tasks performing I/O there was a
> > good
> > chance that the 6 tasks would be using only 2 physical devices
> > while
> > the other 7 physical devices sat idle.
> >
> > Now that the 2 GB file limit no longer exists under AIX and even
> > with
> > the disks at 9.1GB (soon to be 18GB) we still stick to one
> > logical
> > adsm volume per physical volume and let adsm handle the load
> > balancing
> > from there...
> >
> > A typical example would be 2 ssa controllers and 4 drawers of
> > 4.5GB
> > drives. Each controller loop has one drawer.
> > SSA card 1
> > A1(1) DB
> > A1(2-15) diskpool
> > A1(16) which is A2(1) DB
> > B1(1) DB
> > B1(2-15) diskpool
> > B1(16) aka B2(1) LOG
> > SSA card 2
> > same as card one but are all the adsm mirrors of the DB & LOG
> >
> > Then if one of the SSA cards fail (which I don't believe I've
> > ever
> > seen in the last two years) you still have 1/2 your diskpool and
> > a
> > complete DB & LOG environment
> >
> > **** personally I would not put 6 logical DB volumes on one
> > physical
> > volume BECAUSE then adsm will work on spreading the load out
> > across
> > those 6 volumes all for nothing because they are the same
> > physical
> > device...
> >
> >
> > ______________________________ Reply Separator
> > _________________________________
> > Subject: database volumes
> > Author: EXBrown (EXBrown AT snopud DOT com) at unix,mime
> > Date: 7/27/98 4:54 PM
> >
> >
> > In our current configuration we have a single large Logical
> > Volume spread over 10x4.5GB SSA drives. We have 8x500MB database
> > volumes
> > for our ADSM database. We are upgrading ADSM and moving to a new
> > server.
> > We have 8x9.1GB SSA drives. We have decided to create a logical volume
> > on
> > each disk so that we can easily manage the location of our storage
> > volumes in relation to the physical disks.
> >
> > My question is this....
> >
> > If I have 6x1GB database volumes, would it be more prudent to
> > (1) Dedicate 2 physical drives to DBvolumes and place all six of the
> > DBvolumes on a single drive. Then use ADSM to mirror them on a
> > different drive? Or (2) should I spread DBvolumes around onto all of
> > the
> > drives in the Volume Group?
> >
> > Basically, what is the trade off by spreading the DBvolumes
> > around on all of the disks, rather then containing them on 2 disks,
> > one
> > for the DB and one for the mirror.
> >
> >
> >
> > Ed Brown
|
