Subject: | |
From: | |
Reply To: | |
Date: | Mon, 27 Nov 1995 12:01:04 -0800 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
My organization belongs to a consortium that is developing a very large MS
Windows client - SQL RDBMS server system to run on the following RDBMS
products:
HP Allbase under the HP MPE OS
Oracle
DEC's RDB
Microsoft's SQL Server
The complete database will probably have around 500 tables, and at the largest
member organization will probably be used by as many as 400 concurrent users.
Transaction rates will be especially high during student registration periods
as about 75 of those concurrent users are students registering via a touch-tone
telephone interface, continuously, all day long. Each update transaction can
involve "many" tables (10? 20?).
The people responsible for the high-level design of this new system felt that
native SQL database locking strategies would be too complex to implement for
"many"-table update transactions, and wouldn't scale well to offer decent
performance under peak loads. As an alternative they have come up with an RPC
(Remote Procedure Call) logical lock server, where a special lock request is
created for each type of update transaction.
If you have experience with large scale, high transaction, interactive SQL
databases, I'd like to know which locking strategies you chose (i.e. SELECT
FOR UPDATE across a terminal read, SELECT FOR UPDATE re-read after a terminal
read, etc, or a non-native alternative) and how well you feel they perform.
The ideal strategies should be compatible with both an interactive human at a
keyboard, as well as the occasional long-running batch process.
PS: I've redirected followups to comp.sys.hp.mpe since I'm most interested to
hear from HP Allbase users since that's what we'll be implementing on here.
--
Mark Bixby E-mail: [log in to unmask]
Coast Community College Dist. Web: http://www.cccd.edu/~markb/
District Information Services 1370 Adams Ave., Costa Mesa, CA, USA 92626-5429
Technical Support +1 714 432-5865 x7064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)
|
|
|