Oracle常见异常汇总
1.Sqlplus無法連接數據庫
異常現象：sqlplus無法連接數據庫，KILL關鍵數據庫進程關閉數據庫，再打開時，報錯如下
[oracle@edigateway01 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Sun Apr 16 14:45:36 2023
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected.
SQL> startup nomount;
ORA-00119: invalid specification for system parameter LOCAL_LISTENER
ORA-00130: invalid listener address '(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521))'
異常原因：/etc/hosts中，IP地址和主機名不對應，例如主機名是monkey01，hosts中配置的卻是192.168.1.100 monkey，修改回來就可以了。
2.EM刪除dbconsole卡住
異常現象：創建EM時，刪除舊的dbconsole時，一直卡住，不往下走
異常原因：也是/etc/hosts沒有設置正確，設置正確後，重啟服務器後就可以了。
3.Clear logfile时报错
alter database clear logfile group 1;
/*ERROR at line 1:
ORA-00350: log 1 of instance dfhdb (thread 1) needs to be archived
ORA-00312: online log 1 thread 1: '/oradata01/dfhdb/redo01.log'*/
解决步骤：
-- 1.查看要clear日志的归档状态，一般时NO，记archived栏位为NO
select group#, thread#, sequence#, status, archived from v$log;
-- 2.想办法归档（mount状态下）
alter system archive log all;
-- 或者
alter system archive log all;
/*ERROR at line 1:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/oradata01/dfhdb/redo01.log'
ORA-27048: skgfifi: file header information is invalid
Additional information: 14*/
-- 3.第2步不可以的话，例如如上报错，可以使用下面的命令（注意，如果是ACTIVE或者Current状态，那么执行下面的命令后，里面的事物会丢失）
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;
-- 或者
alter database clear unarchived logfile 'E:\ORACLE\ORADATA\ORCL\REDO01.LOG';
参考：ORA-00350: log 1 of instance needs to be archived
4.11g客户端连接19c数据库报错
异常现象：ORA-28040: No matching authentication protocoL
异常原因：11g和19c的协议不匹配
解决方法：数据库服务端增加sqlnet.ora文件
cd $ORACLE_HOME/network/admin
vi sqlnet.ora
----------------------
# 表示允许11g及以上版本客户端连接
SQLNET.ALLOWED_LOGON_VERSION=11
----------------------
5.控制文件过旧导致数据库无法打开
异常现象：
Errors in file /oracle/diag/rdbms/monkey/monkey/trace/monkey_ora_23504.trc:
ORA-01122: database file 664 failed verification check
ORA-01110: data file 664: '/data/monkey/monkey01.dbf'
ORA-01207: file is more recent than control file - old control file
异常原因：数据库异常重启或者服务器硬体损坏，导致控制文件比数据文件旧
解决方法：重建控制文件
startup mount;
alter database backup controlfile to trace;
-- 从tracefile中得到重建控制文件的脚本，要注意，如果online redo没有损坏，要使用noresetlog选项
CREATE CONTROLFILE REUSE DATABASE "MONKEY" NORESETLOGS FORCE LOGGING ARCHIVELOG
-- 得到tracefile的名字
oradebug setmypid
oradebug tracefile_name
-- 重建控制文件需要在nomount状态
startup nomount;
@create_control.sql
-- 创建控制文件后，数据库会自动到mount状态，应用redo
recover database;
alter database open;
-- 创建控制文件的脚本中没有tempfile的信息，需要手动添加
ALTER TABLESPACE temp ADD TEMPFILE '/extend/oradata/br/temp01.dbf' REUSE;
6.impdp导入中被kill，大量数据回滚
异常现象：
大量的wait for a undo record等待
异常原因：
回滚时，SMON会打开多个并行进行恢复，会引起争用，导致无法恢复
解决方法：
-- 关闭并行恢复
shutdown immediate;
startup mount;
alter system set parallel_max_servers = 0;
alter system set fast_start_parallel_rollback = false;
alter database open;
参考：“Wait for a undo record” OR “Wait for stopper event to be increased” database wait events
7.OnlineRedo损坏处理
在实例未崩溃时，检查点发出不需要从OnlineRedo读取数据，，在redolog buffer中找到最新的重做记录，LGWR将REDOLOG BUFFER写入在线日志，DBWR将脏数据按照顺序写入磁盘，CKPT将检查点目标写入数据文件头和控制文件。因此即使Online Redo损坏，也不影响检查点发出
8.归档日志无法删除
报错：RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process archived log file name=/xxx/xxx/xxx.dbf thread=1 sequence=140635
解决方法：
出现上述问题，一般与OGG，DATAGUARD，流复制，长事务有关，DATAGUARD一般是备库的归档没有应用，可以首先检查排除。其他的可以按以下流程
- 查看长事务
SELECT vs.inst_id,
vt.xidusn,
vt.xidslot,
vt.xidsqn,
vs.sid,
vs.serial#,
vs.client_identifier,
vs.username,
vs.program,
vs.machine,
vt.used_ublk,
vt.start_time,
TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') Current_Time
FROM gv$transaction vt, gv$session vs
WHERE vt.addr = vs.taddr
ORDER BY vt.start_time;
- 查看视图检查排除ogg和流复制
-- 查看CAPTURED_SCN结合v$archived_log可以找到online redo的sequence号
select capture_name, CAPTURED_SCN,APPLIED_SCN,OLDEST_SCN from dba_capture;
- ogg抽取进程原因
ggsci
dblogin USERID xxx, PASSWORD xxx
# 取消注册，本次异常原因就是普通抽取进程，无需注册，却被注册了，导致第二步查到的scn一直没有推进
unregister extract ext_test database
参考：RMAN-08137
9.使用DBLINK往目标端插数据使用本地sequence报错
报错信息：ORA-02069: 在這項作業中, 必須將 global_names 參數設為 TRUE
-- 报错
insert into test@ORACLE19C values (seq_test_id.nextval);
-- 不报错
insert into test@ORACLE19C values (seq_test_id.nextval@ORACLE19C);
10.资源正在被使用中
报错信息：ORA-00054: 資源正被使用中, 請設定 NOWAIT 來取得它, 否則逾時到期
-- 1.查看被使用资源的OBJECT_ID
SELECT *FROM DBA_OBJECTS WHERE OBJECT_NAME='OBJECT_NAME'
-- 2.查看资源被谁占用
SELECT * FROM V$LOCKED_OBJECT WHERE OBJECT_ID='591488'
-- 3.杀掉进程
SELECT * FROM V$SESSION WHERE SID=24369
ALTER SYSTEM KILL SESSION '24369,33469' IMMEDIATE
-- 在系统中杀掉，找到spid
SELECT * FROM V$PROCESS WHERE ADDR='0000002ABFB39368'
11.查v$session是多维元组字元
报错信息：ORA-29275:部份多位元组字元
--查找TO_NCHAR(ACTION)中乱码的即可
select SID,SERIAL#,OSUSER,MODULE,PROGRAM,TO_NCHAR(ACTION) from v$session;
12.DG日志已经应用，但主库v$archived_log的applied栏位为no
原因：DG数据库挂了，即使重新开起来，也导致主备库之间的ARCn-Process挂起，不会更新主库视图
The ARCH-RFS Heartbeat Ping between the Primary and Standby Database is responsible for updating the APPLIED-Column of v$archived_log on the Primary Database. There is a designated Heartbeat ARCn-Process on the Primary Database to perform this Ping. If this Process starts to hang, it does not communicate with the remote RFS-Process any more and so it cannot update the Primary accordingly.
解决方法：
alter system set log_archive_max_processes=1 scope=memory;
alter system set log_archive_max_processes=4;
alter system archive log current;
select * from v$archived_log order by first_time desc;
参考：关于dg，备库日志已经应用，但主库依旧显示applied=no问题的处理
13.存储过程调用DBMS_STATS.EXPORT_TABLE_STATS报错，直接执行没有问题
CREATE OR REPLACE PROCEDURE monkeytest
AS
I_SRC_OWNER VARCHAR (200) := 'SAILY';
I_SRC_TABLE VARCHAR (200) := 'SAILY_TEST';
PARTITION_NAME VARCHAR (200) := 'SYS_P6294';
V_STATTAB VARCHAR (200) := 'TABLE_STATS_20240417092515';
V_STATID VARCHAR (200) := 'TABLE_STATS_20240417092515';
V_STATOWNER VARCHAR (200) := 'MONKY';
BEGIN
EXECUTE IMMEDIATE 'BEGIN DBMS_STATS.EXPORT_TABLE_STATS (ownname => '''||I_SRC_OWNER||''', tabname =>'''|| I_SRC_TABLE||''',partname => '''||PARTITION_NAME||''', stattab => '''||V_STATTAB||''',statid => '''||V_STATID||''',statown =>'''|| V_STATOWNER||'''); END;';
END;
如上sql，在monkey下，调用导出saily表统计信息，报错：ORA-20000: TABLE "XXX"."XXX" does not exist or insufficient privileges
解决方法：
-- monkey为存储过程的owner，调用EXPORT_TABLE_STATS存储的存储过程属于monkey
GRANT ANALYZE ANY TO monkey;
参考：ORA-20000: Object does not exist or insufficient privileges
14.DBLINK，两数据库SCN差距过多，导致不允许查询
报错信息：ORA-19706: invalid SCN,ORA-02063: preceding line from link_xxx
报错原因：一个库的SCN远远大于另一个数据库的SCN，在使用DBLINK时，需要同步SCN，SCN很低的数据库如果同步到打的SCN时，会超过oracle限制的合理SCN增长速率，导致报错。
解决方法：
alter system set _max_reasonable_scn_rate=65536 scope=spfile;
-- 重启数据库使参数生效
参考：
SCN异常增长导致数据库异常关闭风险的防范
警告：ORA-00600 2252 错误正在SCN问题下不断爆发
Oracle修改了SCN算法
白鳝：一直往上走，从程序员到数据库专家
15.并发连接过多，导致数据库tnsping时间很长，建立连接很慢
异常背景：开发反馈系统缓慢，查看oracle服务器负载和EM，发现都很低。经过排查，通过tnsping数据库时，有时无法返回，是数据库建立连接缓慢导致的。
解决方法：
1.请开发把短链接修改为长连接（这个可以从根本上解决，但是由于开发使用事务临时表，不现实）
2.创建多个监听LISTENER1,LISTENER2，请开发把短链接的程式修改为LISTENER2。
参考：深入内核：监听器的工作原理与故障诊断分析
