对于Oracle数据库的每个版本，总是需要遵循一个升级路径。而对于很多人来说，他们经常是在不了解需要做些什么的情况下就匆忙下载软件并尝试去安装或升级。如果失败，这就有可能会导致灾难并对业务产生潜在的影响。

升级至Oracle数据库12c（12.1.0）的路径是相当简单的。如果你所运行的Oracle数据库支持升级至12c的直接路径，那么使用任何受支持的升级方法都没问题。反之，如果你的版本不支持直接路径升级，那么你就需要在升级至Oracle数据库12c之前先升级至一个受支持的版本。

受支持的直接升级路径：

• Oracle数据库10g（10.2.0.5）
• Oracle 数据库 11g （11.1.0.7）
• Oracle 数据库 11g （11.2.0.2 或后续版本）

目前有三个受支持的升级路径/工具，每个都有各自需要注意的问题。升级选项包括：

• 数据库升级助手 （DBUA）
• 手动升级 （基于脚本）
• 导出/导入

本文主要介绍如何使用DBUA升级到Oracle数据库12c。

Oracle已对DBUA做出改进以提供无缝升级。如果出现错误，我们现在就有选择可直接从DBUA对它们进行修复。此外，DBUA使得监控升级更为简便。要使用DBUA，我们必须去Oracle数据库12c主目录并通过运行dbua来开启它。

运行 PREUPGRD.SQL

为了运行preupgrd.sql文件，我们首先需要为12c安装新的二进制文件到Oracle主目录。之后需要配置环境来连接想要升级的数据库。

在本文的测试环境中，Oracle数据库11g设置如下：

ORACLE_SID=ora11g ORACLE_BASE=/opt/oracle ORACLE_HOME=/opt/oracle/product/11.2.0.3.0/db_1

接下来，我们需要去preupgrd.sql 文件所在的目录：

#> cd /opt/oracle/product/12.1.0.1/dbhome_1/rdbms/admin

最后，我们需要使用SQL*Plus并运行preupgrd.sql 文件来连接11g数据库：

#> sqlplus / as sysdba SQL>@preupgrd.sql

当preupgrd.sql脚本完成后，我们就会获得需要参考的文件所在路径，这些文件可以帮助我们检验并纠正环境中出现的任何问题。

/opt/oracle/cfgtoollogs/ora11g/preupgrade/preupgrade.log

预升级修复脚本（在源数据库环境中运行）：

/opt/oracle/cfgtoollogs/ora11g/preupgrade/preupgrade_fixups.sql

升级后修复脚本（升级后运行）：

/opt/oracle/cfgtoollogs/ora11g/preupgrade/postupgrade_fixups.sql

检查这些脚本并纠正任何需要修复的问题。一旦修正完成，再运行DBUA就会更加简单。而如果在preupgrade.log中列有任何错误，那就需要在继续之前对它们加以纠正。

运行 DBUA

一旦在检查了preupgrade.log之后并纠正了所有问题，我们就可以启动DBUA了。

要启动DBUA，我们需要去Oracle数据库12c主目录并运行dbua：

#> cd /opt/oracle/product/12.1.0.1/dbhome_1/bin #> ./dbua &

这将开启GUI开始升级。注意目前并没有对环境做任何更改，仍然指向11g的环境。

ORACLE_SID=ora11g ORACLE_BASE=/opt/oracle ORACLE_HOME=/opt/oracle/product/11.2.0.3.0/db_1

DBUA启动后，你会注意到我们是处在11个步骤中的步骤1。而步骤数量的变化取决于所选择的选项。步骤1，我们有两个选项

• 升级一个Oracle数据库
• 迁移一个已存在的12c数据库到一个新的12coracle主目录

出于更新的目的，我们可以只点击下一步并继续。

作为升级过程的一部分，我们需要确定想要升级的Oracle主目录。因为我们是在将Oracle主目录设置到11g主目录的情况下启动DBUA的，DBUA就会给我们所有与Oracle主目录相关的数据库。选择所要升级的数据库，然后点击下一步。

在步骤3中，我们看到的结果与我们在preupgrade.log看到的相类似。DBUA实际上是运行了相同的preupgrade.log脚本并返回结果给GUI。

步骤4是DBUA中最有意思的界面之一。Oracle已经对如何处理升级做了一个根本性的改变，升级现在可以并行完成。这可通过使用新的perl脚本catctl.pl来完成。并行的数量是基于服务器中CPU的数量来进行计算的。此外，现在我们可以并行重编译对象并让DBUA执行此多时区的升级，获取统计信息并使得表空间在升级过程中只读。点击下一步继续。

步骤5可以选择如何管理Oracle数据库12c环境。我们可以选择使用EM Express,这是Oracle数据库12c中新的Web界面，它用以替代之前版本中的数据库控制台，或者我们可以选择通过Oracle企业管理12c（OEM）来注册数据库。

注意：如果在正在进行升级的服务器上已经安装了OEM12c，那么DBUA就会自动选择所需信息。

步骤6允许我们指定想要将数据文件迁移到何处并在何处设置快速恢复区（FRA）。如果想要在此处使用Oracle管理文件（OMF），我们也可以进行配置。

步骤7让我们可以选择将11g上的监听器迁移至12c（如果还没有完成升级）。在下图中，已经安装了12c二进制文件并有一个监听器正运行。此界面的重要之处在于‘Migrate’列。此列会告诉你监听器是否会进行迁移。

在步骤8中，我们可以选择在升级之前为数据库创建一个新备份。如果你对自己的备份策略自信的话，就可选择‘I have my own backup and restore strategy ’，告诉DBUA不必做备份。

最后，我们看到的是总结界面（步骤9）。此界面会向我们展示DBUA认为它将要做的事情。应该始终有人对此界面进行检查并在点击‘Finish ’之前确保一切正常。一旦我们点击了完成，升级就会开始并且我们可以通过进度界面对这一过程进行监控。

在进度界面上，我们可以看到升级的进度。界面上的箭头可以扩展显示DBUA当前所在进行的步骤。进度界面上另一个不错的功能就剩余时间展示，可以在时间列看到这一点。

一旦升级完成，‘Stop ’按钮就会改变其文字并显示为‘Upgrade Results ’。点击此按钮，界面就会改变并为你提供升级的结果。

此时，升级完成并且可以关闭DBUA。点击‘Close ’按钮退出GUI。

验证升级

有多种方法可以对升级进行验证。而最为简单的方法就是检查/etc/oratab 文件。一旦升级完成，oratab文件就应该已将Oracle主目录变成与12c二进制文件相匹配的路径。

另外一种验证方法就是用以下命令行检查环境变量：

#> env | grep ORA ORACLE_SID=ora11g ORACLE_BASE=/opt/oracle ORACLE_HOME=/opt/oracle/product/12.1.0.1/dbhome_1

最后，我们可以使用SQL*Plus对数据库版本进行检查：

#> sqlplus / as sysdba SQL> select banner from v$version

甲骨文为Oracle数据库12c的升级提供了非常简单的路径，希望本文对你有所帮助。