ODA 上的数据库系统备份

原创小小亮 2022-12-21

1139

介绍

所有运行最新版本补丁 (19.1x) 的 Oracle 数据库机现在都能够运行裸机数据库、虚拟化数据库或两者。虚拟化数据库实际上是称为数据库系统的专用 VM 中的单个数据库。这正是您可以在 Oracle 公有云 OCI 中找到的内容。此功能非常方便隔离不同网络中的数据库，并提供有限的内存和 CPU 资源。你可能认为这些数据库系统有一种由 odacli 提出的备份命令，但目前还没有。

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:

是否有解决方案可以对这些数据库系统进行简单备份？让我们试着找出答案。

数据库系统和存储

数据库系统使用 2 种存储。一个用于系统本身的虚拟磁盘，以及用于数据和恢复区的 ASM 存储。数据库系统中建议的 ASM 存储就是 ODA 的 ASM 存储，它在所有 VM 之间共享。ASM 存储仅用于数据库文件，正如您所知，您将使用经典的 RMAN 脚本或依赖 RMAN 的 odacli 备份数据库。

没有备份虚拟磁盘的工具，虚拟磁盘是此文件系统上的隐藏文件：/u05/app/sharedrepo/ hostname。没有此虚拟磁盘的备份不是问题，因为您通常能够在另一个数据库系统上恢复数据库的 RMAN 备份。数据库系统不应手动调整。通常支持的唯一操作是使用 modify-dbsystem 修改 DB System，主要是改变其形状（资源分配）。

最有可能的是，没有什么永远不会损坏或破坏您的数据库系统，但您永远不知道，时不时地进行备份可能会很好，以防万一。

识别虚拟磁盘

让我们列出我的 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

找到这个独特的数据库系统的关联虚拟磁盘非常容易：

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

我的数据库系统正在运行，所以 vdisk 不断更新：

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

干净的备份首先需要停止数据库系统：

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

备份虚拟磁盘

现在让我们将虚拟磁盘复制到备份位置。在这个例子中，我将使用我的 ACFS 恢复区卷，但在现实生活中它可能是一个 NFS 共享：

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

让我们检查副本是否一切正常：

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

现在我可以重新启动我的数据库系统了：

odacli start-dbsystem -n srvdb01

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

破坏我的数据库系统

破坏系统和数据库总是很容易！让我们使用其私有 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
root@192.168.17.4'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

我将在销毁系统之前创建一个表：

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

我的数据库 VDBITST 运行良好，但很快就会结束。

让我们销毁 / 文件系统：

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.

我的数据库系统不再正常工作。让我们从 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

关闭需要 10 分钟，因为 odacli 显然没有成功停止。

恢复数据库系统

恢复DB System实际上就是恢复虚拟磁盘。因此，让我们从备份文件夹中复制干净的虚拟磁盘映像：

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

然后让我们重新启动数据库系统：

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

最后，让我们连接到它并检查是否一切正常：

ssh 192.168.17.4
FIPS mode initialized
root@192.168.17.4'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

看起来不错。

我的桌子呢？

让我们检查数据库是否正常，以及在崩溃之前创建但在虚拟磁盘备份之后创建的表是否仍然存在：

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

我的数据库系统回来了，我的数据库也正常了。完成 vdisk 备份后创建的数据仍然如预期的那样存在。

结论

odacli 可能会在未来的版本中包含数据库系统的备份功能。但就目前而言，不时对虚拟磁盘进行冷备份是一个不错的解决方案。

原文标题：DB Systems backup on ODA
原文作者：Jérôme Dubar
原文链接：https://www.dbi-services.com/blog/db-systems-backup-on-oda/

oracle 墨力翻译小小亮的翻译文章

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者