PGA引發的ORA-04030報錯的處理思路
一個故障案例,報錯資訊如下
ORA-04030: 在嘗試分配 16328 位元組 (koh-kghu call ,kollrsz) 時程式記憶體不足
oerr檢視報錯資訊,是process獲取不到足夠的記憶體,server process消耗的是PGA,而非SGA
[oracle@febdb ~]$ oerr ora 04030
04030, 00000, "out of process memory when trying to allocate %s bytes (%s,%s)"
// *Cause: Operating system process private memory was exhausted.
// *Action:
PGA不足,思路主要檢視PGA、workarea的引數值和例項啟動以來的統計值,可以分4步來處理,第一步查詢引數值、第二步查詢隱含引數值、第三步查詢v$pgastat統計值、第四步分析前面三步的各項值得出結論
第一步
SQL> show parameter pga
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target big integer 8G
SQL> show parameter area_size
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size integer 1048576
create_bitmap_area_size integer 8388608
hash_area_size integer 131072
sort_area_size integer 65536
workarea_size_policy string AUTO
第二步
SQL> col NAME format a25
SQL> col VALUE format a20
SQL> col DESCRIPTION format a55
SQL> set linesize 110
SQL> select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '%_pga_max%';
NAME VALUE DESCRIPTION
--------------- --------------- --------------------------------------------------
_pga_max_size 1717985280 Maximum size of the PGA memory for one process
SQL> select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '%smm_max%';
NAME VALUE DESCRIPTION
-------------------- --------------- -------------------------------------------------------
_smm_max_size_static 838860 static maximum work area size in auto mode (serial)
_smm_max_size 838860 maximum work area size in auto mode (serial)
SQL> select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '%smm_px%';
NAME VALUE DESCRIPTION
------------------------- --------------- -------------------------------------------------------
_smm_px_max_size_static 4194304 static maximum work area size in auto mode (global)
_smm_px_max_size 4194304 maximum work area size in auto mode (global)
一個程式最大的PGA值,本案例中是1717985280B(_pga_max_size的單位是B)
自動模式下,一個程式的PGA的最大work area值,本案例中是838860KB(_smm_max_size的單位是KB,此值一般是_pga_max_size的50%)
自動模式下,所有程式的PGA最大work area總量值,本案例中是4194304KB(_smm_px_max_size的單位是KB,此值一般是PGA_AGGREGATE_TARGET引數的50%)
第三步
SQL> col value format 9999999999999999
SQL> col name format a40
SQL> select * from v$pgastat where name in ('aggregate PGA target parameter','maximum PGA allocated','maximum PGA used for auto workareas','maximum PGA used for manual workareas','total PGA allocated','total PGA inuse','cache hit percentage') order by 1;
NAME VALUE UNIT
---------------------------------------- ----------------- ------------
aggregate PGA target parameter 8589934592 bytes
cache hit percentage 97 percent
maximum PGA allocated 29975256064 bytes
maximum PGA used for auto workareas 3414564864 bytes
maximum PGA used for manual workareas 2713600 bytes
total PGA allocated 15749543936 bytes
total PGA inuse 12480521216 bytes
aggregate PGA target parameter
Current value of the PGA_AGGREGATE_TARGET initialization parameter
--當前PGA的引數值,本案例中為8589934592bytes,和引數pga_aggregate_target值一樣
cache hit percentage
A value of 100% means that all work areas executed by the system since instance startup have used an optimal amount of PGA memory.
--小於100%表示排序等消耗work areas的操作不一定都是在PGA完成,而是work areas走了磁碟使用了臨時表空間,本案例中為97%
maximum PGA allocated
Maximum number of bytes of PGA memory allocated at one time since instance startup
--PGA曾經達到的最大值,本案例中為29975256064bytes
maximum PGA used for auto workareas
Maximum amount of PGA memory consumed at one time by work areas running under the automatic memory management mode since instance startup
--自動模式下的work areas曾經達到的最大值,本案例中為3414564864bytes
maximum PGA used for manual workareas
Maximum amount of PGA memory consumed at one time by work areas running under the manual memory management mode since instance startup.
--手工模式下的work areas曾經達到的最大值,本案例中為2713600bytes
total PGA allocated
Current amount of PGA memory allocated by the instance. The Oracle Database attempts to keep this number below the value of the PGA_AGGREGATE_TARGET initialization parameter. However, it is possible for the PGA allocated to exceed that value by a small percentage and for a short period of time when the work area workload is increasing very rapidly or when PGA_AGGREGATE_TARGET is set to a small value.
--當前PGA的真實值,本案例中為15749543936 bytes
Oracle資料庫試圖將這個數字保持在PGA_AGGREGATE_TARGET初始化引數的值以下。然而,PGA可以在短時間內以較小的百分比分配超過該值,當工作區域的工作負載增長非常快,或者當PGA_AGGREGATE_TARGET被設定為一個小的值時,這是可能的。
total PGA inuse
Indicates how much PGA memory is currently consumed by work areas
--當前work areas的真實值。本案例中為12480521216bytes
第四步
根據以上1、2、3的資料,分析是PGA不足還是workarea_size_policy設定為AUTO的問題。
如果PGA不足,重新設定引數pga_aggregate_target,使用更大值
如果PGA設定很大後,還是保報錯,則設定引數值workarea_size_policy為MANUAL,再根據業務設定*area_size這些引數的值。
--本案例明顯是因為PGA不足引發,設定PGA引數值為20G解決。
ORA-04030: 在嘗試分配 16328 位元組 (koh-kghu call ,kollrsz) 時程式記憶體不足
oerr檢視報錯資訊,是process獲取不到足夠的記憶體,server process消耗的是PGA,而非SGA
[oracle@febdb ~]$ oerr ora 04030
04030, 00000, "out of process memory when trying to allocate %s bytes (%s,%s)"
// *Cause: Operating system process private memory was exhausted.
// *Action:
第一步
SQL> show parameter pga
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target big integer 8G
SQL> show parameter area_size
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size integer 1048576
create_bitmap_area_size integer 8388608
hash_area_size integer 131072
sort_area_size integer 65536
workarea_size_policy string AUTO
第二步
SQL> col NAME format a25
SQL> col VALUE format a20
SQL> col DESCRIPTION format a55
SQL> set linesize 110
SQL> select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '%_pga_max%';
NAME VALUE DESCRIPTION
--------------- --------------- --------------------------------------------------
_pga_max_size 1717985280 Maximum size of the PGA memory for one process
SQL> select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '%smm_max%';
NAME VALUE DESCRIPTION
-------------------- --------------- -------------------------------------------------------
_smm_max_size_static 838860 static maximum work area size in auto mode (serial)
_smm_max_size 838860 maximum work area size in auto mode (serial)
SQL> select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '%smm_px%';
NAME VALUE DESCRIPTION
------------------------- --------------- -------------------------------------------------------
_smm_px_max_size_static 4194304 static maximum work area size in auto mode (global)
_smm_px_max_size 4194304 maximum work area size in auto mode (global)
一個程式最大的PGA值,本案例中是1717985280B(_pga_max_size的單位是B)
自動模式下,一個程式的PGA的最大work area值,本案例中是838860KB(_smm_max_size的單位是KB,此值一般是_pga_max_size的50%)
自動模式下,所有程式的PGA最大work area總量值,本案例中是4194304KB(_smm_px_max_size的單位是KB,此值一般是PGA_AGGREGATE_TARGET引數的50%)
第三步
SQL> col value format 9999999999999999
SQL> col name format a40
SQL> select * from v$pgastat where name in ('aggregate PGA target parameter','maximum PGA allocated','maximum PGA used for auto workareas','maximum PGA used for manual workareas','total PGA allocated','total PGA inuse','cache hit percentage') order by 1;
NAME VALUE UNIT
---------------------------------------- ----------------- ------------
aggregate PGA target parameter 8589934592 bytes
cache hit percentage 97 percent
maximum PGA allocated 29975256064 bytes
maximum PGA used for auto workareas 3414564864 bytes
maximum PGA used for manual workareas 2713600 bytes
total PGA allocated 15749543936 bytes
total PGA inuse 12480521216 bytes
aggregate PGA target parameter
Current value of the PGA_AGGREGATE_TARGET initialization parameter
--當前PGA的引數值,本案例中為8589934592bytes,和引數pga_aggregate_target值一樣
cache hit percentage
A value of 100% means that all work areas executed by the system since instance startup have used an optimal amount of PGA memory.
--小於100%表示排序等消耗work areas的操作不一定都是在PGA完成,而是work areas走了磁碟使用了臨時表空間,本案例中為97%
maximum PGA allocated
Maximum number of bytes of PGA memory allocated at one time since instance startup
--PGA曾經達到的最大值,本案例中為29975256064bytes
maximum PGA used for auto workareas
Maximum amount of PGA memory consumed at one time by work areas running under the automatic memory management mode since instance startup
--自動模式下的work areas曾經達到的最大值,本案例中為3414564864bytes
maximum PGA used for manual workareas
Maximum amount of PGA memory consumed at one time by work areas running under the manual memory management mode since instance startup.
--手工模式下的work areas曾經達到的最大值,本案例中為2713600bytes
total PGA allocated
Current amount of PGA memory allocated by the instance. The Oracle Database attempts to keep this number below the value of the PGA_AGGREGATE_TARGET initialization parameter. However, it is possible for the PGA allocated to exceed that value by a small percentage and for a short period of time when the work area workload is increasing very rapidly or when PGA_AGGREGATE_TARGET is set to a small value.
--當前PGA的真實值,本案例中為15749543936 bytes
Oracle資料庫試圖將這個數字保持在PGA_AGGREGATE_TARGET初始化引數的值以下。然而,PGA可以在短時間內以較小的百分比分配超過該值,當工作區域的工作負載增長非常快,或者當PGA_AGGREGATE_TARGET被設定為一個小的值時,這是可能的。
total PGA inuse
Indicates how much PGA memory is currently consumed by work areas
--當前work areas的真實值。本案例中為12480521216bytes
第四步
根據以上1、2、3的資料,分析是PGA不足還是workarea_size_policy設定為AUTO的問題。
如果PGA不足,重新設定引數pga_aggregate_target,使用更大值
如果PGA設定很大後,還是保報錯,則設定引數值workarea_size_policy為MANUAL,再根據業務設定*area_size這些引數的值。
--本案例明顯是因為PGA不足引發,設定PGA引數值為20G解決。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30126024/viewspace-2152119/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- rails gem報錯的處理AI
- 處理高併發的一般思路
- pga相關引數
- Gulp壓縮報錯處理
- 堆疊溢位報錯引發的思考
- JavaScript 中的引數處理JavaScript
- CMake出錯的處理
- go的錯誤處理Go
- axios 的錯誤處理iOS
- 處理VM的一種特殊方法和思路
- Mysql自動處理同步報錯MySql
- Python 入門級報錯處理Python
- Too many open files報錯處理
- grpc中的錯誤處理RPC
- 在使用 zabbix 4 時, orabbix 會報錯的處理方法
- 高併發處理思路與手段(一):擴容
- @AllArgsConstructor與@Value共同使用引發的報錯問題Struct
- group by 引發的錯誤
- 【Ansible】Ansible 連線主機顯示報錯的處理方案
- Restful API 中的錯誤處理RESTAPI
- 請教 Element 的錯誤處理
- 【譯】RxJava 中的錯誤處理RxJava
- SAP CRM點了附件的超連結後報錯的處理方式
- Android開發:系統程式中使用Webview引發異常的處理AndroidWebView
- ORA-04030: out of process memory ...(initSubHeap:qk...)的錯誤解決
- 寫給go開發者的gRPC教程-錯誤處理GoRPC
- Go 錯誤處理新思路?用左側函式和表示式Go函式
- 前端的水平線,錯誤處理和除錯前端除錯
- 11.2.0.1bug引發的報錯:ORA-07445: exception encounteredException
- MyBatis 引數處理MyBatis
- git上傳檔案時報錯常見的處理辦法Git
- 錯誤處理
- axios 後端拿不到引數的處理iOS後端
- 說說你對異常處理和錯誤處理的理解
- Go 併發 2.2:錯誤處理模式Go模式
- 詳述一條SQL引發的高CPU故障處理過程SQL
- 談談RxSwift中的錯誤處理Swift
- 基於 React Redux 的錯誤處理ReactRedux