Comparative Management Cost Study: Oracle 10g IBM … · Comparative Management Cost Study: Oracle...

Comparative Management Cost

Study: Oracle Database 10g

Release 2 and IBM DB2

Universal Database 9.1

December 20, 2006

Edison Group, Inc. / Comparative Management Cost Study: Oracle Database 10g Release 2 and IBM DB2 Universal Database 9.1

Printed in the United States of America.

Copyright © 2006 Edison Group, Inc. New York. Edison Group offers no warranty either expressed or implied on the information contained herein and shall be held harmless for errors resulting from its use.

All products are trademarks of their respective owners.

First Publication: December 2006

Produced by: Steve Mintz, Senior Analyst; Barry Cohen, Lead Analyst; Craig Norris, Editor


Table of Contents

Executive Summary ..................................................................................................................... 1

About this Report......................................................................................................................... 3 WHO SHOULD READ THIS REPORT? ..........................................................................................................3 METHODOLOGY OVERVIEW.......................................................................................................................3 CONTENTS OF THIS REPORT .......................................................................................................................4

Rationale Behind This Comparison ......................................................................................... 5 WHAT’S NEW?............................................................................................................................................5

The Methodology Defined......................................................................................................... 6 WORKLOAD WEIGHTING ...........................................................................................................................9 TEST ADMINISTRATION WORKLOAD.......................................................................................................10

Test Results ................................................................................................................................. 11 COMPARATIVE MANAGEMENT COST SAVINGS.......................................................................................11 WORKLOAD CATEGORY TEST RESULTS SYNOPSIS...................................................................................12

INSTALL DB/SOFTWARE/OUT‐OF‐THE‐BOX SETUP (RESULTS SYNOPSIS)...........................................12 QUALITATIVE ANALYSIS..................................................................................................................12

DAY‐TO‐DAY DATABASE ADMINISTRATION (RESULTS SYNOPSIS) ....................................................13 QUALITATIVE ANALYSIS..................................................................................................................13

BACKUP AND RECOVERY (RESULTS SYNOPSIS) ...................................................................................14 QUALITATIVE ANALYSIS..................................................................................................................14

PERFORMANCE TUNING (RESULTS SYNOPSIS) ....................................................................................15 QUALITATIVE ANALYSIS..................................................................................................................15

Conclusion................................................................................................................................... 18

Appendix I ‐ Test Platform Details......................................................................................... 19

Appendix II ‐ Architectural and Terminology Discrepancies Requiring Clarification20

Appendix III ‐ Detailed Test Results ..................................................................................... 21

Appendix IV – Complexity Calculation Formula ................................................................ 23

Appendix V ‐ Detailed Task Descriptions ............................................................................ 24 INSTALLATION AND SIMPLE “OUT‐OF‐BOX” SETUP ...............................................................................24

TASK 1: INSTALL DATABASE AND MANAGEMENT SOFTWARE, AND CREATE STARTER DATABASE 24 TASK 2: CREATE ADDITIONAL DATABASE SERVER/INSTANCE ........................................................25 TASK 3: SET UP PRO‐ACTIVE MONITORING FOR PERFORMANCE AND SPACE UTILIZATION............27 INSTALLATION AND SIMPLE “OUT‐OF‐BOX” SETUP TASKS RESULTS SUMMARY ..........................27

DAY‐TO‐DAY DATABASE ADMINISTRATION...........................................................................................28 TASK 4: CREATE USER, ASSIGN ROLES/PRIVILEGES..........................................................................28 TASK 5: CREATE SCHEMA ................................................................................................................29


TASK 6: CREATE TABLESPACE/FILE GROUP......................................................................................29 TASK 7: ADD SPACE TO TABLESPACE...............................................................................................30 TASK 8: CREATE TABLE ....................................................................................................................30 TASK 9: CREATE INDEX ....................................................................................................................31 TASK 10: CREATE PARTITIONED TABLE ...........................................................................................32 TASK 11: CREATE INDEX ON PARTITIONED TABLE .........................................................................32 TASK 12: RECLAIM LOST SPACE DUE TO FRAGMENTED DATA.........................................................33 TASK 13: LOAD DATA FROM A TEXT FILE.........................................................................................34

DAY‐TO‐DAY DATABASE ADMINISTRATION TASKS RESULTS SUMMARY ..........................................34 BACKUP & RECOVERY ..............................................................................................................................35

TASK 14: CONFIGURE AND PERFORM FULL DATABASE ONLINE BACKUP .......................................35 TASK 15: RECOVER DROPPED TABLE................................................................................................36 TASK 16: RECOVER DATA FILE .........................................................................................................37 TASK 17: RECOVER FROM ERRONEOUS TRANSACTION ...................................................................37

BACKUP & RECOVERY TASK SUMMARY ..............................................................................................38 PERFORMANCE DIAGNOSTICS & TUNING TASKS ....................................................................................38

TASK 18: DIAGNOSE PERFORMANCE PROBLEM ...............................................................................38 TASK 19: FIX PERFORMANCE PROBLEM (TUNE SQL STATEMENT) ..................................................39 TASK 20: TUNE MEMORY .................................................................................................................39

PERFORMANCE TUNING TASK SUMMARY...........................................................................................40 Appendix VI – Glossary of Task Areas/Tasks...................................................................... 41

Comparative Management Cost Study: Oracle Database 10g Release 2 and IBM DB2 Universal Database 9.1

Executive Summary

This report is the latest in a series of Comparative Management Cost Studies (CMCS) comparing Oracle Database 10g with database management systems offered by other leading enterprise software vendors. Earlier studies1 compared Oracle Database 10g with Microsoft SQL Server 2005 and IBM DB2 Universal Database (UDB) 8.2. In the last few months, IBM released its latest major production release of database product, DB2 UDB 9.1 (previously called “Viper”). This study compares IBM DB2 UDB 9.1 with Oracle Database 10g Release 2.

Following the same approach taken in the earlier studies, Edison Group set up a laboratory environment to analyze a suite of standard RDBMS administrative tasks, and measured their respective management efficiency (time taken to complete tasks) and their complexity based on a proprietary manageability metric. Using the management efficiency results, Edison Group calculated the annual savings for businesses due to the enhanced DBA productivity that would result from using the product with superior manageability. Based on feedback from our clientele using products from leading database vendors, we broadened the scope of the tasks in the study to include some common data warehouse specific administrative tasks. As a result, our research is now applicable to organizations deploying Data Warehouse as well as On‐Line Transaction Processing databases.

The study results show that while both the vendor products have features to help average DBA perform everyday administrative tasks, Oracle Database 10g Release 2 holds substantial advantage over IBM DB2 Universal Database 9.1. Our detailed analysis reveals that:

1. Database administrators (DBAs) can perform typical administrative functions in 38% less time when using Oracle Database 10g Release 2 compared to IBM DB2 UDB 9.1.

2. Oracle Database 10g Release 2 requires 35% fewer steps for the same set of standard RDBMS tasks than IBM DB2 UDB 9.1 using Edison’s metric for complexity assessment.

3. Benefiting from increased DBA productivity due to lower complexity and higher efficiency cited above, businesses could save up to $31,654 per year per DBA by using Oracle Database 10g Release 2 rather than IBM DB2 UDB 9.1.

1 These studies can be obtained from Edison Group, Inc. website at http://www.theedison.com. The documents can be found in the document library (registration required) at http://www.theedison.com/index.php/c51

Edison Group, Inc, 1 December 1, 2006

http://www.theedison.com/

http://www.theedison.com/index.php/c51


The main areas of difference between the two products were:

• Performance Diagnostics and Tuning: In this category, Oracle Database 10g Release 2 demonstrated a significant 76% savings in time and 50% difference in complexity. Especially in the area of SQL tuning, DB2 is still significantly more complex and time consuming. This manual effort more than offsets the other improvements in performance tuning in DB2.

• Day‐to‐Day Administration: In this category Oracle Database 10g Release 2 provided 44% time savings and 31% lower complexity over IBM DB2 9.1. The main contributor to this difference was the need to take the DB2 database offline for space defragmentation and Oracle’s superior capabilities in handling space fragmentation.

• Backup & Recovery: In the case of backup and recovery tasks, Oracle Database 10g Release 2 shows architectural and functional capabilities beyond those offered by DB2 UDB. Oracle’s unique “flashback technology” provides the ability to recover from human errors — the number‐one cause of unplanned system downtime. Oracle Database 10g Release 2 took 50% less time and 62% fewer steps than IBM DB2 UDB 9.1 in backup and recovery tasks.

• Installation and Out‐of‐the‐Box Setup: IBM DB2 installs fewer components out of the box, and thus requires 78% less installation time than Oracle Database 10g Release 2. Under the structure of this study, the add‐on DB2 products were not installed, skewing the results in favor of DB2. Since installation and initial setup has a low weighting factor, the substantial time advantage as measured is relatively insignificant in total administrative cost effect.

• Oracle Database’s management console ‐ Database Control – is the sole management tool for managing Oracle Database. It can be accessed via a web browser from any authorized location. This was a key advantage over IBM DB2 9.1, which has several management consoles, each requiring a separate client installation on every machine to be used for database administration.

There are numerous ways to interpret the significance of these savings. That significance depends on the size of the organizations involved as well as the relative importance attached to higher productivity in these organizations and the need for superior performance for specific tasks and classes of tasks.

What is clear is that both IBM and Oracle have provided their customers with efficient tools for day‐to‐day management of their respective database systems. But when analyzing the cost of day‐to‐day operations, Oracle Database 10g Release 2 can provide organizations with 38% annual DBA‐related cost savings.



About this Report

This report documents the results of a head‐to‐head product comparison examining the database administration functions of Oracle Database 10g Release 2 and IBM DB2 UDB 9.1. The study focuses on the use of human resources. Its objective is to reveal the comparative database administration costs of operating the two products.

Common database management tasks were performed in Oracle Database 10g Release 2 and IBM DB2 UDB 9.1 and compared for their ease of use. For both products, their native management tools — Oracle Enterprise Manager 10g Database Control for Oracle and the IBM provided tools: Control Center, Command Center, Health Monitor / Health Center, etc. for DB2 UDB 9.1 — were used in the study. The study measures (in quantitative and qualitative terms) the relative manageability of Oracle Database 10g Release 2 and IBM DB2 UDB 9.1, and projects the expected savings in management cost over the course of a year due to the administrative efficiency of one product over the other.

Who Should Read this Report?

This report will be useful for corporate decision makers, technical end users (DBAs/System Administrators), and independent software vendors (ISVs). It will also be of particular interest to small and medium businesses with critical database requirements but with limited IT resources to manage them.

Methodology Overview

This Comparative Management Cost Study (CMCS), conducted by Edison Group, compares the ease of use or manageability of Oracle Database 10g Release 2 and IBM DB2 UDB 9.1 and assesses their relative cost of management to a business. It represents a product‐specific application of a proprietary, general‐purpose methodology developed by Edison Group for making product management cost comparisons. The result is a summary definition of the annual costs that will be incurred by any corporate IT department or ISV running either of these two products.

In the course of this study, Oracle Database 10g Release 2 and IBM DB2 UDB 9.1 were compared against a set of methodology metrics in order to determine which of the two products is easier to operate for businesses with real‐world database management requirements. The Test Administration Workload Task Areas that we used to perform this study fall into the following four categories:

1. Database Setup and Configuration

2. Day‐to‐Day Database Administration

3. Backup and Recovery



4. Performance Diagnostics and Tuning

Task categories were divided into individual tasks that logically map into their respective area. To determine the overall manageability of a given task for a given product, each task was broken down into steps to assess the complexity and usability involved. Each task was then measured for time and number of steps required for successful completion.

Next, tasks were weighted against workload weighting constants. These weightings were used to determine the relative importance of a given task as measured against all of the tasks required to manage the entire product administration lifecycle. In other words, simple tasks that occur relatively infrequently were given a proportionately lower weighting than complex tasks that occur on a regular basis.

Finally, the results were tallied and the CMCS metrics for each product were substituted into manageability cost formulas to determine the projected human resources cost of operating both products, based on median DBA salary.

Contents of this Report

The following is a brief overview of the sections contained in this document, to provide for quick reference.

• Rationale Behind this Report – a discussion of the reasons Edison Group engaged in this research.

• The Methodology Defined – this section explains the criteria used in the study, including how we weighted and calculated the results and a description of the workloads evaluated.

• Test Results – presents the results of each set of tests, providing summary findings and a discussion of their relevance to business operations.

• Conclusion – summarizes our findings.

• Appendices – provide details on the test platform, clarification of architectural and terminology issues, the detailed test results, a discussion of our Complexity Calculation Formula, a detailed list of the actual steps performed and their individual timings, and a glossary of task areas.



Rationale Behind This Comparison

Over the last several years, Edison Group has conducted management costs research on key vendors in the RDBMS industry. Edison Group reviewed the methodology used in the development of the previous studies, modifying it to account for recommended practices for IBM DB2 9.1. To this end, Edison Group also consulted Oracle and DB2 database administrators and engineers for independent validation of the study methodology.

Through this process, Edison Group identified a series of day‐to‐day tasks performed by the average Database Administrator (DBA). A simple laboratory environment was created, consisting of a single server onto which the respective database management systems were installed and configured.

Once this was done, Edison Groupʹs analysts performed and documented the evaluations contained in this paper. The conclusions in this report are our own, based upon the research we performed.

IBM DB2 and Oracle Database systems support the needs of a wide variety of customer applications ranging from small through medium to large businesses, which need the capabilities of a state‐of‐the‐art database management system. This past decade has seen the growth of these database systems in capability, functionality, manageability, and scalability.

The main thrust of this paper is to independently test these products on a point‐by‐point basis, in order to arrive at a set of quantitative and qualitative manageability metrics.

What’s New?

With the latest release of Database 10g Release 2, Oracle is offering a state‐of‐the‐art RDBMS that promises customers all of the industrial‐strength features and functions found in past Oracle products, with an ease of maintenance that Oracle claims will meet or exceed that of its leading rivals. With Release 2, Oracle has improved the Enterprise Manager user interface, especially in the areas of data loading, backup and recovery and the day‐to‐day administrative tasks covered in this study. According to Oracle, Release 2 of its flagship database product, comes pre‐configured and instrumented in a manner that is simpler to install, run, and maintain than those of its competitors.

IBM has recently released IBM DB2 UDB 9.1. This updated version to IBM’s database management system adds an array of features across the spectrum of product capabilities. Changes and enhancements that are relevant to the current study include adaptive, self‐tuning memory allocation, automated storage management, and storage optimization – that is, data compression to reduce storage requirements. In addition, autonomic performance tuning features that were once optional are now turned on by default.



The Methodology Defined

For purposes of this study, the methodology is defined as a product manageability cost evaluation process whereby the two products in question are compared against a set of task‐oriented objective and subjective metrics in order to derive an accurate set of analytical results. The outcome of this study determines the Comparative Management Cost (CMC) incurred by managing and operating either of these products in a production environment. The methodology employed to conduct this comparison consists of the following elements:

1. Workload Weighting: The workload weighting is a set of constants that define the relative importance of a single task area in the workload, based on frequency of execution and measured against the entire set of task areas that compose this study.

2. The Study: The study is the baseline checklist of standard database administration tasks routinely performed, which are quantitatively and qualitatively compared in order to objectively determine, on a task‐by‐task basis, which product is superior. This is measured primarily in terms of ease of administration and secondarily (for certain tasks only) in terms of system speed of execution — the wall clock time it takes for the system in question to complete a job once it has been submitted by a DBA. The function of this study is to apply a set of quantitative metrics, developed by Edison Group, to a list of tasks typically regarded as qualitative in nature, in order to derive a meaningful set of CMCS statistics that can reveal the real difference in management costs for the two products in question.

3. Tasks: A task is defined as a complete logical activity, composed of one or more steps, all of which effect a significant alteration on the state of the database that accomplishes a specific work goal. Each task is measured for time and complexity. Time and complexity, as measured in the study, are defined as follows:

Time: Defined as the amount of time it takes to perform a given task. For certain (asynchronous) tasks, when a job can be run in the background so that the DBA can use the time for accomplishing other tasks, time is measured strictly in terms of the time it takes the DBA to perform the steps to configure, initiate, and submit a given task.

For other (synchronous) tasks in the study that demand the DBA’s full attention and prevent the accomplishment of other tasks (as in performing a hot recovery operation on a live database), time is measured to include both the time it takes for a DBA to configure/execute the task in question as well as the time it takes the system to complete the task. All time metrics are measured in wall clock time and are rounded up to the nearest ten seconds.

Complexity: For the purposes of this study, complexity is measured using a proprietary metric devised by Edison Group. It is defined as the number of



system‐affecting steps it takes to complete a given task, where a step is defined as a task component that effects a change of state to the database. Creating a tablespace or a view is an example of a step.

Because not all steps have the same inherent complexity, each step is further broken down into increments to account for the difference. An increment is a decision point that the user must make to complete a step. Increments are technically defined as a part of a step that will have a measurable effect on the state or execution path of that step in the task process, but which in and of itself does not effect a change upon the underlying database state until the step being executed is complete. For example, selecting Basic vs. Advanced Install and clicking the Next button in the Oracle installation wizard screen is an increment and not a step, which effects an incremental change on the flow of the database installation process but does not change the state of the database.

Complexity is then measured in terms of number of steps, but taking into account the following factors:

• The number of increments it takes to complete each step.

• Whether or not instrumentation for a given step is GUI‐based or requires the use of a command line/scripting interface.

• Whether or not the task requires a context switch between multiple interfaces in order to be completed. If a context switch exists, then additional steps will be added to the total step count for a given task.

The above factors affect the complexity calculation as follows:

• The primary measure is steps. If a step has many increments, it is considered several steps. The metric allows each step 5 increments, and thereafter we add steps for each additional 5 increments rounded up. So if a step has between 0–5 increments, it remains unchanged; if it has between 6–10 increments, it is increased by 1; between 11–15 increments, it is increased by 2; and so on. We decided to do this because, while increments are secondary to steps in determining complexity, they do modify the relative complexity of a given step in the course of completing a task. In other words, steps with a low number of increments are simple, and steps with a high number of increments are complex.

• The other modifiers (instrumentation and context switching) occur very infrequently in the products under review, but they were significant enough a factor that we needed to account for them in some meaningful way in order to generate a measure of complexity that accurately reflects our experience of using the two products.



Regarding instrumentation, if an operation could be executed entirely within a GUI interface, then the complexity/step value for that task would remain unmodified. If, on the other hand, a step required the use of a command line interface, this would increase the step count. For a simple single‐line command operation, the step count was increased by 1, whereas if the operation required the user to write a script, the step value was increased by 2 or more, depending on how much work was required to write the script in question.

Lastly, we come to the matter of context switching. If a context switch was encountered during the course of completing a given task, then 2 or more steps were added to the step count for that task. The possible addition of more than 2 steps was allowed for as a judgment call on the part of the analyst performing the task under consideration. The reason tasks containing context switches were penalized is that we regard the complexity of understanding the dependencies of relating and performing a single operation in two different environments in order to complete a single task as inherently more complex than performing a similarly complex task in a well‐integrated environment, where all the operations can be accomplished in one place.

The workload for this CMCS was reduced to the basic set of atomic maintenance operations that effectively fulfill all fundamental database administration procedures. The reasoning behind this approach is that enterprise‐class database configuration and administration is a non‐trivial matter; we therefore set out to develop a (relatively) simple yet comprehensive evaluation process, establishing a CMCS methodology benchmark that we feel is realistic in its technical assessment, yet accessible to the large audience of non‐technical decision makers who will read this document.

The evaluation of each task in the study workload was executed by measuring the time that a typical DBA spends in a given workload task area using the methodology metrics. We counted compute time for utility tasks only in situations where the DBA is expected to “baby‐sit,” such as instance recovery. This was the process we used in order to determine whether Oracle Database 10g Release 2 is less expensive to operate than IBM DB2 UDB 9.1.

• Licensing and Packaging: License costs were not considered in this study. There are several reasons for this choice, the most important of which is that licensing costs are usually the least expensive factor in cost of ownership. For example, the management costs analyzed here are usually of greater significance.

The entire evaluation process was performed based upon the installation of these products from the product installation disk. In the case of Oracle Database 10g, this included installation of management tools and other features that require additional disks from IBM. The difference in packaging is the result of marketing and product development decisions made by the two vendors.



This CMCS methodology has been derived from the following sources:

• The initial baseline workload task list for this paper was based upon research performed by Oracle. This initial baseline was then modified by Edison Group and certain tasks were adjusted in order to compare both products on equal terms.

• The workload task weighting was based on a survey published by Database Trends.2

• The baseline workload task list was checked for process consistency by Edison Group analysts against the Oracle Database 10g Administrators Guide.

• The baseline workload weighting and task list was further checked for consistency against IBM DB2 UDB Administration Guide: Implementation, IBM DB2 UDB Guide: Performance, IBM DB2 UDB Utilities Guide and Reference.

• Independent professional Oracle and DB2 database administrators and engineers were consulted as anonymous third‐party verifiers of the methodology and workload tasks employed in the course of conducting this CMCS.

Workload Weighting

To view these results in terms of management costs, we recognized that the tasks in the workload have different levels of importance and complexity, and are performed at differing levels of frequency. For example, tuning a database or creating a new table is performed more frequently than creating a new database. In order to accurately account for this, we have used a weighted average of the workload test areas to measure each set of tasks according to their typical degree of use. Here are the weightings used for this CMCS:

Database Administration Workload Weighting Setup and Configuration 5% Day-to-Day Administration 34% Backup & Recovery 14% Performance Tuning 26% Other 21%

Total 100%

The Database Workload Weighting metrics in the table above was derived from an article published in Database Trends and Applications Online in 2002. The “Other” category represents tasks that were not included in the study, such as software license maintenance and database upgrades. We left this category in the weighting in order to acknowledge in the Comparative Management Costs (CMC) calculations that such activities are a necessary part of day‐to‐day business. Furthermore, in performing the CMC calculations for this analysis, it was presumed that both products required the same degree of “Other” tasks so

2 http://databasetrends.com/


http://databasetrends.com/


as not to favor one product over the other. This approach renders the 21% of the workload weighting that falls into the “Other” category irrelevant to the outcome of this study.

Test Administration Workload

• Database Setup and Configuration (Workload Task Category)

1. Install database/software/out‐of‐box setup

2. Create new database/server instance

3. Set up proactive monitoring

• Day‐to‐Day Database Administration (Workload Task Category)

4. Create user with roles, privileges

5. Create schema

6. Create tablespace

7. Add space to tablespace

8. Create table

9. Create index

10. Create partitioned table

11. Create index on a partitioned table

12. Reclaim wasted space due to fragmented data

13. Load data from text file

• Backup and Recovery Tasks (Workload Task Category)

14. Configure and perform full backup

15. Recover dropped table

16. Recover data file

17. Recover from erroneous transaction

• Performance Diagnostics and Tuning Tasks (Workload Task Category)

18. Diagnose performance problem

19. Fix performance problem (tune resource‐intensive SQL)

20. Tune instance memory



Test Results3

The table below presents the cumulative test results of the study. As can be seen, Oracle Database 10g Release 2 has a 28% time advantage and a 47% complexity advantage over IBM DB2 9.1. After adjusting the tasks for their prominence in a DBA workday, the study revealed that a typical DBA will need 38% less time to perform common administrative functions with Oracle Database 10g Release 2 than with IBM DB2 UDB 9.1. Similarly, for product complexity, DBAs will require 36% fewer steps with Oracle Database 10g Release 2 than with IBM DB2 UDB 9.1 in the course of their typical workday.

Time (min) Complexity (steps) Result Summary DB2 Oracle DB2 Oracle

Overall Total 64.55 46.53 51 27 % difference – (DB2 - Oracle)/DB2

28% 47%

DBA Workday Savings 38% 36%

Note: For a complete rundown of all of the numbers comprised in this report, see Appendix III – “Detailed Test Results,” containing the comprehensive numerical analysis derived from this study.

Comparative Management Cost Savings

The core premise of any Comparative Management Cost Study is that the true cost of owning and operating complex systems like Oracle 10g Release 2 and IBM DB2 UDB 9.1 only start to accrue after the product has been purchased. In most real‐world business environments, the management costs will far outweigh the licensing and support costs throughout the life of the product. With this in mind, we estimated the annual costs that businesses can expect to save due to the DBA‐related time savings that result from one product being easier to administer and operate than the other.

In order to compute cost savings, we used DBA salary figures published by Enterprise Systems. Further information on these salary figures can be obtained from: http://esj.com/it_info_center/article.aspx?EditorialsID=27.

From Enterprise Systems survey: The median total compensation including benefits for a typical Database Administrator in the United States is $83,300. 4 This basic market

3 The times in all results tables are in minutes. Precision is 1/100th of a minute. Cumulative results are rounded in the tables used in the body of this paper. 4 According to the Enterprise Systems survey, an Oracle DBA earned an average of $80, 000 while a DB2 DBA earned $79,000. We averaged the two figures for a figure of $79,500. We then added the average bonus reported as $3,800 for our total of $83,300.


http://esj.com/it_info_center/article.aspx?EditorialsID=27


pricing report was prepared using analysis of survey data collected from thousands of HR departments at employers of all sizes, industries, and geographic regions.

If we insert the median DBA compensation salary found in the Enterprise Systems survey into the formula below, we arrive at the following quantitative management cost (MC) saving calculation.

Median DBA Salary * (DBA time savings) = $83,300 *38% = $31,654

This result can be interpolated to match to your company’s DBA salary expenses by applying the above formula.

When multiplied across all of the DBAs in an organization, these management cost savings quickly grow into a figure that dwarfs the one‐time licensing fee required to acquire a product of this nature.

Workload Category Test Results Synopsis

This section of the report delineates the Results Synopsis for each of the workload categories tested in this study. It will help the reader acquire a deeper understanding of how Oracle Database 10g Release 2 and IBM DB2 UDB 9.1 really compare across the board.

Install DB/Software/Out‐of‐the‐Box Setup (Results Synopsis)

This workload category addresses tasks relating to software installation and default out‐of‐the‐box setup. Three tasks were performed in this area. The quantitative results synopsis for this area is documented in the table below.

The results for this task were inconclusive. While IBM DB2 9.1 took much less time to install, the installation process was more complex that that for Oracle Database 10g. When looked at from the perspective of weighted DBA Workday savings, the differences — though real — may not be significant for most organizations.

Time (min) Complexity (steps) Installation and Simple “Out-of-Box” Setup DB2 Oracle DB2 Oracle

Category Sub-Total 15 26.63 12 6 % difference — (DB2 - Oracle)/DB2

-78% 50%

DBA Workday Savings -4% 3%

Qualitative Analysis

Installation is not a frequent DBA activity, and the major concerns tend to focus not on how long a product takes to actually install, but rather the complexity of choices involved. A first install often raises concerns about choices of such issues as block sizes or storage models, while subsequent ones are more mechanical. Both IBM DB2 UDB 9.1 and Oracle Database 10g have reduced the number of required installation parameters, and this



category dramatizes the success of these reduced administration efforts. In both cases, the default installation parameters generate a reasonably sound database instance that can be used for common day‐to‐day administrative tasks.

IBM apparently has made great strides in shortening installation time and lowering installation complexity when compared to our past experience. It is important to note that the Oracle Database 10g installation includes the installation of management tools that for IBM DB2 require additional separate disks, installation, and configuration steps. If the time required for these additional tools were to be taken into account, the time required would be much closer for the two products.

The most interesting takeaway from this category is simply the clean entry both of these products provide into their systems. Historically, both Oracle and DB2 installations had issues; DB2 was confusing, and Oracle installation required a long time and had a large disk footprint. These issues seem resolved in both products. Significantly, both installed products seemed stable — the ultimate success criteria of an installation scenario. In particular, the Oracle installer shows maturity as an elegant and consistent interface to manage a sophisticated product.

Day‐to‐Day Database Administration (Results Synopsis)

The Day‐to‐Day Database Administration Workload Task Category relates to the routine database object maintenance operations such as creating users, tables, and indexes, as well as reorganizing data and loading information into the database from external sources. Ten tasks were performed in this category. The quantitative results synopsis for this category is documented in the table below.

Time (min) Complexity (steps) Day-to-Day Database Administration DB2 Oracle DB2 Oracle

Category Sub-Total 11.75 6.57 16 11 % difference — (DB2 - Oracle)/DB2

44% 31%



The time difference between the products is 44% in favor of Oracle Database 10g Release 2, because once again the IBM DB2 9.1 UDB management interface was more complex. Edison Group believes that both vendors are paying significant attention to lowering the complexity and time spent by administrators for these tasks. Oracle Database 10g Release 2 provides out‐of‐the‐box capability to determine candidate segments for reclamation of space thereby removing the onus on DBAs. Further, the space reclamation capability in Oracle Database 10g Release 2 is vastly superior to IBM DB2 UDB 9.1; it can be executed “in‐place” without requiring any additional space and “on‐line” without incurring any application and database downtime.



When recovering space due to fragmented data IBM DB2 9.1 offers much improved capabilities over previous versions of their product, but the need to take the database offline had an affect on our results. The affect of taking database tables offline will have different significance in different implementations. Measuring this impact is outside the scope of this study.

In response to requests from readers of previous studies, a new set of tasks was added to this edition of our study: table partitioning. This capability is now commonly used in mid‐ to large size database systems and is very important in data warehouse implementations. Its addition to our study expands the applicability of our research to a wider range of users. Oracle Database 10g Release 2 exhibited a 31% time advantage in creating and indexing a partitioned table. Not only was there a greater time differences for these tasks, but also the tasks themselves were more complicated to perform under DB2.

Backup and Recovery (Results Synopsis)

This task category addresses tasks relating to database backup and recovery management. Four tasks were performed in this category. The quantitative results synopsis for this category is documented in the table below.

Time (min) Complexity (steps) Backup & Recovery DB2 Oracle DB2 Oracle

Category Sub-Total 16.55 8.33 13 5 % difference — (DB2 - Oracle)/DB2

50% 62%



Here Oracle won both in time and complexity. The Oracle default installation includes setting up automated backups, and a small part of the savings is attributable to that default. We believe that for small and medium sized businesses, these defaults are reasonable. Having a default in this situation is a practical feature; very often, quickly implemented development instances and such are either not backed up or — worse — are backed up incorrectly.

In the backup/recovery scenarios, it is significant to point out the Oracle flashback features are an enormous benefit in specific scenarios. Oracle provides a recovery window in flashback, allowing logical recovery — a conceptual leap over the traditional physical recovery — that can reduce problem resolution efforts by orders of magnitude. The Oracle recovery through flashback also seems qualitatively safer than the DB2 options of restoration a database and merging data or losing data though point‐in‐time recovery. This



flashback technology was the main reason behind Oracle’s substantial advantage over DB25.

The timing differences are based entirely on the functional and architectural differences between the two products. Oracle in this instance is raising the bar for recovery substantially; even though prior mechanisms to mine logs existed, the natural integration with production data is a substantive differentiator.

Performance Tuning (Results Synopsis)

This task category addresses tasks relating to manual and automated systems performance diagnostics and tuning. Three tasks were performed in this area. The quantitative results synopsis for this category is documented in the table below.

Time (min) Complexity (steps) Performance Diagnostics and Tuning DB2 Oracle DB2 Oracle

Category Sub-Total 21.25 5 10 5 % difference — (DB2 - Oracle)/DB2

76% 50%



This category is the one presenting the greatest leeway in testing. There are a bewildering number of ways in a modern RDBMS to inadvertently create performance issues, as well as to identify and diagnose them. Outside of design, the most rarified stratum of skills within the DBA world that can most affect utility is the tuning of applications and configurations. This complexity has driven vendors towards increased automation of performance tuning.

Due to the multiplicity of means for performance tuning, we believe that the best way to examine the results for this category is task‐by‐task. This study was designed with three tasks:

1. Diagnose performance problems

2. Tune resource‐intensive SQL

3. Tune memory

Diagnosis

For the task of diagnosing performance problems, the Oracle Database 10g Release 2 product installation process — combined with the selection of appropriate defaults when 5 IBM does offer an add‐on product, IBM DB2 Recovery Expert which might have affected the results of this study in the area of database and table recovery. Recovery Expert was excluded from consideration for two reasons. First, the project methodology is based upon evaluating only tools included as part of the initial installation disk: add‐on products were excluded. Second, the version of IBM DB2 Recovery Expert available at the time of this study was not compatible with DB2 9.1.



creating tables/indexes, gathering workload performance data, and other tasks — enables automatic diagnostics to function with no further interaction on the part of the DBA. IBM DB2 UDB Health Monitor can identify problems when certain thresholds are exceeded and bring them to the DBA’s attention. Deeper digging for problem root‐cause analysis may require the initiation of appropriate monitoring events, gathering snapshot data, and at times enabling CLI tracing mechanisms. Based on the problem at hand, users have to decide what appropriate events or level of tracing to enable, both of which incur performance overhead. Additionally, most often these problems are not known before hand and often might require replaying the problem workload. These extra steps add to the time and complexity of the diagnostic process in IBM DB2 UDB 9.1. IBM’s Health Monitoring can be compared to Oracle’s Server‐generated Alert feature that proactively notifies DBAs when certain metric thresholds are exceeded by the database.

As for Oracle Database 10g, unique features such as AWR (Automatic Workload Repository), ASH (Active Session History), and ADDM (Automatic Database Diagnostic Monitor) completely automate the process of performance diagnosis alleviating the need to replay workload or enable monitor events/tracing. Available out‐of‐the‐box, ADDM is a “one‐stop” shop for diagnosing performance problems. It diagnoses all types of problems, not just SQL related ones. The functionalities of ASH and ADDM that help provide pin‐pointed problem analysis are the key differentiators that make Oracle Database 10g a superior product to both IBM DB2 UDB 9.1for this task. .

The time and complexity measurements reported for tuning focus solely on the enabling of monitoring and diagnostic tools.

Tuning Resource-Intensive SQL

Because the two products under consideration – IBM DB2 9.1 Enterprise Edition and Oracle Database 10g Enterprise Edition – are not likely to be found in the single‐server simple database scenario we used in this study, it sometimes becomes necessary to recognize and consider the real‐world manageability challenges frequently faced in the complex enterprise‐class data centers more likely to deploy them. Tuning resource‐intensive SQL is one such challenge.

Oracle Database 10g Release 2 provides a SQL Tuning Advisor which can be run against Oracleʹs diagnosis report. The Advisor returns a tuning recommendation including suggestions for new or revised indexes; auxiliary information about the query (called SQL Profile) that transparently improves performance by tuning the SQL execution plan, and modifications to SQL code; for this study this recommendation of SQL Profile was accepted and the tuning went forward automatically. This choice demonstrated both an automatic and interactive approach to tuning.

IBM DB2 9.1 includes Design Advisor, a tool for tuning SQL statements. Whereas this tool provides help by identifying indexes that will improve SQL performance, it does not address the problem of SQL execution plan tuning. That has to be performed manually for SQL statements requiring it. The time required to tune the complex query manually was



actually less for our study than it might be in a real‐world scenario, as we knew what was wrong with the code and essentially just went through the steps to perform the tuning. If a true iterative process had been needed, the time required may have been much greater than that measured in the lab.

Edison Group therefore feels that when SQL tuning is needed for problematic queries Oracle has an advantage over DB2. In the real‐world data center, the need for the tuning of complex queries is a common and time‐consuming DBA task: this is why it caries the strongest weighting in our workload metric.

Memory Tuning

Memory tuning is another important aspect of performance tuning. IBM DB2 UDB 9.1 now supports automatic memory tuning. All that is required for DB2 is enabling automatic memory tuning during setup. While there is an option to enable it later, within the context of this study, there are neither steps nor time required to tune memory. Oracle’s performance diagnostic monitor ADDM does provide tuning recommendations for undersized SGA and PGA memory issues on the system but their implementation still requires a DBA. We expect Oracle will enhance its functionality in the area of memory tuning for future releases.



Conclusion

This CMCS study represents our detailed analysis of Oracle Database 10g Release 2 and IBM DB2 UDB 9.1 in the area of manageability. The study demonstrates that DBAs can perform routine administrative functions not only more quickly with Oracle but these functions are quantifiably easier to perform.

The key factors for Oracle’s superior manageability are self‐monitoring and diagnostic capabilities, and the increased automation of many otherwise manual but vital DBA tasks such as SQL tuning, space management, and performance diagnostics. These manageability advantages translate into substantial management cost savings for businesses along with higher reliability and availability of their systems.

Oracle Database 10g Release 2 demonstrated significant strengths in the more heavily weighted areas of Performance Diagnostics and Tuning, Backup and Recovery, and Day‐to‐Day administration. These strengths directly translated into the 38% cost savings calculated herein.

A final comment, which might not be immediately apparent from our report: Oracle Database 10g’s management console — Enterprise Manager Database Control — is the sole interface required for access to all the management features of the system. This console can be accessed via a web browser from any authorized location. IBM DB2 9.1, on the other hand, has several management consoles and several management applications accessed through those consoles. In addition, the interfaces of these several applications and consoles are not completely consistent. We have taken account of these design differences in assessing complexity, but it is important to recognize the affect that switching interfaces and multiple consoles can have on productivity. A deeper discussion of these factors is outside the scope of this document.



Appendix I ‐ Test Platform Details

Below are the technical specifications of the lab computers used to conduct this CMCS.

• Hardware Platform: OS/Hardware platform data points.

OS: Microsoft Windows Server 2000 5.00.2195 (SP4)

Processors: Dual Intel Xeon 2.8 GHz CPUs w/512 K Cache, 533 MHz FSB

Memory: 1 GB DDR, 2x512 MB 266 MHz DIMMS

Storage: Three 36 GB, 10 K RPM, 1in (Ultra 320) SCSI Hot Plug Hard Drives

HD Configuration: On‐board RAID 5, three drives connected via on‐board RAID

Software Platforms: Relational database management software platform data points.

• Oracle

Oracle Database 10g Enterprise Database Release 10.2.0.1

Oracle Database Diagnostics and Tuning Pack

Oracle Enterprise Manager 10g Database Control

Database Configuration Assistant

SQL*Plus

• IBM

DB2 — DB2 Enterprise Server Edition for Windows (x86, 32‐bit), v9.1

DB2 Control Center

DB2 Command Center

DB2 Health Monitor / Health Center

DB2 Command Line Processor

Note: All comparisons were performed using the database management tools bundled with the products under consideration. Since this study was a comparison of the stock manageability features bundled with these two products, no third‐party or add‐on software was taken into consideration in the course of conducting this study.



Appendix II ‐ Architectural and Terminology Discrepancies Requiring Clarification

Both Oracle Database 10g Release 2 and IBM DB2 UDB 9.1 are mainstream relational database management systems. Yet, relative to how these products have been designed to execute their respective database management functions, a few key architectural and terminological discrepancies should be clarified so that both Oracle and DB2 users reading this report will have a clear understanding of the synonymous terms and tasks comprised within this comparison. (See Appendix VI for a Glossary of Terms.)

Oracle database users are either created only within the database or both in the database and in the operating system; DB2 users must have an OS ID (or corresponding IBM Tivoli identification).

Oracle schemas are user names, while in DB2 they are distinct entities. DB2 has coarse grain point‐in‐time recovery; recovering a single tablespace is the lowest logical recovery point in DB2, while in Oracle the flashback mechanism provides any detail of transactional history with a clear and powerful interface. DB2 SQL is generally precompiled into plans and packages of compiled access paths, while Oracle mostly uses dynamic SQL, relying on cache for performance.



Appendix III ‐ Detailed Test Results

Time (mins) Complexity

(steps)

Task Description DB2 Oracle DB2 Oracle

Installation and Simple "Out-of-Box" Setup Tasks 1 Install db/software/out-of-box setup 8.75 19.3 5 2

2 Create 2nd database server/instance 5 6.83 4 3 3 Setup proactive monitoring 1.25 0.5 3 1

Category Sub-Total 15 26.63 12 6

% difference -- (DB2 - Oracle)/DB2* -78% 50% DBA Workday Savings -4% 3%

Day-to-Day Database Administration Tasks 4 Create user with roles, privileges 0.75 0.67 2 1 5 Create Schema 0.3 0 1 0 6 Create tablespace 0.5 0.5 1 1 7 Add space to tablespace 0.5 0.5 1 1 8 Create table 0.3 0.5 2 1 9 Create index 1 0.5 1 1 10 Create Partitioned Table 1.5 0.7 2 1 11 Create Index on Partitioned Table 0.5 0.67 1 1

12 Reclaim space due to fragmented data 5.9 0.67 3 1 13 Load data from text file 0.5 1.86 2 3 Category Sub-Total 11.75 6.57 16 11

% difference -- (DB2 - Oracle)/DB2* 44% 31% DBA Workday Savings 15% 11%

Backup and Recover Tasks 14 Configure and perform full backup 0.65 0 1 0 15 Recover dropped table 2 0.33 7 2 16 Recover data file 5.5 5.33 1 1 17 Recover from erroneous transaction 8.4 2.67 4 2 Category Sub-Total 16.55 8.33 13 5 % difference -- (DB2 - Oracle)/DB2* 50% 62% DBA Workday Savings 7% 9%



Time (mins) Complexity

(steps)

Task Description DB2 Oracle DB2 Oracle

Performance Diagnostics and Tuning Tasks 18 Diagnose performance problem 3.25 2 3 1 19 Tune resource-intensive SQL 18 1.5 7 2 20 Tune memory 0 1.5 0 2 Category Sub-Total 21.25 5 10 5 % difference -- (DB2 - Oracle)/DB2* 76% 50% DBA Workday Savings 20% 13%

Overall Total 64.55 46.53 51 27

% difference -- (DB2 - Oracle)/DB2* 28% 47%

Total DBA Workday Savings 38% 35%



Appendix IV – Complexity Calculation Formula

Complexity is defined as the number of computed steps it takes to complete a given task. The formula used to compute complexity for each of the tasks in this study is as follows:

• For every five increments contained in a step we increase the step value by 1. For example:

If a step has 0–5 increments, step value = step + 0,

If a step has 6–10 increments, step value = step + 1

If a steps has 11–15 increments, step value = step + 2

… and so on.

• The type of instrumentation offered to perform a given task modifies the task’s complexity.

If a task can be performed completely with a GUI, then step count = step count + 0.

If a task requires the use of a command line interface, then step count is modified as follows:

• If the command line operation consists of a single‐line command, then step count = step count + 1.

• If the command line operation requires writing a script, then step count = step count + 2 or more steps, depending on a subjective assessment of the complexity of the script.

• If a task requires a context switch between different environments, then step count = step count + 2 or more steps, depending on a subjective assessment of the complexity of the context switch.

• In the case of point‐in‐time recovery operations (task 12 and task 14), we exercised the discretionary option of assessing step penalties that we consider exceptions to these rules, due to the open‐ended subjective and analytical nature of the operations required to successfully complete those tasks.

• In the case of reclaiming space due to fragmented data, we accessed a penalty of two steps to DB2, as taking the database offline was required to complete this task.



Appendix V ‐ Detailed Task Descriptions6

Installation and Simple “Out‐of‐Box” Setup

Task 1: Install database and management software, and create starter database Task Oracle DB2

Step Time Step Time Install DB Server & Management Software, Set Up Networking Configuration

1. Launch the Oracle Installer * Specify File Locations * Select Installation Type (Enterprise Edition) * Select Database Configuration (Create Starter Database, General Purpose) * Specify Database Configuration Options(DB Naming, DB Char Set, DB Examples) and keep defaults.* Select DB Management Option and keep defaults * Select DB File Storage Options and keep defaults * Select Backup and Recovery Options, Set Enable Automated Backups, and keep defaults * Check archivelog mode leaving defaults * Set Backup Job Credentials with the username and password of a user with at least backup operator

19 min 20 sec 1. Select Install Products from the installation Wizard

* Select Install New Server / <Next> * Accept License * Select installation type ( Typical) * Installation options - Install EE on this computer (implicitly single rather than partitioned) and Response File Options * Select Installation Folder * Set user Info for Administration Server (DAS) * Accept Defaults for Instance * Accept Defaults for Tools Catalog *Setup Notifications *Specify Contact for Notifications *Specify OS Security for DB2 Objects *Finish

2. Install Starter Database *From DB2 First Steps / Database Creation / Create Sample Database / <GO> * Accept Defaults for Type of Database (SQL and Data Only) / Default Location (Drive C) <OK>

8 minutes

45 sec

6 In the Task Description tables, “*” in the Step column represents increment for the step. For more information on this metric, refer to the section, The Methodology Defined.



Task Oracle DB2 Step Time Step Time

privileges. * Specify Database Schema Passwords and use same password for all accounts. Install

Management Framework Setup

Part of the install

N/A Part of the install N/A

Metrics Oracle DB2 Time 19 min 20 sec 8 min 45 sec Steps 1 2 Increment Penalty 1 1 Context Switch Penalty 0 2 Adjusted Steps (Complexity) 2 5

Task 2: Create additional database server/instance Task Oracle DB2

Step Time Step Time Create a New Database Instance

1. Launch DBCA from the Start Menu * Create New Database * Select General Purpose Database Template (this is selected by default) * Enter New Database Name and SID * Select Management Options and Keep Defaults (Use DB Control for DB Mgmt) * Enable Daily Backup by setting Start time, OS User Name, and Password. * Set DB Credentials and Use Same Password for all Accounts. * Set storage

6 min 50 sec

1. From Launch Pad - Select Install Product

*Select Install New *Accept License *Set Installation Type *Select Installation / Response File Options *Accept Installation Folder Defaults *Set DB Copy Name / Default Properties *Select Default New Instance Settings *Set User Info for Default Instance *Setup Notifications *Specify Health Monitor Notification *Enable OS Security *Review Options and Install

2 Install Starter Database

*From DB2 First Steps / Database Creation / Create Sample Database / <GO> * Accept Defaults for Type of Database (SQL and Data

4 min 15 sec

45 sec



Task Oracle DB2 Step Time Step Time

options and keep defaults. * Select DB file locations and keep defaults. * Set recovery configuration and keep defaults * Check archive log mode * Specify Database Content and keep defaults * Configure Initialization Parameters and keep defaults * Set Creation Options Finish

Only) / Default Location (Drive C) <OK>

Metrics Oracle DB2 Time 6 min 50 sec 5 min Steps 1 2 Increment Penalty 2 2 Adjusted Steps (Complexity) 3 4



Task 3: Set up pro-active monitoring for performance and space utilization Task Oracle DB2

Step Time Step Time Create task to monitor for performance problems and space issues

N/A

N/A (default database / tablespace setup now includes preset alarms in health indicators)

Set thresholds for each event, save event, and start monitoring database

1. Go to the Manage Metrics” page (EM home page, * Click on the “Manage Metrics” link). * Click the “Edit Threshold” button. This takes you to the “Edit Thresholds” page. * Set threshold for Buffer Cache Hit (%). OK

30 sec 1. From Health Center, select Object Health Settings

*Select Object: Instance / Database

2. On the Configure Health Indicators for Database Default Settings,

*Verify the defaults for Sort Overflowed *Select Heap Utilization *Set alarm threshold (%) for Heap Utilization *Confirm successful Heap Utilization modification

3. Select Object: Instance / Database / Tablespace / Tablespace Name

*Verify Tablespace Utilization - Total

1.min 15 sec

Metrics Oracle DB2 Time 30 sec 1 min 15 sec Steps 1 3 Increment Penalty 0 0 Adjusted Steps (Complexity) 1 3

Installation and Simple “Out-of-Box” Setup Tasks Results Summary Metrics Oracle DB2 Time 26 min 40 sec 15 min Total Steps 6 12



Day‐to‐Day Database Administration

Task 4: Create user, assign roles/privileges Task Oracle DB2

Step Time Step Time Create User and Assign Role(s)/ Privs

1. Navigate in EM to the Administration tab and… * Select Security Users link. * Select the Create button and enter the username, password. * Select the default tablespace information for the new user. (The CONNECT role is granted by default) OK.

40 secs 1. From Control Center / Instance / Database / User and Group / DB Users: * Select Add New User * Select User from Database tab drop-down * Select check-box DBA Authority / <APPLY> 2. From Control Center / Database / Tablespaces Select Tablespace / Privileges Tablespace Privileges / Add User *Select User / Apply * Tablespace Privileges / User Tab / Select User * Privileges / Use / Select Grant from drop-down *Privileges / Select User / <OK>

45 sec

Metrics Oracle DB2 Time 40 sec 45 sec Steps 1 2 Increment Penalty 0 0 Adjusted Steps (Complexity) 1 2



Task 5: Create schema Task Oracle DB2

Step Time Step Time Create Schema

n/a 0 1. From Control Center / Instance / Database / Schemas / right-click / Create

* Enter Schema Name / Authorization Name (Owner) / Comment / OK

18 sec

Metrics Oracle DB2 Time 0 18 sec Steps 0 1 Increment Penalty 0 0 Adjusted Steps (Complexity) 0 1

Task 6: Create tablespace/file group Task Oracle DB2

Step Time Step Time Create Table-space

1. Go to the EM Administration tab and… * Select the Tablespaces link. Click the Create button and enter tablespace name * Click the Add Button in the Datafile section * Enter datafile path/name, and size. Continue Click OK

30 sec 1. From Control Center go to Instance / Database / Tablespace /Create

*Specify Name / Comment / System Managed or Database Managed storage management *Review Actions / <Finish>

30 sec




Task 7: Add space to tablespace Task Oracle DB2

Step Time Step Time Add More Space to the DB

1. Go to the EM Administration TAB->Tablespaces link. * Choose the Add Datafile option and click GO. * Enter new file name and size. Click OK.

30 sec 1. From Control Center navigate to Database

* Select / Manage Storage /Add Automatic Storage * Specify Storage Path /OK /Complete/View Results Message / close

30 sec


Task 8: Create table Task Oracle DB2

Step Time Step Time Create Table

1. Go to the EM Administration Tab->Tables link. * Click the Create button. (This launches the table creation wizard.) * Enter table name, 3 columns with data types (number, varchar2 and date) Click OK.

30 sec 1. From Control Center * Database / Tables / Create right-click / Create *Create Table Wizard: Name / Select Schema / Enter Table Name / Comment

2. Create Table Wizard: Columns / <ADD>

* Add Column Dialog Enter Column Name / Set Col Attributes <OK> Repeat 4 Times *Assign to Tablespace (Existing)

18 sec




Task 9: Create index Task Oracle DB2

Step Time Step Time Create Index

1. Go to the EM Administration Tab ->Indexes link. * Click Create button. (This launches index creation page.) Enter index name, table name, and columns. Click OK.

30 sec 1. From Control Center, go to Database / Index / Create

*Create Index: Target Table / Set Schema / Select Table *Create Index: Name / Set Schema/ Enter Index Name *Create Index: Column / Select column(s) / Sort Order / <Next> *Create Index: Options / [Accept Defaults / <Next> *Create Index: Summary / Review Actions / <Finish>

1 minute

Metrics Oracle DB2 Time 30 sec 1 min Steps 1 1 Increment Penalty 0 0 Adjusted Steps (Complexity) 1 1



Task 10: Create partitioned table Task Oracle DB2

Step Time Step Time Create Partitioned Table

1. Database Home -> Admin Tab -> Click on Tables link. Click “Create” Button to launch the wizard

* Click Create Button, (this launches Table Creation wizard) * Click on Partition Tab,. Then “Create” (this launches partition create wizard), Select default options (Range option) continue, * Specify which columns are partitioned keys, Next, #partitions = 13, starting date, duration 1 month (Automatically Generated values is selected by default)

* Specify destination TS, Next, Review, Finish, OK

42 sec Select Database / Create Table * Add column definitions * Identify Schema and Name * Define Data Partition: Select Column / Data Partition / Add *Data Partition / Specify Boundary Start / Boundary *Multiple Data Partitions / Select Time Unit / "Width" ( 13 months ) 30 *Select Tablespace - / Finish

1 min 30 sec

Metrics Oracle DB2 Time 42 sec 1 min 30 sec Steps 1 1 Increment Penalty 0 1 Adjusted Steps (Complexity) 17 2

Task 11: Create Index on Partitioned Table Task Oracle DB2

Step Time Step Time Create index on Partitioned table

1a. Go to EM Administration Tab -> Indexes Link,

* Click Create button

40 sec Command Center / Database / Table / Create Index

*Table / Schema / Next /

30 sec

7 Oracle has the ability to perform per partition compression while DB2 partitioning is at table level. Oracle supports numerous partitioning types, list, range, composite, hash etc. Determining the compression efficiency and cost for each of the vendors was beyond the scope of this study.



(this launches the index creation page) Enter index name, columns *. Click on Partitions, Click on Enable Partitioning, Click OK.

Specify Schema / Specify Name for New Index / *Accept Default Tablespace / Next / *Specify Index Keys - Select Column / Next *Accept Default Index Performance Options / Finish


Task 12: Reclaim lost space due to fragmented data Task Oracle DB2

Step Time Step Time Determine if any tables in the application tablespace need to be reorganized.

EM / Advisor Central / Segment Advisor / Review Recommendations / Accept Advice

30 sec 1. Run Control Center / Configure Automatic Maintenance

* Select Change Automation Settings / Specify When Automatic Maintenance can run * Select Contacts to Notify *Select Activities / Defragment Table and Index Data / Automate/ Notify *Review Summary / Finish

30 sec

Execute shrink command

N/A

10 sec 1. Defragmentation takes place offline. This was the offline time for our sample data.

5 min 24 sec

Metrics Oracle DB2 Time 40 sec 5 Minutes 54 sec Steps 1 1 Increment Penalty 0 0 Context Change Penalty (offline) 0 2 Adjusted Steps (Complexity) 1 3 Note: DB2 Defragmentation takes place during a maintenance window that is defined during job setup. It only occurs if the system recognizes a need or parameters established during job setup are reached. The database tables need to be taken offline during the maintenance window: indexes can be defragmented online. The time taken for this task is for a table of 6.5 million rows that needed



defragmentation. The table had five indexes and is representative of a problem found in real world deployments.

Task 13: Load data from a text file Task Oracle DB2

Step Time Step Time Data Loading

1. From Enterprise Manager:

*Select/ Schema / EM Load Data wizard

*Select columns

*Select delimiter

*Select file

* Select table

* Accept Datatype Defaults

2. * Run Job

1 min 52 sec

1. Control Center / All systems / My Server / My Instance / Databases / Tables / Table to Import – right-click – Select

* Load Wizard / Type – Select Append or Replace * Load Wizard / Files : Configure Input File Format (Delimited Text, Delimited Options) / Input File Location / Path and Filename of Input / Path and File Name for Log *Load Wizard / Columns - Define / Approve Input Column Mapping *Load Wizard / Accept Defaults for: Failure Options and Recovery Strategy *Advanced Options / Schedule / *Review Summary / <FINISH>

30 sec

Metrics Oracle DB2 Time 1 min 52 sec 30 sec Steps 2 1 Increment Penalty 1 1 Adjusted Steps (Complexity) 3 2

Day‐to‐Day Database Administration Tasks Results Summary

Metrics Oracle DB2 Time 6 min 34 sec 11 min 45 sec Total Steps 11 16



Backup & Recovery

Task 14: Configure and perform full database online backup Task Oracle DB2

Step Time Step Time Configuring for online backup

N/A (Oracle 10g R2 recommended backups are configured and scheduled automatically upon database creation.)

0 min 1. From Control Center / Wizards / Backup Wizard / Select Database

* Start Wizard / Confirm Backup Entire Database / <NEXT> *Specify Media / File System / Add directory / <NEXT> *Choose Options / Full Backup / Online / <NEXT> *Specify Performance Options / accept Defaults * Run Now or Schedule <Next>

39 Seconds

Perform backup

0 min 2. N/A (done automatically)

Metrics Oracle DB2 Time 0 39 sec Steps 0 1 Increment Penalty 0 0 Adjusted Steps (Complexity) 0 1



Task 15: Recover dropped table Task Oracle DB2

Step Time Step Time

Recover dropped table.

1. Recover table using “Flashback Table <table name> To Before Drop” command.

20 sec 1. From Command Line invoke List History Dropped Table command 2. Restore Data Wizard / select Database / Select Tablespace to Restore / * Select Backup Image / * accept Defaults◊ / * Restore selected data files (specify) 3 Command line rollforward and complete recover dropped table 4 Command line create table 5. Command Center/ import file to restore data

2 min

Metrics Oracle DB2 Time 20 sec 2 min Steps 1 5 Increment Penalty 0 0 Command line usage penalty 1 2 Adjusted Steps (Complexity) 2 7



Task 16: Recover data file Task Oracle DB2

Step Time Step Time Data file recovery: application data file of size 1.2 GB is lost.

1. Go to the EM Maintenance tab and click on Perform Recovery link. This launches the Recovery Wizard. * Specify the datafile(s) you want to recover. * Specify the Recovery Location

* Review Recovery Parameters & Submit.

5 min 20 sec

1. Control Center / Wizards / Restore Data Wizard / <OK>

*Select Database / Confirm Details / *Restore to Existing DB <Enter> *Select Object / Name of Dropped Table Space / *Select from Available Backup Images / <NEXT> OR <Finish>

5 min 30 sec

Metrics Oracle DB2 Time 5 min 20 sec 5 min 30 sec Steps 1 1 Increment Penalty 0 0 Adjusted Steps (Complexity) 1 1

Task 17: Recover from erroneous transaction Task Oracle DB2

Step Time Step Time Recovery scenario: Due to a human error, a transaction was submitted by mistake

1. Go to the tables page in EM (Administration / Schema / Tables), * Select the Inventories table and * Select Action “Flashback by timestamp” / Go / Identify the time to recover from error

2. Execute the undo SQL

2 min 40 sec

1. From Control Center right-click <Restore> Restore Data Wizard, restore to existing database *Restore selected data files (specify) a select backup image *Specify rollforward time (time just before the accidental drop) Finish 2. Manually rerun the transactions lost due to point-in-time recovery (not accounted for in time)

8 min 28 sec

Metrics Oracle DB2 Time 2 min 40 sec 8 min 28 sec Steps 2 2 Increment Penalty 0 0 Context switch penalty 0 2 Adjusted Steps (Complexity) 2 4



Backup & Recovery Task Summary

Metrics Oracle DB2 Time 8 min 20 sec 16 min 37 sec Total Steps 5 13

Performance Diagnostics & Tuning Tasks

Task 18: Diagnose performance problem Task Oracle DB2

Step Time Step Time Configure system to identify top resource-consuming SQL

N/A 0 1. Receive Alert from Health Monitor

1 min 15 sec

Identify resource-intensive SQL

1. Go to the EM home page and review the last ADDM report.

2 min 2. Open Activity Monitor and review report

2 min

Metrics Oracle DB2 Time 2 min 3 min 15 sec Steps 1 2 Increment Penalty 0 0 Context Switch Penalty 0 1 Adjusted Steps (Complexity) 1 38

8 Taking into account all the intricacies associated with performance tuning could increase the adjusted complexity and time for this task. The penalty assessed for IBM UDB 9.1 is fairly conservative in these areas a) Amount of manual work and time that needs to be spent to diagnose various kinds of performance problems b) Increment penalty/complexity incurred in Step 1 of the task.



Task 19: Fix performance problem (tune SQL statement) Task Oracle DB2

Step Time Step Time Tuning SQL 1. From the ADDM report page,

click on Run SQL Tuning Advisor button to tune resource-intensive SQL identified in the previous task.

2. Navigate to EM Advisor central page

* Click on the SQL Tuning Advisor task result

* Accept SQL Tuning Advisor Recommendations.

1 min 30 sec

1. Rewriting problem SQL manually using Control Center’s Explain plan utility. 2. Launch Design Advisor to determine if new indexes are needed. 3.Accept advice

18 Min

Metrics Oracle DB2 Time 1 min 30 sec 18 min Steps 2 3 Increment Penalty 0 0 Context switch penalty 0 2 Command Line Penalty 0 2 Adjusted Steps (Complexity) 2 7

Task 20: Tune memory Task Oracle DB2

Step Time Step Time Tune Memory

1. Check the latest ADDM report.

2. Change SGA_TARGET and/or PGA_Target based on ADDM advice.

1 min 30 sec

DB2 9 configuration advisor runs by default at DB creation time and Self-Tuning memory management kicks in during production. So for Sort Heap, Buffer pool, and other key SQL execution memory parameters, no manual tuning is required.

0 min

Metrics Oracle DB2 Time 1 min 30 0 Steps 2 0 Increment Penalty 0 0 Adjusted Steps (Complexity) 2 0



Performance Tuning Task Summary

Metrics Oracle DB2 Time 5 minutes 21 min 15 sec Total Steps 5 10



Appendix VI – Glossary of Task Areas/Tasks

Database setup and configuration (workload task area): A workload task area that encompasses all of the operations that a DBA would need to perform in order to accurately install and configure either product prior to using it in a real‐world application.

Install db/software/out‐of‐box setup: The workload task that identifies the process of installing and configuring either of these products for the first time.

Create new database server/instance: The workload task that allows a DBA to create a second database server/instance on a computer already running one or more instances of the RDBMS.

Set up proactive monitoring: Proactive monitoring is a tool that allows a DBA to identify problems with the RDBMS before they become performance or operational issues. Setting up monitoring is crucial in providing a highly reliable system.

Day‐to‐Day database administration (workload task area): The workload task area where all of the routine DBA operations occur, such as creating database users and objects (for example, tables, indexes, triggers, procedures), as well as granting and revoking roles/privileges, plus database table/table space/data file sizing.

Create user with roles, privileges: The workload task that allows DBAs to manage user security in the database.

Create schema: The workload task that allows DBAs to create a new schema.

Create table: The workload task that allows DBAs to create a table object to store information inside a schema in the database.

Create index: The workload task that allows DBAs to create an index on a set of columns in a table that are heavily queried in order to speed the execution of queries run against that table.

Reclaim wasted space from tables with fragmented data: The workload task that allows DBAs to pack/shrink the database after prolonged use in order to consolidate space and optimize performance.

Load data from text file: The workload task that allows a DBA to load information from an external source such as a flat file or spreadsheet into one or more tables in the database.

Create table space: The workload task that allows DBAs to build a new tablespace for use by a particular database instance or schema.

Add space to table space: The workload task that allows a DBA to add data files to a table space, thus increasing the amount of space available to all of the objects contained in that database.

Create Partitioned Table:



Create Index on Partitioned Table:

Backup and recovery tasks (workload task area): The workload task area where all tasks pertaining to database backup and recovery are performed.

Configure and perform full backup: The workload task that allows DBAs to schedule and execute regular system backups as part and parcel of standard system fault tolerance operations.

Recover dropped table: The workload task that allows a DBA to recover a table that has been inadvertently dropped from the database by a DBA, developer, or power user in the course of working with the database.

Recover data file: The workload task that allows the DBA to recover a data file from a backup copy in the event of a media failure.

Recover from erroneous transaction: The workload task that allows an DBA to undo a mistakenly executed transaction in order to recover objects ill‐affected by this transaction to the state they were in before the transaction was executed.

Performance diagnostics and tuning tasks (workload task area): The workload task area where all performance‐related diagnostic, tuning, and optimization tasks are performed.

Diagnose performance problem: The workload task that allows a DBA to analyze a poorly performing system in order to assess the performance problem as a prerequisite to performing the systems optimization functions required to bring the level of system performance to an optimal state (such as creating additional indexes, tuning a query/procedure, defragmenting table spaces, or adjusting the server’s memory configuration).

Tune instance memory: The workload task that allows DBAs to adjust server/instance system memory configuration parameters in order to efficiently support the load placed on the system by all applications that access the database.

Fix performance problem (tune SQL statement): the workload task that allows DBAs to optimize a poorly running query/procedure so that it executes in an efficient manner.


Comparative Management Cost Study: Oracle 10g IBM … · Comparative Management Cost Study: Oracle...

Documents

Transcript of Comparative Management Cost Study: Oracle 10g IBM … · Comparative Management Cost Study: Oracle...