Re: Migrate from AIX to Linux

From: Deepak Sharma <"Deepak>
Date: Thu, 17 Dec 2015 17:52:03 +0000 (UTC)
Message-ID: <72183924.271527.1450374723961.JavaMail.yahoo_at_mail.yahoo.com>



We have started to look at that document now. The problem is that the document refers to taking datafile copies as the Prepare phase. In our case, we already have datafile copies (image copy and incrementals) as a regular process to backup our DW. Now, since you have experience with actually doing the migration, let me know if this would work (we will of course try it out soon too): 1. Copy the 'datafile copies' from source to destination staging area2. Run the 'convert from platform' RMAN command, to convert those datafile copies so they land in the real datafile locations3. Copy the subsequent 'Incrementals' from source to destination area4. Convert the Incrementals on destination to apply to real datafile (from Step 2).5. Repeat 3 & 4, until you're almost caught up, and do a final 3 & 4 with source tablespaces being read-only. Does this make sense? Pls share your thoughts. -thanks

    On Thursday, December 17, 2015 9:40 AM, max scalf <oracle.blog3_at_gmail.com> wrote:  

 Have you looked at the below note?  We recently moved an 60Tb database from hp to linx(big to little endiness) with downtime of only 4 hours... Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1)

On Wednesday, December 16, 2015, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

  Yes, I wholeheartedly agree with Kyle. It is much easier to use specialized utility, like Delphix or Commvault, which is a general purpose backup suite which also does de-duplication, storage snapshots, compression and a lot more, to migrate databases or duplicate databases on schedule.  Regards    

 On 12/16/2015 07:43 PM, kyle Hailey wrote:     

 I think Tim nails it completely in his online here but I also blogged with more detail at http://blog.delphix.com/kyle/2014/delphix-unix-linux-oracle-conversion/   

  The big difference is automation, though there are some huge technical advantages.  As an analogy, I could backup my database with the UNIX copy command (cp) but why? I'd use RMAN. RMAN not only is much more powerful, with cool low level functionality that I couldn't write myself, but it's automated. Same with Delphix. You can script much of what Delphix does by hand if you have storage system with snapshots but with Delphix it's completely automated and there are things you probably can't code yourself such as storing 2 versions of a database (AIX version and Linux version) in 1/3 the size of the original database. Delphix actually maps the endianess conversions from one platform to another using the same data for both versions of the database and compressing that data. Delphix is also point and click and forget about it when migrating to the cloud. One Delphix appliance can replicate to another in the cloud with compression, encryption, reusability and at scheduled transfer times (so as not to flood network during high usage periods). It's much easier and foolproof than trying to migrate the database myself.    Delphix does 3 things to help XPP

  • full automation - connect to source, pull in changes, provision converted database
  • export and import of system data
  • reduce disk footprint required by 2-3x (i.e. in 1/2 to 1/3 the space) for initial copy, almost free for any additional copies For me, full automation is where it's at. Just select and register source and target and click a few buttons and conversion is done automatically. That's powerful especially when the process can be slow and tedious. IMO the biggest challenge with cross platform conversion (XPP) is complying with the restrictions for XPP. Delphix will find them, but the DBA still has to fix them. Going from one version of Linux to another is great because there is a convert database command. Unfortunately going *NIX to Linux there is no command and it requires exporting the database general information like users and procedures etc (since with convert database doesn't work with *UNIX to Linux so you have to transfer each tablespace and then manually transfer system data you want to keep). Delphix takes care of this part automatically.
    • Kyle

 On Tue, Dec 15, 2015 at 4:01 AM, Tim Gorman <tim_at_evdbt.com> wrote:  

  Matt,  

 Extra work?  Not for the DBA, and not when you consider that the "standard" RMAN approach requires three full copies (3x) of the database being converted...       

  • Original database in READ WRITE on UNIX (i.e. Solaris, HP-UX, AIX)
  • Copy of database in READ ONLY on UNIX (a.k.a. conversion "source")
  • Creating this copy often needs to happen multiple times for TTS and XPP "validation"
  • Copy of database in READ WRITE on Linux (a.k.a. conversion "target")

 What Kyle describes uses about 1.3x of the size of the original database, not 3.0x...       

  • Original database in READ WRITE on UNIX (i.e. Solaris, HP-UX, AIX)
  • dSource of database (consuming 1/3rd the size of the original database)
  • Copy of database in READ ONLY on UNIX (a.k.a. conversion "source") consuming zero bytes and 5-10 mins to create
  • Creating this copy often needs to happen multiple times for TTS and XPP "validation"
  • Copy of database in READ WRITE on Linux (a.k.a. conversion "target") consuming less than 100 GB of storage

 All of this may not matter when you're discussing cross-platform migration of a small database, but small databases rarely cause difficulties of any kind.  

 Besides, if you've done the process "manually", then having the whole process employing TTS automated already should be very attractive.  

 I've also spent some time documenting the process online here, if that helps?  

 Thanks!  

 -Tim      

 On 12/15/15 0:48, Dimensional DBA wrote:       

  Seems like extra unnecessary work Kyle, than just using the standard rman methodology proposed.   Deepak, what is your outage window allowed for this database?       Matthew Parker Chief Technologist 425-891-7934 (cell) Dimensional.dba_at_comcast.net View Matthew Parker's profile on LinkedIn                  

 --
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com     

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Dec 17 2015 - 18:52:03 CET

Original text of this message