接到告警，发现extract进程ABENDED

查看进程日志如下：

***********************************************************************

**                     Run Time Messages                             **

***********************************************************************

2024-08-25 13:22:11  INFO    OGG-01517  Position of first record processed Log Number: 79079

Record Offset: 67072343, Aug 24, 2024 12:32:26 AM.

2024-08-25 13:22:11  INFO    OGG-06507  MAP (TABLE) resolved (entry pub_credit.ent_core_data_count): TABLE “pub_credit”.”ent_core_data_

count”.

2024-08-25 13:22:11  INFO    OGG-06509  Using the following key columns for source table pub_credit.ent_core_data_count: ogg_key_id.

2024-08-25 13:23:25  WARNING OGG-01266  cm_mf_write_lower: write: to_write: 98304  errno: 28 (No space left on device)  co_uid: 1  /ogg

/dirtmp/e_ph02_p48330_extr_0x7f968d981020_00016.cm.

2024-08-25 13:23:25  WARNING OGG-01857  cachemgr: filecaching: cm_mf_write_upper: /ogg/dirtmp.

2024-08-25 13:23:25  WARNING OGG-01262  The call to the cm_mf_write_lower() function from line 3164 in cm_mf_get() failed with reason ‘

no space on directories: error: 108: co: 00007F968D981020 obj_id: <30><30><30><30><30><30><30><30><30><30><30><30><30><30><30><30><37><

39><30><37><39><3A><30><30><30><30><30><30><30><36><37><30><37><32><33><34><33>’.

Source Context :

SourceModule            : [ggapp.cmgr_filecaching]

SourceID                : [/scratch/aime/adestore/views/aime_adc4150378/oggcore/OpenSys/src/gglib/ggapp/cachemgr/cmgr_filecache.c]

SourceFunction          : [cm_mf_write_upper]

SourceLine              : [854]

ThreadBacktrace         : [6] elements

: [/ogg/libgglog.so(CMessageContext::AddThreadContext()+0x26) [0x7f969a2d6336]]

: [/ogg/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, …)+0x6a8) [0x7f969a2c9358

]]

: [/ogg/libgglog.so(_MSG_ERR_CACHEMGR_FILECACHING_FILE(CSourceContext*, char const*, CMessageFactory::Message

Disposition)+0x41) [0x7f969a270a41]]

: [/ogg/extract(cm_filecaching_thread(void*)+0x2b49) [0x6ed689]]

: [/lib64/libpthread.so.0(+0x7dd5) [0x7f96971b2dd5]]

: [/lib64/libc.so.6(clone+0x6d) [0x7f969579fead]]

2024-08-25 13:23:25  ERROR   OGG-01853  cachemgr: filecaching: cm_mf_write_upper: /ogg/dirtmpcm_mf_get: no space on directories: error:

108: co: 00007F968D981020 obj_id: <30><30><30><30><30><30><30><30><30><30><30><30><30><30><30><30><37><39><30><37><39><3A><30><30><30>

<30><30><30><30><36><37><30><37><32><33><34><33>.

***********************************************************************

*                   ** Run Time Statistics **                         *

***********************************************************************

【分析】

从日志看到报错，是因为空间满了：

ERROR   OGG-01853  cachemgr: filecaching: cm_mf_write_upper: /ogg/dirtmpcm_mf_get: no space on directories: error:

发现dirtmp目录占了32G，这是罪魁祸首。

参考：

https://docs.oracle.com/en/middleware/goldengate/core/19.1/installing/temporary-disk-requirements.html

当总缓存事务数据超过 CACHEMGR CACHESIZE 参数时，Extract 将开始将缓存数据写入临时文件。

默认会使用整改目录的大小，建议设置一个单独专用的目录，并通过 CACHEMGR CACHEDIRECTORY 参数指定。

注意：

CACHEMGR 是一个内部自动配置和自动调节的参数，Oracle 建议不要更改 CACHESIZE，因为根据环境的不同，可能会对性能产生不利影响。

通常情况下，操作系统写 swap 的效率高于写临时文件的效率。默认的 CACHESIZE 参数就是这样设定的。

当事务提交或回滚之后，对应的临时文件也会被删除。所以这里dirtmp目录占用了32G导入整个/ogg目录满了，是因为这是一个大事务。

了解发现由于上游系统有个表做了历史数据清理，导致OGG同步这个delete语句的事务很大。

【解决】

临时扩容/ogg 目录，等这个大事务执行完成之后，目录空间就自动释放了。

OGG同步恢复正常

OGG报错dirtmp目录占满最先出现在dbAnt。

【报错】

接到告警电话，查看alert 日志报错如下：

Thu Jun 20 22:17:11 2024

Errors in file /oracle/diag/rdbms/coredb/coredb/trace/coredb_j003_23800.trc  (incident=288071):

ORA-04030: out of process memory when trying to allocate 432 bytes (kxs-heap-c,kprbalo temp memory)

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

End automatic SQL Tuning Advisor run for special tuning task  “SYS_AUTO_SQL_TUNING_TASK”

Thu Jun 20 22:17:13 2024

Sweep [inc][288071]: completed

【分析】

当操作系统请求内存或其他资源，而系统资源不足时，就会报错 ORA-4030，这里我们可以看到 kxs-heap-c,kprbalo temp memory 是内存的问题，也就是PGA内存不足了。

1、如果 ORA-4030 报错没有对应的trace详细信息，可以手动开启

## 开启trace

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

## 等ORA-4030错误再次出现之后，关闭trace

ALTER SYSTEM SET EVENTS '4030 trace name context off; name context off';

2、查看trace文件：/oracle/diag/rdbms/coredb/coredb/trace/coredb_j003_23800.trc

*** 2024-06-20 22:00:04.116

*** SESSION ID:(406.2663) 2024-06-20 22:00:04.116

*** CLIENT ID:() 2024-06-20 22:00:04.116

*** SERVICE NAME:(SYS$USERS) 2024-06-20 22:00:04.116

*** MODULE NAME:(DBMS_SCHEDULER) 2024-06-20 22:00:04.116

*** ACTION NAME:(ORA$AT_SQ_SQL_SW_3355) 2024-06-20 22:00:04.116

 

status=(pst=ERROR)

status=(pst=ERROR)

status=(pst=ERROR)

…

Incident 273219 created, dump file: /oracle/diag/rdbms/coredb/coredb/incident/incdir_273219/coredb_j003_23800_i273219.trc

ORA-04030: out of process memory when trying to allocate 432 bytes (kxs-heap-c,kprbalo temp memory)

 

Incident 273220 created, dump file: /oracle/diag/rdbms/coredb/coredb/incident/incdir_273220/coredb_j003_23800_i273220.trc

ORA-04030: out of process memory when trying to allocate 169040 bytes (pga heap,kgh stack)

ORA-04030: out of process memory when trying to allocate 432 bytes (kxs-heap-c,kprbalo temp memory)

 

Incident 273221 created, dump file: /oracle/diag/rdbms/coredb/coredb/incident/incdir_273221/coredb_j003_23800_i273221.trc

ORA-04030: out of process memory when trying to allocate 82456 bytes (pga heap,control file i/o buffer)

ORA-04030: out of process memory when trying to allocate 432 bytes (kxs-heap-c,kprbalo temp memory)

从上面的日志可以看到是DBMS_SCHEDULER 定时任务调用的 ORA$AT_SQ_SQL_SW_3355 模块导致 4030 报错，这个是Oracle定时执行的Automatic SQL Tuning job。

## 查看trace文件：/oracle/diag/rdbms/coredb/coredb/incident/incdir_273219/coredb_j003_23800_i273219.trc

这里可以看到 pid 145 这个进程执行了一个存储过程占用了90%的内存。

查看pid 145的详细信息，确实是ORA$AT_SQ_SQL_SW_3355 模块。

这里可以看到32G的内存，剩下232M 可用，基本消耗完了。

到这里，我们已经确认是Oracle每天晚上定时执行的 Automatic SQL Tuning job 导致内存耗尽的，可以选择关闭定时任务解决问题。

## 关闭job
BEGIN
dbms_auto_task_admin.disable(
client_name => 'sql tuning advisor',
operation => NULL,
window_name => NULL);
END;
/

3、如果不想关闭这个定时任务，进一步分析日志

从上面的trace日志可以看到，还有另外两个错误提示：

(pga heap,kgh stack)

(pga heap,control file i/o buffer)

参考MOS文档：

PLSQL Procedure Causing ORA-04030: (pga heap,control file i/o buffer) And ORA-04030: (koh-kghu sessi,pmuccst: adt/record) or ORA-04030: (koh-kghucall ,pmucalm coll) Errors (Doc ID 1325100.1)

该文章提到即使PGA已经设置大于4GB，当一个进程使用内存达到4GB，就会报这个错误。

## 查看trace文件：/oracle/diag/rdbms/coredb/coredb/incident/incdir_273221/coredb_j003_23800_i273221.trc

可以看到trace日志中，确实内存使用达到4GB就被限制了。

为什么会有4GB这个限制呢？

## 查看trace文件的 Process Map Dump，内存dump信息

从日志看出，进程的内存map记录数是 70986-5453+1=65534 条。

查看系统最大内存记录数65530（默认应该是65536），上面那个进程的记录数已经超过系统限制了

more /proc/sys/vm/max_map_count

默认的内存分配器（realfree allocator）页大小是64KB（65536），所以64K 条记录 64KB * 64K 就是4GB，所以单进程使用达到4GB内存的限制，就报错了。

【解决】

我们可以从系统层面 或 数据库层面修改这个限制。

• 操作系统修改内存最大记录数为256K（262144），即 64KB * 256K = 16GB

more /proc/sys/vm/max_map_count

## 临时生效

sysctl -w vm.max_map_count=262144

## 永久生效

echo "vm.max_map_count=262144" >> /etc/sysctl.conf

sysctl -p

• 数据库修改内存分配器的页大小256KB（262144），即256KB * 64K = 16GB

## 11.2.0.4 及以下版本:

_use_realfree_heap=TRUE

_realfree_heap_pagesize_hint = 262144

## 12.1 及以上版本:

_use_realfree_heap=TRUE

_realfree_heap_pagesize = 262144

对于多租户数据库，只要修改CDB的参数即可，PDB会继承该参数。

注意：

请修改OS 或 DB 其中一个即可，因为一个修改的是记录数，一个修改的是页大小，如果同时修改，那么限制就是 256KB * 256K = 64GB了。

【其他】

参考文档：FAQ: ORA-4030 (Doc ID 399497.1)

该案例只是其中一种情况，导致  ORA-4030 的原因很多，典型的原因有：

• 系统内存或swap空间达到限制；
• 系统达到内核或用户shell等限制，限制用户级或进程级的内存使用；
• 系统内存地址限制（32位系统），SGA占用了所有地址，导致PGA无法分配地址；
• 触发内部未公开的Bug:3130972
• 应用设计问题导致限制；
• 内存空间溢出或内存堆溢出等bug

Diagnostic Tools Catalog (Doc ID 559339.1)

MOS上面有很多诊断工具

可以使用 ORA-4030-Troubleshooting Tool

## 新建一个issue

## 支持上次TFA、IPS、RDA 3种工具收集的日志，选择其一上传即可

## 上传之后，如果是一个有已知问题，会给出现象、原因以及解决方案。如果是一个未知的问题，会给出相关文档以及内存监控工具，便于继续分析或提交SR。

也可以使用RDA工具检查系统配置，内存使用情况等

./rda.sh T hcve

## 检查修复检查结果为 FAILED 的

参考：

Primary Note for Diagnosing OS Memory Problems and ORA-4030 (Doc ID 1088267.1)

FAQ: ORA-4030 (Doc ID 399497.1)

https://community.oracle.com/mosc/discussion/3900920/ora-04030-out-of-process-memory-when-trying-to-allocate-x-bytes-kxs-heap-c-kprbalo-temp-memory

ORA-04030: out of process memory when trying to allocate 432 bytes (kxs-heap-c,kprbalo temp memory)最先出现在dbAnt。

【问题现象】

exp system/123456 OWNER=rs2 file=20160823_rs2_17_8.dmp log=20160823_rs2_17_8.log

...

EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table ACCEPT_DETAILS 70239 rows exported
EXP-00091: Exporting questionable statistics.
"20160823_rs2_17_8.log" 5686L, 314896C 1,0-1 顶ç«EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table ACCEPT_DETAILS0527 64422 rows exported

...

【问题处理】

由于exp工具会依赖与操作系统的字符串编码，所以需要将NLS_LANG环境变量设置与数据库一致。

SQL> select * from nls_database_parameters;

PARAMETER                      VALUE
------------------------------ ------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               ZHS16GBK
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              10.2.0.4.0

20 rows selected.

设置Linux的NLS_LANG环境变量：

[oracle@mfs ~]$ export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

设置windows的NLS_LANG环境变量：

C:\Users\Administrator>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

设置了环境变量之后，重新导出一切正常。

不过还是建议使用数据泵来导数，因为数据泵不会收到操作系统的字符集编码的影响，就不会有这样的报错了。

EXP-00091: Exporting questionable statistics最先出现在dbAnt。

test@TESTDB> insert into t1 select * from dba_objects where rownum < 100;
insert into t1 select * from dba_objects where rownum < 100
*
ERROR at line 1:
ORA-00001: unique constraint (TEST.PK_T1_OBJECT_ID) violated

查询T1表主键及索引，发现主键索引仍然存在

test@TESTDB> select * from dba_cons_columns where table_name='T1';

no rows selected

test@TESTDB> select INDEX_OWNER,INDEX_NAME,TABLE_NAME,COLUMN_NAME from dba_ind_columns where table_name='T1';

INDEX_OWNER                    INDEX_NAME                     TABLE_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------ --------------------
TEST                           PK_T1_OBJECT_ID                T1                             OBJECT_ID

手动删除该索引，插入数据成功

test@TESTDB> drop index test.PK_T1_OBJECT_ID;

Index dropped.

test@TESTDB> insert into t1 select * from dba_objects where rownum < 100; 

99 rows created.

正常情况下删掉主键的时候会同时删除主键附带的索引，这里为什么会出现不删除的情况呢？

在MOS上面有一篇文章解答了这个疑问：

Indexes Associated With Primary Key Constraints Of Imported Tables Are Not Dropped When Constraints Are Disabled (文档 ID 887208.1)

由于T1表是imp导入的，而在import的时候，oracle会先创建唯一性索引，然后在添加主键约束，这就导致在创建主键的时候，唯一索引已经存在，并被主键使用，而对于并非主键创建的唯一性索引，在删除主键的时候，索引是会保留的。

如果想解决该问题，可以通过如下的方法进行修复：

test@TESTDB> alter table t1 enable constraint PK_T1_OBJECT_ID;

Table altered.

test@TESTDB>
test@TESTDB> select * from dba_cons_columns where table_name='T1';

OWNER CONSTRAINT_NAME TABLE_NAME COLUMN_NAME POSITION
------------------------------ ------------------------------ ------------------------------ -------------------- ----------
TEST PK_T1_OBJECT_ID T1 OBJECT_ID 1

test@TESTDB>
test@TESTDB> select INDEX_OWNER,INDEX_NAME,TABLE_NAME,COLUMN_NAME from dba_ind_columns where table_name='T1';

INDEX_OWNER INDEX_NAME TABLE_NAME COLUMN_NAME
------------------------------ ------------------------------ ------------------------------ --------------------
TEST PK_T1_OBJECT_ID T1 OBJECT_ID

Indexes Are Not Dropped When Primary Key Are Dropped最先出现在dbAnt。

DB：ORACLE 11.2.0.3

通过EXPDP导出全库，查看log发现如下报错：

ORA-31693: 表数据对象 “AUDIT_GD”.”PUB_LOBFILE” 无法加载/卸载并且被跳过, 错误如下:
ORA-02354: 导出/导入数据时出错
ORA-01555: 快照过旧: 回退段号 7 (名称为 “_SYSSMU7_93985497$”) 过小
已成功加载/卸载了主表 “EXP_DBA”.”JOB_EXP_FULL_2″

从报错信息ORA-31693，我们可以看到由于”AUDIT_GD”.”PUB_LOBFILE”对象的UNDO段过期导致。我们知道LOB对象的UNDO段保留时间通过PCTVERSION和RETENTION参数控制。

注意：

1、SecureFiles类型的LOB，只能通过RETENTION参数控制。

2、BasicFiles类型的LOB，可以通过PCTVERSION 或 RETENTION中的其中一个进行控制。

PCTVERSION：表示整个BasicFiles LOB对象的空间允许被该LOB对象的UNDO段占用的最大百分比。

RETENTION：表示保留的时间，单位秒。当数据库为自动UNDO段管理是，该参数为默认值，并参考undo_retention的参数值。

查看该LOB对象的UNDO段保留情况：

SQL> select COLUMN_NAME,SECUREFILE,PCTVERSION,RETENTION from dba_lobs where OWNER=upper('AUDIT_GD') and TABLE_NAME=upper('PUB_LOBFILE') ;

COLUMN_NAME                    SEC PCTVERSION  RETENTION
------------------------------ --- ---------- ----------
LOB                            NO          10
TEXTLOB                        NO                    900

查看数据库中使用UNDO段的最大保留时间：

SQL> select max(maxquerylen) from v$undostat;

MAX(MAXQUERYLEN)
----------------
1839

为了防止数据导出过程中UNDO段过期，增加undo_retention参数值：(设置该参数之前，必须保证UNDO表空间有足够的空间)

SQL> alter system set undo_retention=2000 scope=both sid='*';

设置LOB对象的UNDO段保留时间：

SQL> alter table AUDIT_GD.PUB_LOBFILE modify lob(LOB) (retention);
Table altered.

SQL> alter table AUDIT_GD.PUB_LOBFILE modify lob(TEXTLOB) (retention);
Table altered.

SQL> select COLUMN_NAME,SECUREFILE,PCTVERSION,RETENTION from dba_lobs where OWNER=upper('AUDIT_GD') and TABLE_NAME=upper('PUB_LOBFILE') ;

COLUMN_NAME                    SEC PCTVERSION  RETENTION
------------------------------ --- ---------- ----------
LOB                            NO                   2000
TEXTLOB                        NO                   2000

修改完参数之后，再进行EXPDP导出。

参考：ORA-31693, ORA-02354 and ORA-01555 with Export Datapump (文档 ID 1580798.1)

版权所有，转载请注明出处：

EXPDP导出全库报错ORA-01555

EXPDP导出全库报错ORA-01555最先出现在dbAnt。