Reg:recovery of datafile

SQL> alter database open resetlogs;
ORA-01190: control file or data file 1 is from before the last RESETLOGS
ORA-01110: data file 1: '/dbdata/oft1/oft1_system01.dbf
can any one solve this please
o/s info:
SunOS s96dbt01 5.10 Generic_120011-14 sun4u sparc SUNW,SPARC-Enterprise

hi,
01190, 00000, "control file or data file %s is from before the last RESETLOGS"
// *Cause: Attempting to use a data file when the log reset information in
//          the file does not match the control file. Either the data file
//          or the control file is a backup that was made before the most
//          recent ALTER DATABASE OPEN RESETLOGS.
// *Action: Restore file from a more recent backup.thanks,
baskar.l

Similar Messages

Data recovery from Datafiles of corrupted database ?

Hi all
Actullay one of my databse(Oracle 9i) is corrupted and i dnt have .dmp files . so i inatlled the new databse.
before that i copied the oradata folder from prevous database( Is not running right now)
is there any way to restore the prevoius data from the files that i have in oradata folder to the new instance.
thanks & regards
Vivek

Has the database - even when it was corrupted - been shutdown cleanly ?
If yes, and only if you have all the files, it should be startable.
If any of the datafiles is corrupted and it prevents database startup, you can always try following:
startup mount
alter database datafile <filename> offline drop;
If the database is/was in archivelog mode you can omit the "drop" and only put it offline.
As soon as all corrupted datafiles are put offline, including all not corrupted from the same tablespace, the database should be able to open.
Keep in mind that this is only true for datafiles not belonging to SYSTEM/SYSAUX or other Instance dependant tablespaces;
I don't think you can restore data from corrupted datafiles, unless you're able to recover them

REG: Recovery Disc - HP Pavilion G6-2231TX

Dears,
I have replaced my HDD and I not able to recover the OS. I logged new ticket in HP support and i sent my bill copy to the mail id which is given by support engineer from HP. I have received a mail regarding that ticket is closed with the comments "The recovery disc was Posted to address given in the Bill copy".
Query:
I didn't receive the recovery disc via postal, even 3 days past after the ticket was closed. Anyone can help me, what to do now or how can i track the postal?

Hello Aravinthan,
I have raised this post to the appropriate team for review. Someone should contact you via private message in these forums. It may take up to two days for someone to contact you. Private messages can be checked by signing in and clicking on the envelope icon at the top of the page.
Clicking the White Kudos star on the left is a way to say Thanks!
Clicking the 'Accept as Solution' button is a way to let others know which steps helped solve the problem!

Recovery of datafile which is in RECOVER state in NOARCHIVELOG mode

Hi,
i have following datafile in recover state
12 /oradata/ORADATA/undo_tbs.dbf OFFLINE
I tried to recover but getting following errors....
SQL> recover datafile 12;
ORA-00279: change 29659636 generated at 03/26/2011 00:47:23 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/product/10.2.0/flash_recovery_area/ORCL/archivelog/2011_04_07/o1_mf_1_4608_%u_.arc
ORA-00280: change 29659636 for thread 1 is in sequence #4608
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log '/u01/app/oracle/product/10.2.0/flash_recovery_area/ORCL/archivelog/2011_04_07/o1_mf_1_4608_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
due to this datafile we r not able to create tables...is there any solution except restoring from backup...Pl helppp

SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 6150
Current log sequence 6153
SQL>
this is the output
Edited by: 850520 on Apr 7, 2011 2:46 AM

Datafile Incomplete recovery

Hi,
I am using oracle database 10g(10.2.0.10) in RHEL5. I want to perform a point in time recovery a datafile from backup. Through RMAN i issued the following command
RMAN> run{
2> sql "alter session set nls_date_format=''dd-mon-yyyy hh24:mi:ss''";
3> set until time '21-aug-2011 13:04:00';
4> restore datafile 4;
5> recover datafile 4;
6> alter database open resetlogs;}
But RMAN performed complete recovery. Again i deleted the datafile and restore the datafile from backup. Now i issued the following command in SQL prompt
SQL> alter session set nls_date_format='dd-mon-yyyy hh24:mi:ss';
Session altered.
SQL>recover datafile '/u01/app/oracle/oradata/ORATESTDB/datafile/o1_mf_users_751h7fmh_.dbf' UNTIL TIME '21-aug-2011 13:04:00';
ORA-00274: illegal recovery option UNTIL
It shows the above error. But i am able to perform Incomplete recovery of whole database using the same RMAN command as shown above.
Does datafile point-in-time recovery is not possible?????? or Is there anything wrong in my approach?????
Regards,
007

A Datafile cannot be recovered to a point in time that is incosistent with the rest of the database.
(why ? Data Integrity !!!! A table with multiple extents may span multiple datafiles. You cannot have some extents with data as of 12:05 and other extents in another datafile recovered with data as of 10:05 !! Even if it is a single datafile tablespace, you will be violating referential integrity (whether enforced or not) if, say, the SALES table has entries upto 12:05 but the SALES_LINES table has entries upto 10:05 !!)
You can do a Tablespace Point In Time Recovery using an Auxiliary Instance and then copy the whole tablespace back. You have to ensure that Integrity is maintained.
Hemant K Chitale

실수로 TABLE을 DELETE 또는 DROP한 경우 복구 방법 (time-based recovery)

제품 : ORACLE SERVER
작성날짜 : 2004-07-29
PURPOSE
사용자의 실수로 중요한 데이타를 delete 하였거나, 테이블을 drop하였을
경우 복구하는 절차를 정리한 자료이다.
Explanation
사용 중인 database 의 archive log mode 여부를 다음과 같이 확인 후
archive log mode인지 아닌지에 따라 복구 방법이 달라진다.
os>svrmgrl
SVRMGR> connect internal;
SVRMGR> archive log list
Database log mode ARCHIVELOG
Automatic archival ENABLED
Archive destination ?/dbs/arch
Oldest online log sequence 2525
Current log sequence 2527
1. Archive mode인 경우 복구 방법
archive log mode로 운영중이면서 full backup및 archive file들이 모두
존재하는 경우 복구가 항상 가능하다.
이때 다시 다음과 같이 두가지의 경우를 구분하여 복구 작업을 수행할 필요가
있으며 아래에 각각의 경우에 대한 절차를 자세히 설명한다.
(1) drop이나 delete한 시점이 얼마 지나지 않았거나, 혹은 필요에 의해
database 전체를 data 손실 이전 시점으로 돌리고자 하는 경우
(2) 손실된 data만을 drop이나 delete이전 상태를 받아내고, 나머지 data는
모두 drop/delete이후 발생한 transaction의 반영분을 유지시키기 위해
현재 시점으로 맞추어햐 하는 경우
1-1 database 전체를 drop이나 delete 이전시점으로 돌리고자 할 때
이러한 경우는 데이타 손실이 발생하기 이전의 datafile들에 대한 backup을
restore한 후 손실 발생 시점 직전까지 time based로 imcomplete recovery를
수행하면 된다.
(1) db를 shutdown시킨 후 현재 상태를 만약의 경우를 대비하여 cold
backup을 받아둔다.
shutdown immediate로 db를 내리고, datafiles, redo log files, control
files 모두 tar등의 명령어를 이용하여 backup을 받아둔다.
이것은 만약의 경우 이전 backup이나 archive file에 문제가 있는 경우,
삭제된 data의 복구가 불가능할 경우 현재 상태로라도 돌리기 위한
것이다.
(2) 데이타를 삭제하기 이전 상태에서 받아둔 datafile full backup을
restore한다.
redo log files과 controlfiles은 현재 것을 그대로 이용하고, 현재
상태의 모든 datafiles을 지우고 데이타가 삭제되기 전에 받아둔
backup datafile을 restore시킨다.
(temp datafile의 경우는 restore시간을 줄이기 위해 restore하지
않아도된다.)
(3) restore한 backup시점 이후의 archive file들을 archive log
destination에 위치시킨다.
full backup 이후의 archive file들을 일부 tape 장비등에 backup을
받아두고 지운 상태라면 그러한 file을을 다시 원래 위치에 restore
하여, full backup받은 시점부터 복구하고자 하는 시점까지의
archive log file들이 모두 log archive destination에 존재하는지
확인한다.
(4) 데이타 삭제 이전 시점까지 time based로 recover를 수행한다.
이때 날짜와 시간 지정은 항상 아래 예와 같은 형식으로 지정한다.
만약 데이타를 삭제한 시간이후로 지정하게 되면 recovery후에도
여전히 data는 지워진 상태로 보여진다.
os>svrmgrl
SVRMGR> connect internal
SVRMGR> startup mount;
SVRMGR> set autorecovery on
SVRMGR> recover database until time '2001-01-30:21:00:00';
SVRMGR> alter database open resetlogs;
(a) 만약 이때, controlfile이 현재것이 존재하지 않아 datafile뿐
아니라, controlfile도 과거것을 사용했다면, recovery command를
다음과 같이 지정하면 된다.
recover database using backup controlfile (아래줄과 이어짐)
until time '2001-01-30:21:00:00';
(b) temp datafile을 restore하지 않은 경우라면 startup mount수행
직후 다음과 같은 문장을 추가하면 된다.
alter databse datafile '/oracle/oradata/temp01.dbf'
offline drop;
/oracle/oradata/temp01.dbf는 temp datafile의 이름을 예로 든
것이다.
(5) 원하는 data가 제대로 조회되는지 확인한다.
1-2. 삭제된 data만을 복구하고 나머지는 현재 상태를 유지하고자 하는 경우
이러한 경우는 데이타가 삭제되기 이전 상태의 backup datafile 중에
SYSTEM, RBS와 삭제된 data가 들어있는 datafile만을 restore시켜 time
based로 recovery하여 db를 open시킨 후 원하는 table만 export를 받아낸다.
그리고 다시 현재 상태의 db에 export받은 내용을 import시키는 것이다.
이때 삭제된 data를 export받기까지의 절차에 대해서 다음과 같이 세가지
경우의 방법을 생각할 수 있다.
(a) 다른 시스템에 backup이나 test용으로 oracle이 설치되어 있는 경우
그 시스템에 backup을 restore하여 해당 table을 export 받는 방법
(b) 같은 시스템에 backup을 restore 하되, db name과 oracle_sid를 다른
이름으로 변경하여 다른 db를 만들어 recovery후 open하여 export받는
방법 <Bulletin:11616 참조>
(c) 현재 db는 cold backup받아 두고, backup을 restore하여 export을
받아내는 방법
여기에서 (a)의 경우는 다른 시스템에 이용하고자 하는 datafile의 oracle
version 이상의 oracle software가 이미 설치되어 있어야 한다.
(b)의 경우는 현재 상태의 cold backup을 받았다가 export받은 후 다시
현재 상태를 restore할 필요는 없애주지만, 대신 SYSTEM, RBS, user
datafile 만큼의 disk space가 추가로 필요하며, 새로운 db를 추가로
구성하는 것이므로 init.ora file 구성 등의 작업이 필요하다.
이것에 관한 자세한 절차는 <Bulletin:11616>을 참조하도록 한다.
이 자료에서는 이중 (c)에 대한 것만을 자세히 설명한다.
(1) 현재의 모든 datafiles과 redo log files, datafiles을 다음과 같이
신중히 cold backup을 받아두도록 한다.
이것은 이후에 삭제한 data를 복구하여 export를 받은 후에 다시 현재
상태의 db로 되돌아오기 위한 것이다.
단 이 때 tar 등을 이용하여 cold backup하는 대신에 disk 상에 cold
backup을 받아 시간을 절약할 수 있다. disk로의 backup이 가능한
이유는 export를 위한 time based recovery를 수행하기 위해 필요한
datafile이 SYSTEM, RBS, 삭제된 data를 포함한 user datafile
정도이기 때문이다.
os>svrmgrl
SVRMGR> connect internal
SVRMGR> shutdown immediate;
SVRMGR> exit
os>cp /oracle/oradata/*.ctl /oracle/backup/*.ctl
os>cp /oracle/oradata/redo*.log /oracle/backup/redo*.log
os>mv /oracle/oradata/system01.dbf /oracle/backup/system01.bak
os>mv /oracle/oradata/rbs01.dbf /oracle/backup/rbs01.bak
os>mv /oracle/oradata/tools01.dbf /oracle/backup/tools01.bak
redo log file이나 controlfile의 경우는 time based recovery시에도
필요하므로 cp를 받아두고, datafile의 경우는 mv를 이용하도록 한다.
위의 예에 제시된 file이름들은 해당 환경에 맞게 변경되어야 하며,
tar를 이용하여 tape에 옮겨도 관계는 없으나, 단 cold backup에
해당하는 모든 datafiles, redo log files, control files를 받아두어야
한다.
(2) 삭제한 data가 존재할 당시에 받아둔 backup에서 SYSTEM datafile, RBS
datafile, 그리고 삭제한 table이 들어있는 datafile만을 restore한다.
redo log files과 controlfiles은 현재 것을 그대로 이용한다.
(3) restore한 backup시점 이후의 archive file들을 archive log
destination에 위치시킨다.
full backup 이후의 archive file들을 일부 tape 장비 등에 backup을
받아두고 지운 상태라면 그러한 file을을 다시 원래 위치에 restore
하여, full backup받은 시점부터 복구하고자 하는 시점까지의
archive log file들이 모두 log archive destination에 존재하는지
확인한다.
(4) restore하지 않을 datafile, 즉 SYSTEM, RBS, 삭제된 data를 포함하
는 user datafile을 제외한 모든 datafile은 모두 offline drop시키
고, 데이타 삭제 이전 시점까지 time based로 recover를 수행한다.
이때 날짜와 시간 지정은 항상 아래 예와 같은 형식으로 지정한다.
만약 데이타를 삭제한 시간이후로 지정하게 되면 recovery후에도
여전히 data는 지워진 상태로 보여진다.
os>svrmgrl
SVRMGR> connect internal
SVRMGR> startup mount;
SVRMGR> alter database datafile '/oracle/oradata/temp01.dbf'
offline drop; (윗줄과 이어짐)
SVRMGR> alter database datafile '/oracle/oradata/userdata05.dbf'
offline drop; (윗줄과 이어짐)
... 이와 같이 resotre하지 않은 datafile을 모두 offline drop시킨다.
SVRMGR> set autorecovery on
SVRMGR> recover database until time '2001-01-30:21:00:00';
SVRMGR> alter database open resetlogs;
만약 이때, controlfile이 현재것이 존재하지 않아 datafile뿐 아니라,
controlfile도 과거것을 사용했다면, recovery command를 다음과 같이
지정하면 된다.
SVRMGR>recover database using backup controlfile until time
'2001-01-30:21:00:00'; (윗줄과 이어짐)
(5) 원하는 data가 제대로 조회되는지 확인한 후 필요한 table을 export한다.
예를 들어 scott user의 dept table을 복구하고자 한것이었다면 다음과
같이 export를 받는다.
os>exp scott/tiger file=dept.dmp tables=dept log=deptlog1
(6) time based로 recovery후 open한 db는 shutdown하여 없애고 (1)번에서
받아둔 현재 상태의 backup을 restore한다.
shutdown은 immediate나 abort 모두 가능하며, shutdown후 restore한
SYSTEM, RBS, user datafile모두 삭제하고, 사용하던 controlfiles,
redo log files도 모두 삭제한다.
그리고 (1)에서 mv나 cp로 (혹은 tar로) 옮겨놓은 모든 datafiles,
controlfiles, redo log files를 원래의 directory와 이름으로
위치시킨다. SYSTEM, RBS, user datafile도 반드시 (1)번 상태의
현재 상태 backup을 restore하여야 한다.
(7) db를 startup시킨 후 (5)에서 받은 export내용을 import시킨다.
os>imp scott/tiger file=dept.dmp tables=dept ignore=y commit=y
log=deptlog2 (윗줄과 이어짐)
(8) 원하는 data가 제대로 조회되는지 확인한다.
2. No archive mode 로 운영할 경우 복구 방법
archive mode 로 운영하지 않았을 경우에는, 삭제한 data를 export 받아
두었거나, 혹은 data가 삭제 전 받아둔 cold backup이 존재하는 경우
복구가 가능하다.
(1) export가 존재하는 경우
다음과 같이 import한다. scott user의 dept가 삭제된 경우를 예로 들었다.
os>imp scott/tiger file=dept.dmp tables=dept ignore=y commit=y log=log1
(2) cold backup이 존재하는 경우
다른 시스템에 사용가능한 oracle engine이 설치되어 있다면, 그곳을
이용하거나, 혹은 현재 database를 backup받아둔후 현재 시스템에
restore하여 export를 받아낼 수 있다.
(1) 현재의 모든 datafiles과 redo log files, datafiles을 다음과 같이
신중히 cold backup을 받아두도록 한다.
이것은 이후에 삭제한 data를 복구하여 export를 받은 후에 다시 현재
상태의 db로 되돌아오기 위한 것이다.
단 이 때 tar 등을 이용하여 cold backup하는 대신에 disk 상에 cold
backup을 받아 시간을 절약할 수 있다. disk로의 backup이 가능한
이유는 export를 위한 time based recovery를 수행하기 위해 필요한
datafile이 SYSTEM, RBS, 삭제된 data를 포함한 user datafile
정도이기 때문이다.
os>svrmgrl
SVRMGR> connect internal
SVRMGR> shutdown immediate;
SVRMGR> exit
os>mv /oracle/oradata/*.ctl /oracle/backup/*.ctl
os>mv /oracle/oradata/redo*.log /oracle/backup/redo*.log
os>mv /oracle/oradata/system01.dbf /oracle/backup/system01.bak
os>mv /oracle/oradata/rbs01.dbf /oracle/backup/rbs01.bak
os>mv /oracle/oradata/tools01.dbf /oracle/backup/tools01.bak
위의 예에 제시된 file이름들은 해당 환경에 맞게 변경되어야 하며,
tar를 이용하여 tape에 옮겨도 관계는 없으나, 단 cold backup에
해당하는 모든 datafiles, redo log files, control files를 받아두어야
한다.
(2) 삭제한 data가 존재할 당시에 받아둔 backup에서 SYSTEM datafile,
RBS datafile, 그리고 삭제한 table이 들어있는 datafile만을
restore한다.
backup당시의 redo log files과 controlfiles도 restore하여야 한다.
(3) restore하지 datafile, 즉 SYSTEM, RBS, 삭제된 data를 포함하는 user
datafile을 제외한 모든 datafile은 모두 offline drop시키고,
database를 open시킨다.
os>svrmgrl
SVRMGR> connect internal
SVRMGR> startup mount;
SVRMGR> alter database datafile '/oracle/oradata/temp01.dbf'
offline drop; (윗줄과 이어짐)
SVRMGR> alter database datafile '/oracle/oradata/userdata05.dbf'
offline drop; (윗줄과 이어짐)
... 이와 같이 resotre하지 않은 datafile을 모두 offline drop시킨다.
SVRMGR> alter database open;
(4) 원하는 data가 제대로 조회되는지 확인한 후 필요한 table을 export
한다.
예를 들어 scott user의 dept table을 복구하고자 한 것이었다면
다음과 같이 export를 받는다.
os>exp scott/tiger file=dept.dmp tables=dept log=deptlog1
(5) exprot받아낸 database는 shutdown하여 없애고 (1)번에서 받아둔
현재 상태의 backup을 restore한다.
shutdown은 immediate나 abort 모두 가능하며, shutdown후 restore한
SYSTEM, RBS, user datafile모두 삭제하고, 사용하던 controlfiles,
redo log files도 모두 삭제한다.
그리고 (1)에서 mv나 tar로 옮겨놓은 모든 datafiles, controlfiles,
redo log files를 원래의 directory와 이름으로 위치시킨다.
(6) db를 startup시킨 후 (4)에서 받은 export내용을 import시킨다.
os>imp scott/tiger file=dept.dmp tables=dept ignore=y commit=y
log=deptlog2 (윗줄과 이어짐)
(7) 원하는 data가 제대로 조회되는지 확인한다.

Relocating ASM datafiles within the same diskgroup

Hi all experts,
We are in windows 2008R2 11gr2 RAC 2 nodes cluster. I want to move +DATA/Tag/datafiles to +DATA/tag1/datafiles. tag1 folder already is exist in diskgroup. Can you please describe the process to do? I want to relocate all datafiles including system and sysaux. Is the process similiar to moving another disk group or the process is different?

This document explains how to move an ASM datafile to another diskgroup.
Step-By-Step
1. Get the name of the datafile to be moved.
. oraenv
ORACLE_SID = [oracle] ? Enter DB Sid
sqlplus '/ as sysdba'
SQL> select tablespace_name, file_name, file_id file# from dba_data_files where tablespace_name = 'MYTSP';
2. List the available ASM disk groups.
. oraenv
ORACLE_SID = [oracle] ? Enter DB Sid
sqlplus '/ as sysdba'
SQL> SELECT name FROM v$asm_diskgroup;
3. Take the ASM data file to be moved OFFLINE
. oraenv
ORACLE_SID = [oracle] ? Enter DB Sid
sqlplus '/ as sysdba'
SQL> alter database datafile 'my_datafile_name' offline;
4. Copy the datafile to the new diskgroup using RMAN
rman target /
RMAN> copy datafile 'my_datafile_name' to '+my_new_disk_group';
RMAN> exit;
5. Rename the ASM database file.
. oraenv
ORACLE_SID = [oracle] ? Enter DB Sid
sqlplus '/ as sysdba'
SQL> alter database rename file 'my_datafile_name' TO 'my_new_datafile_name';
SQL> exit
6. Switch to the new datafile using RMAN
rman target /
RMAN> switch datafile 'my_new_datafile_name' to copy;
7. Recover the datafile using RMAN
RMAN> recover datafile 'my_new_datafile_name';
RMAN> exit
8. Put the datafile back online
. oraenv
ORACLE_SID = [oracle] ? Enter DB Sid
sqlplus '/ as sysdba'
SQL> alter database datafile 'my_new_datafile_name' online;
9. Confirm the datafile has been moved.
. oraenv
ORACLE_SID = [oracle] ? Enter DB Sid
sqlplus '/ as sysdba'
SQL> select tablespace_name, file_name, file_id file# from dba_data_files where tablespace_name = 'MYTSP';
Example Output
SQL> select tablespace_name, file_name, file_id file# from dba_data_files where tablespace_name = 'MYTSP';
TABLESPACE_NAMEaaFILE_NAMEaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaFILE#
MYTSPaaaaaaaaaaaaa+DATA/mydb/datafile/myfile.379.716245261aaaaaaaaaaaaaaaaa22
SQL> SELECT name FROM v$asm_diskgroup;
NAME
REC
DATA
SQL> alter database datafile '+DATA/mydb/datafile/myfile.379.716245261' offline;
Database altered.
rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Tue May 13 10:01:27 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: MYDB (DBID=403243456)
RMAN> copy datafile '+DATA/mydb/datafile/myfile.379.716245261' to '+REC';
Starting backup at 13-MAY-08
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=165 instance=MYDB devtype=DISK
channel ORA_DISK_1: starting datafile copy
input datafile fno=00022 name=+DATA/mydb/datafile/myfile.379.716245261
output filename=+REC/mydb/datafile/myfile.2005.716245261 tag=TAG20080513T120010 recid=364 stamp=716223223
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
Finished backup at 13-MAY-08
RMAN> exit;
sqlplus / as sysdba
SQL> ALTER DATABASE RENAME FILE '+DATA/mydb/datafile/myfile.379.716245261' TO
aaaaaaaaaa'+REC/mydb/datafile/myfile.2005.716245261';
Database altered.
SQL> exit
rman target /
RMAN> switch datafile '+REC/mydb/datafile/myfile.2005.716245261' to copy;
Recovery Manager: Release 10.2.0.4.0 - Production on Tue May13 10:08:27 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: MYDB (DBID=403243456)
using target database control file instead of recovery catalog
datafile 22 switched to datafile copy "+REC/mydb/datafile/myfile.2005.716245261'"
RMAN> recover datafile '+REC/mydb/datafile/myfile.2005.716245261';
Starting recover at 13-MAY-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=161 instance=MYDB devtype=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 13-MAY-10
RMAN> exit
SQL> alter database datafile '+REC/mydb/datafile/myfile.2005.716245261' online;
Database altered.
SQL> select tablespace_name, file_name, file_id file# from dba_data_files where tablespace_name = 'MYTSP';
TABLESPACE_NAMEaaFILE_NAMEaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaFILE#
MYTSPaaaaaaaaaaaaa+REC/mydb/datafile/myfile.2005.716245261aaaaaaaaaaaaaaaaa22

11g standby database media recovery failed due to ora-600

hi friends,
DB: 11g 11.1.0.6
OS: Windows server 2003 ent
I've setup datagaurd using 11g. but for last 2 days, not able to start media recovey on standby database.
here's my alertlog file
alter database recover managed standby database using current logfile disconnect from session
Sat Jan 03 11:23:04 2009
MRP0 started with pid=18, OS id=648
Fast Parallel Media Recovery enabled
Managed Standby Recovery starting Real Time Apply
Media Recovery apply datafile 5 offline range
parallel recovery started with 2 processes
Waiting for all non-current ORLs to be archived...
Media Recovery Log C:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GOLDSBY\ARCHIVELOG\2008_12_30\BACKUP\O1_MF_1_297_4ON23Q00_.ARC
Completed: alter database recover managed standby database using current logfile disconnect from session
Media Recovery Log C:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GOLDSBY\ARCHIVELOG\2008_12_31\BACKUP\O1_MF_1_298_4OP3CLWS_.ARC
Errors in file c:\app\administrator\diag\rdbms\goldsby\gold\trace\gold_mrp0_648.trc (incident=544158):
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
Incident details in: c:\app\administrator\diag\rdbms\goldsby\gold\incident\incdir_544158\gold_mrp0_648_i544158.trc
Errors with log C:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GOLDSBY\ARCHIVELOG\2008_12_31\BACKUP\O1_MF_1_298_4OP3CLWS_.ARC
MRP0: Background Media Recovery terminated with error 600
Errors in file c:\app\administrator\diag\rdbms\goldsby\gold\trace\gold_mrp0_648.trc:
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
Managed Standby Recovery not using Real Time Apply
Shutting down recovery slaves due to error 600
Recovery interrupted!
Sat Jan 03 11:23:15 2009
Trace dumping is performing id=[cdmp_20090103112315]
Sat Jan 03 11:23:16 2009
Recovered data files to a consistent state at change 92419435
Errors in file c:\app\administrator\diag\rdbms\goldsby\gold\trace\gold_mrp0_648.trc:
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
Errors in file c:\app\administrator\diag\rdbms\goldsby\gold\trace\gold_mrp0_648.trc:
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
Sat Jan 03 11:23:17 2009
Sweep Incident[544158]: completed
MRP TRACE FILE
** 2009-01-03 11:05:36.140 1095 krsh.c
MRP0: Background Managed Standby Recovery process started
*** 2009-01-03 11:05:41.140
*** 2009-01-03 11:05:41.140 1295 krsm.c
Managed Recovery: Initialization posted.
Started 11g Parallel Media Recovery
Fast Parallel Media Recovery enabled
*** 2009-01-03 11:05:41.156 1095 krsh.c
Managed Standby Recovery starting Real Time Apply
*** 2009-01-03 11:05:41.671
Recovery target incarnation = 5, activation ID = 0
Influx buffer limit = 31623 (50% x 63246)
Successfully allocated 2 recovery slaves
Start recovery at thread 1 ckpt scn 92413878 logseq 297 block 2
*** 2009-01-03 11:05:43.281
Media Recovery add redo thread 1
*** 2009-01-03 11:05:43.296 1295 krsm.c
Managed Recovery: Active posted.
*** 2009-01-03 11:05:43.500
Media Recovery Log C:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GOLDSBY\ARCHIVELOG\2008_12_30\O1_MF_1_297_4ON1Y6NZ_.ARC
*** 2009-01-03 11:05:44.093
Media Recovery Log C:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\GOLDSBY\ARCHIVELOG\2008_12_31\O1_MF_1_298_4ON74ROZ_.ARC
*** 2009-01-03 11:05:44.906
Incident 520220 created, dump file: c:\app\administrator\diag\rdbms\goldsby\gold\incident\incdir_520220\gold_mrp0_4044_i520220.trc
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
*** 2009-01-03 11:05:45.687 1095 krsh.c
MRP0: Background Media Recovery terminated with error 600
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
*** 2009-01-03 11:05:45.687 1095 krsh.c
Managed Standby Recovery not using Real Time Apply
kcrrgaptime: no snapshot information available
----- Redo read statistics for thread 1 -----
Read rate (ASYNC): 21376Kb in 2.55s => 8.19 Mb/sec
Total redo bytes: 23424Kb Longest record: 14Kb, moves: 17/62299 moved: 0Mb (0%)
Longest LWN: 804Kb, reads: 2357
Last redo scn: 0x0000.05823f03 (92421891)
Change vector header moves = 8621/118937 (7%)
*** 2009-01-03 11:05:45.828
Media Recovery drop redo thread 1
Completed 11g Parallel Media Recovery
Starting in-flux buffer recovery from SCN 0.92413878 to SCN (non-inclusive) 0.92419435
*** 2009-01-03 11:05:46.265
Influx Media Recovery add redo thread 1
*** 2009-01-03 11:05:47.531
*** 2009-01-03 11:05:47.531 1295 krsm.c
Managed Recovery: Not Active posted.
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
error 473 detected in background process
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-00600: internal error code, arguments: [3012], [5], [131], [0], [92421891], [0], [92413878], []
could you help on this...?
waiting for your favorable reply,
thanks in advance..
Regards

Hi;
This error occurs when you have run a switchover/ failover, you may have two parallel standby's but when you pass the command for switchover the one standby is not aware of what you have done.
The point is that all standby should know who is your primary & standby's should also be aware of each other in their "pfiles" now, you should either recreate the standby or open with reset logs.
ora-600 occurs due to different incarnation.
Hope this will help you
if you switch multiple logfiles in primary, & run >>
alter database recover managed standby database disconnect;
your standby will start syncing.
Hope this will help you

Audit file - media recovery

After shutdown our 8.1.7.4 database had a datafile change to the audit_data_01.dbf file. (4 hours later). Unfortunately, we were moving the database to a new server the next day and are now unable to bring the database back up. Error is that the file (51337) is smaller than the correct size of 64k. Actual size of file is 420mb. Original server has the file at the same size as moved so old and new are still identical. What happened and what can I do to bring the database back up?
All processes were down prior to the move.
Audit init file parameter was set to true.

apparently there is not a cron that could have affected the file so it must have been a backup or a transfer/tar failure. I'll have to check tomorrow when I go in to see if the audit file is in a separate tablespace. I didn't create these databases, they've been around for several years. It is not named consistently with the other appication files so we are not sure how it was created. Losing the data/change after the shutdown will not be an issue. It looks at this time like we're facing either a recover database until time x recovery, a datafile recovery or a database recovery tomorrow morning. Any advice on which to try first? or which is most likely to work without causing further damage? or alternatives?

FUZZY BIT에 대해서 (DATAFILE의 FUZZY 상태)

제품 : ORACLE SERVER
작성날짜 : 2000-05-22
fuzzy bit에 대해서 (datafile의 fuzzy 상태)
==========================================
[1] 개요
~~~~~~~~
datafile이 fuzzy라는 것은 해당 file에 대한 checkpoint이후 그 file에
변경사항이 있을 수 있음을 나타낸다. 즉 그 file에는 반영되지 않은 변경
사항이 redo log file과 buffer cache에만 존재하는 경우를 나타낸다.
이렇게 datafile이 fuzzy 상태인 경우를 setting하여 그러한 상태의
datafile이 존재하는 경우에는 database가 open되는 것을 막는다.
[2] datafile status (fuzzy bit)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
datafile의 fuzzy bit라고 하는 것은 실제 별도의 structure로 관리되는 것은
아니고 datafile header에 datafile의 status를 나타낸다.
datafile에는 10가지 status가 있으며, 그 중 아래 4개의 status가 datafile이
fuzzy 임을 나타내며, 각 status를 bit로 나타내면 특정 하나의 bit가 setting
된 형태이므로 fuzzy bit라고 부른다.
0x01 (0000 0001) : hot backup-in-progress on file (fuzzy file)
0x04 (0000 0100) : online fuzzy because it was online and db open
0x10 (0001 0000) : media recovery fuzzy - file in media recovery
0x40 (0100 0000) : absolute fuzzy - fuzzyness from fule scan
[3] clear marker
~~~~~~~~~~~~~~~~
위에서 설명한 fuzzy 상태에 대해서 online fuzzy, hot backup fuzzy, media
recovery fuzzy, absolute fuzzy라고 부르는데, 앞의 세개에 대해서 fuzzy
상태가 clear되면 관계되는 marker를 redo log file에 기록한다.
online fuzzy의 경우는 end crash recovery marker, hot backup fuzzy의
경우에는 end hot backup marker, media recovery fuzzy에 대해서는 clear
media recovery fuzzy를 redo log 에 기록하고 datafile header에도 반영한다.
이렇게 fuzzy 상태가 종료됨을 나타내는 marker를 redo log file에 기록해
둠으로써, 이후에 redo log file내용을 이용하여 recovery시 datafile의 fuzzy
상태를 이 marker만을 적용함으로써 clear하도록 할 수 있다.
[4] 각 fuzzy 종류 설명
~~~~~~~~~~~~~~~~~~~~~~
(1) hot backup fuzzy
hot backup 시작시에 setting되어 end backup을 만나면 clear된다.
이것은 hot backup 을 통해 backup 받은 file을 이용하여 recover하는 경우
end backup이전 상태까지만 recover하는 것을 막기 위한 것이다.
begin backup end backup recovery 시도
---------|-------------------------|-------------------|---------
1시 5시 10시
예를 들어 오전 1시에 hot backup을 시작하여 5시에 end backup이 된 경우
이후에(예를 들어 10시) 이 file을 이용하여 recover하는 경우 time based로
3시까지만 recover하고자 시도하면 hot backup fuzzy bit가 setting되어
있어서 오류가 난다.
즉, 반드시 end backup이 수행된 5시 이후시점까지 recover가 되어야 하는
것이다. 이것은 hot backup과 end backup 도중 계속해서 그 datafile에
transaction이 반영되기 때문에 resotre한 file이 이미 3시 이후의 4시,5시
까지의 변경사항을 일부 포함할 수 있기 때문이다.
end backup marker는 hot backup시에 end backup 명령이 수행되면 hot backup
fuzzy bit가 clear되면서 redo log file내에 기록된다. 이후에 이 hot backup된
datafile을 이용하여 recover하는 경우 그 backup된 datafile의 status는
hot backup fuzzy bit가 setting된 상태이며, 이 bit는 redo log file
(혹은 archive file)내에 기록된 end backup marker를 만나면 clear된다.
(2) online fuzzy
database가 open되고 datafile이 online상태가 되면 이 bit가 설정된다.
그리고 database가 정상적으로 shutdown 되거나 recovery시 media recovery가
성공적으로 끝나면 clear된다. 또한 tablespace를 offline normal하거나
read only로 변경시키는 명령에 의해 clear된다
online fuzzy가 필요한 경우를 다음 예를 통해 살펴본다.
- 1시 : db crash
- 1시 10분: 사용자가 crash된 datafile을 os image backup
- 1시 20분: db startup (crash recovery자동 수행으로 정상 open)
- 2시 : disk failure
1시 10분에 crash된 채로 받은 backup만이 존재
archive log mode
이때 만약 사용자가 1시 10분에 받은 비정상적인 backup을 이용하여 recovery
를 수행하는 경우를 가정해보자. 이 datafile의 backup은 online fuzzy bit이
setting상태 그대로이다. 실제 여기에서 datafile은 1시 20분의 crash
recovery에 의해 online fuzzy가 clear되었기 때문이다.
이때 만약 recovery시에 until time 으로 1시 15분을 지정한다면 이
datafile은 여전히 online fuzzy bit가 설정된 상태이기 때문에 database가
open이 될 수 없다.
만약 until time을 1시 20분 이후로 지정하게 되면 1시 20분에 생성된
end-crash recovery marker가 datafile에 적용되어 online fuzzy bit는 clear
되게 되어 이 부분으로 인해 db가 open되지 않는 일은 없게 된다.
(3) media recovery fuzzy
file에 media recovery가 진행중임을 나타낸다. 각 file마다 media recovery가
시작될 때 설정되었다가, file의 stop SCN을 만나거나 recovery가 정상적으로
끝나게 되면 clear된다.
media recovery시 archive file에 기록된 변경사항이 바로 disk에 반영되는 것이
아니고 일단 archive file의 내용을 buffer 에 읽은 후 반영하는 것이기 때문에,
변경사항의 일부는 buffer에만 존재할 수 있게 된다. 그래서 media recovery가
끝날 때까지는 fuzzy상태가 되는 것이다.
이렇게 recovery fuzzy bit를 설정함으로써, 이미 한 session에서 recovery를
진행하는 동안 다른 session에서 database를 open하려고 시도하면, recovery
중임을 알고 open하지 못하도록 하는 것이 가능하다.
(4) absolute fuzzy
이 fizzy 상태는 RMAN사용시에만 이용된다. absolute fuzzy SCN은 datafile의
checkpoint이후 그 datafile의 모든 block들의 모든 SCN중 가장 큰 값이다.
이 absolute fuzzy flag는 file의 checkpoint로 인해 checkpoint SCN이
이 absolute fuzzy SCN이상의 값으로 되면 clear된다.

Tcode for Recovery Data

Hi,
How to check the Recovery Data ( After the DRP ). Any list of Transaction Code..
Pls Advise. Very Urgent...
Thks
Roy.

Hi Roy,
you can get useful information reg recovery data from these links...
pls check out...
http://help.sap.com/saphelp_nw04/helpdata/en/26/29d829213e11d2a5710060087832f8/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/26/29d829213e11d2a5710060087832f8/frameset.htm
regards,
rudra.
Assign points if useful...

Blue screen crash on my A60

I have a equium a60 155 model no psa67e-00300cj8 at I keep getting a stop 0x00000010 messages I have done most things and it is almost definatly a hardware driver conflict with windows xp. is anyone aware of any hardware conflics. The error message on bootup (when i can get it to) identifies os ver 5_1_2600 sp2-0 product 768-1 as the cause.
If I use product recovery disc I get a message saying that a system registry had to be recovered
Please help

I am getting different problems on the stop messages always irql_not_less_or_equal to interestingly on one occassion it was preceeded with the word Driver after running chk disc. Two stop messages are the most common 0x0000000a (0x0a060006,0x00000016,0x00000001,0x804e2219 (3times) & 0x0000000a (0x0000116c,0x0000002,0x00000001,0x804fibi3 (twice)
always IRQ < or = to and a phys mem dump in the message.
I dont understand why it would need a system reg recovery after recovery. I would appreciate any assistance.
I am getting despirate as I have installed extra Toshiba memory (no help) formatted the hard drive, it happens even in safe mode so it is a system critical driver (Monitor, graphic etc.)

ORA-03113: end-of-file on communication channel

Hi
While I startup Oracle database, i get the following error. What could be the issue and how to resolve this.
SQL> startup
ORACLE instance started.
Total System Global Area 864333824 bytes
Fixed Size 2231368 bytes
Variable Size 704644024 bytes
Database Buffers 150994944 bytes
Redo Buffers 6463488 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 6507
Session ID: 580 Serial number: 5
Below is the content from alert log and trace log
*#alert_orcl.log#*
Bad header found during crash/instance recovery
Reading datafile '+DATA/orcl/datafile/sysaux.257.762570243' for corruption at rdba: 0x0080f01b (file 2, block 61467)
Data in bad block:
type: 255 format: 2 rdba: 0x0000a2ff
last change scn: 0x0000.0080019f seq: 0x0 flg: 0x00
spare1: 0x0 spare2: 0x0 spare3: 0x4ff
consistency value in tail: 0x643e0346
check value in block header: 0x0
Read datafile mirror 'ASM5' (file 2, block 61467) found same corrupt data (no logical check)
block checksum disabled
Reading datafile '+DATA/orcl/datafile/sysaux.257.762570243' for corruption at rdba: 0x0080019f (file 2, block 415)
Read datafile mirror 'ASM4' (file 2, block 415) found same corrupt data (no logical check)
Read datafile mirror 'ASM1' (file 2, block 61467) found same corrupt data (no logical check)
Hex dump of (file 2, block 34539) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p000_6831.trc
Corrupt block relative dba: 0x008086eb (file 2, block 34539)
Bad header found during crash/instance recovery
Data in bad block:
type: 1 format: 6 rdba: 0x0000a201
last change scn: 0x0000.008086eb seq: 0x0 flg: 0x00
Read datafile mirror 'ASM3' (file 2, block 415) found same corrupt data (no logical check)
spare1: 0xbb spare2: 0xe1 spare3: 0x4ff
consistency value in tail: 0x02c20304
check value in block header: 0x0
block checksum disabled
Reading datafile '+DATA/orcl/datafile/sysaux.257.762570243' for corruption at rdba: 0x008086eb (file 2, block 34539)
Read datafile mirror 'ASM2' (file 2, block 34539) found same corrupt data (no logical check)
Hex dump of (file 2, block 420) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p002_6839.trc
Corrupt block relative dba: 0x008001a4 (file 2, block 420)
Bad header found during crash/instance recovery
Data in bad block:
type: 255 format: 2 rdba: 0x0000a206
last change scn: 0xe1f3.008001a4 seq: 0x74 flg: 0x00
spare1: 0x0 spare2: 0x0 spare3: 0x401
consistency value in tail: 0x474f4c20
check value in block header: 0x0
block checksum disabled
Reading datafile '+DATA/orcl/datafile/sysaux.257.762570243' for corruption at rdba: 0x008001a4 (file 2, block 420)
Read datafile mirror 'ASM4' (file 2, block 420) found same corrupt data (no logical check)
Read datafile mirror 'ASM1' (file 2, block 34539) found same corrupt data (no logical check)
Read datafile mirror 'ASM3' (file 2, block 420) found same corrupt data (no logical check)
Hex dump of (file 1, block 3097) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p002_6839.trc
Corrupt block relative dba: 0x00400c19 (file 1, block 3097)
Bad header found during crash/instance recovery
Data in bad block:
type: 2 format: 6 rdba: 0x0000a202
last change scn: 0x0000.00400c19 seq: 0x0 flg: 0x00
spare1: 0xdf spare2: 0xe2 spare3: 0x4ff
consistency value in tail: 0x09c10280
check value in block header: 0x0
Hex dump of (file 2, block 34765) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p000_6831.trc block checksum disabled
Corrupt block relative dba: 0x008087cd (file 2, block 34765)
Reading datafile '+DATA/orcl/datafile/system.256.762570243' for corruption at rdba: 0x00400c19 (file 1, block 3097)
Bad header found during crash/instance recovery
Data in bad block:
type: 255 format: 1 rdba: 0x0000a206
last change scn: 0xe27b.008087cd seq: 0x74 flg: 0x00
spare1: 0x0 spare2: 0x0 spare3: 0x401
Read datafile mirror 'ASM5' (file 1, block 3097) found same corrupt data (no logical check)
consistency value in tail: 0x00000000
check value in block header: 0x0
block checksum disabled
Reading datafile '+DATA/orcl/datafile/sysaux.257.762570243' for corruption at rdba: 0x008087cd (file 2, block 34765)
Read datafile mirror 'ASM3' (file 2, block 34765) found same corrupt data (no logical check)
Read datafile mirror 'ASM2' (file 1, block 3097) found same corrupt data (no logical check)
Hex dump of (file 3, block 272) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p002_6839.trc
Reading datafile '+DATA/orcl/datafile/undotbs1.258.762570243' for corruption at rdba: 0x00c00110 (file 3, block 272)
Read datafile mirror 'ASM1' (file 3, block 272) found same corrupt data (logically corrupt)
Read datafile mirror 'ASM5' (file 2, block 34765) found same corrupt data (no logical check)
Hex dump of (file 2, block 34771) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p000_6831.trc
Corrupt block relative dba: 0x008087d3 (file 2, block 34771)
Bad header found during crash/instance recovery
Data in bad block:
type: 1 format: 6 rdba: 0x0000a201
last change scn: 0x0000.008087d3 seq: 0x0 flg: 0x00
spare1: 0x3a spare2: 0xe3 spare3: 0x4ff
consistency value in tail: 0x00045055
check value in block header: 0x0
block checksum disabled
Reading datafile '+DATA/orcl/datafile/sysaux.257.762570243' for corruption at rdba: 0x008087d3 (file 2, block 34771)
Read datafile mirror 'ASM3' (file 2, block 34771) found same corrupt data (no logical check)
Read datafile mirror 'ASM2' (file 3, block 272) found same corrupt data (logically corrupt)
RECOVERY OF THREAD 1 STUCK AT BLOCK 272 OF FILE 3
Read datafile mirror 'ASM5' (file 2, block 34771) found same corrupt data (no logical check)
Wed Jun 27 05:49:55 2012
Hex dump of (file 2, block 65353) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_6713.trc
Corrupt block relative dba: 0x0080ff49 (file 2, block 65353)
Bad header found during buffer corrupt after write
Data in bad block:
type: 1 format: 6 rdba: 0x0000a206
last change scn: 0xe2bf.0080ff49 seq: 0x74 flg: 0x00
spare1: 0xf5 spare2: 0xe0 spare3: 0x602
consistency value in tail: 0x00000000
check value in block header: 0x0
block checksum disabled
Reread of rdba: 0x0080ff49 (file 2, block 65353) found different data
Hex dump of (file 2, block 65356) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_6713.trc
Corrupt block relative dba: 0x0080ff4c (file 2, block 65356)
Bad header found during buffer corrupt after write
Data in bad block:
type: 2 format: 6 rdba: 0x0000a206
last change scn: 0xe2a7.0080ff4c seq: 0x74 flg: 0x00
spare1: 0xbf spare2: 0xe2 spare3: 0x602
consistency value in tail: 0x00000059
check value in block header: 0x0
block checksum disabled
Reread of rdba: 0x0080ff4c (file 2, block 65356) found different data
Hex dump of (file 2, block 66114) in trace file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_6713.trc
Corrupt block relative dba: 0x00810242 (file 2, block 66114)
Bad header found during preparing block for write
Data in bad block:
type: 255 format: 1 rdba: 0x0000a206
last change scn: 0xe1bb.00810242 seq: 0x74 flg: 0x00
spare1: 0x0 spare2: 0x0 spare3: 0x401
consistency value in tail: 0x800102c1
check value in block header: 0x0
block checksum disabled
Errors in file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_6713.trc (incident=292893):
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], [], [], [], [], []
Incident details in: /appl/oracle/diag/rdbms/orcl/orcl/incident/incdir_292893/orcl_dbw0_6713_i292893.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Exception [type: SIGBUS, Non-existent physical address] [ADDR:0x72BFFFF8] [PC:0x3612E7CAE9, _wordcopy_bwd_dest_aligned()+185] [flags: 0x0, count: 1]
Errors in file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p000_6831.trc (incident=293021):
ORA-07445: exception encountered: core dump [_wordcopy_bwd_dest_aligned()+185] [SIGBUS] [ADDR:0x72BFFFF8] [PC:0x3612E7CAE9] [Non-existent physical address] []
Incident details in: /appl/oracle/diag/rdbms/orcl/orcl/incident/incdir_293021/orcl_p000_6831_i293021.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x546B040, kcbs_dump_adv_state()+634] [flags: 0x0, count: 2]
Wed Jun 27 05:49:59 2012
Dumping diagnostic data in directory=[cdmp_20120627054959], requested by (instance=1, osid=6831 (P000)), summary=[incident=293021].
Errors in file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_p000_6831.trc (incident=293022):
ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+634] [SIGSEGV] [ADDR:0x0] [PC:0x546B040] [SI_KERNEL(general_protection)] []
ORA-07445: exception encountered: core dump [_wordcopy_bwd_dest_aligned()+185] [SIGBUS] [ADDR:0x72BFFFF8] [PC:0x3612E7CAE9] [Non-existent physical address] []
Incident details in: /appl/oracle/diag/rdbms/orcl/orcl/incident/incdir_293022/orcl_p000_6831_i293022.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x546B040, kcbs_dump_adv_state()+634] [flags: 0x0, count: 1]
Errors in file /appl/oracle/diag/rdbms/orcl/orcl/incident/incdir_293021/orcl_p000_6831_i293021.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00602: internal programming exception
ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+634] [SIGSEGV] [ADDR:0x0] [PC:0x546B040] [SI_KERNEL(general_protection)] []
ORA-07445: exception encountered: core dump [_wordcopy_bwd_dest_aligned()+185] [SIGBUS] [ADDR:0x72BFFFF8] [PC:0x3612E7CAE9] [Non-existent physical address] []
Errors in file /appl/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_6713.trc (incident=292894):
ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+634] [SIGSEGV] [ADDR:0x0] [PC:0x546B040] [SI_KERNEL(general_protection)] []
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], [], [], [], [], []
Incident details in: /appl/oracle/diag/rdbms/orcl/orcl/incident/incdir_292894/orcl_dbw0_6713_i292894.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Dumping diagnostic data in directory=[cdmp_20120627055004], requested by (instance=1, osid=6713 (DBW0)), summary=[incident=292893].
Wed Jun 27 05:50:08 2012
PMON (ospid: 6679): terminating the instance due to error 471
Wed Jun 27 05:50:08 2012
ORA-1092 : opitsk aborting process
Wed Jun 27 05:50:08 2012
License high water mark = 4
Instance terminated by PMON, pid = 6679
USER (ospid: 6860): terminating the instance
Instance terminated by USER, pid = 6860
*#trace logs#*
Corrupt block relative dba: 0x00810242 (file 2, block 66114)
Bad header found during preparing block for write
Data in bad block:
type: 255 format: 1 rdba: 0x0000a206
last change scn: 0xe1bb.00810242 seq: 0x74 flg: 0x00
spare1: 0x0 spare2: 0x0 spare3: 0x401
consistency value in tail: 0x800102c1
check value in block header: 0x0
block checksum disabled
kcra_dump_redo_internal: skipped for critical process
kcbz_try_block_recovery <1, 8454722>: tries=0 max=5 cur=1340797795 last=0
BH (0x7bbe0fc8) file#: 2 rdba: 0x00810242 (2/66114) class: 1 ba: 0x7b8f4000
set: 12 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 0,0
dbwrid: 0 obj: 68150 objn: -1 tsn: 1 afn: 2 hint: f
hash: [0x912f45b0,0x912f45b0] lru-req: [0x7bbdfdb0,0x90deff60]
lru-flags: on_auxiliary_list
obj-flags: object_write_list
ckptq: [0x7bbfc4c8,0x7bbea0a8] fileq: [NULL] objq: [0x8b251480,0x8b251480] objaq: [0x8b251450,0x7bbe0e88]
st: INST_RCV md: NULL rsop: 0x90d110e0
flags: buffer_dirty being_written block_written_once recovery_resilver
recovery_read_complete
cr pin refcnt: 0 sh pin refcnt: 0
kcra_dump_redo_internal: skipped for critical process
Incident 292893 created, dump file: /appl/oracle/diag/rdbms/orcl/orcl/incident/incdir_292893/orcl_dbw0_6713_i292893.trc
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], [], [], [], [], []
Incident 292894 created, dump file: /appl/oracle/diag/rdbms/orcl/orcl/incident/incdir_292894/orcl_dbw0_6713_i292894.trc
ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+634] [SIGSEGV] [ADDR:0x0] [PC:0x546B040] [SI_KERNEL(general_protection)] []
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], [], [], [], [], []

Did you actually read the alert-log ??
The problem is clear in there. Your datafiles are corrupted!!!
While the database is trying to correct these, a lot of ORA-00600 and ORA-07445's are generated.
Consult Oracle Support to get this resolved
Thanks
FJFranken

ORA-1113 signalled during: alter database open...

Hello,
Today when I was unable to logon to my Oracle 9i database on Windows machine, I referred to the Alter.log file.
This file showed me the above error.
And when I try to logon to database with normal user, I get the error as "Database initialization or shutdown is in progress"
When I tried to log on using the DBA privileges, I can see that my Database is MOUNTED.
What should I do next? Do I bring the database down forcefully using the "Shutdown abort" command? and then at the startup when some datafile is shown as required to recovery then, recover the datafile using following command:
RECOVER AUTOMATIC DATAFILE 'file_Path';
Please guide
Thanks in advance
Himanshu

ORA-01113 file string needs media recovery
Cause: An attempt was made to open a datafile that is in need of media recovery.
Action: First apply media recovery to the datafile identified in the message, then retry the operation.
media recovery for datafile is required
log as sys user.
shutdown the database
startup mount
recover datafile <filename>
alter database open

Oracle Backup Misbehavior

Hello,
iam running into a strange problem while doing a backup via Oracle Enterprise Tool under Oracle 11g:
1. Login: sys as sydba
2. Backup Setting are on "Image Copy"
2.1 Keep most generally default settings
2.2 Test Disk Backup successfully
3. Schedule Backup
3.1 Whole database
3.2 Full Backup
3.3 Online
3.4 Disk
3.5 One time
4. Waiting until orcl is ready and backup job is succeeded
5. Altering the database
5.1 e.g. filling an empty tablespace with tables
5.2 or changing an existing database table content through a database tool (e.g. DVisualizer)
6. Perform Recovery
6.1 Recovery Scope: datafile
6.2 Restore datafile
6.3 select the afected datafile
6.4 the most recent backup
6.5 restore to default location
6.6 Submit job und wait till succeeded
From now on the problem starts:
- If i am looking now at the datafile i can see the status = Recover. I can access the tablespace, but not my data (datafile)
- Looking at the function "Perform Recover" => the Oracle Advisor is recommending a Recovery
- Performing the Recovering => I can afterwards access the tablespace, but there is not the state i have backuped before and i wanted to restore
What iam doing wrong here?
Please advice.
Any help is appreciated.
If you have any guideline how i can easily do a simply Oracle backup it would be helpful as well.
Edited by: Macgator on Aug 25, 2009 9:24 AM
Edited by: Macgator on Aug 25, 2009 9:54 AM

If I understand you correctly you performed a COMPLETE recovery,rsp. EM triggered this. Do you want to get back the state of the database BEFORE the changes? Then you must restore/recover incompletely, just before the point in time the changes were done.
A short description is here:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28301/backrest.htm#i1004902
Werner

Reg:recovery of datafile

Similar Messages

Maybe you are looking for