ITPub博客

oracle备库延时的监控方法[@more@]根据最后一个已经apply的日志文件的next_time时间戳进行判断 select /*+ rule */ nvl(round((sysdate-max(NEXT_TIME))*24),999) from v$archived_log where APPLIED！='NO' and REGISTRAR='RFS' http://docs.oracle.com/cd/E11882_01/server.112/e25513/dynviews_1016.htm#REFRN30011 其他检查方式 1.根据system表空间文件的chkpoint时间检查 select /*+ rule */ nvl(round((sysdate-CHECKPOINT_TIME)*24),999) from v$datafile where file#=1; 2.根据最后一个apply的归档文件的创建时间判断，优点是不需

预警的些想法[@more@]1.预警的意义 通知我们某个点出现了异常，并且这个异常在可预见的未来可能会造成什么样的影响2.预警的要素 监控点&触发点&对象&渠道&频率3.一次通知定义 语音外呼-1次，短信-2条，邮件1条，旺旺1条4.常规预警分级 根据影响可能发生的时间和可能造成的影响和评估，而不是简单根据触发点的重要程度 分级的目的1） 重要性的传递2）抑制告警 分级的出发点，主要的级别为LV0，LV1，LV4，LV5。LV2,LV3的预警希望只是用做辅助性分级。 负载类：LV0，LV1，LV4，LV5 负载类告警一般突发性比较强，以短期型

Bug 9290526 - Poor plan for recursive SQL used for DML involving a UNIQUE constraint [ID 9290526.8] … [@more@] A suboptimal plan may be seen for the specific recursive SQL: select c.name, u.name from con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled =:1 and c.owner# = u.user#; This can cause inserts involving a unique constraint to show poor performance. Workaround Set optimizer_mode=rule for the affected DMLs. https://supporthtml.oracle.com/epmos/faces/ui/km/SearchDocDisplay.js

softer soft parse 软软解析[@more@]不解释，帖链接http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams228.htmhttp://docs.oracle.com/cd/E11882_01/server.112/e25513/stats002.htmhttp://www.orafaq.com/node/758http://www.orafan.net/blog/180.html