This presents an interesting question -- can you turn your normal redundancy disk group into a high redundancy by using a diskgroup template with high protection attribute thus telling ASM to use triple mirroring for related files?
I'll start by creating a diskgroup:
SQL> create diskgroup data normal redundancy 2 disk '/dev/sdb1', '/dev/sdc1', '/dev/sdd1'; Diskgroup created.I'm not explicitly specifying any failgroups, each disk will end up in it's own FG and triple-mirroring will spread extents across all three disks. Let's add a high protection template:
SQL> alter diskgroup data add template mirror_high attributes (high coarse); Diskgroup altered.Now let's create two tablespaces, one using the default mirroring template (two-way) and one using mirror_high (three-way) template:
SQL> create tablespace mirror_normal datafile '+data' size 256m; Tablespace created. SQL> create tablespace mirror_high datafile '+data(mirror_high)' size 256m; Tablespace created.We can confirm how many mirror extents our datafiles have:
SQL> select a.name, case LXN_KFFXP when 0 then 'primary' when 1 then 'secondary' when 2 then 'third' end, count(*) from X$KFFXP, v$asm_alias a where a.file_number=NUMBER_KFFXP group by a.name, LXN_KFFXP order by 1, 2; 2 3 4 5 6 7 8 9 10 NAME CASELXN_K COUNT(*) ------------------------------ --------- ---------- MIRROR_HIGH.257.787940101 primary 258 MIRROR_HIGH.257.787940101 secondary 258 MIRROR_HIGH.257.787940101 third 258 MIRROR_NORMAL.256.787940093 primary 258 MIRROR_NORMAL.256.787940093 secondary 258 MIRROR_NORMAL.256.787940093 third 1 6 rows selected.Indeed, all extents got triple mirrored for MIRROR_HIGH tablespace and only double mirrored for MIRROR_NORMAL (with the exception of one extent which probably holds some triple-mirrored metadata).
Now, because all data essentially got triple mirrored for our MIRROR_HIGH tablespace it ought to survive two disk failure, right? Let's give it a try:
SQL> alter diskgroup data dismount; Diskgroup altered.... then I'm going to change the permissions and make two disks inaccessible to ASM:
[oracle@ora11gr2 ~]$ chmod 000 /dev/sdc1 [oracle@ora11gr2 ~]$ chmod 000 /dev/sdd1Let's see if I could mount it back:
SQL> alter diskgroup data mount force; alter diskgroup data mount force * ERROR at line 1: ORA-15032: not all alterations performed ORA-15017: diskgroup "DATA" cannot be mounted ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"...looks like the answer is no. It still sees that the remaining disk is missing required partners and does not allow the disk group to be mounted. How many extent copies the datafile had becomes a moot point.
The conclusion is that triple-mirroring inside a normal redundancy disk group can help you in certain cases (like physical corruption of both primary and secondary extents so ASM can use a third one to read the data) but it's not a substitute for a high redundancy disk group.
Update a little bit later: if anyone is thinking about doing it the other way around then remember that mirroring attribute works only for normal redundancy disk groups.
just a guess ... if you have only tablespace with "mirror_high" template on DG, what would be result?
ReplyDeletecheers,
goran
Goran, the outcome will be the same, I think this has mainly to do with PST but I might dig a bit further using kfed when I get some time.
ReplyDelete