schema change + ogg 变更手册

 
Check OGG  until no data queuing in replication process:
testRO:
a)login  test5 –l oggmgr
b)ogg
c)#ggsci> lag *
check lag=0
{note: when check lag result = 0, proceed next step]  [GGSCI的lag命令可以查询复制延迟, 如:    GGSCI> lag <replicat>]
(At EOF, no more records to process.)


Stop  OGG   replication process: [目标段停下replication]
testRO:
a)login test5 –l oggmgr
b)ogg
c)ggsci>stop rpttestpr

Deactivate the current configuration file on primary server
a)login test4 –l oggmgr         [原端删除trandata,并且使用初始化配置重启extractor]
Choose testPR
  ggsci> dblogin userid gguser, password gguser_123q
a)ggsci>delete trandata testdata.*            
b)ggsci>stop er *!
cd  /testprdb/ogg/dirprm/
cp ertestpr.prm  ertestpr.201701
cp  ertestpr_sc.prm  ertestpr.prm
c)Activate the new configuration file “newfilename1

ogg
ggsci> start er *


Schema change on testpr           [表结构变更,原库和目标库都做]
a) login test4 -l oracle
Choose testpr
$cd /testprdb/change/schema/test/2016_10_09_test_4_4_3
$appl_schema_change.sh
b) check log for any errors (vi */*/*/rollout/log/01*.log)

Schema change on testro
a) login test5 -l oracle
Choose testRO
$cd /testrodb/change/schema/test/2016_10_09_test_4_4_3
$appl_schema_change.sh
b) check log for any errors (vi */*/*/rollout/log/01*.log)

Schema change on testhis
a) login test4 -l oracle
Choose testhis
$cd /testhisdb/change/schema/hdb/2016_10_10_test_4_3_18
$appl_schema_change.sh
b) check log for any errors (vi */*/*/rollout/log/01*.log)


Disable FK and check constraints in read-only DB:nGenROA
login test5 -l  oracle [目标段 禁用主建检查和外建检查]
Choose  testRO
cd /home/oracle/ogg/RO/scripts
SQL>@gen_dcons_test.sql
SQL>@dcons.sql
SQL>exit

Activate the current configuration file on primary server (testPR)
a)login test4 –l oggmgr                    [重新启动原端的extractor,并重新加入trandata ]
Choose testPR

ogg
  ggsci> dblogin userid gguser, password gguser_123q
a)ggsci>add trandata testdata.*
b)ggsci> stop er *!
cd  /testprdb/ogg/dirprm/
cp  ertestpr.201701 ertestpr.prm
c)Activate the new configuration file “newfilename1

ogg
ggsci> start er *
Check OGG  until no data queuing in replication process:

testRO:                                     [重新启动目标段的extractor,观察lag ]
a)login test5 –l oggmgr
b)ogg
c)ggsci>start rpttestpr
c)#ggsci>lag *
check lag=0
d)stats rpttestpr
 ggsci>STATS * latest,totalsonly *.*

 ggsci>stats rpttestpr
{note: when check lag result = 0, proceed next step]




 

FAQ:

command 1: STATS * latest,totalsonly *.*

command 2:info er *

 command 2: stop er *!

          start er *是启动所有进程,

isse 1:start er *
解决方法:  
 一定要进入 OGG 安装目录/ggs (OGG),执行./ggsci 进入命令行模式;

issue 2: ogg command

定义在oggmgr user 的profile里。

### OGG Env. Setup
export JAVA_HOME=/opt/java6
. $HOME/utility/setup/setogg.sh
. oraenv

ORACLE

第二章 OGG 日常维护操作指南

  1. 启动 Goldenagate
    1. oracle 用户登录生产数据库主机系统
    2. 进入 OGG 安装目录/ggs,执行./ggsci 进入命令行模式;
    3. 启动源端管理进程

Copyright OGG Software, Inc.   1995-2007

GGSCI > start mgr          //  启动 manager 进程

  1. 启动所有进程

Copyright OGG Software, Inc.   1995-2007

GGSCI > start ext *         //启动所有抽取进程

  1. 查看进程状态是否为 Running(表示已经启动);

Copyright OGG Software, Inc.   1995-2007

GGSCI > info ext *//查看所有进程信息
   
SCI > start rep * //启动所有投递进程
   
  1. 查看进程状态是否为 Running(表示已经启动);

Copyright OGG Software, Inc.   1995-2007

GGSCI > info er *   //查看所有进程信息

说明:GGSCI > start er *是启动所有进程,如果只启动一个进程命令为 start <

进程名>。例如进程名称为 dpesz,则启动命令为 start dpesz。

2.监控goldengate复制延迟
  goldengate分为多个组件(extract,lag,replicat),所以在说延迟的时候也应该具体到是说哪个组件.作为一个复制解决方案来 说,我们通常关心复制延迟,也就是消息在source数据库的生成,到被apply到target数据库的这段时间.
  a> GGSCI的lag命令可以查询复制延迟, 如: 
    GGSCI> lag <replicat>
  b> 实际应用中,我们通常采用heartbeat表的方式来监控复制延迟,其优点是不仅可以监控适时复制延迟,还可以监控历史延迟情况.
  该机制的缺点是当goldengate本身发生异常停止了,heartbeat数据也不能更新,则表中的延迟数据不能反映真实的延迟情况. 规避该问题的方式是用当前系统时间减去heartbeat表中的源消息生成时间,则可以更准确的反映此时的真实延迟.
  但若heartbeat job出现异常停止更新heartbeat表,则heartbeat表中的源消息生成时间也不再及时,计算得来的延迟数据也不准确,所以采用heartbeat监控延迟还要注意对heartbeat表本身的监控.
  
3.监控goldengate复制错误
  默认情况下,当goldengate遇到复制错误时,goldengate是会异常终止的,处于abended状态.但在实际使用中,通常会修改这种默认设置,以让goldengate在遇到复制错误后能继续工作,避免造成过大的复制延迟.
  这种情况下一般会将错误信息写到discard文件中.要监控discard文件中有多少错误,可使用以下命令:
  GGSCI> STATS <replicat> latest,totalsonly *.*
  *** Latest statistics since 2013-08-14 07:17:33 ***
        Total inserts                               18840062.00
        Total updates                               26221878.00
        Total deletes                                6471532.00
        Total discards                                     0.00
        Total operations                            51533472.00
  这里的Total discards统计值就是出错的消息数.错误的详细信息记录在discard文件中,当然,也可能存在于某个表中,取决于你的goldengate配置中对错误信息的处理机制.
  当我们对错误信息作了处理后,比如手工fix了这些问题,我们就不希望上述检查命令再重复报告这些错误记录,这时可以运行以下命令来重置goldengate对错误信息的统计:
  GGSCI> STATS <replicat> latest,reset,totalsonly *.*
 
4.监控goldengate消息处理量
  a> 监控goldengate自启动以来总的消息处理量,可用以下命令:
  GGSCI> STATS <replicat>,totalsonly *.*
  这里查的是replicat进程,同样,也可以查询extract和pump进程
  b> 按表来统计消息处理量,使用以下命令:
  GGSCI> STATS <replicat>
  或者制定某个表作统计:
  GGSCI> STATS <replicat>,table <schema>.<table>
  c> 实际使用中,我们通常关心一定时间单位内的处理能力,比如每秒处理多少消息。这时我们可以借助heartbeat表的统计信息来监控,heartbeat 表中的RDMLDELTASTATS列记录了总的DML数,除以时间就可以得到goldengate处理能力统计数据。
  d> 除了以上方法之外,还可以设置REPORTCOUNT参数来让goldengate每隔一定时间将处理的消息统计写入goldengate report文件中,比如:
  ReportCount Every 30 Minutes, Rate
 
5.goldengate的事务处理命令
  对于常用的复制解决方案,无论是高级复制,stream还是goldengate,大事务或者长事务都是影响复制性能的重要因素之一。goldengate中有一些事务操作命令,可以帮助我们更好的监控或者人工干预这些大/长事务。
  a> 查看extract进程当前打开的事务:
  GGSCI> send <extract>,showtrans
  b> 当我们意识到某个事务可能存在问题,我们可能希望看看该事务中的具体信息,可采用以下命令:
  GGSCI> send extract <extract name>,showtrans <XID> file <file_name> detail
  上述命令会将事务的详细信息写到文件中。
  c> 当我们看到某个事务运行了很长时间,同时认为该事务可以提交或直接忽略时,可使用以下命令:
  GGSCI> send extract <extract name>,skiptrans <xid>    --跳过某个事务
  GGSCI> send extract <extract name>,forcetrans <xid>   --强制提交某个事务
原文地址:https://www.cnblogs.com/feiyun8616/p/6277651.html