Question on data movement

From: Lok P <loknath.73_at_gmail.com>
Date: Sun, 23 Jun 2024 11:40:09 +0530
Message-ID: <CAKna9VZDhx0unBygqPO6EZfk0k_i8W91ThUskS0n8c1dhA1zmA_at_mail.gmail.com>



Hi,
We have a third party application which is having a backend hosted on Azure cloud Oracle database. It's currently processing all of our transactions. Due to some risk and reporting requirement , we want the data to be persisted in our own cloud account i.e. AWS. These data will be ingested to our own data lake through the existing data pipeline which comprises postgres database and snowflake databases. The total size of the third party Oracle database hosting our data is ~10GB.

For this we are thinking of doing it in two methods 1)Get the database full backup or dumpfile from the Oracle database hosted on Azure cloud and MFTS that to the AWS S3 bucket. And then subsequently import the incremental backups from the oracle database to AWS. This will ensure all of the transaction data(means all the data elements without miss) getting persisted in our cloud/data lake environment.

2)List the selected data elements which our datalake needs for the satisfying reporting requirement. Pass on the list of those selected data elements to the third party vendor , so that they will send the delta data/changed data each day in .csv file format for those selected data elements. This csv files will then MFTS to our AWS account S3 bucket and then we can then ingest those to our datalake system for satisfying our reporting needs.

But here I have a question,
If we get the full Oracle database dump from Azure cloud and move it to AWS S3 bucket and then subsequent incremental backup dump. Will this dump be in a state , so that it can be imported into AWS RDS oracle without any issue and the database schema along with the data can be visualized inside our AWS account whenever we need? Or do you suggest any other method to handle the above requirement?

Regards
Lok

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Jun 23 2024 - 08:10:09 CEST

Original text of this message