手把手教你升级到 Oracle 19c（2）

在前面的内容当中，我们向大家介绍了通过手动升级到 Oracle 19c 的方法，在今天的内容当中，我们首先比较数据库升级之前和之后的性能差异，然后为您介绍 SQL Performance Analyzer、SQL Plan Management、SQL Tuning Advisor 的使用，最后为您介绍数据库自动升级。

我们在上一篇文章当中，将 upgr 数据库从 11.2.0.4 升级到了 19.3，现在我们使用 HammerDB 生成与之前相同的工作量，然后对比升级前与升级后的性能差异，下面的视频是操作录像，我们将在视频之后，为您做分步讲解。

http://mpvideo.qpic.cn/0af2obbeyu2vicyabeeqeaimaigfrwpk6cyqem4rbmgq2aqfa4cq.f10002.mp4?

第一步：生成快照

我们设定 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个实验，期待您的点阅，谢谢。