电脑上装了Oracle数据库之后好卡怎么办?

1、首先右键我的电脑，选择管理选项。

2、进入电脑管理界面，展开服务和进程选项，然后选择服务，进入服务的管理界面。

3、在页面右边，依次右键点击所有Oracle开头的服务，选择属性。

4、将启动类型选择为手动就可以了，这样就不会因为数据库卡了。

5、最后以后随时用的时候，再次进入服务界面，把划红线的四项，右键选择启动。

详解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优化团队成员帮您搞定!

1.检查数据库alert日志，查看是否有异常信息。

2.检查数据库状态，查看是否有其它异常情况。

3.检查定时任务程序，查看是否有任务死锁的情况。

4.检查数据库实例，查看是否有资源不足的情况。

5.检查定时任务的执行计划，查看是否有程序错误。

6.检查定时任务的执行日志，查看是否有程序错误。

7.检查定时任务的执行环境，查看是否有程序错误。

---