] Enforcing conflict serializability

[edit] Testing conflict serializability

Schedule compliance with conflict serializability can be tested with the

precedence graph (serializability graph, conflict graph) of the schedule for
committed transactions. It is the directed graph representing precedence
of transactions in the schedule, as reflected by precedence of conflicting
operations in the transactions.

In the precedence graph transactions are nodes and precedence

relations are directed edges. There exists an edge from a first
transaction to a second transaction, if the second transaction is in
conflict with the first (see Conflict serializability above).
Comment: In many text books only committed transactions are
included in the precedence graph. Here all transactions are
included for convenience in later discussions.

The following observation is a key characterization of conflict

serializability:

A schedule is conflict-serializable if and only if its precedence graph

of committed transactions (when only committed transactions are
considered) is acyclic. This means that when committed
transactions create a cycle in the precedence graph, conflict-
serializability is violated.

Cycles of committed transactions can be prevented by aborting an

undecided (neither committed, nor aborted) transaction on each cycle in
the precedence graph of all the transactions, which can otherwise turn
into a cycle of committed transactions (and a committed transaction
cannot be aborted). One transaction aborted per cycle is both required
and sufficient number to break and eliminate the cycle. The probability
of cycle generation is typically low, but nevertheless, such a situation is
carefully handled, since correctness is involved. Transactions aborted
due to serializability violation prevention are executed again immediately.

Serializability enforcing mechanisms typically do not maintain a

precedence graph as a data structure, but rather prevent or break cycles
implicitly (e.g., SS2PL below).
SQL*PLUS is a command line tool where as SQL and PL/SQL language
interface and reporting tool. Its a command line tool that allows user to
type SQL commands to be executed directly against an Oracle database.
SQL is a language used to query the relational database(DML,DCL,DDL).
SQL*PLUS commands are used to format query result, Set options, Edit
SQL commands and PL/SQL.

SQL * Plus is an environment

.
Keywords can be abbreviated.

SQL is a Query Language.

Keywords cannot be abbreviated.

SQL, SQL*Plus, PL/SQL: What's the Difference?

This question has bedeviled many people new to Oracle. There are
several products with the letters "SQL" in the title, and these three,
SQL*Plus, SQL, and PL/SQL, are often used together. Because of this,
it's easy to become confused as to which product is doing the work and
where the work is being done. This section briefly describes each of these
three products.

SQL

SQL stands for Structured Query Language. This has become the lingua
franca of database access languages. It has been adopted by the
International Standards Organization (ISO) and has also been adopted by
the American National Standards Institute (ANSI). When you code
statements such as SELECT, INSERT, UPDATE, and DELETE, SQL is the
language you are using. It is a declarative language and is always
executed on the database server. Often you will find yourself coding SQL
statements in a development tool, such as PowerBuilder or Visual Basic,
but at runtime those statements are sent to the server for execution.
PL/SQL

PL/SQL is Oracle's Procedural Language extension to SQL. It, too,

usually runs on the database server, but some Oracle products such as
Developer/2000 also contain a PL/SQL engine that resides on the client.
Thus, you can run your PL/SQL code on either the client or the server
depending on which is more appropriate for the task at hand. Unlike
SQL, PL/SQL is procedural, not declarative. This means that your code
specifies exactly how things get done. As in SQL, however, you need
some way to send your PL/SQL code up to the server for execution.
PL/SQL also enables you to embed SQL statements within its procedural
code. This tight-knit relationship between PL/SQL, SQL, and SQL*Plus is
the cause for some of the confusion between the products.

SQL*Plus

SQL*Plus is an interactive program that allows you to type in and

execute SQL statements. It also enables you to type in PL/SQL code and
send it to the server to be executed. SQL*Plus is one of the most common
front ends used to develop and create stored PL/SQL procedures and
functions.

What happens when you run SQL*Plus and type in a SQL statement?
Where does the processing take place? What exactly does SQL*Plus do,
and what does the database do? If you are in a Windows environment
and you have a database server somewhere on the network, the following
things happen:

1. SQL*Plus transmits your SQL query over the network to the

database server.
2. SQL*Plus waits for a reply from the database server.

3. The database server executes the query and transmits the results
back to SQL*Plus.

4. SQL*Plus displays the query results on your computer screen.

Even if you're not running in a networked Windows environment, the

same things happen. The only difference might be that the database
server and SQL*Plus are running on the same physical machine. This
would be true, for example, if you were running Personal Oracle on a
single PC.

PL/SQL is executed in much the same manner. Type a PL/SQL block

into SQL*Plus, and it is transmitted to the database server for execution.
If there are any SQL statements in the PL/SQL code, they are sent to the
server's SQL engine for execution, and the results are returned back to
the PL/SQL program.

The important thing is that SQL*Plus does not execute your SQL queries.
SQL*Plus also does not execute your PL/SQL code. SQL*Plus simply
serves as your window into the Oracle database, which is where the real
action takes place. Figure 1.1 illustrates this relationship

Relationship of SQL*Plus, PL/SQL, and Oracle.

Several other tools besides SQL*Plus can serve as your window to the
database. Server Manager, which has an interface similar to SQL*Plus, is
one such tool, although Oracle plans to stop supporting it sometime in
the future. If you have Oracle Enterprise Manager installed, you should
take a look at SQLPlus Worksheet. SQLPlus Worksheet is a GUI tool that
is fully compatible with SQL*Plus but is much easier to use. If you are a
Developer 2000 programmer, you'll have access to Oracle's Procedure
Buildera tool designed for developing and debugging PL/SQL code.
You'll read more about SQLPlus Worksheet and Procedure Builder later
in this chapter.

SQL*Plus is used for most of the examples in this book because of its
universal availability to developers. It is perhaps still the most widely
used tool to develop, test, and create PL/SQL stored subprograms and
SQL queries.

Ans 2: Some short notes are explained above in ans 1.

PL/SQL:

PL/SQL (Procedural Language/Structured Query Language) is Oracle

Corporation's proprietary procedural extension to the SQL database
language, used in the Oracle database. Some other SQL database
management systems offer similar extensions to the SQL language.
PL/SQL's syntax strongly resembles that of Ada, and just like Ada
compilers of the 1980s the PL/SQL runtime system uses Diana as
intermediate representation.

The key strength of PL/SQL is its tight integration with the Oracle
database.

PL/SQL is one of three languages embedded in the Oracle Database, the

other two being SQL and Java.

PL/SQL supports the following: variables, conditions, arrays, and

exceptions. Implementations from version 8 of Oracle Database onwards
have included features associated with object-orientation.
The underlying SQL functions as a declarative language. Standard SQL
unlike some functional programming languagesdoes not require
implementations to convert tail calls to jumps. The open standard SQL
does not readily provide "first row" and "rest of table" accessors, and it
cannot easily perform some constructs such as loops. PL/SQL, however,
as a Turing-complete procedural language that fills in these gaps, allows
Oracle database developers to interface with the underlying relational
database in an imperative manner. SQL statements can make explicit in-
line calls to PL/SQL functions, or can cause PL/SQL triggers to fire upon
pre-defined Data Manipulation Language (DML) events.

PL/SQL stored procedures (functions, procedures, packages, and

triggers) performing DML will get compiled into an Oracle database: to
this extent, their SQL code can undergo syntax-checking. Programmers
working in an Oracle database environment can construct PL/SQL
blocks of functionality to serve as procedures, functions; or they can
write in-line segments of PL/SQL within SQL*Plus scripts.

While programmers can readily incorporate SQL DML statements into

PL/SQL (as cursor definitions, for example, or using the SELECT ... INTO
syntax), Data Definition Language (DDL) statements such as CREATE
TABLE/DROP INDEX etc. require the use of "Dynamic SQL". Earlier
versions of Oracle Database required the use of a complex built-in
DBMS_SQL package for Dynamic SQL where the system needed to
explicitly parse and execute an SQL statement. Later versions have
included an EXECUTE IMMEDIATE syntax called "Native Dynamic SQL"
which considerably simplifies matters. Any use of DDL in an Oracle
database will result in an implicit COMMIT. Programmers can also use
Dynamic SQL to execute DML where they do not know the exact content
of the statement in advance.

PL/SQL offers several pre-defined packages for specific purposes. Such

PL/SQL packages include:

DBMS_OUTPUT - for output operations to non-database

destinations
DBMS_JOB - for running specific procedures/functions at a
particular time (i.e. scheduling)
DBMS_XPLAN - for formatting "Explain Plan" output
 DBMS_SESSION - provides access to SQL ALTER SESSION and
SET ROLE statements, and other session information.
DBMS_METADATA - for extracting meta data from the data
dictionary (such as DDL statements)
UTL_FILE - for reading and writing files on disk
UTL_HTTP - for making requests to web servers from the database
UTL_SMTP - for sending mail from the database (via an SMTP
server)

Oracle Corporation customarily adds more packages and/or extends

package functionality with each successive release of Oracle Database.

Ans 3:

What Is T-SQL?
In the early 1970s, IBM developed SQL (short for Structured Query
Language) for use in its original relational database product named
System R. SQL has one purpose: to query and manipulate data.

T-SQL (short for Transact SQL) is an extension to SQL that adds extra
programming functionality and control mechanisms. T-SQL is the query
language used by not only Microsoft SQL Server but also other database
products, such as Sybases Adaptive Server Enterprise (ASE).

The Query Tools

Depending on which version of SQL Server youre running, youll have
different query tools available. In SQL Server 2000, the tools are Query
Analyzer and Enterprise Manager. Query Analyzers primary purpose is
to execute the T-SQL commands that you write. Enterprise Manager is
more of an administrative tool. It has excellent built-in query-building
tools, but they can be overwhelming for uninitiated users.

In SQL Server 2005, SQL Server Management Studio (SSMS) replaces

Query Analyzer and Enterprise Manager. The component of SSMS that
you use to execute queries is called the Query Editor. All the T-SQL
commands presented in this course will work in both SQL Server 2005s
Query Editor and SQL Server 2000s Query Analyzer.

Retrieving Data with SELECT

A database stores data in tables. Data in a table is broken into columns
and rows. An Employee table, for example, would contain information
about employees. The columns in the Employee table might include
EmployeeNumber, FirstName, LastName, Age, and Salary. A row of data
in the Employee table would contain data pertaining to a specific
employee.

The data stored in a database is useless without the ability to retrieve

and view it. T-SQLs SELECT statement is what you use to get data out of
the database and onto your screen. Querying databases with a SELECT
statement is like shopping for groceries with a grocery list. Think of the
database as a grocery store in which the database tables are the shelves
and the data is the items on the shelves. Your assistant (i.e., Query
Editor or Query Analyzer) will be doing the grocery shopping for you, so
you write a grocery list (i.e., a SELECT statement) that describes the
items you need and contains instructions on where to find those items
on the shelves and how you want the items delivered. Your assistant
goes to the grocery store and diligently travels up and down the aisles,
searching the shelves for the items that you specified, carefully following
your instructions. The assistant also follows your instructions on how to
pack the items in a bag (i.e., a result set) before delivering that bag to
you. If all the items were in stock, your bag will contain everything you
need.

Now that you know how the SELECT statement is used, lets take a look
at what it contains. A basic SELECT statement consists of two parts and
looks like Part1 is where you specify the columns that contain the data
you need. Part2 is where you specify the table or view containing those
columns. The columns that you select must exist in specified table or
view; otherwise, an error will result.

The simplest form of the SELECT statement tells the Query Editor or
Query Analyzer to give you the data in all the columns in the specified
table or view. For example, if you type

SELECT * FROM sysobjects

in the Query Editor or Query Analyzer, highlight the code, then press
CTRL-E, youll see all the data stored in the sysobjects table in the result
pane. The asterisk (*) is a wildcard that tells the Query Editor or Query
Analyzer to retrieve the data from all the columns in the table.
In the instructions I just gave, note that I had you highlight the code
prior to executing it. Highlighting a code snippet ensures that only that
code is executed. Otherwise, all the code in the query window will be
executed. Also note that I told you to press CTRL-E. Alternatively, you
can press F5 or click the Execute button on the toolbar to execute the
code. I prefer using CTRL-E, though, because it goes hand-in-hand with
CTRL-D and CTRL-T, which let you put the results in a grid format or
text format, respectively. Sysobjects is a system table that exists in every
SQL Server database and contains entries for each database object
within that database. If you dont specify a database when establishing a
connection to SQL Server, youre automatically connected to the default
database, which is the master database (unless you changed this
default). For the purposes here, Im assuming youre connected to the
master database. Typically, you wouldnt spend much time querying
tables in the master database. However, since all instances of SQL Server
have a master database, it serves as a good place to run the sample
queries.

Ordering and Renaming Columns

If you dont want data from all the columns in a table, you can specify
the column or columns you want. When you have multiple columns, you
need to separate them with commas. The order of the columns in the
SELECT statement determines the order of the columns in the result set.
For example, when I run the query

SELECT name, type, crdate

FROM sysobjects

I get the result set that Figure 1 shows. For space reasons, I included
only three of the returned rows and trimmed the length of the columns. (I
also shortened and trimmed the data in the other sample result sets
shown here.) If you try this query, dont be surprised if you get different
results. The data returned depends on which SQL Server version youre
using and what your tables contain. Having different data doesnt matter
at this point because the focus is on the mechanics of the query itself
and not on the details of the data returned.

If you want the result set to display different names for the columns, you
can use the AS clause in a SELECT statement. For example, if you want
to retrieve the name, type, and crdate columns but want to name them
ObjectName, ObjectType, and Creation- Date, respectively, you can run
the query

SELECT name AS ObjectName,

type AS ObjectType,
crdate AS CreationDate
FROM sysobjects

Figure 2 shows the results from this query.

Filtering Results with WHERE

If you dont want all the data from a column returned, you can use a
WHERE clause with operators to filter the result set to get exactly what
you need. For example, in the last two queries, all the data (which in this
case are objects) in the three columns are being returned. If you want
only objects of type U (which stands for user table) returned, youd run
the query

SELECT name AS ObjectName,

type AS ObjectType,
crdate AS CreationDate
FROM sysobjects
WHERE type = U

In this query, the = operator is being used to see whether each value in
the type column is equal to U. If so, that object is returned in a result set
that will look something like the one in Figure 3. The = operator is one of
several comparison operators you can use in a WHERE clause, as Table
1 shows.

You can combine comparison operators with logical operators to further

filter result sets. Table 2 outlines the logical operators that you can use
in a WHERE clause. For example, suppose you want to see all objects
except stored procedures (which have the object type of P) and system
tables (which have the object type of S). You can use the <> and AND
operators in the query

SELECT name AS ObjectName,

type AS ObjectType,
crdate AS CreationDate
FROM sysobjects
WHERE type <> P
AND type <> S

As Figure 4 shows, the returned result set contains only those objects
that meet the criteria.

Lets look at a more complex example that combines multiple comparison

and logical operators. Suppose you want to see all the stored procedure
objects whose names begin with sp. You also want to see all the stored
procedure objects that were created in the year 2000. To get this data,
you can run the query

SELECT name AS ObjectName,

type AS ObjectType,
crdate AS CreationDate
FROM sysobjects
WHERE (type = P AND
name LIKE sp%)
OR (crdate
BETWEEN 2000-01-01
AND 2000-12-31)

The first component(type = P AND name LIKE sp%)selects only

those objects that are stored procedures (type = P) and have names
beginning with sp (name LIKE sp%). The second component(crdate
BETWEEN 2000-01-01 AND 2000-12-31)selects any object that was
created between January 1, 2000, and December 31, 2000. Note that
parentheses separate these two components, which are part of a large
OR operation. The parentheses indicate which logical operators to
evaluate first. Figure 5 shows sample results from this query. If you
execute this query, consider running it against one of your own
databases so that the results will be more meaningful to you.

Sorting Results with ORDER BY

Besides using a WHERE clause in a SELECT statement to filter results,
you can use an ORDER BY clause to sort results. By default, results are
sorted in ascending order (i.e., lowest value to highest value). If you want
the results sorted in descending order (i.e., highest value to lowest value),
you must specify the keyword DESC. Optionally, you can use the
keyword ASC to explicitly specify that you want the results sorted in
ascending order.

For example, suppose you want a querys returned objects to be sorted

alphabetically by object type, then by their creation date, with the most
recent date first. The query would look like

SELECT name AS ObjectName,

type AS ObjectType,
crdate AS CreationDate
FROM sysobjects
ORDER BY type ASC,
crdate DESC

and the result set would look like that in Figure 6.

You shouldnt use the ORDER BY clause in views, derived tables, inline
functions, and subqueries, unless you also use the TOP command.
Otherwise, you might get an error message. (If youd like to know why the
sometimes error occurs, see the Microsoft article at
support.microsoft.com/kb/841845.)

Limiting Results with TOP

To reduce strain on the server and network resources (not to mention
your own workstation), you should limit the number of rows returned in
a result set, especially if youre querying a large database just to explore
it. You can use the TOP command to limit result sets. For example, the
query

SELECT TOP (5)

type AS ObjectType,
crdate AS CreationDate
FROM sysobjects
ORDER BY crdate DESC

displays the first 5 rows returned by the ORDER BY operation.

Alternatively, you can have the TOP command return a percentage of
rows. For example, if you want to display the top 5 percent of the rows
returned by the ORDER BY operation, youd use the query

SELECT TOP (5) PERCENT

 type AS ObjectType,
crdate AS CreationDate
FROM sysobjects
ORDER BY crdate DESC

SQL Server Architecture Overview

Microsoft SQL Server 2000 is a set of components that work together

to meet the data storage and analysis needs of the largest Web sites and
enterprise data processing systems. The topics in SQL Server
Architecture describe how the various components work together to manage
data effectively.

Topic Description
Features of SQL Server Highlights the features of Microsoft SQL Server
2000 2000.
Relational Database Describes the main relational database
Components components of SQL Server 2000, including the
database engine itself and the components
involved in communications between applications
and the database engine.
Database Architecture Describes the logical components defined in SQL
Server databases and how they are physically
implemented in database files.
Relational Database Describes the features of the server engine that
Engine Architecture make it efficient at processing large numbers of
concurrent requests for data from many users.
Administration Describes how the easy-to-use tools provided with
Architecture SQL Server 2000 and the dynamic configuration
capabilities of SQL Server minimize routine
administrative tasks.
Replication Describes the replication components of SQL
Architecture Server 2000 and how they can be used to
distribute data between databases.
Data Warehousing and Describes Data Transformation Services (DTS)
Online Analytical and Microsoft SQL Server 2000 Analysis Services,
Processing and how they help in building and analyzing a
data warehouse or data mart.
Application Describes how SQL Server 2000 supports the
Development various database programming APIs, which allow
Architecture users to build robust database applications.
Implementation Details Provides implementation details, such as the
maximum capacities of Transact-SQL statements,
the ranges of SQL Server configuration options,
memory usage of SQL Server objects, and the
differences among the editions of Microsoft SQL
Server.

Features of SQL Server 2000

Microsoft SQL Server 2000 features include:

Internet Integration.

The SQL Server 2000 database engine includes integrated XML

support. It also has the scalability, availability, and security
features required to operate as the data storage component of the
largest Web sites. The SQL Server 2000 programming model is
integrated with the Windows DNA architecture for developing Web
applications, and SQL Server 2000 supports features such as
English Query and the Microsoft Search Service to incorporate
user-friendly queries and powerful search capabilities in Web
applications.

Scalability and Availability.

The same database engine can be used across platforms ranging

from laptop computers running Microsoft Windows 98 through
large, multiprocessor servers running Microsoft Windows 2000
Data Center Edition. SQL Server 2000 Enterprise Edition supports
features such as federated servers, indexed views, and large
 memory support that allow it to scale to the performance levels
required by the largest Web sites.

Enterprise-Level Database Features.

The SQL Server 2000 relational database engine supports the

features required to support demanding data processing
environments. The database engine protects data integrity while
minimizing the overhead of managing thousands of users
concurrently modifying the database. SQL Server 2000 distributed
queries allow you to reference data from multiple sources as if it
were a part of a SQL Server 2000 database, while at the same time,
the distributed transaction support protects the integrity of any
updates of the distributed data. Replication allows you to also
maintain multiple copies of data, while ensuring that the separate
copies remain synchronized. You can replicate a set of data to
multiple, mobile, disconnected users, have them work
autonomously, and then merge their modifications back to the
publisher.

Ease of installation, deployment, and use.

SQL Server 2000 includes a set of administrative and development

tools that improve upon the process of installing, deploying,
managing, and using SQL Server across several sites. SQL Server
2000 also supports a standards-based programming model
integrated with the Windows DNA, making the use of SQL Server
databases and data warehouses a seamless part of building
powerful and scalable systems. These features allow you to rapidly
deliver SQL Server applications that customers can implement
with a minimum of installation and administrative overhead.

Data warehousing.

SQL Server 2000 includes tools for extracting and analyzing

summary data for online analytical processing. SQL Server also
includes tools for visually designing databases and analyzing data
using English-based questions.
Oracle Server

Oracle Instance

Oracle Process
o PMON, SMON, DBWR, LGWR, CKPT
o Server Process
Memory Structure Update!(May7,2002)
o SGA
Shared pool
Library Cache
Data Dictionary cache
Database Buffer cache
Redo buffer cache
o PGA

Oracle Database Update!(May9,2002)

Data files
Control files
Redo log files
Archived log files
Parameter file
Password file

Oracle Clients

user process

Oracle Net

Oracle Net Server-Side

Oracle Net Client-Side
Ans 2:

SQL Server 2000 vs Oracle 9i

Platform comparison
SQL Server 2000 only works on Windows-based platforms, including
Windows 9x, Windows NT, Windows 2000 and Windows CE.
In comparison with SQL Server 2000, Oracle 9i Database supports all
known platforms, including Windows-based platforms, AIX-Based
Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, Sun
Solaris and so on.

Hardware requirements
To install SQL Server 2000, you should have the Intel or compatible platforms and the
following hardware:

Hardware Requirements
Processor Pentium 166 MHz or higher
32 MB RAM (minimum for Desktop Engine),
Memory 64 MB RAM (minimum for all other editions),
128 MB RAM or more recommended
270 MB (full installation),
250 MB (typical),
95 MB (minimum),
Hard disk space Desktop Engine: 44 MB
Analysis Services: 50 MB minimum and 130 MB
typical
English Query: 80 MB

Oracle 9i supports Intel or compatible platforms, AIX-Based Systems, Compaq Tru64

UNIX, HP 9000 Series HP-UX, Linux Intel, Sun Solaris and so on.

To install Oracle 9i under the Intel or compatible platforms, you should have the
following hardware:

Hardware Requirements
Processor Pentium 166 MHz or higher
RAM: 128 MB (256 MB recommended)
Memory Virtual Memory: Initial Size 200 MB, Maximum Size
400 MB
140 MB on the System Drive
Hard disk
plus 4.5 GB for the Oracle Home Drive (FAT)
space
or 2.8 GB for the Oracle Home Drive (NTFS)
To install Oracle 9i Database under the UNIX Systems, such as AIX-Based Systems,
Compaq Tru64 UNIX, HP 9000 Series HP-UX, and Sun Solaris, you should have the
following hardware:

Hardware Requirements
Memory A minimum of 512 MB RAM
A minimum of 2 x RAM or 400 MB, whichever is
Swap Space
greater
Hard disk
4.5 GB
space

Software requirements
SQL Server 2000 comes in six editions: Enterprise, Standard, Personal, Developer,
Desktop Engine, and SQL Server CE (a compatible version for Windows CE) and
requires the following software:

SQL
Operating Enterprise Standard Personal Developer Desktop
Server
System Edition Edition Edition Edition Engine
CE
Windows CE No No No No No Yes
Windows 9x No No Yes No Yes No
Windows NT
4.0
Workstation No No Yes Yes Yes No
with Service
Pack 5
Windows NT
4.0 Server
Yes Yes Yes Yes Yes No
with Service
Pack 5
Windows NT
4.0 Server
Enterprise
Yes Yes Yes Yes Yes No
Edition with
Service
Pack 5
Windows
2000 No No Yes Yes Yes No
Professional
Windows
Yes Yes Yes Yes Yes No
2000 Server
Windows
2000
Yes Yes Yes Yes Yes No
Advanced
Server
Windows
2000 Yes Yes Yes Yes Yes No
DataCenter
Windows XP
No No Yes Yes Yes No
Professional

Oracle 9i Database comes in three editions: Enterprise, Standard and Personal and
requires the following software:

Operating System
Platform Required Patches
Version
Windows-based Windows NT 4.0 Service Pack 5
Windows-based Windows 2000 Service Pack 1
Windows-based Windows XP Not Necessary
Maintenance Level 09 and
AIX-Based AIX 4.3.3 IY24568,
IY25282, IY27614, IY30151
AIX 5L release 5.1 ML01+
(IY22854),
AIX-Based AIX 5.1
IY26778, IY28766, IY28949,
IY29965, IY30150
Compaq Tru64
Tru64 5.1 5.1 patchkit 4
UNIX
Compaq Tru64
Tru64 5.1A 5.1A patchkit 1
UNIX
HP-UX HP-UX version 11.0 Sept. 2001 Quality Pack,
(64-bit) PHCO_23792,
PHCO_24148, PHKL_24268,
 PHKL_24729,
PHKL_ 25475, PHKL_25525,
PHNE_24715,
PHSS_23670, PHSS_24301,
PHSS_24303,
PHSS_24627, PHSS_22868
SuSE Linux
Enterprise Server 7
Linux (or SLES-7) with Not Necessary
kernel 2.4.7,
and glibc 2.2.2
Solaris 32-Bit 2.6
Sun Solaris (5.6), 7 (5.7) Not Necessary
or 8 (5.8)
Sun Solaris Solaris 64-Bit 8 (5.8) Update 5

Performance comparison
It is very difficult to make the performance comparison between SQL
Server 2000 and Oracle 9i Database. The performance of your databases
depends rather from the experience of the database developers and
database administrator than from the database's provider. You can use
both of these RDBMS to build stable and efficient system. However, it is
possible to define the typical transactions, which used in inventory
control systems, airline reservation systems and banking systems. After
defining these typical transactions, it is possible to run them under the
different database management systems working on the different
hardware and software platforms.

TPC tests
The Transaction Processing Performance Council (TPC.Org) is
independent organization that specifies the typical transactions
(transactions used in inventory control systems, airline reservation
systems and banking systems) and some general rules these
transactions should satisfy.

The TPC produces benchmarks that measure transaction processing and

database performance in terms of how many transactions a given system
and database can perform per unit of time, e.g., transactions per second
or transactions per minute.

The TPC organization made the specification for many tests. There are
TPC-C, TPC-H, TPC-R, TPC-W and some old tests, such as TPC-A, TPC-B
and TPC-D. The most popular test is the TPC-C test (OLTP test).

At the moment the article was wrote, SQL Server 2000 held the top TPC-
C by performance results with Distributed Partitioned Views-based
cluster systems.
See Top Ten TPC-C by Performance Version 5 Results

At the moment the article was wrote, SQL Server 2000 held the top TPC-
C by price/performance results. See Top Ten TPC-C by
Price/Performance Version 5 Results

Note. Because most organizations really do not run very large databases,
so the key points on which SQL Server 2000 won the TPC-C benchmarks
do not really matter to the vast majority of companies.

Price comparison
One of the main Microsoft SQL Server 2000 advantage in comparison
with Oracle 9i Database is that SQL Server is cheaper. Other SQL Server
advantage is that Microsoft includes the Online analytical processing
(OLAP) and Data Mining as standard features in SQL Server 2000
Enterprise Edition. So, you can save up to four times with SQL Server
2000 Enterprise Edition if you use OLAP and Data Mining.

The price comparisons below were based on the

Oracle and SQL Server 2000 Price Comparison
article from Microsoft.

Compare pricing for SQL Server 2000 Standard Edition and Oracle9i Standard Edition:

Number of Oracle9i SQL Server 2000

CPUs Standard Edition Standard Edition
1 $15,000 $4,999
2 $30,000 $9,998
4 $60,000 $19,996
8 $120,000 $39,992
 16 $240,000 $79,984
32 $480,000 $159,968

Compare pricing for SQL Server 2000 Enterprise Edition (which include OLAP and Data
Mining) and Oracle9i Enterprise Edition with OLAP and/or Data Mining:

Oracle9i Oracle9i
SQL Server
Oracle9i Enterprise Enterprise
Number of 2000
Enterprise Edition with Edition With
CPUs Enterprise
Edition OLAP or Data OLAP and Data
Edition
Mining Mining
1 $40,000 $60,000 $80,000 $19,999
2 $80,000 $120,000 $160,000 $39,998
4 $160,000 $240,000 $320,000 $79,996
8 $320,000 $480,000 $640,000 $159,992
16 $640,000 $960,000 $1,280,000 $319,984
32 $1,280,000 $1,920,000 $2,560,000 $639,968

Note. This is not a full price comparison between SQL Server 2000 and
Oracle 9i Database. It is only a brief comparison. You can have any
discounts and the prices can be increased or decreased in the future. See
Microsoft and Oracle to get more information about the price of their
products.

Features comparison
Both SQL Server 2000 and Oracle 9i Database support the ANSI SQL-92
entry level and do not support the ANSI SQL-92 intermediate level. In the
Features comparison section of this article I want to make the brief
comparison of the Transact-SQL with PL/SQL and show some SQL
Server 2000 and Oracle 9i Database limits.

T-SQL vs PL/SQL
The dialect of SQL supported by Microsoft SQL Server 2000 is called Transact-SQL (T-
SQL). The dialect of SQL supported by Oracle 9i Database is called PL/SQL. PL/SQL is
more powerful language than T-SQL. This is the brief comparison of PL/SQL and T-SQL:

Feature PL/SQL T-SQL

Indexes B-Tree indexes, B-Tree indexes
 Bitmap indexes,
Partitioned indexes,
Function-based indexes,
Domain indexes
Relational tables,
Object tables,
Temporary tables, Relational tables,
Tables
Partitioned tables, Temporary tables
External tables,
Index organized tables
BEFORE triggers,
AFTER triggers, AFTER triggers,
Triggers
INSTEAD OF triggers, INSTEAD OF triggers
Database Event triggers
PL/SQL statements,
Java methods,
Procedures T-SQL statements
third-generation language
(3GL) routines
Arrays Supported Not Supported

SQL Server 2000 and Oracle 9i limits

Here you can find some SQL Server 2000 and Oracle 9i Database limits:

Oracle 9i
Feature SQL Server 2000
Database
database name length 128 8
column name length 128 30
index name length 128 30
table name length 128 30
view name length 128 30
stored procedure name length 128 30
max columns per index 16 32
max char() size 8000 2000
max varchar() size 8000 4000
max columns per table 1024 1000
max table row length 8036 255000
max query size 16777216 16777216
recursive subqueries 40 64
constant string size in SELECT 16777207 4000
constant string size in WHERE 8000 4000

Conclusion
It is not true that SQL Server 2000 is better than Oracle 9i or vice versa.
Both products can be used to build stable and efficient system and the
stability and effectiveness of your applications and databases depend
rather from the experience of the database developers and database
administrator than from the database's provider. But SQL Server 2000
has some advantages in comparison with Oracle 9i and vice versa.

The SQL Server 2000 advantages:

SQL Server 2000 is cheaper to buy than Oracle 9i Database.

SQL Server 2000 holds the top TPC-C performance and
price/performance results.
SQL Server 2000 is generally accepted as easier to install, use and
manage.

The Oracle 9i Database advantages:

Oracle 9i Database supports all known platforms, not only the

Windows-based platforms.
PL/SQL is more powerful language than T-SQL.
More fine-tuning to the configuration can be done via start-up
parameters.