分类目录归档：数据库

OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher

发表于 2024 年 12 月 5 日 由 惜分飞

在一些情况下,我们会遇到某些原因,在源端和目标端部署不同版本的ogg,如果是目标端版本高于源端版本,一般没有问题,但是如果源端版本较高,需要考虑在抽取和传输进程中加上类似这样的配置

EXTTRAIL <trail file>, FORMAT RELEASE 11.2
 
RMTTRAIL <trail file>, FORMAT RELEASE 11.2

需要注意ogg 19版本设置FORMAT RELEASE 参数最低只能12.2,否则就会出现类似报错,导致进程无法启动

2024-12-05 15:06:59  INFO    OGG-02089  Source redo compatibility version is: 19.0.0.

2024-12-05 15:06:59  INFO    OGG-00546  Default thread stack size: 10485760.

Source Context :
  SourceModule     : [er.redo.ora]
  SourceID         : [er/redo/oracle/redoora.c]
  SourceMethod     : [validateOutTrailFileCompatibility]
  SourceLine       : [6931]
  ThreadBacktrace  : [15] elements
                   : [/ogg/libgglog.so(CMessageContext::AddThreadContext())]
                   : [/ogg/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, ...))]
                   : [/ogg/libgglog.so(_MSG_String_String(CSourceContext*, int, char const*, char const*, CMessageFactory::MessageDisposition))]
                   : [/ogg/extract()]
                   : [/ogg/extract(RedoAPI::createInstance(ggs::gglib::ggdatasource::DataSource*, ggs::gglib::ggapp::ReplicationContext*))]
                   : [/ogg/extract(ggs::er::OraTranLogDataSource::setup())]
                   : [/ogg/extract(ggs::gglib::ggapp::ReplicationContext::establishStartPoints(char, ggs::gglib::ggdatasource::DataSourceParams c
onst&))]
                   : [/ogg/extract(ggs::gglib::ggapp::ReplicationContext::initializeDataSources(ggs::gglib::ggdatasource::DataSourceParams&))]
                   : [/ogg/extract()]
                   : [/ogg/extract(ggs::gglib::MultiThreading::MainThread::ExecMain())]
                   : [/ogg/extract(ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*))]
                   : [/ogg/extract(ggs::gglib::MultiThreading::MainThread::Run(int, char**))]
                   : [/ogg/extract(main)]
                   : [/lib64/libc.so.6(__libc_start_main)]
                   : [/ogg/extract()]

2024-12-05 15:06:59  ERROR   OGG-02246  Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher.

2024-12-05 15:06:59  ERROR   OGG-01668  PROCESS ABENDING.

出现这个问题主要是从oracle 12.2开始引入了BigSCN机制,基于目前客户比较常见的数据库版本,最可能出现这类问题的是:源端19c版本数据库,目标端是11.2版本数据库.对于这类同步需求,可以在目标端也部署19版本ogg for 11.2数据库版本来解决

发表在 GoldenGate | 标签为 , , | 评论关闭

GoldenGate 19安装和打patch

发表于 2024 年 12 月 2 日 由 惜分飞

1. 下载V983658-01.zip,并上传到/tmp中
2. 安装19.1.0.0.4版本ogg,需要修改静默文件/tmp/fbo_ggs_Linux_x64_shiphome/Disk1/response/oggcore.rsp中修改这两个参数

INSTALL_OPTION=ORA19c
SOFTWARE_LOCATION=/tmp/ogg

3. 静默安装ogg

[oracle@ora19c:/home/oracle]$ /tmp/fbo_ggs_Linux_x64_shiphome/Disk1/runInstaller -silent \
 -responseFile /tmp/fbo_ggs_Linux_x64_shiphome/Disk1/response/oggcore.rsp
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 120 MB.   Actual 6106 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 1257 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2024-12-02_10-57-00PM. Please wait ...
[oracle@ora19c:/home/oracle]$ You can find the log of this install session at:
 /data/app/oraInventory/logs/installActions2024-12-02_10-57-00PM.log
Successfully Setup Software.
The installation of Oracle GoldenGate Core was successful.
Please check '/data/app/oraInventory/logs/silentInstall2024-12-02_10-57-00PM.log' for more details.

[oracle@ora19c:/home/oracle]$ cd /tmp/ogg
[oracle@ora19c:/tmp/ogg]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054_FBO
Linux, x64, 64bit (optimized), Oracle 19c on Oct 17 2019 21:16:29
Operating system character set identified as UTF-8.

Copyright (C) 1995, 2019, Oracle and/or its affiliates. All rights reserved.



GGSCI (ora19c) 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     STOPPED                                           


GGSCI (ora19c) 2> create subdirs

Creating subdirectories under current directory /tmp/ogg

Parameter file                 /tmp/ogg/dirprm: created.
Report file                    /tmp/ogg/dirrpt: created.
Checkpoint file                /tmp/ogg/dirchk: created.
Process status files           /tmp/ogg/dirpcs: created.
SQL script files               /tmp/ogg/dirsql: created.
Database definitions files     /tmp/ogg/dirdef: created.
Extract data files             /tmp/ogg/dirdat: created.
Temporary files                /tmp/ogg/dirtmp: created.
Credential store files         /tmp/ogg/dircrd: created.
Masterkey wallet files         /tmp/ogg/dirwlt: created.
Dump files                     /tmp/ogg/dirdmp: created.


GGSCI (ora19c) 3> exit

4. 下载patch p37236684_1925000OGGRU_Linux-x86-64.zip 和opatch p6880880_190000_Linux-x86-64.zip（12.2.0.1.44版本） 并解压

[oracle@ora19c:/tmp]$ cd /tmp/
[oracle@ora19c:/tmp]$ unzip p37236684_1925000OGGRU_Linux-x86-64.zip 
[oracle@ora19c:/tmp]$ cd /tmp/ogg
[oracle@ora19c:/tmp/ogg]$ mv OPatch/ OPatch_bak
[oracle@ora19c:/tmp/ogg]$ unzip /tmp/p6880880_190000_Linux-x86-64.zip 
[oracle@ora19c:/tmp/ogg]$ /tmp/ogg/OPatch/opatch version
OPatch Version: 12.2.0.1.44

OPatch succeeded.

5. 对19.1.0.0.4版本ogg 打上最新patch(37236684)

[oracle@ora19c:/tmp/ogg]$ export ORACLE_HOME=/tmp/ogg
[oracle@ora19c:/tmp/ogg]$ OPatch/opatch apply /tmp/37236684/
Oracle Interim Patch Installer version 12.2.0.1.44
Copyright (c) 2024, Oracle Corporation.  All rights reserved.


Oracle Home       : /tmp/ogg
Central Inventory : /data/app/oraInventory
   from           : /tmp/ogg/oraInst.loc
OPatch version    : 12.2.0.1.44
OUI version       : 12.2.0.4.0
Log file location : /tmp/ogg/cfgtoollogs/opatch/opatch2024-12-02_23-04-26PM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   37236684  

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/tmp/ogg')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '37236684' to OH '/tmp/ogg'

Patching component oracle.oggcore.ora19c, 19.1.0.0.0...
Patch 37236684 successfully applied.
Log file location: /tmp/ogg/cfgtoollogs/opatch/opatch2024-12-02_23-04-26PM_1.log

OPatch succeeded.
[oracle@ora19c:/tmp/ogg]$ OPatch/opatch lspatches
37236684;

OPatch succeeded.
[oracle@ora19c:/tmp/ogg]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 19.25.0.0.241105 OGGCORE_19.25.0.0.0OGGRU_PLATFORMS_241118.0932_FBO
Linux, x64, 64bit (optimized), Oracle 19c  on Nov 18 2024 13:19:46
Operating system character set identified as UTF-8.

Copyright (C) 1995, 2024, Oracle and/or its affiliates. All rights reserved.



GGSCI (ora19c) 1>
发表在 GoldenGate | 标签为 , | 评论关闭

dd破坏asm磁盘头恢复

发表于 2024 年 12 月 2 日 由 惜分飞

有朋友对asm disk的磁盘头dd了2048byte的数据
dd-2048
asm-candidate
QQ20241202-204931

通过分析,gi软件版本,确认是11.2.0.4

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options.
ORACLE_HOME = /u01/app/11.2.0/grid
System name:	Linux
Node name:	rac1
Release:	4.1.12-37.4.1.el6uek.x86_64
Version:	#2 SMP Tue May 17 07:23:38 PDT 2016
Machine:	x86_64

从10.2.0.5之后版本,在第二个au的倒数第二个block上面,有asm disk header备份（每个block大小为4k）,分析au大小(通过分析正常的asm disk快速找到au 大小【使用dd备份的正常的磁盘头查看】)

H:\TEMP\tmp\asmbak>kfed read sdcp.dd |grep ausize
kfdhdb.ausize:                 16777216 ; 0x0bc: 0x01000000

找到被破坏的asm disk的备份磁盘头信息

H:\TEMP\tmp\asmbak>kfed read sdc.dd blkn=4094 aun=1 aus=16777216|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                    4094 ; 0x004: blk=4094
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                   229348702 ; 0x00c: 0x0dab955e
kfbh.fcn.base:                 11727032 ; 0x010: 0x00b2f0b8
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                        0 ; 0x024: 0x0000
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:               DATA_0000 ; 0x028: length=9
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                DATA_0000 ; 0x068: length=9
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             33123276 ; 0x0a8: HOUR=0xc DAYS=0x1e MNTH=0xa YEAR=0x7e5
kfdhdb.crestmp.lo:           2259134464 ; 0x0ac: USEC=0x0 MSEC=0x1ea SECS=0x2a MINS=0x21
kfdhdb.mntstmp.hi:             33162836 ; 0x0b0: HOUR=0x14 DAYS=0x12 MNTH=0x1 YEAR=0x7e8
kfdhdb.mntstmp.lo:           3600987136 ; 0x0b4: USEC=0x0 MSEC=0xad SECS=0x2a MINS=0x35
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                 16777216 ; 0x0bc: 0x01000000
kfdhdb.mfact:                    454272 ; 0x0c0: 0x0006ee80
kfdhdb.dsksize:                   65536 ; 0x0c4: 0x00010000
kfdhdb.pmcnt:                         2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn:                      0 ; 0x0d4: 0x00000000
kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]:                0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]:                0 ; 0x0dc: 0x0000
…………

确认被损坏的磁盘只有磁盘头信息损坏(即确认第二个block是否是好的)

H:\TEMP\tmp\asmbak>kfed read sdc.dd blkn=0
kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       0 ; 0x008: file=0
kfbh.check:                           0 ; 0x00c: 0x00000000
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
0065D8400 00000000 00000000 00000000 00000000  [................]
  Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]


H:\TEMP\tmp\asmbak>kfed read sdc.dd blkn=1|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            2 ; 0x002: KFBTYP_FREESPC
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                       1 ; 0x004: blk=1
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                  2781697777 ; 0x00c: 0xa5cd56f1
kfbh.fcn.base:                 39359331 ; 0x010: 0x02589363
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdfsb.aunum:                         0 ; 0x000: 0x00000000
kfdfsb.max:                        1014 ; 0x004: 0x03f6
kfdfsb.cnt:                         147 ; 0x006: 0x0093
kfdfsb.bound:                         0 ; 0x008: 0x0000
kfdfsb.flag:                          1 ; 0x00a: B=1
kfdfsb.ub1spare:                      0 ; 0x00b: 0x00
kfdfsb.spare[0]:                      0 ; 0x00c: 0x00000000
kfdfsb.spare[1]:                      0 ; 0x010: 0x00000000
kfdfsb.spare[2]:                      0 ; 0x014: 0x00000000
kfdfse[0].fse:                        0 ; 0x018: FREE=0x0 FRAG=0x0
…………

基于上述分析,直接使用备份的asm disk header信息进行merge或者repair修复之后,asm 磁盘头状态恢复正常
QQ20241202-205116
QQ20241202-205235
QQ20241202-205147

这个客户运气比较好,库非常大,只是破坏了2k的数据,如果超过4k可能就是比较麻烦的事故了,再次提醒对asm磁盘的dd操作一定要小心谨慎.如果不慎破坏asm磁盘过多,参考以前类似文档:
asm磁盘dd破坏恢复

发表在 Oracle ASM, Oracle备份恢复 | 标签为 , | 评论关闭