Upgrade from 22.214.171.124 to 126.96.36.199 on Solaris 8
Has anybody encountered any issue regarding upgrading from 188.8.131.52 to 184.108.40.206? My boss does not want to spend the time on testing the upgrade (I thought I definitely should), so I try to avoid any known issues.
Also, when running DB upgrade assistant, if I have a 8i DB with 10GB, do I need to ensure I have at least 10GB free space available for it to use as temp storage? In other words, does it convert the DB on the spot or convert by copying/modifying piece by piece?
Your boss should be sacked (maybe he/she will be once you have attempted the upgrade!)
If I were you I would refuse to do it without testing.
There could be a whole variety of different issues that may occur.
e.g. your application could be utilising svrmgr - obsolete in 9i.
Another issue that springs to mind is the added default security of the data dictionary, without the appropriate initialisation parameter, application queries of the DD will fail.
....and there may be others. Always test such upgrades first!
Else, get your boss to sign something!!
Re: Upgrade from 220.127.116.11 to 18.104.22.168 on Solaris 8
I suggest not using the assistant with that 10G DB. Make an empty 9.2 DB, create the tablespaces, users, grant them their priveleges, export the 8i DB and import into 9i.
I have done about 50 upgrades this way.
Oracle Certified Master
Oracle Certified Professional 6i,8i,9i,10g,11g,12c
I'm with Julian, for your small db of 10GB, EXP/IMP is by far the simpilist and the least risky. Create your DB, tablespace exp, imp. If you have only ONE main Oracle schema, perform EXP/IMP on the schema.
You may need to exp/imp through a named pipe, but there is DEFINATLY a thread in these forums, in which I posted in, that can help you with that syntax. Search on "gzip_pipe" and you'll find it.
That's how I perform the majority of my migrations.
OCP 8i, 9i DBA
I disagree. I think ODMA is by far the easiest way to upgrade a 10G database (Assuming your database is setup the way you want it).
First, you are obviously concerned about space. exp/imp method requires you to have at least double the disk space.
Second, Why would you want to spend all that time using exp/imp when you can do a backup and convert your database with dbca in less time than it would take to exp a 10G database?
Third, Why would you want to deal with creating a bunch of users, making sure the passwords are correct, re-granting permissions, makeing sure everything is valid, changing the tnsnames.ora on every client, etc.
Lastly, I think exp/imp is the MOST risky method since you essentially have an entirely new database with multiple changes.
To do a 10G exp/imp right, you're probably looking at 1/2 day or more. ODMA, 2 hours at the most.
I agree with the old man...
ODMA is the fastest if you are performing the upgradation on the same OS or on different platforms having same OS. But export import is the only way to do it if across platforms having different OS.
More ever if we use ODMA, its keeps a backward compatibility and more ever its like the same old database with new features. While doing export import its like importing data into totally new database.
There is a possiblity that using export import may lead to few initial issues because of new database. I did face a few problems using export import while upgrading to 9i where the snapshots were converted to tables and had to use ODMA instead.
Any way ODMA is still the fastest.
"There is a difference between knowing the path and walking the path."
Click Here to Expand Forum to Full Width