RE: ASM Startup Help!
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <peter.sharman@xxxxxxxxxx>, <oraracdba@xxxxxxxxx>, "Michael Saffitz" <m@xxxxxxxxxxx>
- Date: Tue, 21 Dec 2004 14:23:21 -0500
If you're experiencing "device creep", one thing to CONSIDER is using
/etc/scsi.alias together with scsidev (usually -M) in order to give specific
LUNs specific names. Then you need to make sure you understand how to
reference the devices by the scsi.alias name instead of the creeping device
names. Then your /etc/raw file and the subsequent bindings become immune to
the creep. However, (and especially if you're using device virtualization
software with services that get started later than usual for device services
in the boot sequence) you may need to play around with the order and phases
and delays to totally automate rebooting, or defer some of these activites
from the normal order and execute them late in the reboot sequence in an
exact order you know should work. Andy Rivenes mentioned some restart issues
a few weeks ago and you might want to flash back to his work-around to a
particular situation to see if it is applicable to you.
As for the ealier poster (Michael), you mentioned disappearing disks- was
that only on reboot, or did you experience dynamic loss of device visibility
at run time?
Absent evidence to the contrary, I believe "device creep" and timing issues
with respect to the order of starting services are sufficient to explain
devices going missing on a reboot, but if you've seen ASM devices "go
missing" dynamically it gives me the willies!
Regards and Happy Holidays,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Pete Sharman
Sent: Tuesday, December 21, 2004 12:59 PM
To: oraracdba@xxxxxxxxx; Michael Saffitz
Cc: oracle-l@xxxxxxxxxxxxx; Peter Ross Sharman
Subject: RE: ASM Startup Help!
So I'm more positive than Scott is. Wonder why that might be? ;)
The first thing I can think to check is if the permissions or access to the=
devices has been changed on reboot. The order in which the disks are found=
by the RH3 OS can sometimes change on reboot and the persistent binding do=
ne between the raw/raw devices and the raw character devices can sometimes =
get clobbered. The permissions will sometimes be set for certain devices b=
ased on the device number. If the order gets changed and permissions are n=
ot accurate, that too can cause a device to not be discovered. This might =
be the cause and it might not be. One other question, as Scott mentioned, =
is whether you are using ASMLIB or not? If so, the above problems are not =
normally an issue. The second question is does this ASM disk group have AS=
M redundancy or external redundancy?
Of course, you could always try calling support...
BTW, the PST stands for Partner Status Table and the error message suggest =
to me that the disk group does not have the full complement of disks which =
it needs to mount the disk group.
=
Pete
=
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
=
"Oh no, it's not. It's much harder than that!"
Bruce Pihlamae, long-term Oracle DBA
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] =
On Behalf Of Scott
Sent: Wednesday, 22 December 2004 3:11 AM
To: Michael Saffitz
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: ASM Startup Help!
Mike, I hate to be the bearer of bad news but I have
seen this before when using ASM libs. The case of the
disappearing disks. I have had this happen to me on
several occasions and now I just don't use the ASM
libs anymore. =
The only way your are going to fix this problem is to
dd over the device and try to add the disks back into
the disk group.
I hope you don't have critical stuff on that
diskgroup.
Scott
--- Michael Saffitz <m@xxxxxxxxxxx> wrote:
> =
> Yes
> =
> =
> Scott wrote:
> > Mike, Are you using ASMLIBS? =
> > =
> > Scott
> > =
> > =
> > =
> > --- Michael Saffitz <m@xxxxxxxxxxx> wrote:
> > =
> > =
> >>Hello,
> >>
> >>I'm having difficulties starting ASM on RAC. This
> >>was previously
> >>working, the nodes were rebooted, and is now
> >>failing. These are
> >>production databases, so any help is greatly
> >>appreciated:
> >>
> >>SQL> startup;
> >>ASM instance started
> >>
> >>Total System Global Area 75497472 bytes
> >>Fixed Size 777772 bytes
> >>Variable Size 74719700 bytes
> >>Database Buffers 0 bytes
> >>Redo Buffers 0 bytes
> >>ORA-15032: not all alterations performed
> >>ORA-15063: diskgroup "STK" lacks quorum of 2 PST
> >>disks; 0 found
> >>
> >>
> >>the alert log displays:
> >>
> >>NOTE: cache registered group STK number=3D1
> >>incarn=3D0x8f081786
> >>NOTE: cache dismounting group 1/0x8F081786 (STK)
> >>NOTE: dbwr not being msg'd to dismount
> >>ERROR: diskgroup STK was not mounted
> >>
> >>The disks are showing up properly in the OS (RHEL
> >>v3).
> >>
> >>Thanks in advance!
> >>
> >>Mike
> >>
> >>--
> >>//www.freelists.org/webpage/oracle-l
> >>
> > =
> > =
> > =
> > =
> > =
> > __________________________________ =
> > Do you Yahoo!? =
> > Send holiday email and support a worthy cause. Do
> good. =
> > http://celebrity.mail.yahoo.com
> > --
> > //www.freelists.org/webpage/oracle-l
> =
=
__________________________________ =
Do you Yahoo!? =
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
