RE: ASM disk corruption
- From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
- To: <andrew.kerber@xxxxxxxxx>, "Harel Safra" <harel.safra@xxxxxxxxx>
- Date: Mon, 22 Nov 2010 20:17:11 -0500
I am not sure which vendors thin provisioning you are talking about, but
the 3par Thin Provisioning works fine with Oracle ASM and RAC for ocr,
voting and data ASM volumes. Smallest LUN size in 3par is 1gb.
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Kerber
Sent: Monday, November 22, 2010 4:02 PM
To: Harel Safra
Cc: pnedeljkovich@xxxxxxxxxxxxxxx; Amaral, Rui; oracle-l@xxxxxxxxxxxxx
Subject: Re: ASM disk corruption
Yup, thats what we did too. Like I said, we never did figure out how it
got overwritten. Problem was our smallest possible LUN size was 17G,
thats an awful lot of wasted space once you make 3 (or 5) of those. Of
course thin provisioning might allow us to work around that eventually,
but that seems like a technology that isnt well tested in Oracle
clusterware.
Anyway, thats kind of OT. I will be really interested to see if the OP
can find a cause of the problem.
On Mon, Nov 22, 2010 at 2:40 PM, Harel Safra <harel.safra@xxxxxxxxx>
wrote:
We have a dedicated disk group for ocr/voting that's just 1GB and
doesn't contain data files.
It made sense (to me at least...) to separate OCR from other data for
later database cloning, etc.
Harel Safra
On 22/11/2010 21:39, Andrew Kerber wrote:
MOS recommendation was to use normal or high redundancy instead of
external. Like we could waste all that space.
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
Other related posts:
