Oracle 10G New Features Part I

Oracle10G Enhancements Blog Part I

These two blogs (I’m still getting used to that term) contain just a small subset of Oracle10G new features.  Consider this the first of many blogs on Oracle10G, so we’ll keep these first two at the 30,000-foot level.  In future blogs, we’ll take an in-depth look at each of the features described in these first two installments.

We are currently testing Oracle10G here at Giant Eagle.    We have several large, multiple-terabyte data warehouses.   Tables that contain billions of rows are quite common, with our largest having 5 billion rows (plus or minus a few million).   Tuning pages of SQL is a common practice here.  It is a challenging environment and we look forward to putting Oracle10G through its paces.  We have thoroughly tested numerous 10G features in our labs but have not converted any of our test database environments.  

In the future, I’ll provide you with all of the interesting information we learn from our first installation in our test environments to final production migration.  The DBA leading the charge, Jim Dojonovic, likes to “aggressively” test and implement new technologies.  Aggressive would be an understatement.   Jim is the perfect DBA for putting each new Oracle release through its paces.     Luckily, the developers that will be testing Oracle10G are strong technically and aren’t easily intimidated by new technologies (or Dojonovic for that matter).   It promises to be an interesting ride.

Grid Computing
Let's get started with a brief overview of Oracle Grid Computing. Oracle describes grid computing as "separate groups of users dynamically sharing computer resources across high-speed networks to meet changing computational needs."  Grid environments utilize farms of low-cost computer servers in a shared environment.  Oracle uses its Real Application Cluster technology (discussed below) along with the 10G database and 10G application server to create the shared computing infrastructure required to implement grid computing.  See figure below:

The optimal grid environment uses an interconnected server farm with each server containing one to four CPUs.  The servers are connected to a shared disk system using network-attached storage (NAS) or a storage area network (SAN) technologies as the connectivity mechanism.  High-speed network connectivity between the hardware servers themselves and from the hardware servers to the shared disk system allows the environment to be viewed as a single application architecture.

Real Application Cluster enhancements in Oracle10G allow hardware servers to be seamlessly added to an application requiring more resources for a particular time period.  Conversely, when hardware resource requirements are low, the extra computing horsepower can be easily freed and used by other applications in the grid.

I will be creating a separate blog about Giant Eagle’s initial foray into Oracle Grid computing.  We are currently testing the waters by implementing a low-end Oracle RAC environment using LINUX as the operating system running on Intel-based hardware platforms.    We are going to compare the initial price tag and ongoing administrative costs between LINUX-Intel/RAC and their UNIX “big iron” counterparts.  I seem to remember calling mainframes “big iron” just a few years ago.   I guess in a few more years, I’ll be comparing PDA-sized hardware platforms running the latest operating system of choice to their “big iron” LINUX counterparts.  I’m starting to think the only constant in this profession is change itself.  But that’s a good thing.

Automatic Storage Management (ASM)
Oracle10G provides its own disk storage management system.  Database administrators are no longer required to use hardware vendor or third-party (Veritas, EMC, etc) disk volume managers to provide striping and mirroring functionality.  ASM manages the raw disks within the Oracle database architecture.  Administrators are able to assign disks to disk groups, which can then be striped and/or mirrored to provide high performance and high availability.  During tablespace creation, the administrator assigns the tablespace datafile to a disk group.  This differs from previous Oracle releases which required that datafiles be assigned to the individual disks themselves.

Interestingly enough, Oracle’s default stripe size is one megabyte.  This differs from most disk storage management systems, which often utilize 32K or 64K stripe sizes.   Oracle found that one-megabyte stripes on disks provided a very high level of data transfer and best met the needs of disk intensive applications.  One can only assume that advancements in disk storage technology have allowed Oracle to access the data in one-megabyte chunks and not drive disk utilization to unacceptable levels.

Administrators provide disk mirroring by creating failure groups.  The DBA creates the appropriate number of failure groups to accommodate the data requiring disk fault tolerance.  ASM’s mirroring capability ranges from the mirroring of individual datafiles to entire disk arrays, providing administrators with a high level of flexibility when creating fault-tolerant disk subsystems. The data is duplicated on separate disks in one-megabyte mirror “chunks”.

Administrators can choose from the following mirroring options in ASM:

• External – no mirroring
• Normal – data is mirrored on two separate disks.  This is the default setting.
• High Redundancy – data is mirrored on there separate disks providing three-way mirroring capabilities.
    

ASM requires its own instance, which identifies the various disk groups and files during instance startup.  The ASM instance then mounts the disks under its control and creates an extent map, which is passed to the database instances.  ASM does not perform the I/O for the database instances; it is only used to manage the various disk groups under its control.  ASM is only activated when individual datafiles are created or dropped or disks are added and removed from the disk groups.  When new disks are added or removed from the disk group, ASM automatically rebalances the files contained in the disk group while the database is open and functioning.

Oracle Enterprise Manager (OEM) for Oracle10G and the Database Configuration Assisstant (DBCA) have been updated to allow administrators to configure and manage databases using ASM.

With Oracle data in double-digit terabytes, we are very interested in ASM and are starting a separate project to determine its viability. The ability to have the database pro-actively tune I/O on its own bears further investigation.

We have been actively scouring both Oracle’s internal websites and Googling the world-wide web to gather as much information as we can before we begin testing.   We have found that reviews vary widely, ranging from “this works great” to others that can be describes as “less than stellar”.  We continue to be cautiously optimistic.  Feel free to comment; I’d like to hear as many opinions I can before tying up a DBA’s precious time testing ASM.

Real Application Clusters (RAC)
One of RAC’s requirements is that clustering software be used to connect the hardware platforms together.  This underlying clustering software was purchased either from the hardware vendor or a third-party clustering software provider.   RAC is installed on top of the cluster environment and works in conjunction with the underlying clustering software to allow the application programs to view the multiple instances as a single entity.  

One of the problems using previous release of RAC was identifying exactly whose software it was causing the problem in the first place.  Was it the RAC software or was it the clustering software provided by the hardware or third party vendor?  Oracle10G solves this problem by providing its own clustering software called Integrated Clusterware.  Integrated Clusterware can now be used in place of the hardware or third-pary vendor’s clustering software. 

This will help prevent the age-old problem of multiple vendors pointing the blame at each other.  I’ve worked with some that were so good at passing the buck; you would have thought their suits were made of Teflon.

Flashback Database
How many times have database recoveries been performed because of incorrect changes made to database data?  A user deletes or updates “one too many rows” by mistake and the result is a time-consuming and error prone process to restore and recover the database to a point-in-time before the error occurred. 

Oracle Education states that point-in-time recoveries are responsible for the majority of DBA errors and the resulting unrecoverable databases.  When I was teaching Oracle as an Oracle-certified instructor, I ran my backup and recovery classes like a boot camp (one of the high-points of my career was when I won one of Oracle's Top Instructor Titles). Some of my students referred to my classes as “Foot Camp” because of my last name.    When my students were done; they may not have liked me but they certainly knew how to back up and recover a database.  I wasn’t going to lay awake nights thinking I was sending them on their way to future Oracle stardom without having all of the information they needed to safeguard the data stores they were charged with protecting.  

A common question in the Oracle DBA backup and recovery class was “why can’t I just roll the database back to remove unwanted changes instead of restoring the database from a backup and applying the redo logs to roll forward to a point-in-time before the error occurred?”    The question was invariably followed by “don’t you think that would be easier?”  The answer was always the same “yes, it would be easier, but the Oracle database doesn’t have that capability.”

Until Oracle10G that is…  Oracle10G’s Flashback Database feature provides a new tool in the DBA’s recovery toolbox.  Flashback Database allows the DBA to “roll back” a table, set of tables or the entire database to a previous point-in-time.

A flashback log is used to capture old versions of changed data blocks.  During Flashback execution, the Oracle database restores the old versions of the data blocks to their original locations which allows the database to be rolled back to a previous point-in-time.  Oracle provides the following example in its sales collateral to highlight how simple this new Flashback Database Feature is:

SQL> flashback database to ‘2:05 PM’;

Compare that to previous point-in-time recovery procedures, which required the entire database to be restored to a previous backup and then rolled forward using archived and online redo log files to replay the changes to a point-in-time before the error occurred.

Flashback Backup
Oracle10G also uses the flashback logs to provide the mechanism for its Flashback Backup feature.  Flashback Backup allows administrators to take a base level backup and then perform nightly incremental backups to roll the backup database forward to the current point-in-time. Since the changed blocks are recorded by the database, a full scan of all of the database blocks is no longer required to keep the backup database synchronized with its production counterpart. 

OK, that was a LOT of information.  If you have any questions on any of these features, please feel free to comment.   I would also like to encourage readers to respond with any hints, tips, tricks and techniques on administering these Oracle10G features.  That’s the great benefit of a blog!   I have more information on Oracle10G in other blogs on this site.