HP3000-L Archives

November 1999, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Sun, 28 Nov 1999 10:56:44 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
Mark Wilkinson wrote:
>
> Hi Everyone,
>
> I know this may sound a little "obvious" but has anyone actually
> benchmarkedIMAGE/SQL against any other databases and if so what were
> the results?
>
> In other words : I hear a lot of people say that IMAGE is faster than
> other databases but have yet to see it proved.

I can't give an apples-to-apples comparison, but we have some "new"
software runniing on HPUX 9000 K570 (4-way) and our legacy system on
a uniprocessor 3000 969/120.  We do student registration, etc, on the
legacy system.  The "new" stuff does financial aid and student A/R.
Currently we synchronize data by running data extraction programs that
run periodically (hourly during production hours) and export their
results over via FTP to be loaded into the Oracle system.  To keep
things relatively accurate, we "reload" student demographics 3 times
a day, but update enrollment/fee assessment hourly.  If we do both in
the same cycle, it takes about 15 minutes (about 8000 students).

In contrast, there is a student 'billing' program on the Oracle side
that includes course fees and any other outstanding A/R.  We ran it
earlier this week, and it ran nearly two hours just to print the bills,
no updates, not to mention the two times it bombed out due to exceeding
our rollback segment space (because of the hourly updates coming from
legacy changing data).  Essentially two seconds per student, while the
IMAGE/legacy side can fully export complete fee assessment,
demographics, and related A/R information and do the Oracle side updates
in 15 minutes or less.

Quite a comparison, considering our 9000, if it were a 3000, would be
a 989/400, and has a not-yet-available dual fiber-channel connected Nike
30 disk array hosting the data.  I'm sure it would be much slower on
MPE-compatible hardware.

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2