Data Integration, GoldenGate, Oracle

Initial Direct Load Access Denied in Oracle GoldenGate 12.2

can-stock-photo_csp17542921Over the last few days, I’ve been checking out the Initial Load process in Oracle GoldenGate 12.2. While it seems straight forward, I kept running into an Access denied error. To be more specific the ggserr.log says: ERROR   OGG-01201  Oracle GoldenGate Capture for Oracle, eload01.prm:  Error reported by MGR : Access denied. How do we fix this?

Environment:

Oracle Virtual Box 5.0.12

Single Host- MacBook Pro

  • VM1 (source – src) 192.168.56.102
    • Oracle GoldenGate 12.2
    • Oracle Database 12c (12.1.0.2.0)
    • Oracle Linux 6.6
    • Swingbench
  • VM2 (target – trg) 192.168.56.101
    • Oracle GoldenGate 12.2
    • Oracle Database 12c (12.1.0.2.0)
    • Oracle Linux 6.6
    • Swingbench

Setting up a very basic Direct Load process, my goal is to populate the target table soe.addresses from data in the source soe.addresses table. I used swingbench to create the soe schema and datasets. Once I configured my system for the Initial Load, I started the extract on the source and it immediately stopped. View ggsevt, provided the follow error information:

ERROR   OGG-01201  Oracle GoldenGate Capture for Oracle, eload01.prm:  Error reported by MGR : Access denied
ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, eload01.prm:  PROCESS ABENDING

After validating that all the login information to the source and target databases was correct, what was left?

What I discovered is in Oracle GoldenGate 12.2, the default behavior is the MANAGER and related EXTRACT/REPLICAT cannot be started or stopped remotely. Since the Direct Initial Load is initiated on the source server and attempts to start the REPLICAT on the target server, this falls into that category.

The fix is to add “ACCESSRULE, PROG *, IPADDR *, ALLOW” to your manager parameter file (mgr.prm) on the target system. I did this in a test system, and I have used wildcards in the accessrule. I suggest that you consult the GoldenGate documentation to ensure you maintain appropriate security measures for your environment.

Read at your leisure

The remainder of the post covers additional details on the”ACCESSRULE, PROG *, IPADDR *, ALLOW” parameter from security perspective and what my original parameter file look like.

In my test environment a more secure ACCESSRULE parameter would look like this:
ACCESSRULE, PROG REPLICAT, IPADDR 192.168.56.102, ALLOW

--
-- GoldenGate Manager Parameter File (mgr.prm)
--
userid xxxxxxx, password xxxxxxx
PORT 7809
ACCESSRULE, PROG REPLICAT, IPADDR 192.168.56.102, ALLOW
PURGEOLDEXTRACTS ./dirdat/rt*, USECHECKPOINTS, MINKEEPHOURS 2
--

accesrule

allowggs

By editing the accessrule parameter on the target mgr.prm by changing the IP address, we can see that extract process has stopped and access has been denied :

ACCESSRULE, PROG REPLICAT, IPADDR 192.168.56.10, ALLOW

extstopped
allowdeny

 

Focusing on the soe.addresses table for a Direct Load, my original parameter files looked like this:

Source mgr.prm

-- GoldenGate Manager Parameter File (mgr.prm)
userid xxxxxxx, password xxxxxxx
PORT 7809
PURGEOLDEXTRACTS ./dirdat/lt*, USECHECKPOINTS, MINKEEPHOURS 2

Source eload01.prm (extract)

EXTRACT ELOAD01
userid xxxxxxx, password xxxxxxx
sourcecatalog pdb1
rmthost trg, mgrport 7809
rmttask replicat, group rload01
table soe.addresses;

Target mgr.prm

--
-- GoldenGate Manager Parameter File (mgr.prm)
userid xxxxxxx, password xxxxxxx
PORT 7809
PURGEOLDEXTRACTS ./dirdat/rt*, USECHECKPOINTS, MINKEEPHOURS 2

Target rload01.prm (replicat)

REPLICAT RLOAD01
userid xxxxxxx, password xxxxxxx
assumetargetdefs
handlecollisions
dboptions suppresstriggers
discardfile ./dirrpt/rload01.dsc, purge
map pdb1.soe.addresses, target pdb1.soe.addresses;

Enjoy

dbaOnTap

Related Posts Plugin for WordPress, Blogger...

3 Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.