Conference ulysse::rdb_vms_competition

44.0. "Trip Report from September's ORACLE Users Meeting." by QUILL::FOLDEVI () Wed Nov 11 1987 21:28

 
                                    
I N T E R O F F I C E   M E M O R A N D O R A N D U M 


                        	              	Date:   1987-10-15
           		                      	From:   Lars Foldevi
				 		Dept:   Database Systems
                                 		Userid: QUILL::FOLDEVI


 

Subject:  ORACLE Users Conference, September 1987; A Trip Report


1.General.

 This year's ORACLE Users Association Conference was held in Washington D.C. 
during three days, September 28-30.  My reasons for attending the conference
were two: to gain competitive information on ORACLE and their products in
particular, and to learn about the relational marketplace in general.  It is 
important to realize that I am a beginner in the RDBMS environment, and that 
I most certainly missed lots of interesting information that an experienced 
database expert would have picked up.

 The major message from ORACLE was that they now are turning their attention 
to the On-Line Transaction Processing market.  They will do this with the 
release of their Transaction Processing Subsystem, TPS, which will improve 
the peek transaction rate 7-10 times (according to themselves).

 Other significant announcements included a new Report Writer, a new Graphics
interface, and improved HELP feature.  Also, I guess that the plans to offer
all their products into the PC, with improved performance, are of common
interest.

 As for the conference itself it was well organized and offered good quality
presentations from the ORACLE people.  I had the impression however, that 
ORACLE now is getting to the size of company and offerings, where it starts
to get more complicated to support both old and new, more demanding, users.
The compatibility is becoming a nagging issue, and at a couple of instances
users voiced their concern, e.g. in the case of SQL*Forms V2.3 to V3.0.  
Another impression is that some users realize that they are "hooked" and that
they now have to pay heavier licenses for things that they need.  Examples
are the new - rather than old improved - Report Writer, and the Transaction 
Processing Subsystem, which does *not* come with the kernel. 

 The conference offered common sessions in the mornings, with ORACLE
presentations, and concurrent sessions with ORACLE and Users presentations
in the afternoons.  With few exceptions there was always an ORACLE
presentation to attend during the afternoons.  These presentations
were of good quality and I can not recall any instance when the presentor
could not respond to technical or marketing questions.  Very often more
than one ORACLE representative were available to answer the questions. 

 The conference offered an Exhibit Area where 20-25 vendors showed how they
used or complemented the ORACLE products.  Harris, Sequent, Network
Innovations, and Digital, were just a few of them.

 The number of conference attendees were about 1,500.  It seemed to me like 
the majority were end-users and managers rather than DP programmers.

 The rest of this report is a run-through of the presentations that I attended. 
It is not a chronological list of the presentations, but rather in order of
generality of interest. My intention is to simply report what I heard and what
I manage to write down, whether it's of real importance or not. 

 For anyone interested I have the Conference Proceedings, an ORACLE magazine, 
the 1986 Annual Report, and some announcements "flyers" in my office.


2. The OLTP Announcement.

 The most important announcement during the conference was the one for the
Transaction Processing Subsystem. This is an optional (separately priced!)
feature to the ORACLE kernel.  It is "the biggest single effort that ORACLE 
has taken on".  The size of the project - which is not yet completed - is
in the range of 50 manyears.  There are 400K lines of code in TPS itself, 
plus 200K lines rewritten in the kernel.  The thrust, of course, is to be
able to compete in the OLTP market, or in their own words "to support large,
transaction-oriented applications".

The means to achieve the goals:

	Transaction Rate      -	Deferred Writing at Commit, i.e. data are
				written to "log block", and "log block" is 
				written to "disk log block" at Commit. At
				Commit only the "log" is written.  At Recovery
				the "log" reapplies the changes.

			      - Reduction of Serialization Points	
    			      - Improved Disk and Runtime Data Structures

	Concurrency	      - Locking at Row Level by Default
			      - Optional Locking at Table Level
			      - Improved Dictionary Concurrency

	Availability	      - Optional Media Recovery with Better Space Usage
				and Performance ("physical logging")
			      - Online Backup
			      - Partial Database Operations (this is planned but
				not committed)
			      - Fault-Tolerance Features (planned-only)

	Reliability	      - Process Cleanup for System Reliability
			      - Improved Internal Consistency Checking
			      - Improved Exception Reporting and Diagnosis

	Configurability	      - Distributed File System Support
				(The VMS Lock Manager extensively used rather
				than ORACLE's own in order to minimize I/O)
			      - Runtime Tuning Mechanism

	Functionality	      - PL/SQL, a procedural language based on SQL,
				ADA, and PL/1; very well integrated with SQL,
				full data handling capabilities, full control
				capabilities

			      - PL/SQL Program Execution
				PL/SQL can appear where SQL appears, SQL is a 
				subset; productivity increase (no context 
				switch), performance (block structure, may 
				include multiple SQL commands, all being
				moved to the RDBMS at the same time)

			      - Control over Use of Space
			      - Better Use of Available Space (re-use of 
				deleted parts of blocks)
			      - Savepoints
			      - Incremental Logical Export (export what is
				changed only)

 Internal performance tests indicates that the performance peeks for 12 users
at approximately 28 TPS.  The current base value is 4.  These tests will 
later be applied to a Debit/Credit banchmark, which will admittedly bring the
peek TPS down somewhat.

 PL/SQL is, of course, not ANSI standard.
  

3. About New Products.

 To provide directions for future products "extensive field discussions on hot
topics were held, including trips to U.K."  The areas identified as to where
ORACLE will concentrate are:
				Workstations
				Windows and Presentation
				Laser Printers

 The goals for ORACLE are formulated as this:

 "A 100-fold increase in application develeopment productivity, and
  a 10-fold increase in 'end-user self-sufficiency'".

 The presentor claimed that ideas for new products has come from competitive
analysis, not from customers.

 ORACLE has formed a group called "New Products Group", and three products have
come out from that organization: 

			/REPORTS    - a new replacement Report Writer
			/CHARTS     - a new graphics interface
			/HELP       - a significantly improved HELP feature

 The following are the Future Directions for ORACLE development.

 For the RDBMS base:	- distribution
			- performance
			- dictionaries (validation, relationships, rules, data)

 For the Workbench - Product Foundation:
			- objects library management
			- window management
			- Definer
			- pop-up menus
			- task manager

 For the Workbench - Utilities:
			- languages
			- HELP
			- tutorials
			- DBA tools
			- gateways (incl. mail system)
			- editors

 For the Workbench - Tools:		
			- reports
			- graphs (/CHARTS)
			- forms
			- menus

 For integrated user interfaces:
			- end-user
			- application developer
			- product architect


4. Some Planned Releases for ORACLE under VMS:

Before 1/1/88:	SQL*QMX V1.0  - this is an IBM QMF "clone"
		PRO*ADA V1.2
 		SQL*REPORT V1.1 - the old Report Writer which apparently is
				 not very well received by the users.
				 A NEW product is in the works (code name
				 /REPORT). That product will "beat FOCUS
				 in 80% of all cases", i.e. only in 20% of
				 all situations will FOCUS meet the users
				 needs. (A grumbling could be heard from
				 some users; they were not pleased to hear
				 that the will have to buy a new product
				 instead of get the one they have fixed.)

Before 6/1/88: ORACLE*TPS


5. Future Directions, SQL*Forms and SQL*Menu.

 The ORACLE Tools Design Strategy

			- Non-procedural
			- Add commonly requested functionality
			- Improve performance

 SQL*Menu		- Common front-end to all applications
			- Effective Menus (incl. Direct Choice)
			- High Developer Productivity

	SQL*Menu Version 4.1 integrates ORACLE Tools; possible to invoke
 	SQL*Plus and SQL*Forms without new log-on.

 SQL*Forms Version 2.3 (maintanance release)
			- Array Interface (process many rows at a time)
			- Redesigned Screen Manager
			- Message Suppression and Message Groups
			- Portability; possible to design on Character Mode	
			  device to run on Block Mode device

 SQL*Forms Version 3.0  - Redesigned User Interface (synchronized with /REPORT)
			- LONG support
			- Pop-Ups
			- Dynamic Screen Attribute Control
			- Field Formatting/Masking

 SQL*Forms V3.0 & SQL*Menu V5.0
			- Invoke menus through SQL*Forms applications
			- Pass information between Forms & Menus

 It was admitted that some incompatibility is introduced between Forms V2.3 and
V3.0. (The FRM format is changed.)

6. On Distributed Databases

 ORACLE will support 2-Phase Commit in Version 7, i.e. in 1-1.5 years from now.
The Version 7 will focus on "SQL level, query optimization, distribution".

 Query to multiple databases & triggers to validate are already possible, but
update to multiple databases not yet supported.

 There were two (2) users in the audience that had installed distributed
databses.

 SQL*Net & SQL*Star were reported to "work as announced; fast via DECNet;
some memory requirements problems".

 As for protocols:
       		PC to VAX: Async, DECNet, MAP, TCP/IP
		PC to IBM: Async, 3270, APPC LU6.2 (future)

	       VAX to IBM: DECNet & DECNet SNA Gateway
			   TCP/IP (future)
	      UNIX to IBM: TCP/IP & APPC LU6.2 (future)
			   (today VAX used as gateway)

		   PC-LAN: MS-DOS clients to LANServer (TCP/IP) Shared DB
 
 SQL*Star provides
		     +	Distributed Processing; spread the workload
		
		     +	Distributed Database; locate data where it's best
						(transparent)

 A demonstartion showed a local database on a PC and a remote database on a
MicroVAX. JOINs were excuted where data came from both local and remote 
database. The system would tell the user where the data resides, upon request.
Another demo included a connection to an IBM SQL/DS database.  The access was
"direct" and via the SQL*QMX interface.

 Future features: 	- Multi-Site Update (with a single transaction)
			- More Data Dictionary support (a la System R*)
			- Distributed Query Optimize
			- VMS to VM & MVS using SNA Gateway & TCP/IP
			- APPC LU6.2, MAP, NetBIOS, Token Ring



7. SQL*Star as used by Caterpillar, Inc.

 The situation at Caterpillar was very briefly that there was a central IBM 
system that *had to* be used for the corporate databases, i.e. DB2 was a given
for RDBMS.  Another given fact was that IBM will not work with Brand X, whatever
that Brand may be.  Locally this site had an Apollo ring, MicroVAX and VAXes,
plus Ethernet network and HyperChannel connection something like this:

                          +-------+
			  |  IBM  |----SNA----
			  +-------+
			      |
		 HyperChannel |	
		+-------------+-----------+	
		|			  |
            +-------+                  +-----+ 
            |  VAX  |		      /|     |\	
            +-------+		     / +-----+ \ 			
		| 		    /  Apollos  \  
		|		+-----+       +-----+
	    +-------+		|     | ----- |     |	
 	    |  VAX  |		+-----+       +-----+
	    +-------+
		|  Ethernet     +------+
		+---------------|MicroV|
				+------+

 Rather than pursuing in-house development, or IBM consulting services, the 
decision was made to use ORACLE, i.e. the SQL*Connect for DB2, and SQL*Net.
The ORACLE kernel was not necessary for this application.  The choice of ORACLE
provided the company with SQL tools, possibilities for staging of data, and
distributed capabilities.
 
 The SQL*Connect appears to IBM as a Dynamic SQL program.  The SQL requests
come from the SQL*Net.  The "array processing" is preserved in the IBM system,
i.e. less network traffic.





 A picture of the implementation:

        +---------------+               +-----------------------+
	|   VAX		|		|	IBM		|
	|		|  HyperChannel	|			|
	|SQL*Net (NETEX)|-------/ 	| SQL*Connect		|
	|   ORACLE	|      /-------	| SQL*Net (NETEX)	|
	|SQL*Net(DECNet)|  (NETEX)	|			|
	+---------------+		+-----------------------+
		|
		| /
	        |/ |
		   |
	+-------------------------------+	   	
	| MicroVAX     			|
	|	       			|
	| SQL> Select * from TABX	|  TABX synonym for TABX on VAX
	+-------------------------------+  TABX on VAX synonym fo TABX on IBM



8. ORACLE on the PC.

History: ORACLE Version 4.1 on PC by the Fall '84.
	 Oralink, async PC to host.
	 SQL*Calc.
	 Approximatly 20,000 units of this shipped!

Problems with V4.1: restriction to too small applications,
		    few tools,
		    limited connectivity,
		    poor performance.
 Added challenge:  the 640K adress-space limit in MS-DOS.

The ORACLE Response: - bundling of PC products
		     - exploit the "protected mode" on 286/386
		     - extend MS-DOS
		     - ship V5.0, go to V5.1 (incl distributed capabilities)

 The Version 5.1 Product Suite:  - Proffesional ORACLE (stand-alone PC)
		    		 - Networkstation ORACLE (tools only)
		    		 - LANServer ORACLE (database server)

The Proffesional ORACLE:
		- Development & Execution of Applications on the PC. 		
		- ORACLE Kernel, Data, and Buffers in Extended Memory
		  above 640K limit.  Approx. 900K needed in Extended Memory.
		- SQL Standard; ANSI and IBM.
		- Complete Set of ORACLE Tools

The Networkstation ORACLE:
		- Distributed processing on *any* PC

      Networkstation	+------+		+-------+ DB Server
	(tools)		|      | - - - - - - -  |	|
			+------+   asynch.	+-------+

     		- Future support of LU2 Data Stream, APPC LU6.2, MAP, and TCP/IP
 

				+---------------+
				| LANServer	|  e.g. Compaq
				+---------------+
					|
	------------------------------------------------------------------
		|		|		|		|
	    +-------+	    +-------+	    +-------+	    +-------+
	    |	    |	    |       |	    |	    |	    |       |
	    +-------+	    +-------+	    +-------+	    +-------+
	     Proff.	    Networkst.		|    Servers	|
	     ORACLE	    ORACLE	        |async		|3270 coax
						|		|
					    +-------+	    +-------+
					    |	    |	    |	    |
					    +-------+	    +-------+
					    	Networkstation
						    ORACLEs
 
 The "ORACLE 4-layer RDBMS Model"
	
	+---------------+---------------+---------------+---------------+
	|Applications	| RDBMS Kernel	| File System	| Disk System	|
	|& User Tools	|		|		|		|
	|		|		|		|		|
	+---------------+---------------+---------------+---------------+

  	1st generation of RDBMS systems - all layers in one system:
	 dBaseII, Paradox 	-	single CPU, single or multiple terminals

	2nd generation - separate Disk System:
	 VAXCluster DB System	-	disk server, one or many user CPUs,
					coop. locking

	3rd generation - separate File and Disk System:
	 dBaseIII Plus LAN, PC FOCUS - 	File locking, Byte-range locking

	 Problems in 3rd generation are excessive network traffic, frequent
	lockups, and poor data integrity.

	4th generation - separate Database Server: 
	 ORACLE LAN Architecture     - 	multiple users, one RDBMS Kernel
	 ORACLE with SQL*Net

 "What's Next?"
	V5.1A,  October		New Install Program
				Improved Performance
				Support of Additional 286/386 PCs

	1-2-SQL,  December	Extends LOTUS 1-2-3 to work with Large 
				Databases on your own PC or on a Shared Host

	LANServer, December	Database Server for LANs

	V5.1B, February '88	Easy*SQL 2.2	SQL*QMX 1.0
				SQL*Loader 1.0	SQL*Calc 1.2
				PRO*FORTRAN	Microsoft C
				Tools above 640K
				SQL*Net Additional Protocols
				SQL*Forms 2.3


 "Future"
	- OS/2
	- DOS commitment
	- OS/2 LAN Manager	
	- OS/2 Presentation Manager
	- Several Surprises


9. Miscelleneous.

 In addition to these presentations I also listened to a number of user 
presentations.  One was called "Tuning VAX/VMS for Improved Performance with
the ORACLE Database System" and discusses a number of actions to tune the 
operating system to better accomodate ORACLE users.  This presentation is 
available in the Conference Proceedings document for further reference.  
 A presentation from an Aussi was a bit "different".  He stressed that
a user/developer is still faced with the "traditional" tasks of Designing,
Documenting, and Maintaining.  Also, based on his own experience, he advocated
de-normalization in the cases where a large number of requests for data is made
to different tables.  The solution is to de-normalize at least some of the 
data from other tables (e.g first five years for tax paid).  In his "own"
application, this remedy changed elapsed time from 36 hours to 1.

 I hope that some of this made sense to some of you.  I sure wish I could go
back and ask some questions that I now realize that I should have asked then.
Anyway, I think I learned something, and if you have any comments or questions
that could add to my or your understanding of ORACLE, please feel welcome to 
bring them to my attention.