闪回技术最佳实践与性能

作者简介:郝文瀚,现就职于北京海天起点,曾获得11g ocp,11g ocm证书,四年oracle数据库维护经验,擅长数据库故障诊断与处理,性能优化等。对数据库高可用,dataguard等有丰富的运维管理经验。

本文着重描述以下四点

Aflashback database的好处

B:性能方面的观察

C:操作的最佳实践

D:针对某些特殊应用程序工作负载的性能调优

该文章粗略介绍了flashback的一些特性,供参考:

A  Flashback database的特性和它的益处:

Flashback database可以快速地将数据库闪回一个时间点,而不是传统的时间点恢复。

Flashback database可以提供以下好处:

1:基于时间点恢复:通过使用Restore Points或正常的闪回数据库功能,快速地将数据库恢复到时间点,可以使用该功能用来:

1)修复已经修改了数据库很大一部分的失败批量更新。

2)从崩溃的数据库中修复当前联机重做日志损坏或无法修复的情况。

3)从计划的维护事件中修复错误(例如更改数据库的应用程序更改)。

2:dataguard快速启动故障转移:快速恢复primary database.

3:手动恢复primary database:如果DATAGUARD没有使用快速启动故障转移特性,dataguard故障转移是必要的,则可以使用flashback database手动恢复失败的primary database. 通过flashback恢复失败的primary database,可以在几分钟内完成,而不必考虑数据库数据量的大小,需要更广泛的工作和在整个网络中执行数据库恢复的时间. DATAGUARD管理和概念指南中说明了故障转移后,使用flashback database恢复失败的primary database.

4:11g dataguard snapshot standby 11g开始使用快照备用数据库或引用数据保护概念和管理)当physical standby database被转换为snapshot standby database时,就会创建一个隐式的保证恢复点,当它被转换回physical standby database时,这个恢复点被用来将快照备份到它的原始状态.

5:flashback失败的数据库升级: 使用flashback database要比传统的降级程序快得多,仅在数据库升级完成后可以使用,兼容的参数保留在源版本中, 并且没有发生应用程序数据更改,为了达到这个目标,请注意步骤,在不执行catdwgr .sql的情况下对数据库进行降级(11.1.0.x to 10.2.0.x/10.2.0.x to 10.2.0.x)

6:rman: flashback databaseRMAN集成,在恢复中隐式地使用,并在需要时显式地使用。例如介质恢复被阻塞时,RMAN隐式使用flashback database

7:snapshot standby:
使用flashback database帮助将数据库恢复到physical database

8:Flashback PDB: Oracle 12.2和更高版本开始, flashback PDB可以在不影响其他PDBs的情况下重放可插入数据库,还可以创建PDB恢复点.

B: 性能方面

在采用下面的配置和操作最佳实践并推荐补丁之后,Oracleprimary databasestandby database上启用flashback数据库时,得到了以下性能观察;

1、即使在工作负载非常高的情况下,一个数据库的前一个小时的刷新通常需要几秒钟或几分钟。在应用给定数量重做的时间中,它只完成了一小部分时间。例如

  • 在一个测试环境中,我们观察到,在一个400GB的批处理工作负载中,有400GB的更改返回一个大的批处理工作负载,用时不到5分钟。
  • 在相同的环境中,34GB大的OLTP工作负载以8GB/s的速度运行1小时,需要2分钟的工作负载,8 MB/秒的重做率不到2分钟。
  • 由于大量的变量,没有确定的方式来估算时间来完成flashback。上述测试是在Exadata上完成的,以消除系统瓶颈,如存储IO带宽。

2、对主要的OLTP工作负载的影响通常小于5%

3、在闪回块的优化生效的情况下,大量的插入(如批量插入)或直接负载操作的影响通常小于5%;否则,影响会有很大的变化(2-40%的影响),所以测试是必需的。在Oracle 11g特性列表中,引用阻止新的优化描述和异常

4、启用Flashback数据库可以减少在物理备用数据库上应用性能速率的峰值重做,但是通常不值得注意,因为启用了闪回功能的可实现的redo应用速率仍然非常高,并且可以超过应用程序的重做生成速率

现在我们来看下不同数据库软件版本的里程碑和关键性能改进

Oracle 10g (2003)
特性:最早拥有flashback database功能的数据库

Oracle 10g Release 2
特性:Normal Restore PointsGuaranteed Restore Points(这俩特性不做具体说明,如想详细了解请参阅官方文档)

Oracle 11g Release 1
特性:Snapshot standbyData Guard Fast-Start Failover 和用flashback自动修复old instatement

性能特征:为单实例环境引入了新的优化特性,降低了直接加载和插入操作的性能影响,flashback block-new优化绕过flashback日志,将插入操作插入到“newed”块中, 对于直接写操作,优化可以避免额外的数据块物理读取到缓冲区缓存。如果没有这个优化,可以观察到三次I/O操作对广泛的直接加载或插入操作的性能影响高达40%

性能修复: 11.1.0.7之前,SQL*loader并行的直接路径加载可能由于隐式段收缩的情况下启用flashback数据库从而导致数据库性能的持续下降,Bug 6403373 修复了该问题

Oracle 11g Release 2

特性:可以在数据库open时开启flashback

性能特征:为RAC提供直接加载和插入操作的新优化特性,除非以下几种情况

1)重新创建一个包含已有回收站的表时

2)截断一个表,然后插入或直接加载操作

3)加载到带有SecureFile LOB或传统LOB数据类型的表时。

性能特征:在到达DB_FLASHBACK_RETENTION_TARGET之前分配闪回日志的初始消耗已经减少,在某些情况下,在阻塞任何应用程序前台进程之前尝试预分配,从而消除了这种消耗,在11.2.0.2版本之前,启用闪回的资源消耗通常比启用了flashback时更高。

Oracle 12c Release 2 (12.2)

特性:1Flashback可插拔数据库支持单个PDBs的闪回,而不影响其他的PDBs

         2PDB Restore Points可以方便地使用方法设置别名和SCN。然后可以使用此别名来进行回闪PDB或时间点恢复

C:操作的最佳实践

1、使用自动工作负载存储库(AWR)收集数据库统计信息,在启用flashback数据库之前和之后的企业管理器,可以测试启用flashback数据库的影响/2、设置企业管理器监控指标,Recovery Area Free Space (%)”,用于对快速恢复区域的空间问题进行主动警报。

3、从11.2开始,当数据库打开时,可以启用flashback数据库。然而,如果该操作未能获得足够的连续内存,则该操作可能失败并发出错误信号。为了保证成功,您可以启用闪回模式。

4、要监视flashback数据库操作的进度,可以查询V$SESSION_LONGOPS视图。监视进程的一个示例查询: select * from v$session_longops where opname like ‘Flashback%’;

5、当使用flashback数据库在测试数据库上执行重复测试时,建议使用Guaranteed Restore Points,而不需要显式地打开flashback数据库,为了最小化空间使用和闪回性能消耗,官方给出以下的方法:

Create Guaranteed Restore Point (GRP)
Execute test
loop

     Flashback database to GRP
     Open resetlogs
     Create new GRP
     Drop old GRP
     Execute test

End loop

D:针对某些特殊应用程序工作负载的性能调优

OTLP工作模式下只有当flashback数据库打开时,才会出现RVWR等待事件的flashback buf,由于缓冲区已经满了,一个会话等待恢复写入器(RVWR)flashback数据写入到磁盘上的flashback日志中,这个会话需要一直等待,直到RVWR可以释放缓冲区。如果该事件成为数据库的顶级等待事件之一。这通常是因为 Fast Recovery Area(FRA)的文件系统或存储系统的IO带宽不足,无法从flashback中提供额外的I/O,参考数据库备份和恢复用户官方文档中的Flashback数据库部分,用于调优考虑并评估相应的IO和存储数据

例如如下top5等待事件

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

write complete waits

1,842

23,938

12995

33.68

Configuration
flashback buf free by RVWR

53,916

20,350

377

28.63

Configuration
cell single block physical read

3,029,626

16,348

5

23.00

User I/O
buffer busy waits

6,248

5,513

882

7.76

Concurrency
DB CPU

 

1,757

 

2.47

 

操作方式:

查看系统的统计信息,在AWR报告或EM中,可以看到在v$sysstat中发现的记录字节和物理写入字节
如果flashback log write bytes/ flashback log write bytes<%5,则flashback不会影响数据库的性能。否则,评估任何操作更改或错误修复将允许使用flashback block new优化特性(参阅上面的性能观察部分),此外,忽略flashback日志文件同步等待事件,即使它是top5等待事件之一
flashback log write bytes= 由RVWR编写的flashback database数据的总大小
physical write bytes=数据库应用程序的活动的所有磁盘的字节总数

例如:当block new优化生效时

flashback log write bytes = 1,223,442,432

physical write bytes = 184,412,282,880

(flashback log write bytes) / (physical write bytes)  = < 5%,这意味着,与在此间隔内直接加载操作的物理写相比,只有一小部分flashback数据。即使在这种情况下,flashback log file sync等待事件依旧是数据库中第二高的等待事件。

Top 5 Timed Foreground Events

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

direct path write

136,553

7,875

58

39.12

User I/O
flashback log file sync

91,566

5,887

64

29.25

User I/O
DB CPU

 

3,092

 

15.36

 
log buffer space

20,545

1,737

85

8.63

Configuration
gc buffer busy release

1,277

487

382

2.42

Cluster

例:当块block new没有生效时

flashback log write bytes= 184,438,194,176

physical write bytes =184,405,925,888

(flashback log write bytes) / (physical write bytes)  = 100% >  5% 这意味着在本例中,所有直接写入都将导致flashback日志写入。下面是这个案例的top 5等待事件。

Top 5 Timed Foreground Events

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

flashback log file sync

170,088

22,385

132

52.04

User I/O
direct path write

278,185

8,284

30

19.26

User I/O
flashback buf free by RVWR

38,396

5,048

131

11.74

Configuration
direct path read

220,618

4,242

19

9.86

User I/O
DB CPU

 

2,788

 

6.48

 
下面的例子说明了两种传统的负载,一种利用了block new优化,而另一种却没有

Top 5 Timed Foreground Events

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

flashback log file sync

235,187

13,728

58

30.82

User I/O
direct path write

558,037

10,818

19

24.29

User I/O
direct path read

459,076

8,419

18

18.90

User I/O
DB CPU

 

6,171

 

13.85

 
flashback buf free by RVWR

79,463

4,268

54

9.58

Configuration

查看实例统计数据,我们看到跟踪block new优化的统计数据几乎没有增加

Statistic

Total

per Second

per Trans

flashback cache read optimizations for block new

62

0.06

1.13

flashback direct read optimizations for block new

8

0.01

0.15

flashback log write bytes

177,533,280,256

177,245,433.67

3,227,877,822.84

flashback log writes

18,917

18.89

343.95

如果flashback cache read optimizations for block new远远小于flashback log writes 则说明block new优化并没有起作用

对于上述负载操作,最好的调优建议是增加I/O带宽,改变执行负载的方式也或许有出其不意的效果,这样就可以利用block new的优化。也可以等待,直到你在闪回保留目标或从回收站移除对象

与其他数据库等待事件相比,使用block new优化的常规负载的等待事件显示在flashback log file sync中花费的总时间相对较少。

Top 5 Timed Foreground Events

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

direct path write

284,115

8,977

32

34.20

User I/O
DB CPU

 

6,284

 

23.94

 
log buffer space

128,879

5,081

39

19.36

Configuration
flashback log file sync

139,546

3,178

23

12.11

User I/O
latch: redo allocation

95,887

1,511

16

5.76

Other

查看实例统计数据,我们看到跟踪block new操作的统计数据在加载期间有显著的增加

Statistic

Total

per Second

per Trans

flashback cache read optimizations for block new

329

0.53

9.68

flashback direct read optimizations for block new

698,410

1,116.43

20,541.47

flashback log write bytes

1,197,514,752

1,914,271.66

35,221,022.12

flashback log writes

18,951

30.29

557.38

未经允许不得转载:Oracle一体机用户组 » 闪回技术最佳实践与性能

相关推荐