Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Some findings on ASM (Automatic Storage Management)
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