oracle rman备份慢,Oracle备份恢复:Rman Backup缓慢问题一例

最新推荐文章于 2021-04-12 00:14:37 发布
最新推荐文章于 2021-04-12 00:14:37 发布
阅读量1.1k 收藏 1
点赞数
文章标签： oracle rman备份慢

01fac6460a22031b8af8da5848698a70.png

近日客户报多套10g的数据库在使用NBU磁带备份时出现RMAN FULL BACKUP十分缓慢的问题，这些数据库中最大一个的达到2.61T，该数据库在一个月前地全库0级备份耗时在3-4个小时，而在最近猛涨到17个小时。客户之前已经向Symantec提交了服务请求，但暂时没有得到结论。希望我们从Oracle角度分析该备份速度变慢问题。

我们首先分析了备份信息的动态视图V$rman_backup_job_details:

OUTPUT_DEVICE

INPUT_TYPE

ELAPSED_SECONDS

INPUT_BYTES_DISPLAY

INPUT_BYTES_PER_SEC

OUTPUT_BYTES_PER_SEC

17

SBT_TAPE

DB INCR

62078

2.61T

44.08M

18.10M

以上可以确认在对2.61T大小的数据库执行全库磁带备份时耗费了62078s，这里还显示了backup时每秒的读取IO为44M，每秒的写出IO为18M；这里不能因为简单的output io per second

V$BACKUP_SYNC_IO

Displays rows when the I/O is synchronous to the process (or thread on some platforms) performing the backup.

V$BACKUP_ASYNC_IO

Displays rows when the I/O is asynchronous to the process (or thread on some platforms) performing the backup.

以上2个视图的区别在于一个汇聚了使用同步IO执行RMAN备份恢复操作的性能信息，而另一个是异步IO的。

因为客户使用默认配置disk_async_io为true，故而我们首先关注input IO的性能信息，这些信息存放在V$backup_async_io视图中；而对于磁带设备未启用slaves IO模拟的异步IO(tape_asynch_io=true但是backup_tape_io_slaves为默认的false)，所以与磁带设备相关的output IO的性能信息存放在v$backup_sync_io视图中。

DEVICE

OPEN_TIME

ELAPSED

BYTES/S

IO_COUNT

READY

long_waits

LONG_WAIT_TIME_TOTAL

LONG_WAIT_TIME_MAX

DISK

4/4

388900

372827681

2765564

2074114

90028

231181

53

DISK

4/5

753900

192323498

2765564

2074114

90028

178548

41

DISK

4/6

369000

392934106

2765564

2074114

90028

243507

41

DISK

4/7

405100

357918255

2765564

2074114

90028

268117

73

DISK

4/8

347900

416765407

2765564

2074114

90028

183543

77

DISK

4/9

395800

366328159

2765564

2074114

90028

255399

48

DISK

4/10

428400

338451646

2765564

2074114

90028

268544

45

DISK

4/11

413200

350901949

2765564

2074114

90028

269857

42

DISK

4/12

735400

197161661

2765564

2074114

90028

169016

34

DISK

4/13

410000

353640696

2765564

2074114

90028

283607

60

DISK

4/14

408300

355113116

2765564

2074114

90028

279012

38

DISK

4/15

442700

327519054

2765564

2074114

90028

308744

605

DISK

4/16

393000

368938130

2765564

2074114

90028

251509

205

DISK

4/17

423100

342691291

2765564

2074114

90028

273868

42

DISK

4/18

375600

386029513

2765564

2074114

90028

230859

328

DISK

4/19

721200

201043657

2765564

2074114

90028

191753

162

DISK

4/20

401000

361577769

2765564

2074114

90028

272852

147

DISK

4/21

346600

418328578

2765564

2074114

90028

209569

109

DISK

4/22

400500

362029177

2765564

2074114

90028

265060

112

DISK

4/23

402400

360319794

2765564

2074114

90028

259008

594

DISK

4/24

449600

322492627

2765564

2074114

90028

274202

64

DISK

4/25

413900

350308493

2765564

2074114

90028

269380

230

DISK

4/26

748600

193685126

2765564

2074114

90028

177477

105

DISK

4/27

389900

371871468

2765564

2074114

90028

261200

38

DISK

4/28

383800

377781879

2765564

2074114

90028

241870

158

DISK

4/29

403700

359159488

2765564

2074114

90028

266135

212

DISK

4/30

390600

371205031

2765564

2074114

90028

248161

340

DISK

5/1

463600

312753851

2765564

2074114

90028

271247

39

DISK

5/2

419900

345302894

2765564

2074114

90028

255042

117

DISK

5/3

705700

205459381

2765564

2074114

90028

173043

189

DISK

5/4

418400

346540835

2765564

2074114

90028

291614

47

DISK

5/5

357400

405687424

2765564

2074114

90028

222676

188

DISK

5/6

421400

344073767

2765564

2074114

90028

285860

95

DISK

5/7

405100

357918255

2765564

2074114

90028

263761

38

DISK

5/8

381500

380059463

2765564

2074114

90028

203510

210

DISK

5/9

918400

157875311

2765564

2074114

90028

221293

37

DISK

5/10

3378600

42915020

2765564

2074114

90028

142211

36

DISK

5/11

559900

258961753

2765564

2074114

90028

252911

174

DISK

5/12

622500

232919976

2765564

2074114

90028

241495

40

DISK

5/13

626700

231359000

2765564

2074114

90028

237973

41

DISK

5/14

802000

180788884

2765564

2074114

90028

231283

42

DISK

5/15

601200

241172131

2765564

2074114

90028

209418

40

DISK

5/16

1387800

104476643

2765564

2074114

90028

211878

36

这里我们关心的几个时间指标包括:ELAPSED(Input IO的总耗时)、LONG_WAIT_TIME_TOTAL(长IO的总等待时间)、LONG_WAIT_TIME_MAX(最长一次的IO等待时间)的单位均为百分之一秒，该视图的具体定义参考这里。

从以上chart中(由于列宽的原因只截取了部分数据)我们可以看到从4/4到5/16之间备份的Input IO总耗时(elapsed)虽然间歇性的暴涨到过33786s，但其他IO指标:IO总数、READY IO总数、LONG IO WAIT的次数、LONG IO WAIT的总耗时、最长LONG IO WAIT均没有出现大的变化；基本可以判定在备份期间对数据文件的读取不存在瓶颈，为了进一步诊断需要分析备份输出的IO性能状况:

DEVICE

date

ELAPSED

BYTES

BYTES/S

IO_COUNT

IO_TIME_TOTAL

IO_TIME_MAX

DISCRETE_BYTES_PER_SECOND

SBT_TAPE

4/5

754900

584663433216

77449123

2230314

440365

2600

132767916

SBT_TAPE

4/5

703900

553432907776

78623797

2111179

381135

5800

145206530

SBT_TAPE

4/12

736400

588200542208

79875142

2243807

433298

3400

135749655

SBT_TAPE

4/12

692300

556839731200

80433299

2124175

369237

2600

150808216

SBT_TAPE

4/19

722200

591873179648

81954193

2257817

395904

3400

149499166

SBT_TAPE

4/19

829000

561043210240

67677106

2140210

510746

2801

109847793

SBT_TAPE

4/26

749600

596010598400

79510485

2273600

435940

2600

136718493

SBT_TAPE

4/26

700300

565171191808

80704154

2155957

377019

2800

149905228

SBT_TAPE

5/3

706800

600177377280

84914739

2289495

396965

5800

151191510

SBT_TAPE

5/3

712500

569155518464

79881476

2171156

392324

5800

145072827

SBT_TAPE

5/10

3379700

604452159488

17884787

2305802

3093781

2802

19537652

SBT_TAPE

5/10

2798400

573396746240

20490164

2187335

2524296

2801

22715115

SBT_TAPE

5/17

428095307776

1633054

2216291

5800

19315844

可以从以上chart中可以发现到5/3为止的output io总耗时还处于合理范围内(为7068+7125)s，约为4小时。而到了5/10时输出IO的总耗时达到了(33797+29784)s，约为17.6小时。研究其他IO统计信息可以发现5/10的IO_TIME_TOTAL总数为(30937+25242)s，IO_TIME_TOTAL代表了某个IO等待的总耗时，单位为百分之一秒。从另一个IO性能指标DISCRETE_BYTES_PER_SECOND来看，在5/10备份文件的平均传输率急剧下降。

综合上述现象，诱发客户环境中的RMAN全库备份缓慢的主要原因是备份文件输出IO性能在一段时间内急剧下降，瓶颈应当存在于RMAN与NBU备份服务器之间，与数据库读取性能没有关系。给客户的建议是复查数据库服务器到NBU备份服务器间的网络带宽是否正常，NBU服务器的性能是否正常，磁带库的写出性能是否正常。

这个case后续经过对NBU的复查发现原因是虚拟磁带库VTL的存储电池过期，导致读写数据时直接从磁盘上进行，而不经过缓存，故影响了数据库全备份的速度。由于VTL存储电池过期信息需要从串口直接访问其存储才能确认问题，所以在问题发生之初无法从VTL的管理界面中获取该信息。

这个case告诉我们不仅是raid卡的冲放电、存储的ups电池过期会引发严重的IO性能问题，VTL的存储电池过期也可能给数据库备份造成麻烦，要让系统7*24时刻正常运行，有太多指标需要我们去关注，良好的规范很重要，同时很多时候我们不得不和硬件打交道。

Lance船长
关注
oracle rman备份慢,rman备份遇到的设置rman导致数据库变慢的原因
weixin_36410277的博客
04-06 981
凌晨3点至4点的awr报告由此可以发现当时的数据库情况是极其卡顿的。查看当时的alert日志由此发现alert日志无报错。查看当时的rman部署脚本无错误。据此可以推测是操作系统的内存参数设置可能不合理以及cup不足的情况导致。查看操作系统的相关参数：#lsps -aPage Space Physical Volume Volume Group Size %Used Activ...
oracle rman部分恢复,Oracle中使用RMAN备份及一些恢复方法
weixin_35983968的博客
04-05 884
使用RMAN备份并恢复Backup 备份命令生成 Backup sets (备份集合)，以 oracle 专有的格式保存，由一个完全的所有的备份片集合构成，构成一个完全备份或增量备份。1.1.1 BACKUP 备份命令选项设置标记(TAG)RMAN> backup database tag='test backup';限制备份集大小RMAN> backup database max...
oracle rman备份慢,RMAN 备份很慢.有没有什么办法解决.
weixin_30391353的博客
04-06 515
There are two backup servers for two oracle8i database servers. The oracle version is oracle8i Enterprise Edition Release 8.1.7.4.0RMAN is using target database controlfile instead of recovery catalog...
诊断Oracle RMAN备份慢的原因
记录创业路上的一些想法
07-27 3016
Oracle RMAN慢分析
rman 速度很慢 系统100m 备份20M 生成的跟踪文件？？
"杰"出虚拟平台-数据运维~~
10-15 3054
恢复管理器: Release 11.2.0.1.0 - Production on 星期二 10月 15 11:22:15 2013 Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved. Windows NT Version V6.1   CPU              
oracle rman备份慢,oracle备份问题rman备份缓慢
weixin_33957089的博客
04-06 209
单独给rman划分的分区，查看该分区的读写与使用率很低。[root@testDB ~]# sar -ud 3 1000 -pLinux 2.6.9-22.EL (testDB) 11/24/2015 _ppc64_ (8 CPU)05:22:56 PM CPU %user %nice %system %iowait %steal %...
ORACLE 数据库RMAN备份恢复
09-11
RMAN（Recovery Manager）是Oracle数据库提供的一种强大的备份与恢复工具。它能够帮助管理员高效地管理数据库的备份与恢复工作，确保数据的安全性和可靠性。RMAN支持全备、增量备份等多种备份策略，并且可以实现对...
ORACLE 备份恢复之RMAN详解
DoubleJing的博客
06-13 3475
一、连接方式 (一)、连接本地数据库 [oracle@oracle ~]$ rman target / (二)、连接远程数据库 [oracle@oracle ~]$ rman target sys/oracle@orcl 二、基本指令 (一)、执行 SQL 语句 RMAN>SQL ‘ALTER SYSTEM SWITCH LOGFILE’; (二)、RMAN 默认配置 1．显示 RMAN 默认配置 RMAN>SHOW ALL; 2．RMAN 默认配置详解 using target dat
oracle指定tag恢复,Oracle RMAN的备份与恢复命令详解
weixin_39813200的博客
04-02 1123
4.3 Copy 镜像拷贝与恢复Copy镜像拷贝命令可以创建数据库数据文件、归档重做日志或者控制文件的精确副本。 RMAN 副本与这些文件的区别仅在于名称和(或)位置的区别。功能相当于用户管理的备份恢复中的热备份。备份副本的好处是恢复比较快，恢复时可以不用拷贝，指定新位置即可。Copy镜像拷贝至少要在mount 状态下运行。Copy镜像拷贝可作为增量备份的 Level 0Oracle10g开始，允...
oracle10g rac环境Rman备份恢复至单机方案
09-18
Oracle 10g RAC 环境下的RMAN（Recovery Manager）备份恢复至单机环境是一项复杂但重要的任务，特别是在灾难恢复或系统迁移的场景中。以下将详细阐述这个过程的关键步骤和注意事项。 首先，RMAN是Oracle数据库管理...
rman备份遇到的设置rman导致数据库变慢的原因
cqtpou3682的博客
09-04 465
OS: aix 5.3 DB: Oracle 10..2.0.1 RAC数据库相关情况 目前情况：2016年8月23日在********部署rman备份脚本，部署时间是凌晨3点到4点，部署完成...
oracle rman备份慢,我的rman备份为什么这么慢？？
weixin_34185396的博客
04-06 308
最初由 xjg 发布[B]楼主意思是“备份文件总大小约1.28G，从17：28分到21：38分，共花了4小时10分钟”？ 不可能4个小时才备份了1.28G吧你的题目让人看不懂。 [/B]是真的。以下是我两次备份的所有备份文件，总共2.5G(看看时间就知道我说的是真的了)[oracle@report cnreport]$ lltotal 2578004drwxrwxr-x 2 oracle ...
RMAN备份慢故障处理一例
辰风的专栏--Oracle/ClearCase管理员日记
10-12 4375
     今天接到上海TAC电话，报告说最近一周的RMAN备份速度很慢， 数据量很小，但做一次增量备份大概需要3天。数据库版本：Oracle9204 RAC操作系统版本：Solaris 9RMAN备份语句为：RMAN> run{allocate channel c1 type disk;backup incremental level 1 database plus archivelo
oracle备份慢,诊断Oracle RMAN备份慢的原因
weixin_39622399的博客
04-05 195
㈠ 先在系统层面查询CPU、IO使用情况：top、iostat、sar...等 ㈡ EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); ㈢ rman ta㈠ 先在系统层面查询CPU、IO使用情况：top、iostat、sar...等㈡ EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();㈢ rman targ...
oracle并行更慢,为什么RMAN启用并行备份反而速度比常规备份更慢呢？
weixin_33946999的博客
04-12 287
数据库版本 9.2.0.4 os rehat as 4.0RMAN> configure device type disk clear;old RMAN configuration parameters:CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;RMAN configuration parameters...
oracle rman备份慢,诊断Oracle RMAN备份慢的原因
weixin_29564301的博客
04-06 168
㈠ 先在系统层面查询CPU、IO使用情况：top、iostat、sar...等㈡ EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();㈢ rman target / debug trace =/tmp/rmandebug.txt log=/tmp/rman_log20130727.txt执行备份㈣ EXEC DBMS_WORKLOAD_REPOSITOR...
一次RMAN还原慢的分析
Mr.pan felix的专栏
09-22 4716
      原文链接：点击打开链接   下面是模拟同事在客户现场遇到的RMAN还原慢的情况，同事也只能在旁边干着急。因为备份与还原是由其它的备份工程师在操作，但是由于备份工程师的ORACLE技术能力，导致在还原数据库速度很慢。我们知道，RMAN备份与还原也是可以通过配置参数来提到性能，如果是通过备份软件，还可以通过调用备份软件的BUFFER来实现，多路复用等机制来优化，如果数据文件存放在ASM...
生产环境提升rman备份速度----启动块跟踪
深蓝@黄炎龙
05-26 2132
生产环境提升rman备份速度----启动块跟踪 【环境】 AIX（5300-08）、oracle10g（10.2.0.1.0-64bit） 【目标】 由于生产环境数据量较大，欲加快rman备份的速度 【方法】 启动块跟踪 【操作】 SQL> alter database enable block changetracking using file '/home/oracle/blo
RMAN 系列（九） ---- 调整RMAN备份与恢复操作的性能
热门推荐
David Dai -- Focus on Oracle
07-13 1万+
<br /><br />RMAN 实际上即装即用的，我们通常不需要对其做什么调整。 但是,RMAN 体系结构中还包含许多组件，当这些组件构成一个整体时，就必须调整RMAN的设置以从备份进程中得到最佳的性能。 通常RMAN 调整设计到处理逻辑和物理数据库设计中的低效率，调整介质管理库（Media Management Library: MML）, 调整RMAN 和MML 层以备份数据库的物理设备更好地共存。<br /> <br /><br /><br /><br />一． 调整RMAN 前的工作<br />如
Oracle RMAN备份恢复教程：从入门到实战
"该资源是一份全面学习RMAN（Recovery Manager）在Oracle数据库备份恢复方面的教程，适合初学者逐步进阶。教程分为多个章节，包括RMAN的入门、命令详解、备份实践、恢复演练以及一些基础资料篇，旨在帮助读者深入...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值