TCO
| Oracle | Mysql |
| • Oracle Real Application Cluster – scalability on the same data copy
• Fully utilize all available CPU cores • Memory utilization greater then 40 GB per server • Throughput: 181 million queries returning 1.1 trillion rows in one hour • Large application server to db server ratio with large connection management capability |
• Availability in numbers scalability by duplication only
• CPU Core utilization restricted • Memory utilization has not been as high • Throughput: Difficult to say without having the proper tools |
| • Reduction of 2 FTE
• Reduction in severity outages • Index creations done online. • Average table change in Oracle takes less then 5 minutes and requires two resources. • Adding a column requires the running of a simple alter statement. • Data segmentation achieved through services i.e. different access paths to the same server. |
• No staff reduction
• 5 out 7 database severity related to current infrastructure • Index creations result in table locks. • Average table change in MySQL takes more than 4 hours and requires three resources. • Adding a column requires the building of an additional table and then a outage related cutover. • Data segmentation achieved through scenarios i.e. additional servers. |
| • Weekly and scheduled system refreshes accomplished through backup & recovery or transportable tablespaces. 1 FTE working 4 hours
• End-to-end automation w/fewer engineers • Highly qualified Oracle engineering resources available |
• Weekly and scheduled test system refreshes require a separate extract and load process for MySQL. 5 FTEs working 48 hours
• Difficult to introduce end-to-end automation • Difficult to find qualified MySQL engineers |
| • Standard tools provide detail analysis of system performance in real time
• Oracle is ahead in database instrumentation i.e. its timing model. • Automatic Workload Repository • Oracle Enterprise Manager • Automatic Database Diagnostic Monitor /w Repository • Active Session History • Automatic SQL Tuning • Automatic Memory Management • Session Level Tracing |
• Dedicated specialized team in place to provide manual monitoring with home grown tools.
• MySQL limited on it’s database instrumentation. • Enterprise Monitor • Explain Plans • Slow log |
| • SQL Plan Management
• Partitioning • Automatic SQL Tuning • Automatic Shared Memory Management • Compression • Database Resident Connection Pooling |
• MySQL 5.1 (not yet GA) Partitioning
• InnoDB (Oracle) Plug in • Fast Index Creation • Data Compression |
Imaging how many mysql servers you need?
© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.
相关文章 | Related posts:
- AUTOMATIC UNDO INTERNALS
- Oracle Database 11gR2 Upgrade Companion
- Oracle In-Memory Database Cache Oracle TimesTen In-Memory Database
- An Example NTP Client Configuration to use with Oracle Clusterware 11gR2
- [Repaste]The Underlying Technology of Facebook Messages
- Oracle vs. IBM DB2 9.5 LUW Performance and Scalability – Competitive Analysis
- Introduction to Oracle GoldenGate And GG Official Price
- Complete Checklist for Manual Upgrades to 11gR2
You describe one benefit of Oracle, the timing model, I guess that you mean the wait events. In my opinion this was before 11.2 the most interesting option of Oracle and one of the reasons why I recommended all professional customers to use Oracle because there was a straight forward method to analyze issues.
Today wait event analysis and timing model look to me like throwing the dice. I hope that this will work in 12 much better because we analysts need methods we can base upon.
I had several issues the last month to solve with 11.2 and I wasn’t able to solve none of them by straight forward analyis (using 10046 traces for example) but by trial and error and chance.
That’s a mess!