数据库IO错误，不重启操作系统就无法恢复？请帮忙看看~

zergduan

xiexie 我马上测试一下~：）

zergduan

原帖由 magic007 于 2011-8-11 13:26 发表
memory(kbytes)       32768
这个资源限制的确会影响进程可用内存数量，实际上AIX对进程内存的限制在这个值之上。我曾经遇到过一个这样设置的系统，进程使用的内存在超过100M多一点的时候才报了ORA-04030错误。

下面是我以前的一个测试：



SQL> create or replace procedure test4030 (size_mb in number)
  2  is
  3    TYPE array_char is table of varchar2(32767) index by binary_integer;
  4    data_list array_char;
  5    cnt number:=size_mb*1024/32;
  6  begin
  7    for i in 1..cnt loop
  8     begin
  9      data_list(i):=rpad('a',32767,'a');
10     exception
11     when others then
12       dbms_output.put_line('error at line ' || i || ' msg:' || substr(sqlerrm,1,200));   
13       raise;
14     end;
15    end loop;
16  end;  
17  /
SQL> set serverout on size 1000000
SQL> exec test4030(1);

PL/SQL procedure successfully completed.

SQL> exec test4030(200);

SQL> select pga_max_mem,pga_alloc_mem,pga_used_mem,pga_freeable_mem from v$process where spid='3150056';

PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PGA_FREEABLE_MEM
----------- ------------- ------------ ----------------
  420360601       1847705       660369           917504
可以看到，成功运行这个存储过程，使进程消耗了420M的PGA。



这里size_mb参数只是存储过程中那个数组存储的字符百万个数，实际效率的空间占了约2倍。

你可以用这样的过程，在你的系统上进行测试，看看是不是会报ORA-4030错误，当然前提是ulimit设置保持如前。
可以预期的是，这个过程输入的参数值在100多一点就会报ORA-4030错误。

注意为了排除监听的干扰，直接在主机上不通过监听连接数据库测试。

。。ulimit 参数没有修改root/oracle用户的 memory 依然是23768
运行到300 还是没有ORA-4030。。。


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select sid from v$mystat where rownum<2;

       SID
----------
       150

Elapsed: 00:00:00.01
SQL> select spid from v$process p , v$session s where s.paddr =p.addr and sid=150;

SPID
------------
196810

Elapsed: 00:00:00.01
SQL> select pga_max_mem,pga_alloc_mem,pga_used_mem,pga_freeable_mem from v$process where spid='196810';

PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PGA_FREEABLE_MEM
----------- ------------- ------------ ----------------
     736673        736673       539601                0

Elapsed: 00:00:00.00
SQL> select pga_max_mem,pga_alloc_mem,pga_used_mem,pga_freeable_mem from v$process where spid='196810';

PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PGA_FREEABLE_MEM
----------- ------------- ------------ ----------------
     736673        736673       425929                0

Elapsed: 00:00:00.00
SQL>  create or replace procedure test4030 (size_mb in number)
  2   is
  3     TYPE array_char is table of varchar2(32767) index by binary_integer;
  4     data_list array_char;
  5     cnt number:=size_mb*1024/32;
  6   begin
  7     for i in 1..cnt loop
  8      begin
  9       data_list(i):=rpad('a',32767,'a');
10     exception
11     when others then
12       dbms_output.put_line('error at line ' || i || ' msg:' || substr(sqlerrm,1,200));   
13       raise;
14     end;
15    end loop;
16  end;  
17  /

Procedure created.

Elapsed: 00:00:00.31
SQL> exec test4030(100);

PL/SQL procedure successfully completed.

Elapsed: 00:00:08.94
SQL> select pga_max_mem,pga_alloc_mem,pga_used_mem,pga_freeable_mem from v$process where spid='196810';

PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PGA_FREEABLE_MEM
----------- ------------- ------------ ----------------
  210582945       1654177       561161           917504

Elapsed: 00:00:00.01
SQL> exec test4030(150);

PL/SQL procedure successfully completed.

Elapsed: 00:00:13.37
SQL> select pga_max_mem,pga_alloc_mem,pga_used_mem,pga_freeable_mem from v$process where spid='196810';

PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PGA_FREEABLE_MEM
----------- ------------- ------------ ----------------
  315440545       1654177       561161           917504

Elapsed: 00:00:00.00
SQL> exec test4030(200);

PL/SQL procedure successfully completed.

Elapsed: 00:00:17.88
SQL> select pga_max_mem,pga_alloc_mem,pga_used_mem,pga_freeable_mem from v$process where spid='196810';

PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PGA_FREEABLE_MEM
----------- ------------- ------------ ----------------
  420298145       1654177       561161           917504

Elapsed: 00:00:00.00
SQL> exec test4030(300);

PL/SQL procedure successfully completed.

Elapsed: 00:00:26.77
SQL> select pga_max_mem,pga_alloc_mem,pga_used_mem,pga_freeable_mem from v$process where spid='196810';

PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PGA_FREEABLE_MEM
----------- ------------- ------------ ----------------
  630013345       1654177       561161           917504

Elapsed: 00:00:00.00


在运行过程中不停用ps gv来查看进程内存如下:

其中RSS是进程使用内存 TRS是这个进程和其他进程公用的内存（也就是可执行文件$ORACLE_HOME/bin/oracle）
SIZE近似等于RSS-TRS，也就是近似等于进程私有内存，可以理解为这个进程的PGA~
从下面的红色输出上看 SIZE 最高达到了559M左右，
上面SQLPLSU中也显示最高的PGA_MAX_MEM(红色)曾达到过 630M ~
可见这些都已经远远的突破了LIM 32768KB的限制呀....


cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196808
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196808      - A     0:00    5  5472 50324 32768 90741 44852  0.0  0.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:00    0  4392 49244 32768 90741 44852  0.0  0.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:07   18 199392 244320 32768 90741 44928  0.5  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:08   18  5420 50348 32768 90741 44928  0.6  0.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:17   18 199396 244324 32768 90741 44928  0.7  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:20   18 281312 326240 32768 90741 44928  0.9  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:22   18  5444 50372 32768 90741 44928  0.9  0.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:24   18 68380 113308 32768 90741 44928  0.8  0.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:26   18 101140 146068 32768 90741 44928  0.9  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:27   18 150280 195208 32768 90741 44928  0.9  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:29   18 199420 244348 32768 90741 44928  1.0  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:31   18 232180 277108 32768 90741 44928  1.1  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:32   18 264940 309868 32768 90741 44928  1.1  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:34   18 297700 342628 32768 90741 44928  1.2  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:35   18 330464 375392 32768 90741 44928  1.2  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:37   18 363232 408160 32768 90741 44928  1.3  2.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:39   18 412448 457376 32768 90741 44928  1.3  2.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:39   18  5536 50464 32768 90741 44928  1.3  0.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:40   18 35712 80640 32768 90741 44928  1.0  0.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:44   18 133992 178920 32768 90741 44928  1.1  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:47   18 199512 244440 32768 90741 44928  1.1  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:51   18 281412 326340 32768 90741 44928  1.2  1.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:54   18 363312 408240 32768 90741 44928  1.3  2.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     0:57   18 434808 479736 32768 90741 44928  1.3  2.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     1:00   18 494368 539296 32768 90741 44928  1.4  2.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     1:02   18 559904 604832 32768 90741 44928  1.5  2.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     1:06   18 376932 420836 32768 90741 44928  1.5  2.0 oracleTr
cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196810
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196810      - A     1:07   18  5584 50512 32768 90741 44928  1.6  0.0 oracleTr

[ 本帖最后由 zergduan 于 2011-8-11 14:07 编辑 ]

magic007

是用的sqlplus / as sysdba 或sqlplus username/password这样的方式过去的么？确认你进去的时候oracle用户的ulimit -a显示的内存限制仍然为32768？

zergduan

原帖由 magic007 于 2011-8-11 14:59 发表
是用的sqlplus / as sysdba 或sqlplus username/password这样的方式过去的么？确认你进去的时候oracle用户的ulimit -a显示的内存限制仍然为32768？

步骤如下：
telnet server  
su - oracle
sqlplus xxx/xxx
(确认没有使用$TWO_TASK变量)
cntzunxb02:/tmp#ps -ef |grep 196810
  oracle 196810 254614   0 13:41:20      -  0:00 oracleTraceB (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
    root 217232 226032   0 13:43:13  pts/0  0:00 grep 196810


确定用户oracle的ulimit -a输出入下:
cntzunxb02:/tmp#su - oracle
cntzunxb02:/home/oracle$ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        4194304
memory(kbytes)       32768
coredump(blocks)     unlimited
nofiles(descriptors) 2000

郁闷...

[ 本帖最后由 zergduan 于 2011-8-11 15:40 编辑 ]

magic007

那确实是很郁闷了，这里ulimit似乎也没起到限制的作用。

Yong Huang

I don't have access to an AIX box. But on Solaris and Linux, there's a way to check the running process resource limit. For example, on Linux,

$ ulimit -a | head -1
core file size          (blocks, -c) 0
$ ps -ef | grep [p]mon
oracle   21150     1  0 07:43 ?        00:00:00 asm_pmon_+ASM1
oracle   27437     1  0 08:31 ?        00:00:06 ora_pmon_oracs21
$ cat /proc/27437/limits | grep core
Max core file size        unlimited            unlimited            bytes

So, the limit for your shell process may be different from that for another, running, process.

Secondly, RSS (resident set) should not be your concern. You should focus on virtual memory.

Yong Huang

zergduan

原帖由 Yong Huang 于 2011-8-12 03:39 发表
I don't have access to an AIX box. But on Solaris and Linux, there's a way to check the running process resource limit. For example, on Linux,

$ ulimit -a | head -1
core file size          (blocks, -c) 0
$ ps -ef | grep [p]mon
oracle   21150     1  0 07:43 ?        00:00:00 asm_pmon_+ASM1
oracle   27437     1  0 08:31 ?        00:00:06 ora_pmon_oracs21
$ cat /proc/27437/limits | grep core
Max core file size        unlimited            unlimited            bytes

So, the limit for your shell process may be different from that for another, running, process.

Secondly, RSS (resident set) should not be your concern. You should focus on virtual memory.

Yong Huang

非常感谢 , 我到公司就去看这个进程限制的问题

不过关于进程使用内存的问题,我是根据MOS
AIX: Determining Oracle Memory Usage On AIX [ID 123754.1]
来考虑的~ 文章中指出每一个进程使用的内存是RSS-TRS~
进程的虚拟内存大小是SIZE，在我这个例子中size和 rss-trs近似相等，都远远的超过32768kb。。。

[ 本帖最后由 zergduan 于 2011-8-12 07:09 编辑 ]

Yong Huang

On closer look at your `ps gv' output, you see it already shows the running process memory limit (the LIM column), and it's smaller than various memory values!

cntzunxb02:/tmp#ps gv| head -1 ;ps gv |grep 196808
    PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND
196808      - A     0:00    5  5472 50324 32768 90741 44852  0.0  0.0 oracleTr
...

According to
http://publib.boulder.ibm.com/in ... doc/aixcmds4/ps.htm
"LIM
    (v flag) The soft limit on memory used, specified through a call to the setrlimit subroutine"
I think an Oracle process is first started with the default memory limit, then calls setrlimit() to set it higher (but cannot higher than the hard limit). The ps command, I could be wrong on this point, still shows the original soft limit. Test it by:

ulimit -<the option for memory only>
ps -v -p $$
ulimit to change the memory soft limit
ps -v -p $$

Yong Huang

magic007

从网上查一些资料来看，有的人说rss实际上内核并不限制。这个说法是不是可靠，不得而知，所以这里也不列出地址之类的。

我看了一下，我当时用存储过程得到ORA-04030错误，应该是由于data 的限制，而不是rss。当时data的限制正是131072。

这里提一下硬限制和软限制。
硬限制理解为系统管理员为某个用户下的进程限定的资源限制。
而软限制理解为进程启动时默认的资源限制，进程本身可以通过setrlimit来修改，但是不能超过硬限制。
通过truss对oracle(10.2.0.5)进程进行跟踪可以发现，sqlplus / as sysdba 方式启动进程时，oracle server process重新设置了nofilles和stack的资源限制。

zergduan

非常感谢两位的耐心解答~ 看样子rss这个限制的确是可以突破的~

PS: 我问了一些AIX的管理员，但是没有人知道如何像linux一样查看单个进程的limit~ 但是他们也倾向于rss的限制不是硬性的，是可以随时突破的~