如何升级oracle版本

本文档旨在提供指南和核对清单，用于将之前升级的数据库从Oracle12c降级回以前的版本：11.2.0.3,11.2.0.2,11.1.0.7必须加以说明的是，将数据库实例从当前版本降级到升级前的版本时，数据库不会返回到升级前的完全相同状态。根据所涉及的版本，升级过程会进行不可逆的更改。用户使用降级过程可以打开和访问以前版本的数据库实例。这通常便已足够。可能需要采取其他更正 *** 作（例如卸载/重新安装或重新升级到当前补丁集级别来解决降级后的遗留问题。如果目标是让实例返回与升级前完全相同的状态，则还应使用包括完全恢复到升级前状态在内的其他过程。本文中讨论的过程是基于脚本的降级。本文不介绍使用导出/导入、数据泵或其他方法将数据从一个版本移动到另一个版本。您所降级到的版本的Oracle二进制文件，在开始降级过程之前应该在服务器上可用/已安装。如果您卸载了要降级到的Oracle可执行文件，请重新安装Oracle二进制文件到正确的版本/补丁程序级别以降级。此过程旨在降级已成功升级到12c的数据库，并非用于从失败的升级退回。您只能降级到升级前所用的版本和补丁程序级别。直接升级可以在版本10.2.0.5、11.1.0.7或版本11.2.0.2及更高版本上执行。可以对这些版本中除10.2.0.5之外的版本进行降级。例如，如果通过应用中间补丁程序11.1.0.7从Oracle11.1.0.6升级到Oracle12c(12.1.0)，则不能降级到Oracle11.1.0.6。降级只能对直接升级版本执行。例外：虽然可以对10.2.0.5直接升级，但降级不适用于10.2.0.5。这是因为在升级过程中，compatible参数已设置为最低11.0.0。这使得无法降级到10.2.0.5。可以降级的版本为11.1.0.7、11.2.0.2、11.2.0.3或更高版本。如果有任何补丁程序应用到了从升级后的主目录运行的源数据库，则需要先回退，然后才能开始降级过程。卸载和回退补丁程序的步骤记录在所涉及补丁程序的自述文件中。未能卸载和回退补丁程序可能会导致无法降级，包括无法重新验证字典对象。Exadata捆绑补丁程序示例，其过程为：卸载补丁程序示例：$opatchauto/u01/app/oracle/patches/14103267-rollback回退任何在补丁程序应用过程中应用的SQL：示例：SQL>@rdbms/admin/catbundle_EXA__ROLLBACK.sql，用于回退SQL更改。解决方案降级前步骤-XMLDB组件在12c中是必需的。在升级到12c期间，将安装XMLDB组件（如果未安装）。从12c降级将删除安装的XDB组件-EnterpriseManager不支持降级。在降级之前，请重新配置OracleEM控件。请参阅OracleDatabaseUpgradeGuide12cRelease1(12.1)E17642-106DowngradingOracleDatabasetoanEarlierRelease6.6.5RestoringOracleEnterpriseManagerafterDowngradingOracleDatabase-升级到12c期间，将删除DatabaseControl资料档案库。降级之后，请重新配置DBControl。Note870877.1HowToSaveOracleEnterpriseManagerDatabaseControlDataBeforeUpgradingTheSingleInstanceDatabaseToOtherRelease?Note876353.1HowToRestoreTheOracleEnterpriseManagerDataToDowngradeTheSingleInstanceDatabaseToPrevious/SourceRelease?-compatible参数不能已经更改到12.1.0。-禁用DataVault（如果已启用）。Note803948.1HowToUninstallOrReinstallDatabaseVaultin11g(UNIX)Note453902.1EnablingandDisablingOracleDatabaseVaultinWINDOWS-如果数据库使用OracleLabelSecurity，则在新OracleDatabase12cOracle主目录中运行OracleLabelSecurity(OLS)预处理降级olspredowngrade.sql脚本（在$ORACLE_HOME/rdbms/admin上提供）。-时区版本应相同。-取消设置并指向12c主目录的ORA_TZFILE（如果已设置）。-如果数据库上有OracleApplicationExpress，则必须将apxrelod.sql文件从OracleDatabase12c$ORACLE_HOME/apex/目录复制到Oracle主目录之外的目录，例如系统上的临时目录以稍后执行。-如果基于固定对象创建了对象，则删除这些对象以避免可能的ORA-00600错误。您可以在降级之后重新创建这些对象。-如果降级集群数据库，则彻底关闭实例并将CLUSTER_DATABASE初始化参数更改为FALSE。降级之后，必须将此参数设置回TRUE。满足以上先决条件之后，可以继续进行降级。数据库的降级步骤1)确保所有数据库组件有效。只能从成功升级的数据库执行降级。要验证数据库组件状态，请执行以下查询以SYS用户身份连接到数据库colcomp_idformata10colcomp_nameformata30colversionformata10colstatusformata8selectsubstr(comp_id,1,15)comp_id,substr(comp_name,1,30)comp_name,substr(version,1,10)version,statusfromdba_registry2)验证没有属于sys/system的无效对象selectowner,count(object_name)"Invalidobjectcount"fromdba_objectswherestatus!='VALID'andownerin('SYS','SYSTEM')groupbyowner如果计数为零，则可以继续降级。如果有无效对象，则执行utlrp.sql多次，如果对象无法解析为有效状态，则不能继续降级。建立SR或在DBA社区上发帖以寻求帮助。或者，对于1和2，运行以下脚本：Note556610.1ScripttoCollectDBUpgrade/MigrateDiagnosticInformation(dbupgdiag.sql)3)关闭数据库Shutdownimmediate4)对12c数据库做备份5)以降级模式启动数据库Startupdowngrade6)执行降级脚本Sql>Spooldowngrade.logSql>@$ORACLE_HOME/rdbms/admin/catdwgrd.sql注：$ORACLE_HOME应指向12c主目录catdwgrd.sql脚本将数据库中的所有组件降级到支持的主版本或补丁集版本（您最初升级时的版本）Sql>spooloffSql>shutdownimmediateExitSQLPlusSql>exit7)如果 *** 作系统为LINUX/UNIX：将以下环境变量更改为要降级到的源数据库：ORACLE_HOMEPATH编辑/etc/oratabor/var/opt/oracle/oratab以更改将数据库映射到源数据库Oracle主目录如果 *** 作系统是Windows，则完成以下步骤：a.停止所有Oracle服务，包括OracleDatabase12c数据库的OracleServiceSIDOracle服务，其中SID是实例名称。例如，如果SID为ORCL，则在命令行提示符中输入以下内容：C:\>NETSTOPOracleServiceORCLb.在命令提示符下，通过运行ORADIM命令删除Oracle服务。如果出现提示，则输入此Windows系统上活动标准用户帐户的口令。例如，如果SID为ORCL，则输入以下命令：C:\>ORADIM-DELETE-SIDORCLc.在命令提示符下，使用ORADIM命令创建要降级的数据库的Oracle服务。C:\>ORADIM-NEW-SIDSID-INTPWDPASSWORD-MAXUSERSUSERS-STARTMODEAUTO-PFILEORACLE_HOME\DATABASE\INITSID.ORA8)还原配置文件将配置文件（口令文件、参数文件等）还原到降级版本的ORACLE_HOME。9)如果这是OracleRAC数据库，则执行以下命令以将数据库修改为单实例模式：SETCLUSTER_DATABASE=FALSE10)从降级版本$ORACLE_HOME/rdbms/admin目录执行catrelod脚本。启动sqlplus，以具有sysdba权限的用户SYS身份连接到数据库实例，然后以升级模式启动数据库：:cd$ORACLE_HOME/rdbms/admin:sqlplussql>connectsysassysdbasql>startupupgradesql>spoolcatrelod.logsql>@?/rdbms/admin/catrelod.sqlsql>spooloffcatrelod.sql脚本在降级的数据库中重新加载各个数据库组件的合适版本。11)运行utlrp.sql脚本：SQL>@utlrp.sqlSql>exitutlrp.sql脚本重新编译先前处于INVALID状态的所有现有PL/SQL模块，例如package、procedure、type等。12)检查已降级数据库的状态：Note556610.1ScripttoCollectDBUpgrade/MigrateDiagnosticInformation(dbupgdiag.sql)此sql脚本是一组查询语句，用于提供用户友好的输出，以在升级前后诊断数据库的状态。脚本将创建名为db_upg_diag__.log的文件。13)降级之后，可能在sys用户下发现无效的QT视图。这是因为视图已从基表中选择了错误的列。您需要重新创建这些视图。请参阅说明：Note1520209.1QT_*BUFERViewsInvalidafterdowngradefrom12C降级后步骤：1)如果您是降级到OracleDatabase11g版本1(11.1.0.7)并且数据库中有OracleApplicationExpress，则转到您将apxrelod.sql脚本复制到的目录（在降级前步骤中）。运行apxrelod.sql脚本以手动重新加载OracleApplicationExpress：SQL>@apxrelod.sql运行apxrelod.sql脚本以避免程序包APEX_030200.WWV_FLOW_HELP由于以下错误而成为INVALID状态：PLS-00201:identifier'CTX_DDL'mustbedeclared2)如果数据库中启用了OracleLabelSecurity，则执行以下脚本a.从OracleDatabase12c的Oracle主目录下将olstrig.sql脚本复制到要将数据库降级到的版本的Oracle主目录。b.从降级到的版本的Oracle主目录，运行olstrig.sql以在表上使用OracleLabelSecurity策略重新创建DML触发器：SQL>@olstrig.sql3)如果降级集群数据库，则必须运行以下命令以降级OracleClusterwaredatabase配置：$srvctldowngradedatabase-ddb-unique-name-ooraclehome-tto_version其中db-unique-name是数据库名称（而非实例名称），oraclehome是已降级数据库的旧Oracle主目录的位置，to_version是数据库所降级到的数据库版本

现象

Sysbench对MySQL进行压测, 并发数过大(>5k)时, Sysbench建立连接的步骤会超时.

猜想

猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.

验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.

检查环境

猜想失败, 回到常规的环境检查:

MySQL error log 未见异常.

syslog 未见异常.

tcpdump 观察网络包未见异常, 连接能完成正常的三次握手只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.

自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响

猜想2

怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:

检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.

通过strace检查MySQL, 发现 accept() 调用确实没有感知到新连接.

怀疑是OS的原因, Google之, 得到参考文档: A TCP “stuck” connection mystery【http://www.evanjones.ca/tcp-stuck-connection-mystery.html】

分析

参考文档中的现象跟目前的状况很类似, 简述如下:

正常的TCP连接流程:

Client 向 Server 发起连接请求, 发送SYN.

Server 预留连接资源, 向 Client 回复SYN-ACK.

Client 向 Server 回复ACK.

Server 收到 ACK, 连接建立.

在业务层上, Client和Server间进行通讯.

当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:

Client 向 Server 发起连接请求, 发送SYN.

Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.

Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).

Server 验证签名, 分配连接资源, 连接建立.

在业务层上, Client和Server间进行通讯.

当启用SYN-cookie时, 第3步的ACK包因为 某种原因 丢失, 那么:

从Client的视角, 连接已经建立.

从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)

发生这种情况时:

若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误

若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.

TCP握手的第三步ACK包为什么丢失

参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:

Some of these packets get lost because some buffer somewhere overflows.

我们可以通过Systemtap进一步探究原因. 通过一个简单的脚本:

probe kernel.function("cookie_v4_check").return

{

source_port = @cast($skb->head + $skb->transport_header, "struct tcphdr")->source

printf("source=%d, return=%d\n",readable_port(source_port), $return)

}

function readable_port(port) {

return (port &((1<<9)-1)) <<8 | (port >>8)

}

观察结果, 可以确认cookie_v4_check (syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.

之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):

static inline bool sk_acceptq_is_full(const struct sock  *sk){   return sk->sk_ack_backlog >sk-   >sk_max_ack_backlog}

恢复故障与日志的正关联

在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.

当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.

检查Linux源码:

if (!queue->synflood_warned &&

sysctl_tcp_syncookies != 2 &&

xchg(&queue->synflood_warned, 1) == 0)

pr_info("%s: Possible SYN flooding on port %d. %s.

Check SNMP counters.\n",

proto, ntohs(tcp_hdr(skb)->dest), msg)

可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.

粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.

解决方案

这种故障一旦形成, 难以检测系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了Client如果没有合适的超时机制, 万劫不复.

解决方案:

1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.

2. 关闭syn_cookie. 有安全的人又要跳出来了.

3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.

有多个系统参数混合影响syn backlog长度, 参看【http://blog.dubbelboer.com/2012/04/09/syn-cookies.html】

下图为精华总结

请点击输入图片描述

---