We have a requirement to implement replication (of transactions) from a production database to a test database (across a db link). We're using 11g enterprise edition.
This is because it's not just the production data that's needed, the intention is that code releases in the test database would be tested against real-world transactions from the prod system, without the need for those transactions to be done manually. If a transaction fails then in the test system that worked in the prod system, something is wrong with the release.
It doesn't necessarily have to be in real-time however, a delay is acceptable.
There must be zero risk though on the production transactions failing, due an issue with the replication.
What are the options here? I believe Streams is deprecated in 12c, should that be of concern? GoldenGate is additional ££, which I'm afraid rules it out in this case. Some kind of custom trigger-based solution... too much risk on the prod system as far as I can see.
Any advice greatly appreciated!
As of Oracle release 12c (12.1.x), Oracle Advanced Replication and Oracle Streams are being discontinued. Oracle Golden Gate is going to replace all features of Oracle Advanced Replication and Oracle Streams.
Please review this list of possible alternatives (to name a few):
SharePlex
DBVisit
DBConvert
Related
I am a java person and not so much familiar with Oracle available features. Please help me.
The requirement is that, we are looking for some virtual(replica/mirror/view) database to be created from Production database just for testing purpose. Once we are done with executing all the automation test cases, delete the virtual database created. So are there any such concepts in Oracle ?
We are on Oracle 12c.
Many apps use same DB(its huge)
PS: We also use docker for deployment and also AWS.
use Rman duplicate to duplicate the test database from production.
https://oracle-base.com/articles/11g/duplicate-database-using-rman-11gr2
you can duplicate from backups or duplicate from active database
You can probably ask your database admin to export the table space to a new test machine which has the same oracle version installed. May require If there are only very few tables, then you can spool your tables out and use sqlloader to load them to a test database ( you will need to manually create the structure of the tables in test environment before hand.
In both cases, you might want to scrub out the sensitive information as per your requirements and standards.
My colleague running Oracle Database (11g) in AIX and they would like to move this DB to RHEL. I already found Link. However I would like to check if someone have already migrated or used any other best tools.
you have several options. As pointed out before, Oracle Data Pump is the easiest approach. It would lift you from every version >=10g upwards (or even back when you use the VERSION= parameter).
The caveat is:
Size of the database - and your downtime requirements.
In terms of larger databases, Transportable Tablespaces is the usual choice. More work as you will have to rebuild meta information such as synonyms, view, plsql, sequences etc - and in your case you'll have to either CONVERT the tablespaces as you are coming from a Big Endiann platform and going to a Little Endiann. DBMS_FILE_TRANSFER could assist you here as it can restore and covert at the same time whereas RMAN will need a 2-phase operation with staging space for it.
You can speed up transportable tablespaces with RMAN Incremental Backups to avoid most of the copy/convert time. And you can ease it with Full Transportable Export/Import (minimum source: 11.2.0.3 - minimum destination: 12.1.0.1) where Data Pump does the manual work of transportable tablespaces.
And of course there are other techniques such as Create-Table-As-Select or Insert-Append-Select options via Database Links and such.
Just see the big slide deck "Upgrade / Migrate / Consolidate to 12.2" for customer examples - and the "Migrate >230Tb in <24 hours" decks on my page: https://mikedietrichde.com/slides/
Cheers,
Mike
Is there some reason you can't just use Oracle Database Pump?
Create the database on RHEL, make sure you use a compatible character set.
https://docs.oracle.com/cd/B19306_01/server.102/b14215/dp_overview.htm
(I do not code on my own, to make things clear)
I am looking for a solution that would allow to replicate data between a, master, Oracle 11g DB and a new PostgreSQL DB. Those are 2 different applications but the need to exchange data in real-time. There are some trigger-based ways but there is quite a big concern that this can affect the master DB efficiency - which we can't do.
I have also come across some log-based solutions, like HVR, but the cost is way too high for 500MB of data to be replicated.
Maybe anyone of You had a similar issue and found a way to deal with it?
Any kind of tips and help will be really appreciated as I am quite short on time
Oracle Archive Logs have different format than Postgres Write Ahead Logs. Despite the general similarity in concept of Oracle Streams, SQL Log Shipping, Postgres Streaming Replication etc, transaction logs <> redo logs <> xlogs and you can't use one provider logs to roll on the other provider engine.
Moreover you can't roll logs over same DB provider different version because of difference in binary format.
Something alike logical replication you can get with Postgres Logical Decoding, Oracle GoldenGate, Heterogeneous Database Replication, AWS DMS. But none of above gives you "Log-Based replication" between different db vendors
You can use a product that specializes in change data capture based data integration. Striim, GoldenGate, Attunity allow you to do CDC from Oracle. Striim also allows you to do CDC from PostgreSQL and write to Oracle as well.
https://striim.com
https://attunity.com
We have application where all logic is implemented in oracle database using pl/sql.
We have different oracle databases for development and production.
When developer make changes in development database after testing we move changes from development database to production database using schema compare tool of toad. Problem here is that developer must have password of production database. We want only admin to know this password.
Can somebody advice me better way of moving changes between databases without need of having production database password, what is best practice for this ?
I posted this question on oracle OTN forums and got some advices there. Maybe it will be interesting for somebody.
Her is a link
I do not recommend to use comparison tools for generating of database migration scripts.
Development and production databases (and also test databases) must be identical except for current changes made by developers in development databases. Generally speaking this assertion is not correct, because there are many kinds of differencies between development and production databases, e.g. partitioned objects, additional objects for audit (triggers, tables), replication-based objects (snapshots), different tablespaces etc.
Every developer must know, what changes were made by him and applied to development database.
If developer was able to change schema and data in developer database, then he/she must be able to create programs for these DDL and DML changes.
To delegate the same developer an ability to run these migration programs on production database is a bad idea. But if you don't have a better way of database migration, then you can use one of following:
1. Configure Oracle authentication by OS. OS authentication allows Oracle to pass
control of user authentication to the operating system.
2. TOAD can save passwords without disclose them. DBA will insert required password
to local TOAD installation at developer PC (if developers use PC).
A quick and simple question: has anybody used the combination of Hibernate 2.1.7 and Oracle 11gR2 database? We have a legacy app that is using Hibernate 2.1.7 (which we are not planning to update at this point in time) and our database back-end is being upgraded to Oracle 11gR2. Is there any issues we need to be aware of?
Thanks!
With jdbc driver 11.1.0.6.0 you can connect to Oracle 11gR2. No problem.
A simple issue that you might run into is the case of username and passwords. In 11g this is case sensitive, before that version it was not case sensitive.
An other nice one is that accounts now default expire. Check that with your local dba.
You should test the app during the upgrade tests. Database features change, optimizer features change, so the app behaviour could change. Technically I see no reasons why it would not work but knowing some software projects .... Test it. In many cases it does not give any problems at all. A lot depends on the quality of the code. If your app's code is working because it is based on a bug in Oracle that is now solved, you will run into an issue.