Removing ASM Disks

February 2, 2010

If you try to release the ASM disk, it fails sometimes with following error:

[root]# /etc/init.d/oracleasm deletedisk ASM3

Removing ASM disk “ASM3”:                                  [FAILED]

To get around this problem, it is necessary to overwrite the ASM header information on the disk. This can be achieved with the UNIX command dd. The following command will write 100x1024b blocks to the specified device:

[root]# dd if=/dev/zero of=/dev/mapper/asm3p1 bs=1024 count=100
100+0 records in
100+0 records out
102400 bytes (102 kB) copied, 0.003025 seconds, 33.9 MB/s

If you try to deletedisk, it should work now.

[root]# /etc/init.d/oracleasm deletedisk ASM3
Removing ASM disk “ASM3”:                                  [  OK  ]

If you get “device or resource busy” message in /var/log/oracleasm

[root]# tail -f /var/log/oracleasm
Clearing disk header: oracleasm-write-label: Unable to open device “/dev/oracleasm/disks/ASM3”: Device or resource busy

Check who is using the asm device:

[root]# fuser /dev/mapper/asm3p1
/dev/mapper/asm3p1:  27612

[root]# ps -ef | grep 27612
root      5076 24373  0 17:06 pts/3    00:00:00 grep 27612
oracle   27612     1  0 16:02 ?        00:00:00 oracle+ASM1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

If this is the case you will have to take your ASM instance down to release the device.


Files are an integral part of modern database applications. You can keep files synched with the relational data stored in the database, by storing business data files in the database. You also get transactional consistency, unified security, backup, and search.

Oracle Database File System (DBFS) provides file system interface to files stored in the database tables. DBFS enables existing file based tools to access database files through familiar pathnames, directories, and links. Files in DBFS are either kept in a dedicated file store , or existing application tables.

DBFS provides unified data and file backups, Disaster Recovery, and management of both relational data as well as files. DBFS also add advanced features of compression, deduplication and encryption to files.

The DBFS Content Store allows each database user to create one or more file systems that can be mounted by clients. Each file system has its own dedicated tables that hold the file system content. The DBFS Content API is the PL/SQL interface in the Oracle RDBMS

How it works?

DBFS is a shared file system like NFS and consists of a server (Oracle Database) and a client (dbfs_client in Linux or internal DB client). The dbfs_client provides a command interface to allow files to be easily copied in and out of the database from any host on the network. On Linux platforms the dbfs_client can be used to mount the database file system on a regular mount point. This is done using the “Filesystem in Userspace” (FUSE) module. This allows Linux machines to access DBFS like any other physical file system.

Application makes file calls. Linux FUSE module receives these calls, and forwards them on to the dbfs_client exectutable. DBFS_client makes remote calls to DBFS content store in the database. DBFS_client makes OCI, LOB and SQL calls to database.

High Availability

DBFS Linux client offers HA by leverging RAC technology. The failure of a database instance is detected based on FAN notification. You will have to configure an extra service for failover. dbfs_client transparently redirects file acces to surviving RAC instances on node failures. Any outstanding transaction is replayed to surviving RAC instance.

DBFS Limitations

  • does not support aync IOs.
  • cannot be used when database is NOT running.
  • DBFS does not support exporting NFS exports.
Related Links

GPnP in 11gR2

December 20, 2009

Grid Plug and Play (GPnP)

  • GPnP Makes it easy to add, replace, or remove nodes in a cluster.
  • Allow the cluster to manage it’s own virtual ip addresses > No need to go back to the network administrator.

In the past, adding or removing servers in a cluster required extensive manual preparation. With this release, you can continue to configure server nodes manually, or use Grid Plug and Play to configure them dynamically as nodes are added or removed from the cluster.

Grid Plug and Play reduces the costs of installing, configuring, and managing server nodes by starting a grid naming service within the cluster to allow each node to perform the following tasks dynamically:

  • Negotiating appropriate network identities for itself
  • Acquiring additional information it needs to operate from a configuration profile
  • Configuring or reconfiguring itself using profile data, making hostnames and addresses resolvable on the network.

Because servers perform these tasks dynamically, the number of steps required to add or nodes is minimized.

Grid Naming Service (GNS)

  • Lets the cluster manage it’s own network
  • Support DHCP for IPs and VIPs
  • No need to go back to the Network Admin

The Grid Naming Service (GNS) is a part of the Grid Plug and Play feature of Oracle RAC 11g Release 2. It provides name resolution for the cluster. If you have a larger cluster or a requirement to have a dynamic cluster (you expect to add or remove nodes in the cluster), then you should implement GNS. If you are implementing a small cluster, you do not need to add GNS.

The GNS virtual IP address is a static IP address configured in the DNS. The DNS delegates queries to the GNS virtual IP address, and the GNS daemon responds to incoming name resolution requests at that address.

Within the subdomain, the GNS uses multicast Domain Name Service (mDNS), included with Oracle Clusterware, to enable the cluster to map hostnames and IP addresses dynamically as nodes are added and removed from the cluster, without requiring additional host configuration in the DNS.

To enable GNS, you must have your network administrator provide a set of IP addresses for a subdomain assigned to the cluster (for example,, and delegate DNS requests for that subdomain to the GNS virtual IP address for the cluster, which GNS will serve. The set of IP addresses is provided to the cluster through DHCP, which must be available on the public network for the cluster.


Single Client Access Name (SCAN) is a single name that allows client connections to connect to any database in an Oracle cluster independently of which node in the cluster the database (or service) is currently running. The SCAN should be used in all client connection strings and does not change when you add/remove nodes from the cluster.

Oracle Database 11g release 2 clients connect to the database using SCANs. The SCAN and its associated IP addresses provide a stable name for clients to use for connections, independent of the nodes that make up the cluster. SCAN addresses, virtual IP addresses, and public IP addresses must all be on the same subnet.

The SCAN is a virtual IP name, similar to the names used for virtual IP addresses, such as node1-vip. However, unlike a virtual IP, the SCAN is associated with the entire cluster, rather than an individual node, and associated with multiple IP addresses, not just one address.

The SCAN works by being able to resolve to multiple IP addresses reflecting multiple listeners in the cluster handling public client connections. When a client submits a request, the SCAN listener listening on a SCAN IP address and the SCAN port is contracted on a client’s behalf. Because all services on the cluster are registered with the SCAN listener, the SCAN listener replies with the address of the local listener on the least-loaded node where the service is currently being offered. Finally, the client establishes connection to the service through the listener on the node where service is offered. All of these actions take place transparently to the client without any explicit configuration required in the client.

During installation, listeners are created on nodes for the SCAN IP addresses. Oracle Net Services routes application requests to the least loaded instance providing the service. Because the SCAN addresses resolve to the cluster, rather than to a node address in the cluster, nodes can be added to or removed from the cluster without affecting the SCAN address configuration.

The SCAN should be configured so that it is resolvable either by using Grid Naming Service (GNS) within the cluster, or by using Domain Name Service (DNS) resolution. For high availability and scalability, Oracle recommends that you configure the SCAN name so that it resolves to three IP addresses. At a minimum, the SCAN must resolve to at least one address.

If you specify a GNS domain, then the SCAN name defaults to clustername-scan.GNS_domain. Otherwise, it defaults to clustername-scan.current_domain. For example, if you start Oracle grid infrastructure installation from the server node1, the cluster name is mycluster, and the GNS domain is, then the SCAN Name is

Clients configured to use IP addresses for Oracle Database releases prior to Oracle Database 11g release 2 can continue to use their existing connection addresses; using SCANs is not required. When you upgrade to Oracle Clusterware 11g release 2 (11.2), the SCAN becomes available, and you should use the SCAN for connections to Oracle Database 11g release 2 or later databases. When an earlier version of Oracle Database is upgraded, it registers with the SCAN listeners, and clients can start using the SCAN to connect to that database. The database registers with the SCAN listener through the remote listener parameter in the init.ora file.

The Oracle Clusterware and Oracle RAC will work with both static and DHCP hostnames. When you use GNS, Oracle will use DHCP for the VIPs which includes node vips and SCAN vips.