RE: San & single point of failure

The SAN contents weren't destroyed, just disconnected. "Just"!

Of course this disconnect corrupted all copies of the controlfile. If there was a local one, I could have copied it over to the remounted SAN, restarted the DB, and auto-recovery would have taken place with minimal downtime. As it was, the controlfile had to be recreated manually. This not only increased downtime and the greater potential for further human failure, but had the happy side-effect of hosing our recovery scenarios from Tivoli, since the log sequence number was reset and we were not at a point yet of being able to use RMAN (details mercifully omitted).

Rich

> I don't understand what good it does to have the control file alone on
> your local disk in that situation? If your SAN with the rest of your
> database files is toast, then your control file alone isn't going to do
> you much good. You're going to have to restore from a backup and do an
> incomplete recovery anyway, so what's the difference if you do it with
> your current controlfile still on your local disk, or if you restore a
> control file from backup along with the rest of the database files
> you'll be restoring?
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Rich Jesse
>
>
> Good luck convincing anyone that you NEED two mirrored fast local
> drives,
> but maybe this will help:
>
> http://www.freelists.org/post/oracle-l/Write-cache-for-a-SAN,7
>
>
> Privileged/Confidential Information may be contained in this message or
> attachments hereto. Please advise immediately if you or your employer do not
> consent to Internet email for messages of this kind. Opinions, conclusions
> and other information in this message that do not relate to the official
> business of this company shall be understood as neither given nor endorsed
> by it.
>

--
http://www.freelists.org/webpage/oracle-l