首先，我对Oracle不了解，我自以为能看懂。哈哈，因为oracle里面太详细的东西我就不专门说了。这部分内容比较笼统，可以参考。我会将这些想法结合到我的平台中。总之，我有了物资之后，就加上时间和精力，就像阳光、空气、水一样。ppt的一部分是我在一次InfoQ会议上做的简单分享。今天在原来ppt的基础上重新解读了一下。这些是我眼中的一些问题。一些预言机已经做得很好了。对于一个成熟的商业软件来说，虽然功能令人满意，但还是有一些值得改进的地方，或者说还不够好。这也体现了处理问题的几个阶段。有的人头痛止痛，有的人能提前发现问题，有的人能更早避免问题。从这个层次来说，层次越高，就越尴尬。因为问题根本没有发生就扼杀在摇篮里，价值很难体现，会很尴尬。有一个关于扁鹊的故事。我没有核实来源，但它可以说明问题。用扁鹊的话说：“我大哥医术高超，可以防患于未然。人的病还没有发作，看脸色就知道，然后用药治病。”，所以世人都认为他不会治病，就没有名气。感冒咳嗽，他用药治好了，所以我二哥的名气只止于村里，也算是治小病的医生，因为他的医术是最差的。所以一定要等到这个人病入膏肓，奄奄一息，再下虎狼之药，起死回生。这样，全世界都会认为我是神医。想想看，当我大哥像这样治疗疾病，t人的元气丝毫没有受损。我二哥治病的时候，这个人元气稍有损伤就会得到补充。他获救，但元气大伤。你说，咱家谁医术最好？所以对于运维来说，说实话，有时候我什至希望他出一些问题，让他能够被大家重视。我对此深有体会。我的初衷是希望大家能遇到更多的问题，解决更多的问题。三观必须正确。说了这么多问题，我们来看看Oracle优化工具定制跟这个有什么关系。我们先来看看Oracle的优化工具。如果您没有听说过也没关系。你可以想象这样一个场景。有一个数据库。清晨某个时候CPU负载突然增加，导致业务拥堵，引发一系列问题。如果你是DBA，如何思考和应对。假设你上午10点到公司，问题发生在凌晨2点，如何诊断分析这个问题。因为对于数据库来说，故障状态已经过去了，如何及时捕捉到那个时间点的问题，这个词早年会经常提到，就是诊断。我们必须分析这个问题。如果是在oracle9i版本，简直就是噩梦。我知道早期的阿里DBA遇到这种问题很痛苦。如果凌晨2点出现问题，如何修复它。那就是2点多守在电脑前。有同学说这个方法太low了。oracle有statspack啊。确实有这个工具，但是问题很可能是求平均。比如数据库的负载在一个小时内是1%和100%。如果平均值是50%，这个问题就被平均化了，会挡住太多的问题，屏蔽不等于解决。所以，我说的最基本的工具是AWR，它可以监控数据库的整体负载。周期可以从半小时到一个小时不等。这样的缺点是显而易见的，过一段时间你才能发现问题出现了。甲骨文在此基础上进行了相当大的改进，是在这方面远超MySQL的工具。ASH.ASH简称神器。它会在后台收集信息，频率为1秒。因此，我们可以将问题诊断到第二层。这对性能有很大影响吗？肯定有，但是非常非常低。ASH的一个缺点是不能关联一些详细的信息，因为它只抓活动会话，有些信息是拿不到的。所以不能说它是万能的，但是从另一个角度来说，造成的问题大部分都是活跃会话。所以这个覆盖率基本够用了。说完AWR和ASH，再来看看ADDM。大家都知道Oracle现在的版本是12c，12cr1是6年前发布的，12cr2是DBA们公认的稳定版。大家等这个版本已经等了6年了。关于。这对于Oracle和众多DBA来说是难以描述的尴尬。所以Oracle必须意识到这个问题。这方面我估计跟SQLServer类似，就是一年一个版本，会削弱大家对版本的敏感度，所以今年会推出18c，也就是说，自治数据库，会有19c，20c（这个是真的）有同学说oracle是自动优化的，是不是oracledba有什么问题，其实不是，太简单了。oracle不能一次launchone之前没有的，12c有cdb，相当于搬了一座建了30多年的大楼的地基，来打造一个自治的数据库。这是一个很大的变化吗？其实我们仔细看就会发现，这些其实都会变成自治的数据库。一些关键部件。而这些预言机已经有了一些自动化的解决方案。因此，自动诊断（ADDM）和SQL自动优化建议（SQLTuning、SQLMonitor、SQLprofile）都是迭代完成的，引入更加动态的处理方式，不断完善。即便如此，这些优化工具在我看来仍然是半成品，因为它们使用起来仍然不是很愉快。所以我想办法想办法做一些改进，即使原来的步骤需要3次手动操作，简化到2次，我觉得也是一种优化。这里需要大家注意的是，在定制的时候，需要明确一个尺子，就是解决一个问题，解决更多的问题，还是带来更多的问题。做一件事，能够交流想法，我觉得如果你做Oracle，MySQL，或者其他数据库，会有很大的帮助。我们来看看生成AWR报告的步骤，就像大家去医院一样，先抽血（这里可以叫采样），生成验血报告（AWR报告），然后医生看是哪个指标高和哪个指数低，很相似。说到这里，我想提一个人，那就是张晓明，他真的是一个博士，后来转到了oracle。生成awr报告的步骤如下：我列出了五个步骤，也就是说这五个步骤都需要人工干预。你可以想象如果你有50个数据库会有多痛苦。感觉就像班主任或班级里的孩子。您不能一一聊天和交谈。我们只需要掌握整体状态，然后更新帮助大家解决问题（性能故障的数据库）。以前处理性能问题，每天都要生成大量的报表，最后实在是受不了了。要看懂这个优化定制，就得了解它的实现原理，所以我决定对它进行改进。AWR的脚本调用关系如下。其实，如果我们了解了调用关系，就可以看到有针对性的可以改进哪些地方。awrinput.sql负责输入参数，awrinpunm负责参数的名称，问号的地方是重点，它的实现是下面列出的一个包dbms_workload_repository，所以这里我们看一下AWR的实现原理，用这张图，ADDM，AWR，ASH可以看个大概。简单的说，Oracle从内存层面抓取一些数据库变化，然后通过MMON后台进程配合，将数据写入快照。快照级别的性能差异是AWR报告，而ADDM是快照级别的数据库。分析，ASH略有不同。了解了这些之后，我们就开始工作吧，我们会明确定制化的方向。不是一口气吃掉一个大胖子，也不是写出惊天动地的大作，会用，能满足需求就够了。那么问题来了，我们在定制AWR的时候，还有一些事情要做。快速拿到AWR有什么意义？为什么要阅读这份AWR报告。如果你想了解这个问题，那比你忙着定制它要好得多。主要是因为这个，DB时间，我觉得是看AWR最重要的一个指标，没有一个，没有这个参考，其他的数据库就没有意义了。如果想看正式的解释，可以看这个解释，看不懂也没关系，略过即可。我们的方向明确之后，定制就很容易了。我们可以自定义输入参数，可以完全预生成。比如你拿到这样一个列表，你可以很清楚的看出在哪个时间点性能高。我不需要生成所有的快照报告，所以我后面要达到的状态就是上班，看看dbtime的值。生成awr报告，不然不用太在意，怎么办。剧本其实很简单，把痛点说清楚了，剧本也很短。其实需要的话会转化成，DB时间高不高，高了就会产生awr报告。否则不生成。脚本可以在这里下载，https://github.com/jeanron100/dbm_lite另外提到了awr格式。一个DBA如果有很强的前端开发能力，战斗力是惊人的。awr格式是由DBA开发的，可以将awr报告进一步细化。awr部分居然占了80%的笔墨。如果自定义ash，addm就很自然了。我会和大家一起去驾校考驾照。前8课都是练感觉，后面两课很快就能学会。ash的定制也是类似的思路，比awr简单。只需输入两个时间戳。自定义ADDM需要一些pl/sql的基本知识。它会调用pl??/sql中的几个进程来创建优化任务并生成优化报告。我们仍然可以动态绑定一些参数来完成它。补充一下ASH的原理图。这对大家理解ASH很有帮助。这些数据分为两部分，一部分放在磁盘上，另一部分在缓存中。所以如果一个数据库宕机了，很可能cache级别的ASH会因为没有磁盘而丢失。此类问题更难调查。这方面需要我们在监控的细节上做更多的工作。SQL优化的部分内容就更多了，辛酸泪满满。由于时间关系，先分享到这里吧。下面我继续补充一些SQL定制的尝试，也算是一个介绍吧。如果再细分的话，可以分为这四类。怎么理解呢？ADDM会根据快照级别分析潜在的SQL问题。他只会分析告诉你某个SQL执行很耗时，可能有问题，但不能告诉你怎么优化。而SQLTuning是这方面的专家，他会告诉你哪些SQL有潜在的问题，是时候加索引了，是时候调整统计信息了等等。但是目前SQLTuningAdvisor比较受诟病，因为根据我们的实践，在大多数情况下，它给出的分析并不是很可靠，我说这话的时候Oracle可能不高兴。为什么，因为有些表的设计是基于业务的，我也知道加索引对这个SQL有帮助，但是其他的SQL，从设计的角度来说，这个工具不能做drill-down，如果可以，那么DBA的位置处于危险之中。所以我最喜欢的工作方式是，如果出现性能问题，当你对某个SQL优化没有概念时，看看oracle的建议。虽然大多数时候我不听从它的建议，但有时它会给出我没有意识到的建议。这就是该工具的好处。完全靠经验，还是会有遗漏的。多年前的策略，现在已经融入到产品中了。老DBA的生活其实很艰难。之前的RBO时代，SQL优化真的很酸，DBA说到做到。让我们再看一下SQL配置文件。如果你的优化体验中没有SQLProfile经验，你会为此扣分。说这话，绝对不是虚张声势，也不是自立旗帜。这种场景是DBA的价值被严重高估的时候。一般遇到这样的问题，都等不及了。更改应用程序代码是不可能的，甚至有可能更改它。重新部署需要重启服务，肯定是不靠谱的，所以如果不改代码，不改SQL，不加索引，并且可以优化SQL，这个操作会给你的职业生涯一个很大的加分.我在我的职业生涯中遇到过很多次。大多数情况下都非常酷。有两次很尴尬。第一次是SQL优化后，一年后问题爆发。简单理解就是这张表本来是10万条数据，绑定的执行计划还行，但是一年后，数据量1000万，原来的执行计划就不行了。如果你使用并发和一些负载，这个问题就会得到解决。放大。因此，SQLprofile处理的正确姿势是作为临时方案可行，但绝对不推荐作为永久方案。如果一个数据库中有大量的执行计划绑定，就像应用了n个以上的补丁。别说优雅，看着就寒酸。另一个尴尬的情况是过度优化。你怎么理解这个？我对开发的SQL进行了优化，实现了高效处理，反馈必达。基本上，他告诉我，当应用程序卡住时，我在不到5分钟的时间内优化了它。申请同学造成的错觉是这个工作很容易。开发主管来找我说，让我授权吧，他们可以自己优化。事实是，它还不成熟。不过退一步说，这种东西终究是要被取代的。如果你不改进，那么Oracle就会改进。这不是18c，这部分肯定会改动和优化。举个例子吧。如果某个SQL执行计划很好，消耗很低，但是执行效率很差，那一定是哪里出了问题。这就好比一个人的简历看起来光鲜亮丽，但工作能力却很一般。问题的瓶颈在哪里？如何向下钻取？从HR的角度来看，招聘的工作就完成了，但是从用人部门的角度来看，会产生很大的影响。所以要找到这个瓶颈点，我们需要做信息下钻。根据真实的执行情况得到整条SQL的执行计划。如上图可以清楚的看到，在进行索引扫描的时候，估计有2000多条记录，但实际上4G的记录可以分成几个分支来考虑，比如索引使用不当、不合理的统计信息、不合理的查询条件等。一一排查下钻，快速定位问题。我知道有高手做逆向优化，就是先看执行计划，再推断什么是SQL。如果你能达到这个水平，就意味着你在和优化器赛跑。获取SQLhtml报告非常简单，直接调用这个包即可。如果你用好SQL监控器，你的职业幸福感会大大提高。当然，我花了很多时间思考这件事。您可以阅读之前的摘要。http://dbaplus.cn/news-10-705-1.htmlSQL监控报告分为几个层次，有简体文本，略带紫色的html，还有丰富的active版本，就像小米手机一样，标准版，高端版和高级版已经说了SQLMonitor的优点，下面再说说它的缺点。缺点也很明显。到目前为止，这部分还需要改进。前几天说到一个性能问题，想看看SQL监控器的报告。很抱歉我买不到这个。唯一勉强能满足需求的是从AWR中抽取的SQL报告。所以mysql在这一点上做得比较好，有慢日志，都记录下来了。Oracle也有类似的慢日志实现。在Oracle中，有些业务可能3秒都无所谓。所以SQLMonitor默认是5秒，当然这个是可以调整的。我是一个喜欢折腾的人，所以我打算做一些改进。我的改进比slowlog更优雅，就是周期扫描。如果发现SQL性能问题，则针对相应的SQL生成SQL监控报告。如果重复存在则生成一次。这个细节其实是可以优化的。后来实现的目标之一如下。生成了很多sql报表，快到了上班可以喝茶看报表的地步了。有问题的时候优化SQL，然后发给开发确认，所以我会和开发拼，因为他们的问题基本逃不过我的眼睛。代替sqlprofile，要想高效优化，就要懂得sqlt的使用。这是oraclecoe部门用的一个简单的outlook。我认为多年前的这种观点在今天仍然适用。有同学说我没有阿里的体量，很难有动力去优化工作。没有困难，就得给自己制造困难。我在这里说的不是你停止数据库导致故障。相反，您进行细粒度的操作和维护。如果你把一个关键业务系统优化到极致，什么时候性能高，什么时候性能低，为什么高，你都能很好地理解，那你就已经到了一个高峰。所以在这一点上，我也不必羡慕那些在大公司的兄弟们。至少以oracle的体量来说，不能太大。主要做重点业务，集中管理。管理MySQL的思路就不一样了。另一种是半自动化。现在自动化提的太多了，有些关键的地方肯定是半自动化的。我们不怕慢，就怕错。小心这个地方。我不希望我的主库被随意更改，即使它的设置真的很不合理和怪异。如果是在维护期间，我可以更正，否则主库就是主库。对于大家的优化来说，这只是一个开始。当今时代对每个人都提出了巨大的挑战。不要低估这些挑战，也不要莫名排斥。现在的发展变化已经远远超出了我的预料，所以我可以想到更多的挑战和可能出现的很多问题，我不希望水煮青蛙的故事发生在我们身边。以上就是我的分享，谢谢大家。
