1 2 Previous Next 15 Replies Latest reply: Jan 30, 2013 2:17 PM by EdStevens RSS

    Move large database to other server using RMAN in less downtime

    556923
      Hi,

      We have large database around 20TB. We want to migrate (move) the database from one server to other server. We do not want to use standby option.
      1)     How can we move database using RMAN in less downtime
      2)     Other than RMAN is there any option is available to move the database to new server

      For option 1 (restore using RMAN),

      Whether below options are valid?
      If this option is valid, how to implement this?


      1)     How can we move database using RMAN in less downtime
      a)     Take the full backup from source (source db is up)
      b)     Restore the full backup in target (source db is up)
      c)     Take the incremental backup from source (source db is up)
      d)     Restore incremental backup in target (source db is up)
      e)     Do steps c and d, before taking downtime (source db is up)
      f)     Shutdown and mount the source db, and take the incremental backup (source db is down)
      g)     Restore last incremental backup and start the target database (target is up and application is accessing this new db


      database version: 10.2.0.4
      OS: SUN solaris 10

      Edited by: Rajak on Jan 18, 2012 4:56 AM
        • 1. Re: Move large database to other server using RMAN in less downtime
          819493
          Hi,

          Call me crazy, but you should be able to do it this way:

          - Take full backup on the source db
          - Restore the database to the target db, but no recovery of the datafiles
          - Shut down the source db, copy control files and log files (archived and online) to the target server.
          - start the target server, and let oracle recover the datafiles to the most current scn

          If you're on Oracle 10 or newer, you could also use the backup as copy-feature,
          http://www.oracle.databasecorner.com/resource,3938,rman-image-copy-features-of-the-oracle-10g.aspx

          HtH
          Johan
          • 2. Re: Move large database to other server using RMAN in less downtime
            Kamran Agayev A.
            If you want less downtime, you can create a standby database from the production, and after restore completes, stop the produciton database and move the latest archived redo log files, take the standby database forward to the latest SCN and perform switchover
            • 3. Re: Move large database to other server using RMAN in less downtime
              aziz
              How about a logical path:

              1. Install the software on the new server.

              2. Use datapump full export.

              3. Use datapump import to the new server.

              You need help implimenting this you can reply to this or google it.
              • 4. Re: Move large database to other server using RMAN in less downtime
                tychos
                Hi,
                1)     How can we move database using RMAN in less downtime
                Most options are already covered. Johan's solution is similar to one I used.
                2)     Other than RMAN is there any option is available to move the database to new server
                If you can do disk mirroring than you have a very fast and simple solution.
                Just sync the mirror and when in sync find a convenient time to stop the database.
                Split the mirror and mount the filesystems on the new machine.
                Last step is to startup the database.
                If for some reason you have an issue the rollback is easy just start the database on the old machine.
                Regards,
                Tycho
                • 5. Re: Move large database to other server using RMAN in less downtime
                  556923
                  Hi,

                  we are moving the database from QFS filesystem to ASM filesystem.
                  so we can not use the disk mirroring option.
                  • 6. Re: Move large database to other server using RMAN in less downtime
                    556923
                    hi,

                    database size is around 20TB (large database), so import and export (with datapump) option will take good amount of time.
                    and database is having around 30,000 indexes, so index rebuild will take good amount of time.
                    • 7. Re: Move large database to other server using RMAN in less downtime
                      NikolayIvankin
                      Kamran Agayev have already gave your a good advice - Standby database and switchover.
                      This is a solution with a really small downtime.
                      • 8. Re: Move large database to other server using RMAN in less downtime
                        556923
                        Hi,

                        As mentioned in question, we do not want to go by standby database.
                        • 9. Re: Move large database to other server using RMAN in less downtime
                          tychos
                          Hi Rajak,
                          we are moving the database from QFS filesystem to ASM filesystem.
                          Mmm, that's new info.

                          Can you provide some more details?
                          How much archived redo in GB is created every day?
                          What is the (estimated) restore time in hours of the 20 TB database?
                          Are you able to do a backup/restore and keep all the archivelogs on a NAS which both machines can see?
                          After the restore doing a recover from the archives on NAs could be an option?

                          Rgds,

                          Tycho
                          • 10. Re: Move large database to other server using RMAN in less downtime
                            Kashif Khan
                            Rajak,

                            There are so many ways of doing this. Since you cannot afford to have a standby I would suggest you to use RMAN to clone your database which doesn't require any downtime. After that you can configure one-way streams to resync your clone with your actual database. Once the resync of the database is done you can schedule a downtime and switch to the new database. This will result in the least possible downtime.

                            Regards,

                            Kashif.
                            • 11. Re: Move large database to other server using RMAN in less downtime
                              onedbguru
                              868332 wrote:
                              How about a logical path:

                              1. Install the software on the new server.

                              2. Use datapump full export.

                              3. Use datapump import to the new server.

                              You need help implimenting this you can reply to this or google it.
                              [868332], I would buy tickets to see you **try** to do an export of a 20TB database. It would take weeks and more than 20-30TB of "backup" storage to do it. I'm thinking not. He did say "LESS" time. :)

                              Edited by: onedbguru on May 11, 2012 2:17 PM
                              • 12. Re: Move large database to other server using RMAN in less downtime
                                onedbguru
                                Simple:

                                I do this all the time to relocate file system files... But the principle is the same. You can do this in iterations so you do not need to do it all at once:

                                Starting 8AM move less-used files and more active files in the afternoon using the following backup method.

                                SCRIPT-1
                                RMAN> BACKUP AS COPY
                                DATAFILE 4 ####"/some/orcl/datafile/usersdbf"
                                FORMAT "+USERDATA";
                                ...

                                Do as many files as you think you can handle during your downtime window.

                                During your downtime window: stop all applications so there is no contention in the database

                                SCRIPT-2
                                ALTER DATABASE DATAFILE 4 offline;
                                SWITCH DATAFILE 4 TO COPY;
                                RECOVER DATAFILE 4;
                                ALTER DATABASE DATAFILE 4 online;
                                ....


                                I then execute the delete of the original file at somepoint later - after we make sure everything has recovered and successfully brought back online.

                                SCRIPT-3
                                DELETE DATAFILECOPY "/some/orcl/datafile/usersdbf"
                                ...

                                For datafiles/tablespaces that are really busy, I typically copy them later in the afternoon as there are fewer archivelogs that it has to go through in order to make them consistent. The ones in the morning have more to go through, but less likelihood of there being anything to do.

                                Using this method, we have moved upwards 600G at a time and the actual downtime to do the switchover is < 2hrs. YMMV. As I said, this can be done is stages to minimize overall downtime.

                                If you need some documentation support see:
                                http://docs.oracle.com/cd/E11882_01/server.112/e18951/asm_rman.htm#CHDBDJJG

                                And before you do ANYTHING... TEST TEST TEST TEST TEST. Create a dummy tablespace on QFS and use this procedure to move it to ASM to ensure you understand how it works.

                                Good luck! (hint: scripts to generate these scripts can be your friend.)
                                • 13. Re: Move large database to other server using RMAN in less downtime
                                  988159
                                  20Tb server to server could take days depending on your network. I can think of using Golden Gate for a very low downtime migration.

                                  1. Create an initial copy(exp) of the DB import into the new DB
                                  2. GG keeps track of changes while source db is online and exporting
                                  3. GG applies all changes on destination server
                                  4. Point the App to the new server

                                  GG is a good option for zero downtime migration.

                                  - David
                                  • 14. Re: Move large database to other server using RMAN in less downtime
                                    EdStevens
                                    Albert_Zaza wrote:
                                    How about a logical path:

                                    1. Install the software on the new server.

                                    2. Use datapump full export.

                                    3. Use datapump import to the new server.

                                    You need help implimenting this you can reply to this or google it.
                                    And while he's waiting for that terabyte of data to import (after possibly having waited for it to move across the network) , the source database is continuing to be updated. Several hours later, when the import is finished, the target database is several hours behind the source .....
                                    1 2 Previous Next