Introduction

All Oracle Database Appliances running recent versions of the patch (19.1x) are now able to run bare metal databases, virtualized databases or both. A virtualized database is actually a single database in a dedicated VM called a DB System. This is exactly what you can find in OCI, the Oracle public cloud. This feature is very convenient to isolate databases in different networks, and dedicate a limited amount of memory and CPU resources. You may think that these DB Systems have a kind of backup command proposed by odacli, but it does not exist for now.

odacli -h | grep dbsystem | sort | uniq
		create-dbsystem
		delete-dbsystem
		describe-dbsystem
		describe-dbsystem-image
		list-dbsystems
		modify-dbsystem
		start-dbsystem
		stop-dbsystem
	dbsystem-image:
	dbsystem:

Is there a solution to make simple backups of these DB Systems? Let’s try to find out.

DB Systems and storage

DB Systems use 2 kind of storages. A vdisk for the system itself, and ASM storage for data and recovery area. The ASM storage proposed in a DB System is nothing else than the ASM storage of your ODA, and it’s shared accross all VMs. ASM storage is only used for database files, and as you know you will backup your database using classic RMAN scripts or with odacli which rely on RMAN.

There is no tool to backup the vdisk, the vdisk being an hidden file on this filesystem: /u05/app/sharedrepo/hostname. It’s not an issue not having backups of this vdisk because you would normally be able to restore the RMAN backup of your database on another DB System. DB System are not supposed to be tuned manually. The only operation that is normally supported is to modify the DB System with modify-dbsystem, mainly to change its shape (resources allocation).

Most probably, nothing will never corrupt or destroy your DB System, but as you never know, it could be nice to do backups from time to time, just in case.

Identifying the vdisk

Let’s list the DB Systems on my ODA:

odacli list-dbsystems
Name                  Shape       Cores  Memory      GI version          DB version          Status           Created                   Updated
--------------------  ----------  -----  ----------  ------------------  ------------------  ---------------  ------------------------  ------------------------
srvdb01               odb2        2      16.00 GB    19.16.0.0.220719    19.16.0.0.220719    CONFIGURED       2022-11-04 15:03:28 CET   2022-11-04 15:29:51 CET

Finding the associated vdisk of this unique DB System is quite easy:

odacli describe-dbsystem -n srvdb01 | grep "VM image"
            VM image path:  /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf

My DB System is running, so the vdisk is continuously updated:

ls -lrth /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf
-rw-r--r-- 1 qemu qemu 53G Dec 20 14:54 /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf

sleep 60 ; ls -lrth /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf
-rw-r--r-- 1 qemu qemu 53G Dec 20 14:55 /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf

A clean backup will first need stopping the DB System:

odacli stop-dbsystem -n srvdb01
odacli describe-dbsystem -n srvdb01 | grep "Current State"
            Current State:  OFFLINE

Backing up the vdisk

Now let’s copy the vdisk on a backup location. In this example I will use my ACFS recovery area volume but in real life it will probably be a NFS share:

cp /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf /u03/app/oracle/`date +"%Y%m%d_%H%M"`_srvdb01_vdisk.bck

Let’s check if everything is OK with the copy:

md5sum /u03/app/oracle/20221220_1501_srvdb01_vdisk.bck
c00c5d1908eca913b5893c277540439b  /u03/app/oracle/20221220_1501_srvdb01_vdisk.bck

md5sum /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf
c00c5d1908eca913b5893c277540439b  /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf

Now I can start again my DB System:

odacli start-dbsystem -n srvdb01

odacli describe-dbsystem -n srvdb01 | grep "Current State"
            Current State:  ONLINE

Destroying my DB System

Destroying systems and databases is always easy! Let’s connect to the DB System using its private IP:

odacli describe-dbsystem -n srvdb01 | grep "ASM:"
                      ASM:  192.168.17.4    / 255.255.255.128 / ens4 / BRIDGE(privasm) VLAN(priv0.100)

ssh 192.168.17.4
FIPS mode initialized
[email protected]'s password:
Last login: Tue Dec 20 14:32:50 2022 from 192.168.17.2
ps -ef | grep pmon
oracle   19650     1  0 15:31 ?        00:00:00 ora_pmon_VDBITST
root     25612 25327  0 15:33 pts/0    00:00:00 grep --color=auto pmon

I will create a table before destroying the system:

su - oracle
. oraenv <<< VDBITST
sqlplus / as sysdba
SQL> create table before_the_crash as select sysdate "THE_DATE" from dual;

Table created.

SQL> exit;

exit

My database VDBITST is running fine, but it will end soon.

Let’s destroy the / filesystem:

rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe
rm -rf / --no-preserve-root
...
df -h
-bash: df: command not found
shutdown -h now
-bash: shutdown: command not found

exit
Connection to 192.168.17.4 closed by remote host.
Connection to 192.168.17.4 closed.

My DB System is not working correctly anymore. Let’s stop it from the ODA:

odacli stop-dbsystem -n srvdb01
odacli describe-dbsystem -n srvdb01 | grep "Current State"
            Current State:  ONLINE
sleep 30 ; odacli describe-dbsystem -n srvdb01 | grep "Current State"
            Current State:  ONLINE
sleep 30 ; odacli describe-dbsystem -n srvdb01 | grep "Current State"
            Current State:  ONLINE

odacli describe-job -i 7a450741-589a-4c6c-9f80-3888a52db91e

Job details
----------------------------------------------------------------
                     ID:  7a450741-589a-4c6c-9f80-3888a52db91e
            Description:  DB System srvdb01 stop
                 Status:  Running
                Created:  December 20, 2022 3:36:46 PM CET
                Message:

Task Name                                Start Time                          End Time                            Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
Stop DB System                           December 20, 2022 3:36:46 PM CET    December 20, 2022 3:36:46 PM CET    Running

odacli describe-job -i 7a450741-589a-4c6c-9f80-3888a52db91e

Job details
----------------------------------------------------------------
                     ID:  7a450741-589a-4c6c-9f80-3888a52db91e
            Description:  DB System srvdb01 stop
                 Status:  Success
                Created:  December 20, 2022 3:36:46 PM CET
                Message:

Task Name                                Start Time                          End Time                            Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
Stop DB System                           December 20, 2022 3:36:46 PM CET    December 20, 2022 3:46:50 PM CET    Success

It took 10 minutes to shut down because odacli didn’t managed to do a clean stop, obviously.

Restoring the DB System

Restoring the DB System is actually restoring the vdisk. So let’s copy back the clean vdisk image from my backup folder:

mv /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf.old

cp /u03/app/oracle/20221220_1501_srvdb01_vdisk.bck /u05/app/sharedrepo/srvdb01/.ACFS/snaps/vm_x9622f3fdf/x9622f3fdf

Let’s then start again the DB System:

odacli start-dbsystem -n srvdb01
odacli describe-dbsystem -n srvdb01 | grep "Current State"
            Current State:  ONLINE

And finally, let’s connect to it and check if everything is OK:

ssh 192.168.17.4
FIPS mode initialized
[email protected]'s password:
Last login: Tue Dec 20 14:32:50 2022 from 192.168.17.2
df -h
Filesystem                             Size  Used Avail Use% Mounted on
devtmpfs                               7.7G   16K  7.7G   1% /dev
tmpfs                                  7.8G     0  7.8G   0% /dev/shm
tmpfs                                  7.8G  8.7M  7.7G   1% /run
tmpfs                                  7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/mapper/VolGroupVm-LogVolRoot       30G  3.5G   25G  13% /
/dev/mapper/VolGroupVm-LogVolOpt        25G  5.6G   18G  24% /opt
/dev/mapper/VolGroupVm-LogVolU01        99G   26G   68G  28% /u01
/dev/vda1                              942M  113M  765M  13% /boot
192.168.17.2:/opt/oracle/oak/pkgrepos   50G   38G  9.1G  81% /opt/oracle/oak/pkgrepos
tmpfs                                  1.6G     0  1.6G   0% /run/user/0

ps -ef | grep pmon
oracle   17286     1  0 15:58 ?        00:00:00 ora_pmon_VDBITST
root     18790 14644  0 15:58 pts/0    00:00:00 grep --color=auto pmon

It looks fine.

What about my table?

Let’s check if the database is OK and if the table created before the crash but after the vdisk backup is still there:

su - oracle
. oraenv <<< VDBITST
sqlplus / as sysdba
SQL> select status from v$instance;

STATUS
------------
OPEN

SQL> create table back_to_life as select sysdate "THE_DATE" from dual;

Table created.

SQL> alter session set nls_date_format='YYYYMMDD HH24MI';

Session altered.

SQL> select the_date from back_to_life;

THE_DATE
-------------
20221220 1600

SQL> select the_date from before_the_crash;

THE_DATE
-------------
20221220 1536

My DB System is back, and my database is OK. Data created after the vdisk backup was done is still there as expected.

Conclusion

odacli may include a backup feature for the DB Systems in a future release. But for now, doing a cold backup of the vdisks from time to time is a nice solution.

Post Views: 3,690
Thumbnail [60x60]
by
Jérôme Dubar