一月 24th, 2011 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
Cascaded Destinations，简单的讲，就是为了避免主库的压力和干扰，将主库产生的redo通过一个standby传送到另外一个standby上，而不是直接通过primary到另外一个standby。在Oracle各版本的在线文档上，对此界定也并不一致。比如这样一个组合方式：Primary Database > Logical Standby Database > Physical Standby Database，因为最后一层的standby并不和第一层的priamry database有直接关系，1-2和2-3分别自成体系，这并不是一个真正意义上的Cascaded Destination。但在10g和9i在线文档中，依然将这种模式列为cascaded destinations，而在11g中已经将这种情形排除。严格意义上的cascaded destination 支持如下组合场景：
1. Primary Database > Physical Standby Database with cascaded destination > Physical Standby Database
2. Primary Database > Physical Standby Database with cascaded destination > Logical Standby Database
Cascaded Destinations的用处还是比较多的，例如使用dataguard做远程容灾的场景，使用Cascaded Destinations就远比local primary和romote standby直接做dataguard可靠。基于WAN上的dataguard的一个致命问题就是主备端的网络质量问题，这将对主端产生严重的影响，尽管可以通过async的方式来进行redo或者archive的传送，但在一个繁忙的系统中，这仍然是个极大的性能和稳定性隐患。通过Cascaded Destinations，redo/archive log的同步放到了local physical standby端上进行，主库产生的日志先传送到local standby，然后由local standby负责传送日志到remote standby。
![cascaded%20destinations[1]](http://www.easyora.net/wp-content/uploads/2011/01/cascaded20destinations11.jpg "cascaded%20destinations[1]")
对于10g版本以上的该模型，通过日志传输参数VALID_FOR的功能，通过角色控制priamry/standby向remote database的日志传送，这样日常中local dataguard的switchover并不影响remote standby的同步且操作上更加平滑，另外，remote standby端配合Flashback Database，这样也避免了因为WAN上带宽有限，local database的Failover造成的remote standby的重建带来的数据传输问题。
需要特别提出的是cascaded standby databases中的FAL的配置问题，正常情况下最后一级standby的日志是从上级standby上取得，并非直接从primary上传输，但特别情况下可直接由Primary向最后一级standby传送。如果最后一级standby的fal_server配置对应primary database和上级standby database，那么可能出现这么一种情况需要注意：上级standby database的对应的归档日志已经apply但已经不存在(比如被删除)，因为下级 standby database存在一系列问题，恢复进度并没有赶上日志的传送速度，当正好需要上级standby上这部分log的时候，发现从上级standby上已经无法获得，这时候通过fal_server的配置可直接从primary向最后一级standby上传输，而不需要中转。
Metalink doc上也相关记录如下：
If primary receives a FAL request from the remote standby in the above case then It ships the archive logs directly to the remote standby without going via cascaded standby.
一月 7th, 2011 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
读写分离是架构分布式系统的一个重要思想。不少系统整体处理能力并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。针对业务类型特点，需要从架构模式上进行一系列的调整，比如业务模块的分割，数据库的拆分等等。
集中式和分布式是两个对立的模式，不同行业的应用特点也决定了架构的思路。如互联网行业中一些门户站点，出于技术和成本等方面考虑，更多的采用开源的数据库产品(如MYSQL)，由于大部分是典型的读多写少的请求，因此为MYSQL及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业，比如电信业、金融业等，考虑到单点处理能力和可靠性、稳定性等问题，可能更多的采用商用数据库，比如DB2、Oracle等。
就数据库层面来讲，大部分传统行业核心库采用集中式的架构思路，采用高配的小型机做主机载体，因为数据库本身和主机强大的处理能力，数据库端一般能支撑业务的运转，因此，Oracle读写分离式的架构相对MYSQL来讲，相对会少。
前段时间一直在规划公司新的数据库架构，考虑到我们的业务特点，采用Oracle读写分离的思路，Writer DB和Reader DB采用日志复制软件实现实时同步； Writer DB负责交易相关的实时查询和事务处理，Reader DB负责只读接入，处理一些非实时的交易明细,报表类的汇总查询等。同时，为了满足高可用性和扩展性等要求，对读写端适当做外延，比如Writer DB采用HA或者RAC的架构模式，Reader DB可以采用多套，通过负载均衡或者业务分离的方式，有效分担读库的压力。
对于Shared-nothing的数据库架构模式，核心的一个问题就是读写库的实时同步；另外，虽然Reader DB只负责业务查询，但并不代表数据库在功能上是只读的。只读是从应用角度出发，为了保证数据一致和冲突考虑，因为查询业务模块可能需要涉及一些中间处理，如果需要在数据库里面处理(取决与应用需求和设计)，所以Reader DB在功能上仍然需要可写。
【 阅读全文 】
十二月 21st, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
一直以来对SQL profiles都是爱恨有加。SQL profiles的灵活和一些特性(比如对SQL语句级的类似cursor_sharing功能，对非绑定变量环境非常实用)，在不很多不能修改应用代码的场景下最小风险的对SQL语句进行调优，是传统的outline无法比拟的;但是用过SQL profile的朋友应该都清楚，按官方的SQL tuning Advisor提供的sql profies生成办法，由于包含了太多了nodirective Hints(比如OPT_ESTIMATE/COLUMN_STATS/TABLE_STATS等),并不能保证执行计划的稳定性，会随着外界的因素发生改变(比如表和索引的信息，柱状图等信息的变化) 。尽管二者都是依靠hints来提示或者指挥优化器完成执行计划的解析，但却不尽相同。通过SQL Tuning Advisor 生成的hints更多是为执行计划的生成提供评估和参考信息，而Outlinie Hints，倾向于指挥命令。
前几天在查阅新书<Pro Oracle SQL>介绍的时候，看到作者blog上有提出了undocmented way手工构造SQL profile的例子，确实能像outline一样，强制固定住执行计划，这顿时让我觉得柳暗花明，因为我之前一直对SQL profiles的稳定性大伤脑筋。结合最近的几次项目调优，使用这种办法固定SQL计划，效果相当不错。
手工构造SQL Profiles，可以使用oracle提供的dbms_sqltune.import_sql_profile过程。
【 阅读全文 】
十二月 20th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
ASM disk header 相关信息如何获取，可参考 完全手工重构ASM Disk Header <一>
以下是一个ASM diskgroup中disk文件头全部损坏重构的例子。
启动asm实例，diskgroup TEST无法挂载。
以下是alert.log错误信息：
———————-
NOTE: cache registered group TEST number=2 incarn=0xc868c69a
Sun Dec 19 14:44:38 2010
ERROR: no PST quorum in group 2: required 2, found 0
Sun Dec 19 14:44:38 2010
NOTE: cache dismounting group 2/0xC868C69A (TEST)
NOTE: dbwr not being msg’d to dismount
ERROR: diskgroup TEST was not mounted
【 阅读全文 】
十二月 20th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
上周帮朋友处理了一个ASM磁盘的故障，反馈到我这里，看到asm disk header的信息已经全部丢失，由于只是损坏了diskgroup组中的一个disk，很多信息可以从该组内的其他disk上获得，处理起来不是太麻烦，用kfed merge了一下，受损的diskgroup被重新挂载。
如果问题再延伸一下，假设一个diskgroup的上所有的disk header信息全部丢失，重新构造一个全新的header的工作量就大了不少，相关数值又是如何获得呢？经过几天的研究，一个asm disk header上的核心信息完全可以从disk上其他AU中获取或计算出来，通过这些信息，ASM disk header可以完全重构。当然，作为一个甲方dba，这种需要借助非常规处理的极端故障情况，几乎在我们的环境中不可能出现，绝大部分隐患故障理所应当通过技术、管理和其他手段规避。
重构asm disk header，比较方便的方法就是使用kfed，另外，很多信息需要根据disk上的其他au和block位置上的结构体来定位，如果对这部分结构不熟悉，要提高效率快速定位，在unix下，比较方便的办法就是利用shell脚本，对disk根据AU和block遍历查找，从而获得我们想要的信息。11g下某些信息和属性有别，以下信息仅供10g参考。
比如，我重构ASM Disk Header,常用的两样东西：kfed 和自己写的一个简单的shell脚本(以下称之为echo_asm_status.sh，作用就是根据指定关键字获取AU和block,脚本很简单，就不列出来了，弄个循环跑，grep我们想要的关键字就行了)
【 阅读全文 】
十月 27th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
提到dataguard的Gap处理机制，大多数人能说出的措施便是设置fal_server和fal_client,从9i开始，Oracle提供了2种log gap的检测和处理机制。对于gap的处理，fal_*参数在某些情况下并不是必须配置的。
1.Automatic Gap Resolution
2.FAL Gap Resolution
1.Automatic Gap Resolution
从9i开始，Dataguard就引入了自动日志缺失检测的机制，无需设置任何fal_*参数，Datguard便运行在这种机制下。当Lgwr和Arch进程发送redo/archive到standby端的时候，当前log sequence会同standby端RFS进程上次接收到的log sequence做比较，如果发现二者有断档，RFS会发送请求到primary端，要求主库传送缺失的日志。从9iR2开始，Automatic gap resolution 功能上得到增强。主库上的ARCH进程会每分钟检查备库上的日志gap情况并做相应处理。
【 阅读全文 】
九月 19th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
之前用shell写的Physical Dataguard监控脚本，实现功能：物理主备库dataguard 同步状态检查.
监测机制：
因脚本配合集中监控平台Shell接口使用,本脚本监控一主一备模式的Physical dataguard 环境,脚本可部署到主备任意端或监控端主机,通过TNS连接主备库,主备库角色自动识别,角色切换后脚本无须更改,未将MAXIMUM PROTECTION模式列入监控. 需要大批量的Dataguard环境一次性输出巡检结果，可增加密码配置文件信息和重新定义数组，自行扩展。
####################主备库同步监控判断依据###############################
# 1.主备日志序号不一致，返回状态： Warning ,打印主备logseq #
# 2.主备日志序号一致: #
# (1).当主库mode_level为MAXIMUM AVAILABILITY，返回状态：Health ,打印主备logseq #
# (2).当主库mode_level为RESYNCHRONIZATION， 返回状态：Attention, 打印主备logseq #
# (3).当主库mode_role为MAXIMUM PERFORMANCE， 返回状态: Health,打印主备logseq #
####################################################################
考虑到Shell的明文安全问题，主备库的密码不嵌入脚本中，配置到到隐藏配置文件$config_file中，可编辑该配置文件属性为400.
明文是Shell的一大缺陷，不符合某些IT运维环境的安全要求，后面维护代码尽量摈弃Shell,统一使用Perl编写。
【 阅读全文 】
九月 16th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
算起来运维dataguard也有一些年头了，对其原理机制和调整诊断也早已烂熟于心。最近闲来重温了一下Oracle MAA系列<Data Guard Redo Transport & Network Best Practices>，之前由于接触关注的dataguard几乎以局域网为主，并没有太多网络上的瓶颈问题，也就未曾多加关注。
Dataguard依赖一个健康的网络，尤其是高负载的系统和网络环境，网络上有调整的需求。
【 阅读全文 】
