ORACLE优化.docx
- 文档编号:3876943
- 上传时间:2022-11-26
- 格式:DOCX
- 页数:14
- 大小:308.63KB
ORACLE优化.docx
《ORACLE优化.docx》由会员分享,可在线阅读,更多相关《ORACLE优化.docx(14页珍藏版)》请在冰豆网上搜索。
ORACLE优化
小余买鱼与ORACLE优化
梁敬彬
1.1优化方法论
1.1.1小余买鱼系列故事
小余买鱼1---诊断与改进
全文就从一个生活中的小故事开始吧,故事的名字叫:
《小余买鱼1》:
一天下午4点多,小余妈妈想做水煮活鱼给家人吃,让小余去买一只草鱼回来。
小余骑自行车到20里外的沃尔玛超市买到鱼然后返回。
一到家,妈妈就开始责怪小余买鱼的时间花的太长了,因为都已经是下午6点半了,晚上7点一家人都安排好了外出的活动了,这下做水煮活鱼来不及了。
。
。
。
。
《小余买鱼1》说完了,好听吗?
(喂,兄台,别砸别砸,鸡蛋很贵的。
。
。
。
。
。
)。
虽然看上去这个故事似乎既没内容又不精彩,但是在我看来,ORACLE的优化思想、方法论却在这个小故事中展现的淋漓尽致。
你看出来了吗?
不明白?
让我们慢慢展开分析。
很明显妈妈对小余买鱼的工作效率不满意(导致她做鱼的时间都没了),问题出在哪呢?
小余是个聪明的孩子,善于思考,这次挨批后,他想好好反省总结一下,避免将来再犯同样错误而再次挨批。
他想诊断环出问题出在哪个环节,为此他得先思考具体都有哪些环节,这就是:
将过程细化
小余回想买鱼经历后,将整个买鱼过程做了细化,具体哪些环节马上出来了:
1.骑车来回往返
2.银行排队取钱
3.在超市里找买草鱼的地方
4.其他时间开销(如取自行车、停车、接电话等等)
接下来他很自然的将思绪飘落到如下之处:
找细化项主要矛盾(开销最大的部分)
依次分析各细化项的开销:
1.骑车来回往返花费90分钟
2.钱不够,去银行取钱排队花费了20分钟
3.在超市里到处找买草鱼的地方,这些动作花费了20分钟
4.其他时间花费了(如取自行车、停车、接电话等等)。
5分钟
小余猛一拍脑袋,重大突破来了,主要时间开销在买鱼往返途中,主要矛盾在这!
如果能大幅度缩短往返时间,必然能让妈妈少等许多时间。
小余接着开始考虑怎么优化改进,从而解决问题。
他脑海瞬间闪过一点:
妈妈让我做什么事?
这就是:
准确理解需求。
妈妈的需求是什么呢?
一句话:
需要买来草鱼做晚餐。
妈妈并没有要求小余一定要在哪买鱼,只要能买到,就满足妈妈的需求了。
小余意识到自己犯了一个很低级的错误,他缺乏下面一个意识:
尽量少做事甚至不做事完成需求。
在妈妈没有要求在哪买鱼的情况下,小余去了20里外的超市买鱼,小余忽然觉的自己是不是有点傻了。
20里外的地方是他学校,平时上学时他留意到附近有一家大超市,同时他无法确定自己家附近是否有可以买到鱼的超市,这正是他要去如此远的地方买鱼的原因。
如果家附近能买到鱼而选择去20里以外的超市买,不是多做事完成同样的需求了?
小余意识到明确自己家附近能否买到鱼,将是处理问题的关键!
经过自己的调查研究,他发现自己家附近真有可以买到鱼的农贸市场,虽然农贸市场很小,但是不影响自己完成买鱼的任务,专业的说法是,并不影响需求的实现。
他开始特别懊悔自己预先不问问妈妈或者其他知情人,否则这90分钟的往返路程可是完全可以缩短为几分钟哦。
一周后妈妈又要做水煮活鱼了,小余就在楼下附近农贸市场买了鱼,这次他没再让妈妈等太久,妈妈对小余买鱼的效率非常满意。
到此问题圆满解决了,小余冷静思考生活中的小事,总结出了诊断问题和解决问题的方法论如下:
小余成长了许多!
生活和技术是相同的,生活如此,ORACLE优化也是如此!
小余买鱼2---需求与设计
下面,我们描述第二个故事,《小余买鱼2》:
一个月后,小余妈妈又准备开始做水煮活鱼了,妈妈还让小余去买一只草鱼回来。
不过这次情况发生变化了,家附近的农贸市场因故关闭了,由于住的比较偏僻,还真的只能去20里外沃尔玛超市买鱼了。
如果是以前,小余必然就是直接兴冲冲的一头冲出门,帮妈妈买鱼去。
不过经历过第一次买鱼的经历后,他学会了思考,变得更成熟了。
。
。
。
。
。
。
(以下略去3000字。
)
“妈妈,我回来了!
”妈妈看到小余提着鱼,连连称赞,非常满意。
《小余买鱼2》说完了,好听吗?
(喂,大哥,别砸别砸,鸭蛋比鸡蛋更贵啊。
。
。
。
。
)
我把这个故事说成悬疑小说了,也难怪读者急了。
故事说完了,读者还有很多疑问,咋办?
好吧,我还是代表一下广大读者,亲自采访一下小余本人,以下是精彩的采访片段:
“你好,小余,很多读者都急切想知道你第二次买鱼做了哪些改进,可以让你妈妈那么满意的,谢谢!
”
“很乐意接受你的采访,谢谢!
对了,我第一次买鱼失败经历后做了一些总结了,你知道吗?
”
“小余,你考我啊,我还记得。
你是把握了诊断和优化改进两个方向。
通过问题细化和抓重点这两个方式,诊断出需解决问题的环节,然后结合理解需求和少做事原则,发现了舍近求远买鱼这个主要错误,水到渠成得出就在家附近买鱼这个改进方法。
是这样吧。
”
“非常不错!
”小余忍不住赞了一句。
“不过诊断是用在出问题的场合,我这次买鱼从头到尾都很顺利,也就不需要有诊断了。
”
“小余,可是这次情况有变化了,你家附近农贸关闭了,你只能去20里外的老地方买鱼了,你还能有啥好方法啊?
”
“优化方法论是诊断和优化改进两部分组成的,如果优化改进考虑非常周全让一切都进行的很顺利,诊断就会因为无用武之地而变成是多余的了,但是优化改进的思想却断然不存在多余的场合!
经过上次失败后,我不断思索改进,现在我的想法比第一次总结的思想更全面合理了。
”
“小余,你有比第一次总结更更全面合理的想法?
太好了,说来听听。
”
“主要改动在于,我认为改进优应该从两方面着手:
1是理解需求,2是设计。
具体看我画的草图如下:
其实我第一次买鱼失败还有另外一个重要原因在于:
无法准确把握隐藏的需求。
这个隐含需求就是:
妈妈没要求多长时间买回鱼,这个时长留个我们自己去判断。
不过很明显超过到下午6点多肯定是不合理的,因为耽误了吃晚饭。
当然除了自己判断我们也可以去问妈妈多长时间合适,因此我把理解需求细分出表面需求和隐藏需求。
这次买鱼我问了妈妈具体需要多长时间,答复是下午4点出发,争取在5点前回来。
哇,去同样的地方做同样的事情,要135分钟缩减到60分钟?
任务该不该接下来呢?
好好设计规划是必要的。
上次仅往返途中就用了90分钟,必须先解决这个问题。
我首先想到是否有近路去同样的目的地,并当即求助于对门邻居的士司机老王,他告诉我从刚开通的跨江大桥到沃尔玛超市,可以缩短一半以上的路程,并且答应陪我一起去。
恰好我爸爸出差没用车,我这次让老王帮忙开爸爸的车子同去。
原先的自行车走远路改为开车走近路的规划后,我们预计路上往返30分钟时间就够了(事实果然如此)。
根据之前的经验,银行排队花费了20分钟,这个完全没必要,这次带足钱去了。
而超市买鱼时找买鱼花费了20分钟,也不应该,我之前居然没注意到其实超市有标识分类,如:
生鲜区、副食品区、用品区、水果区、服装区等等。
买鱼可以直接进生鲜区查找,接下来在生鲜区找到水产品区,在水产品区中再找到鱼类区,草鱼就买到了,大大缩小了找鱼的范围。
规划好后,觉得60分钟完成任务没问题,就愉快的答应去买鱼了,最后圆满完成任务!
”
“太精彩了,受益匪浅,多谢你,小余。
”
采访结束了,大家是否觉的很精彩,受益匪浅。
小余我们来用下面这个完善改进优化的图表来结束《小余买鱼2》的故事吧,如下:
小余买鱼3---资源的利用
又过了几天,妈妈再次让小余去买鱼,这次楼下附近的农贸市场开放了。
小余没能摆脱上次买鱼延续的思维惯式,选择让表哥帮忙一起开车去买鱼,结果到地下车库开车、到了农贸找车位停车,花费了大量时间,导致比走路去时间还花费更多。
这就是要注意什么场景选择什么样的处理方式(从技术角度来看就是什么时候选择什么技术)。
也就是上图中设计的第2点的再次强调,这是非常重要的。
事实上事情其实还更糟,小余买鱼这时间爸爸正准备去公司参加紧急会议,结果车被开走了,最后导致会议迟到了。
爸爸迟到这个事和上图设计中的第3点的相关:
善于合理利用资源。
之前一来爸爸去出差了,二来买鱼的路途遥远,当然要合理利用资源。
而情况变化后,就要及时考虑清楚了,车开走了,别人需要怎么办?
你事先沟通过了吗?
你想过了吗?
《小余买鱼3》说完了,好听吗?
(哈哈,看来这个故事很精彩,没人砸了,啥,说啥?
有人去买蛋了?
没明白您啥意思。
。
。
。
。
)。
《小余买鱼3》没有新的输出图,故事只是《小余买鱼2》的一个补充和说明,请读者们回过头好好看看《小余买鱼2》中的图表吧。
小余买鱼4---真正的需求
又过了一个月,妈妈又准备让小余买草鱼来招待刚上门做客的大舅了,不过因为离晚饭时间很近了,妈妈希望能在20分钟内买好鱼,而此时家附近的农贸市场依然没有开张,小余判断,无论如何都不可能完成这个任务了,不过小余还是开动了脑筋。
最终居然让妈妈满意的点点头。
你们谁能猜到小余做了什么事吗?
我估计谁也猜不到这次小余怎么让妈妈满意了.让我来直接公布答案吧。
答案就是:
最终小余让妈妈别买鱼了,用冰箱里的牛肉做水煮肉片。
《小余买鱼4》说完了,好听吗?
(喂,老弟,老弟,你干嘛,别冲动。
。
。
。
救命。
。
。
。
)
其实这次小余很不简单,居然让妈妈改变了需求,从买鱼改为了直接用冰箱里的肉。
其实小余是真正成长起来了。
他并没有帮妈妈改变需求,而是帮妈妈一起发掘了真正的需求!
妈妈的真正需求并不总是买鱼,而是要展现手艺,和家人共享美味。
从这个角度来看,水煮活鱼和水煮牛肉是一样的,大舅对妈妈擅长的水煮牛肉和水煮活鱼是同样感兴趣的。
鱼很难在规定时间内买回来,而牛肉就在冰箱。
真正的需求已经从“我要买到鱼做水煮鱼”的表象转化为“我要做美味和家人分享”。
小余再次让妈妈满意了。
这个故事其实很重要,在后面的优化中将会有不少落地的案例来说明。
这里看来对设计中的理解需求做了完善,应该有一个“理解真正需求”,具体见下图:
1.1.2买鱼买出方法论
1.1.2.1一套流程
至此可以用一套完整的流程图来暂时结束《小余买鱼》系列故事,此套流程概括了本文全部精华思想。
浓缩了笔者多年的调优心得,该图内容将在后续的描述中被不断印证!
1.1.2.2两大法宝
上述总结的一套流程从小余买鱼系列故事演绎推理出来,从诊断和改进优化两个分支徐徐拉开优化方法论的序幕,形成了本文最宝贵精华部分。
此外任何事物都可以多角度看待剖析。
我们还可以将买鱼的事情分成意识(非技术能力)和技能(技术能力)两部分。
在我们看来,这是优化的两大法宝。
此话怎讲?
让我细细道来:
小余思考自己买鱼具体经历了哪些环节、最长时间耗在哪个环节、楼下是否有鱼、如果一定要去某处买鱼是否有近路、自己银行排队取钱能否避免。
。
。
。
这些都属于意识类的,和具体的技术能力无关。
小余买鱼过程中曾经骑自行车去买、也曾经开车去买鱼,无论是开车还是骑自行车,都不是一生下来就会的,必须经历过训练学习才能掌握,这就是技能类。
生活中的优化就是意识和技能的结合,两者都非常重要。
首先说技能,掌握技能的重要性毋庸置疑,就比如要到很远的沃尔玛超市买鱼吧,你既不掌握开车的技能也没学会骑车的本领,想而靠走路到达目的地,那估计到达时店铺也打了吧。
接下来谈意识,生活中有不少场景甚至是仅靠意识而未使用特定技能最终解决问题的。
比如小余直接去楼下买到鱼了,还需要考虑会不会骑车吗?
再比如小余让妈妈改做水煮牛肉了,还需要掌握开车的本领吗?
(喂,你这是去哪?
啥,要去买正规的ORACLE优化书。
。
。
正规?
)
1.2方法论应用案例
好吧,不说故事了,和大家分享点工作中的数据库优化经典案例吧(啥,你说啥?
你终于听到高级的了?
哦,说案例就高级,讲故事就低级啊。
。
。
。
)
某电信营运商生产系统出现故障,短信平台产生大量积压,维护人员跟踪发现,原因是后台短信平台进程调用数据库中某个过程包,而该过程包原先执行返回结果给后台进程在10秒以内,现在不知是何种原因过程包返回时间居然长达1分钟,所以导致短信后台程序处理缓慢许多,最终造成短信积压。
情况紧急,需要立即着手调查,该怎么处理呢?
亲爱的读者,如何处理你心中有数吗?
如果你读懂《小余买鱼》,你就应该很有信心来解决这个故障,优化这个系统,成为大家心目中的英雄!
不信?
让我接着往下讲吧。
该如何优化这个系统呢?
好吧,祭出秘密武器:
优化方法论!
该方法论由买鱼故事演化而来,旗下有两大精髓,又称作八字要领:
一套流程、两大法宝!
(啥,叫我别吹牛了,讲实在的?
还不实在啊,好吧,接下来让你好好看看实在不实在….)
忘记前面总结出的方法论的读者,请自觉翻回上小节再仔细阅读三遍。
根据总结的“一套流程”,我们自然想到,优化的这套流程主要分为诊断和改进优化两个环节,由于现在还不明确问题出在该数据库包的哪个模块?
因此进入诊断环节是必要的,然后根据诊断定位出来的具体问题,再进行具体的优化。
1.2.1一套流程
1.2.1.1诊断
模拟后台调用该包的时候传入的参数手动执行该包,然后开启ORACLE的TRACE跟踪工具工具,该过程包执行完毕后关闭跟踪,具体步骤大致如下:
1.用10046trace工具开始跟踪
altersessionsetevents'10046tracenamecontextforever,level12';
2.执行你的数据库包
execpkg_test(‘abc’);
3.执行包完毕后结束跟踪
altersessionsetevents'10046tracenamecontextoff';
4.10046trace工具跟踪完毕后会输出分析结果,类似如下:
E:
\admin\ora10\udump\ora10_ora_4832.trc
5.可格式化后进行分析,类似如下:
tkprofE:
\admin\ora10\udump\ora10_ora_4832.trcd:
\10046.txtsys=nosort=prsela,exeela,fchela
6.然后分析10046.txt的文件,这里响应时间从大到小展现该包所有SQL语句,即可有如下收获:
6.1该过程包总共执行了多少SQL语句,具体内容是什么,分别开销了多少时长
6.2哪些是开销时长最长的语句。
(由于有排序过,所以最长的一眼可看出,在最前端)
咦,这和《小余买鱼1》中的诊断方法有差别吗?
还真是过程细化和找细化项主要矛盾两个动作啊。
接下来分析10046.txt文件发现,原来慢的SQL是类似如下的两条非常简单的SQL,分别占用30秒和20秒,其他所有SQL单条执行都只零点几秒。
语句1(SQL1耗时30秒)
Selectcount(*)fromt1;
语句2(SQL2耗时20秒)
Selectdistinctt1.col1,t1.col2,t2.col3,t2.col4
fromt1,t2
wheret1.id=t2.idandt1.name=’cc’
orderbyt1.col5;
其他SQL语句(合计才消耗0.5秒)
----SQL3(0.03秒)
----SQL4(0.028秒)
----SQLn…….(0.001秒)
--略去
1.2.1.2改进优化(首次优化)
通过分析可以知道,SQL1和SQL2是重点需要改进的SQL,首先分析SQL1,该如何改进优化呢?
如何改进优化?
根据小余买鱼的经验,我们知道要先去理解需求,这条SQL背后的需求是什么?
看上去并不难猜测,就为了查询T1表的记录数,毕竟Selectcount(*)fromt1;这条语句太简单了。
开始介入分析,通过查看该SQL的执行计划可以知道,该表T1是进行全表扫描。
(查看执行计划和10046TRACE一样,是一个非常重要的优化工具)
该表记录目前有5千万,每次都对全表进行扫描仅为了获取该表的记录。
我们的需求是为了得到记录数,是否一定要对全表进行扫描呢?
就好比小余要去买鱼,是否一定要去20里外的沃尔玛超市呢?
就好比小余需要具备了解自己住宅周围是否有地方买鱼这个生活经验一样,这个案例我们也需要多了解点相关知识,啥知识?
这里需要读者对ORACLE索引有比较深刻的理解。
通过全扫描数据表可以获取到该表有多少记录的信息,如果对该表存放序列值的非空字段SEQ_ID上建一个索引,全扫描该索引,一样可以获取到该表有多少记录的信息。
看来,获取表记录数可以有两种方法了。
选那种方法呢?
大家知道,索引的大小比表大小小的多,在更大的范围内遍历更快速还是在小的多的范围内遍历更快速呢?
好比买鱼是到远方的沃尔玛还是楼下的农贸商场买鱼那种更快一样,答案毋庸置疑。
接下来我在T1表的SEQ_ID这个非空字段上建立一个索引,Selectcount(*)fromt1;的语句执行计划从全表扫描转换为索引全扫描。
由于该表字段很多,而这个SEQ_ID字段又仅占10个字节,索引大小仅为表大小的三十分之一。
从大范围找答案改为小范围找答案后,意味这我们达成同样的目的,少做了不少事情。
如此下来该SQL执行速度当然会有大幅度提升,果然,最终执行速度从原来的30秒变为1秒左右。
看来学习优化还真是和学习买鱼一个道理,顺利优化了SQL1就等于完成了工作的一半,继续努力。
接下来进行SQL2的调优,和优化SQL1时一样首先开始查看分析SQL2语句的执行计划,发现SQL2的执行计划也是全表扫描,这里t1.name=的取值为cc的返回仅仅10条记录,而T1表记录都在5千万左右,T2表在200万左右,需要全扫这么大的两个表而获取仅有的10记录吗?
这里又要再次利用到索引的原理,SQL1是利用到了索引一般比表小的多的特点,现在又是要利用啥呢?
哦,利用索引的快速定位原理。
假如我们在name列建了一个索引,而现在是利用了索引的快速检索原理。
索引有个最大的特点是有序排列,当表记录检索到dc等以d打头的记录后,ORACLE就停止遍历了!
为啥,因为索引是有序的,当出现d打头的记录后,绝对后面不可能再出现c打头的记录了,因为我们是查询=cc的值,当然停住了。
随时停止检索相比遍历全表,明显是少做事和不做事,效率可以意料会提升不少。
那SQL2如何优化,哦,好简单,就是在name列建一个索引就好了。
索引在这条SQL中因为可以让应用少做事和不做事,最终到了速度大幅度提升,果然,优化后的执行速度从原来的20秒缩减为1秒。
到此优化完毕,短息后台进程由原来的每次执行1分钟多变为2秒多,速度提升了30多倍,积压情况大大缓解,系统运行恢复正常。
应该说这次优化总体是很成功的,客户也非常满意。
不过我个人心中还是有少许疑惑之处,什么疑问呢?
1.SQL1(Selectcount(*)fromt1)为什么要统计条数,得到条数的真正目的是什么?
2.SQL2中的distinct取唯一值是为啥,难道表有重复记录?
distinct可是需要排序的。
3.SQL2中的orderbyt1.col5;排序是T1表的col5字段,展现字段又没有这个字段,真的需要这个排序吗?
1.2.1.3需求与设计(再次优化)
遇到疑问最重要的就是,去理解需求是什么?
真正的需求让我大吃一惊!
原来该SQL1的语句在过程包中的代码是类似如下的:
begin
selectcount(*)intov_cntfromt1;
ifv_cnt>0
then…A逻辑….
else
then…B逻辑…..
End;
因为这条selectcount(*)fromt1执行的偏慢,所以被10046TRACE给追踪到了,但是这个逻辑真的需要这么实现吗?
我来翻译一下这段需求,获取t1表的记录数,判断是否大于0,如果大于0走A逻辑,否则就走B逻辑。
因此代码就如上所示来实现了。
真正的需求是这样吗?
其实应该是这样的:
只要T1表里有记录就走A逻辑,否则就走B逻辑。
两者有区别吗?
其实区别还是很大的,前者可是强调获取记录数,我们是不是一定要遍历整个表得出一个记录数才知道是否大于0?
真正需求的理解可以让我们这样实现,只要从T1表中成功获取到第一条记录,就可以停止检索了,表示该表有记录了,难道事实不是这样?
因此原先的SQL1从Selectcount(*)fromt1;被改造为Selectcount(*)fromt1whererownum=1;速度从1秒提升到0.01秒,几乎可以忽略不计了。
这里我们马上联想到《小余买鱼4》,妈妈真正的需求其实是要做美味的晚餐,站在这个角度,完全可以用现成的其他菜来代替非常麻烦的买鱼经历,少做事甚至不做事而快速满足需求,提升效率。
对于SQL2,我查看了T2表,发现真有大量重复记录,怪不得需要用distinct来排重。
我很奇怪为什么会有重复记录,在问明开发设计人员后,我明白了,原来是源头程序有漏洞,导致t2表出现大量重复记录,现在所有的应用只要涉及到访问t2表的,都需要增加distinct关键字来排重!
天啦,居然还有这回事!
还有更神奇的,关于此处的orderby,居然是多余的,展现的几个字段的输出根本无需排序,没有这个需求!
接下来思路很简单,就是优化了源头程序(另外一个数据库包),保证插入t2表的数据再也不会有重复记录,然后再把t2表记录进行删除重复记录的操作。
后来t2表的记录从原来的500万缩减为20万,最难得的是,distinct语句可以去掉了(因为不会有重复记录了),orderby也去掉了(因为根本没有顺序展现的需求),现在T2表不但记录数变小了,排序也都避免了,结果SQL2也由原来的1秒优化为0.01秒,也快到几乎可以忽略不计了。
现在后台短信进程调用该过程包,需要总时间还不足0.1秒,比起以前成百上千倍的提升,这次优化终于取得了圆满的成功!
最难能可贵的是,很多和这个后台短信进程无关的别的应用也快了!
咦,很奇怪吗?
其实不奇怪,因为只要是访问t2表的应用都少做了两件事,第一是不再需要增加distinct语句来去重了,避免了排序。
第二就是以前访问t2表是大表,现在是访问小表。
1.2.1.4资源利用(花絮)
读者还记得我说的T2表排除重复记录的事情吧,我当时提供了技术方案给维护人员,方案是新建一张表出来,提取不重复记录,然后把旧表替换了,大致思路如下:
1.首先建立新表
Createtablet2_newnologgingparallel12
Asselectdistinct*fromt2where…..;
2.停应用
3.Renamet2tot2_bk
4.Renamet2_newtot2;
5.补上t2表的相关索引,并将t2表的logging属性恢复。
我之前有提醒是要在业务不繁忙的时候操作,比如凌晨打补丁的时候顺道操作。
因为我有写了parallel12,表示要并行用到12个CPU。
(而当时生产仅有12个CPU)。
可惜的是维护人员自作主张,在大白天系统繁忙的时候执行了上述语句,结果导致12个CPU资源被这条createtablet2_new的语句占据消耗着,引发生产系统短时间的压力繁忙,险些压垮了系统,好在该语句在5分钟内结束,未造成严重的影响。
亲爱的读者,这个花絮让你们联想到什么吗?
应该是《小余买鱼3》吧,小余不会合理利用资源,开车去楼下附近农贸市场买鱼,导致要去远方开会的爸爸没车开,迟到了。
当然《小余买鱼2》却是会合理利用资源的典范,爸爸去出差了,要去那么远的地方,不选择开车去就是傻瓜了。
如果维护人员按我的要求在凌晨打补丁的时候顺便执行这个语句,不用并行也是不善于利用资源,因为凌晨系统没有什么进程在运行,不会有应用因为CPU被占用光而收到影响。
1.2.2两大法宝
还记得前面《小余买鱼》故事总结的买鱼方法论中的“两大
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ORACLE 优化