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

From: Karl Arao <karlarao_at_gmail.com>
Date: Tue, 4 Aug 2009 12:15:47 +0800
Message-ID: <12ee65600908032115q5fd05d70se945a228740216f2_at_mail.gmail.com>



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_at_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_at_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.

On Mon, Aug 3, 2009 at 12:52 PM, sanjeev m<sanjeevorcle_at_gmail.com> 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.

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Aug 03 2009 - 23:15:47 CDT

Original text of this message