chiu@brahms.amd.com (Timothy Chiu) (04/05/91)
I hope this is the right group for this, since there is no comp.databases.admin I recently had the [dis]pleasure of having to install Oracle as a database on a group Sun-4 machines. From the experience I compiled a list of complaints, comments, etc. that I sent to the folks at Oracle. To date no response. (Not even an acknowledgement of receipt.) I've installed Ingres previously and it was not nearly as brain-dead or inflexible. Are other database packages as difficult to deal with? Are my complaints valid or do database people just accept these problems as given with database packages? I installed v6.0.30 and my comments to Oracle follow. As you can tell my background is mostly as a systems administrator and as a end user of databases. This is only the second database I've ever had to install. ------------------------------------------------------------------------------ Here is a list of the 13 major faults I have currently encountered while installing ORACLE on a Sun 4/75. While most of these issues can be resolved by reorganizing the documentation and including more information in appropriate places, it seems to me that the product has been rushed through Quality control, and that there has been a lack of planning in its implementation. Some of these issues alone are more than enough for the Systems Group to reject a product for use in CTS (CAD Technology and Systems). Please forward this list to whomever you deem appropriate. 1) Documentation relating to different releases of Sun OS is sketchy. On page 1-7 two small scripts are described, yet there are no instructions on how to run them, where to run them, how they should be executed, etc. Also they are not reiterated on page 3-24 where the step-by-step installation is described. There is also no explanation as to what the scripts will actually accomplish, e.g. what's the difference between /usr/old/make and /usr/bin/make. 2) Troubleshooting oracle.boot on page 3-23, neglects to mention that the install script (in fact, all oracle install scripts) require that your tape drive be /dev/rst0. It just happens that the system I'm working with has the tape drive as /dev/rst1. I had to edit all the install scripts by hand to make the install use /dev/rst1. The scripts themselves also do not mention which drive the tape needs to be in. 3) There is no documentation on which order to install the tapes. I tried installing the patch after the main tapes, but before the upgrade. It didn't work. So I had to start from the beginning again. 4) The oracle.patch scripts didn't work. They expect that openwindows exist in /home/openwin! Sun puts openwindows in /usr/openwin. There was no way to change this without physically editing the scripts. There is also no documentation on troubleshooting this problem. The error messages were obscure, pointing to missing links in compiling. 5) The step-by-step installation instructions in chapter 3 and 4 is incomplete. It fails to mention that for certain products you need to do more than just run the script! This is explained in the individual chapters that follow, but there is no easy way to tell which products need more work and which are fully installed. This is a true hassle! For products which require further setup there should be one chapter going through all the additional stuff. Or there should be a list somewhere stating which products require further installation procedures. 6) Documentation on how to setup a client is sketchy and and never explains the implications fully. You are told explicitly that NFS-mounting the partition is a bad idea, yet that was the only simple reasonable way to get a client up and running. There should be a separate install script for running on a client. So currently on my system I have NFS-mounted the entire ORACLE_HOME directory. (This is the solution provided by the Oracle Hotline. Note that there are many inherent dangers to this setup as described by the manual for installation on page 2-43). Also it never states whether you need another ORACLE_SID for a client, in fact it would lead one to believe you do need a separate ORACLE_SID for each client, when in fact that is not the case. 7) The Database Administrator's manual is almost totally worthless. It should be a complete manual for the administrator, yet it barely outlines what needs to be done, and is more a general intro to database administration. For instance, commands to add users are explained, but never is it explained, which tools to use to add users (e.g. sqlplus or sqldba) and nowhere does it say which database or the need to connect to a database before issuing the commands. It was very easy to get the impression that sqldba automatically connected you to the correct database, which is an incorrect assumption. Also there is practically no troubleshooting tips in the DBA manual, which should be the touchstone of the manual. It's why most DBA's would pick up the manual to begin with. 8) For installation of CASE Designer and CASE Dictionary, there is no easy way to implement the X functions. On page 18-17 it describes having each user type in these lengthy xmodmap, xset and xterm commands. This is NOT acceptable. Instead I have moved these commands to a file sourced by the ~/.cshrc, but even that causes problems since I need to be able to have them executed only when openwindows has started. At the very least I have them limited to only when a person is logged in on a sun. But before openwindows starts up each user gets three error messages. There's got to be a better way! 9) Explanation on the syntax of the TWO_TASK driver is extremely difficult to locate in the documentation. Most areas just say to put one in and never explains how. For example page 3-39 of the installation manual, does this. There should be a syntax description on that page. Or at the very least a pointer to where the description is located. 10) oracle.patch is very misleading. I thought I needed to run oracle.patch to install the patch tape, but the oracle.patch supplied with the source tape in actuality serves no purpose whatsoever. The patch tape isn't even installed in the same place as $ORACLE_HOME/install/patch, instead it locates itself in $ORACLE_HOME/patch1. This seems very disorganized and there is an extreme lack of foresight in the planning of patches! 11) One of the readme documents states explicitly that some of the products need to be installed in a very specific order. Nowhere does it say whether a default installation, (e.g. doing just an oracle.install, and saying yes to all products) will do it in the correct order or not. Based on the documentation, I would think they are not installed in the correct order. If that is the case then there seems to be no easy way to do a full install. What are the implications of doing a full install, and installing these products in the wrong order? 12) The orasrv binary is setuid root! It is commonly accepted by the sysadmin community that setuid root is a security breach and should be avoided whenever possible. 13) Oracle seems to rely much too heavily on setting environment variables for the user. Isn't there a way around this? Having 4 separate variables to define which printer the user is going to use seems outrageous, considering csh already has one called PRINTER. Why do you need CASE_SDPRINT, CASE_PS_CMD, SDD_PRINT, and SDD_WPRINT? -- Timothy Chiu | "Some bookes are to bee tasted, others to bee swallowed, chiu@brahms.amd.com | and some few to bee chewed and digested." -Francis Bacon Advanced Micro Devices, M/S 167 901 Thompson Place, Sunnyvale, CA 94088-3000 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
englhq@jetson.uh.edu (04/11/91)
In article <1991Apr4.220242.17770@amd.com>, chiu@brahms.amd.com (Timothy Chiu) writes: > I recently had the [dis]pleasure of having to install Oracle > as a database on a group Sun-4 machines. From the experience > I compiled a list of complaints, comments, etc. that I sent > to the folks at Oracle. To date no response. (Not even > an acknowledgement of receipt.) > .....it seems to me that the product has been rushed > through Quality control, and that there has been a lack > of planning in its implementation. Ditto my experience exactly, down to the (ignored) list of comments. I bought into the Oracle for Macintosh product, which comes complete with local Oracle kernel, Hyper*Sql for building HyperCard front ends, a C precompiler, and a bundle of problems as you work through glitches in the documentation. I should say, in all honesty, that Oracle provides spirited assistance for the first thirty days, complete with a squadron of Tech helpers who are happy to confirm the bugs as quickly as you phone them in. Truly the poorest presentation of any product I have had the misfortune of using. ___ Duane Franklet englhq@jetson.uh.edu