You lookin' for a phased migration or one fell swoop? If you're at least up to 22.214.171.124, 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.