RE: ** 8i to 10G conversion
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <ajoshi977@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 5 Apr 2006 19:05:54 -0400
You lookin' for a phased migration or one fell swoop?
If you're at least up to 8.1.7.4, then sqlnet works across that gap and if
you don't have any funky types you can make your new 10g and use sqlplus
copy to move pieces (presumably integral applications) at a time.
Someone else suggested transportable tablespaces, but I wasn't aware 8.1
tablespaces could be moved to 10g. I'd probably prefer to leave the detritus
of 8.1 behind anyway and make a nice clean managed by the database storage
layout anyway. If you copy longs, make sure to set long at least as long as
the longest long you have, and set arraysize and copycommit to useful
values. HMM, I guess you'll need to thing about what to copy longs into if
you have them. If you have some preferred order for inserting into the new
database, sqlplus copy is handy for that. (and likewise for leaving behind
nasty old stuff you don't really want any more.)
Now as for your applications, beware this quote from the November 1988
pressing of the Database Administrator's Guide, Version 6.0, page 19-14:
Under the heading: "Optimizing ORDER BY"
"Though there may be several ways to word a SQL statement to achieve the
ordering you desire, the only way to guarantee ordering is to use the ORDER
BY clause at the end of a SQL statement.
Results which appear ordered, but were not obtained using an ORDER BY
clause, may not be returned in the same order in future releases....."
Since the advent of hashes and other methods of resolving groups and
uniqueness in Oracle, that "may not" is easily experienced and those plans
seem much more likely in 10g than in 8i. SO if you have old code that left
out the ORDER BY, possibly living with differences between character set and
binary sort to avoid sorting the already sorted result set that was sorted
as an artifact of grouping or a sort-merge join, it is very likely to break
(just like Oracle told you a long time ago). (TK was wondering where people
got the idea this ever worked at a HotSOS panel. Well, they put the fact you
could do it under a heading "Optimizing...." but the idea was deprecated
from birth (and heavily used on those speedy 25 MHz chips, tiny memory
sizes, and "sticktion disk drives of the day.") )
If you've got very old clients currently accessing the 8.1.7 database, that
will likely be a problem, as with programs that are linked with the older
sqlnet protocols (which you'll need to relink which is sometimes an
adventure if they've just been running for several years). ("sqlnet will
always be our forward and backward transparency layer." - Name the year and
the quoted person for 42 bonus points).
The system tablespace will grow a ton and you'll have sysaux.
That's all I can think of at the moment. Someone else mentioned the upgrade
guide.
I wish you much luck!
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of A Joshi
Sent: Saturday, March 18, 2006 11:59 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: ** 8i to 10G conversion
Hi,
We are currently on 8.1.7 and considering upgrade to 10G. I would like
to know any opinions or list of issues to expect for this. Maybe this issue
has been discussed already on this forum in which can someone tell me how to
look at the forum archives. SunOS version 8. The databases are over 150GB
and export/import is not an option.
Thanks
----------------------------------------------------------------------------
--
Yahoo! Mail
Use Photomail to share photos without annoying attachments.
Other related posts:
