XTTS系列之三:中转空间的选择和优化

xtts,系列,之三,中转,空间,选择,优化 · 浏览次数 : 103

小编点评

**生成内容时需要带简单的排版** **1.源文件格式** * 确保源文件格式正确,例如oracle数据文件格式。 * 可以使用目标端ACFS挂载目录进行文件保存。 **2.目标文件位置** * 确保目标文件位置正确,例如目标端ACFS挂载目录。 * 可以使用NFS挂载方式进行文件保存。 **3.目标文件权限** * 确保目标文件权限正确,例如可读、可写、可执行。 * 可以使用目标端ACFS挂载目录进行文件保存。 **4.目标文件大小** * 确保目标文件大小正确,例如与源文件大小相同。 * 可以使用目标端ACFS挂载目录进行文件保存。 **5.目标文件块大小** * 确保目标文件块大小正确,例如与源文件块大小相同。 * 可以使用目标端ACFS挂载目录进行文件保存。 **6.目标文件复制策略** * 确保目标文件复制策略正确,例如复制所有文件,复制所有文件,或复制特定文件。 * 可以使用目标端ACFS挂载目录进行文件复制。

正文

通常选择XTTS做迁移的数据库都不会太小的,至少都是几T、几十T这样的规模,这种级别的数据量原有空间不够用,所以在迁移过程临时用作存放迁移数据库备份文件的空间也是需要提前考虑规划的问题。

最近就有客户有这样场景,数据库的数据量已经达到了60T+,也是优先选择XTTS的方案做U2L迁移测试。
至于这个中转空间,目前是在存储上划分了对应空间给到源端,目标端XD是使用ACFS挂载的集群文件系统。
测试阶段发现性能不理想,主要是源端备份到挂载的存储速度太慢基本要一周时间,算了下平均都达不到100MB/s,另外由于文件数量大,scp传输也花费了几十个小时,只有目标端应用还算可以。
这说明目标端一体机的性能还是不错的,那这种场景下,如何优化这个时间呢?

简单说,确认该加的并行要加,各种找瓶颈解决瓶颈,比如计算能力、带宽、存储IO能力等。
这些都没啥或者也没改进的情况,
可以先思考下面这个问题:

Q.一体机目标端ACFS挂载的目录能否直接通过NFS挂载到源端,优化其操作时间?

如果答案是可以,那么scp这个时间自然就完全不需要了,直接省去了这一步骤。
而且,因为源端备份本来就慢,所以NFS挂载到目录也完全能满足这个需求。

现在我告诉你,答案经测试就是可以的。

无操作无真相,我这里就在自己测试环境试下Linux的情况:

  • 1.ACFS挂载目录NFS挂载到其他机器
  • 2.测试rman备份到NFS挂载点成功
  • 3.测试xtts脚本备份到NFS挂载点成功
  • 4.总结

1.ACFS挂载目录NFS挂载到其他机器

首先,客户环境要求暂时无法使用图形界面,创建ACFS可参考:

在创建ACFS系统之后,挂载到/xtts目录,启用NFS服务:

[root@db01rac1 ~]# 
service nfs status
service nfs start

vi /etc/exports

/xtts *(rw)

显示NFS相关信息的命令:

showmount -e
exportfs

[root@db01rac1 ~]# showmount -e
Export list for db01rac1:
/xtts *
[root@db01rac1 ~]# 
[root@db01rac1 ~]# 
[root@db01rac1 ~]# exportfs
/xtts           <world>

创建完成之后,使用NFS挂载到源端环境,源端环境需要做如下操作:

创建挂载点目录/xtts

mkdir /xtts

配置/etc/fstab,新增内容:

192.168.1.11:/xtts     /xtts nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,actimeo=0,vers=3,timeo=600

我这里是Linux系统,如果是其他Unix系统,其实是不太一样的,具体可参考:

  • Mount Options for Oracle files for RAC databases and Clusterware when used with NFS on NAS devices (Doc ID 359515.1)

具体参考下面表格,根据你的需求选择即可:

挂载并确认挂载点成功:

mount -a
df -h /xtts

[root@bogon xtts]# mount -a
[root@bogon xtts]# df -h /xtts
Filesystem          Size  Used Avail Use% Mounted on
192.168.1.11:/xtts  5.0G  623M  4.4G  13% /xtts

2.测试rman备份到NFS挂载点成功

测试挂载的文件系统是否能否支持xtts脚本执行正常的备份?

[root@bogon xtts]# 
[root@bogon xtts]# ls -ld /xtts
drwxr-xr-x. 4 54321 54321 32768 Jun 30 00:29 /xtts

备份users表空间测试:

RMAN> backup tablespace users format '/xtts/test%U.bak';

...
ORA-19504: failed to create file "/xtts/testvf2071lq_4079_1_1.bak"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied
...

意料之中的失败,就是授权问题,但这个授权是需要在NFS服务端去授权:

[oracle@db01rac1 xtts]$ chmod 777 /xtts

然后再次在NFS客户端执行备份,成功写入没问题:

RMAN> backup tablespace users format '/xtts/test%U.bak';

Starting backup at 01-JUL-23
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=247 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=369 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=488 device type=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=609 device type=DISK
allocated channel: ORA_DISK_5
channel ORA_DISK_5: SID=731 device type=DISK
allocated channel: ORA_DISK_6
channel ORA_DISK_6: SID=852 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00007 name=/flash/oradata/DEMO/users01.dbf
channel ORA_DISK_1: starting piece 1 at 01-JUL-23
channel ORA_DISK_1: finished piece 1 at 01-JUL-23
piece handle=/xtts/testvg2071t2_4080_1_1.bak tag=TAG20230701T231337 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 01-JUL-23

Starting Control File and SPFILE Autobackup at 01-JUL-23
piece handle=/hdd/orabak/AUTO_c-3869296410-20230701-06.CTL comment=NONE
Finished Control File and SPFILE Autobackup at 01-JUL-23

3.测试xtts脚本备份到NFS挂载点成功

下面进一步测试xtts脚本调用备份是否可以,先改下配置文件:

[oracle@bogon xtt]$ grep -vE '^$|^#' xtt.properties 
tablespaces=TEST
platformid=13
src_scratch_location=/u01/media/src_backups
dest_datafile_location=+DATADG
dest_scratch_location=/xtts
parallel=3
rollparallel=2
getfileparallel=4
srcconnstr=sys/oracle@jingyu
destconnstr=sys/oracle@jingyu
allowstandby=1

修改 src_scratch_location 为 /xtts,这样就省去了scp传输的过程。

[oracle@bogon xtt]$ grep -vE '^$|^#' xtt.properties 
tablespaces=TEST
platformid=13
src_scratch_location=/xtts
dest_datafile_location=+DATADG
dest_scratch_location=/xtts
parallel=3
rollparallel=2
getfileparallel=4
srcconnstr=sys/oracle@jingyu
destconnstr=sys/oracle@jingyu
allowstandby=1

执行xtts脚本:

[oracle@bogon xtt]$ 
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

--如果报错,再次执行,只需要加-L参数或手工清除错误日志
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3 -L

测试执行成功,跑了两次,全量增量都没问题:

[oracle@bogon xtt]$ ls -lrth /xtts/
total 103M
drwx------. 2 root   root      64K Jun  1 14:31 lost+found
-rw-r-----. 1 oracle oinstall 2.3M Jul  1 23:13 testvg2071t2_4080_1_1.bak
-rw-r-----. 1 oracle oinstall 101M Jul  1 23:57 TEST_34.tf 		<-----  第一次全量生成文件
-rw-r-----. 1 oracle oinstall  56K Jul  1 23:58 vj2074hh_4083_1_1		<-----  第一次增量生成文件

此时目标端查看,就直接有这些文件了,权限到时恢复前改下就OK。

[oracle@db01rac1 xtts]$ ls -lrth
total 103M
drwx------ 2 root  root   64K Jun  1 14:31 lost+found
-rw-r----- 1 10001 10001 2.3M Jul  1 23:13 testvg2071t2_4080_1_1.bak
-rw-r----- 1 10001 10001 101M Jul  1 23:57 TEST_34.tf
-rw-r----- 1 10001 10001  56K Jul  1 23:58 vj2074hh_4083_1_1

4.总结

XTTS用的中转空间可以使用目标端的ACFS挂载目录,再通过NFS挂载到源端,至少可以节省scp的传输时间。
另外目标端通常新硬件,通常性能要比之前源环境的更好一些,也能加快些速度。

与XTTS系列之三:中转空间的选择和优化相似的内容:

XTTS系列之三:中转空间的选择和优化

通常选择XTTS做迁移的数据库都不会太小的,至少都是几T、几十T这样的规模,这种级别的数据量原有空间不够用,所以在迁移过程临时用作存放迁移数据库备份文件的空间也是需要提前考虑规划的问题。 最近就有客户有这样场景,数据库的数据量已经达到了60T+,也是优先选择XTTS的方案做U2L迁移测试。 至于这个

XTTS系列之五:警惕大文件表空间

在上篇《[XTTS系列之四:迷迷糊糊的并行度](https://www.cnblogs.com/jyzhao/p/17525723.html)》验证之后,就让测试组在RMAN配置中设置好正确的并行。然后重新将备份任务执行,平均速度直接由之前的150MB/s提升为1200MB/s。优化效果非常明显,速

XTTS系列之二:不可忽略的BCT

重要系统Oracle数据库U2L迁移场景中,如果客户来问我建议,我都会回复说首选就是XTTS,除非XTTS经测试实在是无法满足停机窗口,否则就不要考虑OGG这类方案。 换句话说,选择OGG做迁移的场景,都是没有其他办法时才会选用的方案了。 而在这类XTTS的迁移项目中,我认为bct的技术是至关重要的

XTTS系列之四:迷迷糊糊的并行度

项目测试组又反馈一个问题,XTTS执行全量备份速度慢,影响测试进度。 实际算了下,平均速度才150MB/s.. 这个速度在客户生产环境的确是不够看,首先询问是否开了并行,开了多少? 回复是说有开32个并行,在xtt.properties配置文件中指定的。 另外也注意在RMAN中show all的配置

XTTS测试遇到问题:ORA-20001、ORA-06512

现场测试工程师在半夜电话反馈:在新建的小测试库做XTTS流程验证,遇到错误: ```shell ERROR at line 1: ORA-20001: TABLESPACE(S) IS READONLY OR, OFFLINE JUST CONVERT, COPY ORA-06512: at lin

小知识:grep过滤以#号开头的注释行 和 空行

xtts的配置文件,有很多注释不想直接去掉的情况下,想清楚的看到目前设置了哪些参数,可以用grep过滤查看: `grep -vE '^#|^$' xtt.properties` 效果如下: ```shell [oracle@db11gcas xtt]$ grep -vE '^#|^$' xtt.pr

闪回数据库的应用场景和测试

如果是用户主生产环境,通常不会有用户会开启这个功能。 但如果是在ADG备库端,就会有不少客户选择开启这个功能,这可以有效补充误操作应急处置方法。 今天给某客户做技术支持的时候,在现场遇到一个蛮有意思的问题: XTTS测试场景,库非常大,数据文件很多,远超db_files的默认值。 在表空间元数据导入