A friend of mine claims that GoldenGate is a product that is supposed to be used and exist outside the Oracle database. And if you run Oracle on a version below 220.127.116.11, the following query for GOLDENGATE objects will probably return no rows selected. But here is what happens with Oracle 18.104.22.168:
Interesting, right ?
Note that recently Oracle GoldenGate 22.214.171.124 was released. For Oracle GoldenGate on Oracle versions 10gR2 and higher, Extract now manages log retention by default. With this new feature, the documentation says you should be aware of the following:
1. The upgrade will automatically register each of your Extract processes with the database, which will start retaining the logs based on the current recovery requirements for each process.
2. An Oracle Streams Capture process will be created for each Extract process and will have the same name as that process. These Capture processes are non-functional and can operate concurrently with other local Oracle Streams installations.
3. In order for the upgrade to succeed (on 126.96.36.199), you will need to assign the Extract user some additional privileges.
Note first that you need to commit after executing the procedure in the dbms_goldengate_auth package:
SQL> exec dbms_goldengate_auth.grant_admin_privilege('GGATE'); PL/SQL procedure successfully completed. SQL> commit work; Commit complete.
Note additionally that the privilege_type can be CAPTURE, APPLY or BOTH. Both (= *) is the default. If you prefer that the GGATE user is granted also the select_catalog_role, you should run the command like this:
SQL> exec dbms_goldengate_auth.grant_admin_privilege('GGATE','*',TRUE); PL/SQL procedure successfully completed. SQL> commit work; Commit complete.
Oracle GoldenGate version 188.8.131.52 contains improved sequence support. To enable this support, you must install some database procedures that support the new FLUSH SEQUENCE command. I recommend that for details you read Samuel Oleleh’s Oracle Goldengate 184.108.40.206 Sequence Support article.
The (Oracle database related) new features of GoldenGate 220.127.116.11 are very well described in the following blob entries:
For all the MySQL users (are there any?), I will note that there is a new ALTLOGDEST option that was added to TRANLOGOPTIONS to specify the location of the MySQL log index file. This value overrides the database default location. Extract reads the log index file to find the binary log file that it needs to read.
For the Sybase users I will mention that the range of values for DBOPTIONS TDSPACKETSIZE has been changed. Additionally, two formerly internal parameters are now available for use in a TRANLOGOPTIONS statement:
– TRANLOGOPTIONS MAXREADSIZE specifies how many records Extract reads from the transaction log at one time. It can be used to improve performance.
– TRANLOGOPTIONS READQUEUESIZE specifies the internal queue size, in bytes, for transaction data. It can be increased to improve performance.
For Oracle GoldenGate installations please check:
As I hinted above MySQL and GoldenGate do not in my opinion go hand in hand. But I would briefly like to mention that Oracle GoldenGate can be used together with Active Data Guard to achieve almost zero planned and/or non-planned down time:
I will soon write more on live upgrades, zero downtime and 100% SLAs 🙂
P.S. As of today, Google returns only two pages with results for dba_goldengate_privileges, try for yourself to see if things have already changed: