Re: Issues with server and need to restore controlfiles and spfiles

  • From: Sandra Becker <sbecker6925@xxxxxxxxx>
  • To: tim.evdbt@xxxxxxxxx
  • Date: Mon, 10 Jan 2022 16:08:37 -0700

We are using ASMLIB as far as I know.  I have asked numerous times over the
past 18 months since we inherited these databases to upgrade both oracle
and RHEL.  I was told no every time because they weren't sure if their
applications would work with newer versions.  Since that time, management
decided we never needed to upgrade again and canceled our support licenses
with Oracle.  I was told that meant we could no longer download upgrades
and patches.  Rock and a hard place these days.

Sandy

On Mon, Jan 10, 2022 at 1:34 PM Tim Gorman <tim.evdbt@xxxxxxxxx> wrote:

Sandy,

Just curious:  which mechanism are you using to persist the addresses of
the SCSI devices across reboots?  ASMLIB?  Linux UDEV?

If the pathname of the ASM disk are something like "/dev/sdc1" or
"/dev/dm-3", then you're using device naming which changes on reboot, and
probably should review Oracle Support Document 1365511.1 (How to
Configure LUNs for ASM Disks using WWID, DM-Multipathing, and ASMLIB on
RHEL 5/OL 5 and  RHEL 6/OL 6  and RHEL7) which can be found at:
https://support.oracle.com/epmos/faces/DocumentDisplay?id=1365511.1.

And, as a side note, please press them to upgrade to at least to 11.2.0.4
on RHEL7?  Friends don't let friends run 11.2.0.1, as 11.2.0.1 is an
example of where the maxim "*if it ain't broke don't fix it*" never even
applied;  it was broke from the start.  The only good 11g database is an
11.2.0.4 database;  every other release in 11.1 and 11.2 is a crisis
waiting to happen.

Hope this helps...

-Tim


On 1/10/2022 11:36 AM, Sandra Becker wrote:

Oracle Database & Grid:  11.2.0.1
OS:  RHEL5.5

We had some issues with a database server and the 9 databases stopped
working.  The sys admins suggested a reboot, which we did.  GRID/ASM would
not come back online after the reboot.  It says it can't find the ASM
disks, but everything the sys admins look at say they are there and
online.

We tried restoring the  $GRID_HOME, but that didn't change anything.  Our
Rimini support said a lot of libraries were missing from the $GRID_HOME, so
another DBA tried to getting the missing files.  Still no luck.  It's a
two-node RAC, but only one of the nodes was functional at the time we
rebooted the first node.  The second has the same issues as the first, so
we can't bring anything online there either.

We tried setting up on another comparable cluster, but due to the way the
database configurations were done in CommVault for the "bad" server,
CommVault thinks they are single instance and won't let us restore to a RAC.

Ultimately, we want to move these databases to a non-ASM server in AWS.
Any suggestions as to what we can do?  I was wondering if we could
reinstall GRID/ASM on the "bad" server and then use Commvault to do our
restores.  Is that totally off base or a viable option?

--
Sandy B.




-- 
Sandy B.

Other related posts: