So, what is the best upgrade path from a single instance of Oracle?
Oracle says moving to Exadata is as easy as 1-2-3!
If you are an existing Oracle customer, you have probably been getting a lot of pressure to move to Oracle’s shiny new toy, Exadata. You have probably been hearing that you can consolidate all of your databases onto a single Exadata system. But, it is not as easy as it seems!!!
The Oracle upgrade is harder than just moving data
If your existing applications are running on a single instance of Oracle (i.e. not on Real Application Clusters – aka RAC), then there is a lot more involved than simply moving your data. In order to get good performance on Oracle RAC (and Exadata is an Oracle RAC cluster with specialized I/O servers) you need to modify your database schemas and applications to make them RAC-aware.
DB2 pureScale makes it quick and easy to upgrade
DB2 pureScale on the other hand provides transparent application scalability, so you can quickly move your data and applications to DB2, and not have to worry about making changes to the schema and application to make them cluster aware.
The difference between RAC and DB2 pureScale
The reason that RAC requires cluster awareness and DB2 pureScale does not is due to the fundamental differences in their architectures. While both use a shared disk mechanism for scale out, that is the only real similarity. Oracle uses a distributed locking mechanism in RAC, while DB2 uses a centralized locking mechanism in pureScale.
Actual work involved to move to Exadata versus pureScale
Exadata | Tasks and Time Required | pureScale | ||
Equal | Move database and schema | Equal | ||
Days to weeks | Re-partition the database | Not Required | ||
Weeks to Months | Modify the application to partition data access | Not required | ||
Not Required | SQL Remediation | Couple of days | ||
Equal | Test and Tune | Equal | ||
Multiple weeks | Total Time | Days |
The data movement, test and tuning time will be similar, but the time to “fix” the application will be significantly longer with Oracle RAC and Exadata than with DB2 pureScale.
On Monday I will dig into the details of why you need to partition your database and application to make it RAC-aware.
On Monday I will dig into the details of why you need to partition your database and application to make it RAC-aware.
1 comment:
Could You explain in details why one when moving from Oracle to Oracle Exadate must:
- Re-partition the database
- Modify the application to partition data access
?
Actually,
why You just cann't move to Exadata DBM
and still use single-instance, not RAC ? ;)
Oleksandr
Post a Comment