vSAN File Service – in the service of critical Oracle workloads
Typical Day 2 operations for Oracle DBAs includes and is not limited to
- Refresh of databases between different environments (e.g., refresh non-production databases from production databases with data masking)
- Cloning of databases between different environments (e.g., clone production databases to non-prod databases with data masking)
- Backup and restore of databases between different environments
- Sharing scripts between non-production or production environments
- Backup databases to filesystem for 3rd party backup software to consume either through direct streaming or via Snapshots
NFS services has helped immensely in this regard where data and scripts can be shared in a controlled manner by the DBAs among different environments, using NFS appliances or server/VM’s serving NFS protocols.
VMware vSAN file services
- can be used to create file shares in the vSAN datastore that client workstations or VMs can access. The data stored in a file share can be accessed from any device that has access rights.
- has a built-in feature that allows you to create a point- in-time image of the vSAN file share. When the vSAN File Service is enabled, you can create up to 32 snapshots per share. A vSAN file share snapshot is a file system snapshot that provides a point-in-time image of a vSAN file share.
This blog addresses the advantages of using VMware vSAN File Service for above mentioned Oracle database day 2 operations for simplifying operational process and achieving efficiency.
VMware vSAN File Service
VMware vSAN File Service is a layer that sits on top of vSAN to provide file shares. It currently supports SMB, NFSv3, and NFSv4.1 file shares. vSAN File Service comprises of vSAN Distributed File System (vDFS) which provides the underlying scalable filesystem by aggregating vSAN objects, a Storage Services Platform which provides resilient file server end points and a control plane for deployment, management, and monitoring. File shares are integrated into the existing vSAN Storage Policy Based Management, and on a per-share basis. vSAN file service brings in capability to host the file shares directly on the vSAN cluster.
More information on vSAN File Service can be found at vSAN File Service.
Test Use case
This blog addresses the advantages of using VMware vSAN File Service for above mentioned Oracle database day 2 operations for simplifying operational process and achieving efficiency.
This test case showcases
- the setup of vSAN NFS file share on an Oracle Production database VM, which is then used as a repository for RMAN backups. The same vSAN file share is mounted on an Oracle QA database VM which is used for database refresh
- the steps which can be taken to create a vSAN NFS file share snapshot which can be consumed by a 3rd party media manager for backup purposes.
Test Bed
The Test bed is a 3 Node vSAN Cluster as shown below, with 3 ESXi servers, ‘sc2esx39.vslab. local’ , ‘sc2esx40.vslab.local’ and ‘sc2esx42.vslab.local’.
All ESXi servers were VMware ESXi, 7.0.3, 19482537, each server with 2 sockets, 48 cores per socket with 768GB RAM.
The vCenter version was 7.0.3 build 19717403
vSAN File Services is enabled on the vSAN Cluster as shown below.
The 3 vSAN File Services VM’s are shown as below
A vSAN NFS file share ‘oracle-vsan-fs’ is created as shown below.
Steps to create vSAN File service can be found here. Steps to create vSAN File share can be found here. The actual installations & configuration steps of vSAN File Services and vSAN File Share is out of scope of this blog.
Production Oracle VM ‘Oracle21C-OL8-Customer’ and QA Oracle VM ‘Oracle21C-OL8-Customer-QA’ details are shown below. Both VM’s ‘Oracle21C-OL8-Customer’ and ‘Oracle21C-OL8-Customer-QA’ had 24 vCPU’s and 256G Memory.
The vmdk’s for the Production VM ‘Oracle21C-OL8-Customer’ are shown as below –
- Hard Disk 1 (SCSI 0:0) – 80G for OS (/)
- Hard Disk 2 (SCSI 0:1) – 80G for Oracle Grid Infrastructure and RDBMS binaries
- Hard Disk 3 (SCSI 1:0) – 100G for Grid ASM (GRID_DG ASM Disk Group)
- Hard Disk 4 (SCSI 1:1) – 200G for Oracle Database (DATA_DG ASM Diskgroup)
- Hard Disk 5 (SCSI 2:0) – 1TB SLOB Tablespace (SLOB_DG ASM Diskgroup)
- Hard Disk 6 (SCSI 3:0) – 100G for Redo logs (REDO_DG ASM Diskgroup)
- Hard Disk 7 (SCSI 1:2) – 512G for FRA (FRA_DG ASM Diskgroup)
The vmdk’s for the QA VM ‘Oracle21C-OL8-Customer-QA’ are shown as below –
- Hard Disk 1 (SCSI 0:0) – 80G for OS (/)
- Hard Disk 2 (SCSI 0:1) – 80G for Oracle Grid Infrastructure and RDBMS binaries
- Hard Disk 3 (SCSI 1:0) – 100G for Grid ASM (GRID_DG ASM Disk Group)
- Hard Disk 4 (SCSI 1:1) – 200G for Oracle Database (DATA_DG ASM Diskgroup)
- Hard Disk 5 (SCSI 3:0) – 100G for Redo logs (REDO_DG ASM Diskgroup)
- Hard Disk 6 (SCSI 1:2) – 512G for FRA (FRA_DG ASM Diskgroup)
For both Production & QA VM’s, a single instance database ‘ORA21C’ with multi-tenant option was provisioned with Oracle Grid Infrastructure (ASM) and Database version 21.5 (Database Release Update 21.5.0.0.220118) on O/S OEL 8.5 UEK.
Oracle ASM was the storage platform with Oracle ASMLIB for device persistence. Oracle SGA & PGA set to 128GB and 20G, respectively. All Oracle on VMware best practices were followed.
Test Steps
Test Case 1 – Setup of vSAN NFS file share on an Oracle Production database VM, which is then used as a repository for RMAN backups. The same vSAN file share is mounted on an Oracle QA database VM which is used for database refresh
As part of the first test case, on Production VM ‘Oracle21C-OL8-Customer’ , mount the vSAN File share ‘oracle_vsan_fs’ as a NFS mount ‘oracle_vsan_fs’
[root@oracle21c-ol8 ~]# cd /
[root@oracle21c-ol8 /]# mkdir oracle_vsan_fs
[root@oracle21c-ol8 ~]# mount -t nfs vsanfileshare1.vslab.local:/vsanfs/oracle-vsan-fs oracle_vsan_fs
Check to see if filesystem has been mounted
[root@oracle21c-ol8 /]# df
Filesystem 1K-blocks Used Available Use% Mounted on
…..
…..
vsanfileshare1.vslab.local:/oracle-vsan-fs 2742141952 0 2742039552 0% /oracle_vsan_fs
[root@oracle21c-ol8 /]#
Login as the ‘Oracle’ user and run Oracle RMAN utility to dump database backup to the NFS share (vSAN file share as NFS mount).
oracle@oracle21c-ol8:ORA21C:/home/oracle> ./rman_backup
Recovery Manager: Release 21.0.0.0.0 – Production on Thu Jun 16 08:11:06 2022
Version 21.5.0.0.0
Copyright (c) 1982, 2021, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORA21C (DBID=3378867384)
RMAN>using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name ORA21C are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default
CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u01/app/oracle/dbs/snapcf_ORA21C.f’; # default
RMAN>
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2151 device type=DISK
specification does not match any backup in the repository
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2151 device type=DISK
specification does not match any archived log in the repository
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
using channel ORA_DISK_1
no obsolete backups found
released channel: ORA_DISK_1
allocated channel: c1
channel c1: SID=2151 device type=DISK
Starting backup at 16-JUN-22
channel c1: starting compressed full datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00005 name=+DATA_DG/ORA21C/undotbs01_01.dbf
input datafile file number=00003 name=+DATA_DG/ORA21C/sysaux_01.dbf
input datafile file number=00001 name=+DATA_DG/ORA21C/system_01.dbf
input datafile file number=00006 name=+DATA_DG/ORA21C/users_01.dbf
channel c1: starting piece 1 at 16-JUN-22
channel c1: finished piece 1 at 16-JUN-22
piece handle=/oracle_vsan_fs/db_ORA21C_42_1_1107504670 tag=TAG20220616T081110 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:35
channel c1: starting compressed full datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00015 name=+DATA_DG/pdb1/sysaux_01.dbf
input datafile file number=00016 name=+DATA_DG/pdb1/users_01.dbf
input datafile file number=00017 name=+DATA_DG/pdb1/usertbs_01.dbf
input datafile file number=00014 name=+DATA_DG/pdb1/system_01.dbf
input datafile file number=00018 name=+DATA_DG/pdb1/pdb_user_01.dbf
channel c1: starting piece 1 at 16-JUN-22
channel c1: finished piece 1 at 16-JUN-22
piece handle=/oracle_vsan_fs/db_ORA21C_43_1_1107504706 tag=TAG20220616T081110 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:15
channel c1: starting compressed full datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00007 name=+DATA_DG/pdbseed/users_01.dbf
input datafile file number=00008 name=+DATA_DG/pdbseed/usertbs_01.dbf
input datafile file number=00002 name=+DATA_DG/pdbseed/system_01.dbf
input datafile file number=00004 name=+DATA_DG/pdbseed/sysaux_01.dbf
channel c1: starting piece 1 at 16-JUN-22
channel c1: finished piece 1 at 16-JUN-22
piece handle=/oracle_vsan_fs/db_ORA21C_44_1_1107504721 tag=TAG20220616T081110 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:07
Finished backup at 16-JUN-22
Starting backup at 16-JUN-22
current log archived
channel c1: starting archived log backup set
channel c1: specifying archived log(s) in backup set
input archived log thread=1 sequence=1931 RECID=9291 STAMP=1107504729
channel c1: starting piece 1 at 16-JUN-22
channel c1: finished piece 1 at 16-JUN-22
piece handle=/oracle_vsan_fs/al_ORA21C_45_1_1107504729 tag=TAG20220616T081209 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:01
Finished backup at 16-JUN-22
Starting Control File Autobackup at 16-JUN-22
piece handle=+FRA_DG/ORA21C/AUTOBACKUP/2022_06_16/n_1107504730.408.1107504731 comment=NONE
Finished Control File Autobackup at 16-JUN-22
released channel: c1
RMAN>
Recovery Manager complete.
oracle@oracle21c-ol8:ORA21C:/home/oracle>
Check the NFS file share ‘/oracle_vsan_fs’ contents.
oracle@oracle21c-ol8:ORA21C:/home/oracle> ls -l /oracle_vsan_fs
total 406976
-rw-r—– 1 oracle asmadmin 882176 Jun 16 08:12 al_ORA21C_45_1_1107504729
-rw-r—– 1 oracle asmadmin 274063360 Jun 16 08:11 db_ORA21C_42_1_1107504670
-rw-r—– 1 oracle asmadmin 110452736 Jun 16 08:11 db_ORA21C_43_1_1107504706
-rw-r—– 1 oracle asmadmin 31342592 Jun 16 08:12 db_ORA21C_44_1_1107504721
oracle@oracle21c-ol8:ORA21C:/home/oracle>
On QA VM ‘Oracle21C-OL8-Customer-QA’ :
Mount the same vSAN File share ‘oracle_vsan_fs’ as a NFS mount ‘oracle_vsan_fs’, follow the same steps as show above for mounting the vSAN file share as a NFS mount.
[root@oracle21c-ol8-qa /]# df
Filesystem 1K-blocks Used Available Use% Mounted on
….
….
vsanfileshare1.vslab.local:/oracle-vsan-fs 2742141952 0 2742039552 0% /oracle_vsan_fs
[root@oracle21c-ol8-qa /]#
Check the NFS file share ‘/oracle_vsan_fs’ contents.
oracle@oracle21c-ol8-qa:ORA21C:/oracle_vsan_fs> ls -l /oracle_vsan_fs
total 406976
-rw-r—– 1 oracle asmadmin 882176 Jun 16 08:12 al_ORA21C_45_1_1107504729
-rw-r—– 1 oracle asmadmin 274063360 Jun 16 08:11 db_ORA21C_42_1_1107504670
-rw-r—– 1 oracle asmadmin 110452736 Jun 16 08:11 db_ORA21C_43_1_1107504706
-rw-r—– 1 oracle asmadmin 31342592 Jun 16 08:12 db_ORA21C_44_1_1107504721
oracle@oracle21c-ol8-qa:ORA21C:/oracle_vsan_fs>
We can see the Production VM ‘Oracle21C-OL8-Customer’ RMAN backup file on the NFS file share ‘/oracle_vsan_fs’.
We can now proceed to use this RMAN backup to refresh QA database from Production or Create another database on the QA VM.
Test Case 2 – Steps which can be taken to create a vSAN NFS file share snapshot which can be consumed by a 3rd party media manager for backup purposes
As part of the second test case, take a vSAN file share snapshot ‘Oracle-RMAN-Snapshot’ as shown below.
vSAN file share snapshot ‘Oracle-RMAN-Snapshot’ operation is successfully completed.
More information on ‘Backing up vSAN File Shares; can be found at Backing up vSAN File Shares.
Summary
In summary, typical Day 2 operations for Oracle DBAs includes and is not limited to
- Refresh of databases between different environments (e.g., refresh non-production databases from production databases with data masking)
- Cloning of databases between different environments (e.g., clone production databases to non-prod databases with data masking)
- Backup and restore of databases between different environments
- Sharing scripts between non-production or production environments
- Backup databases to filesystem for 3rd party backup software to consume either through direct streaming or via Snapshots
VMware vSAN file services
- can be used to create file shares in the vSAN datastore that client workstations or VMs can access. The data stored in a file share can be accessed from any device that has access rights.
- has a built-in feature that allows you to create a point- in-time image of the vSAN file share. When the vSAN File Service is enabled, you can create up to 32 snapshots per share. A vSAN file share snapshot is a file system snapshot that provides a point-in-time image of a vSAN file share.
Conclusion
This blog addresses the advantages of using VMware vSAN File Service for above mentioned Oracle database day 2 operations for simplifying operational process and achieving efficiency.
This test case showcases
- the setup of vSAN NFS file share on an Oracle Production database VM, which is then used as a repository for RMAN backups. The same vSAN file share is mounted on an Oracle QA database VM which is used for database refresh
- the steps which can be taken to create a vSAN NFS file share snapshot which can be consumed by a 3rd party media manager for backup purposes.
All Oracle on VMware vSphere collaterals can be found in the url below
Oracle on VMware Collateral – One Stop Shop
https://blogs.vmware.com/apps/2017/01/oracle-vmware-collateral-one-stop-shop.html
