Adventures of a Designer 2000 installer on Netware

From: <porus_at_ozemail.com.au>
Date: 1995/08/03
Message-ID: <N.080395.170733.59_at_slsyd4p09.ozemail.com.au>

Adventures of a Designer 2000 installer on Netware 3.12

Recently, I upgraded to Designer 2000 from Case 5.1.8. On the head office server, my company uses Netware 3.12, a robust, user-friendly and almost maintenance-free operating system. The server is a Compaq Proliant 60 MHZ Pentium with 4 GB hard disk and 48 MB Ram. Oracle 7.1 for Netware runs as a robust NLM (Netware Loadable module) on the server.

Prior to the upgrade, Oracle support advised me that at least 60 MB needed to be FREE in my System tablespace. The Rollback segments needed to be 20-30 MB, and the SGA needed an optimum of 25 MB or 21 MB at the bare minimum - my present SGA was just 5MB. Oops... I remembered that Netware 3.12 requires 4 MB for the base operating system and 8 MB per GB of hard disk, ie. 4+8*4=36 MB. So, I had only 48-36=12 MB left for Oracle. My netware consultant warned me of terrible things to come if I had an SGA as big as 25 MB. Would the install work? Would I be doomed to ask my boss for a hardware upgrade?

Support advised me to install the Designer 2000 CD first. After that , I was not to upgrade minor different version changes of the software on the Developer 2000 CD for eg. if Sql Plus was version 3.1.2 on the Designer 2000 CD, I was not to change to 3.1.3 in the Developer 2000 CD even though it was a later version. The same applied to the Forms Designer 4.5 and Reports Designer 2.5 on the two CDs. This was because all the software on the Designer 2000 CD was tried and tested as a whole, and not with any different earlier or later versions.

Also, I was not to do a Complete install from the Designer2000 CD but a Custom install - specifically, only the items: Designer 2000 and Sqlnet (version 1 or 2). Oracle Graphics in the Designer 2000 6.0.5 CD apparently has an install problem. Support advised me to wait till Designer 20000 6.0.6 was released, and NOT to install Graphics from the Developer 2000 CD. However, Support advised it would be quite okay to install Oracle Browser from the Designer CD. Of course, I had the licences for these products.

I did all this. The Designer 2000 software was now on my hard disk. Now, I had to upgrade the case 5.1 dictionary to a 6.0.5 Repository instance.

As preparation, I took certain smaller rollback segments offline, using Sqldba on the Netware console, as follows (as advised in the install manual):

1. select segment_name, tablespace_name, status from dba_rollback_segs; This showed the rollback segments and their online or offline status
2. select segment_name, tablespace_name, bytes/1024/1000, blocks, extents from sys.dba_segments where segment_type = 'ROLLBACK';

This showed me that segments RBS1, RBS2, RBS3 were the largest in my system, so I would take the smaller segments case1_rs, case2_rs offline. (Note that the System rollback segment cant be taken offline.)

c. alter rollback segment case1_rs offline;

    alter rollback segment case2_rs offline;

Note that the rollback segs come back online when the Oracle instance starts if they are mentioned in the init.ora (in \oranw\rdbms71) in the parameter rollback_segments.

I now started the upgrade of the dictonary, from the repository administrator utility. After a while, during the upgrade, an error suddenly appeared - unable to allocate temp segment to tablespace case. The error was put in ckindex.lis, because this error occurred while creating the indexes. So, I aborted, and in Sqldba on the Netware server I increased the Case tablespace (by adding a datafile), and made the temp tablespace of the repository owner as TEMP instead of Case, using the alter user command. When I started the upgrade again, it intelligently continued at the right spot it had aborted before ie. Ckindex.

The next step was building packages. While doing this, an unexpected PLUS31 error appeared, scaring the wits out of me - Plus31 caused a GPF in Ora71win.dll at 0002.0479. Version problem? I took a guess. I re-installed Sqplus from the Designer 2000 CD, removing the later version of Sqlplus on my hard disk which had come from a previous Oracle 7.1 install. I restarted the 6.0.5 upgrade. The GPF disappeared.

Loading certain modules in CKLDPACK now aborted with Ora 04030: out of process memory
when trying to allocate 46592 bytes. It was unable to get more memory from Netware. Apparently, I had a serious problem, because of the hardware configuration of the server.

At the Netware server console, typing in Modules<enter> showed which modules were loaded in the server. I unloaded several immediately-unnecssary modules such as Nlmauto (a batch job scheduler in Netware), Cdrom, the compaq cd disk driver module, Xtree (a network management module), Rspx and Remote (modules that allow the rconsole command in Netware ie. Remote console), Apcsmups (for my ups), etc. I could have even unloaded Oracle Nlms such as spxsrv, sqlspx, tnslsnr, sqltns etc., and worked in Sqldba at the server just for the building of the failed packages.

Also, I increased the PGA by two parameters in init.ora: db_files was increased to 254 from the default 32, and open_links to 6 from 4. The shared pool size was brought down to 6 MB (then increased to 7 MB when some modules failed again during compilation and gave Ora 04031 ie. less SGA memory).

Oracle support said I could do all the remaining install scripts manually at that stage, under SqlPlus in Windows. The remaining scripts at that point were:

p:\orawin\repadm10\api\cdldpack.sql
p:\orawin\repadm10\api\ckrecver.sql
p:\orawin\repadm10\api\ckldtrig.sql
p:\orawin \repadm10\api\ckreset.sql
p:\orawin\repadm10\utl\ postimp.tab 

(The postimp.tab was to be executed as: CDREP10 <repository owner>/<password> postimp.tab).

In these sql scripts, I would have had to type in the values for certain substitution variables as follows:

&sdd_api_dir stands for p:\orawin\repadm10\api
&sdd_sql_dir stands for p:\orawin\repadm10\sql
&sdd_ins_dir stands for p:\orawin\repadm10\ins
&ck_sql_dir stands for p:\orawin\repadm10\sql.

In the case of CKRECVER.sql, I was to hit return after a message checking versions appeared, else it would wait indefinitely in Sqlplus.

However, I decided to do it a different way. Rather than do it manually, I wanted the automatic installation to continue.

I went through the repository administration utility again to upgrade. When it gave errors in compiling certain packages during cdpack, I let it go through and compile what it could. At the end it asked me if I wanted to continue, aboort, or recover. I selected recover. The recover process finds those packages that are invalid and recompiles them. If the recover process failed again, I could abort, go to the server, compile those packages there, come back, and the repository administration utility upgrade would restart at recover. If I had aborted at the cdpack process, it would have restarted at cdpack and started compiling all the packages again. This way, the recover process would only compile the invalid packages, saving time.

The packages that were not compiled were in the following scripts, that I found using the Norton file find utility: searching for all files under the orawin\repadm10 directory containing the words ciodataflow, cioforeign_key_constraint etc. (which were the names of the failed packages from the .lis files in \orawin\bin).

Package: Script file : all in Oracle:\orawin\repadm10\api\

ciodataflowcidfl.ops and opb (pakage spec and

body)cioforeign_key_constraintcifco.ops and opbciofunctioncifun.ops and 
opbciomodule_detail_column_usagecimci.ops and opbciomodulecimod.ops and 
opbciomodule_detail_table_usagecimti.ops and opbciotable_definitioncitbl.ops 

and opbciocolumncicol.ops and opb

Then I could compile these pacgages at the Netware server, connecting in Sqldba as Porus (the repository owner), and type:

_at_Oracle:\orawin\repadm10\api\cidfl.opb _at_Oracle:\orawin\repadm10\api\cifco.opb etc.

Note that Oracle: is the name of our Netware volume containing the Oracle software, it may be different in your case.

After a bit of adjustment of the SGA and PGA, and also unloading some NLMs, I was able to get all my failed packages compiled one by one. Going back to the repository administration utility and restarting the upgrade to 6.0.5, the Recover process restarted, found a few dependant invalid packages, compiled them, and went on automatically through ckrecver, ckldtrig, ckreset and finally postimp.tab to finish the install and give me a 6.0.5 repository.

I had cheated Netware! Now, I could use Designer 2000.

Author: Porus Homi Havewala. Received on Thu Aug 03 1995 - 00:00:00 CEST