Best Of
Re: QMTO in F3112 Not Rollback
Hello John,
It would be best if you could open a new service request so that we can work on this issue with you. Please supply a print screen of the P31226 along with a databrowser of the Routing (F3003). From there we can test your specific setup and if a bug needs to be written, then it will be done.
Thank you kindly,
J.J.
QMTO in F3112 Not Rollback
Dears,
When WO Routing triggers the outside operation the OPSQ will write the quantity in F3112 QMTO, so P31226 can inquire the QMTO (Qty at Operation) column. However, if cancel the outside operation order from WO routing the F3112 QMTO will not roll back to zero, and like to know why's that? Thank you!
Regards,
John
9.2 R24, TR 9.2.8.4
Re: Mod_Auth_Mellon
Hi Michael,
Thanks for the reply.
we'll evaluate the changelog more carefully, on the box we did look at it, I was told there had not been any recent changes, so will dig into that a bit.
I think the expectation was that since this project was forked in dec 2019, that the newer source (latchset) would have gone into ol8 stream as well, not just the ol9, but perhaps that was just wishful thinking.
Mark
Re: Can I run the post-install script once for multiple installations of Oracle database patches?
If you are on oracle 12c and above then you can apply both patches one after the other at binary level and then run datapatch to apply both patches to each database.
Re: After April 2025 PSU materialized view refresh failing which connects to SQL Server using dg4odbc.
Hello All,
I opened SR with Oracle support, and the team confirmed that it's a bug in 19.27 (April 2025 PSU).
====
Oracle Support confirmed that the April 2025 PSU (19.27) has a bug.There is a problem with DBRU 19.27, which is causing the gateway connection to fail with ORA-00001.
This problem is being worked by Oracle development on the below bug - Bug 37889661 - DG4ODBC - ORA-00001: UNIQUE CONSTRAINT (%S.%S) VIOLATED - AFTER APPLY DBRU 19.27
====
Thanks,
Mukesh Kumar
Re: Veridata 23c installation and software owner account?
Hi DougK
No other configurations needed. The referenced link was posted by one of the product managers for Veridata.
The official documentation
https://www.oracle.com/pls/topic/lookup?ctx=en/middleware/goldengate/veridata/23&id=GVDUG-GUID-F70C6F17-0DED-489D-8060-F289D3360075
would have indicated of any other items required for the successful installation.
As long as you perform the installation on supported/certified OS version, both references above should work.
For certification information you can check
https://www.oracle.com/a/ocom/docs/ogg-veridata-23c-cert-matrix.xlsx
For Linux platforms, both Oracle Linux 8, RHEL 8 and Oracle Linux 9, RHEL 9 are certified.
The xls doc. contains all certified combinations.
thanks
Carlos
Re: Veridata 23c installation and software owner account?
Greetings DougK
The install for Veridata 23c is done as a regular "oracle" user.
You can follow the instructions in this link that includes all steps plus screen shots
https://www.oracle-scn.com/oracle-goldengate-veridata-23c-installation/
In that example we see the typical "oracle:oinstall" Unix/Linux user owning the installation.
thanks
Carlos
Re: The best practice for the number of Extract and Replicate groups for Oracle Golden Gate MA 21
Hi,
Thanks for the update.
You can use the below query to find out the thread# for respective log seq#:
SELECT NAME,THREAD#, SEQUENCE#,DELETED,STATUS FROM V$ARCHIVED_LOG where SEQUENCE#=513626;
Regards,
Gopal
Re: The best practice for the number of Extract and Replicate groups for Oracle Golden Gate MA 21
Hi,
You can get log seq#/rowid from trail file for an update or any DMLS, and then you may need to mine the source log to get exact update SQL.
Regards,
Gopal
Re: The best practice for the number of Extract and Replicate groups for Oracle Golden Gate MA 21
Thanks Rsudha for your input. It is very much useful.
Now I have 1 more question. I got one of the replicates abended due to no data found. However, I can see the record in the target. The discard file shows the values for each column but it doesn't show the exact update statement that was applied by the replicate. Is there a way to get the SQL statement which was applied? From the trail file, for example? So I can manually execute it on the target? And if so, how can I make the replicate start again ignoring only the failing statement, not the whole transaction? Appreciate your contribution.
