Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability An Oracle White Paper December 2008 Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Introduction........................................................................................... 3 Management Tools................................................................................ 3 Storage Management ............................................................................ 5 Space & Object Management ............................................................... 6 Proactive Space Management ........................................................... 6 Online Reorganization ...................................................................... 7 Row Size Limit ................................................................................. 7 Handling Out-of-Space Situations .................................................... 8 Performance Management .................................................................... 8 Performance Diagnostics .................................................................. 8 Performance Statistics Collection................................................. 8 Comparative Performance Analysis ............................................. 9 Active Session History (ASH) ...................................................... 9 Automatic Performance Diagnosis ............................................. 10 Identifying and Tuning High-load SQL Statements ....................... 12 Automatic SQL Tuning................................................................... 14 Tuning Packaged Applications ....................................................... 15 Execution Plan Stability.................................................................. 16 Managing Resources....................................................................... 17 Change Assurance............................................................................... 18 Load Testing ................................................................................... 18 Ensuring SQL Performance ............................................................ 19 Backup & Recovery............................................................................ 20 Backup Files Management.............................................................. 20 Self-contained Backups .................................................................. 21 Intelligent Recovery........................................................................ 21 Recovery from Human Errors......................................................... 22 Recovery of Dropped Table........................................................ 22 Recovery from Logical Data Corruptions .................................. 23 Installation and Configuration ............................................................ 24 Instance Creation ............................................................................ 24 Database Duplication ...................................................................... 24 Installation Cloning......................................................................... 25 Software Maintenance ........................................................................ 26 Patching .......................................................................................... 26 Fault Diagnostics ............................................................................ 27 Cross-platform Portability .................................................................. 28 Scalability ........................................................................................... 28 Conclusion .......................................................................................... 30 Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 2 Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability INTRODUCTION In the area of manageability, Oracle’s main competition has traditionally come from SQL Server. Both vendors have made enhanced manageability of their database server a primary objective, with new features being added with every new release to make database management easier and more cost-effective. Despite the addition of new features in the area of manageability in SQL Server 2008, it still lags behind Oracle Database 11g. Oracle Database 11g is a sophisticated self-managing database that automatically monitors, adapts, and fixes itself. The self-managing solutions found in the Oracle Database allow DBAs to be more productive, and helps their organizations reduce management costs without compromising service level objectives. The latest release of SQL Server was mainly catching up with the manageability features already introduced by Oracle in its latest verson of Oracle Database 11g, which at the time of its own release dramatically widened the gap between two competitors. MANAGEMENT TOOLS Oracle Enterprise Manager and SQL Server Management Studio are the GUI tools provided by Oracle and SQL Server respectively, for the management and maintenance of their systems. Enterprise Manager 11g is Oracle’s single, integrated solution for administering and monitoring applications and systems that are based on Oracle and 3rd party components. It provides the ability to seamlessly manage hundreds and thousands of systems located across organizational and geographical boundaries from a single point of control. Enterprise Manager has a web-based architecture, which is robust, reliable, scalable, and is easy to deploy and operate within today’s internet-enabled environments. It has an HTML-based console interface, which allows an administrator to manage from anywhere — all that is needed is a Web browser. Its robust grouping and task automation functionality provide core features that enable reliable, rapid, and secure automation of traditionally time-consuming, error prone tasks, such as application performance management, policy-based standardization and system provisioning. Looking from a database-centric point of view, Enterprise Manager significantly simplifies day-to-day database administration by combining simplicity with a Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 3 rich feature set for managing an environment of any size regardless of O/S platform. It automates many crucial management tasks and enhances administrator productivity by providing: • Immediate out-of-box value by configuring and starting all the necessary framework component processes during database creation. Enterprise Manager is completely configured and ready for use when a new database is created. • Consolidated overview of the enterprise’s health on the Home page. It shows availability, alert and job statuses for the database, configuration information, software maintenance advisories for critical patches, and the ability to drill down into more details in any of these areas. • System monitoring and alert notification to anticipate problems and possibly fixing them automatically using “fix-it” jobs. A large number of Oracle customers such as British Telecom, Boeing, Telstra, Fidelity and Shell have standardized on Enterprise Manager to manage their production systems. Their experience is live testimony of how effective Oracle management tools are in boosting administrator productivity and increasing the number of databases each DBA can manage. SQL Server Management Studio lacks the depth of management capabilities provided by Oracle Enterprise Manager. It does not have an HTML-based console interface and hence, requires installation of its client tool on all systems from which an administrator may want to manage the SQL Server database. This seriously restricts the ability of the administrators to manage their database from anyplace at any time. Another deficiency in SQL Server’s management tool is its inability to provide end-to-end management and diagnostics of the entire system from a single console. Metrics relating to the O/S, middle-tier application servers, etc., cannot be monitored by the SQL Server’s management tool. A further difference between Oracle and SQL Server is in their management model. Oracle Enterprise Manager follows the management-by-exception model, where DBA intervention is only needed when an exception condition occurs or is about to occur. Oracle highlights problem areas on its Home page such as space pressures, performance issues, etc., so that any potential problems or exceptions can be identified and dealt with immediately. This approach is very different from SQL Server’s where DBAs themselves have to monitor the system for potential problems. For example, if a SQL statement is taking an inordinately long time, it will proactively be shown under the diagnostic summary section of the Oracle Enterprise Manager 11g Home page. In comparison, for SQL Server, a DBA would have to first turn on monitor counters on the database (this has an obvious negative impact on performance), rerun the workload (this may not always be possible and is never convenient), Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 4 and analyze the trace files to determine the most resource consuming SQL. Only then can the DBA know if there are any problem SQL statements that are affecting system performance. Thus, SQL Server’s management tool, unlike Oracle’s, requires its users to invest considerably more time for common administrative functions, is fundamentally reactive rather than proactive in its management approach, and lacks many of the management capabilities provided by Oracle. STORAGE MANAGEMENT Database administrators face many challenges in the area of storage management. With the rapid growth in database size and the demand for uptime continuing to increase, taking the database offline to perform maintenance operations such as changing disk configuration, is becoming increasingly difficult to schedule. In addition, the process of working with system administrators to locate and remove I/O hot spots or fragmentation can be grueling. At the same time the pressure of cost reduction no longer allows the growth in the DBAs staff to keep pace with the database growth rate. This results in what some refer to as the “management gap”. DBAs need better tools that can increase their productivity and help automate many of their manual tasks. Automatic Storage Management (ASM) is a feature of the Oracle Database, first released in database version 10g, that provides the solution for these storage management challenges by automating the entire function. All an administrator has to do is to allocate a set of storage devices to a database instance and the Oracle’s ASM solution takes care of the rest. It automates the placement of the database files within those disk groups and spreads data evenly across all available storage resources to optimize performance and utilization. This even distribution of database files makes manual I/O performance tuning obsolete. ASM also provides three mirroring options for protection against disk failure: none, two-way, and three-way mirroring. Furthermore, ASM enables the DBA to change the storage configuration without having to take the database offline. ASM automatically rebalances files across the disk group after disks have been added or dropped. ASM is a feature specifically built to simplify the job of storage management. It is a capability that saves the administrators time and provides flexibility to manage a dynamic database environment with increased efficiency. SQL Server does not have any storage management capabilities like those offered by Oracle. Storage management has to be done manually, using the new Share and Storage Management Console introduced in SQL Server 2008 or, alternatively, a separate tool has to be purchased to provide this function. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 5 SPACE & OBJECT MANAGEMENT Proactive Space Management Oracle provides proactive space management capabilities with its space monitoring, notification, and space trending features. Rather than using external tools to poll the database to monitor space usage — something that is inherently resource intensive — Oracle database server has built-in intelligence that provides a non-intrusive and timely check of space usage in the database. If the space usage of a tablespace crosses a user-defined threshold, Oracle server will issue an alert to forewarn the appropriate person — DBA — that the database is running out of space so that corrective measures can be taken. By default, Oracle will issue a warning alert when a tablespace is 85% full and a critical alert when it is 97% full. A DBA can override these defaults for a given tablespace (either in terms of percentage of space used or amount of free space available in bytes) or alternatively, can set a new default for the entire database. Once corrective measures have been taken, the alerts are cleared automatically by the server. Oracle also provides a sophisticated alert notification system. DBAs can receive alerts via email, pagers, Enterprise Manager, or directly by querying views inside the database server. The key aspect of space management in Oracle is its efficiency. The database server tracks space utilization while performing regular space management operations, e.g., allocating a new extent. A background process compares the state of the tablespace against the thresholds specified to determine if an alert should be raised or cleared. If a state transition has occurred, appropriate action is taken and an alert is either triggered or cleared. Finally, Oracles’ proactive space management is enabled by default and causes no measurable performance impact on the system. SQL Server also has the capability to monitor space usage, but it differs from Oracle in several aspects. First, space usage monitoring is done using the SQL Server agent, whose primary function is job scheduling and alert handling. Thus, the monitoring and alerting mechanism is based on polling of database meta data and is intrinsically inefficient and expensive. Second, the space monitoring and alerting infrastructure in SQL Server is not as flexible as Oracle’s. SQL Server lets you set space usage thresholds for alerting at the database level only. This means that if you have two different filegroups (tablespace in Oracle terminology), one for tables and the other for indexes and you want to set two different alert thresholds for them — a very basic requirement — you cannot do it. Oracle, on the other hand, allows you to set alert thresholds at the database or the tablespace level. This added granularity in monitoring gives Oracle DBAs more flexibility and precision in setting space usage guidelines for honoring service level agreements. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 6 Online Reorganization Oracle Database 11g enables database administrators to perform almost all segment maintenance operations online, i.e., the data is fully available for queries, updates, and deletes. Schema evolution allows table definitions to be modified while the data table is in service. Tables can be relocated, defragmented, reorganized or have their storage parameters changed. Indexes can be added, rebuilt or defragmented online. SQL Server does not support the extensive set of online operations as Oracle Database 11g. In SQL Server, the ability to create, rebuild and drop and index online has been added only recently. This allows concurrent modifications (DML operations) to the underlying table or clustered index data and any associated indexes during DDL operations on indexes. This is significant improvement over earlier versions of SQL Server where index create/rebuild operations held exclusive locks on the underlying data and associate indexes, preventing modifications or queries until the index operation was complete1. Oracle has provided this capability for many years now and moreover SQL Server still does not have online schema evolution, table reorganization, and table redefinition capabilities provided by Oracle. Many of these maintenance operations are done frequently and can take hours to complete and as a result, SQL Server 2008 applications can suffer significant data unavailability. To get around this problem, SQL Server DBAs have to skillfully devise elaborate schedules on when to perform these operations in order to minimize the impact on system unavailability. This significantly adds to the management workload of the DBA, and is something that Oracle DBAs do not have to consider at all in their day-to-day operations. Row Size Limit SQL Server generally imposes a limit of 8060 bytes (8KB) on the size of a row with a few exceptions. However, this restriction is relaxed for certain cases, namely for tables containing varchar, nvarchar, varbinary, or sql_variant columns. The length of each one of these columns must still fall within the limit of 8KB; however, their combined widths can exceed the 8,060-byte row limit in a table. This applies to varchar, nvarchar, varbinary, or sql_variant columns when they are created and altered, as well as to when data is updated or inserted2. For tables with that do not fall under the exception outlined above, a SQL Server DBA has to somehow overcome the 8KB row size limitation. In such instances, a common practice among SQL Server DBAs is to vertically divide the table into multiple tables. Whereas this solves one problem by overcoming the 8KB restriction, it creates another problem by compromising the 1 An Overview of SQL Server 2008 Beta 2 for the Database Administrator , www.microsoft.com/technet/prodtechnol/sql/2008/maintain/sqlydba.mspx 2 SQL Server 2008 Books Online, Designing and Creating Databases, Designing Tables. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 7 optimality of the application design. This is yet another area that an Oracle DBA does not have to worry about. Oracle allows a row to span across multiple pages (or blocks in Oracle parlance) and imposes no limits on its row size. Handling Out-of-Space Situations Operations such as data loads or batch updates can encounter errors when they run out of space. Sometimes these errors occur just when the operation is about to finish. Oracle’s Resumable Space Allocation feature enables it to handle such errors in a very graceful manner. Whenever an operation encounters an out-ofspace situation, it is held in a “suspended” state while an alert is generated to notify the administrator of the problem so that the problem can be fixed. The “suspended” operation automatically resumes as soon as the error condition is corrected. In case of a transient problem, such as a query running out of temporary space, no administrator intervention may be required since Oracle will resume the operation automatically as soon as the transient problem disappears. Virtually any kind of operation, be it a PL/SQL or Java stored procedure, a DML or DDL statement, or an export/import or loader session, can all be run in the “resumable” mode. This capability is unique to Oracle with no parallel in SQL Server. It saves Oracle DBAs enormous time that their SQL Server counterparts spend in monitoring and re-executing failed long running operations. In SQL Server, if an operation runs into an out-of-space situation, the entire operation has to be repeated after the space issue has been addressed. This not only results in wastage of time but can also hamper normal database performance, for instance, by forcing the DBA to re-run a failed batch job during normal workload hours. Thus, Oracle’s Resumable space allocation feature avoids all the pitfalls that a SQL Server user would encounter by offering a graceful way to manage out-ofspace situations. PERFORMANCE MANAGEMENT Performance Diagnostics Performance diagnosis is a very critical DBA function that traditionally has proven to be both complex and time consuming. Oracle Database 11g provides automatic performance diagnosis and monitoring technology, built inside the database server, that automates the entire performance diagnosis process and provides detailed information on the cause of performance problems and their remedies. Performance Statistics Collection Oracle Database 11g maintains a repository of information on the operation of the system called the Automatic Workload Repository (AWR). This infrastructure is a key building block for Oracle’s performance diagnostic Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 8 solution. It runs automatically to collect performance data about the operation of the Oracle system and stores it in the database. Being part of the database kernel, AWR captures the most relevant data in the most optimal fashion. It is designed to be lightweight and self-managing. Data is captured every 60 minutes and is purged after 8 days automatically. Both the frequency and length of time for which data is kept can be configured. Additionally, AWR can also be run on-demand to capture information at specific times deemed to be interesting. AWR captures all of the data required to perform a thorough system or user level performance analysis. By proactively capturing this data it obviates the need to re-run the workload for problem diagnosis purposes. AWR provides the basis for improved performance diagnostic facilities in Oracle Database 11g. It is on AWR data that the Automatic Database Diagnostic Monitor, Oracle’s performance diagnostic engine, performs analysis to identify and remedy performance problems. Comparative Performance Analysis Oracle Database 11g also provides rich reporting and baselining capabilities to facilitate comparative performance analysis. A baseline contains performance data from a specific time period that is protected from purging. This baseline can then be used to compare performance with any other time period. Typically you will create a baseline when the database is functioning within acceptable performance parameters. At any time thereafter if you notice performance divergence, you will run the AWR Compare Period Report that will tell you exactly what has changed compared to the baseline period. The report identifies all performance attributes and configuration settings that differ between two time periods, thereby enabling the quick identification of the cause of performance divergence. Active Session History (ASH) Active Session History (ASH) is another important type of statistical data collected by the Oracle kernel and saved as part of the AWR snapshot. ASH samples the current state of all active sessions, i.e., those sessions that are connected to the database and at that moment are using CPU, or waiting on a non-idle event. Active sessions are sampled every second and stored in a circular buffer in the system global area (SGA). ASH data is also written out to persistent store by the AWR snapshot processing. The Active Session History allows us to go ‘back in time’ and perform analysis in great detail and often removes the need to replay the workload to gather additional performance tracing information as part of performance diagnosis. To name a few, the ASH report allows us to diagnose transient performance problems, locking issues, long running transaction issues, expensive SQL Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 9 statements, top database CPU consumers, generalized performance issues (multi-dimensional aggregation of DB Time for skew analysis). Automatic Performance Diagnosis The Automatic Database Diagnostic Monitor (ADDM) is a feature of the Oracle Database that proactively analyzes the wealth of performance statistics available in the AWR and tells the DBA exactly what the problem is and how to fix it. Because ADDM is part of the database kernel and is not an external tool, the diagnosis is done with negligible overhead compared to traditional monitoring systems. The code instrumentation put in place to support the capabilities also enhances the functionality for real-time reactive tuning method supported by Oracle Enterprise Manager 11g. ADDM runs proactively every hour and reports on the health of the database. AWR, by default, has a retention period of 8 days for all performance related information, and this allows the DBA to diagnose any problem that occurred within the retention period time window. All a DBA has to do is to look at the ADDM report for the relevant time period and implement its advice. The key benefits provided by ADDM can be summarized as follows: 1. Automatic performance diagnostic report every hour. 2. Time-based quantification of problem impacts and recommendation benefits. 3. Identification of root cause, not just symptoms. 4. Greatly reduced need to replay workload for detailed analysis due to completeness of the data held in the AWR. In Oracle Database 11g ADDM was enhanced by offering cluster-wide performance analysis for Real Application Clusters (RAC) databases. For RAC environments ADDM analyses the RAC cluster and reports on issues that are affecting the entire database as well as its individual instances. It performs database-wide analysis of global resources, such as high-load SQL, global cache interconnect traffic, network latency issues, skew in instance response times, I/O capacity, etc. DBAs have the ability to restrict ADDM analysis to a few specified instances of a RAC cluster. This is called partial analysis ADDM and is available only through PL/SQL APIs. With ADDM for RAC, performance analysis of a RAC database becomes as simple as that of a single instance database. In Oracle Database 11g, ADDM findings can be suppressed by DBAs to filter and display only findings of interest. To better understand the impact of the findings over time, each finding has a descriptive name that facilitates search, a link to number of previous occurrences of the finding in last 24 hrs, and a link to affected instances. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 10 SQL Server has nothing remotely resembling ADDM’s self-diagnostic capabilities. All performance problems have to be manually monitored and diagnosed. As part of the performance diagnostic process for SQL Server, a DBA must the first determine which tool to use to monitor performance depending on the type of problem being investigated. For memory, disk, and CPU activity monitoring you would use the System Monitor tool of the Windows operating system. For diagnosing other kinds of problems in SQL Server a DBA must choose between: • SQL Profiler • SQL Trace • SQL Server Management Studio Activity Monitor • SQL Server Management Studio Graphical Showplan • Database Console Commands (DBCC) The next step in the diagnostic process is to identify the components to monitor. For example, if SQL Profiler is being used to trace a server, a DBA must define the trace to collect data about specific events that are relevant to his/her environment. After identifying the components to monitor, the next step is to determine the metrics for components being monitored. For example, after selecting the events to include in a trace, a DBA should choose to include only specific data about the events so as to minimize the system resources required to conduct the trace. Only after all the above steps have been completed is a DBA ready to actually monitor the server. The trace files generated as a result of the monitoring must then be manually analyzed to identify the cause of the performance problem. Not only is the SQL Server performance diagnostic process cumbersome and time-consuming, it requires an expert performance engineer to read and interpret the data collected, and provides little help in proposing a remedy for performance problems. The other limitation of SQL Server’s approach is that it is intrinsically reactive. For example, if the SQL Server system is running slow, a DBA would first have enable tracing using SQL Profiler and then rerun the workload, before any analysis of performance issues such as poorly performing SQL, can take place. In contrast, if an Oracle system is performing below expectations, a DBA simply needs to look at the current ADDM report to identify the real cause and its remedy. It is worth noting that in the latest release of SQL Server 2008 Microsoft has added a new highly promoted feature, Management Data Warehouse. It is a new centralized data repository for storing performance data with configurable performance data collection and new reporting and monitoring tools. To effectively diagnose a performance issue, DBA needs to have an awareness of the state of the system before it had a problem. Three features: Data Collector, Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 11 Management Data Warehouse (MDW) and specialized performance reports are supposed to address this problem in SQL Server 2008. The idea behind SQL Server’s MDW is far from being revolutionary. It slightly resembles Oracle’s AWR introduced in years ago in Oracle Database 10g. So once again SQL Server is playing catch up with Oracle by dublicating features from its competitor’s previous releases. MDW also has its own shortcomings compared to Oracle’s AWR/ASH framework. It does not come configured out of the box as in Oracle’s case, the amount of data it collects with default configuration can range up to 0.5GB per day per instance. The default collection sets cannot be changed through SQL Server’s central management console, Management Studio. In summary, Oracle stands out in the area of performance diagnosis compared to SQL Server. It provides a solution that is comprehensive and powerful such that even novice users can fix performance problems with ease. SQL Server, mimicing Oracle’s features from previous releases, still employs manual tuning approach that is reactive, requires skill and expertise, and is time-consuming. Identifying and Tuning High-load SQL Statements DBAs can spend a significant amount of their time identifying and tuning resource intensive SQL statements. In this area as well, Oracle automates the function completely. High-load SQL identification is performed proactively by ADDM. An Oracle DBA has to just look at the ADDM report, which is produced every hour automatically, to see if any high-load SQL statements need attention. In addition to ADDM, Oracle also captures high-load SQL statements hourly in the Automatic Workload Repository (AWR). These statements are displayed in the Top Activity page of Enterpriser Manager 11g. Identification of high-load SQL statements in SQL Server is a more involved process. A DBA has to first setting up a trace event through the SQL Profiler, enable the relevant events and then re-run the workload so that run-time statistics are captured in the trace files. Once trace files have been generated, they then have to be analyzed manually for high-load SQL identification. This is a very significant manageability issue for SQL Server administrators for a couple of reasons. First, monitoring resource consuming SQL statements is a common database administrative task and hence, spending anything more than a few minutes to get this information is often unacceptable. Second, for a busy system, the generated trace file can easily grow to a very large size quite rapidly, making it extremely difficult to extract meaningful information from it. SQL Server very clearly lags behind Oracle in automating this very important DBA task. The next step is tuning the SQL. Oracle Database 11g has the SQL Tuning and Access Advisors that automate this process as well. They take one or more SQL statements as input and invoke the query optimizer in a special tuning mode to Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 12 comprehensively tune the SQL statements. Four kinds of analysis are performed here: • Statistics Analysis: The query optimizer needs up-to-date object statistics to generate good execution plans. In this analysis objects with stale or missing statistics are identified and missing statistics collected. It should be noted that Oracle Database 11g automates the collection of statistics. As a result, this problem will generally only be seen when the automatic statistics collection feature has been deliberately disabled. • SQL Profiling: This is a new feature introduced back in Oracle Database 10g (not to be confused by the SQL Profiler tool of SQL Server, which is basically a GUI interface for trace file management) that revolutionizes the approach to SQL tuning. It eliminates the need for using optimizer hints for manually tuning a SQL statement and tunes the statement without requiring any change to the SQL code. In this analysis, a profile of a SQL statement, called a SQL Profile, is built consisting of auxiliary statistics specific to that statement. The query optimizer can sometimes generate sub-optimal execution plans due to the lack of information about the correlations between the different objects in a query. Traditionally, both Oracle and SQL Server handled this problem by manually adding query hints to the code. SQL Profile eliminates the need for this manual process in Oracle by collecting additional information using sampling and partial execution techniques. Also starting in Oracle Database 11g the SQL Tuning Advisor now does a test-execute of the SQL statements with the new execution plan for which a SQL Profile is recommended. This dramatically increases the accuracy and reliability of SQL Tuning Advisor recommendations. • Access Path Analysis: Indexes, partitions, and materialized views can tremendously enhance performance of a SQL statement by reducing the need for full table scans. In this analysis, new indexes, partitions, materialized views (mv), and mv logs that can significantly enhance query performance are identified and recommended. • SQL Structure Analysis: Problems with the structure of SQL statements can lead to poor performance. These could be syntactic, semantic, or design problems with the statement. In this analysis relevant suggestions are made to restructure the SQL statements for improved performance. By performing the afore-mentioned analysis and recommending appropriate actions, Oracle Database 11g with its SQL Tuning and Access Advisors offers a comprehensive SQL tuning solution that obviates the need for the slow, tedious and expensive manual tuning process. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 13 SQL Server has only a partial solution in this area. It offers no way of tuning a SQL other than by way of manually adding query hints, nor does it provide any help in rewriting poorly structured SQL queries. All these have to be done by hand and require deep understanding of SQL Server optimization techniques. The only area where it does assist is with the creation of clustered indexes, nonclustered indexes, and indexed views thorough its Database Tuning Advisor, which is the enhanced version of its Index Tuning Wizard. The Database Tuning Wizard offers some new options not present in the Index Tuning Wizard such as time bound tuning where the user can specify the limit the time spent by the advisor analyzing the statement, as well as the ability to perform instance wide tuning. All these tuning options and more are already part of Oracle’s SQL Tuning and Access Advisors. Although SQL Server’s Database Tuning Advisor helps in tuning physical database design, it leaves the more challenging and time consuming aspects of SQL tuning to the DBAs and application developers. The newest addition to SQL Server 2008 is plan freezing for query performance stability and predictability, providing new functionality to lock down query plans, enabling organizations to promote stable query plans across hardware server replacements, server upgrades, and production deployments. This feature is closely resembling Oracle’s Outlines that are being currently replaced by SQL Profiles, a more intelligent way of addressing poorly performing SQL statements. Besides the comprehensiveness and simplicity of Oracle’s tuning solution, another key differentiator between Oracle and SQL Server solutions is that tuning in Oracle is actually carried out by the query optimizer itself and not by an external tool trying to coerce or trick the optimizer through various approaches to generate a better execution plan. This is a significant advantage for Oracle compared to tuning tools provided by other vendor, including Microsoft, as the tuning actions performed by the query optimizer are superior in quality, reliability, and effectiveness than anything an external component can do. Automatic SQL Tuning In Oracle Database 11g, the SQL tuning process has been further enhanced and automated from the previous release. The SQL Tuning Advisor now runs automatically during the system maintenance window as a maintenance task. In each run it auto-selects high-load SQL queries in the system and generates recommendations on how to tune them. This Automatic SQL Tuning Advisor can be configured to auto-implement SQL Profile recommendations. This means that the database will automatically tune high-load SQL without requiring any user input or intervention. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 14 You can view a summary of the results of Automatic SQL Tuning over a specified period, such as the previous seven days, and can view a detailed report on recommendations made for all SQL statements processed. The Automatic SQL Tuning Advisor can be configured to run in any maintenance window or can be disabled altogether if desired. SQL Server does not offer a feature comparable to Oracle’s Automatic SQL Tuning primarily because its SQL tuning tools are limited to offering index advise only. They are not as comprehensive as Oracle’s solution and particularly their inability to help in execution plan tuning means that they cannot automate this complex task. Adding query hints manually to the application code is Microsoft’s only way of tuning SQL plans and this is not something that can ever be automated. Tuning Packaged Applications Tuning packaged applications like SAP, Siebel, or PeopleSoft, offer a different type of tuning challenge. Since customers do not have the privileges to modify application code, any time a serious performance issue is encountered in a packaged application, a customer has to log a bug with the application vendor, and then wait for several weeks, months or more, to receive a code fix for the problem. Historically, this has been the only option available to customers of database management systems. Oracle, on the other hand, offers an alternative to its customers. Its SQL Profile feature, which is part of the SQL Tuning Advisor, tunes SQL statements without changing the application code. As described earlier, SQL Profiles consist of information pertaining to the data correlations between the different tables referenced in a SQL statement, and by providing this additional information to the query optimizer, tune the SQL. Because SQL Profiles are stored in the data dictionary and not in the application code, they make it possible for Oracle to transparently tune packaged applications. Oracle is the only commercial database in the market today that has this functionality. Oracle customers do not have to file bugs nor do they have to wait to get their performance problems fixed. With SQL Profiling tuning is immediate. SQL Server does offer the ability to tune packaged applications but its solution is inherently iterative and must be done manually. Plan Guides, introduced in SQL Server 2005 and integrated into the Management Studion in SQL Server 2008, are query hints that can be associated with SQL statements without requiring direct modifications to the application code. This does make tuning of packaged applications possible but it still needs a DBA to determine the correct hints for tuning a SQL statement. This process is naturally iterative, requires deep knowledge and expertise in SQL optimization techniques, and is timeconsuming. Oracle’s solution, on the other hand is automatic, precise, and scalable. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 15 Execution Plan Stability One thing that DBAs crave is predictability, especially when it comes to query performance. The performance of a query depends on the optimality of its execution plan. The more efficient an execution plan, the better the query performance. However, cost based optimization — an optimization model used by both Oracle and SQL Server — among other factors also relies on the database environment in generating an execution plan for a query. As a result, changes in database environment such as optimizer statistics of the underlying objects, memory parameters, etc., can suddenly change the execution plan of a query, mostly improving it but sometimes making it drastically worse. This is a serious problem in SQL Server, because the database server, by default, continually regenerates optimizer statistics, hence opening up the possibility of continually changing execution plans. The only thing a DBA can do in this situation is to turn off auto-creation and update of optimizer statistics so that execution plans do not change. But this opens up a new set of problems because now the table and index statistics can become stale and the optimizer will be forced to generate execution plans based on stale data, resulting in poor optimization. SQL Server has no real solution to the issue of execution plan stability, and in fact its default behavior of continually updating optimizer statistics actually exacerbates the problem. Unlike SQL Server, Oracle provides DBAs the ability to freeze execution plans by creating SQL Plan Baselines that are part of the SQL Plan Management solution. It was introduced in Oracle Database 11g to prevent performance regressions resulting from sudden changes to SQL execution plans. It provides infrastructure for capturing, selecting, and evolving SQL executions plans. SQL performance can be affected by various changes, such as a new optimizer version or changes to optimizer statistics or parameters. SQL plan management is a mechanism that records and evaluates the execution plans of SQL statements over time and builds baselines composed of a set of existing execution plans known to be efficient. These SQL execution plan baselines are then used to preserve performance of the corresponding SQL statements, regardless of changes occurring in the system. Common usage scenarios where SQL plan management can improve or preserve SQL performance include: • A database upgrade that installs a new optimizer version. This frequently results in plan changes for a small percentage of SQL statements, with most of the plan changes resulting in either no performance change or an improvement. However, certain plan changes may cause performance regressions. The use of SQL plan baselines significantly minimizes potential performance regressions resulting from a database upgrade. • Ongoing system and data changes. These can impact plans for some SQL statements, potentially causing performance regressions. The use of SQL Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 16 plan baselines will help to minimize performance regressions and stabilize SQL performance. • Deployment of new application modules. New applications or application modules means introducing new SQL statements into the system. The application software can use appropriate SQL execution plans developed under a standard test configuration for the new SQL statements. SQL plan baselines evolve over time to produce better performance. During the SQL plan baseline evolution phase, Oracle Database 11g can be configured to routinely evaluate new execution plans by executing them in the background and then integrating the plans with better performance into SQL plan baselines. A successful verification of a new plan consists of comparing its performance to that of a plan selected from the SQL plan baseline and ensuring that it delivers better performance. Only recently in SQL Server 2008 added an equivalent capability to Oracle’s Outlines to freeze query plans. However, the comprehensive solution, taking into account underlying data evelution is still missing, thus leaving DBAs on their own to devise ways of providing consistent SQL performance. Managing Resources The ability to easily and accurately perform system and resource management is critical to maintaining application and database performance, scalability and availability. The Oracle Database Resource Manager enables administrators to align the distribution of system resources with enterprise goals by allowing allocation of CPU resources among database users and applications according to business priorities. Its ability to automatically limit the resources consumed by batch jobs helps in ensuring that such operation do not adversely impact online users in a mixed workload environment. Furthermore, Database Resource Manager also provides the ability to limit the number of concurrent long operations and prevents execution of highly resource intensive queries during certain times of the day. The Database Resource Manager, therefore, makes it extremely easy to deliver predictable service level with minimal human intervention and facilitates almost unlimited system scalability without compromising performance3. SQL Server 2008 finally released a feature similar to Oracle’s Resource Manager. The feature is named Resource Governor and should be similar in functionality to its Oracle counterpart. According to Microsoft, Resource Governor enables database administrators to define resource limits and priorities for different workloads, which enables concurrent workloads to provide consistent performance to end users. The Resource Governor, while 3 For more details, refer to paper titled Oracle Database Resource Manager at http://www.oracle.com/technology/products/manageability/database/pdf/twp03/twp_oracle% 20database%2010g%20resource%20manager.pdf Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 17 undoubtfully considered to be one of the most significant features of SQL Server 2008, is not free of shortcomings. Firstly, Resource Governer only restricts a user to utilize not more than previously allocated % of memory if it finds that remaining memory is not available but if memory is available and there are no pending workload then it will allow the user to consume more than its allowed quota. This is in place purposely to optimize the utilization of memory and avoid wastage of resources. But it can have negative effects as well, for example if some user fires a query before other users then SQL Server will start utilizing all the available memory and all other users which came afterwards will suffer the consequences. Secondly, Resource Governor is for the database engine only and not for any other services in SQL Server. It means you can not control usage of Reporting Services, Analysis Services or Integration Services. Finally, if there are multiple instances running on same machine, Resource Governor cannot manage load across these instances. CHANGE ASSURANCE IT managers face change every day coming from different directions. Corporate compliance teams require that the IT infrastructure, such as databases and operating systems, need to be kept up-to-date with the latest patch levels. Applications need to be upgraded through patches or major upgrades. These may be in response to business process changes or application bugs. Whether the enterprise is making infrastructure improvements or implementing database changes for compliance or business process reasons, Oracle Database provides a comprehensive framework for managing change in the form of its Real Application Testing solution. Load Testing “Oracle Real Application Testing reduces the time required to test changes by as much as 80%, lower testing costs by as much as 70%, mitigate risks by reducing the number of unexpected outages, and improve the quality of service for their IT operations" David Mitchell Senior Vice President OVUM Database Replay, one component of the Real Application Testing solution, enables realistic testing of system changes by essentially recreating production load environment on a test system. It does this by capturing a workload on the production system with negligible performance overhead and replaying it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload. This allows complete assessment of the impact of the change including undesired results, new contention points or performance regressions. Extensive analysis and reporting is provided to help identify any potential problems, such as new system errors or performance degradations. The ability to accurately capture the production workload results in significant cost and timesaving since it completely eliminates the need to develop simulation workloads or scripts. As a result, realistic testing of even complex applications using load simulation tools/scripts that previously took several months now can be accomplished in a few days with minimal effort with the help of Database Replay. Thus using Database Replay, businesses can lower their testing costs and still have a high degree of confidence in the overall success of the system change. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 18 SQL Server does not provide a complete load testing solution. At this point Microsoft expects users to purchase 3rd party product for this purpose. SQL Server’s Profiler provides a graphical interface to create and manage traces and then analyze and replay trace results. If the SQL Profiler is used to trace a production server, it is advisable to have the traces to be more focused and limited in time so tracing incurs the least load on your server. The problem with SQL Profiler is that it does not offer realistic load testing. It analyzes trace files generated by activities and events in the database and uses that information to re-submit the same calls to the database for testing and diagnostic purposes. The difficulty with this approach is that calls are not submitted with the original concurrency or timing. In fact all calls are submitted in serial fashion. The SQL Profiler is also unable to maintain dependencies between transactions across multiple sessions during replay. This makes the SQL Profiler not very useful because it really cannot generate a load with production characteristics for testing purposes. Moreover, SQL Profiler also does not have the kind of advanced capabilities offered by Database Replay such as increasing or decreasing speed of replay by controlling the think-time between calls. Unlike SQL Profiler, Oracle Real Application Testing’s Database Replay is a sophisticated solution that is designed to address a very key need in the market – the ability to test database systems with realistic, realworld production workloads. Ensuring SQL Performance SQL Performance Analyzer (SPA), the second component of Oracle Real Application Testing, provides functionality similar to Database Replay, but is focused on predicting problems resulting from any change that affects the SQL execution performance. SPA provides fine-grained assessment of a change on SQL execution plan and statistics by executing the SQL statements serially before and after a change and then automatically comparing their performance to determine performance changes. This enables users to assess the overall effect of change and makes it possible to remediate any negative outcome before end-users can be impacted. Being able to accurately forecast the potential impact of system changes on SQL performance enables you to tune the system beforehand in cases where some SQL statements regress, or to validate and measure the performance gain in cases where the performance of the SQL statements improves. SQL Server does not offer a solution that compares well with Oracle’s SPA. Its SQL Profiler can capture SQL statements but it does not have the ability to identify performance changes for a SQL statement, and unlike SPA it does not have any reports either that show performance divergences of application workloads. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 19 BACKUP & RECOVERY Backup Files Management A database backup consists of multiple files of different types such as data files, transaction log files, redo log files, control files, etc. As regular backups are taken over time, these files can grow in number and managing them manually can quickly become a non-trivial matter. For DBAs to manually manage backup files would require that they ensure that all the different types of files necessary for recovery are indeed backed up properly; they must have a reliable mechanism of tracking the backups in order to determine whether they have become redundant and hence, can be deleted; they must diligently monitor backup location to guarantee that sufficient space is available for new backups; etc. Even for a small system, to do this manually can be burdensome. Oracle Database 11g automates the management of all backup files by introducing the Flash Recovery Area feature. The Flash Recovery Area is a unified storage location for all recovery related files in an Oracle database. By defining one initialization parameter, DB_RECOVERY_FILE_DEST, all RMAN (Recovery Manager) backups, archive logs, control files, and data file copies are automatically written to a specified disk location that is auto-managed by Oracle. When there is space pressure, the Flash Recovery Area automatically deletes obsolete backups and archive logs that are no longer required based on retention policy specified by the DBA. If you set the retention policy to a recovery window of 7 days, then Oracle will retain all backups required to recover the database to 7 days in the past. With the Flash Recovery Area feature, Oracle Database 11g offloads yet another mundane task off the DBA workload, and makes media recovery operations faster, simpler, and more reliable. SQL Server also provides the ability to manage backup files but it does not have the same level of sophistication offered by Oracle. It has a backup wizard that backs up the relevant files but, unlike Oracle, it does not have an intelligent mechanism to clean up the backup location automatically. In SQL Server a DBA can specify a time duration beyond which all files in the backup location expire and consequently can be deleted. The approach is too simplistic to be useful. In an environment where backups consist of a mix of full and incremental backups — a backup strategy that is fairly common nowadays — SQL Server does not have the intelligence to recognize the difference between the two types of backups and will maintain the redundant incremental backups even if the system is under space pressure as long as they not older than the predefined expiration time. A DBA will actually have to manually separate the files that are needed from those that are not in case the system is running out of space and unnecessary files need to be removed. Another fact to keep in mind is that in SQL Server terminology, an instance typically consists of several databases (a SQL Server database can be considered equivalent to an Oracle tablespace.) This makes matters even more complicated because a DBA has to Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 20 not only track files needed files for a single database, but also has to correlate and maintain them across multiple (SQL Server) databases in order to ensure that all requisite files are available if a recovery operation becomes necessary. This adds to the burden of the DBA and further opens up the possibility for human errors leading to failed recovery situations. In SQL Server 2008 incremental improvements to database backup come in the form of backup compression. With the compression less disk I/O is required, less storage is required to keep backups online, and some speedup is achieved. However, the whole instrumentation of database backup still remains the same, making it an inferior solution to Oracle Database 11g. Self-contained Backups In Oracle, the backups are complete and fully self-contained. A DBA can recover an Oracle database from any situation as long as there is a good backup of the database. This is not the case in SQL Server. If the SQL Server system database, msdb, is lost, a DBA cannot recover the system without undergoing a frantic search for the original install CD even though he/she may have performed regular backups. This is because SQL Server backups are not selfcontained. A DBA must first manually recreate the system database, msdb, from the original install CD using the command line utility, rebuildm.exe4. The recovery of application databases can be started only after the master database has been recovered. This makes the complete recovery of a SQL Server instance quite complex and highly unintuitive unlike Oracle where the same operation can be performed simply using the recovery wizard. Even in this most critical DBA function of recovering a down database instance, SQL Server poses a serious manageability impediment to its DBAs. Intelligent Recovery Oracle Database further demonstrates its superior manageability and reliability with the Data Recovery Advisor (DRA) tool. DRA automatically diagnoses data failures, determines and presents appropriate repair options, and executes repairs at the user's request. The DRA presents recovery options in an intelligent manner so that administrator’s time spent hunting down the root cause of a database failure and developing an action plan declines dramatically. DRA provides Oracle with the following advantages as compared to the SQL Server repair techniques: 4 • DRA can detect, analyze and repair data failures early, thus limiting damage cased by corruptions • Automatic failure diagnostics assesses symptoms of data failures, correlates them to problem statements and reports these findings to the user SQL Server Books Online: How to rebuild the master database. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 21 • In case of multiple failures the right sequence of repairs is not always obvious. DRA automatically determines the best repair options and runs checks to make sure these options are feasible in the environment • Execution of a data repair can be complex and error-prone. DRA automates this process and in addition verifies its success. SQL Server’s manual process of rebuilding the transaction log, running repair to fix up any corruptions, and ensuring the logical integrity of data is not broken, is just too complex, error-prone and time-consuming. This manual process forces many DBAs to simply rebuild the transaction log and continue with regular operations in the interest of maintaining SLAs – no checks, no repairs, no rootcause analysis. 5 Recovery from Human Errors Numerous availability studies have highlighted human error as one of the most prominent causes of application outage. While it is possible to develop safeguards against hardware and software failures, it is nearly impossible to insulate a system from human mistakes such as accidentally deleting critical data. Once again, only Oracle provides easy and completely non-intrusive options to recover from such failures leveraging its Flashback technology features. The Flashback technology provides a set of new features to view and rewind data back and forth in time. The Flashback features offer the capability to query past versions of schema objects, query historical data, perform change analysis or perform self-service repair to recover from logical corruptions while the database is online. With the Oracle Database Flashback technology, you can indeed go back in time for as long as needed to undo your mistakes! Recovery of Dropped Table Oracle’s Flashback Drop feature allows instant recovery of a table dropped by mistake. When a user drops a table, Oracle automatically places it into the “Recycle Bin”. The Recycle Bin is a virtual container where all dropped objects reside. Objects remain in the Recycle Bin until either Oracle needs to reclaim the space in order to accommodate new data or the owner of the dropped objects decides to permanently remove them using the new PURGE command. As long as a dropped object remains in the recycle bin, it can be recovered using a simple SQL statement: FLASHBACK TABLE <table_name > TO BEFORE DROP; 5 “Secrets of Fast Detection and Recovery from Database Corruptions”, Paul S. Randall, session from TechEd 2006. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 22 Recovery from Logical Data Corruptions Due to user errors, e.g., a batch job being run twice, logical corruptions can occur in the database. In such instances, the most common remedy is to restore the database to a time prior to the action that caused the corruption took place. Traditionally, this meant first restoring the database from a backup and then performing point-in-time media recovery on it. This form of recovery can be tedious and usually takes a long time. This is the only option available in SQL Server. Oracle, on the other hand, offers the traditional media recovery option as well as a distinctly faster and simpler solution based on its Flashback technology. Flashback supports recovery at any level of granularity including database, table, transaction, and row level. • Flashback Database: For widespread data corruptions, this offers the best option. Flashback Database quickly rewinds an Oracle database to a previous time specified by the user using a special type of file called Flashback Log. This file captures previous images of the data blocks as they change over time. The bigger this file, the more the database can be rewound back. DBAs can size this file based on the recovery requirements of their business. Recovering a database using the FLASHBACK DATABASE command has no down time associated with restoring a backup, and makes recovery from logical data corruptions caused by human errors very easy and fast. • Flashback Table: For data corruptions that affected only a small set of tables, this offers a more targeted recovery option. Flashback Table provides the DBA the ability to recover a table or a set of tables to a specified point in time in the past quickly and online. It restores the tables while automatically maintaining its associated attributes such as the current indexes, triggers and constraints, and does not require the DBA to find and restore application specific properties. Flashback Table alleviates the need for performing more complicated recovery operations on the entire database. • Flashback Transaction: This feature allows more granular recovery by reversing the specific transactions that caused the corruption. It provides a mechanism to view changes made to the database at the transaction level and reversing them. It causes the database to rewind to a state as if the transaction, and any transactions that could be dependent on it, never occurred. • Flashback Versions Query: This allows the recovery at row level. It provides a mechanism to view changes made to the database over time at the row level and gives the user to ability to selectively undo any undesired changes caused by human errors. • Flashback Data Archive (Total Recall): This technology provides an extremely secure, efficient, easy to use and application transparent Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 23 solution managing historical data as well as a centralized, secure queryable historical data store in the most resource efficient manner while reducing compliance costs with regulations such as SOX, HIPAA and BASEL-II. The Flashback technology is unique to Oracle and SQL Server has nothing comparable to it. In SQL Server the remedy for all the above-mentioned human errors is a full database point-in-recovery. This form of recovery is an offline operation, is slow, and results in data loss. In contrast, Oracle’s Flashback technology provides the user with a wide range of options for recovering from human errors without sacrificing any data or compromising system availability. This technology is very precise in its ability to repair damage, is very efficient, and most notably is fast and easy to use. INSTALLATION AND CONFIGURATION Instance Creation Instance creation is among the most basic and important DBA functions. Oracle has a simple, easy-to-use GUI tool, Database Configuration Assistant (DBCA), for creating database instances. DBCA performs all the necessary steps for the user with minimal input and eliminates the need to plan in detail the parameters and structure of the database. Furthermore, DBCA also makes recommendations about certain database settings based on user input and thus helps database administrators make correct decisions for optimal database configuration depending on whether it will be used for Data Warehousing, OLTP or mixed workload applications. In SQL Server, on the other hand, every instance creation requires a complete new installation with all the binaries and scripts. This is in contrast to Oracle where multiple instances on the same machine share binaries and other relevant files. Consequently, any time multiple instances are needed on a single machine, a SQL Server DBA has to contend with considerable amount of wasted space, as each instance needs its own private binaries and scripts. In SQL Server 2008 Microsoft claims to have re-engineered the installtion process for the better. These improvements separate the installation of the bits on the computer from the configuration of the SQL Server software, which enables organizations and software partners to provide recommended installation configurations. However, during configuration of the SQL Server software no help in setting some database parameters is provided, thus adding to the workload of its DBAs. Database Duplication Creating a standard definition for enterprise wide databases is a fairly common practice. Having all databases conform to a standard greatly simplifies their management by allowing the use of uniform administrative and monitoring Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 24 procedures. DBA’s also often want to duplicate databases for the purpose of setting up development and test environments. Oracle database templates, which allow for storing database definition in XML format, make both these tasks extremely simple. The template definition includes all characteristics of the database, such as initialization parameters, redo log settings, etc., and can be used to create identical databases on local or remote machines. There are two kinds of templates, those that contain only the structure of a database, and those that contain both the structure and the data. This functionality allows administrators to either create a new structurally identical database or clone a database along with its data. A template can be created by reverse engineering an existing database. This ability is extremely useful since it saves administrators a significant amount of time and effort in creating and testing scripts for duplicating a database. SQL Server has no comparable feature to this. The only way to create a new SQL Server database is to use the Copy Database Wizard. There are many drawbacks to this method. First, in this method the database structure alone cannot be duplicated; instead both the data and the database have to be copied. Second, the database being copied must not have any active sessions on it, that is, the database must be offline to users6. If the SQL Server DBA wants to duplicate just the structure of the database, which is the more common case, the database and all its objects have to be recreated manually using scripts or the GUI tool. This is a cumbersome and error-prone method and, is certainly not comparable to the functionality provided by Oracle. Installation Cloning The Oracle Enterprise Manager provides users with a convenient and flexible way to intelligently duplicate Oracle software installations (a.k.a. Oracle Homes) across hosts. Guided by an intuitive wizard, users can designate an Oracle software home on a source system and select one or more destination hosts to which they want to clone that home. Via “multicasting”, multiple new installations can be created in a single operation. The only requirement is that Enterprise Manager agents are present on all systems involved. The cloning of an Oracle home is performed in an intelligent manner, i.e. environment-dependent home properties such as the host name, IP address or listener settings are automatically adjusted during the cloning process. Furthermore, the Oracle Universal Installer (OUI) inventory that keeps track of all Oracle installations on a system is automatically updated as part of the cloning process. Cloning operations can be scheduled as Enterprise Manager jobs to be run during off-hours in order to minimize network load. 6 SQL Server 2008 Books Online, Administering the Database Engine, Using the Copy Database Wizard. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 25 SQL Server does not support software cloning. Users have to manually install SQL Server software on all systems and then have to separately copy the database in the new location using the Database Copy wizard feature. The inability to clone software installations is yet another deficiency in SQL Server and it only serves to exacerbate the manageability challenge of its users. SOFTWARE MAINTENANCE Patching Administrators spend a significant portion of their time in software maintenance operations such as applying software patches. Being able to quickly identify and apply relevant patches on the system is key to maintaining system reliability and performance. Oracle Enterprise Manager provides administrators with powerful new patch management tools. The Critical Patch Advisor is a new tool that alerts users of critical patches issued by Oracle and immediately identifies those systems across the enterprise that may require a new patch. The administrator can then decide whether and when to apply the patch. This functionality is possible because Oracle collects detailed configuration information about all databases being managed across the enterprise. Data collected includes information on: • Host hardware specs including number and clock speed of the CPUs, memory, hard disk and network information • Operating system parameter settings, file system information and installed packages and patches • Oracle software installed on the host including version and component information, patch sets and interim patches, as well as software configuration settings This comprehensive system inventory is stored in the Enterprise Manager Repository and is the foundation for many of Oracles’ configuration management solutions including software maintenance. By default, the configuration data is refreshed daily. In addition, users may refresh this data at any time with the click of a button. The next step after being alerted to a patch is its application. This function is facilitated by another tool, the Patch Wizard. This tool searches, downloads and applies patches. Using the Patch Wizard, all patches applicable to a specific target database can be searched or, if desired, the administrator can query all the databases in the enterprise that are candidates for a specific patch. Once the necessary patch is located, Enterprise Manager can be used to download and deploy it. Optionally, Enterprise Manager can execute an end-user provided script to install the patch. Each of these steps allows for quicker application of Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 26 patches across the customer's enterprise with minimal effort on behalf of the administrator. Enterprise Manager Database Control 11g has an auto-patching capability which enables it to patch itself. This patching is supported through customizable deployment procedures. The workflow covers the entire patching cycle right from getting the patches from Metalink, staging the patches, shutting down the services, installing the patches and brining the database upOracle Database 11g includes feature-based patch bundle advisories. It correlates the patch metadata with the feaures being used (as opposed to installed). This can save data centers a lot of unwanted downtime by avoiding application of patches that are not necessary, based on current usage of the product. SQL Server 2008 offer little to no solution in this area. It puts the burden on the administrator to determine what patches are needed and offers little help in their application via the recently introduced policy-based management framework, which requires setup effort. For proactive administrators this means that they either scan the Microsoft web site constantly for critical patches or call their support organization on a regular basis to find out whether there are some patches out there that they should apply. Others administrators would probably just wait for a problem to occur before they act to counter the damage and patch the problem. This not only occupies administrator time unnecessarily but potentially also impacts availability, reliability, and performance of a system. Fault Diagnostics Oracle Database includes an advanced fault diagnostic infrastructure for preventing, detecting, diagnosing, and resolving problems. Critical errors that can affect the health of the database are targeted in particular. When a critical error occurs, it is assigned an incident number and diagnostic data for the error is immediately captured and tagged with this number. The data is then stored in the Automatic Diagnostic Repository (ADR)—a file based repository outside the database—where it can later be retrieved by incident number and analyzed. At any point the DBA, with the click of a button, can automatically package all diagnostic data (traces, dumps, health check reports, SQL test cases, and more) pertaining to a critical error and package the data into a zip file suitable for transmission to Oracle Support with the help of the Incident Packaging Service feature. The Enterprise Manager Support Workbench, the interactive interface to the diagnostic infrastructure of Oracle Database, provides an easy-to-use interface that presents database health-related incidents on the system to the DBAs in a timely manner along with information on how to manage the incidents. It also assists DBAs in viewing diagnostic information from multiple Oracle products (such as Net, clients, ASM, Oracle RAC, etc.), running health checks, packaging incident data to Oracle Support, and managing incidents. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 27 The Support Workbench significantly reduces problem resolution time for customers by providing a simple workflow interface to view and diagnose incident data and package it for Oracle Support. SQL Server does not offer a competing solution for fault diagnostics and resolution. Once a database error occurs there is no tool that automatically collects the necessary context for the Microsoft support professionals to resolve the issue efficiently. With Oracle if an appropriate patch for the problem at hand exists it will automatically be downloaded and applied. In case of SQL Server the problem resolution time and effort are dramatically longer. CROSS-PLATFORM PORTABILITY One of the major and unique strengths of Oracle’s architecture is its portability to different platforms. Oracle is available on practically all platforms and it is by far the most portable database than any of its competitors. This means that an Oracle database on Unix has the same code base as the one running on a Windows OS, ensuring that the management of the Oracle database on one platform is no different than on another. This makes it possible for an Oracle DBA to manage databases on any and all platforms without additional training. Another benefit of extensive portability is that an application can be designed independent of the platform with the sole objective of addressing the business requirements in the best possible manner. The same cannot be said about SQL Server as it runs only on the Windows platform. As a result, any future growth of a business is limited to the Windows platform. Outgrowing Windows means a huge investment of time and money to upgrade all the hardware and software systems to Unix, migrate the data to a more scalable database, rewrite all the applications to run against the new database, and hire or retrain DBAs. With Oracle, you never need to worry about outgrowing your hardware, since Oracle data and applications are fully compatible and portable across all major hardware and operating systems platforms. SCALABILITY One of Oracle’s greatest assets is its scalability. Oracle databases can scale seamlessly from hundreds to thousands of users. In addition, Oracle Real Applications Cluster (RAC) offers the most transparent cluster database solution from a deployment and management perspective. Nodes can be added to a RAC database on the fly with no impact on existing nodes. Also, since all nodes in a RAC environment access a single database, addition or removal of nodes does not generate any additional tasks for a DBA. The most unique aspect of RAC, however, is that unlike other database products (including SQL Server) where an application has to be rewritten for a clustered environment, moving from a Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 28 single node to a RAC environment requires absolutely no application change thanks to its patented Cache Fusion technology that was introduced in Oracle9i.7 Microsoft’s recommended implementation of a scalable model for SQL Server is either in a distributed database environment, or in a federated database architecture, where many independent databases are connected together with no common data dictionary while a single application accesses data across all these databases. Imagine a simple task such as adding a node in SQL Server’s federated architecture environment. A DBA or system administrator will have to do all of the following: • Add hardware • Configure new instance (set instance-specific parameters, etc.) • Create new database • Disconnect all users • Unload data from existing tables • Redefine partitioned tables and indexes • Redefine triggers on partitioned or replicated tables • Redefine distributed partitioned views • Reload the data to spread it across a larger number of partitions • Reconnect all users. This represents a highly complex and elaborate set of management tasks that involve unloading and reloading of data, redefining of views, modification of triggers, etc. Furthermore, when these tasks are being performed all the databases have to be unavailable for the entire duration of the operation. Compare this to Oracle Real Application Clusters. The administrator needs to do the following two tasks only when adding a node: • Add hardware • Configure new instance (set instance-specific parameters, etc.) The DBA did not have to unload and reload data, change any schema definitions, nor was the system taken offline at all. Thus, when compared to Oracle, SQL Server’s scalability solution is a manageability ordeal even for basic tasks. Another point to note about SQL Server is that the complexity of management goes up dramatically when there are tens of databases to manage, administer, 7 For more details on RAC and Cache Fusion, refer to the white paper titled “Oracle Real Application Clusters: Cache Fusion Delivers Scalability”, which can be found at http://otn.oracle.com/products/oracle9i/pdf/cache_fusion_rel2.pdf. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 29 maintain, backup and upgrade. As an example, to achieve a high TPC-C benchmark Microsoft had to use 32 different databases. Thus, Microsoft’s approach is to distribute rather than contain complexity. Managing so many databases is quite an unappealing scenario for DBAs when compared to implementing and administering a single, more scalable database like Oracle. Brian Moran, SQL Server Magazine editor says it all: “Microsoft sells ease of use and hesitates to point out that a SQL Server environment is often just as complex — and expensive — to manage as its UNIX counterparts.”8 Oracle’s scalability advantage is not restricted to the multi-node RAC model only. Being the most portable database in the market, it runs on all major OS platforms including large SMP boxes. SQL Server, on the other hand, is restricted to the Windows operating system. This means that SQL Server’s scalability within a box is restricted to the smaller Windows machines, while Oracle has no such limitation as it runs on all major platforms. It can easily scale on large 64-cpu SMP boxes without any problem. From a manageability perspective this is a great advantage because as the applications grow over time, an Oracle DBA can address the growth by just adding more CPUs to the machine, whereas in the case of SQL Server an application can quickly outgrow the smaller Windows machines. This leaves the DBA with no option but to add more machines and then hope that the application can be redesigned for a federated architecture. Even when possible, this is an extremely painful and time-consuming task. To overcome the lack of scalability of SQL Server, a DBA has to administer an environment that is complex and virtually unmanageable. Simple tasks like adding a new node can involve very elaborate redistribution of application data requiring deep understanding of the application logic and the database layout. These are just some of the manageability issues that a SQL Server DBA has to contend with on a regular basis, whereas Oracle’s scalable architecture makes all these non-issues for its DBA. CONCLUSION Oracle Database 11g is not only rich in functionality but is also easier to manage than SQL Server 2008. With management costs of software quickly outpacing acquisitions costs, ease-of-use or manageability has become a most crucial factor affecting purchase decisions. Oracle is the only solution in the market that offers the best of both worlds. SQL Server 2008 lacks many of the basic management functionality critical for effective database management of mission critical applications. So far SQL Server has been following a well-adopted delayed catch-up strategy, duplicating, with various success, certain features from Oracle’s past releases. Because of that SQL Server DBAs are often left with no choice but to undertake cumbersome workarounds that are unintuitive, 8 SQL Server Magazine UPDATE News Editor, Jan. 2001. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 30 complex, and, quite frequently, a management nightmare. Oracle’s comprehensive and structured approach to manageability will only further its lead over its competitors in the future releases. Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability Page 31 Technical Comparison of Oracle Database 11g and SQL Server 2008: Focus on Manageability December 2008 Author: Sergey Koltakov, Mughees Minhas Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright © 2008 Oracle Corporation All rights reserved.
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement
© 2021