1 Reply Latest reply: Mar 3, 2014 8:07 AM by mrmessin RSS

    Exadata Design

    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. How many Exadata Full RACKs would be required to buy so that all these databases workload would be accommodated?


      2. What is the best way to use these FULL RACK - meaning - should we break down the FULL RACK to Quarter RACK or to HALF RACK ? what is the methodology to follow to design this?


      3. Is there any impact of availability of usable storage if a FULL RACK is broken down to HALF or QUATER ? how much % waste of storage and why the waste?


      4. Due to cost, is it advisable to use Non-Exadata environment for development/Test databases?


      Thanks,

        • 1. Re: Exadata Design
          mrmessin

          1. How many Exadata Full RACKs would be required to buy so that all these databases workload would be accommodated?

          Without information on transaction activity, database size and many other factors here is no way to give a solid answer.  Have you had Oracle or another firm experienced with Exadata migrations evaluate the environment, this would be the best way to get an answer to this question.


          2. What is the best way to use these FULL RACK - meaning - should we break down the FULL RACK to Quarter RACK or to HALF RACK ? what is the methodology to follow to design this?

          Best way to use Exadata is to utilize the features of the environment, ie. Resource management and instance caging and instance placement.  By evaluating the databases and instances and placing them properly and then applying resource management and instance caging you can have a good level of control of resource utilization.  Breaking a Full rack down to 2 half racks or 1 half rack and 2 quarter racks while possible and has been done typically is done in cases where there is a firm requirements to divide the workload and based on SLAs promise not to share any resources between the environments and must dedicate hardware for those environments.


          3. Is there any impact of availability of usable storage if a FULL RACK is broken down to HALF or QUATER ? how much % waste of storage and why the waste?

          Yes, if you break the Racks apart physically you will loose some space utilization due to mirror required free in the configuration the amount that you would lose will depend on how many physical Racks you break down into.  In an Exadata configuration the tolerance is to be able to lose an entire cell without impacting availability.  The more you break down the rack the more cells have to be used to ensure that a lost storage cell can still happen therefore usable space is reduce by that amount. 


          4. Due to cost, is it advisable to use Non-Exadata environment for development/Test databases?

          A lot of organizations for development and QA environments use non-Exadata for these environments, but have a non-prod Exadata that is used for performance and release testing whenever possible.  Ok to have development non-exeadata and feature and QA testing, but to ensure that your releases are fully tested for Exadata it would be recommended to have an Exadata Environment to test in for a Pre-production testing environment.  I have seen this environment be one where the applications utilize the environment in a rotation so in cases where there are multiple racks in production they have a matching rack for non-production and the applications testing cycle rotates through for testing helping reduce costs that way.