Re: Unexpected behavior from ASM (?)

ASM should check for permissions, and the alter disk group should fail if it doesn't have permissions to the devices.

Is is possible that someone (evil sysadmin) changed permissions on those devices after the fact? That seems the most likely cause...

-Mark

From: <Hubler>, Daniel <daniel.hubler_at_aurora.org<mailto:daniel.hubler_at_aurora.org>> Reply-To: "daniel.hubler_at_aurora.org<mailto:daniel.hubler_at_aurora.org>" <daniel.hubler_at_aurora.org<mailto:daniel.hubler_at_aurora.org>> Date: Wednesday, March 19, 2014 at 9:03 AM To: "oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>" <oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>> Subject: Unexpected behavior from ASM (?)

Oracle DBMS v11.2.0.3
2-node RAC
ASM on raw devices
AIX v6.1
(a TEST environment !)

Added a bunch of raw devices into ASM using the following: ===
SQL> alter diskgroup data
add disk '/dev/rhdisk35','/dev/rhdisk36','/dev/rhdisk37','/dev/rhdisk38','/dev/rhdisk39','/dev/rhdisk40','/dev/rhdisk41' rebalance power 8;

Diskgroup altered.
===

Shortly (minutes) after this completed,
both database instances crashed.
ASM survived.

Immediately started looking at the details on these raw devices. Discovered that the permissions on some of them were incorrect; missing various r-w permissions.

Changed those permissions.
Restarted the DBMS instances successfully; no issues since.

I guess my question is, how did this get past ASM ? Does it not check for this?

(the coincidence is that the AIX-admin who built the raw devices was doing this for the first time)

Thanks for any input.

Daniel Hubler
Aurora Healthcare
IT Infrastructure
daniel.hubler_at_aurora.org<mailto:daniel.hubler_at_aurora.org>

--
http://www.freelists.org/webpage/oracle-l