启动lnsr需要写tmp权限

今天凌晨被叫醒起来,某省的数据库db01坏了一个cpu,由于有HA架构的保护,切换到了db02,但是在db02上却无法启动侦听,以下是报错信息:

看报错很奇怪:Error listening on: (ADDRESS=(PROTOCOL=ipc)(PARTIAL=yes)(QUEUESIZE=1)),难道是网络的问题?问了一下主机工程师,确认网络没问题。

那难道是ipc协议的问题?继续去看listener.ora文件的配置:

难道是(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)) 的问题?但是这个一模一样的配置当初在db01也是没事的呀,奇怪!尝试去掉这个配置,再次启动侦听的时候,还是报同样的错。

重启network服务还是一样报错;一样的配置,尝试再次切换到db01,侦听能顺利启动;再切换到db02,还是无法启动。

没办法,trace一下侦听吧,由于侦听没启动,不能LSNRCTL> set trc_level admin,只能在listener.ora文件里面加入如下的内容:

启动侦听后,观察trace文件:

我们注意到在391行有一个报错 [000001 29-JUL-2009 04:48:02:909] sntuscrt: failed to create dir /tmp/.oracle,在这个报错之后,在443行就[000001 29-JUL-2009 04:48:02:912] nsglhfre: Terminating listening endpoint: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.203.104.11)(PORT=1521))),侦听被终止了。

因此,我们将该问题定位于oracle无法写入/tmp/.oracle,并且通过进一步的检查,发现db01有/tmp/.oracle目录,而db02没这个目录,当我们手工创建/tmp/.oracle,并且chown oracle:dba /tmp/.oracle再次启动侦听,恢复正常了!

我们此时再看了一下/tmp目前的权限,发现:

看来还确实是权限问题,修改db02上的/tmp目前权限为777,和db01一样,这样,下次哪怕/tmp/.oracle目录被删除,也不怕了。

最后打扫战场,停止lsnr的trace。故障处理完成。

相关文章

6条评论

  1. 应该不是所有平台都有这问题,我在linux上测试没有这问题

  2. 遇到这种怪怪的问题,重建一个监听连接,可以吧。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据