This content has been marked as final. Show 8 replies
First I hope your source has the latest patchset aka v 220.127.116.11 or so.
Yes use the latest 10g (10.2.0.5) as it is required to upgrade to 11g.
re 1. yes, create tbs and add in IGNORE=Y as import parameter
re 2. you may need to refresh data manually. create db link and merge into 10g changes. but I may not fully understand this question.
Be aware of NLS_LANG when you export out and import in for the character set conversion.
Also you may end up much bigger database at the end so setup auto increment for your tbs and check available space.
Edited by: Zoltan Kecskemethy on Apr 30, 2013 10:18 PM
[url http://docs.oracle.com/cd/B19306_01/server.102/b14238/expimp.htm#BABJHBEJ]Hope you aware that it is important which version of export and import to use
Edited by: Zoltan Kecskemethy on Apr 30, 2013 10:32 PM
added in exp-imp version info link from upgrade guide
Pl always post 4 digit versions (e.g. 18.104.22.168 or 10.2.0.3) of Oracle - "9i" and "10g" are meaningless marketing labels - along with your exact OS versions.
You can directly upgrade from "9i" (or any other version) to 11gR2 using export/import - there is no requirement to make a "pit-stop" at 10gR2.
Pl also post your exact export and import commands used, along with the first 20 lines of the export and import logs.
Posting the exact error messages and codes also helps. If the tablespaces do not exist on the target, then import will try to create them on the same exact directory path as the source. If the tablespace creation fails, then expect many downstream errors (creation of users will fail since tablespace does not exist, creation of objects will fail since users do not exist etc).
You can pre-create the tablespaces as needed, and ignore the CREATE TABLESPACE errors that the import process will report.
Yes, it is 22.214.171.124
Really? Can't expdp from 10.2.0.1 and impdp to 11.2.x.x?? Can you please point me to the possible issues from 10.2.0.1 to 11.2.x.x??
Thanks for the heads up and cautions. Appreciate it. I'll try it tomorrow.
Sorry. I'm glad to report it is 126.96.36.199
"pit-stop" requirements at 10gR2 is a requirement of the vendor ... we kinda need to play by their rules for their software piece support.
I'll try to run it again tomorrow and post the logs. Unfortunately, it's time to put on the home life and responsibilities hat now.
Thanks to both for now.
That was my plan going from 10.2.0.1 to 188.8.131.52 until I was told I needed to patch to 10.2.0.5.
At this point, I'm trying to move from 184.108.40.206 to 10.2.0.1 and upgrade the applications and apply fixes / changes from the vendor on 10.2.0.1. Once everything is done, I'll worry about upgrading 10.2.0.1 / 10.2.0.5 to 220.127.116.11. That's not to say, I don't appreciate your comments. Thank you for your opinion. I appreciate it.
Creating the tablespace first and importing using ignore=y seems to be working. It's still running, but, it does shows it's importing tables into the 10.2.0.1 environment. So, thank you so much.
Does the plan to upgrade from 10gR2 to 11gR2 also involve export/import ? If so, there is no need to apply any patchset on top of 10.2.0.1- the 10.2.0.2 patchset (or higher) is only required if you plan to upgrade the 10gR2 database to 11gR2 by either using DBUA or upgrade scripts