GVKun编程网logo

Oracle GoldenGate 系列:Replicat 进程遇 OCI Error ORA(oracle进程出现错误)

1

如果您想了解OracleGoldenGate系列:Replicat进程遇OCIErrorORA和oracle进程出现错误的知识,那么本篇文章将是您的不二之选。我们将深入剖析OracleGoldenGa

如果您想了解Oracle GoldenGate 系列:Replicat 进程遇 OCI Error ORAoracle进程出现错误的知识,那么本篇文章将是您的不二之选。我们将深入剖析Oracle GoldenGate 系列:Replicat 进程遇 OCI Error ORA的各个方面,并为您解答oracle进程出现错误的疑在这篇文章中,我们将为您介绍Oracle GoldenGate 系列:Replicat 进程遇 OCI Error ORA的相关知识,同时也会详细的解释oracle进程出现错误的运用方法,并给出实际的案例分析,希望能帮助到您!

本文目录一览:

Oracle GoldenGate 系列:Replicat 进程遇 OCI Error ORA(oracle进程出现错误)

Oracle GoldenGate 系列:Replicat 进程遇 OCI Error ORA(oracle进程出现错误)

生产环境发票管理库到总局主数据库 Replicat 进程因报如下错误 Abended: 2013-04-25 07:59:50 WARNING OGG-00869 OCI Error ORA-14402: updating partition keycolumn would cause a partition change (status = 14402). UPDATEHX_FP.FP_PZHDXX SET SWJG_DM

生产环境发票管理库到总局主数据库 replicat 进程因报如下错误 abended:

2013-04-25 07:59:50  WARNING OGG-00869  OCI Error ORA-14402: updating partition keycolumn would cause a partition change (status = 14402). UPDATE"HX_FP"."FP_PZHDXX" SET "SWJG_DM" =:a1,"XGRQ" = :a2,

"SJGSDQ" = :a3 WHERE"HDQCUUID" = :b0.

2013-04-25 07:59:50  WARNING OGG-01004  Aborted grouped transaction on''HX_FP.FP_PZHDXX'', Database error 14402 (OCI Error ORA-14402: updatingpartition key column would cause a partition change (statu

s = 14402). UPDATE"HX_FP"."FP_PZHDXX" SET "SWJG_DM" = :a1,"XGRQ"= :a2,"SJGSDQ" = :a3 WHERE "HDQCUUID" = :b0).

2013-04-25 07:59:50  WARNING OGG-01003  Repositioning to rba 355778 in seqno 83.

2013-04-25 07:59:50  WARNING OGG-01154  SQL error 14402 mapping HX_FP.FP_PZHDXX toHX_FP.FP_PZHDXX OCI Error ORA-14402: updating partition key column would causea partition change (status = 14402). U

PDATE"HX_FP"."FP_PZHDXX" SET "SWJG_DM" =:a1,"XGRQ" = :a2,"SJGSDQ" = :a3 WHERE "HDQCUUID"= :b0.

2013-04-25 07:59:50  WARNING OGG-01003  Repositioning to rba 355778 in seqno 83.

Source Context :

 SourceModule            :[er.errors]

 SourceID                :[/scratch/aime1/adestore/views/aime1_staxj16/oggcore/OpenSys/src/app/er/errors.cpp]

 SourceFunction          :[take_rep_err_action(short, int32_t, const char *, extr_ptr_def *,std_rec_hdr_def *, char *, file_def *, bool)]

  SourceLine              : [623]

2013-04-25 07:59:50  ERROR  OGG-01296  Error mapping fromHX_FP.FP_PZHDXX to HX_FP.FP_PZHDXX.

 

WARNNING OGG-00869根据官方的 Error Reference 中的描述,专指OGG遇到了特定的数据库错误,可以忽略。

OGG-00869: {0}

Cause: The specified database error occurred, but can be ignored.

Action: Contact Oracle Support only if a problem persists.

 

但在本例中,replicat 进程遇到的数据库错误为OCI ErrorORA-14402: updating partition key column would cause a partition change,显然无法忽略。ORA-14402 错误一般是由于 update 操作更改了分区表的分区键的值触使该行迁移到其他的分区中。而表的 row movement 默认情况下处于禁用状态,从而导致报该错误。

[oracle@prod ~]$ oerr ora 14402

14402, 00000, "updating partition keycolumn would cause a partition change"

// *Cause: An UPDATE statement attempted to change the value of a partition

//         key column causing migration of the row to another partition

// *Action: Do not attempt to update apartition key column or make sure that

//         the new partition key is within the range containing the old

//         partition key.

 

Replicat 进程报错时正在修改的记录为:

Logdump 7 >pos 355778

Reading forward from RBA 355778

Logdump 8 >n

___________________________________________________________________

Hdr-Ind    :     E (x45)     Partition  :    .  (x04) 

UndoFlag   :     . (x00)     BeforeAfter:     A (x41) 

RecLength  :    91 (x005b)   IO Time    : 2013/04/24 20:33:00.010.627  

IOType     :    15 (x0f)     OrigNode   :  255  (xff)

TransInd   :     . (x00)     FormatType :     R (x52)

SyskeyLen  :     0 (x00)     Incomplete :     . (x00)

AuditRBA   :        950       AuditPos   : 915048500

Continued  :     N (x00)     RecCount   :    1  (x01)

 

2013/04/24 20:33:00.010.627 FieldComp            Len    91 RBA 355778

Name: HX_FP.FP_PZHDXX

After  Image:                                            Partition 4   G  b  

 0000 0022 0000 4232 3742 3133 35354146 3646 3430 | ..."..B27B1355AF6F40 

 3945 3839 3145 3142 4238 4144 36383837 4438 000c | 9E891E1BB8AD6887D8.. 

 000d 0000 3135 3030 3931 3030 30303000 1000 1500 | ....15009100000..... 

 0032 3031 332d 3034 2d32 343a 32303a33 333a 3030 | .2013-04-24:20:33:00 

 0011 0007 0000 3135 3030 39                       | ......15009 

Column     0 (x0000), Len    34 (x0022) 

Column    12 (x000c), Len    13 (x000d) 

Column    16 (x0010), Len    21 (x0015) 

Column    17 (x0011), Len     7 (x0007)

 

执行的 update 语句为:

UPDATE HX_FP.FP_PZHDXX SET SWJG_DM = ‘15009100000’,XGRQ= ‘2013-04-24:20:33:00’,SJGSDQ= ‘15009’ WHERE HDQCUUID = ‘B27B1355AF6F409E891E1BB8AD6887D8’

 

其中SJGSDQ 正是HX_FP.FP_PZHDXX 表的分区键。

针对这种修改分区表分区键的操作导致的 replicat 进程挂起,metalink 上给出的建议为在应用设计时尽量避免这种操作,启用该表的 row movement便可临时解决这一问题。

SQL> alter table HX_FP.FP_PZHDXX enablerow movement;

Table altered.

GGSCI (bjsczjdbzsj01) 1> info all

Program    Status      Group       Lag at Chkpt Time Since Chkpt

MANAGER    RUNNING                                          

JAGENT     STOPPED                                          

EXTRACT    RUNNING     EZJTS_TS    00:00:00      00:00:02   

EXTRACT    RUNNING     PZJTS_TS    00:00:00      00:00:03   

REPLICAT   ABENDED     RFP_ZJ3     00:00:00      12:21:37   

REPLICAT   RUNNING     RFX_ZJ3     00:00:00      00:00:07   

REPLICAT   RUNNING     RGZ_ZJ5     00:00:00      00:00:02   

REPLICAT   RUNNING     RNSTS_ZJ    00:00:00      00:00:03   

REPLICAT   RUNNING     RNS_ZJ2     00:00:00      00:00:01   

REPLICAT   RUNNING     RSB_ZJ4     00:00:00      00:00:04   

GGSCI (bjsczjdbzsj01) 3> start RFP_ZJ3

Sending START request to MANAGER ...

REPLICAT RFP_ZJ3 starting

GGSCI (bjsczjdbzsj01) 4> info all

Program    Status      Group       Lag at Chkpt Time Since Chkpt

MANAGER    RUNNING                                          

JAGENT     STOPPED                                           

EXTRACT    RUNNING     EZJTS_TS    00:00:00      00:00:05   

EXTRACT    RUNNING     PZJTS_TS    00:00:00      00:00:06   

REPLICAT   RUNNING     RFP_ZJ3     00:00:00      00:00:00   

REPLICAT   RUNNING     RFX_ZJ3     00:00:00      00:00:00    

REPLICAT   RUNNING     RGZ_ZJ5     00:00:00      00:00:03   

REPLICAT   RUNNING     RNSTS_ZJ    00:00:00      00:00:06   

REPLICAT   RUNNING     RNS_ZJ2     00:00:00      00:00:09   

REPLICAT   RUNNING     RSB_ZJ4     00:00:00      00:00:07


http://blog.csdn.net/xiangsir/article/details/8851677

 

ALTER SEQUENCE 导致 REPLICAT 延时

ALTER SEQUENCE 导致 REPLICAT 延时

1.查看OGG线程状态

GGSCI (klcoredb-node1) 46> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                           
EXTRACT     RUNNING     EXTBI       unknown       00:00:04    
EXTRACT     RUNNING     PXTBI       00:00:00      00:00:02    
REPLICAT    RUNNING     REP_1B      14:32:46      00:00:02    
REPLICAT    RUNNING     REP_1X      00:00:00      00:00:01 
2.查看replicate线程在什么
send REPLICAT REP_1B trace2 /home/oracle/trace2.log
send REPLICAT REP_1B trace /home/oracle/trace.log 


send  REPLICAT REP_1B trace2 of
send REPLICAT REP_1B trace off


---
10:38:16.263 (1326639) exited READ_EXTRACT_RECORD (stat=0, seqno=7511, rba=54995215)
10:38:16.263 (1326639) processing record for KLSMISSTAND.LP_GL_INTERFACE_SEQ
10:38:16.263 (1326639) mapping record
10:38:16.263 (1326639) entering perform_sql_statements (normal)
10:38:16.303 (1326679) exited perform_sql_statements (sql_err=0,recs output=41000)
10:38:16.303 (1326679) * --- entering READ_EXTRACT_RECORD --- *
10:38:16.303 (1326679) exited READ_EXTRACT_RECORD (stat=0, seqno=7511, rba=54995430)
10:38:16.303 (1326679) processing record for KLSMISSTAND.LP_GL_INTERFACE_SEQ
10:38:16.303 (1326679) mapping record
10:38:16.303 (1326679) entering perform_sql_statements (normal)
10:38:16.333 (1326709) exited perform_sql_statements (sql_err=0,recs output=41001)
10:38:16.333 (1326709) * --- entering READ_EXTRACT_RECORD --- *
10:38:16.333 (1326709) exited READ_EXTRACT_RECORD (stat=0, seqno=7511, rba=54995645)
10:38:16.333 (1326709) processing record for KLSMISSTAND.LP_GL_INTERFACE_SEQ
10:38:16.333 (1326709) mapping record
10:38:16.333 (1326709) entering perform_sql_statements (normal)
10:38:16.373 (1326749) exited perform_sql_statements (sql_err=0,recs output=41002)
10:38:16.373 (1326749) * --- entering READ_EXTRACT_RECORD --- *
10:38:16.373 (1326749) exited READ_EXTRACT_RECORD (stat=0, seqno=7511, rba=54995860)
10:38:16.373 (1326749) processing record for KLSMISSTAND.LP_GL_INTERFACE_SEQ
10:38:16.373 (1326749) mapping record
10:38:16.373 (1326749) entering perform_sql_statements (normal)
10:38:16.403 (1326779) exited perform_sql_statements (sql_err=0,recs output=41003)
10:38:16.403 (1326779) * --- entering READ_EXTRACT_RECORD --- *
10:38:16.403 (1326779) exited READ_EXTRACT_RECORD (stat=0, seqno=7511, rba=54996075)
10:38:16.403 (1326779) processing record for KLSMISSTAND.LP_GL_INTERFACE_SEQ
4.查看系统当前运行的sql
多次刷新发现sql

ALTER SEQUENCE "LP_GL_INTERFACE_SEQ"  NOCYCLE
5.查看当前sequnce的裱花

SQL> set time on
14:14:27 SQL> SELECT LAST_NUMBER,INCREMENT_BY FROM DBA_SEQUENCES WHERE SEQUENCE_NAME=''LP_GL_INTERFACE_SEQ'';

LAST_NUMBER INCREMENT_BY
----------- ------------
   24330470            1

14:14:35 SQL> /

LAST_NUMBER INCREMENT_BY
----------- ------------
   24330540            1

14:14:37 SQL> /

LAST_NUMBER INCREMENT_BY
----------- ------------
   24330582            1

14:14:39 SQL> /
6.缓解同步sequence延时 在replice相关参数文件中添加参数:
DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH

--Metalink 说明

The replicat changes the last_number in target sequence by querying the nextval, but this change is not secured if the target database goes down.  The observed DDL will move the high water mark (HWM) of target sequence and make sure sequences replicate reliably for each sequence record.  

 
The DDL may be skipped with replicat parameter: 


DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH


However, if target db goes down, the sequence number may be out of sync with source.  then you will need to use FLUSH to make sure they are in sync (or FLUSH it before the target goes down, for scheduled shutdown).

 

DG不能自动mount导致数据库不能正常启动:ORA-01157、ORA-01110、ORA-17503、ORA-150

DG不能自动mount导致数据库不能正常启动:ORA-01157、ORA-01110、ORA-17503、ORA-150

DG不能自动mount导致数据库不能正常启动:ORA-01157、ORA-01110、ORA-17503、ORA-15001、ORA-15001现象:每次重启整个CRS之后,D

dg不能自动mount导致数据库不能正常启动:ora-01157、ora-01110、ora-17503、ora-15001、ora-15001
现象:
每次重启整个crs之后,db都不能自动开启到open状态,查看alert日志报错:
success: diskgroup unid was mounted
thu nov 14 21:46:01 2013
create relation sweeperr
setting recovery target incarnation to 1
successful mount of redo thread 1, with mount id 2364838615
database mounted in exclusive mode
lost write protection disabled
completed: alter database mount
thu nov 14 21:46:05 2013
alter database open migrate
errors in file /opt/app/diag/rdbms/nc/nc1/trace/nc1_dbw0_8399.trc:
ora-01157: cannot identify/lock data file 21 - see dbwr trace file
ora-01110: data file 21: ''+indx/nc/datafile/indx.256.820323481''
ora-17503: ksfdopn:2 failed to open file +indx/nc/datafile/indx.256.820323481
ora-15001: diskgroup "indx" does not exist or is not mounted
ora-15001: diskgroup "indx" does not exist or is not mounted
errors in file /opt/app/diag/rdbms/nc/nc1/trace/nc1_dbw0_8399.trc:
ora-01157: cannot identify/lock data file 22 - see dbwr trace file
ora-01110: data file 22: ''+indx/nc/datafile/indx.257.820323659''
ora-17503: ksfdopn:2 failed to open file +indx/nc/datafile/indx.257.820323659
ora-15001: diskgroup "indx" does not exist or is not mounted
从alert日志可以看出,indx dg的文件不能被读到,
查看发现indx dg处于dismount状态。

分析:
ASM中创建了2个DG:UNID,INDX.每次只有UNID会被自动mount,而INDX不能被自动MOUNT。
查看asm_diskgroups参数发现只设置了UNID,,这就是为什么每次INDX不会被自动MOUNT的原因了。
SQL>
SQL> show parameter asm

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
asm_diskgroups string UNID
SQL> show parameter pfile

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string

解决办法:
将INDX添加到asm_diskgroups参数中。
spfile:alter system set asm_diskgroups=''UNID'',''INDX'' scope=both;
pfile:修改pfile中asm_diskgroups参数。

相关阅读:

ORA-01172、ORA-01151错误处理

ORA-00600 [2662]错误解决

ORA-01078 和 LRM-00109 报错解决方法

ORA-00471 处理方法笔记

ORA-00314,redolog 损坏,或丢失处理方法

ORA-00257 归档日志过大导致无法存储的解决办法

error: ora-01034:oracle not available ora-27101:shared memory realm does not exist

error: ora-01034:oracle not available ora-27101:shared memory realm does not exist

出现错误

 

 

 

解决方法

1 、先看oracle的监听和oracle的服务是否都启动了。启动oracle监听:
cmd的命令行窗口下,输入lsnrctl start,回车即启动监听。

2 、查看oracle的sid叫什么,比如创建数据库的时候,实例名叫“abc”,那么先手工设置一下oralce的sid,cmd命令窗口中,set ORACLE_SID=abc

3 、再输入sqlplus  /nolog,回车
再输入 conn / as sysdba;回车

4、再输入startup,回车.这步是启动oracle服务。如果startup启动被告知已经启动了,可以先输入shutdown immediate;等shutdown结束之后,再输入startup。

5 、过几秒钟等命令运行完成,就能连接了。这个时候,可以输入"select * from user_tables;"测试一下,看是否有查询结果。

6 、出现ORA-01034和ORA-27101的原因是多方面的:主要是oracle当前的服务不可用,shared memory realm does not exist,是因为oracle没有启动或没有正常启动,共享内存并没有分配给当前实例.所以,通过设置实例名,再用操作系统身份验证的方式,启动数据库。这样数据库就正常启动了,就不会报ORA-01034和ORA-27101两个启动异常了。

expdp导出报错:ORA-31626 ORA-31633 ORA-06512 ORA-01658怎么办

expdp导出报错:ORA-31626 ORA-31633 ORA-06512 ORA-01658怎么办

expdp导出报错:ORA-31626 ORA-31633 ORA-06512 ORA-01658怎么办,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。

ORA-31626:JOB does not exist
ORA-31633:unable to create master table "NYFS.SYS_EXPORT_SCHEMA_49"
ORA-06512:at "SYS.DBMS_SYS_ERROR" line 95
ORA-06518: unable to create INITIAL extent for segment in tablespace users
解决方案:由于表空间无自动扩展,USERS表空间已经占满,扩大USERS表空间即可。
ALTER DATABASE DATAFILE ''/XXX/XXX/USER01.DBF'' RESIZE 10G;

ALTER DATABASE DATAFILE ''/XXX/XXX/USER01.DBF'' AUTOEXTEND ON NEXT 50M MAXSIZE 10G;

看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注小编行业资讯频道,感谢您对小编的支持。

今天关于Oracle GoldenGate 系列:Replicat 进程遇 OCI Error ORAoracle进程出现错误的分享就到这里,希望大家有所收获,若想了解更多关于ALTER SEQUENCE 导致 REPLICAT 延时、DG不能自动mount导致数据库不能正常启动:ORA-01157、ORA-01110、ORA-17503、ORA-150、error: ora-01034:oracle not available ora-27101:shared memory realm does not exist、expdp导出报错:ORA-31626 ORA-31633 ORA-06512 ORA-01658怎么办等相关知识,可以在本站进行查询。

本文标签: