Skip to content

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)

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

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

 

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

 

DBMS_SUPPORT_INTERNAL

DBMS_SYSTEM_INTERNAL

DBMS_CORE_INTERNAL

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

 

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

 

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

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 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.

8月12,又一次遭遇比特币勒索病毒,变种。

在国内一个汽车制造商的生产库中碰到该类问题。

相对比16年的那次,病毒变种了,增加了额外2个存储过程。当时客户的生产库离1200天还不到2个小时,但是庆幸还有备份。

···所以悄悄的作弊了,改系统时间,备份恢复后对相关的触发器和存储过程进行删除后,系统恢复运行。但是建议客户进行datapump数据干净导出。