RE: Does ASM's EXTERNAL REDUNDANCY concatenate? (maximum disk group size)
Date: Tue, 1 Jul 2008 08:51:19 -0400
Please correct me if I'm wrong - I think you are referring to the 4-petabyte-per-disk-GROUP promise. If there is a 4-petabyte per disk promise somewhere that is indeed a farce for at least a few years from now.
As for disk groups, I guess you're thinking that keeping track of a couple thousand components 2 TB in size to build up the 4 petabyte disk group would be a problem.
Myself, I'd probably rather have a catalog application keeping track of a few thousand pieces than have a unit of physical recovery bigger than 2 TB, anyway.
But I am curious: Is there some other aspect of this issue other than needing a couple thousand pieces that leads you to call it a farce?
Please be assured this is a genuine question. If there is some other logical conundrum to scaling the maximum size of a disk group to what Oracle publishes it to be, we all (including Oracle) win by documenting it exactly. I have high confidence in Oracle to attack and correct such problems over time. Consider Oracle's reaction to my building 9 seven gigabyte databases instead of a single 63 gigabyte database in 1988. That helped them to realize that at the time getting disks bigger than half a gigabyte was expensive and the software to allow logical presentation of multiple disks as a single piece of storage was expensive and unreliable on UNIX, so the practical limit of database size was limited by the 62 open file limit times the half gigabyte disk size rather than the published theoretical limits. So all that was changed by 1990 or so.
So please, if you see some problem other than keeping track of a couple thousand pieces, let us know.
Unfortunately, the only thing this patch "solves", is the corruption issue. With the patch applied (included in my 10.2.0.4), they are simply blocking the addition of disks >2TB with ORA-15099, which makes the 4-petabyte-per-disk-promise in the papers a farce.
--Received on Tue Jul 01 2008 - 07:51:19 CDT