[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 |
10.0. "INGRES Trip Report (Spring 87)" by NOVA::MAHLER (Andy Mahler) Wed Jun 24 1987 22:06
Below is a trip report from the INGRES USERS ASSOCIATION Meeting I
attended almost 2 months ago. There is some interesting information,
please do not distribute the report outside the company, thanks.
Andy
+-----------------+
| d i g i t a l | I n t e r o f f i c e M e m o r a n d u m
+-----------------+
To: Shirley Date: 19 May 1987
From: Andy Mahler
Dept: Database Systems
DTN: 381-2596
Loc/Mail: ZKO2-2/N59
Net: NOVA::MAHLER
Subject: Trip Report from the INGRES Users Association Meeting San
Francisco, April 27 - 30.
INGRES is a full function relational database management system
combined with a visual programming applications development system.
It is manufactured by Relational Technology Incorporated (RTI) and has
been on the market since 1981.
This was the worldwide meeting of the INGRES Users Association (IUA),
and met in San Francisco from Sunday, April 27 to Wednesday, April 30.
I would like to state that my INGRES knowledge is currently low, I
have yet to run an application on INGRES, but plan to very soon.
Therefore, what I know of INGRES is what I have read in the trade
journals and documentation.
Relation Technology Inc. took the IUA to their headquarters in
Alameda, about half an hour away. At the headquarters, the IUA was
treated to tours of the facilities and an informal get together of the
IUA and RTI staff.
Some notes include:
o Training facility was small, only 1 large room that could be
split into 2. Half of the room was equipped with DEC
terminals, the other half had IBM terminals.
RTI said that they know the room is small and plan to build a
new training facility and offices across the street. RTI
also has a training facility on the East coast, I believe it
is Rockville, MD and they're planning on building (setting
up) one in the Midwest.
o RTI does their own publishing of their documentation and
newsletters, from what I saw, it looks like the copy center
at ZK, with two big XEROX printers.
Page 2
o I went into their lab, they stressed several times how they
have 7 million dollars worth of equipment. What I saw was
several VAXen, an Apollo machine, an IBM machine, an ELXSI
machine (I believe this runs VMS clone operating system, but
I'm not sure), and several workstations.
o We were not permitted into their development area.
o Through some informal talking with participants of IUA, I got
the feeling that many of these people were dissatisfied with
the documentation and support.
o Most people are using VAXen and running either VMS or UNIX
(ULTRIX).
o Most have never heard of Rdb/VMS, or when they chose a
database product, Rdb/VMS wasn't considered because it wasn't
out on the market. I was told that they see more about our
hardware developments in the trade journals, then about any
software developments.
No one I talked to had actually done testing between INGRES
and Rdb/VMS, most of the people here had tested INGRES v.
ORACLE, with INGRES being chosen.
At the opening of the Meeting, there were about 400 attendees, from
all over the world. Paul Newton, President and COO of RTI, talked
about the "state of the company". What he saw as the direction of RTI
is:
o To increase scope of product.
- more database design aids
- more tools for development of applications
- more training aids
o To get people in the production environment.
- increase performance
- multiple servers
- handle VAXclusters better
- provide better security and integrity
Interesting to note that with V5.0 of INGRES (current
version), if a machine goes down, when it comes back up
Page 3
again, it needs to be recovered MANUALLY!
- provide better support
o To provide distributed systems.
- Not just INGRES to INGRES, but INGRES to other products
with gateways and protocols.
Then Gary Morganthaler, Chairman and CEO, spoke about RTI as a company
and what the current strategy is.
Licenses: 6000+ (3500 on VAXen)
Employees: 420
Revenues: $28 Million
Morganthaler wants RTI to Increase TPS/MIPS, Improve Hardware Price
Performance and Decrease Hardware dollars/TPS. By 1992, he sees
Relational as the only database model or having a very large (90%)
share of the market.
He sees the strategy for RTI to offer products that are:
o Relational
o Portable
o Distributed
o Adherent to standards
o Open architecture
o Integrated Tools
o Workstation and Server computing
o Desktop computing
Chris (C.J.) Date spoke next as the keynote speaker for the meeting.
His talked was directed at distributed databases (There will be an
article on this in the June issue of "Computerworld"). His
presentation talked about why distributed databases are important and
some of the history of distributed database, including early
prototypes and actual products (he mentioned VAX Data Distributor).
He then went on to discuss his 12 rules of a distributed database
(much like Codd's 12 rules of Relational Database Systems). His 12
rules for what a distributed database must be are:
Page 4
0. User on Distributed Database should look the
same as a user on a local database.
1. Local Autonomy
2. No reliance on central site.
3. Continuous Operation.
4. Location Independence.
5. Fragmentation Independence.
6. Replication Independence.
7. Distributed Query Processing
8. Distributed Transaction Management
9. Hardware Independence
10. Operating System Independence
11. Network Independence
12. DBMS Independence
If any of the above seem unclear or confusing, I have additional notes
about each one that goes into more detail.
The summary to his talk, Date stated that these rules make up a
full-function distributed database management system, and nobody is
there now and nobody will be there for quite sometime.
Chip Hay, RTI's Industry Product Manager, talked about how systems can
grow when using INGRES and he ran through some examples. He did
mention that they are working on a Gateway to DB2. When I asked more
about when the Gateway would be available and how far along in the
development cycle they were, the answers where "no date" and "still in
the planning stages", respectively.
Paul Butterworth, RTI's chief architect, talked about the new features
for V6.0 of INGRES. It is scheduled to go to field test this summer,
but I heard rumors all week that the date is going to slip at least 3
months. New features include:
1. Increased Performance
With the emphasis on larger machines (>3 MIPS), what they are
doing is setting up internal servers (much like ACMS) to
allow for more throughput and more users.
2. Full Automatic Recovery
No longer will the user have to issue a RESTOREDB command
after a system crash to get the machine to recover itself.
This will be for both clusters and stand-alone machines and
will offer new journal and log formats.
3. Support for Null Values
Page 5
4. New Datatypes:
- CHAR 255 characters, blank padded
- VARCHAR 2000 characters
- DECIMAL
5. Log files will now have usernames to identify users and not
user codes.
6. Maximum of 30 tables per query
7. COPY command improvements
A continue on error option, a rollback option, and an error
log.
8. FORMS enhancements
9. SQL enhancements
- CHAR, VARCHAR, DECIMAL and NULL datatype support
- Dynamic queries in ESQL (Embedded SQL)
- COMMIT and ROLLBACK commands
- Improve performance when several cursors are open
10. What won't be in V6.0 is:
- Record Level Locking
- Multistreaming, INGRES/STAR does allow this though
(INGRES/STAR will cost 30% more than INGRES)
- If you destroy a table that belongs to a view, the view
will be deleted, even if you just wanted to modify the
table
if you want to modify a table, I believe you need to
delete, then create it again - INGRES doesn't allow
modifies on tables, like adding a column, deleting a
column, modifying a column's size, or renaming a table.
The next session that was presented was a forum with the database
developers. This was an hour (but could have gone on all day) of
Page 6
questions from the IUA members directed at the developers of the
database portion of INGRES. What came out of it was the Users asking
for features and why INGRES didn't have them yet, the list follows:
o The ability to create temporary tables.
o The ability to add columns on the fly without unloading and
reloading.
o The ability to be able to DENY CREATE TABLES for security.
o The ability to allow setting page size for a table.
o Record Level locking
o The ability to lock the entire database, so that they can run
an analyze.
o Want to see the limits on maximum size of columns and rows
increased.
o Want a tool to say how many relations and what the relations
are that a certain field belongs to.
o Want to be able to bring whole table into memory.
The rest of the sessions reflected the DECUS format, with many
sessions going on at the same time, some being presented by users and
others by RTI.
One session that I went to the user noted that RTI defines "large
database" as anything greater than half a gigabyte, so that was
interesting to note, because I heard that INGRES will handle large
databases, but never got a clarification on what large is.
I went to a session on INGRES technical support, and how they handle
it. I was very curious about this because what I had heard was that
support was lousy with a lot of "phone tag" going on and poor response
time before the customer actually talked to someone (like 3 days in
one instance). RTI mentioned that the west coast staff is on from
7am-5pm PST, for a while they were the only support for the United
States (not sure about Europe). In January 1987, RTI added an east
coast call center, but the expertise there is not that of the west
coast center. Therefore a customer on the east coast can talk to
someone in the morning, but usually 2 out of every 3 calls still get
sent to the west coast for answers.
To help alleviate the problem and provide 24 hour support, RTI set up
DIAL, this is a call-in system (similar to the Credit Union) and using
a touch-tone phone the customer can find out status of a call, or log
a call and have a support specialist call them when they come on duty.
Page 7
Robert "Corky" McCord, INGRES/STAR Product Marketing Manager, talked
about INGRES/STAR and distributed databases in general. The first
part of his talk was based on distributed databases and why they are
important, their advantages, their uses, etc...
The second part of his talk was based more on INGRES/STAR and it's
future. What was mentioned is that INGRES/STAR has a Gateway to IMS
(developed with GM) that goes through DXT (?), but it is a very poor
performer, RTI is looking to get rid of DXT and go directly to IMS and
DB2. They are also looking at building an Rdb/VMS gateway through
SQL. Also mentioned that they have a prototype that updates a central
database from branch nodes using a two-phase-commit, just to prove to
themselves that it can be done.
Ed Horst, Member of Technical Staff, talked about performance of
INGRES/STAR. He set up the what the benchmark was and where he took
measurements from. Below is a diagram of the layout of INGRES/STAR
and from where to where the measurements were taken.
+-------+
| user |
+-------+ -------+
| |
V |
+-------+ |
| DDB | Time was measured
|manager| from here to here
+-------+ (DDB = Distributed DB)
| |
+-----------+-----------+ |
| | | |
V V V |
+-------+ +-------+ +-------+ -------+
| local | | local | | local |
|manager| |manager| |manager|
+-------+ +-------+ +-------+
| | |
V V V
+-------+ +-------+ +-------+
|OperSys| |OperSys| |OperSys|
+-------+ +-------+ +-------+
| | |
V V V
Disks Disks Disks
The benchmark itself was run on a MicroVAX II, 9 meg and VMS V4.5A,
running INGRES V5.0/03, default local cache and no global cache, the
relation used was a 100 byte record with 10 fields, mixed datatypes,
5000 records, and was all done with a single user. The results
follow.
Page 8
Queries/Second:
Query Local STAR %
-------- ------- ------ ---
Select 18.2 12.5 31
Update 11.1 9.1 18
Insert 16.7 12.5 25
Delete 8.3 6.9 17
---
23
So he said that INGRES/STAR will pump through
23% LESS queries per second than the INGRES.
Same Relation he performed a query:
SELECT * FROM HEAPTABLE
Measured in seconds - clock time.
local STAR
------- ------
25 54
DEWITT benchmark, this ran on a 750, 1 RA81, 8meg. The benchmark is
made up of 53 queries, he showed 21, then added up the 21 queries he
showed and compared the 2 figures. Measured in hours, minutes,
seconds - clock time.
local STAR
------- -------
1:18:14 1:20:01
He then said that STAR has about 2.2% overhead. I wanted to know what
happened to the other 32 queries, and he never mentioned it and I
never got a chance to ask.
He summarized a little bit and said that the highest overhead will
occur on short and simple queries, with the lowest overhead on complex
or local sufficient queries.
The last session on the meeting was another panel forum with all the
executives of RTI on the board to handle questions, concerns and/or
comments. What was said include:
o INGRES has lousy documentation and when are they going to fix
it.
One user noted that at the last IUA meeting, RTI said that
they were going to rewrite the documentation, and RTI at this
Page 9
meeting said they weren't going to rewrite because of
resources.
o More VMS training.
Several users asked for more VMS training, they wanted a
Computer-Based-Training package for VMS similar to what they
have for PC/INGRES, they also want more classes for VMS
training.
o Users mentioned it would be nice to know what bugs are fixed
and which ones haven't when a new release comes out.
o There was concern over some of the limitations with secondary
indices, RTI is looking at better optimizer strategy.
o A comment made was that after INGRES is purchased, the sales
rep becomes invisible, the person who said this, stated that
she has better contact with the corporate office than the
field office and she's on the east coast.
As a side note, the exhibitors room was very small, about the size of
2 cubes, with 7 companies plus RTI in there. I was disappointed in
that RTI didn't have any literature about their products in the booth.
I have more detailed information in my notes and should be receiving a
folder from RTI on all the proceedings with the Speakers notes and
slides. If you are interested in anything please let me know.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 10.1 | | TRUCKS::SMITH_B | Bazzoo� | Tue Nov 02 1993 17:36 | 20 |
| >I was at a customer who is trying to implement client / server solutions. They
>use Rdb currently, however, there is a group who is evaluating Sybase.
>
>They asked what courses I could recommend that deal with how to develop and
>implement client / server solutions with Rdb. They are currently using
>SQL/Services, but, they would certainly be interested in courses that dealt
>with ODBC.
Hi Barry,
I have just finished dealing with exactly the same type of query from a
customer in the UK. From what I can tell, there are no courses which cover
the ODBC/SQL Services arena.
I think this is an excellent area for development. I know Sweden has just
finished running courses on ODBC, but had to bring in an outside vendor.
Join me in TPIS_.... conference to discuss this further?
Barry
|