Skip to content

未分类 - 15. page

对于在云数据库 (OCI) 创建时 (虚拟机还没有生成) 的问题，只提供第一步的信息就可以。

 

对于其他的问题，需要提供步骤一到步骤三的所有信息。

1. 从 OCI 的控制台搜集数据库(OCI) 的相关信息：

a. Cloud Account Name
b. Region:
Region will be available on the top corner of every page in OCI console
c. Availability Domain:
Availability Domain can be found next to the database system name in OCI console
d. Tenancy ID:
In OCI console, Navigate to Administration –> Tenancy Details, Look OCID under the Tenancy Information
e. Compartment OCID:
In OCI console, Navigate to Identity –> Compartments. Look OCID under the compartment name
f. Database system OCID:
In OCI console, Navigate to Menu –> Bare Metal, VM, and Exadata, Look for Database System OCID near the database system name
g. Database OCID:
In OCI console, navigate to Database System page and click on the problematic database system. In the Database System page, look for the Database OCID under the “Databases”

 

2. 如果数据库 (OCI) 对应的虚拟机可以访问，那么用 root 用户登陆虚拟机，搜集基础架构、代理、数据库和任务详细信息：

基础架构详细信息

 

# sudo -s

# curl -s http://169.254.169.254/opc/v1/instance/ | egrep -v “user_data|ssh_authorized_keys|timeCreated”

代理详细信息

# sudo -s

# rpm -qa | grep dcs
# initctl status initdcsagent
# initctl status initdcsadmin

集群、数据库详细信息

# sudo -s

# Replace the grid home and issue below command
# /u01/app/12.2.0.1/grid/bin/crsctl check crs

# sudo su – oracle

# sqlplus / as sysdba

— Run below SQLs in SQLPLUS prompt

select status from v$instance;
select name, open_mode from v$database;
select banner from v$version where banner like ‘Oracle Database%’;

— if Multitenant

show pdbs;

任务详细信息

# sudo -s

# /opt/oracle/dcs/bin/dbcli describe-component > /tmp/dcs_job_details.log
# /opt/oracle/dcs/bin/dbcli list-databases >> /tmp/dcs_job_details.log
# /opt/oracle/dcs/bin/dbcli list-jobs >> /tmp/dcs_job_details.log
# /opt/oracle/dcs/bin/dbcli describe-job -i <faild_job_ID> >> /tmp/dcs_job_details.log

上传 /tmp/dcs_job_details.log

3. 使用 opc 用户登陆到数据库 (OCI) 对应的虚拟机，并执行如下命令：

# sudo /opt/oracle/dcs/bin/diagcollector.py

Sample Output:
=============[oci@ludatou ~]$ sudo /opt/oracle/dcs/bin/diagcollector.py
Log files collected to :/tmp/dcsdiag/diagLogs-1526004897.zip

Logs are being collected to:
/ludatou/ocidiag/diagLogs-4758698722.zip

该命令会生成 /tmp/dcsdiag/diagLogs-xxxxx.zip 的文件。

用如下命令上传这个文件到 SR：
Note 1547088.2 – How to upload large files to Oracle Support

# curl -T <path_and_filename>” -u “<userID>” https://transport.oracle.com/upload/issue/<sr-number>/

For example:
curl -T /ludatou/ocidiag/diagLogs-4758698722.zip -u ********@oracle.com https://transport.oracle.com/upload/issue/

Oracle cloud 上的云资源诊断信息收集

在升级之前习惯备份整个Oracle程序目录，包括数据文件，这里介绍一种备份oracle主要程序文件（Oracle_home）的方式，可以使用多种方式备份 Oracle home 。你可以使用任何工具来压缩Oracle Home，比如zip,tar,cpio。

备份之前建议关闭源库上的任何数据库，监听进程，从而可以对Oracle Home软件进行冷备份，当然也可以不停机。 如果是在安装补丁或者补丁集，Readme中的步骤会要求关闭，这种情况下，建议关闭数据库和监听再执行ORACLE_HOME冷备份。在Oracle进程活跃状态下执行备份仍然是有效的，因为任何加载static binaries 或者libraries的进程都不应当持有write lock。备份必须由Oracle安装用户或者root用户执行。目的是保证文件的属主和权限正确。

如下是使用tar命令的例子。

1. 关闭数据库，监听或者任何其它关联到你在备份的ORACLE_HOME的进程

2. cd 到ORACLE_HOME所在的目录。例如：

cd /u01/app/oracle/product/11.2

3. 备份 ORACLE_HOME 。

tar -pcvf /u01/app/oracle/backup/oracle_home_bkup.tar db1

在上述命令中, ORACLE_HOME 是 /u01/app/oracle/product/11.2/db1 而备份目录是 /u01/app/oracle/backup/

如下是一个还原ORACLE_HOME的例子:

1. 关闭数据库，监听或者任何其它关联到你在还原的ORACLE_HOME的进程

2. 进入 ORACLE_HOME 所在的目录。例如：

cd /u01/app/oracle/product/11.2

3. 重命名或者移动 ORACLE_HOME 例如:

mv db1 db1_bkup

4. 还原ORACLE_HOME 例如:

tar -pxvf /u01/app/oracle/backup/oracle_home_bkup.tar

在备份前检查是否有足够的空间备份，Oracle_Home 所注册的Central Inventory建议一起与ORACLE_HOME同时备份，从而保证一致性。

 

在升级或者打补丁之前备份ORACLE_HOME目录

2018年2月15日Oracle官方在MOS上新发布预警文档《Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (Doc ID 2361478.1)》中强烈建议所有DBA在2019年6月之前将Oracle数据库版本11.1.0.7、11.2.0.3和12.1.0.1打补丁到下面提到的patchset/PSU级别，以解决未来dblinks互操作性方面的潜在问题。

Oracle只是定义为潜在问题，实际关键是oracle的高版本(11.2.4/12.1.0.2/12.2及以上)数据库在2019年06月23日，默认的SCN兼容性会进行自动变化。

2.1 SCN基础概念

系统更改号(SCN)是Oracle数据库使用的一个逻辑的内部时间戳。SCN对数据库中发生的事件进行排序，这是满足事务的ACID属性所必需的。

 

数据库使用SCN来查询和跟踪更改。例如，如果事务更新了一行，那么数据库将记录更新发生时的SCN。此事务中的其他修改通常具有相同的SCN。当事务提交时，数据库将为此提交记录SCN。每个事务在提交后增加SCN。

 

 

2.2 SCN limit 

SCN以单调递增的顺序出现，Oracle数据库可以使用的SCN数量上限非常大。也称为Reasonable SCN Limit，简称RSL。这个值是一个限制，避免数据库的SCN无限制地增大，甚至达到了SCN的最大值。这个值大约是这样一个公式计算出来的：(当前时间-1988年1月1日）*24*3600*16,384 (16K/sec)。兼容性版本1

由于存在上限，任何给定的Oracle数据库都不能耗尽可用的SCN，这一点很重要。Oracle数据库使用基于时间的配给系统来确保不会发生这种情况。

这样做可以确保Oracle数据库随着时间的推移对SCN进行定量配给，从而允许任何使用版本12.2.0.1或更低版本的Oracle数据库进行超过500年的数据处理。从12.2.0.1开始，数据库的兼容性设置为12.2，即使SCN以96K/sec（兼容性版本3）的速度消耗，Oracle数据库也将允许近300万年的数据处理。

 

2.3 SCN headroom

数据库使用的当前SCN与“不超过”上限之间的差异称为SCN headroom 。

 

然而，Oracle已经确定，一些软件错误可能会导致数据库试图超过当前最大SCN值(或者超出所保证的范围)。

 

通常，如果数据库确实试图超过当前的最大SCN值，那么引起此事件的事务将被数据库取消，应用程序将看到一个错误。下一秒，这个限制就会增加，所以通常应用程序在处理过程中会继续出现轻微的打嗝。然而，在一些非常罕见的情况下，数据库确实需要关闭以保持其完整性。在任何情况下，数据都不会丢失或损坏。

 

2.4 SCN兼容性

SCN 兼容级别是限制SCN增速和SCN RSL。

 

2.5 Auto-rollover 

AUTO-ROLLVOER是一种类例JOB的定时任务，定时修改SCN 兼容性级别。

禁用了AUTO-ROLLOVER 到2019-06-23后SCN兼容级别就不会自动调整，还保持原来的限制。 禁用了Auto-RollOver，可以手动调整scn兼容性(前提是应用了补丁)。

 

 


 三 关于这次SCN兼容性自动触发的原理 

在高版本的数据库中引入了SCN 兼容性参数( Compatibility)，而且在这个特性中设置了时间限制。

在Oracle数据库软件内核中， 引入了一个： Auto-RollOver 的机制 。

也就是说Oracle 为不同 SCN 兼容性设定了触发时间，随着时间推移自动迭代，用户会在不知情的情况下自动应用了新的SCN 兼容性。

当在2019年6月23日后，整体数据库环境中，有高版本(定义参看上)创建后， 由于SCN允许最高SCN新增速率会有可能有较高的SCN，而未打补丁的数据库处于较低的SCN级别(可能会出现通过dblink连接这两个数据库,由于DBLINK的特性（两端数据库必须同步SCN）,如果SCN增加修改数据库的同步超出它的允许SCN率或当前最大的SCN限制,无法建立连接,那么dblink被拒绝，导致业务中断。

 

 


四 查看SCN兼容性级别和调整时间

数据库版本在11.2.0.3.9之前没有打dblink的补丁则没有DBMS_SCN包。

 

在11g版本可以通过sqlplus连接至数据库执行以下语句

set serveroutput on

declare

rsl number;

headroom_in_scn number;

headroom_in_sec number;

cur_scn_compat number;

next_compat number;

max_scn_compat number;

auto_rollover_ts date;

is_enabled boolean;

begin

dbms_scn.getcurrentscnparams(rsl,headroom_in_scn,headroom_in_sec,cur_scn_compat,max_scn_compat);

dbms_scn.getscnautorolloverparams(auto_rollover_ts,next_compat,is_enabled);

dbms_output.put_line(‘RSL=’||rsl);

dbms_output.put_line(‘headroom_in_scn=’||headroom_in_scn);

dbms_output.put_line(‘headroom_in_sec=’||headroom_in_sec);

dbms_output.put_line(‘CUR_SCN_COMPAT=’||cur_scn_compat);

dbms_output.put_line(‘NEXT_COMPAT=’||next_compat);

dbms_output.put_line(‘MAX_SCN_COMPAT=’||max_scn_compat);

dbms_output.put_line(‘auto_rollover_ts=’||to_char(auto_rollover_ts,’YYYY-MM-DD’));

if(is_enabled) then

dbms_output.put_line(‘Auto_rollover is enabled!’);

else

dbms_output.put_line(‘Auto_rollover is disabled!’);

end if;

end;

/

样例输出

 

当前auto rollover是启用且在2019年6月23日自动调整SCN兼容级别为3

五 如何判断是否需要应用补丁调整策略

5.1符合以下条件则无需关注SCN兼容性自动变化及相关补丁信息

所有有DBLINK传输数据数据库的集合版本均为低版本（11.1.0.7/11.2.0.3/12.1.0.1之前版本）或均为高版本(11.2.4/12.1.0.2/12.2及以上)，且未来不会有版本和dblink交叉传输数据需求的变化

 

5.2对于11.1.0.7、11.2.0.3和12.1.0.1版本的数据库

 

这些补丁增加了数据库当前最大SCN限制，从16k/s到96k/s，且默认为2019年6月24日启动生效，允许更高的SCN速率，使数据库能够支持比早期版本高许多倍的事务速率。

 

在2019年6月23日之前安装补丁后，可以通关闭autorollover的特性，来规避scn兼容性自动变更到3。命令如下：

sqlplus连接至数据库

Exec dbms_scn. DisableAutoRollover ;

在2019年6月23日之后安装的高版本（定义参看上）数据库环境设置scn 兼容性至1.命令如下：

sqlplus连接至数据库

ALTER DATABASE SET SCN COMPATIBILITY 1;

 

5.3对于上表中Oracle官方没有提及的数据库版本如10.2或更老的数据库 

充分评估业务将来可能出现的dblink传输数据的场景，考虑升级数据库或不使用dblink通过JDBC等其他方式进行数据传输。

对于10g数据库在安装完10.2.0.5.171017的PSU以及补丁14121009。

 

 

5.4安装相应补丁后将SCN的异常情况记录到alert日志中 

我们建议通过控制SCN Headroom的告警阀值使得数据库可以尽可能的将DBLINK传播SCN的行为在alert日志中提现出来，目前我们建议将_external_scn_logging_threshold_seconds设置为600秒左右，使得通过DBLINK传递导致SCN Headroom过低产生alert告警。

alter system set “_external_scn_logging_threshold_seconds”=600 scope=spfile;

 

参考《Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (Doc ID 2361478.1)》

关于Oracle高版本SCN兼容性 变化的处理建议

引用自： Doc ID 1577660.1

升级到19c的升级兼容性

  能够直接升级到Oracle Database 19c的数据库最小版本

源库 目标库
18 (所有版本) 19c
12.2.0.1 19c
12.1.0.2 19c
11.2.0.4 19c 
其他未在上面提到的数据库发布/版本不支持直接升级到19c。
所以首先升级到中间Oracle数据库版本，然后可以直接升级到19c。

升级到18c的升级兼容性矩阵

注意：对于 Exadata 18.1 数据库已经发布了，  对于 On-Premise 数据库 18.3 发布了。

  能够直接升级到Oracle Database 18.1的数据库最小版本

源库 目标库
12.2.0.1 18c
12.1.0.1 / 12.1.0.2 18c
11.2.0.3 / 11.2.0.4 18c 
如果不是上述提到的数据库版本，直接升级到18c是不support的。
因此，首先升级到Oracle数据库的中间版本，然后可以将其直接升级到18c版本。

升级到12.2.x的升级兼容性矩阵

能够直接升级到Oracle 12c Release 2的数据库最小版本

                              源库                         目标库
                                 11.2.0.3 / 11.2.0.4                                  12.2.x
                                 12.1.0.1 / 12.1.0.2                                  12.2.x

以下的数据库版本需要间接升级

源库  升级路径 目标库
11.2.0.2 –> 11.2.0.4/12.1.0.2 –> 12.2.x
11.2.0.1 –> 11.2.0.4 –> 12.2.x
11.1.0.7 –> 11.2.0.4/12.1.0.2 –> 12.2.x
11.1.0.6 –> 11.2.0.4 –> 12.2.x
10.2.0.5 –> 11.2.0.4/12.1.0.2 –> 12.2.x
10.2.0.2 /10.2.0.3/10.2.0.4 –> 11.2.0.4 –> 12.2.x
10.2.0.1 –> 10.2.0.5 –>   11.2.0.4/12.1.0.2 –> 12.2.x
10.1.0.5 –> 11.2.0.4 –> 12.2.x
10.1.0.4(或更低版本) –> 10.2.0.5 –> 11.2.0.4/12.1.0.2 –> 12.2.x
9.2.0.8 –> 11.2.0.4 –> 12.2.x
9.2.0.7(或更低版本) –>   9.2.0.8 –> 11.2.0.4 –> 12.2.x

升级到12.1.x的升级兼容性矩阵

能够直接升级到Oracle 12c Release 1的数据库最小版本

源数据库

        目标数据库

10.2.0.5

12.1.x

11.1.0.7

12.1.x

11.2.0.2 (或更高版本)

12.1.x

以下的数据库版本需要间接升级。

源数据库

升级路径

目标数据库

11.2.0.1

=> 11.2.0.2 或更高版本 =>

12.1.x

11.1.0.6

=> 11.1.0.7 or 11.2.0.2 或更高版本 =>

12.1.x

10.2.0.4 (或更低版本)

=> 10.2.0.5 或之后的直接升级版本 =>

12.1.x

10.1.0.5 (或更低版本)

=> 10.2.0.5 或之后的直接升级版本 =>

12.1.x

9.2.0.8 (或更低版本)

=> 9.2.0.8 –> 11.2.0.2 或更高版本 =>

12.1.x

升级到11.2.x的升级兼容性矩阵

能够直接升级到Oracle 11g Release 2的数据库最小版本

源数据库

         目标数据库

9.2.0.8   (或更高版本)

11.2.x

10.1.0.5 (或更高版本)

11.2.x

10.2.0.2 (或更高版本)

11.2.x

11.1.0.6 (或更高版本)

11.2.x

 

以下的数据库版本需要间接升级。

源数据库

升级路径

目标数据库

7.3.3 (或更低版本)

=> 7.3.4.0 => 9.2.0.8 =>

11.2.x

8.0.5 (或更低版本)

=> 8.0.6.x => 9.2.0.8 =>

11.2.x

8.1.7 (或更低版本)

=> 8.1.7.4 => 10.2.0.4 =>

11.2.x

9.0.1.3 (或更低版本)

=> 9.0.1.4 => 10.2.0.4 =>

11.2.x

9.2.0.7 (或更低版本)

=> 9.2.0.8 =>

11.2.x

 

更多信息，请参阅以下链接:
http://docs.oracle.com/cd/E11882_01/server.112/e23633/preup.htm#UPGRD12358

（以上链接会定向到Oracle Technology Network，需要OTN的用户名和密码进行访问）

升级到11.1.x的升级兼容性矩阵

能够直接升级到Oracle 11g Release 1的数据库最小版本

源数据库

          目标数据库

9.2.0.4   (或更高版本)

11.1.x

10.1.0.2 (或更高版本)

11.1.x

10.2.0.1 (或更高版本)

11.1.x

 

以下版本的数据库需要间接升级。

源数据库

升级路径

目标数据库

7.3.3 (或更低版本)

=> 7.3.4.0 => 9.2.0.8 =>

11.1.x

8.0.5 (或更低版本)

=> 8.0.6.x => 9.2.0.8 =>

11.1.x

8.1.7 (或更低版本)

=> 8.1.7.4 => 9.2.0.8 =>

11.1.x

9.0.1.3 (或更低版本)

=> 9.0.1.4 => 9.2.0.8 =>

11.1.x

9.2.0.3 (或更低版本

=> 9.2.0.4.0 =>

11.1.x

 

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28300/preup.htm#CEGEIBHC

(以上链接会定向到Oracle Technology Network，需要OTN的用户名和密码进行访问)

升级到10.2.x的升级兼容性矩阵

能够直接升级到10.2.x的数据库最小版本

源数据库

目标数据库

8.1.7.4   (或更高版本)

10.2.x

9.0.1.4   (或更高版本)

10.2.x

9.2.0.4   (或更高版本)

10.2.x

10.1.0.2 (或更高版本)

10.2.x

以下版本的数据库需要间接升级。

源数据库

升级路径

目标数据库

7.3.3 (或更低版本)

=> 7.3.4 => 8.1.7 =>8.1.7.4 =>

10.2.x

7.3.4 (或更低版本)

=>8.1.7 => 8.1.7.4 =>

10.2.x

8.0.n (或更低版本)

=>8.1.7 => 8.1.7.4 =>

10.2.x

8.1.n (或更低版本)

=>8.1.7 => 8.1.7.4 =>

10.2.x

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14238/preup.htm#CEGEIBHC

升级到10.1.x的升级兼容性矩阵

能够直接升级到10.1.x的数据库最小版本

源数据库

目标数据库

8.0.6  (或更高版本)

10.1.x

8.1.7  (或更高版本)

10.1.x

9.0.1 (或更高版本)

10.1.x

9.2.0 (或更高版本)

10.1.x

以下版本的数据库需要间接升级。

源数据库

升级路径

目标数据库

7.3.4 (或更低版本)

=> 8.0.6 =>

10.1.x

8.0.5 (或更低版本)

=> 8.0.6 =>

10.1.x

8.1.6 (或更低版本)

=> 8.1.7 =>

10.1.x

 

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10763/preup.htm#CEGEIBHC

升级到9.2.x的升级兼容性矩阵

能够直接升级到9.2.x的数据库最小版本

源数据库

目标数据库

7.3.4 (或更高版本)

9.2.x

8.0.6 (或更高版本)

9.2.x

8.1.7 (或更高版本)

9.2.x

9.0.1 (或更高版本)

9.2.x

以下版本的数据库需要间接升级。

源数据库

升级路径

目标数据库

7.3.3 (或更低版本)

=> 7.3.4 =>

9.2.x

8.0.5 (或更低版本)

=> 8.0.6 =>

9.2.x

8.1.6 (或更低版本)

=> 8.1.7 =>

9.2.x

 

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B10501_01/server.920/a96530/migprep.htm#1006863

降级

 

从19c降级的降级兼容性矩阵

 

源数据库

                  可能降级到

Non-CDB 19c

18c,12.2.0.1,12.1.0.2,12.1.0.1,11.2.0.4

PDB/CDB 19c

18c,12.2.0.1,12.1.0.2

更多的信息，请参考 19c Downgrade link.

 

从18c降级的降级兼容性矩阵

 

源数据库

                   可能降级到

Non-CDB 18c

12.2.0.1,12.1.0.2,12.1.0.1,11.2.0.4

PDB/CDB 18c

12.2.0.1,12.1.0.2

更多的信息，请参考 18c Downgrade link.

从12.2降级的降级兼容性矩阵

 

源数据库

                   可能降级到

Non-CDB 12.2

12.1.0.2,12.1.0.1,11.2.0.4,11.2.0.3

PDB/CDB 12.2

12.1.0.2

更多的信息，请参考 12.2 Downgrade link.

从12.1.x降级的降级兼容性矩阵

源数据库

          可能降级到

12.1.x

11.1.0.7

12.1.x

11.2.0.2.0 (或更高版本)

更多信息，请参阅以下链接:
http://docs.oracle.com/cd/E16655_01/server.121/e17642/downgrade.htm#i1010267

注意：
你不能降级到10.2.0.5因为Oracle Database 12c的最小兼容版本是11.0。
你不能降级一个从Oracle Database Express Edition升级上来的数据库。

从11.2.x降级的降级兼容性矩阵

源数据库

              可能降级到

11.2.x

10.1.0.5.0 (或更高版本)

11.2.x

10.2.0.2.0 (或更高版本)

11.2.x

11.1.0.6.0 (或更高版本)

更多信息，请参阅以下链接:
http://docs.oracle.com/cd/E11882_01/server.112/e23633/downgrade.htm#UPGRD00710

从11.1.x降级的降级兼容性矩阵

源数据库

               可能降级到

11.1.x

10.1.0.5.0 (或更高版本)

11.1.x

10.2.0.3.0 (或更高版本)

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28300/downgrade.htm#i1010243

从10.2.x降级的降级兼容性矩阵

源数据库

可能降级到

10.2.x

9.2.0.6.0 (或更高版本)

10.2.x

10.1.0.4.0 (或更高版本)

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14238/downgrade.htm#i1010243

从10.1.x降级的降级兼容性矩阵

源数据库

可能降级到

10.1.x

9.2.0.4.0 (或更高版本)

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10763/downgrade.htm#i1010243

从9.2.x降级的降级兼容性矩阵

源数据库

可能降级到

9.2.x

9.0.1.3.0 (或更高版本)

9.2.x

8.1.7.3.0 (或更高版本)

更多信息，请参阅以下链接:
http://download.oracle.com/docs/cd/B10501_01/server.920/a96530/downgrad.htm#1008177

注意
1 : 如果您在升级后打了某个补丁集，那么将不能降级。
例如：如果您从9.2.0.6 升级到 10.2.0.1，然后打上了10.2.0.3的补丁集，那么您将不能从10.2.0.3 降级到 9.2.0.6. （只有当您直接升级9.2.0.6 到 10.2.0.3，您才能从10.2.0.3 降级到 9.2.0.6）

2 : 您只能降级到和您数据库升级前一样的版本。
例如：只有您的数据库是从10.2.0.3升级到11.1.0.6的话，才能从11.1.0.6降级到10.2.0.3。如果您创建了新的11.1.0.6数据库，那么您不能将数据库降级到10.2.0.3。而且，如果您直接升级9.2.0.8 到 11.1.0.6，那么您也不能降级到10.2.0.3，因为您的数据库不是从10.2.0.3升级的。

3 : 如果数据库参数COMPATIBLE设置为比您升级前数据库版本更高的版本，您将不能做降级。
例如：如果您从10.2.0.3 升级到 11.1.0.6，之后设置COMPATIBLE 为 11.1.0.6，您不能做降级。而且，如果您从9.2.0.8 直接升级到 11.1.0.6之后设置COMPATIBLE 为10.2.0.1，您也不能做降级。

4 : 您不能升级一个发行版的数据库二进制文件到另一个发行版
例如：您不能升级10.1.0.2.0的二级制文件 到 10.2.0.1.0。发行版必须在一个单独的oracle home下安装。您不能将10.2.0.x安装在任何其他发行版的oracle home下来完成升级。

升级到 oracle 19c 的版本差异

Oracle 12c 升级失败的降级步骤

Oracle 12c 升级失败的降级步骤

 

降级前步骤
– XML DB 组件在 12c 中是必需的。
在升级到 12c 期间，将安装 XML DB 组件（如果未安装）。
从 12c 降级将删除安装的 XDB 组件

- Enterprise Manager 不支持降级。在降级之前，请重新配置 Oracle EM 控件。请参阅
Oracle Database Upgrade Guide 12c Release 1 (12.1) E17642-10
6 Downgrading Oracle Database to an Earlier Release
6.6.5 Restoring Oracle Enterprise Manager after Downgrading Oracle Database

- 升级到 12c 期间，将删除 Database Control 资料档案库。降级之后，需重新配置 DB Control。

Note 870877.1 How To Save Oracle Enterprise Manager Database Control Data Before Upgrading The Single Instance Database To Other Release ?
Note 876353.1 How To Restore The Oracle Enterprise Manager Data To Downgrade The Single Instance Database To Previous/Source Release ?
- compatible 参数不能已经更改到 12.1.0。
- 禁用 Data Vault（如果已启用）。
Note 803948.1  How To Uninstall Or Reinstall Database Vault in 11g (UNIX)
Note 453902.1 Enabling and Disabling Oracle Database Vault in WINDOWS
- 如果数据库使用 Oracle Label Security，则在新 Oracle Database 12c Oracle 主目录中运行 Oracle Label Security (OLS) 预处理降级 olspredowngrade.sql 脚本（在 $ORACLE_HOME/rdbms/admin 上提供）。注意！此步骤仅在需要降级到12c之前的版本时才需要
- 时区版本应相同。假设升级数据库的过程中时区版本也被升级了，那么要在升级前在源库打patch。例如11.2.0.4已经升级到12.1.0.2.0，时区作为升级的一部分也升级到了18，那么在降级到11.2.0.4.0之前，在11.2.0.4.0的home上打时区patch 18。
- 取消设置并指向 12c 主目录的 ORA_TZFILE（如果已设置）。
- 如果数据库上有 Oracle Application Express，则必须将 apxrelod.sql 文件从 Oracle Database 12c $ORACLE_HOME/apex/ 目录复制到 Oracle 主目录之外的目录，例如系统上的临时目录以稍后执行。
- 如果基于固定对象创建了对象，则删除这些对象以避免可能的 ORA-00600 错误。您可以在降级之后重新创建这些对象。
- 如果降级集群数据库，则彻底关闭实例并将 CLUSTER_DATABASE 初始化参数更改为 FALSE。降级之后，必须将此参数设置回 TRUE。
- 假设在升级之后你已经在升级的数据库打了patch，那么在降级之前，在数据库级别使用datapatch回滚这些patch。

满足以上先决条件之后，可以继续进行降级。

数据库的降级步骤

1) 确保所有数据库组件有效。只能从成功升级的数据库执行降级。要验证数据库组件状态，请执行以下查询

以 SYS 用户身份连接到数据库

col comp_id format a10
col comp_name format a30
col version format a10
col status format a8

select substr(comp_id,1,15) comp_id,substr(comp_name,1,30) comp_name,substr(version,1,10) version,status from dba_registry

2) 验证没有属于 sys/system 的无效对象

select owner, count(object_name) "Invalid object count" from dba_objects where status!='VALID' and owner in ('SYS','SYSTEM') group by owner;

如果计数为零，则可以继续降级。

如果有无效对象，则执行 utlrp.sql 多次，如果对象无法解析为有效状态，则不能继续降级。建立 SR 或在 DBA 社区上发帖以寻求帮助。

或者，对于 1 和 2，运行以下脚本：

Note 556610.1  Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)

3) 关闭数据库

Shutdown immediate

4)  对 12c 数据库做备份

5)  以降级模式启动数据库

Startup downgrade;

6)  执行降级脚本

Sql> Spool downgrade.log

Sql> @$ORACLE_HOME/rdbms/admin/catdwgrd.sql

注：
$ORACLE_HOME 应指向 12c 主目录

catdwgrd.sql 脚本将数据库中的所有组件降级到支持的主版本或补丁集版本（您最初升级时的版本）

Sql> spool off

Sql> shutdown immediate

Exit SQL Plus

Sql> exit;

7) 如果操作系统为 LINUX/UNIX：

将以下环境变量更改为要降级到的源数据库：

ORACLE_HOME

PATH

编辑 /etc/oratab or /var/opt/oracle/oratab 以更改

将数据库映射到源数据库 Oracle 主目录

如果操作系统是 Windows，则完成以下步骤：


a. 停止所有 Oracle 服务，包括 Oracle Database 12c 数据库的 OracleServiceSID Oracle 服务，其中 SID 是实例名称。

例如，如果 SID 为 ORCL，则在命令行提示符中输入以下内容：

C:\> NET STOP OracleServiceORCL
b. 在命令提示符下，通过运行 ORADIM 命令删除 Oracle 服务。如果出现提示，则输入此 Windows 系统上活动标准用户帐户的口令。

例如，如果 SID 为 ORCL，则输入以下命令：

C:\> ORADIM -DELETE -SID ORCL
c. 在命令提示符下，使用 ORADIM 命令创建要降级的数据库的 Oracle 服务。

C:\> ORADIM -NEW -SID SID -INTPWD PASSWORD -MAXUSERS USERS

-STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

8) 还原配置文件

将配置文件（口令文件、参数文件等）还原到降级版本的 ORACLE_HOME。

9) 如果这是 Oracle RAC 数据库，则执行以下命令以将数据库修改为单实例模式：

SET CLUSTER_DATABASE=FALSE

10) 从降级版本 $ORACLE_HOME/rdbms/admin 目录执行 catrelod 脚本。

启动 sqlplus，以具有 sysdba 权限的用户 SYS 身份连接到数据库实例，然后以升级模式启动数据库：

: cd $ORACLE_HOME/rdbms/admin

: sqlplus

sql> connect sys as sysdba

sql> startup upgrade

sql> spool catrelod.log

sql> @?/rdbms/admin/catrelod.sql

sql> spool off

catrelod.sql 脚本在降级的数据库中重新加载各个数据库组件的合适版本。

11) 运行 utlrp.sql 脚本：

SQL> @utlrp.sql

Sql> exit;

utlrp.sql 脚本重新编译先前处于 INVALID 状态的所有现有 PL/SQL 模块，例如 package、procedure、type 等。

12) 检查已降级数据库的状态：

Note 556610.1  Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)
此 sql 脚本是一组查询语句，用在升级前后诊断数据库的状态。脚本将创建名为 db_upg_diag__<时间戳>.log 的文件。

13) 降级之后，可能在 sys 用户下发现无效的 QT 视图。这是因为视图已从基表中选择了错误的列。需要重新创建这些视图。

请参阅说明：

Note 1520209.1 QT_*BUFER Views Invalid after downgrade from 12C

降级后步骤：
1)如果是降级到 Oracle Database 11g 版本 1 (11.1.0.7) 并且数据库中有 Oracle Application Express，则将 apxrelod.sql 脚本复制到的目录（在降级前步骤中）。
运行 apxrelod.sql 脚本以手动重新加载 Oracle Application Express：

SQL> @apxrelod.sql

运行 apxrelod.sql 脚本以避免程序包 APEX_030200.WWV_FLOW_HELP 由于以下错误而成为 INVALID 状态：

PLS-00201: identifier ‘CTX_DDL’ must be declared
2) 如果数据库中启用了 Oracle Label Security，则执行以下脚本

a. 从 Oracle Database 12c 的 Oracle 主目录下将 olstrig.sql 脚本复制到要将数据库降级到的版本的 Oracle 主目录。

b. 从降级到的版本的 Oracle 主目录，运行 olstrig.sql 以在表上使用 Oracle Label Security 策略重新创建 DML 触发器：

SQL> @olstrig.sql

3) 如果降级集群数据库，则必须运行以下命令以降级 Oracle Clusterware database 配置：

$ srvctl downgrade database -d db-unique-name -o oraclehome -t to_version
其中 db-unique-name 是数据库名称（而非实例名称），oraclehome 是已降级数据库的旧 Oracle 主目录的位置，to_version 是数据库所降级到的数据库版本

因为代码的改变，现在-to_version对应的值如下:

RDBMS Version -to_version Value
9.2.0.*              9.2.0.0.0
10.1.0.*            10.0.0.0.0
10.2.0.*            10.2.0.0.0
11.1.0.*            11.0.0.0.0
11.2.0.1            11.2.0.1.0
11.2.0.2            11.2.0.2.0
11.2.0.3            11.2.0.3.0
11.2.0.4            11.2.0.4.0

4) 如果发现失效的SYS/SYETEM的对象，那么可以使用下面的方法来编译这些失效对象

$ sqlplus "/ as sysdba"
SQL> startup upgrade
SQL> spool catout.log
SQL> @?/rdbms/admin/catproc.sql
SQL> @?/rdbms/admin/utlrp.sql
SQL> spool off
SQL> shutdown immediate

5) 如果数据库从11.2.0.4升级到12.1.0.2之前没有安装XDB，那么在降级回11.2.0.4的时候，XDB的对象需要被移除。然而，我们还是可以发现无效的XDB对象残留在数据库中。这已经被记录为一个bug 22854967，patch已经可以下载了。

Invalid XDB-related Objects After Downgrading To 11.2.0.4 (Doc ID 2163596.1)

Database Oracle Oracle 排障配置与调整 数据技术 未分类 | Guang Cai Li |