The @DATENOW() function is returning the results of SYSDATE from the database. For many types items, this should be enough to meet the needs of the end user. In this case, you are wanting to dig a bit deeper and get the millisecond precision of the timestamp. Doing a simple test, this can be achieved.

The use case I used is as follows:

Source Table:

Name Null? Type
---- ----- -------------
ID NUMBER
NAME VARCHAR2(128)

Target Table:

Name Null? Type
------------ ----- ---------------------------
ID NUMBER
NAME VARCHAR2(128)
REC_DATE TIMESTAMP(6)
REC_DATE_WTZ TIMESTAMP(6) WITH TIME ZONE

These tables are the same table; just on the target side, I have two columns that record the record date (@DATENOW()) and record date with timezone. The latter allows for the milliseconds to the 6th place to be captured.

Now for the GoldenGate setup.

Extract Parameter File (Source):

extract IEXTTEST
useridalias SGGATE domain OracleGoldenGate
exttrail za
sourcecatalog pdb1;
table test.test_date;

Replicat Parameter File (Target):

replicat IREPTEST
useridalias TGGATE domain OracleGoldenGate
map pdb1.test.test_date, target test.test_date,
sqlexec (ID lookup, QUERY 'select systimestamp from dual'),
colmap(usedefaults,
rec_date = @DATENOW(),
rec_date_wtz = lookup.systimestamp
);

The changes that needed to be made in order to capture the timestamp to milliseconds required the use of SQLEXEC to call the system timestamp (SYSTIMESTAMP) from the database. Then the target table had to accept the SYSTIMESTAMP data into a datatype that supported capturing milliseconds (TIMESTAMP WITH TIME ZONE).

Now when I replicat a few transactions from source-to-target, I can see the difference between the @DATENOW() function calling SYSDATE and using SYSTIMESTAMP to get the milliseconds for when the record was applied.

ID NAME REC_DATE REC_DATE_WTZ
---------- --------------- ------------------------------- --------------------------------------
1 SysAdmin 22-JAN-18 09.44.46.000000000 PM 22-JAN-18 09.44.46.531189000 PM -05:00
2 SysAdmin 22-JAN-18 09.44.46.000000000 PM 22-JAN-18 09.44.46.703136000 PM -05:00
3 SysAdmin 22-JAN-18 09.44.46.000000000 PM 22-JAN-18 09.44.46.721737000 PM -05:00

This example provides a bit more information in terms of timezone details, but it should provide enough information to show how to use SQLEXEC to get additional information from database.