Block Corruption
RameshG, July 17, 2003 - 9:36 am UTC
Tom,
You have said that "Block corruption is rare but it does happen. As databases get larger and larger
-- the probability of it happening at some point nears 100%". I am confused here, we got a table with 270million records with no partionning and is using rule based optimizer. What is the probability of a data block getting corrupted? Is it 100% as you have said?.
The DatabaseCapacity project has bulked up this table upto 700 million records and has come up saying that there are no threats to this table which is contradicting with what you have said.
Thanks
RameshG
July 17, 2003 - 10:44 am UTC
270 million what? 1 byte rows? 100 byte rows? 100000000 byte rows?
number of records is not meaningful.
the capacity planner is worried about space, not recovery issues.
If you have a solid recovery plan, have tested recovery, can do recovery, know everything about recovery -- you are safe.
If not, you are not (safe)
Just an eye-opener
Sneaking around, July 17, 2003 - 12:46 pm UTC
> the capacity planner is worried about space, not recovery issues.
The capacity planner is worried about:
o Space: disk, etc
o Performance: CPU, IO, ram, network, etc
Note: sometimes both are intermixed.
Block Corruption
Ramesh G, July 18, 2003 - 4:12 am UTC
Thanks Tom.
The following is the structure of the table.
TableName : Customer_Req_Fields
CUST_REQ_ID NUMBER (10) NOT NULL,
CUST_REQ_FIELD_TYPE_ID NUMBER (6) NOT NULL,
CUST_REQ_GROUP NUMBER (6) NOT NULL,
CUST_GROUP_LEVEL1 NUMBER (3),
CUST_FIELD_VALUE VARCHAR2 (250),
CUST_GROUP_LEVEL2 NUMBER (3),
CUST_GROUP_LEVEL3 NUMBER (3),
CUST_GROUP_LEVEL4 NUMBER (3),
CUST_CREATION_DATE DATE DEFAULT Sysdate,
CUST_MODIFIED_DATE DATE
Most of these fields are not null and the average row size is 103bytes. There are nearly 300million records in this table.
Recently i have raised the issue of recovery but was told that there are no threats to the table. I need a solid proof to justify my argument. Could you please explain me how to justify that the recovery is a big issue.
Thanks
RameshG
July 18, 2003 - 8:42 am UTC
who would be foolish enough to say "there are no threats"?
the structure of the table is MEANINGLESS.
if you value the data, if losing it would be painful, you will have a tried, tested, bullet proof recovery process in place. period.
anything else is "amateur time"
Type of Block corruption
Jagjeet Singh, November 13, 2005 - 8:43 am UTC
Hi,
Can you please tell us, How many type block corruption may be happend.
o In one case for testing purpose I populate a table with
NOLOGGING and then recover it from its last backup and
got corrupted block. But I was able to fix this simply
truncate the table. -- I was not able to select the data
from this table.
o My client's database has block corruption and I was able
to select the data from that particular table. I just
found this error in alert log. I don't know what operation
generated this. dbv could not check this corruption.
o I just opened a datafile and typed some junck value.
I was not able to select/delete/truncate the table evem I was
not able to startup the database. I had to take datafile offline then opened the database.
Can you please explain what type of block corruption may be happend and in what case exp/imp, dbv,validate structure,rman backup can detect this.
Thanks,
November 13, 2005 - 10:34 am UTC
cannot answer the infinite question.
In the first case, it was not really corrupt - it was known to contain unrecoverable data.
In the second case - not sure what you mean, if the data was corrupt - how did you select it? not sure of the circumstances here so I won't even comment.
in the last case, you damaged the datafile itself, probably the head and more (you probably edited the file which is BINARY with a text editor - causing massive and severe and total corruption
Re: Block corruption
Jagjeet Singh, November 14, 2005 - 7:13 am UTC
In second case: I found this error in alert log ORA-1578
for a File# blcok#. I checked that block was pointing to a
partition of a big partitioned table. I created one table
using "create table t as select * from table partition () ".
Mean I was able to select data from this partition.
I issued " Analyze table part_table partition (P) validate structure into .. "
I ran dbv to that datafile I did not find anything wrong.
That's why I was asking that these all tools ( dbv,validate structure,rman backup,exp/imp ) what type of block corruption can detect and what happened in this case.
Regards,
Js
November 14, 2005 - 9:19 am UTC
then it sounds like it was an error that was corrected - else you would have gotten the 1578 reading the data to create the new table. (eg: block was no longer corrupted when you did what you did)
Testing for Block Corruption
Randall, November 14, 2005 - 10:43 am UTC
Tom,
I am putting together a small training class on using RMAN for our other DBA's. I have outlined different failure and recovery scenarios, but block corruption is one I am having a hard time with.
Could you provide a sample of how to corrupt a block, and then test for it? Once identified, I know how to recover it with RMAN. I just don't know how to simulate it.
Database is 9.2.0.7
Thanks for your time..
November 14, 2005 - 1:33 pm UTC
you would use a binary editor (os specific) or custom program to do this. You could write a very small C or Java program that would open a file, seek to an offset in the file that you told it to and have it write binary zeroes for as many bytes as you said to.
Makes me worried
Randy, November 14, 2005 - 12:00 pm UTC
When you say "Block corruption is rare but it does happen. As databases get larger and larger -- the probability of it happening at some point nears 100%. " that really makes me very worried. What's the size of the database in your mind when you say probability nears 100%? Also how do you avoid having any block corruption ?
November 14, 2005 - 2:09 pm UTC
anysize - the larger, the more likely a failure is to occur *somewhere*.
the more disk you have, the higher the probability something will fail mechanically at some point (introducing corruption).
You cannot avoid it, you can only plan for it (eg: it always comes back to "Yes, I can recover my database")
Tool to simulate block Corruption
A reader, November 14, 2005 - 7:50 pm UTC
Tom,
You said that you would use a binary editor (os specific) or custom program to do this. You could write a very small C or Java program that would open a file. -- Well, that sounds like as if one is required to know the internals of OS files, blocks and the block-dumps (which I know for a fact that you don'nt like to discuss). My question on that would be -- Is there a utlity already available anywhere, which can be used to simulate this kind of block corruption failure; probably a java utility could appropriately do it regardless of the platform type.
As a matter of fact, I have seen this kind of utility being used by the original developers of RMAN (Oracle Employees), while conducting a hands-on session on the RMAN, couple of years ago in the ORACLE OPEN-WORLD 2002. At that time, they did not want to share their block corrution utility.
I would be curious to know your thoughts on that.
Thanks,
Neeraj
November 15, 2005 - 8:02 am UTC
No, one is not required to know that.
You want to corrupt a file, fine - seek to some place in the Oracle datafile, write binary zeroes to it.
I agree with them - I have my own quick and dirty tools and there are undocumented utilities that ship with the server - but I'm not going to share them or talk about them. This kind of playing is best done "on your own".
Tool to simulate block Corruption
Neeraj Nagpal, November 14, 2005 - 7:51 pm UTC
Tom,
You said that you would use a binary editor (os specific) or custom program to do this. You could write a very small C or Java program that would open a file. -- Well, that sounds like as if one is required to know the internals of OS files, blocks and the block-dumps (which I know for a fact that you don'nt like to discuss). My question on that would be -- Is there a utlity already available anywhere, which can be used to simulate this kind of block corruption failure; probably a java utility could appropriately do it regardless of the platform type.
As a matter of fact, I have seen this kind of utility being used by the original developers of RMAN (Oracle Employees), while conducting a hands-on session on the RMAN, couple of years ago in the ORACLE OPEN-WORLD 2002. At that time, they did not want to share their block corrution utility.
I would be curious to know your thoughts on that.
Thanks,
Neeraj
Re: Block corruption
Jagjeet Singh, November 15, 2005 - 8:01 am UTC
Ok ..
Can you please explain in what case this 1578 can be fixed automatically.
Regards,
Js
November 15, 2005 - 11:36 am UTC
intermittent hardware failure.
Related disaster question
Bob B, November 15, 2005 - 8:59 am UTC
I'm curious if you've ever heard of corrupt blocks in the oracle binaries?
November 15, 2005 - 11:40 am UTC
doesn't make sense.
oracle binaries are programs
blocks are in datafiles
are you asking "has the oracle binary ever itself corrupted a block?" (answer = yes, it would be a bug)
Binary corruption
Bob B, November 15, 2005 - 1:27 pm UTC
If bytes on the disk get corrupted, they aren't necessarily going to always "choose" data bytes. They could corrupt a binary. I'm just curious if you've ever heard this happening in Oracle.
November 15, 2005 - 2:43 pm UTC
sure, I've seen disks go bad and programs get paging errors and such.
DBMS_SPACE_ADMIN.SEGMENT_CORRUPT
Neeraj, December 08, 2005 - 7:35 pm UTC
Tom,
I was reading about this packaged procedure in the Oracle9i Supplied PL/SQL Packages and Types Reference manual. Can this procedure, DBMS_SPACE_ADMIN.SEGMENT_CORRUPT, be used to mark the blocks as CORROUPT? If not then what exactly this procdure is used for. Could you please clarify.
Thanks For your Help,
Neeraj
December 09, 2005 - 1:34 am UTC
"This procedure marks the segment corrupt or valid so that appropriate error recovery can be done."
it does the segment header only. I would use it under the advice of support only.
RMAN
Neeraj, December 09, 2005 - 11:53 am UTC
Thanks so much for your response. What I was more curious about was that - if the header of a segment is marked corrupt, then do you think that a tool like RMAN will identify that block as a "corrupt block".
Block Corruption and Export/Import
Mahesh Kumar, March 09, 2006 - 7:17 am UTC
Tom,
When block corruption is there then we cannot SELECT then how export works on this table to select the data?
March 09, 2006 - 2:30 pm UTC
export just uses a select, therefore block in table must not have been corrupt.
Block Corruption and Select
Mahesh Kumar, March 11, 2006 - 2:15 am UTC
Tom
What is the difference between SELECT run by export utility and SELECT run on SQL prompt?
When both are selecting same table then why export is able to select data from table and user get error?
Please put more light on this.
March 11, 2006 - 3:35 pm UTC
nothing really (well, the export select could be a direct path which is a bit different).
show us
a) the select getting the error, eg:
set autotrace traceonly
select * from t;
<error here>
host exp tables=t
<successful export log here>
Block Corruption Strategies
Robert, May 03, 2006 - 12:17 pm UTC
Tom,
1. If we cannot afford the overhead of db_block_check* RMAN appears to be the most efficient way of checking for corruption. BUT...The one thing RMAN misses is cross-segment validation.. But this would *only* miss a corrupt index which can *easily* be rebuilt.
(Am I correct in my understanding here?)
2. I am understanding that your corrupt block recovery strategy is to rebuild the block from a backup.
What if the backup is corrupt?
How does one recover *up to* a corrupt block without losing any data?
Thanks,
Robert
May 03, 2006 - 1:28 pm UTC
1) pretty much, yes.
2) that is why you use rman to find out it is corrupt BEFORE you back it up!
"up to a corrupt block" - did not understand that part
Addendum to above........Oracle 8.1.7.4
Robert, May 03, 2006 - 12:22 pm UTC
Tom, sorry....... Oracle 8.1.7.4 database.
Clarification....
Robert, May 03, 2006 - 4:13 pm UTC
Tom,
<quote>
"up to a corrupt block" - did not understand that part
<quote>
Tom, I meant as in an incomplete recovery.... *up to* the point in time *before* the block was corrupted.
How would you do this in 8.1.7.4 ? (I understand it is 'easy' in 9i)
Thanks,
Robert.
May 03, 2006 - 4:40 pm UTC
point in time recovery - either SCN or time based.
Block recovery
Roderick, May 03, 2006 - 6:01 pm UTC
In regards to dbms_repair, there may be rare times you need to mark a block corrupt before you can fully leverage the RMAN blockrecovery feature. But better to call support at that point.
If you have a backup of a file taken before a block became physically corrupt, it can usually be fully recovered rather than stopping at a point in time. This is especially true if the underlying cause was that a few bits were messed up while the block was sitting innocently on disk (or as it got passed down through the IO infrastructure leading to disk). It is fairly rare (but not completely impossible thanks to bugs and such) if both the data block and the archive log records of the block changes were both messed up at the same time. Physical standby databases are nice to have for such situations. In 10g, flashback database features provide even more options.
Block Recovery
Patrick, July 31, 2006 - 3:13 am UTC
We have had block corruption on a table (ora-01578 on export).
We have renamed the table and recovered a copy of the table from an export, but still have the corruption in the renamed table.
If we drop this table will the tablespace be clean?
Is there any advantage to dropping and recreating the tablespace?
July 31, 2006 - 8:11 am UTC
if you drop the table, that block would be reformatted the next time it would be used. If the corruption was due to disk hardware issues - it may well come back however (if the disk is having problems).
You need not drop and create the tablespace.
You could have actually done a block level recovery using rman - meaning, you could have likely FIXED the block itself, rather that rolling back to some old version of the data.
Next time, suggest you involve support to work through your options.
Suraj Sharma, December 21, 2006 - 11:32 pm UTC
Hi Tom,
Thanks a lot Tom again for making Oracle so easy for all of us. I always refer your articals to solve my problems. Just now we had a block curruption in one of our databse. The database was 1.8TB. The error was like
"ORA-01578: ORACLE data block corrupted (file # 331, block #
> 153547)#ORA-01110: data file 331:
> 'P:\ORACLE\WF4\SAPDATA18\DAT_163\DAT.DATA163'#ORA-26040: Dat
> block was loaded using the NOLOGGING option"
I issued a query to find which object TYPE, OWNER and NAME of a segment for the corrupt block:
"SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = 331 and 153547 between block_id AND block_id + blocks – 1;"
But there was no row returned from this query. Then I used DB verify> the output of dbverify as as under:
Total Pages Examined : 1023999
Total Pages Processed (Data) : 844778
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 178898
Total Pages Failing (Index): 0
Total Pages Processed (Other): 316
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 7
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Again nothing much in the dbv as well, but there was some errors while running dbv the errors were like "DBV-00200: Block, dba 1388672967, already marked corrupted"
What does it exactly means and what should be the right approach in this case.
December 22, 2006 - 6:25 am UTC
please utilize support for something like this.
but it looks like you did non-logged operations (hence media recovery cannot be done)
Using binery editor
Suraj Sharma, March 08, 2007 - 3:08 am UTC
Tom,
In your post above as you said "you would use a binary editor (os specific) or custom program to do this. You could write a very small C or Java program that would open a file, seek to an offset in the file that you told it to
and have it write binary zeroes for as many bytes as you said to."
I am using a binery editor to edit a file on windows operating system. When I am trying to save the file after editing it, it is not allowing my by saying that "the file is already in use" (a common windows issue) and when I shoutdown the database and edit and saved it my database is not opening as it requires recovery for that file.
Please let me know if something/some way to corrupt the block for testing
March 08, 2007 - 10:30 am UTC
if you corrupt a random block when the database is down - it won't prompt for recovery afterwards. Not sure what you did - but just writing zeros to a block in the middle of a datafile would not be detected until we actually tried to READ that block
OS Timestamp
S, March 08, 2007 - 11:59 am UTC
Does operating system timestamp play a role here? It changed when the file was saved.
March 08, 2007 - 12:46 pm UTC
we don't care about the file system date/time.
Corrupt Block after applying Archive logs
Qazi Ahmed, May 14, 2007 - 1:45 pm UTC
Last week we went through our yearly Disaster recovery exercise. We have four production instances. All restored and worked well except one. Here is the summary of our setup.
We are using Oracle 8.1.7 on IBM AIX 5.3. All instances are in Archive Log mode. Our two archive destinations are Local on database server but 3rd archive destination is on our DRS Server.
We restored all instances from last available backup on tape. Then applied Archive logs to roll forward. This went fine except for one instance where we got following.
ORA-01578: ORACLE data block corrupted (file # 28, block # 169698)
ORA-01110: data file 28: '/data/orcl/ORCL_ldcdata03_03.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
I restored instance ORCL again but did not apply archive logs and ran DBV (database verify utility) to check the datafile and DBV find no errors. But after applying Archive logs there were many corrupted blocks in the datafile. I have not got any errors while applying archive logs.
I even asked our Unix Admins to check if any got reported at OS lever but they did not find any.
My questions are
1. Why datafile got corrupt after applying archive logs?
2. How can I find which Archive log is causing problem?
3. How to avoid this situation in future.
Thanks in Advance
May 14, 2007 - 5:01 pm UTC
did you read the error message??????????
someone did a non-logged direct path operation. that means NO REDO was generated.
you did this to yourself.
Qazi Ahmed, May 14, 2007 - 5:58 pm UTC
Yes someone created that Index with NoLogging option. I am going to fix it.
Can we drop that Index after media recovery is done and recreate it?
What will happen to those corrupt blocks after droping this index?
May 14, 2007 - 9:17 pm UTC
yes, you can drop and recreate it.
nothing happens to those blocks, they are not accessed again after you drop the segment.
block corrupt when backup
A reader, August 21, 2007 - 11:42 pm UTC
Tom,
I have problems related to block corruption known when backup with RMAN. Here is the error log we get:
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/22/2007 00:14:04
ORA-19566: exceeded limit of 0 corrupt blocks for file +FLASH_RECOVERY_AREA/orcl/datafile/sysaux.257.583168635
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/22/2007 00:14:08
ORA-19566: exceeded limit of 0 corrupt blocks for file +FLASH_RECOVERY_AREA/orcl/datafile/undotbs4.280.599668459
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/22/2007 00:05:35
ORA-19566: exceeded limit of 0 corrupt blocks for file +FLASH_RECOVERY_AREA/orcl/datafile/eg.274.583173327
What scenario you suggest to me to overcome this problem? (Oracle 10g R2, RAC)
Thanks.
August 22, 2007 - 1:32 pm UTC
please utilize support.
A reader, May 28, 2008 - 2:29 am UTC
Hello, I have a question.
For example we have a data corruption error in one file. But let's suppose than we discover that one day after the corruption has occurred. Let's suppose we have all the archive logs and a backup. Then we use the command:
.
.
rman> BLOCKRECOVER DATAFILE <N1> BLOCK <N2>
.
.
And then everything is ok. But, my question is, when a i have data changed after the block corruption has occurred, will it be recovered after the backup ? For example i have one day after a change in the same fail but not in the same block. Will it be recovered this data ?
Best Regards,
May 28, 2008 - 9:33 am UTC
I'm not sure what you are asking.
If you are asking "if I suffer another failure, can I recover from that", then the answer would be "if you have your backups and all archives and online redo log, yes"
Block Corruption
Sagar, June 01, 2008 - 1:04 am UTC
I got block corruption in my test database 9.2.0.6.0 Enterprise Edition on linux in file from system tablespace.This database is running on VMware running on Windows Vista.
This was just a test database. I have some doubts.
1. It seems from this thread that there is no way to avoid this problem or know it beforehand.we can just be ready for it.It just happens rarely.Is this correct?.
2.Only solution is to restore database from backup right?.
June 02, 2008 - 7:44 am UTC
1) this is why we have backups - so you can restore and recover them.
Yes, file systems can fail us
Yes, hardware can fail us
Yes, software in general can fail us
2) not the entire database - no, and maybe just the block in question (rman has block level recovery) which would not entail any downtime depending on the affected block. In some cases - depending on the block itself, maybe not even a recovery - just a rebuild of a index perhaps (if it was an index block) - system makes this a little special (probably recovery since SYS objects in general cannot be touched by normal means)
blockrecover with corrupt redo group
Sam, December 23, 2008 - 10:49 am UTC
Hi Tom,
DB: 10.2.0.1 on Solaris
We had a network failure which resulted in some corrupt blocks. The same failure also caused us to have a corrupt redo group.
We had to clear the entire redo group with the "unarchived" option (as the header was corrupted).
We now have a block that was corrupted because of the same failure. This block needed the unarchived redo log to recover.
At this point the only thing we can do is to recover the block upto just before the failure time. Any changes from the damaged redo file are lost.
So if we recover the block to a scn earlier than the rest of the database will it create any inconsistency issues ?
Thanks
Sam
December 29, 2008 - 3:12 pm UTC
... So if we recover the block to a scn earlier than the rest of the database will it create any inconsistency issues ? ...
yes, and it won't let you do that.
please utilize support to discuss your options
John Carew, April 21, 2010 - 6:13 pm UTC
Hi
As far as I know, if rman finds block corruption, it will terminate the backup session.
However, in my scenerio, rman skipped the corrupted block and continue taking backup of remaining datafiles.
What is the reason for this?
The below is the end of the logfile:
channel t4: backup set complete, elapsed time: 01:02:50
released channel: t1
released channel: t2
released channel: t3
released channel: t4
released channel: t5
released channel: t6
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on t2 channel at 03/20/2010 17:29:52
ORA-19566: exceeded limit of 0 corrupt blocks for file /dbs02/prd/mis_refrence.dbf01
Recovery Manager complete.
April 21, 2010 - 6:28 pm UTC
it looks like it stopped to me? more details please
undo datafile corrupted - ORA-00704
Andre, May 22, 2020 - 8:53 am UTC
Dear Tom & associates experts
We are running 12.1c database and RMAN regularly runs.
Problem
Database crashed and alert-log pointing to a corrupted UNDO (8GB dbf)
We had attempted to recover with RMAN from a backup taken 5 days earlier and all archived logs - PITR to when we knew the main j
obs had finished fine
But ... when we tried to open the database we got
ORA-00704: bootstrap process failure
RMAN retention was set to 21 days - so we tried 14 days back and the same ORA-00704: bootstrap process failure
ORA-00376: file 77 cannot be read at this time (77 = UNDO dbf)
Oracle support told us that it would NOT be possible to open database without a good UNDO as it is needed for crash recovery and
if we were unable to find an RMAN backup with a healthy UNDO - we were OUT OF LUCK and we would not be able to get this databas
e back at all.
+
I have worked with Oracle since 1989 and have never confronted such a case - however surely there must be (should be) a way to o
pen the database in MANUAL undo + create a new UNDO and switch over.
If we can very safely establish a PITR for which we know that all was OK - then we should be able to open the database even if t
here were some transactions that would need to be restored.
+
We were lucky in a way that an RMAN backup from 20 days back that we ended up using had the UNDO in an UN-corrupted state so we
PITR was finally successful - - but ... suppose it was not available ...?
Could you please enlighten me - if this is REALLY true that once you do not have UNDO and database open produces bootstrap error
= you are done - i.e. you are facing a total disaster = loss of the entire database.???
Thanks
Best wishes
Andre Switzerland
May 26, 2020 - 5:42 am UTC
Potentially....yes. You *could* lose it all.
There are some emergency options that can be tried in these *last resort* situations, that you should only ever do with the guidance of Support.
1) Try to force open the database
You go back to manual undo to avoid any reference to the undo tablespace
undo_management = manual
rollback_segments = (system)
and you then need to tell the database that the undo is corrupted
_corrupted_rollback_segments = ( a list of all of your undo segments )
Then you startup in upgrade mode, create a new undo tablespace, stop/start the database with the standard init.ora and pray :-)
Typically you would immediately export the database and import into a fresh one
2) Allowing data corruptions
Sometimes if this does not work, you head down into the road of setting things like
_allow_resetlogs_corruption = true
_allow_read_only_corruption = true
and opening the database with resetlogs. Once again, no guarantees and you immediately export the database and import into a fresh one
3) external options
If you cannot get your database open at all, there are solutions out there that read the datafiles directly and try to extract as much data as they can.
With *all* of these options, the risks are high, and it is quite possible that you can end up in a worse position than when you started....
You've been warned :-)
undo datafile corrupted - ORA-00704
Andre, May 30, 2020 - 2:53 pm UTC
undo datafile corrupted - ORA-00704
Andre, May 30, 2020 - 2:59 pm UTC
Andre, May 30, 2020 - 3:06 pm UTC
Dear Connor,
Once I submitted my follow-up - then I saw your response dated May-26
Thank you
I had saved ALL database files + control etc into a different file system - so in theory I could be in a position to try options you had listed.
However - you mentioned to do that with Oracle Support assisting and the one who joined at that time appeared not to know any of these options.
I think I could transfer all DBF files into a file system mounted for a UAT database and attempt these options.
Before I do anything of the sort - is there any specific comprehensive Oracle documentation that deals with such issues and solutions that you had listed..? or is it just your own personal experience?
Thanks
Best wishes
Andre
June 03, 2020 - 5:31 am UTC
The closest you will get is probably the backup/recovery reference where there is a section about recovery from loss of all files, but that always runs under the assumption that they are not corrupted.
The notes I provided were just from the (rare) need to do it myself over the years as a DBA.
The reason I suggest always enlisting the help of Support for this, is that if things get *worse* then they may be able to help.
If you are not happy with your Support techniican, you can escalate the call.
undo datafile corrupted - ORA-00704
Andre, June 04, 2020 - 7:43 am UTC
checking in
A reader, June 15, 2020 - 7:09 am UTC
Dear Connor,
Once I submitted my follow-up - then I saw your response dated May-26
Thank you
I had saved ALL database files + control etc into a different file system - so in theory I could be in a position to try options you had listed.
However - you mentioned to do that with Oracle Support assisting and the one who joined at that time appeared not to know any of these options.
I think I could transfer all DBF files into a file system mounted for a UAT database and attempt these options.
Before I do anything of the sort - is there any specific comprehensive Oracle documentation that deals with such issues and solutions that you had listed..? or is it just your own personal experience?
Thanks
Best wishes
Andre
June 16, 2020 - 3:12 am UTC
As I said before:
The closest you will get is probably the backup/recovery reference where there is a section about recovery from loss of all files, but that always runs under the assumption that they are not corrupted.
The notes I provided were just from the (rare) need to do it myself over the years as a DBA.
The reason I suggest always enlisting the help of Support for this, is that if things get *worse* then they may be able to help.
If you are not happy with your Support techniican, you can escalate the call.
Also...ALWAYS keep a copy of the files you *currently* have, so you never end up in a worse position than what you are in now