Skip to content

Oracle 发布 18.3.0.0!!!!!!!!!!!

2018年7月23日 Oracle发布了18.3.0.0的版本,经过测试和资料查验,可以理解这个版本为12.2.0.2,意思就是这个是12c的稳定版本,类似12.1.0.2,11.2.0.2。

Oracle确实是在做重大变革,更新的频率和速度明显提升

目前可以在官网下载到linux版本的18.3.0.0数据库,4.3g

 

点击此链接访问下载位置:

18c文档的链接:

18c new fewtures介绍链接:

Oracle sharding in 18c

Sharding是一种数据层架构,其中数据在独立数据库中水平分区。

每个数据库都托管在具有自己的本地资源(CPU,内存,闪存或磁盘)的专用服务器上。 在这种配置中的每个数据库称为碎片。 所有分片一起组成一个逻辑数据库,称为分片数据库(SDB)

水平分区涉及跨分片拆分数据库表,以便每个分片包含具有相同列但行的不同子集的表。以这种方式分割的表也称为分片

下图显示了跨三个分片水平分区的表。

图1-1跨越碎片的表格的水平分区

下面是图1-1的描述
横跨碎片的水平分区”的描述

Description of Figure 1-2 follows

Oracle sharding的架构

分片基于无共享硬件基础架构,它消除了单点故障,因为分片不共享物理资源,如CPU,内存或存储设备。碎片在软件方面也松散耦合; 他们不运行集群件。

碎片通常托管在专用服务器上。这些服务器可以是商用硬件或工程系统。分片可以在单实例或Oracle RAC数据库上运行。它们可以放置在本地,云端或混合本地和云配置中。

从数据库管理员的角度来看,SDB由多个数据库组成,这些数据库可以集体或单独管理。但是,从应用程序的角度来看,SDB看起来像一个数据库:这些分片中的分片数量和数据分布对数据库应用程序是完全透明的。

分片适用于适用于分片数据库体系结构的自定义OLTP应用程序。使用分片的应用程序必须具有明确定义的数据模型和数据分布策略(一致的散列,范围,列表或复合),主要使用分片键访问数据。一个分片键的实例包括customer_idaccount_no,或country_id

 

Oracle 18c关于sharding的资料链接:

 

目前我们正在帮一个客户解决大表的分布式分区问题,采用的oracle shaerding 技术正在测试中,后续分享完整的过程。

NOLOGGING 操作引起的坏块 – 错误解释和解决方案

如果数据段定义为 NOLOGGING 属性,当 NOLOGGING/UNRECOVERABLE 操作修改该数据段或者使用datapump import 参数 disable_archive_logging:y,联机重做日志只记录很少的日志信息,如果之后执行 RECOVERY 操作的话,会导致这些块无效。

如果这些联机重做日志/归档日志被用来恢复数据文件,那么 Oracle 会将对应的数据块标志为无效,而且下一次访问这些数据块时,会报 ORA-1578 和 ORA-26040错误。

例如:

SQL> select * from test_nologging;

ORA-01578: ORACLE data block corrupted (file # 11, block # 84)
ORA-01110: data file 4: ‘/oradata/users.dbf’
ORA-26040: Data block was loaded using the NOLOGGING option

以下数据字典视图中的 LOGGING 列记录了 NOLOGGING 属性:

DBA_TABLES, DBA_INDEXES, DBA_LOBS, DBA_TAB_PARTITIONS, DBA_LOB_PARTITIONS, DBA_TAB_SUBPARTITIONS, 等等。

LOGGING=’NO’ 表示 NOLOGGING。

接下来,这些数据块会被标志为 Soft Corrupt,当下一次访问该数据块时,会报 ORA-1578 和 ORA-26040错误。

DATAPUMP 参数 DISABLE_ARCHIVE_LOGGING

DATAPUMP impdp 参数 DISABLE_ARCHIVE_LOGGING:Y 在import时禁止 LOGGING 定义,会产生NOLOGGING操作; 如果相应的datafile被restored 和 recovered, 那么接下来的语句会报错 ORA-1578 和 ORA-26040.

“如果database是 FORCE LOGGING 模式, 那么DISABLE_ARCHIVE_LOGGING 选项不会关闭logging.

import时使用这个参数的例子:

 

impdp scott/tiger directory=DATA_PUMP_DIR dumpfile=dp transform=disable_archive_logging:y

 

DBV 检测坏块时,如果 RDBMS 版本小于 10.2.0.4,那么 DBV 打印错误 DBV-200,如果 RDBMS 版本大于或等于 10.2.0.4,那么 DBV 打印错误 DBV-201  ( Note  5031712.8 ):

DBV-00200: Block, dba 46137428, already marked corrupted
DBV-00201: Block, DBA 46137428, marked corrupt for invalid redo application

“VALIDATE” RMAN 命令用来检测NOLOGGING数据块,检查结果记录在 view v$database_block_corruption (versions lower than 12c) 和 v$nonlogged_block (12c and greater).  下面的例子中检查出datafile 4 有 933 坏块,查询v$database_block_corruption 或者 v$nonlogged_block。

RMAN> VALIDATE DATABASE;

…..
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
4    OK     933            1            6401            2275124
File Name: /oracle/dbs/users.dbf

RMAN 检测坏块时,如果 RDBMS 版本小于 10.2.0.5 和 11.1.0.7,RMAN 打印如下错误:

10.2.0.4 and lower, 11.1.0.6, 11.1.0.7:

RMAN validate reports it in v$database_block_corruption with CORRUPTION_TYPE=LOGICAL

如果 RDBMS 版本大于或等于 10.2.0.5 和 11.2.0.1,RMAN 报告:查看视图 v$database_block_corruption 中 CORRUPTION_TYPE=NOLOGGING 的记录。参考 Note 7396077.8 :

10.2.0.5 and 11.2.0.1+:

RMAN validate reports it in v$database_block_corruption with CORRUPTION_TYPE=NOLOGGING

 

在12c及以后版本中,RMAN validate的结果不在视图v$database_block_corruption中,而是在视图v$nonlogged_block:

12c:

RMAN validate的结果显示在视图v$nonlogged_block

 

在12.2 版本, 可以使用新的命令:”validate .. nonlogged block” 去验证nologging的block。 在以下的例子中,数据文件5,6有nologged的block:

RMAN> validate database nonlogged block;

Starting validate at …
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=133 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: validation complete, elapsed time: 00:00:35

List of Datafiles
=================
File Status Nonlogged Blocks Blocks Examined Blocks Skipped
—- —— —————- ————— ————–
1 OK 0 106363 0
2 OK 0 78919 0
3 OK 0 96639 0
4 OK 0 4991 0
5 OK 400 2559 0
6 OK 569 2559 0

Details of nonlogged blocks can be queried from v$nonlogged_block view

Alert log中会更新以下信息:

Started Nonlogged Block Replacement recovery(validate) on file 5 (ospid 26351 rcvid 10616970560844821494)
Finished Nonlogged Block Replacement recovery(validate) on file 5. 400 blocks found

Started Nonlogged Block Replacement recovery(validate) on file 6 (ospid 26351 rcvid 10616970560844821494)
Finished Nonlogged Block Replacement recovery(validate) on file 6. 569 blocks found

NOLOGGING 导致的坏块不会导致 RMAN 备份失败,一般来说 soft corrupt block 不会导致 RMAN 备份失败,不需要设置 MAXCORRUPT。数据库备份中就会含有 soft corrupt block,如果使用这些备份恢复数据,那么恢复的数据也含有 soft corrupt block。

除 ORA-26040 错误之外,当还有一些其他通用信息出现时,block dump 可 能会被产生,如果数据块的 block dump 内有 byte 0xff 信息或者属于某个段,ORA-1578/ORA-26040会因为介质恢复了NOLOGGING的部分导致了corruption而出现。

 

监控 NOLOGGING 操作

执行NOLOGGING操作,并且之后没有备份的情况下,RMAN 命令 “REPORT UNRECOVERABLE” 可以查询出被影响的datafile。

RMAN> report unrecoverable;

using target database control file instead of recovery catalog
Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
—- ———————– ———————————–
4    full or incremental     /oracle/dbs/users.dbf

当初始化参数db_unrecoverable_scn_tracking设置为true (默认值),那么V$DATAFILE 中以下列会被更新;
db_unrecoverable_scn_tracking参数在10g中是不可用的。请参考Oracle Database在线文档中关于V$DATAFILE中以下列信息:

UNRECOVERABLE_CHANGE#
UNRECOVERABLE_TIME
FIRST_NONLOGGED_SCN
FIRST_NONLOGGED_TIME

在11.2.0.4 or 12.1.0.2+版本中,设置event 16490的情况下,物理备库的MRP进程会检查出NOLOGGING变化,并记录在alert log。

ORA-16490 “logging invalidated blocks on standby due to invalidation redo”

“INVD_BLKS: Invalidating (file <file number>, bno <block number>)”
“fname: ‘Datafile name’. rdba: …”

识别数据块什么时候被标志为NOLOGGING

识别数据块什么时候被标志为NOLOGGING,可以将trace文件中数据块SCN或者v$database_block_coruption视图中CORRUPTION_CHANGE#值
转换为时间:

使用trace文件中数据块SCN
例如:

  Start dump data blocks tsn: 60 file#: 4 minblk 84 maxblk 84
buffer tsn: 3 rdba: 0x02c00054 (11/84)
scn: 0x0771.4fa24eb5 seq: 0xff flg: 0x04 tail: 0x4eb500ff

提取SCN值 0x0771.4fa24eb5, 删除 ‘.’ ,然后转换 0x07714fa24eb 到十进制 511453045995

 

使用v$database_block_coruption视图中CORRUPTION_CHANGE#值

如果运行RMAN validate命令后,v$database_block_coruption视图中corruption_type=’NOLOGGING’ (10.2.0.5 和 11.2.0.1+),
那么CORRUPTION_CHANGE#列的值就是十进制的SCN值。

获得SCN Timestamp

使用下面的方法获得时间:

  

select scn_to_timestamp(&&decimal_scn)
from dual;

如果运行RMAN validate:

select file#, block#, scn_to_timestamp(CORRUPTION_CHANGE#)
from v$database_block_corruption
where CORRUPTION_TYPE=’NOLOGGING’;

In 12c:

select file#, block#, scn_to_timestamp(NONLOGGED_START_CHANGE#)
from v$nonlogged_block;

 

如果查询gv$archived_log 或 gv$log_history遇到错误ORA-08181:

alter session set nls_date_format = ‘DD-MON-YY HH24:MI:SS’;

select first_time, next_time
from gv$archived_log
where &decimal_scn between first_change# and next_change#;

select first_time
from gv$log_history
where &decimal_scn between first_change# and next_change#;

如果运行RMAN validate:

alter session set nls_date_format = ‘DD-MON-YY HH24:MI:SS’;

select file#, block#, first_time, next_time
from v$archived_log, v$database_block_corruption
where CORRUPTION_CHANGE# between first_change# and next_change#
and CORRUPTION_TYPE=’NOLOGGING’;

select file#,block#,first_time
from   v$log_history, v$database_block_corruption
where  CORRUPTION_CHANGE# between first_change# and next_change#
and CORRUPTION_TYPE=’NOLOGGING’;

12c:

alter session set nls_date_format = ‘DD-MON-YY HH24:MI:SS’;

select file#, block#, first_time, next_time
from v$nonlogged_block, v$archived_log
where NONLOGGED_START_CHANGE# between first_change# and next_change#;

OR

select file#, block#, first_time
from v$nonlogged_block, v$log_history
where NONLOGGED_START_CHANGE# between first_change# and next_change#;

 

SYSAUX表空间/AWR,EM 等出现NOARCHIVELOG 和 NOLOGGING 问题

 

如果数据库版本是11.1.0.6 或 11.1.0.7 或 11.2.0.1,
对NOLOGGING对象执行过DIRECT PATH操作,并且后续执行了RECOVER DATABASE命令,及时数据库FORCE LOGGING是打开的情况下,
会出现ORA-1578 and ORA-26040错误。

 

这种问题经常发生在SYSAUX表空间中的AWR或EM对象

 

解决方法

NOLOGGING 操作引起的坏块是不能修复的,比如”Media Recovery” 或 “RMAN blockrecover”都无法修复这种坏块。可行的方法是在 NOLOGGING 操作之后立刻备份对应的数据文件。

问题是在执行RMAN DUPLICATE或RESTORE之后产生?

如果问题是执行RMAN DUPLICATE 或 RESTORE之后 ,那么在源库打开FORCE LOGGING,然后再重新运行RMAN DUPLICATE 或 RESTORE。

  • alter database force logging;

问题是发生在物理standby库?

  • 如果错误出现在物理 STANDBY 数据库, 从主库恢复被影响的数据文件 (只有当主库没有这个问题的情况下)。 在12c中可以使用RMAN选项RECOVER NONLOGGED BLOCK with DATAFILE,TABLESPACE,DATABASE。例如:
  •   
    RMAN> RECOVER DATABASE NONLOGGED BLOCK;
  • 为了避免这个问题发生,在主库强制生产日志:
  • alter database force logging;

如果同一个datafile的数据块在主库出现nologging 坏块,但是备库没有,可以通过手动跳过(dbms_repair)坏块 或者设置event 10231.
主库出现nologging 坏块可能是由于主库执行过备份恢复或者之前是备库,执行了switchover

识别被影响的Segment

找到坏块所在的对象:

  • 如果NOLOGGING数据块位于空闲数据块(dba_free_space视图可以查询到),DBVerify检查会发现这个问题,报错DBV-00201
    或者在v$database_block_corruption视图中显示.对于这种情况,我们可以等待到这个数据块被重用时,会自动格式化,或者
    手动强制格式化
  • 如果是索引,重新创建(drop/create)索引。
  • 如果是,使用 procedure DBMS_REPAIR.SKIP_CORRUPT_BLOCKS 跳过坏块。然后考虑是否重建表:移动table: alter table &table_name move;或者保存数据 (export, Create Table as Select, etc) 然后truncate 或 drop/create.
  • 如果是LOB 另行处理

如果删除有坏块的段之后,这个坏块就处于空闲状态,后续可以被分配给其他对象/段,当这个坏块被分配给他对象/段时,
这个数据块被重新格式化。 如果v$database_block_corruption视图中还是显示为坏块,那么手动运行rman validate来清除视图中的信息。

手动升级到 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 问题。