 | |||
|
|
||
| |||
| |||
| |
|
Home > Oracle Database / Applications News > Review: Oracle's 11g R2 database has some good and bad |
| |
|
|
|
|
| Oracle Database / Applications News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
While 11g doesn't contain the major architectural enhancements we saw in 10g, it did bring us a couple of important features including the Real Application testing and the SQL Performance Analyzer for real world testing with SQL tuning sets. It also included adaptive cursor sharing for deploying cursor sharing in systems that use bind variables. But with the arrival of 11g Release 2, there are some interesting features alongside a couple of clunkers I wish Oracle did not include. Among the more interesting features are:
And the clunkers include:
Let's take a closer look at these new features in 11g Release 2, and see why they are important to an Oracle professional. Column level data storage for Exadata This is clearly the most exciting new feature of all, a new data storage model where row storage is replaced by column storage. This is what in 11g release 2 Oracle calls column level data storage, and is available only on the million dollar Oracle Exadata storage units.
The internal storage of the data on the physical blocks is not supposed to matter, according to Codd and Date. But in the real world, the placement of the data on blocks is critical to performance. Oracle provides tools like sorted hash clusters to group related rows together along with row-sequencing that can improve the performance of SQL queries by placing all information on a single data block. But what about applications like DSS that want data stored with related columns on the data blocks? While traditional database systems want to group related data items together, data warehouse applications prefer to see related columns of data grouped together on the data blocks. Oracle guru Guy Harrison of Quest Software has a great illustration of rows storage vs. column storage on Oracle data blocks.
These column-oriented databases have another significant advantage, because they store adjacent column data. They can use compression algorithms to detect patterns in the columns and achieve very high rates of data compression. This packs more data onto each data block, making data warehouse queries run even faster. Oracle flash_cache The flash_cache feature in Release 2 is important because it directly leverages the new hardware capabilities of onboard flash memory. The flash cache resembles the assignment of high-use objects to the KEEP pool, but it's designed exclusively for flash, solid-state RAM memory. SSD for Oracle is six years old, a mature technology that will eventually replace platter-based disks, as well as change the whole landscape of Oracle data processing. See my book on Oracle Tuning with SSD for details. Unlike the KEEP pool however, which uses volatile RAM disk, the flash_ cache is used for tertiary storage on solid-state disk (SSD). On Oracle databases, flash memory SSD is now up to 600 times faster than platter disks. Oracle documentation suggests enabling the flash_cache when the data buffer advisor indicates Oracle wants more RAM, or when you are disk I/O bound and have spare CPU cycles. In other words, flash_cache is for systems not already running an SSD back end. Unlike the KEEP pool, the new flash_cache option requires setting two new flash_cache parameters: db_flash_cache_file=/dev/mountpoint and db_flash_cache_size=32G. In summary, the flash_cache is not much more than another method for segregating high-impact objects, and it's not clear how the flash_cache differs from traditional SSD flash systems where the SSD is mounted just like a disk. Oracle Omotion Omotion is a new online migration utility in 11g Release 2 that is used with RAC One Node to facilitate instance relocation in cases involving server failure. This is part of Oracle's acknowledgement of the server consolidation movement as part of the second age of mainframe computing. While details from Oracle are sketchy, it's safe to assume that Omotion performs instance relocation in a fashion similar to Savantis Systems with their DB-Switch invention. In the days of old, we did instance relocation with a SAN environment using the following five steps: 1. The Oracle instance when the server crashes; 2. Do a dead connection probe (DCD) which detects the outage and the un-mount of the SAN data file systems from the source server (if it's awake); 3. Mount the database files onto the failover server using SAN; 4. Restart the instance on the new server, using a pre-loaded init.ora file; 5. Use a failover routing mechanism like transparent application failover (TAF) to redirect transactions accessing the database (VIP) to the new server. A typical timeframe for Oracle instance relocation is less than 20 seconds. This is not true continuous availability, but it is certainly better than a catastrophic unplanned outage. The Oracle instance relocation scheme makes sense because it uses far less resources than Data Guard (which requires a standby server) and Streams failover. With instance relocation, a single standby server could serve for hundreds of instances. RAC One Node Oracle RAC traditionally is used in a multi-node architecture where many separate instances of RAC reside on separate servers. This protects against unplanned server outages because transparent application failover will redirect to another server. It also aids the RAC goal of scalability when a new server instance is generated into the RAC cluster. But in Oracle 11g Release 2 there is a new feature called "RAC One Node" that claims to be multiple instances of RAC running on a single node in a cluster. It has a fast "instance relocation" feature for cases of catastrophic server failure. Oracle now embraces the IT industry's concept of "instance consolidation," a movement to collect together instances from the bad old days of client-server computing where we had the concept of one instance/one server architecture. This is a back-to-the-future approach, a movement back to the monolithic server environments of the 1980's with all of their benefits including:
That's all the good stuff. Let's take a look at the not so good stuff in 11g Release 2. These features might even be considered dangerous. Oracle Instance Caging Due to falling prices on large servers with 32- and 64-bit CPU's, the majority of IT shops across the country are undertaking server consolidation as a way to more easily manage servers and share resources. Similar to "fencing" tools from the 1980's mainframes, Oracle's instance caging is like CPU fencing, dedicating processors to specific instances. This is a method to prevent one instance from "hogging" the processors. Oracle instance caging is neither new nor useful, and it appears to be identical in function to these approaches for dedicating CPU processors to Oracle instance processes such as:
Oracle instance caging uses an initialization parameter to limit the number of CPUs an instance can use simultaneously. While CPU fencing tools have been around for decades, tools such as those from VMware also allow for CPU and RAM fencing. However, fencing with instance caching can be wasteful and it's quite rare for one Oracle instance to "hog" an entire bank of processors. Remember, the goal of server consolidation is to facilitate sharing of processor resources, not hinder it with instance caging. Therefore, I do not recommend deploying instance caging without careful testing and justification. ASM Cluster Filesystem (ACFS) There is a serious vulnerability for Oracle RAC databases noted in the Oracle 11g Release 2 RAC documentation. This note indicates a scenario where it's possible for an entire RAC cluster to fail. This exposure is only for RAC databases that are using Automatic Storage Management (ASM). When using RAC, Oracle has announced that the key clusterware files, the OCR and Votedisks can now be stored in Oracle Automated Storage Management (ASM). However, research by expert DBA's indicate that it may well be premature to use this feature. According to Oracle's documentation, if a single node is lost, then the entire cluster may go down if that node happens to be the master node. The entire cluster only fails if the Oracle ASM instance on the OCR master node fails. If the majority of the OCR locations are in Oracle ASM and if there is an OCR read or write access, then the crsd stops and the node becomes inoperative. In order to identify the OCR master node, search the crsd.log file for the line -- "I AM THE NEW OCR MASTER" -- with the most recent time stamp. Oracle has announced that new installations of 11g Release 2 (as opposed to upgrades) will not allow the installation of the OCR and Votedisks on RAW. So the best solution at this time is to install these files on a shared, non-ASM file system such as OCFS2. Clusterware upgraded to 11g Release 2 may still be on RAW.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
 |  |  | |  | |  | |  | |  | |  | |  | |  | |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
