The dreaded ora 600 errors

I have a problem that needs fixing.

I am doing an operating system database datafile copy from one database to another database where all the file systems have been trashed.

Problem:

My target database was closed(seeing there are no file systems) but the source database was open when I kicked off the copy.
After about 10 minutes I discovered what was happening and I stopped the copy. Only about 4 files had been copied to the target location.

I shut down my source database normally, deleted the four files on the target database and kicked off the copy again.

When the copy was finished I opened the source database normally and issued the alter database create controlfile .

I edited the file to reflect my target database and when I ran the script on my target database it worked and the database mounted.
When I go to open the database it fails with error

This is en extract from my alert log file

CREATE CONTROLFILE REUSE set DATABASE "G_T2" RESETLOGS NOARCHIVELOG

Completed: CREATE CONTROLFILE REUSE set DATABASE "G_T2" RESET..

alter database open resetlogs
Tue Oct 2 07:31:23 2001
RESETLOGS after incomplete recovery UNTIL CHANGE 1924631670400
Tue Oct 2 07:31:36 2001
Thread 1 opened at log sequence 1
Current log£ 4 seq£ 1 mem£ 0: /g_t2/i2_redo2/gmi2/redo/log_4_gmi2.dbf
Current log£ 4 seq£ 1 mem£ 1: /g_t2/i2_redo2m/gmi2/redo/log_4m_gmi2.dbf
Successful open of redo thread 1.
Tue Oct 2 07:31:36 2001
SMON: enabling cache recovery
SMON: disabling cache recovery
Tue Oct 2 07:31:37 2001
ORA-1534 signalled during: alter database open resetlogs...
Tue Oct 2 07:31:57 2001
Shutting down instance (normal)
License high water mark = 1
Tue Oct 2 07:31:57 2001
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
Tue Oct 2 07:31:57 2001
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
Tue Oct 2 07:34:40 2001

Tue Oct 2 07:34:44 2001
alter database mount exclusive
Tue Oct 2 07:34:45 2001
Successful mount of redo thread 1.
Tue Oct 2 07:34:45 2001
Completed: alter database mount exclusive
Tue Oct 2 07:34:58 2001
alter database open resetlogs
Tue Oct 2 07:34:59 2001
ORA-1139 signalled during: alter database open resetlogs...
Tue Oct 2 07:35:19 2001
alter database open
Tue Oct 2 07:35:19 2001
Errors in file /g_t2/big0c/I2/traces/ora_19190.trc:
ORA-00600: internal error code, arguments: [3668], [1], [3], [7649], [7649], [26
0], [], []
ORA-600 signalled during: alter database open
...
Tue Oct 2 07:36:36 2001
Shutting down instance (normal)
License high water mark = 1
Tue Oct 2 07:36:36 2001
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
Tue Oct 2 07:36:36 2001
ALTER DATABASE DISMOUNT

I have checked the source database which is still running and there are no datafiles needing recovery.

Can someone please help.

I know this is long

thanks

Janet

A file needs media recovery.
Argument Description to ORA-00600 [3668] [a][b][c][d][e]

a. File number needing media recovery

look in v$datafile

thanks PIPO i already checked the v$datafile,v$recovery and even used OEM and all the files look okay.

I think a simple question could be

1. can a datafile become corrupt because its been physically copied to another location without taking it offline or shutting the database down first?

2. The database in which these datafiles are is up and running and all datafiles are online with no status of needing recovery

.... so if the datafiles are corrupt can the database still be funcioning well?

Quote:

---

Originally posted by janet
thanks PIPO i already checked the v$datafile,v$recovery and even used OEM and all the files look okay.

I think a simple question could be

1. can a datafile become corrupt because its been physically copied to another location without taking it offline or shutting the database down first?

---

Your source datafile, No. If you think your error is because of corrupt data files, I would shutdown the source database, copy the files to the EXACT same location on the new box, use a utility like diff or cksum to verify the files are exactly the same, and restart your database on the target box. Once the DB comes up, you can rename it and move data files.

Quote:

---

2. The database in which these datafiles are is up and running and all datafiles are online with no status of needing recovery

.... so if the datafiles are corrupt can the database still be funcioning well?

---

It's probably not an issue with your source database.

By any chance you have copied the files to nfs directory and the target database is using files on nfs mount? That could be the reason for this error. Unless oracle has validated their databases to work on nfs mounted devices like netapp, they don't work well on nfs mounted directories.