Separate ASM disk group for online redo log files?
mhoys
In one of the technical papers from Oracle, they recommend to have
only 2 disk groups: one for the data files, and one for the recovery
files (FRA). This means that the online redo log files are included in
the disk group for the data files, but I wonder if this is a set-up
that is followed by most DBA's? I would think that, for performance
reasons, it's best to create a separate third disk group for the
online redo log files? How do you guys do it? :-)
Thanks,
Matthias
Steve Howard
No, we separate them into a separate smaller disk group. Granted,
this is on a database that generates 400GB on average per day of
archived redo logs (and as high as 1.5TB). However, we were getting
killed with checkpointing, so when we moved them to a separate
diskgroup, the problem went away.
As time goes on, I think Oracle tries to make things too simple for
DBA's sometimes, and they ignore physics in the process :)
John Hurley
> Ok, I've read a lot about ASM recently :-)
>
> In one of the technical papers from Oracle, they recommend to have
> only 2 disk groups: one for the data files, and one for the recovery
> files (FRA).
I have 2 disk groups one separate for the online logs and the other
one for everything else.
I am NOT using an ASM based flash recovery area ... not using FRA at
all. My archive logs go into a cooked file system.
I was getting some really nasty funky problems early on trying to
stress test system while using archive log mode going into ASM based
FRA. It was a while back ... but I pretty quick immediately decided I
really did not want to put all my eggs into the ASM basket.
Disk based rman backups go into a cooked file system as do my archive
logs.
If something goes south with ASM and you pretty much lose
everything ... and your backups were inside ASM ... what are you going
to do?
When using ASM for the database and testing recoveries ... one option
( which really really needs to be tested and documented ) is starting
back at the beginning by recreating the ASM disk groups ... ( create
diskgroup blah blah blah FORCE ) ... which also means you are then
going to restore a controlfile backup next ).
Mark D Powell
Matthias, I think the answer depends on preference and if you
underlying logical disks that you assign to the disk group are
separate physical disks or just different logical disk spread across
the same physical disks for both diskgroups.
When the physical disks are the same and the physical disk stripe size
is the same there shouldn't be an IO benefit from separating the two
via ASM. Most disks assigned to ASM are logical disks and it is how
the logical disks are defined that really controls the IO performance.
HTH -- Mark D Powell --
mhoys
Hello Mark,
Yes, I'm well aware that a separate disk group for redo log files is
only useful when the underlying physical disks are split from the ones
in the other disk groups.
Thanks,
Matthias
mhoys
Hello John,
Interesting idea of using ASM only for the "data" files and a cooked
file system for the FRA...
I just realised that we first do a backup on disk and then the backup
software writes the backup files from disk to tape. That would
probably be not possible with ASM as file system, anyway.
Matthias
onedbguru
That depend Mathias,
If you are using 11gR2 you can have a separate disk group and create a
volume with an ACFS file system. While it "lives" in ASM, it is
accessible as a "cooked" file system - and it is expandable while
online - even in a cluster. Oracle liked this feature so well, they
now sell the clusterware+ASM as a standalone product called CloudFS.
and will be the replacement for OCFS2 (OCFS2 is Linux only).
Having FRA or online redo logs on any other OS-level file system would
make it much more difficult should you decide to convert to RAC.
These sorts of "problems" are the reason DBA's need to take a few
courses in System and SAN administration.
Sometimes Sys Admins need to also use their brains - true story - I
was configuring a 10g RAC system which required separate OCR (2
minimum) and VOTING (3 minimum) devices. The smallest LUN the SAN
group was carving was 8GB. These 5 devices need only to be about 500M
max. So, this really smart SA creates 5 partitions on the same
LUN... Does anyone see a problem with this??? Just because you can
do a something, does not mean you should do something. BTW, I have
seen an array lose a LUN before... just in case you did not get the
previous question....
John Hurley
# Interesting idea of using ASM only for the "data" files and a cooked
file system for the FRA...
Like I said we do NOT use FRA at all. We do use rman for a disk based
backup ( which does get copied to tape ). We do run in archivelog
mode and the archive logs are in a cooked file system.
What are your recovery steps exactly if "all" of your ASM based
storage is messed up?
... I just realised that we first do a backup on disk and then the
backup software writes the backup files from disk to tape. That would
probably be not possible with ASM as file system, anyway.
Well sure you could get it done one of several possible ways ... but I
don't want to live like that.
John Hurley
# These sorts of "problems" are the reason DBA's need to take a few
courses in System and SAN administration.
Be specific here ... what exactly are these "alleged" problems? I for
one have no idea where you are trying to stray here.
You seem to have a lot of attitude here in this newsgroup. Let me
guess ... you charge people for these "courses" that you want some
people to take.
The oracle OCR stuff has been a nightmare for many people. I guess
you cannot get away from using Oracle clusterware any longer when
running RAC. One additional argument in my mind for considering why
you probably don't need RAC.