Re: What to keep in ASM?

  • From: "Alex Gorbachev" <gorbyx@xxxxxxxxx>
  • To: "Don Seiler" <don@xxxxxxxxx>
  • Date: Mon, 26 Feb 2007 17:24:14 -0500

On 2/26/07, Don Seiler <don@xxxxxxxxx> wrote:
On 2/26/07, Alex Gorbachev <gorbyx@xxxxxxxxx> wrote:
Does it make any sense to multiplex controlfiles/redo within the same
disk group?  We were only planning on one disk group, so that's
another reason why I thought it might make sense to multiplex outside
of ASM.  Perhaps with striping it isn't an issue.

If it would be on filesystem - you might protect yourself from human
mistake of removing one redo log. About a year ago I remember the case
when DBA overwrote one copy of controlfile with small typo in tar
command. On the other hand, you won't be protected from "rm -f *". You
still can remove files from ASM but it's not that easy and it won't
delete file that is in use.

In ASM - I don't see much sense to multiplex redo/controlfiles in the
same disk group. You might put another controlfile into your FRA
diskgroup, for example (you won't be able to unmount it then). I don't
like to rely of FRA availability but every case is different. You do
have disk mirroring somewhere anyway. Don't you? Mirroring on SAN or
ASM or at least RAID-F in the worst case.

> In this case I would doubt if you really need ASM at all but that's
> another story. ;-)

Mainly for the auto management of it.  Obviously we've gotten this far
without it, but I'd like to take advantages of some of the really nice
features of 10g EE (ASM/ASSM/OMF) to save me a few keystrokes and
headaches now and then.

ASM has nothing to do with ASSM. You can also use OMF with file system
just fine.
Just list the feature that you think you will benefit from when using
ASM. Then decide if it's worth the hassle of learning new technology
and introduce one more component into your infrastructure.
Note that I'm not against ASM -- we do have quite a few customers
using it without real problems. Real problems in this case I mean
corruptions. Not bad for something so new in Oracle. ;-)

> As I mentioned, if you have dedicated DG for backup only (not FRA
> location) than you should be able to unmount it and temporary mount on
> your development machines subject to SA policies.

Gotcha.  Makes a lot more sense than the first time I read it!

Cool. Back to my English course then... ;-)

--
Best regards,
Alex Gorbachev

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


Other related posts: