Skip to content

Oracle - 19. page

手动升级到 Non-CDB Oracle Database 12c（12.2）的核对清单

手动升级到 Non-CDB Oracle Database 12c Release 2（12.2）的核对清单

步骤1：升级到数据库 12.2 的升级路径

能够直接升级到 Oracle 12c Release 2 (12.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.1 / 11.2.0.2 –> 11.2.0.4 –> 12.2.x
11.1.0.6 / 11.1.0.7 –> 11.2.0.4 –> 12.2.x
10.2.0.2/10.2.0.3/10.2.0.4/10.2.0.5 –> 11.2.0.4 / 12.1.0.2 –> 12.2.x
10.1.0.5 –> 11.2.0.4 / 12.1.0.2 –> 12.2.x
9.2.0.8 –> 11.2.0.3 / 11.2.0.4 –> 12.2.x

 

比如

  • 如果源库是 11.2.0.2 或者 11.1.0.7，那么你需要先升级至 11.2.0.4。
  • 如果源库是 10.2.0.2，10.2.0.3，10.2.0.4，10.2.0.5 或者 10.1.0.5，需要先升级至 11.2.0.4 或者 12.1.0.2。
  • 对于 9.2.0.8 版本的数据库，需要先升级至一个中间版本，比如：9.2.0.8 -> 11.2.0.3 或者 11.2.0.4 -> 12.1。

步骤2：推荐/需要在源库上完成的

 

  • 对源库做备份，冷备份或热备份都可以。
  • 禁用所有自定义的 before/after DDL 类型的触发器，完成升级后再启用它们。
  • 在 11g 数据库上定义的 Data security roles 不能自动转换成 ORAS。所以在升级前，需要删除所有在 11g 数据库上定义的 data security roles。升级后可以使用 Analytic Workspace Manager 12c 重新定义 data security roles。
  • 如果从 11g 升级到 12c 之前未删除 data security roles，那么所有的 data security policies 以及 data security role 都会在 12c 上失效。
  • Timezone 版本应当小于等于目标数据库的 Timezone 版本。
  • 如果源库上已经安装了 APEX 组件，那么升级数据库前需要先在源库上升级 APEX 组件。

步骤3：推荐/需要在目标库上完成的

 

  • 需要先检查您的硬件平台/操作系统是否兼容 12.2。点击此处来确定兼容性。
  • 安装数据库软件 12.2.0.1，并确保没有安装方面的问题。
  • 如果有的话，下载并应用最新的 PSU。
  • 从源库的 ORACLE_HOME/dbs 下拷贝 spfile 或者 pfile 到目标 ORACLE_HOME/dbs。
  • 从参数文件中删除所有废弃的参数。
  • 注意升级到 12.2 需要的最低的参数 COMPATIBLE 值为”11.2.0”，确保参数 COMPATIBLE 值设置为 11.2.0 或者更高。
  • 查看文档 “Patches to apply before upgrading Oracle GI and DB to 12.2.0.1 (Doc ID 2180188.1)” 给出的推荐补丁

步骤 4：检查源库的健康状况

 

  • 执行 dbupgdiag.sql（可以从 note 556610.1 下载这个脚本），并且确认是否有 SYS/SYSTEM 用户下的失效对象或者失效组件。如果存在的话，那么需要在升级前解决这些问题。你可以多次执行 utlrp.sql 来解决问题。如果在这样做之后仍然存在失效对象，那么开一个 SR 来解决这个问题。
  • 多次执行脚本 utlrp.sql 确认数据库中没有失效对象。

 

步骤5：升级前检查

 

清理数据库

 

清空回收站
检查 SYS 及 SYSTEM 用户的失效对象
检查 SYS 及 SYSTEM 用户下的重复对象
检查失效的、必需的、废弃的组件

 

检查物化视图

 

检查所有的物化视图的状态，刷新所有没有刷新的物化视图。
检查物化视图日志的大小，如果物化视图日志的行数非零，那么刷新物化视图。
检查 direct loader 日志以及 PMOP 日志（分区维护操作日志），如果 direct loader log 或者 PMOP 日志非空，那么刷新日志显示的物化视图。
升级数据库前，必须确保所有的物化视图都已经刷新完毕。

 

1. 执行下面的 SQL 查询：

 

SQL> SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) =8; 

性能方面

 

保存性能相关指标
检查网络性能
收集优化器统计信息

收集统计信息可以减少停机时间，Oracle建议使用 DBMS_STATS.GATHER_DICTIONARY_STATS 来收集这些统计信息，比如：

 

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

检查时区设置

 

Oracle database 12.2 的默认 time zone 文件版本是 V26。
源库的 time zone 文件版本应该小于或者等于目标库的 time zone 文件版本。如果源库的 time zone 文件版本更高，那么需要升级目标库的 time zone 文件版本来对应源库的 time zone 文件。

 

备份数据库

 

备份数据库，创建 guaranteed flashback restore point。
在升级数据库窗口前应最少测试一下回滚策略。确保回滚策略不仅考虑到升级中，同时也要考虑到升级后的失败。

1）连接到 RMAN

rman “target / nocatalog”
2）执行 RMAN 脚本来备份
RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT ‘some_backup_directory%U’ TAG before_upgrade;
BACKUP CURRENT CONTROLFILE FORMAT ‘controlfile location and name’;
}

 

确保升级前所有的文件都没有处于备份模式

 

执行下面的语句：

 

SQL> SELECT * FROM v$backup WHERE status != ‘NOT ACTIVE’; 

 

清空回收站

 

要清空回收站，执行下面的语句：

SQL> PURGE DBA_RECYCLEBIN

注意：升级前务必清空回收站来避免 ORA-00600 错误并且减少升级时间。

 

 

备份 Oracle EM DB Control 配置及数据

 

如果在升级数据库到 12.2 版本后，有需要再降级，那么我们必须在升级前使用 emdwgrd 工具备份 Database Control 的文件，这样在降级后可以恢复这些文件。

 

备份数据的步骤：

 

1. 安装 12.2 的数据库软件。
2. 设置 ORACLE_HOME 到旧的数据库版本。
3. 设置 ORACLE_SID 为要升级的数据库 SID。
4. 设置 PATH， LD_LIBRARY_PATH 和 SHLIB_PATH 到旧的 ORACLE_HOME 相关的目录下。
5. 切换目录到 12c 数据库软件的 ORACLE_HOME/bin。
6. 执行 emdwgrd。

对于单数据库实例 （非 RAC） 运行下面的命令：

 

emdwgrd[sh|bat] -save -sid old_SID -path save_directory

Oracle Real Application Clusters（Oracle RAC）数据库：

需要跨节点远程拷贝。定义一个环境变量 EM_REMCP 来指向远程拷贝的命令，比如：export EM_REMCP /usr/bin/scp

emdwgrd -save -cluster -sid old_SID -path save_directory

7. 输入 SYS 密码。

 

使用 emremove.sql 手工删除 DB control

 

1）关闭 DB control

emctl stop dbconsole

 
2）使用 sysdba 登陆

SQL>SET ECHO ON
SQL>SET SERVEROUTPUT ON
SQL>@emremove.sql >> 脚本位于新的 12c ORACLE_HOME/rdbms/admin

从系统中手工删除 ORACLE_HOME/HOSTNAME_SID/ 和 ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SID 目录。
如果是 windows 系统则删除 DB Console service OracleDBConsoleSID。

 

删除 JSON-Enabled Context search 索引

 

如果源库版本为 12.1.0.2 并且创建了 JSON search index 那么 Oracle 推荐先删除这些索引，在升级后再创建回来。

 

检查使用大小写不敏感密码的用户

 

使用管理用户登录 SQL*Plus，并且执行下面的语句：

 

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

如果存 在10g 版本的用户，建议根据 Oracle 文档解决这个问题，否则升级后用户会被 LOCK。

 

删除 Unified Auditing Schema and Roles

 

注意：如果在 Oracle 12.1 数据库上已经创建了 AUDIT_ADMIN   或者 AUDIT_VIEWER 用户或者 roles，或者数据库是在 12.1 版本上创建（而不是升级上来的），那么不需要删除这些 role 和 AUDSYS 用户。

更多信息请参照 URL：

 

https://docs.oracle.com/database/122/UPGRD/unified-auditing-audit_admin-audit_viewer-changes.htm#UPGRD60010

 

使用 SYS 以 SYSDBA 权限登录 SQL*Plus，删除 AUDSYS，如果存在的话。以 migrate 模式启动数据库并删除 AUDSYS 用户

 

SQL> startup migrate pfile=$T_WORK/t_init1.ora
ORACLE instance started.
SQL> drop user audsys cascade;

删除 AUDIT_ADMIN 和 AUDIT_VIEWER roles

DROP ROLE AUDIT_ADMIN;
DROP ROLE AUDIT_VIEWER;

 

在升级过程中把某些 schema 的表空间置于 offline

 

记下所有在升级过程中需要 offline 的表空间，使用 -T 选项指定表空间的名字

 

dbupgrade –T

从 Oracle database 12.2 开始，可以在并行升级时使用 -T 参数来 offline 一些用户表空间。把用户表空间 offline 可以减少升级前的备份工作。并行升级工具（catctl.pl）可以自动选取正确的表空间来设置为只读。这个工具不会把任何包含Oracle 自带的对象的表空间设置为只读。

 

保留降级的能力

 

如果计划把数据库降级到之前的版本，那么需要在源库上打 patch 20898997，否则不能降级。

在源库执行：

$ORACLE_HOME/OPatch/opatch lsinventory -bugs_fixed |grep –i “20898997”

 
如果尚未应用这个补丁，那么从 MOS 下载 patch 20898997 并安装。

 

关于 Audit table 的升级前要求

 

 

如果要升级的数据库版本低于 12.1 并且使用了 Oracle database Vault，Oracle Label Security，那么必须先执行 olspreupgrade.sql。从目标 Oracle_home 拷贝 $ORACLE_HOME/rdbms/admin/olspreupgrade.sql 到源库的ORACLE_HOME，使用 DVOWNER 登陆源库

 

SQL> GRANT DV_PATCH_ADMIN to SYS;

在把 DV_PATCH_ADMIN 权限赋给 SYS 后，使用 SYSDBA 登陆执行 olspreupgrade.sql

 

SQL>ORACLE_HOME/rdbms/admin/olspreupgrade.sql

执行完毕后，以 DVOWNER 登陆数据库并收回 SYS 的 DV_PATCH_ADMIN 权限

 

SQL> REVOKE DV_PATCH_ADMIN from SYS;

 

集群数据库的需要

 

在升级数据库前需要先升级 GI 软件。如果是 RAC，那么需要把参数文件中的 CLUSTER_DATABASE 参数设置为 false。

注意！在升级完毕后需要把CLUSTER_DATABASE再设置回来

 

其它检查

 

1. 确保 ARCHIVE_LOG 以及 FLASHBACK 目录有足够的磁盘空间。

2. 执行下面的查询来检查是否有和SDO_GEOMETRY关联的表

 

col owner format a15
col table_name format a30
col column_name format a30
SELECT owner,table_name,column_name FROM dba_tab_columns WHERE data_type = ‘SDO_GEOMETRY’ AND owner != ‘MDSYS’ ORDER BY 1,2,3;

如果有返回行数，那么在升级前需要往12.2的ORACLE HOME上打补丁 patch 25293022

 

步骤6：Preupgrade 步骤

 

在源库执行 Preupgrade 脚本

 

$Earlier_release_Oracle_home/jdk/bin/java -jar $New_release_Oracle_home/rdbms/admin/preupgrade.jar FILE TEXT DIR output_dir

 

FILE – 使用这个参数把输出写入输出文件
TEXT – 使用这个参数指定日志格式为 TEXT 模式（如果不指定的话则为 XML 格式）
DIR – 日志会创建在<output_dir>指定的这个目录中

 

建议执行 pre-upgrade 的 fixup 脚本，如果发现的问题是可以使用这个脚本修复的话。

 

Network Utility 包的依赖关系

 

执行下面的语句

 

SQL> SELECT * FROM DBA_DEPENDENCIES WHERE referenced_name IN (‘UTL_TCP’,’UTL_SMTP’,’UTL_MAIL’,’UTL_HTTP’,’UTL_INADDR’,’DBMS_LDAP’) AND owner NOT IN (‘SYS’,’PUBLIC’,’ORDPLUGINS’);

 

在升级测试中，确保使用新的访问控制。在升级后确保这些包是可用的，在升级后，根据源库的使用情况赋予正确的权限。

 

检查 Time zone 文件版本

 

检查目标数据库的 time zone 文件版本是否低于源库的 time zone 文件版本，如果是的话，需要升级目标数据库的 time zone 文件版本。数据库 DST 补丁可以从 Note 412160.1 下载。

 

步骤7：升级数据库到 12.2

 

设置环境变量指向目标 ORACLE_HOME

 

export ORACLE_HOME=<Oracle 12.2的目录>
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_BASE=<安装时指定的Oracle_Base目录>

 

使用目标 ORACLE_HOME（设置 ORACLE_HOME 为目标 ORACLE_HOME）启动数据库到 upgrade 模式

 

CONNECT / AS SYSDBA
SQL> startup upgrade;
SQL> exit

在 Linux/Unix 上

cd $ORACLE_HOME/bin
./dbupgrade 

在 Windows 上

cd %ORACLE_HOME%\bin
dbupgrade

执行 Post-Upgrade Status 工具，utlu122s.sql 并且检查升级的日志。在新的版本下执行 Post-Upgrade Status 工具。

 

$ sqlplus “/as sysdba”
SQL> STARTUP
SQL> @utlu122s.sql

 

检查升级日志看是否脚本 catuppst.sql 已被执行。如果尚未执行，那么在新的 ORACLE_HOME 里手工执行。这个脚本被放置在 $ORACLE_HOME/rdbms/admin 目录。

SQL> @catuppst.sql

在另一个 session 里执行 utlrp.sql 来编译 stored PL/SQL 和 Java 代码。

SQL> @utlrp.sql

检查诊断升级/迁移相关的状态的 Oracle 数据字典。dbupgdiag.sql 脚本可以收集和升级迁移诊断信息有关的数据字典的信息，可以在升级的数据库上以 SYS 用户来执行它，关于更多信息，请参考文档 Note 556610.1 Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)

如果脚本 dbupgdiag.sql 发现了失效对象，执行 $ORACLE_HOME/rdbms/admin/utlrp.sql (多次) 来使它们生效，直到失效对象的个数不再改变。之后重新执行 dbupgdiag.sql 并确保没有任何问题。

如果使用了集群，那么必须升级这个数据库的 Oracle Clusterware keys，运行 srvctl 来完成，比如：

ORACLE_HOME/bin/srvctl upgrade database -db name -o ORACLE_HOME

 

步骤8：升级后步骤

 

在 Linux 和 Unix 上设置环境变量

 

确保下面的环境变量指向了新的 ORACLE_HOME 对应的目录：

ORACLE_HOME
PATH

 

更新 oratab 文件

 

修改 /etc/oratab 文件对应的条目指向新的 ORACLE_HOME 目录

 

Post-upgrade fixup 脚本

 

执行 pre-upgrade 产生的 post-upgrade fixup 脚本

 

升级依赖 Oracle-Maintained 类型的表

 

从 Oracle 12.2 开始，必须手工升级依赖 Oracle-Maintained 类型的用户表。

在数据库升级后确认需要升级的用户表，使用 SYSDBA 连接到数据库并执行下面的语句来列出这些表：

 

COLUMN owner FORMAT A30
COLUMN table_name FORMAT A30
SELECT DISTINCT owner, table_name
FROM dba_tab_cols
WHERE data_upgraded = ‘NO’
ORDER BY 1,2;

使用 sysdba 权限的用户，或者有权限 alter 所有这些表的用户执行脚本 utluptabdata.sql：

 

SET SERVEROUTPUT ON
@utluptabdata.sql

 

启用新的 Extended Data Type 功能（并不是必须的）

 

启用 extended data types 需要一些特定的操作。

Oracle 数据库 12c 引入了扩展 VARCHAR2，NVARCHAR2，以及 RAW 数据类型的大小的功能。设置 MAX_STRING_SIZE = EXTENDED 可以扩展这些数据类型最大限制到32767字节。

要实现这个功能，初始化参数 COMPATIBLE 要设置为 12.0.0.0 或者更高。 关于更多信息，请参考Note 1570297.1

 

升级 Recovery Catalog

 

如果 recovery catalog schema 比要备份的数据库版本低，那么必须升级它。可以使用 UPGRADE CATALOG 命令来升级。

请参 照Oracle 文档的”Upgrading the Recovery Catalog” 部分来得到更多信息。

 

在升级数据库后升级 Time Zone 文件版本

 

如果 Pre-Upgrade Information 工具要求在升级数据库后升级 time zone 文件版本，那么需要使用 DBMS_DST PL/SQL 包来更新 RDBMS DST (timezone) 版本。

参照 Oracle 文档的”Steps to Upgrade Time Zone File and Timestamp with Time Zone Data” 部分以及 Note 1509653.1 “Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST”

 

升级统计信息表

 

如果之前使用 DBMS_STATS.CREATE_STAT_TABLE 创建了一些统计信息表，那么使用 DBMS_STATS.UPGRADE_STAT_TABLE 来升级这些表。在下面的例子里，统计信息表的名字是’dictstattab’，而 SYS 是这个表的 owner。

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE(‘SYS’, ‘dictstattab’);

对所有的统计信息表都执行类似上面的语句。

 

升级外部验证的 SSL 用户

 

如果是从 9.2 或者 10.1 的数据库升级上来的，并且使用了外部验证的 SSL 用户，那么需要执行 SSL external users conversion (extusrupgrade) 脚本来升级这些用户。

ORACLE_HOME/rdbms/bin/extusrupgrade –dbconnectstring hostname:port_no:sid –dbuser db_admin –dbuserpassword password -a

 

在升级数据库后安装 Oracle Text Supplied Knowledge Bases

 

Oracle Text-supplied knowledge bases 是数据库 12c 的扩展产品的一部分，并不会在升级后立刻可用。所有依赖这个产品的 Oracle Text 功能在升级后都会不可用。如需重新启用这些功能，需要从安装介质安装 Oracle Text supplied knowledge bases。

 

升级数据库后更新 Oracle Application Express Configuration

 

如果要升级的数据库包含了 Oracle Application Express release 3.2 或更高版本，那么不需要做任何额外的操作。但是如果 Oracle Application Express 存在 registry里，那么 Oracle Application Express 是从低版本升级而来，那么需要设置open_cursors 参数最小为200。

 

对额外的 Network Services 配置访问控制列表（ACLs）

 

如果应用程序使用了 UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, 或者 UTL_INADDR 包，那么升级后需要配置这些包的网络访问控制列表 (ACLs)来让它们像之前版本一样正常工作。如果没有正确配置访问控制列表 (ACLs)，应用程序会碰到错误”ORA-24247: network access denied by access control list (ACL).”

 

检查参数 SQLNET.ALLOWED_LOGON_VERSION

 

10g 之前的客户端连接到 12c 数据库会碰到 ORA-28040: No matching authentication protocol 错误，请参考 Oracle 文档来解决 ORA-28040: No matching authentication protocol 问题。

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

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 |

关于Oracle数据库比特币敲诈的简单防御方法

由于17年到18年现在陆陆续续接到了不少新老客户的Oracle database受此类恶意脚本的攻击，我们也积累了一些防范此类问题的措施，在此篇中简单介绍2种容易的被动防御方法：

 

1.创建此类攻击脚本的对象名称进行占用（最简单最笨的方法）

 

DBMS_SUPPORT_INTERNAL

DBMS_SYSTEM_INTERNAL

DBMS_CORE_INTERNAL

对这三个对象名称进行占用处理。

 

2.对创建触发器的操作进行主动阻止

 

对主要的dba用户进行DDL操作的阻止，类似写法不再描述。

Access control Database Oracle Oracle security 数据技术 | Guang Cai Li |

OBJ$表上索引有坏块导致部分业务失效的修复

这种问题的解决办法有好几种，根据数据量的大小以及业务是否允许停机的情况考虑，主要分以下几类救急办法：

一、坏块在索引上的位置判断

1.1如果坏块不多，而且坏块都在在索引比较靠前的位置（这个靠前的位置每个版本不一样，每个版本的对象数不一样），可以理解为在建库时候obj$自带索引的那个块最大地址就是属于考前的位置，当坏块在这个位置前面时候有一种比较便捷的处理方式，

就是通过创建一个一模一样的数据库，使用bbed copy（相比DD操作，操作起来超级简单又不容易出错）把对应坏块位置的块copy覆盖损坏的块，apply后即可（如果是在obj$表中的块那么记得修改下obj里对应的create time即可使数据库恢复正常，这个在前面有个案例描述过）。

 

1.2如果坏块是在索引靠后的位置或者坏块很多，索引的对象为后面创建的对象，那么这个时候就比较麻烦了，好在obj$的数据是完整的，

我的建议是采用2种方法，

1.2.1  采用屏蔽obj$索引的方法，具体需要修改基表，这个方法在前面文章中有描述。这个情况一般用在数据库比较大，比如数据量有几十个T，上百T或者业务不能接受长时间停机的情况

1.2.2 当数据库的数据量不大的时候，可以采用另外一种办法，使用exp来导出数据进行修复，一般这个时候exp工具是无法直接使用的，需要使用到catexp.sql这个脚本，具体的方法请查阅博客里的文章 Corruptions on OBJ$ indexes

 

Oracle恢复 异常恢复 数据技术 | Guang Cai Li |

Oracle bootstrap$ 说明

What is bootstrap?

Bootstrap is a technique for loading the first few instructions of a computer program into active memory and then using them to bring in the rest of the program.

What is bootstrap in Oracle ?

In Oracle, Bootstrap refers to loading of metadata (data dictionary) before we OPEN the database.Bootstrap objects are classified as the objects (tables / indexes / clusters) with the object_id below 56 as bootstrap objects.  These objects are mandatory to bring up an instance, as this contains the most important metadata of the database.

What happens on database startup?

This shall be explained by setting the SQL_TRACE while opening the database.Connect as sysdba and do the following
SQL> startup mount ;
SQL> alter session set events ‘10046 trace name context forever, level 12 ‘ ;
SQL> alter database open ;
SQL>  alter session set events ‘10046 trace name context off ‘ ;
SQL> ORADEBUG SETMYPID
SQL> ORADEBUG TRACEFILE_NAME
The sql_trace of the above process explains the following operations behind startup. The bootstrap operation happens between MOUNT stage and OPEN stage.
1.)  The first SQL after in the above trace shows the creation of the bootstrap$ table. Something similar to the following:
create table bootstrap$ ( line# number not null, obj# number not null, sql_text varchar2(4000) not null) storage (initial 50K objno 56 extents (file 1 block 377))
This sys.bootstrap$ table contains the DDL’s for other bootstrap tables (object_id below 56). Actually these tables were created internally by the time of database creation (by sql.bsq), The create DDL passed between MOUNT and OPEN stage will be executed through different driver routines. In simple words these are not standard CREATE DDLs.
While starting up the database oracle will load these objects into memory (shared_pool), (ie) it will assign the relevant object number and refer to the datafile and the block associated with that. And such operations happen only while warm startup.
 The internals of the above explained in ‘kqlb.c’.
2.)  Now a query executed against the sys.bootstrap$ table, which holds the create sql’s for other base tables.
select line#, sql_text from bootstrap$ where obj# != :1 (56)
Subsequently it will create those objects by running those queries.
Object number 0 – (System Rollback Segment)
Object number 2 to 55 (Other base tables)
Object number 1 is NOT used by any of the objects.
3.) Performs various operations to keep the bootstrap objects in consistent state.
Upon the successful completion of bootstrap the database will do the other tasks like recovery and will open the database.

Which objects are classified as bootstrap objects in oracle database?

Objects with data_object_id less than 56 are classified as core bootstrap objects.The objects are added to the bootstrap. The objects affected are :

hist_head$
histgrm$
i_hh_obj#_col#
i_hh_obj#_intcol#
i_obj#_intcol#
i_h_obj#_col#
c_obj#_intcol#
From 10.1 the following objects have been added:
fixed_obj$
tab_stats$
ind_stats$
i_fixed_obj$_obj#
i_tab_stats$_obj#
i_ind_stats$_obj#
object_usage
These additional objects shall be re-classified (or) ignored by following methods.
1. Opening the database in migrate mode
2. Using event 38003
Event 38003 affects the bootstrap process of loading the fixed cache in  kqlblfc(). Per default certain objects are marked as bootstrap objects (even though they are not defined as such in sys.bootstrap$) but by setting the event they will be left as non-bootstrapped.

What is bootstrap process failure? or  ORA-00704

This ORA-00704 error SERIOUS if reported at startup. This error refers to some problem during bootstrap operation. Any ORA-00704 error on STARTUP / RECOVER is serious, this error normally rose due to some inconsistency with the bootstrap segments (or) data corruption on bootstrap$ (or) any of the base tables below object_id  56. After this error it might not allow to open that database.

When ORA-00704 shall occur?

1. There is a probable of this error when any unsupported operations are tried to force open the database.
2. This error can also occur when system datafile has corrupted blocks. (ORA-01578)
3. In earlier releases of oracle (prior to 7.3.4 and 8.0.3) this issue shall arise due to Bug 434596
The option is to restore it from a good backup and recover it.
-> If the underlying cause is physical corruption that is due to hardware problems then do complete recovery.
-> If the issue is not relating to any physical corruption, then the problem could be due some unsupported actions on Bootstrap, and a Point In Time Recovery would be an option in such cas.
Oracle Oracle恢复 异常恢复 数据技术 | Guang Cai Li |