Routine maintenance commands of goldengate

1. view the process status

Ggsci (pony) 2> info all

2. Check the detailed process status to help troubleshoot
Ggsci (pony) 2> View Report + process name

3. View alarm log information
Ggsci (pony) 2> View ggsevt

4. View latency and file extraction applications
Ggsci> lag <process name> allows you to view detailed latency information.
For example:
Ggsci (db4) 11> lag rep1
Sending getlag request to replicat rep1...
No records yet processed.
At EOF, no more records to process.
We can see that at EOF, no more records toprocess. All the table names have been extracted.

5. View statistics
Ggsci> stats <process name>, <time frequency>, table <ownername>. <Table Name> allows you to view the number of records processed by a process. This report will detail the types and number of records processed.
For example, ggsci> stats EDR, total lists the number of records processed since the process was started.
Ggsci> stats EDR, daily, table GG. Test list the number of records related to the GG. Test Table processed since the current day.

6. view detailed transaction records
Ggsci> info <process name> showch

7. view more detailed information, including the used tail file, parameter file, report file, and alarm log file location.
Ggsci> info <process name> detail

8. view long transactions
Ggsci> send extract ext1, showtrans
Ggsci> send extract <process name>, showtrans [thread N] [count N]
Where <process name> is the name of the process to be viewed, such as extsz/extxm/extjx;
Thread N is optional, indicating that only uncommitted transactions on one of the nodes are viewed;
Count N is also optional, indicating that only N records are displayed.
For example, to view the maximum 10 transactions on node 1 in the extsz process, run the following command:
Ggsci> send extract extsz, showtrans thread 1 count 10
The output result is a list of all uncommitted transactions sorted in descending chronological order. Xid can be used to find the corresponding transaction and the reason for uncommitted transactions, after the database is submitted or rolled back, the checkpoint of goldengate will automatically scroll forward.

9. Use the goldengate command to skip or accept long transactions
To forcibly commit or roll back a specified transaction in goldengate, run the following command (the parameter in <> ):
Ggsci> send extract <process name>, skiptrans <5.17.27634> thread <2> // skip the transaction.
Ggsci> send extract <process name>, forcetrans <5.17.27634> thread <1> // force that the transaction has been submitted
Note: using these commands will only let the goldengate process skip or think that the transaction has been submitted, but it does not change the transactions in the database. They still exist in the database. Therefore, it is strongly recommended that you use the database to submit or roll back transactions instead of using goldengate for processing.

10. Configure long transaction alerts
You can configure long transaction alerts in the extract process. The parameters are as follows:
Extract extsz
......
Warnlongtrans 12 h, checkintervals 10 m
Exttrail/backup/goldengate/dirdat/SZ
....
The preceding statement indicates that goldengate checks long transactions every 10 minutes. If a long transaction lasts for more than 12 hours, goldengate adds an alarm message to ggserr. log in the root directory. You can view these alarms by checking ggserr. log or running the view ggsevt command in ggsci. The above configuration can help you detect long transactions in a timely manner and handle them.
Note: In Ogg 11g, extract provides the BR parameter, which can be set to cache long transactions to a local hard disk (under the dirtmp directory by default) at intervals (4 hours by default ), therefore, as long as the extract does not stop, the archive log generally requires no more than 8 hours (limit ). However, if extract is stopped, long transactions cannot be automatically cached, and the archiving log is dependent on the downtime.

11. view the current replication table and add a copy table. Note: only when goldengate only enables replication DML
Ggsci> dblogin userid GGS, password GGS
Ggsci> info trandata Scott .*
Ggsci> Add trandata <schema>. <Table Name>

12.-reset the extraction process. The serial number of the local file is generated from 0.
Alter extract ext1, extseqno 0, extrba 0
13.-reset the read process and start reading from the trial File No. 0 again.
Alter replicat rep1, extseqno 0, extrba 0

Routine maintenance commands of goldengate