RE: ASM disks and how disks are balanced.
- From: John Hallas <John.Hallas@xxxxxxxxxxxxxxxxxx>
- To: Suse Shi <sinosuse@xxxxxxxxx>, Herring Dave - dherri <Dave.Herring@xxxxxxxxxx>
- Date: Tue, 15 Nov 2011 15:40:30 +0000
Thanks Suse.
This is a quiet test system so the rebalance level was OK at 8.
I agree that it is not the most important thing in the world but I am only
challenging the documentation that states that disks are rebalanced evenly. I
can see that they are with FRA diskgroups but not with DATA ones.
I am working on Dave's suggestion of multiple consecutive rebalances and I can
see it makes a subtle difference (there are about 10 rebalance commands between
the 3 snapshots shown below) but not a massive difference.
NAME AU(Mb) MIN MAX AVG
------------------------------ ---------- ---------- ---------- ----------
DATA 8 48528 51496 50278.1176
DATA 8 48560 51496 50278.1176
DATA 8 48912 51232 50278.1176
I have also looked at the imbalance between files and I cannot see anything
difference or improvement after doing the imbalances. Unfortunately the biggest
difference I can see is on a production database diskgroup and I cannot
experiment with that.
John
From: Suse Shi [mailto:sinosuse@xxxxxxxxx]
Sent: 15 November 2011 14:48
To: John Hallas
Cc: Oracle-L Group
Subject: Re: ASM disks and how disks are balanced.
Hi John,
from your query, we can see the disks space in a very similar scope.
I think it's expected and no worry at the difference on data, ASM instance
will try to do rebalance jobs and keep space-usage 'SAME' on different disks,
but it doesn't mean that ASM diskgroup will do rebalance once there're tiny
modifications, that should be a waste of performance.
If you're working on a test environment, just do add/drop disks, add/drop
large files jobs and see the changes, I think the difference will always be in
an acceptable scope.
btw, if your systems are in busy transactions state, please don't set power
value so high as '8', it will also decrease the database i/o performance.
wish helps,
-S
2011/11/15 John Hallas
<John.Hallas@xxxxxxxxxxxxxxxxxx<mailto:John.Hallas@xxxxxxxxxxxxxxxxxx>>
Looking at a variety of systems I can see that there is a difference between
the space available on each disk of a ASM disk group.
This is despite the documentation stating :-
If the disks are the same size, then ASM spreads the files evenly across all of
the disks in the disk group. This allocation pattern maintains every disk at
the same capacity level and ensures that all of the disks in a disk group have
the same I/O load. Because ASM load balances among all of the disks in a disk
group, different ASM disks should not share the same physical drive.
The following query shows a selection of databases and how the disks are
striped. In all examples the disks in the disk group are the same size -
normally 100Gb
Select dg.name<http://dg.name>,dg.allocation_unit_size/1024/1024
"AU(Mb)",min(d.free_mb) Min, max(d.free_mb) Max, avg(d.free_mb) Avg
from v$asm_disk d, v$asm_diskgroup dg
where d.group_number = dg.group_number
group by dg.name<http://dg.name>, dg.allocation_unit_size/1024/1024
/
NAME AU(Mb) MIN MAX AVG
------------------------------ ---------- ---------- ---------- ------
FRA 1 11364 11470 11390
DATA 1 8282 14258 9170
NAME AU(Mb) MIN MAX AVG
------------------------------ ---------- ---------- ---------- ------
FRA 1 72659 72920 72837
DATA 1 19377 30987
22157<tel:30987%C2%A0%2022157>
DATAMRDW 8 10464 15536 11654
NAME MIN MAX AVG
------------------------------ ---------- ---------- ------
DATA 47056 50344
48131<tel:50344%C2%A0%2048131> -- before rebalance
FRA 22740 22769 22752
alter diskgroup data rebalance power 8;
NAME AU(Mb) MIN MAX AVG
------------------------------ ---------- ---------- ---------- ------
FRA 1 22740 22769 22752
DATA 8 47824 49096 48131 -- after
rebalance - no real difference
______________________________________________________________________
Wm Morrison Supermarkets Plc is registered in England with number 358949. The
registered office of the company is situated at Gain Lane, Bradford, West
Yorkshire BD3 7DL. This email and any attachments are intended for the
addressee(s) only and may be confidential.
If you are not the intended recipient, please inform the sender by replying to
the email that you have received in error and then destroy the email.
If you are not the intended recipient, you must not use, disclose, copy or rely
on the email or its attachments in any way.
This email does not constitute a contract in writing for the purposes of the
Law of Property (Miscellaneous Provisions) Act 1989.
Our Standard Terms and Conditions of Purchase, as may be amended from time to
time, apply to any contract that we enter into. The current version of our
Standard Terms and Conditions of Purchase is available at:
http://www.morrisons.co.uk/gscop
Although we have taken steps to ensure the email and its attachments are
virus-free, we cannot guarantee this or accept any responsibility,
and it is the responsibility of recipients to carry out their own virus checks.
______________________________________________________________________
--
//www.freelists.org/webpage/oracle-l
Other related posts:
