Technical comparison of Oracle Database 11 g and Microsoft SQL Server 2008: Focus on Manageability

Technical comparison of Oracle Database 11 g and Microsoft SQL Server 2008: Focus on Manageability
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.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement