前半生

2020年10月09日 阅读数:22
这篇文章主要向大家介绍<Oracle优化新常态> 前半生,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。
公众号有 Oracle  技术文章,  MySQL 的, Linux  系统的,也有投资方面的. 还有养身方面的. 
欢迎订阅, 欢迎分享朋友圈,欢迎留言,欢迎打赏. 

祖仙教一小凡仙 公众号: 前端


经过公众号查看本书的图片mysql

第一章 前言linux



1.1 做者简介git

  本人小凡仙,真姓为曾凡坤,一个很普通的人。程序员

于2004年去了东莞工做,在一家台湾工厂干程序员活。主要是用C++BUILDER工具和微软SQL SERVER数据库,开发工厂的信息系统。其实就是简化各个车间文员的工做,以及比较好的让各部门领导查看数据而已。虽然叫ERP系统,实际就是个MIS信息管理系统!2005年来到了深圳,开始在一家软件公司为证券信息公司开发个信息发布系统,使用C++BUILDER开发ORACLE数据库。后来再去了工厂里开发ERP系统,其实是维护ERP系统,用的是DELPHI开发ORACLE。在这里主要是学到了PL/SQL,已经对ORACLE和LINUX系统有个基本了解,原本想学ERP总体思想,可时运不佳。ERP随着经济而萎缩,招聘职位愈来愈少。2007年转向了ORACLE管理,得到一份DBA工做,其实就是个运维DBA。2008年的金融危机使我失去了该DBA职位。而后3年内从事的数据库开发的工做,主要是ORACLE开发,开发什么经营分析系统和移动139邮箱的报表系统。所以对SQL写法,SQL执行,SQL优化是有深入的体会的。es6

  2013年再度回到了DBA岗位,虽然从事运维DBA,负责多个系统的集群和灾备数据库。web

干了多年,或多或少遇到过性能问题,也尽力去优化了。感受数据库最后端优化的空间是不大的!后来去了家物流公司,听说这家公司在淘宝物流的单量排在第10位,不过压力也挺大的,常常CPU飙高,负载指数达到500!面试

 

1.2数据库发展史sql

 

 计算机的起源相信大部分大学计算机课本都有介绍,无论是科班和非科班以及职业中学都有介绍。数据库

众所周知的第一台计算机是美国军方定制,专门为了计算弹道和射击特性表面而研制的,承担开发任务的“莫尔小组”由四位科学家和工程师埃克特、莫克利、戈尔斯坦、博克斯组成。1946年这台计算机主要元器件采用的是电子管。该机使用了1500

ENIAC

继电器,18800个电子管,占地170m2,重量重达30多吨,耗电150KW,造价48万美圆。开机时让周围居民暂时停电。这台计算机每秒能完成5000次加法运算,400次乘法运算,比当时最快的计算工具快300倍,是继电器计算机的1000倍、手工计算的20万倍。用今天的标准看,它是那样的“笨拙”和“低级”,其功能远不如一只掌上可编程计算器,但它使科学家们从复杂的计算中解脱出来,它的诞生标志着人类进入了一个崭新的信息革命时代。

然而,英国在二战期间研制的用于破解密电的电子计算机巨人(Colossus)却要比ENIAC早两年(1943年12 ),巨人计算机是第一部全然电子化的电脑器件,使用了数量庞大的真空管,以纸带做为输入器件,可以执行各类布林逻辑的运算,但仍未具有图灵彻底的标准。巨人计算机建造到第9部“马克二号”4,可是其实体器件、设计图样和操做方法,直到1970年代都仍是一个谜。后来温斯顿·丘吉尔亲自下达一项销毁命令,将巨人计算机全都拆解成巴掌大小的废铁,巨人计算机才所以在许多计算机历史里都未留下一纸纪录。英国布莱切利园目前展有巨人计算机的重建机种。

 

 有专家说算盘也是计算机,若是从算数来讲,这点不能否认! 当算盘依旧是算盘,不是计算机。计算机是用机器来计算, 算什么呢?天然是算古代应用数学。我国对数学的应用算盘就够了,没有继续发展下去。而在欧洲应用数学就有不断的提出高难度要求,促进了对计算数字的工具发展。计算机是从加密机和破密机发展而来的!

 英国拍了部二战题材的电影叫《模拟游戏》


 

讲的是图灵用机器去破译密码的故事。图灵何许人?

艾伦·麦席森·图灵(Alan Mathison Turing,1912年6月23日-1954年6月7日),英国数学家、逻辑学家,被称为计算机科学之父,人工智能之父。[1] 

1931年图灵进入剑桥大学国王学院,毕业后到美国普林斯顿大学攻读博士学位,二战爆发后回到剑桥,后曾协助军方破解德国的著名密码系统Enigma,帮助盟军取得了二战的胜利。

  另外我的是冯·诺依曼[1]  (John von Neumann,1903~1957),20世纪最重要的数学家之一,在现代计算机、博弈论、核武器和生化武器等诸多领域内有杰出建树的最伟大的科学全才之一,被后人称为“计算机之父”和“博弈论之父(涯杰)”。第二次世界大战期间为第一颗原子弹的研制做出了贡献。为研制电子数字计算机提供了基础性的方案。

 

这两我的奠基了现代计算机的基础,尤为是可存储的程序!

 

开始的第一代的计算机采用的是纸带串孔来表示01,表示程序和数据。要求计算机提供计算的结果。这样为第一代原子弹的诞生提升了速度。后来的发展就是把纸带编程了磁盘,里面不在存的是01,而是ASM编码,俗称汇编语言。由于你们认为每次人工在纸带上打孔,自定和修改都很不方便,并且学习0101也很费力和费时。天然也不多人用得起!后期计算机发展迅猛,计算速度越快,而人类编制计算任务相对来讲很耗时间,计算机的计算能力被闲置了不少。这样一来一边硬件的发展,一边是编程的发展。硬件从大型机,到小型机,再到台式机,以及目前的手机!并且编程发展从汇编语言到C语言 后面就是DELPHI, JAVA,PYTHON语言。

  而数据库是怎么来的呀?除了语言的发明外,还发明了操做系统这个东西,它是中介而已。

说白了就是社会分工,由操做系统负责硬件的交道和协调工做。既然有能够存储的程序,天然会有能够存储的数据。程序是二进制编码 10101这样的内容,后缀名字通常都是.EXE,linux通常都是bin 。而数据以文本文编码而保存,通常是TXT命名,天然还有其余结构的。

  计算机除了科学计算外,还有一个用途是数据处理。程序操做数据文件,程序代码不多,而数据文件确不少,或者很大。程序操做这样的数据文件,就是咱们的数据库初型!

这就是数据库的雏形,程序和文件!你也能够编写这样的数据库。我用C++BUILDER 使用结构数据类型把股票信息,在套个一维数组使用流化类保存在文件当中。能够新增,保存,查找,删除等操做。

 这样的雏形数据库就大部分开始应用在企业领域当中,也就是企业请人来编程,据说是用的COBOL。

COBOL(CommonBusinessOrientedLanguage)是数据处理领域最为普遍的程序设计语言,是第一个普遍使用的高级编程语言。在企业管理中,数值计算并不复杂,但数据处理信息量却很大。为专门解决经企管理问题,美国的一些计算机用户于1959年组织设计了专用于商务处理的计算机语言COBOL,并于1961年美国数据系统语言协会公布。经不断修改、丰富完善和标准化,目前COBOL已发展为多种版本。

 

后来出现了商业软件,好比咱们学校教过的基于DOS操做系统的FOXBASE,FOXPRO和基于WINDOWS系统的VISUAL FOXPRO 。这就是第一代数据库 是商业化的软件!你们是用的ACCESS也是这一类

 

第一代桌面数据库 在这本讲性能优化的书中,我重点看到的是它是个桌面型数据库,只供一我的操做,用户并发数是一!固然商业化第一代数据库提供了统计功能和数据文件的管理功能。

 

第二代是服务型数据库 主要表明是微软公司的SQLSERVER 和甲骨文公司的ORACLE 以及IBM 公司的DB2。 这代数据库完成了SQL统一接口,虽然在各家数据库当中有特点的SQL,好比微软的T-SQL,甲骨文公司的PL-SQL。同时也定义了关系理论,并在这代数据库获得了实现! 这代主要是C/S架构,能够同时接500个客户同时操做! 使用不一样的锁解决用户并发问题。基于地第二代数据库有大量的ERP系统,包括SAP和EBS!

 

第三代是WEB集群据库,由于WEB的发展刺激了数据库的发展,表明是MYSQL。在工厂里SAP系统使用小型机作为数据库平台,由于它稳定,可靠,性能卓越。没有必要搞集群,没那个动力,支持百儿千的用户量没问题。而后在WEB世界里,万,百万,千万的用户量是一件很常见的量,而且是老板很开心的事情,是技术大牛值得追求的事情。为此IT技术再次出现了分层,出来了个应用服务器,好比说TOMCAT等。从C/S架构两层变成了三层,既是浏览器+应用服务器+数据库服务器。除了分层还有就是集群,应用服务器TOMCAT也集群,数据库MYSQL也集群,天然ORACLE也集群了!

 

第四代是集团化数据库。 由于互联网+和移动互联网出现!用户量从万的级别变成了亿的级别。淘宝平日PV量(页面浏览量)16亿到25亿之间,并且12306.cn也有10亿的量,而真实的UV量(用户量)也过亿。象如此大的用户,靠集群已经没法支撑了,须要各类不一样特性的数据库组团打怪,造成集团化做战。列如使用 上千台MYSQL服务器承担查询任务,使用上百台ORACLE集群服务器来承担,库存,支付,结算的工做。 再用NOSQL数据库现在火爆的REDIS和MONGODB集群来完成非结构的查询.使用内存数据库完成缓存查询,列入memcache,用列式数据库完成消费帐单的统计功能。

 

   数据库的发展解决数据的共享和用户并发的控制!

 

1.3性能为何会慢?

   性能为何会慢?缘由有12345等。主要是慢是个趋势,无可逆转,如同人总要衰老的!

也就是说当你的系统哪怕是上线后未曾修改,随着时间和业务的发展必然达到硬件上限能力!而现实有不少缘由致使系统未必达到那个境界就开始慢起来了,如同咱们但愿人没有病没有痛的老化而死去!

 

慢的第一个缘由是用户量多了!

  这个缘由是个开心的事,说明用的人多啊,只有增长硬件的投入

 

慢的第二个缘由是数据量变多了!

  这个或许也是开心的缘由,除了追加硬件投入外,还能够减小数据来提升性能

 

慢的第三个缘由是功能愈来愈多!

  很显然这也是个开心的缘由,除了硬件追加外,没别的法子

 

慢的第四个缘由是设计师设计得很差

  这是个很重要的缘由,由于设计的很差或致使不少不少问题出来,并且设计很差的缘由会被深度掩藏起来。解决办法是从新设计新版本。

 

慢的第五个缘由是开发人员SQL写的很差!

  这个是目前市场上性能优化的重点,可开发人员都是充忙地加班加点赶忙度呢!解决之道是制定个规范,并且这个规范易用,而后再SQL审计把关下。后期只好请DBA参加优化。

 

慢的第六个缘由是数据库和系统的参数配置很差!

  这个也是目前市场优化的重点。招个有经验的DBA来配置。不要让开发人员去管理数据库!

 

慢的第七个缘由是硬件问题

 可能硬件某个环节坏掉了。

 

 

1.4性能优化新常态

 新常态 就是说优化的重点不是在SQL的化和参数的配置。虽然这两项比较能立杆见影,性能突进。好像是个倚天剑和屠龙刀!采用SQL和参数两项优化外,时间过了仍是会出现性能问题,只不过是其它方面的性能问题。

 常态是 咱们该从设计领域着手,从数据库发展史和计算机发展史得到灵感,就是分工和分层!依据JAVA编程的思想高内聚 低耦合!根据业务特性来配置硬件,设计系统,是系统各个子系统高内聚,低耦合。相互独立自主,又不互相影响!

   本书主要谈的是ORACLE性能优化,主要是讲ORACLE在服务型数据库和WEB集群数据库领域的优化,好比工厂里的SAP,EBS和基于WEB的金融,云ERP,进销存等系统。在互联网+,移动互联网领域ORACLE基本上属于集团化中的子数据库系统,跟2,3代数据库差很少,再也不是优化的重点,并且优化的方法依旧如此,没有特殊之处。




第二章强拆


如下强拆是基于WEB化的数据库应用系统,若是是工厂的ERP ORACLE EBS就飘过吧!


  2.1 为何要强拆?

    本章读者群是,技术总监,系统架构师,数据库架构师,系统设计师,高级程序员。只有这样的角色才能起到强拆做用!没有领导的号召,城管才不去搞拆迁活动啊!

由于咱们的数据库大部分基本上,几乎是,90%都是混合型数据库。全部的系统,该系统全部的业务都在一个数据库里面实现。也就是说全部的表都同在一个用户下,集群多也是100%克隆式的扩展而已!为何要混合在一块儿呢?那是由于数据库设计课程当中没有讲过,讲的是3N方式和冗余措施,讲的是逻辑关系ER图。而应用开发人员还有ROSE的时间图,状态图。

  通常来讲一个系统上线要2-3年的时间才出现数据库性能的问题。而此时留守来的只有高级开发人员和技术总监,以及招来少许的低级开发人员作维护性开发。慢起来就是突发的事件,要承担巨大的精神压力,轻则业务缓慢运行,重则业务中断。好比12306每到节假日不可开机!作为留守或者是半路而来接手的技术总监幸福指数直接降低!顶多都是临时优化,头疼吃感冒药,脚疼打麻醉药,应付过去了事。实在没办法当即采购硬件来顶。和尚敲钟,能顶一天算一天。假如你要在这家公司长期干下去,不想蹦来蹦去的,或许你接手这个系统已经优化不少次了,已经买了屡次硬件来顶,到你手上已经没有了优化空间和余地了。

那么怎么办?老板会怎么看你?老板会会相信前几任把优化空间用完了吗?他只会认为前几任有本事,并且你是废物!

 2.2 第一次拆按业务来拆

   一个系统,能够细分多个子系统,或者说子业务,不一样的业务。好比说我所在的第三方支付公司,公司业务主要流程以下,商户开户-,商户发来交易,过风控,发给银行,走银行通道,结算,划款,退款,拒付。那么大体来讲有以下几个业务:

1  管理业务主要是商户管理,商户自身管理。

2  风空业务  这个业务涉及到不少规则。

3  交易业务  处理交易,接受银行交易返回信息,核对交易。

4  银行通道管理,银行通道有不少限制,好比说交易量,拒付指数

5  财务业务  涉及到结算,划款,退款。

 

 那么就说能够分红5种业务

 这里主要是根据业务来划分,也能够叫系统。接下来若是须要能够深度拆分,系统-》子系统-》模块

或者是业务-》子业务--》模块。这就根据用户数量级别,公司经济实力,以及开发实力来定。

作为技术总监,高级开发人员应该说是熟透业务,按业务来拆分是轻而一举的事情!

  第一按业务来拆分的话,当其中一个业务发生了性能问题,不会影响到其它业务的正常运行。而后混合型数据库,当每个月月底或者月初的时候,都要给商户作结算,有的是30天,有的60天,有的是90天,还有的是180天。另外还要给销售人员算提成,提成都是根据商户的交易量来算的。这将是个巨大的IO运算量,每到这个时候数据库就要卡好几回对吗?并且会影响到其余业务正常运行,好比通道不行了,很慢啊!商户打来电话抱怨很慢了。这要承受巨大的压力!

 有了业务拆分,它好!你也好,何乐而不为呢?采用JAVA思想高内聚,低耦合,经过接口来完成业务之间的数据共享。那么设计接口呢?有如下几种方式

   1  后端数据库DBLINK模式,没个业务都用一个用户名概括子在一块儿,包含,表啊,存储过程啊,视图和函数啦!这里介绍下恒波手机卖场,用.NET开发的WEB进销存系统就是采用该方式完成业务拆分。

  

采用多数据源方式,NETJAVA都支持多数据方式。好比财务当中的结算业务就要调用商户管理业务的数据库。那么财务业务要再多配个数据源就是商户的数据源。咱们公司就采用这种方式

  3 采用MQ消息机制,JAVA经过内部服务对象发消息给另外个对象要求某些数据。


采用数据库中间件 MYCAT ,经过数据库中间件,mycat,myproxy,oneproxy等分析接手到的SQL语句来,分析用到的表名来路由具体的数据库。

  

这四种方式最好的是第三种,在JAVA层完成数据接口。主要是清晰可控,并发能力也能提升,天然这涉及到了开发实力。不过一开始设计的时候考虑进去了的话,确实是一件不难的事情。其次是第二种采用多数据源方式,这方式NET会用得多。也比较容易实现。

 再者是第一种方式,这方式适合把业务放在数据库端来实现的,而应用端只实现用户友好方式。

最后一种就是第四种,这是一种偷懒的方式,基本上应用层代码不用改,数据库层表能够不用分离。就靠数据库中间件来路由。

 为何这样排序呢?由于有利于开发人员进行SQL的分离,目前的SQL不少是多表的联合查询,这些表不少是跨业务系统的。开发人员依旧把过去混合模型中的习惯延续下去,天然对后续的机器扩展带来性能问题。

物理部署方案

单数据库模式

单集群模式


多集群模式


2.3 第二次拆读写分离 OLSPOLTP OLAP

   。。。。。。。。。


SQL请求分离


2.3 第二次拆 SQL请求分离 


   分离这个词组现在已经很是耳熟,熟到已经熟透了。在MYSQL领域常常据说到分库分表,读写分离之类的架构思想,依旧是3-4年前的事。这里分离要结合业务特性,就是SQL请求特性来分离。应用程序发往数据库的SQL是有不一样的类型,虽然能够分为INSERT,SELECT,UPDATE,DELETE等,虽然这些类型的SQL,当它们的请求是不同的。站在应用程序角度来看,它发日后台数据库的SQL频繁度,要求的响应时间,以及SQL所涉及访问数据的多少来划分,OLQP, OLTP,OLAP,OLHP  这四个类型就是小仙个人划分。什么是OLTP和OLAP呢? 

OLTP是在线业务处理;

OLAP是在线分析(统计);

OLQP是在线业务查询;

OLHP是在线业务(大数据,分析,统计,挖掘);


详细介绍以下:

当今的数据处理大体能够分红两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。
OLTP是传统的关系型数据库的主要应用,主要是基本的、平常的事务处理,例如银行交易。
OLAP是数据仓库系统的主要应用,支持复杂的分析操做,侧重决策支持,而且提供直观易懂的查询结果.
OLTP:
也称为面向交易的处理系统,其基本特征是顾客的原始数据能够当即传送到计算中心进行处理,并在很短的时间内给出处理结果。
这样作的最大优势是能够即时地处理输入的数据,及时地回答。也称为实时系统(Real time System)。衡量联机事务处理系统的一个重要性能指标是系统性能,具体体现为实时响应时间(Response Time),即用户在终端上送入数据以后,到计算机对这个请求给出答复所须要的时间。OLTP是由数据库引擎负责完成的。
OLTP 数据库旨在使事务应用程序仅写入所需的数据,以便尽快处理单个事务。

OLAP:
  简写为OLAP,随着数据库技术的发展和应用,数据库存储的数据量从20世纪80年代的兆(MB)字节及千兆(GB)字节过渡到如今的兆兆(TB)字节和千兆兆(PB)字节,同时,用户的查询需求也愈来愈复杂,涉及的已不只是查询或操纵一张关系表中的一条或几条记录,并且要对多张表中千万条记录的数据进行数据分析和信息综合,关系数据库系统已不能所有知足这一要求。在国外,很多软件厂商采起了发展其前端产品来弥补关系数据库管理系统支持的不足,力图统一分散的公共应用逻辑,在短期内响应非数据处理专业人员的复杂查询要求。
联机分析处理(OLAP)系统是数据仓库系统最主要的应用,专门设计用于支持复杂的分析操做,侧重对决策人员和高层管理人员的决策支持,能够根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理,而且以一种直观而易懂的形式将查询结果提供给决策人员,以便他们准确掌握企业(公司)的经营情况,了解对象的需求,制定正确的方案。


不过在小仙这里明肯定义为在线分析,相似于SELECT SUM() 之类的统计功能。

 

OLHP

真正的数据库仓库,咱们使用大数据HADOOP 为操做系统平台,用HIVEHBASE作数据库。用SPARK来作分析。

 

OLQP的定义是读写分离中的读操做,在线查询功能!由于MYSQL来支持互联网,互联网有大量的查询简称QPS。而在通常数据库SELECT查询量也是不少的。

 

那么第二次拆分是 OLTP,OLQP,OLAP,OLHP了

  目前来讲OLHP是个独立的系统,每每与常规的交易系统隔离开了。好比说经过ETL程序把交易数据迁移到数据仓库中,同时通过清洗和转化。小仙认为未来可能每一个业务都有可能独立的分析库。好比我公司的风控数据仓库,全球化的今天高官须要在线模式使用数据仓库。将来不会跟正常系统混合在一块儿,不过做为拆分思想,这里稍微预测下。

重点是OLTP,OLQP,OLAP

  由于这三个特性很是不同,OLTP是交易类型,是用户并发量大,要求时间很是短,事务要求一致性很高,要求数据安全度很高,不允许数据丢失。并且涉及数据比较少,涉及的表也很是少。

 OLAP 在线统计用户量或许少,主要是查询的数据比较多,涉及多张表联合查询,主要消耗IO和内存。


而OLTP是消耗CPU和锁资源。完成一个付款交易,货架减库存的交易


OLQP 把它独立开来,从OLTP中分离出来,目的是不影响高并发OLTP. 由于用户查询量是很是大的。

好比物流当中,用户常常要查本身的快递,运输的状况,到达了哪一个站点,以方便本身安排接货.

 

 也就是说把INSETDELTET UPDATE语句放进指向OLTP数据源中;

把经过索引访问的SELECT 语句指向OLQP数据源中。好比说SELECT NAME FORM STUDENTS WHERE ID=? 这样根据ID查到学生的姓名可能要放进OLQP中。

简单来DML操做放进OLTP中,而把单索引访问的SELECT放进OLQP中,

把大数量的统计的SELECT 放进OLAP中。

  

  这样拆分有利用ORACLE众多的参数调整。最明显的一点就是 OLAP能够建立好多好多的索引,并且不影响交易的速度,由于每次的数据插入,更新都有同步维护索引,若是索引多了话,维护索引的时间会更长,每一个索引可能会发生索引分裂,从而致使每笔交易时间拉长,进而会形成更多的锁资源争用。并且OLTP中的表只须要两个索引。同时两种类型的表能够不一样的形态,从而两种都获得了性能上的提升。

好比说OLTP除了设计到3N范式外,还能够进步提升到4-5N范式,而不用考虑什么数据冗余的问题。

数据冗余所有交给OLAP当中去设计。OLAP能够采用大数据块和压缩技术以及列式存储,ORACLE 11G 的结果集缓存,12C的IMO。什么是IMO呢?

2014年6月,在Oracle 12c的12.1.0.2版本中,Oracle正式发布和引入了基于内存和列式计算的In-Memory Option 简称IMO。这个特性有利统计单列。好比说统计整年的交易额,只涉及一个字段,

SELECTSUM(TR_AUMOUNT)

FORMTR_TRADE

WHERE TR_DATIME BETWEEN XXXX AND XXX;

在过去它要访问全部行的每一个字段,要把每一个字段读取到内存而后在筛选出来。而这个特性就是列转行地存储在数据块中。也就是说数据块只存一个字段的内容,相对行来讲所须要的数据块数量很是少。而平时是经过联合索引方式达到该目的,好比建个(TR_DATIME,TR_AUMOUNT)


所以 OLTP,OLQP,OLAP 分别是事务量(TPS),查询量(QPS),吞吐量(OPS).  而OLHP 就是挖掘量!! 



 2.4 第三次拆数据的水平拆分

 

 这个拆分已经接近了技术层面了,固然这个技术拆分必须结合第二层拆分才能发挥到最大性能。

 一方面根据数据冷热程度,拆成热,温,凉,冷。把热的和温的放进OLTP当中,把温的,凉的,冷的放进OLAP中,把冷的放进OLHP当中。 这中间有个交叉重复,这主要考虑数据同步问题。另外市面上常有个叫法是叫当前表和历史表。差很少是以冷热程度来拆分的。 那么依据什么来判断冷热的程度呢?

 小仙我认为根据修改频繁度来决定,好比说insert delete 和短期内发生的UPDATE操做,以及实时查询单笔要求的数据,能够作为热表。而温表是查询比较多,同时只会发生UPDATE 一条或多条数据。凉表是数据不在发生变化了,再也不发生UPDATE,更不能发生DELETE了。并且查询量大,主要是统计类型。所谓冷表就是基本没有什么查询了。这个要看业务界面上的设计了。我在工行能够查过去好几年前的美圆购买记录。

  为此每一个表都必须带有两个必要的字段(建立时间,更改时间)


另外根据OLTP和OLAP的特性使用不一样的分区技术,好比说OLTP经常使用是散列分区,而OLAP经常使用的是时间分区,数据量大的话用到双层分区,先时间分区,而后列举分区,好比说移动公司的时间加省份。




这个图表明了三次拆分,也可说是拆了三层。若是业务复杂,或者用户量超多。能够在业务层再细分模块成。若是使用JAVA对象MQ传递消息 完成数据共享的话,再采用多集群部署。应该达到很是高的性能,同时也是高扩展,高可用的三高典范设计。哪怕是真的出现了数据库性能慢的事,也是发生在局部当中,不影响全局整个系统运转。并且每一个局部都是单纯化,为此针对该单纯能够很是个性的优化系统,数据库以及SQL语句。而不会象混合数据库样,为个SQL语句建立的索引,又致使其余SQL语句改变了执行路径,从而形成该SQL语句变慢的麻烦。



第三章 分库分表


市面上流行的分库分表的说法,其实都是来自MYSQL那伙人的.MYSQL DBA 太弱鸡了,毛办法,没有分区表,数量那么太,用户那么变态。什么根据水平拆表,USER_ID= 分到其余库中。


MYSQL DBA 爱拆法


Sharding的基本思想就要把一个数据库切分红多个部分放到不一样的数据库(server)上,从而缓解单一数据库的性能问题。不太严格的讲,对于海量数据的数据库,若是是由于表多而数据多,这时候适合使用垂直切分,即把关系紧密(好比同一模块)的表切分出来放在一个server上。若是表并很少,但每张表的数据很是多,这时候适合水平切分,即把表的数据按某种规则(好比按ID散列)切分到多个数据库(server)上。固然,现实中更可能是这两种状况混杂在一块儿,这时候须要根据实际状况作出选择,也可能会综合使用垂直与水平切分,从而将原有数据库切分红相似矩阵同样能够无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分.

垂直切分的最大特色就是规则简单,实施也更为方便,尤为适合各业务之间的耦合度很是低,相互影响很小,业务逻辑很是清晰的系统。在这种系统中,能够很容易作到将不一样业务模块所使用的表分拆到不一样的数据库中。根据不一样的表来进行拆分,对应用程序的影响也更小,拆分规则也会比较简单清晰。(这也就是所谓的”share nothing”)。



水平切分于垂直切分相比,相对来讲稍微复杂一些。由于要将同一个表中的不一样数据拆分到不一样的数据库中,对于应用程序来讲,拆分规则自己就较根据表名来拆分更为复杂,后期的数据维护也会更为复杂一些。



让咱们从广泛的状况来考虑数据的切分:一方面,一个库的全部表一般不可能由某一张表所有串联起来,这句话暗含的意思是,水平切分几乎都是针对一小搓一小搓(实际上就是垂直切分出来的块)关系紧密的表进行的,而不多是针对全部表进行的。另外一方面,一些负载很是高的系统,即便仅仅只是单个表都没法经过单台数据库主机来承担其负载,这意味着单单是垂直切分也不能彻底解决问明。所以多数系统会将垂直切分和水平切分联合使用,先对系统作垂直切分,再针对每一小搓表的状况选择性地作水平切分。从而将整个数据库切分红一个分布式矩阵。




ORACLE DBA 爱拆法

第一 业务拆分法  也就是前面两张讲的按业务,按功能业务拆分法

第二 就是按 SQL请求特性 拆分法   : OLAP OLTP OLQP OLHP


第三 分表法

3.0 在甲骨文公司没有开发SHARDING产品前,咱们可采用以下方式,达到分库分表的效果

   3.1 垂直拆分法: 

    根据字段使用频率拆分, 就是有些经常使用的字段放在一个表中,其余不经常使用的字段放在另外个表中。 垂直拆分叫法跟 MYSQL 不同了

  3.2  水平拆分法:

  通常使用分区技术。根据某个字段的值 把数据分在不一样表中。 好比根据时间字段,状态字段, ID值。     时间字段采用范围分区,状态字段采用列表分区,ID采用散列分区。

 3.3 根据生命周期拆分法:

   根据用户对数据的使用频繁度来把表拆成,热表,温表,冷表或者是说 当前表 历史表。



第四  分表分库

 这里说的是如何把分出来的表,迁移到其它数据库当中。使用其它数据库的服务器能力一块儿为应用程序提供服务

 对于 按业务拆分的库, 通常都是独立的数据库,数据库之间的数据不作同步,减小耦合性。只是在应用程序上作个服务接口,为其余业务提供本库的数据服务。


 对于 SQL请求特性拆库的话,就须要完成数据同步服务了!


好比OLTP 通常采用集群模式,或者是主备模式。小仙我通常建议RAC集群模式,表采用散列分区,每一个数据库实列分别承担不一样散列分区的SQL请求操做,这样扩大了用户的并发量,同时也提升了OLTP性能。


而OLAP 通常采用独立的数据库,经过OGG来或者简单的DBLINK来从OLTP里得到数据。

OLAP 主要是为了统计而从新设计的,能够在使用32KB空间,压缩技术,结果集缓存,建立N多索引,而不用小心影响OLTP插入性能。采用RAC集群模式多个分区表分别在多个数据库实列上,并开启并行操做。天然达到了MYSQL 多库同时完成统计的功效!


OLQP   通常能够同过 主备模式 从OLTP 及时同步数据到DG库上。 主库能够单独拿出一个实列完成DG的数据传输,使用LGWR +ASYNC 及时把数据传给到DG库上。log_archive_dest_30  能够支持30个DG。这样会对主数据库带来性能压力。毕竟太多了,须要LGWR进程工做。支持4-5台DG,仍是能够的。 4-5台ORACLE DG性能完胜MYSQL 100台服务器。

应用程序能够经过 TNSNAME.ORA里面的配置进行负载均衡到不一样的DG上。


说实在的MYSQL 分库分表技术难度很高,实现很麻烦,还须要数据库中间件来帮忙解决路由的问题,须要这个分区表是存在哪一个库中。而ORACLE 就容易多了。只是数据冗余了些!


通常经过DG 就能很好完成分库分表的工做。20台ORACLE服务器就能跟100台MYSQL服务器同样出色。能够支持中小型电商网站的用户请求量。


关于费用! 基本上不少民营企业使用D版的,并且也没人去查。若是要买正版能够买一个CPU的LINCES 大约20-30万。 至于你往后装在多少台服务器上,它也不那么管。


分库分表是总结了第二章的强拆,也就是ORACLE的分库分表.与MYSQL的分库分表的区别.

从我所了解到的MYSQL分库分表,视野集中在表的身上,把不一样的表放在不一样的数据库中,这种拆分法跟个人按业务和功能拆分法,基本上相似,不过MYSQL是从下往上看.思惟方式有点井底之蛙的感受。视野集中在性能上,可能没法达到业务和功能上的隔离。

MYSQL拆表法,有两种,一种按字段,经常使用和不经常使用分别存在不一样表中。另一种是按某个字段的值,好比user_id=XXX 或者时间字段进行水平拆分。其实这个ORACLE分区技术是一个概念的。当这里有个问题,那就是水平拆分的表,若是放在不一样的数据库中,就须要数据库中间件来完成路由工做。光从技术角度来看是没法理解这样的拆分需求的,只有OLQP的大量查询,把查询分别负载到不一样的水平数据库中,好比登陆的时候根据用户ID分散到不一样的数据库中。 好比电商查询不一样的商品,电脑和化妆品的查询,就经过水平拆分表的方法,分散到不一样的数据库中。每一个数据库就保存不一样的数据。

    把表水平拆分到不一样的数据库后,再用MYCAT把请求同时分发到全部的数据库,一块儿完成工做。而后在MYCAT进行数据合并。这样的操做需求应该是统计类型的,好比说SELECT SUM() FROM USER_ID .须要全表扫描的工做。可表已经拆散了,分布在不一样的数据库当中,天然要向所有数据发出命令一块儿合做完成工做。 这就是典型的OLAP。

说白了你们都差很少,只不过MYSQL是从技术角度由下往上进行拆。 而我提的ORACLE分库分表是从业务角度由上而下地分。


  若是你作成到了两级分库,那么往后的性能问题就比较单纯了


有朋友质疑20台ORACLE数据库与100台MYSQL数据库 分库分表性能是否同样? 其实这个嘛,主要是MYSQL是硬解析,不得不用机器来拼人力!ORACLE高效的共享池技术极大了下降了硬解析的CPU消耗。你说20台拼不过100台MYSQL服务器。假设一样的配置,一样的应用!

而电商WEB应用最大的是天量查询请求,也就是OLQP。 QPS量大!

QPS能够用多个备库来完成。把大表水平拆分多个分区,也不须要路由MYCAT的了。由于每一个备库都有全量的数据,经过TNSNAME.ORA来负载均衡完成。因此实现起来很是简单明了!


物理实现的方式能够多种多样,考虑公司的经济实力而已。重点是要完成两级分库。往后爱咋折腾都方便了,就不用鸟应用开发啥事了。后台DBA根据性能轻松完成,数据库的部署,架构的调整,数据的迁移等等操做。


你看我啰嗦里八嗦的 好几章了! 不过我仍是认为重要的事情说三遍!






第四章  三大配置

今天咱们将重要的三大配置,分别应用程序端,系统端,数据库端。

由于这三大配置,常常致使性能问题,并且很重要的问题!


第一大配置 应用程序链接池配置

由于ORACLE连接是进程,每来个连接进来的话,ORACLE后台要生成一个服务进程SERVER PROCESS 提供服务,而系统也要有个客户端进程。

而在WEB应用的今天,大量的,并且是频繁的短连接。就是发生一个WEB请求后,须要操做后台数据库,则须要连接一次数据库。查询完了,立马翻脸不认人。下次要的时候,在狗脸乞讨。


这个时候LINUX 系统须要FORK()函数生成一个进程出来,用完后就销毁!

在之前工厂中这种状况也有,只是比较少,无所谓而已。毕竟一个工厂顶多255台连接,大部分都是长连接,并且就是在早上上班的时候发生登陆风暴!


可现在WEB天下,动不动就云ERP,从工厂内部,扩展到全球其余工厂,或者支持异地上班,好比说销售人员,在家工做好比说老板。这样的话须要1千个连接。并且每次都是短期连一下,连完后就丢丢掉!


这样的状况很显然对数据库所在的LINUX服务器来讲,鸭梨山大!AIX 和SORILAS,都跑不掉! 你说升级小型机,仍是大型机也是给不了多少力的。


不用说云ERP了,就是工行的WEB网银都很累!工行的客户远远多于全球化的工厂用户。


因此就要配置应用连接池!

JAVA 应用有好多连接池能够玩! TOMCAT也有,。。。。


Proxool是一个Java SQL Driver驱动程序,提供了对你选择的其它类型的驱动程序的链接池封装。能够很是简单的移植到现存的代码中。彻底可配置。快速,成熟,健壮。能够透明地为你现存的JDBC驱动程序增长链接池功能。


DBCP (Database Connection Pool)是一个依赖Jakarta commons-pool对象池机制的数据库链接池,Tomcat的数据源使用的就是DBCP。目前 DBCP 有两个版本分别是 1.3 和 1.4。1.3 版本对应的是 JDK 1.4-1.5 和 JDBC 3,而1.4 版本对应 JDK 1.6 和 JDBC 4。所以在选择版本的时候要看看你用的是什么 JDK 版本了,功能上却是没有什么区别。

(主页:http://commons.apache.org/dbcp/)


C3P0是一个开放源代码的JDBC链接池,它在lib目录中与Hibernate一块儿发布,包括了实现jdbc3和jdbc2扩展规范说明的Connection 和Statement 池的DataSources 对象。

(主页:http://sourceforge.net/projects/c3p0/)


商业中间件链接池 weblogic的链接池 websphere的链接池


NET IIS 容器也有, 小仙就配过。

string cs =

    "server=.;uid=sa;pwd=tcaccp;database=pubs;pooling=true;min pool size=5;max pool size=10"

    其中 pooling 表示是否打开链接池,默认为打开,关掉时须要 pooling = false;

    min pool size 表示链接池最少保存几个链接对象;

    max pool size 表示链接池最多保存几个链接对象。(最大值不能为 0,也不能小于最小值)

    配置好之后,经过 SqlConnection con = new SqlConnection(cs); 便可获得一个属于链接池的链接对象。

在作 ASP.Net 程序时,咱们会发现,若是网站20分钟不访问,再次访问就会比较慢,这是由于IIS默认的 idle timeout 是20分钟,若是在20分钟内没有一个访问,IIS 将回收应用程序池,回收应用程序池的结果就至关于应用程序被重启,全部原来的全局变量,session, 物理链接都将清空。回收应用程序池后首次访问,至关于前面咱们看到的程序启动后第一次访问数据库,链接的创建时间将比较长。因此若是网站在某些时段访问量不多的话,须要考虑 idle timeout 是否设置合理。


PHP 好像没有现成的链接池能够使用,不过PHP常常和MYSQL搭伙过日子,利用MYSQL的内置链接池功能。


连接池注意要点就是 最大连接数和最小连接数,不要太大的差距。并且不要很频繁地释放连接回操做系统!


目前来讲连接池对ORACLE来讲,有一项功能没有实现,就是尽量地把同一条类似的语句,分配在同一个连接上。这样就重复利用了SESSION_CURSOR_CACHE的参数。



第二大配置  系统大页内存。


目前的PC服务器基本上都是4GB以上的64系统。AIX和SUNSOARLAS 基本上配置好了大页内存,而LINUX6系列默认都是小页内存。

关于内存能够参考以下

Linux 64 页表,进程内存,大页

Linux_x86_64BIT内存管理与分布

部分SWAP 内存知识


由于系统存在着程序逻辑内存和真实的物理内存的映射关系,而这个关系须要用部份内存来保存起来。

并且是每一个进程都须要一部份内存。内存的多少取决于程序使用的逻辑内存量。

虽然内存映射关系进行了4层以上的映射。不过也抵不住程序使用内存的野心。

最终致使内存表的变态的肥肥!


好比说 你有张100MB的数据库表,通过一年的运行和积累达到了1GB。每一个回话,也就是每一个连接,有个语句,天然是SQL全表扫描该表的语句,扫描1GB。那么该进程须要1GB逻辑内存地址和物理内存地址映射。

假设下,原来100MB须要1MB内存地址来保存映射关系,如今须要10MB了。

好比说咱们如今有1500个数据库链接,加上链接池不重用链接线路的话,1500*10MB=14GB内存保存映射关系表!

有点夸张了! 不过我如今有个11.2.0.1 JAVA开发高级人员,以为本身很牛鸡巴,本身搭建了ORACLE数据库。

结果链接池也没配,大页内存也没有配。 大约230个应用程序链接数,占了3.2GB的映射表(内存表) 系统总共才32GB 。


默认状况下LINUX是4K内存页大小的。 也就是说3.2GB除以4KB,大约有多少个页。我就不算,你能够算算看! 这么多页,CPU须要把它掉入到CPU寄存器中。因此CPU处理这活的话,累死了!


而LINUX 能够开启2MB的大页内存。这样的话CPU也轻松了,页表大小也少了。


第三大配置 数据库内存自动分配!


只从ORACLE开始人性化来,从ORACLE 9I开始,到目前的ORACLE 12C。基本上免除了你们辛苦,而有细致调整各个功能池的大小。如今12C自动完成。

最小分配单位是64MB。


这样的人性化工做,很是适合JAVA开发人员了使用,之前须要专职DBA来完成的工做,如今要么JAVA开发人员搞,要么运维工程师来搞。基本上连上网,照着网络配置下,启动了图形界面后就一路向西去了!


终于不须要DBA了,老子天下第一! 十八武艺样样精通!


很显然作为专业DBA来讲,这话就咽不下去了! 那也没办法,咽下去,等你的数据库慢了后,再高价请我吧!! 哈哈。


专业DBA 一来 就PASS掉自动内存调整参数。


设置PGA多少,SGA多少。

SGA 中 DB_CACHE多少, SHARD_POOL多少,LARGE_pool多少,JAVA_POOL,STREAM_POOL多少。剩下的就交给SGA自动调整吧!


具体调多少,要参考上图 OLTP,OLQP,OLAP类型! 单机仍是RAC


通常来讲OLAP 须要大大的DB_CACHE。 而OLTP SHARD_POOL 就要不少,起码要跟DB_CACHE势均力敌。RAC当中的SHARD_POOL要超过DB_CACHE。


至于PGA+SGA 在整个内存的分配,通常参考80%系统内存! OLTP SGA>PGA 而OLAP PGA=SGA。


另外 数据库系统内存除了装监控代理好比说ZABBIX AGENT 外,禁止装其余应用程序!

好比说OEM或者说EM!



第四配置! 超线程


通常我是禁用掉超线程的。 超线程在PC  BIOS 里面禁止。

为何呢?

由于超线程,不是真的CPU内核,是利用CPU暂时空闲时间,虚拟的内核。

也就是在CPU空闲当中。利用它的空闲作其余的事情。并且当主活回来后,再还给它! 这里面涉及到了上下文切换。切换就须要时间,内存调度嘛!原本主活的数据保留在寄存器,一级缓存,二级缓存,乃至内存中。这下好了,被超线程给赶跑了,再把数据调回来就麻烦了。


因此超线程适合计算类型的应用。至于数据库嘛!你们都懂的,密集型IO操做!


第五章  六大禁止

第一禁止 禁止外键


第二禁止 禁止视图


第三禁止  禁止触发器


第四禁止  禁止存储过程


第五禁止  禁止JOB


第六禁止 索引


这六大禁止会带来不少性能隐患的,其中触发器就是特例,视图也会影响性能的,你说能够作成物化视图。


自从应用程序从C/S架构发展到B/S架构,而后在是水平扩展成多机器分布式集群架构。而以上的外键,视图,触发器以及存储过程都是C/S架构中的数据库为了实现企业业务逻辑的工具。之前企业和工厂数据库服务器都采用的是小型机器,好比现在的AIX操做系统必须运行在IBM的小型机上。而ORACLE+AIX+小型机是标准搭配。现在的ORACLE EBS系统依旧运行上面平台中。之前我的电脑性能不咋地,什么586,686,奔腾1-5估计你都没有据说过,都是单核CPU。因此当时就把大量的计算工做和业务逻辑也放在了数据库服务器上跑。


现在的WEB,云化的B/S架构,已经把业务逻辑移到了 TOMCAT容器或者是IIS上运行。使用的编程语言要么JAVA,要么是C#.NET。而数据库就充当数据存储的角色。数据对象就是表和索引,而对它们的操做就是SQL。除了这三样外就别无其它了。


曾经面试被问到业务逻辑放在哪端?你怎么看待存储过程的?当初经验缺少,不知道如何回答。虽而后来想了下,以为业务逻辑放在JAVA层,而存储过程只处理数据逻辑。也就是说存储过程一点都不涉及业务逻辑,只是GROUP BY  WHERE  SUM 掉大量的数据,返回少许的数据给应用层。虽然一直以为这是个完美的方案,各就其位,各尽所长,充分发挥各自的优势。然而如今想起这方案比较理想,你没法让开发人员又写JAVA中的业务逻辑,还要让他们写存储过程。那开发人员会没法区分业务逻辑写在哪里去了,或许那个实现方便,快捷就使用谁。或许两边都使用下,这样来业务就被拆分在两端了。


视图也是一段SQL代码,当初是为了屏蔽低下某些表给某些人看,或者是公共一段代码做为共享SQL。既然是SQL必然是业务逻辑的实现体,因此也要移植到应用层里去。


外键和触发器 现在JAVA开发人员已经取得了认识不在数据库端实现了。


关于JOB的禁止, JOB JAVA应用开发已经实现定时调度的功能,而且调度什么时候调度都是业务逻辑的考虑。



索引为何也有要禁止呢? 这是由于禁止开发人员去建索引,索引也归DBA使用的。由DBA负责创建业务所须要的索引!


OK !! 我小仙并无说真的在数据库上禁止这五个东西,而是说禁止开发人员去使用它们。这五个东西专属咱们DBA的,咱们DBA就能够使用这五个东西。由于咱们不会把业务逻辑写在存储过程,视图里面啊! 


不少人看到这里不少人就转不过弯来,他们想的是不让开发人员使用存储过程,难道叫DBA去写存储过程吗?这样不是累死了DBA吗?  有的人不认真仔细看上面的文字含义,或者他们大脑里先入为主的固有思惟限制了,看了也白看。才会问这些愚蠢的问题!


在这里我声明下,本优化新常态是针对WEB性的数据库应用,而不是第二代 服务型数据库应用。是第三代的WEB型和第四代WEB集团化型数据库应用系统。

在这里没有数据库开发工程师这一个职位。WEB开发人员和DBA。 DBA不开发业务的存储过程,视图,触发器,外键,物化视图。这些东西归DBA作运维方便而已,毕竟DBA不懂PHP,JAVA.C#等WEB开发语言。DBA懂PL/SQL语言,作些运维,作些统计,作些优化,天然使用PL/SQL语言和对应的工具,JOB,存储过程,视图,触发器。



第六章 急诊法

当咱们被数据库忽然慢的时候,这个时候不应作AWR报表!比如你是医院的急科的值班医生,当120拉来一名患者,而你要作的是当即判断病情所在。AWR不太适合急诊模式,阅读完它就要花费30分钟!因此咱们须要特殊的简单明确的方法,进行快速诊断,快速恢复生产,让用户继续完成业务,让老板有利润。


第一从系统上开始 TOP命令 以下

TOP命令不少LINUX都有,并且比较重要哦!读懂里面的意思是DBA必备良药。

第一 看第一行LOAD AVERAGE  超过1 就比较忙,越大越忙

第二 看第二行 TASKS 任务数 尤为是 RUNNING的数,通常平时的时候都1-2.恐怖的时候达到1000,说明并发量大,排队等候也大。

第三 看第三行 CPU 看目前的CPU消耗在哪一个领域。US表示应用,SY表示系统,WA表示等待(IO或者是网络)。经过CPU消耗在什么位置能够肯定哪里病了,是心脏仍是胃,还脑壳瓜子呢?

第四 看第四和第五行  大体讲的是当前内存使用状况和SWAP内存使用的状况。

第五 下面的进程活动列表,动态变化的,通常都是按CPU使用率变化的。若是排在顶部的大部分是ORACLE进程,说明是数据库发生了问题。


从TOP命令不能精确判断出来, 不过能了解到是什么消耗比较严重 是IO仍是CPU 尤为是第三行。大体判断出是系统出了问题仍是数据库出了问题。


VMSTAT 命令

因为CENTOS 6带的VMSTA输出格式对齐不咋地,看起来有点不舒服。

重点是看PROCS 的R B两列和SWAP的SI SO两列。

R B 表示运行队列的进程数和阻塞的进程数。 R表明运行进程,B表明阻塞进程。SI SO表示交换内存的进出数量。

VMSTAT 主要用来判断是非发生了交换内存的频繁大量的交换。

下图是ORACLE LINUX 6 的DSTAT命令 你们看下友好性特别的好。

第一组表明的是CPU;

第二组表明的是磁盘IO状况;

第三组表明的是网络状况;

第四组表明交换内存状况;

第五组表明系统状况;Int 中断,CSW上下文切换


到这里咱们结束了系统方面的急症了。从上面两个命令能够肯定病情集中在CPU,内存仍是IO方面。假如CPU 内存 IO 都很正常那就是说系统是没有问题的,问题在数据库上面,起码数据库慢的问题没有体如今系统指标上。说明病情不严重。


ORATOP命令 

这个命令是ORACLE公司开发的小工具,变化挺大的。

第一行和第二行,有些我也不懂,主要是变化太大了,每一个新版本都不同,另外仍是英文缩写,没有长格式的,都是80列的格式的。

重点看EVENT ,这个就是及时性的TOP五等待事件。这样咱们就知道数据库是否发生了严重的等待。好比上图正常状况下是DB CPU占比较多的DBTIME。

若是是下面 LOG FILE SYNC和DB FILE SEQUENTIAL READ 等待事件排在第一或第二位 那就说明IO争用很厉害。

关于小工具看下面连接 ==》ORATOP小工具


接下来就是TOP-SQL了 一眼望过去大部分列都懂,除了E/T STE W/T外。

经过TOP-SQL 你能够内心有普了,知道这些家伙了。你能够KILL了它们。不过要在SQLPLUS里面发不KILL SESSION命令 另外还有手动去查出来。虽然给了SID 和SPID。

也能够在系统上KILL -9 命令,不过也要经过SQLPLUS查出系统ID来。仍是有点不方便。


视图      V$SESSION_BLOCKERS

这是个回话阻塞视图里面包含了以下字段

SID

SESS_SERIAL#

WAIT_ID

WAIT_EVENT

WAIT_EVENT_TEXT

BLOCKER_INSTANCE_ID

BLOCKER_SID

BLOCKER_SESS_SERIAL#

分别意思是 回话ID,回话序号,等待ID,等待事件,等待事件文本,阻塞实列ID,阻塞回话ID,阻塞回话序号。

这个视图若是只有一两行还比较给力,若是是几百行的话,就不像话了,一点都不给力。尤为是急症下,上百行阻塞回话,它们之的上下级关系,阻塞连。我写个START WITH相似的树下结构的语句,发现也不行,反而产生更多的行,从原来几百行变成了几千行。也没有机会去调试SQL,毕竟发生阻塞的时候,你必须干掉它,因此就没有机会了。只有截图回来分析下。

另外该表只有这几列字段,显然信息量是不够的,尤为是在急症状况下。必须有等待者的SQL语句,阻塞者的SQL语句,阻塞者的等待事件。

为此我整了个大SQL,不过不太理想


SELECT LEVEL AS LEVEL_NUM,

B.SID AS "会话ID",