客戶資料庫警告日誌顯示，經檢查是由statspack自動排程指令碼引起的。
[quote]thu jul 22 12:30:14 2010
errors in file /oracle/admin/fysb/bdump/fysb_j000_1805.trc:
ora-12012: error on auto execute of job 82
ora-12005: may not schedule automatic refresh for times in the past[/quote]
將其job刪除
[quote]exec dbms_job.remove('82');[/quote]
再次執行spauto.sql
[quote]sql> @spauto.sql
begin
*error at line 1:
ora-23420: interval must evaluate to a time in the future
ora-06512: at "sys.dbms_job", line 57
ora-06512: at "sys.dbms_job", line 134
ora-06512: at line 3[/quote]
解決辦法
[quote]begin
select instance_number into :instno from v$instance;
dbms_job.submit(:jobno, 'statspack.snap;', trunc(sysdate+1/96,'mi'), 'trunc(sysdate+1/96,''mi'')',true, :instno);
commit;
end;
/[/quote]
順便將統計級別從預設的5，提高至6，用於sql執行計畫分析
[quote]exec statspack.snap(i_snap_level => 6, i_modify_parameter => 'true');[/quote]
記一次database cpu high的處理
基本上，我們的資料庫例項每次cpu飆公升都是因read而起，很少有write導致的cpu高。這說明read，隨機讀，排序，都會占用cpu。而寫入主要是io行為，尤其是順序寫，不需要佔cpu。今次問題，rds在三個小時內都很高，始終維持50 最高甚至到98 當然我們的業務可用性並不依賴rds。觀察一段...
記一次Nginx 400錯誤
在乙個非cdn的網域名稱下有乙個頁面，需要請求cdn網域名稱下的資源。所以在cdn的那臺源站的nginx上設定了 add header access control allow headers x requested with add header access control allow meth...
記一次Nginx 400錯誤
在乙個非cdn的網域名稱下有乙個頁面，需要請求cdn網域名稱下的資源。所以在cdn的那臺源站的nginx上設定了 add header access control allow headers x requested with add header access control allow meth...