Entry Topic
Oracle7 Server Concepts Manual

Oracle7™ Server Concepts Manual

PREFACE

PART  I . WHAT IS ORACLE?

CHAPTER 1. A TECHNICAL INTRODUCTION TO THE ORACLE SERVER

PART  II . BASIC DATABASE OPERATION

CHAPTER 2. DATABASE AND INSTANCE STARTUP AND SHUTDOWN

PART  III . DATABASE STRUCTURES

CHAPTER 3. DATA BLOCKS, EXTENTS, AND SEGMENTS

CHAPTER 4. TABLESPACES AND DATA FILES

CHAPTER 5. SCHEMA OBJECTS

CHAPTER 6. DATATYPES

CHAPTER 7. DATA INTEGRITY

CHAPTER 8. THE DATA DICTIONARY

PART  IV . SYSTEM ARCHITECTURE

CHAPTER 9. MEMORY STRUCTURES AND PROCESSES

CHAPTER 10. DATA CONCURRENCY

PART  V . DATA ACCESS

CHAPTER 11. SQL AND PL/SQL

CHAPTER 12. TRANSACTION MANAGEMENT

CHAPTER 13. THE OPTIMIZER

PART  VI . PROGRAMMATIC CONSTRUCTS

CHAPTER 14. PROCEDURES AND PACKAGES

CHAPTER 15. DATABASE TRIGGERS

CHAPTER 16. DEPENDENCIES AMONG SCHEMA OBJECTS

PART  VII . DATABASE SECURITY

CHAPTER 17. DATABASE ACCESS

CHAPTER 18. PRIVILEGES AND ROLES

CHAPTER 19. AUDITING

PART  VIII . DISTRIBUTED PROCESSING AND DISTRIBUTED DATABASES

CHAPTER 20. CLIENT-SERVER ARCHITECTURE

CHAPTER 21. DISTRIBUTED DATABASES

CHAPTER 22. TWO-PHASE COMMIT

PART  IX . DATABASE BACKUP AND RECOVERY

CHAPTER 23. RECOVERY STRUCTURES

CHAPTER 24. DATABASE BACKUP

CHAPTER 25. DATABASE RECOVERY

APPENDIX A. NATIONAL LANGUAGE SUPPORT

APPENDIX B. OPERATING SYSTEM SPECIFIC INFORMATION


This help file created via:

 Version 1.0n

© 1994 Oracle Corporation Inc.

Authored by KM .


A12713-1


Oracle7ä Server Concepts Manual
Oracle7™ Server Concepts Manual

Part No. A12713-1

August 10, 1993

Oracle7 Server Concepts Manual

Part No. A12713-1

Copyright  1993 Oracle Corporation dates

Contributing Authors:  Eric Armstrong, Steven Bobrowski, Cindy Closkey, Brian Linden, Maria Pratt

Contributors:  Richard Allen, David Anderson, Lori Asher, Andre Bakker, Bill Bridge, Atif Chaudry, Cray Clossman, Jeff Cohen, Dave Ensor, Stephan Faris, John Frazzini, Anaraug Gupta, Gary Hallmark, Michael Hartstein, Terry Hayes, Brian Hirano, Ken Jacobs, Sandeep Jain, Robert Jenkins, Jr., Michael Kennedy, Jonathan Klein, R. Kleinro, Robert Kooi, Lefty Leverenz, Walter Lindsay, Juan Loaiza, Brom Mahbod, William Maimone, Andrew Mendelsohn, Mark Moore, Edward Peeler, Mark Porter, Tuomas Pystenen, Brian Quigley, Patrick Ritto, Gordon Smith, Leng Leng Tan, Joyo Wijaya, Beth Winslow, Kevin Wharton

This software/documentation contains proprietary information of Oracle Corporation; it is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited.

If this software/documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:

Restricted Rights Legend  Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988) Oracle Corporation, 500 Oracle Parkway, Redwood City, CA  94065..

If this software/documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with "Restricted Rights," as defined in FAR 52.227-14, Rights in Data - General, including Alternate III (June 1987).

The information in this document is subject to change without notice.  If you find any problems in the documentation, please report them to us in writing.  Oracle Corporation does not warrant that this document is error-free.

Oracle, Pro*Ada, Pro*COBOL, Pro*FORTRAN, Pro*PL/I, Pro*Pascal, SQL*DBA, SQL*Forms, SQL*Loader, SQL*Net, SQL*Plus, and SQL*ReportWriter are registered trademarks of Oracle Corporation.

Oracle7, Oracle Parallel Server, PL/SQL, and Pro*C are trademarks of Oracle Corporation.

VMS is a registered trademark of Digital Equipment Corporation.


Preface


PREFACE

This Manual describes all features of the ORACLE7 Server, a relational database management system (RDBMS). This Manual is provided so that the reader can understand how ORACLE functions.

Information in this Manual applies to the ORACLE7 Server, running on all operating systems. It provides information about the base ORACLE Server product and the special options, including:

•	procedural option

•	distributed option

•	Parallel Server option

Any chapter of this Manual that applies only to a particular option is clearly indicated on the first page of the chapter.

________________________________________

Audience

This Manual is written for database administrators, system administrators, and database application developers.

Knowledge Assumed of the Reader

Readers of this Manual are assumed to be familiar with relational database concepts. They are also assumed to be familiar with the operating system environment under which they are running ORACLE.

As a prerequisite, all readers should read the first chapter, "A Technical Introduction to the ORACLE Server." Chapter 1 is a comprehensive introduction to the concepts and terminology used throughout the remainder of this Manual.

Readers Interested in Installation and Migration Information

This Manual is not an installation or migration guide; therefore, if your primary interest is installation, refer to the installation or user's guide for your particular operating system, and if your primary interest is database and application migration, refer to the ORACLE7 Server Migration Guide.

Readers Interested in Database Administration Information

While this Manual describes the architecture, processes, structures, and other concepts of the ORACLE Server, it does not explain how to administer the ORACLE Server. For that information, see the ORACLE7 Server Administrator's Guide.

Readers Interested in Application Design Information

In addition to administrators, experienced users of ORACLE and advanced database application designers will find information in this Guide useful. However, database application developers should also refer to the ORACLE7 Server Application Developer's Guide, and the documentation for the tool or language product they are using to develop ORACLE database applications.

________________________________________

How This Manual Is Organized

This Manual is divided into many chapters, as described below.

Part I What is ORACLE?

Chapter 1:  A Technical Introduction to the ORACLE Server This chapter provides the "big picture" including the concepts and terminology of the ORACLE Server. It is required that you read this overview before using the detailed information in the remainder of this Manual.

Part II Basic Database Operation

Chapter 2:  Database and Instance Startup and Shutdown This chapter describes how the database administrator (DBA) can control the accessibility of an ORACLE database system. This chapter also describes the parameters that control how the database operates.

Part III Database Structures

Chapter 3:  Data Blocks, Extents, and Segments This chapter discusses how data is stored and how storage space is allocated for and consumed by various objects within an ORACLE database. The material in this chapter is important space management background information that supplements information in the following two chapters.

Chapter 4:  Tablespaces and Data Files

 This chapter discusses how physical storage space in an ORACLE database is divided into logical divisions called tablespaces. The physical operating system files associated with tablespaces, called data files, are also discussed.

Chapter 5:  Schema Objects

 This chapter describes the objects that can be created in the domain of a specific user (a schema), including tables, views, numeric sequences, and synonyms. Also described are indexes and clusters, which are optional structures that can enhance the performance of data retrieval from database tables.

Chapter 6:  Datatypes

 This chapter describes the types of data that can be stored in an ORACLE database table, such as fixed- and variable-length character strings, numeric data, dates, and binary large objects (BLOBs). This chapter describes how data of different types is physically stored, datatype size limits, datatype conversion, and how datatypes of other systems are mapped to ORACLE datatypes.

Chapter 7:  Data Integrity

 This chapter discusses data integrity concepts and the declarative integrity constraints that can provide data integrity within an ORACLE database.

Chapter 8:  The Data Dictionary

 This chapter describes the data dictionary, which is a set of reference tables and views that contain read-only information about an ORACLE database.

Part IV System Architecture

Chapter 9:  Memory Structures and Processes This chapter describes the memory structures and processes that make up an ORACLE database system. This chapter also describes the different process configurations available for ORACLE.

Chapter 10:  Data Concurrency

 This chapter explains how ORACLE provides concurrent access to and maintains the accuracy of shared information in a multi-user database environment. It describes the automatic mechanisms that ORACLE uses to guarantee that the concurrent operations of multiple users do not interfere with each other.

Part V Data Access

Chapter 11:  SQL and PL/SQL This chapter briefly describes SQL, the language used to communicate with ORACLE, as well as PL/SQL, Oracle's procedural language extension to SQL.

Chapter 12:  Transaction Management

 This chapter defines the concept of transactions or logical units of work and the SQL statements used to control transactions.

Chapter 13:  The Optimizer

 This chapter describes the optimizer, the part of ORACLE that chooses the most efficient way to execute each SQL statement, and explains how the optimizer works.

Part VI Programmatic Constructs

Chapter 14:  Procedures and Packages This chapter discusses the procedural language constructs called  procedures, functions, and packages, which are PL/SQL program units that are stored in the database.

Chapter 15:  Database Triggers

 This chapter describes the procedural language constructs called triggers, procedures that are implicitly executed when anyone inserts rows into, updates, or deletes row from a database table.

Chapter 16:  Dependencies Among Schema Objects

 This chapter explains how ORACLE manages the dependencies for objects such as procedures, packages, triggers, and views.

Part VII Database Security

Chapter 17:  Database Access This chapter describes how the access to the database is controlled. Database users and limitation of system resources are discussed.

Chapter 18:  Privileges and Roles

 This chapter discusses system and object security.

Chapter 19:  Auditing

 This chapter discusses how ORACLE's auditing feature tracks database activity.

Part VIII Distributed Processing and Distributed Databases

Chapter 20: Client-Server Architecture This chapter discusses distributed processing environments and the ORACLE Server.

Chapter 21:  Distributed Databases

 This chapter discusses the ORACLE Server's distributed architecture,  remote data access, and table replication.

Chapter 22:  Two-Phase Commit

 This chapter explains how ORACLE protects transactions that distribute work among multiple sites in a distributed database. This chapter also discusses possible failures that can interrupt the commit of a distributed transaction and how the ORACLE Server can overcome such failures.

Part IX Database Backup and Recovery

Chapter 23:  Recovery Structures This chapter describes the files and structures used for database recovery: the redo log files and the control files. Media and software failure are distinguished.

Chapter 24:  Database Backup

 This chapter discusses how to protect an ORACLE database from possible failures.

Chapter 25:  Database Recovery

 This chapter explains how to recover a database from failures.

Reference

Appendix A:  National Language Support This appendix explains how ORACLE can handle data and interface with users using various languages.

Appendix B:  Operating System Specific Information

 This appendix lists all of the operating system specific references within this Manual.

________________________________________

How to Use This Manual

Every reader of this Manual must read Chapter 1, "A Technical Introduction to the ORACLE Server."  This brief overview of the concepts and terminology related to ORACLE provides a foundation for the more detailed information that follows in later chapters.

Each part of this Manual addresses a specific audience within the general audiences previously described. For example, after reading Chapter 1, administrators interested primarily in managing security should focus on the information presented in Part VII, "Database Security."

________________________________________

Conventions Used in This Manual

The following sections explain the conventions used in this Manual.

Text of the Manual

The following textual conventions are used:

UPPERCASE  WORDS	Uppercase text is used to call attention to command keywords, object names, parameters, filenames, etc. For example:

"If you create a private rollback segment, the name of the rollback segment must be included in the ROLLBACK_SEGMENTS parameter of the parameter file."

Italicized Words	Italicized words within text indicate the definition of a term. For example:

"A database is a collection of data to be treated as a unit. The general purpose of a database is to store and retrieve related information, as needed."

Italics also call out specific book titles.

Bold Words	Bolding within text calls special attention to important information. For example:

"In summary, remember that this procedure provides a reasonable estimate of a table's size, not an exact number of blocks or bytes."

Examples of Commands and Statements

SQL, SQL*DBA, and SQL*Plus commands/statements appear separated from the text of paragraphs in a mono-spaced font. For example:

INSERT INTO emp (empno, ename) VALUES (1000, 'SMITH');

ALTER TABLESPACE users ADD DATAFILE 'users2.ora' SIZE 50K;

Punctuation   , ' "	Example statements may include punctuation such as commas or quotation marks. All punctuation given in example statements are required. All example statements are terminated with a semi-colon. Note that depending on the application being used, a semi-colon or other terminator may or may not be required to end a statement.

Uppercase Words:  INSERT, SIZE	Uppercase words in example statements are used to indicate the keywords within ORACLE SQL. However, note that when issuing statements, keywords are not case-sensitive.

Lowercase Words: emp, users2.ora	Lowercase words in example statements are used to indicate words supplied only for the context of the example. For example, lowercase words may indicate the name of a table, column, or file.

Special Icons

Two special icons are provided to alert you to particular information within the body of this Manual:

•	The lightbulb highlights suggestions and practical tips that could save time, make procedures easier, and so on.

•	The warning symbol highlights text that warns you of actions that could be particularly damaging or fatal to your operations.

________________________________________

Related Publications

The ORACLE7 Server Concepts Manual is one of many books used to explain various parts of an ORACLE database system.

In many sections of this Manual, you will also find many references in this book to important information in the related publications. To clearly indicate an area in this Manual that may be supported by information in a related book, a corresponding icon is placed in the margin of the page, adjacent to the text referring to the supporting book. The related books (and corresponding icons) referred to in this Manual are included below.

•	For information about administering the ORACLE7 Server, see the ORACLE7 Server Administrator's Guide.

•	For information about developing database applications within the ORACLE7 Server, see the ORACLE7 Server Application Developer's Manual.

•	For the procedures for migrating a previous version of ORACLE to ORACLE7, see the ORACLE7 Server Migration Guide.

•	For information specific to the ORACLE7 Server working on your host operating system, see your installation or user's guide (specific book titles vary by operating system), and system release bulletins, if available.

•	For reference information on ORACLE's SQL commands and functions, see the ORACLE7 Server SQL Language Reference Manual.

•	For information about ORACLE's procedural language extension to SQL, PL/SQL, refer to the PL/SQL User's Guide and Reference.

•	For information about programming applications that use the ORACLE Call Interfaces, see the ORACLE Call Interfaces Programmer's Guide.

•	For information about the utilities bundled with the ORACLE Server, including SQL*DBA, Export, Import, and SQL*Loader, refer to the ORACLE7 Server Utilities User's Guide.

•	For information specific to administering the ORACLE Parallel Server, refer to the ORACLE7 Parallel Server Administrator's Guide.

•	For information specific to administering ORACLE's multilevel secure database management system product, Trusted ORACLE, refer to the Trusted ORACLE7 Server Administrator's Guide.

•	For more information about ORACLE messages and codes, refer to the ORACLE7 Server Messages and Codes Manual.

•	For information about SQL*Net see the SQL*Net documentation, which includes the SQL*Net V2 Administrator's Guide; the MultiProtocol Interchange Administrator's Guide; and the Oracle Network Products Messages Manual.

Oracle Corporation also publishes a file commonly named README.DOC. This file is available on your distribution media and describes differences between minor releases of Oracle software that are not accompanied by new manuals. The exact name and location of this file might vary, depending on your operating system. Read this file to learn about changes to the software that are not described in the regular manuals.

________________________________________

Your Comments Are Welcome

We value and appreciate your comments as an ORACLE user and reader of the manuals. As we write, revise, and evaluate our documentation, your opinions are the most important input we receive. At the back of this Manual is a Reader's Comment Form which we encourage you to use to tell us what you like and dislike about this Manual or other ORACLE manuals. If the form has been used or you would like to contact us, please use the following address or FAX number, or call us at (415) 506-7000.

ORACLE7 Server Documentation Manager

 	Oracle Corporation

 	500 Oracle Parkway

 	Redwood Shores, CA  94065

FAX: (415) 506-7200


PART  I . WHAT IS ORACLE?


CHAPTER 1. A TECHNICAL INTRODUCTION TO THE ORACLE SERVER

I am Sir Oracle,

 	And when I ope my lips, let no dog bark!

Shakespeare: The Merchant of Venice

This chapter is an overview of the ORACLE relational database management system. It presents information that will help you use the remainder of this book. The topics in this chapter include:

•	the logical and physical structures of an ORACLE database and the system architecture of ORACLE

•	the ways that data can be accessed and modified in an ORACLE database and the mechanisms used to maintain concurrency in a multi-user ORACLE database system

•	the security features that protect system and data access

•	the backup and recovery options available to protect an ORACLE database from system and disk failures

•	the concepts of distributed processing and distributed databases and how ORACLE supports network environments

________________________________________

Databases and Information Management

Database management software is the key to solving the problems of information management. In general, a database management system (DBMS) must be able to reliably manage a large amount of data in a multi-user environment so that many users can concurrently access the same data. All this must be accomplished while delivering high performance to the users of the database. A DBMS must also be secure from unauthorized access and provide efficient solutions for failure recovery. The ORACLE Server provides efficient and effective solutions for the major database features:

large databases and space management control	ORACLE supports the largest of databases, potentially hundreds of gigabytes in size. To make efficient use of expensive hardware devices, it allows full control of space usage.

many concurrent database users	ORACLE supports large numbers of concurrent users executing a variety of database applications operating on the same data. It minimizes data contention and guarantees data concurrency.

high transaction processing performance	ORACLE maintains the preceding features with a high degree of overall system performance. Database users do not suffer from slow processing performance.

high availability	At some sites, ORACLE works 24 hours per day with no down time to limit database throughput. Normal system operations such as database backup and partial computer system failures do not interrupt database use.

controlled availability	ORACLE can selectively control the availability of data, at the database level and sub-database level. For example, an administrator can disallow use of a specific application so that the application's data can be reloaded, without affecting other applications.

industry accepted standards	ORACLE adheres to industry accepted standards for the data access language, operating systems, user interfaces, and network communication protocols. It is an "open" system that protects a customer's investment.

The ORACLE7 Server has been certified by the U.S. National Institute of Standards and Technology as 100% compliant with Level 2 of the ANSI/ISO SQL89 standard. ORACLE7 fully satisfies the requirements of the U.S. Government's FIPS127-1 standard and includes a "flagger" to highlight non-standard SQL usage.

Also, ORACLE7 has been evaluated by the U.S. Government's National Computer Security Center (NCSC) as compliant with the Orange Book security criteria; the ORACLE7 Server and Trusted ORACLE7 comply with the C2 and B1 Orange Book levels, respectively, as well as with comparable European ITSEC security criteria.

manageable security	To protect against unauthorized database access and use, ORACLE provides fail-safe security features to limit and monitor data access. These features make it easy to manage even the most complex design for data access.

database enforced integrity	ORACLE enforces data integrity, "business rules" that dictate the standards for acceptable data. As a result, the costs of coding and managing checks in many database applications are eliminated.

client/server (distributed processing) environments	To take full advantage of a given computer system or network, ORACLE allows processing to be split between the database server and the client application programs. All responsibilities of shared data management can be processed by the computer running the database management system while the workstations running the database application concentrate on the interpretation and display of data.

distributed database systems	For computing environments that are connected via networks, ORACLE combines the data physically located on different computers into one logical database that can be accessed by all network users. Distributed systems have the same degree of user transparency and data consistency as non-distributed systems, yet receive the advantages of local database management.

portability	ORACLE software is ported to work under different operating systems and is the same on all systems. Applications developed for ORACLE can be ported to any operating system with little or no modification.

compatibility	ORACLE software is compatible with industry standards, including most industry standard operating systems. Applications developed for ORACLE can be used on virtually any system with little or no modification.

connectability	ORACLE software allows different types of computers and operating systems to share information across networks.

The following sections provide a comprehensive overview of the ORACLE architecture. Each major section describes a different part of the overall architecture.

________________________________________

Database Structure and Space Management

This section describes the architecture of an ORACLE database, including the physical and logical structures that constitute a database. This discussion provides an understanding of ORACLE's solutions to controlled data availability, the separation of logical and physical data structures, and fine-grained control of disk space management.

Relational Database Management Systems

Database management systems have evolved from hierarchical to network to relational models. Today, the most widely accepted database model is the relational model. The relational model has three major aspects:

Structures	Structures are well-defined objects that store the data of a database. Structures and the data contained within them can be manipulated by operations.

Operations	Operations are clearly defined actions that allow users to manipulate the data and structures of a database. The operations on a database must adhere to a predefined set of integrity rules.

Integrity Rules	Integrity rules are the laws that govern which operations are allowed on the data and structures of a database. Integrity rules protect the data and the structures of a database.

Relational database management systems offer benefits such as:

•	independence of physical data storage and logical database structure

•	variable and easy access to all data

•	complete flexibility in database design

•	reduced data storage and redundancy

An ORACLE database is a collection of data that is treated as a unit. The general purpose of a database is to store and retrieve related information.

 Open and Closed Databases

An ORACLE database can be open (accessible) or closed (not accessible). In normal situations, the database is open and available for use. However, the database is sometimes closed for specific administrative functions that require the database's data to be unavailable to users.

 Database Structure

An ORACLE database has both a physical and a logical structure. By separating physical and logical database structure, the physical storage of data can be managed without affecting the access to logical storage structures.

Physical Database Structure      An ORACLE database's physical structure is determined by the operating system files that constitute the database. Each ORACLE database is comprised of three types of files: one or more data files, two or more redo log files, and one or more control files. The files of a database provide the actual physical storage for database information.

Logical Database Structure   An ORACLE database's logical structure is determined by:

•	one or more tablespaces

•	the database's schema objects (e.g., tables, views, indexes, clusters, sequences, stored procedures)

The logical storage structures, including tablespaces, segments, and extents, dictate how the physical space of a database is used. The schema objects and the relationships among them form the relational design of a database.

Logical Structures

The following sections explain logical structures, including tablespaces, schema objects, data blocks, extents, and segments.

 Tablespaces

A database is divided into logical storage units called tablespaces. A tablespace is used to group related logical structures together. For example, tablespaces commonly group all of an application's objects to simplify certain administrative operations.

Databases, Tablespaces, and Data Files      The relationship among databases, tablespaces, and data files (data files are described in the

next section) is illustrated in Figure 1 - 1.

This figure illustrates:

•	Each database is logically divided into one or more tablespaces.

•	One or more data files are explicitly created for each tablespace to physically store the data of all logical structures in a tablespace.

•	The combined size of a tablespace's data files is the total storage capacity of the tablespace (SYSTEM has 2 M storage capacity while DATA has 4 M).

•	The combined storage capacity of a database's tablespaces is the total storage capacity of the database (6 M).

Online and Offline Tablespaces      A tablespace can be online (accessible) or offline (not accessible). A tablespace is normally online so that users can access the information within the tablespace. However, sometimes a tablespace may be taken offline to make a portion of the database unavailable while allowing normal access to the remainder of the database. This makes many administrative tasks easier to perform.

 Schemas and Schema Objects

A schema is a collection of objects. Schema objects are the logical structures that directly refer to the database's data. Schema objects include such structures as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links. (There is no relationship between a tablespace and a schema; objects in the same schema can be in different tablespaces, and a tablespace can hold objects from different schemas.)

Tables      A table is the basic unit of data storage in an ORACLE database. The tables of a database hold all of the user-accessible data.

Table data is stored in rows and columns. Every table is defined with a table name and set of columns. Each column is given a column name, a datatype (such as CHAR, DATE, or NUMBER), and a width (which may be predetermined by the datatype, as in DATE) or scale and precision (for the NUMBER datatype only). Once a table is created, valid rows of data can be inserted into it. The table's rows can then be queried, deleted, or updated.

To enforce defined business rules on a table's data, integrity constraints and triggers can also be defined for a table. (For more information, see "Data Integrity" on page 1 - 27)

Views      A view is a custom-tailored presentation of the data in one or more tables. A view can also be thought of as a "stored query."

Views do not actually contain or store data; rather, they derive their data from the tables on which they are based, referred to as the base tables of the views. Base tables can in turn be tables or can themselves be views.

Like tables, views can be queried, updated, inserted into, and deleted from, with restrictions. All operations performed on a view actually affect the base tables of the view.

Views are often used to do the following:

•	Provide an additional level of table security by restricting access to a predetermined set of rows and columns of a table. For example, a view of a table can be created so that columns with sensitive data (for example, salary information) are not included in the definition of the view.

•	Hide data complexity. For example, a single view can be used to create a join, which is a display of related columns or rows in multiple tables. However, the view hides the fact that this data actually originates from several tables.

•	Simplify commands for the user. For example, views allow users to select information from multiple tables without requiring the users to actually know how to perform a correlated subquery.

•	Present the data in a different perspective from that of the base table. For example, views provide a means to rename columns without affecting the tables on which the view is based.

•	Store complex queries. For example, a query might perform extensive calculations with table information. By saving this query as a view, the calculations are performed only when the view is queried.

Sequences      A sequence generates a serial list of unique numbers for numeric columns of a database's tables. Sequences simplify application programming by automatically generating unique numerical values for the rows of a single table or multiple tables.

For example, assume two users are simultaneously inserting new employee rows into the EMP table. By using a sequence to generate unique employee numbers for the EMPNO column, neither user has to wait for the other to input the next available employee number. The sequence automatically generates the correct values for each user.

Sequence numbers are independent of tables, so the same sequence can be used for one or more tables. After creation, a sequence can be accessed by various users to generate actual sequence numbers.

Program Units   The term "program unit" is used in this Manual to refer to stored procedures, functions, and packages.

Note: The information in this section applies only to ORACLE with the procedural option.

A procedure or function is a set of SQL and PL/SQL statements grouped together as an executable unit to perform a specific task. (See "Data Access" on page 1 - 22 for more information about SQL and PL/SQL.) Procedures and functions allow you to combine the ease and flexibility of SQL with the procedural functionality of a structured programming language. Using PL/SQL, such procedures and functions can be defined and stored in the database for continued use. Procedures and functions are identical, except that functions always return a single value to the caller, while procedures do not return a value to the caller.

Packages provide a method of encapsulating and storing related procedures, functions, and other package constructs together as a unit in the database. While packages provide the database administrator or application developer organizational benefits, they also offer increased functionality and database performance.

Synonyms      A synonym is an alias for a table, view, sequence, or program unit. A synonym is not actually an object itself, but instead is a direct reference to an object. Synonyms are used to:

•	mask the real name and owner of an object

•	provide public access to an object

•	provide location transparency for tables, views, or program units of a remote database

•	simplify the SQL statements for database users

A synonym can be public or private. An individual user can create a private synonym, which is available only to that user. Database administrators most often create public synonyms that make the base schema object available for general, systemwide use by any database user.

Indexes,     Clusters, and Hash Clusters   Indexes, clusters, and hash clusters are optional structures associated with tables, which can be created to increase the performance of data retrieval.

Indexes are created to increase the performance of data retrieval. Just as the index in this Manual helps you locate specific information faster than if there were no index, an ORACLE index provides a faster access path to table data. When processing a request, ORACLE can use some or all of the available indexes to efficiently locate the requested rows. Indexes are useful when applications often query a table for a range of rows (for example, all employees with a salary greater than 1000 dollars) or a specific row.

Indexes are created on one or more columns of a table. Once created, an index is automatically maintained and used by ORACLE. Changes to table data (such as adding new rows, updating rows, or deleting rows) are automatically incorporated into all relevant indexes with complete transparency to the users.

Indexes are logically and physically independent of the data. They can be dropped and created any time with no effect on the tables or other indexes. If an index is dropped, all applications continue to function; however, access to previously indexed data may be slower.

Clusters are an optional method of storing table data. Clusters are groups of one or more tables physically stored together because they share common columns and are often used together. Because related rows are physically stored together, disk access time improves.

The related columns of the tables in a cluster is called the cluster key. The cluster key is indexed so that rows of the cluster can be retrieved with a minimum amount of I/O. Because the data in a cluster key of an index cluster (a non-hash cluster) is stored only once for multiple tables, clusters may store a set of tables more efficiently than if the tables were stored individually (not clustered). Figure 1 - 2 illustrates how clustered and non-clustered data is physically stored.

Clusters also can improve performance of data retrieval, depending on data distribution and what SQL operations are most often performed on the clustered data. In particular, clustered tables that are queried in joins benefit from the use of clusters because the rows common to the joined tables are retrieved with the same I/O operation.

Like indexes, clusters do not affect application design. Whether or not a table is part of a cluster is transparent to users and to applications. Data stored in a clustered table is accessed via SQL in the same way as data stored in a non-clustered table.

Hash clusters also cluster table data in a manner similar to normal, index clusters (clusters keyed with an index rather than a hash function). However, a row is stored in a hash cluster based on the result of applying a hash function to the row's cluster key value. All rows with the same hash key value are stored together on disk.

Hash clusters are a better choice than using an indexed table or index cluster when a table is often queried with equality queries (e.g., return all rows for department 10). For such queries, the specified cluster key value is hashed. The resulting hash key value points directly to the area on disk that stores the specified rows.

Database Links      A database link is a named object that describes a "path" from one database to another. Database links are implicitly used when a reference is made to a global object name in a distributed database. (Also see "Distributed Databases" on page 1 - 44.)

 Data Blocks, Extents, and Segments

ORACLE allows fine-grained control of disk space usage through the logical storage structures, including data blocks, extents, and segments.

ORACLE Data Blocks      At the finest level of granularity, an ORACLE database's data is stored in data blocks. One data block corresponds to a specific number of bytes of physical database space on disk. A data block size is specified for each ORACLE database when the database is created. A database uses and allocates free database space in ORACLE data blocks.

Extents      The next level of logical database space is called an extent. An extent is a specific number of contiguous data blocks, obtained in a single allocation, used to store a specific type of information.

Segments      The level of logical database storage above an extent is called a segment. A segment is a set of extents allocated for a certain logical structure. For example, the different types of segments include:

Data Segment	Each non-clustered table has a data segment. All of the table's data is stored in the extents of its data segment. Each cluster has a data segment. The data of every table in the cluster is stored in the cluster's data segment.

Index Segment	Each index has an index segment that stores all of its data.

Rollback Segment	One or more rollback segments are created by the database administrator for a database to temporarily store "undo" information. This information is used:

•	to generate read-consistent database information (See "Read-Consistency" on page 1 - 30.)

•	during database recovery (See "Database Backup and Recovery" on page 1 - 38.)

•	to rollback uncommitted transactions for users

Temporary Segment	Temporary segments are created by ORACLE when a SQL statement needs a temporary work area to complete execution. When the statement finishes execution, the temporary segment's extents are returned to the system for future use.

ORACLE allocates space for all types of segments in extents. Therefore, when the existing extents of a segment are full, ORACLE allocates another extent for that segment as needed. Because extents are allocated as needed, the extents of a segment may or may not be contiguous on disk.

Physical Structures

The following sections explain the physical structures of an ORACLE database, including data files, redo log files, and control files.

 Data Files

Every ORACLE database has one or more physical data files. A database's data files contain all the database data. The data of logical database structures such as tables and indexes is physically stored in the data files allocated for a database.

The following are characteristics of data files:

•	A data file can be associated with only one database.

•	Once created, a data file cannot change in size.

•	One or more data files form a logical unit of database storage called a tablespace, as discussed earlier in this chapter.

The Use of Data Files      The data in a data file is read, as needed, during normal database operation and stored in the memory cache of ORACLE. For example, assume that a user wants to access some data in a table of a database. If the requested information is not already in the memory cache for the database, it is read from the appropriate data files and stored in memory.

Modified or new data is not necessarily written to a data file immediately. To reduce the amount of disk output and increase performance, data is pooled in memory and written to the appropriate data files all at once, as determined by the DBWR background process of ORACLE. (For more information about ORACLE's memory and process structures and the algorithm for writing database data to the data files, see "ORACLE System Architecture" on page 1 - 15)

Redo Log Files

Every ORACLE database has a set of two or more redo log files. The set of redo log files for a database is collectively known as the database's redo log. The primary function of the redo log is to record all changes made to data. All changes made to the database are recorded in the redo log. Should a failure prevent modified data from being permanently written to the data files, the changes can be obtained from the redo log and work is never lost.

Redo log files are critical in protecting a database against failures. To protect against a failure involving the redo log itself, ORACLE allows a mirrored redo log so that two or more copies of the redo log can be maintained on different disks.

The Use of Redo Log Files      The information in a redo log file is used only to recover the database from a system or media failure that prevents database data from being written to a database's data files.

For example, if an unexpected power outage abruptly terminates database operation, data in memory cannot be written to the data files. However, any lost data is recovered when the database is subsequently opened after power is restored. ORACLE automatically applies the information in the most recent redo log files to the database's data files to restore the database to the instant at which that the power failure occurred.

The process of applying the redo log during a recovery operation is called rolling forward. (See "Database Backup and Recovery" on page 1 - 38.)

 Control Files

Every ORACLE database has a control file. A control file records the physical structure of the database. For example, it contains the following types of information:

•	database name

•	names and locations of a database's data files and redo

 log files

•	time stamp of database creation

Like the redo log, ORACLE allows the control file to be mirrored for protection of the control file.

The Use of Control Files      Every time an instance of an ORACLE database is started, its control file is used to identify the database and redo log files that must be opened for database operation to proceed. If the physical makeup of the database is altered (for example, a new data file or redo log file is created), the database's control file is automatically modified by ORACLE to reflect the change.

A database's control file is also used if database recovery is necessary. (See "Database Backup and Recovery" on page 1 - 38)

The Data Dictionary

Each ORACLE database has a data dictionary. The data dictionary of an ORACLE database is a set of tables and views that are used as a read-only reference about the database. For example, a data dictionary stores information about both the logical and physical structure of the database. In addition to this valuable information, a data dictionary also stores such information as:

•	the valid users of an ORACLE database

•	information about integrity constraints defined for tables in the database

•	how much space is allocated for a schema object and how much of it is being used

A data dictionary is created when a database is created. To accurately reflect the status of the database at all times, the data dictionary is automatically updated by ORACLE in response to specific actions (such as when the structure of the database is altered). The data dictionary is critical to the operation of the database, which relies on the data dictionary to record, verify, and conduct ongoing work. For example, during database operation, ORACLE reads the data dictionary to verify that schema objects exist and that users have proper access to them.

________________________________________

ORACLE System Architecture

The following section discusses the memory and process structures used by ORACLE to manage a database. Among other things, the architectural features discussed in this section provide an understanding of ORACLE's capabilities to support:

•	many users concurrently accessing a single database

•	the high performance required by concurrent multi-user, multi-application database systems

Memory Structures and Processes

The mechanisms of ORACLE execute by using memory structures and processes. All memory structures exist in the main memory of the computers (sometimes called virtual memory or random access memory) that constitute the database system. Processes are jobs or tasks that work in the memory of these computers.

Figure 1 - 3 shows a typical variation of ORACLE's memory and process structures; the memory structures and processes in this diagram are discussed in the next section.

Memory Structures

ORACLE creates and uses memory structures to complete several jobs. For example, memory is used to store program code being executed and data that is shared among users. Several basic memory structures are associated with ORACLE: the system global area (which includes the database and redo log buffers, and the shared pool) and the program global areas. The following sections explain each in detail.

System Global Area (SGA)

The System Global Area (SGA) is a shared memory region allocated by ORACLE that contains data and control information for one ORACLE instance. An SGA and the ORACLE background processes constitute an ORACLE instance. (See page 1 - 19 for information about the ORACLE background processes and page 1 - 21 for information about ORACLE instances.)

The SGA is allocated when an instance starts and deallocated when the instance shuts down. Each instance that is started has its own SGA.

The data in the SGA is shared among the users currently connected to the database. For optimal performance, the entire SGA should be as large as possible (while still fitting in real memory) to store as much data in memory as possible and minimize disk I/O. The information stored within the SGA is divided into several types of memory structures, including the database buffers, redo log buffer, and the shared pool. These areas have fixed sizes and are created during instance startup.

Database Buffer Cache      Database buffers of the SGA store the most recently used blocks of database data; the set of database buffers in an instance is the database buffer cache. These buffers can contain modified data that has not yet been permanently written to disk. Because the most recently (and often the most frequently) used data is kept in memory, less disk I/O is necessary and performance is increased.

Redo Log Buffer      The redo log buffer of the SGA stores redo entries-a log of changes made to the database. The redo entries stored in the redo log buffers are written to an online redo log file, which is used if database recovery is necessary. Its size is static.

Shared Pool      The shared pool is a portion of the SGA that contains shared memory constructs such as shared SQL areas. A shared SQL area is required to process every unique SQL statement submitted to a database. (See "SQL Statements" on page 1 - 23) A shared SQL area contains information such as the parse tree and execution plan for the corresponding statement. A single shared SQL area is used by multiple applications that issue the same statement, leaving more shared memory for other uses.

Cursors      A cursor is a handle (a name or pointer) for the memory associated with a specific statement. Although most ORACLE users rely on the automatic cursor handling of the ORACLE utilities, the programmatic interfaces offer application designers more control over cursors. For example, in precompiler application development, a cursor is a named resource available to a program and can be specifically used for the parsing of SQL statements embedded within the application. The application developer can code an application so that it controls the phases of SQL statement execution and thus improve application performance.

 Program Global Area (PGA)

The Program Global Area (PGA) is a memory buffer that contains data and control information for a server process. A PGA is created by ORACLE when a server process is started. The information in a PGA depends on the configuration of ORACLE.

Processes

A process is a "thread of control" or a mechanism in an operating system that can execute a series of steps. Some operating systems use the terms job or task. A process normally has its own private memory area in which it runs.

An ORACLE database system has two general types of processes: user processes and ORACLE processes.

 User (Client) Processes

A user process is created and maintained to execute the software code of an application program (such as a Pro*C program) or an ORACLE tool (such as SQL*DBA). The user process also manages the communication with the server processes. User processes communicate with the server processes through the program interface, described later in this section.

 ORACLE Processes

ORACLE processes are called by other processes to perform functions on behalf of the invoking process. The different types of ORACLE processes and their specific functions are discussed in the following sections.

Server     Processes   ORACLE creates server processes to handle requests from connected user processes. A server process is in charge of communicating with the user process and interacting with ORACLE to carry out requests of the associated user process. For example, if a user queries some data that is not already in the database buffers of the SGA, the associated server process reads the proper data blocks from the data files into the SGA.

ORACLE can be configured to vary the number of user processes per server process. In a dedicated server configuration, a server process handles requests for a single user process. A multi-threaded server configuration allows many user processes to share a small number of server processes, minimizing the number of server processes and maximizing the utilization of available system resources.

On some systems, the user and server processes are separate, while on others they are combined into a single process. If a system uses the multi-threaded server or, if the user and server processes run on different machines, the user and server processes must be separate.

Background Processes   ORACLE creates a set of background processes for each instance. They consolidate functions that would otherwise be handled by multiple ORACLE programs running for each user process. The background processes asynchronously perform I/O and monitor other ORACLE processes to provide increased parallelism for better performance and reliability.

An SGA and the ORACLE background processes constitute an ORACLE instance. (See page 1 - 17 for information about the SGA and page 1 - 21 for information about ORACLE instances.)

Each ORACLE instance may use several background processes. The names of these processes are DBWR, LGWR, CKPT, SMON, PMON, ARCH, RECO, Dnnn and LCKn. Each background process is described in the following sections.

Database Writer (DBWR)       The Database Writer writes modified blocks from the database buffer cache to the data files. Because of the way ORACLE performs logging, DBWR does not need to write blocks when a transaction commits (see "Transactions" on page 1 - 24.) Instead, DBWR is optimized to minimize disk writes. In general, DBWR writes only when more data needs to be read into the SGA and too few are database buffers free. The least recently used data is written to the data files first.

Log Writer (LGWR)       The Log Writer writes redo log entries to disk. Redo log data is generated in the redo log buffer of the SGA. As transactions commit and the log buffer fills, LGWR writes redo log entries into an online redo log file.

Checkpoint (CKPT)      At specific times, all modified database buffers in the SGA are written to the data files by DBWR; this event is called a checkpoint. The Checkpoint process is responsible for signalling DBWR at checkpoints and updating all the data files and control files of the database to indicate the most recent checkpoint. CKPT is optional; if CKPT is not present, LGWR assumes the responsibilities of CKPT.

System Monitor (SMON)      The system monitor performs instance recovery at instance startup. In a multiple instance system (one that uses the Parallel Server), SMON of one instance can also perform instance recovery for other instances that have failed. SMON also cleans up temporary segments that are no longer in use and recovers dead transactions skipped during crash and instance recovery because of file-read or offline errors. These transactions are eventually recovered by SMON when the tablespace or file is brought back online. SMON also coalesces free extents within the database, to make free space contiguous and easier to allocate.

Process Monitor (PMON)      The process monitor performs process recovery when a user process fails. PMON is responsible for cleaning up the cache and freeing resources that the process was using. PMON also checks on dispatcher (see below) and server processes and restarts them if they have failed.

Archiver (ARCH)       The archiver copies the online redo log files to archival storage when they are full. ARCH is active only when a database's redo log is used in ARCHIVELOG mode. (See "The Redo Log" on page 1 - 41)

Recoverer (RECO)      The recoverer is used to resolve distributed transactions that are pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to remote databases and automatically complete the commit or rollback of the local portion of any pending distributed transactions.

Dispatcher (Dnnn)      Dispatchers are optional background processes, present only when a multi-threaded server configuration is used. At least one dispatcher process is created for every communication protocol in use (D000, . . ., Dnnn). Each dispatcher process is responsible for routing requests from connected user processes to available shared server processes and returning the responses back to the appropriate user processes.

Lock (LCKn)   Up to ten lock processes (LCK0, . . ., LCK9) are used for inter-instance locking when the ORACLE Parallel Server is used; see "The ORACLE Parallel Server: Multiple Instance Systems" on page 1 - 21 for more information about this configuration.

The Program Interface

The program interface is the mechanism by which a user process communicates with a server process. It serves as a method of standard communication between any client tool or application (such as SQL*Forms) and ORACLE software. Its functions are to:

•	act as a communications mechanism, by formatting data requests, passing data, and trapping and returning errors

•	perform conversions and translations of data, particularly between different types of computers or to external user program datatypes

 Communications Software and SQL*Net

If the user and server processes are on different computers of a network or if the user processes connect to shared server processes through dispatcher processes, the program interface includes the physical network connection, the communications software, and SQL*Net. SQL*Net is ORACLE's interface to standard communications protocols that allows for the proper transmission of data between computers. (See "SQL*Net" on page 1 - 47.)

An ORACLE Instance

Every time a database is started, an SGA is allocated and ORACLE background processes are started. The combination of these processes and memory buffers is called an ORACLE instance. Figure 1 - 4 illustrates a multiple process ORACLE instance.

The ORACLE Parallel Server: Multiple Instance Systems

Some hardware architectures (for example, loosely coupled processors) allow multiple computers to share access to data, software, or peripheral devices. ORACLE with the Parallel Server option can take advantage of such architecture by running multiple instances that "share" a single physical database. In appropriate applications, the ORACLE Parallel Server allows access to a single database by the users on multiple machines with increased performance.

An Example of How ORACLE Works

The following illustrates an ORACLE configuration where the user and associated server process are on separate machines (connected via a network).

1..	An instance is currently running on the computer that is executing ORACLE (often called the host or database server).

2..	A computer used to run an application (a local machine or client workstation) runs the application in a user process. The client application attempts to establish a connection to the server using the proper SQL*Net driver.

3..	The server is running the proper SQL*Net driver. The server detects the connection request from the application and creates a (dedicated) server process on behalf of the user process.

4..	The user executes a SQL statement and commits the transaction. For example, the user changes a name in a row of a table.

5..	The server process receives the statement and checks the shared pool for any shared SQL area that contains an identical SQL statement. If a shared SQL area is found, the server process checks the user's access privileges to the requested data and the previously existing shared SQL area is used to process the statement; if not, a new shared SQL area is allocated for the statement so that it can be parsed and processed.

6..	The server process retrieves any necessary data values from the actual data file (table) or those stored in the SGA.

7..	The server process modifies data in the SGA. The DBWR process writes modified blocks permanently to disk when doing so is efficient. Because the transaction committed, the LGWR process immediately records the transaction in the online redo log file.

8..	If the transaction is successful, the server process sends a message across the network to the application. If it is not successful, an appropriate error message is transmitted.

9..	Throughout this entire procedure, the other background processes run, watching for conditions that require intervention. In addition, the database server manages other users' transactions and prevents contention between transactions that request the same data.

These steps describe only the most basic level of operations that ORACLE performs.

________________________________________

Data Access

This section introduces how ORACLE meets the general requirements for a DBMS to do the following:

•	adhere to industry accepted standards for a data access language

•	control and preserve the consistency of a database's information while manipulating its data

•	provide a system for defining and enforcing rules to maintain the integrity of a database's information

•	provide high performance

SQL'The Structured Query Language

SQL is a simple, powerful database access language which is the standard language for relational database management systems. The SQL implemented by Oracle Corporation for ORACLE is 100% compliant with the ANSI/ISO standard SQL data language.

SQL Statements

All operations on the information in an ORACLE database are performed using SQL statements. A SQL statement is a string of SQL text that is given to ORACLE to execute. A statement must be the equivalent of a complete SQL sentence, as in:

SELECT ename, deptno FROM emp

Only a complete SQL statement can be executed, whereas a sentence fragment, such as the following, generates an error indicating that more text is required before a SQL statement can execute:

SELECT ename

A SQL statement can be thought of as a very simple, but powerful, computer program or instruction.

SQL statements are divided into five categories: DDL statements, DML statements, transaction control statements, session control statements, and embedded SQL statements.

Data Definition Statements (DDL)   DDL statements define and maintain objects, and drop objects when they are no longer needed. DDL statements also include statements that permit a user to grant other users the privileges or rights to access the database and specific objects within the database. (See "Database Security" on page 1 - 32.)

Data Manipulation Statements (DML)   DML statements manipulate the database's data. For example, querying, inserting, updating, and deleting rows of a table are all DML operations; locking a table or view and examining the execution plan of an SQL statement are also DML operations.

Transaction Control Statements      Transaction control statements manage the changes made by DML statements. They allow the user or application developer to group changes into logical transactions. (See "Transactions" on page  1 - 24) Examples include COMMIT, ROLLBACK, and SAVEPOINT.

Session Control Statements      Session control statements allow a user to control the properties of his current session, including enabling and disabling roles and changing language settings. The two session control statements are ALTER SESSION and SET ROLE.

System Control Statements      System control commands change the properties of the ORACLE Server instance. The only system control command is ALTER SYSTEM; it allows you to change such settings as the minimum number of shared servers, to kill a session, and to perform other tasks.

Embedded SQL Statements      Embedded SQL statements incorporate DDL, DML, and transaction control statements in a procedural language program (such as those used with the Oracle Precompilers). Examples include OPEN, CLOSE, FETCH, and EXECUTE.

Transactions

A transaction is a logical unit of work that comprises one or more SQL statements executed by a single user. According to the ANSI/ISO SQL standard, with which ORACLE is compatible, a transaction begins with the user's first executable SQL statement. A transaction ends when it is explicitly committed or rolled back (both terms are discussed later in this section) by that user.

Consider a banking database. When a bank customer transfers money from a savings account to a checking account, the transaction might consist of three separate operations: decrement the savings account, increment the checking account, and record the transaction in the transaction journal.

ORACLE must guarantee that all three SQL statements are performed to maintain the accounts in proper balance. In the event that something prevents one of the statements in the transaction from executing (such as a hardware failure), the other statements of the transaction must be undone; this is called "rolling back." If an error occurs in making either of the updates, then neither update is made.

Figure 1 - 5 illustrates the banking transaction example.

 Committing and Rolling Back Transactions

The changes made by the SQL statements that constitute a transaction can be either committed or rolled back. After a transaction is committed or rolled back, the next transaction begins with the next SQL statement.

Committing a transaction makes permanent the changes resulting from all SQL statements in the transaction. The changes made by the SQL statements of a transaction become visible to other user sessions' transactions that start only after the transaction is committed.

Rolling back a transaction retracts any of the changes resulting from the SQL statements in the transaction. After a transaction is rolled back, the affected data is left unchanged as if the SQL statements in the transaction were never executed.

 Savepoints

For long transactions that contain many SQL statements, intermediate markers or savepoints can be declared. Savepoints can be used to divide a transaction into smaller parts.

By using savepoints, you can arbitrarily mark your work at any point within a long transaction. This allows you the option of later rolling back all work performed from the current point in the transaction to a declared savepoint within the transaction. For example, you can use savepoints throughout a long complex series of updates, so that if you make an error, you do not need to resubmit every statement.

Data Consistency Using Transactions

Transactions provide the database user or application developer with the capability of guaranteeing consistent changes to data, as long as the SQL statements within a transaction are grouped logically. A transaction should consist of all of the necessary parts for one logical unit of work-no more and no less. Data in all referenced tables are in a consistent state before the transaction begins and after it ends. Transactions should consist of only the SQL statements that comprise one consistent change to the data.

For example, recall the banking example. A transfer of funds between two accounts (the transaction) should include the debit to one account (one SQL statement), the credit to another account (one SQL statement), and the record in the transaction journal (one SQL statement). All actions should either fail or succeed together; the credit should not be committed without the debit. Other non-related actions, such as a new deposit to one account, should not be included in the transfer of funds transaction; such statements should be in other transactions.

PL/SQL

Note: The information in this section applies only to ORACLE with the procedural option.

PL/SQL is Oracle's procedural language extension to SQL. PL/SQL combines the ease and flexibility of SQL with the procedural functionality of a structured programming language, such as IF ... THEN, WHILE, and LOOP.

When designing a database application, a developer should consider the advantages of using stored PL/SQL:

•	Because PL/SQL code can be stored centrally in a database, network traffic between applications and the database is reduced, so application and system performance increases.

•	Data access can be controlled by stored PL/SQL code. In this case, users of PL/SQL can access data only as intended by the application developer (unless another access route is granted).

•	PL/SQL blocks can be sent by an application to a database, executing complex operations without excessive network traffic.

Even when PL/SQL is not stored in the database, applications can send blocks of PL/SQL to the database rather than individual SQL statements, thereby again reducing network traffic.

The following sections describe the different program units that can be defined and stored centrally in a database.

 Procedures and Functions

Procedures and functions consist of a set of SQL and PL/SQL statements that are grouped together as a unit to solve a specific problem or perform a set of related tasks. A procedure is created and stored in compiled form in the database, and can be executed by a user or a database application. Procedures and functions are identical except that functions always return a single value to the caller, while procedures do not return values to the caller.

 Packages

Packages provide a method of encapsulating and storing related procedures, functions, variables, and other package constructs together as a unit in the database. While packages allow the administrator or application developer the ability to organize such routines, they also offer increased functionality (for example, global package variables can be declared and used by any procedure in the package) and performance (for example, all objects of the package are parsed, compiled, and loaded into memory once).

 Database Triggers

ORACLE allows you to write procedures that are automatically executed as a result of an insert in, update to, or delete from a table. These procedures are called database triggers.

Database triggers can be used in a variety of ways for the information management of your database. For example, they can be used to automate data generation, audit data modifications, enforce complex integrity constraints, and customize complex security authorizations.

Data Integrity

It is very important to guarantee that data adheres to certain business rules, as determined by the database administrator or application developer. For example, assume that a business rule says that no row in the INVENTORY table can contain a numeric value greater than .9 in the SALE_DISCOUNT column. If an INSERT or UPDATE statement attempts to violate this integrity rule, ORACLE must roll back the invalid statement and return an error to the application. ORACLE provides integrity constraints and database triggers as solutions to manage a database's data integrity rules.

 Integrity Constraints

An integrity constraint is a declarative way to define a business rule for a column of a table. An integrity constraint is a statement about a table's data that is always true:

•	If an integrity constraint is created for a table and some existing table data does not satisfy the constraint, the constraint cannot be enforced.

•	After a constraint is defined, if any of the results of a DML statement violate the integrity constraint, the statement is rolled back and an error is returned.

Integrity constraints are defined with a table and are stored as part of the table's definition, centrally in the database's data dictionary, so that all database applications must adhere to the same set of rules. If a rule changes, it need only be changed once at the database level and not many times for each application.

The following integrity constraints are supported by ORACLE:

NOT NULL	disallows nulls (empty entries) in a table's column

UNIQUE	disallows duplicate values in a column or set of columns

PRIMARY KEY	disallows duplicate values and nulls in a column or set of columns

FOREIGN KEY	requires each value in a column or set of columns match a value in a related table's UNIQUE or PRIMARY KEY (FOREIGN KEY integrity constraints also define referential integrity actions that dictate what ORACLE should do with dependent data if the data it references is altered.)

CHECK	disallows values that do not satisfy the logical expression of the constraint

Keys      The term "key" is used in the definitions of several types of integrity constraints. A key is the column or set of columns included in the definition of certain types of integrity constraints. Keys describe the relationships between the different tables and columns of a relational database. The different types of keys include:

primary key	The column or set of columns included in the definition of a table's PRIMARY KEY constraint. A primary key's values uniquely identify the rows in a table. Only one primary key may be defined per table.

unique key	The column or set of columns included in the definition of a UNIQUE constraint.

foreign key	The column or set of columns included in the definition of a referential integrity constraint.

referenced key	The unique key or primary key of the same or different table that is referenced by a foreign key.

Individual values in a key are called key values.

 Database Triggers

Note: The information in this section applies only to ORACLE with the procedural option.

Centralized actions can be defined using a non-declarative approach (writing PL/SQL code) with database triggers. A database trigger is a stored procedure that is fired (implicitly executed) when an INSERT, UPDATE, or DELETE statement is issued against the associated table. Database triggers can be used to customize a database management system with such features as value-based auditing and the enforcement of complex security checks and integrity rules. For example, a database trigger might be created to allow a table to be modified only during normal business hours.

Note: While database triggers allow you to define and enforce integrity rules, a database trigger is not the same as an integrity constraint. Among other things, a database trigger defined to enforce an integrity rule does not check data already loaded into a table. Therefore, it is strongly recommended that you use database triggers only when the integrity rule cannot be enforced by integrity constraints.

________________________________________

Data Concurrency and Consistency

This section explains the software mechanisms used by ORACLE to fulfill the following important requirements of an information management system:

•	Data must be read and modified in a consistent fashion.

•	Data concurrency of a multi-user system must be maximized.

•	High performance is required for maximum productivity from the many users of the database system.

Concurrency

A primary concern of a multi-user database management system is how to control concurrency, or the simultaneous access of the same data by many users. Without adequate concurrency controls, data could be updated or changed improperly, compromising data integrity. If many people are accessing the same data, one way of managing data concurrency is to make each user wait his or her turn. The goal of a database management system is to reduce that wait so it is either non-existent or negligible to each user. All DML statements should proceed with as little interference as possible and destructive interactions between concurrent transactions must be prevented. Neither performance nor data integrity can be sacrificed.

ORACLE resolves such issues by using various types of locks and a multiversion consistency model. Both features are discussed later in this section. These features are based on the concept of a transaction. As discussed in "Data Consistency Using Transactions" on page 1 - 26,  it is the application designer's responsibility to ensure that transactions fully exploit these concurrency and consistency features.

Read-Consistency

Read-consistency, as supported by ORACLE, does the following:

•	guarantees that the set of data seen by a statement is consistent with respect to a single point-in-time and does not change during statement execution (statement-level read consistency)

•	ensures that readers of database data do not wait for writers or other readers of the same data

•	ensures that writers of database data do not wait for readers of the same data

•	ensures that writers only wait for other writers if they attempt to update identical rows in concurrent transactions

The simplest way to think of ORACLE's implementation of read-consistency is to imagine each user operating a private copy of the database, hence the multiversion consistency model.

 Read-Consistency, Rollback Segments, and Transactions

To manage the multiversion consistency model, ORACLE must create a read-consistent set of data when a table is being queried (read) and simultaneously updated (written). When an update occurs, the original data values changed by the update are recorded in the database's rollback segments. As long as this update remains part of an uncommitted transaction, any user that later queries the modified data views the original data values-ORACLE uses current information in the SGA and information in the rollback segments to construct a read-consistent view of a table's data for a query. Only when a transaction is committed are the changes of the transaction made permanent. Only statements that start after another user's transaction is committed see the changes made by the committed transaction.

Note that a transaction is key to ORACLE's strategy for providing read-consistency. This unit of committed (or uncommitted) SQL statements:

•	dictates the start point for read-consistent views generated on behalf of readers

•	controls when modified data can be seen by other transactions of the database for reading or updating

 Read-Only Transactions

By default, ORACLE guarantees statement-level read consistency. The set of data returned by a single query is consistent with respect to a single point-in-time. However, in some situations, you may also require transaction-level read consistency-the ability to run multiple queries within a single transaction, all which are read-consistent with respect to the same point-in-time, so that queries in this transaction do not see the effects of intervening committed transactions.

If you want to run a number of queries against multiple tables and if you are doing no updating, you may prefer a read-only transaction. After indicating that your transaction is read-only, you can execute as many queries as you like against any table, knowing that the results of each query are consistent with respect to the same point in time.

Locking

ORACLE also uses locks to control concurrent access to data. Locks are mechanisms intended to prevent destructive interaction between users accessing ORACLE data. Destructive interaction can be interpreted as any interaction that incorrectly updates data or incorrectly alters underlying data structures.

Locks are used to achieve two important database goals:

consistency	ensures that the data a user is viewing or changing is not changed (by other users) until the user is finished with the data

integrity	ensures that the database's data and structures reflect all changes made to them in the correct sequence

Locks guarantee data integrity while allowing maximum concurrent access to the data by unlimited users.

 Automatic Locking

ORACLE locking is performed automatically and requires no user action. Implicit locking occurs for SQL statements as necessary, depending on the action requested.

ORACLE's sophisticated lock manager automatically locks table data at the row level. By locking table data at the row level, contention for the same data is minimized.

ORACLE's lock manager maintains several different types of row locks, depending on what type of operation established the lock. In general, there are two types of locks: exclusive locks and share locks. Only one exclusive lock can be obtained on a resource (such as a row or a table); however, many share locks can be obtained on a single resource. Both exclusive and share locks always allow queries on the locked resource, but prohibit other activity on the resource (such as updates and deletes).

 Manual Locking

Under some circumstances, a user may want to override default locking. ORACLE allows manual override of automatic locking features at both the row level (by first querying for the rows that will be updated in a subsequent statement) and the table level.

________________________________________

Database Security

Multi-user database systems, such as ORACLE, include security features that control how a database is accessed and used. For example, security mechanisms do the following:

•	prevent unauthorized database access

•	prevent unauthorized access to schema objects

•	control disk usage

•	control system resource usage (such as CPU time)

•	audit user actions

Database security can be classified into two distinct categories: system security and data security.

System security includes the mechanisms that control the access and use of the database at the system level. For example, system security includes:

•	valid username/password combinations

•	whether or not a user is authorized to connect to the database

•	the amount of disk space available to the objects of a user

•	the resource limits for a user

•	whether or not database auditing is active

•	which system operations a user can perform

Data security includes the mechanisms that control the access and use of the database at the object level. For example, data security includes:

•	which users have access to a specific schema object and the specific types of actions allowed for each user on the object (e.g., user SCOTT can issue SELECT and INSERT statements but not DELETE statements using the EMP table)

•	the actions, if any, that are audited for each schema object

Security Mechanisms

The ORACLE Server provides discretionary access control, which is a means of restricting access to information based on privileges. The appropriate privilege must be assigned to a user in order for that user to access an object. Appropriately privileged users can grant other users privileges at their discretion; for this reason, this type of security is called "discretionary."

ORACLE manages database security using several different facilities:

•	database users and schemas

•	privileges

•	roles

•	storage settings and quotas

•	resource limits

•	auditing

Figure 1 - 6 illustrates the relationships of the different ORACLE security facilities and the following sections provide an overview of users, privileges, and roles.

 Database Users and Schemas

Each ORACLE database has a list of user names. To access a database, a user must use a database application and attempt a connection with a valid user name of the database. Each user name has an associated password to prevent unauthorized use.

Associated with each database user is a schema by the same name. A schema is a logical collection of objects (tables, views, sequences, synonyms, indexes, clusters, procedures, functions, packages, and database links). By default, each database user creates and has access to all objects in the corresponding schema.

Security Domain      Each user has a security domain-a set of properties that determine such things as:

•	the actions (privileges and roles) available to the user

•	the tablespace quotas (available disk space) for the user

•	the system resource limits (for example, CPU processing time) for the user

Each property that contributes to a user's security domain is discussed in the following sections.

 Privileges

A privilege is a right to execute a particular type of SQL statement. Some examples of privileges include:

•	the right to connect to the database (create a session)

•	the right to create a table in your schema

•	the right to select rows from someone else's table

•	the right to execute someone else's stored procedure

The privileges of an ORACLE database can be divided into two distinct categories: system privileges and object privileges.

System Privileges      System privileges allow users to perform a particular systemwide action, or to perform a particular action on a particular type of object. For example, the privileges to create a tablespace or to delete the rows of any table in the database are system privileges. Many system privileges are available only to administrators and application developers because the privileges are very powerful.

Object Privileges      Object privileges allow users to perform a particular action on a specific object. For example, the privilege to delete rows of a specific table is an object privilege. Object privileges are granted (assigned) to end-users so that they can use a database application to accomplish specific tasks.

Granting Privileges      Privileges are granted to users so that users can access and modify data in the database. A user can receive a privilege two different ways:

•	Privileges can be granted to users explicitly. For example, the privilege to insert records into the EMP table can be explicitly granted to the user SCOTT.

•	Privileges can be granted to roles (a named group of privileges), and then the role can be granted to one or more users. For example, the privilege to insert records into the EMP table can be granted to the role named CLERK, which in turn can be granted to the users SCOTT and BRIAN.

Because roles allow for easier and better management of privileges, privileges are normally granted to roles and not to specific users. The following section explains more about roles and their use.

 Roles

ORACLE provides for easy and controlled privilege management through the use of roles. Roles are named groups of related privileges that are granted to users or other roles. The following properties of roles allow for easier privilege management:

•	reduced granting of privileges-Rather than explicitly granting the same set of privileges to many users, a database administrator can grant the privileges for a group of related users granted to a role, and then grant only the role to each member of the group.

•	dynamic privilege management-When the privileges of a group must change, only the privileges of the role need to be modified. The security domains of all users granted the group's role automatically reflect the changes made to the role.

•	selective availability of privileges-The roles granted to a user can be selectively enabled (available for use) or disabled (not available for use). This allows specific control of a user's privileges in any given situation.

•	application awareness-A database application can be designed to automatically enable and disable selective roles when a user attempts to use the application.

Roles are often created for a database application. An application role is granted all privileges necessary to run the application. The application role is then granted to other roles or users. An application can have several different roles, each granted a different set of privileges that allow for more or less data access while using the application.

A role can be created with a password to prevent unauthorized use of the privileges granted to the role. Typically, an application is designed so that when it starts, it enables the proper role. As a result, an application user does not need to know the password for an application's role.

 Storage Settings and Quotas

ORACLE provides means for directing and limiting the use of disk space allocated to the database on a per user basis, including default and temporary tablespaces, and tablespace quotas.

Default Tablespace   Each user is associated with a default tablespace. When a user creates a table, index, or cluster and no tablespace is specified to physically contain the object, the user's default tablespace is used if the user has the privilege to create the object and a quota in the specified default tablespace. The default tablespace feature provides ORACLE with information to direct space usage in situations where object location is not specified.

Temporary Tablespace   Each user has a temporary tablespace. When a user executes a SQL statement that requires the creation of temporary segments (such as the creation of an index), the user's temporary tablespace is used. By directing all users' temporary segments to a separate tablespace, the temporary tablespace feature can reduce I/O contention among temporary segments and other types of segments.

Tablespace Quotas   ORACLE can limit the collective amount of disk space available to the objects in a schema. Quotas (space limits) can be set for each tablespace available to a user. The tablespace quota security feature permits selective control over the amount of disk space that can be consumed by the objects of specific schemas.

 Profiles and Resource Limits

Each user is assigned a profile that specifies limitations on several system resources available to the user, including:

•	the number of concurrent sessions the user can establish

•	the CPU processing time:

•	available to the user's session

•	available to a single call to ORACLE made by a

 SQL statement

•	the amount of logical I/O:

•	available to the user's session

•	available to a single call to ORACLE made by a

 SQL statement

•	the allowed amount of idle time for the user's session

•	the allowed amount of connect time for the user's session

Different profiles can be created and assigned individually to each user of the database. A default profile is present for all users not explicitly assigned a profile. The resource limit feature prevents excessive consumption of global database system resources.

 Auditing

ORACLE permits selective auditing (recorded monitoring) of user actions to aid in the investigation of suspicious database use. Auditing can be performed at three different levels: statement auditing, privilege auditing, and object auditing.

statement auditing	Statement auditing is the auditing of specific SQL statements without regard to specifically named objects. (In addition, database triggers allow a DBA to extend and customize ORACLE's built-in auditing features.)

Statement auditing can be broad and audit all users of the system, or can be focused to audit only selected users of the system. For example, statement auditing by user can audit connections to and disconnections from the database by the users SCOTT and LORI.

privilege auditing	Privilege auditing is the auditing of the use of powerful system privileges without regard to specifically named objects. Privilege auditing can be broad and audit all users or can be focused to audit only selected users.

object auditing	Object auditing is the auditing of accesses to specific schema objects without regard to user. Object auditing monitors the statements permitted by object privileges, such as SELECT or DELETE statements on a given table.

For all types of auditing, ORACLE allows the selective auditing of successful statement executions, unsuccessful statement executions, or both. This allows monitoring of suspicious statements, regardless of whether or not the user issuing a statement has the appropriate privileges to issue the statement.

The results of audited operations are recorded in a table referred to as the audit trail. Predefined views of the audit trail are available so that audit records can be easily retrieved.

Trusted ORACLE

Trusted ORACLE is Oracle Corporation's multilevel secure database management system product. It is designed to provide the high level of secure data management capabilities required by organizations processing sensitive or classified information. Trusted ORACLE is compatible with Oracle base products and applications, and supports all of the functionality of standard ORACLE.

In addition, Trusted ORACLE enforces mandatory access control (also called MAC) across a wide range of multilevel secure operating system environments. Mandatory access control is a means of restricting access to information based on labels. A user's label indicates what information a user is permitted to access and the type of access (read or write) that the user is allowed to perform. An object's label indicates the sensitivity of the information that the object contains. A user's label must meet certain criteria, determined by MAC policy, in order for him to be allowed to access a labeled object. Because this type of access control is always enforced, above any discretionary controls implemented by users, this type of security is called "mandatory."

See the Trusted ORACLE7 Server Administrator's Guide for more information.

________________________________________

Database Backup and Recovery

This section covers the structures and software mechanisms used by ORACLE to provide:

•	database recovery required by different types of failures

•	flexible recovery operations to suit any situation

•	availability of data during backup and recovery operations so that users of the system can continue to work

Why Is Recovery Important?

In every database system, the possibility of a system or hardware failure always exists. Should a failure occur and affect the database, the database must be recovered. The goals after a failure are to ensure that the effects of all committed transactions are reflected in the recovered database and to return to normal operation as quickly as possible while insulating users from problems caused by the failure.

Types of Failures

Several circumstances can halt the operation of an ORACLE database. The most common types of failure are described below:

user error	User errors can require a database to be recovered to a point in time before the error occurred. For example, a user might accidentally drop a table. To allow recovery from user errors and accommodate other unique recovery requirements, ORACLE provides for exact point-in-time recovery. For example, if a user accidentally drops a table, the database can be recovered to the instant in time before the table was dropped.

statement and process failure	Statement failure occurs when there is a logical failure in the handling of a statement in an ORACLE program (for example, the statement is not a valid SQL construction). When statement failure occurs, the effects (if any) of the statement are automatically undone by ORACLE and control is returned to the user.

A process failure is a failure in a user process accessing ORACLE, such as an abnormal disconnection or process termination. The failed user process cannot continue work, although ORACLE and other user processes can. The ORACLE background process PMON automatically detects the failed user process or is informed of it by SQL*Net. PMON resolves the problem by rolling back the uncommitted transaction of the user process and releasing any resources that the process was using.

Common problems such as erroneous SQL statement constructions and aborted user processes should never halt the database system as a whole. Furthermore, ORACLE automatically performs necessary recovery from uncommitted transaction changes and locked resources with minimal impact on the system or other users.

instance failure	Instance failure occurs when a problem arises that prevents an instance (SGA and background processes) from continuing work. Instance failure may result from a hardware problem such as a power outage, or a software problem such as an operating system crash. When an instance failure occurs, the data in the buffers of the SGA is not written to the data files.

Instance failure requires instance recovery. Instance recovery is automatically performed by ORACLE when the instance is restarted. The redo log is used to recover the committed data in the SGA's database buffers that was lost due to the instance failure.

media (disk) failure	An error can arise when trying to write or read a file that is required to operate the database. This is called disk failure because there is a physical problem reading or writing physical files on disk. A common example is a disk head crash, which causes the loss of all files on a disk drive. Different files may be affected by this type of disk failure, including the data files, the redo log files, and the control files. Also, because the database instance cannot continue to function properly, the data in the database buffers of the SGA cannot be permanently written to the data files.

A disk failure requires media recovery. Media recovery restores a database's data files so that the information in them corresponds to the most recent time point prior to the disk failure, including the committed data in memory that was lost because of the failure. To complete a recovery from a disk failure, the following is required: backups of the database's data files, and all online and necessary archived redo log files.

ORACLE provides for complete and quick recovery from all possible types of hardware failures including disk crashes. Options are provided so that a database can be completely recovered or partially recovered to a specific point-in-time.

If some data files are damaged in a disk failure but most of the database is intact and operational, the database can remain open while the required tablespaces are individually recovered. Therefore, undamaged portions of a database are available for normal use while damaged portions are being recovered.

Structures Used for Recovery

ORACLE uses several structures to provide complete recovery from an instance or disk failure: the redo log, rollback segments, a control file, and necessary database backups.

The Redo Log

As described in "Redo Log Files" on page 1 - 13, the redo log is a set of files that protect altered database data in memory that has not been written to the data files. The redo log can be comprised of two parts: the online redo log and the archived redo log.

The Online Redo Log      The online redo log is a set of two or more online redo log files that record all committed changes made to the database. Whenever a transaction is committed, the corresponding redo entries temporarily stored in redo log buffers of the SGA are written to an online redo log file by the background process LGWR.

The online redo log files are used in a cyclical fashion; for example, if two files constitute the online redo log, the first file is filled, the second file is filled, the first file is reused and filled, the second file is reused and filled, and so on. Each time a file is filled, it is assigned a log sequence number to identify the set of redo entries.

To avoid losing the database due to a single point of failure, ORACLE can maintain multiple sets of online redo log files. A mirrored online redo log consists of copies of online redo log files physically located on separate disks; changes made to one member of the group are made to all members. If a disk fails that contains an online redo log file, other copies are still intact and available to ORACLE. System operation is not interrupted and the lost online redo log files can be easily recovered using an intact copy.

The Archived Redo     Log   Optionally, filled online redo files can be archived before being reused, creating an archived redo log. Archived (offline) redo log files constitute the archived redo log.

The presence or absence of an archived redo log is determined by the mode that the redo log is using:

ARCHIVELOG	The filled online redo log files are archived before they are reused in the cycle.

NOARCHIVELOG	The filled online redo log files are not archived.

In ARCHIVELOG mode, the database can be completely recovered from both instance and disk failure. The database can also be backed up while it is open and available for use. However, additional administrative operations are required to maintain the archived redo log.

If the database's redo log is operated in NOARCHIVELOG mode, the database can be completely recovered from instance failure, but not from a disk failure. Additionally, the database can be backed up only while it is completely closed. Because no archived redo log is created, no extra work is required by the database administrator.

 Control Files

The control files of a database keep, among other things, information about the file structure of the database and the current log sequence number being written by LGWR. During normal recovery procedures, the information in a control file is used to guide the automated progression of the recovery operation.

Mirrored Control Files      This feature is similar to the mirrored redo log feature: a number of identical control files may be maintained by ORACLE, which updates all of the simultaneously. The loss of one such control file therefore does not cause the database to halt as long as other control files are available.

 Rollback Segments

As described in "Segments" on page 1 - 12, rollback segments record rollback information used by several functions of ORACLE. During database recovery, after all changes recorded in the redo log have been applied, ORACLE uses rollback segment information to undo any uncommitted transactions. Because rollback segments are stored in the database buffers, this important recovery information is automatically protected by the redo log.

 Database Backups

Because one or more files can be physically damaged as the result of a disk failure, media recovery requires the restoration of the damaged files from the most recent operating system backup of a database. There are several ways to back up the files of a database.

Full Backups      A full backup is an operating system backup of all data files, online redo log files, and the control file that constitutes an ORACLE database. Full backups are performed when the database is closed and unavailable for use.

Partial Backups      A partial backup is an operating system backup of part of a database. The backup of an individual tablespace's data files or the backup of a control file are examples of partial backups. Partial backups are useful only when the database's redo log is operated in ARCHIVELOG mode.

A variety of partial backups can be taken to accommodate any backup strategy. For example, data files and control files can be backed up when the database is open or closed, or when a specific tablespace is online or offline. Because the redo log is operated in ARCHIVELOG mode, additional backups of the redo log are not necessary; the archived redo log is a backup of filled online redo log files.

Basic Recovery Steps

Due to the way in which DBWR writes database buffers to data files, at any given point in time, a data file may contain some data blocks tentatively modified by uncommitted transactions and may not contain some blocks modified by committed transactions. Therefore, two potential situations can result after a failure:

•	Blocks containing committed modifications were not written to the data files, so the changes may only appear in the redo log. Therefore, the redo log contains committed data that must be applied to the data files.

•	Since the redo log may have contained data that was not committed, uncommitted transaction changes applied by the redo log during recovery must be erased from the data files.

To solve this situation, two separate steps are always used by ORACLE during recovery from an instance or media failure: rolling forward and rolling back.

 Rolling Forward

The first step of recovery is to roll forward, or reapply to the data files all of the changes recorded in the redo log. Rolling forward proceeds through as many redo log files as necessary to bring the data files forward to the required time. If all needed redo information is online, ORACLE performs this recovery step automatically when the database starts. After roll forward, the data files contain all committed changes as well as any uncommitted changes that were recorded in the redo log.

 Rolling Back

The roll forward is only half of recovery. After the roll forward, any changes that were not committed must be undone. After the redo log files have been applied, then the rollback segments are used to identify and undo transactions that were never committed, yet were recorded in the redo log. This process is called rolling back. ORACLE completes this step automatically.

________________________________________

Distributed Processing and Distributed Databases

As computer networking becomes more and more prevalent in today's computing environments, database management systems must be able to take advantage of distributed processing and storage capabilities. This section explains the architectural features of ORACLE that meet these requirements.

Client-Server Architecture: Distributed Processing

Distributed processing uses more than one processor to divide the processing for a set of related jobs. Distributed processing reduces the processing load on a single processor by allowing different processors to concentrate on a subset of related tasks, thus improving the performance and capabilities of the system as a whole.

An ORACLE database system can easily take advantage of distributed processing by using its client-server architecture. In this architecture, the database system is divided into two parts: a front-end or a client portion and a back-end or a server portion.

Client      The client portion is the front-end database application and interacts with a user through the keyboard, display, and pointing device such as a mouse. The client portion has no data access responsibilities; it concentrates on requesting, processing, and presenting data managed by the server portion. The client workstation can be optimized for its job. For example, it might not need large disk capacity or it might benefit from graphic capabilities.

Server      The server portion runs ORACLE software and handles the functions required for concurrent, shared data access. The server portion receives and processes SQL and PL/SQL statements originating from client applications. The computer that manages the server portion can be optimized for its duties. For example, it can have large disk capacity and fast processors.

Distributed Databases

Note: The information in this section regarding distributed updates and two-phase commit applies only for those systems using ORACLE with the distributed option.

A distributed database is a network of databases managed by multiple database servers that appears to a user as a single logical database. The data of all databases in the distributed database can be simultaneously accessed and modified. The primary benefit of a distributed database is that the data of physically separate databases can be logically combined and potentially made accessible to all users on a network.

Each computer that manages a database in the distributed database is called a node. The database to which a user is directly connected is called the local database. Any additional databases accessed by this user are called remote databases. When a local database accesses a remote database for information, the local database is a client of the remote server (client-server architecture discussed above).

While a distributed database allows increased access to a large amount of data across a network, it must also provide the ability to hide the location of the data and the complexity of accessing it across the network. The distributed DBMS must also preserve the advantages of administrating each local database as though it were non-distributed.

 Location Transparency

Location transparency occurs when the physical location of data is transparent to the applications and users of a database system. Several ORACLE features, such as views, procedures, and synonyms, can provide location transparency. For example, a view that joins table data from several databases provides location transparency because the user of the view does not need to know where the data originates from.

 Site Autonomy

Site autonomy means that each database participating in a distributed database is administered separately and independently from the other databases, as though each database were a non-networked database. Although each database can work with others, they are distinct, separate systems that are cared for individually.

 Distributed Data Manipulation

The ORACLE distributed database architecture supports all DML operations, including queries, inserts, updates, and deletes of remote table data. To access remote data, a reference is made including the remote object's global object name-no coding or complex syntax is required to access remote data. For example, to query a table named EMP in the remote database named SALES, you reference the table's global object name:

SELECT * FROM emp@sales;

 Two-Phase Commit

ORACLE provides the same assurance of data consistency in a distributed environment as in a non-distributed environment. ORACLE provides this assurance using the transaction model and a two-phase commit mechanism. As in non-distributed systems, transactions should be carefully planned to include a logical set of SQL statements that should all succeed or fail as a unit. ORACLE's two-phase commit mechanism guarantees that, no matter what type of system or network failure that might occur, a distributed transaction either commits on all involved nodes or rolls back on all involved nodes to maintain data consistency across the global distributed database.

Complete Transparency to Database Users      The ORACLE two-phase commit mechanism is completely transparent to users that issue distributed transactions. A simple COMMIT statement denoting the end of a transaction automatically triggers the two-phase commit mechanism to commit the transaction; no coding or complex statement syntax is required to include distributed transactions within the body of a database application.

Automatic Recovery from System or Network Failures      The RECO background process automatically resolves the outcome of in-doubt distributed transactions-distributed transactions in which the commit was interrupted by any type of system or network failure. After the failure is repaired and communication is reestablished, the RECO of each local ORACLE Server automatically commits or rolls back any in-doubt distributed transactions consistently on all involved nodes.

Optional Manual Override Capability   In the event of a long-term failure, ORACLE allows each local administrator to manually commit or roll back any distributed transactions that are in-doubt as a result of the failure. This option allows the local database administrator to free up any locked resources that may be held indefinitely as a result of the long-term failure.

Facilities for Distributed Recovery      If a database must be recovered to a point in the past, ORACLE's recovery facilities allow database administrators at other sites to return their databases to the earlier point in time, also. This ensures that the global database remains consistent.

Table Replication

Note: The information in this section applies only to ORACLE with both the distributed option and the procedural option.

Distributed database systems often locally replicate remote tables that are frequently queried by local users. By having read-only copies of heavily accessed data on several nodes, the distributed database does not need to send information across a network repeatedly, thus helping to maximize the performance of the database application.

ORACLE provides an automatic method for table replication and update called snapshots. Snapshots are read-only copies of a master table located on a remote node. A snapshot can be queried, but not updated; only the master table can be updated. A snapshot is periodically refreshed to reflect changes made to the master table.

ORACLE and SQL*Net

SQL*Net is ORACLE's mechanism for interfacing with the communication protocols used by the networks that facilitate distributed processing and distributed databases. Communication protocols define the way that data is transmitted and received on a network. In a networked environment, an ORACLE database server communicates with client workstations and other ORACLE database servers using ORACLE software called SQL*Net. SQL*Net supports communications on all major network protocols, ranging from those supported by PC LANs to those used by the largest of mainframe computer systems.

Using SQL*Net, the application developer does not have to be concerned with supporting network communications in a database application. If a new protocol is used, the database administrator makes some minor changes, while the application requires no modifications and continues to function.


PART  II . BASIC DATABASE OPERATION


CHAPTER 2. DATABASE AND INSTANCE STARTUP AND SHUTDOWN

You've got to get up, you've got to get up,

 You've got to get up this morning!

Irving Berlin: Oh! How I Hate to

 	Get Up in the Morning

This chapter explains the concepts involved in starting and stopping an ORACLE instance and database. Topics include:

•	startup and shutdown concepts

•	modes and stages of database and startup

•	methods and reasons for database and shutdown

•	levels of database availability

•	parameter files

If you are using Trusted ORACLE, refer to the Trusted ORACLE7 Server Administrator's Guide for more information about starting up and shutting down in that environment.

________________________________________

Introduction to Database Startup and Database Shutdown

An ORACLE database is not necessarily always available to all users. The database administrator can start up a database so that it is open. When a database is open, users can access the information that it contains. If a database is open, the database administrator can shut down the database so that it is closed. When a database is closed, users cannot access the information that it contains.

Only a database administrator can open or close a database. Normal users do not have control over the current status of an ORACLE database. Security for database startup and shutdown is controlled via connections to ORACLE as INTERNAL.

Connecting as INTERNAL

Database startup and shutdown are powerful administrative options, and are protected by the ability to connect to ORACLE as INTERNAL. Depending on the operating system, one of the following prerequisites is required to connect to ORACLE as INTERNAL:

•	The user's operating system account has operating system privileges that allow her to connect using INTERNAL.

•	The user is authorized to connect using INTERNAL.

•	The database has a password for INTERNAL, and the user knows the password.

In addition, users can connect as INTERNAL only to dedicated servers (not shared servers), and only over secure connections.

These requirements provide extra security to prevent unauthorized users from starting up or shutting down any ORACLE databases. See your installation or user's guide for information on how INTERNAL works on your operating system.

________________________________________

Database Startup

There are three steps to starting a database and making it available for systemwide use:

1..	Start an instance.

2..	Mount the database.

3..	Open the database.

Starting an Instance

The process of starting an instance includes the allocation of an SGA, a shared area of memory used for database information, and creation of the background processes. Instance startup is performed in anticipation of a database being mounted by the instance. If an instance has been only started, no database is associated with these memory structures and processes.

Before an instance is actually created, ORACLE reads a parameter file, which determines how the instance is initialized. This file includes parameters that control such things as the size of the SGA, the name of the database to which the instance can connect, and so on.

Note: See "Parameter Files" on page 2 - 6 for more information about parameter files. See Chapter 9 for more information about the terms "SGA," "background processes," and "instance."

 Restricted Mode of Instance Startup

An instance can be started in (or later altered to be in) restricted mode so that when the database is open, connections are limited only to those whose user accounts have been granted the RESTRICTED SESSION system privilege.

 Forcing an Instance to Startup in Abnormal Situations

In unusual circumstances, when a database is shut down its instance might not be "cleanly" shut down (e.g., one of the instance's processes might not be killed). In such situations, the database might return an error during normal instance startup. To resolve this problem, the database administrator must kill all remnant ORACLE processes of the previous instance and start a new instance.

Mounting a Database

Mounting a database is the process of associating a database with a previously started instance. After a database is mounted by an instance, it remains closed and is accessible only to database administrators. The database administrator might want to start an instance and only mount the database to complete specific maintenance operations.

When a database is mounted, the instance finds the control files (specified in the parameter CONTROL_FILES of the parameter file used to start the instance) and opens them. Once the database's control files are opened, ORACLE reads them to get the names of the database's data files and redo log files, and then confirms that these files exist as specified.

 Modes of Mounting a Database with the Parallel Server

If ORACLE allows multiple instances to concurrently mount the same database, the DBA can choose the mode in which to run a database: exclusive or parallel mode.

Exclusive Mode      If the first instance that mounts a database does so in exclusive mode, only that instance can mount the database. Versions of ORACLE that do not support the Parallel Server option only allow an instance to mount a database in exclusive mode.

Parallel Mode      If the first instance that mounts a database is started in parallel mode (also called "shared mode"), other instances that are started in parallel mode can also mount the database. The number of instances that can mount the database is subject to a predetermined maximum. (See the ORACLE7 Parallel Server Administrator's Guide for more information about the use of multiple instances with a single database.)

Opening a Database

Opening a mounted database is the process of making the database available for normal database operations. Any valid user can connect to the database and access its information once it is open. In most cases, the database administrator opens the database to make it available for general use.

When the database is opened, the online data files and online redo log files are opened. If a tablespace was offline when the database was previously shut down, the tablespace and its corresponding data files will still be offline when the database is reopened. (See "Online and Offline Tablespaces" on page 4 - 5.)

 Instance Recovery

If the database was shut down because either the DBA aborted its instance or a power failure occurred while the database was running, instance recovery is automatically performed when the database is reopened. (See Chapter 25 for complete information concerning instance recovery.)

 Rollback Segment Acquisition

As an instance opens a database, the instance attempts to acquire one or more rollback segments. (See "Instances and Types of Rollback Segments" on page 3 - 21.)

 Resolution of In-Doubt Distributed Transaction

Assume that a database is abruptly shut down (for example, a power failure occurs or the instance is aborted) and one or more distributed transactions have not been committed or rolled back. When the database is reopened and instance recovery is complete, the RECO background process automatically, immediately, and consistently resolves any distributed transactions that have been committed or rolled back. (For information about distributed transactions, see Chapter 21. For information about recovery from failures associated with distributed transactions, see Chapter 25.)

________________________________________

Database and Instance Shutdown

There are three steps to shutting down an instance and the database to which it is connected:

1..	Close the database.

2..	Dismount the database.

3..	Shut down the instance.

All three steps are automatically performed when an instance is shut down.

Closing a Database

The first step of database shutdown is closing the database. When a database is closed, all database data and recovery data in the SGA are written to the data files and redo log files, respectively. After this operation, all online data files and online redo log files are closed. The offline data files of any offline tablespaces are already closed. When the database is subsequently reopened, the tablespace that was offline and its data files remain offline and closed, respectively. The control files remain open after a database is closed but still mounted.

 Closing the Database by Aborting the Instance

In rare emergency situations, the instance of an open database can be aborted to instantaneously close and completely shut down the database. This process is fast because the operation of writing all data in the buffers of the SGA to the data files and redo log files is skipped. The subsequent reopening of the database requires instance recovery, which is automatically performed by ORACLE.

Note: If a system crash or power failure occurs while the database is open, the instance is, in effect, "aborted," and instance recovery is performed when the database is reopened.

Dismounting a Database

The second step accomplished during database shutdown is dismounting or disassociating the database from an instance. After a database is dismounted, only an instance remains in the memory of your computer.

After a database is dismounted, the control files of the database are closed.

Shutting Down an Instance

The final step in database shutdown is shutting down an instance. When an instance is shut down, the SGA is removed from memory and the background processes are terminated from the computer that executes ORACLE.

 Abnormal Instance Shutdown

In unusual circumstances, shutdown of an instance might not occur cleanly; all memory structures might not be removed from memory or one of the background processes might not be killed. When remnants of previous instances exist, subsequent instance startup will most likely fail. To handle this problem, the DBA can force the new instance to start up by first removing the remnants of the previous instance and then starting a new instance, or by issuing a SHUTDOWN ABORT statement.

________________________________________

Parameter Files

To start an instance, ORACLE must read a parameter file. A parameter file is a text file containing a list of instance configuration parameters. These parameters are set to particular values and are used to initialize many of the memory and process settings of an ORACLE instance. This file is used only by the utility SQL*DBA. Among other things, the parameters of this file tell ORACLE the following:

•	the name of the database for which to start up an instance

•	how much memory to use for memory structures in the SGA

•	what to do with filled online redo log files

•	the names and locations of the database's control files

•	the names of private rollback segments in the database

An Example of a Parameter File

Following is an example of a typical parameter file:

db_block_buffers = 550

db_name = ORA7PROD

db_domain = US.ACME.COM

#

license_max_users = 64

#

control_files = filename1, filename2

#

log_archive_dest = c:\logarch

log_archive_format = arch%S.ora

log_archive_start = TRUE

log_buffer = 64512

log_checkpoint_interval = 256000

# rollback_segments = rs_one, rs_two

ORACLE treats string literals defined for National Language Support (NLS) parameters in the file as if they are in the database character set.

Most parameters belong to one of the following groups:

•	parameters that name things (such as files)

•	parameters that set limits (such as maximums)

•	parameters affecting capacity, called variable parameters (such as the DB_BLOCK_BUFFERS parameter, which specifies the number of data blocks to allocate in the computer's memory for the SGA)

Changing Parameter Values

The database administrator can adjust variable parameters to improve the performance of a database system. Exactly which parameters most affect a system is a function of numerous database characteristics and variables.


PART  III . DATABASE STRUCTURES


CHAPTER 3. DATA BLOCKS, EXTENTS, AND SEGMENTS

Infinite riches in a little room.

Christopher Marlowe: The Jew of Malta

This chapter describes the following logical storage structures and how these structures are interrelated:

•	data blocks, and their size and format (including PCTFREE and PCTUSED)

•	extents, and how and when they are allocated

•	segments, including:

•	data segments

•	index segments

•	rollback segments

•	temporary segments

If you are using Trusted ORACLE, refer to the Trusted ORACLE7 Server Administrator's Guide for more information about storage in that environment.

________________________________________

The Relationships Between Segments, Extents, and Data Blocks

ORACLE allocates database space for all data in a database. The units of logical database allocations are data blocks, extents, and segments. The following illustration shows the relationships between these data structures.

Data Blocks

At the finest level of granularity, an ORACLE database's data is stored in data blocks (also called logical blocks, ORACLE blocks, or pages). One data block corresponds to a specific number of bytes of physical database space on disk. A data block size is specifically set for every ORACLE database when the database is created. This data block size is a multiple of the operating system's block size within the maximum limit. What is important to remember is that a database, at its finest level of granularity, uses and allocates free database space in ORACLE data blocks.

(In contrast, all data at the physical, operating system level is stored in bytes. Each operating system has what is called a block size. An operating system block size is a specific number of bytes on disk.)

Extents

The next level of logical database space is called an extent. An extent is a specific number of contiguous data blocks that is allocated for storing a specific type of information.

Segments

The level of logical database storage above an extent is called a segment. A segment is a set of extents that have been allocated for a specific type of data structure, and that all are stored in the same tablespace. For example, each table's data is stored in its own data segment, while each index's data is stored in its own index segment.

ORACLE allocates space for segments in extents. Therefore, when the existing extents of a segment are full, ORACLE allocates another extent for that segment. Because extents are allocated as needed, the extents of a segment may or may not be contiguous on disk, and may or may not span files. An extent cannot span files, though.

________________________________________

Data Blocks

ORACLE manages the storage space in the data files of a database in units called data blocks. A data block is the smallest unit of I/O used by a database. A data block corresponds to a block of physical bytes on disk, equal to the ORACLE data block size. This block size can differ from the standard I/O block size of the operating system that executes ORACLE.

Data Block Format

The ORACLE block format is similar regardless of whether the data block contains table, index, or clustered data. Figure 3 - 2 illustrates the format of a data block.

 Header (Common and Variable)

The header contains general block information, such as block address, segment type, such as data, index, or rollback. While some block overhead is fixed in size, the total block overhead size is variable. On average, the fixed and variable portions of data block overhead total 84 to 107 bytes.

 Table Directory

The table directory portion of the block contains information about the tables having rows in this block.

 Row Directory

This portion of the block contains row information about the actual rows in the block (including addresses for each row piece in the row data area).

Once the space has been allocated in the row directory of a block's header, this space is not reclaimed when the row is deleted. Therefore, a block that is currently empty but had up to 50 rows at one time continues to have 100 bytes allocated in the header for the row directory. This space is only reused as new rows are inserted in the block.

 Row Data

This portion of the block contains table or index data. Rows can span blocks; see "Row Chaining Across Data Blocks" on page 3 - 9.

 Free Space

Free space is used to insert new rows and for updates to rows that require additional space (e.g., when a trailing null is updated to a non-null value). Whether issued insertions actually occur in a given data block is a function of the value for the space management parameter PCTFREE and the amount of current free space in that data block. See "An Introduction to PCTFREE, PCTUSED, and Row Chaining" on page 3 - 5 describes space management parameters.

 Space Used for Transaction Entries

Data blocks allocated for the data segment of a table, cluster, or the index segment of an index can also use free space for transaction entries. A transaction entry is required in a block for each INSERT, UPDATE, DELETE, and SELECT...FOR UPDATE transaction accessing one or more rows in the block. The space required for transaction entries is operating system dependent; however, transaction entries in most operating systems require approximately 23 bytes.

An Introduction to PCTFREE, PCTUSED, and Row Chaining

Two space management parameters, PCTFREE and PCTUSED, allow a developer to control the use of free space for inserts of and updates to the rows in data blocks. Both of these parameters can only be specified when creating or altering tables and clusters (data segments). In addition, the storage parameter PCTFREE can also be specified when creating or altering indexes (index segments).

 The PCTFREE Parameter

The PCTFREE parameter is used to set the percentage of a block to be reserved (kept free) for possible updates to rows that already are contained in that block. For example, assume that you specify the following parameter within a CREATE TABLE statement:

PCTFREE 20

This states that 20% of each data block used for this table's data segment will be kept free and available for possible updates to the existing rows already within each block. Figure 3 - 3 illustrates PCTFREE.

Notice that before PCTFREE is reached, the free space of the data block is filled by both the insertion of new rows and by the growth of the data block header.

 The PCTUSED Parameter

After a data block becomes full, as determined by PCTFREE, the block is not considered for the insertion of new rows until the percentage of the block being used falls below the parameter PCTUSED. Before this value is achieved, the free space of the data block can only be used for updates to rows already contained in the data block. For example, assume that you specify the following parameter within a CREATE TABLE statement:

PCTUSED 40

In this case, a data block used for this table's data segment is not considered for the insertion of any new rows until the amount of used space in the block falls to 39% or less (assuming that the block's used space has previously reached PCTFREE). Figure 3 - 4 illustrates this.

 How PCTFREE and PCTUSED Work Together

PCTFREE and PCTUSED work together to optimize the utilization of space in the data blocks of the extents within a data segment. Figure 3 - 5 illustrates how PCTFREE and PCTUSED work together to govern the free space of a data block to be used.

 How ORACLE Uses PCTFREE and PCTUSED

In a newly allocated data block, the space available for inserts is the block size minus the sum of the block overhead and PCTFREE. Updates to existing data can use any available space in the block; therefore, updates can reduce the available space of a block to less than PCTFREE, the space reserved for updates but not accessible to inserts.

For each data and index segment, ORACLE maintains one or more free lists; a free list is a list of data blocks that have been allocated for that segment's extents and have free space greater than PCTFREE; these blocks are available for inserts. When an INSERT statement is issued, ORACLE checks a free list of the table for the first available block and uses it if possible; if the free space in that block is not large enough to accommodate the INSERT statement, and it is at least PCTUSED, the block is taken off the free list. Multiple free lists per segment can reduce contention for free lists when concurrent inserts take place.

After DELETE and UPDATE statements are issued, ORACLE checks to see if the space being used in the block is less than PCTUSED; if it is, the block goes to the beginning of the free list, and it is the first of the available blocks to be used.

 Availability and Compression of Free Space in a Data Block

Two types of statements return space to the free space of one or more data blocks: DELETE statements, and UPDATE statements that update existing values to smaller values. The released space from these types of statements is available for subsequent INSERT statements with the following conditions:

•	If the INSERT statement is in the same transaction and subsequent to the statement that frees space, the INSERT statement can use the space made available.

•	If the INSERT statement is in one transaction and the statement that frees space is in a second transaction (perhaps being executed by another user), the INSERT statement can only use the space made available after the second transaction commits, and only if the space is needed.

Released space may or may not be contiguous with the main area of free space in a data block. The free space of a data block is only coalesced when an INSERT or UPDATE statement attempts to use a block that contains enough free space to contain a new row piece, yet the free space is fragmented so that the row piece cannot be inserted in a contiguous section of the block. This compression is only done in such situations so that the performance of a database system is not decreased by the continuous and unnecessary compression of the free space in data blocks as each DELETE or UPDATE statement is issued.

Row Chaining Across Data Blocks

In some circumstances, all of the data for a row in a table may not be able to fit in the same data block. When this occurs, the data for the row is stored in a chain of data blocks (one or more) reserved for that segment. Row chaining most often occurs with large rows (e.g., rows that contain a column of datatype LONG or LONG RAW).

Note: The format of a row is described in "Row Format and Size" on page 5 - 4.

If a table contains a column of datatype LONG, which can hold up to two gigabytes of information, the data for a row may need to be chained to one or more data blocks. Nothing can be done to avoid this type of row chaining.

If a row in a data block is updated so that the overall row length increases and the block's free space has been completely filled, the data for the entire row is migrated to a new data block, assuming the entire row can fit in a new block. The original row piece of a migrated row is preserved to point to the new block containing the migrated row; the ROWID of a migrated row does not change.

When a row is chained or migrated, I/O performance associated with this row is decreased because ORACLE must scan more than one data block to retrieve the information for the row. For information about reducing migrated rows and improving I/O performance, see the ORACLE7 Server Application Developer's Guide.

________________________________________

Extents

An extent is a logical unit of database storage space allocation made up of a contiguous number of data blocks. Each type of segment is comprised of one or more extents. When the existing space in a segment is completely used, ORACLE allocates a new extent for the segment.

This section describes how extents are allocated for segments.

When Extents Are Allocated for Segments

No matter what type, each segment in a database is created with at least one extent to hold its data. This extent is called the segment's initial extent.

Note: Rollback segments are an exception to this rule; they always have at least two extents.

For example, when a table is created, its data segment contains an initial extent of a specified number of data blocks. Although no rows have been inserted yet, the ORACLE data blocks that correspond to the initial extent are reserved for that table's rows.

If the data blocks of a segment's initial extent become full and more space is required to hold new data, ORACLE automatically allocates an incremental extent for that segment. An incremental extent is a subsequent extent of the same or incremented size of the previous extent in that segment.

For maintenance purposes, each segment in a database contains a segment header block that describes the characteristics of that segment and a directory (list) of the extents in that segment.

How Extents Are Allocated for Segments

ORACLE controls the actual allocation of extents for a given segment. The following steps are performed to allocate a new extent for a segment:

1..	ORACLE searches through the free space (in the tablespace that contains the segment) for the first free, contiguous set of data blocks that constitute an incremental extent's size (or larger). The free space to contain the new extent is found using the following algorithm:

a.  ORACLE searches for a contiguous set of data blocks that matches the size of new extent, rounded up to reduce internal fragmentation. For example, if a new extent requires 19 data blocks, ORACLE searches for exactly 20 contiguous data blocks.

b.  If an exact match is not found, ORACLE then searches for a set of contiguous data blocks equal to or greater than the amount needed. If it finds a group of contiguous blocks that is at least five blocks greater than the size of the extent that is needed, it splits the group of blocks into separate extents, one of which is the size it needs; if it finds a group of blocks that is larger than the size it needs, but less than five blocks larger, it allocates all the contiguous blocks.

Continuing with the example, if ORACLE does not find a set of exactly 20 contiguous data blocks, it then searches for a set of contiguous data blocks greater than 20. If the first set that it finds contains 25 or more blocks, it breaks the blocks up to allocate the new extent; if the first set of blocks it finds contains between 21 and 24 blocks, it allocates all of the blocks without breaking any off.

c.  If a larger set of contiguous data blocks is not found, ORACLE then coalesces any free, adjacent data blocks in the corresponding tablespace so that larger sets of contiguous data blocks are formed. (The SMON background process also periodically coalesces adjacent free space.) After coalescing a tablespace's data blocks, the searches described in a. and b. are performed a second time. If an extent cannot be allocated after the second search, an error is returned.

2..	Once ORACLE finds the necessary free space in the tablespace, a portion of the free space that corresponds to the size of the incremental extent is allocated for that extent. If ORACLE had found a larger amount of free space than was required for the extent, the remainder is left as free space (no smaller than five contiguous blocks).

3..	The segment header and data dictionary are updated to show that a new extent has been allocated and that the allocated space is no longer free.

Usually ORACLE zeros out the blocks of a newly allocated extent when the extent is first used; in a few cases (such as when a DBA issues an ALTER TABLE or ALTER CLUSTER statement with the ALLOCATE EXTENT option while using free list groups), ORACLE clears the extent's blocks when it allocates the extent.

When Extents Are Deallocated

In general, the extents of a segment are not returned to the tablespace until the segment is deallocated as a unit, such as when they are dropped using a DROP TABLE statement or DROP CLUSTER statement. Exceptions to this rule include the following:

•	The owner of a table or cluster, or a user with the DELETE ANY privilege, can truncate the table or cluster with a TRUNCATE statement.

•	Periodically, ORACLE may deallocate one or more extents of a rollback segment.

When extents are freed, the data dictionary is updated to reflect the regained extents as available space. All data in the blocks of freed extents is not accessible, and is zeroed when the blocks are subsequently reused for other extents.

 Non-Clustered Tables, Snapshots, and Snapshot Logs

As long as a non-clustered table (including an underlying table for a snapshot or snapshot log) exists or until the table is truncated, any data block allocated to its data segment remains allocated for the table; new rows for the table can be inserted into a block if there is enough room. Even if all rows of a table are deleted, the data blocks are not reclaimed for use by other objects in the tablespace.

When a non-clustered table is dropped, all the extents of its data and index segments are reclaimed by ORACLE for the tablespaces that they were in and the extents are made available for other objects in the tablespace. Subsequently, when other segments require large extents, contiguous reclaimed extents are identified and combined at this time by ORACLE to form larger extents requested by other segments.

 Clustered Tables and Snapshots

Clustered tables and snapshots store their information in the data segment created for the cluster. Therefore, if a clustered table is dropped, the data segment remains for the other tables in the cluster, and no extents are deallocated. Clusters (except for hash clusters) can also be truncated to free extents.

 Indexes

All extents allocated to an index segment remain allocated as long as the index exists. When the index or associated table or cluster is dropped, the extents are reclaimed for other uses within the tablespace.

 Rollback Segments

ORACLE periodically checks to see if the rollback segments of the database have grown larger than their optimal size. If a rollback segment is larger than optimal (that is, has too many extents), then ORACLE automatically deallocates one or more extents from the rollback segment. (Also see "How Extents Are Deallocated from a Rollback Segment" on page 3 - 20;..)

 Temporary Segments

Temporary segments; droppingWhen a statement requiring a temporary segment is finished being executed, the temporary segment is automatically dropped and the extents allocated for the segment are returned to the tablespace that contains the segment.

Determining Sizes and Limits of Segment Extents

Every segment is defined by several storage parameters expressed in terms of extents. Storage parameters apply to all types of segments. They control how free database space is allocated by the RDBMS for a given segment. For example, by specifying the storage parameters of the STORAGE clause in the CREATE TABLE statement used to create a table, you can determine how much space is initially reserved for a table's data segment or limit the maximum amount of space (number of extents) a table can allocate.

________________________________________

Segments

A segment is a set of extents that contain all the data for a specific type of logical storage structure within a tablespace. For example, for each table, ORACLE allocates one or more extents to form the table's data segment and for each index, ORACLE allocates one or more extents to form the index's index segment.

An ORACLE database can contain four different types of segments:

•	data segment

•	index segment

•	rollback segment

•	temporary segment

The following sections discuss each type of segment.

Data Segments

Every non-clustered table (including snapshots and snapshot logs) in an ORACLE database has a single data segment to hold all of its data. The data segment for a table is indirectly created via the CREATE TABLE/SNAPSHOT/SNAPSHOT LOG command.

Every cluster in an ORACLE database also has a single data segment to hold all of its data. All data for all tables in the same cluster is stored in the same data segment. The data segment for the cluster is indirectly created via the CREATE CLUSTER command.

Storage parameters for a table, snapshot, snapshot log, or cluster control the way that a data segment's extents are allocated. Setting these storage parameters directly via the CREATE TABLE/ SNAPSHOT/ SNAPSHOT LOG/CLUSTER or ALTER TABLE/ SNAPSHOT/ SNAPSHOT LOG/CLUSTER commands affects the efficiency of data retrieval and storage for that data segment.

Index Segments

Every index in an ORACLE database has a single index segment to hold all of its data. The index segment for the index is indirectly created via the CREATE INDEX command. This command allows you to specify the storage parameters for the extents of the index segment and the tablespace in which to create the index segment. (A data segment for a table and an index segment for an associated index do not have to reside in the same tablespace.)

The creator of an index can control the way that an index segment's extents are allocated; setting the storage parameters directly affects the efficiency of data retrieval and storage corresponding to that index segment.

Rollback Segments

Each database contains one or more rollback segments. A rollback segment is a portion of the database that records the actions of a transaction that should be rolled back under certain circumstances. Rollback segments are used to provide read consistency, to rollback transactions, and to recover the database. For specific information about how rollback segments function in these situations, see the appropriate sections of this book:

Topic	Section Name	Page

Read Consistency	Read Consistency and Rollback Seg	10 - 7

ments

Transaction Rollback	Rolling Back Transactions	12 - 6

Database Recovery	Rollback Segments and Rolling Back	25 - 4

The following sections concerning rollback segments provide information about how rollback segments work in transaction rollback, read consistency, and database recovery.

 Contents of a Rollback Segment

Information in a rollback segment consists of several rollback entries. Among other information, a rollback entry includes block information (the filename and block ID corresponding to the data that was changed) and data as it existed before an operation in a transaction. Rollback entries for the same transaction are linked together so the entries can easily be found if necessary for transaction rollback.

Rollback segments cannot be accessed or read by database users or the database administrator; they are written and read by ORACLE only. (They are owned by the user SYS, no matter which user creates them.)

Because rollback entries change data blocks, they are also recorded in the redo log. This second recording of the rollback information is very important for active transactions not yet committed at the time of the system crash. If a system crash occurs, the rollback segment information, including the rollback entries for active transactions, is automatically restored as part of instance or media recovery. Rollbacks of transactions that had not been committed or rolled back at the time of the failure can be performed after recovery is complete.

When Rollback Information Is Required

ORACLE maintains a transaction table for each rollback segment contained in a database. Each table is a list of all transactions that use the associated rollback segment and the rollback entries for each change performed by these transactions. The rollback entries in a rollback segment are used to perform a transaction rollback and to create read-consistent results for queries.

Rollback segments record the data prior to change, on a per transaction basis. For every transaction, each new change is linked to the previous change. If the transaction needs to be rolled back, the changes in the chain are applied to the data blocks in an order that restores the data to its previous state.

Similarly, when ORACLE needs to provide a read-consistent set of results for a query, it can use information in rollback segments to create a set of data consistent with respect to a single point-in-time.

All types of rollbacks use the same procedures:

•	statement level rollback (due to statement or deadlock execution error)

•	rollback to a savepoint

•	rollback of a transaction due to user request

•	rollback of a transaction due to abnormal process termination

•	rollback of all outstanding transactions when an instance terminates abnormally

•	rollback of incomplete transactions during recovery

Transactions and Rollback Segments

Each time a user's transaction begins, the transaction is assigned to a rollback segment:

•	A transaction can be automatically assigned to the next available rollback segment by ORACLE. If a transaction is assigned to a rollback segment by ORACLE, the transaction is assigned when the first DML or DDL statement in the transaction is issued. Read-only transactions (transactions that contain only queries) are never assigned to a rollback segment, whether or not the transaction begins with a SET TRANSACTION READ ONLY statement.

•	A transaction can be explicitly assigned to a specific rollback segment by the application. At the start of a transaction, a developer or user can specify a particular rollback segment that ORACLE should use in executing the transaction. This allows the developer or user to select a large or small rollback segment, as appropriate for the transaction.

For the duration of a transaction, the associated user process writes rollback information only to the assigned rollback segment.

When a transaction is committed, the rollback information is released, but is not immediately destroyed. The information remains in the rollback segment to create read-consistent views of pertinent data for queries that started before the transaction was committed. To guarantee that rollback data is available for as long as possible for such views, the extents of rollback segments are written to sequentially. When the last extent of the rollback segment becomes full, ORACLE continues writing rollback data by wrapping around to the first extent in the segment. A long-running transaction (idle or active) may require a new extent to be allocated for the rollback segment. See Figure 3 - 6, Figure 3 - 7, and Figure 3 - 8 for more information about how transactions use the extents of a rollback segment.

Each rollback segment can handle a certain number of transactions from one instance. That number is an operating system specific function of the data block size; see your installation or user's guide for information. Unless transactions are explicitly assigned to particular rollback segments by the user, ORACLE distributes active transactions across available rollback segments so that all rollback segments are assigned approximately the same number of active transactions. Distribution does not depend on the size of available rollback segments. Therefore, in environments where transactions all generate the same amount of rollback information, rollback segments can all be the same size.

 How Extents Are Used and Allocated for Rollback Segments

When a rollback segment is created, storage parameters can be specified to control the allocation of extents for this segment. At least two extents are allocated for each rollback segment.

A transaction writes sequentially to a single rollback segment. Each transaction writes to only one extent of the rollback segment at any given time. Furthermore, many active transactions (transactions in progress, not committed or rolled back) can concurrently write to a single rollback segment, even the same extent of a rollback segment; however, each block in a rollback segment's extent can contain information for a single transaction only.

When a transaction runs out of space in the current extent and needs to continue writing, ORACLE must find an available extent of the same rollback segment in which to write. ORACLE has two options:

•	It can reuse an extent already allocated to the rollback segment.

•	It can acquire (and allocate) a new extent for the rollback segment.

The first transaction that needs to acquire more rollback space checks the next extent of the rollback segment. If the next extent of the rollback segment does not contain active undo information, ORACLE makes it the current extent, and all transactions that need more space from then on can write rollback information to the new current extent. Figure 3 - 6  illustrates two transactions, T1 and T2, which continue writing from the third extent to the fourth extent of a rollback segment.

As the transactions continue writing and fill up the current extent, the next extent already allocated for the rollback segment is checked for availability. In Figure 3 - 7, when E4 is completely full, T1 and T2 continue any further writing to the next extent allocated for the rollback segment that is available; in this figure, E1 is this extent. This figure shows the cyclical nature of extent use in rollback segments.

To continue writing rollback information for a transaction, ORACLE always tries to reuse the next extent in the ring first. However, if the next extent contains active data, then ORACLE must allocate a new extent. ORACLE can allocate new extents for a rollback segment until the number of extents reaches the value set for the rollback segment's storage parameter MAXEXTENTS.

Figure 3 - 8 illustrates when a new extent must be allocated for a rollback segment. The uncommitted transactions are long running (either idle, active, or persistent in-doubt distributed transactions). At this time, they are writing to the fourth extent, E4, in the rollback segment. However, when E4 is completely full, the transactions cannot continue any further writing to the next extent already allocated for the rollback segment, E1, because it contains active rollback entries. Therefore, ORACLE allocates a new extent, E5, for this rollback segment and the transactions continue any writing to this new extent.

How Extents Are Deallocated from a Rollback Segment

When a rollback segment is created or altered, the storage parameter OPTIMAL, which applies only to rollback segments, can be used to specify the optimal size of the rollback segment, in bytes. If a transaction needs to continue writing rollback information from one extent to another extent in the rollback segment, ORACLE compares the current size of the rollback segment to the segment's optimal size. If the rollback segment is larger than its optimal size and the extents immediately following the extent just filled are inactive, ORACLE deallocates consecutive non-active extents from the rollback segment until the total size of the rollback segment is equal to or as close to but not less than its optimal size. ORACLE always frees the oldest inactive extents, as these are the least likely to be used by consistent reads. A rollback segment's OPTIMAL setting cannot be less than the combined space allocated for the minimum number of extents for the segment:

(INITIAL + NEXT + NEXT + ... up to MINEXTENTS) bytes

When a rollback segment is dropped, all extents of the rollback segment are returned to its tablespace. The returned extents are then available to other segments in the tablespace.

 Instances and Types of Rollback Segments

When an instance opens a database, it must acquire one or more rollback segments so that the instance can handle rollback information produced by subsequent transactions. An instance can acquire both private or public rollback segments. A private rollback segment is one that is explicitly acquired by an instance when the instance opens a database. Public rollback segments form a pool of rollback segments that can be used by any instance requiring a rollback segment.

Any number of private and public rollback segments can exist in a database. As an instance opens a database, the instance attempts to acquire one or more rollback segments according to the following rules:

•	An instance must acquire at least one rollback segment. If the instance is the only one accessing the database, it acquires the SYSTEM segment; if the instance is one of several accessing the database, it acquires the SYSTEM rollback segment and at least one other rollback segment. If it cannot, an error is returned and the instance cannot open the database.

•	The instance first tries to acquire all private rollback segments specified by the instance's ROLLBACK_SEGMENTS parameter. If one instance opens a database and attempts to acquire a private rollback segment already claimed by another instance, the second instance trying to acquire the rollback segment receives an error during startup. An error is also returned if an instance attempts to acquire a private rollback segment that does not exist.

•	An instance always attempts to acquire at least the number of rollback segments equal to the quotient of the values for the following initialization parameters:

CEIL(TRANSACTIONS/TRANSACTIONS_PER_ROLLBACK_SEGMENT)

•	If an instance has already acquired a sufficient number of private rollback segments in Step 2, no further action is required. However, if more rollback segments are required, the instance attempts to acquire public rollback segments. (An instance can open the database even if the instance cannot acquire the number of rollback segments given by the division above.)

Note: The TRANSACTIONS_PER_ROLLBACK_SEGMENT parameter does not limit the number of transactions that can use a rollback segment. Rather, it determines the number of rollback segments to acquire when an instance opens a database.

Once a public rollback segment has been claimed by an instance, it cannot be used by any other instance until either the rollback segment is taken offline or the instance that claimed the rollback segment is shut down.

Note: A database used by the ORACLE Parallel Server can have only public segments (and no private segments), as long as the number of segments in the database is high enough to assure that each instance that opens the database can acquire at least one rollback segment in addition to the SYSTEM rollback segment (see the next section). However, when using the ORACLE Parallel Server, it may be useful to use private rollback segments. See the ORACLE7 Parallel Server Administrator's Guide for more information about rollback segment use in such systems.

 The Rollback Segment SYSTEM

An initial rollback segment called SYSTEM is created when a database is created. This initial segment is created in the SYSTEM tablespace, using the default storage parameters associated with that tablespace. The rollback segment SYSTEM can never be dropped. An instance always acquires the SYSTEM rollback segment in addition to any other rollback segments it needs.

If there are multiple rollback segments, ORACLE tries to use the SYSTEM rollback segment only for special system transactions and distributes user transactions among other rollback segments; if there are too many transactions for the non-SYSTEM rollback segments, ORACLE uses the SYSTEM segment as necessary. In general, after database creation, at least one additional rollback segment should be created in the SYSTEM tablespace.

 Rollback Segment States

A rollback segment is always in one of several states, depending on whether it is offline, acquired by an instance, involved in an unresolved transaction, in need of recovery, or dropped. The state of the rollback segment determines whether it can be used in transactions, as well as which administrative procedures a DBA can perform on the segment.

The rollback segment states are the following:

OFFLINE	has not been acquired (brought online) by any instance

ONLINE	has been acquired (brought online) by an instance; may contain data from active transactions

NEEDS RECOVERY	contains data from uncommitted transactions that cannot be rolled back (because the data files involved are inaccessible), or is corrupted

PARTLY AVAILABLE	contains data from an in-doubt transaction (that is, an unresolved distributed transaction)

INVALID	has been dropped (The space once allocated to this rollback segment will later be used when a new rollback segment is created.)

Figure 3 - 9 shows how a rollback segment moves from one state to another.

PARTLY AVAILABLE and NEEDS RECOVERY Rollback Segments      The PARTLY AVAILABLE and NEEDS RECOVERY states are very similar: a rollback segment in either state usually contains data from an unresolved transaction. The differences between the two states are the following:

•	A PARTLY AVAILABLE rollback segment is being used by an in-doubt distributed transaction, which cannot be resolved because of a network failure. A NEEDS RECOVERY rollback segment is being used by a transaction (local or distributed) that cannot be resolved because of a local media failure, such as a missing or corrupted data file, or is itself corrupted.

•	ORACLE or a DBA can bring a PARTLY AVAILABLE rollback segment online. In contrast, a NEEDS RECOVERY rollback segment must be taken OFFLINE before it can be brought online. (If the database is recovered and thereby resolves the transaction, ORACLE automatically changes the state of the NEEDS RECOVERY rollback segment to OFFLINE.)

•	A DBA can drop a NEEDS RECOVERY rollback segment. (This allows the DBA to drop corrupted segments.) A PARTLY AVAILABLE segment cannot be dropped; the in-doubt transaction must first be resolved, either automatically by the RECO process or manually by the DBA. (See Chapter 22 for information about failures in distributed transactions.)

If a PARTLY AVAILABLE rollback segment is brought online (by a DBA or during instance startup), ORACLE can use it for new transactions. However, some of its transaction table entries are still held by the in-doubt transaction, so the number of new transactions that can use the rollback segment is limited. (See "When Rollback Information Is Required" on page 3 - 15 for information on the transaction table.)

Also, until the in-doubt transaction is resolved, the transaction continues to hold the extents it acquired in the rollback segment, preventing other transactions from using them; thus, the rollback segment might need to acquire new extents for the active transactions, and therefore grow. To prevent the rollback segment from growing, a DBA might prefer to create a new rollback segment for transactions to use until the in-doubt transaction is resolved, rather than bring the PARTLY AVAILABLE segment online.

Viewing the State of a Rollback Segment      The data dictionary table DBA_ROLLBACK_SEGS lists the status (state) of each rollback segment, along with other rollback segment information.

 Deferred Rollback Segments

When a tablespace goes offline such that transactions cannot be rolled back immediately, ORACLE writes a deferred rollback segment. The deferred rollback segment contains the rollback entries that could not be applied to the tablespace, so they can be applied when the tablespace comes back online. These segments disappear when the tablespaces are brought back online and recovered. Deferred rollback segments are automatically created in the SYSTEM tablespace.

________________________________________

Temporary Segments

When processing queries, ORACLE often requires temporary workspace for intermediate stages of SQL statement processing. This disk space, called a temporary segment, is automatically allocated by ORACLE. Typically a temporary segment is required as a work area for sorting. A segment is not created if the sorting operation can be done in memory, or if ORACLE finds some other way to perform the operation using indexes.

Operations Requiring Temporary Segments

SQL statements with the following commands may require the use of a temporary segment:

•	CREATE INDEX

•	SELECT ... ORDER BY

•	SELECT DISTINCT ...

•	SELECT ... GROUP BY

•	SELECT ... UNION

•	SELECT ... INTERSECT

•	SELECT ... MINUS

•	un-indexed joins

•	certain correlated subqueries

For example, if a query contains a DISTINCT clause, a GROUP BY, and an ORDER BY, as many as two temporary segments could be required. If applications often issue statements in the list above, the database administrator can adjust the initialization parameter SORT_AREA_SIZE.

How Temporary Segments Are Allocated

Temporary segments are allocated as needed during a user session. For example, a user might issue a query that requires three temporary segments to be allocated. Temporary segments are dropped when the statement completes. The storage characteristics for the extents of the temporary segment are determined by the defaults of the tablespace in which the temporary segment is created.

Temporary segments are created in the user's temporary tablespace (the user issuing the statement), as specified for the user via the CREATE USER or ALTER USER commands with the TEMPORARY TABLESPACE option. The SYSTEM tablespace is the default temporary tablespace if no temporary tablespace has been explicitly specified for a user. For more information about assigning a user's temporary segment tablespace, refer to Chapter 17.

Because allocation and deallocation of temporary segments occur frequently, it is reasonable to create a special tablespace for temporary segments. By doing so, you can distribute I/O across disk devices and you may avoid fragmentation of the SYSTEM and other tablespaces that would otherwise hold temporary segments.

The redo log does not contain any entries for changes made to temporary segments.


CHAPTER 4. TABLESPACES AND DATA FILES

Let Rome in Tiber melt, and the wide arch

 Of the ranged empire fall! Here is my space.

Shakespeare:  Antony and Cleopatra

This chapter describes tablespaces, the primary logical storage structures of any ORACLE database, and the physical data files that correspond to each tablespace. Topics include:

•	tablespaces

•	the relationship among databases, tablespaces and data files

•	the SYSTEM tablespace

•	the use of multiple tablespaces

•	data files

•	the relationship between data files and tablespaces

•	the limits concerning data files

If you are using Trusted ORACLE, refer to the Trusted ORACLE7 Server Administrator's Guide for more information about tablespaces and data files in that environment.

________________________________________

An Introduction to Tablespaces and Data Files

The usable data of an ORACLE database is logically stored in the tablespaces and physically stored in the data files associated with the corresponding tablespace. Figure 4 - 1 illustrates this relationship.

Although databases, tablespaces, data files, and segments are closely related, they have important differences:

databases and tablespaces	An ORACLE database is comprised of one or more logical storage units called tablespaces. The database's data is collectively stored in the database's tablespaces.

tablespaces and data files	Each tablespace in an ORACLE database is comprised of one or more operating system files called data files. A tablespace's data files physically store the associated database data on disk.

databases and data files	A database's data is collectively stored in the data files that constitute each tablespace of the database. For example, the simplest ORACLE database would have one tablespace, with one data file. A more complicated database might have three tablespaces, each comprised of two data files (for a total of six data files).

schema objects, segments, and tablespaces	When a schema object such as a table or index is created, its segment is created within a designated tablespace in the database. For example, suppose a table is created in a specific tablespace using the CREATE TABLE command with the TABLESPACE option. The space for this table's data segment is allocated in one or more of the data files that constitute the specified tablespace. An object's segment allocates space in only one tablespace of a database. (See Chapter 3 for more information about extents and segments and how they relate to tablespaces.)

The following sections further explain tablespaces and data files.

________________________________________

Tablespaces

A database is divided into one or more logical storage units called tablespaces. A database administrator can use tablespaces to do the following:

•	Control disk space allocation for database data.

•	Assign specific space quotas for database users.

•	Control availability of data by taking individual tablespaces online or offline.

•	Perform partial database backup or recovery operations.

•	Allocate data storage across devices to improve performance.

A database administrator can create new tablespaces, add and remove data files from tablespaces, set and alter default segment storage settings for segments created in a tablespace, and drop tablespaces.

The SYSTEM Tablespace

Every ORACLE database contains a tablespace named SYSTEM, which is automatically created when the database is created. The SYSTEM tablespace always contains the data dictionary tables for the entire database.

A small database might need only the SYSTEM tablespace; however, it is recommended that at least one additional tablespace be created to store user data separate from data dictionary information. This allows you more flexibility in various database administration operations and can reduce contention among dictionary objects and schema objects for the same data files.

The SYSTEM tablespace must always be kept online-it cannot be taken offline. (See "Online and Offline Tablespaces" on page 4 - 5.)

All data stored on behalf of stored PL/SQL program units (procedures, functions, packages and triggers) are stored in the SYSTEM tablespace. If many of these PL/SQL objects are created for a database, the database administrator needs to plan for the space that is used in the SYSTEM tablespace by these objects. (For more information about these objects and the space that they require, see Chapters 14 and 15.)

Allocating More Space for a Database

To enlarge a database, a second data file could be added to one of its existing tablespaces, thereby increasing the amount of disk space allocated for the corresponding tablespace. This kind of space increase is illustrated in Figure 4 - 2 .

Alternatively, a DBA can create a new tablespace (defined by an additional data file) to increase the size of a database. This is illustrated in Figure 4 - 3 .

The size of a tablespace is the size of the data file or combined size of the multiple data files that constitute the tablespace, and the size of a database is the collective size of the tablespaces that constitute the database.

Online and Offline Tablespaces

A database administrator can bring any tablespace in an ORACLE database online (made available) or offline (made unavailable) whenever the database is open. The only exception is that the SYSTEM tablespace must always be online because the data dictionary must always be available to ORACLE.

A tablespace is normally online so that the data contained within it is available to database users. However, the database administrator might wish to take a tablespace offline for any of the following reasons:

•	to make a portion of the database unavailable, while allowing normal access to the remainder of the database

•	to perform an offline tablespace backup (although a tablespace can be backed up while online and in use)

•	to make an application and its group of tables temporarily unavailable while updating or maintaining the application

When a tablespace is offline, ORACLE does not permit any subsequent SQL statements to reference objects contained in the tablespace. Active transactions with completed statements that reference data in a tablespace that has been taken offline are not affected at the transaction level; however, rollback data corresponding to statements that affect data in the offline tablespace is saved in a deferred rollback segment (in the SYSTEM tablespace) and applied to the tablespace, if necessary, when the tablespace is brought back online.

A tablespace cannot be taken offline if it contains any rollback segments that are active. Only when all rollback segments in a tablespace are not being used can the tablespace be taken offline.

The data dictionary in the SYSTEM tablespace records whether a tablespace is offline or online. If a tablespace was offline when a database was shut down, the tablespace is offline when the database is subsequently mounted and reopened.

A tablespace can be brought online only by the database that took it offline, because the necessary data dictionary information is maintained in the SYSTEM tablespace of that database. An offline tablespace cannot be read or edited by any utility other than ORACLE. Thus, tablespaces cannot be transferred from database to database.

A tablespace can be automatically changed from online to offline when certain errors are encountered (e.g., when the database writer process, DBWR, fails in several attempts to write to a data file of the tablespace). Users trying to access tables in the tablespace with the problem receive an error. If the problem that causes this disk I/O to fail is a case of media failure, the tablespace must be recovered after the hardware problem is corrected.

By using multiple tablespaces to separate different types of data, the database administrator can also take specific tablespaces offline for certain procedures, while other database tablespaces remain online and the information in them is still available for use. However, special circumstances can occur when tablespaces are taken offline. For example, if two tablespaces are used to separate table data from index data, the following is true:

•	If the tablespace containing the indexes is offline, queries can still access table data, because queries do not require an index to access the table data.

•	If the tablespace containing the tables is offline, the table data in the database is not accessible because the tables are required to access the data.

In summary, if ORACLE determines that it has enough information in the online tablespaces to execute a statement, it will do so. If it needs data in an offline tablespace, then it causes the statement to fail.

________________________________________

Data Files

A tablespace in an ORACLE database consists of one or more physical data files. The data files associated with a tablespace store all the database data in that tablespace. One or more data files form a logical unit of database storage called a tablespace. A data file can be associated with only one tablespace, and only one database.

When a data file is created for a tablespace, ORACLE creates the file by allocating the specified amount of disk space. When a data file is created, the operating system is responsible for clearing old information and authorizations from a file before allocating it to ORACLE. If the file is large, this process might take a significant amount of time.

Since the first tablespace in any database is always the SYSTEM tablespace, the first data files of any database are automatically allocated for the SYSTEM tablespace during database creation.

Data File Contents

After a data file is initially created, the allocated disk space does not contain any data; however, the space is reserved to hold only the data for future segments of the associated tablespace-it cannot store any other program's data. As a segment (such as the data segment for a table) is created and grows in a tablespace, ORACLE uses the free space in the associated data files to allocate extents for the segment.

The data in the segments of objects (data segments, index segments, rollback segments, and so on) in a tablespace are physically stored in one or more of the data files that constitute the tablespace. Note that a schema object does not correspond to a specific data file; rather, a data file is a repository for the data of any object within a specific tablespace. The extents of a single segment can be allocated in one or more data files of a tablespace; therefore, an object can "span" one or more data files. Unless table "striping" is used, the database administrator and end-users cannot control which data file stores an object.

Offline Data Files

Tablespaces can be taken offline (made unavailable) or brought online (made available) at any time. Therefore, all data files making up a tablespace are taken offline or brought online as a unit when the tablespace is taken offline or brought online, respectively. Individual data files can also be taken offline; however, this is normally done only during certain database recovery procedures.


CHAPTER 5. SCHEMA OBJECTS

Whoever tries for great objects must suffer something.

Plutarch

This chapter discusses the different types of objects contained in a user's schema. Topics include:

•	the different types of schema objects, including tables, views, sequences, synonyms, indexes, and clusters

•	the relationship among schema objects, tablespaces, and data files

•	the storage format of tables, indexes, and clusters

•	name resolution when referencing schema objects in SQL statements

Procedures, functions, and packages are discussed in Chapter 14, database triggers in Chapter 15, and snapshots are covered in Chapter 21.

If you are using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide for additional information.

________________________________________

Schema Objects

Associated with each database user is a schema. A schema is a collection of schema objects. Examples of schema objects include tables, views, sequences, synonyms, indexes, clusters, database links, procedures, and packages. This chapter explains tables, views, sequences, synonyms, indexes, and clusters.

Schema objects are logical data storage structures. Each schema object does not have a corresponding physical file on disk that stores its information. However, a schema object is logically stored within a tablespace of the database. The data of each object is physically contained in one or more of the tablespace's data files. For some objects such as tables, indexes, and clusters, you can specify how much disk space is allocated for the object within the tablespace's data files. Figure 5 - 1 illustrates the relationship among objects, tablespaces, and data files.

There is no relationship between schemas and tablespaces: a tablespace can contain objects from different schemas, and the objects for a schema can be contained in different tablespaces.

________________________________________

Tables

Tables are the basic unit of data storage in an ORACLE database. Data is stored in rows and columns. Every table is defined with a table name (such as EMP) and set of columns. Each column is given a column name (such as EMPNO, ENAME, and JOB), a datatype (such as VARCHAR2, DATE, or NUMBER), and a width (the width might be predetermined by the datatype, as in DATE) or precision and scale (for columns of the NUMBER datatype only). A row is a collection of column information corresponding to a single record.

Note: See Chapter 6 for a discussion of the ORACLE datatypes.

You can optionally specify rules for each column of a table. These rules are called integrity constraints. One example is a NOT NULL integrity constraint defined on a column of a table. This type of integrity constraint enforces the rule that the column cannot contain a null. (Integrity constraints are discussed in Chapter 7.)

Once you create a table, rows of data can be inserted into it using SQL statements. This table information can then be queried, deleted, or updated using SQL.

Figure 5 - 2  shows a table named EMP.

How Table Data Is Stored

When creating a non-clustered table, a data segment is automatically allocated in a tablespace to hold the table's future data. You can control the allocation of space for a table's data segment and use of this reserved space in the following ways:

•	You can control the amount of space of the data segment's extents by setting the storage parameters for the data segment.

•	You can control the use of the free space in the data blocks that constitute the data segment's extents by setting the PCTFREE and PCTUSED parameters for the data segment.

Data for a clustered table is stored in the data segment created for the associated cluster. Storage parameters cannot be specified when a clustered table is created or altered; the storage parameters set for the cluster always control the storage of all tables in the cluster.

The tablespace that contains a non-clustered table's data segment is either the table owner's default tablespace or a tablespace specifically named in the CREATE TABLE statement. (See "User Tablespace Settings and Quotas" on page 17 - 4.)

Row Format and Size

Each row of a database table is stored as one or more row pieces. If an entire row can be inserted into a single data block, the row is initially stored as one row piece. However, if all of a row's data cannot be inserted into a single data block or an update to an existing row causes the row to outgrow its data block, the row is stored using multiple row pieces. A data block usually contains only one row piece per row; all parts of a row that fit into a given block are stored in one row piece within the block. When a row must be stored in more than one row piece, the row is said to be "chained" because one row's pieces are chained to other data blocks. If a row is chained, the row pieces are chained together using the ROWIDs of the pieces. (See "Row Chaining Across Data Blocks" on page 3 - 9.)

Each row piece, chained or unchained, contains a row header and data for all or some of the row's columns. Individual columns might also span row pieces and, consequently, data blocks. Figure 5 - 3 shows the format of a row piece.

The row header precedes the data, and contains information such as:

•	row piece information

•	for chained row pieces, chaining information

•	information about the columns in the row piece

•	for clustered data, cluster key information

A non-clustered row fully contained in one block has at least three bytes of row header. After the row header information, each row contains column information and data. The column length requires one byte for columns that store 250 bytes or less, or three bytes for columns that store more than 250 bytes, and precedes the column data. Space required for column data depends on the datatype. If the datatype of a column is variable length, the space required to hold a value can grow and shrink with updates to the data.

To conserve space, a row that contains a null only stores the column length (zero) and no data for the null column.

Note: Each row uses two bytes in the data block header's row directory.

Clustered rows contain the same information as non-clustered rows. In addition, they contain information that references the cluster key they belong to. (See "Clusters" on page 5 - 18.)

 Column Order

The column order is the same for all rows in a given table. Columns are usually stored in the order in which they were listed in the CREATE TABLE statement, but are not guaranteed to be. For example, if you create a table with a column of datatype LONG, ORACLE always stores this column last. Also, if a table is altered so that a new column is added, the new column becomes the last column to be stored.

In general, you should try to make columns that frequently contain nulls last, so that rows take less space. Note, though, that if the table you are creating includes a LONG column as well, the benefits of putting frequently-null columns last are lost.

 ROWIDs of Row Pieces

Each row piece is identified by its location or address, called the ROWID. Once assigned, a given row piece retains its ROWID until the corresponding row is deleted, or exported and imported using the IMPORT and EXPORT utilities. If the cluster key values of a row change, the row keeps the same ROWID, but also gets an additional pointer ROWID for the new values.

Because ROWIDs are constant for the lifetime of a row piece, ROWIDs can be referenced in SQL statements and can be useful in SELECT, UPDATE, and DELETE statements. (See "ROWIDs and the ROWID Datatype" on page 6 - 8.)

Nulls

A null is the absence of a value in a column of a row. Nulls indicate missing, unknown, or inapplicable data. A null should not be used to imply any other value, such as zero. A column allows nulls unless a NOT NULL integrity constraint has been defined for the column, in which case no row can be inserted without a value for that column.

Nulls are stored in the database if they fall between columns with data values. In these cases they require one byte. Trailing nulls in a row require no storage. In tables with many columns, the columns more likely to contain nulls should be defined last to conserve disk space.

Nulls are identified in SQL using the IS NULL predicate. The SQL function NVL can be used to convert nulls to non-null values. (For more information about comparisons using IS NULL and the NVL function, see the ORACLE7 Server SQL Language Reference Manual.)

Nulls are not indexed, except when cluster key column value is null.

Default Values for Columns

A column of a table can be assigned a default value so that when a new row is inserted and a value for the column is omitted, a default value is automatically supplied. Default column values work as though an INSERT statement actually specifies the default value.

Legal default values include any literal, or expression that does not refer to a column, LEVEL, ROWNUM, or PRIOR. Default values can include the functions SYSDATE, USER, USERENV, and UID. The datatype of the default literal or expression must match or be convertible to the column datatype.

If a default value is not explicitly defined for a column, the default for the column is implicitly set to NULL.

 When Default Values Are Inserted Relative to Integrity Constraint Checking

Integrity constraint checking occurs after the row with a default value is inserted. For example, in Figure 5 - 4, a row is inserted into the EMP table that does not include a value for the employee's department number. Because no value is supplied for the employee's department number, the DEPTNO column's default value "20" is supplied. After the default value is supplied, the FOREIGN KEY integrity constraint defined on the DEPTNO column is checked.

________________________________________

Views

A view is a tailored presentation of the data contained in one or more tables (or other views). A view is defined using a query, and can thus be thought of as a "stored query" or a "virtual table." Views can be used in most places where a table can be used.

For example, the EMP table has several columns and numerous rows of information. If you only want users to see five of these columns, or only specific rows, you can create a view of that table for other users to access. Figure 5 - 5  shows an example of a view called STAFF derived from the base table EMP. Notice that the view shows only five of the columns in the base table.

Since views are derived from tables, many similarities exist between the two. For example, views can be defined with up to 254 columns, just like a table. Views can be queried, and with some restrictions (see the ORACLE 7 Server SQL Language Reference Manual), users can update, insert into, and delete from views. All operations performed on a view actually affect data in the base tables of the view and are subject to the integrity constraints and triggers of the base tables.

Note: Integrity constraints and triggers cannot be defined explicitly for views, but can be defined for the underlying base tables referenced by the view.

Storage for Views

Unlike a table, a view is not allocated any storage space (like a table), nor does a view actually contain data; rather, a view is defined by a query that corresponds to data from the tables the view references. These tables are called base tables. Base tables can in turn be actual tables or can be views themselves (including snapshots). Because a view is based on other objects, a view requires no storage other than storage for the definition of the view (the stored query) in the data dictionary.

How Views Are Used

Views provide a means to present a different representation of the data that resides within the base tables. Views are very powerful because they allow you to tailor the presentation of data to different types of users. Views are often used:

•	to provide an additional level of table security by restricting access to a predetermined set of rows and/or columns of a table. For example, Figure 5 - 5  shows how the STAFF view does not show the SAL or COMM columns of the EMP table.

•	to hide data complexity. For example, a single view might be defined with a join, which is a collection of related columns or rows in multiple tables. However, the view hides the fact that this information actually originates from several tables.

•	to simplify commands for the user. For example, views allow users to select information from multiple tables without actually knowing how to perform a join.

•	to present the data in a different perspective from that of the base table. For example, the columns of a view can be renamed without affecting the tables on which the view is based.

•	to isolate applications from changes in definitions of base tables. For example, if a view's defining query references three columns of a four column table and a fifth column is added to the table, the view's definition is not affected and all applications using the view are not affected.

•	to express a query that cannot be expressed without using a view. For example, a view can be defined that joins a GROUP BY view with a table, or a view can be defined that joins a UNION view with a table.

•	to save complex queries. For example, a query could perform extensive calculations with table information. By saving this query as a view, the calculations can be performed each time the view is queried.

The Mechanics of Views

A view's definition is represented by storing in the data dictionary the text of the query that defines the view. When a view is referenced in a SQL statement, ORACLE merges the statement that references the view with the query that defines the view, and then parses the merged statement in a shared SQL area and executes it. A statement that references a view is parsed in a new shared SQL area only if no existing shared SQL area contains an identical statement. Therefore, the same benefit of reduced memory usage associated with shared SQL is observed with the use of views.

In evaluating views containing string literals or SQL functions that have NLS parameters as arguments (such as TO_CHAR, TO_DATE, and TO_NUMBER), ORACLE takes default values for these parameters from the NLS parameters for the session. The view creator can override these default values by specifying NLS parameters explicitly in the view definition.

Whether ORACLE uses indexes for a query against a view is determined by how ORACLE transforms the original query when merging it with the view's defining query. Consider the view:

CREATE VIEW emp_view AS

SELECT empno, ename, sal, loc

FROM emp, dept

WHERE emp.deptno = dept.deptno AND dept.deptno = 10;

Now consider the following user-issued query:

SELECT ename

FROM emp_view

WHERE empno = 9876;

The final query constructed by ORACLE is:

SELECT ename

FROM emp, dept

WHERE emp.deptno = dept.deptno AND

      dept.deptno = 10 AND

      emp.empno = 9876;

In all cases where possible, ORACLE merges a query against a view with the view's defining query (and those of the underlying views). The merged query is optimized just as if the query were issued without referencing the views. Therefore, indexes on any referenced base table columns can be used, whether the columns are referenced in the view definition or the user query against the view.

In some cases, it is not possible to merge the view definition with the user-issued query. In such cases, not all indexes on referenced columns can be used.

Dependencies and Views

Because a view is defined by a query that references other objects (tables, snapshots, or other views), a view is dependent on the objects referenced in its defining query. ORACLE automatically handles the dependencies for views. For example, if a base table of a view is dropped and then recreated, ORACLE determines whether or not the new base table is acceptable to the existing definition of the view. (See Chapter 16 for a complete discussion of dependencies in a database.)

________________________________________

The Sequence Generator

The sequence generator generates sequential numbers. The sequence generator is especially useful in multi-user environments to generate and return unique sequential numbers without the overhead of disk I/O or transaction locking. Therefore, the sequence generator reduces "serialization" where the statements of two transactions must generate sequential numbers at the same time. By avoiding the serialization that results when multiple users wait for each other to generate and use a sequence number, transaction throughput is improved and a user's wait is considerably shorter.

Sequence numbers are ORACLE integers of up to 38 digits. Sequence numbers are defined in the database. A sequence definition indicates general information: the name of the sequence, whether it ascends or descends, the interval between numbers, and other information. One important part of a sequence's definition is whether or not sets of generated sequence numbers are to be cached in memory. The definitions of all sequences for a particular database are stored as rows in a single data dictionary table in the SYSTEM tablespace; therefore, all sequence definitions are always available, because the SYSTEM tablespace is always online.

Sequence numbers are used by SQL statements that reference the sequence. Statements can be issued such that they generate a new sequence number or use the current sequence number. Once a statement in a user's session generates a sequence number, the particular sequence number is available only to that session; each user that references a sequence has access to its own, current sequence number.

Sequence numbers are generated independently of tables. Therefore, the same sequence generator can be used for one or for multiple tables. Sequence number generation is useful to automatically generate unique primary keys for your data and to coordinate keys across multiple rows or tables. Individual sequence numbers can be skipped if they were generated and used in a transaction that was ultimately rolled back. Applications can make provisions to catch and reuse these sequence numbers, if desired.

See the ORACLE7 Server Application Developer's Guide for additional performance implications when using sequences.

________________________________________

Synonyms

A synonym is an alias for any table, view, snapshot, sequence, procedure, function, or package. Because a synonym is simply an alias, it requires no storage other than its definition in the data dictionary.

Synonyms are often used for security and convenience. For example, they can do the following:

•	mask the name and owner of an object

•	provide location transparency for remote objects of a distributed database

•	simplify SQL statements for database users

Both public and private synonyms can be created. A public synonym is owned by the special user group named PUBLIC and is accessible to every user in a database. A private synonym is contained in the schema of a specific user and available only to the user and the user's grantees.

Synonyms are very useful in both distributed and non-distributed database environments because they hide the identity of the underlying object, including its location in a distributed system. This is advantageous because if the underlying object must be renamed or moved, only the synonym needs to be redefined and applications based on the synonym continue to function without modification.

Synonyms can also simplify SQL statements for users in a distributed database system. The following example shows how and why public synonyms are often created by a database administrator to hide the identity of a base table and reduce the complexity of SQL statements. Assume the following:

•	There is a table called SALES_DATA, contained in the schema owned by the user named JWARD.

•	The SELECT privilege for the SALES_DATA table is granted

 to PUBLIC.

At this point, a user of the database would have to query the table SALES_DATA with a SQL statement similar to the one below:

SELECT * FROM jward.sales_data;

Notice how it is necessary to include both the schema that contains the table along with the table name to perform the query.

Assume that the database administrator creates a public synonym with the following SQL statement:

CREATE PUBLIC SYNONYM sales FOR jward.sales_data;

After the public synonym is created, a user is able to query the table SALES_DATA with a simple SQL statement:

SELECT * FROM sales;

Notice that the public synonym SALES hides the name of the table SALES_DATA and the name of the schema that contains the table.

________________________________________

Indexes

Indexes are optional structures associated with tables and clusters. You can create indexes explicitly to speed SQL statement execution on a table. Just as the index in this Manual helps you locate information faster than if there were no index, an ORACLE index provides a faster access path to table data. Properly used, indexes are the primary means of reducing disk I/O.

The absence or presence of an index does not require a change in the wording of any SQL statement. An index is merely a fast access path to the data; it affects only the speed of execution. Given a data value that has been indexed, the index points directly to the location of the rows containing that value.

Indexes are logically and physically independent of the data in the associated table. They can be created or dropped anytime without any effect on the base tables or other indexes. If an index is dropped, all applications continue to work; however, access of previously indexed data might be slower. Indexes, as independent structures, do require storage space.

Once created, an index is automatically maintained and used by ORACLE. Changes to data, such as adding new rows, updating rows, or deleting rows, are automatically reflected in all relevant indexes with no additional action by users.

Retrieval performance of indexed data remains almost constant, even as new rows are inserted. However, the presence of many indexes on a table decreases the performance of updates, deletes, and inserts since the indexes associated with the table must also be updated.

Unique and Non-Unique Indexes

Indexes can be unique or non-unique. Unique indexes guarantee that no two rows of a table have duplicate values in the columns that define the index. Non-unique indexes do not impose this restriction on the column values.

Although it is possible, it is recommended that unique indexes not be explicitly defined in tables of an ORACLE database; uniqueness is strictly a logical concept and should be associated with the definition of a table. Alternatively, UNIQUE integrity constraints should be defined on the desired columns. ORACLE enforces UNIQUE integrity constraints by automatically defining a unique index on the unique key.

Composite Indexes

A composite index (also called a concatenated index) is an index that is created on multiple columns in a table. Columns in a composite index can appear in any order and need not be adjacent in the table.

Composite indexes can speed retrieval of data for SELECT statements in which the WHERE clause references all or the leading portion of the columns in the composite index. Therefore, some thought should be given to the order of the columns used in the definition; generally the most commonly accessed or most selective columns go first. (See the ORACLE7 Server Application Developer's Guide for more information.)

Figure 5 - 6  illustrates the VENDOR_PARTS table that has a composite index on the VENDOR_ID and PART_NO columns.

Indexes and Keys

Although the terms are often used interchangeably, a distinction should be made between "indexes" and "keys." Indexes are structures actually stored in the database, which users create, alter, and drop using SQL statements. You create an index to provide a fast access path to table data. Keys are strictly a logical concept. Keys correspond to another feature of ORACLE called integrity constraints. Integrity constraints enforce the business rules of a database; see Chapter 7. Because some integrity constraints are enforced by indexes, the terms key and index are often are used interchangeably; however, they should not be confused with each other.

How Indexes Are Stored

When an index is created, an index segment to hold the index's data is automatically allocated in a tablespace. Allocation of space for an index's segment and use of this reserved space can be controlled in the following ways:

•	The allocation of the index segment's extents can be controlled by setting the storage parameters for the index segment.

•	The free space in the data blocks that constitute the index segment's extents can be controlled by setting the PCTFREE parameter for the index segment.

The tablespace of an index's segment is either the owner's default tablespace or a tablespace specifically named in the CREATE INDEX statement. An index does not have to be in the same tablespace as its associated table. Furthermore, performance of queries that use an index can be improved by storing an index and its table in different tablespaces located on different disk drives because both index and table data can be retrieved in parallel. (See "User Tablespace Settings and Quotas" on page 17 - 4.)

 Format of Index Blocks

Space available for index data is the ORACLE block size minus block overhead, entry overhead, ROWID, and one length byte per value indexed. The number of bytes required for the overhead of an index block is operating system dependent; see your installation or user's guide for more information.

When an index is created, the columns to be indexed are fetched and sorted, and the ROWID is stored along with the index value for each row. Then the index is loaded from the bottom up. For example, consider the statement:

CREATE INDEX emp_ename ON emp(ename);

ORACLE sorts on ENAME for all EMP's rows and loads the index with the ENAME and ROWID values for each row in the EMP table. Though ORACLE accepts the keywords ASC, DESC, COMPRESS, and NOCOMPRESS in the CREATE INDEX command, they have no effect on index data, which is stored using rear compression in the branch nodes but not in the leaf nodes.

 The Internal Structure of Indexes

ORACLE uses B*-tree indexes that are balanced in order to equalize access times to any row. The theory of B*-tree indexes is beyond the scope of this Manual; for more information you can refer to computer science texts dealing with data structures. Figure 5 - 7 illustrates the structure of a B*-tree index.

The upper blocks (branch blocks) of a B*-tree index contain index data that points to lower-level index blocks. The lowest level index blocks (leaf blocks) contain every indexed data value and a corresponding ROWID used to locate the actual row; the leaf blocks are doubly-linked. Indexes in columns containing character data are based on the binary values of the characters in the database character set.

For a unique index, there is one ROWID per data value. For a non-unique index, the ROWID is included in the key in sorted order, so non-unique indexes are sorted by the index key and ROWID. Key values containing all nulls are not indexed, except for cluster indexes. Two rows can both contain all nulls and not violate a unique index.

The B*-tree structure has the following advantages:

•	All leaf blocks of the tree are at the same depth, so retrieval of any record from anywhere in the index takes approximately the same amount of time.

•	B*-tree indexes automatically stay balanced.

•	All blocks of the B*-tree are three-quarters full on the average.

•	B*-trees provide excellent retrieval performance for a wide range of queries, including exact match and range searches.

•	Inserts, updates, and deletes are efficient, maintaining key order for fast retrieval.

•	B*-tree performance is good for both small and large tables, and does not degrade as the size of a table grows.

________________________________________

Clusters

Clusters are an optional method of storing table data. A cluster is a group of tables that share the same data blocks because they share common columns and are often used together. For example, the EMP and DEPT table share the DEPTNO column. Because the EMP and DEPT table are clustered (see Figure 5 - 8), all rows for each department from both the EMP and DEPT tables are physically stored in the same data blocks.

Because clusters store related rows of different tables together in the same data blocks, two primary benefits are achieved when clusters are properly used:

•	Disk I/O is reduced and access time improves for joins of clustered tables.

•	In a cluster, a cluster key value is the values of the cluster key columns for a particular row. Each cluster key value is stored only once each in the cluster and the cluster index, no matter how many rows of different tables contain the value. Therefore, less storage might be required to store related table and index data in a cluster than is necessary in non-clustered table format. For example, notice how each cluster key (each DEPTNO) is stored just once for many rows that contain the same value in both the EMP and DEPT tables.

Performance Considerations

Clusters can reduce the performance of INSERT statements as compared with storing a table separately with its own index. These disadvantages relate to the use of space and the number of blocks that must be visited to scan a table; because multiple tables have data in each block, more blocks must be used to store a clustered table than if that table were stored non-clustered.

To identify data that would be better stored in clustered form than non-clustered, look for tables that are related via referential integrity constraints and tables that are frequently accessed together using SELECT statements that join data from two or more tables. If you cluster tables on the columns used to join table data, you reduce the number of data blocks that must be accessed to process the query; all the rows needed for a join on a cluster key are in the same block. Therefore, performance for joins is improved. Similarly, it might be useful to cluster an individual table. For example, the EMP table could be clustered on the DEPTNO column to cluster the rows for employees in the same department. This would be advantageous if applications commonly process rows department by department.

Like indexes, clusters do not affect application design. The existence of a cluster is transparent to users and to applications. Data stored in a clustered table is accessed via SQL just like data stored in a non-clustered table.

See the ORACLE7 Server Application Developer's Guide for additional information about the performance implications of using clusters.

Format of Clustered Data Blocks

In general, clustered data blocks have an identical format to non-clustered data blocks with the addition of data in the table directory. However, all rows that share the same cluster key value are stored in the same data block.

When a cluster is created, the average amount of space required to store all the rows for a cluster key value is specified using the SIZE parameter of the CREATE CLUSTER command. SIZE determines the maximum number of cluster keys that can be stored per data block. For example, if each data block has 1700 bytes of available space and the specified cluster key size is 500 bytes, each data block can potentially hold rows for three cluster keys. If SIZE is greater than the amount of available space per data block, each data block holds rows for only one cluster key value.

Although the maximum number of cluster key values per data block is fixed by SIZE, ORACLE does not actually reserve space for each cluster key value nor does it guarantee the number of cluster keys that are assigned to a block. For example, if SIZE determines that three cluster key values are allowed per data block, rows for one cluster key value can take up all of the available space in the block. If more rows exist for a given key than can fit in a single block, the block is chained, as necessary.

A cluster key value is stored only once in a data block.

The Cluster Key

The cluster key is the column, or group of columns, that the clustered tables have in common. The columns of the cluster key are specified when creating the cluster. The same columns are subsequently specified when creating every table added to the cluster.

For each column specified as part of the cluster key (when creating the cluster), every table created in the cluster must have a column that matches the size and type of the column in the cluster key. No more than 16 columns can form the cluster key and a cluster key value cannot exceed roughly one-third the available data space in a data block. The cluster key cannot include a LONG or LONG RAW column.

The data values in clustered columns of a table can be updated. However, since the placement of data depends on the cluster key, changing the cluster key for a row might cause the physical relocation of the row. Therefore, columns that are updated often are not good candidates for the cluster key.

The Cluster Index

You must create an index on the cluster key columns after you have created a cluster. A cluster index is an index defined specifically for a cluster. Such an index contains an entry for each cluster key value. To locate a row in a cluster, the cluster index is used to find the cluster key value, which points to the data block associated with that cluster key value. Therefore, a given row is accessed with a minimum of two I/Os (possibly more, depending on the number of levels that must be traversed in the index).

A cluster index must be created before any DML statements (including INSERT and SELECT statements) can be executed against the clustered tables. Therefore, data in a clustered table cannot be loaded until the cluster index is created.

Like a table index, a cluster index is created and stored in an index segment. Therefore, a cluster can be stored in one tablespace and the cluster index in a different tablespace.

A cluster index is unlike a table index in the following ways:

•	Keys that are all null have an entry in the cluster index.

•	Index entries point to the first block in the chain for a given cluster key value.

•	A cluster index contains one entry per cluster key value, rather than one entry per cluster row.

•	The absence of a table index does not affect users, but clustered data cannot be accessed unless there is a cluster index.

If a cluster index is dropped, data in the cluster remains but becomes unavailable until a new cluster index is created. You might want to drop a cluster index in order to move the cluster index to another tablespace, or to change its storage characteristics; however, you must recreate the cluster's index to allow access to data in the cluster.

________________________________________

Hashing

Hashing is an optional way of storing table data to improve the performance of data retrieval. To use hashing, you create a hash cluster and load tables into the cluster. The rows of a table in a hash cluster are physically stored and retrieved according to the results of a hash function. A hash function is used to generate a distribution of numeric values, called hash values, which are based on specific cluster key values. The key of a hash cluster (like the key of an index cluster) can be a single column or composite key (multiple column key). To find or store a row in a hash cluster, ORACLE applies the hash function to the row's cluster key value; the resulting hash value corresponds to a data block in the cluster, which ORACLE then reads or writes on behalf of the issued statement.

A hash cluster is an alternative to a non-clustered table with an index or an index cluster. With an indexed table or index cluster, the rows in a table are located using key values which are stored in a separate index. To find or store a row in an indexed table or cluster, at least two I/Os must be performed (but often more): one or more I/Os to find or store the key value in the index, and another I/O to read or write the row in the table or cluster. In contrast, a hash function is used to locate a row in a hash cluster (no I/O is required). As a result, a minimum of one I/O operation is necessary to read or write a row in a hash cluster.

How Data Is Stored in a Hash Cluster

A hash cluster stores related rows together in the same data blocks. Rows in a hash cluster are stored together based on their hash value.

Note: In contrast, an index cluster stores related rows of clustered tables together based on each row's cluster key value.

When a hash cluster is created, an initial amount of storage is allocated for the cluster's data segment. The storage initially allocated for a hash cluster is based on the predicted number and predicted average size of the hash key's rows in the cluster.

Figure 5 - 9 illustrates data retrieval for a table in a hash cluster as well as a table with an index. The following sections further explain the internal operations of hash cluster storage.

Hash Key Values

To find or store a row in a hash cluster, the hash function is applied to the row's cluster key value. The resulting hash value corresponds to a data block in the cluster, which is then read or written on behalf of an issued statement. The number of hash values for a hash cluster is fixed at creation and is determined by the HASHKEYS parameter of the CREATE CLUSTER command. The value of HASHKEYS limits the number of unique hash values that can be generated by the hash function used for the cluster. For example, setting HASHKEYS to 100 means that for any cluster key value, the hash function generates hash values between 0 and 99. Therefore, the distribution of rows in a hash cluster is directly controlled by the value set for the HASHKEYS parameter. With a larger number of hash keys for a given number of rows, the likelihood of a collision (two cluster key values having the same hash value) decreases. Minimizing the number of collisions is important because overflow blocks (thus extra I/O) might be necessary to store rows with cluster key values that collide.

The maximum number of hash keys assigned per data block is determined by the SIZE parameter of the CREATE CLUSTER command. SIZE is an estimate of the total amount of space, in bytes, required to store the average number of rows associated with each hash value. For example, if the available free space per data block is 1700 bytes and SIZE is set to 500 bytes, three hash keys are assigned per data block.

Note: The importance of the SIZE parameter of hash clusters is analogous to that of the SIZE parameter for index clusters. However, with index clusters, SIZE applies to rows with the same cluster key value instead of the same hash value.

Although the maximum number of hash key values per data block is determined by SIZE, ORACLE does not actually reserve space for each hash key value in the block. For example, if SIZE determines that three hash key values are allowed per block, rows for one hash key value can take up all of the available space in the block. If there are more rows for a given hash key value than can fit in a single block, the block is chained, as necessary.

Note that each row's hash value is not stored as part of the row; however, the cluster key value for each row is stored. Therefore, when determining the proper value for SIZE, the cluster key value must be included for every row to be stored.

Hash Functions

A hash function is a function applied to a cluster key value and returns a hash value; the hash value is then used to locate the row in the proper data block of the hash cluster. The job of a hash function is to provide the maximum distribution of rows among the available hash values of the cluster. In order to achieve this goal, a hash function must minimize the number of collisions.

When creating a cluster, you can use the internal hash function of ORACLE or bypass the use of this function. The internal hash function allows the cluster key to be a single column or composite key. Furthermore, the cluster key can be comprised of columns of any datatype (except LONG and LONG RAW). The internal hash function offers sufficient distribution of cluster key values among available hash keys, producing a minimum number of collisions for any type of cluster key.

In cases where the cluster key is already a unique identifier that is uniformly distributed over its range, you might want to bypass the internal hash function and simply specify the column to hash on. Instead of using the internal hash function to generate a hash value, ORACLE checks the cluster key value. If the cluster key value is less than HASHKEYS, the hash value is the cluster key value; however, if the cluster key value is equal to or greater than HASHKEYS, ORACLE divides the cluster key value by the number specified for HASHKEYS, and the remainder is the hash value; the hash value is the cluster key value mod the number of hash keys. The internal hash function is bypassed if the HASH IS parameter is specified in the CREATE CLUSTER command. In this parameter, the cluster key must be specified and the cluster key must be comprised of a single column which contains only zero scale numbers (integers). If the internal hash function is bypassed and a non-integer cluster key value is supplied, the operation (INSERT or UPDATE statement) is rolled back and an error is returned.

Allocation of Space for a Hash Cluster

As with other types of segments, the allocation of extents during the creation of a hash cluster is controlled by the INITIAL, NEXT, and MINEXTENTS parameters of the STORAGE clause. However, with hash clusters, an initial portion of space, called the hash table, is allocated at creation so that all hash keys of the cluster can be mapped, with the total space equal to SIZE * HASHKEYS. Therefore, initial allocation of space for a hash cluster is also dependent on the values of SIZE and HASHKEYS. The larger of (SIZE*HASHKEYS) and that specified by the STORAGE clause (INITIAL, NEXT, etc.) is used.

Space subsequently allocated to a hash cluster is used to hold the overflow of rows from data blocks that are already full. For example, assume the original data block for a given hash key is full. A user inserts a row into a clustered table such that the row's cluster key hashes to the hash value which is stored in a full data block; therefore, the row cannot be inserted into the root block (original block) allocated for the hash key. Instead, the row is inserted into an overflow block which is chained to the root block of the hash key.

Frequent collisions might or might not result in a larger number of overflow blocks within a hash cluster (thus reduce data retrieval performance). If a collision occurs and there is no space in the original block allocated for the hash key, an overflow block must be allocated to hold the new row. The likelihood of this happening is largely dependent on the average size of each hash key value and corresponding data, specified when the hash cluster is created, as illustrated in Figure 5 - 10 .

If the average size is small and each row has a unique hash key value, many hash key values can be assigned per data block. In this case, a small colliding row can likely fit into the space of the root block for the hash key. However, if the average hash key value size is large or each hash key value corresponds to multiple rows, only a few hash key values can be assigned per data block. In this case, it is likely that the large row will not be able to fit in the root block allocated for the hash key value and an overflow block is allocated.


CHAPTER 6. DATATYPES

If you want to be witty, work on your character and say what you think on every occasion.

Stendahl

This chapter discusses the ORACLE datatypes, their properties, and how they map to non-ORACLE datatypes:

•	the ORACLE datatypes: CHAR, VARCHAR2, NUMBER, DATE, ROWID, MLSLABEL, LONG, RAW, and LONG RAW

•	ROWIDs and the ROWID datatype

•	ANSI, SQL/DS, and DB2 datatypes

•	data conversions

________________________________________

ORACLE Datatypes

The following sections describe the ORACLE datatypes that can be used in column definitions:

•	CHAR

•	VARCHAR2

•	VARCHAR

•	NUMBER

•	DATE

•	LONG

•	RAW

•	LONG RAW

•	ROWID

•	MLSLABEL

Character Datatypes

The CHAR and VARCHAR2 datatypes store alphanumeric data; any character can be stored in a column of these datatypes. Character data is stored in strings, with byte values corresponding to the character encoding scheme (generally called a character set or code page); the database's character set is established when the database is created, and never changes. Examples of character sets are 7-bit ASCII (American Standard Code for Information Interchange), EBCDIC (Extended Binary Coded Decimal Interchange Code) Code Page 500, and Japan Extended UNIX. ORACLE supports both single-byte and multi-byte encoding schemes.

 CHAR Datatype

The CHAR datatype stores fixed length character strings. When a table is created with a CHAR column, a column length (in bytes, not characters) between 1 and 255 is specified for the CHAR column (default is 1). ORACLE then guarantees:

•	When a row is inserted into or updated in the table, the value for the CHAR column has the fixed length.

•	If a shorter value is given, the value is blank-padded to the fixed length.

•	If a longer value with trailing blanks is given, blanks are trimmed from the value to the fixed length.

•	If a value is too large, ORACLE returns an error.

ORACLE compares CHAR values using the blank-padded comparison semantics. For more information on comparison semantics, refer to the ORACLE7 Server SQL Language Reference Manual.

 VARCHAR2 Datatype

The VARCHAR2 datatype stores variable-length character strings. When a table is created with a VARCHAR2 column, a maximum column length (in bytes, not characters) between 1 and 2000 is specified for the VARCHAR2 column. For each row, each value in the column is stored as a variable-length field (unless a value exceeds the column's maximum length and ORACLE returns an error). For example, assume a column is declared VARCHAR2 with a maximum size of 50 characters. In a single-byte character set, if only 10 characters are given for the VARCHAR2 column value in a particular row, the column in the row's row piece only stores the 10 characters (10 bytes), not 50.

ORACLE compares VARCHAR2 values using the non-padded comparison semantics. For more information on comparison semantics, refer to the ORACLE7 Server SQL Language Reference Manual.

 VARCHAR Datatype

The VARCHAR datatype is currently synonymous with the VARCHAR2 datatype. However, in a future version of ORACLE, the VARCHAR datatype might store variable-length character strings compared with different comparison semantics. Therefore, use the VARCHAR2 datatype to store variable-length character strings.

 How to Choose the Correct Character Datatype

When deciding which datatype to use for a column that will store alphanumeric data in a table, consider the following points of distinction:

•	Comparison Semantics

 Use the CHAR datatype when you require ANSI compatibility in comparison semantics, that is, when trailing blanks are not important in string comparisons. Use the VARCHAR2 when trailing blanks are important in string comparisons.

•	Space Usage

 To store data more efficiently, use the VARCHAR2 datatype. The CHAR datatype blank-pads and stores trailing blanks up to a fixed column length for all column values, while the VARCHAR2 datatype does not blank-pad or store trailing blanks for column values.

•	Future Compatibility

 The CHAR and VARCHAR2 datatypes are and will always be fully supported. At this time, the VARCHAR datatype automatically corresponds to the VARCHAR2 datatype and is reserved for future use.

 Column Lengths for Character Datatypes and NLS Character Sets

The National Language Support (NLS) feature of ORACLE allows the use of various character sets for the character datatypes. The size of characters should be considered when specifying the column length for character datatypes. For example, some characters require one byte, some require two bytes, and so on. This issue must be considered when estimating space for tables with columns that contain character data. Refer to Appendix A for more information about the NLS feature of ORACLE.

NUMBER Datatype

The NUMBER datatype stores fixed and floating point numbers. Numbers of virtually any magnitude can be stored and are guaranteed portable among different systems operating ORACLE, up to 38 digits of precision. Numbers that can be stored in a NUMBER column are the following:

•	positive numbers in the range 1 x 10-130 to 9.99..9 x 10125 (with up to 38 significant digits)

•	negative numbers from -1 x 10-130 to 9.99..99 x 10125 (with up to 38 significant digits)

•	zero

•	positive and negative infinity (generated only in import from a Version 5 database)

For numeric columns you can specify the column as follows:

column_name NUMBER

Optionally, you can also specify a precision (total number of digits) and scale (number of digits to right of decimal point):

column_name NUMBER (precision, scale)

If a precision is not specified, the column stores values as given. If no scale is specified, the scale is zero.

ORACLE guarantees portability of numbers with a precision equal to or less than 38 digits. You can specify a scale and no precision:

column_name NUMBER (*, scale)

In this case, the precision is 38 and the specified scale is maintained.

When specifying numeric fields, it is a good idea to specify the precision and scale; this provides extra integrity checking on input. Table 6 - 1  below shows examples of how data would be stored using different scale factors.

Input Data	Specified As	Stored As

7,456,123.89	NUMBER	7456123.89

7,456,123.89	NUMBER(*,1)	7456123.9

7,456,123.89	NUMBER(9)	7456124

7,456,123.89	NUMBER(9,2)	7456123.89

7,456,123.89	NUMBER(9,1)	7456123.9

7,456,123.89	NUMBER(6)	(not accepted, exceeds precision)

7,456,123.89	NUMBER(7,-2)	7456100

Table 6 - 1.  How Scale Factors Affect Numeric Data Storage

If a negative scale is specified, the actual data is rounded to the specified number of places to the left of the decimal point. For example, specifying (7,-2) means ORACLE should round to the nearest hundredths, as shown in Table 6 - 1 .

For input and output of numbers, the standard ORACLE default decimal character is a period, as in the number "1234.56". (The decimal is the character that separates the integer and decimal parts of a number.) The default decimal character can be changed for the instance with the parameter NLS_NUMERIC_CHARACTERS. It can also be changed for the duration of a session with the ALTER SESSION statement. To enter numbers that do not use the current default decimal character, one can use the TO_NUMBER function.

 Internal Numeric Format

Numeric data is stored in variable-length format. Each value is stored in scientific notation, with one byte used to store the exponent and up to 20 bytes to store the mantissa. (However, there are only 38 digits of precision.) Leading and trailing zeros are not stored. For example, the number 412 is stored in a format similar to 4.12 * 102, with one byte used to store the exponent (2) and two bytes used to store the three significant digits of the mantissa (4, 1, 2).

Taking this into account, the column data size for a particular numeric data value NUMBER (p), where p is the precision of a given value (scale has no effect), can be calculated using the following formula:

  1 byte	(exponent)

  FLOOR(p/2)+1 bytes	(mantissa)

+ 1 byte	(only for a negative number where

the number of significant digits is

less than 38)

_______________________

number of bytes of data

Zero, and positive and negative infinity (only generated on import from Version 5 ORACLE databases) are stored using unique representations; zero and negative infinity each require one byte, while positive infinity requires two bytes.

DATE Datatype

The DATE datatype stores point-in-time values (e.g., dates and times) in a table. The DATE datatype stores the year (including the century), the month, the day, the hours, the minutes, and the seconds (after midnight). ORACLE can store dates ranging from Jan 1, 4712 BC through Dec. 31, 4712 AD. Unless BC is specifically used, AD date entries are the default.

ORACLE uses its own internal format to store dates. Date data is stored in fixed-length fields of seven bytes each, corresponding to century, year, month, day, hour, minute, and second.

For input and output of dates, the standard ORACLE default date format is DD-MON-YY, as below:

'13-NOV-92'

This default date format can be changed for an instance with the parameter NLS_DATE_FORMAT. It can also be changed during a user session with the ALTER SESSION statement. To enter dates that are not in standard ORACLE date format, use the TO_DATE function with a format mask:

TO_DATE ('November 13, 1992', 'MONTH DD, YYYY')

Note: If the standard date format DD-MON-YY is used, YY indicates the year in the 20th century (e.g., 31-DEC-92 is December 31, 1992). If you want to indicate years in any century other than the 20th century, use a different format mask, as shown above.

Time is stored in 24-hour format-HH:MI:SS. By default, the time in a date field is 12:00:00 A.M. (midnight) if no time portion is entered. In a time-only entry, the date portion defaults to the first day of the current month. To enter the time portion of a date, the TO_DATE function must be used with a format mask indicating the time portion, as in:

INSERT INTO birthdays (bname, bday) VALUES

('ANDY',TO_DATE('13-AUG-66 12:56 A.M.','DD-MON-YY HH:MI A.M.'));

 Using Julian Dates

Julian dates allow continuous dating from a common reference. (The reference is 01-01-4712 years B.C., so current dates are somewhere in the 2.4 million range.) A Julian date is nominally a non-integer, the fractional part being a portion of a day. ORACLE uses a simplified approach that results in integer values. Julian dates can be calculated and interpreted differently; the calculation method used by ORACLE results in a 7 digit number (for dates most often used), such as 2449086 for 08-APR-93.

The format mask "J" can be used with date functions (TO_DATE or TO_CHAR) to convert date data into Julian dates. For example, the following query returns all dates in Julian date format:

SELECT TO_CHAR (hiredate, 'J') FROM emp;

The TO_NUMBER function must be used if you want to use Julian dates in calculations. You can use the TO_DATE function to enter Julian dates:

INSERT INTO emp (hiredate) VALUES (TO_DATE(2448921, 'J'));

 Date Arithmetic

ORACLE date arithmetic takes into account the anomalies of the calendars used throughout history. For example, the switch from the Julian to the Gregorian calendar, 15-10-1582, eliminated the previous 10 days (05-10-1582 through 14-10-1582). The year 0 does not exist.

Missing dates can be entered into the database, but are ignored in date arithmetic and treated as the next "real" date. For example, the next day after 04-10-1582 is 15-10-1582, and the day following 05-10-1582 is also 15-10-1582.

Note: This discussion of date arithmetic may not apply to all countries' date standards (such as those in Asia).

LONG Datatype

Columns defined as LONG can store variable-length character data containing up to two gigabytes of information. LONG data is text data that is to be appropriately converted when moving among different systems. Also see the next section for information about the LONG RAW datatype.

 Uses of LONG Data

Columns defined with the LONG datatype are used in the data dictionary to store the text of view definitions. Columns defined as LONG can be used in SELECT lists, SET clauses of UPDATE statements, and VALUES clauses of INSERT statements.

 Restrictions on LONG and LONG RAW Data

Although LONG (and LONG RAW; see below) columns have many uses, there are some restrictions on their use:

•	Only one LONG column is allowed per table.

•	LONG columns cannot be indexed.

•	LONG columns cannot appear in integrity constraints.

•	LONG columns cannot be used in WHERE, GROUP BY, ORDER BY, CONNECT BY clauses or with the DISTINCT operator in SELECT statements.

•	LONG columns cannot be referenced by SQL functions (such as SUBSTR or INSTR).

•	LONG columns cannot be used in the SELECT list of a subquery or queries combined by set operators (UNION, UNION ALL, INTERSECT, or MINUS).

•	LONG columns cannot be used in expressions.

•	LONG columns cannot be referenced when creating a table with query (CREATE TABLE . . . AS SELECT . . .) or when inserting into a table (or view) with a query

 (INSERT INTO . . . SELECT . . .).

•	A variable or argument of a PL/SQL program unit cannot be declared using the LONG datatype.

RAW and LONG RAW Datatypes

The RAW and LONG RAW datatypes are used for data that is not to be interpreted (not converted when moving data between different systems) by ORACLE. These datatypes are intended for binary data or byte strings. For example, LONG RAW can be used to store graphics, sound, documents, or arrays of binary data; the interpretation is dependent on the use.

RAW is equivalent to VARCHAR2, and LONG RAW to LONG, except that SQL*Net (which connects users sessions to the instance) and the Import and Export utilities do not perform character conversion when transmitting RAW or LONG RAW data. In contrast, SQL*Net and Import/Export automatically convert CHAR, VARCHAR2, and LONG data between the database character set to the user session character set (set by the NLS_LANGUAGE parameter of the ALTER SESSION command), if the two character sets are different.

When ORACLE automatically converts RAW or LONG RAW data to and from CHAR data, the data is represented as one hexadecimal character representing the bit pattern for every four bits of RAW data. For example, one byte of RAW data with bits 11001011 is displayed and entered as 'CB'.

LONG RAW data cannot be indexed, but RAW data can be indexed.

ROWIDs and the ROWID Datatype

Every row in a non-clustered table of an ORACLE database is assigned a unique ROWID that corresponds to the physical address of a row's row piece (the initial row piece if the row is chained among multiple row pieces). In the case of clustered tables, rows in different tables that are in the same data block can have the same ROWID.

Each table in an ORACLE database internally has a pseudocolumn named ROWID; this pseudo-column is not evident when listing the structure of a table by executing a SELECT * FROM . . . statement, or a DESCRIBE . . . statement using SQL*Plus. However, each row's address can be retrieved with a SQL query using the reserved word ROWID as a column name:

SELECT ROWID, ename FROM emp;

ROWIDs use a binary representation of the physical address for each row selected. When queried using SQL*Plus or SQL*DBA, the binary representation is converted to a VARCHAR2/hexadecimal representation and the above query might return the following row information:

ROWID              ENAME

------------------ ----------

00000DD5.0000.0001 SMITH

00000DD5.0001.0001 ALLEN

00000DD5.0002.0001 WARD

As shown above, a ROWED's VARCHAR2/hexadecimal representation is divided into three pieces: block.row.file

•	The data block that contains the row (block DD5 in the example). Block numbers are relative to their data file, not tablespace. Therefore, two rows with identical block numbers could reside in two different data files of the same tablespace.

•	The row in the block that contains the row (rows 0, 1, 2 in the example). Row numbers of a given block always start with 0.

•	The data file that contains the row (file 1 in the example). The first data file of every database is always 1, and file numbers are unique within a database.

A row's assigned ROWID remains unchanged unless the row is exported and imported (using the IMPORT and EXPORT utilities). When a row is deleted from a table (and the encompassing transaction is committed), the deleted row's associated ROWID can be assigned to a row inserted in a subsequent transaction.

It is not possible to set the value of the pseudocolumn ROWID in INSERT or UPDATE statements. The ROWIDs in the pseudocolumn ROWID are used internally by ORACLE for various operations (see the next section). Though ROWIDs in the pseudocolumn ROWID can be referenced like other table columns (used in SELECT lists and WHERE clauses), ROWIDs in this pseudocolumn are not stored in the database, nor are they database data.

ROWIDs and Non-ORACLE Databases      ORACLE database applications can be executed against non-ORACLE database servers using SQL*Connect or the Oracle Open Gateway. In such cases, the binary format of ROWIDs varies according to the characteristics of the non-ORACLE system. Furthermore, no standard translation to VARCHAR2/hexadecimal format is available. Programs can still use the ROWID datatype; however, they must use a non-standard translation to hexadecimal format of length up to 256 bytes. Refer to the relevant manual for OCIs or Precompilers for further details on handling ROWIDs in conjunction with non-ORACLE systems.

 How ROWIDs Are Used

ROWIDs are used internally by ORACLE in the construction of indexes. Each key in an index is associated with a ROWID that points to the associated row's address for fast access.

ROWIDs can also be used by end-users and application developers for several important uses:

•	ROWIDs are the fastest means of accessing particular rows.

•	ROWIDs can be used to see how a table is organized.

•	ROWIDs are unique identifiers for rows in a given table.

Before ROWIDs are used in DML statements, they should be verified and guaranteed not to change; the intended rows should be locked so they cannot be deleted. Under some circumstances, requesting data with an invalid ROWID could cause a statement to fail.

Users can also create tables with columns defined using the ROWID datatype; for example, an exception table is defined with a column of datatype ROWID to store the ROWIDs of rows in the database that violate integrity constraints. Such columns defined using the ROWID datatype behave like other table columns; values can be updated, etc. All values in a column defined as datatype ROWID require six bytes to store pertinent column data.

 Examples of Using ROWIDs

Using some group functions with ROWID, you can see how data is internally stored in an ORACLE database.

The function SUBSTR can be used to break the data in ROWID into its three components (file, block, and row). For example:

SELECT ROWID, SUBSTR(ROWID,15,4) "FILE",

   SUBSTR(ROWID,1,8) "BLOCK",

   SUBSTR(ROWID,10,4) "ROW"

   FROM products;

 ROWID               FILE  BLOCK     ROW

------------------  ----  --------  ----

00000DD5.0000.0001  0001  00000DD5  0000

00000DD5.0001.0001  0001  00000DD5  0001

00000DD5.0002.0001  0001  00000DD5  0002

ROWIDs can be useful for revealing information about the physical storage of a table's data. For example, if you are interested in the physical location of a table's rows (such as for table striping), the following query tells how many data files contain rows of a given table:

SELECT COUNT(DISTINCT(SUBSTR(ROWID,15,4))) "FILES" FROM tablename;

  FILES

--------

    2

For more information on how to use ROWIDs, refer to the ORACLE7 Server SQL Language Reference Manual, the PL/SQL User's Guide and Reference, the ORACLE7 Server Application Developer's Guide, and other books that document ORACLE tools and utilities.

The MLSLABEL Datatype

Trusted ORACLE provides one new datatype:  the MLSLABEL datatype. You can declare columns of the MLSLABEL datatype in standard ORACLE, as well as in Trusted ORACLE, for compatibility with Trusted ORACLE applications.

The MLSLABEL datatype is used to store the binary format of an operating system label. The maximum width of a column declared as MLSLABEL is 255 bytes.

MLSLABEL data is stored as a variable length tag (two to five bytes, in which one indicates length) that maps to a binary label in the data dictionary. The reason that MLSLABEL data is stored as a representative tag instead of the binary label itself is that binary operating system labels can be very long. Given that a label is stored with every row in the database (in the ROWLABEL column), storing a large number of large labels can consume a lot of space. Storing a representative tag instead of a label is more space efficient.

Any labels that are valid on your operating system can be inserted into an MLSLABEL column. When you insert a label into an MLSLABEL column, Trusted ORACLE implicitly converts the data into the binary format of the label.

The following sections further describe this datatype and the ROWLABEL pseudocolumn. If you are using Trusted ORACLE, also see the Trusted ORACLE7 Server Administrator's Guide for more information.

 The ALL_LABELS Data Dictionary View

The ALL_LABELS data dictionary view lists all of the labels ever stored in the database, including the values of DBHIGH and DBLOW. Any label ever stored in an MLSLABEL column (including the ROWLABEL column) is automatically added to this view.

Note that this view does not necessarily contain all labels that are valid in the database, since any valid operating system label, in any valid format, is a valid label within Trusted ORACLE. Also note that this view may contain labels that are invalid within the database (if those labels were once used in the database, but are no longer valid).

 The ROWLABEL Column

The ROWLABEL column is automatically appended to each Trusted ORACLE table at table creation. This column contains a label of the MLSLABEL datatype for every row in the table.

In OS MAC mode, given that a table can contain rows at one label only, the values in this column are always uniform within a table (and within a single database).

In DBMS MAC mode, the values in this column can range within a single table from DBHIGH to DBLOW (within any constraints defined for that table).

Summary of ORACLE Datatype Information

For quick reference,  Table 6 - 2  summarizes the important information about each ORACLE datatype.

Data Type	Description	Column Length (bytes)

CHAR (size)	Fixed length char	Fixed for every row in the table

acter data of length 	(with trailing spaces); maximum

size.	size is 255 bytes per row, default

size is one byte per row. Consid

er the character set that is used

before setting size. (Are you using

a one or two byte character set?)

VARCHAR2 (size)	Variable length 	Variable for each row, up to 2000

character data. A 	bytes per row. Consider the char

maximum size must 	acter set that is used before set

be specified.	ting size. (Are you using a one or

two byte character set?)

NUMBER (p, s) 	Variable length nu	Variable for each row. The maxi

meric data. Maxi	mum space required for a given

mum precision p 	column is 21 bytes per row.

and/or scale s is 38.

DATE	Fixed length date 	Fixed at seven bytes for each row

and time data, 	in the table.

ranging from Janu

ary 1, 4712 B.C. to

December 31, 4712

A. D. Default for

mat: DD-MON-YY.

LONG	Variable length 	Variable for each row in the table,

character data.	up to 231 * 1 bytes, or two giga

bytes, per row.

RAW (size)	Variable length raw 	Variable for each row in the table,

binary data. A 	up to 2000 bytes per row.

maximum size must

be specified.

LONG RAW	Variable length raw 	Variable for each row in the table,

binary data.	up to 231 * 1 bytes, or two giga

bytes, per row.

ROWID	Binary data repre	Fixed at six bytes for each row in

senting row ad	the table.

dresses.

MLSLABEL	Variable length 	Variable for each row in the table,

binary data repre	ranging from two to five bytes

senting operating 	per row.

system labels.

Table 6 - 2.  Summary of ORACLE Datatype Information

________________________________________

ANSI, DB2, and SQL/DS Datatypes

In addition to ORACLE datatypes, columns of tables in an ORACLE database can be defined using ANSI, DB2, and SQL/DS datatypes. However, ORACLE internally converts such datatypes to ORACLE datatypes.

ANSI SQL Datatype	ORACLE Datatype

CHARACTER (n), CHAR(n)	CHAR(n)

NUMERIC (p, s), DECIMAL (p, s) DEC (p, a)	NUMBER (p, s)

INTEGER, INT, SMALLINT	NUMBER (38)

FLOAT (p), REAL, DOUBLE PRECISION	NUMBER

CHARACTER VARYING(n), CHAR VARYING(n)	VARCHAR(n)

Table 6 - 3.  ANSI Datatype Conversions to ORACLE Datatypes

DB2 or SQL/DS Datatype	ORACLE Datatype

CHARACTER (n)	CHAR(n)

VARCHAR (n)	VARCHAR2 (n)

LONG VARCHAR	LONG

DECIMAL (p, s)	NUMBER (p, s)

INTEGER, SMALLINT	NUMBER (38)

FLOAT (p)	NUMBER

DATE	DATE

Table 6 - 4.  SQL/DS, DB2 Datatype Conversions to ORACLE Datatypes

The IBM products SQL/DS and DB2 datatypes TIME, TIMESTAMP, GRAPHIC, VARGRAPHIC, and LONG VARGRAPHIC have no corresponding ORACLE datatype, and cannot be used. The TIME and TIMESTAMP datatypes are subcomponents of the ORACLE datatype DATE.

The ANSI datatypes NUMERIC, DECIMAL, and DEC can specify only fixed point numbers. For these datatypes, s defaults to 0.

________________________________________

Data Conversion

In some cases, ORACLE supplies data of one datatype where it expects data of a different datatype. This is allowed when ORACLE can automatically convert the data to the expected datatype using one of the following functions:

•	TO_NUMBER()

•	TO_CHAR()

•	TO_DATE()

•	TO_LABEL()

•	CHARTOROWID()

•	ROWIDTOCHAR()

•	HEXTOCHAR()

•	CHARTOHEX()

Implicit datatype conversions work according to the rules explained in the following two sections.

Note: If you are using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide for additional information involving data conversions and the MLSLABEL and RAW MLSLABEL datatypes.

Rule 1: Assignments

For assignments, ORACLE can automatically convert the following:

•	VARCHAR2 or CHAR to NUMBER

•	NUMBER to VARCHAR2

•	VARCHAR2 or CHAR to DATE

•	DATE to VARCHAR2

•	VARCHAR2 or CHAR to ROWID

•	ROWID to VARCHAR2

•	VARCHAR2 or CHAR to LABEL

•	LABEL to VARCHAR2

•	VARCHAR2 or CHAR to HEX

•	HEX to VARCHAR2

The assignment succeeds if ORACLE can convert the datatype of the value used in the assignment to that of the assignment's target.

Note: For the examples in the following list, assume a package with a public variable and a table declared as in the following statements:

var1	CHAR(5);

CREATE TABLE table1 (col1 NUMBER);

•	variable := expression

The datatype of expression must be either be the same as or convertible to the datatype of variable. For example, ORACLE automatically converts the data provided in the following assignment within the body of a stored procedure:

    VAR1 := 0

•	INSERT INTO table VALUES (expression1, expression2, ...)

The datatypes of expression1, expression2, and so on, must either be the same as or convertible to the datatypes of the corresponding columns in table. For example, ORACLE automatically converts the data provided in the following INSERT statement for TABLE1 (see table definition above):

    INSERT INTO table1 VALUES ('19');

•	UPDATE table SET column = expression

The datatype of expression must either be the same as or convertible to the datatype of column. For example, ORACLE automatically converts the data provided in the following UPDATE statement issued against TABLE1:

    UPDATE table1 SET col1 = '30';

•	SELECT column INTO variable FROM table

The datatype of column must either be the same as or convertible to the datatype of variable. For example, ORACLE automatically converts data selected from the table before assigning it to the variable in the following statement:

    SELECT col1 INTO var1 FROM table1 WHERE col1 = 30;

Rule 2: Expression Evaluation

For expression evaluation, ORACLE can automatically convert the following:

•	VARCHAR2 or CHAR to NUMBER

•	VARCHAR2 or CHAR to DATE

Some common types of expressions follow:

•	Simple expressions, such as the following:

comm + '500'

•	Boolean expressions such as the following:

bonus > sal / '10'

•	Function and procedure calls such as the following:

MOD (counter, '2')

•	WHERE clause conditions such as the following:

WHERE hiredate = '01-JAN-91'

In general, ORACLE uses the rule for expression evaluation when a datatype conversion is needed in places not covered by the rule for assignment conversions.

In assignments of the form

variable := expression

ORACLE first evaluates expression using the conversions covered by Rule 2; expression can be simple or complex. If it succeeds, expression results in a single value and datatype. Then, ORACLE tries to assign this value to the assignment's target using Rule 1.

CHAR to NUMBER conversions only succeed if the character string represents a valid number. CHAR to DATE conversions only succeed if the character string has the default format 'DD-MON-YY'.


CHAPTER 7. DATA INTEGRITY

Freedom and constraint are two aspects of the same necessity, which is to be what one is and no other.

Antoine de Saint-Exupery:  La Citadelle

This chapter explains how to enforce the business rules associated with your database and prevent the entry of invalid information into tables using integrity constraints. Topics include:

•	the definition of data integrity

•	an introduction to integrity constraints and other methods of enforcing data integrity

•	the different types of integrity constraints

•	NOT NULL constraints

•	UNIQUE key constraints

•	PRIMARY KEY constraints

•	FOREIGN KEY (referential) constraints

•	CHECK constraints

•	the internal mechanisms that enforce constraints

If you are using Trusted ORACLE, refer to the Trusted ORACLE7 Server Administrator's Guide for more information about integrity constraints in that environment.

________________________________________

What Is Data Integrity?

It is important that data adheres to a predefined set of rules, as determined by the database administrator or application developer. As an example of data integrity, consider the tables EMP and DEPT and the business rules for the information in each of the tables, as illustrated in Figure 7 - 1.

Note that certain columns of each table have specific rules that constrain the data contained within them.

Types of Data Integrity

In general, the different types of data integrity applicable to the tables in a relational database include those defined in the following sections.

 Nulls

A rule defined on a single column that allows or disallows inserts or updates of rows containing a null for the column.

 Unique Column Values

A rule defined on a column (or set of columns) that allows the insert or update of a row containing only a unique value for the column (or set of columns).

 Primary Key Values

A rule defined on a column (or set of columns) so that each row in the table can be uniquely identified by the values in the column (or set of columns).

 Referential Integrity

A rule defined on a column (or set of columns) in one table that allows the insert or update of a row only if the value for the column or set of columns (the dependent value) matches a value in a column of a related table (the referenced value).

Referential integrity also includes the rules that dictate what types of data manipulation are allowed on referenced data and what actions are to be performed on dependent data as a result of any actions taken on the referenced data. The rules associated with referential integrity include:

Restrict	A referential integrity rule that disallows the update or deletion of referenced data.

Set to Null	When referenced data is updated or deleted, all associated dependent data is set to NULL.

Set to Default	When referenced data is updated or deleted, all associated dependent data is set to a default value.

Cascade	When referenced data is updated, all associated dependent data is correspondingly updated; when a referenced row is deleted, all associated dependent rows are deleted.

 Complex Integrity Checking

A user-defined rule for a column (or set of columns), related to the values the column contains, that allows or disallows inserts, updates, or deletes of a row based on the value it contains for the column (or set of columns).

How ORACLE Enforces Data Integrity

ORACLE allows you to define and enforce each type of the data integrity rules defined in the previous section. The majority of these rules are easily defined using integrity constraints.

 Integrity Constraints

An integrity constraint is a declarative method of defining a rule for a column of a table. The integrity constraints supported by ORACLE include:

•	NOT NULL integrity constraints for the rules associated with nulls in a column

•	UNIQUE key integrity constraints for the rule associated with unique column values

•	PRIMARY KEY integrity constraints for the rule associated with primary identification values

•	FOREIGN KEY integrity constraints for the rules associated with referential integrity. ORACLE currently supports the use of FOREIGN KEY integrity constraints to define the referential integrity actions including:

•	update and delete RESTRICT

•	delete CASCADE

•	CHECK integrity constraints for the rules associated with complex integrity rules

Other referential integrity actions not included on this list should be defined using database triggers (see the following section).

Note: Referential integrity cannot be enforced using declarative integrity constraints if child and parent tables are on different nodes of a distributed database. However, referential integrity in a distributed database can be enforced using database triggers (see next section).

 Database Triggers

ORACLE also allows you to enforce integrity rules with a non-declarative approach using database triggers (stored database procedures automatically invoked on insert, update, or delete operations). While database triggers allow you to define and enforce any type of integrity rule, it is strongly recommended that you use database triggers only in the following situations:

•	to enforce referential integrity when a required referential integrity rule cannot be enforced using the integrity constraints listed above: update CASCADE, update and delete SET NULL, update and delete SET DEFAULT

•	to enforce referential integrity when child and parent tables are on different nodes of a distributed database

•	to enforce complex business rules not definable using integrity constraints

For more information and examples of database triggers used to enforce data integrity, see Chapter 15.

________________________________________

An Introduction to Integrity Constraints

An integrity constraint is a mechanism used by ORACLE to prevent invalid data entry into the base tables of the database. Integrity constraints can be defined to enforce the business rules that are associated with the information in a database. If any of the results of a DML statement execution violate an integrity constraint, the statement is rolled back and an error is returned.

Note: Integrity constraints are defined on tables. However, also note that operations on views (and synonyms for tables) are subject to the integrity constraints defined on the underlying base tables.

For example, assume that an integrity constraint is defined for the SAL column of the EMP table. This integrity constraint enforces the rule that no row in this table can contain a numeric value greater than 10,000 in this column. If an INSERT or UPDATE statement attempts to violate this integrity constraint, the statement is rolled back and an informative error is returned.

The integrity constraints implemented in ORACLE fully comply to the standards set forth by ANSI X3.135-1989 and ISO 9075-1989.

Advantages of Integrity Constraints

Integrity constraints are not the only way to enforce data integrity rules on the data of your database. You can also:

•	enforce business rules in the code of a database application

•	use stored procedures to completely control access to data

•	enforce business rules using triggered stored database procedures (see Chapter 15.)

The following section describes some of the advantages that integrity constraints have versus these other alternatives.

 Declarative Ease

Because integrity constraints are defined using SQL commands, when you define or alter a table, no programming is required. Therefore, they are easy to write, eliminate programming errors, and their functionality is controlled by ORACLE. For these reasons, declarative integrity constraints are preferable to application code and database triggers. The declarative approach is also better than using stored procedures because, unlike the stored procedure solution to data integrity by controlled data access, integrity constraints do not eliminate the flexibility of ad hoc data access.

 Centralized Rules

Integrity constraints are defined for tables (not an application) and stored in the data dictionary. Therefore, the data entered by any application must adhere to the same integrity constraints associated with a table. By moving business rules from application code to centralized integrity constraints, the tables of a database are guaranteed to contain valid data, no matter which database application manipulates the information. Stored procedures cannot provide the same advantage of centralized rules stored with a table, and although database triggers can provide this benefit, the complexity of implementation is far greater than the declarative approach used for integrity constraints.

 Maximum Application Development Productivity

If a business rule enforced by an integrity constraint changes, the administrator need only change the definition of that integrity constraint and all applications automatically adhere to the modified constraint. Alternatively, if a business rule is enforced by the code of each database application, developers must modify all application source code and recompile, debug, and test the modified applications.

 Immediate User Feedback

Because specific information about each integrity constraint is stored in the data dictionary, database applications can be designed to use the this information to provide immediate user feedback about integrity constraint violations, even before the SQL statement is executed and checked by ORACLE. For example, a SQL*Forms application can use integrity constraint definitions stored in the data dictionary to check for violations as values are entered into the fields of a form, even before a statement is issued by the SQL*Forms application.

 Superior Performance

Because the semantics of integrity constraint declarations are clearly defined, performance optimizations are implemented for each specific declarative rule. The ORACLE query optimizer can use declarations to learn more about data to improve overall query performance. (Also, taking integrity rules out of application code and database triggers guarantees that checks are only done when necessary.)

 Flexibility for Data Loads and Identification of Integrity Violations

Integrity constraints can be temporarily disabled so that large amounts of data can be loaded without the overhead of constraint checking. When the data load is complete, the integrity constraints can be easily enabled, and any new rows that violate integrity constraints can be automatically reported to a separate exceptions table.

The Performance Cost of Integrity Constraints

The advantages of enforcing data integrity rules do not come without some loss in performance. In general, the "cost" of including an integrity constraint is, at most, the same as executing a SQL statement that evaluates the constraint.

________________________________________

Types of Integrity Constraints

There are several types of integrity constraints that the database administrator or application developer can use to impose restrictions on the input of column values:

•	NOT NULL constraints

•	UNIQUE key constraints

•	PRIMARY KEY constraints

•	FOREIGN KEY (referential) constraints

•	CHECK constraints

The following sections explain each type of integrity constraint in detail. The information in each section includes the following:

•	the rule enforced by the constraint

•	an example of the constraint

•	recommendations for appropriate use of the constraint

•	other important information about the constraint

NOT NULL Integrity Constraints

By default, all columns in a table allow nulls (the absence of a value). A NOT NULL constraint requires that no nulls be allowed in a column of a table. For example, a NOT NULL constraint can be defined to require that a value be input in the ENAME column for every row of the EMP table.

Figure 7 - 2 illustrates a NOT NULL integrity constraint.

UNIQUE Key Integrity Constraints

A UNIQUE key integrity constraint requires that no two rows of a table have duplicate values in a specified column or set of columns.

For example, consider Figure 7 - 3  of the DEPT table; a UNIQUE key constraint is defined on the DNAME column to disallow rows with duplicate department names.

 Unique Keys

The column (or set of columns) included in the definition of the UNIQUE key constraint is called the unique key. The term "unique key" is often incorrectly used as a synonym for the terms "UNIQUE key constraint" or "UNIQUE index"; however, note that the term "key" refers only to the list of columns used in the definition of the integrity constraint.

If the UNIQUE key constraint is comprised of more than one column, that constraint is said to be a composite unique key. For example, in Figure 7 - 4, the CUSTOMER table has a UNIQUE key constraint defined on the composite unique key: the AREA and PHONE columns.

This UNIQUE key constraint allows an area code to be entered any number of times and a phone number to be input any number of times, but the combination of a given area code and given phone number cannot be duplicated in the table. This eliminates unintentional duplication of a phone number.

 UNIQUE Key Constraints and Indexes

All unique integrity constraints are enforced using indexes. In Figure 7 - 4, the UNIQUE key constraint is enforced by the implicit creation of a unique index on the composite unique key. Because UNIQUE key constraints are enforced using indexes, composite UNIQUE key constraints are limited to the same limitations imposed on composite indexes; up to 16 columns can constitute a composite unique key, and the total size (in bytes) of a key value cannot exceed approximately half the associated database's block size.

 Combining UNIQUE Key and NOT NULL Integrity Constraints

Notice in the examples of the previous section that UNIQUE key constraints allow the input of nulls unless NOT NULL constraints are also defined for the same columns. In fact, any number of rows can include nulls for columns without NOT NULL constraints because nulls are not considered equal. A null in a column always satisfies a UNIQUE key constraint.

Unique keys are often defined on columns with NOT NULL integrity constraints. The combination of NOT NULL and UNIQUE key integrity constraints is used to force the input of values in the unique key; this combination of data integrity rules eliminates the possibility that any new row's data will ever risk conflicting with an existing row's data.

PRIMARY KEY Integrity Constraints

Each table in the database can have a single PRIMARYKEY constraint. Rows of a table can be identified or referenced using the values governed by the PRIMARY KEY integrity constraint.

The ORACLE implementation of the PRIMARY KEY integrity constraint guarantees that both of the following are true:

•	No two rows of a table have duplicate values in the specified column or set of columns.

•	The primary key columns do not allow nulls (i.e., a value must exist for the primary key columns in each row).

 Primary Keys

The column (or set of columns) included in the definition of a table's PRIMARY KEY integrity constraint is called the primary key. Although it is not required, every table should have a primary key so that:

•	Each row in the table can be uniquely identified.

•	No duplicate rows exist in the table.

Figure 7 - 5 illustrates a PRIMARY KEY constraint in the DEPT table and examples of rows that are not allowed in the table by the constraint.

 PRIMARY KEY Constraints and Indexes

ORACLE enforces all PRIMARY KEY constraints using indexes. In the previous example, the primary key constraint created for the DEPTNO column is enforced by:

•	the implicit creation of a unique index on that column

•	the implicit creation of a NOT NULL constraint for that column

Because primary key constraints are enforced using indexes, composite primary key constraints are limited to 16 columns, which is the same limitation imposed on composite indexes. The name of the index is the same as the name of the constraint. Also, you can specify the storage options for the index by including the ENABLE clause in the CREATE TABLE or ALTER TABLE statement used to create the constraint.

Referential Integrity and FOREIGN KEY (Referential) Integrity Constraints

Because tables of a relational database can be related by common columns, the rules that govern the relationship of the columns must be maintained. Referential integrity rules guarantee that these relationships are preserved.

There are several terms associated with referential integrity constraints:

Foreign Key	The column or set of columns included in the definition of the referential integrity constraint that reference a referenced key (see below).

Referenced Key	The unique key or primary key of the same or different table that is referenced by a foreign key.

Dependent or Child Table	A dependent or child table is the table that includes the foreign key. Therefore, it is the table that is dependent on the values present in the referenced unique or primary key.

Referenced or Parent Table	A referenced or parent table is the table that is referenced by the child table's foreign key. It is this table's referenced key that determines whether or not specific inserts or updates are allowed in the child table.

A referential integrity constraint requires that for each row of a table, the value in the foreign key matches a value in a parent key.

Figure 7 - 6 illustrates the above terms.

Figure 7 - 6  shows a foreign key defined on the DEPTNO column of the EMP table. It guarantees that every value in this column must match a value in the primary key of the DEPT table (the DEPTNO column); therefore, no erroneous department numbers can exist in the DEPTNO column of the EMP table.

Foreign keys can be comprised of multiple columns. However, a composite foreign key must reference a composite primary or unique key with the same number of columns and datatypes. Because composite primary and unique keys are limited to 16 columns, a composite foreign key is also limited to 16 columns.

 Self-Referential Integrity Constraints

Another type of referential integrity constraint, shown in Figure 7 - 7 ,is called a self-referential integrity constraint. This type of foreign key references a parent key of the same table. In the example above, the referential integrity constraint is defined so that every value in the MGR column of the EMP table corresponds to a value that currently exists in the EMPNO column of the same table; this integrity constraint eliminates the possibility of erroneous employee numbers in the MGR column.

 Nulls and Foreign Keys

The relational model permits foreign keys to be a value of the referenced primary or unique key, or null. There are several possible interpretations of this basic rule of the relational model when composite (multicolumn) foreign keys are involved. The ANSI/ISO SQL89 standard permits a composite foreign key to contain any value in its non-null columns if any other column is null, even if those non-null values are not found in the referenced key. By using other constraints (e.g., NOT NULL and CHECK constraints), you can alter the treatment of partially null foreign keys from this default treatment.

A composite foreign key can be all null, all non-null, or partially null. The following terms define three alternative matching rules for composite foreign keys:

match full 	Partially null foreign keys are not permitted. Either all components of the foreign key must be null, or the combination of values contained in the foreign key must appear as the primary or unique key value of a single row of the referenced table.

match partial	Partially null composite foreign keys are permitted. Either all components of the foreign key must be null, or the combination of non-null values contained in the foreign key must appear in the corresponding portion of the primary or unique key value of a single row in the referenced table.

match none	Partially null composite foreign keys are permitted. If any column of a composite foreign key is null, then the non-null portions of the key do not have to match any corresponding portion of a parent key.

Actions Defined by Referential Integrity Constraints

Referential integrity constraints also specify particular actions that are performed on the dependent rows in a child table if a referenced parent key value is modified. The referential actions supported by the FOREIGN KEY integrity constraints of ORACLE include UPDATE and DELETE RESTRICT, and DELETE CASCADE.

Note: Other referential actions not supported by FOREIGN KEY integrity constraints of ORACLE can be enforced using database triggers. See Chapter 15 for more information regarding database triggers.

Update and Delete Restrict   The restrict action specifies that referenced key values cannot be updated or deleted if the resulting data would violate a referential integrity constraint. For example, if a primary key value is referenced by a value in the foreign key, the referenced primary key value cannot be deleted because of the dependent data.

Delete Cascade   The delete cascade action specifies that when rows containing referenced key values are deleted, all rows in child tables with dependent foreign key values are also deleted; therefore, the delete cascades. For example, if a row in a parent table is deleted, and this row's primary key value is referenced by one or more foreign key values in a child table, the rows in the child table that reference the primary key value are also deleted from the child table.

DML Restrictions with Respect to Referential Actions    Table 7 - 1 outlines the DML statements allowed by the different referential actions on the primary/unique key values in the parent table, and the foreign key values in the child table.

DML Statement	Issued Against Parent Table	Issued Against Child Table

INSERT	Always OK if parent key 	OK only if the foreign key

value is unique.	value exists in the parent

key.

UPDATE Restrict	Allowed if the statement 	Allowed if the new foreign

does not leave any rows in 	key value still references a

the child table without a 	referenced key value.

referenced parent key val

ue.

DELETE Restrict	Allowed if no rows in the 	Always OK.

child table reference the

parent key value.

DELETE Cascade	Always OK.	Always OK.

Table 7 - 1.  DML Statements Allowed by Update and Delete Restrict

* Assumes that NOT NULL constraints are defined on all columns of the foreign key

CHECK Integrity Constraints

A CHECK integrity constraint on a column or set of columns requires that a specified condition be true or unknown for every row of the table. If a DML statement is issued so that the condition of the CHECK constraint evaluates to false, the statement is rolled back.

 The Check Condition

CHECK constraints allow you to enforce very specific or sophisticated integrity rules with the specification of a check condition. The condition of a CHECK constraint has some limitations, including that the condition must be a Boolean expression evaluated using the values in the row being inserted or updated, and cannot contain subqueries, sequences, the SYSDATE, UID, USER, or USERENV SQL functions, or the pseudocolumns LEVEL or ROWNUM.

In evaluating CHECK constraints that contain string literals or SQL functions with NLS parameters as arguments (such as TO_CHAR, TO_DATE, and TO_NUMBER), ORACLE uses the database's NLS settings by default. The defaults can be overridden by specifying NLS parameters explicitly in such functions within the CHECK constraint definition. (For more information on NLS features, see Appendix A

 Multiple CHECK Constraints

A single column can have multiple CHECK constraints that reference the column in its definition. There is no limit to the number of CHECK constraints that can be defined that include a column.

________________________________________

The Mechanisms of Constraint Checking

To know what types of actions are permitted when constraints are present, it is useful to understand when ORACLE actually performs the checking of constraints. To illustrate this, an example or two is helpful. Assume the following:

•	The EMP table has been defined as illustrated in a previous example (see Figure 7 - 7  on page 7 - 14.).

•	The self-referential constraint makes the entries in the MGR column dependent on the values of the EMPNO column. For simplicity, the rest of this discussion only addresses the EMPNO and MGR columns of the EMP table.

Consider the insertion of the first row into the EMP table. No rows currently exist, so how can a row be entered if the value in the MGR column cannot reference any existing value in the EMPNO column? The three possibilities include:

•	A null can be entered for the MGR column of the first row, assuming that the MGR column does not have a NOT NULL constraint defined on it.

•	The same value can be entered in both the EMPNO and MGR columns.

•	A multiple row INSERT statement, such as an INSERT statement with nested SELECT statement, can insert rows that reference one another. For example, the first row might have EMPNO as 200 and MGR as 300, while the second row might have EMPNO as 300 and MGR as 200.

Each case reveals something about how and when ORACLE performs constraint checking.

The first case is easy to understand; a null is given for the foreign key value. Because nulls are allowed in foreign keys, this row is inserted successfully into the table.

The second case is more interesting. This case reveals when ORACLE effectively performs its constraint checking: after the statement has been completely executed. To allow a row to be entered with the same values in the parent key and the foreign key, ORACLE must first execute the statement (i.e., insert the new row) and then check to see if any row in the table has an EMPNO that corresponds to the new row's MGR.

The third case reveals even more about the constraint checking mechanism. This scenario shows that constraint checking is effectively deferred until the complete execution of the statement; all rows are inserted first, then all rows are checked for constraint violations.

As another example of this third case, consider the same self-referential integrity constraint and the following scenario:

•	The company has been sold. Because of this sale, all employee numbers must be updated to be the current value plus 5000 to coordinate with the new company's employee numbers. Because manager numbers are really employee numbers, these values must also increase by 5000.

The table currently exists as illustrated in Figure 7 - 8

Next, the following statement is issued to perform the update:

UPDATE emp

SET empno = empno + 5000,

    mgr = mgr + 5000;

Even though a constraint is defined to verify that each MGR value matches an EMPNO value, this statement is legal because ORACLE effectively performs its constraint checking after the statement completes Figure 7 - 9  shows that the actions of the entire SQL statement are performed before any constraints are checked.

The examples in this section illustrated the constraint checking mechanism during INSERT and UPDATE statements; the same mechanism is used for all types of DML statements, including UPDATE, INSERT, and DELETE statements.

The examples also used self-referential integrity constraints to illustrate the checking mechanism; however, the same mechanism is used for all types of constraints, including NOT NULL, UNIQUE key, PRIMARY KEY, all types of FOREIGN KEY, and CHECK constraints.

Default Column Values and Integrity Constraint Checking

Default values are included as part of an INSERT statement before the statement is parsed. Therefore, default column values are subject to all integrity constraint checking.


CHAPTER 8. THE DATA DICTIONARY

No dictionary of living tongue ever can be perfect, since while it is hastening to publication, some words are budding and some falling away.

Samuel Johnson: Preface to Dictionary

This chapter describes the central set of read-only reference tables and views of each ORACLE database, known collectively as the data dictionary. Topics include:

•	the definition and use of the data dictionary

•	the objects that constitute the data dictionary

•	the underlying design and naming scheme

Not only is the data dictionary central to every ORACLE database, it is an important tool for all users, from end users to application designers and database administrators. Even beginning users can benefit from understanding and using the data dictionary. However, no user should ever alter (update, delete, or insert) any rows or objects in the data dictionary; such activity can compromise data integrity.

________________________________________

An Introduction to the Data Dictionary

One of the most important parts of an ORACLE database is its data dictionary. The data dictionary is a set of tables to be used as a read-only reference, which provides information about its associated database. For example, a data dictionary can provide the following information:

•	the names of ORACLE users

•	privileges and roles each user has been granted

•	names of schema objects (tables, views, snapshots, indexes, clusters, synonyms, sequences, procedures, functions, packages, triggers, etc.)

•	information about integrity constraints

•	default values for columns

•	how much space has been allocated for, and is currently used by, the objects in a database

•	auditing information, such as who has accessed or updated various objects

•	in Trusted ORACLE, the labels of all objects and users (See the Trusted ORACLE7 Server Administrator's Guide.)

•	other general database information

The data dictionary is structured in tables and views, just like other database data. To access the data dictionary, you use SQL. Because the data dictionary is read-only, users can only issue queries (SELECT statements) against the tables and views of the data dictionary.

________________________________________

The Structure of the Data Dictionary

A database's data dictionary is comprised of:

base tables	The foundation of the data dictionary is comprised of a set of base or underlying tables that store information about the associated database. These tables are written and read by ORACLE only; they are rarely accessed directly by any type of ORACLE user because they are normalized, and most of the data is stored in a cryptic format.

user accessible views	The data dictionary contains user accessible views that summarize and conveniently display the information in the base tables of the dictionary. The views decode the information in the base tables into useful information, such as user or table names, and use joins and WHERE clauses to simplify the information. Most users are given access to the views rather than the base tables.

________________________________________

SYS, the Owner of the Data Dictionary

All base tables and user accessible views of the data dictionary are owned by the ORACLE user SYS. Therefore, no ORACLE user should ever alter any object contained in the SYS schema and the security administrator should keep strict control of this central account.

Note: Altering or manipulating the data in underlying data dictionary tables can permanently and detrimentally affect the operation of a database.

________________________________________

How the Data Dictionary Is Used

The data dictionary of an ORACLE database has two primary uses:

•	ORACLE accesses the data dictionary every time that a DDL statement is issued.

•	Any ORACLE user can use the data dictionary as a read-only reference for information about the database.

How ORACLE and Other Oracle Products Use the Data Dictionary

Data in the base tables of the data dictionary is necessary for ORACLE to function. Therefore, only ORACLE should write or change data dictionary information.

During database operation ORACLE reads the data dictionary to ascertain that objects exist and that users have proper access to them. ORACLE also updates the data dictionary continuously to reflect changes in database structures, auditing, grants, and data.

For example, if user KATHY creates a table named PARTS, new rows are added to reflect the new table, columns, segment, extents, and the privileges that KATHY has on the table. This new information is then visible the next time the dictionary views are queried.

 Caching of the Data Dictionary for Fast Access

Because the data dictionary is accessed by ORACLE constantly during database operation to validate user access and to verify the state of objects, much of the data dictionary information is cached in the SGA. All information is stored in memory using the LRU (least recently used) algorithm. Information typically kept in the caches is that required for parsing. The COMMENTS columns describing the tables and columns are not cached unless they are frequently accessed.

 Other Programs and the Data Dictionary

Other Oracle products can create additional data dictionary tables or views of their own and reference existing views. Application developers who write programs that refer to the data dictionary should refer to the public synonyms rather than the underlying tables: the synonyms are less likely to change between software releases.

 Adding New Data Dictionary Items

You can add entirely new tables or views to the data dictionary. If you add new data dictionary objects, the owner of the new objects should be the user SYSTEM or a third ORACLE user. Never create new objects belonging to user SYS, except by running script provided by Oracle Corporation for creating data dictionary objects.

 Deleting Data Dictionary Items

Because all changes to the data dictionary are performed by ORACLE in response to DDL statements, no data in any data dictionary tables should be deleted or altered by any user.

The single exception to this rule is the table SYS.AUD$. When auditing is enabled, this table can grow without bound. Although you should not drop the AUDIT_TRAIL table, the security administrator can delete data from it because the rows are for information only and are not necessary for ORACLE to run.

 Public Synonyms for Data Dictionary Views

Public synonyms are created on many data dictionary views so they can be conveniently accessed by users. The security administrator can create additional public synonyms for objects used systemwide. However, other users should avoid naming their own objects with the same names as those used for public synonyms.

How ORACLE Users Can Use the Data Dictionary

The views of the data dictionary serve as a reference for all database users. Access to the data dictionary views is via the SQL language. Certain views are accessible to all ORACLE users, while others are intended for administrators only.

The data dictionary is always available when the database is open. It resides in the SYSTEM tablespace, which is always online when the database is open.

The data dictionary consists of sets of views. In many cases, a set consists of three views containing similar information and distinguished from each other by their prefixes:

Prefix	Scope

USER	user's view (what is in the user's schema)

ALL	expanded user's view (what the user can access)

DBA	database administrator's view (what all user's can access)

The set of columns is identical across views with these exceptions:

•	Views with the prefix USER usually exclude the column OWNER; this column is implied in the USER views to be the user issuing the query.

•	Some DBA views have additional columns containing information useful to the administrator.

 Views with the Prefix USER

The views most likely to be of interest to typical database users are those with the prefix USER. These views:

•	refer to the user's own private environment in the database, including information about objects created by the user, grants made by the user, and so on

•	display only rows pertinent to the user

•	have identical columns to the other views, except that the column OWNER is implied (the current user)

•	return a subset of the information in the ALL_ views

•	can have abbreviated PUBLIC synonyms for convenience

For example, the following query returns all the objects contained in your schema:

SELECT object_name, object_type FROM user_objects;

 Views with the Prefix ALL

Views with the prefix ALL refer to the user's overall perspective of the database. These views return information about objects to which the user has access via public or explicit grants of privileges and roles, in addition to objects that the user owns. For example, the following query returns information about all the objects that you have access to:

SELECT owner, object_name, object_type FROM all_objects;

 Views with the Prefix DBA

Views with the prefix DBA show a global view of the entire database; therefore, they are meant to be queried only by database administrators. Any user granted the system privilege SELECT ANY TABLE can query the DBA-prefixed views of the data dictionary.

Synonyms are not created for these views, as the DBA views should only be queried by administrators. Therefore, to query the DBA views, administrators must prefix the view name with its owner, SYS, as in:

SELECT owner, object_name, object_type FROM sys.dba_objects;

Administrators can run the script file DBA_SYNONYMS.SQL to create private synonyms for the DBA views in their accounts, if that they have the SELECT ANY TABLE system privilege. Executing this script creates synonyms for the current user only.

 DUAL

The table named DUAL is a small table referenced by ORACLE and user-written programs to guarantee a known result. This table has one column and one row.

________________________________________

The Dynamic Performance Tables

Throughout its operation, ORACLE maintains a set of "virtual" tables that record current database activity. These tables are called dynamic performance tables.

Because dynamic performance tables are not true tables, they should not be accessed by most users. However, database administrators can query these tables and can create views on the tables and grant access to those views to other users.

The dynamic performance tables are owned by SYS and their names all begin with V_$. Views are created on these tables, and then synonyms are created for the views. The synonym names begin with V$.


PART  IV . SYSTEM ARCHITECTURE


CHAPTER 9. MEMORY STRUCTURES AND PROCESSES

Tis in my memory locked,

 And you yourself shall keep the key of it.

Shakespeare:  Hamlet

This chapter discusses the memory structures and processes in an ORACLE database system. Topics include:

•	ORACLE instances

•	single-process and multiple-process ORACLE instances

•	ORACLE memory structures

•	software areas, the System Global Area, and Program Global Areas

•	variations in ORACLE configuration

•	user processes, connections, and sessions

•	ORACLE processes

________________________________________

An ORACLE Instance

Regardless of the type of computer executing ORACLE and the particular memory and process options being used, every running ORACLE database is associated with an ORACLE instance. Every time a database is started on a database server, a memory area called the System Global Area (SGA) is allocated and one or more ORACLE processes are started. The combination of the SGA and the ORACLE processes is called an ORACLE database instance. The memory and processes of an instance work to efficiently manage the database's data and serve the one or multiple users of the associated database. Figure 9 - 1  shows an ORACLE instance.

An instance is started, then a database is mounted by the instance. Multiple instances can be executing concurrently on the same machines, each accessing its own physical database. In loosely coupled systems, the ORACLE Parallel Server is used when a single database is mounted by multiple instances; the instances share the same physical database. When Trusted ORACLE is used in OS MAC mode, a single instance can mount multiple databases.

The remaining sections of this chapter explain the memory and process structures and configurations associated with an ORACLE instance. See the ORACLE7 Parallel Server Administrator's Guide for more information about the ORACLE Parallel Server. See the Trusted ORACLE7 Server Administrator's Guide for more information about Trusted ORACLE.

________________________________________

Process Structure

A process is a "thread of control" or a mechanism in an operating system that can execute a series of steps. Some operating systems use the terms job or task. A process normally has its own private memory area in which it runs.

The process structure of a system such as ORACLE is important because it defines how multiple activities can occur and how they are accomplished. For example, two goals of a process structure might be:

•	to simulate a private environment for multiple processes to work simultaneously, as though each process has its own private environment

•	to allow multiple processes to share computer resources, which each process needs, but no process needs for long periods of time

The process architecture of ORACLE is designed to maximize performance.

Single-Process ORACLE Instance

Single-process ORACLE (also called single-user ORACLE) is a database system in which all ORACLE code is executed by one process. Different processes are not used to separate execution of the parts of ORACLE and the client application program. Instead, all code of ORACLE and the lone user's database application is executed by a single process.

Figure 9 - 2 shows a single-process ORACLE instance. The single process executes all code associated with database application and ORACLE.

An ORACLE instance in a single-process environment can be accessed by one user only; multiple users cannot access the database concurrently. For example, ORACLE running under the MS-DOS operating system on a PC can only be accessed by a single user because MS-DOS is not capable of running multiple processes.

Multiple-Process ORACLE Instance

Multiple-process ORACLE (also called multi-user ORACLE) uses several processes to execute different parts of ORACLE, and a separate process for each connected user. Each process in a multiple-process ORACLE instance performs a specific job. By dividing the work of ORACLE and database applications into several processes, multiple users and applications can simultaneously connect to a single database instance while the system maintains excellent performance. Most database systems are multi-user, because one of the primary benefits of a database is managing data needed by multiple users at the same time.

Figure 9 - 3 illustrates a multiple-process ORACLE instance. Each connected user has a separate user process and several background processes are used to execute ORACLE. This figure might represent multiple concurrent users running an application on the same machine as ORACLE; this particular configuration is usually on a mainframe or minicomputer.

In a multiple-process system, processes can be categorized into two groups: user processes and ORACLE processes. These classes of processes are explained in the following sections.

 User Processes

When a user runs an application program, such as a Pro*C program, or an ORACLE tool, such as SQL*DBA, a user process is created to run the user's application.

ORACLE Processes

In multiple-process systems, ORACLE is controlled by two types of ORACLE processes: server processes and background processes.

Server processes are created to handle the requests of user processes connected to the instance. Often, when the application and ORACLE operate on the same machine rather than over a network, a user process and its corresponding server process are combined into a single process to reduce system overhead. However, when the application and ORACLE operate on different machine, a user process communicates with ORACLE via a separate server process. (See "Variations in ORACLE Configuration" on page 9 - 26 for more information.)

Server processes (or the server portion of combined user/server processes) created on behalf of each user's application may perform one or more of the following:

•	parse and execute SQL statements issued via the application

•	read necessary data blocks from disk (data files) into the shared database buffers of the SGA, if the blocks are not already present in the SGA

•	return results in such a way that the application can process the information

To maximize performance and accommodate many users, a multiprocess ORACLE system uses some additional ORACLE processes called background processes. On many operating systems, background processes are created automatically when an instance is started. On other operating systems, the server processes are created as a part of the ORACLE installation. See your installation or user's guide for details on how these processes are created.

An ORACLE instance may have a large number of background processes; not all are always present. The names of the background processes in an ORACLE instance are:

•	Database Writer (DBWR)

•	Log Writer (LGWR)

•	Checkpoint (CKPT)

•	System Monitor (SMON)

•	Process Monitor (PMON)

•	Archiver (ARCH)

•	Recoverer (RECO)

•	lock (LCKn)

•	dispatcher (Dnnn)

•	server (Snnn)

Each background process's interaction with the different parts of an ORACLE database is illustrated in Figure 9 - 4, and each process is described in detail in the following sections. The Parallel Server is not illustrated; see the ORACLE7 Parallel Server Administrator's Guide.

Database Writer (DBWR)      All the writing of buffers to data files is performed by the Database Writer process (DBWR), an ORACLE background process responsible for buffer cache management. (For more information about the database buffer cache, see page 9 - 16.) When a buffer in the buffer cache is modified, it is marked "dirty"; the primary job of the DBWR process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers in the cache are filled from the database and dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWR manages the buffer cache so that user processes can always find free buffers.

A LRU (least recently used) algorithm keeps the most recently used data blocks in memory, and thereby minimizes I/O. Blocks that are used often, for example, blocks that are part of frequently accessed small tables or indexes, are kept in the cache so that they do not need to be read in again from disk. Blocks that are accessed infrequently, for example, blocks that are part of very large tables or leaf blocks from very large indexes, are removed from the SGA if they have not been modified since they were read, and are written to disk after they have been modified to make room in the buffer cache for other blocks. The LRU scheme causes more frequently accessed blocks to stay in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon. However, if the DBWR process becomes too active it may write blocks to disk that are about to be needed again.

The DBWR process is signalled to write dirty buffers to disk under these conditions:

•	When a server process moves a buffer to the dirty list and discovers that the dirty list has reached a threshold length, the server process signals DBWR to write. The threshold length is defined to be one half of the value of the parameter DB_BLOCK_WRITE_BATCH.

•	When a server process searches DB_BLOCK_MAX_SCAN_- CNT buffers in the LRU list without finding a free buffer, it stops searching and signals DBWR to write (because not enough free buffers are available and DBWR must make room for more).

•	When a time-out occurs (every three seconds), DBWR signals itself.

•	When a checkpoint occurs, the Log Writer process (LGWR) signals DBWR.

In the first two cases, DBWR writes the blocks on the dirty list to disk with a single multiblock write. The number of blocks written in a multiblock write is specified by the initialization parameter DB_BLOCK_WRITE_BATCH. If the dirty list does not have DB_BLOCK_WRITE_BATCH buffers when DBWR is signalled, DBWR searches the LRU list for additional dirty buffers.

A time-out occurs if DBWR is inactive for three seconds. In this case, DBWR searches a specified number of buffers on the LRU list and writes any dirty buffers that it finds to disk. Whenever a time-out occurs, DBWR searches a new set of buffers. The number of buffers searched by DBWR at each time-out is twice the value of the initialization parameter DB_BLOCK_WRITE_BATCH. If the database is idle, DBWR eventually writes the entire buffer cache to disk.

When a checkpoint occurs, the Log Writer process (LGWR) specifies a list of modified buffers that must be written to disk. DBWR writes the specified buffers to disk. For more information about checkpoints, see "Checkpoints" on page 23 - 9.

On some platforms, an instance can have multiple DBWRs. In such an instance, if one DBWR blocks during a write to one disk the others can continue writing to other disks. The parameter DB_WRITERS controls the number of DBWR processes. See your installation or user's guide for information about DBWR on your platform.

For more information about DBWR and how to monitor and tune the performance of DBWR, see the ORACLE7 Server Administrator's Guide.

Log Writer (LGWR)      The redo log buffer is written to a redo log file on disk by the Log Writer process (LGWR), an ORACLE background process responsible for redo log buffer management. The LGWR process writes all redo entries that have been copied into the buffer since the last time it wrote. LGWR writes one contiguous portion of the buffer to disk. LGWR writes:

•	a commit record when a user process commits a transaction

•	redo buffers every three seconds

•	redo buffers when the redo log buffer is one-third full

•	redo buffers when the DBWR process writes modified buffers to disk

Note: LGWR writes synchronously to the active mirrored group of online redo log files. If one of the files in the group is damaged or unavailable, LGWR can continue to write to other files in the group (an error is also logged in the LGWR trace file and in the system ALERT file). If all files in a group are damaged, or the group is unavailable because it has not been archived, LGWR cannot continue to function. See "The Online Redo Log" on page 23 - 6 for more information about mirrored online redo logs and how LGWR functions in this configuration.

The redo log buffer (see "The Redo Log Buffer" on page 9 - 33) is a circular buffer; when LGWR writes redo entries from the redo log buffer to a redo log file, server processes can then copy new entries over the entries in the redo log buffer that have been written to disk. LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries, even when access to the redo log is heavy.

Note: Sometimes, if more buffer space is needed, LGWR writes redo log entries before a transaction is committed. These entries become permanent only if the transaction is later committed.

ORACLE uses a "fast commit" mechanism; when a user issues a COMMIT statement, a commit record is immediately put in the redo log buffer, but the corresponding data buffer changes are deferred until it is more efficient to write them to the data files. The atomic write of the redo entry containing the commit record for a transaction is the single event that determines the transaction has committed (then a success code is returned to the committing transaction).

When a transaction is committed, it is assigned a system change number (SCN), which is recorded along with the transaction's redo entries in the redo log. SCNs are recorded in the redo log so that recovery operations can be synchronized in Parallel Server configurations and distributed databases. (See the ORACLE7 Parallel Server Administrator's Guide and the ORACLE7 Server Administrator's Guide for more information about SCNs and how they are used.)

In times of high activity, LGWR may write to the online redo log file using group commits. For example, assume that a user commits a transaction-LGWR must write the transaction's redo entries to disk. As this happens, other users issue a COMMIT statement; however, LGWR cannot write to the online redo log file to commit these transactions until it has completed its previous write operation. After the first transaction's entries are written to the online redo log file, the entire list of redo entries of waiting transactions (not yet committed) can be written to disk in one operation, requiring less I/O than would transaction entries handled individually. Therefore, disk I/O is minimized and database performance with respect to the redo log is maximized. If requests to commit continue at a high rate, then every write (by LGWR) from the redo log buffer may contain multiple commit records, averaging less than one write per COMMIT.

If the CKPT background process is not present, LGWR is also responsible for recording checkpoints as they occur in every data file's header. (See "Checkpoint (CKPT)" below for more information about this background process.)

Checkpoint (CKPT)      When a checkpoint occurs, the headers of all data files must be updated to indicate the checkpoint. In normal situations, this job is performed by LGWR. However, if checkpoints significantly degrade system performance (usually, when there are many data files), you can enable the Checkpoint process (CKPT) to separate the work of performing a checkpoint from other work performed by LGWR, the Log Writer process (LGWR).

For most applications, the CKPT process is not necessary. If your database has a large number of data files and the performance of the LGWR process is reduced significantly during checkpoints, you may want to enable the CKPT process.

The CKPT process does not write blocks to disk; that work is always done by DBWR. The statistic dbwr checkpoints displayed by the SQL*DBA monitor STATISTIC indicates the number of checkpoint messages completed, regardless of whether the CKPT process is enabled or not. See the ORACLE7 Server Administrator's Guide for information about the effects of changing the checkpoint interval.

The initialization parameter CHECKPOINT_PROCESS enables and disables the CKPT process; its default is FALSE.

Note: See the ORACLE7 Parallel Server Administrator's Guide for additional information about CKPT with this configuration of ORACLE.

System Monitor (SMON)   The System Monitor process (SMON) performs instance recovery at instance start up. SMON is also responsible for cleaning up temporary segments that are no longer in use; it also coalesces contiguous free extents, to make larger blocks of free space available. In a Parallel Server environment, SMON performs instance recovery for a failed CPU or instance; see the ORACLE7 Parallel Server Administrator's Guide for more information about SMON in this configuration of ORACLE.

SMON "wakes up" regularly to check whether it is needed and can be called if another process detects the need for SMON.

Process Monitor (PMON)   The Process Monitor (PMON) performs process recovery when a user process fails. PMON is responsible for cleaning up the cache and freeing resources that the process was using. For example, it resets the status of the active transaction table, releases locks, and removes the process ID from the list of active processes.

PMON also periodically checks the status of dispatcher and server processes, and restarts any that have died (but not any that ORACLE has killed intentionally).

Like SMON, PMON "wakes up" regularly to check whether it is needed, and can be called if another process detects the need for it.

Recoverer (RECO)   The Recoverer process (RECO) is a process used with the distributed option that automatically resolves failures involving distributed transactions. The RECO background process of a node automatically connects to other databases involved in an in-doubt distributed transaction. When a connection between involved database servers is reestablished, the RECO processes automatically resolve all in-doubt transactions. Rows corresponding to any resolved in-doubt transactions are automatically removed from each database's pending transaction table.

If the RECO background process of a database server attempts to establish communication with a remote server, and the remote server is not available or the network connection has not been reestablished, RECO will automatically try to connect again after a timed interval. However, RECO waits an increasing amount of time (growing exponentially) before it attempts another connection.

For more information about distributed transaction recovery, see "Failures During Two-Phase Commit" on page 22 - 20.

The RECO background process of an instance is only present if the system permits distributed transactions and if the DISTRIBUTED_- TRANSACTIONS parameter is greater than zero. If this parameter is set to zero, RECO is not created during instance startup.

Archiver  (ARCH)    The Archiver process (ARCH) copies online redo log files to a designated storage device once they become full. ARCH is present only when the redo log is used in ARCHIVELOG mode and automatic archiving is enabled. For information on archiving the online redo log, see Chapter 23C. Details of using ARCH are operating system specific; for more information, see Chapter 23 and your installation or user's guide.

Lockn (LCK)   When the Parallel Server option is used, up to ten Lock processes (LCK0, . . ., LCK9) are used for inter-instance locking; however, a single LCK process (LCK0) is sufficient for most Parallel Server systems. See the ORACLE7 Parallel Server Administrator's Guide for more information about this background process.

Dispatcher Processes (Dnnn)   The Dispatcher processes allow user processes to share a limited number of server processes. Without a dispatcher, each user process requires one dedicated server process; however, with the multi-threaded server, fewer shared server processes are required for the same number of users. Therefore, in a system with a large number of users, the multi-threaded server can support a greater number of users, particularly in client-server environments where the client application and server operate on different machines.

Multiple dispatcher processes can be created for a single database instance; at least one dispatcher must be created for each network protocol by which users will communicate with ORACLE. The database administrator should start an optimal number of dispatcher processes depending on the operating system limitation on the number of connections per process, and can add and remove dispatcher processes while the instance runs.

Note: The multi-threaded server requires SQL*Net Version 2 or later. Each user process that connects to a dispatcher must do so through SQL*Net, even if both processes are running on the same machine.

In a multi-threaded server configuration, a network listener process waits for connection requests from client applications, and routes each to a dispatcher process. If it cannot connect a client application to a dispatcher, the listener process starts a dedicated server process, and connects the client application to the dedicated server. This listener process is not part of an ORACLE instance; rather it is part of the networking processes that work with ORACLE. (See your SQL*Net documentation for more information about the network listener.)

When an instance starts, the listener opens and establishes a communication pathway through which users connect to ORACLE. Then, each dispatcher gives the listener an address at which the dispatcher listens for connection requests. When a user process makes a connection request, the listener process examines the request and determines if the user can use a dispatcher. If so, the listener process returns the address of the dispatcher process with the lightest load and the user process directly connects to the dispatcher.

Some user processes cannot communicate with the dispatcher (such as users connected using pre-Version 2 SQL*Net) and the network listener process cannot connect such users to a dispatcher. In this case, the listener creates a dedicated server and establishes an appropriate connection.

 Trace Files, the ALERT File, and Background Processes

Each server and background process can write to an associated trace file. When an internal error is detected by a process, it dumps information about the error to its trace file. If an internal error occurs and information is written to a trace file, the administrator should contact Oracle support. (See the ORACLE7 Server Messages and Codes Manual.)

Trace file information can also provide information for tuning applications or an instance. Background processes always write to a trace file when appropriate. However, trace files are written on behalf of server processes (in addition to being written to when there is an internal error) only if the initialization parameter SQL_TRACE is set to TRUE. Regardless of the current value for this parameter, each session can enable or disable trace logging on behalf of the associated server process by using the SQL command ALTER SESSION with the SQL_TRACE parameter. For example, the following statement enables writing to a trace file for the session:

ALTER SESSION SET SQL_TRACE = TRUE;

Each database also has an ALERT file. The ALERT file of a database is a chronological log of messages and errors, including:

•	all internal errors (ORA-600), block corruption errors (ORA-1578), and deadlock errors (ORA-60) that occur

•	administrative operations, such as CREATE/ALTER/DROP DATABASE/TABLESPACE/ROLLBACK SEGMENT SQL statements and STARTUP, SHUTDOWN, ARCHIVE LOG, and RECOVER SQL*DBA statements

•	several messages and errors relating to the functions of shared server and dispatcher processes

•	errors during the automatic refresh of a snapshot

ORACLE uses the ALERT file to keep a log of these special operations as an alternative to displaying such information on an operator's console (although many systems display information on the console). If an operation is successful, a message is written in the ALERT file as "completed" along with a timestamp.

________________________________________

ORACLE Memory Structures

ORACLE uses memory to store the following information:

•	program code being executed

•	information about a connected session, even if it is not currently active

•	data needed during program execution (for example, the current state of a query from which rows are being fetched)

•	information which is shared and communicated among ORACLE processes (for example, locking information)

•	cached information which is also permanently stored on peripheral memory (for example, a data block)

The basic memory structures associated with ORACLE include:

•	software code areas

•	the system global area

•	the database buffer cache

•	the redo log buffer

•	the shared pool

•	program global areas

•	stack areas

•	data areas

•	sort areas

The following sections explain each in detail.

Virtual Memory

On many operating systems, ORACLE takes advantage of virtual memory. Virtual memory is an operating system feature which offers more apparent memory than is provided by real memory alone and more flexibility in using main memory.

Virtual memory simulates memory using a combination of real (main) memory and secondary storage (usually disk space). The operating system accesses virtual memory by making secondary storage look like main memory to application programs.

Note: Usually, it is best to keep the entire SGA in real memory. The software and other parts of ORACLE can use virtual memory.

Software Code Areas

Software code areas are portions of memory used to store code that is being or may be executed. The code for ORACLE is stored in a software area, which is typically at a location different than users' programs-a more exclusive or protected location.

 Size of Software Areas

Software areas are usually static in size, only changing when software is updated or reinstalled. The size required varies by operating system.

Read-Only, Shared and Non-Shared

Software areas are read-only and may be installed shared or non-shared. When possible, ORACLE code is shared so that all ORACLE users can access it without having multiple copies in memory. This results in a saving of real main memory, and improves overall performance.

User programs can be shared or non-shared; some ORACLE tools and utilities can be installed shared (SQL*Forms, SQL*Plus, etc.) and some cannot. Multiple instances of ORACLE can use the same ORACLE code area with different databases if running on the same computer. However, installing software shared is not an option for all operating systems. For example, it is not on PCs operating MS-DOS. See your installation or user's guide for more information.

System Global Area (SGA)

A System Global Area(SGA) is a group of shared memory structures allocated by ORACLE that contain data and control information for one ORACLE database instance. If multiple users are concurrently connected to the same instance, the data in the instance's SGA is "shared" among the users. Consequently, the SGA is often referred to as either the "System Global Area" or the "Shared Global Area."

As described in "An ORACLE Instance" on page 9 - 2, an SGA and ORACLE processes constitute an ORACLE instance. Memory for an SGA is automatically allocated when an instance is started and reclaimed when the instance is shutdown. Each instance that is started has its own SGA.

The SGA is a shared memory area; all users connected to a multiple-process database instance may use information contained within the instance's SGA. The SGA is also writable; it is written to by several processes during execution of ORACLE.

The information stored within an SGA is divided into several areas of memory, including:

•	the database buffer cache

•	the redo log buffer

•	the shared pool

•	request and response queues (if multi-threaded server is used)

•	the data dictionary cache

•	other miscellaneous information

The Database Buffer Cache

A portion of the SGA is a cache that holds database information. The buffers in the buffer cache hold copies of the data blocks read from data files. The buffers are shared by all ORACLE user processes concurrently connected to the instance

Organization of the Buffer Cache   The buffers in the cache are organized in two lists: the dirty list and the least-recently-used (LRU) list. The dirty list holds dirty buffers. A dirty buffer is a buffer that has been modified but has not yet been written to disk. The least-recently-used (LRU) list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the dirty list. Free buffers are buffers that have not been modified and are available for use. Pinned buffers are buffers that are currently being accessed.

When an ORACLE process accesses a buffer, the process moves the buffer to the most-recently-used (MRU) end of the LRU list. As more buffers are continually moved to the MRU end of the LRU list, dirty buffers "age" towards the LRU end of the LRU list.

When a user process needs to access a block that is not already in the buffer cache, the process must read the block from a data file on disk into a buffer in the cache. Before reading a block into the cache, the process must first find a free buffer. The process searches the LRU list, starting at the least-recently-used end of the list. The process searches either until it finds a free buffer or until it has searched the number of buffers specified by the parameter DB_BLOCK_MAX_SCAN_CNT.

As a user process searches the LRU list, it may find dirty buffers. If the user process finds a dirty buffer, it moves the buffer to the dirty list and continues to search. When a user process finds a free buffer, it reads the block into the buffer and moves it to the MRU end of the LRU list.

Note: In one particular case, the user process puts the newly-read block's buffer on the LRU end of the list; when the process is performing a full table scan of any but a very small table, the blocks for the table are read and put in buffers on the LRU end of the list. This is because a fully-scanned table will most likely be needed only briefly, so the blocks should be moved out quickly to leave more frequently-used blocks in the cache. The parameter SMALL_TABLE_THRESHOLD sets the limit for whether a table is small enough to have its blocks put on the MRU end of the list.

If an ORACLE user process searches DB_BLOCK_MAX_SCAN_CNT buffers without finding a free buffer, the process stops searching the LRU list and signals the DBWR process to write some of the dirty buffers to disk. See "Database Writer (DBWR)" on page 9 - 7 for more information about the DBWR background process.

Size of the Buffer Cache   The number of buffers in the cache of an instance's SGA is specified by the initialization parameter DB_BLOCK_BUFFERS. Each buffer in the cache is the size of one data block (specified by the initialization parameter is DB_BLOCK_SIZE); therefore, each database buffer in the cache can hold a single data block read from a data file.

The first time a piece of data is accessed by an ORACLE user process, the process must copy the data from disk to the cache before accessing it. This is called a cache miss. When a process accesses a piece of data that is already in the cache, the process can read the data directly from memory. This is called a cache hit. Accessing data through a cache hit is faster than data access through a cache miss.

Since the cache has a limited size, all the data on disk cannot fit in the cache. When the cache is full, subsequent cache misses cause ORACLE to write data already in the cache to disk to make room for the new data. Subsequent access to the data written to disk results in a cache miss.

The size of the cache affects the likelihood that a request for data will result in a cache hit. If the cache is large, it is more likely to contain the data that is requested. Increasing the size of a cache increases the percentage of data requests that result in cache hits.

 The Redo Log Buffer

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations; redo entries are used for database recovery, if necessary

Redo entries are copied by ORACLE server processes from the user's memory space to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The redo log buffer is written to the active online redo log file group on disk by the background process LGWR. See "Log Writer (LGWR)" on page 9 - 9 for more information about how the redo log buffer is written to disk.

Size of the Redo Log Buffer   The size of redo log buffer is determined by the setting (in bytes) for the initialization parameter LOG_BUFFER. In general, larger values reduce log file I/O, particularly if transactions are long or numerous. The default setting is four times the maximum data block size for the host operating system.

The Shared Pool

The shared pool is an area in the SGA that contains constructs such as shared SQL areas and the data dictionary cache. Each of these constructs is discussed in the following sections

Shared SQL Areas and Private SQL Areas   ORACLE represents each SQL statement it executes with a shared part (a shared SQL area) and a private part (a private SQL area). ORACLE recognizes when two users are executing the same SQL statement and reuses the same shared part for those users. However, each user must have a separate copy of the statement's private part.

A shared SQL area is a memory area that contains the parse tree and execution plan for a single SQL statement. The size of a shared SQL area is computed when the statement is parsed and depends on the complexity of the statement. A shared SQL area is always in the shared pool and is shared for identical SQL statements. For more information about the criteria used to determine identical SQL statements, see "Shared SQL" on page 11 - 5.

A private SQL area is a memory area that contains data such as binding information and run-time buffers. Each session that issues a SQL statement has a private SQL area. Each user that submits an identical SQL statement has his/her own private SQL area that uses a single shared SQL area; many private SQL areas can be associated with the same shared SQL area.

A private SQL area is further segmented into a persistent area and a run-time area:

persistent area	The persistent area contains binding information that persists across executions. The size of the persistent area is constant and depends on the number of binds and columns specified in the statement. For example, the persistent area is larger if many columns are specified in a query.

runtime area	The runtime area contains information used while the SQL statement is being executed. The size of the runtime area depends on the type and complexity of the SQL statement being executed, and on the sizes of the rows that are processed by the statement. In general the runtime area is somewhat larger for INSERT, UPDATE, and DELETE statements than it is for SELECT statements. For INSERT, UPDATE, and DELETE statements, the runtime area is freed after the statement has been executed. For queries, the runtime area is freed only after all rows are fetched or the query is canceled.

A private SQL area continues to exist until the corresponding cursor is closed. Since the runtime area is freed after the statement completes, generally only the persistent area remains waiting. When developing applications, close all open cursors that will not be used again to minimize the amount of memory required for users of the application.

The location of a private SQL area varies depending on the type of connection established for a session. If a session is connected via a dedicated server, private SQL areas are located in the user's PGA. However, if a session is connected via the multi-threaded server, the persistent areas, and, for SELECT statements, the runtime areas, are kept in the SGA.

How the User Process Manages Private SQL Areas      The management of private SQL areas is the responsibility of the user process. The allocation and deallocation of private SQL areas depends largely on which application tool you are using, although the number of private SQL areas that a user process can allocate is always limited by the initialization parameter OPEN_CURSORS. The default value of this parameter is 50.

How ORACLE Manages Shared SQL Areas      Since shared SQL areas must be available to multiple users, the library cache is contained in the shared pool within the SGA. The size of the library cache, along with the size of the data dictionary cache, is limited by the size of the shared pool. Memory allocation for shared SQL areas is determined by the initialization parameter SHARED_POOL_SIZE. This parameter determines the amount of space in the SGA allocated to the shared pool. Since the library cache is contained in the shared pool, this parameter specifies the amount of space available to the library cache. The default value for this parameter is 3.5 megabytes.

If a user process tries to allocate a shared SQL area after the entire shared pool has been allocated, ORACLE can deallocate items from the pool using a modified least-recently-used algorithm until there is enough free space for the new item. If a shared SQL area is deallocated, the associated SQL statement must be reparsed and reassigned to another shared SQL area when it is next executed.

PL/SQL Program Units and the Shared Pool      The processing of PL/SQL program units (procedures, functions, packages, anonymous blocks, and database triggers) is performed by ORACLE in a manner analogous to the processing of individual SQL statements. A shared SQL area is allocated to hold the parsed, compiled form of a program unit. A private SQL area is allocated to hold values specific to the session that executes the program unit, including local variable values. If more than one user is simultaneously executing the same program unit, then a single, shared SQL area is utilized by all users, while each user maintains a separate copy of his private SQL area, holding values specific to his session.

Individual SQL statements contained within a PL/SQL program unit are processed as described in the previous sections. Despite their origins within a PL/SQL program unit, these SQL statements utilize a shared SQL area to hold their parsed representations and a private SQL area for each session that executes the statement.

The single, shared SQL area utilized by a PL/SQL program unit is often called a "parent cursor" to distinguish it from the shared SQL areas utilized by SQL statements within that program unit, called "child cursors."

The Data Dictionary Cache   The data dictionary is a collection of database tables and views containing reference information about the database, its structures, and its users. Among the data stored in the data dictionary are the following:

•	names of all tables and views in the database

•	names and datatypes of columns in database tables

•	privileges of all ORACLE users

This information is useful as reference material for DBAs, application designers, and end users alike. The data dictionary is also accessed frequently by ORACLE itself during the parsing of SQL statements. This access is essential to the continuing operation of ORACLE. (See Chapter 8 for more information on the data dictionary.)

Since the data dictionary is accessed so often by ORACLE, a special location in memory is designated to hold dictionary data. This area is called the data dictionary cache, or sometimes the row cache. The data dictionary cache is shared by all ORACLE user processes.

The data dictionary cache is contained in the shared pool within the SGA. Its size, along with the size of the library cache, is limited by the size of the shared pool.

Allocation and Reuse of Memory in the Shared Pool      In general, any item (shared SQL area or dictionary row) in the shared pool remains present until it is flushed according to a modified LRU algorithm; the memory for items not being regularly used is freed if space is required for new items that must be allocated some space in the shared pool. By using a modified LRU algorithm, shared pool items that are shared by many sessions can remain in memory as long as they are useful, even if the process which originally created the item is terminated. As a result, the overhead and processing of SQL statements associated with a multi-user ORACLE is kept to a minimum.

When a SQL statement is submitted to ORACLE for execution, there are some special steps to consider. On behalf of every SQL statement, ORACLE automatically performs the following memory allocation steps:

1..	A private SQL area is allocated on behalf of the session. The exact location of the private SQL area depends on the connection (see previous section).

2..	ORACLE checks the shared pool to see if a shared SQL area already exists for an identical statement. If there is already a shared SQL area for the statement, it is used for the execution of the subsequent new instances of the statement. Therefore, instead of having multiple shared SQL areas for identical SQL statements, only one shared SQL area exists for multiple identical DML statements, greatly saving memory, particularly when many users execute the same application.

Alternatively, if there is not a shared SQL area for a statement, a new shared SQL area is allocated in the shared pool. In either case, the user's private SQL area is associated with the shared SQL area that contains the statement.

Note: A shared SQL area can be flushed from the shared pool, even if the shared SQL area corresponds to an open cursor that

has not been used for some time. If the open cursor is subsequently used to execute its statement, the statement is reparsed an a new shared SQL area is allocated in the shared pool.

Some unique circumstances can also cause a shared SQL area to be flushed from the shared pool. When the ANALYZE command is used to update or delete the statistics of a table, cluster, or index, all shared SQL areas that contain statements that reference the analyzed object are flushed from the shared pool. The next time a flushed statement is executed, the statement is parsed in a new shared SQL area to reflect the new statistics for the object. Shared SQL areas are also dependent on the objects referenced in the corresponding SQL statement. If a referenced object is modified, the shared SQL area is invalidated (marked invalid) and must be reparsed the next time the statement is executed. See Chapter 16 for more information about the invalidation of SQL statements and dependency issues.

If you change a database's global database name, all information is flushed from the shared pool. If desired, the administrator can manually flush all information in the shared pool to assess the performance (with respect to the shared pool, not the data buffer cache) that can be expected after instance startup without shutting down the current instance.

Cursors      The application developer of an ORACLE Precompiler program or OCI program can explicitly open cursors, or handles to specific private SQL areas, and use them as a named resource throughout the execution of the program. Each user session can open any number of cursors up to the limit set by the initialization parameter OPEN_CURSORS. However, applications should close unneeded cursors to conserve system memory. If a cursor cannot be opened due to a limit on the number of cursors, the database administrator can alter the OPEN_CURSORS initialization parameters. For more information about cursors, see page 11 - 5.

Some statements (primarily DDL statements) require ORACLE to implicitly issue recursive SQL statements, which also require recursive cursors. For example, a CREATE TABLE statement causes many updates to various data dictionary tables to record the new table and columns. Recursive calls are made for those recursive cursors; one cursor may execute several recursive calls. These recursive cursors also utilize shared SQL areas.

Size of the Shared Pool      The total size of the shared pool is determined by the initialization parameter SHARED_POOL_SIZE. Increasing the value of this parameter increases the amount of memory reserved for the shared pool, and therefore the space reserved for shared SQL areas.

 Other SGA Information

Information also stored in the SGA includes the following:

•	information communicated between processes, such as locking information

•	when an instance is running the multi-threaded server, some contents of the program global areas, and the request and response queues are in the SGA (See "The Program Global Area" on page 9 - 24, and "Dispatcher Request and Response Queues" on page  9 - 33.)

The amount of memory dedicated to all shared areas in the SGA can have performance impact; see the ORACLE7 Server Administrator's Guide for more information.

Size of the SGA

The size of the SGA is determined at instance start up. For optimal performance in most systems, the entire SGA should fit in real memory. If the entire SGA does not fit in real memory and virtual memory is used to store parts of the SGA, overall database system performance can decrease dramatically because portions of the SGA are paged (written to and read from disk) by the operating system.

The primary determinants of the size of the SGA are the parameters found in a database's parameter file. The parameters that most affect SGA size are the following:

DB_BLOCK_SIZE	the size, in bytes, of a single data block and database buffer

DB_BLOCK_BUFFERS	the number of database buffers, each the size of DB_BLOCK_SIZE, allocated for the SGA (The total amount of space allocated for the database buffer cache in the SGA is DB_BLOCK_SIZE times DB_BLOCK_BUFFERS.)

LOG_BUFFER	the number of bytes allocated for the redo log buffer

SHARED_POOL_SIZE	the size, in bytes, of the area devoted to shared SQL and PL/SQL statements

The memory allocated for an instance's SGA is displayed on instance startup when using SQL*DBA. You can also see the current instance's SGA size using the SQL*DBA command SHOW and the SGA option. (See the ORACLE7 Server Utilities User's Guide for more information about the SQL*DBA command SHOW, and the ORACLE7 Server Administrator's Guide for discussions of the above initialization parameters and how they affect the SGA. See your installation or user's guide for information specific to your operating system.)

Part of the SGA contains general information about the state of the database and the instance, which the background processes need to access; this is called the fixed SGA. No user data is stored here.

Program Global Area (PGA)

The Program Global Area (PGA) is a memory region that contains data and control information for a single process (server or background). Consequently, the PGA is referred to as the "Program Global Area" or the "Process Global Area."

 Contents of a PGA

A PGA is allocated by ORACLE when a user process connects to an ORACLE database and a session is created, though this varies by operating system and configuration. (See page 9 - 27 for more information about sessions.) The contents of a PGA vary, depending on whether or not the associated instance is running the multi-threaded server. Figure 9 - 5 summarizes these differences.

Stack Space      A PGA always contains a stack space, which is memory allocated to hold a session's variables, arrays, and other information.

Session Information   A PGA in an instance running without the multi-threaded server requires additional memory for the user's session, such as private SQL areas and other information. If the instance is running the multi-threaded server, this extra memory is not in the PGA, but is instead allocated in the SGA.

Shared SQL Areas      Shared SQL areas are always in shared memory areas of the SGA (not the PGA), with or without the multi-threaded server.

 Non-Shared and Writable

The PGA is non-shared memory area to which a process can write. One PGA is allocated for each server process; the PGA is exclusive to a server process and is read and written only by ORACLE code acting on behalf of that process.

 Size of a PGA

A PGA's size is operating system specific, and not dynamic. When the client and server are on different machines, the PGA is allocated on the database server at connect time; if sufficient memory is not available to connect, an error occurs. This error is an ORACLE error in an operating system error number range. Once connected, a user can never run out of PGA space; there is either enough or not enough memory to connect in the first place.

The following initialization parameters affect the sizes of PGAs:

•	OPEN_LINKS

•	DB_FILES

•	LOG_FILES

The size of the stack space in each PGA created on behalf of ORACLE background processes (such as DBWR and LGWR) is affected by some additional parameters. See your installation or user's guide for more information.

Sort Areas

Sorting requires space in memory. Portions of memory in which ORACLE sorts data are called sort areas. A sort area exists in the memory of an ORACLE user process that requests a sort. A sort area can grow to accommodate the amount of data to be sorted but is limited by the value of the initialization parameter SORT_AREA_SIZE. The value of this parameter is expressed in bytes. The default value varies depending on your operating system.

During the course of a sort, ORACLE may perform some tasks that do not involve referencing data in the sort area. In such cases, ORACLE may decrease the size of the sort area by writing some of the data to a temporary segment on disk and then deallocating the portion of the sort area that contained that data. Such deallocation may occur, for example, if ORACLE returns control to the application. The size to which the sort area is reduced is determined by the initialization parameter SORT_AREA_RETAINED_SIZE. The value of this parameter is expressed in bytes. The minimum value is 0, the maximum and default value is the SORT_AREA_SIZE value.

If the amount of data to be sorted does not fit into a sort area, then the data is divided into smaller pieces that do fit. Each piece is then sorted individually. The individual sorted pieces are called "runs". After sorting all the runs, ORACLE merges them to produce the final result.

________________________________________

Variations in ORACLE Configuration

All connected ORACLE users must execute two modules of code to access an ORACLE database instance:

application or ORACLE tool	A database user executes a database application (such as a precompiler program) or an ORACLE tool (such as a SQL*Forms application) which issues SQL statements to an ORACLE database.

ORACLE server code	Each user has some ORACLE server code executing on his/her behalf, which interprets and processes the application's SQL statements.

In a multiple-process instance, the code for connected users can be configured in one of three variations:

•	For each user, both the database application and the ORACLE server code are combined in a single user process.

•	For each user, the database application is run by a different process (a user process) than the one that executes the ORACLE server code (a dedicated server process). This configuration is called the dedicated server architecture.

•	The database application is a different process (a user process) than the one that executes the ORACLE server code. Furthermore, each server process that executes ORACLE server code (a shared server process) can serve multiple user processes. This configuration is called the multi-threaded server architecture.

Some operating systems offer a choice of configurations; see your installation or user's guide for more details on your options. The following sections describe each variation in more detail.

Connections, Sessions, and User Processes

Before describing the variations in ORACLE configurations, it is useful to introduce the terms "connection" and "session," which are related to the term "user process" (see page 9 - 27), but are very different in meaning.

A connection is a communication pathway between a user process and an ORACLE instance. A communication pathway is established using available inter-process communication mechanisms (on a computer which executes both the user process and ORACLE) or network software (when different computers execute the database application and ORACLE, and communicate via a network).

A session is specific connection of a user to an ORACLE instance via a user process; for example, when a user starts SQL*Plus, the user must provide a valid username and password and then a session is established for the user. A session lasts from the time the user connects until the time the user disconnects (or exits the database application).

Multiple sessions can be created and concurrently exist for a single ORACLE user; for example, a user with the username/password of SCOTT/TIGER can connect to the same ORACLE instance several times using the same username.

When the multi-threaded server is not used, a server process is created on behalf of each user session; however, when the multi-threaded server is used, a single server process can be shared among many user sessions; each of the following sections describes the relationship of sessions and processes with respect to the configuration variations.

ORACLE Using Combined User/Server Processes

Figure 9 - 6 illustrates one configuration of ORACLE. Notice that in this configuration, the database application and the ORACLE server code all run in the same process, termed a user process.

This configuration of ORACLE (sometimes called single-task ORACLE) is only feasible in operating systems that can maintain a separation between the database application and the ORACLE code in a single process (such as on the VAX VMS operating system). This separation is required for data integrity and privacy. Some operating systems, such as UNIX, cannot provide this separation and thus must have separate processes run application code from server code to prevent damage to ORACLE by the application.

Note: The program interface is responsible for the separation and protection of the ORACLE server code and is responsible for passing data between the database application and the ORACLE user program. See "The Program Interface" on page 9 - 37 for more information about this structure.

Only one ORACLE connection is allowed at any time by a process using the above configuration. However, in a user-written program it is possible to maintain this type of connection while concurrently connecting to ORACLE using a network (SQL*Net) interface.

ORACLE Using Dedicated Server Processes

Figure 9 - 7      illustrates ORACLE running on two computers using the dedicated server architecture.

Notice that in this type of system, the database application is executed by a user process on one machine and the associated ORACLE server code is executed by a server process on another machine; these two processes are separate, distinct processes. The separate server process created on behalf of each user process is called a dedicated server process (or shadow process) because this server process acts only on behalf of the associated user process. In this configuration (sometimes called two-task ORACLE), every user process connected to ORACLE has a corresponding dedicated server process. Therefore, there is a one-to-one ratio between the number of user processes and server processes in this configuration. Even when the user is not actively making a database request, the dedicated server process remains (though it is inactive and may be paged out on some operating systems).

The dedicated server architecture of ORACLE allows client applications being executed on client workstations to communicate with another computer running ORACLE across a network. This is illustrated in Figure 9 - 7.. However, this configuration of ORACLE is also used if the same computer executes both the client application and the ORACLE server code, but the host operating system cannot maintain the separation of the two programs if they were to be run in a single process. A common example of such an operating system is UNIX.

The program interface allows the communication between the two programs. In the dedicated server configuration, communications between the user and server processes is accomplished using different mechanisms:

•	If the system is configured so that the user process and the dedicated server process are run by the same computer, the program interface uses the host operating system's inter-process communication mechanism to perform its job.

•	If the user process and the dedicated server process are executed by different computers, the program interface also encompasses the communication mechanisms, such as the network software and SQL*Net, between the programs. These communications links are operating system and installation dependent; see your installation or user's guide and SQL*Net documentation for more information.

See "The Program Interface" on page 9 - 37 for additional information about the program interface.

The Multi-Threaded Server

The multi-threaded server configuration allows many user processes to share very few server processes. Without the multi-threaded server configuration, each user process requires its own dedicated server process; a new server process is created for each client requesting a connection. A dedicated server process remains associated to the user process for the remainder of the connection. With the multi-threaded server configuration, many user processes connect to a dispatcher process. The dispatcher routes client requests to the next available shared server process. The advantage of the multi-threaded server configuration is that system overhead is reduced, so the number of users that can be supported is increased.

 Contrasting Dedicated Server Processes and Shared Server Processes

Consider an order entry system with dedicated server processes. A customer places an order as a clerk enters the order into the database. For most of the transaction, the clerk is on the telephone talking to the customer and the server process dedicated to the clerk's user process remains idle. The server process is not needed during most of the transaction, and the system is slower for other clerks entering orders.

The multi-threaded server configuration eliminates the need for a dedicated server process for each connection. A small number of shared server processes can perform the same amount of processing as many dedicated server processes. Also, the amount of memory required for each user is relatively small. Because less memory and process management are required, more users can be supported.

 An Overview of the Multi-Threaded Server Architecture

The following types of processes are needed in a system using the multi-threaded server architecture:

•	a network listener process that connects user processes to dispatchers and dedicated servers (This process is part of SQL*Net, not ORACLE.)

•	one or more dispatcher processes

•	one or more shared server processes.

The network listener process waits for incoming connection requests and determines if each user process can use a shared server process. If so, the listener gives the user process the address of a dispatcher process. If the user process requests a dedicated server, the listener process creates a dedicated server process and connects the user process to it. (At least one dispatcher process must be configured and started per network protocol that the database clients will use.)

Note: To use shared servers, a user process must connect through SQL*Net, even if the user process is on the same machine as the ORACLE instance.

A request from a user is a single program interface call which is part of the user's SQL statement. When a user makes a call, its dispatcher places the request on the request queue in the SGA, where it is picked up by the next available shared server process. The shared server processes make all the necessary calls to the database to complete each user process's request. When the server completes the request, the server returns the results to the response queue of the dispatcher that the user is connected to in the SGA. The dispatcher then returns the completed request to the user process.

In the order entry system example, each clerk's user process connects to a dispatcher; each request made by a clerk is sent to a dispatcher, which places the request in the request queue. The next available shared server process picks up the request, services it, and puts the response in the response queue. When a clerk's request is completed, the clerk remains connected to the dispatcher, but the shared server process that processed the request is released and available for other requests. While one clerk is talking to a customer, not making a request to the database, another clerk can use the same shared server process.

Figure 9 - 8 illustrates how user processes communicate with the dispatcher across the two-task interface and how the dispatcher communicates users' requests to shared server processes.

 Shared Server Processes

Shared server processes and dedicated server processes provide the same functionality, except shared server processes are not associated with a specific user process. Instead, a shared server process serves any client request in the multi-threaded server configuration.

The PGA of a shared server process does not contain user-related data; such information needs to be accessible to all shared server processes. The PGA of a shared server process contains only stack space and process-specific variables. "Program Global Area (PGA)" on page 9 - 24 provides more information about the content of a PGA in different types of instance configurations.

All session-related information is contained in the SGA. Each shared server process needs to be able to access all sessions' data spaces so that any server can handle requests from any session. Space is allocated in the SGA for each session's data space. You can limit the amount of space that a session can allocate by setting the resource limit PRIVATE_SGA to the desired amount of space in the user's profile. See Chapter 17 for more information about resource limits and profiles.

ORACLE dynamically adjusts the number of shared server processes based on the length of the request queue. The number of shared server processes that can be created ranges between the initialization parameters MTS_SERVERS and MTS_MAX_SERVERS.

Dispatcher Request and Response Queues

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations; redo entries are used for database recovery, if necessary.

The request queue is in the SGA and is common to all dispatcher processes of an instance. The shared server processes check the common request queue for new requests, picking up new requests on a first-in-first-out basis. One shared server process picks up one request in the queue and makes all necessary calls to the database to complete that request. The shared server process then places the response on the calling dispatcher's response queue. Each dispatcher has its own response queue in the SGA and each dispatcher is responsible for sending completed requests back to the appropriate user process.

 Artificial Deadlocks

With a limited number of shared server processes, the possibility of an "artificial" deadlock can arise. An artificial deadlock can occur in the following situation:

1..	One user acquires an exclusive lock on a resource by issuing a SELECT statement with the FOR UPDATE clause or LOCK TABLE statement.

2..	The shared server process used to process the locking request is released once the statement completes.

3..	Other users attempt to access the locked resource. Each shared server process is bound to the user process it is serving until the necessary locked resource becomes available. Eventually, all shared servers may be bound to users waiting for locked resources.

4..	The original user attempts to submit a new request (such as a COMMIT or ROLLBACK statement) to release the previously acquired lock, but cannot because all shared server processes are currently being used.

When ORACLE detects an artificial deadlock, new shared server processes are automatically created as needed until the original user submits a request that releases the locked resources causing the artificial deadlocks. If the maximum number of shared server processes (as specified by the MTS_MAX_SERVERS parameter) have been started, the database administrator must to manually resolve the deadlock by disconnecting a user. This releases a shared server process, resolving the artificial deadlock.

If artificial deadlocks occur too frequently on your system, you should increase the value of MTS_MAX_SERVERS.

Restricted Operations of the Multi-Threaded Server

Certain administrative activities cannot be performed while connected to a dispatcher process, including shutting down or starting an instance and media recovery. An error message is issued if you attempt to perform these activities while connected to a dispatcher process.

These activities are typically performed when connected as INTERNAL. When you want to connect as INTERNAL in system configured with multi-threaded servers, you must state in your connect string that you want to use a dedicated server process instead of a dispatcher process (SRVR=DEDICATED). See your installation or user's guide or SQL*Net documentation for the proper connect string syntax.

________________________________________

Examples of How ORACLE Works

Now that the memory structures, processes, and varying configurations of an ORACLE database system have been discussed, it is helpful to see how all the parts work together. The following sections demonstrate and contrast the two-task and multi-threaded server ORACLE configurations.

An Example of ORACLE Using Dedicated Server Processes

The following example is a simple illustration of the dedicated server architecture of ORACLE:

1..	A database server machine is currently running ORACLE using multiple background processes.

2..	A client workstation runs a database application (in a user process) such as SQL*Plus. The client application attempts to establish a connection to the server using a SQL*Net driver.

3..	The database server is currently running the proper SQL*Net driver. The Listener process on the database server detects the connection request from the client database application and creates a dedicated server process on the database server on behalf of the user process.

4..	The user executes a single SQL statement. For example, the user inserts a row into a table.

5..	The dedicated server process receives the statement. At this point, two paths can be followed to continue processing the SQL statement:

•	If the shared pool contains a shared SQL area for an identical SQL statement, the server process can use the existing shared SQL area to execute the client's SQL statement.

•	If the shared pool does not contain a shared SQL area for an identical SQL statement, a new shared SQL area is allocated for the statement in the shared pool.

In either case, a private SQL area is created in the session's PGA and the dedicated server process checks the user's access privileges to the requested data.

6..	The server process retrieves data blocks from the actual data file, if necessary, or uses data blocks already stored in the buffer cache in the SGA of the instance.

7..	The server process executes the SQL statement stored in the shared SQL area. Data is first changed in the SGA. It is permanently written to disk when the DBWR process determines it is most efficient to do so. The LGWR process records the transaction in the online redo log file only on a subsequent commit request from the user.

8..	If the request is successful, the server sends a message across the network to the user. If it is not successful, an appropriate error message is transmitted.

9..	Throughout this entire procedure, the other background processes are running and watching for any conditions that require intervention. In addition, ORACLE is managing other transactions and preventing contention between different transactions that request the same data.

These steps show only the most basic level of operations that ORACLE performs.

An Example of ORACLE Using the Multi-Threaded Server

The following example is a simple illustration of the multi-threaded server architecture of ORACLE:

1..	A database server is currently running ORACLE using the multi-threaded server configuration.

2..	A client workstation runs a database application (in a user process) such as SQL*Forms. The client application attempts to establish a connection to the database server using the proper SQL*Net driver.

3..	The database server machine is currently running the proper SQL*Net driver. The Listener process on the database server detects the connection request of the user process and determines how the user process should be connected. If the user is using SQL*Net Version 2, the Listener informs the user process to reconnect using the address of an available dispatcher process.

Note: If the user is using SQL*Net Version 1 or 1.1, the SQL*Net listener process creates a dedicated server process on behalf of the user process and remainder of the example operates as described in the preceding example. (Users using earlier versions of SQL*Net cannot use a shared server process.)

4..	The user issues a single SQL statement. For example, the user updates a row into a table.

5..	The dispatcher process places the user process's request on the request queue, which is in the SGA and shared by all dispatcher processes.

6..	An available shared server process checks the common dispatcher request queue and picks up the next SQL statement on the queue. It then processes the SQL statement as described in Steps 5, 6, and 7 of the previous example. Note in Step 5 that parts of the session's private SQL area created in the SGA.

7..	Once the shared server process finishes processing the SQL statement, the process places the result on the response queue of the dispatcher process that sent the request.

8..	The dispatcher process checks its response queue and sends completed requests back to the user process that made the request.

________________________________________

The Program Interface

The program interface is the software layer between a database application and ORACLE. The program interface does the following:

•	provides a security barrier, preventing destructive access to the SGA by client user processes

•	acts as a communication mechanism, formatting information requests, passing data, and trapping and returning errors

•	converts and translates data, particularly between different types of computers or to external user program datatypes

The ORACLE code acts as a server, performing database tasks on behalf of an application (a client), such as fetching rows from data blocks. It consists of several parts, provided by both ORACLE software and operating system specific software.

Program Interface Structure

The program interface consists of the following pieces:

•	ORACLE call interface (OCI)

•	the client or user side of the program interface (also called the UPI)

•	various SQL*Net drivers (protocol-specific communications software)

•	operating system communications software

•	the server or ORACLE side of the program interface (also called the OPI)

Both the user and ORACLE sides of the program interface execute ORACLE software, as do the drivers.

SQL*Net is the portion of the program interface that allows the client application program and the ORACLE Server to reside on separate computers in your communication network.

The Program Interface Drivers

Drivers are pieces of software that transport data, usually across a network. They perform operations like connect, disconnect, signal errors, and test for errors. Drivers are specific to a communications protocol. There is always a default driver.

You may install multiple drivers (such as the asynchronous or DECnet drivers), and select one as the default driver, but allow an individual user to use other drivers by specifying the desired driver at the time of connection. Different processes can use different drivers. A single process can have concurrent connections to a single database or to multiple databases (either local or remote) using different SQL*Net drivers.

The installation or user's guide and SQL*Net documentation for your system contains details about choosing and installing drivers and adding new drivers after installation. The SQL*Net documentation describes selecting a driver at run time while accessing ORACLE.

Operating System Communications Software

The lowest level software connecting the user side to the ORACLE side of the program interface is the communications software, which is provided by the host operating system. DECnet, TCP/IP, LU6.2, and ASYNC are examples.

The communication software may be supplied by Oracle Corporation but is usually purchased separately from the hardware vendor or a third party software supplier. See your installation or user's guide for more information about the communication software of your system.


CHAPTER 10. DATA CONCURRENCY

Make 'em laugh; make 'em cry; make 'em wait.

Charles Reade

This chapter explains how ORACLE automatically maintains the concurrent access and accuracy of information in a multi-user database environment using locks, transactions, and a multiversion consistency model.

Topics covered in this chapter include:

•	data concurrency, integrity, and consistency

•	the automatic locking mechanisms of ORACLE

•	explicit (manual) locking

•	ORACLE Lock Management services

________________________________________

What Are Data Concurrency and Consistency?

In a single-user database, the user can modify data within a transaction without concern of other users modifying the same data at the same time. However, in a multi-user database, the statements within simultaneous multiple transactions can update the same data. Concurrently executing transactions must be guaranteed to produce the same effect as serially executing the same transactions. Therefore, primary concerns of a multi-user database include how to control data concurrency and consistency:

data concurrency	Access to data concurrently used by many users must be coordinated.

data consistency	A user always sees a consistent view of all data, which consists of all data committed by other transactions as of that time and all changes made by the user up to that time.

General Concurrency Issues

Specific concurrency and consistency problems that a multi-user database must prevent include the following:

inconsistent reads	During the execution of a single query in one transaction, changes of another committed or uncommitted transaction are visible. Therefore, the set of data returned for a query is not consistent with respect to any single point in time.

non-repeatable reads (phantoms)	Within the context of a single transaction, two identical queries (or queries that seek the same data) return different data because the changes of other committed transactions are noticed by the query.

dirty reads	A transaction (T1) reads uncommitted data from another user's uncommitted transaction (T2). Therefore, T1 has read data that does not yet exist.

lost updates	An update in one transaction overwrites an update in another transaction before the second transaction commits.

destructive DDL operations	One user updates the data in a table while another user simultaneously modifies or drops the table.cursor stability

Locks are released as data is fetched from a cursor. When a cursor moves off a block, read locks are released. Therefore, if the query revisits the block, different data may be seen if other users have changed data between the original and subsequent fetch.

General Locking Concepts

In general, multi-user databases use some form of data locking to solve the problems associated with data concurrency, integrity, and consistency. Locks are mechanisms used to prevent destructive interaction between users accessing the same resource, such as an entire table, specific row in a table. Destructive interaction can be interpreted as any interaction that incorrectly updates data or incorrectly alters underlying data structures, such as tables, column definitions, indexes, privilege grants. Lost updates and destructive DDL operations are two examples of destructive interference.

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

 Restrictiveness of Locks

In general, two levels of locking can be used in a multi-user database:

exclusive locks	An exclusive lock prohibits the sharing of the associated resource. The first transaction to exclusively lock a resource is the only transaction that can alter the resource until the exclusive lock is released.

share locks	A share lock allows the associated resource to be shared, depending on the operations involved (e.g., several users can read the same data at the same time). Several transactions can acquire share locks on the same resource.

Share locks allow a higher degree of data concurrency than exclusive locks.

 Deadlocks

A deadlock is a situation that can occur in multi-user systems that causes some number of transactions to be unable to continue work. A deadlock can occur when two or more users are waiting for data locked by each other. It typically happens when each of two or more users are waiting to access a resource that another user has already locked. This creates a deadlock situation because each user is waiting for resources held by the other user. Figure 10 - 1 illustrates two transactions in a deadlock.

Figure 10 - 1.  Two Transactions in a Deadlock

Transaction 1	Time Point	Transaction 2

UPDATE emp	1	UPDATE emp

    SET sal = sal*1.1	    SET sal = 1342

    WHERE empno = 1000; 	    WHERE empno = 2000;

UPDATE emp	2	UPDATE emp

    SET sal = sal*1.1	    SET sal = 1342

    WHERE empno = 2000; 	    WHERE empno = 1000;

ORA-00060	3

deadlock detected while

waiting for resource

In Figure 10 - 1, no problem exists at time point 1, as each transaction has a row lock on the row it attempts to update. However, then each transaction proceeds (without committing or ending the transaction in any way) to try to update the row currently held by the other transaction. Therefore, a deadlock results at time point 2, because neither transaction can obtain the resource it needs to proceed or terminate. It is a deadlock because no matter how long each transaction waits, the conflicting locks are held.

 Lock Escalation

Note: ORACLE never escalates locks.

In some database systems, lock escalation occurs when numerous locks are held at one level and the database automatically changes the locks to different locks at a higher level. For example, if a single user locks many rows in a table, the database might automatically escalate the user's row locks to a single table lock. With this plan, the number of locks has been reduced, but the restrictiveness of what is being locked has increased.

Lock escalation greatly increases the likelihood of deadlocks. 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. A deadlock is created if transaction T2 also requires lock escalation before it can proceeds; the escalator is devoted to T1.

 Lock Conversion

A transaction may re-request a lock on a resource that it already has locked. Re-requests of locks on the same resource by the same transaction are handled differently by different database systems. Optimally, if the most recently requested lock is of lower or equivalent restrictiveness in relation to the previously acquired lock, the previously acquired lock is sufficient and the user's transaction can proceed immediately. If the most recently requested lock is of higher restrictiveness than the previously acquired lock, the previously acquired lock must be converted to the more recently requested lock of higher restrictiveness. The user's transaction must wait until the lock conversion is accomplished.

________________________________________

How ORACLE Controls Data Concurrency, Integrity, and Consistency

ORACLE maintains data concurrency, integrity, and consistency by using various types of locks, transactions, and a multiversion consistency model.

How ORACLE Locks Data

ORACLE uses various types of locks that range in restrictiveness. This range of lock restrictiveness allows ORACLE to automatically provide a high degree of data concurrency, as follows:

•	Readers of data do not wait for writers of the same data blocks.

•	Writers of data do not wait for readers of the same data blocks (non-blocking queries).

•	Writers only wait for other writers if they attempt to update the same rows at the same time.

Note: Readers of data may have to wait for writers of the same data blocks in some very special cases of pending distributed transactions.

In all cases, necessary locks are obtained automatically by ORACLE when a SQL statement is executed; users need not be concerned with such details. ORACLE automatically locks data at the lowest level of restrictiveness to provide the highest degree of data concurrency yet provide fail-safe data integrity. ORACLE also allows the option to manually lock data, if desired.

For a complete description of the internal locks used by ORACLE, see "Locking Mechanisms" on page 10 - 9.

Transactions and Data Concurrency

ORACLE can provide data concurrency and integrity using transactions and its locking mechanisms. 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 other concurrent transactions. The changes made by the SQL statements of one transaction only become visible to other transactions that start after the first transaction is committed.

All locks acquired by the statements within a transaction are released when the transaction is either committed or rolled back. Because the locking mechanisms of ORACLE are tied closely to transaction control, application designers are responsible for assuring that transactions are defined properly.

For more information about the locking mechanisms of ORACLE, see "Locking Mechanisms" on page 10 - 9.

Multi-Version Consistency Model

ORACLE provides for read consistency at two different levels: statement-level and transaction-level read consistency. The following sections explain each level of read consistency and the mechanisms the ORACLE uses to implement the multiversion consistency model.

 Statement-Level Read Consistency

ORACLE always enforces statement-level read consistency, which guarantees that the data returned by a single query is consistent with respect to the time that the query began. Therefore, a query never sees any of the changes made by transactions that commit during the course of query execution.

To produce statement-level read consistency, ORACLE observes the current SCN (system change number) as a query enters the execution phase. As query execution proceeds, only data committed as of the observed SCN is available; the query does not see changes of other transactions committed after statement execution begins.

A consistent result set is guaranteed for every query, guaranteeing data consistency and requiring no action on the user's part. The SQL statements SELECT, INSERT with a query, UPDATE, and DELETE all query data, either explicitly or implicitly, and all return a consistent set of data. Each of these statements uses a query to determine which data will be affected (selected, inserted, updated, or deleted, respectively). A SELECT statement is an explicit query and may have nested queries or a join operation. An INSERT statement can use nested queries. UPDATE and DELETE statements can use WHERE clauses or subqueries to affect only some rows in a table rather than all rows. While queries used in INSERT, UPDATE, and DELETE statements are guaranteed a consistent set of results, they do not see the changes made by the DML statement.

 Transaction-Level Read Consistency

ORACLE also allows the option of enforcing transaction-level read consistency; it can guarantee that the data seen by all queries within the same transaction is consistent with respect to a single point-in-time. Therefore, transaction-level read consistency produces repeatable reads.

ORACLE can provide transaction-level read consistency using different methods:

read-only transactions	Read-only transactions can only contain queries; they cannot contain any DML statements. To provide repeatable reads within a read-only transaction, ORACLE observes the start of the transaction. For the duration of the transaction, only data committed before the start of the transaction is available.

exclusive table and row locks	If repeatable reads are required in transactions that contain DML statements, a transaction can explicitly acquire share locks on the tables or exclusive locks on the rows which must return repeatable reads. This solution provides transaction-level read consistency, yet reduces the degree of data concurrency.

In summary, ORACLE is capable of both statement-level and transaction-level read consistency by providing each statement or transaction its own "version" of data, as of a specific point-in-time (the start of a statement execution or a transaction).

For more information on manual locking and the procedures used to produce repeatable reads, see "Explicit (Manual) Data Locking" on page 10 - 21.

Read Consistency and Rollback Segments

ORACLE uses rollback segments (discussed in Chapter 3) to provide read consistency.  Figure 10 - 2  shows how ORACLE can provide statement-level read consistency using data in rollback segments and SCNs.

As a query enters the execution stage, the current SCN is determined; in Figure 10 - 2, this SCN is 10023. As data blocks are read on behalf of the query, only blocks written with the observed SCN are used. Blocks with changed data (more recent SCNs) are reconstructed using data in the rollback segments and the reconstructed data is returned for the query. Therefore, each query returns all committed data with respect to the SCN recorded at the time that query execution began; committed or uncommitted changes of other transactions that occur during a query's execution are not observed, guaranteeing that a consistent set of data is returned for each query.

The "Snapshot  Too Old" Message

In rare situations, ORACLE is not able to return a consistent set of results (often called a snapshot) for a long-running query. This phenomenon occurs because not enough information remains in the rollback segments to reconstruct older data. In most cases, this error is produced when a lot of update activity causes the rollback segment to wrap around and overwrite data needed to reconstruct data needed by a long-running query. In this event, error 1555 will result:

ORA-1555: snapshot too old (rollback segment too small)

This error condition can be avoided by creating more or larger rollback segments. Alternatively, long-running queries can be issued when online transaction processing volume is at a minimum, or you can obtain a shared lock (see the next section) on the table you are querying, thus prohibiting any other exclusive locks during the transaction.

________________________________________

Locking Mechanisms

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 automatically released when certain events occur and the transaction no longer requires the resource.

Note: While reading this section, keep in mind that ORACLE locking is fully automatic and requires no user action. Implicit locking occurs for all SQL statements so that database users never need to explicitly lock any resource. ORACLE's default locking mechanisms lock data at the lowest level of restrictiveness to guarantee data integrity yet allow the highest degree of data concurrency. The following sections assume that two initialization parameters are set to the default values, as follows:

SERIALIZABLE = FALSE

ROW_LOCKING = ALWAYS

Later sections also describe situations when you might wish to manually acquire locks or alter the default locking behavior of ORACLE and how you can do so; see "Explicit (Manual) Data Locking" on page 10 - 21.

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 the following general categories:

data locks  (DML locks)	Data locks protect data. For example, table locks lock entire tables, row locks lock selected rows.

dictionary locks (DDL locks)	Dictionary locks protect the structure of objects. For example, dictionary locks protect the definitions of tables and views.

internal locks and latches 	Internal locks and latches protect internal database structures such as files. Internal locks and latches are entirely automatic.

distributed locks	Distributed locks ensure that the data and other resources distributed among the various instances of an ORACLE Parallel Server remain consistent. Distributed locks are held by instances rather than transactions. They communicate the current status of a resource among the instances of an ORACLE Parallel Server.

parallel cache management  (PCM) locks	Parallel cache management locks are the distributed locks that cover one or more data blocks (table and index blocks) in the buffer cache. PCM locks do not lock any rows on behalf of transactions.

The following sections discuss data locks, dictionary locks, and internal locks, respectively. For more information about distributed and PCM locks, see the ORACLE7 Parallel Server Administrator's Guide.

Data Locks

The purpose of a data lock (DML lock) is to protect table data, guaranteeing data integrity when data is being accessed concurrently by multiple users. Data locks prevent destructive interference of simultaneous conflicting DML and DDL operations. For example, ORACLE data locks guarantee that a specific row in a table can be updated by only one transaction at any given time and that a table cannot be dropped if an uncommitted transaction contains an insert into the table.

DML operations can acquire data locks at two different levels: for specific rows and for entire tables. The following sections explain row and table locks.

Note: The acronym in parentheses after each type of lock or lock mode in the following sections is the abbreviation used in the Locks Monitor of SQL*DBA. SQL*DBA might display TM for any table lock, rather than indicate the mode of table lock (such as RS or SRX).

 Row Locks (TX)

An exclusive data lock is acquired for a individual row on behalf of a transaction when the row is modified by one of the following statements: INSERT, UPDATE, DELETE, and SELECT with the FOR UPDATE clause.

A row is always locked exclusively so that other users cannot modify the row until the transaction holding the lock is committed or rolled back. Row locks are always acquired automatically by ORACLE as a result of the statements listed above.

Rows Locks and Table Locks      If a transaction obtains a row lock for a row, the transaction also acquires a table lock for the corresponding table; a table lock must also be obtained to prevent conflicting DDL operations that would override data modifications in an ongoing transaction. The following section explains table locks and "DDL Locks (Dictionary Locks)" on page 10 - 17 explains the locks necessary for DDL operations.

 Table Locks (TM)

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 some level of DML access to the table on behalf of a transaction and to prevent conflicting DDL operations that would override data modifications in an ongoing transaction. Any table lock acquired for a table prevents the acquisition of an exclusive DDL lock on the same table, thereby restricting DDL operations that require an exclusive DDL lock on the table. For example, a table must not be altered or dropped if an uncommitted transaction holds a table lock for the table. (For more information about exclusive DDL locks, see "Exclusive DDL Locks" on page 10 - 18.)

A table lock can be held in any of several modes: row share (RS), row exclusive (RX), share lock (S), share row exclusive (SRX), and exclusive (X). The restrictiveness of a table lock's mode determines the modes in which other table locks on the same table can be obtained and held.

Table 10 - 1 indicates the modes of table locks that statements acquire and operations that those locks permit and prohibit.

Mode of 	      Lock Modes Permitted?

SQL Statement	Table

Lock

Mode of 	RS	RX	S	SRX	X

SQL Statement	Table

Lock

SELECT...FROM table ...	none	Y	Y	Y	Y	Y

INSERT INTO table ...	RX	Y	Y	N	N	N

UPDATE table ...	RX	Y*	Y*	N	N	N

DELETE FROM table ...	RX	Y*	Y*	N	N	N

SELECT ... FROM table	RS	Y*	Y*	Y*	Y*	N

   FOR UPDATE OF ...

LOCK TABLE table IN	RS	Y	Y	Y	Y	N

    ROW SHARE MODE

LOCK TABLE table IN	RX	Y	Y	N	N	N

    SHARE MODE

LOCK TABLE table IN	S	Y	N	Y	N	N

    SHARE MODE

LOCK TABLE table IN	SRX	Y	N	N	N	N

    SHARE ROW EXCLUSIVE

MODE

LOCK TABLE table IN	X	N	N	N	N	N

    EXCLUSIVE MODE

Table 10 - 1.  Summary of Table Locks

RS: row share	SRX: share row exclusive

RX: row exclusive	X: exclusive

 S: share

 *	if no conflicting row locks are held by another transaction;

  	otherwise, waits occur

The following sections explain each mode of table lock, from least restrictive to most restrictive. Each section describes the mode of table lock, the actions that cause the transaction to acquire a table lock in that mode, and which actions are permitted and prohibited in other transactions when each mode of table lock is acquired by your transaction. For more information about manual locking, see "Explicit (Manual) Data Locking" on page 10 - 21.

Row Share Table Locks (RS)   A row share table lock (also sometimes internally called a sub-share table lock, SS) indicates that the transaction holding the lock on the table has locked rows in the table and intends to update them. A row share table lock is automatically acquired for a table modified by the following statements:

SELECT . . . FROM table . . . FOR UPDATE OF . . . ;

LOCK TABLE table IN ROW SHARE MODE;

A row share table lock is the least restrictive mode of table lock, offering the highest degree of concurrency for a table.

Permitted Operations:   A row share table lock held by a transaction allows other transactions to concurrently query, insert, update, delete, or lock rows in the same table. Therefore, other transactions can obtain simultaneous row share, row exclusive, share, and share row exclusive table locks for the same table.

Prohibited Operations:   A row share table lock held by a transaction prevents other transactions from exclusive write access to the same table using only the following statement:

LOCK TABLE table IN EXCLUSIVE MODE;

Row Exclusive Table Locks (RX)   A row exclusive table lock (also internally called a sub-exclusive table lock, SX) generally indicates that the transaction holding the lock has made one or more updates to rows in the table. A row exclusive table lock is automatically acquired for a table modified by the following types of statements:

INSERT INTO table . . . ;

UPDATE table . . . ;

DELETE FROM table . . . ;

LOCK TABLE table IN ROW EXCLUSIVE MODE;

A row exclusive table lock is slightly more restrictive than a row share table lock.

Permitted Operations:   A row exclusive table lock held by a transaction allows other transactions to concurrently query, insert, update, delete, or lock rows in the same table. Therefore, row exclusive table locks allow multiple transactions to obtain simultaneous row exclusive and row share table locks for the same table.

Prohibited Operations:   A row exclusive table lock held by a transaction prevents other transactions from manually locking the table for exclusive reading or writing; therefore, other transactions cannot concurrently lock the table using the following statements:

LOCK TABLE table IN SHARE MODE;

LOCK TABLE table IN SHARE EXCLUSIVE MODE;

LOCK TABLE table IN EXCLUSIVE MODE;

Share Table Locks (S)      A share table lock is automatically acquired for a table specified in the following statement:

LOCK TABLE table IN SHARE MODE;

Permitted Operations:   A share table lock held by a transaction allows other transactions only to query, lock specific rows with SELECT . . . FOR UPDATE, or successfully execute LOCK TABLE . . . IN SHARE MODE statements; no updates are allowed by other transactions. Multiple transactions can concurrently hold share table locks for the same table; in this case, no transaction can update the table (even if a transaction holds row locks as the result of a SELECT statement with the FOR UPDATE clause). Therefore, a transaction that has a share table lock can only update the table if no other transactions also have a share table lock for the same table.

Prohibited Operations:   A share table lock held by a transaction prevents other transactions from modifying the same table; a transaction cannot insert, update, or delete rows in a table when a share table lock is held on the table by another transaction. (To do so, the mode of the lock must change to SHARE ROW EXCLUSIVE.) A share table lock held by a transaction also prohibits other transactions from successfully executing the following statements:

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;

LOCK TABLE table IN EXCLUSIVE MODE;

LOCK TABLE table IN ROW EXCLUSIVE MODE;

Share Row Exclusive Table Locks (SRX)   A share row exclusive table lock (also sometimes called a share-sub-exclusive table lock, SSX) is more restrictive than a share table lock. A share row exclusive table lock is acquired for a table specified in the following statement:

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;

Permitted Operations:  Only one transaction can acquire a share row exclusive table lock. A share row exclusive table lock held by a transaction allows other transactions only to query or lock specific rows with SELECT with the FOR UPDATE clause, but not update the table.

Prohibited Operations:  A share row exclusive table lock held by a transaction prevents other transactions from obtaining row exclusive table locks and modifying the same table. A transaction cannot insert, update, or delete rows in a table when a share row exclusive table lock is held by another transaction. A share row exclusive table lock also prohibits other transactions from obtaining share, share row exclusive, and exclusive table locks; other transactions cannot successfully execute the following statements:

LOCK TABLE table IN SHARE MODE;

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;

LOCK TABLE table IN ROW EXCLUSIVE MODE;

LOCK TABLE table IN EXCLUSIVE MODE;

Exclusive Table Locks (X)      An exclusive table lock is the most restrictive mode of table lock, allowing the transaction that holds the lock exclusive write access to the table. An exclusive table lock is acquired for a table specified in the following statement:

LOCK TABLE table IN EXCLUSIVE MODE;

Permitted Operations:   Only one transaction can obtain an exclusive table lock for a table. An exclusive table lock permits other transactions only to query the same table.

Prohibited Operations:   An exclusive table lock held by a transaction prohibits other transactions from performing any type of DML statement on the same table; other transactions cannot insert, update, delete rows in the same table, lock rows in the same table, or lock the table in any mode.

 Data Locks Automatically Acquired for DML Statements

The previous sections explained the different types of data locks, modes in which they can be held, when they can be obtained, when they are obtained, and what they prohibit. The following sections summarize how data is automatically locked on behalf of different DML operations. Table 10 - 2  summarizes the information in the following sections.

DML Statement	 Row Locks? 	Mode of Table Lock

SELECT ...FROM table

INSERT INTO table ...	 n 	RX

UPDATE table ...	 n	RX

DELETE FROM table ...	 n	RX

SELECT ... FROM table ...	 n	RS

   FOR UPDATE OF ...

LOCK TABLE table IN ...

   ROW SHARE MODE	RS

   ROW EXCLUSIVE MODE	RX

   SHARE MODE	S

   SHARE EXCLUSIVE MODE	SRX

   EXCLUSIVE MODE	X

Table 10 - 2.  Locks Obtained By DML Statements

RS: row share	SRX: share row exclusive

RX: row exclusive	X: exclusive

S: share

Default Locking for Queries      Queries include the following kinds of statements:

SELECT

INSERT . . . SELECT . . . ;

UPDATE . . . ;

DELETE . . . ;

They do not include the following statements:

SELECT . . . FOR UPDATE OF . . . ;

Note that INSERT, UPDATE, and DELETE statements can have implicit queries as part of the statement.

Queries are the SQL statements least likely to interfere with other SQL statements because they only read data. The following characteristics are true of all queries that do not use the FOR UPDATE clause:

•	A query acquires no data locks. Therefore, other transactions can query and update a table being queried, including the specific rows being queried. Because queries do not acquire any data locks to block other operations, queries in ORACLE are often referred to as non-blocking queries.

•	A query does not have to wait for any data locks to be released; it can always proceed. (Queries may have to wait for data locks in some very specific cases of pending distributed transactions.)

Default Locking for INSERT, UPDATE, and DELETE Statements   The locking characteristics of INSERT, UPDATE, and DELETE statements are as follows:

•	The transaction that contains a DML statement acquires exclusive row locks on the rows modified by the statement. Therefore, other transactions must wait to update or delete the locked rows until the locking transaction either commits or rolls back.

•	The transaction that contains a DML statement does not need to acquire row locks on any rows selected by a subquery or implicit query, such as a query in a WHERE clause. A subquery or implicit query in a DML statement is guaranteed to be consistent as of the start of the query and does not see the effects of the DML statement it is part of.

•	A query in a transaction can see the changes made by previous DML statements in the same transaction, but cannot see the uncommitted changes of other active transactions.

•	In addition to the necessary exclusive row locks, the transaction that contains a DML statement acquires at least a row exclusive table lock on the table the contains the affected rows. If the containing transaction already holds a share, share row exclusive, or exclusive table lock for the table, the row exclusive table lock is not acquired; if the containing transaction already holds a row share table lock, ORACLE automatically converts this lock to a row exclusive table lock.

 Duration of Data Locks

All data locks acquired by a transaction, including all row and table locks, are released when the transaction commits or rolls back. Data locks acquired after a savepoint are released if the transaction is rolled back to the savepoint; however, only transactions not waiting on 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 and 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.

ORACLE does not escalate any locks at any time.

DDL Locks (Dictionary Locks)

A DDL lock protects the definition of a schema object (e.g., a table) while that object is acted upon by an ongoing DDL operation in a transaction (recall that a DDL statement implicitly commits a 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 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.

A dictionary lock is acquired automatically by ORACLE on behalf of any DDL transaction requiring it. Users cannot explicitly request DDL locks. Only individual schema objects that are modified or referenced are locked during DDL operations; the whole data dictionary is never locked.

DDL locks fall into three categories: exclusive DDL locks, share DDL locks, and breakable parse locks.

Exclusive DDL Locks

Certain DDL operations require exclusive DDL locks for a resource to prevent destructive interference with other DDL operations that might modify or reference the same object. For example, a DROP TABLE operations is not allowed to drop a table while an ALTER TABLE operation is adding a column to the table, and vice versa.

In addition to DDL locks, DDL operations also acquire DML locks (data locks) on the object to be modified.

Most DDL operations acquire exclusive DDL locks on the object to be modified (except for those listed in the next section, "Share DDL Locks").

During the acquisition of an exclusive DDL lock, if another DDL lock is already held on the object by another operation, the acquisition waits until the older DDL lock is released, and then proceeds.

 Share DDL Locks

Certain 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 executed, 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 object will remain constant for the duration of the transaction.

A share DDL lock is acquired on an object for DDL statements on the object that include the following commands: AUDIT, NOAUDIT, GRANT, REVOKE, COMMENT, CREATE [OR REPLACE] VIEW/

 PROCEDURE/PACKAGE/PACKAGE BODY/FUNCTION/ TRIGGER, CREATE SYNONYM, and CREATE TABLE (when the CLUSTER parameter is not included).

 Breakable Parse Locks

A SQL statement (or PL/SQL program unit) in the shared pool holds a parse lock for each object referenced by the SQL statement. Parse locks are acquired so that the associated shared SQL area can be invalidated if a referenced object is altered or dropped. (See Chapter 16 for more information about dependency management.) A parse lock does not disallow any DDL operation and can be broken to allow conflicting DDL operations, hence the name "breakable parse lock."

A parse lock is acquired during the parse phase of SQL statement execution and held as long as the shared SQL area remains in the shared pool.

 Duration of DDL Locks

The duration of a DDL lock varies depending on the type of DDL lock. Exclusive and share DDL locks last for the duration of DDL statement execution and the ensuing implicit transaction commit. A parse lock persists as long as the associated SQL statement remains in the shared pool.

 DDL Locks and Clusters

A DDL operation on a cluster acquires exclusive DDL locks on the cluster and also on all tables and snapshots in the cluster. A DDL operation on a table or snapshot in a cluster acquires a share lock on the cluster, in addition to a share or exclusive DDL lock on the table or snapshot. The share DDL lock on the cluster prevents another operation from dropping the cluster while the first operation proceeds.

Internal Locks and Latches

Internal locks and latches protect internal database and memory structures; these structures are inaccessible to users. Users have no need for control over their occurrence or duration. The following information will help you interpret the displays resulting from the SQL*DBA commands MONITOR LOCKS or MONITOR LATCHES.

 Latches

Latches are simple, low level serialization mechanisms to protect shared data structures in the SGA. For example, latches protect the list of users currently accessing the database and the data structures describing the blocks in the buffer cache. A server or background process acquires a latch for a very short time while manipulating or looking at one of these structures. The implementation of latches is operating system dependent, particularly in regard to whether a process will wait for a latch and how long.

Internal locks are higher-level, more complex mechanisms than latches, and serve a variety of purposes. Details on the three categories follow.

Dictionary Cache     Locks   These locks are of very short duration, and are held on entries in dictionary caches while the entries are being modified or used. They guarantee that statements being parsed do not see inconsistent object definitions.

Dictionary cache locks can be held shared or exclusive. Shared locks are released when the parse is complete. Exclusive locks are released when the DDL operation is complete.

File and Log Management Locks      These locks protect different files. For example, one lock protects the control file so that only one process can change the file at a time. Another lock coordinates the use and archiving of the redo log files. Data files are locked to ensure that multiple instances mount a database in shared mode or one instance mounts it in exclusive mode. Because file and log locks indicate the status of files, these locks are necessarily held for a long time.

File and log locks are of particular importance when using the ORACLE Parallel Server; see the ORACLE7 Parallel Server Administrator's Guide for additional information.

Tablespace and Rollback Segment Locks   These locks protect tablespaces and rollback segments. For example, all instances accessing a database must agree on whether a tablespace is online or offline. Rollback segments are locked so that only one instance can write to a segment.

Deadlock Detection

ORACLE automatically detects deadlock situations. When detected, ORACLE automatically resolves a deadlock by rolling back one of the statements involved in the deadlock, thereby releasing one set of the conflicting row locks. A corresponding message is also returned to the transaction that undergoes statement-level rollback. The statement rolled back is the one belonging to the transaction detecting the deadlock. Usually, the signalled transaction should be explicitly rolled back, but it can also retry the rolled back statement after waiting.

Note: In distributed transactions, local deadlocks are detected by analyzing a "waits for" graph and global deadlocks are detected by a time out. Once detected, non-distributed and distributed deadlocks are handled by the database and application in the same way.

Deadlocks most often occur when transactions explicitly override the default locking of ORACLE. Because ORACLE itself does no lock escalation, and because ORACLE does not use read locks for queries and does use row level locking (rather than page level locking), deadlocks occur infrequently in ORACLE. See "Explicit (Manual) Data Locking" on page 10 - 21 for more information about manually acquiring locks and another example of a deadlock situation.

 Avoiding Deadlocks

Multi-table deadlocks can usually be avoided if transactions accessing the same tables lock those tables in the same order as each other, either through implicit or explicit locks. For example, all application developers might follow the rule that when both a master and detail table are updated, the master table is locked first, and then the detail table. If such rules are properly designed and then followed in all applications, deadlocks are very unlikely to occur.

When you know you will require a sequence of locks for one transaction, you should consider acquiring the most exclusive (least compatible) lock first.

________________________________________

Explicit (Manual) Data Locking

In all cases, ORACLE automatically performs locking to assure data concurrency, integrity, and statement-level read consistency. However, options are available to allow you to override the ORACLE default locking mechanisms. Overriding the default locking is useful in situations like the following:

•	Applications require transaction-level read consistency or "repeatable reads"; transactions must query a consistent set of data for the duration of the transaction, knowing that the data has not been changed by any other transactions of the system. Transaction-level read consistency can be achieved only by using explicit locking, read-only transactions, or overriding default locking for the system.

•	Applications require that a transaction have exclusive access to a resource; to proceed with its statements, the transaction with exclusive access to a resource does not have to wait for other transactions to complete.

ORACLE's automatic locking can be overridden at two levels:

transaction level	Transactions including the following SQL statements override ORACLE's default locking: the LOCK TABLE command (which locks either a table, or the underlying tables when used with views), and the SELECT command including the FOR UPDATE clause. Locks acquired by these statements are released after the transaction commits or rolls back. (See the ORACLE7 Server SQL Language Reference Manual for information about each command.)

system level	An instance can be started with non-default locking by adjusting the initialization parameters SERIALIZABLE and ROW LOCKING.

Note: If ORACLE's default locking is overridden at any level, the database administrator or application developer should be sure that the overriding locking procedures operate correctly. They must satisfy the following criteria:  data integrity is guaranteed, data concurrency is acceptable, and deadlocks are not possible or are appropriately handled.

Examples of Concurrency Under Explicit Locking

The following illustration shows how ORACLE maintains data concurrency, integrity, and consistency when LOCK TABLE and SELECT with the FOR UPDATE clause statements are used.

Note: For brevity, the message text for ORA-00054 is not included, but reads "resource busy and acquire with NOWAIT specified." User entered text is in bold.

Transaction 1, Time Point, Trans	Time 	Transaction 2

action 2	Point

1

LOCK TABLE scott.dept

   IN ROW SHARE MODE	DROP TABLE scott.dept;

Statement processed	DROP TABLE scott.dept

              *

ORA-00054

(exclusive DDL lock not

possible because of T1's

table lock)

LOCK TABLE scott.dept

   IN EXCLUSIVE MODE NOWAIT;

ORA-00054

2

LOCK TABLE scott.dept

   IN ROW SHARE MODE	DROP TABLE scott.dept;

Statement processed	DROP TABLE scott.dept

              *

ORA-00054

(exclusive DDL lock not

possible because of T1's

table lock)

LOCK TABLE scott.dept

   IN EXCLUSIVE MODE NOWAIT;

ORA-00054

3

DROP TABLE scott.dept;

DROP TABLE scott.dept

              *

ORA-00054

(exclusive DDL lock not

possible because of T1's

table lock)

LOCK TABLE scott.dept

   IN EXCLUSIVE MODE NOWAIT;

ORA-00054

4	SELECT LOC

  FROM scott.dept

  WHERE deptno = 20

  FOR UPDATE OF loc;

LOC

- - - - - - -

BOSTON

1 row selected

UPDATE scott.dept   	5

  SET loc = 'NEW YORK'

  WHERE deptno = 20;

(waits because T2 has locked

same rows)

6	ROLLBACK;

(releases row locks)

1 row processed. 	7

ROLLBACK;

LOCK TABLE scott.dept   	8

  IN ROW EXCLUSIVE MODE;

Statement processed.

9	LOCK TABLE scott.dept

  IN EXCLUSIVE MODE NOWAIT;

ORA-00054

10 	LOCK TABLE scott.dept

 IN SHARE ROW EXCLUSIVE

 MODE NOWAIT;

ORA-00054

11	LOCK TABLE scott.dept

 IN SHARE ROW EXCLUSIVE

 MODE NOWAIT;

ORA-00054

12	UPDATE scott.dept

  SET loc = 'NEW YORK'

  WHERE deptno = 20;

1 row processed.

13	ROLLBACK;

SELECT loc   	14

  FROM scott.dept

  WHERE deptno = 20

  FOR UPDATE OF loc;

LOC

- - - - - -

BOSTON  1 row selected.,

15	UPDATE scott.dept

  SET loc = 'NEW YORK'

  WHERE deptno = 20;

(waits because T1 has locked

same rows)

ROLLBACK; 	16

17	1 row processed.

(conflicting locks were re

leased)

ROLLBACK;

LOCK TABLE scott.dept	18

   IN ROW SHARE MODE

Statement processed

19	LOCK TABLE scott.dept

  IN EXCLUSIVE MODE NOWAIT;

ORA-00054

 	LOCK TABLE scott.dept

 IN SHARE ROW EXCLUSIVE

 MODE NOWAIT;

ORA-00054

21	LOCK TABLE scott.dept

  IN SHARE MODE;

Statement processed.

22	SELECT loc

  FROM scott.dept

  WHERE deptno = 20;

LOC

- - - - - -

BOSTON

1 row selected.

23	SELECT loc

  FROM scott.dept

  WHERE deptno = 20

  FOR UPDATE OF loc;

LOC

- - - - - -

BOSTON

1 row selected.

24	UPDATE scott.dept

  SET loc = 'NEW YORK'

  WHERE deptno = 20;

(waits because T1 holds

conflicting table lock)

ROLLBACK;	25

26	1 row processed.

(conflicting table  lock

released)

ROLLBACK;

LOCK TABLE scott.dept	 27,

 IN SHARE ROW EXCLUSIVE

 MODE;

Statement processed.

28 	LOCK TABLE scott.dept

  IN EXCLUSIVE MODE

  NOWAIT;

ORA-00054

29	LOCK TABLE scott.dept

  IN SHARE ROW EXCLUSIVE

  MODE NOWAIT;

ORA-00054

30	LOCK TABLE scott.dept

  IN SHARE MODE NOWAIT;

ORA-00054

31	LOCK TABLE scott.dept

  IN ROW EXCLUSIVE MODE

  NOWAIT;

ORA-00054

32	LOCK TABLE scott.dept

  IN SHARE MODE NOWAIT;

ORA-00054

33	SELECT loc

  FROM scott.dept

  WHERE deptno = 20;

LOC

- - - - - -

BOSTON

1 row selected.

SELECT loc

  FROM scott.dept

  WHERE deptno = 20

  FOR UPDATE OF loc;

LOC

- - - - - -

BOSTON

1 row selected.

35	UPDATE scott.dept

  SET loc = 'NEW YORK'

  WHERE deptno = 20;

(waits because T1 holds con

flicting table lock)

UPDATE scott.dept   	36

  SET loc = 'NEW YORK'

  WHERE deptno = 20;  	(deadlock)

(waits because T2 has locked

same rows)

Cancel operation  	37

ROLLBACK;

38	1 row processed

LOCK TABLE scott.dept	39

   IN EXCLUSIVE MODE

40 	LOCK TABLE scott.dept

   IN EXCLUSIVE MODE

ORA-00054

41	LOCK TABLE scott.dept

  IN ROW EXCLUSIVE MODE

  NOWAIT;

ORA-00054

42 	LOCK TABLE scott.dept

   IN SHARE MODE

ORA-00054

43	LOCK TABLE scott.dept

  IN ROW EXCLUSIVE MODE

  NOWAIT;

ORA-00054

44	LOCK TABLE scott.dept

  IN ROW SHARE MODE

  NOWAIT;

ORA-00054

45	SELECT loc

  FROM scott.dept

  WHERE deptno = 20;

LOC

- - - - - -

BOSTON

1 row selected.

46	SELECT loc

  FROM scott.dept

  WHERE deptno = 20

  FOR UPDATE OF loc;

(waits because T1 has

conflicting table lock)

UPDATE scott.dept   	47

 SET deptno = 30

 WHERE deptno = 20;

1 row processed.

COMMIT;	48

49	0 rows selected.

(T1 released conflicting

lock)

SET TRANSACTION READ ONLY;	50

SELECT loc   	51

  FROM scott.dept

  WHERE deptno = 10

LOC

- - - - - -

BOSTON

52	UPDATE scott.dept

  SET loc = 'NEW YORK'

  WHERE deptno = 10;

1 row processed.

SELECT loc   	53	SELECT loc   FROM

  FROM scott.dept   	scott.dept   WHERE deptno

  WHERE deptno = 10   	= 10   LOC  ---------  BOS

TON  (T1 does not see uncom

LOC  	mitted data),  53,

- - - - - -

(T1 does not see uncommitted

data)

54	COMMIT;

SELECT loc   	55

  FROM scott.dept

  WHERE deptno = 10

LOC

- - - - - -

(same results seen even af

ter T2 commits)

COMMIT; 	56

SELECT loc   	57

  FROM scott.dept

  WHERE deptno = 10

LOC

- - - - - -

NEW YORK

(committed data is seen)

ORACLE Lock Management Services

ORACLE Lock Management services allow an application developer to include in PL/SQL blocks statements that request a lock of a specific type, give it a unique name recognizable in another procedure in the same or another instance, change the lock type, and release it. Because a reserved user lock is the same as an ORACLE lock, it has all the functionality of an ORACLE lock such as deadlock detection. User locks never conflict with ORACLE locks because they are identified with the prefix "UL".

The ORACLE Lock Management services are available through procedures in the DBMS_LOCK package. For more information about ORACLE Lock Management, see the ORACLE7 Server Application Developer's Guide.


PART  V . DATA ACCESS


CHAPTER 11. SQL AND PL/SQL

A clear statement is the strongest argument.

English proverb

This chapter provides an overview of SQL, the Structured Query Language, and PL/SQL, Oracle's procedural extension to SQL. Topics include:

•	a definition of a SQL statement

•	the types of SQL statements

•	an overview of cursors

•	parsing

•	what PL/SQL blocks and stored procedures are

•	how PL/SQL is executed

You can use PL/SQL only if you have ORACLE with the procedural option. For complete information on PL/SQL, see the PL/SQL User's Guide and Reference.

________________________________________

The Structured Query Language (SQL)

SQL is a very simple, yet powerful, database access language. SQL is a non-procedural language; users describe in SQL want they want done, and the SQL language compiler automatically generates a procedure to navigate the database and perform the desired task.

SQL was developed and defined by IBM Research, and has been refined by ANSI/ISO as the standard language for relational database management systems. The SQL implemented by Oracle Corporation for ORACLE is 100% compliant with the ANSI/ISO standard SQL data language.

ORACLE SQL includes many extensions to the ANSI/ISO standard SQL language, and Oracle tools and applications provide additional commands. For example, the ORACLE tools SQL*Plus and SQL*DBA allow you to execute any ANSI/ISO standard SQL statement against an ORACLE database. They also allow you to execute additional commands or functions that are available for those tools.

Although some ORACLE tools and applications simplify or mask the use of SQL, all database operations are performed using SQL. Any other data access method would circumvent the security built into ORACLE and potentially compromise data security and integrity.

Refer to the ORACLE7 Server SQL Language Reference Manual for more information about SQL commands and other parts of SQL (e.g., functions, etc.), and the ORACLE7 Server Utilities User's Guide for more information about SQL*DBA commands, including their distinction from SQL commands.

SQL Statements

All operations performed on the information in an ORACLE database are executed using SQL statements. A SQL statement is specific instance of a valid SQL command. A statement partially consists of SQL reserved words, which have special meaning in SQL and cannot be used for any other purpose. For example, SELECT and UPDATE are reserved words and cannot be used as table names.

The statement must be the equivalent of a SQL "sentence," as in:

SELECT ename, deptno FROM emp

Only a SQL statement can be executed, whereas a "sentence fragment" such as the following generates an error indicating that more text is required before a SQL statement can execute:

SELECT ename

A SQL statement can be thought of as a very simple, but powerful, computer program or instruction.

ORACLE SQL statements are divided into the following categories:

•	Data Manipulation Language statements (DML)

•	Data Definition Language statements (DDL)

•	Transaction Control statements

•	Session Control statements

•	System Control statements

•	Embedded SQL statements

Each category of SQL statement is briefly described below.

Note: ORACLE also supports the use of SQL statements in PL/SQL program units; refer to Chapters 14 and 15 for more information about this feature.

 Data Manipulation Statements (DML)

DML statements query or manipulate data in existing schema objects. They allow you to do the following:

•	Remove rows from tables or views (DELETE).

•	See the execution plan for a SQL statement (EXPLAIN PLAN).

•	Add new rows of data into a table or view (INSERT).

•	Lock a tables or view, temporarily limiting other users' access to it (LOCK TABLE).

•	Retrieve data from one or more tables and views (SELECT).

•	Change column values in existing rows of a table or view (UPDATE).

DML statements are the most frequently used SQL statements. Some examples of DML statements follow:

SELECT ename, mgr, comm + sal FROM emp;

INSERT INTO emp VALUES

(1234, 'DAVIS', 'SALESMAN', 7698, '14-FEB-1988', 1600, 500, 30;

DELETE FROM emp WHERE ename IN ('WARD','JONES');

 Transaction Control Statements

Transaction control statements manage the changes made by DML statements, and group DML statement into transaction. They allow you to do the following:

•	Make a transaction's changes permanent (COMMIT).

•	Undo the changes in a transaction, either since the transaction started or since a savepoint (ROLLBACK).

•	Set a point to which you can roll back (SAVEPOINT).

•	Establish properties for a transaction (SET TRANSACTION).

 Data Definition Statements (DDL)

DDL statements define, alter the structure of, and drop schema objects. DDL statements allow you to do the following:

•	Create, alter, and drop schema objects and other database structures, including the database itself and database users (CREATE, ALTER, DROP).

•	Change the names of schema objects (RENAME).

•	Delete all the data in schema objects without removing the objects' structure (TRUNCATE).

•	Gather statistics about schema objects, validate object structure, and list chained rows within objects (ANALYZE).

•	Grant and revoke privileges and roles (GRANT, REVOKE).

•	Turn auditing options on and off (AUDIT, NOAUDIT).

•	Add a comment to the data dictionary (COMMENT).

DDL statements implicitly commit the preceding transaction, and start a new transaction. Some examples of DDL statements follow:

CREATE TABLE plants

(COMMON_NAME VARCHAR2 (15), LATIN_NAME VARCHAR2 (40));

DROP TABLE plants;

GRANT SELECT ON emp TO scott;

REVOKE DELETE ON emp FROM scott;

For specific information on DDL statements that correspond to database and data access, refer to Chapters 17  through 19..

 Session Control Statements

Session control commands manage the properties of a particular user's session. For example, they allow you to do the following:

•	Alter the current session by performing a specialized function, such as enabling and disabling the SQL trace facility (ALTER SESSION).

•	Enable and disable roles (groups of privileges) for the current session (SET ROLE).

 System Control Statements

System control commands change the properties of the ORACLE Server instance. The only system control command is ALTER SYSTEM; it allows you to change such settings as the minimum number of shared servers, to kill a session, and to perform other tasks.

 Embedded SQL Statements

Embedded SQL statements incorporate DDL, DML, and transaction control statements within a procedural language program. They are used with the ORACLE Precompilers. Embedded SQL statements allow you to do the following:

•	Define, allocate, and release cursors (DECLARE CURSOR, OPEN, CLOSE).

•	Declare a database name and connect to ORACLE (DECLARE DATABASE, CONNECT).

•	Assign variable names, initialize descriptors, and specify how error and warning conditions are handled (DECLARE STATEMENT, DESCRIBE, WHENEVER).

•	Parse and execute SQL statements, and retrieve data from the database (PREPARE, EXECUTE, EXECUTE IMMEDIATE, FETCH).

Recursive SQL

When a DDL statement is issued, ORACLE implicitly issues recursive SQL statements that modify data dictionary information. Users need not be concerned with recursive SQL internally performed by ORACLE.

Cursors

A cursor is a handle or name for an area in memory in which a parsed statement and other information for processing the statement are kept; such an area is also called a private SQL area. Although most ORACLE users rely on the automatic cursor handling of the Oracle utilities, the programmatic interfaces offer application designers more control over cursors. In application development, a cursor is a named resource available to a program and can be specifically used for the parsing of SQL statements embedded within the application.

Shared SQL

ORACLE automatically notices when applications send identical SQL statements to the database. If two identical statements are issued, the SQL area used to process the first instance of the statement is shared, or used for the processing of the subsequent instances of that same statement. Therefore, instead of having multiple shared SQL areas for identical SQL statements, only one shared SQL area exists for a unique statement. Thus, shared SQL areas are shared memory areas; any ORACLE process can use a shared SQL area. The sharing of SQL areas reduces memory usage on the database server, thereby increasing system throughput.

In evaluating whether statements are identical, ORACLE considers SQL statements issued directly by users and applications as well as recursive SQL statements issued internally by a DDL statement.

For more information on shared SQL, see the ORACLE7 Server Application Developer's Guide.

What Is Parsing?

Parsing is one step in the processing of a SQL statement by ORACLE. When an application issues a SQL statement, the application makes a parse call to ORACLE. During the parse call, ORACLE performs these tasks:

•	checks the statement for syntactic and semantic validity

•	determines whether the process issuing the statement has privileges to execute it

•	allocates a private SQL area for the statement

ORACLE also determines whether there is an existing shared SQL area containing the parsed representation of the statement in the library cache already. If so, the user process uses this parsed representation and executes the statement immediately. If not, ORACLE parses the statement, performing these tasks:

•	ORACLE generates the parsed representation of the statement.

•	The user process allocates a shared SQL area for the statement in the library cache and stores its parsed representation there.

Note the difference between an application making a parse call for a SQL statement and ORACLE actually parsing the statement:

•	A parse call by the application associates a SQL statement with a private SQL area. Once a statement has been associated with a private SQL area, it can be executed repeatedly without your application making a parse call.

•	A parse operation by ORACLE allocates a shared SQL area for a SQL statement. Once a shared SQL areas has been allocated for a statement, it can be executed repeatedly without being reparsed.

Since both parse calls and parsing can be expensive relative to execution, it is desirable to perform them as seldom as possible.

This discussion also applies to the parsing of PL/SQL blocks and the allocation of PL/SQL areas. (See the description of PL/SQL, in the next section.) Stored procedures, functions, and packages and triggers are assigned PL/SQL areas. Each SQL statement within a PL/SQL block is also assigned a shared and a private SQL area.

________________________________________

PL/SQL

PL/SQL is Oracle's procedural language extension to SQL. PL/SQL allows you to mix SQL statements with procedural constructs. PL/SQL provides the capability to define and execute PL/SQL program units such as procedures, functions, and packages. PL/SQL program units are generally categorized as anonymous blocks and stored procedures.

An anonymous block is a PL/SQL block that appears within your application. In many applications, PL/SQL blocks can appear wherever SQL statements can appear. Such blocks are called anonymous blocks because they are not named.

 A stored procedure is a PL/SQL block that is stored in the database and can be called by name from an application. When you create a stored procedure, ORACLE parses the procedure and stores its parsed representation in the database. ORACLE also allows you to create and store functions, which are similar to procedures, and packages, which are groups of procedures and functions. For information on stored procedures, functions, packages, and database triggers, see Chapter 14 and Chapter 15.

How PL/SQL Is Executed

The PL/SQL engine is a special component of many Oracle products, including the ORACLE Server, that processes PL/SQL. Figure 11 - 1 illustrates the PL/SQL engine contained in ORACLE Server.

•

The procedure (or package) is stored in a database. When a procedure stored in the database is called from an application, the compiled procedure (or package) is loaded into the shared pool in the System Global Area (SGA) and the PL/SQL and SQL statement executors work together to process the statements within the procedure.

The PL/SQL engine is incorporated into these Oracle products:

•	ORACLE Server with the procedural option

•	SQL*Forms (Version 3 and later)

•	SQL*Menu (Version 5 and later)

•	SQL*ReportWriter (Version 2 and later)

•	Oracle Graphics (Version 2 and later)

If you have ORACLE with the procedural option, you can call a stored procedure from another PL/SQL block, which can be either an anonymous block or another stored procedure. For example, you can call a stored procedure from SQL*Forms (Version 3 or later).

Also, you can pass anonymous blocks to ORACLE from applications developed with these tools:

•	ORACLE Precompilers (including user exits)

•	ORACLE Call Interfaces (OCIs)

•	SQL*Plus

•	SQL*DBA

Language Constructs for PL/SQL

PL/SQL blocks can include the following PL/SQL language constructs:

•	variables and constants

•	cursors

•	exceptions

The following sections give a general description of each construct; see the PL/SQL User's Guide and Reference for more information.

Variables and Constants   Variables and constants can be declared within a procedure, function, or package. A variable or constant can be used in a SQL or PL/SQL statement to capture or provide a value when one is needed.

Note: Some interactive tools, such as SQL*DBA, allow you to define variables in your current session. Variables declared using this method can be used in a similar manner as variables declared within procedures or packages.

Cursors      Cursors can be explicitly declared within a procedure, function, or package to facilitate record-oriented processing of ORACLE data. Cursors can also be implicitly declared (to support other data manipulation actions) by the PL/SQL engine.

Exceptions      PL/SQL allows you to explicitly handle internal and user-defined error conditions, called exceptions, that arise during processing of PL/SQL code. Internal exceptions are caused by illegal operations, such as divide-by-zero, or ORACLE errors returned to the PL/SQL code. User-defined exceptions are explicitly defined and signaled within the PL/SQL block to control processing of errors specific to the application (e.g., debiting an account and leaving a negative balance).

When an exception is raised (signaled), the normal execution of the PL/SQL code stops and a routine called an exception handler is invoked. Specific exception handlers can be written to handle any internal or user-defined exception.

While many Oracle products have PL/SQL components, this chapter specifically covers the procedures and packages that can be stored in an ORACLE database and processed using the PL/SQL engine of ORACLE Server. The PL/SQL capabilities of each Oracle tool are described in the appropriate tool user guide.

ORACLE with the procedural option also allows you to create and call stored procedures. If your application calls a stored procedure, the parsed representation of the procedure is retrieved from the database and processed by the PL/SQL engine in ORACLE. You can call stored procedures from applications developed using these tools:

•	ORACLE Precompilers (including user exits)

•	ORACLE Call Interfaces (OCIs)

•	SQL*Module

•	SQL*Plus

•	SQL*DBA

You can also call a stored procedure from another PL/SQL block, either an anonymous block or another stored procedure. For information on how to call stored procedures from each type of application, see the manual for the specific application tool, such as the Programmer's Guide to the ORACLE Precompilers.


CHAPTER 12. TRANSACTION MANAGEMENT

Success generally depends upon knowing how long it takes to succeed.

Charles Louis de Secondat Montesquieu

This chapter defines a transaction and describes how you can manage your work using transactions. Topics include:

•	the definition of a transaction

•	the start point of a transaction

•	the end point of a transaction

•	transaction management

•	committing transactions

•	rolling back transactions

•	defining savepoints

•	discrete transactions

________________________________________

Introduction to Transactions

A transaction is a logical unit of work that is comprised of one or more SQL statements. A transaction is an atomic unit; the effects of all the SQL statements that constitute a transaction can either all be committed (applied to the database) or all rolled back (undone from the database).

A transaction begins with the first executable SQL statement. A transaction ends when it is committed or rolled back, either explicitly (with a COMMIT or ROLLBACK statement) or implicitly (when a DDL statement is issued).

To illustrate the concept of a transaction, consider a banking database. When a bank customer transfers money from a savings account to a checking account, the transaction might consist of three separate operations: decrement the savings account, increment the checking account, and record the transaction in the transaction journal.

ORACLE must allow for two situations. If all three SQL statements can be performed to maintain the accounts in proper balance, the effects of the transaction can be applied to the database. However, in the event that something (such as insufficient funds, invalid account number, or a hardware failure) prevents one or two of the statements in the transaction from completing, the entire transaction can be rolled back so that the balance of the accounts are correct.

Figure 12 - 1 illustrates the banking transaction example.

Statement Execution and Transaction Control

A SQL statement that "executes successfully" is different from a "committed" transaction.

Executing successfully means that a single statement was parsed and found to be a valid SQL construction, and that the entire statement executed without error as an atomic unit (e.g., all rows of a multi-row update are updated). However, until the transaction that contains the statement is committed, the transaction can be rolled back and all of the changes of the statement can be undone. A statement, rather than a transaction, executes successfully.

Committing means that a user has either explicitly or implicitly said "make the changes in this transaction permanent." You commit a transaction, which can consist of one or many SQL statements; you do not commit every single statement. The changes made by the SQL statement(s) of your transaction only become permanent and visible to other users' transactions that start after your transaction has been committed.

Statement-Level Rollback

If at any time during execution a SQL statement causes an error, all effects of the statement are rolled back. The effect of the rollback is as if that statement were never executed.

Errors that cause statement rollbacks are errors discovered during the execution stage of SQL statement processing (such as attempting to insert a duplicate value in a primary key or an invalid number into a numeric column), not the parsing stage (such as syntax errors in a SQL statement). Single SQL statements can also be rolled back in order to resolve deadlocks (competition for the same data); see "Deadlock Detection" on page 10 - 20.

Therefore, a SQL statement that fails causes the loss only of any work it would have performed itself; it does not cause the loss of any work that preceded it in the current transaction. If the statement is a DDL statement, the implicit commit that immediately preceded it is not undone. This is a statement-level rollback. (Note: Users cannot directly refer to implicit savepoints in rollback statements.)

________________________________________

ORACLE and Transaction Management

A transaction in ORACLE begins when the first executable SQL statement is encountered. An executable SQL statement is a SQL statement that generates calls to an instance including DML and DDL statements.

When a transaction begins, the transaction is assigned to an available rollback segment to record the rollback entries for the new transaction. See "Transactions and Rollback Segments" on page 3 - 16 for more information about this topic.

A transaction ends when any of the following occurs:

•	A COMMIT or ROLLBACK (without a SAVEPOINT clause) statement is issued.

•	A DDL statement is executed (such as CREATE, DROP, RENAME, ALTER). If the current transaction contains any DML statements, the transaction is first committed, and the DDL statement is executed and committed as a new, single statement transaction.

•	A user disconnects from ORACLE. (The current transaction

 is committed.)

•	There is an abnormal termination of a user process. (The current transaction is rolled back.)

After one transaction ends, the next executable SQL statement automatically starts the following transaction.

Note: Applications should always explicitly commit or roll back transactions before program termination.

Committing Transactions

Committing a transaction means making permanent the changes performed by the SQL statements within the transaction.

Before committing a transaction that has modified data, the following have occurred:

•	ORACLE has generated rollback segment records in rollback segment buffers of the SGA. The rollback information contains the old data values changed by the SQL statements of the transaction.

•	ORACLE has generated redo log entries in the redo log buffers of the SGA. These changes may go to disk before a transaction is committed.

•	The changes have been made to the database buffers of the SGA. These changes may go to disk before a transaction is actually committed.

After a transaction is committed, the following occurs:

•	The internal transaction table for the associated rollback segment records that the transaction has committed and a corresponding unique system change number (SCN) of the transaction is assigned and recorded in the table.

•	The redo log entries in the redo log buffers of the SGA are written to the online redo log file by LGWR process. The transaction's SCN is also written to the online redo log file; this is the atomic event that constitutes the commit of the transaction.

•	Locks held on rows and tables are released (see "Locking Mechanisms" on page 10 - 9 for a discussion of locks).

•	The transaction is marked "complete."

Note: The data changes for a committed transaction, stored in the database buffers of the SGA, are not necessarily written immediately to the data files by the DBWR background process. This action takes place when it is most efficient to do so; as mentioned above, this may happen before the transaction commits, or alternatively, it may happen some time after the transaction commits. See "ORACLE Processes" on page 9 - 7  for more information about the LGWR and DBWR..

Rolling Back Transactions

Rolling back means undoing any changes to data that have been performed by SQL statements within an uncommitted transaction.

ORACLE allows an entire uncommitted transaction to be rolled back. Alternatively, the trailing portion of an uncommitted transaction can be rolled back to a marker called a savepoint; see "Savepoints" on page 12 - 6 for a complete explanation of savepoints.

In rolling back an entire transaction, without referencing any savepoints, the following occurs:

•	All changes made by all the SQL statements in the transaction are undone using the corresponding rollback segments.

•	All the transaction's locks of data are released (see "Locking Mechanisms" on page 10 - 9 for a discussion of locks).

•	The transaction is ended.

By rolling back a transaction to a savepoint, the following occurs:

•	Only the statements executed after the savepoint are rolled back.

•	The specified savepoint is preserved, but all savepoints that were established after the specified one are lost.

•	All table and row locks acquired since that savepoint are released, but all data locks acquired previous to the savepoint are retained (see "Locking Mechanisms" on page 10 - 9 for a discussion of locks).

•	The transaction is still active; it can be continued.

Savepoints

Intermediate markers or savepoints can be declared within the context of a transaction. Savepoints are often used to divide a long transaction into smaller parts.

Using savepoints, you can arbitrarily mark your work at any point within a long transaction. This allows you the option of later rolling back work performed before the current point in the transaction (the end of the transaction) but after a declared savepoint within the transaction. For example, you can use savepoints throughout a long complex series of updates, so that if you make an error, you do not need to resubmit every statement.

Savepoints are also useful in application programs in a similar way. If a procedure contains several functions, a savepoint can be created before each function begins. Then, if a function fails, it is easy to return the data to its original state before the function began and then re-execute the function with revised parameters or perform a recovery action.

After a rollback to a savepoint, the data locks obtained by rolled back statements are released. Other transactions that were waiting for the previously locked resources can proceed. Other transactions that want to update previously locked rows can do so.

________________________________________

Discrete Transaction Management

Application developers can improve the performance of short, non-distributed transactions by using the bundled procedure BEGIN_DISCRETE_TRANSACTION, which is included with the ORACLE Server with the procedural database option. This procedure streamlines transaction processing so short transactions can execute more rapidly.

During a discrete transaction, all changes made to any data are deferred until the transaction commits. Other concurrent transactions are unable to see the uncommitted changes of a transaction during normal transaction processing or during the processing of discrete transactions.

Redo information is generated, but is stored in a separate location in memory. When the transaction issues a commit request, the redo information is written to the redo log file (along with other group commits) and the changes to the database block are applied directly to the block. Control is returned to the application, once the commit completes. This eliminates the need to generate undo information since the block is not actually modified until the transaction is committed, and the redo information is stored in the redo log buffers.

For more information on discrete transactions, see the ORACLE7 Server Application Developer's Guide.


CHAPTER 13. THE OPTIMIZER

It is a bad plan that admits of no modification.

Publilius Syrus: Maxim 469

This chapter discusses how the ORACLE optimizer chooses how to execute SQL statements. Topics include the following:

•	what the ORACLE optimizer is

•	how ORACLE optimizes SQL statements

________________________________________

What is Optimization?

Optimization is an important step in the processing of any Data Manipulation Language statement (SELECT, INSERT, UPDATE or DELETE). Whenever such a statement is issued, ORACLE must determine how to execute the statement. There may be many different ways for ORACLE to execute a single statement. A part of ORACLE called the optimizer chooses one of these ways.

The goal of the optimizer is to choose the most efficient way to execute a SQL statement. The optimizer considers a number of factors to make what is usually the best choice among its alternatives. However, an application designer usually knows more about a particular application's data than the optimizer could possibly know. Despite the best efforts of the optimizer, in some situations a developer can choose a more effective way to execute a SQL statement than the optimizer can.

Note: The optimizer may not make the same decisions from one version of ORACLE to the next. In future versions of ORACLE, the optimizer may make different decisions based on better, more sophisticated information available to it.

Execution Plans

To execute a Data Manipulation Language statement, ORACLE may have to perform many steps. Each of these steps either physically retrieves rows of data from the database or prepares them in some way for the user issuing the statement. The combination of the steps the optimizer chooses to execute a statement is called an execution plan.

Example	This example shows an execution plan for this SQL statement:

SELECT ename, job, sal, dname

FROM emp, dept

  WHERE emp.deptno = dept.deptno

AND NOT EXISTS

(SELECT *

FROM salgrade

  WHERE emp.sal BETWEEN losal AND hisal)

This statement selects the name, job, salary, and department name for all employees whose salaries do not fall into any recommended salary range.

Figure 13 - 1  shows a graphical representation of the execution plan.

 Steps of Execution Plan

Each step of the execution plan returns rows that are either used by another step or returned to the user issuing the SQL statement. A set of rows returned by a step is called a row source. Figure 13 - 1 is a hierarchical diagram showing the flow of rows from one step to another.

Each step of the execution plan either retrieves rows from the database or accepts rows from one or more row sources as input:

•	Steps indicated by gray circles physically retrieve data from an object in the database. Such steps are called access paths:

•	Steps 3 and 6 read all the rows of the EMP and SALGRADE tables, respectively.

•	For each row of the EMP table returned by Step 3, Step 5 uses the DEPTNO value to searches the PK_DEPTNO index to find the ROWIDs of the row in the DEPT table with the matching DEPTNO value.

•	Step 4 uses the ROWIDs returned by Step 5 to locate rows in the DEPT table and return them.

•	Steps indicated by clear circles operate on row sources:

•	Step 2 performs a nested loops operation, accepting row sources from Steps 3 and 4, joining each row from Step 3 source to its corresponding row in Step 4, and returning the resulting rows to Step 1.

•	Step 1 performs a filter operation, accepting row sources from Steps 2 and 6, eliminating rows from Step 2 based on the presence of a corresponding row in Step 6, and returning the remaining rows to the user issuing the statement.

Access paths are discussed in the section "Choosing Access Paths" on page 13 - 26. Methods by which ORACLE joins row sources are discussed in the section "Join Operations" on page 13 - 44.

 Order of Performing Execution Plan Steps

The steps of the execution plan are not performed in the order in which they are numbered. ORACLE first performs the steps that appear as leaf nodes in the tree-structured graphical representation in Figure 13 - 1. The rows returned by each step are then returned to each parent step. Then ORACLE can perform the parent steps.

To execute the statement for Figure 13 - 1, ORACLE performs steps in this order:

•	First, ORACLE performs Step 3, and returns the resulting rows, one at a time, to Step 2.

•	For each row returned by Step 3, ORACLE performs these steps:

•	ORACLE performs Step 5 and returns the resulting ROWID to Step 4.

•	ORACLE performs Step 4, and returns the resulting row to Step 2.

•	ORACLE performs Step 2, accepting a single row from Step 3 and a single row from Step 4 and returning a single row to Step 1.

•	ORACLE performs Step 6 and returns the resulting row, if there is one, to Step 1.

•	ORACLE performs Step 1. If a row is returned from Step 6, ORACLE returns the row from Step 2 to the user issuing the SQL statement.

Note that ORACLE performs Steps 5, 4, 2, 6, and 1 once for each row returned by Step 2. Many parent steps require only a single row from their child steps before they can be executed. For such a parent step, ORACLE performs the parent step (and possibly the rest of the execution plan) as soon as a single row has been returned from the child step. ORACLE then performs the parent step once for each row subsequently returned by the child step. Such parent steps include table accesses, index accesses, nested loops joins, and filters.

Some parent steps require all rows from their child steps before they can be performed. For such a parent step, ORACLE cannot perform the parent step until all rows have been returned from the child step. Such parent steps include sorts, sort-merge joins, and group functions, or aggregates.

 The EXPLAIN PLAN Command

You can examine the execution plan chosen by the optimizer for a SQL statement by using the EXPLAIN PLAN command. This command causes the optimizer to choose the execution plan and then inserts data describing the plan into a database table. This is a tabular representation of the execution plan for the statement described in the previous section:

ID	OPERATION	OPTIONS	OBJECT_NAME

------------------------------------------------------------

0	SELECT STATEMENT

1	  FILTER

2	    NESTED LOOPS

3	      TABLE ACCESS	FULL	EMP

4	      TABLE ACCESS	BY ROWID	DEPT

5	        INDEX	UNIQUE SCAN	PK_DEPTNO

6	    TABLE ACCESS	FULL	SALGRADE

You can obtain such a listing by using the EXPLAIN PLAN command and then querying the output table. For information on how to use this command and produce and interpret its output, see Appendix B "Performance Diagnostic Tools" of the ORACLE7 Server Application Developer's Guide.

Each circle in the figure and each row in the output table corresponds to a single step in the execution plan. For each row in the listing, the value in the ID column is the value shown in the corresponding circle in the figure.

ORACLE's Approaches to Optimization

To choose an execution plan for a SQL statement, the optimizer uses one of these approaches:

rule-based	Using the rule-based approach, the optimizer chooses an execution plan based on the access paths available and the ranks of these access paths in Table 13 - 1 on page 13 - 28.

cost-based	Using the cost-based approach, the optimizer considers available access paths and determines which execution plan is most efficient based on statistics in the data dictionary for the tables accessed by the statement and their associated clusters and indexes. The cost-based approach also considers hints, or optimization suggestions placed in a comment, in the statement.

 The Rule-Based Approach

The rule-based approach chooses execution plans based on heuristically-ranked operations. If there is more than one way to execute a SQL statement, the rule-based approach always uses the operation with the lower rank. In most cases, operations of lower rank execute faster than those associated with constructs of higher rank.

 The Cost-Based Approach

Conceptually, the cost-based approach consists of these steps:

1..	The optimizer generates a set of potential execution plans for the statement based on its available access paths and hints.

2..	The optimizer estimates the cost of each execution plan based on the data distribution and storage characteristics statistics for the tables, clusters, and indexes in the data dictionary.

The cost is an estimated value proportional to the expected elapsed time needed to execute the statement using the execution plan. The optimizer calculates the cost based on the estimated computer resources including but not limited to I/O, CPU time, and memory required to execute the statement using the plan. Execution plans with greater costs take more time to execute than those with smaller costs.

3..	The optimizer compares the costs of the execution plans and chooses the one with the smallest cost.

Goal of the Cost-Based Approach      By default, the goal of the cost-based approach is the best throughput, or minimal elapsed time necessary to process all rows accessed by the statement.

ORACLE can also optimize a statement with the goal of best response time, or minimal elapsed time necessary to process the first row accessed by a SQL statement. For information how the optimizer chooses an optimization approach and goal, see the section "Choosing an Optimization Approach and Goal" on page 13 - 24.

Statistics Used for the Cost-Based Approach      The cost-based approach uses statistics to estimate the cost of each execution plan. These statistics quantify the data distribution and storage characteristics of tables, columns, and indexes. These statistics are generated using the ANALYZE command. Using these statistics, the optimizer estimates how much I/O, CPU time, and memory are required to execute a SQL statement using a particular execution plan.

The statistics are visible through these data dictionary views:

•	USER_TABLES, ALL_TABLES, and DBA_TABLES

•	USER_TAB_COLUMNS, ALL_TAB_COLUMNS, and DBA_TAB_COLUMNS

•	USER_INDEXES, ALL_INDEXES, and DBA_INDEXES

•	USER_CLUSTERS and DBA_CLUSTERS

For information on these statistics, see Appendix D "Data Dictionary Reference" of the ORACLE7 Server Application Developer's Guide or Appendix B "Data Dictionary Reference" of the of the ORACLE7 Server Administrator's Guide

________________________________________

How ORACLE Optimizes SQL Statements

This section explains how ORACLE optimizes SQL statements. For any SQL statement processed by ORACLE, the optimizer performs these tasks:

evaluation of expressions and conditions	The optimizer first evaluates expressions and conditions containing constants as fully as possible.

statement transformation	For a complex statement, the optimizer may transform the original statement into an equivalent join statement.

view merging	For a SQL statement that accesses a view, the optimizer often merges the view's query into the original statement or the original statement into the view's query and then optimizes the result.

choice of optimization approaches	The optimizer chooses either a rule-based or cost-based approach to optimization.

choice of access paths	For each table accessed by the statement, the optimizer chooses one or more of the available access paths to obtain the table's data.

choice of join orders	For a join statement that joins more than two tables, the optimizer chooses which pair of tables is joined first, and then which table is joined to the result, etc.

choice of join operations	For any join statement, the optimizer chooses an operation to use to perform the join.

Types of SQL Statements

ORACLE optimizes these different types of SQL statements:

simple statements	A simple statement is an INSERT, UPDATE, DELETE, or SELECT statement that only involves a single table.

simple queries	A query is another name for a SELECT statement.

joins	A join is a query that selects data from more than one table. A join is characterized by multiple tables in the FROM clause. ORACLE pairs the rows from these tables using the condition specified in the WHERE clause and returns the resulting rows. This condition is called the join condition and usually compares columns of all the joined tables.

equijoins	An equijoin is characterized by a join condition containing an equality operator.

nonequijoins	An nonequijoin is characterized by a join condition containing something other than an equality operator.

outer joins	An outer join is characterized by a join condition that uses the outer join operator (+) with one or more of the columns of one of the tables. ORACLE returns all rows that meet the join condition. ORACLE also returns all rows from the table without the outer join operator for which there are no matching rows in the table with the outer join operator.

cartesian products	A join with no join condition results in a cartesian product, or a cross product. A cartesian product for two tables is the result of pairing each row of one table with each row of the other table. A cartesian product for more than two tables is the result of pairing each row of one table with each row of the cartesian product of the remaining tables.

complex statements	A complex statement is an INSERT, UPDATE, DELETE, or SELECT statement that contains a form of the SELECT statement called a subquery. The outer portion of the complex statement that uses the rows returned by the subquery is called the parent statement.

compound queries	A compound query is a query that uses set operators (UNION, UNION ALL, INTERSECT, or MINUS) to combine two or more simple or complex statements. Each simple or complex statement in a compound query is called a component query.

statements accessing views	You can also write simple, join, complex, and compound statements that access views as well as tables.

distributed statements	A distributed statement is one that accesses data on a remote database.

Evaluating Expressions and Conditions

The optimizer fully evaluates expressions whenever possible and translates certain syntactic constructs into equivalent constructs. The optimizer performs some of these evaluations because ORACLE can more quickly evaluate the resulting expression than the original expression. The optimizer performs some of the translations because the original expression is merely a syntactic equivalent for the resulting expression.

Constants      Any computation involved with such evaluation is performed only once when the statement is optimized rather than each time the statement is executed. Consider these conditions that test for monthly salaries greater than 2000:

sal > 24000/12

sal > 2000

sal*12 > 24000

If a SQL statement contains the first condition, the optimizer simplifies it into the second condition.

Note that the optimizer does not simplify expressions across comparison operators. The optimizer does not simplify the third expression into the second. For this reason, application developers should write conditions that compare columns with constants whenever possible, rather than conditions with expressions involving columns.

LIKE      The optimizer simplifies conditions that use the LIKE comparison operator to compare an expression with no wildcard characters into an equivalent condition that uses an equality operator instead. For example, the optimizer simplifies the first condition below into the second:

ename LIKE 'SMITH'

ename = 'SMITH'

IN      The optimizer expands a condition that uses the IN comparison operator to an equivalent condition that uses equality comparison operators and OR logical operators. For example, the optimizer expands the first condition below into the second:

ename IN ('SMITH', 'KING', 'JONES')

ename = 'SMITH' OR ename = 'KING' OR ename = 'JONES'

ANY or SOME      The optimizer expands a condition that uses the ANY or SOME comparison operator followed by a parenthesized list of values to an equivalent condition that uses equality comparison operators and OR logical operators. For example, the optimizer expands the first condition below into the second:

sal > ANY (:first_sal, :second_sal)

sal > :first_sal OR sal > :second_sal

The optimizer transforms a condition that uses the ANY or SOME operator followed by a subquery into a condition containing the EXISTS operator and a correlated subquery. For example, the optimizer transforms the first condition below into the second:

x > ANY (SELECT sal

FROM emp

WHERE job = 'ANALYST')

EXISTS (SELECT sal

FROM emp

WHERE job = 'ANALYST'

  AND x > sal)

ALL      The optimizer expands a condition that uses the ALL comparison operator followed by a parenthesized list of values to an equivalent condition that uses equality comparison operators and AND logical operators. For example, the optimizer expands the first condition below into the second:

sal > ALL (:first_sal, :second_sal)

sal > :first_sal AND sal > :second_sal

The optimizer transforms a condition that uses the ALL comparison operator followed by a subquery to an equivalent condition that uses the ANY comparison operator and a complementary comparison operator. For example, the optimizer transforms the first condition below into the second:

x > ALL (SELECT sal

FROM emp

WHERE deptno = 10)

NOT (x <= ANY (SELECT sal

FROM emp

WHERE deptno = 10) )

The optimizer then transforms the second query to the following query using the rule for transforming conditions with the ANY comparison operator followed by a correlated subquery:

NOT EXISTS (SELECT sal

FROM emp

WHERE deptno = 10

  AND x <= sal)

BETWEEN      The optimizer always replaces a condition that uses the BETWEEN comparison operator with an equivalent condition that uses the >= and <= comparison operators. For example, the optimizer replaces the first condition below with the second:

sal BETWEEN 2000 AND 3000

sal >= 2000 AND sal <= 3000

NOT      The optimizer always simplifies a condition to eliminate the NOT logical operator. The simplification involves removing the NOT logical operator and replacing a comparison operator with its opposite comparison operator. For example, the optimizer simplifies the first condition below into the second one:

NOT deptno = (SELECT deptno FROM emp WHERE ename = 'TAYLOR')

deptno <> (SELECT deptno FROM emp WHERE ename = 'TAYLOR')

Often a condition containing the NOT logical operator can be written many different ways. The optimizer attempts to transform such a condition so that the subconditions negated by NOTs are as simple as possible, even if the resulting condition contains more NOTs. For example, the optimizer simplifies the first condition below into the second and then into the third.

NOT (sal < 1000 OR comm IS NULL)

NOT sal < 1000 AND comm IS NOT NULL

sal >= 1000 AND comm IS NOT NULL

Transitivity      If two conditions in the WHERE clause involve a common column, the optimizer can sometimes infer a third condition using the transitivity principle. The optimizer can then use the inferred condition to optimize the statement. The inferred condition could potentially make available an index access path that was not made available by the original conditions.

Imagine a WHERE clause containing two conditions of these forms:

WHERE column1 comp_oper constant

  AND column1 = column2

In this case, the optimizer infers this condition:

column2 comp_oper constant

where:

comp_oper	is any of the comparison operators =, !=, ^=, <,=, <>, <, >, <=, or >=.

constant	is any constant expression involving operators, SQL functions, literals, bind variables, and correlation variables.

Example	Consider this query in which the WHERE clause containing two conditions that each use the EMP.DEPTNO column:

SELECT *

FROM emp, dept

WHERE emp.deptno = 20

  AND emp.deptno = dept.deptno

Using transitivity, the optimizer infers this condition:

dept.deptno = 20

If there is an index on the DEPT.DEPTNO column, this condition makes available access paths using that index.

Note: The optimizer only infers conditions that related columns to constant expressions, rather than columns to other columns. Imagine a WHERE clause containing two conditions of these forms:

WHERE column1 comp_oper column3

  AND column1 = column2

In this case, the optimizer does not infer this condition:

column2 comp_oper column3

Transforming Statements

Since SQL is such a flexible query language, a single goal can often be achieved by more than one statement. Sometimes the optimizer transforms one such statement into another that achieves the same goal if the second statement can be executed more efficiently. This section discusses the following transformations that the optimizer can make:

•	transforming queries containing ORs into compound statements containing UNION ALL

•	transforming complex statements into join statements

 Transforming ORs into Compound Queries

If a query contains a WHERE clause with multiple conditions combined with OR operators, the optimizer transforms it into an equivalent compound query that uses the UNION ALL set operator if the compound query can be executed more efficiently:

•	If each condition individually makes an index access paths available, the optimizer can make the transformation. The optimizer then chooses an execution plan for the resulting statement that accesses the table multiple times using the different indexes and then puts together the results.

•	If any condition requires a full table scan because it does not make an index available, the optimizer does not transform the statement. The optimizer chooses a full table scan to execute the statement and ORACLE tests each row in the table to determine whether it satisfies any of the conditions.

For information on access paths and how indexes make them available, see Table 13 - 1 on page 13 - 28 and the sections that follow it. For statements that use the cost-based approach, the optimizer may also use statistics to determine whether to make the transformation by estimating and then comparing the costs of the executing the original statement and resulting statement.

Example	Consider this query with a WHERE clause that contains two conditions combined with an OR operator:

SELECT *

FROM emp

WHERE job = 'CLERK'

  OR deptno = 10

If there are indexes on both the JOB and DEPTNO columns, the optimizer may transform the query above into the equivalent query below:

SELECT *

FROM emp

WHERE job = 'CLERK'

UNION ALL

SELECT *

FROM emp

WHERE deptno = 10

  AND job <> 'CLERK'

If you are using the rule-based approach, the optimizer makes this transformation because each component query of the resulting compound query can be executed using an index. The rule-based approach assumes that executing the compound query using two index scans is faster than executing the original query using a full table scan.

If you are using the cost-based approach, the optimizer compares the cost of executing the original query using a full table scan with that of executing the resulting query when deciding whether make the transformation. The execution plan for the transformed statement might look like this:

To execute the transformed query, ORACLE performs these steps:

•	Steps 3 and 5 scan the indexes on the JOB and DEPTNO columns using the conditions of the component queries. These steps obtain ROWIDs of the rows that satisfy the component queries.

•	Steps 2 and 4 use the ROWIDs from Steps 3 and 5 to locate the rows that satisfy each component query.

•	Step 1 puts together the row sources returned by Steps 2 and 4.

If either of the JOB or DEPTNO columns is not indexed, the optimizer does not even consider the transformation because the resulting compound query would require a full table scan to execute one of its component queries. Executing the compound query with a full table scan in addition to an index scan could not possibly be faster than executing the original query with a full table scan.

Example	Consider this query and assume there is an index on the ENAME column:

SELECT *

FROM emp

WHERE ename = 'SMITH'

  OR sal > comm

Transforming the query above would result in the compound query below:

SELECT *

FROM emp

WHERE ename = 'SMITH'

UNION ALL

SELECT *

FROM emp

WHERE sal > comm

Since the condition in the WHERE clause of the second component query (SAL > COMM) does not make an index available, the compound query requires a full table scan. For this reason, the optimizer does not consider making the transformation and chooses a full table scan to execute the original statement.

Optimizing Complex Statements

To optimize a complex statement, the optimizer chooses one of these alternatives:

•	to transform the complex statement into an equivalent join statement and then optimize the join statement

•	to optimize the complex statement as is

 Transforming Complex Statements into Join Statements

The optimizer transforms a complex statement into a join statement whenever such a transformation results in a join statement that is guaranteed to return exactly the same rows as the complex statement. This transformation allows ORACLE to execute the statement by taking advantage of join optimization techniques described in the section "Optimizing Join Statements" on page 13 - 43.

Consider this complex statement that selects all rows from the ACCOUNTS table whose owners appear in the CUSTOMERS table:

SELECT *

FROM accounts

WHERE custno IN

(SELECT custno FROM customers)

If the CUSTNO column of the CUSTOMERS column is a primary key, the optimizer can transform the complex query into this join statement that is guaranteed to return the same data:

SELECT accounts.*

FROM accounts, customers

WHERE accounts.custno = customers.custno

The execution plan for this statement might look like this:

To execute this statement, ORACLE performs a nested loops join operation. For information on nested loops joins, see the section "Join Operations" on page 13 - 44.

If the optimizer cannot transform a complex statement into a join statement, the optimizer chooses execution plans for the parent statement and the subquery as though they were separate statements. ORACLE then executes the subquery and uses the rows it returns to execute the parent query.

Consider this complex statement that returns all rows from the ACCOUNTS table that have balances that are greater than the average account balance:

SELECT *

FROM accounts

WHERE accounts.balance >

(SELECT AVG(balance) FROM accounts)

There is no join statement that can perform the function of this statement, so the optimizer does not transform the statement. Note that complex queries whose subqueries contain group functions such as AVG cannot be transformed into join statements.

Optimizing Statements That Access Views

To optimize a statement that accesses a view, the optimizer chooses one of these alternatives:

•	transforming the statement into an equivalent statement that accesses the view's base tables

•	issuing the view's query, collecting all the returned rows, and then accessing this set of rows with the original statement as though it were a table

 Transforming Statements That Access Views

To transform a statement that accesses a view into an equivalent statement that accesses the view's base tables, the optimizer can use one of these techniques:

•	merging the view's query into the accessing statement

•	merging the accessing statement into the view's query

The optimizer then optimizes the resulting statement.

Merging the View's Query into the Accessing Statement      To merge the view's query into the accessing statement, the optimizer replaces the name of the view with the name of it's base table in the accessing statement and adds the condition of the view's query's WHERE clause to the accessing statement's WHERE clause.

Example	Consider this view of all employees who work in department 10:

CREATE VIEW emp_10

AS SELECT empno,ename, job, mgr, hiredate, sal, comm, deptno

FROM emp

WHERE deptno = 10

Consider this query that accesses the view. The query selects the IDs greater than 7800 of employees who work in department 10:

SELECT empno

FROM emp_10

WHERE empno > 7800

The optimizer transforms the query into the following query that accesses the view's base table:

SELECT empno

FROM emp

WHERE deptno = 10

  AND empno > 7800

If there are indexes on the DEPTNO or EMPNO columns, the resulting WHERE clause makes them available.

Merging the Accessing Statement into the View's Query      The optimizer cannot always merge the view's query into the accessing statement. Such a transformation is not possible if the view's query contains:

•	set operators (UNION, UNION ALL, INTERSECT, MINUS)

•	GROUP BY clause

•	CONNECT BY clause

•	DISTINCT operator in the select list

•	group functions (AVG, COUNT, MAX, MIN, SUM) in the select list

To optimize statements that access such views, the optimizer can merge the statement into the view's query.

Example	Consider the TWO_EMP_TABLES view, which is the union of two employee tables. The view is defined with a compound query that uses the UNION set operator:

CREATE VIEW two_emp_tables

(empno, ename, job, mgr, hiredate, sal, comm, deptno) AS

SELECT empno, ename, job, mgr, hiredate, sal, comm,

deptno FROM emp1 UNION

SELECT empno, ename, job, mgr, hiredate, sal, comm,

deptno FROM emp2

Consider this query that accesses the view. The query selects the IDs and names of all employees in either table who work in department 20:

SELECT empno, ename

FROM two_emp_tables

WHERE deptno = 20

Since the view is defined as a compound query, the optimizer cannot merge the view query into the accessing query. Instead, the optimizer transforms the query by adding its WHERE clause condition into the compound query. The resulting statement looks like this:

SELECT empno, ename FROM emp1 WHERE deptno = 20

UNION

SELECT empno, ename FROM emp2 WHERE deptno = 20

If there is an index on the DEPTNO column, the resulting WHERE clauses make it available.

Figure 13 - 2  shows the execution plan of the resulting statement.

To execute this statement, ORACLE performs these steps:

•	Steps 5 and 6 perform full scans of the EMP1 and EMP2 tables.

•	Step 4 performs a UNION-ALL operation returning all rows returned by either Step 5 or Step 6 including all copies of duplicates.

•	Step 3 sorts the result of Step 4, eliminating duplicate rows.

•	Step 2 performs an internal operation on the result of Step 3.

•	Step 1 simply indicates that the view's query was not merged into the accessing query.

Example	Consider the view EMP_GROUP_BY_DEPTNO which contains the department number, average salary, minimum salary, and maximum salary of all departments that have employees:

CREATE VIEW emp_group_by_deptno

AS SELECT deptno,

       AVG(sal) avg_sal,

MIN(sal) min_sal,

       MAX(sal) max_sal

  FROM emp

  GROUP BY deptno

Consider this query that selects the average, minimum, and maximum salaries of department 10 from the EMP_GROUP_BY_DEPTNO view:

SELECT *

FROM emp_group_by_deptno

WHERE deptno = 10

The optimizer transforms the statement by adding its WHERE clause condition into the view's query. The resulting statement looks like this:

SELECT deptno,

AVG(sal) avg_sal,

MIN(sal) min_sal,

MAX(sal) max_sal,

  FROM emp

  WHERE deptno = 10

  GROUP BY deptno

If there is an index on the DEPTNO column, the resulting WHERE clause makes it available.

Figure 13 - 3 shows the execution plan for the resulting statement. The execution plan uses an index on the DEPTNO column.

To execute this statement, ORACLE performs these operations:

•	Step 4 performs a range scan on the index named EMP_DEPTNO_INDEX to retrieve the ROWIDs of all rows in the EMP table with a DEPTNO value of 10. EMP_DEPTNO_INDEX is an index on the DEPTNO column of the EMP table.

•	Step 3 accesses the EMP table using by the ROWIDs retrieved by Step 4.

•	Step 2 sorts the rows returned by Step 3 to calculate the average, minimum, and maximum SAL values.

•	Step 1 simply indicates that the view's query was not merged into the accessing query.

Example	Consider this query that accesses the EMP_GROUP_BY_DEPTNO view defined in the previous example. This query selects the averages for the average department salary, the minimum department salary, and the maximum department salary from the employee table:

SELECT AVG(avg_sal), AVG(min_sal), AVG(max_sal)

FROM emp_group_by_deptno

The optimizer transforms this statement by applying the AVG group function to the select list of the view's query:

SELECT AVG(AVG(sal)), AVG(MIN(sal)), AVG(MAX(sal))

FROM emp

GROUP BY deptno

Figure 13 - 4 shows the execution plan of the resulting statement:

To execute this statement, ORACLE performs these operations:

•	Step 4 performs a full scan of the EMP table.

•	Step 3 sorts the rows returned by Step 4 into groups based on their DEPTNO values and calculates the average, minimum, and maximum SAL value of each group.

•	Step 2 simply indicates that the view's query was not merged into the accessing query.

•	Step 1 calculates the averages of the values returned by Step 2.

 Optimizing Other Statements That Access Views

The optimizer cannot transform all statements that access views into equivalent statements that access base table(s). To execute a statement that cannot be transformed, ORACLE issues the view's query, collects the resulting set of rows, and then accesses this set of rows with the original statement as thought it were a table.

Example	Consider the EMP_GROUP_BY_DEPTNO view defined in the previous section:

CREATE VIEW emp_group_by_deptno

AS SELECT deptno,

      AVG(sal) avg_sal,

MIN(sal) min_sal,

       MAX(sal) max_sal

  FROM emp

  GROUP BY deptno

Consider this query that accesses the view. The query joins the average, minimum, and maximum salaries from each department represented in this view and to the name and location of the department in the DEPT table:

SELECT emp_group_by_deptno.deptno, avg_sal, min_sal,

 	max_sal, dname, loc

FROM emp_group_by_deptno, dept

WHERE emp_group_by_deptno.deptno = dept.deptno

Since there is no equivalent statement that accesses only base tables, the optimizer cannot transform this statement. Instead, the optimizer chooses an execution plan that issues the view's query and then uses the resulting set of rows as it would the rows resulting from a table access.

Figure 13 - 5  shows the execution plan for this statement.

To execute this statement, ORACLE performs these operations:

•	Step 4 performs a full scan of the EMP table.

•	Step 3 sorts the results of Step 4 and calculates the average, minimum, and maximum SAL values selected by the query for the EMP_GROUP_BY_DEPTNO view.

•	Step 2 indicates that the previous two steps were executed to select data for a view.

•	For each row returned by Step 2, Step 6 uses the DEPTNO value to perform a unique scan of the PK_DEPT index.

•	Step 5 uses each ROWID returned by Step 6 to locate the row in the DEPTNO table with the matching DEPTNO value.

•	ORACLE combines each row returned by Step 2 with the matching row returned by Step 5 and returns the result.

For more information on how ORACLE performs a nested loops join operation, see the section "Join Operations" on page 13 - 43.

Choosing an Optimization Approach and Goal

The optimizer's behavior when choosing an optimization approach and goal for a SQL statement is affected by these factors:

•	the OPTIMIZER_MODE initialization parameter

•	statistics in the data dictionary

•	the OPTIMIZER_GOAL parameter of the ALTER SESSION command

•	hints in the statement

 The OPTIMIZER_MODE Initialization Parameter

The OPTIMIZER_MODE initialization parameter establishes the default behavior for choosing an optimization approach for the instance. This parameter can have these values:

COST	This value causes the optimizer to choose between the rule-based approach and the cost-based approach for a SQL statement based on the presence of statistics for the tables accessed by the statement. If the data dictionary contains statistics for at least one of these tables, the optimizer uses the cost-based approach and optimizes with a goal of best throughput. If data dictionary contains no statistics for any of these tables, the optimizer uses the rule-based approach. This is the default value for the parameter.

RULE	This value causes the optimizer to choose the rule-based approach for all SQL statements issued to the instance regardless of the presence of statistics.

If the optimizer uses the cost-based approach for a SQL statement and some tables accessed by the statement have no statistics, the optimizer uses internal information such as the number of data blocks allocated to these tables and estimates other statistics for these tables.

 The OPTIMIZER_GOAL Parameter of the ALTER SESSION Command

The OPTIMIZER_GOAL parameter of the ALTER SESSION command can override the optimization approach and goal established by the OPTIMIZER_MODE initialization parameter for an individual session. This parameter can have these values:

CHOOSE	This value causes the optimizer to choose between the rule-based approach and the cost-based approach for a SQL statement based on the presence of statistics for the tables accessed by the statement. If the data dictionary contains statistics for at least one of these tables, the optimizer uses the cost-based approach and optimizes with the goal of best throughput. If data dictionary contains no statistics for any of these tables, the optimizer uses the rule-based approach.

ALL_ROWS	This value causes the optimizer to use the cost-based approach for all SQL statements in the session regardless of the presence of statistics and to optimize with a goal of best throughput.

FIRST_ROWS	This value causes the optimizer to use the cost-based approach for all SQL statements in the session regardless of the presence of statistics and to optimize with a goal of best response time.

RULE	This value causes the optimizer to choose the rule-based approach for all SQL statements in a session regardless of the presence of statistics.

The value of this parameter does affect the optimization of SQL statements issued by stored procedures and functions called during the session, but it does not affect the optimization of recursive SQL statements that ORACLE issues during the session. The optimization approach for recursive SQL statements is only affected by the value of the OPTIMIZER_MODE initialization parameter. When the optimizer uses the cost-based approach for recursive SQL statements, the goal is always best throughput.

 The FIRST_ROWS, ALL_ROWS, and RULE Hints

The FIRST_ROWS, ALL_ROWS, and RULE hints can override the affects of the OPTIMIZER_MODE initialization parameter and the OPTIMIZER_GOAL parameter of the ALTER SESSION command for an individual SQL statement. For information on these hints, see Chapter 5 "Tuning SQL Statements" of the ORACLE7 Server Application Developer's Guide.

Choosing Access Paths

One of the most important choices the optimizer makes when formulating an execution plan is how to retrieve the data from the database. For any row in any table accessed by a SQL statement, there may be many access paths by which that row can be located and retrieved. The optimizer chooses one of them.

This section discusses these topics:

•	the basic methods by which ORACLE can access data

•	each access path and when it is available to the optimizer

•	how the optimizer chooses among available access paths

 Access Methods

This section describes basic methods by which ORACLE can access data.

Full Table Scans      A full table scan retrieves rows from a table. To perform a full table scan, ORACLE reads all rows in the table, examining each row to determine whether it satisfies the statement's WHERE clause. ORACLE reads every data block allocated to the table sequentially, so a full table scan can be performed very efficiently using multi-block reads. ORACLE reads each data block only once.

Table Access by ROWID      A table access by ROWID also retrieves rows from a table. The ROWID of a row specifies the data file and data block containing the row and the location of the row in that block. Locating a row by its ROWID is the fastest way for ORACLE to find a single row.

To access a table by ROWID, ORACLE first obtains the ROWIDs of the selected rows, either from the statement's WHERE clause or through an index scan of one of more of the table's indexes. ORACLE then locates each selected row in the table based on its ROWID.

Cluster Scans      From a table stored in an indexed cluster, a cluster scan retrieves rows that have the same cluster key value. In an indexed cluster, all rows with the same cluster key value are stored in the same data blocks. To perform a cluster scan, ORACLE first obtains the ROWID of one of the selected rows by scanning the cluster index. ORACLE then locates the rows based on this ROWID.

Hash Scans      ORACLE can use a hash scan to locate rows in a hash cluster based on a hash value. In a hash cluster, all rows with the same hash value are stored in the same data blocks. To perform a hash scan, ORACLE first obtains the hash value by applying a hash function to cluster key value specified by the statement. ORACLE then scans the data blocks containing rows with that hash value.

Index Scans      An index scan retrieves data from an index based on the value of one or more columns of the index. To perform an index scan, ORACLE searches the index for the indexed column values accessed by the statement. If the statement accesses only columns of the index, ORACLE reads the indexed column values directly from the index, rather than from the table.

In addition to each indexed value, an index also contains the ROWIDs of rows in the table having that value. If the statement accesses other columns in addition to the indexed columns, ORACLE then finds the rows in the table with a table access by ROWID or a cluster scan.

An index scan can be one of these types:

Unique	A unique scan of an index returns only a single ROWID. ORACLE can only perform a unique scan in cases in which only a single ROWID, rather than many ROWIDs, is required. For example, ORACLE performs a unique scan if there is a unique or primary key that guarantees that the statement accesses only a single row.

Range	A range scan of an index can return the one or more ROWIDs depending on how many rows are accessed by the statement.

Access Paths

Table 13 - 1  lists the access paths. The rank of each path is used by the rule-based approach to choose a path when more than one is available.

Rank	Access Path

1	Single row by ROWID

2	Single row by

3	Single row by

4	Single row by

5	Cluster join

6	Hash cluster key

7	Indexed cluster key

8	Composite key

9	Single-column  indexes

10	Bounded range search on indexed columns

11	Unbounded range search on indexed columns

12	Sort-merge join

13	MAX or MIN of indexed column

14	ORDER BY on indexed columns

15	Full table scan

Table 13 - 1.  Access Paths

The optimizer can only choose to use a particular access path for a table if the statement contains a WHERE clause condition or other construct that makes that access path available. Each of the following sections describes an access path and discusses:

•	when it is available

•	the method ORACLE uses to access data with it

•	the output generated for it by the EXPLAIN PLAN command

Path 1

Single Row by ROWID      This access path is only available if the statement's WHERE clause identifies the selected rows by ROWID or with the CURRENT OF CURSOR embedded SQL syntax supported by the ORACLE Precompilers. To execute the statement, ORACLE accesses the table by ROWID.

Example	This access path is available in the following statement:

SELECT * FROM emp WHERE ROWID = '00000DC5.0000.0001'

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

TABLE ACCESS	BY ROWID	EMP

Path 2

Single Row by Cluster Join      This access path is available for statements that join tables stored in the same cluster if both of these conditions are true:

•	The statement's WHERE clause contains conditions that equate each column of the cluster key in one table with the corresponding column in the other table.

•	The statement's WHERE clause also contains a condition that guarantees that the join returns only one row. Such a condition is likely to be an equality condition on the column(s) of a unique or primary key.

These conditions must be combined with AND operators. To execute the statement, ORACLE performs a nested loops operation. For information on the nested loops operation, see the section "Join Operations" on page 13 - 44 .

Example	This access path is available for the following statement in which the EMP and DEPT tables are clustered on the DEPTNO column and the EMPNO column is the primary key of the EMP table:

SELECT *

FROM emp, dept

WHERE emp.deptno = dept.deptno

  AND emp.empno = 7900

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

NESTED LOOPS

  TABLE ACCESS	BY ROWID	EMP

INDEX	UNIQUE SCAN	PK_EMP

  TABLE ACCESS	CLUSTER	DEPT

PK_EMP is the name of an index that enforces the primary key.

Path 3

Single Row by Hash Cluster Key with Unique or Primary Key      This access path is available if both of these conditions are true:

•	The statement's WHERE clause uses all columns of a hash cluster key in equality conditions. For composite cluster keys, the equality conditions must be combined with AND operators.

•	The statement is guaranteed to return only one row because the columns that make up the hash cluster key also make up a unique or primary key.

To execute the statement, ORACLE applies the cluster's hash function to the hash cluster key value specified in the statement to obtain a hash value. ORACLE then uses the hash value to perform a hash scan on the table.

Example	This access path is available in the following statement in which the ORDERS and LINE_ITEMS tables are stored in a hash cluster and the ORDERNO column is both the cluster key and the primary key of the ORDERS table:

SELECT *

FROM orders 	WHERE orderno = 65118968

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

TABLE ACCESS	HASH	ORDERS

Path 4

Single Row by Unique or Primary Key      This access path is available if the statement's WHERE clause uses all columns of a unique or primary key in equality conditions. For composite keys, the equality conditions must be combined with AND operators. To execute the statement, ORACLE performs a unique scan on the index on the unique or primary key to retrieve a single ROWID and then accesses the table by that ROWID.

Example	This access path is available in the following statement in which the EMPNO column is the primary key of the EMP table:

SELECT *

FROM emp

WHERE empno = 7900

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	BY ROWID	EMP

INDEX	UNIQUE SCAN	PK_EMP

PK_EMP is the name of the index that enforces the primary key.

Path 5

Clustered Join      This access path is available for statements that join tables stored in the same cluster if the statement's WHERE clause contains conditions that equate each column of the cluster key in one table with the corresponding column in the other table. For a composite cluster key, the equality conditions must be combined with AND operators. To execute the statement, ORACLE performs a nested loops operation. For information on nested loops operations, see the section "Join Operations" on page 13 - 44.

Example	This access path is available in the following statement in which the EMP and DEPT tables are clustered on the DEPTNO column:

SELECT *

FROM emp, dept

WHERE emp.deptno = dept.deptno

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  NESTED LOOPS

TABLE ACCESS	FULL	DEPT

TABLE ACCESS	CLUSTER	EMP

Path 6

Hash Cluster Key      This access path is available if the statement's WHERE clause uses all the columns of a hash cluster key in equality conditions. For a composite cluster key, the equality conditions must be combined with AND operators. To execute the statement, ORACLE applies the cluster's hash function to the hash cluster key value specified in the statement to obtain a hash value. ORACLE then uses this hash value to perform a hash scan on the table.

Example	This access path is available for the following statement in which the ORDERS and LINE_ITEMS tables are stored in a hash cluster and the ORDERNO column is the cluster key:

SELECT *

FROM line_items

WHERE deptno = 65118968

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

TABLE ACCESS	HASH	LINE_ITEMS

Path 7

Indexed Cluster Key      This access path is available if the statement's WHERE clause uses all the columns of an indexed cluster key in equality conditions. For a composite cluster key, the equality conditions must be combined with AND operators. To execute the statement, ORACLE performs a unique scan on the cluster index to retrieve the ROWID of one row with the specified cluster key value. ORACLE then uses that ROWID to access the table with a cluster scan. Since all rows with the same cluster key value are stored together, the cluster scan requires only a single ROWID to find them all.

Example	This access path is available in the following statement in which the EMP table is stored in an indexed cluster and the DEPTNO column is the cluster key:

SELECT *  FROM emp

WHERE deptno = 10

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	CLUSTER	EMP

INDEX	UNIQUE SCAN	PERS_INDEX

PERS_INDEX is the name of the cluster index.

Path 8

Composite Index      This access path is available if the statement's WHERE clause uses all columns of a composite index in equality conditions combined with AND operators. To execute the statement, ORACLE performs a range scan on the index to retrieve the ROWIDs of the selected rows and then accesses the table by those ROWIDs.

Example	This access path is available in the following statement in which there is a composite index on the JOB and DEPTNO columns:

SELECT *

FROM emp

WHERE job = 'CLERK'

  AND deptno = 30

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	BY ROWID	EMP

INDEX	RANGE SCAN	JOB_DEPTNO_INDEX

JOB_DEPTNO_INDEX is the name of the composite index on the JOB and DEPTNO columns.

Path 9

Single-Column Indexes      This access path is available if the statement's WHERE clause uses the columns of one or more single-column indexes in equality conditions. For multiple single-column indexes, the conditions must be combined with AND operators.

If the WHERE clause uses the column of only one index, ORACLE executes the statement by performing a range scan on the index to retrieve the ROWIDs of the selected rows and then accessing the table by these ROWIDs.

Example	This access path is available in the following statement in which there is an index on the JOB column of the EMP table:

SELECT *

FROM emp

WHERE job = 'ANALYST'

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	BY ROWID	EMP

INDEX	RANGE SCAN	JOB_INDEX

JOB_INDEX is the index on EMP.JOB.

If the WHERE clauses uses columns of many single column indexes, ORACLE executes the statement by performing a range scan on each index to retrieve the ROWIDs of the rows that satisfy each condition. ORACLE then merges the sets of ROWIDs to obtain a set of ROWIDs of rows that satisfy all conditions. ORACLE then accesses the table using these ROWIDs.

ORACLE can merge up to five indexes. If the WHERE clause uses column of more than five single-column indexes, ORACLE merges five of them, access the table by ROWID, and then tests the resulting rows to determine whether they satisfy the remaining conditions before returning them.

Example	This access path is available in the following statement in which there are indexes on both the JOB and DEPTNO columns of the EMP table:

SELECT *

FROM emp

WHERE job = 'ANALYST'

  AND deptno = 20

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	BY ROWID	EMP

AND-EQUAL

  INDEX	RANGE SCAN	JOB_INDEX

  INDEX	RANGE SCAN	DEPTNO_INDEX

The AND-EQUAL operation merges the ROWIDs obtained by the scans of the JOB_INDEX and the DEPTNO_INDEX, resulting in a set of ROWIDs of rows that satisfy the query.

Path 10

Bounded Range Search on Indexed Columns      This access path is available if the statement's WHERE clause contains condition that uses either the column of a single-column index or one or more columns that make up a leading portion of a composite index:

column = expr

column >[=] expr AND column <[=] expr

column BETWEEN expr AND expr

column LIKE 'c%'

Each of these conditions specifies a bounded range of indexed values that are accessed by the statement. The range is said to be bounded because the conditions specify both its least value and its greatest value. To execute such a statement, ORACLE performs a range scan on the index and then accesses the table by ROWID.

Example	This access path is available in this statement in which there is an index on the SAL column of the EMP table:

SELECT *

FROM emp

WHERE sal BETWEEN 2000 AND 3000

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	BY ROWID	EMP

INDEX	RANGE SCAN	SAL_INDEX

SAL_INDEX is the name of the index on EMP.SAL.

Example	This access path is also available in the following statement in which there is an index on the ENAME column of the EMP table:

SELECT *

FROM emp

WHERE ename LIKE 'S%'

Example	This access path is available in the following statement in which there is a composite index on the ORDER and LINE columns of the LINE_ITEMS table:

SELECT *

FROM line_items

WHERE order > 65118968

The access path is available because the WHERE clause uses the ORDER column, a leading portion of the index.

Example	This access path is not available in the following statement in which there is an index on the ORDER and LINE columns:

SELECT *

FROM line_items

WHERE line < 4

The access path is not available because the WHERE clause only uses the LINE column, which is not a leading portion of the index.

Path 11

Unbounded Range Search on Indexed Columns      This access path is available if the statement's WHERE clause contains one of these conditions that use either the column of a single-column index or one or more columns of a leading portion of a composite index:

WHERE column >[=] expr

WHERE column <[=] expr

Each of these conditions specify an unbounded range of index values accessed by the statement. The range is said to be unbounded because the condition specifies either its least value or its greatest value, but not both. To execute such a statement, ORACLE performs a range scan on the index and then accesses the table by ROWID.

Example	This access path is available in the following statement in which there is an index on the SAL column of the EMP table:

SELECT *

FROM emp 	WHERE sal > 2000

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	BY ROWID	EMP

INDEX	RANGE SCAN	SAL_INDEX

Path 12

Sort Merge Join      This access path is available for statements that join tables that are not stored together in a cluster if the statement's WHERE clause uses columns from each table in equality conditions. To execute such a statement, ORACLE uses a sort-merge operation. ORACLE can also use a nested loops operation to execute a join statement. For information on these operations and when the optimizer chooses one over the other, see the section "Optimizing Join Statements" on page 13 - 43.

Example	This access path is available for the following statement in which the EMP and DEPT tables are not stored in the same cluster:

SELECT *

FROM emp, dept

WHERE emp.deptno = dept.deptno

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS

OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  MERGE JOIN

SORT	JOIN

  TABLE ACCESS	FULL	EMP

SORT	JOIN

  TABLE ACCESS	FULL	DEPT

Path 13

MAX or MIN of Indexed Column      This access path is available for a SELECT statement for which all of these conditions are true:

•	The query uses the MAX or MIN function to select the maximum or minimum value of either the column of a single-column index or the leading column of a composite index. The index cannot be a cluster index.

The argument to the MAX or MIN function can any expression involving the column, a constant, or the addition operator (+), the concatenation operation (||), or the CONCAT function.

•	There are no other expressions in the select list.

•	The statement has no WHERE clause or GROUP BY clause.

To execute the query, ORACLE performs a range scan of the index to find the maximum or minimum indexed value. Since only this value is selected, ORACLE need not access the table after scanning the index.

Example	This access path is available for the following statement in which there is an index on the SAL column of the EMP table:

SELECT MAX(sal) FROM emp

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  AGGREGATE	GROUP BY

INDEX	RANGE SCAN	SAL_INDEX

Path 14

ORDER BY on Indexed Column      This access path is available for a SELECT statement for which all of these conditions are true:

•	The query contains an ORDER BY clause that uses either the column of a single-column index or a leading portion of a composite index. The index cannot be a cluster index.

•	There must be a PRIMARY KEY or NOT NULL integrity constraint that guarantees that at least one of the indexed columns listed in the ORDER BY clause contains no nulls.

To execute the query, ORACLE performs a range scan of the index to retrieve the ROWIDs of the selected rows in sorted order. ORACLE then accesses the table by these ROWIDs.

Example	This access path is available for the following statement in which there is a primary key on the EMPNO column of the EMP table:

SELECT *

FROM emp

ORDER BY empno

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	BY ROWID	EMP

INDEX	RANGE SCAN	PK_EMP

PK_EMP is the name of the index that enforces the primary key. The primary key ensures that the column does not contain nulls.

Path 15

Full Table Scan      This access path is available for any SQL statement, regardless of its WHERE clause conditions.

This statement uses a full table scan to access the EMP table:

SELECT *

FROM emp

The EXPLAIN PLAN output for this statement might look like this:

OPERATION	OPTIONS	OBJECT_NAME

-----------------------------------------------------

SELECT STATEMENT

  TABLE ACCESS	FULL	EMP

Note that these conditions do not make index access paths available:

•	column1 > column2

•	column1 < column2

•	column1 >= column2

•	column1 <= column2

where column1 and column2 are in the same table.

•	column IS NULL

•	column IS NOT NULL

•	column NOT IN

•	column != expr

•	column LIKE '%pattern'

regardless of whether column is indexed.

•	expr = expr2

where expr is an expression that operates a column with an operator or function, regardless of whether the column is indexed.

•	NOT EXISTS subquery

•	any condition involving a column that is not indexed

Any SQL statement that contains only these constructs and no others that make index access paths available must use full table scans.

 Choosing Among Access Paths

This section describes how the optimizer chooses among available access paths:

•	when using the rule-based approach

•	when using the cost-based approach

Choosing Among Access Paths with the Rule-Based Approach      With the rule-based approach, the optimizer chooses whether to use an access path based on these factors:

•	the available access paths for the statement

•	the ranks of these access paths in Table 13 - 1 on page 13 - 28

To choose an access path, the optimizer first examines the conditions in the statement's WHERE clause to determine which access paths are available. The optimizer then chooses the most highly-ranked available access path. Note that the full table scan is the lowest-ranked access path on the list. This means that the rule-based approach always chooses an access path that uses an index if one is available, even if a full table scan might execute faster.

The order of the conditions in the WHERE clause does not normally affect the optimizer's choice among access paths.

Example	Consider this SQL statement that selects the employee numbers of all employees in the EMP table with an ENAME value of 'CHUNG' and with a SAL value greater than 2000:

SELECT empno

FROM emp

WHERE ename = 'CHUNG'

  AND sal > 2000

Consider also that the EMP table has these integrity constraints and indexes:

•	There is a PRIMARY KEY constraint on the EMPNO column that is enforced by the index PK_EMPNO.

•	There is an index named ENAME_IND on the ENAME column.

•	There is an index named SAL_IND on the SAL column.

Based on the conditions in the WHERE clause of the SQL statement, the integrity constraints, and the indexes, these access paths are available:

•	A single-column index access path using the ENAME_IND index is made available by the condition ENAME = 'CHUNG'. This access path has rank 9.

•	An unbounded range scan using the SAL_IND index is made available by the condition SAL > 2000. This access path has rank 11.

•	A full table scan is automatically available for all SQL statements. This access path has rank 15.

Note that the PK_EMPNO index does not make the single row by primary key access path available because the indexed column does not appear in a condition in the WHERE clause.

Using the rule-based approach, the optimizer chooses the access path that uses the ENAME_IND index to execute this statement. The optimizer chooses this path because it is the most highly-ranked path available.

Choosing Among Access Paths with the Cost-Based Approach      With the cost-based approach, the optimizer chooses an access path based on these factors:

•	the available access paths for the statement

•	the estimated cost of executing the statement using each access path or combination of paths

To choose an access path, the optimizer first determines which access paths are available by examining the conditions in the statement's WHERE clause. The optimizer then generates a set of possible execution plans using available access paths and estimates the cost of each plan using the statistics for the index, columns, and tables accessible to the statement. The optimizer then chooses the execution plan with the lowest estimated cost.

The optimizer's choice among available access paths can be overridden with hints. For information on hints, see the ORACLE7 Server Application Developer's Guide.

To choose among available access paths, the optimizer considers these factors:

•	Selectivity:  The selectivity is the percentage of rows in the table that the query selects. Queries that select a small percentage of a table's rows have good selectivity, while a query that selects a large percentage of the rows has poor selectivity.

The optimizer is more likely to choose an index scan over a full table scan for a query with good selectivity than for one with poor selectivity. Index scans are usually more efficient than full table scans for queries that access only a small percentage of a table's rows, while full table scans are usually faster for queries that access a large percentage.

To determine the selectivity of a query, the optimizer considers these sources of information:

•	the operators used in the WHERE clause

•	unique and primary key columns used in the WHERE clause

•	statistics for the table

The following examples in this section illustrate the way the optimizer uses selectivity.

•	DB_FILE_MULTIBLOCK_READ_COUNT:  Full table scans use multi-block reads, so the cost of a full table scan depends on the number of multi-block reads required to read the entire table, which depends on the number of blocks read by a single multi-block read, which is specified by the initialization parameter DB_FILE_MULTIBLOCK_READ_COUNT. For this reason, the optimizer may be more likely to choose a full table scan when the value of this parameter is high.

Example	Consider this query that uses an equality condition in its WHERE clause to select all employees name Jackson:

SELECT *

FROM emp

WHERE ename = 'JACKSON'

If the ENAME column is a unique or primary key, the optimizer determines that there is only one employee named Jackson and the query returns only one row. In this case, the query is very selective and the optimizer is most likely to choose to access the table by performing a unique scan on the index enforcing the unique or primary key (access path 4).

Example	Consider again the query in the previous example. If the ENAME column is not a unique or primary key, the optimizer can use these statistics to estimate the query's selectivity:

USER_TAB_COLUMNS.NUM_DISTINCT

 This statistic is the number of values for each column in the table.

USER_TABLES.NUM_ROWS

 This statistic is the number of rows in each table.

By dividing the number of rows in the EMP table by the number of distinct values in the ENAME column, the optimizer estimates what percentage the employees have the same name. By assuming that the ENAME values are uniformly distributed, the optimizer uses this percentage as the estimated selectivity of the query.

Example	Consider this query that selects all employees with employee ID numbers less than 7500:

SELECT *

FROM emp

WHERE empno < 7500

To estimate the selectivity of the query, the optimizer uses the boundary value of 7500 in the WHERE clause condition and the values of the HIGH_VALUE and LOW_VALUE statistics for the EMPNO column available. These statistics can be found in the USER_TAB_COLUMNS view. The optimizer assumes that EMPNO values are evenly distributed in the range between the lowest value and highest value. The optimizer then determines what percentage of this range is less than the value 7500 and uses this value as the estimated selectivity of the query.

Example	Consider this query that uses a bind variable rather than a literal value for the boundary value in the WHERE clause condition:

SELECT *

FROM emp

WHERE empno < :e1

The optimizer does not know the value of the bind variable E1. Indeed, the value of E1 may be different for each execution of the query. For this reason, the optimizer cannot use the means described in the previous example to determine selectivity of this query. In this case, the optimizer heuristically guesses that the query selects 25% of the table's rows. The optimizer makes this assumption whenever a bind variable is used as a boundary value in a condition with one of the operators <, >, <=, or >=.

The optimizer's treatment of bind variables can cause it to choose different execution plans for SQL statements that differ only in the use of bind variables rather than constants. In one case in which this difference may be especially apparent, the optimizer may choose different execution plans for an embedded SQL statement with a bind variable in an ORACLE Precompiler program and the same SQL statement with a constant in SQL*Plus.

Example

Consider this query that uses the BETWEEN operator to select all employees with employee ID numbers between 7500 and 7800:

SELECT *

FROM emp

WHERE empno BETWEEN 7500 AND 7800

To determine the selectivity of this query, the optimizer decomposes the WHERE clause condition into these two conditions:

empno >= 7500

empno <= 7800

The optimizer estimates the individual selectivity of each condition using the means described in a previous example. The optimizer then uses these selectivities (S1 and S2) and the absolute value function (ABS) in this formula to estimate the selectivity (S) of the BETWEEN condition:

S = ABS( S1 + S2 - 1 )

Example	Consider this query that uses two bind variables as boundary values in the condition with the BETWEEN operator:

SELECT *

FROM emp

WHERE empno BETWEEN :low_e AND :high_e

The optimizer decomposes the BETWEEN condition into these two conditions:

empno >= :low_e

empno <= :high_e

The optimizer heuristically estimates that the selectivities of these conditions are both 25%. Using these values in the formula presented in the previous example, the optimizer estimates the selectivity (S) of the BETWEEN condition:

S = ABS( S1 + S2 - 1 )

S = ABS( .25 + .25 - 1 )

S = .5 = 50%

Optimizing Join Statements

To choose an execution plan for a join statement, the optimizer must choose:

access paths 	As for simple statements, the optimizer must choose an access path to retrieve data from each table in the join statement.

join operations	To join each pair of row sources, ORACLE must perform one of these operations:

•	nested loops

•	sort-merge

•	cluster

join order	To execute a statement that joins more than two tables, ORACLE joins two of the tables, and then joins the resulting source to the next table. This process is continued until all tables are joined into the result.

These choices are related.

Join Operations

To join two row sources, ORACLE must perform one of these operations:

•	nested loops

•	sort-merge

•	cluster

Nested Loops Join    To perform a nested loops join, ORACLE follows these steps:

1..	The optimizer chooses one of the tables as the outer table, or the driving table. The other table is called the inner table.

2..	For each row in the outer table, ORACLE finds all rows in the inner table that satisfy the join condition.

3..	ORACLE combines the data in each pair of rows that satisfy the join condition and returns the resulting rows.

Figure 13 - 6 shows the execution plan for this statement using a nested loops join:

SELECT *

FROM emp, dept

WHERE emp.deptno = dept.deptno

To execute this statement, ORACLE performs these steps:

•	Step 2 accesses the outer table (EMP) with a full table scan.

•	For each row returned by Step 2, Step 4 uses the EMP.DEPTNO value to perform a unique scan on the PK_DEPT index.

•	Step 3 uses the ROWID from Step 4 to locate the matching row in the inner table (DEPT).

•	ORACLE combines each row returned by Step 2 with the matching row returned by Step 4 and returns the result.

Sort-Merge Join      To perform a sort-merge join, ORACLE follows these steps:

1..	ORACLE sorts each row source to be joined if they have not already been sorted by a previous operation. The rows are sorted on the values of the columns used in the join condition.

2..	ORACLE merges the two sources so that each row of one source is combined with each row of the other source containing matching values for the columns used in the join condition and returns the resulting source.

ORACLE can only perform a sort-merge join for an equi-join.

Figure 13 - 7  shows the execution plan for this statement using a sort-merge join:

SELECT *

FROM emp, dept

WHERE emp.deptno = dept.deptno

To execute this statement, ORACLE performs these steps:

•	Steps 3 and 5 perform full table scans of the EMP and DEPT tables.

•	Steps 2 and 4 sort each row source separately.

•	Step 1 merges the sources from Steps 2 and 4 together combining each row from Step 2 with each matching row from the Step 4 and returns the resulting row source.

Cluster Join      ORACLE can only perform a cluster join for an equi-join statement that equates the cluster key columns of two tables that are stored in the same cluster. In a cluster, rows from both tables with the same cluster key values are stored in the same blocks, so ORACLE only accesses those blocks. For information on clusters, including how to decide which tables to cluster for best performance, see Chapter 5 "Tuning SQL Statements" of the ORACLE7 Server Application Developer's Guide.

Figure 13 - 8  shows the execution plan for this statement in which the EMP and DEPT tables are stored together in the same cluster:

SELECT *

FROM emp, dept

WHERE emp.deptno = dept.deptno

To execute this statement, ORACLE performs these steps:

•	Step 2 accesses the outer table (DEPT) with a full table scan.

•	For each row returned by Step 2, Step 3 uses the DEPT.DEPTNO value to find the matching rows in the inner table (EMP) with a cluster scan.

A cluster join is nothing more than a nested loops join involving two tables that are stored together in a cluster. Since the each row from the DEPT table is stored in the same data blocks as the matching rows in the EMP table, ORACLE can access matching rows most efficiently.

 Choosing Execution Plans for Join Statements

This section describes how the optimizer chooses an execution plan for a join statement:

•	when using the rule-based approach

•	when using the cost-based approach

Note these caveats that apply to both approaches:

•	The optimizer first determines whether joining any two or more of the tables results in a row source containing only a single row. The optimizer recognizes such situations based on UNIQUE and PRIMARY KEY constraints on the tables. If such a result is possible, the optimizer places these tables first in the join order. The optimizer then optimizes the join of the remaining R tables. The cost-based approach only checks for this situation for statements joining more than five tables.

•	For join statements with outer join conditions, the table with the outer join operator must come after the other table in the condition in the join order. The optimizer does not consider join orders that violate this rule.

Choosing Execution Plans for Joins with the Rule-Based Approach      With the rule-based approach, the optimizer follows these steps to choose an execution plan for a statement that joins R tables:

1..	The optimizer generates a set of R join orders, each with a different table as the first table. The optimizer generates each potential join order using this algorithm:

1.1	To fill each position in the join order, the optimizer chooses the table with the most highly-ranked available access path according to the ranks for access paths in Table 13 - 1 on page 13 - 28. The optimizer repeats this step to fill each subsequent position in the join order.

1.2	For each table in the join order, the optimizer also chooses the operation with which to join the table to the previous table or row source in the order. The optimizer does this by "ranking" the sort-merge operation as access path 12 and applying these

 rules:

•	If the access path for the chosen table is ranked 11 or better, the optimizer chooses a nested loops operation using the previous table or row source in the join order as the outer table.

•	If the access path for the table is ranked worse than 12, and there is an equijoin condition between the chosen table and the previous table or row source in join order, the optimizer chooses a sort-merge operation.

•	If the access path for the chosen table is ranked worse than 12, and there is not an equijoin condition, the optimizer chooses a nested loops operation with the previous table or row source in the join order as the outer table.

2.	The optimizer then chooses among the resulting R execution plans. The goal of the optimizer's choice is to maximize the number of nested loops join operations in which the inner table is accessed using an index scan. Since a nested loops join involves accessing the inner table many times, an index on the inner table can greatly improve the performance of a nested loops join. In most cases, the optimizer does not consider the order in which tables appear in the FROM clause when choosing an execution plan.

The optimizer makes this choice by applying the following rules in order:

2.1	The optimizer chooses the execution plan with the fewest 	nested-loops operations in which the inner table is accessed

 	with a full table scan.

2.2	If there is a tie, the optimizer chooses the execution plan with the fewest sort-merge operations.

2.3	If there is still a tie, the optimizer chooses the execution plan for which the first table in the join order has the most highly-rated access path:

•	If there is a tie among multiple plans whose first tables are accessed by the single-column indexes access path, the optimizer chooses the plan whose first table is accessed with the most merged indexes.

•	If there is a tie among multiple plans whose first tables are accessed by bounded range scans, the optimizer chooses the plan whose first table is accessed with the greatest number of leading columns of the composite index.

2.4	If there is still a tie, the optimizer chooses the execution plan for which the first table appears later in the query's FROM clause.

Choosing Execution Plans for Joins with the Cost-Based Approach      With the cost-based approach, the optimizer generates a set of execution plans based on the possible join orders, join operations, and available access paths. The optimizer then estimates the cost of each plan and chooses the one with the lowest cost. The optimizer estimates costs in these ways:

•	The cost of a nested loops operation is based on the cost of reading each selected row of the outer table and each of its matching rows of the inner table into memory. The optimizer estimates these costs using the statistics in the data dictionary.

The cost-based approach uses the table from which more rows are returned for the outer table.

•	The cost of a sort-merge join is largely based on the cost of reading each source into memory and sorting them.

•	The optimizer also considers other factors when determining the cost of each operation. For example:

•	A smaller sort area size is likely to increase the cost for a sort-merge join because sorting takes more CPU time and I/O in a smaller sort area. Sort area size is specified by the initialization parameter SORT_AREA_SIZE.

•	A larger multi-block read count is likely to decrease the cost for a sort-merge join in relation to a nested loops join. If a large number of sequential blocks can be read from disk in a single I/O, an index on the inner table for the nested loops join is less likely to improve performance over a full table scan. The multi-block read count is specified by the initialization parameter DB_FILE_MULTIBLOCK_READ_COUNT.

•	For join statements with outer join conditions, the table with the outer join operator must come after the other table in the condition in the join order. The optimizer does not consider join orders that violate this rule.

With the cost-based approach, the optimizer's choice of join orders can be overridden with the ORDERED hint. If the ORDERED hint specifies a join order that violates the rule for outer join, the optimizer ignores the hint and the optimizer chooses the order. The optimizer's choice of join operations can also be overridden with hints. For information on using hints, see Chapter 5  "Tuning SQL Statements" of the ORACLE7 Server Application Developer's Guide.

Optimizing Compound Queries

To choose the execution plan for a compound query, the optimizer chooses an execution plan for each of its component queries and then combines the resulting row sources with the union, intersection, or minus operation, depending on the set operator used in the compound query.

Figure 13 - 9  shows the execution plan for this statement that uses the UNION ALL operator to select all occurrences of all parts in either the ORDERS1 table or the ORDERS2 table:

SELECT part FROM orders1

UNION ALL

SELECT part FROM orders2

To execute this statement, ORACLE performs these steps:

•	Steps 3 and 4 perform full table scans on the ORDERS1 and ORDERS2 tables.

•	Step 2 perform a UNION-ALL operation returning all rows that are returned by either Step 3 or Step 4 including all copies of duplicates.

•	Step 1 performs an internal operation on the result of Step 2.

Figure 13 - 10  shows the execution plan for this statement which uses the UNION operator to select all parts that appear in either the ORDERS1 table or the ORDERS2 table:

SELECT part FROM orders1

UNION

SELECT part FROM orders2

This execution plan is identical to the one for the UNION-ALL operator shown in Figure 13 - 9, except that in this case ORACLE uses the SORT operation to eliminate the duplicates returned by the UNION-ALL operation.

Figure 13 - 11 shows the execution plan for this statement that uses the INTERSECT operator to select only those parts that appear in both the ORDERS1 and ORDERS2 tables:

SELECT part FROM orders1

INTERSECT

SELECT part FROM orders2

To execute this statement, ORACLE performs these steps:

•	Steps 4 and 6 perform full table scans of the ORDERS1 and ORDERS2 tables.

•	Steps 3 and 5 sort the results of Steps 4 and 6, eliminating duplicates in each row source.

•	Step 2 performs an INTERSECTION operation that returns only rows that are returned by both Steps 3 and 5.

•	Step 1 perform an internal operation on the result of Step 2.

Optimizing Distributed Statements

The optimizer chooses execution plans for SQL statements that access data on remote databases in much the same way it chooses executions for statements that access only local data:

•	If all the tables accessed by a SQL statement are collocated on the same remote database, ORACLE sends the SQL statement to that remote database. The remote ORACLE instance executes the statement and sends only the results back to the local database.

•	If a SQL statement accesses tables that are located on different databases, ORACLE decomposes the statement into individual fragments, each of which access tables on a single database. ORACLE then sends each fragment to the database it accesses. The remote ORACLE instance for each of these databases executes each fragment and returns the results to the local database where the local ORACLE instance may perform any additional processing the statement requires.

When choosing the execution plan for a distributed statement, the optimizer considers the available indexes on remote databases just as it does indexes on the local database. If the statement uses the cost-based approach, the optimizer also considers statistics on remote databases. Furthermore, the optimizer considers the location of data when estimating the cost of accessing it. For example, a full scan of a remote table has a greater estimated cost than a full scan of an identical local table.


PART  VI . PROGRAMMATIC CONSTRUCTS


CHAPTER 14. PROCEDURES AND PACKAGES

Three things are to be looked to in a building: that it stand on the right spot; that it be securely founded; that it be successfully executed.

Johann Wolfgang Von Goethe

This chapter discusses the procedural capabilities of ORACLE. This chapter includes:

•	procedures, functions, and packages

•	the PL/SQL engine of ORACLE

•	how procedures, functions, and packages are stored in the database

•	how procedures and functions are executed by ORACLE

The information in this chapter applies only for those systems using ORACLE with the procedural option. For information about the dependencies of procedures, functions, and packages, and how ORACLE manages these dependencies, refer to Chapter 16.

If you are using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide .

________________________________________

An Introduction to Stored Procedures and Packages

ORACLE allows you to access and manipulate database information using procedural schema objects called PL/SQL program units. Procedures, functions, and packages are all examples of PL/SQL program units.

Stored Procedures and Functions

A procedure or function is a schema object that logically groups a set of SQL and other PL/SQL programming language statements together to perform a specific task. Procedures and functions are created in a user's schema and stored in a database for continued use. A procedure or function is executed interactively using an ORACLE tool, such as SQL*DBA, or called explicitly in the code of a database application, such as a SQL*Forms or Precompiler application, or another procedure or trigger. Figure 14 - 1  illustrates a simple procedure stored in the database, being called by several different database applications.

The stored procedure in Figure 14 - 1, which inserts an employee record into the EMP table, is shown in Figure 14 - 2.

All of the database applications in Figure 14 - 1 call the HIRE_EMP procedure. Alternatively, a privileged user might use SQL*DBA to execute the HIRE_EMP procedure using the following statement:

EXECUTE hire_emp ('TSMITH', 'CLERK', 1037, SYSDATE, \

              500, NULL, 20);

A new employee record for TSMITH is inserted into the EMP table (and any other procedural computations and SQL) as a result of this EXECUTE statement.

Packages

A package provides a way of grouping related procedures and functions, cursors, and variables together as a unit, and storing this unit in the database for continued use. Similar to stand-alone procedures and functions, packaged procedures and functions can be called explicitly by applications or users. Figure 14 - 3 illustrates a package that encapsulates a number of procedures used to manage an employee database.

The database applications explicitly call packaged procedures as necessary. After being granted the privileges for the EMP_MGMT package, a user can explicitly execute any of the procedures in the EMP_MGMT package. For example, the following statement might be issued using SQL*DBA to execute the HIRE_EMP package procedure:

EXECUTE emp_mgmt.hire_emp ('TSMITH', 'CLERK', 1037, \

SYSDATE, 500, NULL, 20);

Packages offer several development and performance advantages when compared to stand-alone stored procedures and functions, as described in the section "Packages" on page 14 - 11.

PL/SQL

PL/SQL is Oracle's procedural language extension to SQL. PL/SQL provides the capability to define and execute PL/SQL program units such as procedures, functions, and packages. The definition, compilation, and execution of PL/SQL program units is handled by the PL/SQL engine. The PL/SQL engine is a special component of many Oracle products, including ORACLE Server, that processes PL/SQL. Figure 14 - 4  illustrates the PL/SQL engine contained in ORACLE Server.

Notice that the procedure (or package) is stored in a database. When a procedure stored in the database is called from an application, the compiled procedure (or package) is loaded into the shared pool in the System Global Area (SGA) and the PL/SQL and SQL statement executors work together to process the statements within the procedure.

These other Oracle products also include a PL/SQL engine:

•	SQL*Forms Version 3

•	SQL*Menu Version 5

•	SQL*ReportWriter Version 2

While many Oracle products have PL/SQL components, this chapter specifically covers the procedures and packages that can be stored in an ORACLE database and processed using the PL/SQL engine of ORACLE Server. The PL/SQL capabilities of each Oracle tool are described in the appropriate tool user guide.

 Language Constructs for Procedures and Packages

Procedures, functions, and packages can include the following PL/SQL language constructs:

•	variables and constants

•	cursors

•	exceptions

The following sections give a general description of each construct; see the PL/SQL User's Guide and Reference for more information.

Variables     and Constants   Variables and constants can be declared within a procedure, function, or package. A variable or constant can be used in a SQL or PL/SQL statement to capture or provide a value when one is needed.

Note: Some interactive tools, such as SQL*DBA, allow you to define variables in your current session. Variables declared using this method can be used in a similar manner as variables declared within procedures or packages.

Cursors      Cursors can be explicitly declared within a procedure, function, or package to facilitate record-oriented processing of ORACLE data. Cursors can also be implicitly declared (to support other data manipulation actions) by the PL/SQL engine.

Exceptions   PL/SQL allows you to explicitly handle internal and user-defined error conditions, called exceptions, that arise during processing of PL/SQL code. Internal exceptions are caused by illegal operations, such as divide-by-zero, or ORACLE errors returned to the PL/SQL code. User-defined exceptions are explicitly defined and signaled within the PL/SQL block to control processing of errors specific to the application, such as debiting an account and leaving a negative balance.

When an exception is raised (signaled), the normal execution of the PL/SQL code stops and a routine called an exception handler is invoked. Specific exception handlers can be written to handle any internal or user-defined exception.

________________________________________

Procedures and Functions

ORACLE can process procedures and functions as well as individual SQL statements. A procedure or function is a schema object that consists of a set of statements and other PL/SQL constructs, grouped together, stored in the database, and executed as a unit to solve a specific problem or perform a set of related tasks. Procedures and functions allow you to combine the ease and flexibility of SQL with the procedural functionality of a structured programming language.

For example, the following statement creates the CREDIT_ACCOUNT procedure, which credits money to a bank account.

CREATE PROCEDURE credit_account

(acct NUMBER, credit NUMBER) AS

/* This procedure accepts two arguments: an account

   number and an amount of money to credit to the specified

   account. If the specified account does not exist, a

   new account is created. */

old_balance  NUMBER;

new_balance  NUMBER;

   BEGIN

SELECT balance INTO old_balance FROM accounts

  WHERE acct_id = acct

  FOR UPDATE OF balance;

new_balance := old_balance + credit;

UPDATE accounts SET balance = new_balance

  WHERE acct_id = acct;

COMMIT;

EXCEPTION

  WHEN NO_DATA_FOUND THEN

    INSERT INTO accounts (acct_id, balance)

VALUES(acct, credit);

  WHEN OTHERS THEN

ROLLBACK;

END credit_account;

Notice that both SQL and PL/SQL statements are included in the CREDIT_ACCOUNT procedure.

Procedures and functions are nearly identical. The only differences are that functions always return a single value to the caller, while procedures do not, and functions do not allow INOUT and OUT arguments. For simplicity, the term "procedure" is used in the remainder of this chapter to mean "procedures and functions," unless otherwise noted.

How Procedures Are Used

The design and use of all stored procedures should have the following properties:

•	Define procedures to complete a single, focused task. Do not define long procedures with several distinct subtasks or subtasks common to many procedures might be unnecessarily duplicated in the code of several procedures.

•	Do not define procedures that duplicate the functionality already provided by another feature of ORACLE. For example, do not define procedures to enforce simple data integrity rules that you can easily enforce using declarative integrity constraints.

Applications for Procedures

Procedures provide advantages in the following areas:

•	security

•	performance

•	memory allocation

•	productivity

•	integrity

 Security

Stored procedures can help enforce data security. You can restrict the database operations that users can perform by allowing them to access data only through procedures and functions.

For example, you can grant users access to a procedure that updates a table, but not grant them access to the table itself. When a user invokes the procedure, the procedure executes with the privileges of the procedure's owner. Because users only have the privilege to execute the procedure and not the privileges to query, update, or delete from the underlying tables, users can invoke the procedure, but they cannot arbitrarily manipulate table data in any other way.

 Performance

Stored procedures can improve database performance. Use of procedures dramatically reduces the amount of information that must be sent over a network compared to issuing individual SQL statements or sending the text of an entire PL/SQL block to ORACLE. Furthermore, because a procedure's compiled form is readily available in the database, no compilation step is required to execute the code. Additionally, if the procedure is already present in the shared pool of the SGA, retrieval from disk is not required and execution can begin immediately.

 Memory Allocation

Because stored procedures take advantage of the shared memory capabilities of ORACLE, only a single copy of the procedure needs to be loaded into memory for execution by multiple users. Sharing the same code among many users results in a substantial reduction in ORACLE memory requirements for applications.

 Productivity

Stored procedures increase development productivity. By designing applications around a common set of procedures, you can avoid redundant coding and increase your productivity.

For example, procedures can be written to insert, update, or delete rows from the EMP table. These procedures can then be called by any application without rewriting the SQL statements necessary to accomplish these tasks. If the methods of data management change, only the procedures need to be modified, not all of the applications that use the procedures.

 Integrity

Stored procedures improve the integrity and consistency of your applications. By developing all of your applications around a common group of procedures, you can reduce the likelihood of committing coding errors.

For example, a procedure or function needs to be tested only once to guarantee that it returns an accurate result. Once this is verified, the procedure can be used in any number of applications, and is guaranteed to yield accurate results. If the data structures referenced by the procedure are altered in any way, only the procedure needs to be recompiled; applications that call the procedure do not require any modifications.

Anonymous PL/SQL Blocks vs. Stored Procedures

An anonymous PL/SQL block is created by sending an unnamed PL/SQL block to ORACLE Server from an Oracle tool or an application. ORACLE compiles the PL/SQL block and places the compiled version in the shared pool of the SGA, but does not store the source code or compiled version in the database for subsequent reuse.

Shared SQL allows a compiled anonymous PL/SQL block already in the shared pool to be reused and shared until it is flushed out of the shared pool.

Alternatively, a stored procedure is created and stored in the database as an object. Once created and compiled, it is a named object that can be executed without recompiling. Additionally, dependency information is stored in the data dictionary to guarantee the validity of each stored procedure.

In summary, by moving PL/SQL blocks out of a database application and into stored database procedures, you avoid unnecessary procedure recompilations by ORACLE at runtime, improving the overall performance of the application and ORACLE.

Stand-Alone Procedures vs. Package Procedures

Stored procedures not defined within the context of a package are called stand-alone procedures. Procedures defined within a package are considered a part of the package. See "Packages" on page 14 - 11 for information on the advantages of packages.

Dependency Tracking for Stored Procedures

A stored procedure is dependent on the objects referenced in its body. ORACLE automatically tracks and manages such dependencies. For example, if you alter the definition of a table referenced by a procedure, the procedure must be recompiled to validate that it will continue to work as designed; in many cases, ORACLE automatically administers such dependency management. See chapter 16 for more information about dependency tracking.

________________________________________

Packages

Packages provide a method of encapsulating related procedures, functions, and associated cursors and variables together as a unit in the database.

For example, the following two statements create the specification and body for a package that contains several procedures and functions which process banking transactions.

CREATE PACKAGE bank_transactions AS

  minimum_balance  CONSTANT NUMBER := 100.00;

  PROCEDURE apply_transactions;

  PROCEDURE enter_transaction (acct   NUMBER,

kind   CHAR,

amount NUMBER);

END bank_transactions;

CREATE PACKAGE BODY bank_transactions AS

/*  Package to input bank transactions */

   new_status  CHAR(20);  /* Global variable to record status

of transaction being applied. Used

for update in APPLY_TRANSACTIONS. */

   PROCEDURE do_journal_entry (acct NUMBER,

kind CHAR) IS

/*  Records a journal entry for each bank transaction applied

    by the APPLY_TRANSACTIONS procedure. */

  BEGIN

INSERT INTO journal

  VALUES (acct, kind, sysdate);

IF kind = 'D' THEN

  new_status := 'Debit applied';

ELSIF kind = 'C' THEN

  new_status := 'Credit applied';

ELSE

  new_status := 'New account';

END IF;

  END do_journal_entry;

(continued on next page)

  PROCEDURE credit_account (acct NUMBER, credit NUMBER) IS

/* Credits a bank account the specified amount. If the account

   does not exist, the procedure creates a new account first. */

old_balance  NUMBER;

new_balance  NUMBER;

  BEGIN

SELECT balance INTO old_balance FROM accounts

  WHERE acct_id = acct

  FOR UPDATE OF balance; /* Locks account for credit update */

new_balance := old_balance + credit;

UPDATE accounts SET balance = new_balance

  WHERE acct_id = acct;

do_journal_entry(acct, 'C');

  EXCEPTION

WHEN NO_DATA_FOUND THEN  /* Create new account if not found */

  INSERT INTO accounts (acct_id, balance)

    VALUES(acct, credit);

  do_journal_entry(acct, 'N');

WHEN OTHERS THEN  /* Return other errors to application */

  new_status := 'Error: ' || SQLERRM(SQLCODE);

  END credit_account;

  PROCEDURE debit_account (acct  NUMBER, debit NUMBER) IS

/* Debits an existing account if result is greater than the

   allowed minimum balance. */

old_balance         NUMBER;

new_balance         NUMBER;

insufficient_funds  EXCEPTION;

  BEGIN

SELECT balance INTO old_balance FROM accounts

  WHERE acct_id = acct

  FOR UPDATE OF balance;

new_balance := old_balance - debit;

IF new_balance >= minimum_balance THEN

  UPDATE accounts SET balance = new_balance

    WHERE acct_id = acct;

do_journal_entry(acct, 'D');

ELSE

  RAISE insufficient_funds;

END IF;

(continued on next page)

  EXCEPTION

WHEN NO_DATA_FOUND THEN

  new_status := 'Nonexistent account';

WHEN insufficient_funds THEN

  new_status := 'Insufficient funds';

WHEN OTHERS THEN  /* Returns other errors to application */

  new_status := 'Error: ' || SQLERRM(SQLCODE);

  END debit_account;

  PROCEDURE apply_transactions IS

/* Applies pending transactions in the table TRANSACTIONS to the

   ACCOUNTS table. Used at regular intervals to update bank

   accounts without interfering with input of new transactions. */

/* Cursor fetches and locks all rows from the TRANSACTIONS

   table with a status of 'Pending'. Locks released after all        pending transactions have been applied. */

CURSOR trans_cursor IS

  SELECT acct_id, kind, amount FROM transactions

    WHERE status = 'Pending'

    ORDER BY time_tag

    FOR UPDATE OF status;

  BEGIN

FOR trans IN trans_cursor LOOP   /* implicit open and fetch */

  IF trans.kind = 'D' THEN

    debit_account(trans.acct_id, trans.amount);

  ELSIF trans.kind = 'C' THEN

    credit_account(trans.acct_id, trans.amount);

  ELSE

    new_status := 'Rejected';

  END IF;

  /* Update TRANSACTIONS table to return result of applying

     this transaction. */

  UPDATE transactions SET status = new_status

    WHERE CURRENT OF trans_cursor;

END LOOP;

COMMIT;  /* Release row locks in TRANSACTIONS table. */

  END apply_transactions;

(continued on next page)

  PROCEDURE enter_transaction (acct   NUMBER,

kind   CHAR,

amount NUMBER) IS

/* Enters a bank transaction into the TRANSACTIONS table. A new

   transaction is always input into this 'queue' before being

   applied to the specified account by the APPLY_TRANSACTIONS

   procedure. Therefore, many transactions can be simultaneously

   input without interference. */

  BEGIN

INSERT INTO transactions

  VALUES (acct, kind, amount, 'Pending', sysdate);

COMMIT;

  END enter_transaction;

END bank_transactions;

While packages allow the database administrator or application developer the ability to organize such routines, they also offer increased functionality and database performance.

Applications for Packages

Packages are used to define related procedures, variables, and cursors. Packages are often implemented to provide advantages in these areas:

•	encapsulation of related procedures and variables

•	separation of the package specification and package body

•	declaration of public and private procedures, variables, constants, and cursors

•	definition of persistent package variables

•	better performance

 Encapsulation

Stored packages allow you to encapsulate, or group, related stored procedures, variables, datatypes, etc. in a single named, stored unit in the database. This provides for better organization during the development process.

Encapsulation of procedural constructs in a package also makes privilege management easier. Granting the privilege to use a package makes all constructs of the package accessible to the grantee.

 Public and Private Data and Procedures

The methods of package definition allow you to specify which variables, cursors, and procedures are:

public	Directly accessible to the user of a package.

private	Hidden from the user of a package.

For example, a package might contain ten procedures. However, the package can be defined so that only three procedures are public and therefore available for execution by a user of the package; the remainder of the procedures are private and can only be accessed by the procedures within the package.

Do not confuse public and private package variables with grants to PUBLIC, which are described in Chapter 17.

 Separate Package Specification and Package Body

A package is created in two parts: the specification and the body. A package's specification declares all public constructs of the package and the body defines all constructs (public and private) of the package. This separation of the two parts provides the following advantages:

•	By defining the package specification separately from the package body, the developer is given more flexibility in the development cycle. Specifications can be created and public procedures can be referenced without actual creation of the package body.

•	Procedure bodies contained within the package body can be altered separately from their publicly declared specifications in the package specification. As long as the procedure specification does not change, objects that reference the altered procedures of the package are never marked invalid; that is, they are never marked as needing recompilation. For more information about dependencies, see Chapter 16.

 Performance Improvement

Using packages rather than stand-alone stored procedures results in the following improvements:

•	The entire package is loaded into memory when a procedure within the package is called for the first time. This load is completed in one operation, as opposed to separate loads required with stand-alone procedures. Therefore, when calls to related packaged procedures occur, no disk I/O is necessary to execute the compiled code already in memory.

•	A package body can be replaced and recompiled without affecting the specification. As a result, objects that reference a package's constructs (always via the specification) never need to be recompiled unless the package specification is also replaced. By using packages, unnecessary recompilations can be minimized, resulting in less impact on overall database performance.

Dependency Tracking for Packages

A package is dependent on the objects referenced by the procedures and functions defined in its body. ORACLE automatically tracks and manages such dependencies. See Chapter 16 for more information about dependency tracking.

________________________________________

How ORACLE Stores Procedures and Packages

When you create a procedure or package, ORACLE automatically performs these steps:

1..	Compiles the procedure or package.

2..	Stores the compiled code.

3..	Stores the procedure or package in the database.

Compiling Procedures and Packages

The PL/SQL compiler compiles the source code. The PL/SQL compiler is part of the PL/SQL engine contained in ORACLE. If an error occurs during compilation, a message is returned. Information on identifying compilation errors is contained in the ORACLE7 Server Application Developer's Handbook

Storing the Compiled Code in Memory

ORACLE caches the compiled procedure or package in the shared pool of the SGA. This allows the code to be executed quickly and shared among many users. The compiled version of the procedure or package remains in the shared pool according to the modified least-recently-used algorithm used by the shared pool, even if the original caller of the procedure terminates his/her session. See "The Shared Pool" on page 9 - 18 for specific information about the shared pool buffer.

Storing Procedures or Packages in Database

At creation and compile time, ORACLE automatically stores the following information about a procedure or package in the database:

object name	ORACLE uses this name to identify the procedure or package. You specify this name in the CREATE PROCEDURE, CREATE FUNCTION, CREATE PACKAGE, or CREATE PACKAGE BODY statement.

source code and parse tree	The PL/SQL compiler parses the source code and produces a parsed representation of the source code, called a parse tree.

pseudo code  (P code)	The PL/SQL compiler generates the pseudocode, or P code, based on the parsed code. The PL/SQL engine executes this when the procedure or package is invoked.

error messages	ORACLE might generate errors during the compilation of a procedure or package.

To avoid unnecessary recompilation of a procedure or package, both the parse tree and the P code of an object are stored in the database. This allows the PL/SQL engine to read the compiled version of a procedure or package into the shared pool buffer of the SGA when it is invoked and not currently in the SGA. The parse tree is used when the code calling the procedure is compiled.

All parts of database procedures are stored in the SYSTEM tablespace (the data dictionary) of the corresponding database. The database administrator should plan the size of the SYSTEM tablespace, keeping in mind that all stored procedures require space in this tablespace.

________________________________________

How ORACLE Executes Procedures And Packages

When a stand-alone or packaged procedure is invoked, ORACLE performs these steps to execute it:

1..	Verifies user access.

2..	Verifies procedure validity.

3..	Executes the procedure.

Verifying User Access

ORACLE verifies that the calling user owns or has the EXECUTE privilege for the procedure or encapsulating package. The user who executes a procedure does not require access to any procedures or objects referenced within the procedure; only the owner of a procedure or package requires privileges to access referenced schema objects.

Verifying Procedure Validity

ORACLE checks the data dictionary to see if the status of the procedure or package is valid or invalid. A procedure or package is invalid when one of the following has occurred since the procedure or package was last compiled:

•	One or more of the objects referenced within the procedure or package (such as tables, views, and other procedures) have been altered or dropped (e.g., if you added a column to a table).

•	Asystem privilege has been revoked from PUBLIC or the owner of the procedure or package.

•	An object privilege for one or more of the objects referenced by a procedure or package has been revoked from PUBLIC or the owner of the procedure or package.

A procedure is valid if it has not been invalidated by any of the above operations.

If a valid stand-alone or packaged procedure is called, the compiled code is executed.

If an invalid stand-alone or packaged procedure is called, it is automatically recompiled before being executed.

For a complete discussion of valid and invalid procedures and packages, recompiling procedures, and a thorough discussion of dependency issues, see Chapter 16.

Executing a Procedure

The PL/SQL engine executes the procedure or package using different steps, depending on the situation:

•	If the procedure is valid and currently in memory, the PL/SQL engine simply executes the P code.

•	If the procedure is valid and currently not in memory, the PL/SQL engine loads the compiled P code from disk to memory and executes it. For packages, all constructs of the package (all procedures, variables, etc. compiled as one executable piece of code) are loaded as a unit.

The PL/SQL engine processes a procedure statement by statement, handling all procedural statements by itself and passing SQL statements to the SQL statement executor, as illustrated in Figure 14 - 4  on page 14 - 5.


CHAPTER 15. DATABASE TRIGGERS

Don't fire until you see the whites of their eyes.

William Prescott

This chapter discusses database triggers; that is, procedures that are stored in the database and implicitly executed ("fired") when a table is modified. Topics include:

•	how triggers are used

•	database triggers vs. SQL*Forms triggers

•	triggers vs. declarative integrity constraints

•	parts of a trigger

•	how triggers are executed

The information in this chapter applies only to those systems using ORACLE with the procedural option. If using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide.

________________________________________

An Introduction to Triggers

ORACLE allows you to define procedures that are implicitly executed when an INSERT, UPDATE, or DELETE statement is issued against the associated table. These procedures are called database triggers.

Triggers are similar to stored procedures, discussed in Chapter 14. A trigger can include SQL and PL/SQL statements to execute as a unit and can invoke other stored procedures. However, procedures and triggers differ in the way that they are invoked. While a procedure is explicitly executed by a user or an application, a trigger is implicitly fired (executed) by ORACLE when a triggering INSERT, UPDATE, or DELETE statement is issued, no matter what user is connected or what application is being used.

For example, Figure 15 - 1 shows a database application with some SQL statements that implicitly fire several triggers stored in the database.

Notice that triggers are stored in the database, separately from their associated tables.

Triggers can only be defined on tables, not views. However, triggers on the base table(s) of a view are fired if an INSERT, UPDATE, or DELETE statement is issued against a view.

How Triggers Are Used

In many cases, triggers supplement the standard capabilities of ORACLE to provide a highly customized database management system. For example, a trigger can permit DML operations against a table only if they are issued during regular business hours. The standard security features of ORACLE, roles and privileges, govern which users can submit DML statements against the table. In addition, the trigger further restricts DML operations to occur only at certain times during weekdays. This is just one way that you can use triggers to customize information management in an ORACLE database.

In addition, triggers are commonly used to:

•	automatically generate derived column values

•	prevent invalid transactions

•	enforce complex security authorizations

•	enforce referential integrity across nodes in a distributed database

•	enforce complex business rules

•	provide transparent event logging

•	provide sophisticated auditing

•	maintain synchronous table replicates

•	gather statistics on table access

Examples of many of these different trigger uses are included in the ORACLE7 Server Application Developer's Guide.

A Cautionary Note About Trigger Use

When a trigger is fired, a SQL statement within its trigger action potentially can fire other triggers, as illustrated in Figure 15 - 2 . When a statement in a trigger body causes another trigger to be fired, the triggers are said to be cascading.

While triggers are useful for customizing a database, you should only use triggers when necessary. The excessive use of triggers can result in complex interdependences, which may be difficult to maintain in a large application.

Database Triggers vs. SQL*Forms Triggers

The Oracle tool SQL*Forms can also define, store, and execute triggers as part of an application developed with SQL*Forms. However, do not confuse SQL*Forms triggers with the database triggers discussed in this chapter.

Database triggers are defined on a table, stored in the associated database, and executed as a result of an INSERT, UPDATE, or DELETE statement being issued against a table, no matter what user or application issues the statement.

SQL*Forms triggers are part of a SQL*Forms application, and are fired only when a specific trigger point is executed within a specific SQL*Forms application. SQL statements within a SQL*Forms application, as with any database application, can implicitly cause the firing of any associated database trigger. For more information about SQL*Forms and SQL*Forms triggers, see the SQL*Forms User's Guide.

Triggers vs. Declarative Integrity Constraints

Triggers and declarative integrity constraints can both be used to constrain data input. However, triggers and integrity constraints have significant differences.

A declarative integrity constraint is a statement about the database that is always true. A constraint applies to existing data in the table and any statement that manipulates the table.

Triggers constrain what transactions can do. A trigger does not apply to data loaded before the definition of the trigger; therefore, it does not guarantee all data in a table conforms to the rules established by an associated trigger.

A trigger enforces transitional constraints; that is, a trigger only enforces a constraint at the time that the data changes. Therefore, a constraint such as "make sure that the delivery date is at least seven days from today" should be enforced by a trigger, not a declarative integrity constraint.

In evaluating triggers that contain SQL functions that have NLS parameters as arguments, (for example, TO_CHAR, TO_DATE and TO_NUMBER), the default values for these parameters are taken from the NLS parameters currently in effect for the session. You can override the default values by specifying NLS parameters explicitly in such functions when you create a trigger.

For more information about declarative integrity constraints, see Chapter 7.

________________________________________

Parts of a Trigger

A trigger has three basic parts:

•	a triggering event or statement

•	a trigger restriction

•	a trigger action

Figure 15 - 3  represents each of these parts of a trigger, and is not meant to show exact syntax. Each part of a trigger is explained in greater detail in the following sections.

Triggering Event or Statement

A triggering event or statement is the SQL statement that causes a trigger to be fired. A triggering event can be an INSERT, UPDATE, or DELETE statement for a specific table.

For example, in Figure 15 - 3 , the triggering statement is:

. . . UPDATE OF parts_on_hand ON inventory . . .

which means that when the PARTS_ON_HAND column of a row in the INVENTORY table is updated, fire the trigger. Note that when the triggering event is an UPDATE statement, you can include a column list to identify which columns must be updated to fire the trigger; because INSERT and DELETE statements affect entire rows of information, a column list cannot be specified for these options.

A triggering event can specify multiple DML statements, as in:

. . . INSERT OR UPDATE OR DELETE OF inventory . . .

which means that when an INSERT, UPDATE, or DELETE statement is issued against the INVENTORY table, fire the trigger. When multiple types of DML statements can fire a trigger, conditional predicates can be used to detect the type of triggering statement; therefore, a single trigger can be created that executes different code based on the type of statement that fired the trigger.

Trigger Restriction

A trigger restriction specifies a Boolean (logical) expression that must be TRUE for the trigger to fire. The trigger action is not executed if the trigger restriction evaluates to FALSE.

A trigger restriction is an option available for triggers that are fired for each row. Its function is to conditionally control the execution of a trigger. A trigger restriction is specified using a WHEN clause. For example, the REORDER trigger in Figure 15 - 3  has a trigger restriction. The trigger is fired by an UPDATE statement affecting the PARTS_ON_HAND column of the INVENTORY table, but the trigger action only fires if the following expression is TRUE:

new.parts_on_hand < new.reorder_point

Trigger Action

A trigger action is the procedure (PL/SQL block) that contains the SQL statements and PL/SQL code to be executed when a triggering statement is issued and the trigger restriction evaluates to TRUE.

 Similar to stored procedures, a trigger action can contain SQL and PL/SQL statements; can define PL/SQL language constructs (variables, constants, cursors, exceptions, etc.); and can call stored procedures. Additionally, for row triggers, the statements in a trigger action have access to column values (new and old) of the current row being processed by the trigger. Two correlation names provide access to the old and new values for each column.

Types of Triggers

When you define a trigger, you can specify the number of times the trigger action is to be executed: once for every row affected by the triggering statement (such as might be fired by an UPDATE statement that updates many rows), or once for the triggering statement, no matter how many rows it affects.

Row Triggers     A row trigger is fired each time the table is affected by the triggering statement. For example, if an UPDATE statement updates multiple rows of a table, a row trigger is fired once for each row affected by the UPDATE statement. If a triggering statement affects no rows, a row trigger is not executed at all.

Row triggers are useful if the code in the trigger action depends on data provided by the triggering statement or rows that are affected. For example, Figure 15 - 3 illustrates a row trigger that uses the values of each row affected by the triggering statement.

Statement Triggers     A statement trigger is fired once on behalf of the triggering statement, regardless of the number of rows in the table that the triggering statement affects (even if no rows are affected). For example, if a DELETE statement deletes several rows from a table, a statement-level DELETE trigger is fired only once, regardless of how many rows are deleted from the table.

 Statement triggers are useful if the code in the trigger action does not depend on the data provided by the triggering statement or the rows affected. For example, if a trigger makes a complex security check on the current time or user, or if a trigger generates a single audit record based on the type of triggering statement, a statement trigger is used.

 BEFORE vs. AFTER Triggers

When defining a trigger, you can specify the trigger timing; that is, you can specify when the trigger action is to be executed in relation to the triggering statement: before or after the triggering statement. BEFORE and AFTER apply to both statement and row triggers.

BEFORE Triggers     BEFORE triggers execute the trigger action before the triggering statement. This type of trigger is commonly used in the following situations:

•	BEFORE triggers are used when the trigger action should determine whether or not the triggering statement should be allowed to complete. By using a BEFORE trigger for this purpose, you can eliminate unnecessary processing of the triggering statement and its eventual rollback in cases where an exception is raised in the trigger action.

•	BEFORE triggers are used to derive specific column values before completing a triggering INSERT or UPDATE statement.

AFTER Triggers     AFTER triggers execute the trigger action after the triggering statement is executed. AFTER triggers are used in the following situations:

•	AFTER triggers are used when you want the triggering statement to complete before executing the trigger action.

•	If a BEFORE trigger is already present, an AFTER trigger can perform different actions on the same triggering statement.

 Combinations

Using the options listed in the previous two sections, you can create four types of triggers:

•	BEFORE statement trigger

Before executing the triggering statement, the trigger action is executed.

•	BEFORE row trigger

Before modifying each row affected by the triggering statement and before checking appropriate integrity constraints, the trigger action is executed if the trigger restriction either evaluated to TRUE or was not included.

•	AFTER statement trigger

After executing the triggering statement and applying any deferred integrity constraints, the trigger action is executed.

•	AFTER row trigger

After modifying each row affected by the triggering statement and possibly applying appropriate integrity constraints, the trigger action is executed for the current row if the trigger restriction either evaluated to TRUE or was not included. Unlike BEFORE row triggers, AFTER row triggers have rows locked.

For example, suppose you have a table, SAL, and you want to know when the table is being accessed, and the types of queries being issued. The following package and trigger tracks this information by hour and type of action (for example UPDATE, DELETE or INSERT) on table SAL. A global session variable, STAT.ROWCNT, is initialized to zero by a BEFORE statement trigger, then it is incremented each time the row trigger is executed, and finally the statistical information is saved in the table STAT_TAB by the AFTER statement trigger.

DROP TABLE stat_tab;

CREATE TABLE stat_tab(utype CHAR(8),

rowcnt INTEGER, uhour INTEGER);

CREATE OR REPLACE PACKAGE stat IS

 rowcnt INTEGER;

END;

/

CREATE TRIGGER bt BEFORE UPDATE OR DELETE OR INSERT ON sal

BEGIN

 stat.rowcnt := 0;

END;

/

CREATE TRIGGER rt BEFORE UPDATE OR DELETE OR INSERT ON sal

FOR EACH ROW BEGIN

 stat.rowcnt := stat.rowcnt + 1;

END;

/

CREATE TRIGGER at AFTER UPDATE OR DELETE OR INSERT ON sal

DECLARE

 typ  CHAR(8);

 hour NUMBER;

BEGIN

 IF updating

 THEN typ := 'update'; END IF;

 IF deleting  THEN typ := 'delete'; END IF;

 IF inserting THEN typ := 'insert'; END IF;

 hour := TRUNC((SYSDATE - TRUNC(SYSDATE)) * 24);

 UPDATE stat_tab

    SET rowcnt = rowcnt + stat.rowcnt

   WHERE utype = typ

      AND uhour = hour;

 IF SQL%ROWCOUNT = 0 THEN

   INSERT INTO stat_tab VALUES (typ, stat.rowcnt, hour);

 END IF;

EXCEPTION

 WHEN dup_val_on_index THEN

   UPDATE stat_tab

      SET rowcnt = rowcnt + stat.rowcnt

     WHERE utype = typ

       AND uhour = hour;

END;

/

________________________________________

Trigger Execution

A trigger can be in either of two distinct modes:

enabled	An enabled trigger executes its trigger action if a triggering statement is issued and the trigger restriction (if any) evaluates to TRUE.

disabled	A disabled trigger does not execute its trigger action, even if a triggering statement is issued and the trigger restriction (if any) would evaluate to TRUE.

For enabled triggers, ORACLE automatically:

•	executes triggers in a planned firing sequence when more than one trigger is fired by a single SQL statement

•	performs integrity constraint checking at a set point in time with respect to the different types of triggers and guarantees that triggers cannot compromise integrity constraints

•	provides read-consistent views for queries and constraints

•	manages the dependencies among triggers and objects referenced in the code of the trigger action

•	uses two-phase commit if a trigger updates remote tables

The Execution Model for Triggers and Integrity Constraint Checking

 A single SQL statement can potentially fire up to four triggers:  a BEFORE row trigger, BEFORE statement trigger, AFTER row trigger, and AFTER statement trigger. A triggering statement or a statement within a trigger can cause one or more integrity constraints to be checked. Also, triggers can contain statements that cause other triggers to fire (cascading triggers). ORACLE uses the following execution model to maintain the proper firing sequence of multiple triggers and constraint checking.

1. Execute BEFORE statement trigger.

2. Loop for each row affected by the SQL statement.

a. Execute BEFORE row trigger.

b. Lock and change row, and perform integrity constraint

checking (The lock is not released until the

transaction is committed.)

c. Execute AFTER row trigger.

3. Complete deferred integrity constraint checking.

4. Execute AFTER statement trigger.

The definition of the execution model is recursive. For example, a given SQL statement can cause a BEFORE row trigger to be fired and an integrity constraint to be checked. That BEFORE row trigger, in turn, might perform an update that causes an integrity constraint to be checked and an AFTER statement trigger to be fired. The AFTER statement trigger causes an integrity constraint to be checked. In this case, the execution model executes the steps recursively, as follows:

1. Original SQL statement issued.

2.	BEFORE row trigger fired.

3.	AFTER statement trigger fired by UPDATE in

BEFORE row trigger.

4.	Statements of AFTER statement trigger executed.

5.	Integrity constraint on tables changed by

AFTER statement trigger checked.

6.	Statements of BEFORE row trigger executed.

7.	Integrity constraint on tables changed by

BEFORE row trigger checked.

8.	SQL statement executed.

9.	Integrity constraint from SQL statement checked.

 An important property of the execution model is that all actions and checks done as a result of a SQL statement must succeed. If an exception is raised within a trigger and the exception is not explicitly handled, all actions performed as a result of the original SQL statement, including the actions performed by fired triggers, are rolled back. Thus, integrity constraints cannot be compromised by triggers. The execution model takes into account integrity constraints and disallows triggers that could violate declarative integrity constraints.

For example, in the previously outlined scenario, suppose that Steps 1 through 8 succeed; however, in Step 9 the integrity constraint is violated. As a result of this violation, all changes made by the SQL statement (in Step 8), the fired BEFORE row trigger (in Step 6), and the fired AFTER statement trigger (in Step 4) are rolled back.

Data Access for Triggers

When a trigger is fired, the tables referenced in the trigger action might be currently undergoing changes by SQL statements contained in other users' transactions. In all cases, the SQL statements executed within triggers follow the common rules used for stand-alone SQL statements. In particular, if an uncommitted transaction has modified values that a trigger being fired either needs to read (query) or write (update), the SQL statements in the body of the trigger being fired use the following guidelines:

•	Queries see the current read-consistent snapshot of referenced tables and any data changed within the same transaction.

•	Updates wait for existing data locks before proceeding.

The following examples illustrate these points.

Example	Assume that the SALARY_CHECK trigger (body) includes the following SELECT statement:

SELECT minsal, maxsal INTO minsal, maxsal

FROM salgrade

WHERE job_classification = :new.job_classification;

For this example, assume that transaction T1 includes an update to the MAXSAL column of the SALGRADE table. At this point, the SALARY_CHECK trigger is fired by a statement in transaction T2. The SELECT statement within the fired trigger (originating from T2) does not see the update by the uncommitted transaction T1, and the query in the trigger returns the old MAXSAL value as of the read-consistent point for transaction T2.

Example	 Assume the following definition of the TOTAL_SALARY trigger, a trigger to maintain a derived column that stores the total salary of all members in a department:

CREATE TRIGGER total_salary

AFTER DELETE OR INSERT OR UPDATE OF deptno, sal ON emp

  FOR EACH ROW BEGIN

  /* assume that DEPTNO and SAL are non-null fields */

   IF DELETING OR (UPDATING AND :old.deptno != :new.deptno)

   THEN UPDATE dept

SET total_sal = total_sal - :old.sal

WHERE deptno = :old.deptno;

   END IF;

   IF INSERTING OR (UPDATING AND :old.deptno != :new.deptno)

   THEN UPDATE dept

    SET total_sal = total_sal + :new.sal

    WHERE deptno = :new.deptno;

   END IF;

   IF (UPDATING AND :old.deptno = :new.deptno AND

  :old.sal != :new.sal )

   THEN UPDATE dept

    SET total_sal = total_sal - :old.sal + :new.sal

   WHERE deptno = :new.deptno;

  END IF;

 END;

For this example, suppose that one user's uncommitted transaction includes an update to the TOTAL_SAL column of a row in the DEPT table. At this point, the TOTAL_SALARY trigger is fired by a second user's SQL statement. Because the uncommitted transaction of the first user contains an update to a pertinent value in the TOTAL_SAL column (i.e., a row lock is being held), the updates performed by the TOTAL_SALARY trigger are not executed until the transaction holding the row lock is committed or rolled back. Therefore, the second user waits until the commit or rollback point of the first user's transaction.

Storage for Triggers

Unlike stored procedures, only the source code of a database trigger is stored in the database. Upon first execution, the source code of a trigger is compiled and cached in the shared pool. If the trigger is flushed from the shared pool, the source code of the trigger must be recompiled when used.

Execution of Triggers

ORACLE internally executes a trigger using the same steps used for procedure execution, as explained in "How ORACLE Executes Procedures and Packages" on page 14 - 17. The only subtle difference is that user access to fire a trigger is verified if a user has the privilege to execute a triggering statement. Other than this, triggers are validated and executed the same way as stored procedures.

Dependency Maintenance for Triggers

ORACLE automatically manages the dependencies of a trigger on the schema objects referenced in its trigger action. However, such dependencies are only managed once a trigger is in the shared pool, and dependencies are not managed in quite the same way that dependencies are managed for stored procedures. Dependency management is discussed in Chapter 16.


CHAPTER 16. DEPENDENCIES AMONG SCHEMA OBJECTS

We are all dependent on one another, every soul of us on earth.

George Bernard Shaw:  Pygmalion

The definitions of certain objects, such as views and procedures, reference other objects, such as, tables. Therefore, some objects are dependent on the objects referenced in their definition. The following chapter discusses the dependencies among objects and how ORACLE automatically tracks and manages such dependencies. Topics include:

•	an explanation of dependent and referenced objects

•	how ORACLE tracks invalid and valid dependent objects

•	how ORACLE dynamically validates invalid objects

•	dependencies on non-existent objects

•	differences between local and remote dependency management

Much of the information in this chapter applies only for those systems using ORACLE with the procedural option.

If using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide.

________________________________________

An Introduction to Dependency Issues

Some types of schema objects can reference other objects as part of their definition. For example, a view is defined by a query that references tables or other views; a procedure's body can include SQL statements that reference other objects of a database. An object that references another object as part of its definition is called a dependent object, while the object being referenced is a referenced object. Figure 16 - 1 illustrates the different types of dependent and referenced objects.

If the definition of a referenced object is altered, dependent objects may, or may not, continue to function without error, depending on the type of alteration. For example, if a table is dropped, no view based on the dropped table can be used.

ORACLE automatically records dependencies among objects to hide the complex job of dependency management from the database administrator and users. For example, if you alter a table on which several stored procedures depend, the dependent procedures are automatically recompiled by ORACLE the next time the procedures are referenced (executed or compiled against).

To manage dependencies among objects, all schema objects in a database have a status:

INVALID	The object must be compiled before it can be used. In the case of procedures, functions, and packages, this means compiling the object; in the case of views, this means that the view must be reparsed, using the current definition in the data dictionary. Only dependent objects can be invalid; tables, sequences, and synonyms are always valid.

If a view, procedure, function, or package is invalid, ORACLE may have attempted to compile it, but there were some errors relating to the object. For example, when compiling a view, one of its base tables might not exist or the correct privileges for the base table might not be present. When compiling a package, there might be a PL/SQL or SQL syntax error, or the correct privileges for a referenced object might not be present. Objects with such problems remain invalid.

VALID	The object has been compiled and can be immediately used when referenced.

ORACLE automatically tracks specific changes in the database and records the appropriate status for related objects in the data dictionary.

Status recording is a recursive process; any change in the status of a referenced object not only changes the status for directly dependent objects, but also for indirectly dependent objects. For example, consider a stored procedure that directly references a view. In effect, the stored procedure indirectly references the base table(s) of that view. Therefore, if a base table is altered, the view is invalidated, which then invalidates the stored procedure; this is illustrated by Figure 16 - 2.

When an object is referenced (directly in a SQL statement, or indirectly via a reference to a dependent object), ORACLE checks the status of the object explicitly specified in the SQL statement and any referenced objects, as necessary. Depending on the status of the objects that are directly and indirectly referenced in a SQL statement, different events can occur.

•	If every referenced object is valid, the SQL statement executes immediately without any additional work.

•	If any referenced view or procedure (including functions and packages) is invalid, ORACLE automatically attempts to compile the object. If all referenced objects that are invalid can be successfully compiled, the objects are compiled and the SQL statement executes successfully. If an invalid object cannot be successfully compiled, the object remains invalid, an error is returned, and the SQL statement is rolled back.

Note: ORACLE attempts to dynamically recompile an invalid object only if it has not been replaced since it was detected as invalid. This optimization eliminates unnecessary recompilations.

Compiling Views and PL/SQL Program Units

A view or PL/SQL program unit can be compiled and made valid if the following conditions are true:

•	The definition of the view or program unit is correct; all SQL and PL/SQL statements must be proper constructs.

•	All referenced objects must be present and of the expected structure. For example, if the defining query of a view includes a column, the column must be present in the base table.

•	The owner of the view or program unit must have the necessary privileges for the referenced objects. For example, if a SQL statement in a procedure inserts a row into a table, the owner of the procedure must have the INSERT privilege for the referenced table.

 Views and Base Tables

A view depends on the base tables (or views) referenced in its defining query. If the defining query of a view is not explicit, for example, SELECT * FROM table, the defining query is expanded in the data dictionary to include all current columns in the referenced base table. If a base table (or view) of a view is altered, renamed, or dropped, the view is invalidated, and its definition remains in the data dictionary along with the privileges, synonyms, other objects, and other views that reference the invalid view.

Attempting to use an invalid view automatically causes ORACLE to dynamically compile the view. After replacing the view, the view might be valid or invalid, depending on the following:

•	All base tables referenced by the defining query of a view must exist. Therefore, if a base table of a view is renamed or dropped, the view is invalidated and the view cannot be used. References to invalid views cause the referencing statement to fail. The view can be compiled only if the base table is renamed to the original name or the base table is recreated.

•	If a base table is altered or recreated with the same columns, but the datatype of one or more columns in the base table are changed, any dependent view can be successfully recompiled.

•	If a base table of a view is altered or recreated with at least the same set of columns, the view can be validated. The view cannot be validated if the base table is recreated with new columns, and the view references columns no longer contained in the recreated table. The latter point is especially relevant in the case of views defined with a "SELECT * FROM . . ." query, because the defining query is expanded at view creation time and permanently stored in the data dictionary.

 Program Units and Referenced Objects

ORACLE automatically invalidates a program unit when the definition of a referenced object is altered. For example, assume that a stand-alone procedure includes several statements that reference a table, a view, another stand-alone procedure, and a public package procedure, then the following conditions hold.

•	If the referenced table is altered, the dependent procedure is invalidated.

•	If the base table of the referenced view is altered, the view and the dependent procedure are invalidated.

•	If the referenced stand-alone procedure is replaced, the dependent procedure is invalidated.

•	If the body of the referenced package is replaced, the dependent procedure is not affected. However, if the specification of the referenced package is replaced, the dependent procedure is invalidated.

This last case reveals a mechanism for minimizing dependencies among procedures and referenced objects.

 Security Authorizations

ORACLE notices when a DML object or system privilege is granted to or revoked from a user or PUBLIC, and automatically invalidates all the owner's dependent objects. ORACLE invalidates the dependent objects to verify that an owner of a dependent object continues to have the necessary privileges for all referenced objects. Internally, ORACLE notes that such objects do not have to be "recompiled"; only security authorizations need to be validated, not the structure of any objects. This optimization eliminates unnecessary recompilations and prevents the need to change a dependent object's timestamp.

________________________________________

Advanced Dependency Management Topics

The previous section conceptually describes the dependency management mechanisms of ORACLE. The following sections explain additional information about the automatic dependency management features of ORACLE. For information on forcing the recompilation of an invalid view or program unit, see the ORACLE7 Server Application Developer's Guide. If you are using Trusted ORACLE, also see the Trusted ORACLE7 Server Administrator's Guide.

Dependency Management and Non-Existent Schema Objects

When a dependent object is created, ORACLE attempts to resolve all references by first searching in the current schema. If a referenced object is not found in the current schema, ORACLE attempts to resolve the reference by searching for a private synonym in the same schema. If a private synonym is not found, ORACLE moves on, looking for a public synonym. If a public synonym is not found ORACLE searches for a schema name that matches the first portion of the object name. If a matching schema name is found, ORACLE repeats this process with the second portion of the object name. If no schema is found, an error is returned.

As ORACLE attempts to resolve a reference, ORACLE internally makes note of the dependencies that the new dependent object has on the "non-existent" objects not found during any reference resolution. Such dependencies must be noted in case a non-existent object is later created. If a non-existent object is created, all dependent objects must be invalidated so that dependent objects can be recompiled and verified. For example, assume the following:

•	At the current point in time, the COMPANY schema contains a table named EMP.

•	A PUBLIC synonym named EMP is created for COMPANY.EMP and the SELECT privilege for COMPANY.EMP is granted to PUBLIC.

•	The JWARD schema does not contain a table or private synonym named EMP.

•	The user JWARD creates a view in his schema with the following statement:

CREATE VIEW dept_salaries AS

   SELECT deptno, MIN(sal), AVG(sal), MAX(sal) FROM emp

   ORDER BY deptno;

When JWARD creates the DEPT_SALARIES view, the reference to EMP is resolved by first looking for JWARD.EMP as a table, view, or private synonym, none of which is found, and then as a public synonym named EMP, which is found. As a result, ORACLE notes that JWARD.DEPT_SALARIES depends on the non-existence of JWARD.EMP and the existence of PUBLIC.EMP.

Now assume that JWARD decides to create a new view named EMP in his schema using the following statement:

CREATE VIEW emp AS

SELECT empno, ename, mgr, deptno

FROM company.emp;

Note: Notice that JWARD.EMP does not have the same structure as COMPANY.EMP.

As JWARD.EMP is created, JWARD.DEPT_SALARIES is invalidated because it depends on JWARD.EMP. Therefore, when JWARD.DEPT_SALARIES is used, ORACLE attempts to recompile the view. As ORACLE resolves the reference to EMP, it finds JWARD.EMP (PUBLIC.EMP is no longer the referenced object). Because JWARD.EMP does not have a SAL column, ORACLE finds errors when replacing the view, leaving it invalid.

In summary, dependencies on non-existent objects checked during object resolution must be managed in case the non-existent object is later created.

Shared SQL Dependency Management

In addition to managing the dependencies among schema objects, ORACLE also manages the dependencies of each shared SQL area in the shared pool. If a table, view, synonym, or sequence is created, altered, or dropped, or a procedure or package specification is recompiled, all dependent shared SQL areas are invalidated. At subsequent execution of the cursor that corresponds to an invalidated shared SQL area, ORACLE reparses the SQL statement to regenerate the shared SQL area.

Package Invalidations and Session State

Each session that references a package construct has its own instance of the corresponding package, including persistent state for any public and private variables, cursors, and constants. All of a session's package instantiations (including state) can be lost if any of the session's instantiated packages (specification or body) are subsequently invalidated and recompiled.

Local and Remote Dependency Management

Tracking dependencies and completing necessary recompilations are important tasks automatically performed by ORACLE. In the simplest case, dependencies must be managed among the objects in a single database (local dependency management). For example, a statement in a procedure can reference a table in the same database. In more complex systems, ORACLE must manage the dependencies in distributed environments across a network (remote dependency management). For example, a SQL*Forms trigger can depend on a schema object in the database; in a distributed database, a local view's defining query can reference a remote table.

 Managing Local Dependencies

All local dependency checking is managed using the database's internal "depends-on" table, which keeps track of each object's dependent objects. When a referenced object is modified, the depends-on table is used to identify any dependent objects, which are then invalidated. For example, assume that there is a stored procedure UPDATE_SAL that references the table JWARD.EMP. If the definition of the table is altered in any way, the status of every object that references JWARD.EMP is changed to INVALID, including the stored procedure UPDATE_SAL. This implies that the procedure cannot be executed until the procedure has been recompiled and is valid. Similarly, when a DML privilege is revoked from a user, every dependent object in the user's schema is invalidated. However, an object that is invalid because authorization was revoked can be revalidated by "reauthorization", which incurs less overhead than a full recompilation.

 Managing Remote Dependencies

Application-to-database and distributed database dependencies must also be considered. For example, a SQL*Forms application can contain a trigger that references a table, or a local stored procedure can call a remote procedure in a distributed database system. The database system must account for dependencies among such objects. ORACLE manages remote dependencies using different mechanisms, depending on the objects involved.

Dependencies Among Local and Remote Database Procedures

   Dependencies among stored procedures (including functions, packages, and triggers) in a distributed database system are managed using timestamp checking. For example, when a procedure is compiled, such as during creation or subsequent replacement, its timestamp (the time it is created, altered, or replaced) is recorded in the data dictionary. Additionally, the compiled version of the procedure includes information (such as schema, package name, procedure name, and timestamp) for each remote procedure it references.

When a dependent procedure is used, ORACLE compares the remote timestamps recorded at compile-time with the current timestamps of the remotely referenced procedures. Depending on the result of this comparison, two situations can occur:

•	The local and remote procedures execute without compilation if the timestamps match.

•	The local procedure is invalidated if any timestamps of remotely referenced procedures do not match, and an error is returned to the calling environment. Furthermore, all other local procedures that depend on the remote procedure with the new timestamp are also invalidated. For example, assume several local procedures call a remote procedure, and the remote procedure is recompiled. When one of the local procedures is executed and notices the different timestamp of the remote procedure, every local procedure that depends on the remote procedure is invalidated.

Actual timestamp comparison occurs when a statement in the body of a local procedure executes a remote procedure; only at this moment are the timestamps compared via the distributed database's communications link. Therefore, all statements in a local procedure, previous to an invalid procedure call, might execute successfully, while statements subsequent to an invalid procedure call do not execute at all (compilation is required). However, any DML statements executed before the invalid procedure call are rolled back.

Dependencies Among Other Remote Schema Objects

    Dependencies among remote schema objects, not including local procedure-to-remote procedure dependencies, are not managed by ORACLE. For example, assume that a local view is created and defined by a query that references a remote table. Also assume that a local procedure includes a SQL statement that references the same remote table. At a later date, the definition of the table is altered. As a result, the local view and procedure are never invalidated, even if the view or procedure is used after the table is altered, and even if the view or procedure now returns errors when used (in this case, the view or procedure must be manually altered so errors are not returned). Lack of dependency management is preferable in such cases to avoid unnecessary recompilations of dependent objects.

Dependencies of Applications   Code in database applications can reference objects in the connected database, for example, OCI, Precompiler, and SQL*Module applications can submit anonymous PL/SQL blocks, triggers in SQL*Forms applications can reference a schema object. Such applications are dependent on the schema objects they reference. Dependency management techniques vary, depending on the development environment. Refer to the appropriate manual for more information about managing the remote dependencies within database applications.


PART  VII . DATABASE SECURITY


CHAPTER 17. DATABASE ACCESS

If I carried all the thoughts of the world in my hand, I would take care not to open it.

Bernard Fontenelle

The primary purpose of database security is to selectively allow and disallow users to access objects for which they are authorized. ORACLE's strategy for protecting information is to provide comprehensive discretionary access control. Discretionary access control regulates all user access to named objects. User access to objects is controlled through privileges. A privilege is permission to access a named object in a prescribed manner, for example, permission to query a table. Because privileges are granted to users at the discretion of other users, this is considered discretionary security.

This chapter explains how access to an ORACLE database as a whole is controlled. Topics include:

•	database user authentication

•	the PUBLIC user group

•	profiles and limiting use of system resources

If you are using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide.

________________________________________

Schemas, Database Users, and Security Domains

ORACLE manages database security using several different facilities. Among these facilities are schemas and users.

Each ORACLE database has a list of schemas. A schema is a collection of schema objects, such as tables, views, clusters, procedures, and packages.

Each ORACLE database has a list of valid database users. To access a database, a user must run a database application (such as a SQL*Forms form, SQL*Plus, or a Precompiler program) and connect using a username defined in the database.

When a database user is created, a corresponding schema of the same name is created for the user. By default, once a user connects to a database, the user has access to all objects contained in the corresponding schema. A user can only be associated with the schema of the same name; therefore, the terms user and schema are similar.

The access rights of a user are controlled by the different settings of the user's security domain. When creating a new database user or altering an existing user, the security administrator must make several decisions concerning a user's security domain. These include:

•	whether user authentication information is maintained by the database or the operating system

•	settings for the user's default and temporary tablespaces

•	a list, if any, of tablespaces accessible to the user and the associated quotas for each listed tablespace

•	the user's resource limit profile; that is, limits that dictate the amount of system resources available to the user

•	the privileges and roles that provide the user with appropriate access to objects needed to perform database operations

This chapter describes the security domain options listed above, except for privileges and roles, which are discussed in Chapter 18.

Note: The information in this chapter applies to all user-defined database users. It does not apply to the special database users SYS, and SYSTEM; settings for these users' security domains should never be altered. For more information about these special database users, see the ORACLE7 Server Administrator's Guide.

________________________________________

User Authentication

To prevent unauthorized use of a database username, ORACLE provides user validation via two different methods:

•	authentication by the operating system

•	authentication by the associated ORACLE database

For simplicity, one method is usually used to authenticate all users of a database; however, ORACLE allows use of both methods within the same database instance.

Authenticating ORACLE Usernames Using the Operating System

If your operating system permits, ORACLE can use information maintained by the operating system to authenticate users. The benefits of operating system authentication are:

•	Users can connect to ORACLE more conveniently (without specifying a username or password). For example, a user can invoke SQL*Plus and skip the username and password prompts by entering:

SQLPLUS /

•	Control over user authorization is centralized in the operating system; ORACLE need not store or manage user passwords. However, usernames are still maintained in the database.

•	Username entries in the database and operating system audit trails correspond.

If the operating system is used to authenticate database users, there are some special considerations with respect to distributed database environments and database links; see Chapter 21 for information on this topic.

Authenticating ORACLE Usernames Using the ORACLE Database

ORACLE can authenticate users attempting a connection to a database by using information stored in that database. Often, this method of user authentication is used when the operating system cannot be used for database user validation.

When user authentication is performed using an ORACLE database, each user is created with an associated password. A user's password is used while establishing a connection to prevent unauthorized use of the database. A user's password is stored in the database's data dictionary; however, all passwords are stored in an encrypted format to maintain security for the user. A user can change his/her password at any time.

________________________________________

User Tablespace Settings and Quotas

As part of every user's security domain, several options can be set regarding tablespace usage:

•	a user's default tablespace

•	a user's temporary tablespace

•	space usage quotas for tablespaces of the database

Default Tablespace

Each user is associated with a default tablespace. When a user creates a schema object and specifies no tablespace to contain the object, the user's default tablespace is used. The default tablespace feature provides ORACLE with information to direct space usage in situations where an object's tablespace is not specified. A user's default tablespace can be set when the user is created or changed after the user has been created.

Temporary Tablespace

Each user is associated with a temporary tablespace. When a user executes a SQL statement that requires the creation of a temporary segment, the user's temporary tablespace contains the temporary segment.

Tablespace Access and Quotas

Each user can be assigned a tablespace quota for any tablespace of the associated database. Two things are accomplished by assigning a user a tablespace quota:

•	Assuming that the user has a privilege to create some type of object, the user has access to create objects in the specified tablespace.

•	The amount of space that can be allocated for storage of a user's objects within the specified tablespace can be limited.

By default, each user has no quota on any tablespace in the database. Therefore, if the user has the privilege to create some type of schema object, he must also have been either assigned a tablespace quota in which to create the object, or been given the privilege to create that object in the schema of another user who was assigned a sufficient tablespace quota.

A user can be assigned two types of tablespace quotas:  a quota for a specific amount of disk space in the tablespace, specified in bytes, Kbytes, or Mbytes, or a quota for an unlimited amount of disk space in the tablespace. Specific quotas are assigned to prevent a user's objects from excessive consumption of space in a tablespace.

Tablespace quotas are not considered during temporary segment creation:

•	Temporary segments do not consume any quota that a user might possess.

•	Temporary segments can be created in a tablespace for which a user does not have a quota.

A user can be assigned tablespace quotas when the user is created, or a quota can be assigned to a current user that has no quota for the tablespace. A user's tablespace quotas can also be changed.

 Revoking Tablespace Access

A user's tablespace access can be revoked by altering the user's current quota to zero. Once a quota of zero is assigned, the user's objects in the revoked tablespace remain, yet the objects cannot be allocated any new space, if needed.

________________________________________

The User Group PUBLIC

Each database contains a user group called PUBLIC. The PUBLIC user group provides public access to specific schema objects (tables, views, etc.) and provides all users with specific system privileges. Every user automatically belongs to the PUBLIC user group.

As members of PUBLIC, users may see (select from) all data dictionary tables prefixed with USER and ALL. Additionally, a user can grant a privilege or a role to PUBLIC. All users can use the privileges granted to PUBLIC.

Any system privilege, object privilege, or role (all discussed in Chapter  18) can be granted to (and revoked from) PUBLIC; however, to maintain tight security over access rights, only privileges and roles of interest to all users should be granted to PUBLIC.

Granting and revoking certain system and object privileges to and from PUBLIC can cause every view, procedure, function, package, and trigger in the database to be recompiled.

Restrictions for PUBLIC include the following:

•	Tablespace quotas cannot be assigned to PUBLIC, although the UNLIMITED TABLESPACE system privilege can be granted to PUBLIC.

•	Only database links and synonyms can be created as PUBLIC objects, using CREATE PUBLIC DATABASE LINK/SYNONYM. No other object can be created as a public object. For example, the following is not legal:

    CREATE TABLE public.emp . . . ;

________________________________________

User Resource Limits and Profiles

As part of a user's security domain, limits can be set on the amount of various system resources available to the user. By explicitly setting resource limits for each user, the security administrator can prevent the uncontrolled consumption of valuable system resources such as CPU time.

The resource limit feature of ORACLE is very useful in large, multiuser systems. In such environments, system resources are very expensive; therefore, the excessive consumption of these resources by one or more users can detrimentally affect the other users of a database. In single-user or small scale multiuser database systems, the system resource feature is of less value because system resources are less likely to be consumed with detrimental impact.

Resource limits are managed with user profiles. A profile is a named set of resource limits that can be assigned to a user. Each ORACLE database can have an unlimited number of profiles available for assignment to the users of that database. Additionally, ORACLE provides the security administrator the option to universally enable or disable the enforcement of profile resource limits at the database level.

If resource limits are used for a database, a slight degradation in performance occurs when users create sessions, because as a user connects to a database, all resource limit data is loaded for the user.

Types of System Resources and Limits

ORACLE can limit the use of several types of system resources. In general, each of these resources can be controlled at the session level, the call level, or both:

Session Level	Each time a user connects to a database, a session is created. Each session consumes at least a minimum amount of CPU time and memory on the computer that executes ORACLE. Several resource limits for ORACLE can be set at the session level.

If a session-level resource limit is exceeded, the current statement is terminated (rolled back) and a message is returned indicating the session limit has been reached. At this point, all previous statements in the current transaction are intact, and the only operations the user can perform are COMMIT, ROLLBACK, or disconnect (in this case, the current transaction is committed); all other operations produce an error. Even after the transaction is committed or rolled back, the user can effectively accomplish no more work during the current session.

Call Level	Each time a SQL statement is executed, several steps are taken to process the statement. During this processing, several calls are made to the database as part of the different execution phases. To prevent any one call from excessively using the system, ORACLE allows several resource limits to be set at the call level.

If a call-level resource limit is exceeded, the processing of the statement is halted, the statement is rolled back, and an error is returned. However, all previous statements of the current transaction remain intact and the user's session remains connected.

 CPU Time

When SQL statements and other types of calls are made to ORACLE, a certain amount of CPU time is necessary to process the call. Average calls require a small amount of CPU time. However, a SQL statement involving a large amount of data or a runaway query can potentially consume a large amount of CPU time, reducing CPU time available for other processing.

To prevent uncontrolled use of CPU time, ORACLE can limit the CPU time per call and the total amount of CPU time used for ORACLE calls in the duration of a session. The limits are set and measured in CPU one-hundredth seconds (0.01 seconds) used by a call or a session.

 Logical Reads

Input/output is one of the most expensive operations in a database system. I/O intensive statements can monopolize memory and disk usage and cause other database operations to compete for these resources.

To prevent single sources of excessive I/O, ORACLE can limit the logical data block reads per call and per session. Logical data block reads include data block reads from both memory and disk. The limits are set and measured in number of block reads performed by a call or a session.

 Other Resources

ORACLE also provides for the limitation of several other resources at the session level:

•	The number of concurrent sessions per user can be limited. Each user can only create up to a predefined number of concurrent sessions.

•	The idle time for a session can be limited. If the time between ORACLE calls for a session reaches the idle time limit, the current transaction is rolled back, the session is aborted, and the resources of the session are returned back to the system. The next call receives an error that indicates the user is no longer connected to the instance. This limit is set as a number of elapsed minutes.

Note: Shortly after a session is aborted because it has exceeded an idle time limit, PMON cleans up after the aborted session; until PMON completes this process, the killed session is still counted as one of the sessions for the sessions/user resource limit.

•	The elapsed connect time per session can be limited. If a session's duration exceeds the elapsed time limit, the current transaction is rolled back, the session is dropped, and the resources of the session are released back to the system. This limit is set as a number of elapsed minutes.

Note: ORACLE does not constantly monitor the elapsed idle time or elapsed connection time. Doing so would reduce system performance. Instead, it checks every few minutes. Therefore, a session can exceed this limit slightly (for example, by five minutes) before ORACLE enforces the limit and aborts the session.

•	The amount of private SGA space (used for private SQL areas) for a session can be limited. This limit is only important in systems that use the multi-threaded server configuration; otherwise, private SQL areas are located in the PGA. This limit is set as a number of bytes of memory in an instance's SGA. The characters "K" or "M" can be used to specify Kilobytes or Megabytes.

Instructions on enabling and disabling resource limits are included in the ORACLE7 Server Administrator's Guide.

Profiles

A profile is a named set of specified resource limits that can be assigned to valid usernames of an ORACLE database. Profiles provide for easy management of resource limits.

 When to Use Profiles

You only need to create and manage user profiles if resource limits are a requirement of your database security policy. To use profiles, first categorize the related types of users in a database. Just as roles are used to manage the privileges of related users, profiles are used to manage the resource limits of related users. Determine how many profiles are needed to encompass all types of users in a database and then determine appropriate resource limits for each profile.

 Determining Values for Resource Limits of a Profile

Before creating profiles and setting the resource limits associated with them, you should determine appropriate values for each resource limit. Base these values on the type of operations a typical user performs. For example, if one class of user does not normally perform a high number of logical data block reads, then the LOGICAL_READS_PER_SESSION and LOGICAL_READS_PER_CALL limits should be set conservatively.

In most cases, the best way to determine the appropriate resource limit values for a given user profile is to gather historical information about each type of resource usage. For example, the database or security administrator can gather information about the CONNECT_TIME, LOGICAL_READS_PER_SESSION, and LOGICAL_READS_PER_CALL limits using the audit feature of ORACLE. By using the AUDIT SESSION option, the audit trail gathers helpful information that can be used to determine appropriate values for the previously mentioned limits. Statistics for other limits can be gathered using the Monitor feature of SQL*DBA, specifically the Statistics monitor. The Monitor feature of SQL*DBA is described in the ORACLE7 Server Utilities User's Guide.

________________________________________

Licensing

Usually, ORACLE is licensed for use by a maximum number of named users, or by a maximum number of concurrently connected users. The database administrator is responsible for making sure that the site complies with its license agreement. ORACLE's licensing facility helps database administrators track and limit the number of sessions concurrently connected to an instance, or limit the number of users created in a database, and thereby ensure that the site complies with the ORACLE license agreement.

The database administrator controls the licensing facilities, and can enable the facility and set the limits. He can also monitor the system's use. If the database administrator discovers that more than the licensed number of sessions need to connect, or more than the licensed number of users need to be created, he can upgrade the ORACLE license to raise the appropriate limit. (To upgrade an ORACLE license, you must contact your Oracle representative.)

Note: In some cases, ORACLE is not licensed for either a set number of sessions or a set group of users. For example, when ORACLE is embedded in an Oracle application (such as Oracle*Mail), run on some older operating systems, or purchased for use in some countries, it is licensed differently. In such cases only, the ORACLE licensing mechanisms do not apply and should remain disabled.

The following sections explain the two major types of licensing available for ORACLE.

Concurrent Usage Licensing

In concurrent usage licensing, the license specifies a number of concurrent users, which are sessions that can be connected concurrently to the database on the specified computer at any time. This number includes all batch processes and on-line users; also, if a single user has multiple concurrent sessions, each session counts separately in the total number of sessions. If multiplexing software (such as a TP monitor) is used to reduce the number of sessions directly connected to the database, the number of concurrent users is the number of distinct inputs to the multiplexing front-end.

The concurrent usage licensing mechanism allows a database administrator to do the following:

•	An administrator can set a limit on the number of concurrent sessions that can connect to an instance, by setting the LICENSE_MAX_SESSIONS parameter. Once this limit is reached, only users who have the RESTRICTED SESSION system privilege can connect to the instance; this allows database administrators to kill unneeded sessions, to allow other sessions to connect.

•	An administrator can set a warning limit on the number of concurrent sessions that can connect to an instance by setting the LICENSE_SESSIONS_WARNING parameter. Once the warning limit is reached, ORACLE allows additional sessions to connect (up to the maximum limit described above), but sends a warning message to any user with RESTRICTED SESSION privilege who connects, and records a warning message in the database's ALERT file.

The database administrator can set these limits in the database's parameter file, so that they take effect when the instance starts. The administrator can alternatively change them while the instance is running, with the ALTER SYSTEM command; this is useful for databases that cannot be taken offline.

In addition, the session licensing mechanism allows a database administrator to check the current number of connected sessions and the maximum number of concurrent sessions since the instance started. The V$LICENSE view shows the current settings for the license limits, the current number of sessions, and the maximum number of concurrent sessions since the instance started (the session "high water mark"). The administrator can use this information to evaluate the system's licensing needs and plan for system upgrades.

For instances running with the Parallel Server, each instance can have its own concurrent usage limit and warning limit. The sum of the instances' limits must not exceed the site's concurrent usage license. See the ORACLE7 Parallel Server Administrator's Guide for more information.

The concurrent usage limits apply to all user sessions, including sessions created for incoming database links. They do not apply to sessions created by ORACLE or recursive sessions. Sessions that connect through external multiplexing software are not counted separately by the ORACLE licensing mechanism, although each contributes individually to the ORACLE license total; the database administrator is responsible for taking these sessions into account.

Named User Licensing

In named user licensing, the license specifies a number of named users, where a named user is an individual who is authorized to use ORACLE on the specified computer. No limit is set on the number of sessions each user can have concurrently, or on the number of concurrent sessions for the database.

Named user licensing allows a database administrator to set a limit on the number of users that are defined in a database, including users connected via database links. Once this limit is reached, no one can create a new user. This mechanism assumes that each person accessing the database has a unique user name in the database, and that no people share a user name.

The database administrator can set this limit in the database's parameter file, so that it takes effect when the instance starts. The administrator can also change it while the instance is running, with the ALTER SYSTEM command; this is useful for databases that cannot be taken offline.

If multiple instances connect to the same database with the Parallel Server, all instances connected to the same database should have the same named user limit. See the ORACLE7 Parallel Server Administrator's Guide for more information.


CHAPTER 18. PRIVILEGES AND ROLES

A paranoid is a man who knows a little of what's going on.

William Burroughs

This chapter explains how, using privileges and roles, an administrator can control the ability to execute system operations, and control access to schema objects. Topics include:

•	system and object privileges

•	database roles

•	how role use can be controlled

If you are configured with Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide.

________________________________________

Privileges

A privilege is a right to execute a particular type of SQL statement or to access another user's object. Some examples of privileges include:

•	the right to connect to the database (create a session)

•	the right to create a table

•	the right to select rows from another user's table

•	the right to execute another user's stored procedure

Complete listings of all system and object privileges, as well as instructions for privilege management are included in the ORACLE7 Server Administrator's Guide.

Privileges are granted (assigned) to users so these users can accomplish tasks required of their job. A privilege should only be granted to a user who absolutely requires the privilege to accomplish necessary work. A user can receive a privilege two different ways:

•	Privileges can be granted to users explicitly. For example, the privilege to insert records into the EMP table can be explicitly granted to the user SCOTT.

•	Privileges can also be granted to roles (a named group of privileges), and then the role can be granted to one or more users. For example, the privileges to select, insert, update, and delete records from the EMP table can be granted to the role named CLERK, which in turn can be granted to the users SCOTT and BRIAN.

Because roles allow for easier and better management of privileges, privileges are normally granted to roles and not to specific users.

There are two distinct categories of privileges:

•	system privileges

•	object privileges

System Privileges

A system privilege is a privilege or right to perform a particular action, or to perform a particular action on a particular type of object. For example, the privileges to create tablespaces and to delete the rows of any table in a database are system privileges. There are over 60 distinct system privileges. Each system privilege allows a user to perform a particular database operation or class of database operations.

 Granting and Revoking System Privileges

System privileges can be granted to or revoked from users and roles. If system privileges are granted to roles, the advantages of roles can be used to manage system privileges (e.g., roles permit privileges to be selectively made available).

System privileges are granted to or revoked from users and roles using either of the following, respectively:

•	the Grant System Privileges/Roles or Revoke System Privileges/Roles dialog boxes of SQL*DBA

•	the SQL commands GRANT and REVOKE

Note: System privileges are normally granted only to administrative personnel and application developers because end-users normally do not require the associated capabilities.

 Who Can Grant or Revoke System Privileges?

Only users granted a system privilege with the ADMIN OPTION (typically the database administrator or security administrator) or a user with the GRANT ANY PRIVILEGE system privilege can grant or revoke a system privilege to or from other users or roles of the database.

Object Privileges

An object privilege is a privilege or right to perform a particular action on a specific table, view, sequence, procedure, function, or package. For example, the privilege to delete rows from the table DEPT is an object privilege. Depending on the type of object, there are different types of object privileges. Object privileges are normally granted to roles defined for end-user groups or granted directly to users so that end-users of the database can perform specific operations.

Some schema objects (such as clusters, indexes, triggers, and database links) do not have associated object privileges; they are controlled using system privileges. For example, to alter a cluster, a user must own the cluster or have the ALTER ANY CLUSTER system privilege.

Object privileges granted for a table, view, sequence, procedure, function, or package can be used when referencing the base object by name or by using a synonym. For example, assume there is a table JWARD.EMP with a synonym named JWARD.EMPLOYEE. JWARD issues the following statement:

GRANT SELECT ON emp TO swilliams;

The user SWILLIAMS can query JWARD.EMP by referencing the table by name or using the synonym JWARD.EMPLOYEE:

SELECT * FROM jward.emp;

SELECT * FROM jward.employee;

Object privileges for table, view, sequence, procedure, function, or package can be granted by specifying a synonym for the base object. In this case, the privileges for the underlying object are actually granted to the grantee. For example, if JWARD wanted to grant the SELECT privilege for the EMP table to SWILLIAMS, JWARD could issue either of the following statements:

GRANT SELECT ON emp TO swilliams;

GRANT SELECT ON employee TO swilliams;

If a synonym is dropped, all grants for the underlying object remain, even if privileges were granted by specifying the dropped synonym.

 Granting and Revoking Object Privileges

Object privileges can be granted to and revoked from users and roles. If object privileges are granted to roles, roles can be used to manage privileges; that is, roles permit privileges to be selectively available. Object privileges can be granted to, or revoked from, users and roles using the SQL commands GRANT and REVOKE, respectively.

 Who Can Grant Object Privileges?

A user automatically has all object privileges for the objects contained in the schema that corresponds to the user's name; i.e., the owner of the schema. An object owner can grant any object privilege on the object to any other user or role. If the grant includes the GRANT OPTION (of the GRANT command), the grantee can further grant the object privilege to other users; otherwise, the grantee can only use the privilege but not grant it to other users.

 Table Security Topics

The object privileges for tables allow table security at two levels:

Data Manipulation Language Operations      The DELETE, INSERT, SELECT, and UPDATE privileges allow DML operations on a table (operations that select from, or change the content of the table). These privileges should only be granted to users and roles that need to manipulate a table's data.

The INSERT and UPDATE privileges for a table can be granted for specific columns of the table. With selective INSERT, a privileged user can insert a row, but only values of specific columns; all other columns receive NULL or the column's default value. With selective UPDATE, a user can update only specific column values of a row. Selective INSERT and UPDATE privileges are used to restrict a user's access to sensitive data.

For example, if you do not want data entry users to alter the SAL column of the employee table, selective INSERT and/or UPDATE privileges can be granted, not including the SAL column. Also, views satisfy this need for an additional level of security for tables.

Data Definition Language Operations      The ALTER, INDEX, and REFERENCES privileges allow DDL operations to be performed on a table. Because these privileges allow other users to alter or create dependencies on a table, the privileges should be granted conservatively. In addition to these privileges, a user attempting to perform a DDL operation on a table can require other system and/or object privileges (for example, to create a trigger on a table, the user requires both the ALTER TABLE object privilege for the table and the CREATE TRIGGER system privilege).

As with the INSERT and UPDATE privileges, the REFERENCES privilege can be granted for specific columns of a table. The REFERENCES privilege is provided so that the dependencies on a table's primary and unique keys can be controlled with respect to foreign keys of related tables. Column-specific REFERENCES privileges only need to be granted on the columns that constitute a primary or unique key of a table, if desired. See Chapter 7 for more information about primary keys, unique keys, and integrity constraints.

 View Security Topics

The object privileges for views allow various DML operations. Of course, a DML statement performed on a view actually affects the base tables that form the view. DML object privileges for tables can be applied similarly to views.

Privileges Required To Create Views      To create a view, requires the following:

•	You must have been granted the CREATE VIEW (to create a view in your schema) or CREATE ANY VIEW system privilege (to create a view in another user's schema), either explicitly or via a role, and

•	You must have been explicitly granted the SELECT, INSERT, UPDATE, and/or DELETE object privileges to all base objects underlying the view or the SELECT ANY TABLE, INSERT ANY TABLE, UPDATE ANY TABLE and/or DELETE ANY TABLE system privilege; you may not have obtained these privileges through roles.

•	Additionally, if you intend to grant access to your view to other users, you must have received the object privilege(s) to the base objects with the GRANT OPTION or the system privileges with the ADMIN OPTION; if you have not, and grant access to your view, grantees cannot access your view.

Increasing Table Security Using Views   To use a view, you only require the appropriate privilege for the view; you do not require any privileges for the base object(s) underlying the view.

Views are useful for adding two more levels of security for tables:

•	A view can provide access to selected columns of the base table or tables that define the view. For example, a view can be defined on the EMP table to show only the EMPNO, ENAME, and MGR columns:

CREATE VIEW emp_mgr AS

   SELECT ename, empno, mgr FROM emp;

•	A view can provide value-based security for the information in a table. A WHERE clause in the definition of a view displays only selected rows of the associated base tables. Consider the following two examples:

CREATE VIEW lowsal AS

   SELECT * FROM emp

   WHERE sal < 10000;

The LOWSAL view allows access to all rows of the base table EMP that have a salary value less than 10000. Value-based security is defined on the salary value in a row. Notice that all columns of the EMP table are accessible by the definition of the LOWSAL view.

CREATE VIEW own_salary AS

   SELECT ename, sal

   FROM emp

   WHERE ename = USER;

The OWN_SALARY view uses the USER pseudocolumn. The values in the USER pseudocolumn are always the current user. In the OWN_SALARY view, only the rows with an ENAME that matches the user using the view are accessible. Value-based security is defined on the user accessing the view. This view combines both column-level security and value-based security.

 Procedure Security Topics

The one object privilege for procedures (including stand-alone procedures and functions, and packages) is EXECUTE. This privilege should only be granted to users who need to execute a procedure.

Procedures can be used to add an additional level of database security. A user requires only the privilege to execute a procedure and no privileges to the underlying objects that a procedure's code accesses. By writing a procedure and granting only the EXECUTE privilege to a user (and not the privileges on the objects referenced by the procedure), the user can be forced to access the referenced objects only through the procedure (that is, the user cannot submit adhoc SQL statements to the database).

Privileges Needed to Create or Alter a Procedure      To create a procedure, a user must have the CREATE PROCEDURE or CREATE ANY PROCEDURE system privilege. To alter a procedure; that is, to manually recompile a procedure, a user must own the procedure or have the ALTER ANY PROCEDURE system privilege.

Additionally, the user who owns the procedure must have the required privileges for the objects referenced in the body of a procedure. To create a procedure, you must have been explicitly granted the necessary privileges (system and/or object) to all objects referenced by the stored procedure; you cannot have obtained the required privileges through roles. This includes the EXECUTE privilege for any procedures that are called inside the stored procedure being created. Triggers also require that privileges to referenced objects be granted explicitly to the trigger owner. Anonymous PL/SQL blocks can use any privilege, whether the privilege is granted explicitly or via a role.

Procedure Execution and Security Domains   A user with the EXECUTE privilege for a specific procedure can execute the procedure. A user with the EXECUTE ANY PROCEDURE system privilege can execute any procedure in the database. A user can be granted the privileges to execute procedures via roles.

When a procedure is being executed, the procedure temporarily operates under the security domain of the user who owns the procedure. Therefore, a user does not need privileges on the referenced objects to execute a procedure. Because the owner of a procedure must have the necessary object privileges for referenced objects, fewer privileges have to be granted to users of the procedure and tighter control of database access can be obtained.

The current privileges of the owner of a stored procedure are always checked before the procedure is executed. If a necessary privilege on a referenced object is revoked from the owner of a procedure, the procedure cannot be executed, either by the owner or any user with the EXECUTE privilege for the procedure.

Note: Trigger execution follows these same patterns. The user executes a SQL statement, which he/she is privileged to execute. As a result of the SQL statement, a trigger is fired. The statements within the triggered action temporarily execute under the security domain of the user that owns the trigger.

Packages and Package Objects      A user with the EXECUTE privilege for a package can execute any (public) procedure or function in the package, and access or modify the value of any (public) package variable. Specific EXECUTE privileges cannot be granted for a package's constructs. Because of this property of privilege management regarding package objects, it is useful to consider two alternatives for establishing security when developing procedures, functions, and packages for a database application. These alternatives are described in the following examples.

Example 1

This example shows four procedures created in the bodies of two packages.

CREATE PACKAGE BODY hire_fire AS

PROCEDURE hire(...) IS

BEGIN

INSERT INTO emp . . .

END hire;

PROCEDURE fire(...) IS

BEGIN

DELETE FROM emp . . .

END fire;

END hire_fire;

CREATE PACKAGE BODY raise_bonus AS

PROCEDURE give_raise(...) IS

BEGIN

UPDATE EMP SET sal = . . .

END give_raise;

PROCEDURE give_bonus(...) IS

BEGIN

UPDATE EMP SET bonus = . . .

END give_bonus;

END raise_bonus;

Access to execute the procedures is given by granting the EXECUTE privilege for the encompassing package, as in the following statements:

GRANT EXECUTE ON hire_fire TO big_bosses;

GRANT EXECUTE ON raise_bonus TO little_bosses;

This method of security for package objects is not discriminatory for any specific object in a package; the EXECUTE privilege is granted for the package, which provides access to all package objects.

Example 2

This example shows four procedure definitions within the body of a single package. Two additional stand-alone procedures and a package are created specifically to provide access to the procedures defined in the main package.

CREATE PACKAGE BODY employee_changes AS

PROCEDURE change_salary(...) IS BEGIN ... END;

PROCEDURE change_bonus(...) IS BEGIN ... END;

PROCEDURE insert_employee(...) IS BEGIN ... END;

PROCEDURE delete_employee(...) IS BEGIN ... END;

END employee_change;

CREATE PROCEDURE hire

BEGIN

insert_employee(...)

END hire;

CREATE PROCEDURE fire

BEGIN

delete_employee(...)

END fire;

PACKAGE raise_bonus IS

PROCEDURE give_raise(...) AS

BEGIN

change_salary(...)

END give_raise;

PROCEDURE give_bonus(...)

BEGIN

change_bonus(...)

END give_bonus;

Using this method, the procedures that actually do the work (the procedures in the EMPLOYEE_CHANGES package) are defined in a single package, and can share declared global variables, cursors, etc. By declaring the top-level procedures HIRE and FIRE, and the additional package RAISE_BONUS, selective EXECUTE privileges can be indirectly granted for the procedures in the main package.

GRANT EXECUTE ON hire, fire TO big_bosses;

GRANT EXECUTE ON raise_bonus TO little_bosses;

________________________________________

Roles

ORACLE provides for easy and controlled privilege management through the use of roles. Roles are named groups of related privileges that are granted to users or other roles.

These properties of roles allow for easier privilege management within a database:

•	Reduced privilege administration  Rather than explicitly granting the same set of privileges to several users, the privileges for a group of related users can be granted to a role, and then only the role needs to be granted to each member of the group.

•	Dynamic privilege management  If the privileges of a group must change, only the privileges of the role need to be modified. The security domains of all users granted the group's role automatically reflect the changes made to the role.

•	Selective availability of privileges  The roles granted to a user can be selectively enabled (made available for use) or disabled (made unavailable for use). This allows specific control of a user's privileges in any given situation.

•	Application awareness  Because the data dictionary records which roles exist, database applications can be designed to query the dictionary and automatically enable (and disable) selective roles when a user attempts to execute the application via a given username.

•	Application-specific security  Role use can be protected by a password. Applications can be created to specifically enable a role by supplying the correct password; users cannot enable the role if they do not know the password. Instructions for enabling roles from an application are included in the ORACLE7 Server Application Developer's Guide.

Common Uses for Roles

In general, a role is created to serve one of two purposes: to manage the privileges for a database application, or to manage the privileges for a user group. Figure 18 - 1  and the sections that follow describe the two uses of roles.

 Application Roles

An application role is one that is granted all privileges necessary to run a given database application. An application role is granted to other roles or to specific users. An application can have several different roles, with each role assigned a different set of privileges that allow for more or less data access while using the application.

 User Roles

A user role is one that is created for a group of database users with common privilege requirements. User privilege management is controlled by granting application roles and privileges to the user role and then granting the user role to appropriate users.

The Mechanisms of Roles

The functionality of database roles includes:

•	A role can be granted system or object privileges.

•	A role can be granted to other roles. However, a role cannot be granted to itself, and cannot be granted circularly (e.g., role A cannot be granted to role B if role B has previously been granted to role A).

•	Any role can be granted to any database user.

•	Each role granted to a user is either enabled or disabled. A user's security domain includes the privileges of all roles currently enabled for the user. A user's security domain does not include the privileges of any roles currently disabled for the user. ORACLE allows database applications and users to enable and disable roles to provide selective availability of privileges.

•	An indirectly granted role (a role granted to a role) can be explicitly enabled or disabled for a user. However, by enabling a role that contains other roles, all indirectly granted roles of the directly granted role are implicitly enabled.

Granting and Revoking Roles

Roles are granted to and revoked from users or other roles using the following options, respectively:

•	the Grant System Privileges/Roles and Revoke System Privileges/Roles dialog boxes of SQL*DBA

•	the SQL commands GRANT and REVOKE

Privileges are granted to and revoked from roles using the same options. Roles can also be granted to and revoked from users using the operating system that executes ORACLE.

More detailed instructions on role management are included in the ORACLE7 Server Administrator's Guide.

Who Can Grant or Revoke Roles?

Any user with the GRANT ANY ROLE system privilege can grant or revoke any role to or from other users or roles of the database; this system privilege should be granted conservatively because it is very powerful. Additionally, any user granted a role with the ADMIN OPTION can grant or revoke the role to or from other users or roles of the database; this option allows administrative powers for roles on a selective basis.

Naming Roles

Within a database, each role name must be unique, and no username and role can be the same. Unlike schema objects, roles are not "contained" in any schema; therefore, a user who creates a role can be dropped with no effect on the role.

Security Domains of a Role and a User Granted Roles

Each role and user has its own unique security domain. A role's security domain includes the privileges granted to the role plus those privileges granted to any roles that are granted to the role. A user's security domain includes privileges on all objects in the corresponding schema, the privileges granted to the user, and the privileges of roles granted to the user that are currently enabled. A user's security domain also includes the privileges and roles granted to the user group PUBLIC. A role can be simultaneously enabled for one user and disabled for another.

Data Definition Language Statements and Roles

Depending on the statement, a user requires one or more privileges to successfully execute a DDL statement. For example, to create a table, the user must have the CREATE TABLE or CREATE ANY TABLE system privilege. To create a view of another user's table, the creator requires the CREATE VIEW or CREATE ANY VIEW system privilege, and the SELECT privilege for the table or the SELECT ANY TABLE system privilege.

ORACLE avoids the dependencies on privileges received via roles by restricting the use of specific privileges in certain DDL statements. The following rules outline these privilege restrictions concerning DDL statements:

•	All system privileges and object privileges that permit a user to perform a DDL operation are usable when received via a role.

Examples:	System Privileges: the CREATE TABLE, CREATE VIEW and CREATE PROCEDURE privileges. Object Privileges: the ALTER and INDEX privileges for a table.

Exception:	The REFERENCES object privilege for a table cannot be used for definition of a table's foreign key if the privilege is received via a role.

•	All system privileges and object privileges that allow a user to perform a DML operation that is required to issue a DDL statement are not usable when received via a role.

Example:	If a user receives the SELECT ANY TABLE system privilege or the SELECT object privilege for a table via a role, neither privilege can be used when creating a view on another user's table.

The following example further clarifies the permitted and restricted uses of privileges received via roles:

Example	Assume that a user:

•	is granted a role that has the CREATE VIEW system privilege

•	is granted a role that has the SELECT object privilege for the EMP table

•	is not directly granted the SELECT privilege for the EMP table

•	is directly granted the SELECT object privilege for the DEPT table

Given these directly and indirectly granted privileges:

•	The user can issue SELECT statements on either the EMP or DEPT tables.

•	Although the user has both the CREATE VIEW and SELECT privilege for the EMP table (both via a role), the user cannot create a usable view on the EMP table because the SELECT object privilege for the EMP table was granted via a role; that is, only views with errors can be created.

•	The user can create a view on the DEPT table because the user has the CREATE VIEW privilege (via a role) and the SELECT privilege for the DEPT table (directly).

Predefined Roles

The roles CONNECT, RESOURCE, DBA, EXP_FULL_DATABASE and IMP_FULL_Database are automatically defined for ORACLE databases. These roles are provided for backward compatibility to earlier versions of ORACLE. These roles can be modified in the same manner as any other role in an ORACLE database.

The Operating System and Roles

In some environments, database security can be administered using the operating system. The operating system can be used to manage the grants (and revokes) of database roles and/or manage the authorization of database roles. This capability might not be available on all operating systems; see your installation or user's guide for details.


CHAPTER 19. AUDITING

Big Brother is watching you.

George Orwell:  1984

This chapter discusses the auditing feature of ORACLE. Topics include:

•	the goals of auditing database activity

•	the different types of auditing, including statement, privilege, and object auditing

•	how the auditing mechanism works

If you are using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide for additional information.

________________________________________

Introduction to Auditing

Auditing is the monitoring and recording of selected user database actions. Auditing is normally used to:

•	investigate suspicious activity. For example, if data is being deleted from tables by an unauthorized user, the security administrator might decide to audit all connections to the database and all successful and unsuccessful deletions of rows from all tables in the database.

•	monitor and gather data about specific database activities. For example, the database administrator can gather statistics about which tables are being updated, how many logical I/Os are performed, or how many concurrent users connect at peak times.

Auditing Features

These sections outline the features of the ORACLE auditing mechanism.

 Types of Auditing

ORACLE supports three general types of auditing:

statement auditing	The selective auditing of SQL statements with respect to only the type of statement, not specific structures or objects, such as AUDIT TABLE. Statement auditing options are typically broad, auditing the use of several types of related actions per option. Statement auditing can be set to audit selected users or every user in the database.

privilege   auditing	The selective auditing of the use of powerful system privileges to perform corresponding actions, such as AUDIT CREATE TABLE. Privilege auditing is more focused than statement auditing, auditing only the use of the target privilege. Privilege auditing can be set to audit a selected users or every user in the database.

object auditing	The selective auditing of specific statements on a particular schema object, such as AUDIT SELECT ON EMP. Object auditing is very focused, auditing only a specific statement on a specific object. Object auditing always applies to all users of the database.

Audit options are set to determine the type of audit information that can be collected.

 Focus of Auditing

ORACLE allows audit options to be focused or broad in the following areas:

•	audit successful statement executions, unsuccessful statement executions, or both

•	audit statement executions once per user session or once every time the statement is executed

•	audit activities of all users or of a specific user

 Audit Records and the Audit Trail

Audit records include such information as the operation that was audited, the user performing the operation, and the date/time of the operation. Audit records can be stored in either a data dictionary table, called the audit trail, or an operating system audit trail.

The database audit trail is a single table name AUD$ in the SYS schema of each ORACLE database's data dictionary. Several predefined views are provided to help you use this information. Instructions for creating and using these views are included in the ORACLE7 Server Administrator's Guide.

Auditing Mechanisms

These sections explain the mechanisms used by the ORACLE auditing features.

 When Are Audit Records Generated?

ORACLE allows the recording of audit information to be enabled or disabled. This functionality allows audit options to be set by any authorized database user at any time, but reserves control of recording audit information for the security administrator. Instructions on enabling and disabling auditing are included in the ORACLE7 Server Administrator's Guide.

Assuming auditing is enabled in the database, an audit record is generated during the execute phase of statement execution.

Note: If you are not familiar with the different phases of SQL statement processing and shared SQL, refer to Chapter 11 for background information concerning the following discussion.

SQL statements inside PL/SQL program units are individually audited, as necessary, when the program unit is executed.

The generation and insertion of an audit trail record is independent of a user's transaction; therefore, if a user's transaction is rolled back, the audit trail record remains committed.

Note: Audit records are never generated by sessions established by the user SYS or connections as INTERNAL. Connections by these users bypass certain internal features of ORACLE to allow specific administrative operations to occur (e.g., database startup, shutdown, recovery, etc.).

 When Do Audit Options Take Effect?

Statement and privilege audit options in effect at the time a database user connects to the database; i.e., begins a session, remain for the duration of the session; a session does not see the effects of statement audit options being set or changed. In this case, a database user only adheres to modified statement or privilege audit options when the current session is ended and a new session is created. Alternatively, a session adheres to any object audit options being set or changed during the current session.

 Auditing in a Distributed Database

Auditing is site autonomous; an instance audits only the statements issued by directly connected users. A local ORACLE cannot audit actions that take place in a remote database. Because remote connections are established via the user account of a database link, the remote ORACLE audits statements issued via the connection of the database link. Refer to Chapter 21 for more information about distributed databases and database links.

________________________________________

Statement Auditing

Statement auditing is the selective auditing of related groups of statements that fall into two categories:

•	DDL statements, regarding a particular type of database structure or object, but not a specifically named structure or object (AUDIT TABLE audits all CREATE and DROP TABLE statements)

•	DML statements, regarding a particular type of database structure or object, but not a specifically named structure or object (AUDIT SELECT TABLE audits all SELECT . . . FROM TABLE/VIEW/SNAPSHOT statements, regardless of the table, view, or snapshot)

Statement auditing can be broad and audit the activities of all database users, or focused and audit only the activities of a select list of database users.

________________________________________

Privilege Auditing

Privilege auditing is the selective auditing of the statements allowed by the grantee of a system privilege. For example, auditing of the SELECT ANY TABLE system privilege audits users' statements that are executed using the SELECT ANY TABLE system privilege.

You can audit the use of any system privilege. In all cases of privilege auditing, owner privileges and object privileges are checked before the use of system privileges. If similar statement and privilege audit options are both set, only a single audit record is generated. For example, if the statement option TABLE and the system privilege CREATE TABLE are both audited, only a single audit record is generated each time a table is created.

Privilege auditing is more focused than statement auditing because each option audits only specific types of statements, not a related list of statements. For example, the statement auditing option TABLE audits CREATE TABLE, ALTER TABLE, and DROP TABLE statements, while the privilege auditing option CREATE TABLE audits only CREATE TABLE statements, since only the CREATE TABLE statement requires the CREATE TABLE privilege.

Privilege auditing can be broad, and audit the activities of all database users, or focused, and audit only the activities of a select list of database users.

________________________________________

Object Auditing

Object auditing is the selective auditing of specific DML statements (including queries), and GRANT and REVOKE statements for specific schema objects. Object auditing audits the operations permitted by object privileges, such as SELECT or DELETE statements on a given table.

You can audit statements that reference tables, views, sequences, stand-alone stored procedures and functions (that is, procedures in packages cannot be individually audited), and packages. Notice that statements that reference clusters, database links, indexes, or synonyms are not directly audited; however, access via one of these objects can be indirectly audited by auditing the operations that affect the base table. Object audit options are always set for all users of the database; these options cannot be set for a specific list of users. ORACLE provides a mechanism for setting default object audit options for all auditable schema objects

Object Audit Options for Views and Procedures

Becauseviews and procedures (including stored functions, packages, and triggers) reference underlying objects in their definition, auditing with respect to views and procedures has several unique characteristics. Several audit records can potentially be generated as the result of using a view or a procedure. Not only is the use of the view or procedure subject to enabled audit options, but the SQL statements issued as a result of using the view or procedure are subject to enabled audit options of the base objects (including default audit options).

Consider the following series of SQL statements to illustrate this unique aspect of auditing views and procedures:

AUDIT SELECT ON emp;

CREATE VIEW emp_dept AS

SELECT empno, ename, dname

FROM emp, dept

WHERE emp.deptno = dept.deptno;

AUDIT SELECT ON emp_dept;

SELECT * FROM emp_dept;

As a result of issuing the query on EMP_DEPT, two audit records are generated; one for querying the EMP_DEPT view and one for querying the base table EMP (indirectly via the EMP_DEPT view). An audit record is not generated for querying the base table DEPT because the SELECT audit option for this table is not enabled. All audit records are generated on behalf of the user that queried the EMP_DEPT view.

Audit options for a view or procedure are determined when the view or procedure is first used and placed in the shared pool. These audit options remain set until the view or procedure is flushed from, and subsequently replaced in, the shared pool. Auditing an object invalidates that object in the cache and causes it to be reloaded. Any changes to the audit options of base objects are not observed by views and procedures in the shared pool. Continuing with the above example, if auditing of SELECT statements is turned off for the EMP table, use of the EMP_DEPT view would no longer generate an audit record for the EMP table.

________________________________________

Focusing Statement, Privilege, and Object Auditing

ORACLE allows statement, privilege, and object auditing to be focused in two areas:

•	successful and unsuccessful executions of the audited SQL statement

•	BY SESSION and BY ACCESS auditing

In addition, statement and privilege auditing can be done for specific users or for all users in the database.

Auditing Successful and Unsuccessful Statement Executions

For statement, privilege, and object auditing, ORACLE allows the selective auditing of successful executions of statements, unsuccessful attempts to execute statements, or both. Therefore, you can monitor actions, even if the audited statements do not complete successfully.

An unsuccessful statement execution can be audited only if a valid SQL statement is issued but fails because of lack of proper authorization or it references a non-existent object; unsuccessful statement executions cannot be audited if an invalid SQL statement is issued. For example, an enabled privilege auditing option set to audit unsuccessful statement executions audits statements that use the target system privilege but have failed due to other reasons (e.g., CREATE TABLE is set, but a CREATE TABLE statement fails due to lack of quota for the specified tablespace).

Using either form of the AUDIT command, you can include:

•	the WHENEVER SUCCESSFUL option, to audit only successful executions of the audited statement

•	the WHENEVER NOT SUCCESSFUL option, to audit only unsuccessful executions of the audited statement

•	neither of the previous options, to audit both successful and unsuccessful executions of the audited statement

•

Auditing BY SESSION versus BY ACCESS

Most auditing options can be set to indicate how audit records should be generated if the audited statement is issued multiple times in a single user session. These sections describe the distinction between the BY SESSION and BY ACCESS options of the AUDIT command.

 BY SESSION

BY SESSION inserts only one audit record in the audit trail, per user and object, per session that includes an audited action.

To demonstrate how the BY SESSION option allows the generation of audit records, consider the following two examples.

Example 1      Assume the following:

•	The SELECT TABLE statement auditing option is set BY SESSION.

•	JWARD connects to the database and issues five SELECT statements against the table named DEPT and then disconnects from the database.

•	SWILLIAMS connects to the database and issues three SELECT statements against the table EMP and then disconnects from the database.

In this case, the audit trail will contain two audit records for the eight SELECT statements (one for each session that issued a SELECT statement).

Example 2      Alternatively, assume the following:

•	The SELECT TABLE statement auditing option is set BY SESSION.

•	JWARD connects to the database and issues five SELECT statements against the table named DEPT, three SELECT statements against the table EMP, and then disconnects from the database.

In this case, the audit trail will contain two records (one for each object against which the user issued a SELECT statement).

The BY SESSION option can be used when directing audit records to the operating system audit trail, but an audit record is generated and stored each time an access is made. Therefore, BY SESSION is equivalent to BY ACCESS in this auditing configuration.

Note: A session is the time between when a user connects to, and disconnects from, an ORACLE database.

 BY ACCESS

BY ACCESS inserts one audit record in the audit trail each time an audited statement is executed.

Example      Assume the following:

•	The SELECT TABLE statement auditing option is set BY ACCESS.

•	JWARD connects to the database and issues five SELECT statements against the table named DEPT and then disconnects from the database.

•	SWILLIAMS connects to the database and issues three SELECT statements against the table DEPT and then disconnects from the database.

The audit trail contains eight records for the eight SELECT statements.

 Defaults and Excluded Operations

The AUDIT command allows you to specify both BY SESSION and BY ACCESS; BY SESSION is the default. However, several audit options can only be set BY ACCESS, including:

•	all statement audit options that audit DDL statements

•	all privilege audit options that audit DDL statements

Auditing By User

Statement and privilege audit options can either be broad, and audit statements issued by any user, or focused, and audit statements issued by a specific list of users. Using this feature, statement and privilege audit options can be targeted at a select list of users, minimizing the number of audit records generated.


PART  VIII . DISTRIBUTED PROCESSING AND DISTRIBUTED DATABASES


CHAPTER 20. CLIENT-SERVER ARCHITECTURE

They also serve who only stand and wait.

John Milton:  Sonnet XV. On His Blindness

This chapter defines distributed processing, and how ORACLE and database applications work in a distributed processing environment. Information is contained for almost every type of ORACLE database system environment. Topics include:

•	the ORACLE client-server architecture

•	the definition of distributed processing

•	SQL*Net

________________________________________

The ORACLE Client-Server Architecture

In the ORACLE client-server architecture, the database application and database are separated into two parts: a front-end or client portion, and a back-end or server portion. The client executes the database application that accesses database information and interacts with a user through the keyboard, screen, and pointing device such as a mouse. The server executes the ORACLE software and handles the functions required for concurrent, shared data access to an ORACLE database.

Although the client application and ORACLE can be executed on the same computer, it may be more efficient and effective when the client portion(s) and server portion are executed by different computers connected via a network. The following sections discuss possible variants in the ORACLE client-server architecture.

Note: In a distributed database, one server (ORACLE) may need to access a database on another server. In this case, the server requesting the information is a client. Refer to Chapter 21 for more information about clients and servers in distributed databases.

Distributed Processing

Distributed processing is the use of more than one processor to divide the processing for an individual task. The following are examples of distributed processing in ORACLE database systems:

•	The client and server are located on different computers; these computers are connected via a network (see Figure 20 - 1, Part A).

•	A single computer has more than one processor and different processors separate the execution of the client application from ORACLE (see Figure 20 - 1, Part B).

Benefits of the ORACLE client-server architecture in a distributed processing environment include the following:

•	Client applications are not responsible for performing any data processing. Client applications can concentrate on requesting input from users, requesting desired data from the server, and then analyzing and presenting this data using the display capabilities of the client workstation or the terminal (for example, using graphics or spreadsheets).

•	Client applications can be designed with no dependence on the physical location of the data. If the data is moved or distributed to other database servers, the application continues to function with little or no modification.

•	ORACLE exploits the multitasking and shared-memory facilities of its underlying operating system. As a result, it delivers the highest possible degree of concurrency, data integrity, and performance to its client applications.

•	Client workstations or terminals can be optimized for the presentation of data (for example, by providing graphics and mouse support) and the server can be optimized for the processing and storage of data (for example, by having large amounts of memory and disk space).

•	If necessary, ORACLE can be scaled. As your system grows, you can add multiple servers to distribute the database processing load throughout the network (horizontally scaled). Alternatively, you can replace ORACLE on a less powerful computer, such as a microcomputer, with ORACLE running on a minicomputer or mainframe, to take advantage of a larger system's performance (vertically scaled). In either case, all data and applications are maintained with little or no modification, since ORACLE is portable between systems.

•	In networked environments, inexpensive, low-end client workstations can be used to effectively access the remote data of the server.

•	In networked environments, client applications submit database requests to the server using SQL statements. Once received, the SQL statement is processed by the server and the results are returned to the client application. Network traffic is kept to a minimum because only the requests and the results are shipped over the network.

________________________________________

SQL*Net

SQL*Net is the Oracle network interface that allows Oracle tools running on network workstations and servers to access, modify, share, and store data on other servers. SQL*Net is considered part of the program interface in network communications (see Chapter 9).

SQL*Net uses the communication protocols or application programmatic interfaces (APIs) supported by a wide range of networks to provide a distributed database and distributed processing for ORACLE. A communications protocol is a set of standards, implemented in software, that govern the transmission of data across a network. An API is a set of subroutines that provide, in the case of networks, a means to establish remote process-to-process communication via a communication protocol.

Communication protocols define the way that data is transmitted and received on a network. In a networked environment, an ORACLE server communicates with client workstations and other ORACLE servers using SQL*Net. SQL*Net supports communications on all major network protocols, ranging from those supported by PC LANs to those used by the largest mainframe computer systems.

Without the use of SQL*Net, an application developer has to manually code all communications in an application that operates in a networked distributed processing environment. If the network hardware, topology, or protocol changes, the application has to be modified accordingly.

However, by using SQL*Net, the application developer does not have to be concerned with supporting network communications in a database application. If the underlying protocol changes, the database administrator makes some minor changes, while the application requires no modifications and will continue to function.

How SQL*Net Works

SQL*Net drivers provide an interface between ORACLE processes running on the database server and the user processes of Oracle tools running on other computers of the network.

The SQL*Net drivers take SQL statements from the interface of the Oracle tools and package them for transmission to ORACLE via one of the supported industry-standard higher level protocols or programmatic interfaces. The drivers also take replies from ORACLE and package them for transmission to the tools via the same higher-level communications mechanism. This is all done independently of the network operating system.

Depending on the operating system that executes ORACLE, the SQL*Net software of the database server may include the driver software and start an additional ORACLE background process; see your installation or user's guide for details.

For additional information on SQL*Net, refer to the appropriate SQL*Net documentation.


CHAPTER 21. DISTRIBUTED DATABASES

Divide and rule.

Machiavelli

This chapter describes what a distributed database is, the benefits of distributed database systems, and the ORACLE distributed database architecture. Topics include:

•	an introduction to distributed databases

•	ORACLE's distributed database architecture

•	object naming in a distributed database

•	accessing data in non-ORACLE databases

Note: The information in this chapter applies only for those systems using ORACLE with the distributed option.

If you are using Trusted ORACLE, see the Trusted ORACLE7 Server Administrator's Guide.

________________________________________

An Introduction to Distributed Databases

A distributed database appears to a user as a single logical database, but is in fact a set of databases stored on multiple computers. The data on several computers can be simultaneously accessed and modified using a network. Each database is controlled by its local DBMS. Each database server in the distributed database cooperates to maintain the consistency of the global database. Figure 21 - 1 illustrates a representative distributed database system.

The following sections outline some of the general terminology and concepts used when discussing distributed database systems.

Clients, Servers, and Nodes

A database server is the software managing a database, and a client is an application that requests information from a server. Each computer in a system is a node. A node in a distributed database system can be a client, server, or both. For example, in Figure 21 - 1, the computer that manages the HQ database is acting as a database server when a statement is issued against local data (e.g., the second statement in each transaction issues a query against the local DEPT table), and is acting as a client when a statement is issued against remote data (e.g., the first statement in each transaction is issued against the remote table EMP in the SALES database).

ORACLE supports heterogenous client/server environments where client and server use different character sets. The character set used by the client is defined by the value of the NLS_LANG parameter for the client session. The character set used by the server is its database character set. Data conversion is done automatically between these character sets if they are different. For more information about National Language Support features, refer to Appendix A.

 Direct and Indirect Connections

A client can connect directly or indirectly to a database server. In Figure 21 - 1, when the client application issues the first and third statements for each transaction, the client is directly connected to the intermediate HQ database and indirectly connected to the SALES database that contains the remote data.

Site Autonomy

Site autonomy means that each server participating in a distributed database is administered separately and independently from the other databases, as though each database was a non-networked database. Each database is maintained (for security and backup operations) independently of the other databases. Although each database can work with others, they are distinct, separate repositories of data that are administered individually. Some of the benefits of site autonomy are as follows:

•	Nodes of the system can mirror the logical organization of companies or cooperating organizations that need to maintain an "arms length" relationship.

•	Local data is controlled by the local database administrator. Therefore, each database administrator's domain of responsibility is smaller and more manageable.

•	Independent failures are less likely to disrupt other nodes of the distributed database. The global database is partially available as long as one database and the network are available; no single database failure need halt all global operations or be a performance bottleneck.

•	Failure recovery is usually performed on an individual node basis.

•	A data dictionary exists for each local database.

•	Nodes can upgrade software independently.

Schema Objects and Naming in a Distributed Database

A schema object (e.g., a table) is accessible from all nodes that form a distributed database. Therefore, just as a non-distributed local DBMS must provide the mechanisms to distinctly reference an object within the local database, a distributed DBMS architecture must provide a naming scheme so that objects throughout a distributed database can be uniquely identified and referenced in applications.

To resolve references to objects (a process called name resolution) within a single database, the DBMS usually forms object names using a hierarchical approach. For example, within a single database, a DBMS guarantees that each schema has a unique name, and that within a schema, each object has a unique name. Because uniqueness is enforced at each level of the hierarchical structure, an object's local name is guaranteed to be unique within the database and references to the object's local name can be easily resolved.

Distributed DBMSs simply extend the hierarchical naming model by enforcing unique database names within a network. As a result, an object's global object name is guaranteed to be unique within the distributed database and references to the object's global object name can be resolved among the nodes of the system.

Statements and Transactions in a Distributed Database

The following sections introduce the terminology used when discussing statements and transactions in a distributed database environment.

 Remote and Distributed Statements

A remote query is a query that selects information from one or more remote tables, all of which reside at the same remote node.

A remote update is an update that modifies data in one or more tables, all of which are located at the same remote node.

Note: A remote update may include a subquery that retrieves data from one or more remote nodes, but because the update is performed at only a single remote node, the statement is classified as a remote update.

A distributed query retrieves information from two or more nodes.

A distributed update modifies data on two or more nodes. A distributed update is possible using a program unit, such as a procedure or trigger, that includes two or more remote updates that access data on different nodes. Statements in the program unit are sent to the remote nodes, and the execution of the program succeeds or fails as a unit.

 Remote and Distributed Transactions

A remote transaction is a transaction that contains one or more remote statements, all of which reference the same remote node. A distributed transaction is any transaction that includes one or more statements that update data on two or more distinct nodes of a distributed database. If all statements of a transaction reference only a single remote node, the transaction is remote, not distributed.

Two-Phase Commit Mechanism

A DBMS must guarantee that all statements in a transaction, distributed or non-distributed, are either committed or rolled back as a unit, so that if the transaction is designed properly, the data in the logical database can be kept consistent. One transaction should see another transaction as committed, or not, at all nodes; this should be true for transactions that include any type of operation, including queries, updates, or remote procedure calls.

The general mechanisms of transaction control in a non-distributed database are discussed in Chapter 12. In a distributed database, transaction control must be coordinated over a network and data consistency must be maintained, even if a network or system failure occurs.

A two-phase commit mechanism guarantees that all database servers participating in a distributed transaction either all commit or all roll back the statements in the transaction. A two-phase commit mechanism also protects implicit DML operations performed by integrity constraints, remote procedure calls, and triggers. Two-phase commit is described in Chapter 1.

Transparency in a Distributed Database System

The functionality of a distributed database system must be provided in such a manner that the complexities of the distributed database are transparent to both the database users and the database administrators.

For example, a distributed database system should provide methods to hide the physical location of objects throughout the system from applications and users. Location transparency exists if a user can refer to the same table the same way, regardless of the node to which the user connects. Location transparency is beneficial for the following reasons:

•	Access to remote data is simplified, because the database users do not need to know the location of objects.

•	Objects can be moved with no impact on end-users or database applications.

A distributed database system should also provide query, update, and transaction transparency. For example, standard SQL commands, such as SELECT, INSERT, UPDATE and DELETE, should allow users to access remote data without the requirement for any programming. Transaction transparency occurs when the DBMS provides the functionality described below using standard SQL COMMIT, SAVEPOINT, and ROLLBACK commands, without the requirement for complex programming or other special operations to provide distributed transaction control:

•	The statements in a single transaction can reference any number of local or remote tables.

•	The DBMS guarantees that all nodes involved in a distributed transaction take the same action: they either all commit or all roll back, based upon the statement that terminates the transaction.

•	If a network or system failure occurs during the commit of a distributed transaction, the transaction is automatically and transparently resolved globally; that is, all nodes either commit or roll back, when the network or system is restored.

A distributed DBMS architecture should also provide facilities to transparently replicate data among the nodes of the system. Maintaining copies of a table across the databases in a distributed database is often desired so that:

•	Tables that have high-query and low-update activity can be accessed faster by local user sessions because no network communication is necessary.

•	If a database that contains a critical table experiences a prolonged failure, replicates of the table in other databases can still be accessed.

A DBMS that manages a distributed database should provide table replication such that it is transparent to users making changes to replicated tables.

Finally, the functional transparencies explained above are not sufficient alone; the distributed database must also perform with acceptable speed.

________________________________________

ORACLE's Distributed Database Architecture

ORACLE's distributed database architecture allows autonomous databases separated by wide area networks to be integrated as a single logical distributed database. In such configurations, each database maintains its independence regarding operation and administration, but gains the advantages of being able to access and share data with other databases in the distributed system. The remainder of this chapter describes ORACLE's distributed database architecture.

Schema Object Names and Data Access

ORACLE allows schema objects (e.g., tables, views, procedures) throughout a distributed database to be referenced in SQL statements using global object names. In ORACLE, a schema object's global name is comprised of the name of the schema that contains the object, the object name, followed by an "at" sign (@), and a database name. For example, the following query selects information from the table named SCOTT.EMP in the SALES database:

SELECT * FROM scott.emp@sales.division3.acme.com;

ORACLE does not check nor enforce unique global object names when an object is created, nor does it store complete global object names in the distributed data dictionaries. However, ORACLE does guarantee that an object name is unique within its own local database . Additionally, a distributed database system can be configured so that each database within the system has a unique database name, thereby providing "effective" global object names.

Refer to the section "Naming and Object Resolution in a Distributed Database" on page 21 - 15 for more information about object names and object resolution within an ORACLE distributed database.

Transparency in a Distributed Database

ORACLE's distributed database architecture is relatively transparent to users and administrators of the system, yet flexible enough to provide full control of the system.

 Location Transparency

The ORACLE database administrator can provide complete location transparency to end-users and applications. Views, synonyms, and procedures can be used to provide location transparency in an ORACLE distributed database system, as described in the following sections.

Views and Location Transparency      Local views can be used to provide location transparency for local and remote tables in a distributed database system. For example, assume that table EMP is stored in a local database. Another table, DEPT, is stored in a remote database. To make the location of, and relationship between, these tables transparent to users of the system, a view named COMPANY can be created in the local database that joins the data of the local and remote servers:

CREATE VIEW company AS

SELECT empno, ename, dname

FROM scott.emp a, jward.dept@hq.acme.com b

WHERE a.deptno = b.deptno;

When users access this view, they do not know, or need to know, where the data is physically stored, or if data from more than one table is being accessed; thus, it is easier for them to get the information:

SELECT * FROM company;

Figure 21 - 2 illustrates this example of location transparency.

Synonyms and Location Transparency       Synonyms are very useful in both distributed and non-distributed environments because they hide the identity of the underlying object, including its location in a distributed system. If the underlying object must be renamed or be moved, only the synonym needs to be redefined; applications based on the synonym continue to function without modification. Synonyms can also simplify SQL statements for users in a distributed database system.

For example, assume that in every database of a distributed database, a public synonym is defined for the SCOTT.EMP table stored in the HQ database:

CREATE PUBLIC SYNONYM emp	FOR scott.emp@hq.acme.com;

An employee management application can be designed without regard to where the application is going to be used because the location of the EMP table is hidden by the public synonyms; SQL statements in the application access the table SCOTT.EMP@HQ.ACME.COM by referencing the public synonym EMP. Furthermore, if the EMP table is moved from the HQ database to the HR database, only the public synonyms need to be changed on the nodes of the system; the employee management application continues to function properly on all nodes.

Procedures and Location Transparency      Location transparency is provided by PL/SQL program units that contain SQL statements that reference remote data. For example, consider the procedure created by the following statement:

CREATE PROCEDURE fire_emp (enum NUMBER) AS

BEGIN

DELETE FROM jward.emp@hq.acme.com

WHERE empno = enum;

END;

When a user or application calls the FIRE_EMP procedure, it is not apparent that a remote table is being modified.

A second layer of location transparency is possible if the statements in a procedure indirectly reference remote data using local procedures, views, or synonyms. For example, the following statement defines a local synonym:

CREATE SYNONYM emp FOR jward.emp@hq.acme.com;

Consequently, the FIRE_EMP procedure can be defined with the following statement:

CREATE PROCEDURE fire_emp (enum NUMBER) AS

BEGIN

DELETE FROM emp WHERE empno = enum;

END;

If the table JWARD.EMP@HQ is renamed or moved, only the local synonym that references the table needs to be modified; all procedures and applications that call the procedure require no modification.

 Query and Update Transparency

ORACLE allows the following standard DML statements to reference remote data: SELECT (queries), INSERT, UPDATE, DELETE, SELECT...FOR UPDATE, and LOCK TABLE.

A query, including joins, aggregates, subqueries, and SELECT ... FOR UPDATE, can reference any number of local and remote tables and views. For example, the following query joins information from two remote tables:

SELECT empno, ename, dname

  FROM scott.emp@sales.acme.com a,

jward.dept@hq.acme.com b

  WHERE a.deptno = b.deptno;

UPDATE, INSERT, DELETE, and LOCK TABLE statements can reference both local and remote tables. No programming is necessary to update remote data. For example, the following statement inserts new rows into the remote table SCOTT.EMP in the SALES database by selecting rows from the JWARD.EMP table in the local database:

INSERT INTO scott.emp@sales.division3.acme.com

  SELECT * FROM jward.emp;

Restrictions      Within a single SQL statement, all referenced LONG and LONG RAW columns, sequences, updated tables, and locked tables must be located at the same node. ORACLE does not allow remote DDL statements (e.g., CREATE, ALTER, and DROP). Also, the LIST CHAINED ROWS clause of an ANALYZE statement cannot reference remote tables.

 Transaction Transparency and Two-Phase Commit

All transactions in ORACLE, single-site or distributed, are terminated with a COMMIT or ROLLBACK statement. SAVEPOINT and ROLLBACK TO SAVEPOINT statements are also supported by ORACLE distributed architecture.

If a transaction is a single-site transaction, the transaction simply commits or rolls back. If a transaction is distributed, ORACLE's transparent two-phase commit mechanism is automatically started once a distributed transaction is terminated with a simple COMMIT statement. ORACLE's two-phase commit mechanism automatically guarantees that the nodes referenced in a distributed transaction either all commit or all roll back the transaction, even if a network failure occurs while the transaction is being committed. For complete information about ORACLE's two-phase commit mechanism, see Chapter 22.

 Failure Resolution Transparency and the RECO Background Process

Network or computer hardware failure is always possible. ORACLE's distributed database architecture guarantees that if a network or system failure occurs during the commit of a distributed transaction, the transaction is automatically and transparently resolved globally; that is, all nodes either commit or roll back) when the network or system is restored.

The RECO background process automatically recovers pending or in-doubt distributed transactions (transactions not committed or rolled back when a network failure occurs during a two-phase commit process). When a network failure is corrected, the RECO processes of the involved database servers automatically resolve the outcome of any pending distributed transaction; no work is required of the database administrator to resolve pending transactions. For complete information about failure resolution of in-doubt distributed transactions in an ORACLE distributed database, see Chapter 22.

 Replication Transparency

ORACLE provides two mechanisms for accomplishing transparent table replication in a distributed database. The table snapshot feature built into ORACLE provides asynchronous table replication (changes to an updatable master table are replicated on the read-only snapshot tables, only at timed intervals). Alternatively, triggers can be used to implement synchronous table replication (changes to any table are applied to all replicated copies immediately). In either case, table replication is transparent to users making changes to replicated tables.

 Performance Transparency

All of ORACLE's underlying performance optimizations are transparently utilized with the statements and transactions in a distributed database, including shared SQL, cost-based SQL statement optimization, ORACLE's array interface (for fetch and insert), and PL/SQL (for reduced network traffic).

Statement Execution in a Distributed Database

SQL statement execution of remote and distributed statements is essentially the same in a distributed database as it is for a non-distributed database (see Chapter 11 for more information). However, depending on the type of statement issued, the location of statement execution can vary.

 Remote Queries and Updates

All remote queries and remote updates are sent to the remote node for statement execution. The remote node executes the statement and returns any results back to the local node, which returns them to the user or application.

 Distributed Queries and Distributed Updates

A distributed query is decomposed by the local ORACLE into a corresponding number of remote queries, which are sent to the remote nodes for execution. Implicitly, an ALTER SESSION statement is issued when a connection is established so that the remote session has the same characteristics as the local session (e.g., NLS language, NLS sort sequence). The remote nodes execute the queries and send results back to the local node. The local node then performs any necessary post-processing and returns results to the user or application.

The statements in a procedure or trigger that constitute a distributed update are individually sent to the correct remote node for statement execution. Results are returned to the local node, and then returned to the calling user or application.

 Values for Environmentally Dependent SQL Functions

In a distributed database system, environmentally dependent SQL functions such as SYSDATE, USER, UID, and USERENV are always evaluated with respect to the local node, regardless of where a statement (or portion of a statement) is executed. In addition, the USERENV function is supported only for queries.

 Shared SQL for Remote and Distributed Statements

The mechanics of a remote or distributed statement using shared SQL are essentially the same as those of a local statement; the SQL text must match, the referenced objects must match, and any bind types of any bind variables must be the same. If available, shared SQL areas can be used for both the local and remote handling of any statement (or decomposed query). See Chapter 11 for more information about shared SQL.

 Optimization of SQL Statements in a Distributed Database

The optimization approach available for SQL statements can vary depending on the type and complexity of the statement; see Chapter 13  for detailed information.

SQL*Net and Network Independence

When data is required from remote databases, a local database server communicates with the remote database using the network, network communications software, and ORACLE's SQL*Net. Just as SQL*Net is the interface used to connect clients and servers that operate on different computers of a network, SQL*Net also connects database servers across networks to facilitate distributed transactions. For more information about SQL*Net and its features, see "SQL*Net" on page 20 - 5.

SQL*Net and ORACLE's distributed database system run on most networks; the particular type of network protocol, brand, or topology does not matter. In fact, it is entirely feasible for a distributed database system to work over several different types of communication networks simultaneously.

Heterogeneous Distributed Database Systems

The ORACLE distributed database architecture allows the mix of different versions of ORACLE along with database products from other companies to create a heterogeneous distributed database system.

 The Mechanics of a Heterogeneous Distributed Database

In a distributed database, any application directly connected to an ORACLE database can issue a SQL statement that accesses remote data in the following ways:

•	Data in another ORACLE database is available, no matter what version. Each ORACLE database is connected by a network and uses SQL*Net to maintain communication.

•	Data in a non-ORACLE database (such as an IBM DB2 database) is available, assuming the non-ORACLE database is supported by ORACLE's gateway architecture, SQL*Connect. The ORACLE and non-ORACLE databases can be connected by a network and use SQL*Net to maintain communication. See the appropriate SQL*Connect documentation for more information about this product.

Figure 21 - 3 illustrates a heterogeneous distributed database system encompassing different versions of ORACLE and non-ORACLE databases.

When connections from an ORACLE node to a remote node (ORACLE or non-ORACLE) are initially established, the connecting ORACLE node records the capabilities of each remote system and associated gateways. SQL statement execution proceeds, as described in the section "Statements and Transactions in a Distributed Database" on page 21 - 4. However, in heterogenous distributed systems, SQL statements issued from an ORACLE database to a remote database server are limited by the capabilities of the remote database server and associated gateway. For example, if a remote or distributed query includes an ORACLE extended SQL function (e.g., outer join), the function may be performed by the local ORACLE database. Extended SQL functions in remote updates (e.g., outer join in a subquery) are not supported by all gateways; see your specific SQL*Connect documentation for more information on the capabilities of your system.

 Connecting Different Versions of ORACLE

In administering a distributed database system, administrators must be aware of the version of Oracle software running at networked nodes:

•	Applications using database links originating from Version 5 databases can query Version 5 or 6 databases, as well as ORACLE7 databases. No remote updates from a Version 5 database are allowed.

•	Applications using database links originating from Version 6 databases can query Version 5 and Version 6 databases, as well as ORACLE7 databases. When querying a Version 5 database, features unique to Version 6 can only be used after the Version 5 data is retrieved (e.g., unique Version 6 SQL functions applied after data is retrieved from a Version 5 database). When querying an ORACLE7 database, Version 6 can fetch both fixed and variable-length strings; however, for fixed-length strings, Version 6 uses ORACLE comparison semantics, but portions of the query evaluated in ORACLE7 uses blank-padded comparison semantics. No remote updates are allowed from a Version 6 database.

•	Applications using database links originating from ORACLE7 databases can query any number of Version 5 or 6 databases per statement. Applications using database links originating from ORACLE7 databases can update a single Version 5 or 6 database per statement, but no other nodes can be updated in the same single-site transaction. In both queries and updates, features unique to ORACLE7 can only be used with Version 5 and Version 6 databases after the Version 5 or Version 6 data is retrieved (similar to the condition in the previous item). If a distributed transaction updates data at only a single node, the transaction is committed without a two-phase commit because a coordinated commit is not required. Of course, ORACLE7 databases can update any number of ORACLE7 databases within the same transaction, which is committed using the two-phase commit mechanism.

________________________________________

Naming and Object Resolution In a Distributed Database

These sections explain ORACLE's object naming scheme and how references to objects are resolved within a distributed database.

Local Object Names

In a distributed or non-distributed environment, ORACLE guarantees that each database has a unique set of schemas and that within each schema, an object name is unique within its name space. Therefore, each schema object's name is guaranteed to be unique within the context of any given ORACLE database and the local ORACLE can easily resolve any references to objects within the local database. Each local data dictionary stores only the names of local objects (and synonyms), not remote object names.

Global Database Names and Global Object Names

In a distributed database system, each database should have a unique global name. Global database names identify each database in the system. A global database name is comprised of two components: the database name of eight characters or less (e.g., SALES) and the network domain that contains the database (see the section below). The network domain component of global database names must follow standard Internet conventions. Levels in domain names are separated by dots and the order of domain names is from leaf to root, left to right.

For example, Figure 21 - 4 illustrates a representative hierarchical arrangement of databases throughout a network and how a global database name is formed.

Note: Do not confuse ORACLE global database names with SQL*Net communities. A SQL*Net community is a group of machines running the same network protocol. These communities can have names, and if so, have domains as well. However, SQL*Net community names and domains are unrelated to ORACLE global database names and domains. See your SQL*Net documentation for more information.

Notice that throughout the network there are several databases with the same name (such as, SALES). However, also notice that each database has a unique global database name because of location within the network domain structure. From left to right, global database names are as follows:

hq.division1.acme_tools.com

finance.division2.acme_tools.com

sales.division2.acme_tools.com

mftg.division3.acme_tools.com

sales.japan.asia.acme_auto.com

hq.us.americas.acme_auto.com

sales.us.americas.acme_auto.com

sales.mexico.americas.acme_auto.com

sales.uk.europe.acme_auto.com

sales.germany.europe.acme_auto.com

Because each database has a unique global database name, each database, and the objects each database contains, can be uniquely identified using the object's global object name. For example, notice that each HQ database contains a table named EMP. However, each EMP table can be uniquely identified using its global object name. In Figure 21 - 4, the global names for the two EMP tables are:

human_resources.emp@hq.us.americas.acme_auto.com

human_resources.emp@hq.division1.acme_tools.com

Each local data dictionary in an ORACLE distributed database stores only object names and names of containing schemas, not complete global object names. However, because each database can have a unique name within a network and because each object name is guaranteed to be unique within the scope of a single database, each object in an ORACLE distributed database has a unique global object name.

 Network Domains and Network Domain Services

Figure 21 - 4 illustrates a fictional network domain structure that follows standard Internet conventions. Network domains are similar to file directories used by many operating systems (such as UNIX); however, unlike file systems, network domains may or may not correspond to any physical arrangement of databases and other structures in a network; they might simply be name spaces. The availability of a network domain service and its functionality dictates what is possible.

For example, if a network domain service is available, it is typically used to create and drop network domains, control access to network domains, create and drop structures (such as databases) within the network structure, and enforce the unique naming of structures within the network. However, if a network domain service is not available, there is typically no enforced control over network domains or structure names; control is left up to the administrators of the network.

ORACLE's architecture is designed to use network domain services such as X.500. As such services become available from Oracle Corporation and other vendors, global database naming and name resolution becomes automatic. However, when a network domain service is not available:

•	Global database naming is a manual job; see your installation or user's guide for more information.

•	Database links are used to facilitate remote connections and allow global name resolution, as discussed in the following section.

Database Links

Note: The following sections discuss how database links are used in a distributed database system when a network domain service is not used. For more information about using database links when a network domain service is available, see your installation or user's guide.

To facilitate connections between the individual databases of a distributed database, ORACLE uses database links. A database link defines a "path" to a remote database.

Database links are essentially transparent to users of a distributed database because the name of a database link is the same as the global name of the database to which the link points. For example, the following statement creates a database link in the local database. The database link named SALES.DIVISION3.ACME.COM describes a path to a remote database of the same name:

CREATE PUBLIC DATABASE LINK sales.division3.acme.com ...

At this point, any application or user connected to the local database can access data in the SALES database by using global object names when referencing objects in the SALES database; the SALES database link is implicitly used to facilitate the connection to the SALES database. For example, consider the following remote query that references the remote table SCOTT.EMP in the SALES database:

SELECT * FROM scott.emp@sales.division3.acme.com;

When a user session connects to an instance, the values of NLS parameters used by the instance for that user session are defined by the value of the NLS_LANG parameter for that session. This applies both to direct and indirect connections. If the values of the NLS parameters are changed during a session by an ALTER SESSION statement, the changes are propagated automatically to all instances that the user session is connected to, either directly or indirectly. For more information on National Language Support features, see Appendix A .

 When Database Links Are Used

When a SQL statement includes a reference to a global object name, ORACLE attempts to locate a database link that matches the database name specified in the global object name; a global object name is indicated by an object name that is followed by an "at" sign (@) and a database name. If a matching database link is found, the local ORACLE uses the database link in attempting to establish a connection to the specified remote database and complete the execution of the SQL statement. If a database link that corresponds to the specified database is not found, a remote connection cannot be established and the SQL statement cannot be executed.

A database link defines a path to a remote database. The two components of a path are a remote account and a database string. The following statement is the complete CREATE DATABASE LINK statement shown earlier. This example illustrates the creation of the SALES database link and the complete path that is specified for the link:

CREATE PUBLIC DATABASE LINK sales.division3.acme.com

CONNECT TO guest IDENTIFIED BY password

USING 'dbstring';

When a database link is created, a complete path (both the remote account and the database string), a partial path (just the remote account or just the database string), or no path can be specified. See "Name Resolution in a Distributed Database" on page 21 - 25 for a complete explanation about how several database links can be used together to form a complete path to a remote database.

When a SQL statement references a global object name in the SALES database, the local ORACLE finds the corresponding SALES database link in the local database and attempts to establish a session in the remote database for the user GUEST/PASSWORD. The database string specified in the SALES database link definition (which is operating system and network dependent) is used to facilitate the remote connection.

Typically, it is the responsibility of each database administrator or application administrator to create the necessary database links to databases throughout the network; database links are merely an implementation detail that should be completely transparent to applications and end-users of a database. It should appear to applications and users that a remote table is accessed simply by specifying the table's global object name, not by referencing an available database link. In fact, administrators should create location transparency for remote objects using views, synonyms, or procedures so that applications do not explicitly reference remote data; then, if the remote object is moved, only the synonym needs to be altered, not all applications.

 Types of Database Links

Several types of database links can be used to resolve users' references to global object names.

private database link	Created on behalf of a specific user. A private database link can be used only when the owner of the link specifies a global object name in a SQL statement or in the definition of the owner's views or procedures.

public database link	Created for the special user group PUBLIC. A public database link can be used when any user in the associated database specifies a global object name in a SQL statement or object definition.

network database link	Created and managed by a network domain service. A network database link can be used when any user of any database in the network specifies a global object name in a SQL statement or object definition.

Note: Because a network domain service is not currently available to ORACLE, network database links are not available. However, you should consider network database links in the following discussion.

Each type of database link has advantages and disadvantages when compared to the other types. For example, tighter security can be maintained with private database links as compared to public and network database links. The use of a private database link is at the discretion of the owner of the link; the owner of a private database link can use the link in his/her own SQL statements or selectively allow other users to use the private link by creating a view, procedure, or synonym that references the link in its definition. Alternatively, there is no way to selectively restrict use of a public database link (for example, any local user can connect to the remote database specified by the public database link).

Network Connections Established for Database Links

When a global object name is referenced, the local ORACLE searches for matching database links that correspond to the specified database name. If a matching link is found, the local ORACLE attempts to establish a network connection to the remote database so that the remote data can be accessed.

The characteristics of a connection (such as, network protocol) are indicated by the database string in the definition of the database link being used to facilitate a connection. The specification of a database string is operating system and network dependent; see your installation or user's guide for details.

When a database link is created using the SQL command CREATE DATABASE LINK, the creator can omit a database string and instead rely on a database string specified in another matching database link.

 User Names Used for Remote Sessions Created for Database Links

When a global object name is referenced, the local ORACLE searches for matching database links that correspond to the specified database name. If one or more links are found, the local ORACLE attempts to create a session in the remote database using the ORACLE username and password indicated in the database links being used.

A database link can be defined so that when it is used, the user accessing remote data connects to the remote database using the local username and password or an explicitly specified username and password. In other words, a database link can be defined so that all users of the link connect to the remote database using either a central, explicitly specified remote account or implied individual remote accounts. Figure 21 - 5 illustrates the use of central vs. individual remote accounts for database links.

Notice that one of the primary advantages of using a central account for a database link is that privileges and/or roles only need to be granted once, to the central user. However, the concerns of using a central account regarding system security include:

•	The central remote account might have more privileges than any one user of a public database link needs. Therefore, users may be able to access more remote data than they require.

•	A public database link using a central remote account allows any user of the local database to access the remote database.

Alternatively, by using individual remote accounts:

•	The remote accounts can be tailored to an individual's application requirements, avoiding the tendency to make grants too liberal. However, the remote security administrator must create a user for each remote user requiring access and grant appropriate privileges (e.g., CREATE SESSION ) and roles to these ORACLE accounts.

•	There is less security exposure because the remote username and password are not stored in the definition of a private database link and there is no single entry point for many remote users.

•	Each user can have the same username and password on every database in the distributed system. However, there is more work to administer each local database (more user accounts to set up and maintain).

•	There must be more coordination between the administrators of the distributed databases. For example, the local and remote database administrators must make sure that each username and password combination is the same in each database.

When a database link is created using the SQL command CREATE DATABASE LINK, the creator has the option of explicitly specifying a remote account to use with the database link, or omitting any such specification, thereby implying that the local username/password is to be used with the database link. See the following section for more information on how database link paths are built.

Use of the Operating System     for User Authentication   The support of operating system names and authentication for the remote account used for a database link is operating system dependent; see your installation or user's guide for details.

Connection Qualifiers

In some situations, you may want to have several database links of the same type (e.g., public) that point to the same remote database, yet establish connections to the remote database using different communication pathways. For example, if a remote database is using the ORACLE Parallel Server, you might want to define several public database links at your local node so that connections can be established to specific instances of the remote database.

To facilitate such functionality, ORACLE allows you to create a database link with an optional connection qualifier in the database link name. When creating a database link, a connection qualifier is specified as the trailing portion of the database link name, separated by an at sign ("@"). For example, assume that a remote database HQ.ACME.COM is managed by the ORACLE Parallel Server. The HQ database has two instances, named HQ_1 and HQ_2. The local database can contain the following public database links to define pathways to the remote instances of the HQ database:

CREATE PUBLIC DATABASE LINK hq.acme.com@hq_1

USING 'string_to_hq_1';

CREATE PUBLIC DATABASE LINK hq.acme.com@hq_2

USING 'string_to_hq_2';

CREATE PUBLIC DATABASE LINK hq.acme.com

USING 'string_to_hq';

Notice in the above examples that a connection qualifier is simply an extension to a database link name. The text of the connection qualifier does not necessarily indicate how a connection is to be established; this information is specified in the database string of the USING clause. Also notice that in the third example, a connection qualifier is not specified. In this case, just as when a connection qualifier is specified, the instance is determined by the USING string.

To use a connection qualifier to specify a particular instance, include the qualifier at the end of the global object name:

SELECT * FROM scott.emp@hq.acme.com@hq_1;

Name Resolution in a Distributed Database

A SQL statement can access a remote object by specifying the object's global object name. In the previous example, the global object name is SCOTT.EMP@HQ.ACME.COM. The connection qualifier is not part of the global object name. The schema, SCOTT, and network domain, ACME.COM, are optional. See your ORACLE7 Server SQL Language Reference Manual for more detailed information.

To resolve a reference to a global object name, ORACLE uses the following steps:

1..	Search for database links that match the specified database.

2..	Search for the specified object in the remote database.

 Resolving Database Names to Database Links

Whenever a SQL statement includes a reference to a global object name, ORACLE searches for a database link with a name that matches the database name specified in the global object name. ORACLE does this in order to determine the path to the specified remote database.

ORACLE always searches for matching database links in the following order:

1..	Private database links in the schema of the user who issued the SQL statement.

2..	Public database links in the local database.

3..	Network database links (only if a network domain service and network database links are available).

If a SQL statement specifies a complete global database name; that is, both the database and network domain components are specified, ORACLE searches for private, public, and network database links that match only the explicitly specified global database name. If any portion of the network domain is specified, ORACLE assumes that a complete global database name is specified. However, if a SQL statement specifies a partial global database name; that is, only the database component is specified, ORACLE appends the local database's network domain component to the database name to form a complete global database name. Then ORACLE searches for private, public, and network database links that match only the constructed global database name. If a matching database link is not found, ORACLE returns an error and the SQL statement cannot execute.

Optimization      If a global object name references an object in the local database and a connection qualifier is not specified, ORACLE automatically detects that the object is local and does not search for, or use, database links to resolve the object reference.

Note: See "Views, Synonyms, Procedures, and Global Name Resolution," on page 21 - 30 for information on how ORACLE expands database names in the SQL statements that define these objects.

ORACLE expands a global object reference, whether or not a connection qualifier is specified. Furthermore, if a connection qualifier is specified, only database links that match, including the connection qualifier, are used to resolve the object reference.

ORACLE does not necessarily stop searching for matching database links when a first match is found. ORACLE must search for matching private, public, and network database links until a complete path to the remote database (both a remote account and database string) is determined. The first match determines the remote username/password to use; the local username/password is implied if the definition of this database link does not explicitly specify a remote username/password. If the first match does not specify a database string, the search continues until a link that specifies a database string is found. If matching database links are found and a database string is never identified, ORACLE returns an error.

Once a complete path is determined, ORACLE creates a remote session on behalf of the local user that issued the SQL statement, assuming an identical connection is not already open on behalf of the same local session.

 Resolving Object Names

Once the local ORACLE connects to the specified remote database on behalf of the local user that issued the SQL statement, object resolution continues as if the remote user had issued the associated SQL statement. That is, if a schema is explicitly specified, object resolution proceeds in the specified schema; if a schema is omitted, object resolution proceeds in the connected remote user's schema (including synonyms) and if the object is not found, public objects of the remote database are then checked.

If an object is not resolved, the established remote session remains but the SQL statement cannot execute.

 Examples of Name Resolution

The following are examples of global object name resolution in a distributed database system. For all the following examples, assume that the remote database is named SALES.DIVISION3.ACME.COM, the local database is named HQ.DIVISION3.ACME.COM, and a network domain service (and therefore, network database links) are not available.

Example 1	This example illustrates how a complete global object name is resolved and the appropriate path to the remote database is determined using both a private and public database link.

For this example, assume that a remote table EMP is contained in the schema TSMITH.

Consider the following statements issued at the local database:

CREATE PUBLIC DATABASE LINK sales.division3.acme.com

CONNECT TO guest IDENTIFIED BY network

USING 'dbstring';

CONNECT jward/bronco;

CREATE DATABASE LINK sales.division3.acme.com

CONNECT TO tsmith IDENTIFIED BY radio;

UPDATE tsmith.emp@sales.division3.acme.com

SET deptno = 40

WHERE deptno = 10;

ORACLE notices that a complete global object name is referenced in JWARD'S UPDATE statement. Therefore, it begins searching in the local database for a database link with a matching name. ORACLE finds matching private database link in the schema JWARD. However, the private database link JWARD.SALES.DIVISION3.ACME.COM does not indicate a complete path to the remote SALES database, only a remote account. Therefore, ORACLE now searches for and finds a matching public database link. From this public database link, ORACLE takes the database string. Combined with the remote account taken from the matching private link, a complete path is determined and ORACLE proceeds to establish a connection to the remote SALES database as the user TSMITH/RADIO.

The remote ORACLE can now resolve the object reference to the EMP table. ORACLE searches in the specified schema, TSMITH, and finds the referenced EMP table. No further resolution is necessary; the remote ORACLE completes the execution of the statement, and returns the results to the local database.

Example 2	This example illustrates how a partial global object name is resolved and the appropriate path to the remote database is determined using both a private and public database link

For this example, assume that a remote table EMP is contained in the schema TSMITH and a remote public synonym named EMP points to the previously mentioned EMP table. Also assume the creation of the public database link in Example 1.

Consider the following statements issued at the local database:

CONNECT scott/tiger;

CREATE DATABASE LINK sales.division3.acme.com;

DELETE FROM emp@sales

WHERE empno = 4299;

ORACLE notices that a partial global object name is referenced in SCOTT's DELETE statement. First, the global object name is expanded to a complete global object name using the network domain of the local database, resulting in the following statement:

DELETE FROM emp@sales.division3.acme.com

WHERE empno = 4299;

Now, ORACLE begins searching in the local database for a database link with a matching name. ORACLE finds a matching private database link in the schema SCOTT. However, the private database link indicates no path at all. ORACLE uses the local username/password as the remote account portion of the path and then searches for and finds a matching public database link. ORACLE takes the database string from the public database link. At this point, a complete path is determined and ORACLE can connect to the remote database as SCOTT/TIGER.

Once connected to the remote database as SCOTT, the remote ORACLE resolves the reference to EMP. First, it searches for and does not find an object named EMP in the schema SCOTT. Next, the remote ORACLE searches for a public synonym named EMP and finds one. The remote ORACLE then completes statement execution and returns the results to the local ORACLE.

Views, Synonyms, Procedures and Global Name Resolution

A remote schema object can be referenced by its global object name in the definition of a view, synonym, or PL/SQL program unit (e.g., procedure, trigger). If a complete global object name is referenced in the definition of a view, synonym, or program unit, ORACLE stores the definition of the object as specified, without having to perform any expansion of the global object name being referenced. However, if a partial global object name (that is, only the database name and not the network domain) is referenced in the definition of a view, synonym, or program unit, ORACLE must expand the partial name using the network domain component of the local database's global database name. The following list explains when ORACLE completes the expansion of a partial global object name for views, synonyms, and program units:

•	When a view is created, partial global object names in the defining query are not expanded; the data dictionary stores the exact text of the defining query. Instead, ORACLE expands a partial global object name each time a statement that uses the view is parsed and placed in the shared pool.

•	When a synonym is created, partial global object names are expanded; the definition of the synonym stored in the data dictionary includes the expanded global object name.

•	Each time a program unit is compiled, partial global object names are expanded.

The above behavior should be considered when creating views, synonyms, and procedures that reference remote data using partial global object names. If the global database name of the containing database is changed (which should rarely happen), views and procedures may try to reference a different database than they did before the global database name change; alternatively, synonyms do not expand database link names at runtime, so they do not change. Depending on the situation, this behavior may or may not be desired. For example, consider two databases named SALES.UK.ACME.COM and HQ.UK.ACME.COM. Also, assume that the SALES database contains the following view and synonym:

CREATE VIEW employee_names AS

SELECT ename FROM scott.emp@hq;

CREATE SYNONYM employee

FOR scott.emp@hq;

ORACLE expands the EMPLOYEE synonym definition and stores it as:

"scott.emp@hq.uk.acme.com"

The company undergoes a reorganization. First, consider the situation where both the Sales and Human Resources departments are moved to the United States. Consequently, the corresponding global database names are both changed to SALES.US.ACME.COM and HQ.US.ACME.COM. In this case, the defining query of the EMPLOYEE_NAMES view still expands to the correct database when the view is used:

"SELECT ename FROM scott.emp@hq.us.acme.com"

However, the definition of the EMPLOYEE synonym continues to reference the previous database name, HQ.UK.ACME.COM.

Now consider that only the Sales department is moved to the United States. Consequently, the corresponding new global database name is SALES.US.ACME.COM, while the Human Resources database is HQ.UK.ACME.COM. In this case, the defining query of the EMPLOYEE_NAMES view expands to a non-existent global database name when the view is used:

"SELECT ename FROM scott.emp@hq.us.acme.com"

Alternatively, the EMPLOYEE synonym continues to reference the correct database, HQ.UK.ACME.COM.

In summary, you should decide when you want to use partial and complete global object names in the definition of views, synonyms, and procedures. Keep in mind that database names should be stable and databases should not be unnecessarily moved within a network.

________________________________________

Table Snapshots

The table snapshot feature built-into ORACLE allows the replication of a master table by an unlimited number of snapshots on other nodes of a distributed database. Updates are allowed only on the master table, while replicates are read-only; that is, replicates cannot be updated, only queried. Each replicate of the master table is called a "snapshot" because the snapshot is asynchronously (periodically) refreshed to reflect a recent transaction consistent state of the master table.

Maintaining snapshots of a master table among the nodes of a distributed database is often a useful feature for the following reasons:

•	Queries can be issued against a local snapshot. Therefore, associated query performance is fast because the requested data does not have to be shipped over a network.

•	If the database that contains the master table or a database that contains a snapshot experiences a failure or is cut off from the distributed database by a network failure, the other (read-only) copies remain accessible to other users of the system.

Figure 21 - 6 illustrates the structures and processes used for the table snapshot feature of ORACLE.

Snapshots

A snapshot is a full copy of a table or a subset of a table that reflects a recent state of the master table. A snapshot is defined by a distributed query that references one or more master tables, view, or other snapshots. A database that contains a master table is referred to as the master database.

Simple vs. Complex Snapshots      Each row in a simple snapshot is based on a single row in a single remote table. Therefore, a simple snapshot's defining query has no GROUP BY or CONNECT BY clauses, or subqueries, joins, or set operations. If a snapshot's defining query contains any of these clauses or operations, it is referred to as a complex snapshot.

The Mechanisms of Snapshot Creation

When a snapshot is created, ORACLE creates several internal objects in the schema of the snapshot. These objects should not be altered.

At the snapshot node, ORACLE creates a base table to store the rows retrieved by the snapshot's defining query. ORACLE then creates a read-only view of this table that is used whenever queries are issued against the snapshot.

Locally, ORACLE creates a view on the remote master table. This view is used to refresh the snapshot. Instructions for creating and managing table snapshots are included in the ORACLE7 Server Application Developer's Guide.

Refreshes

Periodically, a snapshot is refreshed to reflect the current state of its master table. To refresh a snapshot, the snapshot's defining query is issued and its results are stored in the snapshot, replacing the previous snapshot data. Each snapshot is refreshed in a separate transaction, either automatically by ORACLE (according to the interval set when the snapshot was defined or altered) or manually. Instructions for refreshing table snapshots are included in the ORACLE7 Server Administrator's Guide.

Snapshot Logs

A simple snapshot can be refreshed from a snapshot log to expedite the refresh process. A snapshot log is a table in the master database that is associated with the master table. ORACLE uses a snapshot log to track the rows that have been updated in the master table. When a certain simple snapshot based on the master table is refreshed (that is, one snapshot log can be used by multiple simple snapshots), only the appropriate rows in the snapshot log need to be applied to the snapshot to refresh it (called a fast refresh). If no other simple snapshot requires an applied row in the log, it is purged from the log to keep the log's size small; however, if another simple snapshot requires the row for its next refresh, the row remains in the log.

A complex snapshot or simple snapshot without a snapshot log must be completely regenerated using the master tables every time the snapshot is refreshed (called a complete refresh).


CHAPTER 22. TWO-PHASE COMMIT

All for one, one for all, that is our device.

Alexandre Dumas the Elder:  The Three Musketeers

This chapter describes ORACLE's transparent two-phase commit mechanism used to complete the commit of a distributed transaction. Topics include:

•	how a simple two-phase commit works

•	the two phases of the process: the Prepare phase and the Commit phase

•	controlling coordination of a two-phase commit

•	failures that can affect a two-phase commit

•	how ORACLE transparently recovers in-doubt distributed transactions

Note: The information in this chapter applies only to those systems using ORACLE with the distributed option.

________________________________________

An Introduction to the Two-Phase Commit Mechanism

ORACLE automatically controls and monitors the commit or rollback of a distributed transaction and maintains the integrity of the global database (the collection of distributed databases participating in the transaction) using a mechanism known as two-phase commit. The two-phase commit mechanism is completely transparent; no programming on the part of the user or application developer is necessary to use the two-phase commit mechanism. The information in this section is provided so that you can understand how this mechanism works, why it is used, and how you can take advantage of its features to better design and configure a distributed database system.

Why Two-Phase Commit?

By definition, changes made by all SQL statements in a transaction are either committed or rolled back as a unit. The commit of a non-distributed transaction (one that contains SQL statements that modify data only at a local database) is simple - all changes are either committed or rolled back as a unit in the non-distributed database. However, the commit or rollback of a distributed transaction must be coordinated over a network so that the participating nodes either all commit or all roll back the transaction, even if a network failure or a system failure of any number of nodes occur during the process. The two-phase commit mechanism guarantees that the nodes participating in a distributed transaction either all commit or all roll back the transaction, thus maintaining the integrity of the global database.

When Is Two-Phase Commit Used?

The two-phase commit mechanism is only used if a transaction contains a DML statement or remote procedure call that references a remote object using its global object name. When no updates are performed at a node, ORACLE automatically notices that the node is read-only and the node does not need to participate in the ensuing two-phase commit.

All implicit DML operations performed by integrity constraints, remote procedure calls, and triggers are also protected by ORACLE's two-phase commit mechanism.

The Phases of the Two-Phase Commit Mechanism

A two-phase commit has two distinct phases:

prepare phase	The global coordinator (initiating node) asks participants to prepare (to promise to commit or rollback the transaction, even if there is a failure).

commit phase	If all participants respond to the coordinator that they are prepared, the coordinator asks all nodes to commit the transaction; if all participants cannot prepare, the coordinator asks all nodes to roll back the transaction.

When a user commits a distributed transaction with a COMMIT statement, the two-phase commit mechanism automatically performs each phase. The following sections describe each phase in further detail.

 Prepare Phase

The first phase in committing a distributed transaction is the prepare phase. This phase is preparatory; the commit is not actually carried out in this stage. Instead, all nodes referenced in a distributed transaction (except one, known as the commit point site) are asked to "prepare."  By preparing, a node records enough information so that it can subsequently either commit or roll back the transaction, regardless of intervening failures. When a node responds to its requestor that it has prepared, the prepared node has made a promise to be able to either commit or roll back the transaction at a later time point and not to make a unilateral decision on whether to commit or roll back the transaction.

Queries that start after a node has prepared cannot access the associated locked data until the two-phase commit is complete (an insignificant amount of time unless a failure occurs).

When a node is asked to prepare, it can respond with three different answers:

"prepared"	Data on the node has been modified by a statement in the distributed transaction and the node has successfully prepared.

"read-only"	No data on the node has been modified (only queried), so no prepare is necessary.

"abort"	The node cannot successfully prepare.

To complete the prepare phase, each node performs the following actions:

•	The node requests its descendants (nodes subsequently referenced) to prepare, if any.

•	The node allocates all resources it needs to commit the transaction.

•	The node flushes redo entries corresponding to any changes made by that transaction to its local redo log.

•	The node guarantees that any locks held for that transaction are able to survive a failure.

•	The node responds to the node that referenced it in the distributed transaction with a "prepared" or "read-only" message.

These actions guarantee that the transaction can subsequently be committed or rolled back on that node. The prepared nodes then wait until a COMMIT or ROLLBACK is sent. Once prepared, a node is said to be in-doubt.

When a node is asked to prepare and the SQL statements affecting the database are queries (read-only), the node responds to the node that referenced it with a "read-only" message. This expedites the two-phase commit process because all nodes that respond with read-only messages do not have to participate in the second phase (the Commit phase). For more information about read-only distributed transactions, see "Read-Only Distributed Transactions" on page 22 - 18

When a node cannot successfully prepare, it performs the following actions:

•	That node releases any resources currently held by the transaction and rolls back the local portion of the transaction.

•	The node responds to the node that referenced it in the distributed transaction with an "abort" message.

These actions then propagate to the other nodes involved in the distributed transaction to roll back the transaction and guarantee the integrity of the data in the global database. Again, this enforces the primary rule of a distributed transaction; all nodes involved in the transaction either all commit or all roll back the transaction at the same logical time.

In summary, the Prepare phase contains the following steps:

1.	The COMMIT statement is issued to denote the end of a transaction.

2.	The local database asks all nodes referenced in the transaction to prepare for the pending commit.

3.	All referenced nodes respond to the prepare message, either that they are prepared or not prepared. If any of the referenced nodes respond to the "prepare" message with an "abort" message, the transaction is rolled back globally. If all of the referenced nodes respond with a "prepared" (or "read-only") message, the next phase of the distributed transaction occurs, the Commit phase.

 Commit Phase

The second phase in committing a distributed transaction is the Commit phase. Before this phase occurs, all nodes referenced in the distributed transaction have guaranteed that they have the necessary resources to commit the transaction; that is, they are prepared. Therefore, the Commit phase consists of the following steps:

1.	All nodes are told to commit the transaction.

2.	ORACLE at each node, commits the local portion of the distributed transaction (releasing locks) and records an additional redo entry in the local redo log, indicating that the transaction has committed.

When this phase is complete, the data on all nodes of the distributed database system are consistent with one another.

A variety of failure cases, caused by network or system failures, are possible during both the Prepare phase and the Commit phase of a two-phase commit. For a brief description of failure situations and how ORACLE resolves intervening failures during a two-phase commit, see "Failures During Two-Phase Commit" on page 22 - 20.

The Session Tree

As the statements in a distributed transaction are issued, a session tree is defined of all nodes participating in the transaction. All nodes participating in the session tree of a distributed transaction assume one or more roles. These roles are:

•	a client

•	a database server

•	the global coordinator

•	a local coordinator

•	the commit point site

The role a node plays in a distributed transaction is determined by:

•	where the transaction originates

•	the commit point strength of that node, as determined by an initialization parameter on instance startup (see page 22 - 16)

•	whether all requested data is available at a node, or whether other nodes need to be referenced to complete the transaction

•	whether the node is read-only

Figure 22 - 1  below illustrates a simple session tree.

Clients

A database server acting as a client is anode that references information from another database server in a distributed transaction. In the above example, the node with the SALES database is a client of the nodes that serve the WAREHOUSE and FINANCE databases.

Database Servers

A server is a node that is directly referenced in a distributed transaction, or is requested to participate in a transaction because another node requires data from it.

In Figure 22 - 1, the distributed transaction initiated at the SALES database accesses information in the WAREHOUSE and FINANCE databases. Therefore, WAREHOUSE and FINANCE both play roles as database servers in this distributed transaction. In this example, SALES is also a database server because the application is directly connected to the SALES database instance.

The Global Coordinator

Thenode where the distributed transaction originates (to which the database application issuing the distributed transaction is directly connected) is called the global coordinator. This node becomes the parent or root of the session tree. The global coordinator performs the following operations during the course of a distributed transaction:

•	All SQL statements and remote procedure calls are originally sent by the global coordinator to directly referenced nodes, thus forming the session tree. For example, in Figure 22 - 1, the transaction issued at the SALES database references information in the WAREHOUSE and FINANCE databases. Therefore, SALES is the global coordinator of this distributed transaction.

•	The global coordinator communicates with all directly referenced nodes other than the commit point site to prepare the transaction.

•	If all nodes prepare successfully, the global coordinator asks the commit point site to initiate the global commit of the transaction.

For more information about the global coordinator's actions, see "A Simple Example of Two-Phase Commit" on page 22 - 8.

Local Coordinators

A nodethat must reference data on other nodes to complete its part in the distributed transaction is called a local coordinator. In Figure 22 - 1, SALES, although it happens to be the global coordinator, is also considered a local coordinator because it coordinates the nodes it directly references: WAREHOUSE and FINANCE.

A local coordinator is responsible for coordinating the transaction among the nodes it references by:

•	relaying information to the nodes that it references

•	gathering information from the nodes that it references

•	returning information back to the node that referenced it

The Commit Point Site

The two-phase commit mechanism always designates a node in the session tree to be the commit point site. The job of the commit point site is to perform an atomic action that determines whether the global distributed transaction will commit or roll back.

The commit point site is distinct from all other nodes involved in a distributed transaction with respect to the following two issues:

•	The commit point site never enters the prepared state during a two-phase commit. This is potentially advantageous because if the commit point site stores the most critical data (the data most widely used), this data never remains in-doubt, even if a failure situation occurs. (In failure situations, failed nodes remain in a prepared state, holding necessary locks on data until the in-doubt transactions are finalized.)

•	In effect, the outcome of a distributed transaction at the commit point site determines how the transaction is completed; i.e., committed or rolled back, on every other node of the session tree. The global coordinator ensures that all nodes complete the transaction the same way that the commit point site completed the transaction.

The eventual outcome of a distributed transaction is considered to be committed after all nodes other than the commit point site are prepared, and when the transaction has been committed at the commit point site (even though some participating nodes may be only in the prepared state and not yet committed). The redo log of the commit point site records this fact immediately when it occurs. Likewise, a distributed transaction is considered not committed if it has not been committed at this database, and no information is stored in its redo log until the transaction is committed at this node.

A Simple Example of Two-Phase Commit

Now that the terms involved with a two-phase commit have been defined and a high-level overview of the two phases in this process has been presented, an example of a simple, successful two-phase commit is given to illustrate:

•	how the session tree is defined

•	how the commit point site is determined

•	when the prepare messages are sent

•	when the transaction is actually committed

•	what information is stored locally about the transaction

Example	To outline the mechanisms involved in committing a distributed transaction, assume that you work in a company that has separate SALES and WAREHOUSE databases, connected via an ORACLE distributed database. As sales records are entered into the SALES database, associated records are updated at the WAREHOUSE database. The following sections take you through the steps carried out during a transaction that places a sales order.

1.	The application issues SQL statements.

At the Sales department, you use a database application to place the sales order. The application is designed so that when an order is placed, it issues a number of SQL statements to place the order and update the inventory. These SQL statements are all issued as part of a single transaction; this guarantees that all issued SQL statements succeed or fail as a unit, thus preventing the possibility of an order being placed but inventory not being updated to reflect the order. In effect, the transaction guarantees the consistency of data in the global database.

As each of the SQL statements in the transaction is executed, the session tree is defined, as shown in Figure 22 - 2..

Notice the following:

•	The transaction is initiated by an order entry application running with the SALES database. Therefore, SALES is the global coordinator of the distributed transaction.

•	The order entry application inserts a new sales record into the SALES database and updates the inventory at the warehouse. Therefore, SALES and WAREHOUSE are both considered database servers. Furthermore, because SALES updates the inventory, SALES is a client of WAREHOUSE.

This completes the definition of the session tree for this distributed transaction. Remember that each node in the tree has acquired the necessary data locks to execute the SQL statements that referenced local data. While these SQL statements have been executed, the transaction has not yet been committed and will not be until the end of a two-phase commit.

2.	The application issues a COMMIT statement.

The final statement in the transaction that places the sales order is now issued - either a COMMIT statement or a ROLLBACK statement. If the ROLLBACK statement is issued, the global coordinator tells all referenced nodes to roll back the transaction and the transaction is completed. However, a COMMIT statement begins the two-phase commit, starting with the Prepare phase.

3.	The global coordinator determines the commit point site.

The commit point site is determined immediately following the COMMIT statement. Because the detailed discussion of how the commit point site is determined has been intentionally left for later, assume that SALES, the global coordinator, is determined as the commit point site, as shown in Figure 22 - 3.

See "Advanced Two-Phase Commit Topics" on page 22 - 16 for more information about how the commit point site is determined.

4.	The global coordinator sends the Prepare message.

After the commit point site is determined, the global coordinator sends the prepare message to all directly referenced nodes of the session tree, excluding the commit point site. In this example, WAREHOUSE is the only node asked to prepare.

Each node that receives the prepare message tries to prepare. If a node can guarantee that it can commit the locally dependent part of the transaction and can record the commit information in its local redo log, the node can successfully prepare.

As each node prepares, it sends a message back to the node that asked it to prepare. Depending on the responses, two things can happen:

•	If any of the nodes asked to prepare respond with an "abort" message to the global coordinator, the global coordinator then tells all nodes to roll back the transaction, and the mechanism is completed.

•	If all nodes asked to prepare respond with a "prepared" message to the global coordinator; that is, they have successfully prepared, the global coordinator asks the commit point site to commit the transaction.

Continuing with the example, Figure 22 - 4  illustrates the parts of Step 4.

In this example, only the WAREHOUSE server receives a "prepare" message because SALES is the commit point site. WAREHOUSE responds to SALES with a "prepared" message.

5.	The commit point site commits.

The SALES server, knowing that WAREHOUSE is prepared, asks the commit point site (itself, in this example) to commit the transaction. The commit point site now commits the transaction locally, and records this fact in its local redo log. The (eventual) outcome of the transaction at all nodes of the session tree is now determined; the transaction will be committed at all nodes. In this example, SALES commits the transaction locally.

6.	The commit point site informs the global coordinator of the commit.

The commit point site now tells the global coordinator that the transaction has committed. In this case, where the commit point site and global coordinator are the same node, no operation is required. The commit point site remembers it has committed the transaction until the global coordinator confirms that the transaction has been committed on all other nodes involved in the distributed transaction.

After the global coordinator has been informed of the commit at the commit point site, it tells all other directly referenced nodes to commit as well. In turn, any local coordinators instruct their servers to commit, and so on. Each node, including the global coordinator, commits the transaction and records appropriate redo log entries locally. As each node commits, the resource locks that were being held locally for that transaction are released.

Figure 22 - 5 illustrates Step 6 in this example. SALES, both the commit point site and the global coordinator, has already locally committed the transaction. SALES now informs WAREHOUSE to commit the transaction as well.

7.	The global coordinator and commit point site complete the commit.

After all referenced nodes and the global coordinator have committed the transaction, the global coordinator informs the commit point site. The commit point site, which has been waiting for this message, erases the status information about this distributed transaction, and in turn, informs the global coordinator that it is finished. In other words, the commit point site "forgets" about the distributed transaction committing. This is acceptable because all nodes involved in the two-phase commit have successfully committed the transaction and they will never have to determine its status in the future.

After the commit point site informs the global coordinator that it has forgotten about the transaction, the global coordinator finalizes the transaction by forgetting about the transaction in the same way.

This completes the COMMIT phase, and thus the two-phase commit of the distributed transaction.

To complete this example, WAREHOUSE informs the global coordinator, SALES, that it has locally committed the transaction. As SALES is also the commit point site, it forgets about the transaction, completing the two-phase commit of the transaction that issued a sales order.

 Summary

While it may seem that there are many steps involved in completing the two-phase commit of a distributed transaction, keep in mind that this is all accomplished automatically and in a fraction of a second. More importantly, the methodical steps of the two-phase commit mechanism guarantee the integrity of the global database in a distributed database system.

________________________________________

Advanced Two-Phase Commit Topics

The following sections cover some advanced, fine tuning issues concerning the two-phase commit mechanism that can be controlled by the database administrator or application developer:

•	commit point strengths and determination of the commit

 point site

•	distributed deadlock detection

•	read-only distributed transactions

Commit Point Strength

EveryORACLE database instance is assigned a commit point strength during database startup. If a database server is referenced in a distributed transaction, the value of its commit point strength determines what role it plays in the two-phase commit. Specifically, the commit point strength determines whether or not a given node is the commit point site in the distributed transaction.

The commit point site is determined when the global coordinator receives the COMMIT statement of a distributed transaction. The commit point site is selected from the nodes participating in the transaction. Of the nodes directly referenced by the global coordinator, the node with the highest commit point strength is determined. Then, the initially selected node determines if any of its servers involved in the distributed transaction has a higher commit point strength. Either the node with the highest commit point strength directly referenced in the transaction, or one of its servers with a higher commit point strength becomes the commit point site. Figure 22 - 6 illustrates the commit point strengths of each node (in parentheses) and the node chosen as the commit point site in a sample session tree.

The following conditions apply when the commit point site is determined:

•	A read-only node (node to which only SELECT statements have been directed) cannot be designated as the commit point site.

•	If all nodes directly referenced by the global coordinator have the same commit point strength, ORACLE designates one of the direct nodes as the commit point site.

•	If a distributed transaction ends with a ROLLBACK, a commit point site is never established. Instead, the global coordinator sends a ROLLBACK statement to all nodes and ends the processing of the distributed transaction.

The commit point strength is used solely to determine the commit point site in a distributed transaction. Because the commit point site stores information about the status of the transaction, the commit point site should not be a node that is frequently unreliable or unavailable in case other nodes need information about the transaction's status.

As Figure 22 - 6 illustrates, the commit point site and the global coordinator can be different nodes of the session tree.

When initial connections among databases in a distributed database are made (by SQL statements or remote procedure calls including global object names), the commit point strengths of the databases are communicated. Each coordinator session notes the commit point strengths (once they are first referenced) so that commit point sites can be efficiently selected during two-phase commits. There are no extra messages exchanged at each commit to determine the commit point site.

Distributed Deadlocks

As with non-distributed database systems, deadlocks can occur among the nodes of a distributed database system. ORACLE avoids distributed deadlocks using a timeout period while waiting for requested data.

Coordination of System Change Numbers

Each committed transaction has an associated system change number (SCN) to uniquely identify the changes made by the statements within that transaction. In a distributed database, the SCNs of communicating nodes are coordinated when:

•	A connection is established using the path described by one or more database links.

•	A distributed SQL statement is executed (i.e., the execute phase completes).

•	A distributed transaction is committed.

Among other benefits, the coordination of SCNs among the nodes of a distributed database system allows global distributed read-consistency at both the statement and transaction level. If necessary, global distributed time-based recovery can also be completed.

During the Prepare phase, the highest SCN at all nodes in the transaction is determined. The transaction is then committed with the high SCN at the commit point site. The commit SCN is then sent to all prepared nodes along with the commit decision.

Read-Only Distributed Transactions

There are three cases in which all or part of a distributed transaction can be considered read-only:

•	A distributed transaction can be partially read-only if:

•	only queries are issued at one or more nodes

•	updates did not modify any records

•	updates were rolled back due to violations of integrity constraints or triggers being fired

In each of these cases, the read-only nodes recognize this fact when they are asked to prepare. They respond to their respective local coordinators with a "read-only" message. By doing this, the two-phase commit process completes faster because the read-only nodes can be eliminated from subsequent processing.

•	The distributed transaction can be completely read-only (all queries at all nodes) and the transaction is not started with the SET TRANSACTION READ ONLY statement. In this case, all nodes recognize that they are read-only during the Prepare phase, and no Commit phase is required. However, the global coordinator, not knowing whether or not all nodes are read-only, must still perform the operations involved in the Prepare phase.

•	The distributed transaction can be completely read-only (all queries at all nodes) and the transaction is started with a

 SET TRANSACTION READ ONLY statement. In this case, only queries are allowed in the transaction, and the global coordinator does not have to undertake a two-phase commit at all. Furthermore, global transaction-level read consistency is automatically guaranteed by coordination of SCNs at each node in the distributed database.

________________________________________

Failures During Two-Phase Commit

The following types of problems can cause a failure during a two-phase commit:

•	machine failure

•	network failure

•	software failure

•	local instance aborts

For example, suppose that during the Prepare phase or Commit phase of a two-phase commit, a network connection fails. What is the outcome of the two-phase commit?  The distributed transaction capabilities of ORACLE have been designed to automatically and transparently complete the recovery from such failures; no work is required of any database administrator to successfully resolve the distributed transaction at any involved node.

There are many failure case scenarios. The following discussion does not cover all cases. For a general treatment of two-phase commit recovery, refer to a distributed database textbook. ORACLE handles all cases without loss of data.

Before discussing how ORACLE can recover from the different types of failures that can occur during a two-phase commit, it is necessary to define some tools used by ORACLE to recover from such problems; the pending transaction table and the RECO background process.

The Pending Transaction Table (DBA_2PC_PENDING)

Every ORACLE database has a pending transaction table. The pending transaction table is a special table in each database that stores information about distributed transactions as they proceed through a two-phase commit. A database's pending transaction table is queried by referencing the DBA_2PC_PENDING data dictionary view.

Each transaction with an entry in the pending transaction table is classified in one of the following categories (as indicated in DBA_2PC_PENDING.STATE):

collecting	This category normally applies only to the global coordinator or local coordinators. The node is currently in the process of collecting information from other database servers before it can decide whether or not it can prepare.

prepared	The node has prepared and may or may not have acknowledged this to its local coordinator with a "prepared" message; however, no "commit" message has been received. The node continues to remain prepared, holding any local resource locks necessary for the transaction to commit.

committed	The node (any type) has committed the transaction, but other nodes involved in the transaction may not have done the same; that is, the transaction is still pending at one or more nodes involved in the transaction.

forced commit	A pending transaction can be forced to commit at the discretion of a database administrator. This entry is made if a transaction is manually committed at a local node by a database administrator.

forced abort (rollback)	A pending transaction can be forced to roll back at the discretion of a database administrator. This entry is made if this transaction is manually rolled back at a local node by a database administrator.

Also of particular interest in the pending transaction table is the mixed outcome flag (as indicated in DBA_2PC_PENDING.MIXED). The database administrator can make the wrong choice if a pending transaction is forced to commit or roll back (e.g., the local administrator rolls back the transaction, but the other nodes commit the transaction). Incorrect decisions are automatically detected and the damage flag for the corresponding pending transaction's record is set (MIXED=yes).

The information in the pending transaction table is used by the RECO (Recoverer) background process to finalize the status of in-doubt transactions. The information in the pending transaction table can also be used by a database administrator who decides to manually override the automatic recovery procedures for pending distributed transactions.

All transactions automatically resolved by RECO are automatically removed from the pending transaction table. Additionally, all information about in-doubt transactions correctly resolved by an administrator (as checked when RECO reestablishes communication) are automatically removed from the pending transaction table. However, all rows resolved by an administrator that result in a mixed outcome across nodes remain in the pending transaction table of all involved nodes until they are manually deleted.

The Recoverer (RECO) Background Process

The RECO background process of an ORACLE instance automatically resolves failures involving distributed transactions. At exponentially growing time intervals, the RECO background process of a node attempts to recover the local portion of an in-doubt distributed transaction. RECO can use an existing connection or establish a new connection to other nodes involved in the failed transaction. When a connection is established, RECO automatically resolves all in-doubt transactions. Rows corresponding to any resolved in-doubt transactions are automatically removed from each database's pending transaction table.


PART  IX . DATABASE BACKUP AND RECOVERY


CHAPTER 23. RECOVERY STRUCTURES

If you do not think about the future, you cannot have one.

John Galsworthy:  Swan Song

This chapter introduces the structures of ORACLE that are used during database recovery. Topics include:

•	errors and failures that can cause database failure

•	the online redo log

•	contents of online redo log files

•	checkpoints

•	log switches and log sequence numbers

•	mirrored online redo logs

•	the archived redo log

•	the ARCH background process

•	contents

•	database archiving modes

•	control files

•	contents

•	mirrored control files

The procedures necessary to create and maintain these structures are discussed in the ORACLE7 Server Administrator's Guide.

________________________________________

An Introduction to Database Recovery and Recovery Structures

A major responsibility of the database administrator is to prepare for the possibility of hardware, software, network, process, and system failure. If such a failure affects the operation of a database system, it is usually desirable to recover the databases and return to normal operations as quickly as possible. Recovery should proceed in such a manner to protect the databases and associated users from unnecessary problems, and avoid or reduce the possibility of having to manually duplicate work.

Recovery processes vary, depending on the type of failure that has occurred, the structures that have been affected, and the type of recovery that is desired. If no files are lost or damaged, recovery may amount to no more than restarting an instance. If data has been lost, recovery requires additional steps, as described in Chapter 25.

Errors and Failures

Several problems can halt the normal operation of an ORACLE database or affect the writing of database information to disk. The most common types of failure are described below. For some of these problems, recovery is automatic and requires little or no action on the part of the database user or database administrator.

 User Error

A database administrator can do little to prevent user errors (e.g., accidentally dropping a table, etc.). In most cases, user error can be reduced by increased training on database and application principles. Furthermore, by planning an effective recovery scheme ahead of time, the administrator can ease the work necessary to recover from many types of user errors.

 Statement Failure

Statement failure occurs when there is a logical failure in the handling of a statement in an ORACLE program. For example, assume all extents of a table are allocated (the number specified in the MAXEXTENTS parameter of the CREATE TABLE statement), and all extents are completely filled with data; the table is absolutely full. A valid INSERT statement cannot insert a row because there is no space available. Therefore, if issued, the statement fails.

If a statement failure occurs, the ORACLE software or operating system returns an error code or message. A statement failure usually requires no action or recovery steps; ORACLE automatically corrects for statement failure by rolling back the effects (if any) of the statement and returning control to the user or user program. The user can simply re-execute the statement after correcting the problem conveyed by the error message.

 Process Failure

A process failure is a failure in a user, server, or background process of a database instance (for example, an abnormal disconnect or process termination). When a process failure occurs, the failed subordinate process cannot continue work, although the other processes of the database instance can.

The ORACLE background process PMON detects an aborted ORACLE process. If the aborted process is a user or server process, PMON resolves the failure by rolling back the current transaction of the aborted process and releasing any resources that this process was using; recovery of a failed user or server process is automatic. If the aborted process is a background process, the instance cannot continue to function correctly (in most cases); therefore, the instance must be shut down and restarted.

 Network Failure

When communication networks (e.g., local area network, phone lines, etc.) are used to connect client workstations to database servers, or to connect several database servers to form a distributed database system, network failures (such as aborted phone connections or network communication software failures) can interrupt the normal operation of a database system. For example:

•	A network failure might interrupt normal execution of a client application and cause a process failure to occur. In this case, the ORACLE background process PMON detects and resolves the aborted server process for the disconnected user process, as described in the previous section.

•	A network failure might interrupt the two-phase commit of a distributed transaction. Once the network problem is corrected, the ORACLE background process RECO of each involved database server automatically resolves any pending distributed transactions not yet resolved at all nodes of the distributed database system. Distributed database systems are discussed in Chapter 21.

 Database Instance Failure

Database instance failure occurs when a problem arises that prevents an ORACLE database instance (SGA and background processes) from continuing to work. An instance failure can result from a hardware problem (such as a power outage) or a software problem (such as an operating system crash).

Recovery from instance failure is relatively automatic. For example, in configurations that do not use the ORACLE Parallel Server, instance recovery is automatically performed as part of the next instance startup. When using the ORACLE Parallel Server, instance recovery is performed by other instances of the system. For additional information about instance recovery, see Chapter 25.

 Media (Disk) Failure

An error can arise when trying to write or read a file that is required to operate an ORACLE database. This occurrence is called media failure because there is a physical problem reading or writing physical files needed for normal database operation.

A common example of a media failure is a disk head crash, which causes the loss of all files on a disk drive. All files associated with a database are vulnerable to a disk crash, including data files, redo log files, and control files. The appropriate recovery from a media failure depends on the files affected; see Chapter 25 for a discussion of media recovery.

How Media Failures Affect Database Operation      Media failures can affect one type or all types of files necessary for the operation of an ORACLE database, including data files, online redo log files, or control files.

Database operation after a media failure that affects online redo log files or control files depends on whether or not the online redo log or control file is mirrored, as recommended. If a media failure damages a single disk, and a mirrored online redo log is used, the database can continue to operate without interruption, in most cases. Damage to a uniplexed online redo log causes database operation to halt and may cause permanent loss of data. Damage to any control file, whether it is mirrored or non-mirrored, halts database operation once ORACLE attempts to read or write the control file.

A media failure that affects data files can be divided into two categories: read errors and write errors. If ORACLE discovers it cannot read a data file, an operating system error is returned to the application, along with an ORACLE error indicating that the file cannot be found, cannot be opened, or cannot be read. ORACLE continues to run, but the error is returned each time an unsuccessful read occurs. At the next checkpoint, a write error will occur when ORACLE attempts to write the file header as part of the standard checkpoint process.

If ORACLE discovers that it cannot write to a data file and ORACLE is archiving filled online redo log files, an error is returned in the DBWR trace file and the data file is taken offline automatically. Only the data file that cannot be written to is taken offline; the tablespace containing the file remains online.

If the data file that cannot be written to is in the SYSTEM tablespace, the file is not taken offline. Instead, an error is returned and ORACLE shuts down the database. The reason for this exception is that all files in the SYSTEM tablespace must be online in order for ORACLE to operate properly. For the same reason, the data files of a tablespace containing active rollback segments must remain online.

If ORACLE discovers that it cannot write to a data file and ORACLE is not archiving filled online redo log files, DBWR fails and the current instance fails. If the problem is temporary (e.g., the disk controller was powered off), instance recovery can usually be performed using the online redo log files, in which case the instance can be restarted. However, if a data file is permanently damaged and archiving is not used, the entire database must be restored using the most recent backup.

Structures Used for Database Recovery

Several structures of an ORACLE database safeguard data against possible failures. The following sections briefly introduce each of these structures and their role in database recovery.

 Database Backups

A database backup consists of operating system backups of the physical files that constitute an ORACLE database. To begin database recovery from a media failure, file backups are used to restore damaged data files or control files.

ORACLE offers several options in performing database backups; see Chapter 24 for more information.

 The Redo Log

The redo log, present for every ORACLE database instance, records all changes made in an ORACLE database. The redo log of an instance consists of at least two redo log files that are separate from the data files (which actually store a database's data). As part of database recovery from an instance or media failure, the appropriate changes in the database's redo log are applied to the data files, updating database data to the instant that the failure occurred.

A database's redo log can be comprised of two parts: the online redo log and the archived redo log, discussed in the following sections.

The Online Redo Log      Every running ORACLE database instance has an associated online redo log. The online redo log works in conjunction with the ORACLE background process LGWR to immediately record all changes made through the associated instance. The online redo log consists of two or more pre-allocated files that are reused in a circular fashion to record ongoing database changes; see page 23 - 6 for more information.

The Archived     (Offline) Redo Log   Optionally, an ORACLE database instance can be configured to archive files of the online redo log once they fill. The online redo log files that are archived are uniquely identified and make up the archived redo log. By archiving filled online redo log files, older redo log information can be preserved for more extensive database recovery operations, while the pre-allocated online redo log files continue to be reused to store the most current database changes; see page 23 - 15 for more information.

 Rollback Segments

Rollback segments are used for a number of functions in the operation of an ORACLE database. In general, the rollback segments of a database store the old values of data changed by ongoing transactions (that is, uncommitted transactions). Among other things, the information in a rollback segment is used during database recovery to "undo" any "uncommitted" changes applied from the redo log to the data files. Therefore, if database recovery is necessary, the data is in a consistent state after the rollback segments are used to remove all uncommitted data from the data files; see page 3 - 14 for more information.

 Control Files

In general, the control file(s) of a database stores status on the physical structure of the database. Certain status information in the control file (e.g., the current online redo log file, the names of the data files, etc.) is used to guide ORACLE during instance or media recovery; see page 23 - 20 for more information.

________________________________________

The Online Redo Log

Every instance of an ORACLE database has an associated online redo log to protect the database in case the database experiences an instance failure. An online redo log consists of two or more pre-allocated files that store all changes made to the database as they occur.

Online Redo Log File Contents

Online redo log files are filled with redo entries. Redo entries record data that can be used to reconstruct all changes made to the database, including the rollback segments stored in the database buffers of the SGA. Therefore, the online redo log also protects rollback data.

Note: Redo entries store low-level representations of database changes that cannot be related to user actions. Therefore, the contents of an online redo log file should never be edited or altered, and cannot be used for any application purposes such as auditing.

Redo entries are buffered in a "circular" fashion in the redo log buffer of the SGA and are written to one of the online redo log files by the ORACLE background process Log Writer (LGWR). Whenever a transaction is committed, LGWR writes the transaction's redo entries from the redo log buffer of the SGA to an online redo log file and a system change number (SCN) is assigned to identify the redo entries for each committed transaction. However, redo entries can be written to an online redo log file before the corresponding transaction is committed; if the redo log buffer fills, or another transaction commits, LGWR flushes redo log entries in the redo log buffer to an online redo log file, of which some redo entries may not be committed; see "The Redo Log Buffer" on page 9 - 33 for more information.

How Online Redo Log Files Are Written

The online redo log of a database consists of two or more online redo log files. Two files are required to guarantee that one is always available for writing while the other can be archived, if desired.

LGWR writes to online redo log files in a circular fashion; when the current online redo log file is filled, LGWR begins writing to the next available online redo log file. When the last available online redo log file is filled, LGWR returns to the first online redo log file and begins writing to it, and the cycle starts again. The circular writing of online redo log files is illustrated in Figure 23 - 1 . The numbers next to each line indicates the sequence in which LGWR writes to each online redo log file.

Filled online redo log files are "available" to LGWR for reuse depending on whether or not archiving is enabled:

•	If archiving is disabled, a filled online redo log file is available once the checkpoint (see page 23 - 9) involving the online redo log file has completed.

•	If archiving is enabled, a filled online redo log file is available to LGWR once the checkpoint involving the online redo log file has completed and after the file has been archived.

 Active (Current) and Inactive Online Redo Log Files

At any given time, only one of the online redo log files is being written to store redo entries written from the redo log buffer. The online redo log file actively being written by LGWR is called the active or current online redo log file, while all other online redo log files are considered inactive. If archiving is enabled, an inactive online log file cannot be reused or overwritten until its contents are archived. If archiving is disabled, when the last online redo log file fills, writing continues by overwriting the first available inactive file. For more information about archiving options for the redo log see "Database Archiving Modes" on page 23 - 17.

 Log Switches and Log Sequence Numbers

The point at which ORACLE ends writing to one online redo log file and begins writing to another is called a log switch.  A log switch always occurs when the current online redo log file is completely filled and writing must continue to the next online redo log file. Log switches can also be forced by the database administrator if it is required that the current redo log file be closed for some operation (e.g., archiving).

Each online redo log file is assigned a new log sequence number every time that a log switch occurs and LGWR begins writing to it. If online redo log files are archived, the archived redo log file retains its log sequence number; the online redo log file that is cycled back for use is given the next available log sequence number when it is used by LGWR.

Each redo log file (including online and archived) is uniquely identified by its log sequence number. During instance or media recovery, ORACLE properly applies redo log files in ascending order by using the log sequence number of necessary archived and online redo log files.

Checkpoints

An event called a checkpoint occurs when an ORACLE background process, DBWR, writes all the modified database buffers in the SGA, including committed and uncommitted data, to the data files. Checkpoints are implemented for the following reasons:

•	Checkpoints ensure that data segment blocks in memory that change frequently are written to data files at regular intervals. Because of the least recently used algorithm of DBWR, a data segment block that changes frequently might never qualify as the least recently used block, and thus might never be written to disk if checkpoints did not occur.

•	Because all database changes up to the checkpoint have been recorded in the data files, redo log entries prior to the checkpoint no longer need to be applied to the data files if instance recovery is required. Therefore, checkpoints are useful because they can expedite instance recovery.

Though some overhead is associated with a checkpoint, ORACLE does not halt activity nor are current transactions affected. Because DBWR continuously writes database buffers to disk, a checkpoint does not necessarily require many data blocks to be written all at once. Rather, the completion of a checkpoint simply guarantees that all data blocks modified since the previous checkpoint are actually written to disk.

Checkpoints occur whether or not filled online redo log files are being archived. If archiving is disabled, a checkpoint affecting an online redo log file must complete before the online redo log file can be reused by LGWR. If archiving is enabled, a checkpoint must complete and the filled online redo log file must be archived before it can be reused by LGWR.

Checkpoints can occur for all data files of the database)called database checkpoints) or can occur for only specific data files. The following list explains when checkpoints occur and what type happens in each situation:

•	A database checkpoint automatically occurs at every log switch. If a previous database checkpoint is currently in progress, a checkpoint forced by a log switch overrides the current checkpoint.

•	An initialization parameter, LOG_CHECKPOINT_INTERVAL, can be set to force a database checkpoint when a predetermined number of redo log blocks have been written to disk relative to the last database checkpoint. Another parameter, LOG_CHECKPOINT_TIMEOUT, can be set to force a database checkpoint a specific number of seconds after the previous database checkpoint started. These options are useful when extremely large redo log files are used and additional checkpoints are desired between log switches. Database checkpoints signaled to start by these initialization parameters are not performed until the previous checkpoint has completed.

•	When the beginning of an online tablespace backup is indicated, a checkpoint is forced only on the data files that constitute the tablespace being backed up. A checkpoint at this time overrides any previous checkpoint still in progress. Also, since this type of checkpoint only affects the data files being backed up, it does not reduce the amount of redo that would be needed for instance recovery.

•	If the administrator takes a tablespace offline with normal or temporary priority, a checkpoint is forced only on the online data files of the associated tablespace.

•	If the database administrator shuts down an instance (NORMAL or IMMEDIATE), ORACLE forces a database checkpoint to complete before the instance is shut down. A database checkpoint forced by instance shutdown overrides any previously running checkpoint.

•	The database administrator can force a database checkpoint to happen, on demand. A checkpoint forced on demand overrides any previously running checkpoint.

Note: Checkpoints also occur at other times if the ORACLE Parallel Server is used; see the ORACLE7 Parallel Server Administrator's Guide for more information.

The Mechanics of a Checkpoint      When a checkpoint occurs, the checkpoint background process (CKPT) remembers the location of the next entry to be written in an online redo log file and signals the database writer background process (DBWR) to write the modified database buffers in the SGA to the data files on disk. CKPT then updates the headers of all control files and data files to reflect the latest checkpoint.

When a checkpoint is not happening, DBWR only writes the least-recently-used database buffers to disk to free buffers for new data, as needed. However, as a checkpoint proceeds, DBWR writes data to the data files on behalf of both the checkpoint and ongoing database operations. DBWR writes a number of modified data buffers on behalf of the checkpoint, then writes the least recently used buffers, as needed, then writes more dirty buffers for the checkpoint, and so on, until the checkpoint is complete.

Depending on what signals a checkpoint to happen, the checkpoint can be either "normal" or "fast."  With a normal checkpoint, DBWR writes a small number of data buffers each time it performs a write on behalf of a checkpoint. With a fast checkpoint, DBWR writes a large number of data buffers each time it performs a write on behalf of a checkpoint. Therefore, by comparison, a normal checkpoint requires more I/Os to complete than a fast checkpoint. Because a fast checkpoint requires fewer I/Os, the checkpoint completes very quickly. However, a fast checkpoint can also detract from overall database performance if DBWR has a lot of other database work to complete. Events that trigger normal checkpoints include log switches and checkpoint intervals set by initialization parameters; events that trigger fast checkpoints include online tablespace backups, instance shutdowns, and administrator forced checkpoints.

It should be noted that until a checkpoint completes, all online redo log files written since the last checkpoint are required if a database failure interrupts the checkpoint and instance recovery is necessary. Additionally, if LGWR cannot access an online redo log file for writing because a checkpoint has not completed, database operation is temporarily suspended until the checkpoint completes and an online redo log file becomes available. In this case, the normal checkpoint becomes a fast checkpoint so it completes as soon as possible. For example, if only two online redo log files are used and LGWR requires another log switch, the first online redo log file is unavailable to LGWR until the checkpoint for the previous log switch completes.

Note: The information that is recorded in the data files and control files as part of a checkpoint varies if the ORACLE Parallel Server configuration is used; see the ORACLE7 Parallel Server Administrator's Guide .

 Mirrored Online Redo Log Files

ORACLE provides the capability to mirror an instance's online redo log files to safeguard against damage to its online redo log files. With mirrored online redo log files, LGWR concurrently writes the same redo log information to multiple identical online redo log files, thereby eliminating a single point of online redo log failure. Figure 23 - 2  illustrates duplexed (two sets of) online redo log files.

The corresponding online redo log files are called groups. Each online redo log file in a group is called a member. Notice that all members of a group are concurrently active (concurrently written to by LGWR), as indicated by identical log sequence numbers assigned by LGWR. If a mirrored online redo log is used, groups of online redo log files can be created, with the requirement that each member in a group is the exact same size.

The Mechanics of a Mirrored Online Redo Log   LGWR always addresses all members of a group, whether a group contains one or many members. For example, LGWR always tries to concurrently write to all members of a given group, then switch and concurrently write to all members of the next group, and so on; LGWR never concurrently writes to one member of a given group and one member of another group.

LGWR reacts differently when certain online redo log members are unavailable, depending on the reason for the file(s) being unavailable:

•	If LGWR can successfully write to at least one member in a group (either at a log switch or as writing to a group is proceeding), writing to the accessible members of the group proceeds as normal; LGWR simply writes to the available members of a group and ignores the unavailable members.

•	If LGWR cannot access the next group at a log switch because the group needs to be archived, database operation is temporarily halted until the group becomes available (e.g., the group is archived).

•	If the next group is not available to LGWR at a log switch because of one or more disk failures; that is, all members are inaccessible, an error is returned and the database instance is immediately shut down. In this case, the database may need media recovery from the loss of an online redo log file; see Chapter 25 for more information about such recovery. However, if the database checkpoint has moved beyond the lost log (this is not the current log in this example), media recovery is not necessary. Simply drop the inaccessible log group. If the log was not archived, archiving might need to be disabled before the log can be dropped.

•	If all members of a group suddenly become inaccessible to LGWR as they are being written, an error is returned and the database instance is immediately shut down. In this case, the database might need media recovery from the loss of an online redo log file; see Chapter 25 for more information about such recovery. If the media containing the log is not actually lost, for example, if the drive for the log was inadvertently turned off, media recovery might not be needed. In this example, all that is necessary is to turn the drive back on and do instance recovery.

Whenever LGWR cannot write to a member of a group, that member is marked as stale, and an error message is written to the LGWR trace file and to the database's ALERT file, to indicate the problem with the inaccessible file(s).

To always safeguard against a single point of online redo log failure, a mirrored online redo log should be completely symmetric; all groups of the online redo log should have the same number of members. However, a mirrored online redo log does not have to be symmetric; for example, one group can have only one member, while other groups can have two members. This behavior is allowed to provide for situations that temporarily affect some online redo log members but leave others unaffected (e.g., a disk failure). The only requirement for an instance's online redo log, mirrored or non-mirrored, is that it be comprised of least two groups. Figure 23 - 3 shows a legal and illegal mirrored online redo log configuration.

 "Threads" of Online Redo Log and the ORACLE Parallel Server

Each database instance has its own online redo log groups; these online redo log groups, mirrored or not, are called an instance's "thread" of online redo. In typical configurations, only one database instance accesses an ORACLE database, thus only one thread is present. However, when running the ORACLE Parallel Server, two or more instances concurrently access a single database; each instance in this type of configuration has its own thread.

This manual describes how to configure and manage the online redo log when the ORACLE Parallel Server is not used; the thread number can be assumed to be 1 in all discussions and examples of commands. For complete information about configuring the online redo log with the ORACLE Parallel Server, see the ORACLE7 Parallel Server Administrator's Guide.

________________________________________

The Archived Redo Log

ORACLE allows the optional archiving of filled groups of online redo log files. By doing this, an archived (offline) redo log is created. The archiving of filled groups has two key advantages relating to database backup and recovery options:

•	A database backup, together with online and archived redo log files, can guarantee that all committed transactions can be recovered in the event of an operating system or disk failure.

•	Online backups, taken while the database is open and in normal system use, can be made and used if an archived log is permanently kept.

The choice of whether or not to enable the archiving of filled groups of online redo log files depends on the backup and recovery scheme for an ORACLE database. If you cannot afford to lose any data in your database in the event of a disk failure, an archived log must be present. However, the archiving of filled online redo log files can require the database administrator to perform extra administrative operations (archiving the filled online redo log files).

The Mechanics of Archiving

Depending on how archiving is configured, the mechanics of archiving filled online redo log groups is performed by either the optional ORACLE background process ARCH (when automatic archiving is used) or the user process that issues a statement to manually archive a group; for more information see "Automatic Archiving and the ARCH (Archiver) Background Process" and "Manual Archiving" on pages 23 - 18 and 23 - 19, respectively.

Note: For simplicity, the remainder of this section assumes that archiving is enabled and the ARCH background process is responsible for archiving filled online redo log groups.

  ARCH can archive a group once the group becomes inactive and the log switch to the next group has completed. The ARCH process can access any and all members of the group, as needed, to complete the archiving of the group. For example, if ARCH attempts to open a member of a group and it is not accessible (e.g., due to a disk failure), ARCH automatically tries to use another member of the group, and so on, until it finds a member of the group that is available for archiving. If ARCH is in the process of archiving a member of a group, and the information in the member is detected as invalid or a disk failure occurs as archiving proceeds, ARCH automatically switches to another member of the group to continue archiving the group where it was interrupted.

A group of online redo log files does not become available to LGWR for reuse until ARCH has archived the group. This restriction is important because it guarantees that LGWR cannot accidentally reuse a group that has not been archived, which would prevent the use of all subsequent archived redo log files during a database recovery.

When archiving is used, an archiving destination is specified. This destination usually points to a storage device separate from the disk drives that hold the data files, online redo log files, and control files of the database. Typically, the archiving destination is another disk drive of the database server; this way, archiving does not contend with other files required by the instance, and archiving completes quickly so the group can become available to LGWR. Ideally, archived redo log files (and corresponding database backups) should be permanently moved to inexpensive offline storage media, such as tape, that can be stored in a safe place, separate from the database server.

At log switch time, when no more information will be written to a redo log, a record is created in the database's control file. Each record contains the thread number, log sequence number, low SCN for the group, and next SCN after the archived log file; this information is used during database recovery in Parallel Server configurations to automate the application of redo log files. See the ORACLE7 Parallel Server Administrator's Guide for additional information.

Archived Redo Log File Contents

An archived redo log file is a simple copy of the identical filled members that constitute an online redo log group. Therefore, an archived redo log file includes the redo entries present in the identical members of a group at the time the group is archived. An archived redo log file also preserves the log sequence number of the group at the time the group is archived.

If archiving is enabled, LGWR is not allowed to reuse an online redo log group until it has been archived. Therefore, it is guaranteed that the archived redo log contains a copy of every group (uniquely identified by log sequence numbers) created since archiving was enabled.

Database Archiving Modes

A database can operate in two distinct modes: NOARCHIVELOG mode (media recovery disabled) or ARCHIVELOG mode (media recovery enabled).

 NOARCHIVELOG Mode (Media Recovery Disabled)

If a database is used in NOARCHIVELOG mode, the archiving of the online redo log is disabled. Information in the database's control file indicates that filled groups are not required to be archived. Therefore, once a filled group becomes inactive and the checkpoint at the log switch completes, the group is available for reuse by LGWR.

NOARCHIVELOG mode protects a database only from instance failure, not from disk (media) failure. Only the most recent changes made to the database, stored in the groups of the online redo log, are available for instance recovery.

 ARCHIVELOG Mode (Media Recovery Enabled)

If an ORACLE database is operated in ARCHIVELOG mode, the archiving of the online redo log is enabled. Information in a database control file indicates that a group of filled online redo log files cannot be reused by LGWR until the group is archived. A filled group is immediately available to the process performing the archiving once a log switch occurs (when a group becomes inactive); the process performing the archiving does not have to wait for the checkpoint of a log switch to complete before it can access the inactive group for archiving. Figure 23 - 4  illustrates how the database's online redo log files are used in ARCHIVELOG mode and how the archived redo log is generated by the process archiving the filled groups (e.g., ARCH in this illustration).

ARCHIVELOG mode permits complete recovery from disk failure as well as instance failure, because all changes made to the database are permanently saved in an archived redo log.

Automatic Archiving and the ARCH (Archiver) Background Process      An instance can be configured to have an additional background process, Archiver (ARCH), automatically archive groups of online redo log files once they become inactive. Therefore, automatic archiving frees the database administrator from having to manually keep track of, and archive, filled groups. For this convenience alone, automatic archiving is the choice of most database systems that have an archived redo log.

If automatic archiving is requested at instance startup, by setting the LOG_ARCHIVE_START parameter in the database's parameter file, ARCH is started during instance startup; otherwise, ARCH is not started during instance startup. However, the database administrator can interactively start or stop automatic archiving at any time. If automatic archiving was not specified to start at instance startup, and the administrator subsequently starts automatic archiving, the ARCH background process is created. ARCH then remains for the duration of the instance, even if automatic archiving is temporarily turned off and turned on again.

ARCH always archives groups in order, beginning with the lowest sequence number. ARCH automatically archives filled groups as they become inactive. A record of every automatic archival is written in the ARCH trace file by the ARCH process. Each entry shows the time the archive started and stopped.

If ARCH encounters an error when attempting to archive a group (for example, due to an invalid or filled destination), ARCH continues trying to archive the group. An error is also written in the ARCH trace file and the ALERT file. If the problem is not resolved, eventually all online redo log groups become full, yet not archived, and the system halts because no group is available to LGWR. Therefore, if problems are detected, you should either resolve the problem so that ARCH can continue archiving (such as by changing the archive destination) or manually archive groups until the problem is resolved.

Manual Archiving      If a database is operating in ARCHIVELOG mode, the database administrator can manually archive the filled groups of inactive online redo log files, as necessary, whether or not automatic archiving is enabled or disabled. If automatic archiving is disabled, the database administrator is responsible for archiving all filled groups.

For most systems, automatic archiving is chosen because the administrator does not have to watch for a group to become inactive and available for archiving. Furthermore, if automatic archiving is disabled and manual archiving is not performed fast enough, database operation can be temporarily suspended if LGWR is forced to wait for an inactive group to become available for reuse. The manual archiving option is provided so that the database administrator can:

•	archive a group when automatic archiving has been stopped because of a problem (for example, the offline storage device specified as archived redo log destination has experienced a failure or become full)

•	archive a group in a non-standard fashion (for example, one group to one offline storage device, the next group to a different offline storage device, etc.)

•	rearchive a group if the original archived version is lost or damaged

When a group is manually archived, the user process issuing the statement to archive a group actually performs the process of archiving the group; even if the ARCH background process is present for the associated instance, it is the user process that archives the group of online redo log files.

________________________________________

Control Files

The control file of a database is a small binary file necessary for the database to successfully start and operate. A control file is updated continuously by ORACLE during database use, so it must be available for writing whenever the database is open. If for some reason the control file is not accessible, the database will not function properly.

Each control file is associated with a single database; one control file cannot be associated with several ORACLE databases.

Control File Contents

A control file contains information about the associated database that is required for the database to be accessed by an instance, both at startup and during normal operation. A control file's information can only be modified by ORACLE; no database administrator or end-user can edit a database's control file.

Among other things, a control file contains information such as:

•	the database name

•	the timestamp of database creation

•	the names and locations of associated database and online redo log files

•	the current log sequence number

•	checkpoint information

The database name and timestamp originates at database creation. The database's name is taken from either the name specified by the initialization parameter DB_NAME or the name used in the CREATE DATABASE statement.

Each time that a data file or an online redo log file is added to, renamed in, or dropped from the database, the control file is updated to reflect this physical structure change. These changes are recorded so that:

•	ORACLE can identify the data files and online redo log files to open during database startup.

•	ORACLE can identify files that are required or available in case database recovery is necessary.

Therefore, if you make a change to your database's physical structure, you should immediately make a backup of your control file. See page 24 - 6 for information about backing up a database's control file.

Control files also record information about checkpoints. When a checkpoint starts, the control file records information to remember the next entry that must be entered into the online redo log. This information is used during database recovery to tell ORACLE that all redo entries recorded before this point in the online redo log group are not necessary for database recovery; they were already written to the data files. Checkpoints are described beginning on page 23 - 9.

Mirrored Control Files

Similar to online redo log files, ORACLE allows multiple, identical control files to be concurrently open and written for the same database. By storing multiple control files for a single database on different disks, you can safeguard against a single point of failure with respect to control files. If a single disk crashes that contained a control file, the current instance fails when ORACLE attempts to access the damaged control file. However, other copies of the current control file are available on different disks, so an instance can be easily restarted without the need for database recovery.

The permanent loss of all copies of a database's control file is a serious problem to safeguard against. If all control files of a database are permanently lost during operation (several disks fail), the instance is aborted and media recovery is required. Even so, media recovery is not straightforward if an older backup of a control file must be used because a current copy is not available. Therefore, it is strongly recommended that mirrored control files be used with each database; with each copy stored on different physical disks.


CHAPTER 24. DATABASE BACKUP

Then the grasshopper knew it is best to prepare for the days of necessity.

Aesop:  The Ant and the Grasshopper

This chapter explains the options available and the procedures necessary to backup the data in an ORACLE database.

 Topics include:

•	full and partial database backups

•	data file backups

•	online and offline tablespace and data file backup

•	consistent and fuzzy backup data

•	control file backups

•	Export and Import utilities

________________________________________

An Introduction to Database Backups

No matter what backup and recovery scheme you devise for an ORACLE database, operating system backups of the database's data files, redo log files, and control files are absolutely necessary as part of the strategy to safeguard against potential media failures that can damage these files. The following sections provide a conceptual overview of the different types of backups that can be made and their usefulness in different recovery schemes. The ORACLE7 Server Administrators Guide provides guidelines for performing database backups.

Full Backups

A full backup is an operating system backup of all data files, online redo log files, and the control file that constitute an ORACLE database. A full backup should also include the parameter file(s) associated with the database.

A full database backup is taken after the database is cleanly shut down; that is, it is not taken after an instance failure, etc. At this time, all of the files that constitute a database are closed and consistent with respect to the current point in time.

Note: A full backup cannot be taken while the database is open. Any file backed up while the database is open is considered a "partial backup," as described in the next section.

The data files obtained from a full backup are useful in any type of media recovery scheme:

•	If a database is operating in NOARCHIVELOG mode and a disk failure damages some or all of the files that constitute the database, the most recent full backup can be used to restore (not recover) the database. Because an archived redo log is not available to bring the database up to the current point in time, all database work performed since the full database backup must be repeated.

•	If a database is operating in ARCHIVELOG mode and a disk failure damages some or all of the files that constitute the database, the data files collected by the most recent full backup can be used as part of database recovery. After restoring the necessary data files from the full backup, database recovery can continue by applying archived and current online redo log files to bring the restored data files up to the current point in time.

In summary, if a database is operated in NOARCHIVELOG mode, a full backup is the only method to partially protect the database against a disk failure; if a database is operating in ARCHIVELOG mode, the files assembled by a full backup can be used to restore damaged files as part of database recovery from a disk failure.

Partial Backups

A partial backup is any operating system backup short of a full backup, taken while the database is open or shut down. The following are all examples of partial database backups:

•	a backup of all data files for an individual tablespace

•	a backup of a single data file

•	a backup of a control file

Partial backups are only useful for a database operating in ARCHIVELOG mode. Because an archived redo log is present, the data files restored from a partial backup can be made consistent with the rest of the database during recovery procedures.

 Data File Backups

A partial backup can include data files of a database. Individual or collections of specific data files can be backed up independently of the other data files, online redo log files, and control files of a database. A data file can be backed up while it is offline or online.

Choosing whether to take online or offline data file backups depends only on the availability requirements of the data--online data file backups are the only choice if the data being backed up must always be available. The following sections describe each type of data file backup.

Offline     Data File Backups   Any data file of a database can be backed up when the data file is offline. The following situations provide examples of offline data file backups:

•	A database is shut down. As a result, all data files of the database are normally closed or "offline."  If any data files of a shutdown database are backed up, these are considered offline data file backups.

•	A database is open, and a tablespace is offline. As a result, normally all data files of the tablespace are offline. If any data files of an offline tablespace are backed up, these are considered offline data file backups.

Note: In most situations, the above are examples of when offline data file backups can be taken. However, in certain circumstances, a database may be shutdown or a tablespace can be offline, but the associated data files are actually online with respect to the operating system. For example, a database may be mounted and closed for database recovery, but the associated data files are open and undergoing changes during the recovery operation. Avoid making data file backups in such situations.

When a database instance is shut down in normal priority; i.e., not aborted, or when a tablespace is taken offline in normal priority; i.e., not temporary or immediate, an offline data file backup is a copy of "consistent" data. All of the data within an offline data file backup is consistent with respect to a single point in time, the time of the backup.

Online     Data File Backups   If a database is operating in ARCHIVELOG mode, any data file of the database can be backed up while the database is open, while the associated tablespace is online, and while the specific data files are online and currently in normal use. This type of data file backup is considered an online data file backup.

An online data file backup is a copy of fuzzy data; all of the data within the online data file backup is not guaranteed to be consistent with respect to a specific point-in-time. However, a fuzzy data file backup is easily made consistent during database recovery procedures.

When the backup of an online tablespace (or individual data file) starts (as indicated by the SQL command ALTER TABLESPACE with the BEGIN BACKUP option), ORACLE stops recording the occurrence of checkpoints in the headers of the online data files being backed up. This means that when a data file is restored, it has "knowledge" of the most recent datafile checkpoint that occurred before the online tablespace backup, not any that occurred during it. As a result, ORACLE asks for the appropriate set of redo log files to apply should recovery be needed. Once an online backup is completed (as indicated by the SQL command ALTER TABLESPACE with the END BACKUP option), ORACLE advances the file header to the current database checkpoint.

Consistent and Fuzzy Backup Data      The data in data file backups can exist in two different states: consistent or fuzzy.

Consistent backup data is obtained when an offline data file is backed up. This data file must not be offline as the result of an I/O error or an immediate offline. The data in a single file is said to be "consistent" with itself because all blocks of data within it correspond to a specific point-in-time. You must still perform recovery actions if using a consistent backup to recover a database, as the backup is consistent only with itself, not with the current point in time.

A full or partial backup taken while the database is shut down, or the tablespace is offline, is used to restore data file(s) to a particular point-in-time. Because the data is already consistent, no action is required to make the data in the restored data files correct.

If a database is not shut down cleanly (e.g., an instance failure occurred or a SHUTDOWN ABORT statement was issued), the offline data files can be fuzzy.

If a data file is online or being recovered, the data file is said to be "fuzzy" or "inconsistent."  The files are fuzzy because blocks are not necessarily written in the order they are changed. Therefore, if an online data file is backed up, fuzzy data is copied because the data file is online and currently in flux.

A complete or partial database backup taken while the database is open and the tablespace is online is also used to restore data files to a particular point in time. However, the data in the restored data files is fuzzy. Therefore, the appropriate redo log files (online and archived) must be reapplied to these restored data files to make the data consistent.

Consider the following simplified example to understand how fuzzy backup data is generated, and then used during database recovery.

Example	A backup is being made of a data file of an online tablespace. The data file corresponds to four data blocks. For simplicity, a representative piece of data in each block is represented by a letter..

Refer to Figure 24 - 1. During this online data file backup, the following actions take place with respect to time.

1..	At the first instant in time, Block #1 of the data file is written to the backup file.

2..	At the second instant in time, Block #2 of the data file is written

 to the backup file. At the same time, a modified version of data block #1 was written from the SGA to the data file.

3..	At the third instant in time, Block #3 of the data file is written to the backup file.

4..	At the fourth instant in time, a modified version of database

 Block #4 is written from the SGA to the data file. This modified block is written to the backup file.

At least two redo entries were also generated because of the modifications to Blocks #1 and #4, as represented in Figure 24 - 2 .

If the backup file is used to restore the data file, the restored data file is inconsistent, as is. However, by applying the corresponding redo log entries, the following actions take place to make the data consistent:

1..	Block #1 will be updated from A to E.

2..	Block #4 is verified to contain the correct information (F).

Control File Backups

Another form of a partial backup is a control file backup. Because a control file keeps track of the associated database's physical file structure, a backup of a database's control file should be made every time a structural change is made to the database.

Mirrored control files safeguard against the loss of a single control file; however, if a disk failure damages the data files and incomplete recovery is desired, or a point-in-time recovery is desired, a backup of the control file that corresponds to the intended database structure should be used, not necessarily the current control file. Therefore, the use of mirrored control files is not a substitute for control file backups taken every time the structure of a database is altered.

The Export and Import Utilities

Export and Import are utilities used to move ORACLE data in and out of ORACLE databases. Export is a utility that writes data from an ORACLE database to operating system files in an ORACLE database format. Export files store information about schema objects created for a database. Import is a utility that reads Export files and restores the corresponding information into an existing database. Although Export and Import are designed for moving ORACLE data, they can also be used as a supplemental method of protecting data in an ORACLE database. Use of these utilities is described in the ORACLE7 Server Utilities User's Guide.


CHAPTER 25. DATABASE RECOVERY

You're worth what you saved, not the million you made.

John Boyle O'Reilly:  Rules of the Road

This chapter discusses the database recovery from instance and media failures. Topics include:

•	general recovery concepts

•	database buffers and the DBWR background process

•	the redo log and rolling forward

•	the rollback segments and rolling back

•	recovery from instance failure

•	recovery from media failure

•	complete media recovery

•	incomplete media recovery

________________________________________

Recovery Procedures

In every database system, the possibility of a system failure is always present. Should system failure occur, the database must be recovered as quickly, and with as little detrimental impact on users, as possible.

Recovering from any type of system failure requires:

1.	Determining what data structures are intact and which ones

 need recovery.

2.	Following the appropriate recovery steps.

3.	Restarting the database so that it can resume normal operations.

4.	Assuring that no work is lost nor incorrect data is in the database.

The goal is to return to normal as quickly as possible, and at the same time, insulate database users from any problems or the possibility of losing or duplicating work.

The recovery process varies depending on the type of failure and the files of the database affected by the failure.

________________________________________

Recovery Features

ORACLE offers several features to provide flexibility in recovery strategies:

•	recovery from system, software, or hardware failure

•	automatic database instance recovery at database start up

•	recovery of individual offline tablespaces or files while the rest of a database is operational

•	time-based and change-based recovery operations to recover to a transaction consistent state specified by the database administrator

•	increased control over recovery time in the event of

 system failure

•	Export and Import utilities for archiving and restoring data in a logical data format, rather than a physical file backup

________________________________________

An Introduction to Database Recovery

The following sections provide a brief summary of how ORACLE writes information to the data files in order to introduce the recovery structures and processes that are necessary to recover a database from any type of failure that can adversely affect a database.

For instructions on performing database recovery, see the ORACLE7 Server Administrator's Guide.

Database Buffers and DBWR

Database buffers in the SGA are written to disk only when necessary, using the least recently used algorithm. Because of the way that DBWR uses this algorithm to write database buffers to data files, data files might contain some data blocks modified by uncommitted transactions and some data blocks missing changes from committed transactions.

Two potential situations can result if an instance failure occurs:

•	Data blocks modified by a transaction might not be written to the data files at commit time and might only appear in the redo log. Therefore, the redo log contains changes that must be reapplied to the database during recovery.

•	Since the redo log might have also contained data that was not committed, the uncommitted transaction changes applied by the redo log (as well as any uncommitted changes applied by earlier redo logs) must be erased from the database.

To solve this dilemma, two separate steps are generally used by ORACLE for a successful recovery of a system failure: rolling forward with the redo log and rolling back with the rollback segments.

The Redo Log and Rolling Forward

The redo log is a set of operating system files that record all changes made to any database buffer, including data, index, and rollback segments, whether or not the changes are committed or uncommitted. The redo log protects changes made to database buffers in memory that have not been written to the data files.

The first step of recovery from an instance or disk failure is to roll forward, or reapply all of the changes recorded in the redo log to the data files. Because rollback data is also recorded in the redo log, rolling forward also regenerates the corresponding rollback segments.

Rolling forward proceeds through as many redo log files as necessary to bring the database forward in time. Rolling forward usually includes online redo log files, and may include archived redo log files.

After roll forward, the data blocks contain all committed changes as well as any uncommitted changes that were recorded in the redo log.

Rollback Segments and Rolling Back

Rollback segments record database actions that should be undone during certain database operations. In database recovery, rollback segments are used to undo the effects of uncommitted transactions applied previously by the rolling forward phase.

After the roll forward, any changes that were not committed must be undone. After redo log files have reapplied all changes made to the database, then the corresponding rollback segments are used. Rollback segments are used to identify and undo transactions that were never committed, yet were recorded in the redo log and applied to the database during roll forward. This process is called rolling back.

Figure 25 - 1 illustrates rolling forward and rolling back, the two steps necessary to recover from any type of system failure.

________________________________________

Recovery from Instance Failure

When an instance is aborted, either unexpectedly (for example, an unexpected power outage, a background process failure, etc.) or expectedly (for example, by issuing a SHUTDOWN ABORT statement or STARTUP FORCE statement), instance failure occurs, and instance recovery is required. Instance recovery restores a database to its transaction consistent state just prior to instance failure.

If you experience instance failure during online backup, media recovery might be required. In all other cases ORACLE automatically performs instance recovery for a database when the database is restarted (mounted and opened to a new instance). If necessary, the transition from a mounted state to an open state automatically triggers instance recovery, which consists of the following steps:

1.	Rolling forward to recover data that has not been recorded in the data files, yet has been recorded in the online redo log, including the contents of rollback segments.

2.	Rolling back transactions that have been explicitly rolled back or have not been committed, as indicated by the rollback segments regenerated in Step a.

3.	Releasing any resources (locks) held by transactions in process at the time of the failure.

4.	Resolving any pending distributed transactions undergoing a two-phase commit at the time of the instance failure.

________________________________________

Recovery from Media Failure

Media failure is a failure that occurs when a file, portion of a file, or a disk either cannot be read from, or cannot be written to, because it is damaged or missing; for example, the accidental erasure of a data file, or the loss of one or more files due to a disk head crash.

Recovery from a media failure can take two forms, depending on the archiving mode a database is operated in:

•	If a database is operated so that its online redo log is only reused and not archived, recovery from a media failure is a simple restoration of the most current full backup. All work performed after the full backup was taken must be manually redone, if desired, after the backup is used to restore the damaged database.

•	If a database is operated so that its online redo log is archived, recovery from a media failure can be an actual recovery procedure, to reconstruct the damaged database to a specified transaction consistent state prior to the media failure.

Recovery from a media failure, no matter what form, always recovers the entire database to a transaction consistent state prior to the media failure. It is not logical or possible to recover a part of a database (such as a tablespace) to one point-in-time, and recover (or leave untouched) another part of a database to a different point-in-time; otherwise, the database would not be in a transaction consistent state with respect to itself.

The following sections describe the different types of media recovery available if a database is operated in ARCHIVELOG mode: complete media recovery and incomplete media recovery.

Complete Media Recovery

Complete media recovery recovers all lost changes; no work is lost. Complete media recovery is possible only if all necessary redo logs (online and archived) are available.

Different types of complete media recovery are available, depending on the files that are damaged and the availability of the database that is required during recovery operations.

 Closed Database Recovery

Complete media recovery of all or individual damaged data files can proceed while a database is mounted but closed and completely unavailable for normal use. Closed database recovery is used in the following situations:

•	The database does not have to be open (i.e., the undamaged portions of the database do not have to be available for use).

•	Files damaged by the disk failure include one or more data files that constitute the SYSTEM tablespace or a tablespace containing active rollback segments.

 Open Database-Offline Tablespace Recovery

Complete media recovery can proceed while a database is open; undamaged tablespaces of the database are online and available for use, while a damaged tablespace is offline and all data files that constitute the damaged tablespace are being recovered as a unit. Offline tablespace recovery is used in the following situations:

•	Undamaged tablespaces of the database must be available for normal use.

•	Files damaged by the disk failure do not include any data files that constitute the SYSTEM tablespace or a tablespace containing active rollback segments.

 Open Database-Offline Tablespace-Individual Data File Recovery

Complete media recovery can proceed while a database is open; undamaged tablespaces of the database are online and available for use, while a damaged tablespace is offline and specific damaged data files that constitute the damaged tablespace are being recovered. Individual data file recovery is used in the following situations:

•	Undamaged tablespaces of the database must be available for normal use.

•	Files damaged by the disk failure do not include any data files that constitute the SYSTEM tablespace or a tablespace containing active rollback segments.

•	Multiple, concurrent SQL*DBA sessions are used to simultaneously recover individual damaged data files to expedite complete media recovery.

 Complete Media Recovery Using a Backup of the Control File

Complete media recovery can proceed without loss of data, even if all copies of the control file are damaged by a disk failure. Media recovery of datafile backups can be done even if the control file is a backup. The control file is not recovered by media recovery; but rather the RESETLOGS at database open recovers the control file.

 The Mechanisms of Complete Media Recovery

The mechanisms that ORACLE uses to perform any type of complete media recovery are best described using an example. The following is an example of complete media recovery of damaged data files while the database is open and a damaged tablespace is offline. Assume the following:

•	the database has three data files:

•	USERS1 and USERS2 are data files that constitute the USERS tablespace, stored on Disk X of the database server

•	SYSTEM is the data file that constitutes the SYSTEM tablespace, stored on Disk Y of the database server

•	Disk X of the database server has crashed

•	the online redo log file being written to at the time of the disk failure has a log sequence number of 31

•	the database is in ARCHIVELOG mode

Recovery of the two data files that constitute the USERS tablespace is necessary because Disk X has been damaged, and the system has automatically taken the tablespace offline. In this case, the data file of the SYSTEM tablespace is not damaged. Therefore, the database can be open with the SYSTEM tablespace online and available for use while recovery is completed on the offline tablespace needing recovery (USERS).

The following sections describe the phases of complete media recovery.

Phase 1: Restoration     of Backup Data Files   After Disk X has been repaired, the most recent backup files are used to restore only the damaged data files USERS1 and USERS2. After restoration, the data files of the database exist as illustrated in Figure 25 - 2.

Each data file header contains the most recent log sequence number being written at the time the data file was being written. The restored backup files will have earlier log sequence numbers than those of the data files that were not affected (not restored) by the disk crash. The control file contains a pointer to the last log sequence number that was written.

Phase 2: Rolling Forward with the Redo Log   As complete media recovery proceeds, ORACLE applies redo log files (archived and online) to data files, as necessary, as illustrated in Figure 25 - 3. ORACLE automatically detects when a redo log file does not contain any redo information corresponding to a restored backup data file; therefore, ORACLE optimizes the recovery process by not attempting to apply the redo log file to the restored data file.

In this case, the redo log file with the log sequence number of 12 is applied exclusively to USERS1, and the redo log files with log sequence numbers ranging from 13 to 31 are applied to both USERS1 and USERS2. No redo log files are applied to the data files that do not require recovery.

There is a flag in the header of the current redo logo that indicates that it is the last available redo log file to apply to the restored data files.

Phase 3: Rolling Back using     Rollback Segments   Once the necessary redo log files have been applied to the damaged data files, all uncommitted data that exists as a result of the roll forward in Phase 2 must be removed; this is completed by applying the deferred rollback segment as the tablespace is brought online, as illustrated in Figure 25 - 4.

After Phase 3 is complete, notice how the log sequence number contained in the data file headers of the previously damaged and restored data files, USERS1 and USERS2, have been updated during Phase 2 of the recovery process. The USERS tablespace can now be brought online. Deferred rollback segments are applied to the files of the offline tablespace as it is brought back online. Once the roll back is complete, the data files USERS1 and USERS2 exist as they did at the instant before the disk failure. Once this is complete, all data in the tablespace is now consistent and available for use.

Incomplete Media Recovery

In specific situations (e.g., the loss of all active online redo log files, or a user error, such as the accidental dropping of an important table), complete media recovery may not be possible or may not be desired. In such situations, incomplete media recovery is performed to reconstruct the damaged database to a transaction consistent state prior to the media failure or user error.

In most cases, unless desired, incomplete media recovery is not necessary if the online redo log has been mirrored, to protect against having a single point of failure.

There are different types of incomplete media recovery that might be used, depending on the situation that requires incomplete media recovery: cancel-based, time-based, and change-based incomplete recovery.

 Cancel-Based Recovery

In certain situations, incomplete media recovery must be controlled so that the administrator can cancel the operation at a specific point. Specifically, cancel-based recovery is used when one or more redo log groups (online or archived) have been damaged by a media failure and are not available for required recovery procedures (for example, the online redo log is not mirrored and the single active online redo log file has been damaged by a disk failure). If one or more redo log groups are not available, the missing redo log groups cannot be applied during recovery procedures. Therefore, media recovery must be controlled so the recovery operation is terminated after the most recent, undamaged redo log group has been applied to the data files.

 Time-Based and Change-Based Recovery

Incomplete media recovery is desirable if the database administrator would like to recover to a specific point in the past. This might be useful in the following situations:

•	A user accidentally dropped a table and noticed the approximate time that the error was committed. The database administrator can immediately shut down the database and recover it to a point-in-time just prior to the user error.

•	Part of an online redo log file (of a non-mirrored online redo log) might become corrupt due to a system failure. Therefore, the active online redo log file is suddenly unavailable; the database instance is aborted; and media recovery is now required. The redo entries in the most recently used online redo log file are valid up to the place that the corrupt data was written; later entries are invalid. Only the undamaged part of current online redo log file can be applied. In this case, the database administrator can use time-based recovery to stop the recovery procedure once the valid portion of the most recent online redo log file has been applied to the data files.

In both of these cases, the end-point of incomplete media recovery can be specified by a point-in-time or a specific system change number (SCN). An SCN is recorded in the redo log, along with the redo entries, each time that a transaction is committed. If a time is given, the database is recovered to the transaction consistent state just prior to the specified time. If an SCN is given, the database is recovered to the transaction committed just prior to the specified SCN.

 The Mechanisms of Incomplete Database Recovery

Incomplete database recovery operations proceed exactly the same as the phases of complete media recovery, with a few exceptions:

•	All data files must be restored using backup files completed before the intended point of recovery (the files could even come from different partial backups taken at different times). This way, the entire database is taken to a point-in-time before the recovery point and rolled forward to the intended point of recovery.

•	For best results, the control file used during incomplete media recovery should reflect the physical structure of the database for the intended time of recovery. If you open the database using the RESETLOGS option, or if you open the database after issuing a CREATE CONTROLFILE statement, ORACLE cross checks the control file with the current data dictionary. If any data files have been added to, or dropped from, the data dictionary, ORACLE updates the control file accordingly. Any other differences are reported by error messages.

•	Recovery might terminate before all the available redo is applied. The recovery operation can be canceled manually, or is terminated automatically when the stop point is reached.

•	If the database's log is reset as part of incomplete media recovery, all tablespaces containing data files that were offline (during the incomplete recovery) must be dropped, unless the tablespace was taken offline normally. Therefore, if you do not want to lose data corresponding to such tablespaces, restore the control file and bring the offline data files online before incomplete recovery.

•	If an incomplete media recovery is actually a complete recovery (for example, all available redo was applied because a future time or SCN was specified), the database may be opened without resetting the log sequence. However, after an incomplete media recovery is finished (or complete recovery using a backup control file), the current log sequence number for the database (as noted in all data files and control files) must be reset to 1. This operation invalidates the redo entries present in all online redo log files and archived redo log files. After the log sequence is reset, the database's log (both online and archived) exists as if it was just created and the online redo log files do not contain any redo entries yet. Figure 25 - 5 illustrates this concept.


APPENDIX A. NATIONAL LANGUAGE SUPPORT

This appendix describes features that enable ORACLE applications to operate with multiple languages using conventions specified by the application user. Topics include:

•	description of National Language Support (NLS) features

•	ORACLE NLS architecture

•	background: explanation of multiple-language issues

•	specifying language-dependent operation of applications

•	specifying character sets

________________________________________

What Does National Language Support Provide?

ORACLE's National Language Support allows users to interact with the database in their native language. It also allows applications to run in different language environments.

To achieve these goals, NLS provides:

•	support for processing data in the various character encoding schemes used by computer hardware:

•	both single-byte and multi-byte character encoding schemes

•	client and server can use different character encoding schemes in client/server environments, with transparent conversion of data between them

•	language-dependent operation of end-user applications:

•	ORACLE messages displayed in multiple languages

•	dates and numbers formatted using language and territory conventions

•	character data sorted according to alphabetic conventions

•	language-dependent operation specifiable for each session

The remainder of this appendix provides background on these issues and describes the mechanisms NLS provides to handle them.

________________________________________

ORACLE NLS Architecture

The NLS architecture has two components: language-independent functions and language-dependent data. The former provides generic language-oriented features; the latter provides data required to operate these features for a specific language.

Since the language-dependent data is separate from the code, the operation of NLS functions is governed by data supplied at runtime. New languages can be added and language-specific application characteristics can be altered without requiring any code changes. This architecture also enables language-dependent features to be specified for each session.

Language-dependent data is defined with the NLS*WorkBench. The NLS*WorkBench maintains a repository of methods for interpreting language-dependent input and methods for displaying language-dependent output. Once the characteristics of a new language are defined, the NLS*WorkBench generates the data files that implement support for the language. For a complete description of the NLS*WorkBench and its features, refer to the NLS*WorkBench Reference Guide.

________________________________________

Background Information

This section provides background information on the issues involved in multilingual applications, and shows how they are resolved by the National Language Support (NLS) features of the ORACLE Server. The remaining sections of this appendix discuss the specific parameters that control NLS operation.

Character Encoding Schemes

To understand how ORACLE deals with character data, it is important to understand the general features of character representation on computers. The appearance of a character on a terminal depends on the convention for character representation used by that terminal. When you press a character key on the keyboard, the terminal generates a numeric code specified by the character encoding scheme in use on that device. When the terminal receives a number representing a character, it displays the character shape specified by that encoding scheme.

Encoding schemes define the representation of alphabetic characters, numerals, and punctuation characters, together with codes that control terminal display and communication. A character encoding scheme (also known as a character set or code page), specifies numbers corresponding to each character that the terminal can display. Examples are 7-bit ASCII, EBCDIC Code Page 500, and Japanese Extended UNIX Code.

Many encoding schemes are used by hardware manufacturers to support different languages. All support the 26 letters of the Latin alphabet, A to Z. In general, single-byte encoding schemes are used for European languages and multi-byte encoding schemes for Asian languages.

Single-byte 7-bit encoding schemes can define up to 128 characters, and normally support just one language. The only characters defined in 7-bit ASCII are the 26 Latin alphabetic characters. Various other 7-bit schemes are used where certain characters (normally punctuation) in 7-bit ASCII are replaced with additional alphanumeric characters required for a specific language.

Single-byte 8-bit encoding schemes can define up to 256 characters, and normally support a group of languages. For example, ISO 8859/1 supports many West European languages.

Multi-byte encoding schemes are needed for Asian languages since these languages use thousands of characters. A double-byte encoding scheme can support up to 65536 characters. Some multi-byte encoding schemes use the value of the most significant bit to indicate if a byte represents a single-byte character or is the first or second byte of a double-byte character. In other schemes, control codes are used to differentiate single-byte from double-byte characters. A shift-out code indicates that the following bytes are double-byte characters until a shift-in code is encountered.

There are two general groups of encoding schemes, those based on 7-bit ASCII and those based on IBM EBCDIC. Within each group, all schemes normally use the same encoding for the 26 Latin characters (A to Z), but use different encoding for other characters used in languages other than English. ASCII and EBCDIC use different encodings even for the Latin characters.

Supported Character Sets

ORACLE's National Language Support features solve the problems that result from the fact that different encoding schemes use different binary values to represent the same character. With NLS, data created with one encoding scheme can be correctly processed and displayed on a system that uses a different encoding scheme.

The following table shows some of the many encoding schemes that are supported. To find out which encoding schemes are available on your system, consult your user's or installation guide.

Encoding Scheme	Description

AR8ISO8859P6	ISO 8859-6 Latin/Arabic Character Set

AR8ISO8859P8	ISO 8859-8 Latin/Hebrew Character Set

CGB2312-80	Chinese GB2312-8

CL8ISO8859P5	ISO 8859-5 Latin/Cyrillic Character Set

CNS11643-86	Taiwan Traditional Chinese

EE8ISO8859P2 	ISO 8859-2 East European Character Set

EL8ISO8859P7	ISO 8859-7 Latin/Greek Character Set

JA16DBCS 	Japanese IBM

JA16EUC	Japanese Extended UNIX Code

JA16HP             	Japanese HP

JA16SJIS            	Japanese Shift-JIS

JA16VMS            	Japanese VMS Kanji

K016DBC	Korean IBM

K016KSC5601         	Korean KSC5601

SE8ISO8859P3    	ISO 8859-3 South European Character Set

SE8ISO8859P4	ISO 8859-4 North/North-east European Character Set

US7ASCII	7 Bit U.S. ASCII Standard Character Set

US8PC437	IBM PC's 8 Bit American Character Set Code Page 437

WE8DEC	DEC's 8 Bit West European Character Set

WE8EBCDIC37	West European 8-bit EBCDIC Code Page 00037

WE8EBCDIC500	West European 8-bit EBCDIC Code Page 00500

WE8ISO8859P1	ISO 8859-1 West European Character Set

WE8ISO8859P9	ISO 8859-9 West European (+Turkish) Character Set

WE8MACROMAN8	Macintosh Extended ROMAN8 Character Set

WE8PC850        	IBM PC's 8 Bit West European Character Set

WE8ROMAN8	HP 8 Bit West European Character Set

________________________________________

Language-Dependent Application Behavior

Setting the values of various NLS parameters allows applications to function in a language-dependent manner. The language-dependent functions controlled by NLS include:

•	language to use for messages and boilerplate text

•	number format

•	date format

•	currency format

•	starting day of the week

 Messages and Text

All messages and text should be in the same language. For example, when running a SQL*Forms application, messages and boilerplate text seen by the user originate from three sources:

•	messages from the Server

•	messages and boilerplate text generated by SQL*Forms

•	messages and boilerplate text defined as part of the application

The application is responsible for meeting the last requirement. NLS takes care of the other two.

 Number Format

The database needs to know the number-formatting convention used in each session, in order to interpret numeric strings correctly. For example, the database needs to know whether numbers are entered with a period or a comma as the decimal character (234.00 or 234,00). In the same vein, the application needs to be able to display numeric information in the format expected at the client site.

 Date Format, Currency Symbols, and First Day of the Week

Similarly, date and currency information need to be interpreted properly when they are input to the Server, and formatted in the expected manner when output to the user's terminal. These functions are all controlled by NLS parameters described later in this appendix.

Sorting Character Data

 Conventionally, when character data is sorted, the sort sequence is based on the numeric values of the characters defined by the character encoding scheme. Such a sort is called a binary sort. Such a sort produces reasonable results for the English alphabet because the ASCII and EBCDIC standards define the letters A to Z in ascending numeric value.

Note however, that in the ASCII standard all uppercase letters appear before any lowercase letters. In the EBCDIC standard, the opposite is true: all lowercase letters appear before any uppercase letters.

When characters used in other languages are present, a binary sort generally does not produce reasonable results. For example, an ascending ORDER BY query would return the character strings ABC, ABZ, BCD, Ä BC, in that sequence, when the Ä  has a higher numeric value than B in the character encoding scheme.

In order to produce a sort sequence that matches the alphabetic sequence of characters for a particular language, another sort technique must be used that sorts characters independently of their numeric values in the character encoding scheme. This technique is called a linguistic sort. A linguistic sort operates by replacing characters with other binary values that reflect the character's proper linguistic order, so that a binary sort returns the desired result.

ORACLE provides both sort mechanisms. Linguistic sort sequences are defined as part of language-dependent data. Each linguistic sort sequence has a unique name. NLS parameters define the sort mechanism used for ORDER BY queries. A default value can be specified, and this value can be overridden for each session with the NLS_SORT parameter.

 Linguistic Special Cases

Linguistic special cases are character sequences that need to be treated as a single character when sorting. Such special cases are handled automatically when using a linguistic sort. For example, one of the linguistic sort sequences for Spanish specifies that the double characters ch and ll are sorted as single characters appearing between c and d and between l and m respectively.

Another example is the German-language sharp s (ß ). The linguistic sort sequence German can sort this sequence as the two characters SS, while the linguistic sort sequence Austrian sorts it as SZ.

Special cases like these are also handled when converting uppercase characters to lowercase, and vice versa. For example, in German the uppercase of the sharp s is the two characters SS. Such case-conversion issues are handled by the NLS_UPPER, NLS_LOWER and NLS_INITCAP functions, according to the conventions established by the linguistic sort sequence. (The standard functions UPPER, LOWER, and INITCAP do not handle these special cases.)

________________________________________

Specifying Character Sets

The character encoding scheme used by the database is defined at database creation as part of the CREATE DATABASE statement. All data columns of type CHAR, VARCHAR2, and LONG, including columns in the data dictionary, have their data stored in the database character set. In addition, the choice of character set determines which characters can be used to name objects in the database.

Once the database is created, the database character set cannot be changed without re-creating the database. Hence, it is important to consider carefully which character set to use. The database character set should always be a superset or equivalent of the operating system's native character set. The character sets used by client applications that access the database will usually determine which superset is the best choice.

When a client application operates with a terminal that uses a different character set, then the client application's characters must be converted to the database character set, and vice versa. This conversion is performed automatically, and is transparent to the client application. The character set used by the client application is defined by the NLS_LANG parameter.

Character Set Conversion

Where a character exists in both source and destination character sets, conversion presents no problem. However, data conversion has to accommodate characters that do not exist in the destination character set. In such cases, replacement characters are used. The source character is replaced by a character that does exist in the destination character set.


APPENDIX B. OPERATING SYSTEM SPECIFIC INFORMATION

This Guide occasionally refers to other ORACLE manuals that contain detailed information for using ORACLE on a specific operating system. These ORACLE manuals are often called installation or user's guides, although the exact name may vary on different operating systems. Throughout this guide, references to these manuals are marked with the icon shown in the left margin.

This appendix lists all the references in this guide to operating system specific ORACLE manuals, and lists the operating system (OS) dependent initialization parameters. If you are using ORACLE on multiple operating systems, this appendix can help you ensure that your applications are portable across these operating systems.

Operating system specific topics are listed alphabetically, with page numbers of sections that discuss these topics.

Topic	Page

Authentication of users through operating system	17 - 3

Background Processes

       creating	9 - 5

       multiple DBWR processes	9 - 9

       using ARCH	9 - 12

Character sets, available	A - 5

Client/server communication	9 - 30

Communication Software	9 - 38

Configuring ORACLE	9 - 26

Database links

       connect string	21 - 20, 21 - 21

       and network domain service	21 - 18

       remote operating system authentication 	21 - 24

Dedicated Server, requesting	9 - 34

Indexes, overhead of index blocks	5 - 16

INTERNAL, prerequisites for connecting as	2 - 2

PGA, size of	9 - 23

Roles, operating system management of	18 - 15

Rollback segments, number of transactions per	3 - 17

Software code areas, shared	9 - 15

SQL *Net

      choosing and installing drivers	9 - 37

       including drivers	20 - 5