症狀：
1）早上決策運算過程沒有正常執行；
2）大量io占用，且未出現下降；
3）客戶端幾乎無法連線資料庫；
4）通過em檢視到有大量由於snmp、sysman在執行相關語句的阻塞。
疑問：
1）為毛客戶端連線全部kill後，系統仍然有大量io；
2）重啟後，問題仍存在，現象一樣；
3）為什麼會有那麼 多回滾？
解決：
由於是資料庫本身在解決資料一致性問題，所以償試kill snmp、sysman程序，重啟資料庫後問題仍然存在，這是因為資料庫本身要保證資料庫一致性，所以不管怎麼殺程序，只要重啟smon程序仍會再次執行。
再有同事反饋，在前乙個晚上執行了一條大表資料插入語句，最終卻沒有正常提交，後續的決策運算進行了類似操作，儘管不同表，但由於io已經幾乎被消耗掉後，造成的大量的io等待；
另一方面，系統本身的redolog設定明顯不足也是另乙個誘因。
現在能進行的兩種辦法，一是讓系統加快回滾速度，另一種是沒有時間等待回滾，直接停止。
這裡採用後一種辦法。
sql> shutdown immediate;
sql> startup nomount;
sql> alter system set fast_start_parallel_rollback=false sope=spfile;
sql> shutdown immediate;
sql> startup;
sql> alter system set fast_start_parallel_rollback =highsql> select * from v$transaction;oracle資料回滾
當我們修改了表的資料並且提交了事務後，想回滾資料怎麼辦？先根據sql執行歷史確定資料回滾時間點 select sql text,last load time from v sql where sql text like update order by last load time desc 再將資料...
Oracle資料回滾
select from 表名 as of timestamp to timestamp 2019 04 15 22 00 38 yyyy mm dd hh24 mi ss alter table 表名 enable row movement alter table 表名 disable row mo...
Oracle資料回滾
1 select from 表名 as oftimestamp to timestamp 2019 04 15 22 00 38 yyyy mm dd hh24 mi ss 1 select 2 from 表名 as oftimestamp to timestamp 2019 04 16 21 43...