Re: Oracle6->Oracle7 Conversion

From: John Peach <epeas_at_abds7.aberdeen.chevron.com>
Date: 18 Mar 93 08:22:19 GMT
Message-ID: <1993Mar18.082219_at_abds7.aberdeen.chevron.com>


In article <1993Mar17.201234.10997_at_netcom.com>, sjs_at_netcom.com (Stephen Schow) writes:
|> Hi all,
|>
|> We are getting ready to upgrade to Oracle7(under HP-UX 9.0) and I was wondering
|> if we could get a discussion going on the various considerations which must
|> be made and taken care of when upgrading to Oracle7. Of particular interest
|> to me right now are things which MUST be tweaked with in order to work properly
|> under V7.
|>
|> I know that there are new features under V7 that will improve
|> performance, maintainability and so forth when they are implemented...but
|> are not actually required to move existing V6 functionality to V7.
|>
|> In other words, we have a number of applications in place under V6 and we
|> want to upgrade to V7. Step 1 would be to just get the existing apps working
|> properly under V6 with existing security, etc... Step 2 MIGHT be to upgrade
|> the applications to include new V7 functionality such as store procedures.
|>
|> Some of the things which I have heard are listed below. Any comments, questions
|> or whatever in this area would be VERY MUCH appreciated.

I would say that attendance of the Oracle7 New Features course is essential. There is too much to cover to try to post it all here.

|>
|> - V6 security vs ROLE-based V7 security

Yes; there's a lot to cover under this topic :-) And security can be taken back to the OS level; (groups for roles).

|>
|> - CHAR datatypes(are hencforth going to be padded with trailing spaces) and
|> the use of VARCHAR

CHAR datatype now follows the ANSI standard (fixed length); Oracle's existing "CHAR" dataype becomes VARCHAR2 (VARCHAR is reserved for future use). A migration or a v6 export imported into a 7 DB will automatically change CHAR into VARCHAR2.

If you plan to use multi-threaded servers refer to my previous posting on the bug in SQL*net v2.0.12 under HP/UX 9.0 (CONNECT_TIMEOUT_listener = 0). It might save you many hours trying to debug your networking implementation! BTW SQL*net v2 is still beta, but apart from that one bug, I've had no problems with it and it does get rid of all the shadow processes.

|>
|> - Constraints
|>
|> - Stored Procedures and RDBMS triggers
|>
|> Thanks to all in advance

There is also a bug in the install script (oitape) for 7.0.12 for HP/UX 9.0 (at least for the 4mm DAT distribution):

After reading in the installer as documented;

In the case statement, replace the line after the SKIP label: mt -t $NOREW_TAPE_DEV fsf 1 ;;

with
cpio -icudBt < $NOREW_TAPE_DEV 2>/dev/null;;

If you don't do this you can't install directly from tape; it will build the staging area whether you want it or not and if you have said that you wanted to install directly from tape and subsequently attempt to re-install anything from the staging area, it will tell you it's not there!

|> --
|> ------------------------------------------------------------------
|> Steve Schow | But you don't have to use the claw, if you
|> sjs_at_netcom.com | pick the pear with the big paw paw......
|> (415) 354-4908 | Have I given you a clue......?
|> | - Baloo the Bear
|> ------------------------------------------------------------------
 

-- 
                               John Peach
                           Chevron (UK) Ltd.
   Ninian House, Crawpeel Road, Altens, Aberdeen, AB1 4LG, Scotland.
   Internet: epeas_at_aberdeen.chevron.com       Phone: +44 224 242637
Received on Thu Mar 18 1993 - 09:22:19 CET

Original text of this message