今天（2018-11-05），同事反馈有一个数据库输入账号密码后连接失败，提示 ORA-00257: archiver error. Connect internal only, until freed。
当时的解决思路如下记录所示：
1、使用同事提供的账号密码，重新登录数据库
[[email protected] ~]# su - oracle
[[email protected] /]$ sqlplus gd_coad/[email protected]:1521/orcl（账号密码地址已隐去，可参照格式对应你们自己服务器的账号密码即可）
SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 5 15:38:19 2018
Copyright (c) 1982, 2009, Oracle. All rights reserved.
ERROR:
ORA-00257: archiver error. Connect internal only, until freed.
2、看到提示，认为指令是没有问题，是因为其他原因报错，于是第一反应是使用管理员进行登录
[[email protected] /]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 5 15:43:31 2018
Copyright (c) 1982, 2009, Oracle. All rights reserved.
ERROR:
ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 28: No space left on device
Additional information: 9925
ORA-01075: you are currently logged on
3、使用数据库管理员登录报错，发现一个熟悉的提示，No space left on device，于是使用 df -h 命令查看本地磁盘空间
[[email protected] /]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda3 38G 37G 56M 100% /
tmpfs 7.8G 520M 7.3G 7% /dev/shm
/dev/vda1 194M 30M 155M 16% /boot
/dev/vdb1 504G 500G 6.4G 100% /oradata
4、发现有两个目录都达到100%的使用率，使用 du -h --max-depth=1 命令查看并逐个目录清理文件，清理之后，重新登录数据库管理员
[[email protected] /]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 5 16:16:10 2018
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>
5、发现重新登录数据库管理员生效，于是重新再登录第一步报错的用户
[[email protected] /]$ sqlplus gd_coad/[email protected]:1521/orcl
SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 5 16:20:51 2018
Copyright (c) 1982, 2009, Oracle. All rights reserved.
ERROR:
ORA-00257: archiver error. Connect internal only, until freed.
6、发现这个用户还是无法登录，不过也排除了因为磁盘空间占满导致的登录失败，于是搜索 ORA-00257 这个错误
https://blog.csdn.net/panys/article/details/3838846
https://blog.csdn.net/darren__chan/article/details/18813581
https://www.cnblogs.com/haoxiaoyu/p/4346851.html
7、按照以上几篇的情景去排查，不符合我当前遇到的问题现状，此时是抱着尝试一下的状态，去删除 /oracle/diag/tnslsnr/host-19-14-132-129/listener/alert 路径下的 logxx.log 日志（虽然是尝试的心态，但我知道这个监听日志的清理不会影响到数据库）注意：要保留最初的 log.xml 日志。
8、清理之后，尝试重新登录用户，突然发现用户登录成功
[[email protected] /]$ sqlplus gd_coad/[email protected]:1521/orcl
SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 5 17:28:25 2018
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>
9、虽然问题解决了，是因为这个路径下的监听日志占满引起的登录失败，但不知道为什么会如此，于是查看这个日志的作用，详情如下
一、Oracle 11g 引入 ADR 机制，监听日志的存放位置调整为 $ORACLE_BASE/diag/tnslsnr/hostname/listener/alert/log.xml，前面的 hostname 根据实际主机名而定；
二、这个日志会以 log_1.xml、log_2.xml、……、log_n.xml 来命名，并以每个 10M 的大小不断增多；
三、通过命令 lsnrctl status 可以查看监听日志的存放位置；
[[email protected] /]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 04-NOV-2018 18:02:28
Copyright (c) 1991, 2009, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Start Date 27-MAY-2018 18:04:53
Uptime 161 days 0 hr. 57 min. 35 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Listener Log File /oracle/diag/tnslsnr/host-xx-xx-xxx-xxx/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=host-xx-xx-xxx-xxx)(PORT=1521)))
Services Summary...
Service "orcl" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
Service "orclXDB" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
The command completed successfully
[[email protected] /]$
原文地址：https://www.cnblogs.com/maple-study/p/9910448.html