4 Replies Latest reply: Mar 20, 2014 2:43 AM by Franck Pachot RSS

    Migration to Exadata

    ABOracle

      Have requirement to migrate 100+ applications (400+ Oracle databases) to Exadata X2-2. Project timeline is 12 months to move everything to Exadata environment.

       

      Current state of databases:

      ===================

      1. All databases are in 11.2.0.2/3

      2. Runs mostly standalone( very less RAC)

      3. Mostly OLTP applications

      4. No consolidations

      5. Production systems are having RMAN - level 0 and incremental and archivelog

      6. databases run on Linux , SunOS

       

      Questions:

      =======

      1. What is the efficient migration technology to migrate all these applications/databases to exadata environments [[within 12 months timeline]]?

      2. Whether databases should be migrated to 11g or 12c ? which one should be best to consider and why?


      Thanks,

        • 1. Re: Migration to Exadata
          mrmessin

          1. What is the efficient migration technology to migrate all these applications/databases to exadata environments [[within 12 months timeline]]?

          I have done migrations to Exadata using Data Guard, Golden Gate, RMAN, export/import and datapump.  The migration strategy you use will depend on many factors and could vary from database to database.  Factors will include, version of current database, size of current database, tolerance for downtime to do the migration, network connectivity between the Exadata and the current environment as well as other infrastructure considerations such as storage space in current environment, ability to utilize current backup solution with the Exadata, etc.  There are potentially other items you will have to consider and factor into the migration strategy.  In developing a strategy for each database you may find them all to the be the same or you may not.  Also consider that in some migration strategies you will not be able to make adjustments that can really utilize some of the Exadata capabilities and that may be important to you.  For example in a Data Guard migration or an RMAN backup and recover migration you will put the copy of the database as is it into the Exadata this does not put in things like Hybrid Columnar compression or a partitioning strategy, if not already in place, which can really help the speed of Exadata in some cases.  Examine each of the database environments gather your requirements for the migration and develop a strategy that matches up to those requirements.  If you are not sure Oracle can help you or you can look for a firm that has done some Exadata migrations to help you develop your strategy a lot of organizations have found that valuable to help thing move more smoothly especially on a tighter timeline.


          2. Whether databases should be migrated to 11g or 12c ? which one should be best to consider and why?

          This has some to do with your tolerance for being on the latest and greatest version, but can introduce some complications as you will be having an upgrade in most cases involved which mean more changes from current environment to new environment and on a tight timeline that may prove more difficult.  Some organizations feel being a version behind has better stability while others feel being at the latest brings the ability to utilize the features of the latest and greatest.  I have many clients running 11.2 on Exadata and running very well, most are highly available environments where downtime and instability or not tolerated well, that being said does not mean 12c would not be good, but do not have anyone that I support running 12c on Exadata so can not say how stable it really is though the 12c testing we have done does not give any indications where would be an issue.  determine what works best for you and that has more to do with your particular requirements which you have not really mentioned here.  When on a tight timeline focus on stability and reducing risk some from having too many changes, utilize things like real application testing to ensure you got it right this will help ensure you transition is much smoother.

          • 2. Re: Migration to Exadata
            ABOracle

            Hi mrmessin,

             

             

             

            Thank You for your detailed elaboration on my queries.These are really helpful answers. I have few more queries in this regard and would like to setup the context more precise.

             

             

             

            1.

             

            Looking for a strategy where I would like to accomplish the migration in 30 calender days(say) irrespective of application complexity - small,medium or large application.

            Depending on complexity of the application, project elapsed time varies from 3-8 months. We wont able to squeeze much in the project elapsed time. So to migrate 100+ applications, it will take few years to migrate everything to exadata when new Oracle version release will in horizon.

             

             

             

            a. What would be right/best strategy to move to the latest stable version Oracle for 100+ applications migration to exadata (before Oracle comes with new release)  ?

             

             

            b. How to stay current with Oracle technology for 100+ applications ?

            c. which techniques will help to squeeze the elapsed time of the project ?

             

             

             

            2. 11g vs 12c

             

            In current application landscape, =< 80% applications are small in size which means size of database is few GB and transactions are also not that much. Apple to Apple migration doesn't help as we will end up buy more exadata if schema consolidation is not done. Whereas if 12c is possible solution, then pdb is best way to consolidate the applications to exadata. So latest technology is very much lucrative but deterrent due to instability. If migration happens to 11g, there would be another initiative to migrate to 12c,will end up spending double the cost.

             

             

             

            What would be right approach - do migration twice or wait till 12c is stable?

             

             

             

            Thank You.

            • 3. Re: Migration to Exadata
              mrmessin

              1.

               

              Looking for a strategy where I would like to accomplish the migration in 30 calender days(say) irrespective of application complexity - small,medium or large application.

              Depending on complexity of the application, project elapsed time varies from 3-8 months. We wont able to squeeze much in the project elapsed time. So to migrate 100+ applications, it will take few years to migrate everything to exadata when new Oracle version release will in horizon.

               

              30 calendar days may be doable with a good solid plan, but without details to the applications, database environments (versions, database sizes, platforms currently on for each, etc) it is hard to say.  Also application servers and their work to goto new database also play a role and testing is something you will need to do and do it well, I would not migrate until I had tested and was sure that I was good to go, and test migration tasks as well, automate the tasks you can.

               

              a. What would be right/best strategy to move to the latest stable version Oracle for 100+ applications migration to exadata (before Oracle comes with new release)  ?

              Oracle will always come with new releases, however staying bleeding edge at the latest and greatest is something most organizations frown upon, Oracle will constantly change if you try and plan your environment that way it will be very difficult, the best advice I can give is to use known stable releases and upgrade as there is value to the next known stable release, most folks for example use the release 2 model,  always use the 2nd release, so stay at 10gR2 until 11gR2 is out and then start you migration plan, stay at 11gR2 until 12cR2 is out then start that migration plan, so that way you always stay in patch support, but you are not at the very latest.

               

              b. How to stay current with Oracle technology for 100+ applications ?


              MRM: Consolidation is a good strategy for this.  Can put multiple applications into the same database or like you are think 12c pluggable databases.  I have seen many applications share a database without any real significant issues.  Any Automation you can do will also help, many tasks in supporting a large number of databases can help save time and create consistency in the environment.  Be consistent in all setups (directory locations on servers for installations, scripts, etc) will help as well.  OEM 12c can help with this too.


              c. which techniques will help to squeeze the elapsed time of the project ?


              MRM: Plan, Plan, Plan......  Nothing shortens a project better then a solid documented plan.  This is the critical component of any project like this.  Small databases are easy, the more downtime you have the more flexibility you have.  When Downtime is less then it can get more complex.  Also if you are coming from 9i or 10g databases that will enter into your plan and will take a bit of time coming from 11gR2 will not.

               

               

              2. 11g vs 12c

               

              In current application landscape, =< 80% applications are small in size which means size of database is few GB and transactions are also not that much. Apple to Apple migration doesn't help as we will end up buy more exadata if schema consolidation is not done. Whereas if 12c is possible solution, then pdb is best way to consolidate the applications to exadata. So latest technology is very much lucrative but deterrent due to instability. If migration happens to 11g, there would be another initiative to migrate to 12c,will end up spending double the cost.

               

              MRM: If you in a position where multiple databases can be combined into a single database that could be an option on 11g.  As you mention you can consolidate using pluggable databases in 12c, remember this is an option to the database that requires additional purchase and could be a significant cost on an Exadata Rack so check out the cost of this option this may eliminate this as a real option as I have had situations where this sounded great until the business realized the added license cost.  I have done a a lot of testing with database 12c and thus far all has performed and appears to work very well, no production systems that I support are currently at 12c so I can not give you assurances you will be ok, but all testing I have done has been fine so far so test well.  As for the size of your databases I have consolidated multiple databases into a single database on Exadata and been just fine on 11gR2, just need to plan what will be consolidated where.  For every small application schema, just build new database on the exadata, setup my services the applications use or will use and export from the current environment and import into new Exadata Database this works very well and is very quick for small databases that I am consolidating esp. when I have some downtime that I can take on the small applications I could do several in a couple of hours if coming from 11gR2 this reduces the amount of testing you may need to do as well.  If the databases you need to combine are larger and can not fit in a proper downtime window I have been able to consolidate many databases to one using Golden Gate (Multiple sources to 1 target) (By the way I have done this with 2 large databases and 1 small database down into 1 database and performance improved significantly on Exadata for those applications).  Keep everything in sync then with a very small downtime change the applications to point to the Exadata Database, remove the Golden Gate and Old database.  You can run on Exadata 11.2 and 12c at the same time, make the Grid Infrastructure 12c, then have the database 11gR2 and 12c database binaries installed and then you can run both as with packaged applications you may not have support for 12c yet.  Remember in a migration you want to change as little as possible as big bang changes where you change platform, database version, etc all at the same time enters risk and with risk more testing should be done.

               

               

               

              Thank You.

              • 4. Re: Migration to Exadata
                Franck Pachot

                Hi,

                 

                 

                Is there any reason why you choose Exadata for mostly standalone OLTP applications ? Exadata X2-2 features will not help anything with that.

                 

                 

                In my opinion, the major point you have to address is that you have 400+ Oracle database. Multitenant will be an option in the future, but you will probably not take the risk to use that brand new feature on so many database. It's not stable enough yet. For example, in current version, if you loose the system tablespace on one PDB then you cannot restore it without a shutdown abort on whole CDB. Obviously you don't want to stop 100+ applications when you loose only one database. So wait at least next patchset for that.

                 

                 

                But 12c has a nice feature for having lot of instance on one server, which is multi-threading. It's a new feature, but less risky (not a major architecture change as the multitenancy is).

                 

                 

                So, 12c yes for multi-threading. Migrate your databases one by one (datapump or transportable tablespace). Try to put several applications in one database if possible without additional cost.

                But I don't see the point with Exadata, RAC and Multitentant options here.

                 

                 

                Regards,

                Franck.