Oracle is celebrating its 30 wonderful years in the industry (from 1977 to 2007).

This article was updated on 6th August, 2007.

• In 1977, Larry Ellison, Bob Miner and Ed Oates founded Software Development
Laboratories to undertake development work
• After reading a paper by Codd in IBM Journal of Research and Development, they created
Oracle. The first version was never released. It was written in Assembly language of PDP
which ran in 128kb of RAM.
• Version 2.0 of Oracle was released in 1979 and it became first commercial relational
database and first SQL database. The company changed its name to Relational Software
Inc. (RSI).
• In 1981, RSI started developing tools for Oracle.
• In 1982, RSI was renamed to Oracle Corporation. It held its first user conference in San
Francisco.
• In 1983, Oracle released version 3.0, which was rewritten in C language and ran on
multiple platforms.
• In 1984, Oracle version 4.0 was released. It contained features like concurrency control -
multi-version read consistency etc.
• By 1985, Oracle released version 5.0 and became the first relational database that worked in
client/server environment.
• In 1986, Oracle goes public on the NASDAQ exchange.
• In 1987, Oracle wanted to create enterprise applications that take advantage of their
database.
• In 1988, Oracle version 6.0 was released. It provided row-level locking, hot backup and
PL/SQL as main features.
• By 1989, Oracle moved to new headquarters in Redwood Shores, California.
• In 1990, they released Oracle Applications Release 8, which included account software for
client/server
• In 1992, they released Oracle 7.0. It provided better performance, administrative utilities,
application development tools, security features, stored procedures, triggers and
declarative integrity.
• In 1995, Oracle became the first major company to announce a comprehensive internet
strategy.
• In 1997, Oracle released Oracle 8.0 and Oracle Applications 10.7. It started embracing
Java. Partitioning, support for different types of data like images, large text, external data
etc.(lobs) are provided. It also started providing support for Object in database becoming an
Object-Relational DBMS
• By 1999, Oracle realized that "Internet Changes Everything". Oracle released Oracle 8i
and Oracle Applications 11i. They supported open standards like XML. Oracle8i provided
Java Virtual Machine (JVM) to run Java program in Oracle Database and also scalability,
which was required for internet databases.
To read more about what is new in Oracle8i, read What's new in Oracle8i and PL/SQL
Enhancements articles.
• In 2000, Oracle9iAS was released. Oracle corporation is no longer a company providing
only database management system and instead started providing all that it takes to develop
and deploy a complete application. AS(Application Server) runs on middle tier in 3-tier
Client/Server architecture boosting the performance.
• In 2001, Oracle9i was released. It allows Oracle to run on RAC (Real Application Cluster),
which is a collection of low-cost servers. It also allowed XML documents to be stored and
 queried in Oracle Database.
You can get information about new features that were introduced in Oracle9i using New
features of Oracle9i Database
• In 2003, Oracle10g was released, where g stands for Grid computing, which servers
computing power across the enterprise as a utility, automatically shifting processing load
based on demand. Oracle10g also made a lot of administrative tasks automatic.
• In 2007, Oracle has released Oracle11g. The new version focused on better partitioning,
easy migration etc.

Starting the instance

sqlplus /nolog

connect sys/MYSECRETPASSWORD as sysdba

Connected to an idle instance.

Creating the database

create database ora10

THE ORACLE 10g ARCHITECTURE

The Oracle server architecture is basically categorized as follows:
• Logical layer
• Physical layer
The logical layer comprises one or more tablespaces and the database schema. The database schema
consists of tables, clusters, indexes, views, procedures, triggers, sequences, and so on. The database
schema is a collection of schema objects.
The hierarchy of Oracle disk-space management is as follows:
• Tablespaces: These are at the highest level of Oracle disk-space management.
• Segments
• Extents
• Data blocks: These are at the lowest level of Oracle disk-space management.
The figure below depicts the relationship between segments, extents, and data blocks:

The physical layer comprises the following files:

• : Though it is the smallest file (1MB-5MB) of the database, it is the most crucial and critical
file. The criticality of this file is ascribed to the fact that if it is damaged then the database
recovery operation becomes tedious. It contains the requisite information to start the
database. The names and locations of all the control files of the database can be obtained
from the V$CONTROLFILE dynamic performance view.
• : These hold data that is stored in tables of a database. They are usually the largest files in
the database, ranging in size from MB, GB, to TB.
• : These files contain information that helps in recovery in the event of system failure. It
contains information stored in the Redo Log Buffer. The information in the Redo Log Buffer
is written into Redo Log files by the LGWR background process. The Redo Log files are
generally multiplexed and copied for recovery purposes. Sets of redo Log files are known as
Redo Log groups. Each database has minimum of two Redo Log groups. Redo Log groups
 are used in a circular fashion.
The figure below depicts the use of Redo Log files in circular fashion:
The figure above shows three Redo Log groups. Each group consists of two members. The first
member of each Redo Log group is stored in directory D1 and the second member is stored in
directory D2.
1. The V$LOGFILE dynamic performance view is used to obtain information about the names
and locations of the Redo Log groups and their members.
2. LGWR writes every three seconds to a Redo Log group in the case of the following events:
• Whenever a user commits a transaction
• Whenever the Redo Log Buffer is one-third (1/3) full
The most basic components of Oracle memory are:
• SGA- It stands for System Global Area. SGA is allocated whenever an Oracle instance starts
and gets de-allocated when the Oracle instance is shutdown.
1. The Database Buffer Cache
2. The Redo Log Buffer
3. The Shared Pool
• PGA- It stands for Program Global Area. It is a region in memory that contains data and
control information for a single process. This can be either a server or a background process.
A PGA is allocated whenever an Oracle database user connects to a database and a session is
created for him/her.
There are two categories of processes that run with an Oracle database. They are mentioned below:
• User processes
• System processes
The following figure illustrates the relationship between user processes, server processes, PGA, and
session:
The first interaction with the Oracle-based application comes from the user computer that creates a
user process. The user process then communicates with the server process on the host computer.
Here, PGA is used to store session specific information.
Oracle has a large number of background processes. The background processes are categorized into:
• Required Oracle background processes
• Optional Oracle background processes
Some of the background processes are:
1. – It writes data blocks from SGA to data files.
2. – It writes data from the Log Buffer to the redo log.
3. – It timestamps all the data files and the control files whenever a checkpoint occurs.
4. – It stands for . It keeps track of database processes. It also cleans up the process that has
died pre-maturely. The result is that all the cache and the resources are freed up. It also
restarts those dispatcher processes that might have failed.
Some of the main functions of background processes are:
• Communication among Oracle instances
• Performing computer maintenance
• Writing the dirty blocks to disk
5. – It stands for . It performs instance recovery at instance startup.
The following figure depicts the Oracle Architecture in detail:
The figure above shows various components of SGA, Oracle background processes, and their
interactions with control files, data files, Redo Log files, and archived redo logs.
The Oracle instance consists of SGA and all the Oracle background processes. To manage the size
of SGA, two initialization parameter files known as PFILE and SPFILE are used. There are a total
of 250-initialization parameters. PFILE holds 30 of those 250 initialization parameters. Oracle does
not recommend modifying the rest of the 220 initialization parameters.
This article has described the various facts involved in order to understand the underlying Oracle
architecture. After reviewing this article, the database user is now well equipped to understand
several components of Oracle architecture.

Oracle materialized views

Materialized views are an Oracle Silver Bullet when pre-joining tables together for super-fast
response time.
One issue with highly-normalized, non-redundant Oracle table designs (e.g. third normal form) is
that Oracle experiences a high degree of overhead (especially CPU consumption) when joining
dozens of tables together, over-and-over again, and partitioning may help.
Using materialized views we pre-join the tables together, resulting in a single, fat, wide and highly-
redundant table.

This can reduce logical I/O from tens of thousands to a single row fetch, resulting in blisteringly
fast response time, but careful attention must be paid to choosing the proper materialized view
partition keys and the best refresh interval.
The problem with materialized view for pre-joined tables is keeping them refreshed. Because the
materialized view is built from many tables, and changes to the base tables require an update to the
materialized view.

CREATE MATERIALIZED VIEW LOG ON "SCOTT"."DEPT" WITH ROWID ;

To create a materialized view in your own schema:

• You must have been granted the CREATE MATERIALIZED VIEW system privilege and
either the CREATE TABLE or CREATE ANY TABLE system privilege.
• You must also have access to any master tables of the materialized view that you do not
own, either through a SELECT object privilege on each of the tables or through the SELECT
ANY TABLE system privilege.
Dimension
A dimension is an Oracle object which defines a hierarchical (parent/child) relationships
between columns, where all the columns do not have to come from the same table. It is
highly recommended that dimensions on your data are defined because they help query
rewrite and the summary advisor make better decisions.

A dimension is an Oracle object which defines a hierarchical (parent/child) relationships

between columns, where all the columns do not have to come from the same table. It is
highly recommended that dimensions on your data are defined because they help query
rewrite and the summary advisor make better decisions.

Another issue for the database designer is that frequently queries will not involve the
dimension column directly but refer to a column which is related to the dimension. e.g. the
query refers to Tuesday rather than a specific date.

However, columns in one column set (called a level) can come from a different table than
columns in another set. The optimizer uses these relationships with materialized views to
perform query rewrite. The SQLAccess Advisor uses these relationships to recommend
creation of specific materialized views.

CREATE DIMENSION customers_dim

LEVEL customer IS (customers.cust_id)
LEVEL city IS (customers.cust_city)
LEVEL state IS (customers.cust_state_province)
LEVEL country IS (countries.country_id)
LEVEL subregion IS (countries.country_subregion)
LEVEL region IS (countries.country_region)
HIERARCHY geog_rollup (
customer CHILD OF
city CHILD OF
state CHILD OF
country CHILD OF
subregion CHILD OF
region
JOIN KEY (customers.country_id) REFERENCES country
)

Data Concurrency and Consistency

in a multiuser database, the statements within multiple simultaneous transactions can
update the same data. Transactions executing at the same time need to produce
meaningful and consistent results. Therefore, control of data concurrency and data
consistency is vital in a multiuser database.
• Data concurrency means that many users can access data at the same time.
• Data consistency means that each user sees a consistent view of the data, including visible
changes made by the user's own transactions and transactions of other users.
To describe consistent transaction behavior when transactions run at the same time, database
researchers have defined a transaction isolation model called serializability. The serializable mode
of transaction behavior tries to ensure that transactions run in such a way that they appear to be
executed one at a time, or serially, rather than concurrently.
Preventable Phenomena and Transaction Isolation
Levels
The three preventable phenomena are:
• Dirty reads: A transaction reads data that has been written by another transaction that has not
been committed yet.
• Nonrepeatable (fuzzy) reads: A transaction rereads data it has previously read and finds that
another committed transaction has modified or deleted the data.
• Phantom reads (or phantoms): A transaction re-runs a query returning a set of rows that
satisfies a search condition and finds that another committed transaction has inserted
additional rows that satisfy the condition.
Table 13-1 Preventable Read Phenomena by Isolation Level

Isolation Level Dirty Read Nonrepeatable Read Phantom Read

Read uncommitted Possible Possible Possible

Read committed Not possible Possible Possible

Repeatable read Not possible Not possible Possible

Serializable Not possible Not possible Not possible

Locks are mechanisms that prevent destructive interaction between transactions

accessing the same resource.
Resources include two general types of objects:
• User objects, such as tables and rows (structures and data)
• System objects not visible to users, such as shared data structures in the memory and data
dictionary rows

Oracle Manages Data Concurrency and Consistency

Multiversion Concurrency Control

Oracle automatically provides read consistency to a query so that all the data that the query sees
comes from a single point in time (statement-level read consistency). Oracle can also provide read
consistency to all of the queries in a transaction (transaction-level read consistency).
Statement-Level Read Consistency
Oracle always enforces statement-level read consistency. This guarantees that all the data returned
by a single query comes from a single point in time—the time that the query began. Therefore, a
query never sees dirty data or any of the changes made by transactions that commit during query
execution. As query execution proceeds, only data committed before the query began is visible to
the query. The query does not see changes committed after statement execution begins.
A consistent result set is provided for every query, guaranteeing data consistency, with no action on
the user's part. The SQL statements SELECT, INSERT with a subquery, UPDATE, and DELETE all
query data, either explicitly or implicitly, and all return consistent data. Each of these statements
uses a query to determine which data it will affect (SELECT, INSERT, UPDATE, or DELETE,
respectively).

Transaction-Level Read Consistency

Oracle also offers the option of enforcing transaction-level read consistency. When a transaction
runs in serializable mode, all data accesses reflect the state of the database as of the time the
transaction began. This means that the data seen by all queries within the same transaction is
consistent with respect to a single point in time, except that queries made by a serializable
transaction do see changes made by the transaction itself. Transaction-level read consistency
produces repeatable reads and does not expose a query to phantoms.

Oracle Isolation Levels

Oracle provides these transaction isolation levels.
Isolation
Level Description
Read This is the default transaction isolation level. Each query executed by a transaction
committed sees only data that was committed before the query (not the transaction) began. An
Oracle query never reads dirty (uncommitted) data.

Because Oracle does not prevent other transactions from modifying the data read by
a query, that data can be changed by other transactions between two executions of
the query. Thus, a transaction that runs a given query twice can experience both
nonrepeatable read and phantoms.

Serializable Serializable transactions see only those changes that were committed at the time the
transaction began, plus those changes made by the transaction itself through
INSERT, UPDATE, and DELETE statements. Serializable transactions do not
experience nonrepeatable reads or phantoms.
Read-only Read-only transactions see only those changes that were committed at the time the
transaction began and do not allow INSERT, UPDATE, and DELETE statements.
Modes of Locking
Oracle uses two modes of locking in a multiuser database:
• Exclusive lock mode prevents the associates resource from being shared. This lock mode is
obtained to modify data. The first transaction to lock a resource exclusively is the only
transaction that can alter the resource until the exclusive lock is released.
• Share lock mode allows the associated resource to be shared, depending on the operations
involved. Multiple users reading data can share the data, holding share locks to prevent
concurrent access by a writer (who needs an exclusive lock). Several transactions can
acquire share locks on the same resource.

Lock Duration
All locks acquired by statements within a transaction are held for the duration of the transaction,
preventing destructive interference including dirty reads, lost updates, and destructive DDL
operations from concurrent transactions. The changes made by the SQL statements of one
transaction become visible only to other transactions that start after the first transaction is
committed.
Oracle releases all locks acquired by the statements within a transaction when you either commit or
undo the transaction. Oracle also releases locks acquired after a savepoint when rolling back to the
savepoint. However, only transactions not waiting for the previously locked resources can acquire
locks on the now available resources. Waiting transactions will continue to wait until after the
original transaction commits or rolls back completely.

Data Lock Conversion Versus Lock Escalation

A transaction holds exclusive row locks for all rows inserted, updated, or deleted within the
transaction. Because row locks are acquired at the highest degree of restrictiveness, no lock
conversion is required or performed.
Oracle automatically converts a table lock of lower restrictiveness to one of higher restrictiveness as
appropriate. For example, assume that a transaction uses a SELECT statement with the FOR
UPDATE clause to lock rows of a table. As a result, it acquires the exclusive row locks and a row
share table lock for the table. If the transaction later updates one or more of the locked rows, the
row share table lock is automatically converted to a row exclusive table lock.
Lock escalation occurs when numerous locks are held at one level of granularity (for example,
rows) and a database raises the locks to a higher level of granularity (for example, table). For
example, if a single user locks many rows in a table, some databases automatically escalate the
user's row locks to a single table. The number of locks is reduced, but the restrictiveness of what is
being locked is increased.
Oracle never escalates locks. Lock escalation greatly increases the likelihood of deadlocks. Imagine
the situation where the system is trying to escalate locks on behalf of transaction T1 but cannot
because of the locks held by transaction T2. A deadlock is created if transaction T2 also requires
lock escalation of the same data before it can proceed.

Types of Locks
Oracle automatically uses different types of locks to control concurrent access to data and to
prevent destructive interaction between users. Oracle automatically locks a resource on behalf of a
transaction to prevent other transactions from doing something also requiring exclusive access to
the same resource. The lock is released automatically when some event occurs so that the
transaction no longer requires the resource.
Throughout its operation, Oracle automatically acquires different types of locks at different levels
of restrictiveness depending on the resource being locked and the operation being performed.
Oracle locks fall into one of three general categories.
Lock Description
DML locks (data DML locks protect data. For example, table locks lock entire tables, row
locks) locks lock selected rows.
DDL locks DDL locks protect the structure of schema objects—for example, the
(dictionary locks) definitions of tables and views.
Internal locks and Internal locks and latches protect internal database structures such as
latches datafiles. Internal locks and latches are entirely automatic.

DML Locks
The purpose of a DML lock (data lock) is to guarantee the integrity of data being accessed
concurrently by multiple users. DML locks prevent destructive interference of simultaneous
conflicting DML or DDL operations. DML statements automatically acquire both table-level locks
and row-level locks.

Row Locks (TX)

Row-level locks are primarily used to prevent two transactions from modifying the same row. When
a transaction needs to modify a row, a row lock is acquired.
There is no limit to the number of row locks held by a statement or transaction, and Oracle does not
escalate locks from the row level to a coarser granularity. Row locking provides the finest grain
locking possible and so provides the best possible concurrency and throughput.

Table Locks (TM)

Table-level locks are primarily used to do concurrency control with concurrent DDL operations,
such as preventing a table from being dropped in the middle of a DML operation. When a DDL or
DML statement is on a table, a table lock is acquired. Table locks do not affect concurrency of DML
operations. For partitioned tables, table locks can be acquired at both the table and the subpartition
level.
A transaction acquires a table lock when a table is modified in the following DML statements:
INSERT, UPDATE, DELETE, SELECT with the FOR UPDATE clause, and LOCK TABLE. These
DML operations require table locks for two purposes: to reserve DML access to the table on behalf
of a transaction and to prevent DDL operations that would conflict with the transaction. Any table
lock prevents the acquisition of an exclusive DDL lock on the same table and thereby prevents DDL
operations that require such locks. For example, a table cannot be altered or dropped if an
uncommitted transaction holds a table lock for it.

DDL Locks
A data dictionary lock (DDL) protects the definition of a schema object while that object is acted
upon or referred to by an ongoing DDL operation. Recall that a DDL statement implicitly commits
its transaction. For example, assume that a user creates a procedure. On behalf of the user's single-
statement transaction, Oracle automatically acquires DDL locks for all schema objects referenced in
the procedure definition. The DDL locks prevent objects referenced in the procedure from being
altered or dropped before the procedure compilation is complete.

Exclusive DDL Locks

Most DDL operations, except for those listed in the section, "Share DDL Locks" require exclusive
DDL locks for a resource to prevent destructive interference with other DDL operations that might
modify or reference the same schema object. For example, a DROP TABLE operation is not allowed
to drop a table while an ALTER TABLE operation is adding a column to it, and vice versa.
During the acquisition of an exclusive DDL lock, if another DDL lock is already held on the schema
object by another operation, the acquisition waits until the older DDL lock is released and then
proceeds.
DDL operations also acquire DML locks (data locks) on the schema object to be modified.

Share DDL Locks

Some DDL operations require share DDL locks for a resource to prevent destructive interference
with conflicting DDL operations, but allow data concurrency for similar DDL operations. For
example, when a CREATE PROCEDURE statement is run, the containing transaction acquires share
DDL locks for all referenced tables. Other transactions can concurrently create procedures that
reference the same tables and therefore acquire concurrent share DDL locks on the same tables, but
no transaction can acquire an exclusive DDL lock on any referenced table. No transaction can alter
or drop a referenced table. As a result, a transaction that holds a share DDL lock is guaranteed that
the definition of the referenced schema object will remain constant for the duration of the
transaction.
A share DDL lock is acquired on a schema object for DDL statements that include the following
statements: AUDIT, NOAUDIT, COMMENT, CREATE [OR REPLACE] VIEW/
PROCEDURE/PACKAGE/PACKAGE BODY/FUNCTION/ TRIGGER, CREATE SYNONYM, and
CREATE TABLE (when the CLUSTER parameter is not included).

Oracle Lock Management Services

With Oracle Lock Management services, an application developer can include statements in
PL/SQL blocks that:
• Request a lock of a specific type
• Give the lock a unique name recognizable in another procedure in the same or in another
instance
• Change the lock type
• Release the lock