Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

92

积分

0

好友

0

主题
1#
发表于 2012-7-25 10:18:26 | 查看: 17222| 回复: 23
ORA-04030-ORA-04030: 在尝试分配 127000 字节 (QERHJ hash-joi,kllcqas:kllsltba) 时进程内存不足.oracle 信息和AIX信息都在附件上,咋整啊

workareaoverview.txt

23.81 KB, 下载次数: 866

support.txt

18.89 KB, 下载次数: 849

2#
发表于 2012-7-25 10:24:25
-ORA-04030 报错的具体时间是多少? 上传alert.log

回复 只看该作者 道具 举报

3#
发表于 2012-7-25 10:36:21
alert log没有报ora-04030错误。下面贴了2天是LOG,我在PLSQL执行sql的时候报的ora-04030

$ tail -100f alert_wasudb.log
  Current log# 1 seq# 3937 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 18:15:21 GMT+08:00 2012Thread 1 advanced to log sequence 3938 (LGWR switch)
  Current log# 2 seq# 3938 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 18:34:40 GMT+08:00 2012Thread 1 advanced to log sequence 3939 (LGWR switch)
  Current log# 3 seq# 3939 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 19:01:02 GMT+08:00 2012Thread 1 advanced to log sequence 3940 (LGWR switch)
  Current log# 1 seq# 3940 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 19:13:12 GMT+08:00 2012Thread 1 advanced to log sequence 3941 (LGWR switch)
  Current log# 2 seq# 3941 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 19:28:58 GMT+08:00 2012Thread 1 advanced to log sequence 3942 (LGWR switch)
  Current log# 3 seq# 3942 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 19:36:17 GMT+08:00 2012Thread 1 advanced to log sequence 3943 (LGWR switch)
  Current log# 1 seq# 3943 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 19:44:16 GMT+08:00 2012Thread 1 advanced to log sequence 3944 (LGWR switch)
  Current log# 2 seq# 3944 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 19:52:05 GMT+08:00 2012Thread 1 advanced to log sequence 3945 (LGWR switch)
  Current log# 3 seq# 3945 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 20:05:21 GMT+08:00 2012Thread 1 advanced to log sequence 3946 (LGWR switch)
  Current log# 1 seq# 3946 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 20:21:25 GMT+08:00 2012Thread 1 advanced to log sequence 3947 (LGWR switch)
  Current log# 2 seq# 3947 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 20:34:05 GMT+08:00 2012Thread 1 advanced to log sequence 3948 (LGWR switch)
  Current log# 3 seq# 3948 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 20:54:22 GMT+08:00 2012Thread 1 advanced to log sequence 3949 (LGWR switch)
  Current log# 1 seq# 3949 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 21:00:48 GMT+08:00 2012Thread 1 advanced to log sequence 3950 (LGWR switch)
  Current log# 2 seq# 3950 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 21:17:15 GMT+08:00 2012Thread 1 advanced to log sequence 3951 (LGWR switch)
  Current log# 3 seq# 3951 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 21:25:42 GMT+08:00 2012Starting control autobackup
Control autobackup written to SBT_TAPE device
        comment 'API Version 2.0,MMS Version 9.0.0.84',
        media '0003000F'
        handle 'c-2636392755-20120724-00'
Tue Jul 24 21:26:15 GMT+08:00 2012ALTER SYSTEM ARCHIVE LOG
Tue Jul 24 21:26:15 GMT+08:00 2012Thread 1 cannot allocate new log, sequence 3952
Private strand flush not complete
  Current log# 3 seq# 3951 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 21:26:17 GMT+08:00 2012Thread 1 advanced to log sequence 3952 (LGWR switch)
  Current log# 1 seq# 3952 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 21:26:18 GMT+08:00 2012ALTER SYSTEM ARCHIVE LOG
Tue Jul 24 21:26:18 GMT+08:00 2012Thread 1 cannot allocate new log, sequence 3953
Private strand flush not complete
  Current log# 1 seq# 3952 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 21:26:20 GMT+08:00 2012Thread 1 advanced to log sequence 3953 (LGWR switch)
  Current log# 2 seq# 3953 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 21:28:13 GMT+08:00 2012Starting control autobackup
Control autobackup written to SBT_TAPE device
        comment 'API Version 2.0,MMS Version 9.0.0.84',
        media '0003000F'
        handle 'c-2636392755-20120724-01'
Tue Jul 24 22:00:24 GMT+08:00 2012Thread 1 advanced to log sequence 3954 (LGWR switch)
  Current log# 3 seq# 3954 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 22:13:59 GMT+08:00 2012Thread 1 advanced to log sequence 3955 (LGWR switch)
  Current log# 1 seq# 3955 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 22:33:19 GMT+08:00 2012Thread 1 advanced to log sequence 3956 (LGWR switch)
  Current log# 2 seq# 3956 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 22:51:52 GMT+08:00 2012Thread 1 advanced to log sequence 3957 (LGWR switch)
  Current log# 3 seq# 3957 mem# 0: /data/oradata/wasudb/redo03.log
Tue Jul 24 23:19:43 GMT+08:00 2012Thread 1 advanced to log sequence 3958 (LGWR switch)
  Current log# 1 seq# 3958 mem# 0: /data/oradata/wasudb/redo01.log
Tue Jul 24 23:25:49 GMT+08:00 2012Thread 1 advanced to log sequence 3959 (LGWR switch)
  Current log# 2 seq# 3959 mem# 0: /data/oradata/wasudb/redo02.log
Tue Jul 24 23:42:09 GMT+08:00 2012Thread 1 advanced to log sequence 3960 (LGWR switch)
  Current log# 3 seq# 3960 mem# 0: /data/oradata/wasudb/redo03.log
Wed Jul 25 00:05:19 GMT+08:00 2012Thread 1 advanced to log sequence 3961 (LGWR switch)
  Current log# 1 seq# 3961 mem# 0: /data/oradata/wasudb/redo01.log
Wed Jul 25 00:31:07 GMT+08:00 2012Thread 1 advanced to log sequence 3962 (LGWR switch)
  Current log# 2 seq# 3962 mem# 0: /data/oradata/wasudb/redo02.log
Wed Jul 25 00:59:27 GMT+08:00 2012Thread 1 advanced to log sequence 3963 (LGWR switch)
  Current log# 3 seq# 3963 mem# 0: /data/oradata/wasudb/redo03.log
Wed Jul 25 01:12:01 GMT+08:00 2012Thread 1 advanced to log sequence 3964 (LGWR switch)
  Current log# 1 seq# 3964 mem# 0: /data/oradata/wasudb/redo01.log
Wed Jul 25 01:49:53 GMT+08:00 2012Thread 1 advanced to log sequence 3965 (LGWR switch)
  Current log# 2 seq# 3965 mem# 0: /data/oradata/wasudb/redo02.log
Wed Jul 25 03:57:18 GMT+08:00 2012Thread 1 advanced to log sequence 3966 (LGWR switch)
  Current log# 3 seq# 3966 mem# 0: /data/oradata/wasudb/redo03.log
Wed Jul 25 05:00:04 GMT+08:00 2012Thread 1 advanced to log sequence 3967 (LGWR switch)
  Current log# 1 seq# 3967 mem# 0: /data/oradata/wasudb/redo01.log
Wed Jul 25 06:24:55 GMT+08:00 2012Thread 1 advanced to log sequence 3968 (LGWR switch)
  Current log# 2 seq# 3968 mem# 0: /data/oradata/wasudb/redo02.log
Wed Jul 25 08:05:00 GMT+08:00 2012Thread 1 advanced to log sequence 3969 (LGWR switch)
  Current log# 3 seq# 3969 mem# 0: /data/oradata/wasudb/redo03.log
Wed Jul 25 08:38:38 GMT+08:00 2012Thread 1 advanced to log sequence 3970 (LGWR switch)
  Current log# 1 seq# 3970 mem# 0: /data/oradata/wasudb/redo01.log
Wed Jul 25 08:53:44 GMT+08:00 2012Thread 1 advanced to log sequence 3971 (LGWR switch)
  Current log# 2 seq# 3971 mem# 0: /data/oradata/wasudb/redo02.log
Wed Jul 25 09:08:19 GMT+08:00 2012Thread 1 advanced to log sequence 3972 (LGWR switch)
  Current log# 3 seq# 3972 mem# 0: /data/oradata/wasudb/redo03.log
Wed Jul 25 09:39:09 GMT+08:00 2012ALTER SYSTEM SET pga_aggregate_target='1000M' SCOPE=BOTH;
Wed Jul 25 09:40:04 GMT+08:00 2012ALTER SYSTEM SET pga_aggregate_target='6000M' SCOPE=BOTH;
Wed Jul 25 09:41:38 GMT+08:00 2012ALTER SYSTEM SET pga_aggregate_target='4000M' SCOPE=BOTH;
Wed Jul 25 09:43:29 GMT+08:00 2012Thread 1 advanced to log sequence 3973 (LGWR switch)
  Current log# 1 seq# 3973 mem# 0: /data/oradata/wasudb/redo01.log
Wed Jul 25 10:04:33 GMT+08:00 2012Thread 1 advanced to log sequence 3974 (LGWR switch)
  Current log# 2 seq# 3974 mem# 0: /data/oradata/wasudb/redo02.log
Wed Jul 25 10:14:53 GMT+08:00 2012Thread 1 advanced to log sequence 3975 (LGWR switch)
  Current log# 3 seq# 3975 mem# 0: /data/oradata/wasudb/redo03.log
Wed Jul 25 10:31:33 GMT+08:00 2012Thread 1 advanced to log sequence 3976 (LGWR switch)
  Current log# 1 seq# 3976 mem# 0: /data/oradata/wasudb/redo01.log

回复 只看该作者 道具 举报

4#
发表于 2012-7-25 12:27:25
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 6000M


PGA自动管理6000M


NAME                                          VALUE UNIT
---------------------------------------- ---------- ----------
aggregate PGA target parameter                 6000 MBytes
aggregate PGA auto target                      5353 MBytes
global memory bound                             100 MBytes
total PGA inuse                                  56 MBytes
total PGA allocated                              74 MBytes
maximum PGA allocated                           119 MBytes
total freeable PGA memory                        12 MBytes
process count                                    31
max processes count                              32
PGA memory freed back to OS                    8071 MBytes
total PGA used for auto workareas                 4 MBytes
maximum PGA used for auto workareas               5 MBytes
total PGA used for manual workareas               0 MBytes
maximum PGA used for manual workareas             0 MBytes
over allocation count                             0
bytes processed                               15810 MBytes
extra bytes read/written                          7 MBytes
cache hit percentage                          99.95 percent
recompute count (total)                      800398

实际最大分配 119M

QERHJ hash-joi,kllcqas:kllsltba= > 说明PGA 可能由于hash join而出现ORA-04031




你具体 引发ORA-04030的语句是什么 、是什么时间点,  如果需要贴alert.log 请以附件形式贴出完整的alert.log


目前来看信息 不足 无法判断原因



建议你设置ORA-4030 event:

ALTER SYSTEM SET EVENTS '4030 trace name errorstack level  3';

当下次发生4030问题时会生成errorstack trace

回复 只看该作者 道具 举报

5#
发表于 2012-7-25 13:53:41
上传了完整alert和trace

wasudb_ora_6095604.rar

629.65 KB, 下载次数: 997

alert_wasudb.rar

84.32 KB, 下载次数: 1003

回复 只看该作者 道具 举报

6#
发表于 2012-7-25 13:54:56
这个是出现问题的sql
select distinct a1.target_file_name,
                a1.content_name,
                round(a6.duration),
                a5.meta_data_type,
                a3.name,
                round((a1.begin_time - a1.create_time) * 24 * 3600),
                round((a1.end_time - a1.begin_time) * 24 * 3600),
                round(a2.file_size / 1024 / 1024),
                a1.create_time,
                a1.begin_time,
                a1.end_time
  from cms_icms.cip_ac_encoder_task         a1,
       cms_icms.cip_ac_fs_file              a2,
       cms_icms.cip_video_encoding          a3,
       cms_icms.cip_ac_delivery_mission_his a4,
       cms_icms.t_base_content              a5,
       cms_icms.t_video_item                a6
where a1.target_file_name = a2.file_name
   and a2.file_size > 0
   and a3.code = a1.codec
   and a1.content_name = a4.asset_name
   and a6.id = a4.content_id
   and a1.content_name = a5.assetname
   and a1.create_time > '24-7月-2012'
    and a1.end_time < '25-7月-2012'
   and a1.begin_time is not null;

回复 只看该作者 道具 举报

7#
发表于 2012-7-25 13:59:10
ODM FINDING:


10.2.0.5.0+ AIX

52%   58 MB, 899 chunks: "kllcqas:kllsltba          "  SQL
         QERHJ hash-joi  ds=110853f30  dsprt=1103fa790
29%   32 MB,   2 chunks: "HT buckets                "  SQL
         QERHJ hash-joi  ds=110854f48  dsprt=1103fa790
11%   12 MB,  15 chunks: "QERHJ list array          "  SQL
         QERHJ hash-joi  ds=110854f48  dsprt=1103fa790
3% 3691 KB, 853 chunks: "free memory               "  SQL
         QERHJ hash-joi  ds=110af4fa8  dsprt=1103fa790
2% 2817 KB,  48 chunks: "QERHJ Bit vector          "  SQL
         QERHJ hash-joi  ds=110af4fa8  dsprt=1103fa790
1%  946 KB,   4 chunks: "kllcqc:kllcqslt           "  SQL
         QERHJ hash-joi  ds=110853f30  dsprt=1103fa790
0%  516 KB,   2 chunks: "HT bitvec List            "  SQL
         QERHJ hash-joi  ds=110af4fa8  dsprt=1103fa790
0%  326 KB,  87 chunks: "free memory               "  
         top uga heap    ds=11019ea60  dsprt=0
0%  122 KB,  17 chunks: "permanent memory          "  
         pga heap        ds=110072e30  dsprt=0
0%  106 KB, 834 chunks: "free memory               "  
         session heap    ds=1103e7360  dsprt=11019ea60



=======================================
PRIVATE MEMORY SUMMARY FOR THIS PROCESS
---------------------------------------
******************************************************
PRIVATE HEAP SUMMARY DUMP
111 MB total:
   111 MB commented, 154 KB permanent
   398 KB free (0 KB in empty extents),
     111 MB,   1 heap:    "session heap   "            326 KB free held
------------------------------------------------------
Summary of subheaps at depth 1
110 MB total:
   110 MB commented, 48 KB permanent
   114 KB free (1 KB in empty extents),
     2 KB uncommented freeable with mark,      110 MB,   1 heap:    "kxs-heap-w     "            103 KB free held
------------------------------------------------------
Summary of subheaps at depth 2
110 MB total:
   110 MB commented, 19 KB permanent
     8 KB free (4 KB in empty extents),
     0 KB uncommented freeable with mark,      110 MB,   4 heaps:   "QERHJ hash-joi "           
------------------------------------------------------
Summary of subheaps at depth 3
110 MB total:
   106 MB commented, 57 KB permanent
  3692 KB free (0 KB in empty extents),
      60 MB, 899 chunks:  "kllcqas:kllsltba          " 3050 KB free held
      32 MB,   2 chunks:  "HT buckets                "
      13 MB,  15 chunks:  "QERHJ list array          " 66 KB free held

=========================================
REAL-FREE ALLOCATOR DUMP FOR THIS PROCESS
-----------------------------------------

Dump of Real-Free Memory Allocator Heap [0x1103c0230]
mag=0xfefe0001 flg=0x5000003 fds=0x0 blksz=65536
blkdstbl=0x1103c0240, iniblk=3072 maxblk=262144 numsegs=14
In-use num=939 siz=116391936, Freeable num=0 siz=0, Free num=0 siz=0

==========================================
INSTANCE-WIDE PRIVATE MEMORY USAGE SUMMARY
------------------------------------------

Dumping Work Area Table (level=1)
=====================================

  Global SGA Info
  ---------------

    global target:     4000 MB
    auto target:       3520 MB
    max pga:            200 MB
    pga limit:           64 MB
    pga limit known:  1
    pga limit errors:     0

    pga inuse:          198 MB
    pga alloc:          252 MB
    pga freeable:        43 MB
    pga freed:        166068 MB
    pga to free:          0

    pga auto:           110 MB
    pga manual:           0 MB

    pga alloc  (max):   809 MB
    pga auto   (max):   245 MB
    pga manual (max):     0 MB

    # workareas     :     5
    # workareas(max):    13



================================
PER-PROCESS PRIVATE MEMORY USAGE
--------------------------------

Private memory usage per Oracle process

-------------------------
Top 10 processes:
-------------------------
(percentage is of 252 MB total allocated memory)
44% pid 50: 111 MB used of 111 MB allocated  <= CURRENT PROC





当前进程 消耗了111MB


stack call

----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedst+001c          bl       ksedst1              000000000 ? 000000000 ?
ksedmp+0290          bl       ksedst               104C203D0 ?
ksddoa+0308          bl       _ptrgl               
ksdpcg+0104          bl       ksddoa               1103F00C0 ? 1103E7800 ?
ksdpec+00e8          bl       ksdpcg               104C3367C ? 104C3384C ?
                                                   104C3386C ?
ksfpec+00a4          bl       03F345B4            
kgesev+007c          bl       _ptrgl               
kgesec3+0040         bl       kgesev               FFFFFFFFFFF73E0 ?
                                                   28422882103B2838 ?
                                                   10006DAC4 ? 110853F30 ?
                                                   000000000 ?
kghnospc+0890        bl       kgesec3              11019BF48 ? 1103E24B0 ?
                                                   FBE00000FBE ? 000000000 ?
                                                   00001F018 ? 000000001 ?
                                                   00000000E ? 110853F7C ?
kghalf+0498          bl       kghnospc             1103FA790 ? 117676188 ?
                                                   110853F7C ? 000000000 ?
                                                   104C28E28 ?
klmalf+0074          bl       01FC493C            
kllcqas+00c8         bl       _ptrgl               
kcblasm1+0028        bl       kllcqas              102380C94 ? 0BABCDEFA ?
                                                   7000003F716F220 ? 020424040 ?

回复 只看该作者 道具 举报

8#
发表于 2012-7-25 14:14:24
_smm_max_size                       = 102400 KB         ==> 100M
   _pga_max_size                       = 204800 KB            ==>  200M

1. PGA_AGGREGATE TARGET
-> should be set to five times the desired work area size

2. _PGA_MAX_SIZE
-> should be set in minimum of twice the desired work area size. The default value is 200Mb.

3. _SMM_MAX_SIZE
-> normally this parameter is not needed but maybe under certain circumstances
-> if set it should be equal to the desired work area size (in kb !)



尝试手动在 session级别  设置 "_smm_max_size" 和 "_pga_max_size"


alter session set  "_smm_max_size"=524288000;
alter session  set "_pga_max_size"=1048576000;

==》更正   "_pga_max_size" 无法在session级别设置,需要ALTER SYSTEM SET scope=spfile ,reboot instance才能生效


再次运行上面引发错误的 SQL语句


若仍不能解决问题 可以采用 手动 PGA 管理,例如:

set timing on;
alter session set workarea_size_policy=MANUAL;
alter session set workarea_size_policy=MANUAL;

alter session set hash_area_size=524288000;
alter session set hash_area_size=524288000;

之后运行你上述的语句

回复 只看该作者 道具 举报

9#
发表于 2012-7-25 15:37:17
除了这个设置失败,其他都尝试了
alter session  set "_pga_max_size"=1048576000;
还是提示04030-那是不是只有重启数据库调整_pga_max_size参数了?

回复 只看该作者 道具 举报

10#
发表于 2012-7-25 15:39:37
手动PGA 你试过了吗?  需要确保在同一个session能才能生效, 如果 还不行 考虑 使用hint 使SQL不走HASH JOIN


alter session set workarea_size_policy=MANUAL;
alter session set workarea_size_policy=MANUAL;

alter session set hash_area_size=524288000;
alter session set hash_area_size=524288000;

回复 只看该作者 道具 举报

11#
发表于 2012-7-25 15:56:23
检查下OS 是否对用于有限制

回复 只看该作者 道具 举报

12#
发表于 2012-7-25 15:59:31
检查下OS是否对用户有限制
$ulimit -a
尝试尽量设置足够的与内存有关的参数

回复 只看该作者 道具 举报

13#
发表于 2012-7-25 16:29:00
ulimie -a
$ ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        unlimited
memory(kbytes)       unlimited
coredump(blocks)     unlimited
nofiles(descriptors) unlimited
threads(per process) unlimited
processes(per user)  unlimited

回复 只看该作者 道具 举报

14#
发表于 2012-7-25 16:30:05
SQL> set timing on;
SQL> alter session set workarea_size_policy=MANUAL;

Session altered

Executed in 0 seconds

SQL> alter session set workarea_size_policy=MANUAL;

Session altered

Executed in 0 seconds

SQL> alter session set hash_area_size=524288000;

Session altered

Executed in 0 seconds

SQL> alter session set hash_area_size=524288000;

Session altered

Executed in 1.076 seconds

SQL> alter session set sort_area_size=524288000;

Session altered

Executed in 0 seconds

SQL> alter session set sort_area_size=524288000;

Session altered

Executed in 0.015 seconds

SQL>
SQL> select distinct a1.target_file_name,
  2                  a1.content_name,
  3                  round(a6.duration),
  4                  a5.meta_data_type,
  5                  a3.name,
  6                  round((a1.begin_time - a1.create_time) * 24 * 3600),
  7                  round((a1.end_time - a1.begin_time) * 24 * 3600),
  8                  round(a2.file_size / 1024 / 1024),
  9                  a1.create_time,
10                  a1.begin_time,
11                  a1.end_time
12    from cms_icms.cip_ac_encoder_task         a1,
13         cms_icms.cip_ac_fs_file              a2,
14         cms_icms.cip_video_encoding          a3,
15         cms_icms.cip_ac_delivery_mission_his a4,
16         cms_icms.t_base_content              a5,
17         cms_icms.t_video_item                a6
18   where a1.target_file_name = a2.file_name
19     and a2.file_size > 0
20     and a3.code = a1.codec
21     and a1.content_name = a4.asset_name
22     and a6.id = a4.content_id
23     and a1.content_name = a5.assetname
24     and a1.create_time > '24-7ÔÂ-2012'
25      and a1.end_time < '25-7ÔÂ-2012'
26     and a1.begin_time is not null
27  ;

select distinct a1.target_file_name,
                a1.content_name,
                round(a6.duration),
                a5.meta_data_type,
                a3.name,
                round((a1.begin_time - a1.create_time) * 24 * 3600),
                round((a1.end_time - a1.begin_time) * 24 * 3600),
                round(a2.file_size / 1024 / 1024),
                a1.create_time,
                a1.begin_time,
                a1.end_time
  from cms_icms.cip_ac_encoder_task         a1,
       cms_icms.cip_ac_fs_file              a2,
       cms_icms.cip_video_encoding          a3,
       cms_icms.cip_ac_delivery_mission_his a4,
       cms_icms.t_base_content              a5,
       cms_icms.t_video_item                a6
where a1.target_file_name = a2.file_name
   and a2.file_size > 0
   and a3.code = a1.codec
   and a1.content_name = a4.asset_name
   and a6.id = a4.content_id
   and a1.content_name = a5.assetname
   and a1.create_time > '24-7ÔÂ-2012'
    and a1.end_time < '25-7ÔÂ-2012'
   and a1.begin_time is not null

ORA-04030: ÔÚ³¢ÊÔ·ÖÅä 1036320 ×Ö½Ú (QERHJ hash-joi,kllcqas:kllsltba) ʱ½ø³ÌÄÚ´æ²»×ã

SQL

回复 只看该作者 道具 举报

15#
发表于 2012-7-25 16:31:08
用hint merge连接方式
SQL> select /*+use_merge(a1,a2,a3,a4,a5,a6)*/distinct a1.target_file_name,
  2                  a1.content_name,
  3                  round(a6.duration),
  4                  a5.meta_data_type,
  5                  a3.name,
  6                  round((a1.begin_time - a1.create_time) * 24 * 3600),
  7                  round((a1.end_time - a1.begin_time) * 24 * 3600),
  8                  round(a2.file_size / 1024 / 1024),
  9                  a1.create_time,
10                  a1.begin_time,
11                  a1.end_time
12    from cms_icms.cip_ac_encoder_task         a1,
13         cms_icms.cip_ac_fs_file              a2,
14         cms_icms.cip_video_encoding          a3,
15         cms_icms.cip_ac_delivery_mission_his a4,
16         cms_icms.t_base_content              a5,
17         cms_icms.t_video_item                a6
18   where a1.target_file_name = a2.file_name
19     and a2.file_size > 0
20     and a3.code = a1.codec
21     and a1.content_name = a4.asset_name
22     and a6.id = a4.content_id
23     and a1.content_name = a5.assetname
24     and a1.create_time > '24-7ÔÂ-2012'
25      and a1.end_time < '25-7ÔÂ-2012'
26     and a1.begin_time is not null
27  ;

select /*+use_merge(a1,a2,a3,a4,a5,a6)*/distinct a1.target_file_name,
                a1.content_name,
                round(a6.duration),
                a5.meta_data_type,
                a3.name,
                round((a1.begin_time - a1.create_time) * 24 * 3600),
                round((a1.end_time - a1.begin_time) * 24 * 3600),
                round(a2.file_size / 1024 / 1024),
                a1.create_time,
                a1.begin_time,
                a1.end_time
  from cms_icms.cip_ac_encoder_task         a1,
       cms_icms.cip_ac_fs_file              a2,
       cms_icms.cip_video_encoding          a3,
       cms_icms.cip_ac_delivery_mission_his a4,
       cms_icms.t_base_content              a5,
       cms_icms.t_video_item                a6
where a1.target_file_name = a2.file_name
   and a2.file_size > 0
   and a3.code = a1.codec
   and a1.content_name = a4.asset_name
   and a6.id = a4.content_id
   and a1.content_name = a5.assetname
   and a1.create_time > '24-7ÔÂ-2012'
    and a1.end_time < '25-7ÔÂ-2012'
   and a1.begin_time is not null

ORA-04030: ÔÚ³¢ÊÔ·ÖÅä 2097184 ×Ö½Ú (QERHJ hash-joi,QERHJ Bit vector) ʱ½ø³ÌÄÚ´æ²»×ã

SQL>

回复 只看该作者 道具 举报

16#
发表于 2012-7-25 17:58:52
SQL> alter system  set  "_pga_max_size" = 2048000000;

System altered.


QL> select distinct a1.target_file_name,
  2                  a1.content_name,
  3                  round(a6.duration),
  4                  a5.meta_data_type,
  5                  a3.name,
  6                  round((a1.begin_time - a1.create_time) * 24 * 3600),
  7                  round((a1.end_time - a1.begin_time) * 24 * 3600),
  8                  round(a2.file_size / 1024 / 1024),
  9                  a1.create_time,
10                  a1.begin_time,
11                  a1.end_time
12    from cms_icms.cip_ac_encoder_task         a1,
13         cms_icms.cip_ac_fs_file              a2,
14         cms_icms.cip_video_encoding          a3,
15         cms_icms.cip_ac_delivery_mission_his a4,
16         cms_icms.t_base_content              a5,
17         cms_icms.t_video_item                a6
18   where a1.target_file_name = a2.file_name
19     and a2.file_size > 0
20     and a3.code = a1.codec
21     and a1.content_name = a4.asset_name
22     and a6.id = a4.content_id
23     and a1.content_name = a5.assetname
24     and a1.create_time > '24-7ÔÂ-2012'
25      and a1.end_time < '25-7ÔÂ-2012'
26     and a1.begin_time is not null
27  /

select distinct a1.target_file_name,
                a1.content_name,
                round(a6.duration),
                a5.meta_data_type,
                a3.name,
                round((a1.begin_time - a1.create_time) * 24 * 3600),
                round((a1.end_time - a1.begin_time) * 24 * 3600),
                round(a2.file_size / 1024 / 1024),
                a1.create_time,
                a1.begin_time,
                a1.end_time
  from cms_icms.cip_ac_encoder_task         a1,
       cms_icms.cip_ac_fs_file              a2,
       cms_icms.cip_video_encoding          a3,
       cms_icms.cip_ac_delivery_mission_his a4,
       cms_icms.t_base_content              a5,
       cms_icms.t_video_item                a6
where a1.target_file_name = a2.file_name
   and a2.file_size > 0
   and a3.code = a1.codec
   and a1.content_name = a4.asset_name
   and a6.id = a4.content_id
   and a1.content_name = a5.assetname
   and a1.create_time > '24-7ÔÂ-2012'
    and a1.end_time < '25-7ÔÂ-2012'
   and a1.begin_time is not null

ORA-04030: ÔÚ³¢ÊÔ·ÖÅä 4194344 ×Ö½Ú (QERHJ hash-joi,QERHJ list array) ʱ½ø³ÌÄÚ´æ²»×ã

还是这个04030.。。。

回复 只看该作者 道具 举报

17#
发表于 2012-7-27 10:37:50
昨天再次测试发现,本地sqlplus正常,远程pl-sql异常,原来在调整了AIX内存限制后,没有重启监听导致。重启监听后,一切正常。结贴!




===============================================================>

虽然目前的ulimit -a显示的结果表示ORACLE用户进程的数据段没有限制,但是这个修改很可能是在监听器启动之后,监听器启动之后继承了先前的ulimits的所有设置,而在此后重新修改的并没有反馈到监听器中。而通过客户端sqlplus连到数据库中的时候,
监听器派生出的服务器进程继承了监听器中的ulimits相关的设置,导致服务器进程的数据段还是有限制的。而通过本地连接的数据库不通过监听器,直接继承了当前的设置,所以本地连接建立索引不会报ORA-4030错误。

回复 只看该作者 道具 举报

18#
发表于 2012-7-27 10:59:36
ulimit 是后来改的?

那我们就是漏掉一个重要的 诊断细节了   ,每一个细节都影响着问题的解决速度, 请尽可能提供所知道的所有细节。



ulimit 相关的参数 一般建议在 安装oracle数据库之前改    , 引以为鉴啊

回复 只看该作者 道具 举报

19#
发表于 2012-7-27 11:09:45
学习了。

回复 只看该作者 道具 举报

20#
发表于 2012-7-27 11:31:51
弱弱问一下,这个ORA-04030 和ora-600[729]错误.之间应该有联系吧~~我的库一经常报这个600[729]错误

回复 只看该作者 道具 举报

21#
发表于 2012-7-27 16:07:09
学习了,一般安装oracle 之前 就把一些操作系统的参数都修改好!

回复 只看该作者 道具 举报

22#
发表于 2012-12-4 08:42:30

没积分,先收藏了

回复 只看该作者 道具 举报

23#
发表于 2012-12-4 09:39:02
谢谢分享,学习!!!!!!

回复 只看该作者 道具 举报

24#
发表于 2012-12-6 13:05:52
How To Find Where The Memory Is Growing For A Process [ID 822527.1]

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-25 15:14 , Processed in 0.063543 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569