48 个解决方案
#1
能不能连接上，和表空间没有关系。
建议查一下防火墙和网络情况。
建议查一下防火墙和网络情况。
#2
一个应该是网络的问题，和表空间没半毛钱关系。
#3
测试库还是生产库？
#4
两次了，都是删了表空间，重新导入数据，连接访问上就快了，会有缓存文件吗。ping 服务器ip没问题，tnsping会很高，网上说日志文件，删过没效果。防火墙关了
#5
你这应该先反省自己的SQL性能问题，比如统计信息没有与时俱进，表结构设计不能支持程序长久稳定运行，而不是把问题扩大化到整个数据库。
#6
sql性能的话有什么方法可以看到吗，表结构设计如果不支持程序长久稳定运行能否通过sql或者其他具体点的东西看出来吗，查看sql占用的连接数？
#7
没有简单点的方法，如果你感受到整个库慢了，最好有个慢的时段的AWR报告。
或者打开服务器的性能监控工具，比如top，查看耗用资源多的进程，通过进程号到库里查到对应SQL进行优化。
或者你也可以用工具，比如plsql developer的会话管理器，查看数据库慢的时候，有哪些active的会话，都在执行什么SQL，都在经历什么等待事件。
最麻烦的方法，就是你逐一检查应用SQL，并判断在数据增长、并发增加的情况下，该SQL是否可能存在问题？
#8
1、数据库就慢了，怎么个慢法，任何操作都慢？ select 1 from dual；半天才出来？还是你查询业务表慢。
2、tns超时，可能是数据库问题，比如监听异常。但此时，与表空间没有关系
3、sqlplus登陆时，你没加@，没有走监听
4、查看alert日志，看有没有错误
#9
今天一早连接又不行了（正式应用，心脏都快跳出来了。。），9号重建的表空间，运行了4天，刚才用plsql连接就是巨慢，然后报错tns连接超时，数据泵备份数据库都连不上，我又把应用停了，重启了数据库，才导出的数据，然后删除表空间DROP TABLESPACE xxx INCLUDING CONTENTS AND DATAFILES;重建表空间，数据泵导入。再用plsql连接就好了。但是还是没有找到原因
#10
你不能这么玩。
赶紧上AWR吧，能找到点端倪，有很大的可能是因为数据量突变，导致原有的执行计划没法得到之前的性能了，这99.9999999999%不可能是表空间本身给你带来的问题。
#11
嗯，我百度下AWR，没弄过这个
#12
如果你应用卡的时间短的话，我建议你用ASH，因为AWR默认是一个小时采集一次快照的，可能没法仅仅覆盖你的问题时段，也可能包括一些正常或者应用没在跑的时段，问题会被稀释。
#13
我生成了一个-12的ash,这个分析能给指点下吗，
#14
这是一个-12:00的ash
#15
十二个小时
如果可以取十二个小时的话，我上面就不会有“稀释”一说了，因为很多性能数据会被这十二个小时平均掉，这样就很难看出问题。好吧，那么就先来猜一猜。
在sql list中，前面两个update是你的应用跑的，看来很可能是条件上没有索引导致了全表扫描，你可以看下这两个SQL的执行计划（简单点的：plsql dev F5），或者直接查看表上有没有对应字段的索引，如果有，请帖出索引建在哪些字段上。
如果可以取十二个小时的话，我上面就不会有“稀释”一说了，因为很多性能数据会被这十二个小时平均掉，这样就很难看出问题。好吧，那么就先来猜一猜。
在sql list中，前面两个update是你的应用跑的，看来很可能是条件上没有索引导致了全表扫描，你可以看下这两个SQL的执行计划（简单点的：plsql dev F5），或者直接查看表上有没有对应字段的索引，如果有，请帖出索引建在哪些字段上。
#16
另外，无论是AWR还是ASH，本质上都是一段时间内取平均值，所以，精确设置报告起止时间是很重要的！！ 也就是说，你什么时间点开始性能出现问题，什么时间点性能问题结束，这两个点越精确越好，复杂点的，如果在一长段时间内，性能问题间歇性出现，你甚至要在这个大的时间段内再做切割，排除那些系统闲置的时段，打个比方：
某系统早上8：30～10：30出现性能问题，中午10：30～13：30系统很闲很闲，而下午13：30～16：30再次出现性能问题，那么，获取AWR报告最好就取8：30～10：30和13：30～16：30两个，而不是8：30～16：30一个，甚至是0：00～第二天0：00这种跨天的。
之前之所以让取ASH，是因为ASH可以精确到分钟，而AWR默认是一个小时的。
某系统早上8：30～10：30出现性能问题，中午10：30～13：30系统很闲很闲，而下午13：30～16：30再次出现性能问题，那么，获取AWR报告最好就取8：30～10：30和13：30～16：30两个，而不是8：30～16：30一个，甚至是0：00～第二天0：00这种跨天的。
之前之所以让取ASH，是因为ASH可以精确到分钟，而AWR默认是一个小时的。
#17
取时间段那个我明白了。您给看看这sql执行计划和索引
#18
这么看来，前面的推测是对的。
看上去，你把主键索引组合中最后一个字段F_JLBH提到最前面来做为前导字段，这两个SQL的性能都应该解决了，除非这个字段过滤性太差，但看数据值，猜猜应该是不错的样子。
当然如果想进一步优化，为这两个update各自创建对应的组合索引可能效果会更好，不过我想前面这么调整已经够了
#19
嗯，我重建一下索引。还有个问题，游标这个会不会影响，我现在查着系统打开的游标数为308，以前设置的好像是300，昨天我改成1000了
#20
你说open_cursors这个参数？这是单个会话最高的游标数，这个爆掉就说明你程序里没有及时关闭游标啊，需要查查。
#21
如果说是因为同一个会话开了N个update在跑，然后因为性能问题都跑不完，导致游标关闭，那也是可能的。
#22
少敲了个字：“导致游标 未 关闭”
#23
今早又要爆炸
，连接巨慢，数据加载平时2-3秒钟的事，现在都6-7秒
下面贴出数据库文件、连接数、游标数
下面是15分钟内的ash
，连接巨慢，数据加载平时2-3秒钟的事，现在都6-7秒
下面贴出数据库文件、连接数、游标数
下面是15分钟内的ash
#24
现在用plsql dev连接就很卡，tnsping也不稳定- -||
#25
楼主，你现在贴的东西都没有任何帮助，上完整的ASH吧
另外，你也可以用plsql devl的会话管理器，看看是不是大多数会话都堵在同样的SQL上，并看看会话管理器里面，他们的event都对应的是啥
另外，你也可以用plsql devl的会话管理器，看看是不是大多数会话都堵在同样的SQL上，并看看会话管理器里面，他们的event都对应的是啥
#26
另外：
1、v$open_cursor是所有会话打开的总的游标，而open_cursors参数指的是单个会话能同时打开的游标数，你这总共才200+的游标，怎么破得了默认参数的300？更何况你已经改到1000；
2、按照你昨天的那种SQL，2～3秒钟也绝对不是正常的性能，200ms之内还可以接受，除非你的数据分布确实比较奇葩；
3、还是那句话：表空间和你现在的性能问题99.9999999999999%毫无关系；
4、你现在可以用操作系统工具，比top、vmstat、sar，如果是windows的话，就用任务管理器看看数据库服务器操作系统的资源使用情况，以作参考。
1、v$open_cursor是所有会话打开的总的游标，而open_cursors参数指的是单个会话能同时打开的游标数，你这总共才200+的游标，怎么破得了默认参数的300？更何况你已经改到1000；
2、按照你昨天的那种SQL，2～3秒钟也绝对不是正常的性能，200ms之内还可以接受，除非你的数据分布确实比较奇葩；
3、还是那句话：表空间和你现在的性能问题99.9999999999999%毫无关系；
4、你现在可以用操作系统工具，比top、vmstat、sar，如果是windows的话，就用任务管理器看看数据库服务器操作系统的资源使用情况，以作参考。
#28
这感觉不对啊，怎么没活跃会话就卡了？你应用已经停掉了？
#29
应用在运行着，用top看，20秒钟内存占用会跳一下，现在8g内存跑了应用和数据库，我打算把数据库放到一个4g内存的单独服务器上
#30
CPU爆掉了，不知道为啥sys cpu会占用那么高，一般sys cpu高是因为大量的换页引起，可以用vmstat确认下，是否有频繁的pi，po。从top来看，oracle确实有几个进程占用了很多CPU资源，但奇怪的是，为什么你的plsql里没有活跃会话？连错库了？
数据库和应用部署在一起是很不合理，你的数据库内存参数是怎么分配的？memory_target、sga_target、pga_aggregate_target设置的都是多少？
#31
vmstat
会话查看库没连错，
cpu那个一直刷新会出现很高的情况，20秒左右出现一次吧
memory_target 736M，sga_target 0，pga_aggregate_target 0
会话查看库没连错，
cpu那个一直刷新会出现很高的情况，20秒左右出现一次吧
memory_target 736M，sga_target 0，pga_aggregate_target 0
#32
你的意思是你的数据库过一会卡一下这样子的？
#33
应用大部分时间都很卡。就单纯用plsql dev，我从其他数据库切换，登录上都得等个10秒左右，第一个sql查询的时候也是比较慢，要等5秒左右，显示的耗时很少0.14秒。感觉这个长时间的等待耗在建立会话上了
#34
感觉我又得重建表空间了- -|||，，会有缓存问题吗
#35
这系统还真有意思，除非你的描述只是描述你的感受，而不是事实，你添油加醋了，或者你选择性地无视了一些东西，否则从你贴的这些图，还有一些报告的情况来看，不该出现这种情况，到现在还是没法判断是你的数据库整库一级的问题，或者是单点的性能问题，或者是其他问题。
你自己的猜测太多了，可能影响了你对问题的描述，这样吧：如果你早上9点～10点这段时间一直有性能问题的话，就取这个时间段的AWR看看吧。
你自己的猜测太多了，可能影响了你对问题的描述，这样吧：如果你早上9点～10点这段时间一直有性能问题的话，就取这个时间段的AWR看看吧。
#36
找不到可行的解决办法着急，唉。病急乱猜测。不过访问慢是真的，客户都反应过来了
#38
从这一个时段整体平均来看，要不这系统还是比较闲的，要不就是性能问题是一下一下的，并不是持续的。但是有一点很奇怪：你上面说的数据加载6～7秒，这个数据加载包含了多少个SQL？如果是单个SQL的话，从下图来看，肯定不对，图中，第一列框起来的是同样SQL执行的总时间，加起来也没多少秒，第二列框起来的是某条SQL执行的平均时间，低得很，唯一奇怪的就是由plsql dev发起的查询数据字典的SQL，大概就是登录用户时候查询，即使是多个SQL，怕也很难凑出这6～7秒，这问题看上去还不是数据库的问题？我看服务器只是个双核CPU，也够寒碜的
也许真有必要将数据库与应用分离看下是不是应用对数据库产生了负面影响，早上看到的sys CPU很高的问题很挺奇怪的，一直没想通是为什么，系统日志可以看下，看看是不是有奇怪的东西……
BTW：这次看到的SQL都是些select，那俩个update还不是你程序里的主SQL吗？
#39
CSDN这破服务器，老是挂，上贴没写完整，还有句漏了：
唯一奇怪的就是由plsql dev发起的查询数据字典的SQL（就是上贴图中首位的SQL，每次执行平均140秒，也就是两分钟），大概就是登录用户时候显示的左侧表之类对象的内容，这应该是你登录慢的原因，如果使用sqlplus登录，就应该不会卡到跳脚了，这个也许是数据字典统计信息的问题，通常也不太容易发生，除非你的系统有大量的对象删除重建的工作。
唯一奇怪的就是由plsql dev发起的查询数据字典的SQL（就是上贴图中首位的SQL，每次执行平均140秒，也就是两分钟），大概就是登录用户时候显示的左侧表之类对象的内容，这应该是你登录慢的原因，如果使用sqlplus登录，就应该不会卡到跳脚了，这个也许是数据字典统计信息的问题，通常也不太容易发生，除非你的系统有大量的对象删除重建的工作。
#40
是的，8g内存，2个cpu，确实寒碜啊，跑了三个domain，再加个oracle。那个慢应该是访问数据库，建立连接的时候慢，可能是资源不够吧。我现在把库拿到另一个服务器了。再看看吧
#41
应用连接慢，还是plsql developer登录慢？
#42
这俩都慢。应用加载数据和plsql dev登录应该都有建立连接这个过程，就是这慢
#43
单纯访问应用下一个页面不慢，读取数据就慢了
#44
那这个应用慢和plsql dev慢是两回事情，不要又猜着猜着混到一起去。
一个是应用或者从应用到数据库的这条路上有问题，之所以没提数据库中的数据加载SQL有问题，是因为AWR中看不到单次执行很慢的SQL，如果你应用日志中能打印出SQL的执行时间，而且确实可以证实在数据库上耗了很长时间，那么可以有针对性地优化这样的SQL，但前面也提到了，AWR报告中看不到这种耗时长的select，除了plsql dev发起的针对数据字典的查询，plsql dev登录慢是因为查询数据字典显示左侧对象栏慢。
#45
之前遇到过一个,plsq连接不上，比较慢比较卡的，后来删除已一下监听日志，就可以连接上了，当然我安装的windows 上的，日志文件最大2g,所有数据连接的时候要写这个文件；如果之前已经连接的，还可以用，看看或者是sesion 数量满了！
#46
我的结帖怎么没给上分吗，设置了好一阵
#47
話說樓主你這個問題解決了沒？
#48
发现了一个更直接的现象，服务器dns注释掉，连接就很快，打开就很慢，，应该是网络的问题吧- -|||
#1
能不能连接上，和表空间没有关系。
建议查一下防火墙和网络情况。
建议查一下防火墙和网络情况。
#2
一个应该是网络的问题，和表空间没半毛钱关系。
#3
测试库还是生产库？
#4
两次了，都是删了表空间，重新导入数据，连接访问上就快了，会有缓存文件吗。ping 服务器ip没问题，tnsping会很高，网上说日志文件，删过没效果。防火墙关了
#5
你这应该先反省自己的SQL性能问题，比如统计信息没有与时俱进，表结构设计不能支持程序长久稳定运行，而不是把问题扩大化到整个数据库。
#6
sql性能的话有什么方法可以看到吗，表结构设计如果不支持程序长久稳定运行能否通过sql或者其他具体点的东西看出来吗，查看sql占用的连接数？
#7
没有简单点的方法，如果你感受到整个库慢了，最好有个慢的时段的AWR报告。
或者打开服务器的性能监控工具，比如top，查看耗用资源多的进程，通过进程号到库里查到对应SQL进行优化。
或者你也可以用工具，比如plsql developer的会话管理器，查看数据库慢的时候，有哪些active的会话，都在执行什么SQL，都在经历什么等待事件。
最麻烦的方法，就是你逐一检查应用SQL，并判断在数据增长、并发增加的情况下，该SQL是否可能存在问题？
#8
1、数据库就慢了，怎么个慢法，任何操作都慢？ select 1 from dual；半天才出来？还是你查询业务表慢。
2、tns超时，可能是数据库问题，比如监听异常。但此时，与表空间没有关系
3、sqlplus登陆时，你没加@，没有走监听
4、查看alert日志，看有没有错误
#9
今天一早连接又不行了（正式应用，心脏都快跳出来了。。），9号重建的表空间，运行了4天，刚才用plsql连接就是巨慢，然后报错tns连接超时，数据泵备份数据库都连不上，我又把应用停了，重启了数据库，才导出的数据，然后删除表空间DROP TABLESPACE xxx INCLUDING CONTENTS AND DATAFILES;重建表空间，数据泵导入。再用plsql连接就好了。但是还是没有找到原因
#10
你不能这么玩。
赶紧上AWR吧，能找到点端倪，有很大的可能是因为数据量突变，导致原有的执行计划没法得到之前的性能了，这99.9999999999%不可能是表空间本身给你带来的问题。
#11
嗯，我百度下AWR，没弄过这个
#12
如果你应用卡的时间短的话，我建议你用ASH，因为AWR默认是一个小时采集一次快照的，可能没法仅仅覆盖你的问题时段，也可能包括一些正常或者应用没在跑的时段，问题会被稀释。
#13
我生成了一个-12的ash,这个分析能给指点下吗，
#14
这是一个-12:00的ash
#15
十二个小时
如果可以取十二个小时的话，我上面就不会有“稀释”一说了，因为很多性能数据会被这十二个小时平均掉，这样就很难看出问题。好吧，那么就先来猜一猜。
在sql list中，前面两个update是你的应用跑的，看来很可能是条件上没有索引导致了全表扫描，你可以看下这两个SQL的执行计划（简单点的：plsql dev F5），或者直接查看表上有没有对应字段的索引，如果有，请帖出索引建在哪些字段上。
如果可以取十二个小时的话，我上面就不会有“稀释”一说了，因为很多性能数据会被这十二个小时平均掉，这样就很难看出问题。好吧，那么就先来猜一猜。
在sql list中，前面两个update是你的应用跑的，看来很可能是条件上没有索引导致了全表扫描，你可以看下这两个SQL的执行计划（简单点的：plsql dev F5），或者直接查看表上有没有对应字段的索引，如果有，请帖出索引建在哪些字段上。
#16
另外，无论是AWR还是ASH，本质上都是一段时间内取平均值，所以，精确设置报告起止时间是很重要的！！ 也就是说，你什么时间点开始性能出现问题，什么时间点性能问题结束，这两个点越精确越好，复杂点的，如果在一长段时间内，性能问题间歇性出现，你甚至要在这个大的时间段内再做切割，排除那些系统闲置的时段，打个比方：
某系统早上8：30～10：30出现性能问题，中午10：30～13：30系统很闲很闲，而下午13：30～16：30再次出现性能问题，那么，获取AWR报告最好就取8：30～10：30和13：30～16：30两个，而不是8：30～16：30一个，甚至是0：00～第二天0：00这种跨天的。
之前之所以让取ASH，是因为ASH可以精确到分钟，而AWR默认是一个小时的。
某系统早上8：30～10：30出现性能问题，中午10：30～13：30系统很闲很闲，而下午13：30～16：30再次出现性能问题，那么，获取AWR报告最好就取8：30～10：30和13：30～16：30两个，而不是8：30～16：30一个，甚至是0：00～第二天0：00这种跨天的。
之前之所以让取ASH，是因为ASH可以精确到分钟，而AWR默认是一个小时的。
#17
取时间段那个我明白了。您给看看这sql执行计划和索引
#18
这么看来，前面的推测是对的。
看上去，你把主键索引组合中最后一个字段F_JLBH提到最前面来做为前导字段，这两个SQL的性能都应该解决了，除非这个字段过滤性太差，但看数据值，猜猜应该是不错的样子。
当然如果想进一步优化，为这两个update各自创建对应的组合索引可能效果会更好，不过我想前面这么调整已经够了
#19
嗯，我重建一下索引。还有个问题，游标这个会不会影响，我现在查着系统打开的游标数为308，以前设置的好像是300，昨天我改成1000了
#20
你说open_cursors这个参数？这是单个会话最高的游标数，这个爆掉就说明你程序里没有及时关闭游标啊，需要查查。
#21
如果说是因为同一个会话开了N个update在跑，然后因为性能问题都跑不完，导致游标关闭，那也是可能的。
#22
少敲了个字：“导致游标 未 关闭”
#23
今早又要爆炸
，连接巨慢，数据加载平时2-3秒钟的事，现在都6-7秒
下面贴出数据库文件、连接数、游标数
下面是15分钟内的ash
，连接巨慢，数据加载平时2-3秒钟的事，现在都6-7秒
下面贴出数据库文件、连接数、游标数
下面是15分钟内的ash
#24
现在用plsql dev连接就很卡，tnsping也不稳定- -||
#25
楼主，你现在贴的东西都没有任何帮助，上完整的ASH吧
另外，你也可以用plsql devl的会话管理器，看看是不是大多数会话都堵在同样的SQL上，并看看会话管理器里面，他们的event都对应的是啥
另外，你也可以用plsql devl的会话管理器，看看是不是大多数会话都堵在同样的SQL上，并看看会话管理器里面，他们的event都对应的是啥
#26
另外：
1、v$open_cursor是所有会话打开的总的游标，而open_cursors参数指的是单个会话能同时打开的游标数，你这总共才200+的游标，怎么破得了默认参数的300？更何况你已经改到1000；
2、按照你昨天的那种SQL，2～3秒钟也绝对不是正常的性能，200ms之内还可以接受，除非你的数据分布确实比较奇葩；
3、还是那句话：表空间和你现在的性能问题99.9999999999999%毫无关系；
4、你现在可以用操作系统工具，比top、vmstat、sar，如果是windows的话，就用任务管理器看看数据库服务器操作系统的资源使用情况，以作参考。
1、v$open_cursor是所有会话打开的总的游标，而open_cursors参数指的是单个会话能同时打开的游标数，你这总共才200+的游标，怎么破得了默认参数的300？更何况你已经改到1000；
2、按照你昨天的那种SQL，2～3秒钟也绝对不是正常的性能，200ms之内还可以接受，除非你的数据分布确实比较奇葩；
3、还是那句话：表空间和你现在的性能问题99.9999999999999%毫无关系；
4、你现在可以用操作系统工具，比top、vmstat、sar，如果是windows的话，就用任务管理器看看数据库服务器操作系统的资源使用情况，以作参考。
#27
#28
这感觉不对啊，怎么没活跃会话就卡了？你应用已经停掉了？
#29
应用在运行着，用top看，20秒钟内存占用会跳一下，现在8g内存跑了应用和数据库，我打算把数据库放到一个4g内存的单独服务器上
#30
CPU爆掉了，不知道为啥sys cpu会占用那么高，一般sys cpu高是因为大量的换页引起，可以用vmstat确认下，是否有频繁的pi，po。从top来看，oracle确实有几个进程占用了很多CPU资源，但奇怪的是，为什么你的plsql里没有活跃会话？连错库了？
数据库和应用部署在一起是很不合理，你的数据库内存参数是怎么分配的？memory_target、sga_target、pga_aggregate_target设置的都是多少？
#31
vmstat
会话查看库没连错，
cpu那个一直刷新会出现很高的情况，20秒左右出现一次吧
memory_target 736M，sga_target 0，pga_aggregate_target 0
会话查看库没连错，
cpu那个一直刷新会出现很高的情况，20秒左右出现一次吧
memory_target 736M，sga_target 0，pga_aggregate_target 0
#32
你的意思是你的数据库过一会卡一下这样子的？
#33
应用大部分时间都很卡。就单纯用plsql dev，我从其他数据库切换，登录上都得等个10秒左右，第一个sql查询的时候也是比较慢，要等5秒左右，显示的耗时很少0.14秒。感觉这个长时间的等待耗在建立会话上了
#34
感觉我又得重建表空间了- -|||，，会有缓存问题吗
#35
这系统还真有意思，除非你的描述只是描述你的感受，而不是事实，你添油加醋了，或者你选择性地无视了一些东西，否则从你贴的这些图，还有一些报告的情况来看，不该出现这种情况，到现在还是没法判断是你的数据库整库一级的问题，或者是单点的性能问题，或者是其他问题。
你自己的猜测太多了，可能影响了你对问题的描述，这样吧：如果你早上9点～10点这段时间一直有性能问题的话，就取这个时间段的AWR看看吧。
你自己的猜测太多了，可能影响了你对问题的描述，这样吧：如果你早上9点～10点这段时间一直有性能问题的话，就取这个时间段的AWR看看吧。
#36
找不到可行的解决办法着急，唉。病急乱猜测。不过访问慢是真的，客户都反应过来了
#37
#38
从这一个时段整体平均来看，要不这系统还是比较闲的，要不就是性能问题是一下一下的，并不是持续的。但是有一点很奇怪：你上面说的数据加载6～7秒，这个数据加载包含了多少个SQL？如果是单个SQL的话，从下图来看，肯定不对，图中，第一列框起来的是同样SQL执行的总时间，加起来也没多少秒，第二列框起来的是某条SQL执行的平均时间，低得很，唯一奇怪的就是由plsql dev发起的查询数据字典的SQL，大概就是登录用户时候查询，即使是多个SQL，怕也很难凑出这6～7秒，这问题看上去还不是数据库的问题？我看服务器只是个双核CPU，也够寒碜的
也许真有必要将数据库与应用分离看下是不是应用对数据库产生了负面影响，早上看到的sys CPU很高的问题很挺奇怪的，一直没想通是为什么，系统日志可以看下，看看是不是有奇怪的东西……
BTW：这次看到的SQL都是些select，那俩个update还不是你程序里的主SQL吗？
#39
CSDN这破服务器，老是挂，上贴没写完整，还有句漏了：
唯一奇怪的就是由plsql dev发起的查询数据字典的SQL（就是上贴图中首位的SQL，每次执行平均140秒，也就是两分钟），大概就是登录用户时候显示的左侧表之类对象的内容，这应该是你登录慢的原因，如果使用sqlplus登录，就应该不会卡到跳脚了，这个也许是数据字典统计信息的问题，通常也不太容易发生，除非你的系统有大量的对象删除重建的工作。
唯一奇怪的就是由plsql dev发起的查询数据字典的SQL（就是上贴图中首位的SQL，每次执行平均140秒，也就是两分钟），大概就是登录用户时候显示的左侧表之类对象的内容，这应该是你登录慢的原因，如果使用sqlplus登录，就应该不会卡到跳脚了，这个也许是数据字典统计信息的问题，通常也不太容易发生，除非你的系统有大量的对象删除重建的工作。
#40
是的，8g内存，2个cpu，确实寒碜啊，跑了三个domain，再加个oracle。那个慢应该是访问数据库，建立连接的时候慢，可能是资源不够吧。我现在把库拿到另一个服务器了。再看看吧
#41
应用连接慢，还是plsql developer登录慢？
#42
这俩都慢。应用加载数据和plsql dev登录应该都有建立连接这个过程，就是这慢
#43
单纯访问应用下一个页面不慢，读取数据就慢了
#44
那这个应用慢和plsql dev慢是两回事情，不要又猜着猜着混到一起去。
一个是应用或者从应用到数据库的这条路上有问题，之所以没提数据库中的数据加载SQL有问题，是因为AWR中看不到单次执行很慢的SQL，如果你应用日志中能打印出SQL的执行时间，而且确实可以证实在数据库上耗了很长时间，那么可以有针对性地优化这样的SQL，但前面也提到了，AWR报告中看不到这种耗时长的select，除了plsql dev发起的针对数据字典的查询，plsql dev登录慢是因为查询数据字典显示左侧对象栏慢。
#45
之前遇到过一个,plsq连接不上，比较慢比较卡的，后来删除已一下监听日志，就可以连接上了，当然我安装的windows 上的，日志文件最大2g,所有数据连接的时候要写这个文件；如果之前已经连接的，还可以用，看看或者是sesion 数量满了！
#46
我的结帖怎么没给上分吗，设置了好一阵
#47
話說樓主你這個問題解決了沒？
#48
发现了一个更直接的现象，服务器dns注释掉，连接就很快，打开就很慢，，应该是网络的问题吧- -|||