在Oracle10gR2中調整過於頻繁user commit的一個方法
我們知道在以往的Oracle版本中,如果commit,那麼後臺的LGWR程式一定會將記憶體中的redo資料寫入online redo log檔案中,然後再將控制權返回給使用者(當然,其實這段也可能不是磁碟操作,而是寫入到磁碟緩衝中)。如果應用中有過於頻繁的使用者commit,那麼可能會產生明顯的log file sync的等待事件。
而Oracle10g中的新功能-Asynchronous Commit可能是解決這個問題的一個新方法(只是看文件自己猜測,並沒有真正實踐)。
在Oracle10g中我們可以設定commit的行為來做到在commit之後,控制權立刻返回給使用者,而Oracle會在恰當的時候喚醒LGWR,批量更新online redo log檔案。
我們可以作系統級的更改:
ALTER SYSTEM SET COMMIT_WRITE = BATCH, NOWAIT
同樣也可以在commit時單獨使用:
COMMIT WRITE BATCH NOWAIT
但是問題在於,這樣作的結果,是否意味著即使commit了的事務,在資料庫恢復時也是不一定找得回來的。用安全換效率,迫不得已的做法吧。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/730796/viewspace-573271/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- zt:Oracle10gR2中調整user commit的實用方法OracleMIT
- js防止事件激發過於頻繁JS事件
- Git調整commit之間順序GitMIT
- Oracle10gR2自動檢查點調整的新特性Oracle
- ORACLE中seq$表更新頻繁的分析Oracle
- 關於快速排序中元素調整方法的分析排序
- Git批量修改歷史commit中的user.name 和user.emailGitMITAI
- windows7 頻繁當機的解決方法Windows
- win10系統中動態詞頻調整灰色無法開啟的解決方法Win10
- 批量調整視訊尺寸大小的方法,一鍵自動批量調整視訊
- RabbitMQ 處理過慢,原來是一個 SQL 快取框架導致的 GC 頻繁觸發MQSQL快取框架GC
- 一次JVM_OLD區佔用過高、頻繁Full GC的解決過程JVMGC
- docker通過commit命令提交一個映象DockerMIT
- user commit (118)MIT
- 一次效能優化調整過程.優化
- JavaScript:面試頻繁出現的幾個易錯點JavaScript面試
- python中的一個現象,db.commit和db.commit()PythonMIT
- [筆記]關於調整的一些建議筆記
- 又抓了一個導致頻繁GC的鬼--陣列動態擴容GC陣列
- Nginx調整(一)Nginx
- 如何處理頻繁建立物件然後丟棄導致頻繁GC的情況物件GC
- 有關效能調整的查詢和pub上的一個sql調優!SQL
- 關於學習心態的調整
- IT頻繁跳槽不是錯薦
- 頻繁GC (Allocation Failure)及young gc時間過長分析GCAI
- 透過外部表改進一個繁瑣的大查詢
- 通過外部表改進一個繁瑣的大查詢
- laravel 在一個控制器的方法中呼叫其他控制器中的方法Laravel
- pytorch---在訓練中動態的調整學習率PyTorch
- 網咖頻繁掉線(ARP)與解決方法(轉)
- vue的第一個commit分析VueMIT
- 一個commit引發的思考MIT
- MySQL如何通過分析binlog日誌找出操作頻繁的表MySql
- SharedPreferences中的commit和apply方法MITAPP
- WebAPI在MVC4下的調整(4)WebAPIMVC
- GitHub 近期頻繁當機?官方解釋:MySQL 負載過重GithubMySql負載
- 用於效能調整的動態效能檢視——效能調整手冊和參考
- 關於appium在安卓上頻繁安裝unlock、setting.apk的問題查詢記錄APP安卓APK