十二月 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依赖一个健康的网络，尤其是高负载的系统和网络环境，网络上有调整的需求。
【 阅读全文 】
九月 15th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
ORA-04030和ORA-04031是oracle内存管理中司空见惯的错误，一个发生在pga中，一个发生在shared pool中。
关于该类错误的bug着实不少，抛却bug本身，一个稳定系统出现该类错误，很可能是code本身的问题造成了内存上的消耗或者碎片，由于无法申请可用内存，造成错误本身。
【 阅读全文 】
四月 12th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
本文重点讨论跨操作系统平台场景下利用Oracle自身特征的迁移升级手法，不涉及跨字符集转换，不涉及成熟的第三方迁移工具，同平台请参考
Oracle高可用迁移升级场景与实战(一)
一般来说，跨平台迁移相对于同平台迁移在停机时间和可控性上有着更严格的要求。核心的方法也无外乎快速的一致迁移和增量同步等几种方法。
【 阅读全文 】
三月 10th, 2010 @ Kevin.yuan |【转载时请务必以超链接形式标明文章原始出处和作者信息】
较大型的系统环境往往因各种原因，将数据库部署到不同平台或者不同版本上。随着系统的后期调整，必然涉及到数据库方面的相关改造（比如平台迁移，版本升级等）。对于这类整改工作，需要考虑的因素比较多，但核心问题无外乎以下几点：
① 风险与可控性
风险与可控不单单指的是迁移升级过程中，更指迁移完毕后的新环境的运行情况(稳定性、性能等)以及对业务系统的支撑情况。
一个良好的迁移工程，需要强有力的迁移控制过程，完善的模拟验证机制以及快速有效的回退方案。
②停机维护窗口
大部分迁移都需要在指定的停机时间内完成，以避免对业务造成更多的中断和影响。对于高可用环境，需要有良好的迁移方案来尽可能压缩停机时间。
本文重点讨论各种常见场景下利用Oracle自身特征的迁移升级手法，不涉及跨字符集转换，不涉及成熟的第三方迁移工具。 【 阅读全文 】
