Database management by automation 

If you’re one of those database managers who thinks Oracle must pride itself on making its database overly complicated and difficult to manage, Oracle Database 10g will be a refreshing change. Simplifying everything from installation to tuning and troubleshooting to backup and recovery, the new release is packed with features designed to make the DBA’s job easier, either by completely automating tasks or by transferring control of important functions to the server. Gone are the days when you need a rocket scientist to run your database.

Automated features such as memory management, storage management, and self-diagnosis, as well as centralized configuration and patch management capabilities, allow DBAs to manage large, complex environments with very little meddling from day to day.

Oracle has also introduced significant improvements to the XML handling capabilities in Database 10g. Along with vast reductions in the size of server footprints required to traverse large DOMs comes XML schema evolution. Rather than discuss them here, I will fully explore 10g’s XML capabilities (as well as those of IBM DB2, Microsoft SQL Server 2000, and Sybase ASE) in an April 26 feature.

‘G’ Is for Grid

An Oracle 10g grid might be best described as a dynamic cluster. Application servers can be added to a cluster as needed, and the cluster resources can be rearranged to suit changing business needs. For example, say you have six servers doing OLTP (online transaction processing) and two more doing data warehousing, and you discover that the OLTP servers are getting bogged down at certain times of the day or week. By combining all eight servers in a grid, the two data warehouse servers could become part of the OLTP pool at peak times, and lend their resources to the mix.

The benefits of a 10g grid, including more flexible use of processing power and increased fault tolerance, are obvious, but configuring one is a complex process. Before you can set up a grid, you must have a clustered environment. Once you have your cluster built, you then define services and the machines on which the services will run. This is done by specifying a primary and secondary server for each service. You then define the level of resources (70 percent, for example) that a service can consume on any particular server.

I have not yet thoroughly tested 10g’s grid functionality (stay tuned), but some limitations are clear. For instance, I would like to see more automation in grid management, such as the ability to set up resource groups that redefine server roles dynamically at different times of the day or night. 

While grid management enables more efficient use of database clusters, a number of other new features make it much easier to manage large numbers of database servers. One of these is ECM (Enterprise Configuration Management), which is available both in Grid Control and as a single database control. ECM provides a centralized repository where you can store configuration policies. These policies can define anything from Oracle patches to operating system service packs to disk configurations. You could specify that all of your Windows 2000 Oracle servers should be on Windows Service Pack 3 and on a certain level of Oracle security patch. ECM will poll the servers every day and report back on the ones that are in violation of policy. You can then download the patches and push the updates out to the offending servers. ECM will also check the Oracle site for any security updates and download them.