I would not recommend to put archivelogs on the same diskgroup as the
By the nature of ASM diskgroups (striping across all Disks) If one of
your disks fail, the whole DG is unusable (As you have no redundancy).
In this case, the DB and archivelogs are lost. (sounds like a kind of
desaster for me)
If you put option 2 so a (single) disk-failure affects either the DB
or the archivelogs. For me this is the better way.
.... It address the above two issues but question is how.
(I havn't tested this procedure right now, so it comes just out of my
memory. Please handle with care, test and re-think before you apply it
1) find the disk you want to remove from your existing diskgroup in v
2) remove it from your existing diskgroup running:
ALTER DISKGROUP dgroup1 DROP DISK diska5;http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/storeman.htm#ADMIN10222
3) check v$asm_operation for a completed drop!
4) check v$asm_disk if the disk is not used anymore (HEADER_STATUS =>
5) create a new Diskgroup with this Disk.
Here is a situation. There are four raw disks( with no redundancy)
assigned to ASM disk group, which contains control files, redo, data,
and temp files. I want to enable archive log mode and keep archives in
a shared file system in ASM. There are two options I can think of
1. Place them under same disk group: This is simplest option but
writing archive logs to the same disk group where datafiles reside
wouldn't be nice (space issues and writing load)
2. Move the data existing on a disk to remaining 3 disks and remove
this disk from existing disk group and create a separate disk group
for Archive logs. It address the above two issues but question is how.
What would you pick outta these two and why ?
application/pkcs7-signature attachment: smime.p7s