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

The figure below depicts the relationship between segments. views. The criticality of this file is ascribed to the fact that if it is damaged then the database recovery operation becomes tedious. and so on. It contains information stored in the Redo Log Buffer. automatically shifting processing load based on demand. triggers. easy migration etc. where g stands for Grid computing. sequences. The information in the Redo Log Buffer is written into Redo Log files by the LGWR background process. and data blocks: The physical layer comprises the following files: • : Though it is the smallest file (1MB-5MB) of the database. extents. • In 2007. • : These hold data that is stored in tables of a database. The Redo Log files are generally multiplexed and copied for recovery purposes. Sets of redo Log files are known as Redo Log groups. Starting the instance sqlplus /nolog connect sys/MYSECRETPASSWORD as sysdba Connected to an idle instance. They are usually the largest files in the database. to TB. Oracle has released Oracle11g. The database schema is a collection of schema objects. Redo Log groups . ranging in size from MB. The names and locations of all the control files of the database can be obtained from the V$CONTROLFILE dynamic performance view. clusters. GB. The hierarchy of Oracle disk-space management is as follows: • • • • Tablespaces: These are at the highest level of Oracle disk-space management. 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. • : These files contain information that helps in recovery in the event of system failure. The database schema consists of tables. Oracle10g also made a lot of administrative tasks automatic. which servers computing power across the enterprise as a utility. You can get information about new features that were introduced in Oracle9i using New features of Oracle9i Database • In 2003. Oracle10g was released. Segments Extents Data blocks: These are at the lowest level of Oracle disk-space management. The new version focused on better partitioning. indexes. It contains the requisite information to start the database. procedures. it is the most crucial and critical file.queried in Oracle Database. Each database has minimum of two Redo Log groups.

Some of the main functions of background processes are: • Communication among Oracle instances • Performing computer maintenance • Writing the dirty blocks to disk 5. server processes. The Database Buffer Cache 2. PGA is used to store session specific information. There are two categories of processes that run with an Oracle database. . 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 writes data from the Log Buffer to the redo log. Each group consists of two members.It stands for Program Global Area. 3. They are mentioned below: • User processes • System processes The following figure illustrates the relationship between user processes. The Shared Pool • PGA. The first member of each Redo Log group is stored in directory D1 and the second member is stored in directory D2. – It writes data blocks from SGA to data files. The Redo Log Buffer 3. 4. 2. The user process then communicates with the server process on the host computer. A PGA is allocated whenever an Oracle database user connects to a database and a session is created for him/her. 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. and session: The first interaction with the Oracle-based application comes from the user computer that creates a user process. – It stands for . The V$LOGFILE dynamic performance view is used to obtain information about the names and locations of the Redo Log groups and their members. – It stands for .are used in a circular fashion. This can be either a server or a background process. The figure below depicts the use of Redo Log files in circular fashion: The figure above shows three Redo Log groups. 1. 2. The background processes are categorized into: • Required Oracle background processes • Optional Oracle background processes Some of the background processes are: 1.It stands for System Global Area. PGA. It is a region in memory that contains data and control information for a single process. 1. – It timestamps all the data files and the control files whenever a checkpoint occurs. SGA is allocated whenever an Oracle instance starts and gets de-allocated when the Oracle instance is shutdown. It keeps track of database processes. Here. Oracle has a large number of background processes. It performs instance recovery at instance startup. It also restarts those dispatcher processes that might have failed.

fat.g. Oracle materialized views Materialized views are an Oracle Silver Bullet when pre-joining tables together for super-fast response time. and their interactions with control files. PFILE holds 30 of those 250 initialization parameters. data files. and archived redo logs. This article has described the various facts involved in order to understand the underlying Oracle architecture. To manage the size of SGA. and partitioning may help. Using materialized views we pre-join the tables together. The Oracle instance consists of SGA and all the Oracle background processes. 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. over-and-over again. One issue with highly-normalized.The following figure depicts the Oracle Architecture in detail: The figure above shows various components of SGA. either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege. two initialization parameter files known as PFILE and SPFILE are used. the database user is now well equipped to understand several components of Oracle architecture. but careful attention must be paid to choosing the proper materialized view partition keys and the best refresh interval. Oracle does not recommend modifying the rest of the 220 initialization parameters. resulting in blisteringly fast response time. CREATE MATERIALIZED VIEW LOG ON "SCOTT". non-redundant Oracle table designs (e. This can reduce logical I/O from tens of thousands to a single row fetch. Oracle background processes. After reviewing this article. There are a total of 250-initialization parameters. Because the materialized view is built from many tables. The problem with materialized view for pre-joined tables is keeping them refreshed. . wide and highlyredundant table. Redo Log files."DEPT" WITH ROWID . • You must also have access to any master tables of the materialized view that you do not own. and changes to the base tables require an update to the materialized view. third normal form) is that Oracle experiences a high degree of overhead (especially CPU consumption) when joining dozens of tables together. resulting in a single.

e.country_region) HIERARCHY geog_rollup ( customer CHILD OF city CHILD OF state CHILD OF country CHILD OF subregion CHILD OF region JOIN KEY (customers. The optimizer uses these relationships with materialized views to perform query rewrite. • Data concurrency means that many users can access data at the same time.country_id) LEVEL subregion IS (countries. control of data concurrency and data consistency is vital in a multiuser database. rather than concurrently. The SQLAccess Advisor uses these relationships to recommend creation of specific materialized views. CREATE DIMENSION customers_dim LEVEL customer IS (customers. 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.country_id) REFERENCES country ) Data Concurrency and Consistency in a multiuser database. . 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.cust_city) LEVEL state IS (customers.g.country_subregion) LEVEL region IS (countries. the statements within multiple simultaneous transactions can update the same data. To describe consistent transaction behavior when transactions run at the same time.Dimension A dimension is an Oracle object which defines a hierarchical (parent/child) relationships between columns. It is highly recommended that dimensions on your data are defined because they help query rewrite and the summary advisor make better decisions. columns in one column set (called a level) can come from a different table than columns in another set. • Data consistency means that each user sees a consistent view of the data. Transactions executing at the same time need to produce meaningful and consistent results. or serially. 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. 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.cust_id) LEVEL city IS (customers.cust_state_province) LEVEL country IS (countries. including visible changes made by the user's own transactions and transactions of other users. the query refers to Tuesday rather than a specific date. However. Therefore. database researchers have defined a transaction isolation model called serializability.

.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. • 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. Oracle can also provide read consistency to all of the queries in a transaction (transaction-level read consistency). Table 13-1 Preventable Read Phenomena by Isolation Level Isolation Level Read uncommitted Read committed Repeatable read Serializable Dirty Read Possible Not possible Not possible Not possible Nonrepeatable Read Possible Possible Not possible Not possible Phantom Read Possible Possible 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 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). • Nonrepeatable (fuzzy) reads: A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data. such as tables and rows (structures and data) • System objects not visible to users.

UPDATE. Because Oracle does not prevent other transactions from modifying the data read by a query. UPDATE. INSERT with a subquery. . Transaction-Level Read Consistency Oracle also offers the option of enforcing transaction-level read consistency. Each of these statements uses a query to determine which data it will affect (SELECT. When a transaction runs in serializable mode. and all return consistent data. Read-only Read-only transactions see only those changes that were committed at the time the transaction began and do not allow INSERT. This guarantees that all the data returned by a single query comes from a single point in time—the time that the query began. except that queries made by a serializable transaction do see changes made by the transaction itself.Statement-Level Read Consistency Oracle always enforces statement-level read consistency. guaranteeing data consistency. The query does not see changes committed after statement execution begins. a transaction that runs a given query twice can experience both nonrepeatable read and phantoms. Thus. and DELETE statements. and DELETE all query data. or DELETE. and DELETE statements. Transaction-level read consistency produces repeatable reads and does not expose a query to phantoms. An Oracle query never reads dirty (uncommitted) data. that data can be changed by other transactions between two executions of the query. plus those changes made by the transaction itself through INSERT. Isolation Level Read committed Description This is the default transaction isolation level. This means that the data seen by all queries within the same transaction is consistent with respect to a single point in time. Therefore. all data accesses reflect the state of the database as of the time the transaction began. INSERT. Oracle Isolation Levels Oracle provides these transaction isolation levels. only data committed before the query began is visible to the query. UPDATE. either explicitly or implicitly. UPDATE. a query never sees dirty data or any of the changes made by transactions that commit during query execution. As query execution proceeds. respectively). Each query executed by a transaction sees only data that was committed before the query (not the transaction) began. Serializable transactions do not experience nonrepeatable reads or phantoms. A consistent result set is provided for every query. Serializable Serializable transactions see only those changes that were committed at the time the transaction began. The SQL statements SELECT. with no action on the user's part.

or deleted within the transaction. no lock conversion is required or performed. only transactions not waiting for the previously locked resources can acquire locks on the now available resources. Lock escalation greatly increases the likelihood of deadlocks. • Share lock mode allows the associated resource to be shared. Lock escalation occurs when numerous locks are held at one level of granularity (for example. some databases automatically escalate the user's row locks to a single table. For example. Because row locks are acquired at the highest degree of restrictiveness. Waiting transactions will continue to wait until after the original transaction commits or rolls back completely. preventing destructive interference including dirty reads. rows) and a database raises the locks to a higher level of granularity (for example. 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. Several transactions can acquire share locks on the same resource. it acquires the exclusive row locks and a row share table lock for the table. Oracle also releases locks acquired after a savepoint when rolling back to the savepoint. lost updates. depending on the operations involved. but the restrictiveness of what is being locked is increased. Multiple users reading data can share the data. the row share table lock is automatically converted to a row exclusive table lock. A deadlock is created if transaction T2 also requires lock escalation of the same data before it can proceed. Oracle releases all locks acquired by the statements within a transaction when you either commit or undo the transaction. As a result. Oracle never escalates locks. The first transaction to lock a resource exclusively is the only transaction that can alter the resource until the exclusive lock is released. table). For example. updated. Data Lock Conversion Versus Lock Escalation A transaction holds exclusive row locks for all rows inserted. Oracle automatically converts a table lock of lower restrictiveness to one of higher restrictiveness as appropriate. 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. and destructive DDL operations from concurrent transactions. Lock Duration All locks acquired by statements within a transaction are held for the duration of the transaction. if a single user locks many rows in a table. assume that a transaction uses a SELECT statement with the FOR UPDATE clause to lock rows of a table. The number of locks is reduced. The lock is released automatically when some event occurs so that the . The changes made by the SQL statements of one transaction become visible only to other transactions that start after the first transaction is committed. However. holding share locks to prevent concurrent access by a writer (who needs an exclusive lock).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. If the transaction later updates one or more of the locked rows. Types of Locks Oracle automatically uses different types of locks to control concurrent access to data and to prevent destructive interaction between users.

UPDATE. The DDL locks prevent objects referenced in the procedure from being . and LOCK TABLE. Oracle locks fall into one of three general categories. Throughout its operation. Lock DML locks (data locks) DDL locks (dictionary locks) Internal locks and latches Description DML locks protect data. table locks can be acquired at both the table and the subpartition level. assume that a user creates a procedure. For example. such as preventing a table from being dropped in the middle of a DML operation. 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. table locks lock entire tables. For example. Recall that a DDL statement implicitly commits its transaction. When a transaction needs to modify a row. DDL locks protect the structure of schema objects—for example. DML statements automatically acquire both table-level locks and row-level locks. a row lock is acquired. Row Locks (TX) Row-level locks are primarily used to prevent two transactions from modifying the same row.transaction no longer requires the resource. For example. Table Locks (TM) Table-level locks are primarily used to do concurrency control with concurrent DDL operations. When a DDL or DML statement is on a 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. Oracle automatically acquires different types of locks at different levels of restrictiveness depending on the resource being locked and the operation being performed. DELETE. a table lock is acquired. Oracle automatically acquires DDL locks for all schema objects referenced in the procedure definition. Any table lock prevents the acquisition of an exclusive DDL lock on the same table and thereby prevents DDL operations that require such locks. A transaction acquires a table lock when a table is modified in the following DML statements: INSERT. Table locks do not affect concurrency of DML operations. DML locks prevent destructive interference of simultaneous conflicting DML or DDL operations. row locks lock selected rows. SELECT with the FOR UPDATE clause. the definitions of tables and views. Row locking provides the finest grain locking possible and so provides the best possible concurrency and throughput. For partitioned tables. Internal locks and latches protect internal database structures such as datafiles. On behalf of the user's singlestatement transaction. There is no limit to the number of row locks held by a statement or transaction. 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. and Oracle does not escalate locks from the row level to a coarser granularity.

DDL operations also acquire DML locks (data locks) on the schema object to be modified. Other transactions can concurrently create procedures that reference the same tables and therefore acquire concurrent share DDL locks on the same tables. As a result. CREATE [OR REPLACE] VIEW/ PROCEDURE/PACKAGE/PACKAGE BODY/FUNCTION/ TRIGGER.altered or dropped before the procedure compilation is complete. and vice versa. Exclusive DDL Locks Most DDL operations. A share DDL lock is acquired on a schema object for DDL statements that include the following statements: AUDIT. CREATE SYNONYM. During the acquisition of an exclusive DDL lock. the acquisition waits until the older DDL lock is released and then proceeds. 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. No transaction can alter or drop a referenced table. a DROP TABLE operation is not allowed to drop a table while an ALTER TABLE operation is adding a column to it. "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. the containing transaction acquires share DDL locks for all referenced tables. and CREATE TABLE (when the CLUSTER parameter is not included). For example. NOAUDIT. if another DDL lock is already held on the schema object by another operation. but allow data concurrency for similar DDL operations. For example. COMMENT. but no transaction can acquire an exclusive DDL lock on any referenced table. Share DDL Locks Some DDL operations require share DDL locks for a resource to prevent destructive interference with conflicting DDL operations. 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 . Oracle Lock Management Services With Oracle Lock Management services. when a CREATE PROCEDURE statement is run. except for those listed in the section.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.