命令行使用oracle19c_手把手教你升级到 Oracle 19c（2）| 教程来了

点击▲关注 “ITPUB”   给公众号标星置顶

更多精彩 第一时间直达

上一期的内容当中(点击上图即可查看)，手把手教你升级到 Oracle  19c(1)| 教程来了 我们向大家介绍了通过手动升级到19c的方法，在今天的内容当中，我们首先比较数据库升级之前和之后的性能差异，然后为您介绍SQL Performance Analyzer、SQL Plan Management、SQL Tuning Advisor的使用，最后为您介绍数据库自动升级。 -1- 升级前后性能对比 我们在上一篇文章当中，将upgr数据库从11.2.0.4升级到了19.3，现在我们使用HammerDB生成与之前相同的工作量，然后对比升级前与升级后的性能差异，下面的视频是操作录像，我们将在视频之后，为您做分步讲解。 第一步： 生成快照 我们设定upgr19这个概要文件，然后在SQL Plus当中确认我们要操作的数据库是upgr，之后通过脚本来生成快照，我们当前看到的快照号码是117，我们需要记录下这个快照号码，稍后将在生成AWR报告时使用它。 第二步： 在HammerDB中生成工作量，并再次生成快照 接下来，我们使用HammerDB生成一些工作量，方法和上一篇文章中的操作一样。首先是载入测试脚本，然后生成测试用户，最后在HammerDB当中执行工作量。 首先启动hammerDB，如下图操作： 然后载入脚本，如下图操作： 创建测试用户，如下图操作： 运行工作量并开启监控，如下图操作： 当看到如下图所示的状态，表明工作量执行完毕，可以关闭HammerDB了。 我们来到SQL Plus再次执行快照生成脚本，并记录当前的快照号码，当前号码为118。 第三步： 执行快照比较脚本，生成性能比较报告 在SQL Plus当中执行如下脚本，生成快照比较报告，我们本次选择HTML格式的报告。并将它存储在/home/oracle/scripts下面，名字叫做awrdiff.html 列出近两天的快照信息 在昨天的文章中，数据库升级之前，我们也使用HammerDB生成工作量，当时的快照号码是92和93。请注意，您的快照号码和我的应该是不相同的，请您使用自己的快照号码。 针对第二个时段，我们让系统输出近1天的快照信息。 然后我们设定开始快照号码为117，结束快照号码为118，您的快照号码与我应该是不同的，请您根据上面HammerDB之前前后所生成的快照号码进行填入。 我们设定报告名称为/home/oracle/scripts/awrdiff.html 当您看到如下结果，表明报告已经生成完毕。 我们可以将报告下载下来，或者在虚拟机内打开。关于报告的解读，在这里我就不再赘述了，您可以在网路中查询该报告的解读方法。通过观察，您可以看到，数据库在升级之后，是有性能提升的，但是提升多少，要看具体的情况啦。 -2- SQL performmance  Analyzer 作为DBA，大家在很久之前就知道Oracle的SPA，这是一个用来分析SQL性能的工具，关于SPA的使用方法，大家可以在网络上找到很多参考资料，本实验主要是使用SPA对升级前和升级后的CPU_TIME和ELAPSED_TIME这两个指标进行比较，我们使用的是Mike为我们写好的脚本，如果您看兴趣，您可以使用文本编辑器打开SQL文件，查看里面的内容。 但是本实验，我们主要关注的是升级前后对相同SQL Tuning Set使用SPA进行比较的结果，我们就不在这里对SPA进行深入讲解了。 第一步： 登入upgr数据库，查看当前数据库内的SQL Tuning Set 通过查询我们可以看到，目前数据库中有两个SQL Tuning Set，这两个STS在之前的实验中，我们见过，并使用过。 第二步： 执行4个脚本，生成两个SPA的报告。 因为之后我们还要使用这4个脚本去生成SPA报告，而Mike大神在写脚本的时候，没有给我们输入文件名的机会，所以，要么您去修改Mike的脚本，要么记住当前生成报告的名称。 第三步： 查看生成的两个SPA文件 为了方便与后面实验所生成的SPA文件相区隔，我们在这里记录这两个文件的名字。 我们打开这两个文件观察一下升级前后的SQL性能变化，都是有提升的。但提升的幅度不尽相同。另外，如果您发现升级之后，性能有回退，也别担心，我们可以通过其他技术对这些SQL进行优化，使其具有更好的性能。在下面的两个报告中，我们都看到一个SQL ID为13dn4hkrzfpdy的语句在升级前后有性能变化，我们在接下来的实验中，针对这个SQL语句进行优化。 -3- SQL 计划管理 在升级之后，我们通过SPA找到了一些性能不好的SQL语句，我们应该有针对性地对这些语句进行优化，而不是使用工具将他们不加区分地统统“优化”。在当前这个实验当中，我们使用了另一位大神(Carlos Sierra)的脚本 用于创建SQL Plan Baseline。 第一步： 来到升级后的upgr环境，执行 SQL Plan Baseline生成脚本 在升级之后，有些SQL语句的执行计划发生改变，可能出现性能回退的情况，我们针对这些执行计划有待优化的SQL使用工具进行优化。在当前的步骤中，我们在执行脚本之后，会被问询SQL ID，我们将上一个实验中找到的那个性能发生改变的SQL语句的SQL ID(13dn4hkrzfpdy)填入。 这个脚本会列出该SQL可能的执行计划，我们比较了一下各种指标，综合考虑一下，觉得第一个执行计划稍好些，于是将他的Hash Value填入。接下来还有3个参数，我们直接忽略，按回车键即可。 当脚本执行完毕，我们将看到如下结果： 第二步： 查询一下，SQL Plan是否已经被接受，我们查看下面的语句，发现已经被接受了。 我们看到下图中第一个红色框中的执行计划名字，在我们使用SQL语句查询执行计划是否被接受的结果中，看到该计划已经被enable并且接受了。 第三步： 我们再次执行之前的那4个用来生成SPA报告的脚本，看看执行计划改变之后，性能是否有提升 我们首先执行一个脚本，这个脚本将SQL Tuning Set(STS_CaptureCursorCache)内的SQL执行计划都改了，这个操作我个人认为也许并不是一个最好的选择，因为不加区分地进行修改，总觉得有些不妥。Anyway，我们在本实验中，先通过脚本将STS_CaptureCursorCache的SQL的计划都修改一下吧。 接下来，我们要修改一下脚本，因为我们发现上面刚刚执行的spm_load_all.sql当中使用的STS名字是STS_CaptureCursorCache。 我们接下来要执行的spa_cpu.sql里面的STS名字是STS_CaptureAWR 我们将spa_cpu.sql和spa_elapsed.sql复制出一个副本，叫做spa_cpu1.sql和spa_elapsed1.sql，然后将里面的Sqlset_name修改成STS_CaptureCursorCache。 为了方便大家观察，我将这两个脚本复制出来，然后在Windows当中进行修改，然后再传回去，您完全可以使用自己喜欢的文本编辑器对这两个脚本进行修改。 接下来就是在SQL Plus当中执行如下4个脚本了，执行之后会在/home/oracle/scripts下面生成2个新的HTML文件。 接下来我们打开新生成的这2个HTML报告看看 在这里就不对该报告的内容做详细解读了，大家可以参考网络上关于SPM的介绍。 -4-  SQL Tuning Advisor SQL优化指导，这个工具在十多年前就被大家广泛使用了，在本实验中，我们使用SQL优化指导，对STS_CaptureCursorCache这个SQL Tuning Set中的语句进行优化，看看它会给我们怎样的建议。大多数用户经常是在EM12c/13c当中使用SQL优化指导，今天我们使用命令行来执行看看效果。  第一步：执行sta_cc.sql  首先我们看看这个脚本中的内容。我们发现，它使用的STS名称为STS_CaptureCursorCache，所以一会儿我们生成报告的时候，要执行我们在上一个实验中修改好的带有“1”的 执行sta_cc.sql 脚本执行完毕之后，会看到输出的建议语句，如下图所示，在工作中，我们应该有针对性地执行这些建议语句，但在本实验中，我们暂不分析这些语句是否正确，都执行一遍吧。 第二步： 执行建议器给出的语句 在执行的过程中，会有几个错误，说是index已经存在了，暂且不用理会。 第三步： 再次运行之前的“那4个脚本”， 生成新的SPA报告看看性能变化，请注意，这里执行的脚本是我们在上个实验中复制出来并修改过的，因为STS的名字要对的上呀。红色箭头的意思是让大家注意，这是修改过的脚本。 第四步： 我们去看看新生成的SPA报告，与升级之前相比有怎样的性能变化 我们以执行之间为例，我们发现不加区分地执行所有建议，似乎也不是一个很好的选择呀。在工作当中，我们还是应该仔细查看每一条建议，在评估之后再去确定是否执行，这才是一个好的选择。 -5- 自动升级 自动升级这个工具已经存在有一段时间了，可以查阅MOS Note: 2485457.1 – AutoUpgrade Tool.获取最新版的工具，目前最新版是version 20191125。在昨天的文章中，大家通过实验的方式了解了手动升级的步骤，那么在这个实验中，我们一起体验一下自动升级带给我们的便捷吧。 在本实验中，我们将12.2.0.1的数据库通过自动升级的方式，升级到19.3. 第一步： 设定db12的环境变量，并启动数据库 第二步生成配置模板，然后根据需要去修改模板中的内容， 在本实验中，我们暂时使用Mike为我们修改好的文件，如果您对配置文件感兴趣，可以查询MOS文档获得更详细的信息 下表为配置文件说明，供您参考。

Generated config.cfg

Make the following adjustments:

#Global configurations#Autoupgrade's global directory, ...#temp files created and other ...#send hereglobal.autoupg_log_dir=/default/...## Database number 1#upg1.dbname=employeeupg1.start_time=NOWupg1.source_home=/u01/...upg1.target_home=/u01/...upg1.sid=empupg1.log_dir=/scratch/autoupg1.upgrade_node=node1upg1.target_version=19.1#upg1.run_utlrp=yes#upg1.timezone_upg=yes

#Global configurations#Autoupgrade's global directory, ...#temp files created and other ...#send hereglobal.autoupg_log_dir=/home/oracle/logs## Database number 1#upg1.dbname=DB12upg1.start_time=NOWupg1.source_home=/u01/app/oracle/product/12.2.0.1upg1.target_home=/u01/app/oracle/product/19upg1.sid=DB12upg1.log_dir=/home/oracle/logsupg1.upgrade_node=localhostupg1.target_version=19upg1.restoration=no

第三步： 升级前分析，看看是否有问题， 我们这里使用的是现成的配置文件，是Mike帮我们写好的 在这个实验中，有一个小小的提示，执行脚本之后，会出现提示符upg>，这不是等待您输入信息，而是脚本正在执行，脚本执行完毕之后，会出现如下界面。 第四步： 执行自动升级， 升级过程大概要20-50分钟的时间 在升级的过程中，您可以使用lsj查看当前运行的状态，以及status -job job编号来查询job的运行状态。 当升级完成之后，您将看到如下界面。 第五步： 修改兼容版本号 因为您当前已经将数据库升级到19c，所以请设定19c的环境变量，然后在SQL Plus当中修改数据库的兼容版本号。修改之后，请重启数据库。 到这里，自动升级的实验就完成了。感谢您今天的阅读，我们将在明天介绍本套教程的最后3个实验，期待您的点阅，谢谢。  往期回顾：    1、 手把手教你升级到 Oracle  19c(1)| 教程来了 编辑：殷海英 本文由甲骨文云技术独家授权ITPUB  转载请联系 甲骨文云技术

你「在看」吗？