RE: Lost one in Migration

From: Kline.Michael <Michael.Kline_at_SunTrust.com>
Date: Thu, 28 Apr 2005 17:14:17 -0400
Message-ID: <52C70FF150F49E479DAF59C68A27149D010A64D7@va016a0e2.corp.suntrust.com>

It was a test box. Didn't have any backup, so we winged it.

The nice side of that is that I've got several days.

I inherited this one.

Then I found out that the export was a "user" export. So the create tablespace statements are not there. On some of those that I have inherited in the past, I'd schedule in a "no rows" empty export of the whole database. Then at least I'd have the statements.

Good old "commandments" that used to circulate in the 70's. "Thou shalt take nothing for granted. Thou shalt check up and make !@##@#$ sure." Yep..

Fortunately being test is better than finding this one out on production. But then again, production has "shadow copy". Tough backing up about 400GB on 4GB tapes. Thus no backup.

Michael Kline
Database Administration
Outside 804.261.9446
Cell 804.744.1545
3-9446  

> -----Original Message-----
> From: Mohammad Rafiq [mailto:rafiq9857_at_gmail.com]
> Sent: Thursday, April 28, 2005 4:10 PM
> To: rgramolini_at_tax.state.vt.us
> Cc: Kline.Michael; oracle-l_at_freelists.org
> Subject: Re: Lost one in Migration
>
> It happened to me once. If you have cold backup of datafiles, control
> files and redlogs then restore it and start again. Just make sure to
> set compatible to 8.1.* before migrating.....
>
> Regards
> Rafiq
>
>
> On 4/28/05, Ruth Gramolini <rgramolini_at_tax.state.vt.us> wrote:
> > I was told by Oracel Support to just change the compatible setting
and then
> > the ananlyst said "Oops' when it didn't work. I couldn't continue it
took
> > about a week to get it back. No one knew what to do. They all said
"That
> > isn't good!" We had already dismantled the old servers (32 bit) and
> > reconfigured the new 64 bit servers we had to get a workaround to
make the
> > old version (8.0.6.3) work so we could do another recovery and try
again.
> > That trace that they say works to overcome the problem doesn't work.
If
> > you can do a restore back to the 8.1.7 version you can just take out
the
> > compatible parameter and try again. If not, you may be in for a
long haul.
> >
> > If I can do anything else to help you, please let me know.
> >
> > Ruth
> >
> > -----Original Message-----
> > From: oracle-l-bounce_at_freelists.org
> > [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Kline.Michael
> > Sent: Thursday, April 28, 2005 1:49 PM
> > To: oracle-l_at_freelists.org
> > Subject: Lost one in Migration
> >
> > HPUX
> > Going from 8.1.7.4 to 9.2.0.4.
> > I and another DBA have just about exhausted our things to try.
> >
> > I had a compatible='9.2.0' in the init.ora for the 9i migration. You
> > can't do this, but must set it AFTER the migration. I had obtained a
> > copy of the init.ora from a working Version 9 and went over the
lines
> > one by one comparing them to "PFTST" to make the version 9 init.ora.
> >
> > Now I get the stuff below. I've tried using:
> > _allow_resetlogs_corruption=TRUE
> > EVENT = "10619 trace name context forever, level 1"
> > Both of which were mentioned as ways to get around the problem.
> >
> > You would think they'd test for that "invalid at this point"
setting.
> >
> > I've saved off the export, just in case.
> >
> > The log gives me this:
> >
> > alter database open resetlogs
> > Thu Apr 28 11:37:45 2005
> > RESETLOGS is being done without consistancy checks. This may result
> > in a corrupted database. The database should be recreated.
> > RESETLOGS after incomplete recovery UNTIL CHANGE 1670398987
> > Resetting resetlogs activation ID 3053850856 (0xb60610e8)
> > Thu Apr 28 11:41:26 2005
> > Errors in file

/u001/app/oracle/admin/PFTST/udump/pftst_ora_12463.trc:
> > ORA-00600: internal error code, arguments: [2765], [9.2.0.0.0], [],
[],
> > [], [], [], []
> > ORA-600 signalled during: alter database open resetlogs...
> > Thu Apr 28 11:42:47 2005
> > Shutting down instance: further logons disabled
> > Shutting down instance (immediate)
> > License high water mark = 2
> > Thu Apr 28 11:42:47 2005
> > ALTER DATABASE CLOSE NORMAL
> > ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
> > Thu Apr 28 11:42:47 2005
> > ALTER DATABASE DISMOUNT
> > Completed: ALTER DATABASE DISMOUNT
> > ARCH: Archiving is disabled
> > Shutting down archive processes
> > Archiving is disabled
> > Archive process shutdown avoided: 0 active
> > ARCH: Archiving is disabled
> > Shutting down archive processes
> > Archiving is disabled
> > Archive process shutdown avoided: 0 active
> >
> > SQL> startup mount
> > ORACLE instance started.
> >
> > Total System Global Area 2158983784 bytes
> > Fixed Size 739944 bytes
> > Variable Size 1610612736 bytes
> > Database Buffers 536870912 bytes
> > Redo Buffers 10760192 bytes
> > Database mounted.
> > SQL> alter database open
> > 2 /
> > alter database open
> > *
> > ERROR at line 1:
> > ORA-01589: must use RESETLOGS or NORESETLOGS option for database
open
> >
> > SQL> alter database open noresetlogs;
> > alter database open noresetlogs
> > *
> > ERROR at line 1:
> > ORA-01588: must use RESETLOGS option for database open
> >
> > SQL> alter database open resetlogs;
> > alter database open resetlogs
> > *
> > ERROR at line 1:
> > ORA-00600: internal error code, arguments: [2765], [9.2.0.0.0], [],
[],
> > [], [], [], []
> >
> > SQL> shutdown immediate;
> > ORA-01109: database not open
> >
> > Database dismounted.
> > ORACLE instance shut down.
> > SQL> exit
> >
> > Michael Kline

---

The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. [ST:A234]

---

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Apr 28 2005 - 17:19:04 CDT