❶ oracle数据库运行sql很卡很慢很顿，看等待事件都是cursor:pin s on x,这是啥

详解cursor: pin S wait on X等待事件
‘cursor: pin * events’等待事件
该类等待事件一般是为了pin相关的子游标
‘Cursor: pin S on X’ 最常见的等待事件， 进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。
实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。

下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用:

过多的子游标 High Version Counts

过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。
检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA

昂贵的X$、V$视图查询

一些对于V$、X$视图的查询，需要访问X$KGL*之类的fixed table，可能触发Mutex争用。

Mutex持有者得不到CPU

Mutex持有者若得不到足够的CPU片可能一直阻塞他人，直到它拿到需要的CPU。
这种情况可能由于OS操作系统的实际情况或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。

已经被KILLED的SESSION仍持有Mutex

当session正持有Mutex，而其对应的Process被强制KILL掉， 则直到PMON彻底清理掉该Dead Process并释放Mutex，其他session才能不再等待。 诊断该类问题，最好能检查PMON的TRACE。 当然也存在部分BUG会导致PMON清理过程非常慢。
举例来说，bug 9312879描述了一种场景：PMON 需要获得某个Mutex以便清理某个dead process，但是该Mutex又被其他进程持有，则PMON甚至无法开始真正清理并释放Mutex。

如果自己搞不定可以找ASKMACLEAN专业ORACLE优化团队成员帮您搞定!

❷ access访问数据库为什么很慢很卡

1.ACCESS这个你也知抄道,当数据量大了点的时候遍历一遍是很慢的.而且非常消耗系统资源.
2.你写的一些操作语句,比如查询等语句是不是尽量将语句优化了的(查询一个东西,要用尽量少的语句实现一样的功能,以减少读取数据库的次数)
3.你说到上面服务器内存和客户机器的对比,内存的确是小了点.现在个人机器的内存也开始普及1G了.服务器最少要2G.还有,你的硬盘是不是老化,出现速度减慢等原因.可以用个软件测试下.
4.你是在局域网,就算是用双绞线连接也不会是网速的原因,这点你可以放心.
5.这些原因排除了之后那要看看你的Connection Statement ResultSet
在用完了之后是不是及时关闭了,有的时候这里疏忽了.对整个程序的影响是非常大的.