[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 |
14.0. "Oracle vs. Rdb, by Oracle" by JAWS::BICKFORD () Thu Jul 02 1987 21:26
Below is an Oracle vs. Rdb report WRITTEN BY ORACLE and distributed
to their sales force for hints on selling against Rdb. I am very
interested in any clarification/opinions on any of the points raised.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
The report reprinted here is an independent customer evaluation pitting
two finalist databases, VAX/Rdb and ORACLE. Originally prepared on
February 2, 1987, this report was the result of a thorough evaluation of
both products and associated tools.
We are particularly impressed with the diligence and the professionalism
shown by the prospect in performing the evaluation. Needless to say, we
are certain that you will be pleased with the findings. The conclusion was
unanimous: ORACLE has been chosen to solve the database needs at this
customer site.
Dan Cronin/Manager of Competitive Analysis
ORACLE Corp.
OVERVIEW
---------------------------------------------------------------------
This report investigates the merits of two finalist databases for the
______ project: ORACLE from Oracle Corportion; and VAX/Rdb from Digital
Equipment Corporation. This document replaces and supersedes all previous
discussions on the subject. Considerably more time has been spent in
hands-on trial of the two products, as well as the testing of new products
previously unavailable. Other users of both products have been contacted
and have provided their opinions. Opinions provided were understood to be
on a CONFIDENTIAL basis; parties involved will NOT be identified.
Six categories have been identified as being of prime importance in the
selection of a relational database for the ______ project. These will be
examined in depth as they provide the basis for any conclusion which may be
drawn from this document. [A
Software Support
Productivity/Data Management Languages
Performance
Reliability
Backup and Recovery
References
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
SOFTWARE SUPPORT
-----------------------------------------------------------------------
Software support is provided by both organizations via a 24-hour day
telephone "hot line", primarily for problem solving and bug fixes. This is
a necessary cost of using the database systems effectively and is included
in the maintenance costs. During testing we used the ORACLE software
support both in ______ and support provided during office hours from _____:
both groups were knowledgeable, helpful, and responded very quickly to
problems of all types. DEC telephone support for Rdb was not used during
the test as we had a DEC resident; resident support will not be rated as
DEC has requested this not be included since it is only a temporary
situation. DEC telephone support, however, can be rated based on the
support received for other related products. Mr._______ , the programmer/
analyst for both ORACLE and Rdb prototypes, has used both support groups
and rates both as very good. Both groups typically respond to a problem
within one hour. In most instances the problem is resolved as soon as
contact is made again. If the problem cannot be resolved immediately,
additional help is given until the problem is fixed.
Additional support is also available at extra cost from both vendors.
Consultants are available at competitive rates for contracted time periods.
Rates vary from approximately 150 dollars/hour or 1000 dollars/day (plus
expenses and travel) and upwards, depending on the type of help required.
All services required from basic programming through database design are
available. Private consultants with extensive experience in both products
are available.
Final Rating: Software Support
------------------------------------------------------------------------
Equal software support is supplied from both vendors: both supply excellent
support.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
PRODUCTIVITY/DATABASE MANIPULATION LANGUAGES (DML)
----------------------------------------------------------------------
ORACLE implements the industry standard data manipulation language, SQL
(Sequel - Structured Query Language), as the single method to access ORACLE
databases. All ORACLE products use this DML. Less time will be required
to train programming staff as all components of the ORACLE systems share
the same syntax. New skills may be acquired more quickly since only a
small set of additional information need be learned to become proficient in
a new area. Programmers, database administration staff, analysts, and
users who may need to directly access the data all use the same terminology
and database access language. This greatly improves communication, and
allows skills to be transferred at all technical project levels.
ORACLE has implemented a powerful superset of the SQL language to allow
more efficient programming. Extensions to SQL need not be used if total
compatibility with the developing ANSI standard is desired. (ANSI has
announced that some of the ORACLE extensions will be adopted in the new
language standard because of their usefulness).
DEC provides a number of products and languages as part of an integrated
data management architecture. Each product utilizes its own specific
language to access data in the most efficient manner. Each product requires
specific training or practice to use. Some products overlap functions. For
example, an Rdb database may be defined via the Common Data Dictionary
(CDD), the Rdb data definition language, or Rally, depending upon the
individual user's training and needs.
Rdb may be accessed by two data management languages, Digital Standard
Relational Interface (DSRI), and DEC's newly announced VAX/SQL. DSRI
provides complete access to the Rdb database system via RDO, an online data
management and query facility, and through the VAX high level language DSRI
compiler. All high level languages are supported either in native language
form or by using "callable" RDO to send DSRI statements to Rdb. DSRI is
currently a more robust product than VAX/SQL.
DEC recently announced VAX/SQL (January 20, 1987) to enhance Rdb. The
common Data Dictionary interface is supported for VAX/SQL. An online SQL
programmer interface is available for prototyping and database definition.
No report writing or formatting options are available - end users should use
DATATRIEVE or TEAMDATA instead. These would have to be purchased
separately. High level languages supported by VAX/SQL are FORTRAN, COBOL
and PL/I.
A performance penalty of 5-10% is realized when using the SQL interface.
In order to use VAX/SQL, the ______ project would have to use one of the
supported languages rather than Pascal as is currently proposed.
Presently, Rdb's lock management algorithm requires the inclusion of some
extra logic and code in any program which updates an Rdb database. Extra
code is not required if the database is only being read. Estimates from
staff who implemented the prototype indicated an increase in programming
time of approximately 25% in both development and maintenance. This
applies to all products which access Rdb.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
Forth Generation Languages (4GL)
-----------------------------------------------------------------------
Usage of either 4GL at the ______ project is dependent upon exactly what
project sections are to be implemented.
Rally is a very powerful development tool, but requires extensive training.
Rally is a relatively new product and other installations which have used
or investigated this product recommend delaying purchase until it has
matured. Cost to purchase Rally is in excess $100,000.
ORACLE's SQL*Forms is also very powerful but requires less training and
experience to use effectively. SQL*Forms is also very powerful but
requires less training and experience to use effectively. SQL*Forms costs
$7500. The use of Microtel Pacific Research's common interface may
preclude the use of either 4GL.
Final Rating: Productivity/Data Management Languages
-------------------------------------------------------------------------
SQL provides a powerful and consistent database access language, which has
become the industry standard. There are significant advantages to
selecting a SQL interface. In order to use VAX/Rdb with VAX/SQL, the
------ project would be required to use COBOL, FORTRAN, or PL/I, instead of
the already chosen Pascal. A 10-15% performance penalty must be added to
any performance reductions caused by Rdb (see the following section,
PERFORMANCE). Some development time (25%) must be spent in order to
properly manage the Rdb locking mechanism in our programs.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
PERFORMANCE
--------------------------------------------------------------------
Performance testing for the databases was limited to six typical
transaction types, plus a multi-user load test. The test programs were
written in PASCAL, and modified for each database access language.
Programs performed the same tasks except where database differences forced
logic changes. Representatives from both DEC and Oracle were present
on-site for testing. All programs were examined and any changes the
particular vendor requested were implementd. Final versions of the test
programs were agreed upon by representatives of both vendors and the ______
project evaluator.
In all tests except the text data scan, multiple iterations were used to
provide statistical smoothing. The tests performed were:
Simple Retrieval One hundred iterations of a table/row retrieval based
on a unique key, spaced throughout the databases.
Complex Retrival One hundred iterations of a table/row retrieval based
on a unique key range, logically related to a
non-unique single key value, spaced throughout the
database.
Test Scan/Retrieval One iteration of a scan of 10% of the database.
Records were selected by a range of values based on a
non-unique key, spaced throughout the database, then
scanned for a specific text string. Approximately 3000
records were selected and read.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
Simple Update One hundred iterations of a table/row retrieval based
on a unique key, spaced throughout the database,
followed by an update in place. This is the most common
action in a production database. Logic was added in the
DEC version to conform with suggested practice in lock
management. This method for controlling locking was based
on suggestions by the creators of Rally, Rdb's 4GL.
Several modifications to correct our code were suggested
by DEC specialists, the program was modified to
accommodate these changes.
Simple Insert One hundred iterations of a table/row insert at the
high end of the database, performed and committed one at
a time.
Simple Delete One iteration of table/row of the previously inserted
records, performed and committed one at a time.
Multi-User Load Sixteen copies of the simple update all based on the
Test same key set to force record locking resolution. All
sixteen copies were run in a quiescent system to allow
elapsed time measurements to be taken. DEC and ORACLE
tests were run at different times to avoid resource
conflict. This is the only test where elapsed time is
a relevant result. The System Performance Monitor was
run concurrently to provide detailed information about
the test.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
Results
--------------------------------------------------------------------
Test Performed CPU MM:ss Direct I/O Page Faults
-------------- --------- ---------- -----------
DEC Oracle DEC Oracle DEC Oracle
--- ------ --- ------ --- ------
Simple Retrieval :24 :20 635 357 3875 3743
Complex Retrieval 1:10 :59 463 239 3210 3097
Text Scan 4:47 6:21 951 2478 7855 5940
Simple Update *[7:29 1:15] [21368 1694] [66429 7642]
Simple Insert 3:42 3:14 [12785 3115] 5580 2966
Simple Delete [12:14 4:43] [33556 2926] [122842 2926]
* Results marked by brackets [] have significant variance.
Test Performed CPU Variance Favoring
-------------- ------------ --------
Simple Retrieval 17% Oracle
Complex Retrieval 16% Oracle
Text Scan 22% Rdb
Simple Update 499% Oracle
Simple Insert 9% Oracle
Simple Delete 277% Oracle
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
Multi-user Test
----------------------------------------------------------------------
The multi-user test results are averaged for CPU, Direct I/O, and Page
Faults. Elapsed time is calculated from the earliest time on the first
program run to the time the last program in the set finished. Elapsed time
measures the total relative throughput which could be expected under system
load. Elapsed time also is a good indicator of user response time, in that
the longer it takes the test program to run, the longer the user would have
to wait. Remember that we performed one hundred transactions in each
program.
VAX/Rdb Oracle
------- ------
CPU - HH:mm 8:45 1:25
Direct I/O 21467 670
Page Faults 72309 7184
Elapsed Time 5 Hours/55 Minutes 38 Minutes
This data shows large discrepancies in system processing with more than one
concurrent user. VAX/Rdb took nearly 9.5 times more elapsed time than
Oracle under the same circumstances. Rdb actually executed the first ten
submitted jobs. Out of sixteen total jobs, the last six were held until
the first ten had completed (3 hours/45minutes later). In a heavily loaded
system, some users may wait a very long time for a response in an Rdb
environment.
Final Rating: Performance
-------------------------
In all categories except one, ORACLE performed better. ORACLE was between
300% and 500% faster than Rdb when updating the database - including
deleting records. With multi-user simulation, ORACLE was 950% faster than
Rdb. Rdb only processed text searches more quickly than ORACLE.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
RELIABILITY
--------------------------------------------------------------------------
Oracle
------
Some testing of the Oracle database was performed using the
pre-release version. Only minor problems were encountered:
(1) The online database performance monitor display did not
work well in all modes.
(2) The pre-release Pascal documentation regarding IF
statements could be misunderstood.
Both problems were fixed in the production copies actually sent
to Oracle clients.
Rdb
---
Rdb release 2.1 incorporates performance improvements and
eliminates many problems found in earlier versions. Release
2.1 was the version used during this testing phase. Major
problems which remain, however, are:
(1) During an index build sort, temporary space was exceeded.
Over 20,000 blocks were released to allow Rdb to either
finish or backout changes. Rdb could do neither. After
a re-boot the new index was deleted, BUT, THE DATABASE
WAS CORRUPTED. All data, including the data only being
read, was lost. The database had to be rebuilt using non-
database files. If this occurred in a production database,
large amounts of data would be permanently lost.
Stopping a backout or crashing during a backout will cause
database corruption. Users can do this by interrupting a
program with active update transactions, then stopping the
backout process.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
(2) Previously, if the monitor log (used to backout
transactions) became full, Rdb would issue a message and
wait pending operator action to allocate more space. With
release 2.1, Rdb only issues a message and the database
continues processing. In the event of a program crash, no
backout is possible. The database cannot be recovered to
current. Unless the operator notices the console message,
this situation could continue indefinitely. To correct the
problem, a complete backup must be taken, which would require
several hours of time, at a minimum.
(3) Recurring problems with the Rdb lock manager will cause
the inclusion of complex code. This will add approximately
25% to the development effort and time. Lock manager problems
of this type have existed since Rdb release 1.0, and have not
yet been fixed.
(4) The Pascal compiler may perform optimizations which cause
precompiler code to fail. Optimization may have to be turned
off.
Final Rating: Reliability
----------------------------------
DEC has continually improved the Rdb database product, and will no doubt
further improve this product in the future. Unfortunately serious problems
remain. The problems listed above are not only problems with the current
version. Some problems have existed for several versions with no fixes
forthcoming. Problem (1) could cause a TOTAL UNRECOVERABLE LOSS OF DATA.
With system availability at all times required by users, we would be in
serious trouble. Problem (2) could cause the same effect in a worst case.
With luck, however, users would only lose one or two days of production
work.
ORACLE is a more mature product. While some small problems exist - any
large system will have a few minor problems - there are no known faults
which will destroy a production database.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
BACKUP and RECOVERY
-------------------
Due to the critical nature of the data contained in the _______ system, a
complete backup/recovery system must be implemented. Backup and subsequent
recovery of the ______ project databases are complicated by the need for
24-hour availability, Rdb must shut down all the databases in the system.
ORACLE cannot currrently perform after-image journaling on a VAX cluster.
DEC and Oracle have suggested, independently, the same means of providing
reasonable backup/recovery options for their databases.
The backup process requires using features unique to the shadow disk
environment, and the same strengths and weaknesses apply to both Rdb and
ORACLE when using this method.
Shadowed disks used by both vendors would be separated by operating system
command into two separate disks - one online and one offline. This disk
being backed up is no longer protected by shadow duplication. A VAX/VMS
backup is then performed on the shadow disk copy which is offline. The
offline disk is once again paired with the online disk, then, automatic
shadow disk recovery restores the previously offline disk to currency by
rewriting the disk.
Backing up the offline disk to tape (assuming RA81 disks, an HSC50
controller, and a TA78 tape drive) will require 40 minutes for a full disk.
Bringing the offline shadow pair member to currency will require 20
minutes. The full operation will then require approximately 1 hour. There
are three disks currently proposed for the production system. Multiple
disks may be processed at the same time, limited by the number of tape
drives available.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
The shadow recovery proposal (outlined above) could have serious
consequences in three circumstances:
(1) A failure of the online disk of the shadow pair being
backed up. This would result in all transactions, from the
beginning of the backup to time of the disk failure, being
lost. There is an extremely low probability of a sudden
disk failure, however.
(2) A simultaneous failure of both members of the shadow pair
being backed up. This occurrence would result in all data
since the last backup being lost. The probability of this
occurring is infinitesimal.
(3) Program failure. If the data has been logically changed,
all databases would have to be recovered to the most recent
backup. All subsequent changes would be lost. Given
sufficient disk space, only the involved ORACLE databases
would require recovery. Critical databases could always be
backed up beforehand.
Final Rating: Backup and Recovery
--------------------------------------------
Both vendor solutions are adequate for development and testing of the
system. For a production system, only a full backup and recovery system is
acceptable. Future revisions of both are believed to solve this problem.
Promised are:
ORACLE Version 6 will contain After Image Journal support for
VAX clusters.
Rdb release 3.0 will allow backups to take place concurrently
with online database operations. Release 3.0 should be available
in twelve to twenty-four months.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
REFERENCES
-------------------------------------------------------------------------
References were supplied by both vendors. Additionally, other sites
involved with ______project were contacted. This is a summary of comments
collected from these sources.
Oracle
--------------------
Of the sites contacted, patterns emerged. Most of the sites were
recommended by Oracle Corporation, but some were contacted
independently. Most were large data processing environments. A
majority had previously used Rdb and had replaced it with Oracle.
All felt Oracle executed faster,and provided a better development
environment. One shop in particular (name available on request) had
been developing applications with Rally/Rdb, but replaced it recently
with Oracle's SQL*Forms. Oracle reference sites were all unanimously
in favor of Oracle, none had found any significant problems. All rated
Oracle support excellent.
Rdb
--------------------
Patterns also emerged in reference sites using Rdb. Rdb sites with
small to medium work loads - with few concurrent users - were very happy
with the database. Rdb has improved greatly with the introduction of
release 2.1, both in terms of reliability and in processing speed. Users
of Rdb were pleased with the support provided by DEC and all rated
telephone support highly.
All sites contacted advised waiting for Rally to mature before
purchasing the product. They claimed the current product is difficult
to use in a production environment, even with extensive training. It
takes a long time to develop applications with Rally, and the resulting
applications execute slowly.
"ORACLE CORPORATION: Rdb vs. ORACLE COMPETITIVE EVALUATION"
RECOMMENDATIONS
------------------------------------------------------------------------
ORACLE is significantly more efficient than Rdb both in development and
production. Additionally, ORACLE is a more mature and stable product with
no known problems, and no history of problems which may corrupt vital data.
Rdb is a well supported product which is part of the Digital Data
Architecture. However, Rdb currently has performance and reliability
problems which render it unacceptable. The ______ project would also be
forced to use a non-standard data access language, or change from Pascal.
Recurring problems with the Rdb lock manager will cause the inclusion of
complex code and add approximately 25% to the development effort and time.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 14.1 | Keep these Evaluations Coming | AUNTB::BOOTH | | Sat Jul 04 1987 05:34 | 20 |
| It's always fascinating to see company's evaluating their own
products. This evaluation is rather conspicuous in several areas:
1) Where is the section on ease of database management? Can we
guess why there isn't one?
2) Is it coincidence or intentional that Pascal was used for this
test, since Pascal seems to be a sore spot for Rdb?
3) A DEC resident is mentioned several times. But is this resident
a database expert, or is he there for some other expertise?
4) Their database crash theory is one I have yet to see in the
field.
5) The performance figures are very strange in view of the relatively
recent DECUS-France comparison benchmarking.
6) Comparing Rally to anything else commercially available is
generally a losing proposition, but I don't know where the $100,000
figure originated, unless it was in Oracle's imagination. In the
real world we would probably use a CMP product to compete with Oracle's
4GL.
I hope they will continue to supply their sales force with
evaluations like this, since these kinds of "tests" are generally
easy to counter.
|
| 14.2 | Support? | AUNTB::BOOTH | | Sat Jul 04 1987 05:38 | 6 |
| One more thing --- the support section directly contradicted what
I am hearing from current Oracle users. They are all concerned by
the lack of support from Oracle. Our largest local Oracle installation
is in the process of reconsidering their corporate database commitment,
largely because of Oracle's lousy support. Their phone support may
be fine, but they seem to have little in the way of local support.
|
| 14.3 | For 2� plain... | COOKIE::MELTON | Livin' and Dyin' in DSRI | Mon Jul 06 1987 23:08 | 98 |
| There are so many parts of this "analysis" that border on the absurd that
I have only just convinced myself that responding to it would be
meaningful.
For example, there's a paragraph which reads as follows:
ORACLE has implemented a powerful superset of the SQL language to allow
more efficient programming. Extensions to SQL need not be used if total
compatibility with the developing ANSI standard is desired. (ANSI has
announced that some of the ORACLE extensions will be adopted in the new
language standard because of their usefulness).
As it happens, I represent DIGITAL on the ANSI X3H2 committee which
considers the SQL language standard. That committee has made *NO*
statement to the effect that anybody's extensions will be adopted in the
new standard. We have made no statement of anything that will or will not
be adopted. At this point, we are beginning to narrow down on what the
next generation of SQL will contain, but no public statements of that
content have been made. In any case, we can propose whatever we want, but
public comment and X3 voting procedures and results will determine the
actual results of out proposals. Now, no doubt there are some features
being proposed for SQL which are closely related to features implemented
by Oracle, but that's not the same thing that was said in that paragraph.
Another paragraph indicates a serious lack of understanding on the part of
the writer regarding DIGITAL's architecture--making a comparison somewhat
imprecise. The paragraph reads:
Rdb may be accessed by two data management languages, Digital Standard
Relational Interface (DSRI), and DEC's newly announced VAX/SQL. DSRI
provides complete access to the Rdb database system via RDO, an online
data management and query facility, and through the VAX high level
language DSRI compiler. All high level languages are supported either in
native language form or by using "callable" RDO to send DSRI statements to
Rdb. DSRI is currently a more robust product than VAX/SQL.
As it happens, I'm the Database Architect for DIGITAL and have
responsibility for DSRI. Many of you will already know that DSRI is in no
way a "data management language", but an interface standard. DSRI
provides nothing vis-�-vis RDO. RDO is a query tool which accepts a
variant of the RDML language and outputs DSRI to the database system.
Furthermore, DSRI is in no way a product of any sort, therefore it'd have
a tough time exhibiting any product robustness.
Just two paragraphs later, the report states:
A performance penalty of 5-10% is realized when using the SQL interface.
In order to use VAX/SQL, the ______ project would have to use one of the
supported languages rather than Pascal as is currently proposed.
Where in the bleeding world did they get the idea that there's a
performance penalty for using the SQL interface? Not from us--we know
better. Not from experimental evidence--it just wouldn't happen. Must've
just made it up.
Similarly, I wonder about the statements in the paragraph reading:
Presently, Rdb's lock management algorithm requires the inclusion of some
extra logic and code in any program which updates an Rdb database. Extra
code is not required if the database is only being read. Estimates from
staff who implemented the prototype indicated an increase in programming
time of approximately 25% in both development and maintenance. This
applies to all products which access Rdb.
I have written lots of programs which updates Rdb/VMS databases. And none
of them "requires the inclusion of some extra logic and code". What are
they talking about? Perhaps some of you field gurus can enlighten me.
Are they, by any chance, referring to the ON ERROR capability that users
can use to help detect and handle deadlocks (or other error situations)?
If so, then the lack of need for Oracle users to use such capabilities
implies that Oracle can never cause deadlocks nor are other error possible.
Either that or they have no possible way to detect errors and adapt for
them. In any case, assessing a 25% development penalty seems rather large
to me for ON ERROR code! This moderately ridiculous point is made
repeatedly. I won't repeat my comments, though.
Like the previous commenter, I wonder where they got the figure of
$100,000 for purchasing Rally. Did they mean to purchase the exclusive
world-wide rights to market the product? A single copy costs a *lot* less
than that, even for an 8978, I'm sure.
Similarly, I'm suspicious of the performance numbers. The previous
commenter noted that a test done by someone related to DECUS/France
indicated that Rdb/VMS performed significantly better than Oracle. Very
casual tests done in database development groups have indicated much the
same thing (though those tests were done long ago with old versions of
both products).
A pet peeve: nothing in the universe can be 300% faster than anything else.
100% faster means it takes 0 time. If Rdb/VMS takes 45 seconds to finish
a transaction and Oracle took 4.5 seconds to do the same thing, that'd
make Oracle 90% faster. If Oracle were 100% faster, then it'd take 100%
less time--or zero seconds. If Oracle were 300% faster, then it'd finish
3*45 seconds faster, or 90 seconds before it started. Time travel made
simple?
In the backup and recovery section, the author makes the statement:
Rdb must shut down all the databases in the system.
Why would Rdb/VMS have to shut down all the databases in the system to
back up one of them? Not likely.
Well, I think the point is made...the person making the review seems to
have made up his mind before doing the evaluation.
Just my 2� worth...
Jim
|
| 14.4 | What a load of rubbish | MINDER::PICKERING | | Tue Jul 07 1987 12:20 | 12 |
| This report keeps mentioning Rally but its unclear where Rally was
actually used, if at all. The tests were using Pascal. Who suggested the
lock management techniques based on Rally? I'm not even sure what
that means. Who are these DEC specialists that are mentioned? Perhaps
the originator of note .0 can find out and ask these specialists
what really went on?
Another minor inaccuracy to add to those already mentioned;
you can't define Rdb from CDD - its the other way round.
Thought the summary was wonderful; 'Oracle reference sites were
all unanimously in favor of Oracle...' -- what a surprise!
|
| 14.5 | Ally not mentioned... | BISTRO::KIRK | Area Field Support Group, Valbonne | Tue Jul 07 1987 18:21 | 6 |
| It's interesting that the article made no mention of the fact that
Oracle are busy implementing a product based on Ally, the same product
that Rally is based on.
Richard
|
| 14.6 | Support is an Issue for Oracle! | BMT::TIMMINS | | Thu Jul 09 1987 22:52 | 33 |
| re .2
Support is still a issue for Oracle...here's a excerpt from a recent
Gartner Group/Software Management Strategies:
"But the most necessary announcement -- new customer service programs
-- featured little technology. Oracles's Achilles' heel is its
task of developing an organization to service its growing base of
commercial users, who are less conservative than Oracle's customers
and have stiffer requirements in the VAX and Unix worlds. These
programs (see Figure II) provide a multilayered support structure
that can serve as the formal <underlined> basis for an adequate
service capability. Unfortunately, most of the support-building
task is still before Oracle, as the recruiting issue is not yet
resolved."
The info in "Figure II" was:
"New Customer Service Programs
o Centralized support teams
o Support call-tracking network
o Two levels of Oracle premium support
o Enhanced consulting services
o Functional learning paths for education"
Regards,
Larry T.
|
| 14.7 | Well, I don't know about that... | FNYFS::MACKEY | Step to the music you hear | Mon Jul 20 1987 20:04 | 12 |
| I notice that Rally took quite a beating in this note and it's replies.
Is there anything to substantiate the rumour that:
"Comparing Rally to anything else commercially available is
generally a losing proposition" ?
Does anyone know how sales of Rally are going - and did we win any
against competition (or did the customer buy just because (s)he
didn't know any better)?
Kevin
|
| 14.8 | People buy Rally on purpose... | BISTRO::KIRK | Another entry from the Captain's log. | Tue Jul 21 1987 14:07 | 22 |
| Kevin,
I worked with 2 sites that chose Rally against the competition,
in one case Oracle, in the other Oracle and Ingres. One of the customers
carried out an extensive evaluation exercise which involved developing
a sample application using all three vendors' software. We won.
I have heard about another site that chose Rally rather than Oracle.
When trying to compare Rally against competitive products, remember
that Rally is barely a year old (as a shipped product), whilst most
competitive products are fairly mature. This could be used against
us, but you can turn it to our advantage by simply stating that
despite Rally's tender age, it manages you stand up very well against
the competition. Now, given its current features, and impending
new version, the future is very exciting.
Also, don't forget that Oracle also bought a copy of Ally (the product
that Rally is based on), and they are developing a product using
Ally. So Ally can't be that bad.
Richard
|
| 14.9 | Qualification | CEDSWS::BOOTH | A career of MISunderstanding | Tue Jul 21 1987 17:32 | 16 |
| OK, OK, Let me rephrase and qualify my statement. I'm working
in the commercial marketplace, not OEM's or small shops. Yes, I
have seen Rally win where there are very few developers, or a
functional test. However, in a large development shop it is not
yet appropriate (in my opinion). In a team development (4-8 people
working on projects) Rally is very difficult to manage without a
pencil and paper tracking system. Change control doesn't exist,
because Rally has no dictionary. Neither can it be "called" from
3GL's. It is also limited as to the number of users (45) it can
support. Consequently, for large scale application development there
are many more appropriate products.
Rally is going to improve dramatically, and as it does I will
be more than happy to endorse it heartily, as I do now when the
situation is appropriate. I will try to qualify my statements more
carefully in the future!!
--- Michael Booth
|