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

xtts,系列,警惕,文件,空间 · 浏览次数 : 128

小编点评

#本文内容查询RMAN运行情况SQL set lines 180 pages 200 COL INPUT_TYPE FORMAT a20COL STATUS FORMAT a20COL minutes FORMAT 999.999COL Input_mb FORMAT 99,999.99COL Output_mb FORMAT 99,999.99SELECT SESSION_KEY, INPUT_TYPE, STATUS,TO_CHAR(START_TIME,'yyyy-mm-dd hh24:mi:ss') start_time,TO_CHAR(END_TIME,'yyyy-mm-dd hh24:mi:ss') end_time,INPUT_BYTES/1024/1024 Input_mb,OUTPUT_BYTES/1024/1024 Output_mb,ELAPSED_SECONDS SecondsFROM V$RMAN_BACKUP_JOB_DETAILSORDER BY SESSION_KEY; #最后留给大家一个思考题,如果说你有客户使用XTTS方案迁移,但其数据库中就只有一个大文件表空间,这种情况你会如何做呢? 归纳总结以上内容,生成内容时需要带简单的排版

正文

在上篇《XTTS系列之四:迷迷糊糊的并行度》验证之后,就让测试组在RMAN配置中设置好正确的并行。然后重新将备份任务执行,平均速度直接由之前的150MB/s提升为1200MB/s。优化效果非常明显,速度直接提升了8倍。但是由于用户的数据库存在大文件表空间,当执行到大文件表空间时,速度又降到150MB/s的速度,无法使用并行。

我们知道大文件表空间在11g引入了Multi-Section,可以通过指定section size来用到并行,但现在很尴尬的是:

  • 目前xtts的封装Perl脚本是动态生成的RMAN备份命令,且未指定这个section size
  • 在RMAN配置中,也无法将section size指定为默认通道配置

也就是说,就是无法用到并行。
那用户还要继续要求优化速度,想想这该怎么办呢?

...

讨论阶段有合作伙伴提出让原厂来改脚本,这条路基本很难,不甘心可以去MOS提SR给后台要求,后续有机会我也会和公司反馈,当提这样需求的关键用户多了,在后续xtts版本就有希望会加入这个功能,但对于当下依然是远水解不了近渴。

既然改脚本不靠谱,那我们又该如何继续优化呢?

...

首先了解下目前客户大文件表空间情况:具体有多个大文件表空间,其中最大的那个大小在8T,其余几个加起来小于8T;
此时庆幸还好不是1个,基于这个背景,workaround的方案就有了,使用当前xtts的perl脚本手工并行来做,分成3批,比如xtt1,xtt2,xtt3:

  • 普通小文件表空间一批,对应xtt1
  • 8T大文件表空间自己一批,对应xtt2
  • 其他大文件表空间一批,对应xtt3

最后总时间理论就是备这个8T的时间,这个是最后的瓶颈,目前条件下没法再优化了。

那这种分批执行具体要怎么来做呢?

假设:

  • 普通小文件表空间:TEST,JINGYU
  • 大文件表空间Part1:BG1
  • 大文件表空间Part2:BG2,BG3

之前已有TEST,JINGYU表空间,现在模拟添加大文件表空间BG1,BG2,BG3:

SQL> create bigfile tablespace BG1 datafile '/flash/oradata/DEMO/fb6d1d5d4f0a245be0530b01a8c024da/datafile/bg1.dbf' size 2G;

Tablespace created.

SQL> create bigfile tablespace BG2 datafile '/flash/oradata/DEMO/fb6d1d5d4f0a245be0530b01a8c024da/datafile/bg2.dbf' size 1G;

Tablespace created.

SQL> create bigfile tablespace BG3 datafile '/flash/oradata/DEMO/fb6d1d5d4f0a245be0530b01a8c024da/datafile/bg3.dbf' size 1G;

Tablespace created.

首先脚本直接拷贝新的3份出来:

[oracle@bogon ~]$ pwd
/home/oracle
[oracle@bogon ~]$ ls -ld xtt
drwxr-xr-x. 3 oracle oinstall 4096 Jul  5 23:00 xtt
[oracle@bogon ~]$ cp -rp xtt xtt1
[oracle@bogon ~]$ cp -rp xtt xtt2
[oracle@bogon ~]$ cp -rp xtt xtt3
[oracle@bogon ~]$ ls -ld xtt*
drwxr-xr-x. 3 oracle oinstall 4096 Jul  5 23:00 xtt
drwxr-xr-x. 3 oracle oinstall 4096 Jul  5 23:00 xtt1
drwxr-xr-x. 3 oracle oinstall 4096 Jul  5 23:00 xtt2
drwxr-xr-x. 3 oracle oinstall 4096 Jul  5 23:00 xtt3

修改下配置文件:
1)xtt是全部表空间的备份,不做任何拆分:

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

2)下面xtt1,xtt2,xtt3就是按我上面的策略做的拆分,3个部分加起来相当于上面全部的表空间:

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

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

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

我这里实测src_scratch_location最开始都是设置的/flash/xtts,是可以的。但为了更好区分每个部分,建议选择分开不同目录。
另外在分了任务之后,就需要特别注意TMPDIR的设置了,因为每次不一样,我这里设计都是对应xtts脚本目录中的tmp目录下:

所有表空间使用一个perl脚本一起备份:

# xtt_full:
export TMPDIR=/home/oracle/xtt/tmp
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

SESSION_KEY INPUT_TYPE           STATUS               START_TIME          END_TIME              INPUT_MB  OUTPUT_MB    SECONDS
----------- -------------------- -------------------- ------------------- ------------------- ---------- ---------- ----------
       5097 DATAFILE FULL        COMPLETED            2023-07-05 23:26:31 2023-07-05 23:26:47   2,048.00   2,048.00         16
       5099 DATAFILE FULL        COMPLETED            2023-07-05 23:26:50 2023-07-05 23:26:58   1,024.00   1,024.00          8
       5101 DATAFILE FULL        COMPLETED            2023-07-05 23:27:00 2023-07-05 23:27:16   2,048.00   2,048.00         16
       5103 DATAFILE FULL        COMPLETED            2023-07-05 23:27:19 2023-07-05 23:27:35   2,048.00   2,048.00         16

2023-07-05 23:26:31 到 2023-07-05 23:27:35
共备份7G的文件,耗时1分零4秒。

表空间按我之前说的策略拆分,每个perl脚本对应一部分任务,分别开启备份:

# xtt_part1:
export TMPDIR=/home/oracle/xtt1/tmp
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

# xtt_part2:
export TMPDIR=/home/oracle/xtt2/tmp
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

# xtt_part3:
export TMPDIR=/home/oracle/xtt3/tmp
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

这里直接开三个窗口同时执行,观察RMAN的运行情况:

SESSION_KEY INPUT_TYPE           STATUS               START_TIME          END_TIME              INPUT_MB  OUTPUT_MB    SECONDS
----------- -------------------- -------------------- ------------------- ------------------- ---------- ---------- ----------
       5105 DATAFILE FULL        RUNNING              2023-07-05 23:31:39 2023-07-05 23:31:53   2,048.00   2,048.00         14
       5106 DATAFILE FULL        RUNNING              2023-07-05 23:31:41 2023-07-05 23:31:53   1,024.00   1,024.00         12
       5109 DATAFILE FULL        RUNNING              2023-07-05 23:31:45 2023-07-05 23:31:53   2,048.00   2,048.00          8

运行完之后:

SESSION_KEY INPUT_TYPE           STATUS               START_TIME          END_TIME              INPUT_MB  OUTPUT_MB    SECONDS
----------- -------------------- -------------------- ------------------- ------------------- ---------- ---------- ----------
       5105 DATAFILE FULL        COMPLETED            2023-07-05 23:31:39 2023-07-05 23:32:05   2,048.00   2,048.00         26
       5106 DATAFILE FULL        COMPLETED            2023-07-05 23:31:41 2023-07-05 23:32:07   1,024.00   1,024.00         26
       5109 DATAFILE FULL        COMPLETED            2023-07-05 23:31:45 2023-07-05 23:32:11   2,048.00   2,048.00         26
       5112 DATAFILE FULL        COMPLETED            2023-07-05 23:32:09 2023-07-05 23:32:25   1,024.00   1,024.00         16
       5114 DATAFILE FULL        COMPLETED            2023-07-05 23:32:14 2023-07-05 23:32:31   1,024.00   1,024.00         17

2023-07-05 23:31:39 到 2023-07-05 23:32:31
这种采用拆分xtts任务的方式,手工并行备份7G的文件,耗时52秒。

因为我这里测试环境资源有限,并行多个perl脚本的提升还不够明显,但即使这样也能看到有提升。
注意观察RMAN运行情况时,我特意截取了执行中的一个状态,实际从STATUS中三个同时RUNNING的状态,就可以知道,并行多个perl脚本可以让之前等待串行的大文件能够先并行和其他任务一起跑起来,这必然就会提升效率了。

附:本文中查询RMAN运行情况SQL如下:

set lines 180 pages 200  
COL INPUT_TYPE FORMAT a20
COL STATUS FORMAT a20
COL minutes FORMAT 999.999
COL Input_mb FORMAT 99,999.99
COL Output_mb FORMAT 99,999.99

SELECT SESSION_KEY, INPUT_TYPE, STATUS,
TO_CHAR(START_TIME,'yyyy-mm-dd hh24:mi:ss') start_time,
TO_CHAR(END_TIME,'yyyy-mm-dd hh24:mi:ss') end_time,
INPUT_BYTES/1024/1024 Input_mb,
OUTPUT_BYTES/1024/1024 Output_mb,
ELAPSED_SECONDS Seconds
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;

最后留给大家一个思考题,如果说你有客户使用XTTS方案迁移,但其数据库中就只有一个大文件表空间,这种情况你会如何做呢?

与XTTS系列之五:警惕大文件表空间相似的内容:

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

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

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

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

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

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

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

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

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的默认值。 在表空间元数据导入