|
|
|
"Upgrading 8.1.5 to 8.1.7"
From the DBA Pipelines
|
Upgrading 8.1.5 to 8.1.7 (1 of 7), Read 91 times |
|
|
Conf: |
|
|
From: |
|
|
Date: |
Wednesday, April 04, 2001 11:36 AM |
I am currently on 8.1.5, Compaq tru64 unix 4.0.F. I am planning to upgrade to 8.1.7 and was wondering if anyone has any words of wisdom. We have 3 production databases ranging from 50 Gig to 100Gig. Does anyone have an opinion on using the upgrade utility versus an export/import to do the upgrade? Any experiences, or documentation would be appreciated.
Thanks in advance for your reply.
Jim
|
Topic: |
Upgrading 8.1.5 to 8.1.7 (2 of 7), Read 67 times |
|
Conf: |
|
|
From: |
|
|
Date: |
Wednesday, April 04, 2001 03:26 PM |
every dba has his own way of doing it. I would clone a prod, upgrade the prod and test it. If it is a small database I would use the exp/imp , if it is a large database I would use the mig utility, I will document it and test the upgrade again as per the document. If the test upgrade does not go as per the document then re-test it and document again. The prod upgrade should go perfectly as per the document, otherwise don't do it. 8.1.5 to 8.1.7 should be a breeze, but remember to have a contingency plan, clone the entire prod to a test before upgrading and taking all those backups. In case the upgrade fails you have a test that can be brought online as prod till the prod is fixed. Also check the 8.1.6 and 8.1.7 bug list.
|
Topic: |
Upgrading 8.1.5 to 8.1.7 (3 of 7), Read 68 times |
|
Conf: |
|
|
From: |
|
|
Date: |
Wednesday, April 04, 2001 03:49 PM |
Defiantly test the upgrade on a test database. Run an application regression test.
You don't need to exp/imp the database to do the upgrade, or even need to use the migration utility (and you would NOT use the mig utility for 8.1.5 to 8.1.7)! Just use the proper upgrade script and do the upgrade manually. It's generally very simple. For 8.1.5 to 8.1.7 just:
Shutdown the 8.1.5 database.
Startup the 8.1.5 database under 8.1.7 software in restricted mode.
Run the upgrade script (u0801050.sql)
Run catalog, catproc, etc after the end of the upgrade. These are run in the U scripts, but I like to run them again for good measure.
Re-Validate any PL/SQL procedures that might have been invalidated during the upgrade.
I would suggest that manual upgrades are better for a few reasons. First, they give the DBA a better sense of what is going on. They also give the DBA a better sense of what is going wrong if something fails. It also helps make a better DBA because they know how to do the upgrade by hand, thus they understand the process rather than expecting some GUI to do it for them. GUI's fail, and if they fail you need to understand the process so you can complete it if need be.
YMMV,
RF
Robert
G. Freeman
Oracle 7.3, 8 and 8i OCP
"If you don't have a database, get one!"
|
Topic: |
Upgrading 8.1.5 to 8.1.7 (4 of 7), Read 68 times |
|
Conf: |
|
|
From: |
|
|
Date: |
Wednesday, April 04, 2001 04:07 PM |
I just upgraded from 8.1.6 to 8.1.7 on Windows2000 using the Oracle Migration Assistant tool. What a breeze?
Just make sure you have a good cold backup before you start.
Install 8.1.7 in it's own Oracle Home
Run Data Migration Tool Assistant
Copy tnsnames.ora, sqlnet.ora, listener.ora and pfile over to the right folders and you should be all set.
Good luck
Jeff
Gallant
ERP Systems Manager/Oracle DBA, OCP
Beers Construction Company
Atlanta, Ga
|
Topic: |
Upgrading 8.1.5 to 8.1.7 (5 of 7), Read 73 times |
|
Conf: |
|
|
From: |
|
|
Date: |
Wednesday, April 04, 2001 04:35 PM |
On 4/4/01 3:49:00 PM, Robert Freeman wrote:
1. Defiantly test the upgrade on a test database. Run an application regression test.
2. You don't need to exp/imp the database to do the upgrade, or even need to use the migration utility (and you would NOT use the mig utility for 8.1.5 to 8.1.7)! Just use the proper upgrade script and do the upgrade manually. It's generally very simple. For 8.1.5 to 8.1.7 just:
Shutdown the 8.1.5 database.
Startup the 8.1.5 database under 8.1.7 software in restricted mode.
Run the upgrade script (u0801050.sql)
Run catalog, catproc, etc after the end of the upgrade. These are run in the U scripts, but I like to run them again for good measure.
Re-Validate any PL/SQL procedures that might have been invalidated during the upgrade.
I
would suggest that manual upgrades are better for a few reasons. First, they
give them DBA a better sense of what is going on. They also give the DBA a
better sense of what is going wrong if something fails. It also helps make a
better DBA because they know how to do the upgrade by hand, thus they understand
the process rather than expecting some GUI to do it for them. GUI's fail, and if
they fail you need to understand the process so you can complete it if need be.
YMMV,
RF
Robert
G. Freeman
Oracle 7.3, 8 and 8i OCP
"If you don't have a database, get one!"
Hi Robert,
I have a question for you as I know you have do a lot of migration. Several month ago, I have upgrade one DB on Linux RH 6.2 from 8.0.5.1 to 8.1.6.1. When I try to bring up the DB with new Oracle executables, I kept getting end of communication error which prevented me from open the DB. I ended up with re-creating the control file, then run the uxxx script. At this time, everything worked fine. When I look back today, I realized the problem might be that I set compatible to 8.1.6 at that time. If I set it to 8.0.5, I might not have this problem. Since I do not have another environment to test it again, what do you think?
Thanks,
T.
Wu
OCP DBA
|
Topic: |
Upgrading 8.1.5 to 8.1.7 (6 of 7), Read 75 times |
|
Conf: |
|
|
From: |
|
|
Date: |
Wednesday, April 04, 2001 05:28 PM |
My suggestion were for 7 to 8 to 8i, And as I said earlier 8.1.5 to 8.1.7 OR 7.3.0 to 7.3.5 is still a breeze.Only the server gets upgraded and the scripts are run to fix the bugs.
Migrating and upgrading pretty confusing terminology.
|
Topic: |
Upgrading 8.1.5 to 8.1.7 (7 of 7), Read 53 times |
|
Conf: |
|
|
From: |
|
|
Date: |
Thursday, April 12, 2001 07:53 AM |
Robert:
"Defiantly
test"?? LOL!
:)