Re: Oracle 6 to Oracle 7 Migration

andy_at_vistachrome.com (Andrew Finkenstadt) writes:

>I know the answers to this, even though I've never actually performed
>a V6->V7 migration. I've just done several dry runs and a lot of
>reading.
 

>shekita_at_yeti.almaden.ibm.com (Eugene Shekita) writes:
>>Can users of Oracle out there comment on what it was like
>>to migrate from Oracle 6 to Oracle 7? In particular, I'm
>>curious about:
>> 1) Did the database have to be shutdown while the migration was done?
 

>Yes, absolutely. No users can be logged in while the O7 kernel
>is changing the layout of all the data dictionary tables.

Well - I agree and disagree - yes there must be NO users logged in, but the database processes must be active in order for MIGRATE to work properly. (at least on the VMS platform).

>> 2) Do you know if the format or layout of data on disk was changed?
 

>Yes, significantly such that the entire data dictionary is rebuilt
>from the existing information in place before migration. The actual
>format of row data did NOT change to the best of my knowledge. (This
>is of little comfort when you have 300 users asking where their data
>is at 8am monday morning.)

Maybe I don't know the meaning - but here's my 2 cents - the format of the data may look different to the users, but (CHAR -> VARCHAR2) but it will, in reality, will be the same. Yes the Data Dictionary goes through SIGNIFICANT changes - but except for the underlying tables and DBA_ synonyms, it basically 'appears' the same. As for the physical layout of the tablepspace files and control files and log files - well, they may have changed in size (somewhat), and their internal format may have changed (only Oracle knows for sure), we did not find that there was a significant change to the physical files from an O/S perspective (again - on the VMS platform).

>> 3) How long did migration take?
 

>This depends highly on several factors:
> the optimized tuning of your Oracle7 kernel.
> the speed of your platform.
> the speed of your disk drives/subsystem.
> what else is going on.

Our migration runs took SOOOOO LLLLOOOONNNNGGG (30+ hours) that we gave up on using Migrate and instead used the EXPORT/IMPORT method.

>Take the Oracle estimates and double them, would be a good starting
>point. Read the Migration Guide TEN TIMES before you even begin to
>think you understand the process. Follow it very closely, including
>the dry runs and the actual PRACTICE migration. TEST your application
>thoroughly before you allow users to test it for you.

I could not agree more!!!! In fact, you should study the Migration Guide as if you life depended on it, and then dry run it on an actual database so that you can see what happens. Finally, as always, make DOUBLE sure that you have proper backups (O/S and EXPORT) before beginning. Good Luck!!!

>>Gene
 

>--
>Andrew Finkenstadt | andy_at_{homes.com,vistachrome.com,genie.geis.com}
>Systems Analyst | Vista-Chrome, Homes & Land Publishing Corporation
> | 1600 Capital Circle SW, Tallahassee Florida 32310
>+1 904-575-0189 | GEnie Postmaster, Unix & Internet RoundTables Sysop

-- 
------------------------------------------------------------------------------
*         Joseph Bennett, I can be reached at jbennett_at_netcom.COM            *
*           Netcom - Online Communication Services San Jose, CA              *
*                                                                            *
* "I have a fear of letting my mind wander, I'm afraid it won't come back"   *
*                "I don't do drugs, I don't have the time."                  *
------------------------------------------------------------------------------