We did this in order to get a test db up in a new
environment that would eventually become production.
We knew that for the production cut over, it
would be a cold backup/restore to a new server, so
there was no risk in trying it.
By causing a log switch immediately after taking the
tablespaces out of backup mode, I am making sure
that all transactions that have all transactions that
have hit the DB up until that point.
I have also used this technique to move/clone and
upgrade 8.0.5 databases to 8.1.6 and 8.1.7 for
testing environments and have never enountered any
problems. I would NEVER NEVER NEVER (is that
enough nevers?) use this to generate a
new production system.
I did not recover the database in 8.1.7 and
then upgrade because the
destination machine did not have the 8.1.7 code installed
on it at that time.
----
Matt Adams - GE Consumer Products - [EMAIL PROTECTED]
Contrary to popular opinion, Unix is user friendly.
It's just particular about who it makes friends with.
-----Original Message-----
From: Hemant K Chitale [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 25, 2003 9:19 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Quick Question -- 8.1.7 logs applied to 9.2.0 database
Courageous and it looks like it worked. But this wouldn't be supported by
Oracle.
Why did you have to go by time ? Why not recover until cancel and apply
all available archive logs ? Ensure that your online redo logs with the last
few transactions are also archived out of the 8.1.7 environment and then
recover till the last archive.
I would apply all the archive logs in 8.1.7, recover the database in 8.1.7
and then upgrade it to 9.2.
Hemant
At 01:29 PM 24-03-03 -0800, you wrote:
>I did this a couple of weeks ago. The answer is yes, but you recover
>first, then upgrade.
>
>You've got to
>
>0) Note the sequence number of the log file being written
>to in the source database before you start.
>1) put source in hot backup mode
>2) copy files to new destination
>3) take source out of backup mode
>4) NOTE the date/time
>5) 'alter system switch logfile' on the source
>6) copy all archived log files from the one
> noted in the step 0 to the most recent (inclusive) to destination
>7) (optional) on source, do a 'alter database backup controlfile to trace'
>8) (optional) copy the trace file to destination
>9) (optional) using the 9.2.0 executables, use trace file to re-create
>control file, renaming database
>10) on destination do 'alter database recover automatic until time 'TIME
>NOTED IN STEP 4' using backup controlfile'
> The 9.2.0 executables can read and understand log files from 8.1.7
>11) on destination do 'alter database open resetlogs'
>12) On destination, perform steps for manual upgrade from 8.1.7 to 9.2.0
>13) Celebrate with a couple of truely great beers (i recommend Sierra
>Nevada Celebration Ale)
>
>Good luck
>
>----
>Matt Adams - GE Appliances - [EMAIL PROTECTED]
>Contrary to popular opinion, Unix is user friendly.
>It's just particular about who it makes friends with.
>
>
>----
>Matt Adams - GE Appliances - [EMAIL PROTECTED]
>Contrary to popular opinion, Unix is user friendly.
>It's just particular about who it makes friends with.
>
>-----Original Message-----
>From: Nick Wagner [mailto:[EMAIL PROTECTED]]
>Sent: Monday, March 24, 2003 3:24 PM
>To: Multiple recipients of list ORACLE-L
>Subject: Quick Question -- 8.1.7 logs applied to 9.2.0 database instance?
>
>Can I take a hot backup of an 8.1.7 instance... and then upgrade the
>backup to 9.2.0 (upgrading data dictionary tables and everything) and then
>apply logs created by the 8.1.7 instance to this 9.2.0 backup?
>
>Please answer as soon as possible...
>
>Thanks!
>Nick Wagner
>
>
