| Title: | DEC Rdb against the World |
| Moderator: | HERON::GODFRIND |
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
I'm new to Sales Support (2 months) and my previous background (mainly
workstations and graphics) dosen't include much DB so pardon anything
stupid that I might say!
I have a customer (a national account) who has committed to placing
their employee retirement program (similar to our SAVE) on Oracle.
The database is large; I've been told it contains 180,000 rows, 4,500
columns, and 18 tables ( they also are a Fortune 50 company). Plans
are to run the application on either a 6420 or 6430, both of which
they already own.
The problem. Once a month (?) they run a series of batch programs that
do updates and generate reports (they are using a third party program -
other than Oracle for report generation. The name escapes me a the
moment but it is provided by Sequel Solutions). Current estimates show
that it will take about 170 hours to do this batch processing (the
breakdown is about 50 hours for update and 120 hours for report
generation) in a uniprocessor environment. This is totally unacceptable
to the customer. They want to get the total time down to around 48
hours - if they don't we may see our systems thrown out ( as ususal,
it's Oracles problem so Digital, you take the blame).
The customer attempted some benchmarks last week using 6420, 6430,
and 6440. The results were as can be expected based on Oracles
'support' of SMP (similar problems were noted elsewhere in this
conference) - not pretty.
We've also scratched the possibilty of using a VAXcluster for the
obvious reasons - no support for the Distributed Lock Manager, so
only one instance of the RDBMS on the cluster (as I understand it).
The customer has asked about the possibilty of backending Oracle on
a DECsystem 5800 and using SQL*NET to 'connect' front end
applications (written in COBOL) on the 64XX(s). This sounds like a
possibility since it places the heavier processing on a fast
uniprocessor. But, since I lack the background in DB I have a number
of questions.
Can SQL*NET be used as described above? (Also can anybody point me
to some information on this product?). If so:
1) Can SQL*NET be used over CI (they brought up the possibility of
using an HSC with the 5800) or does it have to use the Ethernet?
2) If using the Ethernet should DECnet or TCP/IP be used?
This project has been going on for at least two years and this is
already the second attempt at doing it (I don't know any of the
particulars of the first) so the odds of getting them to move to
Rdb/VMS (which supports VAXclusters and SMP) are slim to none. If
They can't get the run time down to at least 48 hours they will
most likley move the application to their 3090 spelling the beginning
of the end of our presence in their corporate arena.
Any suggestions that you might be able to give me would be appreciated.
Ron Dlugosz
Sales Support/Pittsburgh
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 672.1 | Why not RDB? | KYOA::KOCH | My brother did not lose the election | Wed Jun 20 1990 16:01 | 7 |
Are they totally against doing this with RDB? Why not benchmark it with RDB and show them how much better it is? It this impratical? Given it is a national account, you should be able to dig up the support to do this... Ted Sales Support in NJ | |||||
| 672.2 | Something doesn't sound right to me | WIBBIN::NOYCE | Bill Noyce, FORTRAN/PARALLEL | Wed Jun 20 1990 22:11 | 14 |
Just curious: if they move it to the 3090, would they still use
Oracle, or would they use an IBM database manager? If they're willing
to consider using IBM software, they should be willing to consider
using DEC software (which is better).
I couldn't tell from your note if the 120 hours is to massage the
data into a report after fetching it from the database, or if most
of that time is spent calling Oracle. If the former, perhaps you
could do the extraction into a bunch of temporary files, and then
generate different sections of the report in parallel. If the latter,
I would expect that even Oracle should be able to provide
multiprocessor read-only access to a database, though you may want
to keep doing the updates in a single process. Isn't there any
way you can tell the database system you're doing read-only activity?
| |||||
| 672.3 | Some more info... | PTOSS4::DLUGOSZ | Open foot, Insert Mouth | Thu Jun 21 1990 17:16 | 47 |
re: .1
Moving to RDB has been brought up with the customer. The major drawback
is that this is their second attempt at this project. The first failed;
I don't have any of the details, and the second is about to fail. They
have been working on this now for at least two years. The reason that
they don't want to hear about RDB right now is that if this isn't
working be September ... they probably won't either.
Agreed that RDB would definitly be the way to go in order to take
advantage of of SMP and/or VAXcluster. Does anybody have any additional
incentives and/or any estimates of the amount of work involved in
such a conversion (remember my experience with RDB is minimal and
my experience with Oracle is NULL).
re: .2
They plan to use Oracle (although nobody seems to know if it will
work or not and if it does how well) on the 3090. They are not
receptive to a lengthy conversion for the reasons stated above.
They're looking more seriously at using a DECsystem as the backend
for the Oracle DB and placing the frontend applications on the VAX.
The choice is between a 5000/200 and a 5800. They are leaning towards
the 5800 because of their investment in RA90s.
There is a utility company based in San Francisco that is using
5000/200s and SQL*NET over TCP/IP to implement this strategy. They
seem to be happy with it (according to an ouside consultant who is
providing consulting/tunning for the account). We are tyring to
contact them for a first hand 'opinion' through their sales rep.
Accoring to the consultant benchmark results showed sub-second
respopnse times for inserts (with embedded selects) and 3-5 second
response times on queries. The system had 120 Mb of memory and was
using RZ57 (1 Gb) drives. Database size was 1 1/2 Gb plus and the
benchmark was run with 100 concurrent users. (As I understand it
this benchmark was used as a selection criteria against HP and
SUN).
The 9000 dosn't look like a good solution at this time do to
slipage in shipmanet schedules to both Oracle and our customer.
It don't look like Oracle will receive their system until September
or later - meaning Oracle won't be certified on until sometime
after that. There goes that deadline again.
Ron
| |||||
| 672.4 | another way to talk to customer, maybe? | OFFPLS::HODGES | Thu Jun 21 1990 18:09 | 8 | |
Try the nodemo::marketing notes file around #1212.220-230 for a name or
two associated with that benchmark! Maybe one of those folks can help
you talk to the customer!
Good Luck!
Maryann Hodges
| |||||