Corrupt Logfile

thats why you multiplex the redo logs isnt it

Quote:

---

Originally Posted by yxez

This is really the disadvantage of oracle against mssql server, it is very strict when in comes to integrity.

---

I agree. Another disadvantage is the blazing fast speed of Oracle, why can't we slow it down? :confused: :confused: :confused: :confused: :confused:

Quote:

---

Originally Posted by marist89

Hmm, you want three copies of the log files and only two of the control files? You definitely want multiple copies, but with each copy comes performance implications.

3-4 log groups may or may not be appropriate. This is a generalization (to which I don't agree because it doesn't fit every case) and needs to be understood before implementing.

---

He is not running in archive log mode. Hence my recomendation of 3-4... vs 8. Seriously doubt 8 is needed. 3 or 4 properly sized groups should be adequate for 80% of the systems.

YES 2 control files are probably adequate, 3 would be better. But these should be on seperate mirrored raid devices. The reason is if any one is corrupted the instance will STOP. But too many, not only decreases performance, it also decreases availability since you would be adding them to seperated device, consequently reducing the overall MTBF.

A good strategy: alter database backup control file to trace;
Then if you do loose all of your control files. Its pretty easy to recreate!

Now, for the redo log members. The reason for at least 3, is because of exactly this scenario that this fellow encountered. Say there are 1 or 2 members.. Well if one is logically corrupted, then how can oracle know which one is correct? All it can do is say, there is an error. If there are 3 members. Then the majority would win. There should be no performance penalty for multiple members given that most modern O/S have Async I/O capabilities. (assuming the user properly lays out the disk correctly, isolating random i/o from sequential I/O).

YMMV

Quote:

---

Originally Posted by yxez

Hi Friends,

Try to create new logfile groups...and drop the corrupted ones.

This is really the disadvantage of oracle against mssql server,
it is very strict when in comes to integrity.
Supposing I got redolog corruption todate (same scenario with
GARYM) but i want to get my data as of yesterday...since all of the
datafiles are still intact. And i know how to restart the process
or redo it manually all the transaction made during the day coz
supposing i know my application very well, or maybe its just a test
database.
Can I not forced it to startup? Disregarding all the transactions today. My point is since the datafiles are still intact why I am not
allowed to open it? and just put it tob waste :p

Thanks a lot

---

You could restore from a backup, prior to the point in time of interest. Then do a point in time recovery.

Oracle is very flexible, and allows you to shoot yourself in the foot if you so choose.

Quote:

---

Originally Posted by marist89

I agree. Another disadvantage is the blazing fast speed of Oracle, why can't we slow it down? :confused: :confused: :confused: :confused: :confused:

---

I agree, lets slow it down! Just put all datafiles and redo logs on one very slow disk device. Size redo logs to 1 meg, 2 groups, and enable archive logging. It should be very slow. Oh, and a tiny sga... And use a Microsoft OS. That way not only will it be slow, it will have a single point of failure.

Mmm......Remembering the days on win NT/95 oracle 7.X......