Ugrade from 8i to 10g on a new server

[rcurva]

Hi guys,

I will migrate an 8i from an old server to 10g on a new server. Just wondering if I can do this without installing the Oracle 8i software component in my new server first.

My DBA friend told me to install Oracle 8i first, copy the datafiles etc, then this will become my base for the upgrade. Once I've done that, I can then install 10g and do the rest of the upgrade. Is this a good plan?


Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided" -- Art of War

 

[jimirvine]

I would suggest that you first thoroghly digest the upgrade documentation before you even consider doing anything else.

 

[SantaMufasa]

Is this a good plan?

I cannot imagine how that would work. Oracle8i datafiles are absolutely, postively unusable by a later version of Oracle.


The only reliable method (in my experience) to migrate Oracle8i (i.e., 8.1.x and above) to a newer major version is:[ul][li]Startup your Oracle8i instance,[/li][li]From the operating-system command prompt, execute the Oracle8i "exp" (export) utility for each Oracle user/schema. (Doing a schema-by-schema export is my personal suggestion versus a full-database export).[/li][li]Copy the resulting dump files to the new server.[/li][li]From the operating-system command prompt (on the new server), execute the Oracle10g "imp" (import) utility for each of the dump files.[/li][/ul]Disclaimer: I have never actually migrated from Oracle8i directly to Oracle10g. I don't know if Oracle10g supports importing dump files that Oracle8i created. If that is the case, then let us know. Under those circumstances, you can certainly:[ul][li]Export from 8i[/li][li]Import to 9i[/li][li]Export from 9i[/li][li]Import to 10g[/li][/ul]Let us know your findings.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
A fo ben, bid bont.

 

[rcurva]

I read these documents and planning (pre-upgrade, upgrade, post-upgrade) to use dbua for my upgrade. But there was no mention if it is possible to upgrade without installing the software components of the old version.

Can I just copy the cold backup of the 8i db (less the Ora8i software) to a newly installed 10g on a new server then proceed with the upgrade? If that is possible, then it would save me a lot of time. If not, then I still need to replicate the existing one to my new server then proceed with the upgrade.

Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided" -- Art of War

 

[SantaMufasa]

BTW, the reason that I suggested using Oracle exports for the migration is because the many times that I have witnessed a migration attempt via Oracle Database Upgrade Assistant (DBUA), the result has never been good/acceptable. Perhaps others have differing experience.

What I do know is that the successful data migrations from an older versions to newer versions have resulted from "exp"/"imp" scenarios.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
A fo ben, bid bont.

 

[rcurva]

Hi Mufasa,
Based on the Oracle 10g upgrade docs, the terminal version allowed for direct upgrade for 8i is 8.1.7.4 which is our version.

Exp/imp (dump) is plan B for me.

Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided" -- Art of War

 

[SantaMufasa]

I will be eager to hear of your success, Robbie. Please update this thread with the method you use to achieve success.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
A fo ben, bid bont.

 

[taupirho]

I agree with Dave and I would make exp/imp your plan A.

We did an Oracle upgrade from 7.3.4 to 9iR2 and used exp/imp technique with success. We did a full database dump though rather than schema by schema. Before that we had tried Oracles built-in upgrade utility and it was a disaster.


In order to understand recursion, you must first understand recursion.

 

[KenCunningham]

Just for the record, we have used dbua with success on one of our systems, but another similar system (from the same supplier!) ended in tears. Seems to be a bit of a mixed bag depending upon the complexity of the database being upgraded.

I want to be good, is that not enough?

 

[jimirvine]

Last week I did exactly as Dave suggested (only with a full db exp) i.e. Upgraded for an 8.1.7 db to a 10.2.0.1 db on a different box. The only thing that I would suggest is that you create the tablespaces in the the 10g Db as LMT with ASSM prior to doing the import.

 

[rcurva]

Hi Ken,
You mentioned using dbua in one of your systems. Have you tried migrating an old version to 10g on a new server?

If yes, did you just install 10g on the new server then copy the files of your old db then use dbua without installing the old database's software component, in my case it's 8i?

Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided" -- Art of War

 

[KenCunningham]

Hi Robbie, sorry, we were more conventional in that the upgrade was from 9i to 10g, so I can't really help on whether it's feasible to go directly from 8i to 10g.

I want to be good, is that not enough?

 

[rcurva]

Hi Ken, So when you upgrade from 9i to 10g, did you just copy your database files (without installing the 9i software components) in your 10g server then fired off the upgrade or did you install 9i software first, then copied 9i datafiles, then installed 10g software, then run dbua?

I would like to know if you installed 9i software in your new server first before upgrading it to 10g?


Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided" -- Art of War

 

[KenCunningham]

Hi Robbie. We were in the fortunate position of having space on the existing server to install both 9i and 10g software, so we were able to do the upgrade in-situ. I recall there being some initial confusion about whether the database had to be started or not when kicking off dbua. I will revisit my notes when I get back to work on Monday, but if the database doesn't have to be started when dbua is invoked, then you might be able to simply copy over the database files.

As this is a new server could you not just give it a whirl?

I want to be good, is that not enough?

 

[rcurva]

Just an update on this thread. I finally manged to migrade my 8i databases on a new server to 10g using dbua (Database Upgrade Assistant) without any problem at all.

Here's what I did (just a quick summary).

1. Shutdown all the dbs from the old 8i server
2. Tar/Copied the ORACLE_HOME from old to new server
3. Relink Oracle 8i binaries in the new server
4. Restore full offline backups of the db to new server. Copy the oratab, password files, init.ora files.
5. Startup the databases in 8i, then performed 10g pre-upgrade tasks (utlu102i.sql).
6. Made some modifications on the database (created on big public rollback segment, Offline the other rbs, changed my temp tablespace to locally managed) and the init params.
7. Shutdown the 8i databases.
8. Install 10g + patchset (Of course, do the pre-installation tasks first)
9. Change .profile of oracle user to use 10g
10. Start dbua
11. Choose which database to upgrade (based on oratab) then just follow the rest of the instructions.
12. Performed post-upgrade tasks (

http://download.oracle.com/docs/cd/B19306_01/server.102/b14238/afterup.htm).

13. Enabled Auto Undo Management, created a database level temp tablespace.
14. Created an SPFILE from PFILE

For my actual cutover to production, I will use imp/exp (schema level only) to update my application data in my 10g databases.


Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided&quot" -- Art of War

 

[Turkbear]

Hi,
Glad that worked for you, but ,if you don't mind sharing your thought process,why go to all that effort when the Exp/Imp method mentioned here would do the same task with far fewer critical steps ( and hence far fewer chances of a problem).

I have worked with Oracle since the SCO Unix versions and have always preferred moving just the data ( and in later version, the Procs, etc) rather than trying some upgrade procedure...( It allowed me to keep production systems up and running until I was sure the move to a new version actually worked..Then I made 1 change to the DNS and the users were in the new version seamlessly)
[ Mostly worked like that, but it is subject to PICNIC (see hidden area) errors ]

[hide]
Problem In Chair Not
In Computer
[/hide]



To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[rcurva]

Actually, this migration that I did was just a continuation of another DBA's work proposal which was signed and agreed by our client. Unfortunately, that DBA resigned already.

That is why, for the actual cutover, I will be doing exp/imp instead of going through the same process again.

Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided&quot" -- Art of War

 

[hoinz]

Hello,

one answer to Turkbear's question why go to all that effort is database size.
The time needed for DBUA does not depend on size, whereas exp/imp does. And if your database has a few TB, it may well take a day or longer. Will your company agree on that long a downtime? And have you got all the disk space for the export files?

btw, there was a similar discussion in thread1177-1371068

regards

 

[Turkbear]

Hi,
Good point hoinz, just as good as your postings in that previous thread..We seldom had that size to deal with but for our large ones ( < Tera but many Gigs ) we exported to another file server and ran the output through a ZIP utility to produce smaller dmp files ( export dmps compress very well); when needed for the really big ones ,we did a schema by schema exp using separate dmp files ( to get around max size limits) -




To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[rcurva]

Hi Guys,

I think size is not the only consideration here. Based on my experience in this migration (from 8.1.7.4), there were just too many variables to consider since there were a lot of changes in terms of db objects and parameters since 8i. Actually, I did a lot of mini-migrations as post-upgrade tasks like creating undo, dropping rollbacks, re-creating the temp tablespace, migrating to locally managed tablespaces. I have not done the ASSM migration of tablespaces yet.

The post-upgrade tasks were just annoying and it took a lot of time as well. It was good that dbua worked for my databases but if I have my way in re-doing this migration, I'd rather create new 10g databases and tablespaces and perform schema exp/imp.

I have not mentioned that the databases that I just migrated was not properly maintained by a full-time dba in years. So when I shutdown 2 weeks ago, I was not able to start it back bec SMON tx recovery was terminating the instance during startup (ORA-600). I needed to put an event to bypass SMON and performed forced clean up to runaway temp segments in the TEMP tablespace.

Too much drama I tell you.




Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided&quot" -- Art of War