[讨论]重现数据库最佳实践和性能_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4344 | 回复: 0   主题: [讨论]重现数据库最佳实践和性能        下一篇 
yapingtian
注册用户
等级:上等兵
经验:127
发帖:14
精华:0
注册:2012-3-23
状态:离线
发送短消息息给yapingtian 加好友    发送短消息息给yapingtian 发消息
发表于: IP:您无权察看 2012-3-23 11:38:14 | [全部帖] [楼主帖] 楼主

Oracle 服务器企业版- Version: 10.2.0.1 to 11.2.0.1 - Release: 10.2 to 11.2

这个文档里的信息适用于任何平台

目的

一些应用的具体情况,可能要求特殊型材调谐或额外的情景时考虑使数据库或使用保证恢复点。这描述了最佳做法,为打开数据库和考虑的情景在具体应用时的范围使用案例。

范围和应用

这些注解是专为数据库管理员都有哪些人在使用或考虑使用数据库或保证恢复点的情景。

数据库重现是一个新的特性对于企业版10g来说,可快速的重现一个数据库一个时间点而不是传统的point-in-time康复。除了point-in-time回收使用,数据库重现使用于:

1.       数据库保护机制——快速恢复主要数据库

2.       11g数据库快照备用(注443720.1 11g使用快照备用数据库)——一个隐含的保证是恢复点时形成一个物理备用数据库转换成一张快照,备用数据库和这个恢复点是用来情景快照备用到它原来的状态转换回时,它是一个物理备用。

3.       回滚升级失败的数据库——使用重现数据库比传统的数据库升级更快,这是唯一可行的数据库升级,只有已经完成,所有申请数据发生了根本性的变化。

4.       数据库升级轧制和物理备用数据库利用瞬态逻辑备用——数据库的一个部分升级当一个物理备用轧制暂时转换为一个合乎逻辑的候补,保证了恢复点进行了初步的数据库升级进程之前,这是使数据库可以重现,后一个物理备用升级。在这看到细节MAA纸,"滚动数据库升级使用备用数据库物理瞬态逻辑待机11 g。

5.       恢复管理器——结合神谕的情景数据库恢复经理和使用回收而明确暗示是否是想要的。

6.       手动恢复数据库——如果数据保护被用于没有失效备援的机制中,那么数据重现就有可能失败。

7.       Pre-11g读/写访问物理备用——在10.2里,你可以用一个物理备用数据库进行检测和其他用途,需要读/写访问备用数据库,完成测试数据库可以闪回一个物理等待问题恢复保护,这是11g附近的快照待机特征,但不同于11 g的最大特色,再做是没有收到而开放的物理备用读写。

8.       测试和训练恢复数据库——另一个常用的数据库重现一个测试或培训数据库相同的起点在每次测试之后跑或训练课程。

数据库重现最佳实践

知道你的基线情景之前确定使开销和应用的影响评估工作量打开数据库的情景,看下面的文档.

确保重现数据库足以支持情景日志,知道你的基线情景之前确定使开销和应用的影响评估工作量打开数据库的情景,一般的经验法则是,我注意到,体积倒叙手法来表现的日志产生大约相同的数量级为重做日志的世代。例如,如果你打算24小时设置DB_FLASHBACK_RETENTION_TARGET ,如果数据库生成20 GB的重做一天,然后一的法则是让20 GB国标GB的磁盘空间为30“闪回”记录。该规则同样适用于为保证值恢复点,例如:如果数据库生成每天20 GB重做,如果保证恢复点会保留一天,然后计划分配20到30 GB,值得注意的是DB_FLASHBACK_RETENTION_TARGET是一个目标,没有保证你可以用倒叙法来表现的数据库那么远在某些情况下,如果有空间压力的区域闪光恢复日志存储情景最古老的木头的情景就被删除,详细的解释规则区域闪光恢复删除看11g Backup and Recovery User's Guide, Maintaining the Flash Recovery Area”。

把企业经理监测公制、“恢复区自由空间(%)“积极的警报的空间问题用闪光灯恢复区。

确保有足够的I / O带宽闪光恢复区,I / O带宽不足的情景是数据库通常表明高发生"FLASHBACK BUF FREE BY RVWR"。

设置LOG_BUFFER至少8 MB给更多的缓冲空间数据库的情景在内存中,对大型11.1.0.7 +数据库在超过4 GB标准遗传算法,你可能认为设置LOG_BUFFER的值在32-64 MB之间。

遵循恢复最佳实践媒体从“数据保护重做申请及媒体恢复”设置PARALLEL_EXECUTION_MESSAGE_SIZE论文到至少8192人,这是任何重现数据库都要改进的方法。

如果你有一个备用数据库DB_FLASHBACK_RETENTION_TARGET然后设置相同的值对备用数据库(s)为主。当在使用Fast-start失效备援的时候,确保UNDO_RETENTION初始化参数设定和DB_FLASHBACK_RETENTION_TARGET至少120仍然是有可能的,恢复经过长期的停电。在一个备用的“闪回”障碍不能保证每隔30分钟发表,在小学,因此,当使情景备用数据库,DB_FLASHBACK_RETENTION_TARGET至少应在120年。

同时也回顾了10g Database Backup and Recovery Basics或者11g Backup and Recovery User's Guide.

为最佳操作授权的数据库重现在数据库LOB  或SecureFiles LOB 类型,用CACHE设置。

RDBMS 11.2不需要数据库在巅峰状态来使用数据库重现。因此,从11.2向前走,它不再需要重新启动数据库转化成山的情景重现数据库。

实际应用数据库在11.2集群可以利用一种新的优化从而降低了性能影响倒叙手法来表现的数据库。参考补丁:9184513的附加信息。

监控进步的数据库操作的情景,你可以询问V $ SESSION_LONGOPS观点,查询监督项目进展的一个例子是: select * from v$session_longops where opname like 'Flashback%';

如果有更多的细节需要对“闪回”然后_flashback_verbose_info数据库的数据库操作参数,可以设定为真实,这将会产生一个详细的数据库操作的情景的痕迹在BACKGROUND_DUMP_DEST目录。

分析性能影响

当使数据库或使用情景保证恢复点你应该遵循这些步骤,分析绩效之影响数据库打开的情景。

1.       占领一个性能基线使用自动工作量仓库(AWR)在高峰试验及生产工作量的时期。如果你没有一个诊断包装许可证要求,然后你就可以使用AWR另外用Statspack,看Note 94224.1"FAQ- Statspack Complete Reference",一个基线数据包含性能一个特定时期内保存的工作量进行比较与其他相似的时期,一个固定的基线创作之前,仔细考虑你选择的时间作为一个基线,因为基线应该代表该系统运行在一个最理想的水平。这个基准(数据库的情景下)将被用来评估的影响数据库的情景你的申请,见第五章Oracle的性能调整指南(10g或11 g)使用AWR技术细节及捕捉一个基线,注意,如果你有任何大的周期性批量工作你也应该AWR占领一个快照。

打开你的测试环境数据库的情景或如果你在RDBMS和释放11g物理备用,然后你可以使你的本身备用数据库的情景,然后将它转换成一个快照待机(这也可以做10.2手动快照,但没有再做备用于收到在11 g快照候补。看Dell 10g Snapshot Standby)。当你运行一个工作量与快照备用的情景也会启用数据库日志。

在高峰AWR工作量试车捕捉快照,这样做是为了大多数的工作。

如果你使用快照待机从生产就跑一个现实的工作量与快照候补,捕捉同样的AWR快照和non-flashback有一样的基线。

启动一个AWR对照报告($ORACLE_HOME/rdbms/admin/awrddrpt.sql)来比较基线快照在数据库重现中,这份报告将会有一个“%差别”栏为每个统计、度量,等事件,如果回顾和评估的影响差异是可以接受的,通常从看着重做一代率(Redo size)和交易每秒(TPS, Transactions on the report),如果你看到一个高发生的“闪回”而得到自由BUF RVWR”等活动,那么这可能表明不够磁盘子系统为闪光恢复区,你也可以使用non-AWR度量如响应时间和工作运行时OLTP间歇概况。

在执行这一production-like测试环境应该是一个好指标数据库性能的影响的情景生产,生产快照是一个更精确的assessmen备用,如果可行,你应该重复测试生产。

已知的高绩效的影响

一个主要的情景使数据库数据库通常会少于2%发送一个OLTP类型的工作量,但在高吊球insert-intensive工作量与直接负载类型的工作量可以高达30%。

1.       对于一个吊球插入广泛应用打开的情景的影响数据库可能是不可接受的,上述分析应该是拿专门的注解来对应每笔交易和物理读取重做一代率/秒。

2.       插入密集的批量工作可能受高达30%,数据库的情景,一般来说,RDBMS释放性能改善的情景11.1.0.6批数据库,性能的影响是微不足道DB_FLASHBACK_RETENTION_TARGET一旦见过面。

3.       SQL *装载机前平行直接路径负载11.1.0.7可以有一个连续的数据库性能下降的情景时由于隐性段出现萎缩。这是固定在11.1.0.7。

4.       之后插入密集应用截断表会招致巨大的开销时,数据库的情景,直到DB_FLASHBACK_RETENTION_TARGET时间过的很快,例如,如果DB_FLASHBACK_RETENTION_TARGET = 240(4小时),然后跟随一个短缩的表格,任何的插入到那张台可能招致逾20%的减少数据库性能截断4小时后,这个性能影响预计将减少到2%以下4小时后的时期已经过去了。

5.      可能有一种情况下,有一个高发生的“闪回”而得到自由BUF RVWR”等事件即使有一个well-tuned闪光恢复区,看Bug 6168063。这个问题是固定在RDBMS 11.1.0.7和10.2.0.4。那儿同样有有一个有效的补丁10.2.0.3正对于绝大多数的平台。

6. 如果使用Oracle SecureFiles然后应用补丁间歇上涨9032717避免等事件”的情景而得到自由BUF RVWR”。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论