Re: Does ocssd.bin started from 11gASM home support diskgroups mounted by 10g ASM instance

  • From: Karl Arao <karlarao@xxxxxxxxx>
  • To: sanjeevorcle@xxxxxxxxx
  • Date: Tue, 4 Aug 2009 12:15:47 +0800

Hi Sanjeev,

I'd like to clear some info first.

1st)... the ocssd.bin

the CSS is created when:
- you use ASM as storage
- when you install Clusterware (RAC, but Clusterware has its separate
home already)

  For Oracle Real Application Clusters installations, the CSS daemon
is installed with Oracle Clusterware in a separate Oracle home
directory (also called the Clusterware home directory). For
single-node installations, the CSS daemon is installed in and runs
from the same Oracle home as Oracle Database.

You could identify the Oracle home directory being used to run the CSS daemon:

# cat /etc/oracle/ocr.loc

The output from this command is similar to the following:

[oracle@dbrocaix01 bin]$ cat /etc/oracle/ocr.loc
ocrconfig_loc=/oracle/app/oracle/product/10.2.0/asm_1/cdata/localhost/local.ocr
local_only=TRUE

The ocrconfig_loc parameter specifies the location of the Oracle
Cluster Registry (OCR) used by the CSS daemon. The path up to the
cdata directory is the Oracle home directory where the CSS daemon is
running (/oracle/app/oracle/product/10.2.0/asm_1 in this example). To
confirm you could grep the css deamon and see that it's running on
that home

[oracle@dbrocaix01 bin]$ ps -ef | grep -i css
oracle    4950     1  0 04:23 ?        00:00:00
/oracle/app/oracle/product/10.2.0/asm_1/bin/ocssd.bin
oracle    5806  5609  0 04:26 pts/1    00:00:00 grep -i css

Note:
If the value of the local_only parameter is FALSE, Oracle Clusterware
is installed on this system.


2nd)... ASM and Database compatibility

I'll supply you with some references..

Note 337737.1 Oracle Clusterware - ASM - Database Version Compatibility
Note 363254.1 Applying one-off Oracle Clusterware patches in a mixed
version home environment

and Chapter 4, page 116-120 of Oracle ASM (under the hood & practical
deployment guide) 10g & 11g

In the book it says that there are two types of compatibility settings
between ASM and the RDBMS:
  1) instance-level software compatibility settings
        - the COMPATIBLE parameter (mine is 10.2.0), this defines what
software features are available to the instance. Setting the
COMPATIBLE parameter in the ASM instance
        to 10.1 will not enable you to use 11g ASM new features (variable
extents, etc.)

  2) diskgroup-specific settings
        - COMPATIBLE.ASM and COMPATIBLE.RDBMS which are persistently stored
in the ASM diskgroup metadata..these compatibility settings are
specific to a diskgroup and control which
          attributes are available to the ASM diskgroup and which are
available to the database.
        - COMPATIBLE.RDBMS, which defaults to 10.1 in 11g, is the minimum
COMPATIBLE version setting of a database that can mount the
diskgroup.. once you advanced it, it cannot be reversed
        - COMPATIBLE.ASM, which controls the persistent format of the on-disk
ASM metadata structures. The ASM compatibility defaults to 10.1 in 11g
and must always be greater than or equal to the RDBMS compatibility
level.. once you advanced it, it cannot be reversed

    The combination of the compatibility parameter setting of the
database, the software version of the database, and the RDBMS
compatibility setting of a diskgroup determines whether a database
instance is permitted to mount a given diskgroup. The compatibility
setting also determines which ASM features are available for a
diskgroup.

    An ASM instance can support different RDBMS clients with different
compatibility settings, as long as the database COMPATIBLE init.ora
parameter setting of each database instance is greater than or equal
to the RDBMS compatibility of all diskgroups.

    You could also read more here...
http://download.oracle.com/docs/cd/B28359_01/server.111/b31107/asmdiskgrps.htm#CHDDIGBJ




So the following info will give us some background on your environment

cat /etc/oracle/ocr.loc
ps -ef | grep -i css
cat /etc/oratab
select name, group_number, value from v$asm_attribute order by 2;
select db_name, status,software_version,compatible_version from v$asm_client;
select name,compatibility, database_compatibility from v$asm_diskgroup;



I hope I did not confuse you with all of this info.





- Karl Arao
http://karlarao.wordpress.com



On Mon, Aug 3, 2009 at 12:52 PM, sanjeev m<sanjeevorcle@xxxxxxxxx> wrote:
> Listers,
>
> On our non-rac environment we have upgraded 10g ASM home to 11g ASM home.Can
> we mount diskgroup belonging to 10g RDMS  from 10g ASM home even though the
> ocssd.bin process is running out of 11g ASM home. In our testing it looks
> like it is working. I would like to know from support and configuration
> point of view whether this i ok.
> In other words does ocssd.bin started from 11gASM home support diskgroups
> mounted by 10g ASM instance.
>
> Regards,
> Sanjeev.
--
//www.freelists.org/webpage/oracle-l


Other related posts: