分析和解決ora-4030錯誤

來源:互聯網
上載者:User
錯誤|解決
分析和解決ora-4030錯誤



ORA-4030意味著什嗎?



    這個錯誤意味著oracle伺服器處理序不能從作業系統獲得更多的記憶體。這裡的記憶體指的是PGA(程式全域區)以及由配置決定的它的子項。對於專用的伺服器處理序,記憶體包括堆棧區、UGA(使用者全域區)。UGA包括使用者會話資料、遊標資訊和排序區。在多線程配置中(共用伺服器),UGA處於SGA(系統全域區)中,它不會造成ora-4030錯誤。



    因此,ora-4030意味著進程需要更多的記憶體(堆棧、UGA或者PGA)來執行它的工作。



是什麼引起了這個錯誤?



這個錯誤表示作業系統不能分配足夠的記憶體。這個錯誤可能是你的進程本身引起的,例如你的進程需要太多的記憶體,或者其它的原因引起作業系統記憶體枯竭,例如SGA區分得太大或者太多的進程競爭系統虛擬記憶體(實體記憶體+交換分區)。許多作業系統會限制某個進程獲得的記憶體以保證系統穩定。



請按以下步驟檢查你的系統:



·       是否仍有足夠的記憶體供分配?



·       作業系統是否有限制?



·       Oracle資料庫是否有限制?



·       哪一個進程需要過多的記憶體?



·       如何收集那個(需要過多記憶體的)進程正在做什麼的資訊?



這些將在下一節裡討論。



進一步討論主題:



·       避免此類錯誤的一般建議



·       參考



是否仍有足夠的記憶體供分配?



    要回答這個問題,我們需要使用作業系統特定的工具來檢測記憶體使用量情況。



1.OpenVMS系統:顯示那些能告訴你實體記憶體和分頁檔使用方式的資訊。



Physical Memory Usage (pages):



Total         Free         In Use           Modified       Main Memory (256.00Mb)       32768          24849           7500               419



……



Paging File Usage(blocks):




 


Free  Reservable Total



DISK$BOBBIEAXPSYS:[SYS0.SYSEXE]SWAPFILE.SYS  30720  30720      39936 DISK$BOBBIEAXPSYS:[SYS0.SYSEXE]PAGEFILE.SYS  2261    60201088  249984  DISK$BOBBIE_USER3:[SYS0.PAGEFILE]PAGEFILE.SYS 462224  405296  499968



    作為一般的原則,分頁檔中的空閑容量總量應該不低於總容量的一半。分頁檔應該幾乎不使用,閒置容量應該幾乎和總容量一樣。



1.Windows系統:在工作管理員中查看記憶體使用量情況。



2.Unix系統:每一個Unix系統都有自己的工具來檢測全部記憶體的使用方式,例如top,vmstat…..,並且每一個系統都有所不同。



o        top常用來顯示實體記憶體和交換空間的情況。



o        swapon –s 顯示交換空間使用方式



o        vmstat 顯示空閑實體記憶體情況



Sample top output on Linux:



在Linux上“top”的輸出例子:



top - 10:17:09 up  1:27,  4 users,  load average: 0.07, 0.12, 0.05



Tasks: 110 total,  4 running, 105 sleeping,   0 stopped,   1 zombie



Cpu(s):  0.3% user,  1.6% system,  0.0% nice,  98.0% idle



Mem:  1033012k total,  452520k used,  580492k free,  59440k buffers



Swap:  1052248k total,  0k used,    1052248k free,  169192k cached



.....



如果有足夠的記憶體,那麼請檢查一下是否作業系統有強制限制。如果記憶體被耗盡了,我們就要找出這些記憶體被用在了哪裡。



作業系統是否有限制?



如果仍有充足的虛擬記憶體剩餘,可能是我們不能使用申請使用的那部分記憶體。請檢查作業系統是否有限制。



1.OpenVMS系統:要檢查你能使用的實體記憶體的總量,請檢查工作(頁面)區配額(working set quotas)和分頁檔配額(pagefile quota)。請查詢OpenVMS使用指南確定配額情況和如何修改它們。根據使用進程的不同以及啟動它們方式的不同,配額使用將不同於oracle的統計。Process/id=<process id>/quota將顯示對於一個特定的進程還有多少剩餘配額可使用。



UAF> show oracle7



Username: ORACLE7               Owner:  Oracle7 DBA



Account:  SUPPORT               UIC: [200,2] ([SUPPORT,ORACLE7])



CLI:   DCL                  Tables: DCLTABLES



Default:  DISK$BOBBIE_USER1:[ORACLE7]



LGICMD:   LOGINFlags:



Primary days:     Mon    Tue    Wed    Thu    Fri



Secondary days:                     Sat    Sun



No access restrictions



Expiration:    (none) Pwdminimum: 6   Login Fails: 0



Pwdlifetime:   (none) Pwdchange:   3-DEC-1997 15:38



Last Login: 27-MAY-2003 14:54 (interactive), 26-MAY-2003 16:15 (non-interactive)



Maxjobs: 0  Fillm:  1200  Bytlm:  180000



Maxacctjobs:0 Shrfillm:  0  Pbytlm:    0



Maxdetach: 0 BIOlm:  500  JTquota:  8192



Prclm: 20  DIOlm:  500  WSdef:   2500



Prio:  4  ASTlm:  4000  WSquo:  4096



Queprio:0  TQElm:  4000  WSextent:  30000



CPU: (none) Enqlm: 18000  Pgflquo:   750000



Authorized Privileges: .....



$ sho proc/id=20200139/quota



24-JUN-2003 12:30:54.39 User: ORACLE7 Process ID: 20200139



        Node: BOBBIE  Process name: "ORA_BOB901_PMON"



Process Quotas:



Account name: SUPPORT



CPU   limit:  Infinite  Direct I/O limit:100



Buffered I/O byte count quota:   9994816  Buffered I/O limit: 100



Timer queue entry quota: 99  Open file quota:29997



Paging file quota: 145968  Subprocess quota: 10



Default page fault cluster:64  AST quota: 496



Enqueue quota: 49995  Shared file limit: 0



Max detached processes: 0  Max active jobs: 0



2.Windows系統:在微軟的windows作業系統上,oracle進程集作為一個進程的許多線程來運行。地址空間不能超過2GB(包括堆棧、PGA、SGA)。這個限制可以突破到3GB或更高。(請看oracle文檔<NOTE:46001.1>)。關於oracle資料庫和Windows NT記憶體結構的情況,請查詢技術公告板。Oracle進程使用的總的記憶體情況(不包括進程堆棧和代碼)可以用query查看。



3.Unix系統:使用內建的shell命令: limit/ulimit。注意那些unlimited的不一定意味著無限制,而是可能有著老系統的限制,例如2GB。



Linux系統上輸出的一個例子:



aroelant@aroelant-be:~> ulimit -a



core file size(blocks, -c)    0



data seg size(kbytes, -d)   unlimited



file size(blocks, -f)    unlimited



max locked memory(kbytes, -l)    unlimited



max memory size(kbytes, -m)    unlimited



open files(-n)    1024



pipe size(512 bytes, -p)    8



stack size(kbytes, -s)    unlimited



cpu time(seconds, -t)    unlimited



max user processes(-u)    7168



virtual memory(kbytes, -v)  unlimited



有可能是記憶體限制定得太小了,需要增大它。也可能是我們需索得太多



Oracle資料庫是否有限制?



    從oracle 9i以後,有一個參數決定一個oracle執行個體可以分配到PGA總量。<Note:223730.1>"Automatic PGA Memory Managment in 9i"提供了更多關於這方面的資訊。下面的查詢可以用來找出分配給所有會話的PGA地區的記憶體總量。



SQL> select  sum(value)/1024/1024 Mb from v$sesstat s, v$statname n



 Where n.STATISTIC# = s.STATISTIC# and name =’session pga memory’;



哪一個進程需要過多的記憶體?    某些操作需要大量的記憶體例如巨大PL/SQL表或者大量的排序操作。在這種情況下,在返回ora-4030錯誤之前進程將運行一段時間。希望我們可以找出記憶體被分配給哪個進程以及為什麼被分配。你可以使用如下的查詢查出oracle資料庫PGA和UGA的運行情況。



SQL>col name format a30SQL>select sid,name,value from  v$statname n,v$sesstat s 



where n.STATISTIC# = s.STATISTIC# and name like 'session%memory%' order by 3 asc;



這個查詢將顯示列表中的對記憶體“饑餓”的進程。從作業系統角度來看,確定進程的記憶體使用量量也是一個好主意。總之,不大可能是oracle資料庫的伺服器處理序使用了過多的記憶體。一般地,對於伺服器處理序來說,oracle資料庫和作業系統之間或多或少的可以就記憶體的使用達成一致。下面的命令允許你從作業系統的角度找出進程的記憶體使用量量。



1.OpenVMS系統:“show system”命令給出進程和資源的使用方式的概覽。那些頻繁調用頁面失敗的進程常常消耗了大量的虛擬記憶體。“page”列指出實體記憶體的使用方式。“show process/continious”(原文如此,我懷疑是continuous)命令則給出實體記憶體(工作頁面區)和虛擬記憶體的使用方式。



$ show system/page



OpenVMS V7.2-1 on node BOBBIE  13-JUN-2003 09:56:30.44 Uptime  17 18:58:18



Pid   Process    Name    State  Pri   I/O   CPU  Page flts  Pages



20200101 SWAPPER    HIB    16  0   0  00:00:02.45   0     0



20200106 CLUSTER_SERVER HIB   13  104  0  00:00:00.03   87   104



20200107 CONFIGURE   HIB    10  21   0  00:00:00.06  77    17



$ sho process/id=xxx/cont:



Process AROELANT      10:00:53



    State     CUR    Working set    131



Cur/base priority   6/4   Virtual pages   11714



Current PC   800D9B28  CPU time  0 00:00:01.28



Current PSL 00000003   Direct I/O      178



Current user SP 7A5227F0  Buffered I/O    962



PID   20200469     Page faults      1312



UIC [SUPPORT,AROELANT] Event flags   C0000003  C0000000



2.Windows系統:對於微軟的windows作業系統來說,oracle進程集作為一個進程的許多線程來運行。到目前為止,我還沒有找到一個方法來查看某個線程的記憶體使用量情況。然而我們可以檢查出oracle是否對作業系統分配的記憶體感到滿意。從作業系統的角度來看,我們可以使用工作管理員。調出工作管理員,點擊“查看”按鈕,選擇“選擇列”,在彈出的視窗中在“虛擬記憶體大小”前打上勾。oracle.exe進程使用的虛擬記憶體大小( VM size)應該和SGA、PGA和進程堆棧以及代碼使用的記憶體總量相匹配。下面的查詢命令可以給出oracle使用的記憶體量,然而,這不包括進程堆棧以及代碼使用的記憶體量。



select sum(bytes)/1024/1024 Mb from      (select bytes from v$sgastat union        select value bytes from v$sesstat s,v$statname n        where n.STATISTIC# = s.STATISTIC# and             n.name = 'session pga memory'       );MB



----------517.296406



在我的系統上,工作管理員中顯示的虛擬記憶體大小比上面的查詢出的記憶體使用量量多大約30MB。當你確認是oracle使用了這個記憶體,這個查詢將給出哪一個會話用得最多。



3.Unix系統:“top”工具是一個很有用的工具,你能夠定製顯示和排序的列。“ps”命令在大多數系統中可以使用,但也有些不能。例如,在Linux上,“ps -AF --sort resident”將列出所有的進程最近的最大常駐記憶體集(resident set)(注二)。你也可參考<Note:174555.1> "UNIX: Determining the Size of an Oracle Process". 



如何收集那個(需要過多記憶體的)進程正在做什麼的資訊?



    本節將只討論oracle伺服器處理序。使用前面幾節介紹的方法,你應該可以判定一個或多個oracle伺服器處理序造成了記憶體資源的枯竭。記住並不總是由於進程造成了記憶體資源的枯竭從而導致ORA-4030錯誤。這個錯誤僅僅意味著進程不能獲得它需要的記憶體資源。



    如果進程不斷增長對記憶體的需求,我們可以在它啟動並執行時候查看一下它的情況。



o  你可以用下面的查詢語句在v$sql_area表中查詢有什麼進程正在執行中。



SQL> select sql_text  from v$sql_area a, v$session s



where a.address = s.sql_address and s.sid = <SID>;



o  We can force a heapdump and have it examined by oracle support services。(這句不知如何譯)



SQL> oradebug unlimitSQL> oradebug setorapid 10 (這是對應 oracle pid, 用“setospid”對應作業系統的進程id)SQL> oradebug dump heapdump 7



    如果問題不再發生,或者某些進程太快而不能作這樣的檢查,很有可能這就是引起記憶體枯竭的原因。我們可以在這個進程引起這個錯誤時使用事件集來獲得一個 heapdump.



SQL> alter session set events '4030 trace name heapdump level 25';



或者在資料庫的init.ora檔案中設定這個事件。<Note:21234.1> EVENT: 10261 "Limit the size of the PGA heap"    這個dump能協助Oracle Support分析並找出引起過多的記憶體配置的原因。



對於如何避免這個錯誤的一般建議。



o  正如前面提到的一樣,某些操作會需要大量的記憶體。對於排序操作來說,減少SORT_AREA_SIZE可能有所協助。Oracle伺服器處理序會在PGA中分配排序操作需要的SORT_AREA_SIZE位元組。如果完成某個查詢需要過多的記憶體,伺服器處理序將會使用臨時段。這意味著,當查詢需要大量的排序操作時,更少的SORT_AREA_SIZE可以使得執行更緊湊。



o  對於9i或更高版本的oracle資料庫,可以裝置參數WORKAREA_SIZE_POLICY為AUTO來開啟自動SQL execution記憶體管理功能,也可以在初始設定檔案中指定PGA_AGGREGATE_TARGET的大小。



  <Note:262946.1> "Performance Issues After Increasing Workload",   <Note:223730.1> "Automatic PGA Memory Managment in 9i",   <Note:223299.1> "Top Oracle 9i init.ora Parameters Affecting Performance" 



o  PL/SQL常式也可能會需要大量記憶體,因此有必要在你的應用程式中重寫這部分查詢代碼。如果某個PL/SQL表經常被使用,它確實會在PGA中分配一塊記憶體。



o  再看一下最佳化策略,由於排序操作可能某些訪問路徑會需要太多的記憶體,函數調用返回過多的行等等……



o  在某些作業系統上,例如Microsoft windows,SGA的大小應該降低,以便於PGA獲得更大的記憶體。



o  確信你的作業系統和oracle資料庫的記憶體限制是適度的。



o  確信有足夠的記憶體(實體記憶體和交換空間)。



參考



General:



<Note:237899.1> Resolving ORA-4030 Errors After Upgrading



NT:



<Note:116076.1> Tackling ORA-4030 on WindowsNT



<Note:46001.1>  Oracle Database and the Windows NT memory architecture, Technical Bulletin



Unix:



<Note:199746.1> How to Resolve ORA-4030 Errors on UNIX (unix specific but general enough for some suggestions)



UNIX: Determining the Size of an Oracle Process




 


VMS:



<Note:67033.1> Background process quotas <Note:68663.1> Dedicated server process quotas (SQL*Net V2.3.3, V8.0.X)<Note:70671.1> Process quotas for Bequeath connections (V7, V8)<Note:68849.1> Bequeath listener process quotas (V7, V8)<Note:68226.1> Listener process quotas (SQL*Net V2.3.3, V8.0.X)




 


@ Internal:



@ <Note:21234.1> EVENT: 10261 "Limit the size of the PGA heap"



@ This event is very usefull. It will cause the process to dump information when the PGA grows above the specified limit




 


本人注一:工作(頁面)區(working set):1.為避免過多的調頁所必須啟用的使用者頁面的集合。2.為避免系統失效,調頁所需要的實存容量。



本人注二:常駐記憶體集(resident set):在虛存系統中,任一時候都存在於主儲存空間內的某個程式的頁面 或程式段的全部。




 



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。