9 07, 2007
问题提出：
一台测试的服务器，停电再起来后发现listener起不来，报错如下：
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.191.100)(PORT=1521)))
Error listening on: (ADDRESS=(PROTOCOL=ipc)(PARTIAL=yes)(QUEUESIZE=1))
No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.191.100)(PORT=1521)))
TNS-12549: TNSperating system resource quota exceeded
TNS-12560: TNSrotocol adapter error
TNS-00519: Operating system resource quota exceeded
Linux Error: 28: No space left on device
首先查看log文件，已经2G了，打开看看日志里面也没发现什么异常，认为日志是自然增长到这么大的，于是直接cat /dev/null>listener.log把日志清空。然后listener还是起不来，仍然报上面的错误。之后重启机器，还是不行，检查磁盘空间：
oracle@test-db1 admin]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 4.9G 1.9G 2.7G 42% /
/dev/sdb1 99M 15M 79M 16% /boot
/dev/sdb7 1012M 493M 468M 52% /home
/dev/sdb8 61G 41G 18G 71% /opt
none 1000M 0 1000M 0% /dev/shm
/dev/sdb5 2.0G 33M 1.9G 2% /tmp
/dev/sdb6 1012M 606M 355M 64% /var
/dev/sda1 34G 14G 19G 43% /
oracle安装在/opt目录，上面还有18个G的空间，而且每个磁盘空间都很多。查看process限制，top发现系统才开了50个process，而对oracle的限制是2048个。在pub的发帖，地址如下：
http://www.itpub.net/showthread.php?s=&threadid=809058&perpage=10&pagenumber=1
一直没有解决，后来通知同事有这个问题存在。周一上班，同事说这个问题已经被他解决了，并推荐一篇文章给我，地址如下：
http://www.zeali.net/entry/480
摘录一部分：
Linux/Unix like OS 的文件系统中每个目录树中的节点并不是像 Windows 那样直接包含文件的具体信息，而只包含了文件名和 Inode number 。通过 Inode number 所找到对应于文件名的 Inode 节点中才真正记录了文件的大小/物理地址/所有者/访问权限/时间戳/被硬链接的次数等实际的 metadata 。因此你可以在 Linux 系统中通过硬链接( hard link ) 的方式给某个文件创建无数个位于不同目录下的文件名，而实际的文件数据只需要一份拷贝。但也正因为这种文件系统的结构，当你在 Linux 中进行 IO 操作的时候，需要的资源除了磁盘空间以外，还要有剩余的 Inode 才行。缺省情况下， Linux 在系统安装过程中按照1个 Inode 对应 2k 磁盘空间来计算每个分区的最大 Inode 数。一旦文件系统创建之后，每个分区可用 Inode 数就无法进行动态调整。正常来说，一般不太会出现某个分区的 Inode 耗尽而磁盘空间尚余的情况，除非像我碰到的这样垃圾小文件疯长而又没进行有效的清理。但如果确实需要的话，可以在创建文件系统（比如用 mke2fs ）的时候根据实际需要来调整这个参数（比如分区如果用于存放超大视频文件的话 Inode 的数量可以少一些；如果打算存放的文件是大量小于 2k 的迷你文件的话就要考虑多创建一些 Inode）。
使用df -i命令可以看到每个分区的总inode数目和被使用的以及空闲的inode数目：
[root@test-db1 log]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb2 640000 115018 524982 18% /
/dev/sdb1 26104 40 26064 1% /boot
/dev/sdb7 131616 409 131207 1% /home
/dev/sdb8 8077312 168316 7908996 3% /opt
none 255900 1 255899 1% /dev/shm
/dev/sdb5 262144 182 261962 1% /tmp
/dev/sdb6 131616 1500 130116 2% /var
/dev/sda1 4447744 117 4447627 1% /u01
上面的结果是同事已经处理后的结果，原因是/var的一个子目录下产生很多很小的文件，删除后恢复正常，listener可以正常起来了。
继续做下面一个试验：
首先找到一个大小为200多k的测试文件
[root@localhost test]# ll
total 208
-rw-r--r-- 1 root root 206305 Mar 8 10:28 test.log
然后查看/usr的inode使用情况
[root@localhost test]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda6 525888 98096 427792 19% /usr
然后把test.log分割成每个字节一个文件，split的使用方法可以参考：http://zhang41082.itpub.net/post/7167/289531
[root@localhost test]# split -a 10 -b 1 test.log
统计分割后的总文件数目，比test.log的文件大小206305多了两个，这个一个是因为test.log文件本身占一个，还有就是统计的返回结果占一行，所以看到文件被成功分割为206305个。
[root@localhost test]# ll | wc -l
206307
查看inode使用情况
[root@localhost test]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda6 525888 304401 221487 58% /usr
可以看到，inode增加了304401-98096=206305个。然后把test.log重命名为test1.log，重新分裂
[root@localhost test]# split -a 10 -b 1 test1.log z
[root@localhost test]# ll|wc -l
412612
[root@localhost test]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda6 525888 510706 15182 98% /usr
inode已经使用了98%了，再重复一次
[root@localhost test]# mv test1.log test2.log
[root@localhost test]# split -a 10 -b 1 test2.log y
split: yaaaaaaawly: No space left on device
可以看到，进行到一半的时候已经不能对文件再进行分割了，而错误提示也已经出现 No space left on device。
总结：这类错误是比较少见的错误，有时候oracle的bug或者其他原因会导致某个目录的trace文件数目疯长，这时候就要小心这个问题了，因此日常的系统监控除了要监控磁盘空间的大小，对inode的使用情况也应该进行监控。
从这个问题可以看出，操作系统的知识多么重要，感谢zeal的文章，感谢同事提供了这篇文章。
后续和补充：
今天看到pub上eygle给出了更合理的解释，放在这里作为补充。
为什么/var目录的inode满了会影响到装在/opt目录的oracle不能启动呢？原来listener启动的时候会在/var/tmp目录下的.oracle隐藏目录下创建两个临时文件：
[oracle@stream .oracle]$ ll
total 0
srwxrwxrwx 1 oracle oinstall 0 Feb 5 05:49 s#4036.1
srwxrwxrwx 1 oracle oinstall 0 Feb 5 05:49 s#4036.2
srwxrwxrwx 1 oracle oinstall 0 Apr 20 04:26 s#5332.1
srwxrwxrwx 1 oracle oinstall 0 Apr 20 04:26 s#5332.2
srwxrwxrwx 1 oracle oinstall 0 Jan 22 21:53 s#7306.1
srwxrwxrwx 1 oracle oinstall 0 Jan 22 21:53 s#7306.2
srwxrwxrwx 1 oracle oinstall 0 Jan 13 04:21 s#9611.1
srwxrwxrwx 1 oracle oinstall 0 Jan 13 04:21 s#9611.2
可以看到这个临时文件确实是成对出现的。