上一期的内容当中，我们向大家介绍了通过手动升级到19c的方法，在今天的内容当中，我们首先比较数据库升级之前和之后的性能差异，然后为您介绍SQL Performance Analyzer、SQL Plan Management、SQL Tuning Advisor的使用，最后为您介绍数据库自动升级。
我们在上一篇文章当中，将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
当您看到如下结果，表明报告已经生成完毕。
我们可以将报告下载下来，或者在虚拟机内打开。关于报告的解读，在这里我就不再赘述了，您可以在网路中查询该报告的解读方法。通过观察，您可以看到，数据库在升级之后，是有性能提升的，但是提升多少，要看具体的情况啦。
作为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语句进行优化。
在升级之后，我们通过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的介绍。
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报告，与升级之前相比有怎样的性能变化
我们以执行之间为例，我们发现不加区分地执行所有建议，似乎也不是一个很好的选择呀。在工作当中，我们还是应该仔细查看每一条建议，在评估之后再去确定是否执行，这才是一个好的选择。
自动升级这个工具已经存在有一段时间了，可以查阅MOS Note: 2485457.1 – AutoUpgrade Tool.获取最新版的工具，目前最新版是version 20191125。在昨天的文章中，大家通过实验的方式了解了手动升级的步骤，那么在这个实验中，我们一起体验一下自动升级带给我们的便捷吧。
在本实验中，我们将12.2.0.1的数据库通过自动升级的方式，升级到19.3.
第一步：设定db12的环境变量，并启动数据库
第二步生成配置模板，然后根据需要去修改模板中的内容，在本实验中，我们暂时使用Mike为我们修改好的文件，如果您对配置文件感兴趣，可以查询MOS文档获得更详细的信息
下表为配置文件说明，供您参考。
第三步：升级前分析，看看是否有问题，我们这里使用的是现成的配置文件，是Mike帮我们写好的
在这个实验中，有一个小小的提示，执行脚本之后，会出现提示符upg>，这不是等待您输入信息，而是脚本正在执行，脚本执行完毕之后，会出现如下界面。
第四步：执行自动升级，升级过程大概要20-50分钟的时间
在升级的过程中，您可以使用lsj查看当前运行的状态，以及status -job job编号来查询job的运行状态。
当升级完成之后，您将看到如下界面。
第五步：修改兼容版本号
因为您当前已经将数据库升级到19c，所以请设定19c的环境变量，然后在SQL Plus当中修改数据库的兼容版本号。修改之后，请重启数据库。
到这里，自动升级的实验就完成了。感谢您今天的阅读，我们将在明天介绍本套教程的最后3个实验，期待您的点阅，谢谢。
扫描下方QR Code即刻预约ADW演示
编辑：殷海英
