This guide provides an architectural and conceptual overview of the Oracle Database Server, an object-relational database management system. The information in this guide applies to the Oracle database server running on all operating systems.
Audience
It describes how the Oracle database server works and lays a conceptual foundation for much of the practical information in other guides.
Documentation Accessibility
To reach Oracle Support Services, you must use a telecommunications relay service (TRS) to call Oracle Support. An Oracle Support Services engineer will handle technical issues and provide customer support according to the Oracle service request process.
Related Documentation
Conventions
A Brief Introduction to Relational Databases
Database Management System (DBMS)
Each parent record has one or more child records, similar to the structure of a file system. A network database is similar to a hierarchical database, except that records have a many-to-many rather than a one-to-many relationship.
The Relational Model
Relational Database Management System (RDBMS)
The RDBMS stores and retrieves data so that physical operations are transparent to database applications. Oracle Database extended the relational model to an object-relational model, making it possible to store complex business models in a relational database.
A Brief History of Oracle Database
A RDBMS that implements object-oriented features such as user-defined types, inheritance, and polymorphism is called a. One characteristic of an RDBMS is the independence of physical data storage from logical data structures.
Indexes
A column identifies an attribute of the entity described by the table, while a row identifies an instance of the entity. For example, attributes of the employees entity correspond to columns for employee ID and last name.
Data Access
Structured Query Language (SQL)
PL/SQL and Java
You can call existing PL/SQL programs from Java and Java programs from PL/SQL.
Transaction Management
Transactions
Data Concurrency
Data Consistency
Oracle Database Architecture
Database and Instance
For example, operating system utilities such as the Linux ls and ps can list database files and processes. An SQL statement can list the tables in an Oracle database, but an operating system utility cannot.
Database Storage Structures
Because physical and logical structures are separate, physical data storage can be managed without affecting access to logical storage structures. For example, renaming a physical database file does not rename the tables whose data is stored in that file.
Physical Storage Structures
Logical Storage Structures
Database Instance Structures
Oracle Database Processes
Instance Memory Structures
Application and Networking Architecture
Application Architecture
An application server contains much of the application logic, provides access to data for the client, and performs some query processing, thereby reducing the load on the database. Web services can be accessed with the HTTP protocol and are based on a set of open standards based on XML, such as the Web Services Description Language.
Networking Architecture
In a client/server architecture, a client application initiates a request to perform an operation on the database server. The application server can serve as an interface between clients and multiple databases, providing an additional level of security.
Oracle Database Documentation Roadmap
Basic Group
Intermediate Group
Advanced Group
This section describes the basic data structures of an Oracle database, including data integrity rules and structures that store metadata. This chapter provides an introduction to schema objects and discusses tables, which are the most common types of schema objects.
Introduction to Schema Objects
Oracle Database 2 Day DBA and Oracle Database's Administrator's Guide to learn how to manage schema objects. Oracle Database 2 Day DBA and Oracle Database's Administrator's Guide to learn how to manage storage for schema objects.
SYS and SYSTEM Schemas
Sample Schemas
Overview of Tables
An external table is a read-only table whose metadata is stored in the database, but whose data is stored outside the database. A temporary table definition persists in the same way as a permanent table definition, but the data exists only for the duration of a transaction or session.
Columns and Rows
In this example, the value of 90 in department_id corresponds to the department_id column of the department table. The value of the commission_pct column for employee 100 is zero, while the value in the field for employee 149 is .2.
Oracle Data Types
For example, the first row in the output shows the record for the employee named Steven King. A foreign key column refers to a primary or unique key in the same table or another table.
Character Data Types
Unicode is a universally encoded character set that can store information in any language using a single character set. The character set of the NCHAR and NVARCHAR2 data types can only be AL16UTF16 or UTF8 and is specified as the national character set during database creation.
Numeric Data Types
Floating-Point Numbers Oracle Database provides two numeric data types exclusively for floating-point numbers: BINARY_FLOAT and BINARY_DOUBLE. Their behavior is similar to the data types FLOAT and DOUBLE in Java and XMLSchema.
Datetime Data Types
Although NUMBER uses decimal precision, BINARY_FLOAT and BINARY_DOUBLE use binary precision, which allows faster arithmetic calculations and generally reduces storage requirements. For example, the value 0.1 cannot be exactly represented by either BINARY_DOUBLE or BINARY_FLOAT.
Rowid Data Types
When a user selects the data, the value is adjusted to the time zone of the user session. When you convert a character string into a date or number, a format model determines how the database interprets the string.
Integrity Constraints
A format pattern is a character literal that describes the format of date or numeric data stored in a character string. In SQL, you can use a format pattern as an argument to the TO_CHAR and TO_DATE functions to format a value to be returned from the database or to format a value to be stored in the database.
Object Tables
Temporary Tables
At the end of the session, the schedule data in the temporary data is automatically deleted.
Temporary Table Creation
Segment Allocation in Temporary Tables
External Tables
External Table Creation
External Table Access Drivers
As rows are added, the database places them in the first available free space in the data segment. Rows are not guaranteed to be retrieved in the order in which they are entered.
Row Storage
Rowids of Row Pieces
If specified at the table space level, all tables created in this table space are compressed by default.
Storage of Null Values
Overview of Table Clusters
As an analogy, let's assume that an HR manager has two bookcases: one with boxes of employee files and one with boxes of department files. Thus, all folders for employees in department 20 and the folder for department 20 itself are in one box; the folders for employees in department 100 and the folder for department 100 are in another box, etc.
Overview of Indexed Clusters
If the tables are not clustered, the database does not ensure that the related rows are stored together. The B-tree cluster index associates the cluster key value with the database block address of the block containing the data.
Overview of Hash Clusters
Hash Cluster Creation
The database takes the value 20 as input to a hash function and then locates the block containing the rows for employees in department 20. A query for departments with IDs between 20 and 100 cannot use the hash algorithm because it does not return every possible value between 20 and 100.
Hash Cluster Variations
Hash Cluster Storage
This chapter discusses indexes, which are schema objects that can speed up access to table rows, and index-organized tables, which are tables stored in an index structure.
Overview of Indexes
Index Characteristics
Keys and Columns
Composite Indexes
Unique and Nonunique Indexes
Types of Indexes
Tree Indexes
By associating a key with a row or range of rows, B-trees provide excellent search performance for a wide range of queries, including exact match and range searches.
Branch Blocks and Leaf Blocks
The height of the index is the number of blocks required to go from the root block to a leaf block. The leaf blocks contain each indexed data value and a corresponding row that is used to locate the actual row.
Index Scans
In this case, the database can use an index-unique scan to locate the rowid for the employee whose ID is 5. The database may choose an index skip scan when the leading column of the composite index is not specified in a query predicate.
Reverse Key Indexes
The database logically splits the index into one subindex with the key F and another subindex with the key M. When searching for a record for a customer whose email is Abbey@company.com, the database first searches the subindex with the value F and then searches.
Ascending and Descending Indexes
It loads the ascending index containing the department_id and corresponding rowid values in ascending order, starting with 0. If the index in Figure 3–1 in the workers.department_id column were descending, then the leaf lock would be 250 on the left side of the tree and block with 0 on the right.
Key Compression
When using the index, Oracle Database looks up the sorted department identifier values and uses the related rows to find the rows that have the required department identifier value. By specifying the DESC keyword in the CREATE INDEX statement, you can create a descending index.
Bitmap Indexes
Each suffix entry references a prefix entry, which is stored in the same index block as the suffix entry. In branch blocks the key suffix may be shortened, but the key is not compressed.
Bitmap Indexes on a Single Table
For example, the bitmap for the value M contains a 1 as its first bit because the gender is M in the first row of the customers table. Bitmap indexes can handle this query efficiently by counting the number of 1 values in the resulting bitmap, as illustrated in Table 3-2.
Bitmap Join Indexes
The previous query would typically use an index on jobs.job_title to retrieve the rows for Accountant and then the job ID and an index on employee.job_id to find the matching rows. As illustrated in Figure 3–2, the index key is jobs.job_title and the indexed table is employees.
Bitmap Storage Structure
In a data warehouse, the join condition is an equijoin (it uses the equality operator) between the primary key columns of the dimension tables and the foreign key columns of the fact table.
Function-Based Indexes
Uses of Function-Based Indexes
For example, the cust_valid column in the sh.customers table has a value of I or A. To index only the A rows, you can write a function that returns a null value for all rows other than the A rows.
Optimization with Function-Based Indexes
Application Domain Indexes
You can encapsulate application-specific index management routines as a schema object of type index and define a domain index on table columns or attributes of an object type. The index structure itself can be stored in the database as an index-organized table or externally as a file.
Index Storage
Overview of Index-Organized Tables
Index-organized tables are useful when related pieces of data need to be stored together or the data needs to be physically stored in a specific order.
Index-Organized Table Characteristics
An index-organized table stores all data in the same structure and does not need to store the rowid. So the number of block I/Os in this example is double the number in the index-organized example.
Index-Organized Tables with Row Overflow Area
Secondary Indexes on Index-Organized Tables
Because rows in index-organized tables do not have permanent physical addresses, the database uses logical rows based on primary key. Secondary indexes provide fast and efficient access to index-organized tables using columns that are not the primary key or a prefix of the primary key.
Logical Rowids and Physical Guesses
As explained in "Rowid Data Types" on page 2-13, Oracle Database uses row IDs called logical rowids for index-organized tables. For imprecise physical guesses, access includes a secondary index scan and an I/O to retrieve the wrong data block (as indicated by the guess), followed by a unique index scan of the index-organized table based on the primary key value.
Bitmap Indexes on Index-Organized Tables
Although tables and indexes are the most important and most commonly used schema objects, the database supports many other types of schema objects, the most common of which are discussed in this chapter.
Overview of Partitions
This allows you to interrupt resource-intensive tasks such as rebuilding an index or table.
Partition Characteristics
Partition Key
Partitioning Strategies
The database chooses the partition for each row based on the time_id value according to the rules specified in the PARTITION BY RANGE clause. The database chooses the partition for each row based on the channel_id value according to the rules specified in the PARTITION BY LIST clause.
Partitioned Tables
Partitioned Indexes
Local Partitioned Indexes
Instead, local index partitions are only deleted when you drop a partition from the underlying table. Local Partitioned Index Storage Like a table partition, a local index partition is stored in its own segment.
Global Partitioned Indexes
A query that uses a prefixed local index always allows index partitioning to be eliminated, while a query that uses an unprefixed local index may not. Thus, a local index consisting of four partitions is not stored in a single index segment, but in four separate segments.
Partitioned Index-Organized Tables
Overview of Views
For an example of using views, see the hr.employees table, which has multiple columns and numerous rows.
Characteristics of Views
Data Manipulation in Views
As with all subqueries, the query that defines a view cannot contain the FOR UPDATE clause. CHECK OPTION creates the view with a constraint so that INSERT and UPDATE statements issued against the view cannot result in rows that the view cannot select.
How Data Is Accessed in Views
Updatable Join Views
Object Views
Overview of Materialized Views
In a replication environment, a materialized view shares data with a table in another database, called a master database. The table associated with the materialized view at the master site is the master table.
Characteristics of Materialized Views
A materialized view is similar to a non-materialized view in that it represents data in other tables and views. You can define a materialized view on a partitioned table and one or more indexes on the materialized view.
Refresh Methods for Materialized Views
The following example drops table sales, which is a master table for sales_mv, and then queries sales_mv. The materialized view log resides in the same database and schema as its master table.
Query Rewrite
Overview of Sequences
Sequence Characteristics
Concurrent Access to Sequences
Overview of Dimensions
Hierarchical Structure of a Dimension
Creation of Dimensions
LEVEL nënrajon IS (countries.country_subregion) LEVEL rajoni IS (countries.country_region) HIERARCHY geog_rollup. BASHKOHU KYÇI (customers.country_id) REFERENCAT shteti ) ATRIBUTE PERCAKTIMI I klientit. cust_first_name, cust_last_name, cust_gender, cust_marital_status, cust_year_of_birth, cust_come_nivel, cust_credit_limit).
Overview of Synonyms
As shown in Example 4–9, if another administrator tries to create the public synonym people, then the creation fails because only one public synonym people can exist in the database. The synonym only acts as an alias for the object in the GRANT statement.
Introduction to Data Integrity
Techniques for Guaranteeing Data Integrity
Advantages of Integrity Constraints
Integrity constraints are defined for tables and are stored in the data dictionary (see "Data dictionary overview" on page 6-1). You can temporarily disable integrity throttling to avoid performance overhead when loading large amounts of data.
Types of Integrity Constraints
Because you define integrity constraints using SQL statements, no additional programming is required when defining or modifying a table. In addition, applications can use metadata in the data dictionary to immediately notify users of violations before the database checks the SQL statement.
NOT NULL Integrity Constraints
Unique Constraints
As shown in Example 2–1 on page 2-8, a unique key constraint exists on the email column of the hr.employees table. Note: Due to the lookup mechanism for unique key constraints on multiple columns, you cannot have identical values in the non-null columns of a partially null composite unique key constraint.
Primary Key Constraints
For example, the department_id column in employees is a foreign key that references the department_id column in departments. Reference key The unique key or primary key of the table referenced by the foreign key.
Self-Referential Integrity Constraints
Nulls and Foreign Keys
Parent Key Modifications and Foreign Keys
For example, deleting a department row sets the department_id column value to zero for employees in this department. Table 5–3 lists the DML statements allowed by the various reference actions on the key values in the parent table, and the foreign key values in the child table.
Indexes and Foreign Keys
Check Constraints
For example, the salary column might have one constraint that prevents values over 10,000 and a separate constraint that prevents values less than 500. If multiple check constraints exist for a column, they must be designed so that their purposes do not conflict.
States of Integrity Constraints
Checks for Modified and Existing Data
Deferrable Constraints
Nondeferrable Constraints
The self-referential constraint causes the entries in the manager_id column to depend on the values of the employee_id column.
Insertion of a Value in a Foreign Key Column When No Parent Key Value Exists
An Update of All Foreign Key and Parent Key Values
Although a constraint is defined to verify that each manager_id value matches an employee_id value, the previous statement is legal because the database effectively checks the constraints after the statement ends. Figure 5-4 shows that the database executes the entire SQL statement before checking the constraints.
Overview of the Data Dictionary
This chapter describes the central set of read-only reference tables and views of each Oracle database, collectively known as the data dictionary. The chapter also describes dynamic performance views, which are special views that are constantly updated while a database is open and in use.
Contents of the Data Dictionary
Views with the Prefix DBA_
Views with the Prefix ALL_
Views with the Prefix USER_
The DUAL Table
Storage of the Data Dictionary
How Oracle Database Uses the Data Dictionary
During database operation, Oracle Database reads the data dictionary to verify that schema objects exist and that users have appropriate access to them. Oracle Database also continuously updates the data dictionary to reflect changes in database structures, auditing, grants, and data.
Public Synonyms for Data Dictionary Views
For example, if the user hr creates a table named interns, then new rows are added to the data dictionary that reflect the new table, columns, segment, extents, and privileges that hr has on the table.
Cache the Data Dictionary for Fast Access
Other Programs and the Data Dictionary
Overview of the Dynamic Performance Views
Contents of the Dynamic Performance Views
Storage of the Dynamic Performance Views
Database Object Metadata
Introduction to SQL
SQL Data Access
This chapter provides an overview of Structured Query Language (SQL) and how Oracle Database processes SQL statements. All SQL statements use the optimizer, a part of the Oracle database that determines the most efficient means of accessing the specified data.
SQL Standards
The database retrieves all rows that satisfy the WHERE condition, also called the predicate, in a single step. Oracle Database also supports techniques that you can use to make the optimizer do its job better.
Overview of SQL Statements
Data Definition Language (DDL) Statements
In Example 7–1, two INSERT statements are followed by an ALTER TABLE statement, so the database executes the two INSERT statements. If the ALTER TABLE statement succeeds, then the database executes this statement; otherwise, the database returns this statement.
Data Manipulation Language (DML) Statements
Example 7–1 uses DDL statements to create the plants table and then uses DML to insert two rows into the table. An implicit COMMIT occurs just before the database executes the DDL statement, and a COMMIT or ROLLBACK occurs immediately after.
SELECT Statements
For example, a transaction to transfer money may involve three discrete operations: decreasing the balance of the savings account, increasing the balance of the checking account, and recording the transfers in an account history table.
Joins
An inner join is a join of two or more tables that returns only rows that meet the join condition. An outer join returns all rows that meet the join condition and also returns rows from one table for which no rows from the other table meet the condition.
Subqueries and Implicit Queries
For example, a left outer join of employees and departments retrieves all rows in the employees table, even if there is no match in departments. For example, an INSERT INTO TABLE mytable VALUES (1) statement does not retrieve rows until a row is inserted.
Transaction Control Statements
The only DML statement that does not necessarily include a query component is an INSERT statement with a VALUES clause.
Session Control Statements
Alter the current session by performing a specialized function, such as enabling and disabling SQL tracing (ALTER SESSION). Enable and disable roles, which are groups of privileges, for the current session (SET ROLE).
System Control Statement
A session lasts from the moment the user is authenticated by the database until the user disconnects or exits the database application.
Embedded SQL Statements
Overview of the Optimizer
Use of the Optimizer
A typical end-user, interactive application would benefit from initial response time optimization, whereas a batch-mode, non-interactive application would benefit from total throughput optimization.
Optimizer Components
Query Transformer
Estimator
Plan Generator
Access Paths
A cluster scan is used to retrieve data from a table stored in an indexed table cluster, where all rows with the same cluster key value are stored in the same data block (see "Overview of Indexed Clusters" on page 2-21). The database first obtains the hash value by applying a hash function to a group key value specified by the statement.
Optimizer Statistics
A hash scan is used to locate rows in a hash array, where all rows with the same hash value are stored in the same data block (see "Hash Array Overview" on page 2-23. Optimizer statistics are generated for the purposes of query optimization and stored in the data dictionary.
Optimizer Hints
The execution plan in examples 7–5 merges two indexes to return the requested records as quickly as possible. Instead of going from index to table repeatedly as in example 7-4, the optimizer chooses a range scan of EMP_DEPARTMENT_IX to find all rows whose department ID is greater than 50 and places those rows in a hash table.
Overview of SQL Processing
In this case, the database cannot return the first row to the client until the scan of the EMP_DEPARTMENT_IX index range is complete. Unlike the design in Example 7-4, which accesses the table by index rowid, the design in Example 7-5 uses multiblock I/O, resulting in many reads.
Stages of SQL Processing
For each row in this index, the hash table is searched to find the department ID.
SQL Parsing
For this purpose, the database uses a hash algorithm to generate a hash value for each SQL statement. If a check determines that a statement in the shared pool has the same hash value, then the database performs semantic and environmental checks to determine if the statements mean the same thing.
SQL Optimization
SQL Row Source Generation
In the preceding example, the same SELECT statement is executed in three different optimization environments. SELECT e.last_name, j.job_title, d.department_name FROM mr.employees e, mr.departments d, mr.jobs j WHERE e.department_id = d.department_id.
SQL Execution
In Figure 7-5, each node of the tree acts as a row source, meaning that each step of the execution plan either retrieves rows from the database or accepts rows from one or more row sources as input. The steps indicated by the black boxes physically retrieve data from an object in the database.
How Oracle Database Processes DML
For example, the row for employee Atkinson is associated with the job title Stock Clerk. The database also takes out any locks and latches necessary to ensure data integrity and records any changes made during the SQL execution.
Read Consistency
The plan shown in Example 7-6 is iterative because the SQL engine moves from the index to the table to the client and then repeats the steps. At runtime, the database reads data from disk into memory if the data is not already in memory.
Data Changes
How Oracle Database Processes DDL
Chapter 7, "SQL" explains the Structured Query Language (SQL) and how the database processes SQL statements. This chapter explains how Procedural Language/SQL (PL/SQL) or Java programs stored in the database can use SQL.
Introduction to Server-Side Programming
Use server-side programming to develop data logic that resides in the database. An application can explicitly invoke stored subprograms (procedures and . functions), written in PL/SQL (pronounced PL successor) or Java. Java stored subprograms run in the database and are independent of programs running in the middle layer.
Overview of PL/SQL
You can also create a trigger called a program unit that is stored in the database and invoked in response to a specific event. Applications written in database APIs can call PL/SQL stored routines and send blocks of PL/SQL code to the database for execution.
PL/SQL Subprograms
Advantages of PL/SQL Subprograms
If the data structures referenced by the procedure have changed, then you only need to recompile the procedure. Users who have only the privilege to execute the procedure (but not privileges to query, update, or delete from the underlying tables) can call the procedure but not manipulate the table's data in any other way.
Creation of PL/SQL Subprograms
Inherited Privileges and Schema Context with Caller Rights Procedures The caller rights procedure runs in the current user's schema with the current user's privileges. In other words, the caller rights process is not tied to a specific user or scheme.
Execution of PL/SQL Subprograms
Example 8–1 PL/SQL Procedure CREATE PROCEDURE hire_employees IS. p_last_name VARCHAR2, p_job_id VARCHAR2, p_manager_id NUMBER, p_hire_date DATE, p_salary NUMBER, p_commission_pct NUMBER, p_department_id NUMBER). For example, if you change the definition of the employee table referenced by the hire_employees procedure in a way that affects this procedure, the procedure must be recompiled to verify that it still works as intended.
PL/SQL Packages
Advantages of PL/SQL Packages
You can define the package so that only three procedures are public and therefore available for execution by a user of the package. The remaining procedures are private and can only be accessed by the procedures in the package.
Creation of PL/SQL Packages
An entire package is loaded into memory in small chunks when a procedure in the package is called for the first time. After you create the package, you can develop applications that call any of these public procedures or functions or raise any of the package's public exceptions.
Execution of PL/SQL Package Subprograms
PL/SQL Anonymous Blocks
PL/SQL Language Constructs
PL/SQL allows you to explicitly handle internal and user-defined error conditions, called exceptions, that occur during the processing of PL/SQL code. PL/SQL can run dynamic SQL statements whose full text is not known until runtime.
PL/SQL Collections and Records
You can declare a cursor explicitly within a procedure, function, or package to facilitate record-oriented processing of Oracle database data. For example, you can create a procedure that operates on a table whose name is not known until runtime.
Collections
Dynamic SQL statements are stored in character strings that are entered into the program or built into the program at runtime.
Records
How PL/SQL Runs
Overview of Java in Oracle Database
Overview of the Java Virtual Machine (JVM)
Overview of Oracle JVM
Main Components of Oracle JVM
Java Programming Environment
Java Stored Procedures
Java and PL/SQL Integration
You can use SQLJ in stored procedures, triggers, and methods in an Oracle Database environment. Because Oracle Database provides a full Java environment, you cannot compile SQLJ programs on the client that will run on the database.
Overview of Triggers
Advantages of Triggers
Types of Triggers
A system event trigger can be caused by events such as starting and shutting down database instances or error messages. A user event trigger fires due to events related to user logon and logoff, DDL statements, and DML statements.
Timing for Triggers
Creation of Triggers
For example, the trigger will not fire unless the number of available parts is less than a current reorder amount. The UPDATE statement changes 2 rows in the line item tables, which fires the trigger once for each row.
Execution of Triggers
Storage of Triggers
Thus, creating a Java trigger involves creating Java code and creating a trigger that references that Java code. See also: Oracle Database PL/SQL Language Reference to learn more about compiling and storing triggers.
Introduction to Transactions
After the transaction is completed, the database uses its recovery mechanisms to ensure that the changes from the transaction are not lost.
Sample Transaction: Account Debit and Credit
Structure of a Transaction
One or more Data Manipulation Language (DML) statements that together represent an atomic change to the database.
Beginning of a Transaction
End of a Transaction
A client process terminates abnormally, causing the transaction to be implicitly rolled back using metadata stored in the transaction table and undo segment.
Statement-Level Atomicity
For example, if the execution of the second UPDATE statement in Figure 9-1 causes an error and is rolled back, then the work done by the first UPDATE statement is not rolled back. Any side effects of an atomic statement, for example triggers that are invoked during the execution of the statement, are considered part of the atomic statement.
System Change Numbers (SCNs)
An example of an error that causes a statement-level rollback is an attempt to insert a duplicate primary key. However, errors detected during SQL statement parsing, such as a syntax error, have not yet been run and therefore do not cause a statement-level rollback.
Overview of Transaction Control
Transaction Names
Active Transactions
The redo log record contains the change to the data block and the change to the undo block. The data changes for a committed transaction stored in the SGA's database buffers are not necessarily written immediately to the data files by the database writer (DBWn).
Savepoints
The undo data contains the old data values that were changed by the SQL statements of the transaction. Other users cannot change the data in the affected rows, nor can they see the uncommitted changes.
Rollback to Savepoint
Enqueued Transactions
Rollback of Transactions
Committing Transactions
The speed of a commit does not increase with the size of the data modified in the transaction. However, the amount of time spent by LGWR is reduced because it has been additionally writing the contents of the redo log buffer in the background.
Overview of Autonomous Transactions
Figure 9-2 shows how control flows from the main routine (MT) to an autonomous routine and back again. The autonomous routine may commit several transactions (AT1 and AT2) before returning control to the main routine.
Overview of Distributed Transactions
In PL/SQL, an autonomous transaction is executed within an autonomous scope, which is a routine marked with the pragma AUTONOMOUS_TRANSACTION. The pragma AUTONOMOUS_TRANSACTION instructs the database that this procedure, when executed, should be executed as a new one.
Two-Phase Commit
In-Doubt Transactions
Oracle Database must coordinate transaction control across a network and maintain data consistency even if a network or system failure occurs.
Introduction to Data Concurrency and Consistency
Multi-Versioning Read Consistency
Statement-Level Read Consistency
Transaction-Level Read Consistency
Read Consistency and Undo Segments
As the database retrieves blocks of data on behalf of a query, the database ensures that the data in each block reflects the contents of the block when the query began. The database rolls back changes to the block as needed to rebuild the block back to when the query began processing.
Locking Mechanisms
Entries in the transaction table describe which transactions have locked rows and which rows in the block contain committed and uncommitted changes. In a sense, the block header contains a recent history of transactions that affected each row in the block.
ANSI/ISO Transaction Isolation Levels
Reading consistency and transaction tables The database uses a transaction table, also called a list of interested transactions (ITL), to determine if a transaction was not committed when the database began modifying the block.
Overview of Oracle Database Transaction Isolation Levels
Read Committed Isolation
Read Consistency in the Read Committed Isolation Level
Conflicting Writes in Read Committed Transactions
Serializable Isolation
Oracle Database only allows a serializable transaction to modify a row if changes to the row by other transactions were already committed when the serializable transaction began. If the serializable transaction does not attempt to modify a row committed by another transaction after the serializable transaction began, then a serialized access problem is avoided.
Read-Only Isolation
Overview of the Oracle Database Locking Mechanism
Summary of Locking Behavior
Use of Locks
