中文网站

英文网站

Oracle RDB poor Recovery or Rollback performance

IT疑难问题解决方案1

IT疑难问题解决方案2

小型机服务

服务器服务

操作系统|双机

success library技术服务

VAX Rdb/VMSRDMLReferenceManual

VAX Rdb/VMS Version 4.0

VAX Rdb/VMSRDO and RMU Reference Manual

Oracle RDB poor Recovery or Rollback performance

-->联系--》霍工--》13301272832

$ pipe rmu/dump rdb1

And increase the parameter using

sql> alter database filename your_database

RDB poor Recovery or Rollback performance.

Follow up from Oracle page:

Subject: RDBPROD: Impact of NUMBER OF RECOVERY BUFFERS on Row Cache DBR Performance

Title: Impact of NUMBER OF RECOVERY BUFFERS on Row Cache DBR Performance

Product: Oracle Rdb

Op/Sys: OpenVMS

The database "NUMBER OF RECOVERY BUFFERS" parameter specifies the number database buffers that recovery

(DBR) process will use while performing recovery operations. As with user processes, the number of

buffers for a DBR process can have a dramatic effect on performance. Generally, increasing the number of

buffers for the DBR process will have a positive effect on performance when the DBR process is

performing recovery for large transactions (either for rollback of aborted transactions or for recovery

(REDO) of many or large transaction when the database FAST COMMIT feature is enabled).

-->联系--》霍工--》13301272832

The performance of the database recovery (DBR) process can be especially significant when the Row Cache

feature is enabled. After a database or node failure (system crash, for example) for a database with Row

Cache enabled, when the database is re-opened, the monitor will create a DBR process to recover the

database. This DBR process performs the following steps:

1. All row caches are recovered from the backing store (.RDC) files

2. The oldest checkpoint (of either the "fast commit" or the Record Cache Server (RCS) checkpoint) for

any database user is determined

3. All transactions starting at the oldest checkpoint found are (re)applied to the database

4. Each active transaction is rolled back

Because of the potential database I/O required to perform steps 3 and 4, a larger number of buffers can

help reduce the duration of the database recovery process.

Testing demonstrates how significant the number of DBR buffers can be on the performance of re-opening a

database after node failure. A test case involving 25 users performing 1,000 transactions each (a total

-->联系--》霍工--》13301272832

of 25,000 transactions) was interrupted by a simulated system crash. After the system was restarted, the

database was opened. A specially instrumented database recovery (DBR) process was used to measure the

amount of CPU time consumed along with the number of I/Os performed for various portions of the

With the default of 20 recovery buffers for the DBR process, a total of 53,542 disk I/Os were performed

during the REDO portion of recovery. At a rate of 100 I/Os per second, this step would require about 9

minutes. Increasing the buffer count to 1,000 reduced the number of disk I/Os for this step to 4,342. At

the same rate of 100 I/Os per second, the REDO step would now take less than 1 minute. However, for this

particular test, increasing the number of buffers for the DBR process to 2,000 only reduced the I/O

count to 4,262 and further increases of the buffer count resulted in no additional I/O decrease.

Generally, if global buffers are not enabled and there is sufficient memory on the system, a large

number of recovery buffers for the DBR process is beneficial. It is important, however, to avoid

specifying so many buffers that the DBR process page faults excessively.

When global buffers are enabled, the number of buffers for the database recovery process is limited to

the global buffer USER LIMIT quota. In order to increase the number of buffers for the DBR process, both

the "USER LIMIT" and "NUMBER OF RECOVERY BUFFERS" parameters may need to be increased.

-->联系--》霍工--》13301272832

For node failure recovery when the ROW CACHE feature is enabled, a value of 5000 or 10000 for buffers

for the DBR process may be reasonable. The optimum number of buffers will vary greatly depending on the

number and complexity of transactions and processes to be recovered and is thus quite application and

中国·北京联系方式：

1）联系电话：（010）82666745

2）传　　真：（010）82666745

3）联系人：　霍先生　　

4）手　机：　13301272832 　

5）E-mail: 　　bjslkc@163.com

6）公司：北京深蓝融鑫科技发展有限公司

7）地址：北京市海淀区西北旺

10）公司地址、乘车路线及公司位置地图

Beijing DeepBlue the Rongxin Technology Development Co., Ltd. All Rights Reserved.
北京深蓝融鑫科技发展有限公司版权所有,不得转载.
京ICP备05042544号