You are on page 1of 26

The Oracle Database:

Past, Present, and Future


Lex de Haan

Aalborg University,
27 November 2003

The Oracle Database: Past, Present, and Future - 1


Overview 2004 Oracle 10g
2001 Oracle9i
Ted Codd 1999 Oracle8i
1970 1997 Oracle8
1993 Oracle7
1989 version 6
1986 version 5
1984 version 4
1980 version 3
1979 version 2
1978 version 1

Oracle History
If you like to find out more about the Oracle history, you can find some articles in the Oracle
Magazine archives at http://www.oracle.com/oramag/.

The Oracle Database: Past, Present, and Future - 2


Oracle History

1978: Oracle version 1


• Ran on PDP-11 under RSX, in 128 KB memory
• Written in assembly language
• Separated Oracle code (OPI) and user code (UPI)
1979: Oracle version 2
• Written in PDP-11 assembly language
• Ran on VAX/VMS in compatibility mode

1978 1979 1980 1984 1986 1989 1993 1997 1999 2001 2004

1978: Oracle RDBMS Version 1


The main architect of the initial releases of the Oracle RDBMS was Bob Miner.
To overcome the memory limitations of RSX, the code had to be split into two parts: the Oracle
code and the user application code.

1979: Oracle RDBMS Version 2


The company—called Relational Software, Inc. (RSI) those days—doesn't offer its product
commercially until 1979. That summer, RSI releases its Oracle database as version 2 rather than
version 1, because the company believes potential customers might not purchase the initial
release of a software product.

The Oracle Database: Past, Present, and Future - 3


Oracle History

1980: Oracle version 3


1981
• Written in C: portable source code
IAF
• Retained split architecture
• Introduced the concept of atomic SQL execution
and transactions (commit, rollback)
1984: Oracle version 4
• Introduced read consistency
• Ported to many platforms
• Interoperability between PC and server

1978 1979 1980 1984 1986 1989 1993 1997 1999 2001 2004

1980: Oracle RDBMS Version 3


This version introduces the concept of transactions and atomic execution of SQL statements. A
user could make interim changes to the data that did not become permanent until they were
committed. The user could choose to abandon the changes by rolling back the transaction.
With version 3, RSI changes its name to Oracle, to more closely identify the company with its
product.
In 1981, Oracle begins developing a tool for data entry and reporting, called IAF (Interactive
Application Facility.)

1984: Oracle RDBMS Version 4


Read consistency is the most important feature in this release. Moreover, the RDBMS is ported
to the desktop PC. The MS-DOS version of Oracle runs in only 640 KB of memory.

The Oracle Database: Past, Present, and Future - 4


Oracle History

1986: Oracle version 5


1987
• True client-server (distributed processing)
Apps
• VAX-cluster support
• Version 5.1: Distributed queries
1989: Oracle version 6 (major kernel rewrite)
• OLTP performance enhancements, savepoints
• Online backup and recovery
• Row-level locking, PL/SQL in the database
• Parallel Server (VAX clusters, nCube)

1978 1979 1980 1984 1986 1989 1993 1997 1999 2001 2004

1986: Oracle RDBMS Version 5


A true client-server configuration (multiple clients connecting to a single database server) is
known as distributed processing. Version 5.1 introduced the concept of distributed queries,
allowing a single query to access tables stored in multiple locations. The initial VAX cluster
solution evolved via Oracle Parallel Server to Oracle9i Real Application Clusters.

1987: Applications Division


In 1987 Oracle begins developing business-management software, closely integrated with its
database. Most of these products are developed by Oracle from scratch.

1989: Oracle RDBMS Version 6


In Oracle version 6, the kernel is almost fully rewritten; for example, the before image file is
replaced by rollback segments. Many OLTP performance enhancements are included. The
PL/SQL support and row-level locking are available as the transaction processing option (TPO).
Oracle version 6 also introduces the concept of savepoints, enabling you to rollback parts of a
transaction without closing the transaction itself.
The Oracle Parallel Server facility was only available on VAX clusters and on the nCube (a MPP
machine.)

The Oracle Database: Past, Present, and Future - 5


Oracle History

1993: Oracle7
1994
• Declarative referential integrity
Media
• Stored procedures and triggers server
• Shared SQL, parallel execution
• Advanced replication 1995

1997: Oracle8 NC
• Object-relational extensions in the database
• From client/server to three-tier architecture
• Partitioning option

1978 1979 1980 1984 1986 1989 1993 1997 1999 2001 2004

1993: Oracle7
Oracle7 takes about four years of development and two years of testing, and comes with an
impressive list of new features.
In 1994, the first attempts are made to support multimedia content, resulting in the media server,
running on the nCube.
In 1995 Oracle launches a set of data warehousing features, including parallel query execution.
This allows queries to be broken up and executed in parallel, using multiple processors of a
symmetric multiprocessing (SMP) machine. In the same year, Larry Ellison introduces his vision
of the network computer (NC).
In 1996 all products are ported to the Windows NT platform, followed by a multinode scalable
database for Windows NT clusters.

1997: Oracle8
Oracle7 is still a client/server product; Oracle8 brings the internet and network computing
paradigm. The database includes support for object-oriented development and multimedia
applications; it also has features for handling both large numbers of users and large amounts of
data.

The Oracle Database: Past, Present, and Future - 6


Oracle History

1999: Oracle8i
2000
• Java in the database (JVM and SQLJ)
• Partitioning enhancements iFS
• Data warehousing enhancements
• XML support
• Summary management
• Oracle Internet Directory (LDAP)
• Ported to Linux

1978 1979 1980 1984 1986 1989 1993 1997 1999 2001 2004

1999: Oracle8i
This product is called the internet database because of its new features, designed to support
internet-based activities and applications. It comes with a JVM, native Java support, and SQLJ -
an open standard for embedding SQL statements into client or server Java code.
Another new product is Oracle interMedia.
Oracle8 and Oracle8i are ported to Linux.
Raw Iron: Oracle starts shipping servers with Oracle's database preinstalled and running on a
slimmed-down operating system, bringing lower costs and simpler operations to smaller
organizations and departmental computing.
Oracle also starts testing Business Components for Java (BC4J).
Oracle WebDB for Linux becomes a popular download from the Oracle Technology Network. It
is a free browser-based tool for building, managing, and monitoring database-driven Web sites.
The tool will eventually mature into portal technology.
To help users more easily manage files, Oracle releases internet file system (iFS) in May 2000.

The Oracle Database: Past, Present, and Future - 7


Oracle History

2001: Oracle9i
• Real Application Clusters, with cache fusion
– Scalability on inexpensive clustered hardware
• Automatic segment-space management
• Internet security enhancements
• Integrated business intelligence functionality
• Data Guard (standby databases)
• Oracle managed files
• Globalization support (Unicode, time zones, locales)

1978 1979 1980 1984 1986 1989 1993 1997 1999 2001 2004

2001: Oracle9i
Probably the most exciting new feature that comes with Oracle9i is Real Application Clusters,
with its cache fusion technology, resulting in transparent scalability on inexpensive, clustered
hardware.
Oracle9i also results in record-breaking TPC-C benchmark results.

The Oracle Database: Past, Present, and Future - 8


Oracle Database 10g

Primary goal: Build a self-managing database


that requires minimal human intervention.
• Reduction in administration cost without
compromising high availability, scalability,
and security.
• Minimal performance impact
• Effective for all configurations and workloads

1978 1979 1980 1984 1986 1989 1993 1997 1999 2001 2004

2004: Oracle database 10g


See next pages for more details about this release.

The Oracle Database: Past, Present, and Future - 9


Manageability: Key Concepts

1. Bring the management of all database components


into the database itself
– SQL tuning, resource management, space and
storage management, backup and recovery
2. Integrate the management of these components
with a central management engine
– Enables holistic rather than independent or
conflicting decisions
3. Provide an intelligent infrastructure to enable
these components to be self-managing

Manageability: Key Concepts


There are three key concepts in the self-managing database architecture.
• First, bring the management of all the database components into the database (i.e. SQL
tuning, resource management, space and storage management, backup and recovery)
instead of relying on external tools or the DBA to manage them.
• Second, integrate the management of all the components with a central management
engine. This ensures that holistic rather than independent or conflicting decisions are
made.
• Third, build an infrastructure that provides the intelligence to enable all the components,
including the central management, to be self-managing.

The Oracle Database: Past, Present, and Future - 10


Automatic Workload Repository (AWR)

The most critical infrastructure component;


the data warehouse of the database.
• Storage of all the important system statistics and
workload information.
• The database kernel is instrumented to capture an
essential set of time-based statistics (Time Model)
– Captured and computed in memory (ASH)
– Periodically flushed to disk as snapshots & baselines

Using AWR’s information, the database is able to intelligently


tune, accurately advise and proactively alert according to the
workload and environment that are unique for every system.

Automatic Workload Repository (AWR)


The most critical infrastructure component is the Automatic Workload Repository (AWR); it is
the data warehouse of the database. AWR is where all the important system statistics and
workload information (e.g. high-load SQL, hot objects) are stored. In Oracle Database 10g, we
also instrumented the database kernel to capture an essential set of time-based statistics, called
the Time Model, which accounts for where time is spent in the database. All this information is
efficiently captured and computed in memory, then periodically flushed to disk as Snapshots.
Active Session History (ASH) samples session statistics every second and records the events that
sessions are waiting for. The sampling facility is very efficient because it directly accesses
internal memory structures. The ASH is designed as a rolling buffer in memory; earlier
information is overwritten when needed. Flushing ASH data is done automatically (and
intelligently) by a background process, every 30 minutes. The default on-disk retention is seven
days.
Baselines allow you to tag sets of snapshot data for important periods. A baseline is defined on a
pair of snapshots. Baselines are used to retain snapshot data because snapshots belonging to
baselines are retained until the baselines are dropped. You typically set up baselines from some
representative periods in the past, to be used for comparison with the current system behavior.
You can set up threshold-based alerts using baselines.

The Oracle Database: Past, Present, and Future - 11


Automatic Database Diagnostic Monitor
(ADDM)

• The central management engine that integrates


all AWR components
• A database performance expert “in the box”
• ADDM uses the data captured in the AWR
• ADDM uses a time-based classification tree to
pinpoint root causes of performance problems
• The Time Model enables ADDM to make
performance-tuning recommendations between
seemingly incomparable trade-offs

A self-diagnostic engine like ADDM built inside the database


is essential to good system performance

The Oracle Database: Past, Present, and Future - 12


Tasks

Alerts

AWR
Adv
Automatic Workload Repository

External clients
EM SQL*Plus …

SGA
Efficient V$ DBA_%
in-memory AWR
statistics snapshots
collection MMON

Self-tuning …
ADDM component
Internal clients

Automatic Workload Repository


The Automatic Workload Repository (AWR) is the infrastructure that provides services to
Oracle Database 10g components to collect, maintain, and utilize statistics for problem detection
and self-tuning purposes.
The AWR infrastructure consists of two major parts:
• An in-memory statistics collection facility that is used by Oracle Database 10g components
to collect statistics. These statistics are stored in memory for performance reasons. Statistics
stored in memory are accessible through dynamic performance (V$) views.
• The AWR snapshots represent the persistent portion of the facility. AWR snapshots are
accessible through data dictionary views.
Statistics are stored in persistent storage for several reasons:
• The statistics need to survive instance crashes.
• Some analyses need historical data for baseline comparisons.
• Memory overflow: When old statistics are replaced by new ones due to memory shortage, the
replaced data can be stored for later use.
The memory version of the statistics is transferred to disk on a regular basis by a new
background process called MMON (Memory Monitor).

The Oracle Database: Past, Present, and Future - 13


Tasks

Alerts

AWR
Adv
Server Alert Models
EM console

EM Server
alerts alerts

Agent Server
Poll
Automatic alerts queue
metrics
notification

Data Server polls


dictionary itself AWR
Oracle
Oracle metrics
Database
Database10g
10g
(SGA)
(SGA) MMON

Server Alert Models


Oracle Database 10g automatically collects a significant number of metrics that were previously
collected by EM. The main difference between EM alerts and the server alerts is that the metrics
computation and threshold validations are performed by Oracle Database 10g; unlike the EM
agent, Oracle Database 10g can access the SGA directly.
There are two kinds of server generated alerts: threshold (stateful) alerts and non-threshold
(stateless) alerts.
You can define critical and warning thresholds for more than 150 predefined stateful alerts;
MMON verifies these threshold values and generates the alerts when needed. Examples of
threshold alerts are the following:
• Physical reads per second
• User commits per second
• SQL service response time
Examples of stateless alerts correspond to specific database events such as “snapshot too old
errors,” “recovery area low on free space,” and “resumable session suspended.”

The Oracle Database: Past, Present, and Future - 14


Tasks

Alerts

AWR
Adv
DBMS_SCHEDULER Package

Prioritization Change prioritization

Job class Window


Job
metadata

Program Job Schedule

When?
How many times?
Arguments Arguments

DBMS_SCHEDULER Package
The DBMS_SCHEDULER package enables you to control when and where various tasks take place.
By ensuring that many routine database tasks occur without manual intervention, you can lower
operating costs, implement more reliable routines, and minimize human error. For example, the
Scheduler now schedules routine administration tasks, such as gathering optimizer statistics.
A program is a collection of metadata about what will be run by the Scheduler. The supported
program types are PL/SQL block, PL/SQL stored procedure, Java stored procedure, C routine
outside the database, and executables external to the database.
A schedule specifies when and how many times a job is executed.
A job specifies what needs to executed and when, along with any additional arguments required
for the job. To appropriately allocate scarce resources among competing jobs, the Scheduler uses
two other concepts:
• A job class defines a category of jobs that share common resource usage requirements and
other characteristics. You can prioritize among job classes by controlling the resources
allocated to each job class using a database resource plan. This ensures that your critical jobs
have priority and have enough resources to complete.
• A window is represented by an interval of time with a well-defined beginning and end. It is
used to change the prioritization among job classes based on a schedule.

The Oracle Database: Past, Present, and Future - 15


Tasks

Alerts

AWR
Adv
Advisory Framework

SQL Tuning PGA PGA Advisor


Advisor
Buffer Cache
Memory Advisor
SGA
ADDM
SQL Access Library Cache
Advisor Advisor

Segment Advisor
Space
Undo Advisor

Advisory Framework
Advisors are server components that provide feedback about resource utilization and
performance.
Automatic Database Diagnostic Monitor (ADDM): Does a top-down instance analysis,
identifies problems and potential causes, and gives recommendations for fixing the problems.
ADDM can potentially call other advisors.
SQL Tuning Advisor: Provides tuning advice for SQL statements
SQL Access Advisor: Deals with schema issues and determines optimal data access
PGA Advisor: Gives detailed statistics for the work areas, and provides recommendations about
optimal usage of PGA memory based on workload characteristics
SGA Advisor: Responsible for tuning and recommending SGA size depending on pattern of
access for the various components within the SGA
Buffer Cache Advisor: Predicts buffer cache hit rates for different buffer cache sizes
Library Cache Advisor: Predicts the cursor cache hit rate for different library cache sizes
Segment Advisor: Monitors object space issues and analyzes growth trends
Undo Advisor: Suggests parameter values and the amount of additional space that is needed to
support flashback for a specified time

The Oracle Database: Past, Present, and Future - 16


ADDM: Reactive versus Proactive
Performance Monitoring
In-memory MMON
statistics
Snapshots

ADDM

Alerts
DBA Proactive ADDM
monitoring results
Reactive
AWR
monitoring

ADDM: Performance Monitoring


With previous releases of the Oracle server, you were able to retrieve statistical information for
only some of the important areas. So the tuning process was tedious and error prone; it could
lead to a waste of your time and efforts. Oracle Database 10g introduces new and more effective
methods to monitor your database.
Proactive monitoring, with two main components:
• Automatic Database Diagnostic Monitor (ADDM). This component is the ultimate solution
for database tuning. The ADDM automatically identifies bottlenecks within Oracle Database
10g. Additionally, working with other manageability components, the ADDM makes
recommendations for fixing these bottlenecks.
• Server-generated alerts: These are discussed earlier in this lesson.
Reactive monitoring: Oracle Database 10g has powerful new data sources and performance-
reporting capabilities. Enterprise Manager provides an integrated performance management
console that uses all relevant data sources. Using a drill-down method, you are able to manually
identify bottlenecks with a few mouse clicks.
New data sources are introduced to capture important information about your database’s health
(for example, new in-memory statistics for real-time diagnostics as well as statistics history
stored in the AWR).

The Oracle Database: Past, Present, and Future - 17


Other Important Enhancement Areas

• Automatic Storage Management (ASM)


• Automatic shared memory management
• Human error correction
• High availability
– Backup and recovery optimization
– Data Guard (logical and physical standby databases)
– Online redefinition
– LogMiner
• Performance (wait interface, end-to-end tracing)
• BI and data warehousing

Performance
In November 2003, Oracle and HP published the first TPC-C benchmark to break the 1 Million
tpmC barrier. This was done using Oracle Database 10g Enterprise Edition on HP Integrity
Superdome, resulting in 1,008,144.49 tpmC @ $8.33/tpmC.
By the way, Oracle 7 on the Compaq Alpha platform was the first to break the 100,000 tpmC
barrier in 1998.

The Oracle Database: Past, Present, and Future - 18


Automatic Storage Management (ASM)

ASM is a database service that provides:


• Load balancing in parallel across disk drives
• Prevention of disk space fragmentation
• Online disk space reorganization
• Data redundancy to provide fault tolerance
– ASM can be built on top of vendor-supplied storage
mechanisms

Automatic Storage Management (ASM)


ASM is a database service that allows the efficient management of disk drives with 24 × 7
availability.
• It automatically does load balancing in parallel across all available disk drives to prevent hot
spots and maximize performance, even with rapidly changing data usage patterns.
• It prevents fragmentation so that there is never a need to relocate data to reclaim space.
• It does automatic online disk space reorganization for the incremental addition or removal of
storage capacity.
• It can maintain redundant copies of data to provide fault tolerance, or it can be built on top of
vendor-supplied reliable storage mechanisms.
Data management is done by selecting the desired reliability and performance characteristics for
classes of data rather than with human interaction on a per-file basis.
ASM does not eliminate any existing database functionality; databases using file systems or raw
devices, or databases that are based on Oracle Managed Files (OMF), can operate as they always
have. New files may be created as ASM files, while old ones are administered in the old way.
Databases can have a mixture of ASM files, OMF, and manually managed files—all at the same
time.

The Oracle Database: Past, Present, and Future - 19


Human Error Correction

• Flashback Query
– Query data at some point-in-time in the past
• Flashback Versions Query
– View changes made over time at the row level
• Flashback Transaction Query
– View changes made at the transaction level
• Flashback Database
– New strategy for doing point-in-time recovery
• Flashback Table
– Recover tables to a specified point in time
• Flashback Drop
– Undrop a table (recycle bin)

The Oracle Database: Past, Present, and Future - 20


The Future?

Databases are vital, and getting more so every day.


• Life sciences, content management, …
• Real-time business intelligence
• Security and availability
• Radio Frequency Identification (RFID)
• Databases versus operating systems
• Taking advantage of new types of hardware

The big challenge for companies like Oracle:


Taking academic research results and applying it
in practical terms.

The Oracle Database: Past, Present, and Future - 21


ANSI/ISO SQL Language

• SQL-86 and SQL-87


• SQL-89 added referential integrity
• SQL-92
– One standard with multiple conformance levels
• CLI-95 and PSM-96
• SQL:1999
– Introduced multiple parts and named features
– Some parts were backported to SQL-92
• OLB:2000 and JRT:2002
• SQL:2003 bug fixing release

SQL Standard History


SQL-86/SQL-87 is the least common denominator; SQL-89 added basic referential integrity.
The SQL-92 standard was a major enhancement, introducing schema manipulation,
orthogonality, dynamic SQL, several new data types, and so on. Nevertheless, the SQL-92
standard consisted of 532 pages in total only.
Between SQL-92 and SQL:1999 two new components were introduced:
• CLI-95: The Call-Level Interface
• PSM-96: Procedural language for SQL
The SQL:1999 standard was a major enhancement again, for example introducing object
technology and collections.
Between SQL:1999 and SQL:2003 two components were introduced:
• OLB:2000: Object Language Bindings
• JRT:2002: Java Routines and Types
SQL:2003 only has minor enhancements; it is mainly a bug fixing release.

The Oracle Database: Past, Present, and Future - 22


ANSI/ISO SQL Conformance

• SQL-86/87/89
– Levels 1 and 2
• SQL-92
– Entry/Transitional/Intermediate/Full levels
• SQL:1999 and SQL:2003
– Core SQL, plus named features and packages
• Conformance testing
– FIPS 127: SQL-92 only
– NIST (formerly NBS) did conformance testing until
1996; political changes eliminated NIST testing

Standards Conformance
SQL-86/87/89 was a truly minimal standard; almost any data retrieval product could conform.
SQL-92 Levels
Entry: Full SQL-89 standard, plus some small new features
Transitional: Half-way step to Intermediate
Intermediate: About half of the SQL-92 standard
Full: Everything (obviously)
Every important SQL product conformed to Entry within one year; no product reached
Transactional until this year.
Core SQL:1999 consisted of SQL-92 Entry level plus most of Transitional, and some
Intermediate and some Full. Most important SQL products conform to Core (or very nearly do)
and most of them implement several other features.
The NIST test suite is available in the public domain, but NIST is no longer organized as a
testing entity; standards conformance is now a contractual issue, rather than a public policy issue.

The Oracle Database: Past, Present, and Future - 23


SQL:1999 and SQL:2003 Parts

1. Framework
2. Foundation
3. Call Level Interface (CLI)
4. Persistent Stored Modules (PSM)
5. Host Language Bindings (gone in SQL:2003)
9. Management of External Data (MED)
10. Object Language Bindings (OLB)
11. Information and Definition Schemata
13. Java Routines and Types (JRT)
14. XML Related Specifications (XML)

SQL:1999 and SQL:2003 Parts


The gaps in the part numbering are caused by some parts being merged, or discontinued. The
main part is definitely Foundation (about 1340 pages).
SQL:1999 Part 5 is about SQL Bindings; that is, embedded and dynamic SQL. This part was
merged with SQL:2003 Foundation.
Part 7 was about Temporal SQL; temporarily suspended, because there were two strongly
opposed philosophies.

The Oracle Database: Past, Present, and Future - 24


The Future of ANSI/ISO SQL

• The current expectation is that the SQL language


will go into “maintenance mode” after SQL:2003
• Main area of further development: SQL/XML

The Oracle Database: Past, Present, and Future - 25


Questions and Answers

The Oracle Database: Past, Present, and Future - 26

You might also like