Home » RDBMS Server » Server Administration » ASM Separation (Oracle 11gR2, RHEL 5)
ASM Separation [message #467819] Tue, 27 July 2010 09:49 Go to next message
chris26
Messages: 5
Registered: July 2010
Junior Member
Hi,

I'm planning to use one Instance of ASM to manage 2 11gR2 RDBMS database in a single server. Each RDBMS will have distinct ORACLE_HOME, OS user and group.

ASM will also have a separate ORACLE_HOME, OS user and group for maintenance purpose.

Based on this configuration, who should own the Raw disks? I am not going to use ASMLib because of the dependancy it creates with the Linux kernel?

I just don't want to waste time with test and trial as the server are managed by sys admin.

Thanks
Re: ASM Separation [message #467822 is a reply to message #467819] Tue, 27 July 2010 09:56 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
>>Each RDBMS will have distinct ORACLE_HOME, OS user and group.
Why? If all are same version, I see no use of having separate homes.
>>ASM will also have a separate ORACLE_HOME, OS user and group for maintenance purpose.
It is mandatory.
ASM will be installed and configured as part of Grid.
And raw disks should be owned by ASM user.
Re: ASM Separation [message #467824 is a reply to message #467822] Tue, 27 July 2010 10:04 Go to previous messageGo to next message
chris26
Messages: 5
Registered: July 2010
Junior Member
Thanks for your prompt reply Razz . That's what I thought but I was not sure if RDBMS Instances were accessing directly the Raw disks (LUNs).

We use separate ORACLE_HOME for ease of maintenance; we can patch one Instance without impacting the other.


Re: ASM Separation [message #467840 is a reply to message #467824] Tue, 27 July 2010 11:04 Go to previous messageGo to next message
babuknb
Messages: 1736
Registered: December 2005
Location: NJ
Senior Member

>>I was not sure if RDBMS Instances were accessing directly the Raw disks (LUNs).
Why RDBMS Instance need to access RAW Disks?? You have separte ORACLE_HOME for ASM Instance. So ASM Home will access RAW Disks

Babu
Re: ASM Separation [message #467849 is a reply to message #467840] Tue, 27 July 2010 12:23 Go to previous messageGo to next message
chris26
Messages: 5
Registered: July 2010
Junior Member
<<Why RDBMS Instance need to access RAW Disks?>>

As I don't have experiance with ASM and by looking at Oracle ASM diagrams I saw direct links between the database instance and RAW disks managed by ASM. But I guess that these links were logicals and all storage is managed by ASM.

My storage disks will consist of several LUNs and 2 IODrive from FusionIO of 160GB (PCIe NAND Flash for Redo and temp). So all of this will have to be owned by the ASM OS user.
Re: ASM Separation [message #467855 is a reply to message #467849] Tue, 27 July 2010 14:21 Go to previous messageGo to next message
mkounalis
Messages: 147
Registered: October 2009
Location: Dallas, TX
Senior Member
ASM manages the disks, but the I/O still goes DIRECTLY from the database instance to the RAW disks. ASM is NOT in the middle of ANY disk I/O to or from the disks to the database instance. You absolutely want to use ASMLIB if you are running Linux. It not only improves I/O to the disks, it eases maintenance and helps with administration. Why on earth would you not want to use the tools made to make your life easier?
Re: ASM Separation [message #467856 is a reply to message #467855] Tue, 27 July 2010 15:13 Go to previous messageGo to next message
chris26
Messages: 5
Registered: July 2010
Junior Member
If such is the case, the permission should be set so that ASM and RDBMS Instances have access to the RAW disks! What would be the best practices, disks owned by ASM OS user of the user hosting the DB Instances?

The issue that our Sys Admin are having with ASMLib is because of the dependency it creates on the kernel. Such as before installing an OS patch they will need to be careful for not impacting ASM disks.

What are the real advantages for ASMLib? Is there a measurable IO gain? For sure as our database is IO bound this could certainly help us, but I will have to come with clear advantages for going forward with ASMLib.
Re: ASM Separation [message #467860 is a reply to message #467856] Tue, 27 July 2010 17:14 Go to previous messageGo to next message
mkounalis
Messages: 147
Registered: October 2009
Location: Dallas, TX
Senior Member
I guess I don't know what you mean by who 'own's' the disks. The raw disks are setup with the permissions necessary to be accessed by ALL your Oracle instances. This is a requirement of ASM. ASMLIB automatomates this process for you. It also makes sure that your I/O is configured properly to the devices. (async I/O, etc.) ASMLIB also helps with management - ASM requires disks to be 'stamped' with an ID. ASMLIB simplifies this process. ASMLIB usually makes a measured positive impact in database I/O performance, but the degree of impact varies based on your hardware and OS combination. While it is true that there is a dependency on ASMLIB and Linux Kernel version, in practice it is NEVER a good idea to upgrade the Linux kernel to the latest and greatest if the system is a host to an Oracle database - especially if you are running RAC. I have never ran into a situation where a feature in a Linux kernel was required for an installation where a corresponding ASMLIB driver wasn't available. ASMLIB also helps do away with device-persistence issues in Linux. Device persistence can hit you right in the gutt when you least expect it Wink. (http://www.oracle.com/technology/tech/linux/asmlib/persistence.html) Device persistence and disk-naming management are the main reasons to use ASMLIB. If you have a good sysadmin, he would be able to configure your disks so that they are capable of using async-io and eligible to being used with the o_direct flag. ASMLIB just simplifies the whole process by preparing your raw disk with everything necessary for your ASM and Oracle instances to use them. Again - the permissions on the RAW disk devices need to be setup in such a way as ALL your Oracle instances can access them.

With all this said - not using ASMLIB is doable - but IMHO, ASMLIB just makes the system easier to manage. And again IMHO - it's not a good idea to install Linux kernel updates just because they exist. Especially in a production system.

The documentation for installing ASMLIB is here --> http://oss.oracle.com/projects/oracleasm/dist/documentation/asm-install.txt
The documentation for configuring ASM is here --> http://download.oracle.com/docs/cd/E11882_01/server.112/e10897/asm.htm#ADMQS12080
This document under 3.6.4.2 describes in detail the persmissions required for ASM disks --> http://download.oracle.com/docs/cd/E11882_01/install.112/e10840/oraclerestart.htm#CHDFDAIG

Good luck!
Re: ASM Separation [message #468521 is a reply to message #467860] Fri, 30 July 2010 09:02 Go to previous message
chris26
Messages: 5
Registered: July 2010
Junior Member
Thanks for all the valuable information Razz .

Based on what you said we are going forward with ASMLIB. As far as the dependency on the Kernel, we will put in place a new procedure for the Sys Admin for installing OS patches (contractually they do this 2-3 times a year). ASM will be used in a non-rac env.

Benefits that we have found:

-relabeling of disk
-ease of disk maintenance
-mark a disk once, see it everywhere
-don't need to manage raw files
-don't need to worry about adding/removing LUNs
-allows oracle to be more efficient

Previous Topic: Redo generation
Next Topic: table have been update/modify in oracle 9
Goto Forum:
  


Current Time: Sun May 19 12:51:43 CDT 2024