Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Some findings on ASM (Automatic Storage Management)

Some findings on ASM (Automatic Storage Management)

From: GeoPappas <PappasG_at_gmail.com>
Date: 10 May 2005 06:26:27 -0700
Message-ID: <1115731587.335214.277010@f14g2000cwb.googlegroups.com>


I have been testing ASM to see how viable it is for a 24x7 production environment.

I thought that I would share my findings:

(1) It seems that the Oracle dbca (Database Configuration Assistant)
can only create/use an ASM instance with a DB_NAME=+ASM. I believe that this is a serious flaw for a few reasons. (a) Some locations might want to install more than one ASM instance on a platform. For example, you might want to use one ASM instance for development, and one ASM instance for test. This can't be done with the dbca. (b) If you create an ASM instance by hand (i.e., w/o the dbca) with another DB_NAME, then the Oracle dbca can't find it (since it is looking for an ASM instance named +ASM). (c) If you try to name your instances differently per platform, then you are out of luck. For example, if you want to name your development instance +ASMD, and your production instance +ASMP, then you are out of luck. It seems silly that Oracle would expect you to name ALL of your ASM instances the same.

(2) It seems that the Oracle RDA (Remote Diagnostic Agent) cannot run
against an ASM instance. It complains with "rda.sh cannot find the pmon process" even though the process is up and running. It seems that the RDA is looking for processes that start with the letters "ora"
(e.g. ora_pmon_SID), whereas the ASM instance processes start with the
letters "asm" (e.g., asm_pmon_+SID). So if you run into problems, you are out of luck.

(3) It seems that ASM instances are harder to connect to remotely (via
SQL*Plus Worksheet, TOAD, etc). Database instances normally register themselves automatically with the Oracle listener. If you run "lsnrctl status", you will see each of the database instances with a "status READY". But an ASM instance will show "status BLOCKED". One thing that this means is that you can't connect to the ASM instance from a remote computer. The only way to get around this is to add a static section to the listener.ora file which will end up giving you two ASM instances in your listener: one with "status BLOCKED" and the other with "status UNKNOWN". Here is an example static section:

  (SID_LIST =
    (SID_DESC =

      (GLOBAL_DBNAME = +ASM)
      (SID_NAME = +ASM)
      (ORACLE_HOME = /u01/app/oracle/product/10.1.0/db_1)
    )
  )

There doesn't seem to be any reasoning from Oracle on why the status is "BLOCKED" at this point.

Here is a statement from Oracle tech support on this subject:

"After examining about 40 issues and other documents where this "problem" arose, the best explanation that can be offered (since no official documentation exists currently, and it is not filed as a bug) is that the ASM instances are not intended to be connected to remotely as an auto-registered instance. In every single case, a static registration had to be created to connect remotely. One explanation even mentioned that this was 'normal' and that the ASM database was not intended to operate using the same methodology as a vanilla DB. It does seem odd that there isn't an official document that just spells it out, but the weight of practical experience bears out this conclusion."

(4) The only way to change the password for SYS is thru the orapwd
utility. FYI: orapwd needs to be run for remote authentication if you plan on connecting to the ASM instance from a remote computer.

Hope this helps someone... Received on Tue May 10 2005 - 08:26:27 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US