标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,768)
- DB2 (22)
- MySQL (77)
- Oracle (1,609)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (591)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
分类目录归档:ORA-xxxxx
ORA-01052: required destination LOG_ARCHIVE_DUPLEX_DEST is not specified 恢复思路
今天一网友找到我,说数据库恢复在推scn的过程中遇到了ORA-01052: required destination LOG_ARCHIVE_DUPLEX_DEST is not specified错误无法解决,让我给予支持.这不禁让我想起,现在由于数据库bug和dblink原因导致了很多数据库scn很大,距离天花板非常近,从而使得数据库恢复过程中无法直接简单的推scn,这里正好结合该例子,简单说明下ORA-01052故障的处理.类似文档以前也写过:ORA-01052发生原因的类似文章
由于坏块导致数据库进行实例恢复无法进行
Beginning crash recovery of 1 threads Started redo scan Completed redo scan read 1901 KB redo, 276 data blocks need recovery Started redo application at Thread 1: logseq 1004, block 172771 Recovery of Online Redo Log: Thread 1 Group 2 Seq 1004 Reading mem 0 Mem# 0: F:\APP\ADMINISTRATOR\ORADATA\XFF\REDO02.LOG Fri May 29 10:59:56 2015 RECOVERY OF THREAD 1 STUCK AT BLOCK 439938 OF FILE 19 Fri May 29 11:00:00 2015 Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x2048] [PC:0x6215134, __intel_new_memcpy()+260] Fri May 29 11:00:12 2015 Trace dumping is performing id=[cdmp_20150529110012] Fri May 29 11:00:12 2015 Slave exiting with ORA-1172 exception Errors in file f:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_p007_1612.trc: ORA-01172: 线程 1 的恢复停止在块 439938 (在文件 19 中) ORA-01151: 如果需要, 请使用介质恢复以恢复块和还原备份 Fri May 29 11:00:27 2015 ORA-01578: ORACLE 数据块损坏 (文件号 19, 块号 450245) ORA-01110: 数据文件 19: 'F:\APP\ADMINISTRATOR\ORADATA\XFF\PSTORE_02.DBF' ORA-10564: tablespace PSTORE ORA-01110: 数据文件 19: 'F:\APP\ADMINISTRATOR\ORADATA\XFF\PSTORE_02.DBF' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 91642 ORA-00607: 当更改数据块时出现内部错误 ORA-00602: 内部编程异常错误 ORA-07445: 出现异常错误: 核心转储 [_intel_new_memcpy()+260] [ACCESS_VIOLATION] [ADDR:0x2048] [PC:0x6215134] [UNABLE_TO_READ] [] Fri May 29 11:00:27 2015 Aborting crash recovery due to slave death, attempting serial crash recovery RECOVERY OF THREAD 1 STUCK AT BLOCK 439938 OF FILE 19 Fri May 29 11:00:45 2015 Trace dumping is performing id=[cdmp_20150529110045] Aborting crash recovery due to error 1172 ORA-1172 signalled during: alter database open...
设置_allow_resetlogs_corruption并resetlogs尝试打开数据库
Assigning activation ID 4272042346 (0xfea2316a) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: F:\APP\ADMINISTRATOR\ORADATA\XFF\REDO01.LOG Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri May 29 11:30:47 2015 SMON: enabling cache recovery Fri May 29 11:30:47 2015 Errors in file f:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_3004.trc (incident=181236): ORA-00600: ??????, ??: [2662], [3360], [2233437186], [3360], [2235447064], [4194545], [], [], [], [], [], [] Incident details in: f:\app\administrator\diag\rdbms\XFF\XFF\incident\incdir_181236\XFF_ora_3004_i181236.trc Errors in file f:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_3004.trc: ORA-00704: ???????? ORA-00704: ???????? ORA-00600: ??????, ??: [2662], [3360], [2233437186], [3360], [2235447064], [4194545], [], [], [], [], [], [] Errors in file f:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_3004.trc: ORA-00704: ???????? ORA-00704: ???????? ORA-00600: ??????, ??: [2662], [3360], [2233437186], [3360], [2235447064], [4194545], [], [], [], [], [], [] Error 704 happened during db open, shutting down database USER (ospid: 3004): terminating the instance due to error 704 Instance terminated by USER, pid = 3004 ORA-1092 signalled during: alter database open resetlogs... opiodr aborting process unknown ospid (3004) as a result of ORA-1092
这里可以看到数据库通过设置_allow_resetlogs_corruption参数,进行不完全恢复,跳过数据库启动的实例恢复,然后强制拉库,然后遭遇大家熟悉的ORA-600[2662]错误,使得恢复失败,根据经验,通过推scn来绕过该错误
使用_minimum_giga_scn尝试推SCN
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. -------------------------------- *._minimum_giga_scn=13443 -------------------------------- SQL> startup pfile='/tmp/pfile' ORACLE instance started. Total System Global Area 236000356 bytes Fixed Size 451684 bytes Variable Size 201326592 bytes Database Buffers 33554432 bytes Redo Buffers 667648 bytes Database mounted. ORA-01052: required destination LOG_ARCHIVE_DUPLEX_DEST is not specified
通过运行Oracle Database Recovery Check检查发现数据库的scn已经非常大,距离天花板较近
这里最大允许的推进的scn为13442.7,但是常规的最小的推scn的方法最小值为1024*1024*1024的倍数,因此这里遇到麻烦.
这里数据库遭遇了ORA-01052错误,导致推scn不成功,数据库无法正常启动.出现这类情况,由于scn可以增加的空间非常小,因此可以使用使用oradebug修改数据库scn或者直接修改控制文件scn的方式来精确控制推scn的值(可以实现任何值的scn增加,只要不超过天花板),也可以通过方法修改数据库scn距离天花板的距离,从而实现大幅度使用_minimum_giga_scn来推scn.另外还有一种解决方法:由于ORA-01052是由于scn过大导致(超过了数据库现在的天花板scn),因此出现了ORA-01052.所以另外一种变通的方法,就是通过调整数据库的天花板scn,从而使得_minimum_giga_scn可以继续推scn.在本次恢复中使用最为简单的增加天花板scn的方式来恢复(不过该方法恢复之后需要重建库,其实已经使用了隐含参数屏蔽redo恢复,本身就建议重建库保证数据字典一致性)
物理备库在read only时报ORA-01552错误处理
物理备库在read only时报ORA-01552错误
Tue Jan 06 11:53:38 中国标准时间 2015 alter database open read only Tue Jan 06 11:53:38 中国标准时间 2015 SMON: enabling cache recovery Tue Jan 06 11:53:39 中国标准时间 2015 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan replication_dependency_tracking turned off (no async multimaster replication found) Physical standby database opened for read only access. Completed: alter database open read only Tue Jan 06 11:54:04 中国标准时间 2015 Errors in file c:\oracle\product\10.2.0\admin\ntsy\udump\ntsy_ora_9080.trc: ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01552: 非系统表空间 'MY_SPACE' 不能使用系统回退段 ORA-06512: 在 line 2
分析trace文件
*** ACTION NAME:() 2015-01-06 11:54:04.828 *** MODULE NAME:(sqlplus.exe) 2015-01-06 11:54:04.828 *** SERVICE NAME:(SYS$USERS) 2015-01-06 11:54:04.828 *** SESSION ID:(1284.9) 2015-01-06 11:54:04.828 Error in executing triggers on connect internal *** 2015-01-06 11:54:04.828 ksedmp: internal or fatal error ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01552: 非系统表空间 'MY_SPACE' 不能使用系统回退段 ORA-06512: 在 line 2 *** 2015-01-06 11:54:05.843 Process diagnostic dump for ORACLE.EXE (MMNL), OS id=10492, pid: 13, proc_ser: 1, sid: <no session>
这里可以看出来,是由于执行触发器导致该问题,根据经验第一感觉很可能是logon之类的触发器导致。
查询触发器
SQL> select trigger_name,trigger_type,OWNER from dba_triggers where owner='OP'; TRIGGER_NAME TRIGGER_TYPE OWNER ------------------------------ ---------------- ------------------------------ LOGAD AFTER EVENT OP TR_TRACE_DDL AFTER EVENT OP
只有这两个触发器是基于事件的,另外从名字和dba_source中确定
SQL> select text from dba_source where name='LOGAD'; TEXT -------------------------------------------------------------------------------- TRIGGER "OP".logad after logon on database begin insert into logad values (SYS_CONTEXT('USERENV', 'SESSION_USER'), SYSDATE,SYS_CO NTEXT('USERENV','IP_ADDRESS')) ; end; 已选择6行。 SQL> select text from dba_source where name='TR_TRACE_DDL'; TEXT -------------------------------------------------------------------------------- TRIGGER "OP".tr_trace_ddl AFTER ddl ON database DECLARE sql_text ora_name_list_t; state_sql ddl$trace.ddl_sql%TYPE; BEGIN FOR i IN 1..ora_sql_txt(sql_text) LOOP state_sql := state_sql||sql_text(i); END LOOP; TEXT -------------------------------------------------------------------------------- INSERT INTO ddl$trace(login_user,audsid,machine,ipaddress, schema_user,schema_object,ddl_time,ddl_sql) VALUES(ora_login_user,userenv('SESSIONID'),sys_context('userenv','host'), sys_context('userenv','ip_address'),ora_dict_obj_owner,ora_dict_obj_name,SYSDATE ,state_sql); EXCEPTION WHEN OTHERS THEN -- sp_write_log('捕获DDL语句异常错误:'||SQLERRM); null; END tr_trace_ddl;
基本上确定LOGAD是登录触发器,tr_trace_ddl是记录ddl触发器,那现在问题应该出在LOGAD的触发器上.因为该触发器在备库上当有用户登录之时,他也会工作插入记录到logad表中,由于数据库是只读,因此就出现了类似ORA-01552错误
解决方法
在触发器中加判断数据库角色条件,当数据库为物理备库之时才执行dml操作
SQL> CREATE OR REPLACE TRIGGER "OP".logad 2 AFTER LOGON on database 3 declare 4 db_role varchar2(30); 5 begin 6 select database_role into db_role from v$database; 7 If db_role <> 'PHYSICAL STANDBY' then 8 insert into op.logad values (SYS_CONTEXT('USERENV', 'SESSION_USER'), 9 SYSDATE,SYS_CONTEXT('USERENV','IP_ADDRESS')) ; 10 end if; 11 end; 12 / Warning: Trigger created with compilation errors. SQL> show error; Errors for TRIGGER "OP".logad: LINE/COL ERROR -------- ----------------------------------------------------------------- 4/1 PL/SQL: SQL Statement ignored 4/40 PL/SQL: ORA-00942: table or view does not exist SQL> conn / as sysdba Connected. SQL> grant select on v_$database to op; Grant succeeded. SQL> CREATE OR REPLACE TRIGGER "OP".logad 2 AFTER LOGON on database 3 declare 4 db_role varchar2(30); 5 begin 6 select database_role into db_role from v$database; 7 If db_role <> 'PHYSICAL STANDBY' then 8 insert into op.logad values (SYS_CONTEXT('USERENV', 'SESSION_USER'), 9 SYSDATE,SYS_CONTEXT('USERENV','IP_ADDRESS')) ; 10 end if; 12 end; 12 / Trigger created.
数据库open正常
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel Tue Jan 06 13:51:20 中国标准时间 2015 alter database open read only Tue Jan 06 13:51:21 中国标准时间 2015 SMON: enabling cache recovery Tue Jan 06 13:51:21 中国标准时间 2015 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan replication_dependency_tracking turned off (no async multimaster replication found) Physical standby database opened for read only access. Tue Jan 06 13:51:23 中国标准时间 2015 db_recovery_file_dest_size of 102400 MB is 0.00% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Tue Jan 06 13:51:23 中国标准时间 2015 Completed: alter database open read only
升级数据库到10.2.0.5遭遇ORA-00918: column ambiguously defined
一个数据库从10201升级到10205之后,出现ORA-00918错误,查询mos发现在以前版本中是bug,Oracle好像在10205中把它修复了,结果就是以前应用的sql无法正常执行.这次升级的结果就是客户晚上3点联系开发商紧急修改程序。再次提醒:再小的系统数据库升级都需要做,功能测试,SPA测试,确保升级后功能和性能都正常.
SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi PL/SQL Release 10.2.0.5.0 - Production CORE 10.2.0.5.0 Production TNS for 64-bit Windows: Version 10.2.0.5.0 - Production NLSRTL Version 10.2.0.5.0 - Production
执行报错ORA-00918
多个表JOIN连接,由于在select中的列未指定表名,而且该列在多个表中有,因此在10205中报ORA-00918错误,Oracle认为在以前的版本中是 Bug 5368296: SQL NOT GENERATING ORA-918 WHEN USING JOIN. 升级到10.2.0.5, 11.1.0.7 and 11.2.0.2版本,需要注意此类问题。修复bug没事,但是修复了之后导致系统需要修改sql才能够运行,确实让人很无语
SQL> set autot trace SQL> set lines 100 SQL> SELECT yz_id, item_code, DECODE (yzlx, 0, '长期医嘱', '临时医嘱') yzlx, 2 item_name, gg, sl || sldw sl, zyjs, yf, a.pc, zbj, zbh, 3 TO_CHAR (dcl, 'fm9999990.009') || dcldw dcl, a.bz, lb, zyh,ch,xm, 4 bq, cfh, lrysdm, lrysxm, lrrq, hdrdm, hdrxm, hdrq, sender_code, 5 sender_name, send_date, tzysdm, tzysxm, tzrq, ksrq, zxfy, 6 lb_yp_yl, zsq_code 7 FROM op.yz a LEFT OUTER JOIN op.pc b 8 ON NVL (TRIM (UPPER (a.pc)), ' ') = NVL (TRIM (UPPER (b.pc)), ' ') 9 LEFT JOIN op.zy p ON a.zyh = p.zyh 10 WHERE p.cy='在院' AND p.new_patient='1' 11 AND upper(nvl(p.bj,1))<> 'Y' 12 AND (state = '已核对') 13 AND is_in_bill IS NULL 14 ORDER BY ksrq, yz_id ; bq, cfh, lrysdm, lrysxm, lrrq, hdrdm, hdrxm, hdrq, sender_code, * ERROR at line 4: ORA-00918: column ambiguously defined SQL> select COLUMN_NAME,TABLE_NAME from DBA_tab_columns where column_name='BQ' 2 AND TABLE_NAME IN('YZ','ZY','PC'); COLUMN_NAME TABLE_NAME ------------------------------ ------------------------------ BQ ZY BQ YZ
10.2.0.1中执行正常
E:\>sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 1月 3 14:09:51 2015 Copyright (c) 1982, 2005, Oracle. All rights reserved. 连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options SQL> set autot trace SQL> set lines 100 SQL> SELECT yz_id, item_code, DECODE (yzlx, 0, '长期医嘱', '临时医嘱') yzlx, 2 item_name, gg, sl || sldw sl, zyjs, yf, a.pc, zbj, zbh, 3 TO_CHAR (dcl, 'fm9999990.009') || dcldw dcl, a.bz, lb, zyh,ch,xm , 4 bq, cfh, lrysdm, lrysxm, lrrq, hdrdm, hdrxm, hdrq, sender_code, 5 sender_name, send_date, tzysdm, tzysxm, tzrq, ksrq, zxfy, 6 lb_yp_yl, zsq_code 7 FROM op.yz a LEFT OUTER JOIN op.pc b 8 ON NVL (TRIM (UPPER (a.pc)), ' ') = NVL (TRIM (UPPER (b.pc)), ' ') 9 LEFT JOIN op.zy p ON a.zyh = p.zyh 10 WHERE p.cy='在院' AND p.new_patient='1' 11 AND upper(nvl(p.bj,1))<> 'Y' 12 AND (state = '已核对') 13 AND is_in_bill IS NULL 14 ORDER BY ksrq, yz_id ; 已选择19804行。 执行计划 ---------------------------------------------------------- ERROR: ORA-00604: 递归 SQL 级别 2 出现错误 ORA-16000: 打开数据库以进行只读访问 SP2-0612: 生成 AUTOTRACE EXPLAIN 报告时出错 统计信息 ---------------------------------------------------------- 1 recursive calls 0 db block gets 41945 consistent gets 0 physical reads 0 redo size 2075973 bytes sent via SQL*Net to client 14989 bytes received via SQL*Net from client 1322 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 19804 rows processed
10.2.0.5库中同名列增加表名前缀执行OK
1 SQL> set autot trace SQL> set lines 100 SQL> SELECT yz_id, item_code, DECODE (yzlx, 0, '长期医嘱', '临时医嘱') yzlx, 2 item_name, gg, sl || sldw sl, zyjs, yf, a.pc, zbj, zbh, 3 TO_CHAR (dcl, 'fm9999990.009') || dcldw dcl, a.bz, lb,zyh,ch,xm, 4 a.bq, cfh, lrysdm, lrysxm, lrrq, hdrdm, hdrxm, hdrq, sender_code, 5 sender_name, send_date, tzysdm, tzysxm, tzrq, ksrq, zxfy, 6 lb_yp_yl, zsq_code 7 FROM op.yz a LEFT OUTER JOIN op.pc b 8 ON NVL (TRIM (UPPER (a.pc)), ' ') = NVL (TRIM (UPPER (b.pc)), ' ') 9 LEFT JOIN op.zy p ON a.zyh = p.zyh 10 WHERE p.cy='在院' AND p.new_patient='1' 11 AND upper(nvl(p.bj,1))<> 'Y' 12 AND (state = '已核对') 13 AND is_in_bill IS NULL 14 ORDER BY ksrq, yz_id ; 20629 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 3468887510 -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 2580 | 2968 (2)| 00:00:36 | | 1 | SORT ORDER BY | | 10 | 2580 | 2968 (2)| 00:00:36 | |* 2 | HASH JOIN OUTER | | 10 | 2580 | 2967 (2)| 00:00:36 | |* 3 | TABLE ACCESS BY INDEX ROWID| YZ | 3 | 672 | 42 (0)| 00:00:01 | | 4 | NESTED LOOPS | | 10 | 2390 | 2963 (2)| 00:00:36 | |* 5 | TABLE ACCESS FULL | ZY | 3 | 45 | 2917 (2)| 00:00:36 | |* 6 | INDEX RANGE SCAN | DZBLYZ_ZYH | 118 | | 2 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | PC | 33 | 627 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access(NVL(TRIM(UPPER("A"."PC")),' ')=NVL(TRIM(UPPER("B"."PC"(+))),' ')) 3 - filter("A"."STATE"='已核对' AND "A"."IS_IN_BILL" IS NULL) 5 - filter("P"."CY"='在院' AND UPPER(NVL("P"."BJ",'1'))<>'Y' AND "P"."NEW_PATIENT"='1') 6 - access("A"."ZYH"="P"."ZYH") Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 42121 consistent gets 0 physical reads 0 redo size 2181383 bytes sent via SQL*Net to client 15617 bytes received via SQL*Net from client 1377 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 20629 rows processed
Bug 5368296: SQL NOT GENERATING ORA-918 WHEN USING JOIN
Bug 12388159 : SQL REPORTING ORA00918 AFTER UPGRADE TO 10.2.0.5.0
再次提醒:再小的系统数据库升级都需要做,功能测试,SPA测试,确保升级后功能和性能都正常.