Oracle的過載保護-資料庫資源限制

自己原文公眾號： https://mp.weixin.qq.com/s/ICj9GzMLukriS9ax9qTR8w

一般來說合格的程式設計師都會在上線前對自己程式碼進行檢查，避免全表查詢或者返回大量資料。雖然簡單，同時問題也是最低階的，但是卻是常見也是最多的引起故障的原因。

      在MySQL、PG的慢日誌和Oracle的AWR、甚至Redis的慢日誌中都能找到這些問題。但是很多問題就是不改也是常態。為了保護資料庫不被無節操的SQL衝擊成不可用，把問題降到最低，我們 想辦法做資料庫過載保護。

      在MySQL中：通過設定MAX_QUERIES_PER_HOUR 限制每小時多少次查詢，我這裡簡單設定2，僅做展示。

這是會話級別的。

Oracle中如何做？答：概要檔案。這裡Oracle的內容比MySQL多一些。我這裡僅展示每個user一次請求能使用多少CPU。

select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from sys.dba_profiles where PROFILE='DEFAULT';

可以看到我這裡僅分配了一個會話2個CPU和20個邏輯讀。

把這個限制賦予賬戶。

效果如上圖。直接踢出去。（誰讓你不守規矩）

以上都是會話級別，有沒有例項級別？有。

我設定了一個叫XXG的限制計劃，把這個XXG給到PDB1的這個例項。這個限制是說這個資料庫例項只能用到2%的CPU資源。

設定好CPU了，還有一個防線是IO。

我這裡設定了每秒最大20個IO資料塊和每秒最大5M的讀寫請求。

出現這些就說明IO被限制住了，隻影響PDB1的資源消耗。其他不受影響。

結論：優先、強烈、推薦設定開發規範，並且遵守開發規範（主要是實現邏輯）。在這個基礎上資料庫是穩穩地很少會出問題。就像有時候有人問，這兩個資料庫能合併嗎？怕（效能）出問題。

通常我就回答：您能遵守開發規範嗎？能就可以，不能就不可以。

交通事故死的人不會因為交通工具一次承載的人多而多。飛機也會失事，但是比起5人的小汽車來說，還是安全多了。高鐵一次16節車廂可能有2000人。但是很少出事。因為有規矩。