Oracle RAC interconnect Traffic 监控

Oracle在AWR中提供了Estd Interconnect traffic(KB)指标,由于AWR默认只能查看小时级别的数据,做准实时监控需要以更小的时间粒度来计算这个指标。AWR怎么算的看不到,我们可以查看statspack计算这一指标的方法,在sprepins.sql中可以发现Statspack的计算公式: Estd Interconnect traffic = ((Global Cache blocks received + Global Cache blocks served)*db_block_size +(GCS/GES messages received + GCS/GES messages sent)*200)/elapsed time 在Oracle statistics中,Global Cache Blocks received等的名字转换参见如下SQL: SELECTDECODE(name,'gc cr blocks received','global cache blocks received','gc cr blocks served','global cache blocks served','gc current blocks received','global cache blocks received','gc current blocks served','global cache blocks served',name) AS

保险核心系统运维惊魂记

                        ??? SQL语句语法有错误,应用怎么不知道,也查不到???语法有错,应用逻辑不应该执行不下去么? 应用会抛出异常、从数据上也会看到数据没有被修改…… 为什么并没有呢??欲知后事如何,且听下回分解。

DPA 试用版

授权说明(License Rights and Restrictions) www.skyatlas.net授予您内部使用本程序的非排他性,不可转让的有限许可,受本协议中规定的限制,仅用于开发,测试,原型设计和演示您的应用程序,且仅限于您的应用程序尚未用于任何数据处理,业务,商业或生产目的,也不用于任何其他目的。您可以允许您的承包商使用本程序,前提是他们代表您行使本协议中授予的许可权利,并进一步规定您有责任在此类使用中遵守本协议。您将与您的承包商签订书面协议,严格限制其使用本程序的权利,并以与本协议相同的程度保护Skyatlas的知识产权。您可以在合理需要的范围内制作本程序的副本,以行使本协议中授予的许可权利。您可以制作一份程序副本以进行备份。 此外,您不可以: 删除或修改任何程序标记或任何Skyatlas或许可方所有权的通知;以任何方式向任何第三方提供本程序(除本协议中规定的代表您的承包商外);使用程序提供第三方培训;转让本协议或分发,给予或转让本程序或其中的权益给任何第三方,除非本承包商协议明确允许(上述内容不得解释为限制您可能另行拥有的权利)持牌第三方技术);导致或允许逆向工程(除非法律要求互操作性),程序的反汇编或反编译;和在未经Skyatlas事先同意的情况下披露任何计划基准测试的结果。本程序可能包含源代码,除非本协议中出于其他目的明确许可(例如,根据开源许可证授权),否则仅为参考目的提供源代码,并且不得修改。 Skyatlas保留本协议未明确授予的所有权利。如果您希望将本程序或您的应用程序用于本协议明确许可之外的任何其他目的,您必须根据允许此类使用的单独协议从Skyatlas或Skyatlas经销商处获得有效的程序许可。但是,您承认本程序可能不适合生产使用和/或Skyatlas可能不会将本程序的版本用于生产或其他目的;您使用本程序进行的任何开发或其他工作均由您自行承担风险。 所有权skyatlas或其许可方保留本计划的所有权和知识产权。 第三方技术本程序可能包含或要求使用随程序提供的第三方技术。 Skyatlas可能会在程序文档,自述文件或与此类第三方技术相关的通知文件中向您提供某些通知。第三方技术将根据本协议的条款许可给您,或者,如果在程序文档中指定,则根据单独条款向您发送自述文件或通知文件。您根据单独条款使用单独许可的第三方技术的权利不受本协议的任何限制。但是,为清楚起见,尽管存在通知,但未经单独许可的第三方技术的第三方技术应被视为本程序的一部分,并根据本协议的条款许可给您。 如果同意上述协议,您可以下载DPA 试用版本软件。如有商业使用需求,请联系skyatlas.net.link:Database Performance Analyzer for Oracle.

Oracle11g提高了DML修改父表时锁定子表的级别

近日处理了一个电信计费系统的性能故障,因为外键上没有索引,导致出现enq: TM 锁争用,以及不时出现Deadlock问题,处理完后整理资料,发现这篇blog叙述比较清晰,遂用Google Translate翻译如下: Oracle 11g(自11.1.0.6以来)引入了一个微妙但可能有重大的变化,关于在监管外键约束方面保持锁的方式。 以下内容已在11.2.0.1和11.2.0.2上进行了测试。 为了设置场景并复制我们在工作中遇到的问题,我将创建一个小表(ALBUMS),它有2个FK约束,指向两个父表(ARTISTS和FORMATS)并用几行填充它们。 SQL> CREATE TABLE artists (id NUMBER PRIMARY KEY, artist_name VARCHAR2(30)); Table created. SQL> CREATE TABLE formats (id NUMBER PRIMARY KEY, format_name varchar2(30)); Table created. SQL> CREATE TABLE albums (id NUMBER, album_name VARCHAR2(30), artist_id NUMBER CONSTRAINT artist_fk REFERENCES artists(id), format_id number CONSTRAINT format_fk REFERENCES formats(id)); Table created. SQL>

DPA在电信计费系统故障诊断案例

3月20日中午,电信客户的计费系统故障,所有操作响应缓慢,应用无法正常运行。现场DBA已经迅速将应用连接转移到RAC集群的另一节点,恢复应用服务,我们使用DPA来回看事故现场,此时离故障发生,已经一小时了…… 回溯负载情况,如下图   问题最严重时,实例堵塞了近700个连接操作…针对此时间段,进一步点击、下钻分析当时系统发生了什么 系统先是每分钟4~5次堵塞(像是咳嗽),到了13:40后,就处于长时间“梗”住的状态,对于外部业务来说,数据库实例已不可用了。   利用DPA,继续下钻,查看堵塞原因: 1654#会话导致80个会话被堵塞,这80个会话的等待事件是 sga:allocation forcing component growth,这80个会话中的一些会话又堵塞了一些其他会话,如下图 266号会话堵塞了3个会话,这三个会话的等待事件都是cursor:pin s wait on x,这个等待事件一般都是跟sql parse相关,所以,现场工程师开始查看oracle 自己的ADDM报告,说是解析有问题,建议应用分析解决问题…被误导了   至此,DPA下钻后清晰显示,堵塞的根源是1654号会话,DPA显示是MMAN进程,它堵塞了80个会话,这些会话又堵塞了更多其他会话,是一个3级的堵塞关系,幸好DPA以“树型”显示方式,把这种多层级堵塞关系显示的非常清晰。 结论:Oracle MMAN进程进行过于频繁的SGA内存组件(本例中是share pool)resize操作,导致了问题…   这张图中显示的share pool内部情况,看官能看出异常么?   “划一条线1美元,知道在哪里划线9999美元”。 至此,后续我们如何解决这个问题的就不再讨论了,解决问题从来不是难事,难的是发现问题。 后记: 从DPA的负载雷达上,我们看到在系统出现问题之前的一小段时间内,系统负载不正常的降的很低,其后负载飙升上去…… 那段时间负载异常降低,说明了什么? 应用程序发生了什么…… 这些从Database Performance Analyzing层面,就无从知晓了。

利用DPA诊断Oracle锁等待问题

10:50分左右,REMS2系统发出系统性能告警,1套RAC的Active Session数量超过了200……收到告警之后,甲方DBA专家进入战位,查找原因。可是——现在的Active Session数量已经恢复了,往事不可追啊……REMS2 DPA出场~查看故障时间段,Active Session变化情况: 大概从10:48左右,Active Session持续增高,到10:53之后,由大概200左右,迅速恢复正常。我们使用DPA的BST History功能模块,查看问题最严重时,系统的Active Session都在干什么…… 可以发现,多个会话,在执行SQL ID为appfxqvj6scuv的SQL,因为无法获取enq:TM而被堵塞,这些会话本身又堵塞了其他的会话。Oracle中,一个DML操作,除了会以独占模式持有行级别的TX锁外,还需要持有表级别TM锁的共享模式,以防止在DML过程中,表的结构定义被修改(关于Oracle Enqueue、Lock机制此处不做过多描述)。现在这些会话无法获取到共享模式的TM锁,那说明什么? 说明TM锁被别的会话以独占模式持有,还没有释放……到这里,已经很清晰了,有人在业务高峰时期做了DDL操作,那么是改了表结构、还是建了索引呢?使用DPA的Top SQL模块,检查一下该时间段的SQL操作,如果有DDL操作,应为肯定耗时较长,会被记录下来…… 再次轻松几分钟诊断故障原因! 哦耶

Oracle活动会话异常增高诊断-续

……之前我们利用DPA-Lite,已经定位到LGWR进程在特定时刻,堵塞了几十、上百个会话,导致Active Session数量在短时间内出现高峰……之后是各种分析、诊断…… 到底是IO性能出现问题,还是Commit量太大,导致LGWR出现延迟,却是一时间无法分辨。甚至,由于REDO LOG是放在高端存储的SSD上的,SSD有无问题…… 每次“故障”也不过就10秒,想精确定位问题何其困难!我们还是通过DPA-Lite来仔细检查,看看能不能找出一些端倪……5月10日,16时左右,问题再现: 此时间段内,Active Session高峰多次出现;16:06:56秒,LGWR堵塞了68个会话; 我们仔细看一看都堵塞了哪些会话,有何特点…… 特点是: HTZT用户,通过JDBC连接的应用,在等待Commit; 当前操作的对象ID都是 131629872和131629864 通过DPA-Lite查询另外一个时间点: 再次确认了这个现象!我们再看看更早之前发生Active Session高峰时的现象(5月8日16时): 仍然是HTZT用户操作OBJECT ID 131629872 131629864时等待Commit……我们查询数据库,确认这两个对象,发现是一张LOG(日志)表和该表上的一个索引,这个表以BLOB方式保存日志,目前数据量极大——超过300G。使用DPA-Lite 查看对应时间段的Top Object: 问题时间点,对于该表索引的操作,在数据库中占用资源排名第一! 存储已经用的最高端的了,解决问题就从这个日志表入手吧……日志么,都是用来事后查询、分析使用的,我觉得存在文件系统里,利用Hadoop之类分析是最好不过的,核心数据库高端存储上存个几百GB的日志,还弄出这种问题来,赶紧迁走……一想到拿着这些证据,一会儿让应用开发那帮哥们哑口无言我就觉得兴奋!

REMS在性能诊断、分析场景下的实用

下午4点半,rems2发出cpu负载高的警报——使用率超过50%。不是演习、不是测试,真正的核心系统:两台aix上的一套Oracle 10g RAC。 很明显16:30之后,cpu负载上升,一直到17:00,使用率在50%处波动~ 同时网络流量,内存,交换分区都很平稳: 检查数据库对应时段的指标,逻辑IO明显的高阶运行,激活会话数升到35左右,物理IO与用户调用无对应跳阶: 接下来,很自然的就是Top Session显示,Top SQL分析了~ 很遗憾,咱是生产核心系统,这些都不允许贴出来了😄  好的监控、性能分析工具,随着你的心意、方向,有如低扭强大的机械马达——让你御风而行

Oracle Case insensitive index searches

有几种方法来编写’case insensitive’的SQL语句——SQL需要避免全表扫描。如果是Oracle10g R2之前版本,我们需要:1. 在查询中转换数据,使其大小写不敏感(case insensitive),FBI(Function Base Index): create index upper_full_name on customer ( upper(full_name)); select full_name from customer where upper(full_name) = ‘SAM HENDRY’;2. 在存储数据(insert或者update)时,使用触发器完成case insensitive转换(比如使用to_lower,to_upper 内建函数)。3. 使用 alter session命令 alter session set NLS_COMP=ANSI; alter session set NLS_SORT=GENERIC_BASELETTER; select * from customer where full_name = ‘Sam Hendry' 在Oracle 10g R2版本中,引入了使用BINARY_CI BINARY_AI排序来进行case insensitive查询的功能。 初始化参数设置: NLS_SORT=binary_ci NLS_COMP=ansi 创建索引: