Re: Current Redo got deleted
Date: Mon, 23 Mar 2015 01:05:52 -0400
Message-ID: <550F9F30.6070600_at_yahoo.com>
On 03/22/2015 10:15 PM, Don Seiler wrote:
> Having duplexed redo logs in a different disk group would most
> definitely have given us a good shot at not having to fail over (and
> go through all the app server changes that is part of our internal
> process). The entire database is on that SAN and only one disk was
> affected.
Hold on, are you telling me that you don't have redo logs on RAID 1+0 LUN? If only a single disk was affected, which sometimes happens, RAID 1+0 should be able to tolerate a single component failure.
> Granted having duplexed logs does incur a bit more log file sync
> waits, but that's the trade-off we've come to accept for now.
Not just more waits, it will also include some CPU in the system mode and reduce the system IO throughput. Basically, duplex redo logs are software RAID. My understanding was that SAN devices are bought precisely to offload such things from DB servers.
> Perhaps as we move to new storage hardware and the vendor can assure
> us beyond any doubt that we would be safe from such problems, we might
> consider changing. But it would take a lot for us to let our guard
> down now.
There is no 100% guarantee. However, standby looks like a reasonably
good assurance to me.
>
> Yes we normally run with flashback on. The database is 28TB.
> Rebuilding it would have taken days
That depends on the backup mechanisms. I have rebuilt 10TB database on another machine using FlexClone in exactly 30 minutes. Granted, your database is almost 3 times the size, but the underlying mechanism is the same. I am not sure how much slower would hardware revert to snapshot be with 28TB, but I assure you that I would be able to get the database back in a few hours, in the worst case scenario. Let me add the fact that the tape backup of such huge databases is all but useless and would take several dog years to restore. For such monsters you have to look beyond LTO-6.
> compared to flashback and conversion which took about an hour. Any
> performance penalty from having flashback on is acceptable for us
> provided the benefits we have already seen from it.
>
> Don.
>
Great! I like seeing people who know what are they doing. Flashback offerss a great protection mechanism, but not quite free. It carries definite performance penalty. I can recommend the following two excellent articles written by Jonathan:
https://jonathanlewis.wordpress.com/2015/03/09/flashback-logging/ https://jonathanlewis.wordpress.com/2015/03/11/flashback-logging-2/
Flashback writer writes committed data blocks from SGA to flashback logs in a fashion similar to what Oracle 8i was doing when it was put in the backup mode. Flashback logs cause flashback checkpoints on the log switch and if you are doing direct writes, as in "direct LOB writes", you will wait for those checkpoints to complete, since the blocks are not in SGA Performance penalty can be quite severe, but you already know that. Security that it offers is also great. I too advise running production databases with flashback turned on, whenever the hardware can sustain such configuration.
-- Mladen Gogala Oracle DBA http://mgogala.freehostia.com -- http://www.freelists.org/webpage/oracle-lReceived on Mon Mar 23 2015 - 06:05:52 CET