Author: mac

以下是Maclean Liu的脚本工具盒的部分脚本：   Script:收集Enterprise Manager Grid Control/Agent/Database Control诊断信息 Script:收集Exadata诊断信息 Script:收集RAC诊断信息 Script:收集自动SGA内存管理ASMM诊断信息 Script:Collect vip resource Diagnostic Information 11g新特性:hangdiag.sql实例hang诊断脚本 Script:verify Oracle Object timestamp discrepancy Script:SQL调优健康检查脚本 Script:列出本会话的细节信息 利用rowid分块实现非分区表的并行update与delete Script:计算Oracle Streams进程所占用的内存大小 利用RMAN检测数据库坏块的脚本 Script:利用外部表实现SQL查询Oracle告警日志Alert.log Script: 收集RAC DRM 诊断信息 Script:10g中不用EM显示Active Session Count by Wait Class Script:数据库最近的性能度量 Script:收集数据库中用户的角色和表空间等信息 Script:收集介质恢复诊断信息 Script:收集Flashback Database Log诊断信息 Script:列出Oracle每小时的redo重做日志产生量 Script:收集11g Oracle实例IO性能信息 Script:检查数据库当前是否有备份操作在执行中 Script:List Schema/Table Constraints Script:RAC Failover检验脚本loop.sh Script:Diagnostic…

Crash/Instance Recovery与Media Recovery的本质区别在于： Crash/Instance Recovery针对需要恢复的实例从增量检查点(incremental checkpoint)开始apply redo应用重做日志。由于日志覆盖的先提条件是完成相关日志的logfile switch checkpoint，且从定义上说归档日志总是落后于实例的检查点，所以对于crash/instance recovery崩溃或实例恢复总是只需要访问读取在线的重做日志(online redo logfile)。   介质恢复Media Recovery从旧数据文件的检查点开始apply redo引用重做日志，这些旧的数据文件可能来源于备份。 介质恢复情况下需要用到归档重做日志，因此RMAN或DBA(用户管理的备份)也需要将备份相关的归档日志还原出来。   Crash/Instance Recovery总是保证仅当所有的持久重做数据被应用之后才算恢复完成。 在Oracle保证所有已提交的事务都已经被包含恢复的情况下，才认为崩溃实例完成了恢复工作。   相反，介质恢复有不完全恢复(incomplete recovery)和部分恢复(partial recovery)的提法，以实现恢复数据库(db)到某个时间点的一致性。     Crash/Instance Recovery与Media Recovery的相同点在于：   Crash/Instance Recovery与Media Recovery都是传统的前滚恢复方式(rolling forward)，原理上都是对持久redo log数据的重演。 不管是Crash/Instance Recovery还是Media Recovery的前滚，都需要继之以事务回滚以便回滚未提交的事务，虽然前滚完成后数据库即可以打开而不用等回滚完成，但是仅在回滚完成的时候我们认为数据库是真正一致的。   扩展阅读： 了解你所不知道的SMON功能(五):Recover Dead transaction 深入了解Oracle前滚恢复rolling forward(一) 了解你所不知道的SMON功能(六):Instance Recovery

_CORRUPTED_ROLLBACK_SEGMENTS(corrupted undo segment list)隐藏参数所独有的功能: 在实例启动startup并open database的阶段_CORRUPTED_ROLLBACK_SEGMENTS所列出的undo segments(撤销段/回滚段)将不会被访问读取 所有指向这些被_CORRUPTED_ROLLBACK_SEGMENTS列出的undo segments的事务都被认为已经提交了commit，和这个undo segments已经被drop时类似 这将导致严重的逻辑讹误 如果数据字典上有活跃事务那么将更糟糕，数据字典逻辑讹误会造成数据库管理问题 如果bootstrap自举核心对象有活跃事务，那么将无法忽略错误ORA-00704: bootstrap process failure错误，导致无法强制打开数据库(见拙作Oracle数据恢复:解决ORA-00600:[4000] ORA-00704: bootstrap process failure错误一例) 衷心地建议用_CORRUPTED_ROLLBACK_SEGMENTS这个参数打开数据库后导出数据并重建数据库，这个参数使用的后遗症可能很顽固 Oracle公司内部有叫做TXChecker的工具可以检查问题事务   如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   _offline_rollback_segments 和 _corrupted_rollback_segments 均会造成的实例行为变化： 以上2个参数所列出的Undo Segments(撤销段/回滚段)将不会被在线使用online 在UNDO$数据字典基表中将体现为OFFLINE的记录 在实例instance的生命周期中将不会再给新的事务分配使用 参数所列出的Undo Segments列表上的活跃事务active transaction将即不被回滚亦不被标记为dead以便SMON去回滚(了解你所不知道的SMON功能(五):Recover Dead transaction)

_OFFLINE_ROLLBACK_SEGMENTS(offline undo segment list)隐藏参数(hidden parameter)的独有作用： 在实例startup启动并open database的阶段仍将读取_OFFLINE_ROLLBACK_SEGMENTS所列出的Undo segments(撤销段/回滚段)，若访问这些undo segments出现了问题则将在alert.log和其他TRACE中体现出来，但不影响实际的startup进程 若查询数据块发现活跃的事务，并ITL指向对应的undo segments则： 若读取undo segments的transaction table事务表发现事务已提交则做数据块的清除 若读取发现事务仍活动未commit，则生成一个CR块拷贝 若读取该undo segments存在问题(可能是corrupted讹误，可能是missed丢失)则产生一个错误并写出到alert.log，查询将异常终止 若DML更新相关的数据块会导致服务进程为了恢复活跃事务而进入死循环消耗大量CPU，解决方法是通过可以进行的查询工作重建相关表     _offline_rollback_segments 和 _corrupted_rollback_segments 均会造成的实例行为变化： 以上2个参数所列出的Undo Segments(撤销段/回滚段)将不会被在线使用online 在UNDO$数据字典基表中将体现为OFFLINE的记录 在实例instance的生命周期中将不会再给新的事务分配使用 参数所列出的Undo Segments列表上的活跃事务active transaction将即不被回滚亦不被标记为dead以便SMON去回滚(了解你所不知道的SMON功能(五):Recover Dead transaction)

是否有想过如何在Oracle中实现脏读(dirty read)，在Oracle官方文档或者Asktom的时候显然会提到Oracle是不实现脏读的， 总是有undo来提供数据块的前镜像(before image)以维护一致性Consistent， 通过正常途径我们几乎不可能破坏Oracle中查询的一致性来实现脏读。   如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   是否真的无计可施？ 非也，非也，Oracle作为一个高度复杂而又可控的RDBMS，仍是有很多空子可以钻的。   我们先来介绍以下的2个隐藏参数： _offline_rollback_segments or _corrupted_rollback_segments 这2个隐藏参数对于熟悉Oracle数据库异常恢复或者解决ORA-600[4XXX]问题有经验的同学来说肯定不陌生，因为这2个参数是针对Undo存在Corruption讹误时忽略问题的有力工具，而大家对这2个参数实际起到的作用有多少认识呢？   我们可能在以下几种场景中用到_offline_rollback_segments 和 _corrupted_rollback_segments 这2个隐藏参数： 强制打开数据库(FORCE OPEN DATABASE) 控制一致性读和延迟块清除(consistent read & delayed block cleanout) 强制删除某个rollback segment回滚段   但是请注意：千万不要在没有Oracle专家建议的情况下，在产品环境设置以上这2个隐藏参数，可能造成数据逻辑讹误等影响！！   _offline_rollback_segments 和 _corrupted_rollback_segments 均会造成的实例行为变化： 以上2个参数所列出的Undo Segments(撤销段/回滚段)将不会被在线使用online 在UNDO$数据字典基表中将体现为OFFLINE的记录 在实例instance的生命周期中将不会再给新的事务分配使用 参数所列出的Undo Segments列表上的活跃事务active transaction将即不被回滚亦不被标记为dead以便SMON去回滚(了解你所不知道的SMON功能(五):Recover Dead transaction)…

有同学在T.askmac.cn上发帖关于bulk collect与open cursor的问题， 帖子的地址在这里。  他的疑问在于:   这么说来 OPEN_CURSOR 负责解析SQL语句 和生成执行计划. 会不会去执行 执行计划? 是不是在第一次提取的时候才会执行 执行计划? test_soruce create table zengfankun_temp01 as select * from dba_objects; select count(*) from zengfankun_temp01;–12,6826 analyze table zengfankun_temp01 compute statistics; create or replace procedure test_open_cursor is type type_owner is table of zengfankun_temp01.owner%type index by binary_integer; type type_object_name is table of zengfankun_temp01.object_name%type index by…

今天有闲去了甲骨文在上海陆家嘴香格里拉酒店举办的《优化数据中心》研讨会， 近距离一睹了Oracle总裁马克赫德(Mark Hurd)的风采， 总体来说台上的赫德还是比较洒脱和萌的:)   议程，马克下午出场致辞并讲了简化数据中心的议题：     会场主舞台：       我一开始坐在第二排，第一排坐的有Oracle的高管：     甲骨文公司高级副总裁卢汝文：     甲骨文副总裁Ravi Pendekanti:       甲骨文系统事业销售咨询部潘榆奇:     马克同学闪亮登场，台风还是很随性的：                           光与影：   甲骨文系统事业部服务器产品高级总监 David Simmons：       甲骨文Solaris产品高级总监：       答疑快乐三兄弟：

有同学在 T.askmac.cn上提问关于增量检查点更新控制文件的问题：     Know more about checkpoint checkpoint 分成很多种 full 、file、thread、parallel query、 object 、incremental 、logfile switch 每一种checkpoint 都有其自身的特性，例如Incremental Checkpoint会要求ckpt 每3s 更新一次controlfile 但是不更新datafile header， 而FULL CHECKPOINT要求立即完成(同步的) 且会同时更新 controlfile 和 datafile header。 Incremental Checkpoint会要求ckpt 每3s 更新一次controlfile >>我想问的时：如何查看此时控制文件中更新的SCN?除了DUMP控制文件，有没有命令查询?       我希望通过以下演示说明该问题：     SQL> select * from v$version; BANNER —————————————————————- Oracle Database 10g Enterprise Edition Release…

Oracle甲骨文公司在2012年7月17日发布了最新的数据库安全补丁Critical Patch Update July 2012:在OTN的CPU security专题页面上已经生成了《Oracle Critical Patch Update Advisory – July 2012》的页面；发布的安全补丁涵盖多个版本的Oracle数据库： 包括主流数据库版本上的以下补丁：   11.2.0.3: Database 11.2.0.3 CPU Patch 14038787, or Database 11.2.0.3.3 PSU Patch 13923374, or GI 11.2.0.3.3 PSU Patch 13919095, or Microsoft Windows (32-Bit) Bundle Patch 14095819, or Microsoft Windows x64 (64-Bit) Bundle Patch 14095820     11.2.0.2: Database 11.2.0.2 CPU Patch…

11gR2 RAC中ocr和votedisk终于可以存放在ASM中了， 这避免了10g中仍需要为这2个RAC的关键点划分裸设备的窘境，  随之 11gR2 中ASM的spfile也可以存放到ASM diskgroup中以实现多节点ASM的共享管理了。   这听上去似乎有些不可思议，照常理来说 ASM实例启动并mount diskgroup后才能够访问diskgroup上的文件， 但是ASM实例只有获得ASM spfile后才能够启动实例，这2者形成了死循环。   有同学在T.askmac.cn上提问关于ASM启动的疑问：   hello maclean, 查看spfile位置 ASMCMD> spget +CRSDG/rac/asmparameterfile/registry.253.787925627 就有个疑问，ASM 也算是一种ORACLE instance,自动的系统参数文件在自己的diskgroup，我的问题是它是如何启动从自身未启动的磁盘组读的参数文件？ thanks.!   我们来解释这个问题： 从11.2开始Oracle Cluterware标示voting disk files的方法较之前的版本11.1或10.2有所区别，11.2之前voting disk file的位置存放在OCR中， 但是因为从11.2开始ocr和votedisk可以存放在ASM了 ， 所以自11.2始voting disk file通过GPNP profile中的CSS voting file discovery string来定位。 CSS voting disk file的discovery string将指向ASM，所以它要使用ASM discovery string的值。  如以下的例子使用udev绑定设备名作为ASM使用的LUN， 这些udev获得的设备形式如/dev/rasm-disk* ， 我们利用gpnptool get命令获得gpnp…