RE: Anyone tried kill ASM in 11gR2 RAC?
Date: Thu, 21 Jan 2010 08:36:36 -0500
Yep, makes sense, I think.
Clusterware starts, ASM serves up OCR and voting disk geometry, as it relates to raw devices that make up your OCRDATA diskgroup. Clusterware caches that info, no longer needs to talk to ASM for it.
You do the damage, including changing ownership of devices that make up OCRDATA diskgroup to root:root. But, clusterware processes run as root, so, they can still read/write those raw devices.
What happens if you chown the devices to root:root, then also chmod 000 all those devices?
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of LS Cheng
Sent: Thursday, January 21, 2010 7:44 AM
To: K Gopalakrishnan
Cc: Oracle Mailinglist
Subject: Re: Anyone tried kill ASM in 11gR2 RAC?
So even OCRDATA Disk Group is not mounted and the physical disks has root.root instead of grid.oinstall ownership Clusterware will be up and running? So basically you mean Clusterware does not need ASM to be up to access the OCRDATA disks?
My test was
- kill ASM
- change asm disks (OCRDATA) from grid.oinstall to root.root
- check clusterware status which was up and running
On Thu, Jan 21, 2010 at 1:38 PM, K Gopalakrishnan <kaygopal_at_gmail.com<mailto:kaygopal_at_gmail.com>> wrote: Clusterware failure will happen _only_ when it can not acess the physical devices (disk timeout in css) and shutting down ASM does not revoke the access to disks. In your case clusterware _knows_ the location of ocr/voting information in ASM disks and it can continue reading/writing even ASM instance is down.
On Thu, Jan 21, 2010 at 2:51 AM, LS Cheng <exriscer_at_gmail.com<mailto:exriscer_at_gmail.com>> wrote:
> I was doing some cluster destructive tests on RAC 11gR2 a few days ago.
> One of tests was kill ASM and see how does that affects Clusterware
> operation since OCR and Voting Disks are located in ASM (OCRDATA Disk
> Group). After killing ASM nothing happened as it was quicky started up
> again. So far so good. The next test was same test but changing the ASM
> Disks ownership so when ASM is restarted OCR Disk Group cannot be accessed.
> Surprisingly ASM Was started up, Database Disk Group was mounted OCR disk
> Group obviously did not get mounted but then the Cluster was working without
> any problems.
> So how is this happening? Doesnt Clusterware need to write and read to
> Voting Disk every second? I was expecting a Clusterware failure in the node
> but everything worked just as everything were ok.