数据库无法打开ORA-09967: unable to create or open lock file

本文记录了一次Oracle数据库启动失败的问题排查过程。由于文件权限错误导致数据库无法正常启动,通过更改文件所有者为正确的oracle用户解决了该问题。此外,还展示了如何检查内存使用情况和信号量等关键步骤。

***************
问题描述:
***************
数据库无法打开
SQL> desc v$datafile;
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-01116: error in opening database file 1
ORA-01110: data file 1: '/u01/oradata/memcache/system01.dbf'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 3


SQL> select name, open_mode from v$database;
select name, open_mode from v$database
                            *
ERROR at line 1:
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/oradata/memcache/control01.ctl'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 3

[root@C113247 ~]# cd /u01/oradata/memcache
[root@C113247 memcache]# ls -alt
total 33285348
-rw-r-----  1 root   root       12206080 Jul 23 17:30 control01.ctl
-rw-r-----  1 root   root       12206080 Jul 23 17:30 control02.ctl
-rw-r-----  1 root   root      209715712 Jul 23 17:30 redo03a.log
-rw-r-----  1 root   root     4294975488 Jul 23 17:30 undotbs101.dbf
-rw-r-----  1 root   root      524296192 Jul 23 17:29 sysaux01.dbf
-rw-r-----  1 root   root     8589942784 Jul 23 17:29 users02.dbf
-rw-r-----  1 root   root     5368717312 Jul 23 17:29 indx01.dbf
-rw-r-----  1 root   root      524296192 Jul 23 17:24 system01.dbf
-rw-r-----  1 root   root     8589942784 Jul 23 16:39 indx02.dbf
-rw-r-----  1 root   root     5368717312 Jul  1 08:08 users01.dbf
-rw-r-----  1 root   root      209715712 Jul  1 08:03 redo02a.log
-rw-r-----  1 root   root      209715712 Jun 21 01:15 redo01a.log
-rw-r-----  1 root   root      524296192 Apr 19 22:00 temp01.dbf
drwxr-xr-x  2 oracle oinstall       4096 Feb  5 15:33 .
drwxr-xr-x  4 oracle oinstall       4096 Jan  4  2010 ..
[root@C113247 memcache]# cd ..
[root@C113247 oradata]# ls -alt
total 16
drwxr-xr-x  2 oracle oinstall 4096 Feb  5 15:33 memcache
drwxr-xr-x  4 oracle oinstall 4096 Jan  4  2010 .
drwxr-xr-x  2 oracle oinstall 4096 Jan  4  2010 archive
drwxr-xr-x  4 oracle oinstall 4096 Jan  4  2010 ..
[root@C113247 oradata]# pwd
/u01/oradata
[root@C113247 oradata]# chown -R oracle:oinstall /u01/oradata/memcache/
[root@C113247 oradata]# ls -alt
total 16
drwxr-xr-x  2 oracle oinstall 4096 Feb  5 15:33 memcache
drwxr-xr-x  4 oracle oinstall 4096 Jan  4  2010 .
drwxr-xr-x  2 oracle oinstall 4096 Jan  4  2010 archive
drwxr-xr-x  4 oracle oinstall 4096 Jan  4  2010 ..
[root@C113247 oradata]# cd memcache
[root@C113247 memcache]# ls -alt
total 33285348
-rw-r-----  1 oracle oinstall   12206080 Jul 23 17:30 control01.ctl
-rw-r-----  1 oracle oinstall   12206080 Jul 23 17:30 control02.ctl
-rw-r-----  1 oracle oinstall  209715712 Jul 23 17:30 redo03a.log
-rw-r-----  1 oracle oinstall 4294975488 Jul 23 17:30 undotbs101.dbf
-rw-r-----  1 oracle oinstall  524296192 Jul 23 17:29 sysaux01.dbf
-rw-r-----  1 oracle oinstall 8589942784 Jul 23 17:29 users02.dbf
-rw-r-----  1 oracle oinstall 5368717312 Jul 23 17:29 indx01.dbf
-rw-r-----  1 oracle oinstall  524296192 Jul 23 17:24 system01.dbf
-rw-r-----  1 oracle oinstall 8589942784 Jul 23 16:39 indx02.dbf
-rw-r-----  1 oracle oinstall 5368717312 Jul  1 08:08 users01.dbf
-rw-r-----  1 oracle oinstall  209715712 Jul  1 08:03 redo02a.log
-rw-r-----  1 oracle oinstall  209715712 Jun 21 01:15 redo01a.log
-rw-r-----  1 oracle oinstall  524296192 Apr 19 22:00 temp01.dbf
drwxr-xr-x  2 oracle oinstall       4096 Feb  5 15:33 .
drwxr-xr-x  4 oracle oinstall       4096 Jan  4  2010 ..


因为整个oracle相关的目录所有者都被改为了root,我没有把所有的改回来。
故还是起不来

SQL> startup mount;
ORA-10997: another startup/shutdown operation of this instance inprogress
ORA-09967: unable to create or open lock file
Linux Error: 13: Permission denied

把oracle相关的目录所有者都改为oracle就可以了


分析中:
查看内存和信号量
[oracle@C113247 bdump]$ ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status     

------ Semaphore Arrays --------
key        semid      owner      perms      nsems    

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages   

[oracle@C113247 bdump]$ ps -ef |grep ora_
oracle   18393 16846  0 17:58 pts/2    00:00:00 grep ora_
[oracle@C113247 bdump]$ ipcs -sb|grep oracle
ipcs: invalid option -- b
[oracle@C113247 bdump]$ ipcs |grep oracle
[oracle@C113247 bdump]$ ipcs -as|grep oracle
[oracle@C113247 bdump]$ sysresv

IPC Resources for ORACLE_SID "memcache" :
Shared Memory
ID              KEY
No shared memory segments used
Semaphores:
ID              KEY
No semaphore resources used
Oracle Instance not alive for sid "memcache"


 [oracle@C113247 bdump]$ free
             total       used       free     shared    buffers     cached
Mem:       4150664    3668084     482580          0     118300    3048240
-/+ buffers/cache:     501544    3649120
Swap:      5668856        208    5668648
  [oracle@C113247 bdump]$ vmstat 5 10
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0    208 482580 118300 3048240    0    0     0     7    0     0  0  0 99  0
 0  0    208 482580 118300 3048240    0    0     0    31 1075    91  0  0 100  0
 0  0    208 482580 118300 3048240    0    0     0    32 1058    93  0  0 100  0
 1  0    208 482580 118300 3048240    0    0     0    26 1074    91  0  0 100  0
 0  0    208 482644 118300 3048240    0    0     0    23 1051    95  0  0 100  0
 0  0    208 482644 118300 3048240    0    0     0    29 1071    92  0  0 100  0
 0  0    208 482580 118300 3048240    0    0     0    22 1051   100  0  0 99  0
 0  0    208 482644 118300 3048240    0    0     0    22 1065    90  0  0 100  0
 0  0    208 482644 118300 3048240    0    0     0    22 1057   101  0  0 100  0
 0  0    208 482580 118300 3048240    0    0     0    19 1054    93  0  0 100  0

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10173379/viewspace-668879/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/10173379/viewspace-668879/

<think>嗯,我现在需要解决用户提到的Oracle数据库报错ORA-09925:“unable to create audit trail file”。首先,我得先理解这个错误的含义。根据错误代码,ORA-09925通常与审计跟踪文件创建失败有关。审计跟踪文件用于记录数据库的审计信息,如果数据库无法创建这个文件,就会抛出这个错误。 接下来,我应该考虑可能的原因。可能的原因包括目录权限问题、存储空间不足、文件系统权限设置不正确,或者参数配置错误等。我需要一步步来排查这些可能性。 首先,检查审计目录的权限。Oracle进程(通常是oracle用户)需要有权限在审计目录中创建和写入文件。审计目录的位置由参数audit_file_dest决定,可以通过SQL查询该参数的值:`SHOW PARAMETER audit_file_dest`。然后,确认该目录是否存在,并且Oracle用户是否有读写权限。如果目录不存在,可能需要手动创建,并设置正确的权限,比如755或777(但要注意安全性)。 其次,查看存储空间是否足够。使用df -h命令检查对应文件系统的可用空间。如果磁盘已满,需要清理空间或扩展存储。 然后,检查文件系统是否挂载为只读。有时候文件系统可能出现问题,导致被挂载为只读模式,这时候需要修复文件系统并重新挂载为可读写。 另外,审计文件的数量可能达到限制。有些系统对单个目录下的文件数有限制,可以检查目录中的文件数量,确认是否超过限制。如果是的话,需要归档或删除旧的审计文件,并考虑调整审计策略,比如使用AUDIT_TRAIL参数改为DB,将审计记录存入数据库而不是文件。 还有可能是参数配置错误。检查init.ora或spfile中的audit_file_dest参数是否正确指向有效的目录。如果参数有误,需要修正并重启数据库实例。 另外,SELinux或AppArmor等安全软件可能会阻止Oracle进程写入文件。可以临时禁用这些安全软件进行测试,如果问题解决,则需要调整策略允许Oracle访问审计目录。 还有可能是文件系统inode耗尽,虽然存储空间足够,但inode不足也会导致无法创建新文件。使用df -i命令检查inode使用情况,如果不足,需要清理小文件或扩展inode数量。 最后,检查Oracle进程的umask设置。umask决定了新创建文件的默认权限,如果设置过严,可能导致文件无法创建。确保umask允许Oracle进程创建文件,通常应为022或002。 在解决过程中,可能需要结合数据库日志(如alert.log)和操作系统日志(如/var/log/messages)来获取更多错误信息,帮助定位问题。如果所有检查都正常,可能需要考虑更深层次的问题,比如存储硬件故障或文件系统损坏,这时候需要联系系统管理员或Oracle支持进一步处理。</think>### **ORA-09925 错误原因及解决步骤** #### **错误描述** Oracle 数据库报错 `ORA-09925: unable to create audit trail file`,表示数据库无法创建审计跟踪文件。审计文件用于记录数据库的安全和操作日志,此错误通常与**文件权限、存储空间或配置错误**相关。 --- ### **1. 检查审计目录权限** - **定位审计目录** 执行 SQL 查询审计文件存储路径: ```sql SHOW PARAMETER audit_file_dest; ``` 默认路径通常为: `$ORACLE_BASE/admin/<数据库名>/adump` 或 `/opt/oracle/admin/<数据库名>/adump`。 - **验证目录权限** Oracle 进程用户(如 `oracle`)需对该目录有**读写权限**: ```bash ls -ld /opt/oracle/admin/ORCLCDB/adump # 预期权限:drwxr-x--- 或 drwxrwx---(属主 oracle:oinstall) ``` - 如果目录不存在,手动创建并赋权: ```bash mkdir -p /opt/oracle/admin/ORCLCDB/adump chown oracle:oinstall /opt/oracle/admin/ORCLCDB/adump chmod 750 /opt/oracle/admin/ORCLCDB/adump ``` --- ### **2. 检查存储空间** - **查看磁盘剩余空间** 确保审计目录所在文件系统有足够空间: ```bash df -h /opt/oracle/admin/ORCLCDB/adump ``` - 若空间不足,清理文件或扩展存储。 - **检查 inode 使用量** 若磁盘空间充足但 inode 耗尽,也会导致文件创建失败: ```bash df -i /opt/oracle/admin/ORCLCDB/adump ``` --- ### **3. 检查文件系统状态** - **确认文件系统未挂载为只读** 某些情况下(如硬盘故障),文件系统会以只读模式挂载: ```bash mount | grep /opt/oracle/admin/ORCLCDB/adump # 正常应为 rw(可读写) ``` - 若为 `ro`,需修复文件系统后重新挂载。 --- ### **4. 调整审计文件数量限制** - **系统级文件数限制** 检查操作系统对单个用户或进程的文件数限制: ```bash ulimit -n # 查看当前限制(Oracle 通常需 ≥ 65536) ``` - 修改 `/etc/security/limits.conf`: ```bash oracle soft nofile 65536 oracle hard nofile 65536 ``` - **清理旧审计文件** 若审计文件过多,手动归档或删除旧文件: ```bash find /opt/oracle/admin/ORCLCDB/adump -type f -mtime +30 -delete ``` --- ### **5. 检查安全软件(SELinux/AppArmor)** - **临时禁用 SELinux** ```bash setenforce 0 # 临时关闭 ``` 测试问题是否解决。若需长期关闭,修改 `/etc/selinux/config` 为 `SELINUX=disabled`。 - **调整 AppArmor 策略** 若使用 AppArmor,检查是否阻止 Oracle 写入文件: ```bash audit2allow -a # 根据日志生成规则 ``` --- ### **6. 检查数据库参数配置** - **验证 `audit_file_dest` 有效性** 确保参数指向有效路径: ```sql ALTER SYSTEM SET audit_file_dest='/valid/path/to/audit_dir' SCOPE=SPFILE; ``` 重启数据库生效。 - **调整审计模式** 若无需文件审计,可改为数据库存储: ```sql ALTER SYSTEM SET audit_trail=DB SCOPE=SPFILE; ``` --- ### **7. 检查 Oracle 进程 umask** - **查看 Oracle 用户 umask** Oracle 进程的 umask 应允许文件创建(通常为 `022`): ```bash grep umask /home/oracle/.bashrc ``` - 修改后重启数据库--- ### **8. 检查日志辅助定位** - **数据库告警日志** 查看 `alert_<数据库名>.log`,定位具体错误上下文: ```bash tail -100f $ORACLE_BASE/diag/rdbms/orclcdb/ORCLCDB/trace/alert_ORCLCDB.log ``` - **操作系统日志** 检查 `/var/log/messages` 或 `journalctl -u oracle`,确认是否有权限拒绝记录。 --- ### **总结步骤** 1. 确认 `audit_file_dest` 路径有效且权限正确。 2. 检查存储空间和 inode。 3. 关闭安全软件或调整策略。 4. 清理旧文件或调整审计模式。 5. 检查参数和日志定位深层问题。 若仍无法解决,建议联系 Oracle 支持或系统管理员进一步排查。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值