Database Management Best Practices and Technology

As adoption of Service Oriented Architectures increase, it is highly unlikely the majority of IT organizations will only have one vendor’s database to manage.  In reports from Industry Analysts, it has been reported that a majority of IT organizations already have at least two or more database vendors they are supporting. In my travels, meetings and industry conferences, I’ve found that many of you have deployed a sizable number of relational databases instances, representing different database vendors, to support current and planned business application needs.

With each new database release you have deployed, you’ve probably encountered greater management complexity than with the previous release.  This, along with the increasing volumes being placed into your databases by the business, you or your IT organization may have been faced with a need to increase headcount, outsource some management tasks or look at adding technology to help with this complexity. For some that choose technology, the process and decision used in selection may now be actually increasing the cost of management instead of reducing it.

Recently, I have had individuals in IT detail how they are burdened by tools purchased that are not helping resolve the problems for which they were purchased to help solve. Some can’t be used across different database releases from the same vendor or others can’t be used to manage multiple database vendors.  Few if any seem to integrate with other IT products for an enterprise view of infrastructure performance management.  I have even met some DBAs that made specific comments that the problem of response time and resolving customers performance issues is someone else’s problem to solve.  They manage a specific database and they have what they need to manage performance on that specific database.

The silo’d approach to database management certainly does not support the growing desire of executive management to implement centralized management and best practices across the enterprise which assists in cost reduction as well as regulatory compliance. Nor does it support the need to identify and resolve customer’s performance issues faster. Furthermore, if you look across an enterprise at all those individual investments, they add up in cost, overlap in functionality, and many can not scale or integrate to provide a full view of infrastructure performance interaction. With the “my” management mentality, systems and networks become overburdened as the company grows, requiring even more hardware investment.  This, in addition to licensing costs can artificially fuel the need to add more resources.

In contrast, IT organizations faced similar challenges for network management, which led to Network Operation Centers (NOCs) and  centralized management, leveraging multi-vendor management technology. One central network with network administrators employing centralized management with one view encompassing all the various vendors and protocols. So this may lead one to ask, if networks can be managed in this manner, why not databases?

Looking back, what we find are that databases were typically deployed when new applications were introduced.  Application teams managed independently whether terminal/mainframe or client/server architectures. As these deployments increased, more management resources were needed.  Instead of adding DBAs in the individual application teams, management sought ways to increase coverage, so for some, DBAs became organized by database vendor.

Is your company one of those in which database management by vendor is prevalent? Could availability and efficiency be improved by managing databases functionally instead of by vendor? To explain my point, one might ask why couldn’t any DBA add or drop a table of any vendors’ database instead of having a SQL Server DBA to perform it for SQL Server databases, an Oracle DBA for Oracle database, and a DB2 DBA for DB2 databases.

There has been significant advancements in technology to support common database management across vendors and platforms. Similar to what was already done for network management; companies like yours are now designing and initiating projects to centralize database management.  In addition, they are also integrating database management with other areas of IT for enterprise performance management.  The driving force behind these initiatives are the competitive pressures to meet customer ‘data-on-demand’ requirements, to  meet SLA’s and improve availability.

A major factor for a project of this undertaking is a firm understanding of the business requirements.  This includes a review of existing systems as well as:

• Multi-vendor management capabilities 
• Functional scalability for very large databases and the enterprise
• Integration for infrastructure coverage, correlation and problem response resolution 

To manage complexity, there has to be the capability to get to the core of the problem.  Understanding where applications are hitting the various tiers of the infrastructure, such as across the network, to systems and storage, to the database, all the way up through the application server and application tiers. Consolidating operations and enabling best practices towards automation enables increased business capabilities as well as controlling costs as business increases.

SOA is here, how well are you prepared for its management encompassing your databases?