sql太卡

⑴ 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優化團隊成員幫您搞定!

⑵ 電腦上裝了Oracle資料庫之後好卡怎麼辦

1、首先右鍵我的電腦，選擇管理選項。

⑶ 運行oracle資料庫對電腦硬體配置的最低要求是什麼

基本運行硬體應該是兩個多核64位CPU，4G內存並安裝64位操作系統的伺服器。