關於fast_start_parallel_rollback引數
今天一個客戶報資料庫執行速度很慢,登上去查。
檢查資料庫,發現資料庫中存在很多wait for a undo record等待事件。再檢查發現有很多的併發程式在執行。
通常,如果有很多併發程式,可以根據v$px_session檢視去檢視,檢視v$px_session檢視,發現所有的併發程式都是由smon程式導致(即qcsid列為smon程式的session id)
而smon程式的等待事件為wait for stopper event to be increased
關於這個現象,查詢mos,可以看到相應的解釋和解決方法(464246.1)
In fast-start parallel rollback, the background process SMON acts as a coordinator and rolls back a set of transactions in parallel using multiple server processes.
Fast start parallel rollback is mainly useful when a system has transactions that run a long time before a commit, especially parallel Inserts, Updates, Deletes operations. When SMON discovers that the amount of recovery work is above a certain threshold, it automatically begins parallel rollback by dispersing the work among several parallel processes.
There are cases where parallel transaction recovery is not as fast as serial transaction recovery because the PQ slaves may interfere with each others work by contending for the same resource. With such a transaction rollback performance may be worse in parallel when compared to a serial rollback.
Becasue of this contention and the perceived slowness and 'hang' like symptoms (the database may seem to hang, SMON and parallel query slaves may be seen to take all the available CPU), DBA intervent
即smon程式在做大事務的回滾,預設引數fast_start_parallel_rollback引數為low,即回滾時會啟動2*CPU個數 個併發程式。而由於是使用併發,所以可能由於併發之間相互使用共同的資源,導致回滾速度更慢。
解決方法為將fast_start_parallel_rollback引數改為false
fast_start_paralllel_rollback引數是可以動態修改的,但是對於正在執行大量的回滾操作的資料庫例項來說,可能動態修改會導致一些問題(具體會是什麼問題,oracle官方文件並沒有說),正確修改方法參考官方文件(238507.1)
1.查詢smon程式ID
2.禁用smon程式的事務清理(Disable SMON transaction cleanup)
oradebug setorapid 'SMON's Oracle PID';
oradebug event 10513 trace name context forever, level 2
3.查詢V$FAST_START_SERVERS檢視,將所有smon啟用的併發程式殺掉
4.修改fast_start_parallel_rollback引數
alter system set fast_start_parallel_rollback=false;
5.啟用smon程式的事務清理(enable transaction recovery)
oradebug setorapid 'SMON's Oracle PID';
oradebug event 10513 trace name context off
關於fast_start_paralllel_rollback引數的介紹:
FALSE indicates that parallel rollback is disabled 禁用併發回滾(注意是禁用併發回滾,不是禁用回滾。只是回滾的時候不使用併發)
LOW limits the number of rollback processes to 2 * CPU_COUNT 預設值
HIGH limits the number of rollback processes to 4 * CPU_COUNT
對於資料庫中的回滾事務,可以檢視下面的檢視監控:
V$FAST_START_SERVERS
V$FAST_START_TRANSACTIONS
分別檢視回滾的程式資訊和事務資訊
檢查資料庫,發現資料庫中存在很多wait for a undo record等待事件。再檢查發現有很多的併發程式在執行。
通常,如果有很多併發程式,可以根據v$px_session檢視去檢視,檢視v$px_session檢視,發現所有的併發程式都是由smon程式導致(即qcsid列為smon程式的session id)
而smon程式的等待事件為wait for stopper event to be increased
關於這個現象,查詢mos,可以看到相應的解釋和解決方法(464246.1)
In fast-start parallel rollback, the background process SMON acts as a coordinator and rolls back a set of transactions in parallel using multiple server processes.
Fast start parallel rollback is mainly useful when a system has transactions that run a long time before a commit, especially parallel Inserts, Updates, Deletes operations. When SMON discovers that the amount of recovery work is above a certain threshold, it automatically begins parallel rollback by dispersing the work among several parallel processes.
There are cases where parallel transaction recovery is not as fast as serial transaction recovery because the PQ slaves may interfere with each others work by contending for the same resource. With such a transaction rollback performance may be worse in parallel when compared to a serial rollback.
Becasue of this contention and the perceived slowness and 'hang' like symptoms (the database may seem to hang, SMON and parallel query slaves may be seen to take all the available CPU), DBA intervent
即smon程式在做大事務的回滾,預設引數fast_start_parallel_rollback引數為low,即回滾時會啟動2*CPU個數 個併發程式。而由於是使用併發,所以可能由於併發之間相互使用共同的資源,導致回滾速度更慢。
解決方法為將fast_start_parallel_rollback引數改為false
fast_start_paralllel_rollback引數是可以動態修改的,但是對於正在執行大量的回滾操作的資料庫例項來說,可能動態修改會導致一些問題(具體會是什麼問題,oracle官方文件並沒有說),正確修改方法參考官方文件(238507.1)
1.查詢smon程式ID
2.禁用smon程式的事務清理(Disable SMON transaction cleanup)
oradebug setorapid 'SMON's Oracle PID';
oradebug event 10513 trace name context forever, level 2
3.查詢V$FAST_START_SERVERS檢視,將所有smon啟用的併發程式殺掉
4.修改fast_start_parallel_rollback引數
alter system set fast_start_parallel_rollback=false;
5.啟用smon程式的事務清理(enable transaction recovery)
oradebug setorapid 'SMON's Oracle PID';
oradebug event 10513 trace name context off
關於fast_start_paralllel_rollback引數的介紹:
FALSE indicates that parallel rollback is disabled 禁用併發回滾(注意是禁用併發回滾,不是禁用回滾。只是回滾的時候不使用併發)
LOW limits the number of rollback processes to 2 * CPU_COUNT 預設值
HIGH limits the number of rollback processes to 4 * CPU_COUNT
對於資料庫中的回滾事務,可以檢視下面的檢視監控:
V$FAST_START_SERVERS
V$FAST_START_TRANSACTIONS
分別檢視回滾的程式資訊和事務資訊
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23850820/viewspace-2122654/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 引數FAST_START_PARALLEL_ROLLBACKASTParallel
- 引數FAST_START_PARALLEL_ROLLBACK(ZT)ASTParallel
- fast_start_parallel_rollback引數的一點測試ASTParallel
- 關於靜態引數和動態引數
- oracle 關於--引數檔案Oracle
- 等待事件wait for a undo record 與 fast_start_parallel_rollback引數事件AIASTParallel
- 引數fast_start_parallel_rollback調整oracle回滾的速度ASTParallelOracle
- 關於view.layout方法引數View
- 關於Callback回撥,傳遞引數
- 關於FAST_START_MTTR_TARGET引數AST
- 關於REMOTE_LOGIN_PASSWORDFILE引數REM
- 關於引數fast_start_mttr_targetAST
- 關於MySQL引數,這些你要知道MySql
- MySQL 關於表名大小寫的引數MySql
- 【AMM】關於ASM中AMM引數說明ASM
- 關於引數O7_DICTIONARY_ACCESSIBILITY
- 關於資料庫標識類引數資料庫
- goldengate關於CONVERTUCS2CLOBS引數Go
- 關於修改資料庫引數的測試資料庫
- 關於資料泵impdp引數驗證(一)
- 【ASM學習】關於 ASM 的隱含引數ASM
- 關於 Oracle 10g EXPDP 的 EXCLUDE 引數Oracle 10g
- 關於隱含引數_b_tree_bitmap_plans
- 關鍵字引數與非關鍵字引數(可變引數)詳解
- python疑問5:位置引數,預設引數,可變引數,關鍵字引數,命名關鍵字引數區別Python
- 關於 groutine 喚醒中 skipframes 引數不理解
- javascript關於Array()建構函式引數注意點JavaScript函式
- Oracle 11g 關於 AWR 的引數設定Oracle
- 分享關於js解析URL中的引數的方法JS
- 關於Oracle GoldenGate 引數TRANLOGOPTIONS altarchivelogdestOracleGoHive
- Shell 中 $ 關於指令碼引數的幾種用法指令碼
- 關於C++引用做為函式引數和指標作為函式引數C++函式指標
- 關於查詢不用重啟或者關閉資料庫的引數資料庫
- 關於 Express API app.use 中的 path 引數用法ExpressAPIAPP
- 關於 Angular 應用部署時的 base-href 引數Angular
- 關於python中format佔位符中的 {!} 引數PythonORM
- 關於PGA_AGGREGATE_TARGET的引數說明
- 【AMM】關於資料庫例項AMM引數說明資料庫