Hi,
we have a lot of table partitions. The vendor application on the db uses in
my opinion the partitioning abuselly. Everyday the application generate a
thousand of new partitions. But this will be a subject for another
question.
Thanks a lot for sharing your experience
Ahmed
------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer>
--- Original-Nachricht ---
Von: Ls Cheng
Betreff: Re: Re: the best approach to migrate a database to new server
Datum: 31.01.2020, 18:16 Uhr
An: ahmed.fikri@xxxxxxxxxxx
Hi
I have done around 80 migrations with TTS and incremental backups. Downtime
from 20, 30 minutes to 2, 3 hours.
The downtime is NOT 0. It depends on the number of database objects because
the data refresh part is fast because it uses incremental backups but the
export and import time depends on number of objects.
BR
On Fri, Jan 31, 2020 at 6:13 PM ahmed.fikri@xxxxxxxxxxx
<mailto:ahmed.fikri@xxxxxxxxxxx> < ahmed.fikri@xxxxxxxxxxx
<mailto:ahmed.fikri@xxxxxxxxxxx> > wrote:
I guess that's exactly what we need and everything else doesn't make
sense. However does someone know how long could take the migration of the
16 TB db? I found article that said the downtime is 0
https://ittutorial.org/new-oracle-xtts-v4-reduce-transportable-tablespace-downtime-using-cross-platform-incremental-backup
<https://ittutorial.org/new-oracle-xtts-v4-reduce-transportable-tablespace-downtime-using-cross-platform-incremental-backup>
/
Regards
Ahmed
----------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer>
--- Original-Nachricht ---
Von: Ls Cheng
Betreff: Re: the best approach to migrate a database to new server
Datum: 31.01.2020, 17:42 Uhr
An: ahmed.fikri@xxxxxxxxxxx <mailto:ahmed.fikri@xxxxxxxxxxx>
Cc: oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>
Hi
Try
V4 Reduce Transportable Tablespace Downtime using Cross Platform
Incremental Backup (Doc ID 2471245.1)
BR
On Fri, Jan 31, 2020 at 3:25 PM ahmed.fikri@xxxxxxxxxxx
<mailto:ahmed.fikri@xxxxxxxxxxx> < ahmed.fikri@xxxxxxxxxxx
<mailto:ahmed.fikri@xxxxxxxxxxx> > wrote:
Hi all,
we are planning to migrate a 16 Terabyte database from 11g on aix
machine to 12c on linux. In the target db is Dataguard used. The DB has
about 50 Schemas the biggest one is about 11 TB the second is 2.6 TB
then four with each one 1 TB the rest is each one less than 1 TB.
Unfortunately all Schemas share the table spaces.
Wich approach could we use with less downtime?
My idea was to move the schemas to separate tablespaces an migrate the
Schemas using transportable ts.
Or somehow copying the metadata to do new instance in such way the new
db use the old data files and then copy them separately one by one.
Or even copying the Schemas separately using dblink and data pump.
Any idea please?
Regards
Ahmed Fikri
--------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer>
