Re: Upgrade to 8.1.7 on NT -- Question

CompGuy wrote:
>
> Hi,
>
> I have an 8.0.5 instance running on Windows NT, and I want to upgrade
> to 8.1.7. I just took this database over and don't like a lot of
> things about it, such as the file layouts, etc. I want to upgrade
> using imp/exp versus using the upgrade script.
>
> However, I don't want to completely remove the old installation until
> the new one is up and the users have verified their applications. I
> want to install 8.1.7, build the new database (under a different
> name), and import the 8.0.5 export file. Easy enough.
>
> I want all this to basically be transparent to the users -- in other
> words, I don't want them to have to change their TNSNAMES setups to
> point to the new SID. Is there a way to "alias" the new database so
> it answers to connect requests directed to the old database?
>
> eg. client PC is setup to connect to database old_db, I install 8.1.7
> and create new db called new_db. I shut down old_db and start up
> new_db but I don't want the users to have to update their TNSNAMES.
> I want them to continue connecting to what they think is old_db but is
> actually new_db on the NT server.
>
> Is this even possible? Is this something SERVICE_NAME can help with?
>
> Thanks.

Hi.

The Service name in NT is "OracleService"%ORACLE_SID%. You cannot re-use the SID (e.g. SID1) while the other database is open. So you cannot have 2 services on one machine that have the same SID.

I think that exp/imp is a good way to go - start with a clean database with LMTs, interMedia, Java, etc.
Chances are - your opinion on using uniformly sized extents has changed since you deployed on 8.0.5.

I believe that what you are going to end up doing is this: (provided you have enough storage capacity for 2)

keep the existing 8.0.5 database open (except that its restricted during the export)
install 8.1.7 in a new home - e.g. D:\Oracle\Ora81 apply the current patches to the 8.1.7.0.0 release create a new (unique) database - lets call it SID2. export the schemas from the db where SID=SID1. import all of the objects from SID1 into SID2. Have the users verify apps against it.
When they're happy - trash the db with SID=SID2.

In an arranged downtime window (weekend): extract all user accounts, granted roles + privs, object creation scripts from db SID1.
create a final export (compress=N) and cold backup set of db SID1. (>> tape).
remove all files for db SID1.
remove services for SID1, including those for the 8.0.5 listener. reboot.
create new database with SID1.
create your tablespaces
create your users
grant privs to users
execute any pre-create scripts for altering storage parameters import schemas
move the indexes that didn't end up where you wanted them create [public] synonyms
gather database stats
switch to archivelog
export full
get a cold backup set on disk
kick off the backup to tape.

get some sleep - because Monday is going to suck.

that's one approach.

Paul Received on Thu May 24 2001 - 23:06:29 CDT