How to remove DBFS configuration on EXDATA systems

This post discusses the Removal of DBFS configuration steps specific to EXADATA systems. This needs to be tested in your test Systems before implementing it in the Production setup.

The steps in this section will deconfigure the components configured by the DBFS. The steps here will only deconfigure the parts that were configured by DBFS configure procedure.

1. Stop the dbfs_mount service in clusterware using the oracle account.

(oracle)$ [GI_HOME_PATH]/bin/crsctl stop resource dbfs_mount
CRS-2673: Attempting to stop 'dbfs_mount' on 'test02'
CRS-2673: Attempting to stop 'dbfs_mount' on 'test01'
CRS-2677: Stop of 'dbfs_mount' on 'test01' succeeded
CRS-2677: Stop of 'dbfs_mount' on 'test02' succeeded

2. Confirm that the resource is stopped and then remove the clusterware resource for dbfs_mount as the oracle (or Grid Infrastructure owner) user.

(oracle)$ [GI_HOME]/bin/crsctl stat resource dbfs_mount -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
dbfs_mount
OFFLINE OFFLINE test01
OFFLINE OFFLINE test02
(oracle)$ [GI_HOME]/bin/crsctl delete resource dbfs_mount

3. If a wallet was used, remove the /home/oracle/dbfs directory and subdirectories as the oracle user.

(oracle)$ dcli -g dbs_group -l oracle rm -rf $HOME/dbfs

4. Remove the custom action script that supported the resource and the /etc/fuse.conf file as the root user.

(root)# dcli -g dbs_group -l root rm -f [GI_HOME_PATH]/crs/script/mount-dbfs.sh /etc/fuse.conf

5. Remove the mount point directory as the root user.

(root)# dcli -g dbs_group -l root rmdir /dbfs_direct

On Linux servers only, modify the group memberships for the oracle user account. This assumes that you have not added any other group memberships for the oracle account (other than the defaults configured during deployment). The following is an example showing that the group memberships that remain do not include the fuse group. In this case, the oracle user was a member of oinstall, dbs, oper, and asmdba groups in addition to the fuse group. The group memberships for the oracle user may vary, so some modification to this example command may be required.

(root)# dcli -g dbs_group -l root usermod -G oinstall,dba,oper,asmdba oracle

On Linux servers only, if a wallet was used, follow these steps to remove wallet-specifc configuration changes:

dcli -g ~/dbs_group -l root 'sed -i "/^\/sbin\/mount.dbfs/d" /etc/fstab
dcli -g ~/dbs_group -l root rm -f /sbin/mount.dbfs
dcli -g ~/dbs_group -l root 'cd /usr/local/lib; rm -f libclntsh.so.11.1 libfuse.so.2 libnnz11.so'
dcli -g ~/dbs_group -l root 'sed -i "/^\/usr\/local\/lib$/d" /etc/ld.so.conf.d/usr_local_lib.conf'
dcli -g ~/dbs_group -l root ldconfig
dcli -g ~/dbs_group -l root 'sed -i "/^\/sbin\/mount.dbfs/d" /etc/fstab'

On Solaris servers only, remove the line from /etc/user_attr that was added in this procedure by executing the follow command as root:

(root)# dcli -g ~/dbs_group -l root 'sed "/^oracle::::/d" /etc/user_attr > /tmp/user_attr.new ; cp /tmp/user_attr.new /etc/user_attr ; rm -f /tmp/user_attr.new

The DBFS repository objects remain. You may either:

  • Delete the DBFS repository database using DBCA once the steps above are completed.
  • Remove the DBFS repository by connecting to the database as the repository owner using SQL*Plus and running @?/rdbms/admin/dbfs_drop_filesystem [filesystem-name].

In the example in this post, the filesystem-name is FS1, so the command would be @?/rdbms/admin/dbfs_drop_filesystem FS1

SQL> connect dbfs_user/dbfs_passwd
SQL> @?/rdbms/admin/dbfs_drop_filesystem FS1
SQL> connect / as sysdba
SQL> drop user dbfs_user cascade;