RE: ASM disk sizes

From: Herring, David <HerringD_at_DNB.com>
Date: Mon, 8 Jul 2013 12:57:17 -0500
Message-ID: <AD8FE6616C097545A4C9A8B0792909AC29103C3E0D_at_DNBEXCH01.dnbint.net>



Ryan,

I was going to let the issue drop until I heard the word "luxury" and then, in my mind, I felt there needed to be some education.

2 things I'm sure of: rebalance ONLY happens when you issue it and Oracle tries to smear each file evenly across every available disk in the diskgroup. But in this case I'm mystified by the following:

LABEL		TOTAL_MB	FREE_MB	USED_MB	% Used
ASM001	511,985		347,353		164,632		32.16%
ASM002	430,076		291,885		138,191		32.13%
ASM003	143,353		97,309		46,044		32.12%
ASM004	122,879		83,342		39,537		32.18%

The 4 disks are evenly balanced in terms of % used but not in terms of AU's allocated. I would have expected the USED_MB to be about 97,000 per disk, regardless of their TOTAL_MB. I need to do some more investigating as the diskgroup is shared by 5 different dbs, so I want to check AU counts per disk per file.

Dave
-----Original Message-----
From: Ryan January [mailto:rjjanuary_at_multiservice.com] Sent: Monday, July 08, 2013 12:11 PM
To: Herring, David
Cc: oracle-l_at_freelists.org
Subject: Re: ASM disk sizes

I wouldn't go quite so far as calling same sized disks a luxury, but there are times in which you need to work within the SAN teams constraints. I have had a few scenarios where we've had differing sized Disks in a DG. In almost all cases they were temporary solutions to an immediate problem.

As far as the rebalance is concerned; isn't the disk group working as intended? From the 11g docs: "Rebalancing a disk group moves data between disks to ensure that every file is evenly spread across all of the disks in a disk group. When all of the files are evenly dispersed, all of the disks are evenly filled to the same percentage; this ensures load balancing."

Have you ruled out a bug in your version(s)? If I recall correctly, there have been a few bugs in both 10 and 11g which caused interesting behavior on disparate disk sizes. Unfortunately I don't have any further details as we vary rarely ran into imbalance issues.

On 07/08/2013 11:17 AM, Herring, David wrote:
> Folks,
>
> I'm running into a discussion with another DBA on our team concerning differing disk (or LUN, but for the sake of simplicity let's just say "disk") sizes within ASM. Best practices for ASM say to use consistent sizes of disks within a diskgroup and I'm sure many of us have run into situations where there was an inconsistency, the smallest disk filled and suddenly Oracle gave space errors even though there was plenty of space on the larger disks. That's just one example of issues that can arrise.
>
> Back to the discussion, I'm told that:
>
> 1) Having consistent disk sizes is a "luxury"
> 2) Many places have inconsistent disk sizes, within diskgroups, and work just fine.
>
> Do many of you currently or in the past worked on dbs where the disks were differently sized within diskgroups for ASM? Do most/any of you see consistent disks within diskgroups as a "luxury" and that instead you accept whatever the SAN team gives you?

>
> Even though I've run into issues concerning space with inconsistently sized disks on 10g and 11g and performed A LOT of detailed tracking of the arb processes doing their rebalance work, I'm being ignored. It's rather frustrating to say the least. In one diskgroup they've got disks of 511 GB, 430 GB, 143 GB, and 122 GB. They're all about 32% used so the best as I can figure is rebalance operations weren't fully performed when disks were added.
>
> Dave Herring
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

-- 


------------------------------------------------------------------
This email is intended solely for the use of the addressee and may contain information that is confidential, proprietary, or both.
If you receive this email in error please immediately notify the sender and delete the email..
------------------------------------------------------------------

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Jul 08 2013 - 19:57:17 CEST

Original text of this message