监听日志太大；内存耗尽；os进程耗尽；CPU过忙；连接风暴；共享池内存收缩...都会导致这种情况
根据网上资料：
当你碰到ORA-12520错误时，如下所示：
英文：
ORA-12520: TNS:listener could not find available handler for requested type of server
中文：
ORA-12520: TNS: 监听程序无法为请求的服务器类型找到可用的处理程序
一般你应该从下面两个方面考虑：
1：数据库是专用服务器，但是在tnsname.ora配置文件中设置的连接方式是shared，这种情况需要修改tnsname.ora配置文件，这种错误情况一般发生在第一次连接数据库服务器。
如下所示，将数据库服务器关闭共享服务器配置后，然后用PL/SQL Developer连接数据库，就会出现ORA-12520错误。
alter system set shared_servers=0 scope=both;
System altered.
2：运行正常的数据库服务器，突然报ORA-12520错误，一般是因为process不够引起的。需要增大processes参数的值。
然而进过检查服务器、客户端都是dedicated模式，且process参数足够。。
接着查看监听日志发现达到4g,现象是从1号开始的，而监听日志不写东西是从上个月31号，现象基本符合，可能是由于监听日志过大引起的
解决：
oracle 监听器日志文件过大导致该文件无法更新
解决操作步骤 ：
lsnrctl set log_status off ### 先把日志状态停掉，这样就不会写监听器日志
现在就可以把 监听器日志文件备份mv 或是 删掉rm
lsnrctl set log_status on ### 重新打开日志，开始记录监听器日志。该文件会自动创建
可以执行 lsnrctl status ，检查监听器日志文件
切记 ： 不能直接 cat /dev/null > listener_testdb1.log 除非在监听器关闭的情况下。
否则，即便文件已经被清空，监听器还是无法执行写入日志的。
另外也可以指定监听器日志文件的名字，而不需要系统生成的文件名：
==========================
如何确定oracle数据库的连接模式是专用，还是共享模式
这个问题既与参数shared_servers、dispatchers有关，还与服务器、客户端的TNSname.ora文件有关系。
在DB端的shared_servers参数控制server是否能接受share server连接,但是，client可以通过在TNSname.ora 来设置强制使用DEDICATED
如下，4种情况：
DB shared_servers = 0 , TNSname.ora server=shared或者不设置 ==> DEDICATED连接
DB shared_servers = 0 , TNSname.ora server=DEDICATED ==> DEDICATED连接
DB shared_servers > 0 , TNSname.ora server=DEDICATED ==> DEDICATED连接
DB shared_servers > 0 , TNSname.ora server=shared或者不设置 ==> Shared连接
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31397003/viewspace-2143099/ ，如需转载，请注明出处，否则将追究法律责任。
