ROI of Oracle Database Management Packs

Noel Yuhanna
Forrester Research

ROI of Oracle Database Management Packs

all enterprises should focus on database manageability and automation to lower cost and improve DBA productivity. Databases tend to get created for a variety of reasons and never get destroyed. Over years the number of database instances tend to grow and cause performance problems or resource conflicts with other instances running on the same server. You are now able to manage more databases now than ever before but automation is needed to make this happen.

trends in database management 2007 – 2012
 – data volumes growing at a fast pace, doubles every 18-24 months
 – newer applicaitons like unstructured data and RFID are causing information to grow at faster and faster rates
 – 30% of large enterprises (> $1B revenue) have more than 1TB+ DB heading to petabytes
 – tools are helping with management of larger databases.
 – trends are centralized administration, automation, and virtualization
 – automation saves more money than outsourcing/offshoring of DBAs
 – consolidation of hardware is a trend with multiple database instances onto fewer servers part of this consolidation. It also allows for cross population of applications across department boundaries. This is a way of breaking down department barriers
 – more companies are treating database as an app that needs HA. More customers looking at clustering/RAC/grids, automated upgrade and automated troubleshooting. Databases are starting to be treated as 24×7 applicaitons so patching and upgrade plans need to be in place
 – need for higher performance and larger workloads. We are heading towards cache databases. In the next four to five years we will see databases residing in cache memory with a connection to another system that is the cache store residing on disk. Large training, manufacturing, and insurance verticals are starting to do this. About 30% corporations will have cache databases by 2012.
 – increased demand for information management and data sharing. There is a trend to get unstructured data into a database.Files do not give you good data management. Files will start to move into databases. 25% of companies are storing XML in databases. This is up from 7% five years ago. Things like videos, audio, and images will start to move into databases.

In 1997, DBAs spent most of their time installing, upgrades(35%), and patching or performance and troubleshooting (45%) backup and recovery (7%), load/unload (5%) security (3%), licensing and training (5%). These numbers hav shifted in 2007. Install, upgrade and patching (47%), performance runing (25%), backup/recovery (9%), load/unload (7%), security (7%), licensing and training (5%). Major database releases are coming out every 4 years.

Patching and upgrades will increase through 2009. After that it will decline and automation will solve this to make it less complex and take less time. Performance and tuning requirements are declining. The database is automating most of these functions and require less tuning. Security will continue to grow through 2012 and tail off after that. There are too many options available and they are not simple solutions. Self securing databases and integration outside the database will help after this. High availability and disaster recoverfy is substantially improving. This is getting simpler and it has become point and click for many instances.  Installation has gotten easier and will continue to get easier. It is the least challenging to most enterprises.  Backup and recovery  will get  more comples as the database sizes grow beyond a TB. It has also gotten easier for incremental but for complete backups will require some innovations.

The current database to DBA ration is currently 24:1. This has been a linear growth from 1990 where it was 10:1. This sould start to increase to about 30:1 in 2010 but the metric will shift to a data size per DBA and not instance per DBA. The ratio will be about 2TB:1 DBA in 2010.  This number is increasing because the database versions start reducing the tuning requirements and automate some of these functions. Automation and self managing are the keys to these improvements. Enterprises using higher degree of automation, tools, and Enterprise Manager can shift this ratio up by about 50%. The current ratio is 38:1 with OEM, tools, and automation. The data ratio incrases to about 4TB/DBA as well.

The focus on database management is shifting from managing individual databases to managing pools of databases and having all of the instances look the same. Thresholds on all of the instances are typically the same. It is easier to set these parameters the same on the majority of the databases. The exception is to have instances configured and tuned differently rather than have each one unique.

Automation helps minimize human efforts. Troubleshooting and diagnostics become proactive tools instead of reactive tools. Change management minimizes the steps and reduces problems or issues in production. centralized, policy driven databases make administration easier. On average automation improves DBA production by 20% or more. It minimizes human errors by 25% or more. Application performance is improved by 10% of more. CPU usage is reduced by 15% or more and defers hardware upgrades.

Key objectives for companies for using OEM
 – reduce cost and improve DBA productivity
 – reduce capital spending for servers and maintenance
 – make DBA perform more value added advisory and strategic services and less basic administration, integrate them more into the business and less into IT
 – wanted to centralize administration to monitor alerts so problems could be resolved quickly.
 – provide an HA platform architecture

sample company based on companies talked to
 – $1.5B in revenue
 – 120+ server running Linux, Unix and Windows
 – one major data center and two regional center
 – > 150 databases running 9i and 10g.
 – too many custom scripts written and monitored by DBAs. This consumed a large amount of the DBA’s time for development and troubleshooting
 
productivity savings – $509K in DBA labor over three years from using OEM with Diagnostic and Tuning pack.

Diagnostic pack gives performance analysis, hostoric and trend analysis, defined thresholds, sends and receives notification or alerts for critical issues. This helps diagnose issues quickly and focus resources quicker.

Tuning pack helps find poorly performing SQL caused by missing index, bad execution plans, poorly formed statements. It also helps to optimize indexes and materialized views.

findings
 – increased DBA productivity
 – reduction in system downtime due to alerts
 – 20% reduction in capital spending on servers
 100% ROI over a 3 years period and a 16 month payback period

recommendations
 – need for doing more with less
 – DBA automation can help everyone
 – new DBMS versions can improve overall manageability. Should consider upgrade 12-18 months after a new release
 – OEM can help and focus on centralized administration

Managing Identities with Server Chaining and SmartBadges

discussion from Chevron at OpenWorld

Roger Raj – Oracle
Roy DeRenzi – Chevron

project connects badge with pin code into the database and identity server. The technology behind this is how to integrate the AD server, Applicaiton Server, and JD Edwards, and other Oracle app technology.

Most applications web based. Global IDs and Desktop Ids
SmartBadge is a common access card. It contains a Java Chip that has the user credentials. It authenticates you locally without passing passwords over the network. It also has the ability to lock/destroy itself if multiple passwords fail. The idea is to authenticate against the card and the card connects to Kerberos without passing the password across the network.

Server chaining  has identities stored in one server and referred to by another server. User entries are not replicated. The request is redirected to the other auth server. Oracle currently supports redirection to LDAP and Active Directory. It is available in the OID 10.1.4 and higher versions

Chevron uses AD for user provisioning and auth/authz. Smart badges presents a user certificate and passes the cert across the network. Kerberos is used for all IT services and tickets are passed between applications.

The unique part of this solution is that the Oracle 10gAS SSO server is linked into the Kerberos server and the ticket exchange is done with the AD server. The user is logged in to the web env without having to authenticate into the service.

Four major OID servers. One in US is master, others are primary for the site but replicas of the master. Each of the primary OID servers locally sync with the local AD server.

The mapping of an AD entry to an OID entry was relatively easy. There were some challenges and did require some sophisticated search filters to restrict the search to ensure that all of the information was not brought across with a user search.

Issues with sync – network bandwith caused backlogs in updates. Group entry changes caused a flurry of transactions in a short window. The capacity of the AD server lookups was not adequate at peak loads.

Server chaining allowed the directory to be virtualized and entries did not need to be replicated between AD and OID. The OID was populated with a reference. This did put more of a load on the AD server for simple queries but not for large search queries.

When a change occurs in AD, a reference is pushed out to the OID server and not the actual data. This was challenging at first but worked better once it was deployed. By default chaining is disabled. When you enable it it allows for bind, compare, modify, and search LDAP functions. Nothing needs to be changed in AD to make this happen.

Summary, two different options, Server chaining or Directory Integration Process. One or both can be used. Chevron used server chaining to reduce replication and delays involved in walking through the AD change logs (which include login events).

A good example of where the DIP component is needed is where a portal function is required that needs more attributes in the LDAP server where AD can not or does not want to store these attributes. In this example, DIP is required and chaining can not be used.

This solution does require alternate solutions for lost badges, badges left at home and temporary access for the day, and charge backs to the departments for help desk support.