Dave,

Thanks for the suggestions.  I do have a test system so I will look into
trying turning off the JFS2 log.  You provided enough hints that I should
be able to figure it out.
I don't think the LVDS adapter has write cache.

Thanks again.

Tab





Dave Canan <ddcanan AT ATTGLOBAL DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/21/2005 08:24 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Why do database restores take so long?






         One suggestion I would make here. For a restore such as this,  I
have seen performance improvements if you temporarily disable the jfslog
(or in this case, the jfs2log) for the duration of the restore. This has
the effect of not writing the data to the jfs log before it is written to
the database, so it is in effect like a raw filesystem write. If you want
specific procedures I can send them to you, but it is basically
accomplished by unmounting the filesystem and the remounting it with the
options of rw and nointegrity. After the resore is finished, you would
then
remount the filesystem with just the rw option so that the jfslog is once
again used.
         I don't know if you want to try this or not, because restores of
TSM databases are not generally something you can "test" unless you have a
test environment. But you might want to keep this in mind if you ever need
to this again.
         There was 1 other thing I wanted to ask. I was trying to find out
whether or not the IBM PCI card (part number 09P2544) had cache on it or
not. I couldn't locate specifications on it, but if it doesn't, a card on
it that had embedded cache would help this situation as well.

At 05:16 PM 1/21/2005 -0600, you wrote:
>Dave,
>
>Our database disk system consists of four 18 GB SCSI disks in a split
>(dual-bus) disk pod connected to a dual-channel LVDS adapter.  The
>Recovery Log in on another pair of such disks.  One set of disks on one
>bus holds the primary database and log volumes; two DB and one log disk.
>Each DB/log volume is mirrored to an identical volume/disk on the other
>bus.  So the mirror read/writes occur on independent buses downstream of
>the PCI slot.  The database consists of four volumes per disk of about 4
>GB each.  All database and log volumes are defined on JFS2 file systems.
>The LVDS adapter is the IBM 64-bit dual-channel adapter called "PCI DUAL
>CHANNEL ULTRA3 SCSI ADAPTER", Part Number 09P2544.
>The disks are "16 Bit LVD SCSI Disk Drive (18200 MB)", Machine Type and
>Model = ST318305LC which I *think* is 15K rpm.
>The server is a 2-way 6H1 64-bit 600 MHz with 4 GB RAM, tuned for just
>about zero paging. TSM DB buffer pool is 1 GB.
>Like I said, when backing up to our HP 4/40 DLT via HVD SCSI, topas
>reports a consistent 11 MB/s, such that a typical backup takes just about
>45-50 minutes including the tape mount.
>The restore took slightly over three hours; and the 3:1 ratio is not out
>of line based on other responses.
>
>Thanks.
>
>Tab
>
>
>
>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/20/2005
>11:27:02 PM:
>
> > Can you provide a little more information? I would like to know:
> >
> >          1. What kind of disk subsystem are you restoring the data to?
> >          2. How many disks, and what kind of disks are they?
> >          3. How is the database laid out database volume wise?
> >          4. Does the disk have write cache behind it?
> >          5.  What kind of controller do you have for the disk
subsystem?
> >
> > At 07:23 PM 1/20/2005 -0600, you wrote:
> > >TSM 5.1.9.0 on AIX 5.2 ML4; DLT8000 media on SCSI
> > >
> > >Why do TSM database restores take so much longer than the backups?
Our
> > >system backs up our 24 GB database to DLT in about 50 minutes with a
> > >sustained rate of 11 MB/s reported by topas.
> > >
> > >Tonight I'm performing a database restore.  It is occurring at an
>average
> > >rate of less than 1 MB/s with rare peaks no higher than 6 MBs.  At
>times
> > >the rate is as low as 300 KB/s.
> > >
> > >I realize the system is writing data to disk rather than reading so
its
> > >not doing as much caching, but these are new disks and I've seen them
> > >stream write at better than 25 MB/s on the inner edge and as fast as
50
> > >MB/s on the outer edge.  So I doubt the disk is the problem.
> > >
> > >This restore has been running for almost 2-1/2 hours now and is about
>90%
> > >complete.
> > >
> > >This is the fourth or fifth time I've restored the TSM database in
the
> > >seven years I've operated the system.  I have never seen database
>restores
> > >exceed 1/3 the backup rate - sustained - on two different servers,
>three
> > >different media and going back to ADSM 3.1.
> > >
> > >Just curious.
> > >
> > >Tab Trepagnier
> > >TSM Administrator
> > >Laitram, L.L.C.
> >
> > Dave Canan
> > TSM Performance
> > IBM Advanced Technical Support
> > ddcanan AT us.ibm DOT com

Dave Canan
TSM Performance
IBM Advanced Technical Support
ddcanan AT us.ibm DOT com