Asm and rdbms interation opening datafile

ASM & RDBMS Interactions: Opening a Datafile

Once your RDBMS instance has found the ASM instance it is relying on, what happens when the RDBMS needs to actually open a file that is held on ASM storage?

It seems fairly straightforward. The RDBMS maintains a series of connections to the ASM instance via the Onnn background processes. Requests to open a file go via these background processes to the ASM instance. The ASM instance then sends the extent map to the RDBMS instance.

The RDBMS can then use the extent map to perform I/O direct to the file. It is important to bare in mind that the I/O requests from the RDBMS do not go via the ASM instance, but straight to the devices by using the extent map.

The ASM instance only looks after the metadata that describes diskgroups and extent allocations. It would not be efficient for the RDBMS to have to send it’s I/O via the ASM instance and this does not happen.

ASM & RDBMS Interactions: Creating a file

How do new files get created when running with ASM?

It is the responsibility of the RDBMS instance to begin the procedure for creating the new file:

The RDBMS instance sends a request to the ASM instance to create the file via the Onnn background processes. This request contains information on the size of the file to create, the type, and the diskgroup name where to create the file in.

The ASM instance then uses this information to allocate the appropriate number of extents on the correct disks. After allocating the extents for the file ASM sends the extent map information back to the RDBMS instance and creates an entry in its Continuing Operations Directory (COD) metadata file.

Once the RDBMS has the extent map it can issue the I/O to initialise the file. Remember I/O to datafiles never goes through the ASM instance it is always from the RDBMS instance direct to the file in question. The ASM instance just takes care of the metadata only.

After this I/O has completed, the RDBMS instance messages the ASM instance that the creation of the file has completed successfully. The ASM instance then updates it’s metadata files to reflect the change.

Should the RDBMS decide to abort the file creation, then ASM can use the COD to rollback the creation of the file, which includes freeing the space that was allocated for the new file.


Thanks

Ref : https://jarneil.wordpress.com/2014/10/07/12c-upgrade-and-concurrent-stats-gathering/

ASM and Rdbms interation

ASM & RDBMS Interactions: Finding the ASM Instance

I thought it would be worthwhile having a couple of blog posts on how the RDBMS instance interacts with the ASM instance in various situations.

So I guess we should start at the beginning and ask how the RDBMS actually knows where to contact the ASM instance that it is storing its files in at all?

When an ASM instance is started it registers with the Cluster Synchronisation Services (CSS) daemon running as occsd.bin. This is part of Oracle Clusterware, but the occsd.bin runs in a single instance configuration as well.

Whenever an RDBMS instance needs for the first time to access files that reside on ASM storage and the RDBMS has not needed prior access to the ASM instance, the RDBMS needs to find the connection details for the ASM instance.

These connection details are NOT stored anywhere and you do not need to configure them. The RDBMS instance contacts CSS and gets passed the connect string for the ASM instance. The RDBMS then connects as sysdba to the ASM instance using OS authentication.

It’s actually the RDBMS’s ASMB background process that connects to the ASM instance and remains connected while there are ASM files open. Termination of this ASMB background process is fatal for the instance.