一、问题描述和分析过程：
alert日志中无限报错ORA-4031
并且sqlplus命令行也无法使用
查询外部应用已经全部关闭，并且无额外调度.
无奈下重启服务器，手动启动数据库报错ORA-00119 ORA-00132
就很奇怪，数据库启动跟监听应该是没有直接关系的
百度后将pfile改成如下
#*.local_listener='LISTENER_ORCL'
*.local_listener='(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.167)(PORT = 1521))'
以pfile启动成功。
但是alert报错改为error getting listening address，注意和上面的报错是不一致的，差点又找不到头绪
查询资料得知是主机名不能被正常访问导致的，
果然hostname和/etc/hosts中的不一致。
修改一致后，重启数据库解决。
最后反想整个过程，数据库开始报错内存不足应该是主机名解析不到而外部应用又不断访问导致内存爆满的一个”假报错“。这说明alert日志中报错并不是百分百准确的，或者是以我目前的理解还无法马上明白这报错的直接含义。
二、反思：
这里有几点需要特别反省：
1、做事没有头绪
上来问题一看是和memory相关，我直接就去看了操作系统内存，然后尝试清空了。首先这是一个非常不好的习惯，除了经常解决的问题，新问题一定要查阅资料，做好备份（或者确认一下这个问题），有一个大致的头绪再来做，上来就搞很有可能造成无法挽回的后果，比如内存被强制清空是否会造成内存中数据的丢失？
2、对现有线索的不尊重
当上面数据库启动之后确实送了一口气，但是看alert日志后只是看起来比较像，但其实已经换了一种报错，这时候再查资料是很轻而易举看出是主机名解析的问题的，而放弃之后再重新理头绪和找线索是很困难的事情了。
3、基础知识不牢固
先查看了/etc/hosts与操作系统[oracle@DZgcyy ~]比对无误就觉得是主机名了，但真正查主机名的命令其实就是最简单的hostname，而这里发现主机名是下面这样的
[oracle@DZgcyy trace]$ hostname
DZgcyy.2
一方面真的想喷死公司省外部署的这些SB，另一反面也确实是自己基础知识掌握的不扎实。
最后，没有思考就没有进步！
