图灵小队—ORACLE的ORA-ERROR问题解决归类

图灵小队——ORACLE的ORA-ERROR问题解决归类

25、ORA-19610

（1）问题现象（RMAN）

restore时出现：

ORA-19610: directory block 1 is corrupt

failover to previous backup

（2）问题分析：

是因为没有解密，rman 恢复识别不到bkp的文件，所以需要进行解密

（3）解决方法：

直接解密即可：RMAN> set decryption identified by '密码';

24、RMAN-05535、RMAN-05158

（1）问题现象（DG)

执行：RMAN> duplicate target database for standby from active database nofilenamecheck;

（2）分析原因：

DB_FILE_NAME_CONVERT 设置不对导致（RMAN-05158），注意大小写
*.DB_FILE_NAME_CONVERT='/oracle/app/oracle/oradata/mesorclstd','/oracle/app/oracle/oradata/MESORCL','/oracle/oradata/mesorclstd','/oracle/oradata/mesorcl'
LOG_FILE_NAME_CONVERT 设置不对，导致（RMAN-05535），注意大小写
*.LOG_FILE_NAME_CONVERT='/oracle/app/oracle/oradata/mesorclstd','/oracle/app/oracle/oradata/MESORCL'

（3）解决：

修改上述两个参数值。

23、ORA-01105

（1）问题现象（RAC）

ORA-01105: mount is incompatible with mounts by other instances
ORA-01677: standby file name convert parameters differ from other instance

RAC集群单节点无法启动。

（2）问题原因

其中一个节点更改了参数，没有同步到第二个节点，此时报错时，数据库是在nomount状态，直接将第二个节点进行修改即可。

节点1做过的修改详情：

SQL> alter system set log_file_name_convert='/oracle/app/oracle/oradata/meoroclstd','+DGSYSTEM01/meorocl','/oracle/archivelog','+DGRECOVERY01/meorocl' scope=spfile sid='*';

（3）解决方案

节点2根据节点1进行修改：

SQL> alter system set log_file_name_convert='/oracle/app/oracle/oradata/meoroclstd','+DGSYSTEM01/meorocl','/oracle/archivelog','+DGRECOVERY01/meorocl' scope=spfile sid='*';

22、16191

（1）问题现象

进行DG时，备机日志出现此警告

FAL[client, USER]: Error 16191 connecting to meorocl for fetching gap sequence
Sat Feb 12 09:53:54 2022
Error 1017 received logging on to the standby

（2）问题原因

主备库的密码文件不一致，从主库拷贝一个到备库，并改名即可

（3）解决方案

主备库的密码文件不一致，从主库拷贝一个到备库，并改名即可

scp orapwmeorocl1 oracle@192.168.20.235:/oracle/app/oracle/product/11.2.0/db_1/dbs/orapwmeorocl

 

21、ORA-16014/ORA-00312

（1）问题现象

ORA-16014: log 1 sequence# 20 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/oracle/app/oracle/oradata/mesorcl/redo01.log'

ADG duplicate过程报错

（2）问题原因

问题指向mesorcl路径，因为备库实例名是mesorclstd，所以mesorcl是指向主库。

主库在进行online log的归档时，无法归档，经检查发现，主库的archivelog归档路径没有。（show parameter db_recovery_file_dest 为空）

（3）问题解决

主库设置db_recovery_file_dest 路径

20、ORA-03113

（1）问题现象

ORA-03113: end-of-file on communication channel
Process ID: 2195
Session ID: 81 Serial number: 5

（2）问题原因

问题原因有多种：

①数据库磁盘目录满了，需要扩容
②数据库归档日志目录满了，需要增大设置或删除过期归档
③库做了ADG，但是没有正常关闭，且DGMGRL的broker开启了，且开启了FAST_START  fail over功能，需要关闭。
④在RAC中，有可能会遇到，如果在启用归档日志时，把db_recovery_dest位置设置为‘+DGRECOVERY01’,如果设置为‘+DGRECOVERY01’，那么open过程会将redo保存为archivelog，因为找不到路径则报03113错误，在mount状态重新设置正确，然后open即可。

（3）解决方案

①磁盘空间满了

使用lvm扩容即可

②针对归档日志满的问题，清理日志

--方法1：增大归档日志目录

--SQL> alter system set db_recovery_file_dest_size=50G; --大于原来的即可

--方法2：删除过期归档

--rman target /
--RMAN> delete archivelog until time 'sysdate';删除过期归档日志 
--RMAN> delete force noprompt rchivelog all; --删除所有归档日志

③针对broker和fast_start failover问题

[oracle@linux1:/home/oracle]$lsnrclt start
SQL> startup mount
[oracle@linux1:/home/oracle]$dgmgrl
DGMGRL> connect sys/oracle@mesorcl
DGMGRL> disable FAST_START FAILOVER force
SQL> alter system set dg_broker_start=FALSE scope=both;
SQL> alter database open;

 

19、ORA-00257

（1）问题现象

NC57前端提示：

ORA-00257:archiver eror.Connect internal only, until freed.DSRA0010E：SQL状态=64000，错误代码-257

（2）问题原因

根据提示，可以发现是归档日志问题。

09:01:21 SYS@mesorcl>select * from v$flash_recovery_area_usage;

（3）解决方案

①首先将归档空间目录设置大一些，让数据库可以正常运行

比如原先为200G，现在改为250G;

SQL>show parameter db_recovery_file_dest_size;
SQL>alter system set db_recovery_file_dest_size=250G;

②清理归档目

删除两天前的归档日志

[oracle@linux1:/home/oracle]$rman target /

SQL>DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-2';

18、ORA-01187

（1）问题现象：

--查询dba_temp_files临时文件，报错:

SQL> select file_name,tablespace_name from dba_temp_files;

ERROR at line 1: ORA-01187: cannot read from file because it failed verification tests 
ORA-01110: data file 201: '/oracle/app/oracle/oradata/mesorcl/temp01.dbf'

--查询v$tempfile没有错误

SQL> select file#,status,name from v$tempfile;

（2）问题原因：

分析为临时文件损坏，需要重建临时文件。

（3）解决方案：

①删除旧数据文件，创建新的数据文件

SQL> alter tablespace temp add tempfile '/oracle/app/oracle/oradata/mesorcl/temp02.dbf' size 200m; 

SQL> alter database tempfile '/oracle/app/oracle/oradata/mesorcl/temp01.dbf' drop; 

②进入系统删除temp01.dbf文件。

17、ORA-01652

（1）问题现象：

log日志提示错误：unable to extend temp segment by 128 in tablespace TEMP;

（2）问题原因：

在完成Select语句、create index等一些使用TEMP表空间的排序操作后，Oracle是会自动释放掉临时段的。

但有时候我们则会遇到临时段没有被释放，TEMP表空间几乎满的状况，甚至是我们重启了数据库仍没有解决问题。

在检查系统的磁盘空间时，发现临时表空间所在临时数据文件已经达到32G，已经占用了100%。

因为是正式数据库服务器，不能随便重启数据库。

（3）解决方案：

①首先查看当前的数据库默认表空间：

SQL> select * from database_properties where property_name='DEFAULT_TEMP_TABLESPACE';

确认当前的临时表空间为TEMP

②查看目前临时表空间的大小：

SQL> select file_name,tablespace_name,bytes/1024/1024 "MB",autoextensible from dba_temp_files；

③创建新的临时表空间：

SQL> create temporary tablespace temp02 tempfile '/oracle/app/oracle/oradata/mesorcl/temp02.dbf' size 512M;

④把新建的临时表空间却换成数据库的默认临时表空间

SQL> alter database default temporary tablespace temp02;

⑤确认目前数据库的默认临时表空间

SQL> select * from database_properties where property_name='DEFAULT_TEMP_TABLESPACE';

确认temp02为当前的数据库默认表空间

⑥在删除temp临时表空间之前，先把运行在temp临时表空间的sql语句kill掉，这样的sql语句多为排序的语句

SQL> select se.username,se.sid,se.serial#,su.extents,su.blocks*to_number(rtrim(p.value))as Space,
tablespace,segtype,sql_text
from v$sort_usage su,v$parameter p,v$session se,v$sql s
where p.name='db_block_size' and su.session_addr=se.saddr and s.hash_value=su.sqlhash
and s.address=su.sqladdr
order by se.username,se.sid;

查询出来之后，kill掉这些sql语句：

SQL>alter system kill session '524,778'; (假如某一条运行的sql语句的SID为524，serial#为778)

确认在temp临时表空间中没有运行的sql语句之后，则可以删除temp临时表空间数据文件了

⑦删除temp临时表空间

SQL> drop tablespace temp including contents and datafiles;

这样很快就可以删除了临时表空间的数据文件

⑧重新建立temp临时表空间

SQL> create temporary tablespace temp tempfile '/oracle/app/oracle/oradata/orcl/temp01.dbf' size 512M autoextend on ;

⑨查看新建的temp临时表空间是否正确

SQL>select file_name,tablespace_name,bytes/1024/1024,maxbytes/1024/1024,autoextensible from dba_temp_files；

⑩把新建的temp临时表空间却换成数据库的默认临时表空间

SQL> alter database default temporary tablespace temp;

⑩①确认目前数据库的默认临时表空间

SQL>select * from database_properties where property_name='DEFAULT_TEMP_TABLESPACE';

确认temp为当前的数据库默认表空间

⑩②删除temp02临时表空间

SQL> drop tablespace temp02 including contents and datafiles;

16、ORA-03113

（1）问题现象：

应用前端报此错误，通过系统登录数据库，同样报这个错误

ORA-03113:通信通道的文件结尾 解决办法

日志显示：

ORA-19815: 警告:db_recovery_file_dest_size 字节 (共 4102029312 字节) 已使用 100.00%, 尚有 0 字节可用

（2）问题原因：

通过查看日志文件，基本可以断定两种情况：

--系统的磁盘空间满

--实际的归档日志大小已经大于设置的归档日志目录db_recovery_file_dest_size的大小。

（3）解决方案：

--首先将归档空间目录设置大一些，让数据库可以正常运行

比如原先为200G，现在改为250G;

SQL>show parameter db_recovery_file_dest_size;
SQL>alter system set db_recovery_file_dest_size=250G;

--清理归档目

删除两天前的归档日志

[oracle@linux1:/home/oracle]$rman target /

SQL>DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-2';

--注意

在删除归档文件中有一点要注意，通过命令：

sql>show parameter db_recovery_file_dest

获取地址

/oracle/app/oracle/product/11.2.0/db_1/dbs/arch 下，但是我们不能手工在操作系统中直接把这些文件删除掉，这是因为在controlfile中记录着每一个archivelog的相关信息，当我们在OS中删除这些文件后，我们的controlfile中仍然记录着这些archivelog的信息，因此在Oracle的OEM管理器中还会存在这些日志。因为当我们手工清除archive目录下的文件后，这些记录并没有被我们从controlfile中清除掉，也就是oracle并不知道这些文件已经不存在了。所以还是要通过命令窗口去执行删除这些文件的命令。

（4）另外的情况

配置ADG时，如果db_unique_name='mesorcl',而*。log_archive_config='DG_CONFIG=(mesorclstd,mesorcl)'主库配置反了,也会导致03113的错误。

归根结底，还是数据库启动或者访问时，无法找到归档日志进行读取或写入。

15、ORA-04030

见：https://www.topunix.com/post-5648.html

14、ORA-12518

（1）问题现象：

在做ADG时，辅助数据库在nomount状态，本地执行:SQL>sqlplus sys/oracle@172.18.5.147/mesorclstd as sysdba时，报错：ORA-12528: TNS: 监听程序: 所有适用例程都无法建立新连接

（2）问题原因：

--一般是监听问题，把监听问题进行检查

--再次检查主机名，看主机名是否主备机相同

（3）解决方案：

--在客户机tnsnames.ora中(service_name = mesorclstd)增加(UR=A)，即(service_name = mesorclstd)(UR=A)。这个问题的处理，在创建database guard的时候比较有用。

--重新配置主机名，配置监听。

13、ORA-12547

（1）问题现象：

一般发生在机器克隆的时，系统无法启动

（2）问题原因：

这个原因是$ORACLE_HOME/bin/oracle文件的权限问题。必须要设置为6751。

（3）解决方案：

--查看oracle权限

[oracle@normal adump]$ ll $ORACLE_HOME/bin/oracle

--如果权限不对，则需要添加

[oracle@normal adump]$chmod 6751 $ORACLE_HOME/bin/oracle

12、TNS-12555:

（1）问题现象：

TNS-12555: TNS:permission denied
TNS-12560: TNS:protocol adapter error
TNS-00525: Insufficient privilege for operation
Linux Error: 1: Operation not permitted

（2）权限问题

修改权限

（3）解决方案：

--切换到root用户下，进入目录：/var/tmp

[root@localhost tmp]# chown oracle:oinstall .oracle

--切换到root用户下，进入目录：/tmp

[root@localhost tmp]# chown oracle:oinstall .oracle

11、ORA-14460:

（1）问题现象：

impdp 导入时报错

（2）问题原因：

这个原因是有些表是有表分区且有子分区，该参数可与忽略expdp导出时附带的相关表空间和存储子句约束。

（3）解决方案：

--查看oracle权限

这个导入语句中加入transform=segment_attributes:n参数。该参数可与忽略expdp导出时附带的相关表空间和存储子句约束。

10、ORA-16014

（1）问题现象：

在进行ADG的RMAN同步时，报此错：

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 02/03/2022 23:57:17
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of sql command on default channel at 02/03/2022 23:57:17
RMAN-11003: failure during parse/execution of SQL statement: alter system archive log current
ORA-16014: log 2 sequence# 5 not archived, no available destinations
ORA-00312: online log 2 thread 1: '/oracle/app/oracle/oradata/mesorcl/redo02.log'

（2）问题原因：

提示log 2没有目标端进行存放，可能是archivelog 归档日志目录没有设置。

（3）解决方案：

设置归档目录：

SQL> alter system set db_recovery_file_dest='/oracle/app/oracle/oradata/mesorcl';

 

9、ORA-17627:

ORA-12577: Message 12577 not found; product=RDBMS; facility=ORA

（1）问题现象：

搭建dataguard主从，用rman进行热备时，报此错误

（2）问题分析

开始几个文件都安全的传输过去了，到第四个就卡住了，后来发现是备库的磁盘空间不足了，所以文件传输失败：）

（3）问题解决

扩容备库磁盘即可

8、ORA-27102

（1）问题现象：

在启动数据库时，报内存不足或空间不足的信息

[oracle@hyzxora:/home/oracle]$sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 25 16:10:27 2021

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to an idle instance.

16:10:27 SYS@mesorcl>startup
ORA-27102: out of memory
Linux-x86_64 Error: 28: No space left on device
Additional information: -268435456
Additional information: 1

（2）问题原因：

一般为内存分配问题：

--配置的kernel.shmmax值过小

小于给sga分配的值，需要增加kernel.shmmax的值或减小sga的值

--配置的vm.nr_hugepages的值过大

配置的vm.nr_hugepages的值过大，将内存占用光了，需要把值调小一些。（物理机内存越小越敏感）

--配置vm.nr_hugepages时，配合free -m查看。

比如:给vm.nr_hugepages分配值为20000，大约为20000*2m=40G，如果此时free的值为39G；
启动数据库startup时，因为要直接占用40G的空间，当前空闲没有这么大，所以会报out of memory。

（3）解决方案：

--方案1：

--可以改小vm.nr_hugepages（vm.nr_hugepages的值，1大约为1.8m-2m，所以设置20000大约35G-40G)

--方案2：

--也可以通过释放buff/cache，使free变大。

echo 1 > /proc/sys/vm/drop_caches   --1：释放页缓存
echo 2 > /proc/sys/vm/drop_caches   --2：释放dentries和inodes
echo 3 > /proc/sys/vm/drop_caches   --3：释放所有缓存，常用
echo 0 > /proc/sys/vm/drop_caches   --0：是系统默认值，默认情况下表示不释放内存，由操作系统自动管理

7、ORA-28040

（1）问题现象：

如使用Oracle11.2客户端连接Oracle 19c的时候，报错:

ORA-28040: No matching authentication protocol

ORA-28040: 没有匹配的验证协议

（2）问题原因：

原因客户端与服务器段的密码生成版本（dba_users.password_versions）不一致导致

（3）解决方案：

在数据库服务器上的$ORACLE_HOME/network/admin/sqlnet.ora文件添加相应参数

注：单实例或RAC都是此目录的sqlnet.ora文件

--Oracle12c以下版本

SQLNET.ALLOWED_LOGON_VERSION=8

--Oracle12c及以上版本

SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8

两者区别

SQLNET.ALLOWED_LOGON_VERSION_SERVER：控制可以连接到12c数据库的客户端版本（client -->12c server ）

SQLNET.ALLOWED_LOGON_VERSION_CLIENT：控制12c数据库可以连到哪些版本的数据库（12c server  -->其它版本dbserver），例如：控制通过DB LINK可连接到哪些版本的oracle库。

（4）注意：

添加参数以后无需重启数据库或监听，但需要重置数据库用户密码，否则还会报错：

ORA-01017: 用户名/口令无效; 登录被拒绝

在数据库服务器使用sys登录并修改密码，修改完数据库用户密码后再重新登录，搞定.

6、ORA-30036

（1）问题现象：

业务前端运行过程中，事务等待，报这个错误。

（2）问题原因：

undo表空间不足

（3）解决方案：

--扩展undo表空间，否则事务就会等待了。

SQL> alter database datafile '/oracle/app/oracle/oradata/mesorcl/undotbs01.dbf' resize 30G;

--如果undo表空间已经满了，需要增加数据文件

SQL> alter tablespace UNDOTBS1 add datafile '/oracle/app/oracle/oradata/mesorcl/undotbs02.dbf' size 1024G autoextend on;

5、ORA-31623/ORA-06512

（1）问题现象：

执行expdp导出，如下语句：

[oracle@YCZBNCPOAP ~]$expdp YCZBWZ/yczb1qaz#EDC@127.0.0.1/orcl schemas=YCZBWZ directory=DUMP_YCZBNC dumpfile=YCZBNC_`date +%Y%m%d\%H%M%S`_expdp.dmp logfile=YCZBNC_`date +%Y%m%d\%H%M%S`_expdp.log compression = all

UDE-31623: operation generated ORACLE error 31623 
ORA-31623: a job is not attached to this session via the specified handle 
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3326 ORA-06512: at "SYS.DBMS_DATAPUMP", line 4551

（2）问题原因：

[oracle@YCZBNCPOAP ~/app/diag/rdbms/orcl/orcl/trace]$tail -f 20 alert_orcl.log

ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool","unknown object","streams pool","fixed allocation callback")

在alert日志中发现，在执行EXPDP导出的时候，数据库报了ORA-04031的错误，我们都知道这是和SGA内存相关的一个报错，而且后面很清楚的提示了是由于SGA中的一个组件“streams pool”出现了内存不足，使用EXPDP导出是会用到流池的，所以需要修改一下流池的大小即可。

（3）解决方案：

--查看sga中streams pool 的分配情况

SQL> select * from v$sgainfo;

--查看streams_pool的大小

SQL> select name,issys_modifiable from v$parameter where name like '%pool%';

--增大并重新设置streams_pool的大小

SQL> alter system set streams_pool_size=128m scope=both;

4、ORA-31619

（1）问题现象：

impdp导入数据库时报错：

Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-31619: invalid dump file "/data/backup/MES.dmpdp"

（2）问题原因：

--数据库版本问题

导出导入的数据库版本不一致，expdp导出的版本需要和导入的数据库版本一致（建议），或者导入的版本要比导出的版本高。

--数据文件

查看此数据文件，考虑是不是传输时数据文件有损坏，校验原文件和mes.dmpdp文件，发现md5sum 值不一样

源文件：

目标文件：

（3）解决方案：

在传输数据时，建议不要使用linux自带的ftp客户端进行远程数据传输，容易丢数据。可以使用FTP filezilla等工具进行传输。

重新传输完成再进行导入则成功。

3、ORA-39064/ORA-29285

（1）问题现象：

在windows下使用expdp导出数据时，提示报错

（2）问题原因：

这个错误，Windows默认客户端字符集NLS_LANG是ZHS16GBK，而数据库是AL32UTF8。

（3）解决方案

--做变量设置:

C:\Users\administrator> set NLS_LANG=AMERICAN_AMERICA.AL32UTF8

--重新导出：

expdp system/1qaz2WSX dumpfile=20210830-5.dmp logfile=20210830-5.log DIRECTORY=backup_PRD full=y compression=all

2、ORA-39082

（1）问题现象：

impdp导入过程，提示大量的ora-39082错误

（2）问题原因：

有些函数、过程、触发器等在导入过程编译失败，需要重新编译

（3）解决方案：

--sys用户查看无效对象

SQL> col object_name for a30;
SQL> select owner,object_name,object_type,status  from dba_objects where status !='VALID' and owner not in ('SYS','SYSTEM')；

--编译无效对象：

view：        alter view <view_name> compile;
function:     alter function <function_name> compile;
procedure:    alter procedure <procedure_name> compile;
trigger：     alter trigger <trigger_name> compile;

--show error 的用法：

查看编译出现的问题，通知开发人员排查问题。

SQL>show errors view view_nam

1、ORA-39181

（1）问题现象

使用system用户，使用expdp导出完毕后，报这个错误。

（2）问题原因：

错误的原因是一个没有权限的用户试图导出一个具有细粒度访问控制的表。

该表的拥有者访问该表会受限，因此不能导出该表里的所有行。该表的所有者只能导出其能看到的那些表行。因此，要保证表的完整性，在安全策略的前提下导入该表时，导入该表的用户必须拥有足够的权限来重建该表。

（3）解决方案

使用sys用户分配给system如下权限：

[oracle@linux1:/home/oracle]$sqlplus / as sysdba

16:19:41 SYS@mesorcl>grant EXEMPT ACCESS POLICY to system;

其他：

1、ORA-ORA-01555

问题原因：

(1)、SQL 语句执行时间太长，或者 undo 表空间过小，或者事务量过大，或者过于频繁的提交，导致执行 SQL 过程中进行一致性读时，SQL 执行后修改的前镜像(既UNDO 数据)在 UNDO 表空间中已经被覆盖，不能构造一致性读块(CR blocks)。这种情况最多。

(2)、SQL 语句执行过程中，访问到的块，在进行延迟块清除时，不能确定该块的事务提交时间与 SQL 执行开始时间的先后次序。这种情况很少。一般sql语句问题

第一种情况解决方法：

(1)、增加 UNDO 表空间大小；
(2)、增加 undo_retention 时间，默认只有 15 分钟；
(3)、优化出错的 SQL，减少查询的时间，首选方法；
(4)、避免频繁的提交。

2、ORA-00600: internal error code,arguments: [4194], 错误

问题原因：undo 表空间损坏后，数据库无法启动