Oracle9i Database Product Overvieww
Oracle9i Database Product Overvieww
Overview
Student Guide
D12862GC10
Production 1.0
October 2001
D33985
Authors Copyright © Oracle Corporation, 2001. All rights reserved.
Oracle and all references to Oracle Products are trademarks or registered trademarks
of Oracle Corporation.
All other products or company names are used for identification purposes only, and
may be trademarks of their respective owners.
Contents
Introduction
Lesson Overview - Unit 1 Fundamentals I-2
Lesson Overview - Unit 2 Optional Lessons I-3
Lesson Overview - Unit 3 Appendixes I-4
DBMS Application Types I-5
iii
3 Oracle9i Database Objects
Objectives 3-2
iv
Database Components 4-6
Objectives 5-2
v
6 User and Data Security Management
Objectives 6-2
7 Oracle9i Optimizer
Objectives 7-2
vi
Statistics Management 7-10
8 Transactions
Objectives 8-2
XA Architecture 8-14
Objectives 9-3
vii
Relational and Object Tables 9-7
10 Globalization Support
Objectives 10-2
Objectives 11-2
Partitioning 11-3
viii
Partitioned Tables and Indexes 11-8
Objectives 12-2
Restore 12-7
ix
Datafile Recovery 12-11
Objectives 13-2
SQL*Loader 13-8
B Oracle 9i Replication
x
Oracle9i Database: Product Overview
Lesson Overview - Unit 1 Fundamentals
• Networking
• Replication
• Content management for the Internet
Objectives
This first lesson introduces the basic concepts you need to know to understand the
foundation of the relational theory.
CARS
RegNr Brand Color Model
...
Tables
A relation is a mathematical representation of a set of rows. This is called a table in an
RDBMS. A table is the logical implementation of a relation. In a later lesson, you learn that
inside Oracle, the physical implementation of a table is called a data segment.
A table has two dimensions, rows and columns. Each column in a table contains values that
are a subset of a corresponding domain and each row in a table represents an element of the
Cartesian product of all domains. The intersection of a column with a row is called a field or
column value.
In reality, things are done in the opposite order in an Oracle9i database. You start by
creating a table and then populate it with rows. Oracle does not implement the domain
concept. When creating a table, you associate each column with one of the Oracle built-in
data types, for example, NUMBER, VARCHAR, DATE, or with a user-defined data type.
Tables are the basis and central object of any RDBMS.
Using the ANSI/ISO standard SQL language, you are able to perform basic tasks, such as
creating a table, selecting a subset of the rows, a subset of the columns, intersection, union,
and join. The next lesson discusses SQL and other data access languages and interfaces.
Missing Information
Each database management system needs a consistent way to represent missing information.
The relational model uses NULL values for that purpose. A database language needs a
consistent way to treat those NULL values, which implies a three-valued logic. For example,
if a certain EMPLOYEE row does not have a SALARY value associated, you do not know
whether it is higher or lower than a certain amount: logical statements or conditions can be
true, false, or unknown.
Because the relational model only supports one way to represent missing information, you
cannot distinguish between possible reasons why a certain value is missing. For example, a
fax number can be missing because somebody does not have a fax at all, or just because you
do not know the number, or even because you do not know whether somebody has a fax. In
fact, some years ago Ted Codd, the father of the relational model, proposed a four-valued
logic with two different NULL values: applicable and inapplicable. Because this would add
complexity without resolving the problem, it will probably never be implemented.
The best approach is to try to avoid as much missing information as possible, in particular
missing information of the inapplicable type, by modeling your database correctly.
Integrity Constraints
Because databases are supposed to model the real world, you need the ability to define rules.
These rules are called integrity constraints. Of course, you can implement such rules in your
application code, but you also need to be able to define them as an integral part of the
logical database model.
There are three constraint levels:
• Attribute or column level: for example, salaries must be positive numbers, the hire-date
is a mandatory attribute (you do not allow missing information)
• Table level: for example, each row needs a unique column or column combination that
uniquely identifies that row (also called the primary key)
• Database level: for example, employees must be related with an existing department
(also called referential integrity), or orders should have at least one associated order item
You also can distinguish between static and dynamic integrity constraints. Static integrity
constraints describe valid database states, as in all of the examples above, and dynamic
integrity constraints describe valid database state transitions. For example, only salary raises
are allowed, or a new status of divorced is only allowed when the current status is married.
INSERT CREATE
UPDATE DROP
GRANT
DELETE REVOKE RENAME
ALTER
SELECT
SQL Language
Structured Query Language (SQL) is the language with which all programs and users access
data in an Oracle database. Application programs and Oracle tools often allow users to access
the database without using SQL directly, but these applications in turn must use SQL when
executing user requests.
SQL lets you work with data at the logical level. You need to be concerned with the
implementation details only when you want to manipulate the data. For example, to retrieve a
set of rows from a table, you define a condition used to filter the rows. All rows satisfying the
condition are retrieved in a single step and can be passed as a unit to the user, to another SQL
statement, or to an application. You need not deal with the rows one by one, nor do you have to
worry about how they are physically stored or retrieved. All SQL statements use the optimizer,
a part that determines the most efficient means of accessing the specified data. Oracle9i also
provides techniques you can use to enhance optimizer performance. SQL provides statements
for a variety of tasks, including: querying data, inserting, updating, deleting rows in a table,
creating, replacing, altering, and dropping objects, and controlling access to the database and
its objects.
With Oracle9i, you can also perform multitable inserts and merge rows from one table into
another. This means that you can either update an existing row or insert and merge rows.
Problems EXECPTION
Handling WHEN OTHERS THEN -- PL/SQL Handler
COMMIT;
END;
PL/SQL Language
A good way to get acquainted with PL/SQL is to look at a sample program. This example
program processes an order for tennis rackets. First, it declares a variable of type NUMBER to
store the quantity of tennis rackets on hand. Then, it retrieves the quantity on hand from a
database table named inventory. If the quantity is greater than zero, the program updates
the table and inserts a purchase record into another table named purchase_record.
Otherwise, the program inserts an out-of-stock record into the purchase_record table.
With PL/SQL, you can use SQL statements to manipulate Oracle data and flow-of-control
statements to process the data. Moreover, you can declare constants and variables, define
procedures and functions, and trap runtime errors. Thus, PL/SQL combines the data
manipulating power of SQL with the data processing power of procedural languages.
PL/SQL is a block-structured language. That is, the basic units (procedures, functions, and
anonymous blocks) that make up a PL/SQL program are logical blocks, which can contain any
number of nested sub-blocks. Typically, each logical block corresponds to a problem or
subproblem to be solved. Thus, PL/SQL supports the divide-and-conquer approach to problem
solving called stepwise refinement.
A block (or sub-block) lets you group logically-related declarations and statements. That way,
you can place declarations close to where they are used. The declarations are local to the block
and cease to exist when the block completes.
In Oracle9i, PL/SQL can be native compiled, giving better performance for large applications.
3GL statement;
Procedural
EXEC SQL... calls
3GL statement; produced
3GL statement; by the
EXEC SQL... precompiler
3GL statement;
SQLLIB
Runtime
Library
Data
Host language
application
3GL statement;
CALL OCI;
Direct OCI
3GL statement; procedural Runtime
3GL statement; calls Library
CALL OCI;
3GL statement;
Data
Calls to OCI
The Oracle Call Interface (OCI) is an application programming interface (API) that allows you
to create applications that use the native procedures or function calls of a third-generation
language to access an Oracle database server and control all phases of SQL statement
execution. OCI supports the data types, calling conventions, syntax, and semantics of a number
of third-generation languages, including C, C++, COBOL and FORTRAN.
Using Oracle Call Interface (OCI), you can make procedural calls to OCI library functions
directly from the host language source code. You compile and link the program in the same
way that you compile and link a nondatabase application. There is no need for a separate
precompilation step.
OCI provides significant advantages over other methods of accessing an Oracle database:
• More fine-grained control over all aspects of the application design
• Use of familiar 3GL programming techniques and application development tools such as
browsers and debuggers
• Ability to associate a commit request with an execute to reduce roundtrips
• Optimization for queries using transparent pre-fetch buffers to reduce roundtrips
• Thread safety so you do not have to use mutually exclusive locks (mutex) on OCI
handles
• Scrollable cursors so you can go anywhere in an open cursor
Oracle ODBC
driver
Oracle9i OCI
layer
Oracle9i Net
layer
2 Listener
process
3
extproc
1 process
5
4
PL/SQL Alias
subprogram library
External
procedure Shared library
External Procedures
An external procedure is a 3GL routine that can perform special purpose processing. You call
the external procedure from within PL/SQL or SQL. This is accomplished through a library
schema object, which is called from PL/SQL, that contains the compiled library filename that
is stored on the operating system.
Callouts and callbacks can also be referred to as an external procedure.
The interactions between the operating system and the database are designed to provide safe
callouts. Although it is possible to create callouts that could damage the instance or database,
the external procedure feature is not intended to be used in that manner.
The external procedure call enables you to invoke an external procedure using a PL/SQL
program unit. Additionally, you can integrate the powerful programming features of 3GLs with
the ease of data access of SQL and PL/SQL commands.
The external procedure can be set up to use a specific extproc process. This extproc
process can be on a different machine from the database.
Extensibility allows you to extend the database and to provide backward compatibility. For
example, you can invoke different index or sorting mechanisms as an external procedure, or
call data cartridges.
Oracle9i
• 2 ways to access SQL:
– JDBC
EJB CORBA
services services – SQLJ
IIOP
• 3 protocols:
EJB TS
Java VM
HTTP – Oracle Net, HTTP, IIOP
ORB
• 4 programming models:
HTTP
– Java stored procedures
JDBC SQLJ
Thin – Enterprise JavaBeans
JDBC – CORBA
SQL
PL/SQL – Java Server Pages
Oracle Net
Browser: Applets
Oracle9i
Java stored procedures
JDBC Thin Enterprise Java Beans
CORBA Servers
Java Sockets Server Java VM
SQL Thin JDBC
PL/SQL
Internal JDBC
JDBC OCI
Database
libraries
OCI C Lib
Oracle
• LOB storage:
– Unstructured data
– Binary or character
– Size to 4 GB Directory
– Special concurrency
• Storage method: LOB
Photo path
– Internal: database Recipe (BLOB)
(CLOB)
– External: OS files
Movie
(BFILE)
Collections
A collection is an object that contains other objects, where each contained object is of the
same type. Collection types are parameterized data types.
Collection types are arrays (VARRAY data type) and nested tables.
VARRAYs can be used to hold lists of objects, REFs, or scalar data types. They are
primarily useful in dealing with small sets, where individual elements need not be
manipulated through SQL.
Nested tables are used where large sets of data need to be placed within a parent table and
are typically useful there is a master-detail relationship, where for a given master row, there
could be many detailed rows.
With Oracle9i Database, it is possible to use multilevel collections. Multilevel collection
types are collection types where the collection element itself is directly or indirectly another
collection type. This means that one collection can be contained in another and this can
occur in several levels. This is usesful when working with the object-oriented approach in
application development.
Index entry
Root
Branch
B*-Tree Indexes
Indexes are optional structures associated with tables and clusters. You can create indexes
on one or more columns of a table to speed SQL statement execution on that table. Just as an
index in any manual helps you locate information faster than if there were no index, an
Oracle index provides a faster access path to table data. Indexes are the primary means of
reducing disk I/O when properly used.
Oracle provides several indexing schemes, which provide complementary performance
functionality: B*-tree indexes (currently the most common), B*-tree cluster indexes, hash
cluster indexes, reverse key indexes, and bitmap indexes. Oracle also provides support for
function-based indexes and domain indexes specific to an application or cartridge.
The absence or presence of an index does not require a change in the wording of any SQL
statement. Given a data value that has been indexed, the index points directly to the location
of the rows containing that value.
Oracle automatically maintains and uses indexes after they are created. Oracle automatically
reflects changes to data, such as adding new rows, updating rows, or deleting rows, in all
relevant indexes with no additional action by users.
Oracle uses B*-tree indexes that are balanced to equalize access times to any row. 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.
Inte RDBMS
Vio grity DEPARTMENTS
SQL lati
on s
DEPTNO DNAME
SQL 35 Accounting
EMPLOYEES
EMPNO MGR DEPTNO PROJECT
5540 Smith 35 108392
7935 PROJ
5892
PROJNO BUDGET DEPTNO
8100
462340 225000.00 54
942384 10000.00 35
402933 35000.00 28
108392 20509.00 50
Data Integrity
It is important that data adhere to a predefined set of rules, as determined by the database
administrator or application developer. This section describes the rules that can be applied to
table columns to enforce different types of data integrity.
• Nulls: A null is a rule defined on a single column that allows or disallows inserts or
updates of rows containing a null (the absence of a value) in that column.
• Unique Column Values: A unique value defined on a column (or set of columns) allows
the insert or update of a row only if it contains a unique value in that column (or set of
columns).
• Primary Key Values: A primary key value defined on a key (a column or set of columns)
specifies that each row in the table can be uniquely identified by the values in the key.
• Referential Integrity: A rule defined on a key (a column or set of columns) in one table
that guarantees that the values in that key match the values in a key in a related table (the
referenced value). Referential integrity also includes the rules that dictate what types of
data manipulation are allowed on referenced values and how these actions affect
dependent values.
• Check: Constraints enable you to enforce very specific or sophisticated integrity rules by
specifying a check condition. The condition of a CHECK constraint needs to be static.
• Trigger: Oracle also allows you to enforce integrity rules with a nondeclarative approach
using database triggers.
You can disable integrity constraints temporarily so that large amounts of data can be loaded
without the overhead of constraint checking.
Constraint Features
By default, constraints are checked immediately. If a constraint is violated, the statement is
rolled back. In Oracle9i, you can also defer constraint checking until the end of your
transaction.
By default, the table data is checked when you enable a constraint. You can choose to enable
a constraint (checking new DML against the table) without validating the current data. This
avoids locking, and allows concurrent DML while enabling the constraint.
When you disable a constraint, the data is not checked by default. However, you can
DISABLE VALIDATE a constraint, which means that the constraint is disabled and
associated indexes can be dropped while the constraint is kept valid. So you can have index-
less constraints; further DML is not allowed. This is a very useful feature in large (read-
only) data warehouses.
For unique or primary key indexes, Oracle9i needs to create or make use of an existing
index in order to check for uniqueness. If violations occur during the building or reuse of an
index, the constraint cannot be validated.
The RELY flag provides a mechanism to indicate that you believe that a given constraint is
true, without actually having to require that the database verifies this. This feature is used
internally by the summary management facility and query rewrites.
Database Triggers
Oracle allows you to define procedures called triggers that execute implicitly when an
INSERT, UPDATE, or DELETE statement is issued against the associated table (or, in some
cases, against a view) or when database system actions occur. These procedures can be
written in PL/SQL or Java and stored in the database, or they can be written as C callouts.
A trigger stored in the database can include PL/SQL or Java statements to execute as a unit
and can invoke stored procedures. However, procedures and triggers differ in the way that
they are invoked. A procedure is explicitly executed by a user, application, or trigger.
Triggers (one or more) are implicitly fired (executed) by Oracle when a triggering event
occurs, no matter which user is connected or which application is being used. The example
above shows a database application with a SQL statement that implicitly fires a trigger
stored in the database.
A triggering event or statement is the SQL statement, database event, or user event that
causes a trigger to be fired. A triggering event can be one or more of the following:
• An INSERT, UPDATE, or DELETE statement on a specific table (or view, in some
cases)
• A CREATE, ALTER, or DROP statement on any schema object
• A database startup or instance shutdown
• A specific error message or any error message
• A user logon or logoff
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 ORDERS and ORDER_ITEMS table share the ORDER_ID column. When you
cluster the ORDERS and ORDER_ITEMS tables, Oracle physically stores all rows for each
order from both the ORDERS and ORDER_ITEMS tables in the same data blocks.
The Cluster Index
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, Oracle accesses a given row with a minimum of two I/Os.
Hash Clusters
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. Oracle
physically stores the rows of a table in a hash cluster and retrieves them according to the
results of a hash function. The key of a hash cluster (like the key of an index cluster) can be
a single column or composite 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.
Table File 3
Index Block 10
Block 11
Block 12
Start End
Key ROWID ROWID Bitmap
<Blue, 10.0.3, 12.8.3, 100010000 010000000 010010100>
<Green, 10.0.3, 12.8.3, 000101000 000000000 100100000>
<Red, 10.0.3, 12.8.3, 010000000 001100000 000001001>
<Yellow, 10.0.3, 12.8.3,001000000 100000000 001000010>
Bitmap Indexes
The purpose of an index is to provide pointers to the rows in a table that contain a given key
value. In a regular index, this is achieved by storing a list of ROWIDs for each key
corresponding to the rows with that key value. In a bitmap index, a bitmap for each key
value is used instead of a list of ROWIDs. Each bit in the bitmap corresponds to a possible
ROWID, and if the bit is set, it means that the row with the corresponding ROWID contains
the key value. A mapping function converts the bit position to an actual ROWID, so the
bitmap index provides the same functionality as a regular index even though it uses a
different representation internally. If the number of different key values is small, bitmap
indexes are very space efficient. Bitmap indexing efficiently merges indexes that correspond
to several conditions in a WHERE clause. Rows that satisfy some, but not all conditions are
filtered out before the table itself is accessed. This improves response time, often
dramatically.
10.8000.3
<Rognes, 1.2.3, 10.8000.3, 100010010010100…>
<Aix-en-Provence, 1.2.3, 10.8000.3, 000101000100000…>
<Marseille, 1.2.3, 10.8000.3, 010000001000001…>
< ..., ..., ... , ... …>
• Function-based indexes:
Based on expressions or functions
• Descending indexes:
Avoid sorting
Function-Based Indexes
Function-based indexes can be useful in several cases:
• When the SELECT list uses expressions that can be materialized as a function-based
index value
• When the WHERE clause contains expressions, as shown in the example, to avoid full
table scans
• While using different NLS collating sequences
Function-based indexes can use any function or object method that is declared as repeatable.
That is, the returned value cannot change for a given set of input values.
Descending Indexes
In Oracle9i, indexes can also be stored in descending order of key values. This is, for
example, useful for concatenated indexes where you frequently sort ascending on the first
column and descending on the second column.
Note that the DESCENDING keyword has always been supported by Oracle for
compatibility reasons; however, it was ignored until Oracle8i.
View STAFF
Empno Ename Job Hiredate Deptno
----- ----- ----- -------- ------
7329 SMITH CLERK 17/12/88 20
7499 ALLEN SALES 20/02/88 30
7521 WARD SALES 22/02/88 30
7566 JONES CLERK 02/04/88 40
Views
A view is a tailored presentation of the data contained in one or more tables. A view takes
the output of a query and treats it as a table. Therefore, a view can be thought of as a stored
query or a virtual table. You can use views 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.
Since views are derived from tables, they have many similarities. You can query views, and
with some restrictions you can update, insert into, and delete from views. All operations
performed on a view actually affect data in some base table of the view and are subject to
the integrity constraints and triggers of the base tables.
Unlike a table, a view is not allocated any storage space, nor does a view actually contain
data; rather, a view is defined by a query that extracts or derives 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. 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.
Views can be used as restricted windows on your data and so it can secure access to them
and also simplify their access.
An inline view is not a schema object, but rather it is a subquery with an alias (correlation
name) that you can use like a view within a SQL statement.
A materialized view:
• Is an instantiation of a SQL statement
• Has its data stored in tables, offering:
– Space management options
– Use of indexes and partitions
• Can be compared to an index in many ways
• Used for:
– Data warehouses
– Distributed computing
–…
Materialized Views
One technique commonly used to improve performance is the creation of materialized
views. Materialized views are objects that improve query execution times by precalculating
expensive joins and aggregation operations prior to execution, and storing the results in a
database table. For example, a table T could be created to contain the sum of sales by region
and by product. If a database application needs to retrieve the sum of sales by region and by
product, it is more efficient to directly query T than to access the SALES table. However,
this manual technique has at least two disadvantages:
• The database application needs to be aware of table T.
• It is possible that table T does not reflect reality. (What if one modifies SALES?)
Oracle9i automates these processes by using materialized views. When the end-user
application executes queries, the Oracle optimizer may transparently rewrite the SQL query
to use the materialized view (analog to indexes). This mechanism significantly improves the
response time and eliminates the need for database applications to be aware of precreated
materialized views. Materialized views can be refreshed automatically, ensuring that both
materialized views and database tables are synchronized.
For more information on materialized views, see Oracle9i Business Intelligence and
Oracle9i Replication lessons.
ROWID + data of
indexed columns
Data by
Primary Key
Data
Index-only table
Heap table/index
Index-Organized Tables
An index-organized table differs from an ordinary table (called a heap table) in that the data
for the table is held in its associated index. Changes to the table data, such as adding new
rows, updating rows, or deleting rows, result only in updating the index.
The index-organized table is like an ordinary table with an index on one or more of its
columns, but instead of maintaining two separate storages for the table and the B*-tree
index, the database system only maintains a single B*-tree index which contains both the
encoded key value and the associated column values for the corresponding row. Rather than
having a row’s ROWID as the second element of the index entry, the actual data row is
stored in the B*-tree index. The data rows are built on the primary key for the table, and
each B*-tree index entry contains
<primary_key_value, non_primary_key_column_values>
Index-organized tables are suitable for accessing data by the primary key or any key that is a
valid prefix of the primary key. There is no duplication of key values because only non-key
column values are stored with the key. You can build secondary indexes to provide efficient
access by other columns. Applications manipulate the index-organized table just like an
ordinary table, using SQL statements. However, the database system performs all operations
by manipulating the corresponding B*-tree index.
In order to keep the B*-tree structures small and efficient, index-organized tables normally
have an overflow segment, especially if the rows are quite long. You can define which part
of the row should be stored into the B*-tree, and which part should go to the overflow
segment.
External Tables
Oracle9i’s external table feature allows you to use external data as a virtual table that can be
queried and joined directly and in parallel without requiring the external data to be first
loaded in the database
External tables are like regular SQL tables with the exception that the data is read-only and
does not reside in the database, thus the organization is external. As a result, the external
table acts as a view. The metadata for the external table is created using the CREATE
TABLE … ORGANIZATION EXTERNAL statement.
No DML operations are possible and no indexes can be created on them.
The CREATE TABLE … ORGANIZATION EXTERNAL operation involves only the
creation of metadata in the Oracle Dictionary since the external data already exists outside
the database in text files. Once the metadata is created, the external table feature enables the
user to easily perform parallel extraction of data from the specified external sources.
External Tables utilizes SQL*Loader functionality. The arguments given when creating an
external table are similar to those found in SQL*Loader control files.
Table Functions
In the ETL process, the data extracted from a source system passes through a sequence of
transformations before it is loaded into a data warehouse. A large class of user-defined
transformations are implemented in a procedural manner, either outside the database or
inside the database in PL/SQL. The table functions in Oracle9i provide support for pipelined
and parallel execution of such transformations implemented in PL/SQL, C, or Java.
Using Table Functions avoids intermediate staging tables, which interrupt the data flow
through the various transformation steps.
External tables enable the pipelining of the loading phase with the transformation phase. The
transformation process can be merged with the loading process without any interruption of
the data streaming. It is no longer necessary to stage the data inside the database for
comparison or transformation.
Traditional method
Oracle method
with sequences
User
process Time
Package Procedure A
specification declaration
Procedure B
definition
Package
body
Procedure A
definition
Local
variable
Packages
Packages bundle related PL/SQL types, items, and subprograms structures into one
container. For example, a r package might contain hiring and firing procedures, commission
and bonus functions, and tax exemption variables.
Usually a package has a specification and a body, stored separately in the database.
The specification is the interface to your applications. It declares the types, variables,
constants, exceptions, cursors, and subprograms available for use.
The body fully defines cursors and subprograms, and so implements the specification.
The package itself cannot be called, parameterized, or nested. Still, the format of a package
is similar to that of a subprogram. Once written and compiled, the contents can be shared by
many applications.
When calling a packaged PL/SQL construct for the first time, the whole package is loaded
into memory. Therefore, later calls to related constructs require no disk I/O.
Because all packages in Oracle9i can be native-compiled, performance is increased as
compared to the traditional method. This is done by translating the package to C code, and
then compiling that C code and mapping it into the database again. All of this is done from
within the database.
DEQUEUE
ENQUEUE
Queues
In client/server environments, requests are executed immediately. This is often called online
or connected execution of work. However, there are many environments in which a deferred
or disconnected execution is preferred or even required.
Queuing implements deferred execution of work. When a request for work is entered,
queuing defers processing of that request until the requester has completed the task, process,
or transaction that created the request.
It is often important that each request is processed exactly once, even in the presence of
application and system failures. By integrating transaction processing with queuing
technology, persistent queuing supports this requirement. The importance of queuing has
been proven by transaction processing (TP) monitors which typically include such a facility.
Business process management and workflow are more and more recognized as fundamental
technologies for emerging applications. Queuing is one of the key technologies for this class
of applications.
Oracle provides an efficient queuing infrastructure that does not depend on the use of TP
monitors or other evolving message-oriented middleware (MOM) infrastructure.
Redo
Parameter Data Control Log
files files files Archived
file
log files
Password
file
Instance
SGA Java Pool
Large Pool
Shared Pool
Parameter Buffer Cache Redo Log Library cache
file Buffer
Dictionary cache
ALERT
file
DBWn CKPT LGWR PMON SMON ...
Parameter File
To start an instance, Oracle must read a parameter file, which is a text file containing a list
of initialization parameter settings for that instance and database, or a binary file called an
SPFILE maintained by Oracle. You will see more information on SPFILE in the next lesson.
Background Processes
Oracle creates a set of background processes for each instance. The background processes
asynchronously perform I/O and monitor other Oracle processes to provide increased
parallelism for better performance and reliability. Each Oracle instance may use several
background processes. The names of these processes are DBWn, LGWR, CKPT, SMON,
PMON, ARCn, RECO, and so on.
Database Buffer Cache
The database buffer cache is the portion of the SGA that holds copies of data blocks read
from the data files. All user processes share access to the database buffer cache.
Redo Log Buffer
The redo log buffer is a circular buffer 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. Redo entries are used for
database recovery, if necessary. The background process LGWR writes the redo log buffer
to the active online redo log file, or group of files, on disk.
Control
files
Multiplexing
Password
file
Data Redo log
files 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.
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. A redo log is made up of redo
entries, each of which is a group of change vectors describing a single atomic change to the
database. The primary function of the redo log is to record all changes made to the database.
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 should be
multiplexed to protect them against failures.
In case of instance failures, Oracle will automatically recover the database using information
from the current online redo log files.
Control Files
Every Oracle database has at least one control file. A control file contains entries that
specify the physical structure of the database. Control files should be multiplexed to protect
them against failures.
Shared Server
The shared server configuration allows many user processes to share very few server
processes. The user processes connect to a dispatcher background process, which routes
client requests to the next available shared server process. The advantage of the shared
server configuration is that system overhead is reduced, increasing the number of users that
can be supported. A small number of shared server processes can perform the same amount
of processing as many dedicated server processes, and the amount of memory required for
each user is relatively small. The shared server requires Net. When an instance starts, the
network listener process opens and establishes a communication pathway through which
users connect to Oracle. Then, each dispatcher process gives the listener process an address
at which the dispatcher listens for connection requests. At least one dispatcher process must
be configured and started for each network protocol that the database clients will use. When
a user process makes a connection request, the listener examines the request and determines
whether the user process can use a shared server process. If so, the listener returns the
address of the dispatcher process that has the lightest load and the user process connects to
the dispatcher directly.
Note: More shared server features, such as connection pooling and multiplexing, are
discussed in a later lesson.
Database Physical
Segment
Extent
Oracle
Logical O/S block
block
Database Structure
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. The database has logical structures and
physical structures.
Tablespaces
A database is divided into logical storage units called tablespaces, that group related logical
structures together. For example, tablespaces commonly group all of an application's objects
to simplify some administrative operations. In Oracle9i, you also have different tablespace
types such as UNDO tablespace for undo information generation, that will be used if
someone writes rollback instead of commit.
Databases, Tablespaces, and Data files
The relationship among databases, tablespaces, and data files is illustrated in the above slide.
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. If it is a TEMPORARY tablespace, instead of a data file, the tablespace has a
temporary file.
Tablespaces
DBA_TABLESPACES
Data Dictionary
One of the most important parts of an Oracle database is the data dictionary, which is a read-
only set of tables that provides information about its associated database. A data dictionary
contains the definitions of all schema objects in the database, such as tables, views, indexes,
synonyms, sequences, procedures, packages, triggers, and so on. It also shows how much
space has been allocated for, and is currently being used, by the database objects, default
values for columns, integrity constraint information, and so on.
All the data dictionary tables and views for a given database are stored in the database’s
SYSTEM tablespace.
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. To access the
data dictionary, you use SQL statements. Because the data dictionary is read-only, you can
only issue queries against the tables and views of the data dictionary.
Metadata Unload
In Oracle9i, you can also use metadata unload. Metadata unload gives you the possibility to
extract information from the data dictionary regarding one specific table. The result from
metadata unload will be an XML document that you can use in another database to create a
copy of the table.
Higher
reliability and
availability
Greater Non-user
complexity tasks
Lower Higher
response throughput
times rate
Less
management
overhead
SGA SGA
Global Global
Resource Resource
Directory Directory
Instance A Instance B
Database files
on shared disks
Executables and archive Executables and archive
logs on local disks logs on local disks
Background Processes
Although some of the background processes used by Real Application Clusters have the
same names as those in Oracle Parallel Server in Oracle8i, their functions and activities are
different from those in previous Oracle cluster-enabled software releases. These differences
are discussed below:
• BSP: The Block Server Process was introduced in Oracle8i Parallel Server to support
Read Consistent Cache Fusion. It does not exist in a Real Application Clusters database
where these activities are performed by the LMS process.
• LMS: This process was known as the Lock Manager Server Process in Parallel Server.
The new LMS process in Real Application Clusters executes as the Global Cache Service
Process.
• LMON: This process was known as the Lock Manager Monitor in Parallel Server. While
Real Application Clusters databases use the same process name, the process is defined as
the Global Enqueue Service Monitor.
• LMD: There was a Lock Manager process, called LMD0, in Oracle Parallel Server, with
a zero at the end of the name implying that multiple copies of the process may be
allowed. This process is not used by Real Application Cluster, but a new process called
LMD executes as the Global Enqueue Service.
Instance Instance
A B
Block transfer with
Node A forced disk write Node B
Instance Instance
A B
Cache Fusion block transfer
Node A Node B
Block Transfers
If a block is only being queried (read) by all the instances, the same image is valid for all the
instances and this image is consistent with the on-disk copy. Thus the block image can be
read from disk or from another instance.
However, when a block has been changed (written) by an instance, another instance must
obtain the current block image before it can make its own changes. Similarly, an instance
performing a read may need to see changes committed by the writing instance. In these cases,
the Global Cache Service instructs the instance holding the current block image to transfer
the image to the requesting instance using one of three basic mechanisms:
Block Transfer with Forced Disk Write: This method, often referred to as a block ping, was
the only block transfer method in Oracle cluster-enabled software releases prior to Oracle8,
release 8.1, and was also used in Oracle8i to transfer blocks between writing instances. The
block is written to disk by the holding instance, and the requesting instance reads the freshly
written copy.
Consistent Read Cache Fusion: This algorithm enables the writing instance to prepare a read-
consistent image in its own buffer cache and to send this image across the interconnect to the
buffer cache of the instance performing the query. A similar algorithm was used in Oracle8i
Parallel Server databases.
Cache Fusion Block Transfer: Exclusive to Real Application Clusters, this algorithm passes
either clean or dirty block images between instances across the cluster interconnect.
Block
access
time With
(milli- Cache
seconds) Fusion
20
1
0.01
Block in Block in Block
local cache remote cache on disk
ACTIVE_INSTANCE_COUNT = 1
Pack Pack
Application or
Oracle instance middleware Oracle instance
Listeners Listeners
IP (A) IP (B)
IP addresses IP addresses
Monitors Monitors
DGM Disk group manager, DGM
only needed on
some platforms
Application or
Oracle instance middleware Oracle instance
Listeners Listeners
IP (A) IP (B)
IP addresses IP addresses
Monitors Monitors
DGM Instance monitor DGM
Listener monitor
Heartbeat monitor
Instance Monitor
The instance monitor detects termination of the local instance and initiates failover to the
secondary node or restarts the instance.
Listener Monitor
The listener monitor checks and restarts the listeners on its own node. When the public
listener fails to restart, the listener monitor exits, initiating a halt script. Oracle Real
Application Clusters Guard either begins failover or restarts the primary instance, depending
on the state of the secondary node.
Heartbeat Monitor
The heartbeat monitor checks the availability of the Oracle instance. During normal
operation, the heartbeat monitor on each instance updates its own local heartbeat and checks
the heartbeat of the other instance The heartbeat monitor on the primary instance also
executes a customer-defined query to test whether the primary instance is capable of work.
The local Oracle instance is considered unavailable if the heartbeat monitor fails to complete
three consecutive attempts and there are no unusual circumstances, such as instance recovery
or unusually large numbers of sessions logging on.
The heartbeat monitor also initiates one kind of failover action: If the primary instance is
unavailable and the primary instance role has not resumed normal function on its new node,
then the heartbeat monitor initiates takeover. A takeover occurs when the secondary node
executes failover of the primary instance role to itself.
/hdisk1 /hdisk2
/dbs/initorac1.ora /dbs/initorac2.ora
SPFILE=/dev/rdisk1/spfile SPFILE=/dev/rdisk1/spfile
/dev/rdisk1
orac1.instance_name = orac1
/spfile orac2.instance_name = orac2
Users Privileges
CREDIT
CLERK Roles
INVOICE
Password Account
history locking
Setting up
User privileges
Password Password
expiration verification
and aging
ORDERS
Em
High priority 75% CPU
plo
ye
e
Em
plo
EX y
DSS user
s dfe
EX
s
A bc
d
Resource Management
Database resource management provides a DBA with the ability to control and limit the total
amount of processing resources available to a given user or set of users.
Resources are allocated to users based on a plan that is specified by the DBA. Users, and
groups of users, are assigned to resource consumer groups. A resource plan specifies how
resources are distributed among the different resource consumer groups. Plans can be
dynamically altered on a production database without quiescing the system. This allows
alternate plans for day time, night time, weekends, quarter end, or other times that require a
different set of priorities.
The resource manager is fully integrated into the database security system. User sessions can
switch resource consumer groups to increase execution priority, if the user has been granted
the privilege to switch consumer groups. Users can also be moved from group to group by
the administrator on a production system, thereby dynamically changing how CPU resources
are used. The DBA can also set up the resource management system to switch the group for a
user automatically, depending on the type of query the user is doing. These capabilities allow
very simple, yet powerful allocation policies to be implemented for database resources.
Joe
Harry
Harry Oracle
Mary server
Mary
Application server or TP
monitor
N-Tier Authentication
To provide scalability, an application server or TP monitor can be used to perform
transactions on behalf of clients that are accessing the application server through the network.
The application server will perform the transactions, but there must be a mechanism that
ensures that the real connected client is still the identity used in the database.
The client may authenticate itself to the middle tier using any authentication method the
middle tier accepts. The middle tier may authenticate itself to the database using any method
the database accepts.
In the Oracle9i server, the middle-tier does not have to reauthenticate the client to the back-
end server. This requires less overhead, and is also useful for cases in which you cannot
reauthenticate the client. For example, a client using an X.509 certificate cannot be
authenticated through a middle tier to the server, because that would require the client to give
up his private key to the middle tier, which is completely insecure.
The database can trust the middle tier because the following is verified:
• that the middle tier IS the middle tier (through authentication)
• that the client for whom a connection is established exists in the database
• that the middle tier is privileged to connect on behalf of that user, with the appropriate
roles for that user
Crypto Authentication
N N
T T
CyberSafe
Kerberos
Z
RC4_128
RADIUS
SecurID
Indentix
RC4_40
RC4_56
DES40
MD5
DES
TCP SSL
adapter adapter
Kerb
Tokens
Smart cards
Other
SecurID
Cyber
Idx
Authentication Architecture
Oracle supports several methods of authentication by the network:
• Third Party-Based Authentication Technologies: If network authentication services, such
as DCE, Kerberos, or SESAME are available to you, the Oracle9i server can accept
authentication from the network service. To use a network authentication service with the
Oracle server, you need Oracle9i Enterprise Edition with the advanced security option
(ASO).
• Public Key Infrastructure-Based Authentication: Authentication systems based on public
key cryptography systems issue digital certificates to user clients, which use them to
authenticate directly to servers in the enterprise without direct involvement of an
authentication server. Oracle provides a public key infrastructure (PKI) for using public
keys and certificates. It consists of the following components:
– Authentication and secure session key management using Secure Sockets Layer
(SSL)
– Oracle Call Interface (OCI) and PL/SQL functions to sign user-specified data
using a private key and certificate, and to verify the signature on data using a
certificate and trust point
– Oracle wallets, which are data structures that contain a user private key, a user
certificate, and a set of trust points (the list of root certificates the user trusts)
Server
Specify
process
audit options
Review audit Generate
information audit trail
Audit options
Database Auditing
Auditing is the monitoring and recording of selected user database actions. You can use it to:
• Investigate suspicious activity
• Monitor and gather data about specific database activities
Oracle supports several general types of auditing:
• Statement auditing: The selective auditing of SQL statements with respect to only the
type of statement, not the specific schema objects on which it operates. Statement
auditing options are typically broad, auditing the use of several types of related actions
per option. For example, AUDIT TABLE tracks several DDL statements regardless of the
table on which they are issued.
You can set privilege auditing to audit a selected user 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 because it audits only the use of the target
privilege. You can set privilege auditing to audit a selected user or every user in the
database.
• Schema object auditing: The selective auditing of specific statements on a particular
schema object, such as AUDIT SELECT ON EMP. Schema object auditing is very
focused; it audits only a specific statement on a specific schema object. Schema object
auditing always applies to all users of the database.
Audit policy
AUDIT_CONDITION
=
SELECT 'salary > 10000'
last_name,salary FROM
employees WHERE
last_name = 'Russell'
Audit records
'SELECT last_name,
salary FROM
employees
SELECT WHERE last_name
last_name,salary FROM = 'Russell'
employees WHERE '
salary < 9000 , <timestamp>
, <SCN>
, <username>
, ...
Fine-Grained Auditing
The Fine-Grained Audit (FGA) mechanism addresses a more granular level of auditing. The
new auditing policy is based on simple user-defined SQL predicates on table objects as
conditions for selective auditing. The predicate can specify auditing when a specified value is
retrieved.
In addition to value based, there are also cases where the administrators are only interested in
whether a certain column is being referenced or accessed. Because auditing is supported
whenever a column is selected in any part of a DML statement, Oracle will audit the query.
Fine-grained auditing is available only on SELECT statements with a WHERE clause, and for
one audit column only.
The triggering event above was not that the user accessed employee records for which
salaries are greater than 10,000, but that the salary was actually returned to the user. A record
is written to the audit trail that includes the complete SQL statement the user submitted, a
timestamp, username, and other information.
Fine-grained auditing does not automatically capture the values returned to the user.
However, you may be able to use fine-grained auditing in conjunction with Flashback Query
to re-create the records returned to the user.
ACME Corporation
DBMS_OBFUSCATION_TOOLKIT.DESEncrypt
Dwcw8739lad9a03ka+d
Obfuscation Toolkit
Among other security technologies, Oracle protects data in eBusiness systems through
strong, standards-based encryption. Oracle has supported encryption of network data through
Oracle Advanced Security (formerly known as "Secure Network Services", and then
"Advanced Networking Option") since Oracle7.
The Oracle9i server also supports protection of selected data by means of encryption within
the database.
To address the need for selective data encryption, the Oracle9i server provides a PL/SQL
package to encrypt and decrypt stored data. The package,
DBMS_OBFUSCATION_TOOLKIT, supports bulk data encryption using the Data
Encryption Standard (DES) algorithm, and includes procedures to encrypt and decrypt using
DES. In addition to single DES, the DBMS_OBFUSCATION_TOOLKIT supports triple DES
(3DES) encryption, in both two and three key modes, for those who demand the strongest
commercial available level of encryption. The toolkit also supports the MD5 secure
cryptographic hash to ensure data integrity, and a random number generator for generating
secure encryption keys.
Slow Quick
Cluster Key
Access Paths
Optimization is the process of choosing the most efficient way to execute a SQL statement.
This is an important step in the processing of any data manipulation language (DML)
statement: SELECT, INSERT, UPDATE, or DELETE. Many different ways to execute a SQL
statement often exist, for example, by varying the order in which tables or indexes are
accessed. The procedure Oracle uses to execute a statement can greatly affect how quickly the
statement executes. A part of Oracle called the optimizer calculates the most efficient way to
execute a SQL statement. The optimizer evaluates many factors to select among alternative
access paths. It can use a cost-based or rule-based approach.
You can influence the optimizer’s choices by setting the optimizer approach and goal and by
gathering statistics for cost-based optimization. Sometimes the application designer, who has
more information about a particular application’s data than is available to the optimizer, can
choose a more effective way to execute a SQL statement. The application designer can use
hints in SQL statements to specify how the statement should be executed.
One of the most important choices the optimizer makes when formulating an execution plan is
how to retrieve 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.
ID Operation
-- -----------------------------------
0 SELECT STATEMENT Cost =
1 TABLE ACCESS BY ROWID (EMP)
2 AND-EQUAL
3 INDEX RANGE SCAN (JOB_INDEX)
4 INDEX RANGE SCAN (DEPTNO_INDEX)
Rule-Based Optimizer
Using the rule-based approach, the optimizer chooses an execution plan based on the access
paths available and the ranks of these access paths (shown on the slide). You can use rule-
based optimization to access both relational data and object types. Oracle’s ranking of the
access paths is heuristic. If there is more than one way to execute a SQL statement, the rule-
based approach always uses the operation with the lower rank. The assumption is that
operations of lower rank execute faster than those associated with constructs of higher rank.
Rule-based optimization is supported for backward compatibility with earlier releases, and
should not be used for new systems. The rule-based optimizer does not recognize many
advanced features of Oracle9i such as partitions, index-organized tables, bitmapped indexes,
function based indexes, histograms, hash joins, and star queries.
SELECT
Co
3 st
1 02 =
= 15
st 00
Co
FULL INDEX
TABLE RANGE
SCAN SCAN
Cost-Based Optimizer
You should design new applications to use cost-based optimization. You should also use cost
based optimization for data warehousing applications because the cost-based optimizer
supports new and enhanced features for DSS. Much of the more recent performance
enhancements, such as hash joins, improved star query processing, and histograms, are only
available through cost-based optimization.
Using the cost-based approach, the optimizer determines which execution plan is most efficient
by considering available access paths and statistics for the schema objects (tables or indexes)
accessed by the SQL statement as well as system statistics regarding CPU time and I/O
performance in the system. The cost-based approach also considers hints, which are
optimization suggestions placed in a comment in the statement. You must gather statistics on a
regular basis to provide the optimizer with information about schema objects. This task is done
by the database administrator most of the time by using the ANALYZE command or procedures
and functions in the package DBMS_STATS.
Conceptually, the cost-based approach consists of these steps:
1. The optimizer generates a set of potential execution plans for the SQL statement based
on its available access paths and hints.
2. The optimizer estimates the cost of each execution plan based on statistics in the data
dictionary for the data distribution and storage characteristics of the tables, indexes, and
partitions accessed by the statement as well as system statistics on CPU and disk I/O.
3. The optimizer compares the costs of the execution plans and chooses the one with the
smallest cost.
Statistics
Copy Statistics
Statistics
Production Test
Cursor Sharing
The term cursor sharing refers to an operation performed by the optimizer to reduce the
overhead of parsing SQL statements. Rather than developing an execution plan each time a
similar statement is executed, the optimizer parses the statement only the first time it is
executed. As a DBA, you can switch from one mode to the other.
Safe Mode
Consider a query such as this one, where EMPLOYEE_ID is the primary key:
SQL> SELECT * FROM employees WHERE employee_id = 153;
The substitution of any value would produce exactly the same execution plan. It is therefore
safe for the optimizer to use only one execution plan for a similar SQL statement.
Unsafe Mode
Assume the same employees table has a wide range of values in its DEPARTMENT_ID
column. For example, department 50 contains over one-third of all employees, and
department 70 contains just one or two. Given the following two queries:
SQL> SELECT * FROM employees WHERE department_id = 50;
SQL> SELECT * FROM employees WHERE department_id = 70;
Using this feature is not safe because it might be better to use a full table scan in the first case
and an index scan in the second.
• ACID properties
• Row level locking
– Maximizes concurrency,
minimizes interference
– Nonblocking
– No escalation
– No restrictions
Read Write
Uncommitted
change
Committed
update/delete
Committed
insert
Old image
Table New
image
Undo segment
Update transaction
Undo Information
Each database contains one or more Undo tablespaces. An Undo tablespace records the old
values of data that were changed by each transaction (whether or not committed). Undo
tablespaces are used to provide read consistency, to roll back transactions, and to recover the
database.
In one Undo tablespace, there are several undo segments maintained by Oracle. For each
undo segment, Oracle maintains a transaction table, that is a list of all transactions that use
the associated undo segment and the undo entries for each change performed by these
transactions. Oracle uses the undo entries in a undo segment to perform a transaction
rollback and to create read-consistent results for queries.
Undo tablespaces record the data prior to change on a per-transaction basis. For every
transaction, Oracle links each new change to the previous change. If you must roll back the
transaction, Oracle applies the changes in a chain 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 an Undo tablespace to create a set of data consistent with respect to a
single point in time.
Multiversion read-
consistency:
Query starts
• Queries see a
consistent view of the
Update 2 rows table
• No matter how many
Consistent updates
read
• Reconstructed from
Query undo segments
continues
• Performance due to
undo caching
Oracle Flashback
Applications can be executed on the version of the database as of a certain time. For
example, a Windows application for customer information may have a button that allows the
user to move back to an earlier point in time to show the account balance as of a certain
time. Previously, much of this information had to be saved away by the application. This
feature allows accessing information in the past, even when it was not explicitly saved away.
There may be several reasons why users would like to query past data. One important
application would be self-service repair, when some important rows were accidentally
deleted from a table and the users wanted to recover them. To perform the repair, they could
possibly move backwards in time, see the missing rows, and reinsert the deleted row into the
current table. Care must be taken not to introduce logical inconsistencies.
Other potential benefits include packaged applications such as e-mail and voice mail. The
users may have accidentally deleted a mail or a voice message by pressing the wrong key.
Using temporal access, they would be able to restore the deleted mail or message by moving
back in time and reinserting the deleted message into the current message box.
Oracle Flashback leverages the Automatic Undo Management functionality which can retain
the undo information for a user specified retention interval. Therefore, all queries addressed
to a system time which is not earlier than a retention interval from the current time have
enough undo information to reconstruct the snapshot. The amount of disk space required
will depend on how far back you intend to go.
COMMIT;
Serializable Transactions
To describe consistent transaction behavior when transactions execute at the same time,
database researchers have defined a transaction isolation model called serializability.
Serializability tries to ensure that transactions execute in such a way that they appear to be
executed one at a time, or serially, rather than concurrently. While this degree of isolation
between transactions is generally desirable, running many applications in this mode can
compromise application throughput. Complete isolation of concurrently running transactions
could mean that one transaction cannot perform an insert into a table being queried by
another transaction. Real-world considerations usually require a compromise between
perfect transaction isolation and performance.
SQL:1999 defines four levels of isolation in terms of the phenomena that a transaction
running at a particular isolation level is permitted to experience:
Isolation level Dirty read Nonrepeatable read Phantom read
Read uncommitted Possible Possible Possible
Read committed Impossible Possible Possible
Repeatable read Impossible Impossible Possible
Serializable Impossible Impossible Impossible
Oracle offers the read committed and serializable isolation levels, as well as a read-only
mode that is not part of SQL:1999. Read committed is the default and was the only
automatic isolation level provided before Oracle Release 7.3.
Oracle9i Database: Product Overview 8-9
Transaction Management
DATA
Transaction Management
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, a transaction begins with the
user’s first executable SQL statement. A transaction ends when it is explicitly committed or
rolled back by that user.
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 session’s 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.
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.
Long Transactions
To help with complex queries and scenarios where you might want to see and test changes to
data before they are finalized, it is now possible to use long transactions. A long transaction
can exist for several days and is managed by creating different versions of a table. To set the
version you want to use, you connect to the proper workspace.
A workspace is a virtual environment that provides a transactionally consistent snapshot of
the entire database. One or more users can share this environment to version data in the
database.
The unit of versioning is the table. When a user in a workspace updates a row in a version-
enabled table, a new version of the row is created. Versions are only accessible within the
workspace until explicitly merged with the parent workspace. This also applies to inserts
and deletes made within a workspace to a version-enabled table.
There can be one or more versions of a row in a workspace from one or more version-
enabled tables. The current or active version of a row in a workspace refers to the version of
a row to which changes are currently being made.
Tables that are not version-enabled will be changed as usual, regardless of which workspace
a user might be in. Access to any table is still controlled by the privileges a user has, not
which workspace a user is in.
• Discrete transactions
– Short, nondistributed
– Changes deferred until commit
– No undo generated
• Autonomous transactions
– Transactions within a transaction
– Commit/rollback independently
Discrete Transactions
Application developers can improve the performance of short, nondistributed transactions by
using the procedure BEGIN_DISCRETE_TRANSACTION. This procedure streamlines
transaction processing so that short transactions can execute more rapidly. During a discrete
transaction, all changes made to any data are deferred until the transaction commits. Oracle
generates redo information, but stores it in a separate location in memory.
When the transaction issues a commit request, Oracle writes the redo information to the redo
log file, and applies the changes directly to the data block. Oracle returns control to the
application once the commit completes. This eliminates the need to generate undo
information, since the block is actually not modified until the transaction is committed, and
the redo information is stored in the redo log buffers.
Autonomous Transactions
Autonomous transactions are independent transactions that can be called from within
another transaction. An autonomous transaction lets you step out of the context of the calling
transaction, perform some SQL operations, commit or roll back those operations, and then
return to the calling transaction’s context and continue with that transaction. Once invoked,
an autonomous transaction is totally independent of the calling transaction (the main
transaction). It does not see any of the uncommitted changes made by the main transaction
and does not share any locks or resources with the main transaction.
Distributed Databases
A distributed database is a network of databases managed by multiple database servers that
appear as a single logical database to a user. 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). 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.
Oracle provides the same assurance of data consistency in a distributed environment as in a
nondistributed environment. Oracle provides this assurance using the transaction model and
a two-phase commit mechanism. As in nondistributed 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 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.
Application
Client
Native TP Monitor
Interface (2PC Coord.)
Native
(SQL) Interface
XA Interface
Resource Manager Resource Manager
(example: Oracle Server) (example: Informix Server)
XA Architecture
In the traditional Oracle client/server architecture, presentation and business logic is
concentrated into a single executable which is distributed to each client machine.
Occasionally, database packages and procedures are used to move some business logic to the
Oracle Server; however, the architecture is inherently 2-tier. Each application client has a
corresponding shadow process (or thread) running within the database server. This
architecture provides great flexibility. However, it runs into problems when scaling to large
numbers of concurrent users.
One approach for improving scalability is to split the application logic into an application
client and application server. The application client becomes primarily responsible for the
collection and presentation of data. The application server becomes responsible for
providing business services which it implements through accessing various data stores
(resource managers).
The application server will usually be written in a 3GL such as C or COBOL, and interface
to a resource manager using the normal precompiler or API mechanisms. Application client
and server communicate through a messaging interface.
In the Oracle case, application servers can be implemented with precompilers or OCI.
Connection to Oracle can be direct or through Oracle Net.
• Relational concepts
– Domains, tables, rows, columns
– Missing information
– Integrity
• Languages and interfaces
– SQL, embedded SQL, PL/SQL, JAVA
– XML
– OCI, ODBC, OLE
– JDBC, SQLJ, EJB, CORBA
Database objects
• Tables, clusters, data types
• Indexes, constraints, triggers
• Views, materialized views
• Sequences, queues
• Procedures, functions, packages
• Security
– Users, schemas, authentication
– Quotas, resource limits, profiles
– Privileges and roles
– Auditing
• The optimizer
– Rule based
– Cost based
• Transactions
– Concurrency
– Read consistency
Object
ORDER
Ship Methods
po#
Check custinfo
Status Cancel
lineitems
amount
Hold
Attributes
What is an Object?
David Taylor (Object Guru) describes objects as:
“Software packets responsible for their information (attributes), and their methods (operations)
for operating on that information.”
In reality, an object is just another step forward in the software engineering life cycle. You
model real things and represent these things as objects. In other words, you can develop
solutions that simulate real-world problems. The model is stated in terms of the interactions
between objects. Object technology has been around for over twenty years. Data-driven
analysis was the first step towards objects. It recognizes that data is constant whereas process is
in constant change. Some of the benefits of object technology are easy maintenance of
applications, faster product development, and higher quality of code at a lower cost.
• Object type
• Method
• Class
• Object instance
• Inheritance
• Subclass
• Polymorphism
• Encapsulation
Object Terminology
An object type is a person, place, or thing. An object type knows things about itself and has
behavior.
A class is the factory which creates an object; it is the template from which instances of that
class are created. The Oracle term for class is object type.
For example, the class watch is sent a message new which invokes the class method new which
then creates an instance of the class watch. Repeated sends of the class message new create
additional instances of the class watch. These instances are initially identical and have no
knowledge of each other. An instance is created from the template for its class. As messages
are processed by their methods, their state changes. An instance is an object that belongs to a
particular class. In relational terms, instance is analogous to a row or record.
Inheritance allows objects to use behavior and attributes in classes above them in the hierarchy.
You can specialize any class by creating a subclass. The subclass will inherit all the
previously-defined behaviors and attributes of the superclass.
CUSTOMERS
object table
1 column of type
ADDRESS_TYPE
OPEN
• Extensibility framework
allows partners to add
Utilities Tools support for new data types.
• Oracle provides a set of
extensible APIs to core
Optimizer Extensibility functions; for example,
indexing, optimizer,
Query engine
operators, memory.
Index engine
• Development, packaging, and
Type manager installation tools
FLUSH
Pin REFRESH
REF REF
SQL
Part-time
student
Initialization parameters
Environment variables
ALTER SESSION
command
Statement level
Partitioning
Partitioning stores large tables and indexes in pieces, instead of as one large monolithic object.
Partitions are a divide and conquer technique that provides scalable performance with a large
amount of data. Each partition can be individually managed, and can operate independently of
the other partitions, increasing availability and making administrative tasks easier.
Oracle9i supports range, hash, composite, and list partitioning, which provides better
manageability, availability, and performance.
ORDERS table
Q1 Q2 Q3 Q4
Range Partitioning
Range partitioning provides the ability to subset data into individual partitions, based on a
range that the administrator defines. For example, an order table could be range-partitioned by
sales date, putting each order record into one of four partitions, one for each quarter of the
year. This method of partitioning data is useful when there is a logical range into which to
divide the data, such as by quarter of the year. However, in this case, partition size could vary
dramatically, which could affect performance of maintenance operations, if the data is skewed
into one particular partition.
ORDERS table
Partitioned
using hash
algorithm
Hash Partitioning
Oracle9i hash partitioning is an alternative to range partitioning. Hash partitioning:
• Controls the physical placement of data across a fixed number of partitions.
• Uses a hash function on the partition columns to place data into required partitions,
sometimes called hash buckets.
• Allows data that does not lend itself to range partitioning to be easily partitioned for
predominantly performance reasons (PDML, partition elimination, piece-wise joins).
CUSTOMERS table
'CA','AZ','NM', 'OH','ND','SD',
'OR','WA','UT‘, 'MO','IL','MI',
'NV','CO' 'IA'
'TX','KY','TN',
'LA','MS','AR',
'AL','GA'
ORDERS table
Partitioned
by range,
then hash
Q1 Q2 Q3 Q4
Composite Partitioning
There is also a need for partitioning methods that are well-suited for historical data and
simplify management for the support of parallelism. To satisfy this need, Oracle9i introduces
composite partitioning. Composite partitioning partitions data using the range method, and
within each partition, subpartitions it using the hash method. This new type of partitioning
supports historical operations data at the partition level, and parallelism (PDML) and data
placement at the sub-partition level.
In the example, the ORDERS table is first range partitioned on order date into four separate
ranges, representing quarters. Each range partition is then explicitly subpartitioned into two
hash partitions, on the PRODUCTID key.
This results in eight individual subpartitions (4 x 2).
Index I3
Index I1
Table T2
Table T1
Index I2 Index I4
Dispatching
sort L-S scan
results
Parallel Execution
When Oracle is not parallelizing SQL statements, each statement is executed sequentially by a
single process. With parallel execution, however, multiple processes work together
simultaneously to execute a single SQL statement. By dividing the work among multiple
processes, Oracle can execute the statement more quickly. Parallel execution can dramatically
improve performance for data-intensive operations associated with DSS applications and
VLDB environments.
Symmetric multiprocessing (SMP), clustered, and massively parallel systems (MPP) gain the
largest benefits from parallel execution because statement processing can be split up among
many CPUs. Parallel execution helps systems scale in performance by making optimal use of
system resources. If your CPUs and disk controllers are already heavily loaded, you need to
alleviate that load or increase hardware resources before using parallel execution to improve
performance.
The Oracle9i server can use parallel execution for many operations, and each new release
comes with new parallel execution enhancements.
Automated query
rewrites
PRODUCTS
Sum by
product
SALES
Year City
Sum by
Quarter Materialized views city
Month
Pre-summarized Sum by
Date automatically maintained day
Dimensions and
• Dimensions and hierarchies hierarchies
can be defined so that Oracle
can rewrite queries. ALL
• Materialized view tables can Year
be used to satisfy queries that
need rollups.
Season Week Quarter
• Enterprise Manager
provides a dimension advisor.
Month
Sales
date
Data
• Summary advisor: Workload dictionary
recommendations information information
based on query usage
• Optimize disk costs to
performance gains
Summary Advisor
• Goal is to explain:
– Why query did not rewrite?
– Or, if rewrite is possible, which materialized view is
used?
• Use procedure DBMS_MVIEW.EXPLAIN_REWRITE
• Parameters
– SQL statement, or
– Materialized view name
• Results are stored in REWRITE_TABLE table
Headquarters
database • Copy tablespaces between
databases:
– Same OS
Product catalog
– Same DB version
• No metadata export/import
required
• Exact full copies only
Catalog Catalog
Branch databases
Transportable Tablespaces
Moving data from a data warehouse to a data mart, or from an OLTP system to a staging area
for a data warehouse, can be cumbersome and time-consuming. Direct path loading via
SQL*Loader or parallel DML makes the task faster, but the process should be simpler for data
movement between identical databases. Oracle9i provides a mechanism for copying data files
between identical systems and allows both systems to access the same data. Now data
movement can be as fast as a simple transfer of files between machines. This greatly improves
performance and provides operational simplicity for the transfer of data.
Companies can also use this feature to publish data on CD ROMs that can be easily integrated
into Oracle databases at regional or area offices. For example, PRODUCT tables with product
descriptions and price can be populated or updated at the head office and moved to regional or
branch offices, for use in an order processing system.
Oracle Direct
DB2 Write OCI load
IMS Buffer program Buffer
Input
Stream Table
Load into
staging tables Staging table 1
Merge into
Staging table 3 warehouse Warehouse table
tables
INSERT & UPDATE
External tables
External table
Flat files
Table functions
Merge into
Validate data Transform data warehouse
tables
Warehouse table
MERGE
Data
files
Export
Objects
OS file
Export file
Import
Data
files
Data Import
The Import utility inserts the data objects extracted from one Oracle database by the Export
utility (and stored in an Export dump file) into another Oracle database. Export dump files can
only be read by Import.
Import reads the object definitions and table data that the Export utility extracted from an
Oracle database and stored in an Oracle binary-format Export dump file located typically on
disk or tape.
The Export and Import utilities can also facilitate certain aspects of Oracle Advanced
Replication functionality, such as offline instantiation.
If you are using Export/Import as a backup and recover utility, you must understand that you
will loose data changes between the export time and import time.
For this reason, you should not rely solely on these utilities for your backup strategies.
Data files
Backup
18 files
19
19 19
NOARCHIVELOG Mode
An Oracle database can operate in two distinct modes: NOARCHIVELOG mode (media
recovery disabled) or ARCHIVELOG mode (media recovery enabled).
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, as soon as a filled group becomes inactive, the group is available for
reuse by the LGWR process. 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 crash recovery or instance
recovery. This is sufficient to satisfy the needs of crash recovery and instance recovery,
because Oracle will not overwrite an online redo log that might be needed until its changes
have been safely recorded in the data files. However, it will not be possible to do media
recovery. This slide demonstrates the only possible way to restore and recover your database in
case of a media crash. Here, a complete cold backup is made, which means that the database is
shut down cleanly and that you back up all the files pertaining to the database. This includes
the redo log, and control and data files.
Note: This page and the following two belong together, and illustrate a typical
NOARCHIVELOG scenario.
35
36 36
36
36
18
19
19 19
Restore Sunday’s 18
whole backup
19
19
19
Restore
Because you lost the transaction history, you cannot recover from this situation.
The only possibility is to restore the full backup from Sunday. The consequence is that you
have lost every data change since Sunday.
Data files
Control 18
Online redo
file
19 log files
19
19
Sunday
Backup
files
18
19
19 19
21 ... 35
20 35
19 Archived
logs 36 36
36
36
18
19
19 19
21 ... 35
20 35
19
19 36
36
36
18
19
19 19
Partial Restore
Now, when there is a media failure, you only need to restore the crashed data file to restore the
database.
21 ... 35
20 35
19
36 36
36
36
No changes lost
18
19
19 19
Recovery Concept
The idea is to recover from the crash by applying the transaction history to the crashed data
file. The RECOVER command will do that automatically. At the end of the recovery process,
the crashed datafile will be usable again. So, in this case, only the noncommitted transactions
relative to this file are lost.
Trial Recovery
Some problems that may occur during media recovery are not recoverable. For example, if a
redo log is corrupted and recovery information cannot be applied, and the recovery process
stops, then the resulting database is useless. For media recovery, the user must restore the
backup and recover the database to a SCN before where the corruption occurred. For a large
database, restoring a backup and recovering the database can take a long time.
The following enhancements are provided:
• If media recovery of a full database encounters a problem, recovery always leaves behind
a consistent database, which can be opened read-only or with resetlogs.
• The DBA can instruct the media recovery process to mark a data block as being
corrupted. The block’s inconsistency is ignored and the recovery can proceed. The block
will subsequently be inaccessible.
• The DBA can invoke a Trial Recovery in order to investigate if the recovery problem is
an isolated problem.
The optimistic redo application algorithm assumes that no problem will occur during media
recovery. If any problem does occur, the Oracle server will automatically undo the last applied
changes, and not leave an inconsistency in the recovered database.
Oracle
database
Recovery Manager
Recovery Manager (RMAN) is a utility that manages the processes of creating backups of all
database files (datafiles, control files, and archived redo log files) and restoring or recovering
files from backups.
Recovery Catalog
RMAN maintains a repository called the recovery catalog, which contains information about
backup files and archived log files. RMAN uses the recovery catalog to automate both restore
operations and media recovery. The recovery catalog is maintained solely by RMAN. The
database server of the backed-up database never accesses the recovery catalog directly. RMAN
propagates information about backup datafile sets, archived redo logs, backup control files, and
datafile copies into the recovery catalog for long-term retention. When doing a restore, RMAN
extracts the appropriate information from the recovery catalog and passes it to the database
server. The server performs various integrity checks on the input files specified for a restore.
Incorrect behavior by RMAN cannot corrupt the database. The recovery catalog is stored in an
Oracle database. It is the database administrator’s responsibility to make such a database
available to RMAN. Taking backups of the recovery catalog is also the database
administrator's responsibility. Since the recovery catalog is stored in an Oracle database, you
can use RMAN to back it up. If the recovery catalog is destroyed and no backups are available,
then it can be partially reconstructed from the current control file or control file backups.
Note: Use of a recovery catalog is not required, but is recommended. Since most information
in the recovery catalog is also available from the control file, RMAN supports an operational
mode where it uses only the control file. This operational mode is appropriate for small
databases.
Data
dictionary Log files
LogMiner
Fixed view
LogMiner
dictionary file
SQL*Plus
SQL*Plus has always been one of the most efficient tools to issue ad hoc SQL statements for
any purpose, including database administration tasks such as managing tablespaces, rollback
segments, users and schemas, privileges and roles, and auditing.
Oracle8i, SQL*Plus also supports database administration commands, including STARTUP
and SHUTDOWN, RECOVER, and ARCHIVE LOG. This means that a database administrator can
perform all regular tasks using SQL*Plus.
TCP/IP
network
iSQL *Plus iSQL *Plus Oracle RDBMS
user HTTP
interface protocol server Net Oracle
Oracle Net
Net
Client Oracle Database
HTTP server
server
iSQL*Plus Architecture
iSQL*Plus is a browser-based implementation of SQL*Plus. It uses no client software, just a
Web browser. It is a component of SQL*Plus and is available on Windows NT/2000. In the
near future, it will also be available on other platforms. The three tiers may be on the same
machine, or on separate machines.
iSQL*Plus User Interface (Client Tier)
The iSQL*Plus user interface runs in a Web browser connected to the Internet or your intranet.
You only need to know the URL of the Oracle HTTP Server to access Oracle9i, or any Oracle
database. There is no installation or configuration required for the iSQL*Plus user interface
other than a Web browser.
Oracle HTTP Server (Middle Tier)
The iSQL*Plus Server is installed as part of the Oracle HTTP Server. The iSQL*Plus Server
enables communication and authentication between the iSQL*Plus user interface and the
RDBMS.
Oracle9i (Database Tier)
Oracle Net components provide communication between the iSQL*Plus Server and Oracle9i.
(Browser-based)
Console HTTP
daemon
Agent Oracle
OMS Server
Loader Source
control file data file
Bad data
SQL*Loader Reject
Discard file
file Log
file
Unwanted
data Oracle
9i
13-8 Copyright © Oracle Corporation, 2001. All rights reserved.
SQL*Loader
SQL*Loader loads data from external files into tables of an Oracle database.
• Powerful data parsing engine puts little limitation on the format of the data in the data file
• Loads data from multiple data files into multiple tables during the same load session
• Character set aware (you can specify the character set of the data)
• Selectively loads data (you can load records based on the records’ values)
• Manipulates the data before loading it, using SQL functions
• Generates unique sequential key values in specified columns
• Uses the OS file system to access data files
• Loads data from disk, tape, or named pipe
• Performs sophisticated error reporting that greatly aids troubleshooting
• Supports two paths: while conventional path loading is very flexible, direct path loading
provides superior loading performance
• Loads arbitrarily complex object-relational data
• Supports secondary data files for loading of LOBs and collections
• Compatible with the DB2 Load Utility from IBM; consequently, with a few changes, DB2
Load Utility control files can be used as a SQL*Loader control file
Data
files
Export
Operating
system file
Export
Export provides a simple way for you to transfer data objects between Oracle databases, even
if they reside on platforms with different hardware and software configurations. Export extracts
the object definitions and table data from an Oracle database and stores them in an Oracle
binary-format Export dump file located typically on disk or tape. You can then use FTP or
physically transport (in the case of tape) to a different site and use, with the Import utility, to
transfer data between databases that are on machines not connected through a network or as
backups in addition to normal backup procedures.
The Export and Import utilities can also facilitate certain aspects of Oracle Advanced
Replication functionality like offline instantiation.
The Export utility can also do the following:
• Specify multiple dump files for an export command
• Specify a query for the select statements that Export uses to unload tables
• Export and import precalculated optimizer statistics instead of recomputing the statistics at
import time
Export file
Import
Data
files
Import
The basic concept behind Import is simple. Import inserts the data objects extracted from one
Oracle database by the Export utility (and stored in an Export dump file) into another Oracle
database or the same database. Export dump files can only be read by Import. It is not
mandatory to import every object that has been exported; the Import utility is selective just as
when you export, you are not required to import everything in the database.
Export and Import
Export and Import together provide a powerful toolset for:
• Software migrations and upgrades
• Logical backups
• Database defragmentation
• Copying cost-based optimizer statistics between databases
Transform
Interim
table
Source
table
Track
updates
Transform
Store updates
updates
Management Others
framework Oracle
Oracle
Server O subagent
ra (and MIB)
cl e
SNM Ne
P t
Repository
Management Master agent
applications
Management Station
The management station refers to a node from which managed elements are monitored using
the SNMP protocol. Typically, it is a stand-alone workstation that is on the same network or
internetwork as the managed elements.
Management Framework
At the management station, the management framework uses SNMP to request management
information from other nodes. The framework collects, graphs, and possibly acts on that SNMP
data, and saves some or all of it in a repository for historical analysis and reporting.
Management frameworks include many tools and options. In addition to directly requesting
information from managed nodes, frameworks typically use daemons to alert them when a
managed node has sent a trap in response to a specific set of conditions. The traps also can be
used to trigger management applications.
Management Application
The management applications are the tools integrated with the management framework to
accomplish more specialized network or database tasks. These applications contain virtually all
of the sophisticated logic associated with network management.
Managed Node
The managed node is a platform, such as a UNIX server, on which elements to be monitored
reside.
Master Agent
The master agent is the process on a managed node that accepts queries, also called polls, from
the management framework and communicates with the elements to be managed in order to
answer the query. It also can send SNMP traps independently in response to specific
conditions. Only one master agent can exist on each managed node.
Subagents
The subagent is a process that receives queries for a particular managed element from the
master agent and sends back the appropriate answers to the master agent. One subagent exists
for each managed element residing on the managed node.
Management Information Base
A management information base (MIB) is a text file, which describes the variables containing
the information that SNMP can access. The variables described in a MIB, which are also called
MIB objects, are the items that can be monitored using SNMP. There is one MIB for each
element being monitored. The actual values of the variables are not part of the MIB, but are
retrieved through a platform-dependent process called instrumentation. The concept of the
MIB is very important because all SNMP communications refer to one or more MIB objects.
What is transmitted to the framework is, essentially, MIB variables and their current values.
Business Intelligence
• Partitioning, paralellization
• Materialized views, summary management
• Transportable tablespaces
• Direct path loads
• OLAP Services
Client Server
Application communication
Oracle Net
Transport layer protocol
Client-Server Architecture
Oracle Net is the foundation of Oracle's family of networking products that allow services
and their applications to reside on different computers and communicate as peer applications.
The main function of Oracle Net is to establish network sessions and transfer data between a
client machine and a server or between two servers. Oracle Net is located on each machine in
the network. After a network session has been established, Oracle Net acts as a data courier
for the client and the server.
Network sessions are established with the help of a listener. The listener is a separate process
that resides on the server whose responsibility is to listen for incoming client connection
requests and manage the traffic to the server.
Oracle Net uses the Transparent Network Substrate (TNS) and industry-standard networking
protocols to connect a client to a server and establish an Oracle network session.
Oracle protocols are Oracle’s implementation of the transport layer. Oracle protocols
include: LU6.2, Named Pipes, VI, TCP/IP, TCP/IP with SSL.
One
logical CUSTOMERS ORDERS
database
2 Phase Commit
Distributed Processing
Oracle databases and client applications operate in a distributed processing environment.
Distributed or cooperative processing involves interaction between two or more computers to
complete a single data transaction. Applications such as an Oracle tool act as clients
requesting data to accomplish a specific operation. Database servers store and provide the
data.
In a typical network configuration, clients and servers can exist as separate logical entities on
separate physical machines.
Distributed Databases
With this type of client-server architecture, you can also distribute databases across a
network. A distributed database is a network of databases stored on multiple computers that
appears to the user as a single logical database. Distributed database servers are connected by
a database link, or path from one database to another. One server uses a database link to
query and modify information on a second server as needed, thereby acting as a client to the
second server.
CONNECT oe/oe@sales
Naming
Naming is generally used to identify an entity with a simple name. Oracle Net uses this
simple name, called a connect identifier, to identify a connect descriptor. A connect identifier
is specified in several different ways. One way is through use of a net service name (sales in
the above slide) that maps to a connect descriptor. Users initiate a connect request by
providing a connect string. A connect string includes a user name and password, along with a
connect identifier, or the complete connect descriptor for the service to which they want to
connect. When a net service name is used, connection processing takes place by first
mapping the net service name to the connect descriptor. This mapped information is stored in
one or more repositories of information that are accessed with naming methods:
• Local naming stores net service names and connect descriptors in localized files.
• Directory naming stores net service names and database service names in a centralized
LDAP-compliant directory server to access a database service.
• Oracle Names uses Oracle proprietary software to store the names and addresses of all
database services on a network. Oracle Names will no longer be supported in the future.
• Host naming enables users to connect to an Oracle database server by using a host name
alias using existing names resolution service, such as Domain Name System (DNS), or
Network Information Service (NIS).
• External naming stores net service names and descriptors in a supported non-Oracle
naming service like NIS and DCE.
Virtual Buffer
circuits cache
PMON
Shared Dedicated
server server
process process
Dispatcher
Listener
Data
files
Dispatcher
Listener Node
Client Dispatcher
Listener Node
Connection Pooling
Connection pooling is a resource utilization feature that enables you to reduce the number of
physical network connections to a dispatcher. This is achieved by sharing or pooling a set of
connections among the client processes.
Connection pooling allows inactive physical connections to the machine to be temporarily
disconnected while a logical session remains. This releases OS resources so that additional
users can connect to the same machine. When network activity is resumed on the dropped
connection, the logical session reestablishes a physical connection through the same process
the new connection was established.
Connection pooling frees system resources and allows more users to access the database. It is
ideal for interactive high think/search time applications, such as e-mail and data warehouse
query tools.
Connection
• Leverage multiplexing Managers
– Predictable, consistent
performance
– User identity passed to
the server
• Simultaneous data access
for many users
Server
• Access control and cross
protocol support
Clients
Server
• Multiple network Client
Listening
sessions use a endpoint
single physical link
Session 1 Session 1
• Clients running
multiple applications
• Minimized lock outs Session 2 Session 2
Single
physical
Session 3 link Session 3
Scalability: Multiplexing
Similar to connection pooling, multiplexing also seeks to free system resources by
minimizing those required to establish connectivity. Multiplexing allows multiple network
sessions to share a single physical transport connection by interspersing the network traffic
across the network connection.
An example of multiplexing might be a client running three applications that connect to the
same machine, requiring three network sessions. Rather than requiring three separate
network connections which reduces the number of sockets available on the machine that the
client connects to, multiplexing takes up one socket because the three sessions share the same
network connection. This reduces the overall resources used.
Note: Multiplexing is only available with Shared Server and Connection Manager.
1 Server search
Names
Repository
2 Address resolution
1 3 Connection
2
HR
Server
Client
Network HR
scott/tiger@HR
3
1 Server search
Directory
Server
2 Address resolution
1 3 Connection
2
HR
Server
Client
Network HR
Multithreaded Agent
Agent
Specific Remote
Oracle9i HS generic
driver database
code
Heterogenous Services
Heterogeneous access is a challenge that affects many organizations. Many run several
different database systems. Each of these systems stores data and has a set of applications
that runs against it. Consolidation of this data into one database system is often difficult.
Heterogeneous Services, an integrated module within the Oracle9i database server, has been
designed to access data in non-Oracle systems by means of either Oracle Transparent
Gateways or generic connectivity. Most of the heterogeneous connectivity related processing
is done in this module.
• An Oracle Transparent gateway is a gateway that is designed and optimized for accessing
a specific non-Oracle system. Oracle Corporation provides gateways to access several
commercially produced non-Oracle systems like DB2, Ingres, IBM DRDA, Rdb,
Informix.
• In addition to transparent gateways to various non-Oracle database systems, there is a set
of agents that comprise the Oracle generic connectivity feature. These agents contain
only generic code and the customer is responsible for providing the necessary drivers.
Oracle has generic connectivity agents for ODBC and OLE DB that enable you to use
ODBC and OLE DB drivers to access non-Oracle systems that have an ODBC or an OLE
DB interface. Generic Connectivity is mainly used for low-end data integration situations
requiring ad hoc querying capabilities like with Foxpro, Access, or dBase.
Agents are used for security reasons avoiding Oracle Server crash if problems occur on the
non-Oracle system. Also, an agent can reside anywhere on the network and can be truly
multithreaded.
Oracle9i Database: Product Overview A - 16
Summary
What is Replication?
The Data Replication feature provides:
• The ability to maintain multiple copies of data at different sites in a distributed
environment
• The ability of the systems to function autonomously even when other systems in the
distributed environment fail
The Oracle server can implement a very basic form of data replication, using asynchronous
data propagation, with the following:
• Export and Import
– Whole table only
– Must manually perform export and import (with TRUNCATE command) repeatedly
for replica to see changes
• CREATE TABLE AS SELECT
– Table cannot exist in order for command to succeed
– One-time data copy procedure
• COPY command in SQL*Plus
– Used for copying data
– Provides a way to copy LONG columns
Unidirectional Replication
You can configure the following forms of data replication to replicate data changes
automatically:
• Database triggers
– Real-time, synchronous data propagation
– Must create trigger for each DML activity: UPDATE, INSERT, DELETE
– Database and network must be available, or commit at local site will fail
• Read-only materialized view
– Local copy of entire remote table, or partial copy of rows and columns for remote
table
– Can use a job to automatically refresh materialized view with new changes created
at master site
Bi-directional Replication
In Advanced Replication, the changes applied to a table at one site are captured and stored
locally before being forwarded and applied to the replicated tables at each of the remote
locations in the replicated database. This is known as asynchronous replication, sometimes also
referred to as store and forward replication. Synchronous replication, applying data changes to
all replication sites real-time, is also available.
Replicated databases are different from distributed databases. In a replicated database, the
tables being replicated exist at each site. In a distributed database, the data for a particular table
is available at each system, but the table itself resides in only one database.
Stored
Source table deferred RPC Destination
table
Trigger Destination
Change Queue process
table
Change
Forward
Error log
Failures
If propagation fails because the target database is not available or accessible through the
network, or the tablespace is full, the deferred RPCs for that target database remain in queue at
the source site for later execution.
Other errors, such as duplicate key violation, that are encountered during execution on the
target system, will cause:
• Any transaction to be rolled back
• The error message and the information of the deferred RPCs to the transaction to be stored
in the error log table on the target database
A PL/SQL-stored procedure enables DBAs to easily re-execute procedure calls in the error log
after fixing the problem that caused the error (discussed later in this course).
Recovery
The failure of source or target systems or a network requires only normal database and network
procedures to recover the database to the current point in time.
The deferred RPC queue and supporting facilities are implemented using database tables fully
protected by the Oracle Server redo log.
Actual propagation and execution of a deferred RPC is performed as a distributed transaction
protected by the distributed protocol.
In a global distributed database, good distributed database designs with fault-tolerant
mechanisms are important.
• Streams-based execution
• Parallel propagation
T3 T2 T1
T1
T3
T2 Destinations
Source
Streams-based Execution
Multiple deferred RPCs are executed as a transaction with one message exchange.
Parallel Execution
A deferred RPC transaction can be executed on multiple remote systems in parallel.
Parallel Propagation
This method asynchronously propagates replicated transactions, using multiple, parallel transit
streams for higher throughput.
Performance Issue
Execution of transactions on remote nodes can potentially result in performance bottlenecks.
Although multiple transactions are executed in parallel on one site, they may be propagated
serially to another site. If a T1 transaction requires a disk access on the destination site, it could
block subsequent transactions until T1 has completed its I/O. This may be truer in serial
propagation than in parallel propagation.
Materialized
View
Materialized Materialized
View View
Materialized Materialized
Views Multimaster Views
Hybrid Configuration
• By combining the multimaster configuration with updatable materialized views, you can
create sophisticated configurations (Enterprise Edition only).
• This configuration supports both full-table and table subset replication in a single
replication system.
• Materialized views can be remastered if a master site fails, resulting in greater fault
tolerance.
Deployment
templates
Support call centers
Sales
Corporate
Deployment Templates
Oracle offers deployment templates to allow the DBA to package a materialized view
environment for easy, custom, and secure deployment. Packaging a deployment template is the
process of defining the materialized view environment that will be created by the deployment
template. Packaging a deployment template prepares it for instantiation at the remote
materialized view site. Instantiation creates the materialized view site objects and populates the
materialized views with data.
In the illustration above, the corporate database might contain the following tables:
• Support
• Customer
• Order
• Product
The support call centers would need access only to the support, customer, and
product tables. The sales force would need access to the order, product, and
customer tables. A single deployment template could be set up using a parameter to
determine which materialized views are created at the materialized view site. Every time new
salespeople need to set up their laptops, they use the deployment template to create the
replication objects and populate them with data on their computers. Then the salespeople
would have access to customer information even when not connected to the network.
• Basic techniques
– Primary site ownership
– Table level
Horizontal data subsets
Vertical data subsets
• Advanced techniques
– Dynamic
– Shared
– Procedural
Data Distribution
There are many ways to distribute data, depending on your needs for the availability and
ownership of data.
Basic techniques are:
• Primary site ownership: Must be implemented through application code and cannot be
configured within Oracle Replication.
• Table level:
– Horizontal partitioning of table data by using a WHERE clause
– Vertical partitioning of table data by specifying a subset of columns
Note: Ownership of data subsets must be implemented through application code. This
cannot be configured with Oracle replication.
• Update-anywhere model
• Automatic data change conflict detection
• Requires a methodology for consistency and
convergence of data
• Dynamic
• Shared
• Replication Manager
• Replication Management API
• Replication Catalog
Manage Create
Deliver
Broadly applicable
Document mgmt.
File system Web site Source control
Access Control
Object DB
XML repositories
File systems
Customer Challenge
What makes this dilemma even more painful, and the resolution of it even more urgent, is the fact
that many organizations have not implemented just one content management system, but many.
Over time, as people within the organization have recognized new needs or vendors have stopped
by to peddle new content management wares, the number of content management applications has
proliferated. Many of these applications do essentially the same things: manage collaboration; make
it easier to publish content; help to better describe, organize, and search for particular kinds of
content; tailor information for particular audiences.
This proliferation of content management technologies has led many organizations to be justifiably
skeptical about deploying new bits of technology advertised to solve their content management
woes. Increasing IS overhead that forces users to learn and adopt to new systems, and committing
to a relationship with an additional vendor are strong disincentives for organizations to take on new
content management technologies.
End-user
focus
Document Web Content E-Commerce
management management management
Content management
infrastructure:
platform, audio/video, authoring,
Infrastructure search, configuration
focus management
Document/ Internet/
Intranet focus e-commerce focus
Market Segmentation
In short, content management is no longer a problem for application vendors to solve. Part of the
problem is that, although some of the basic requirements cross the boundaries of content
management applications, others do not. The companies who have made document management
their focus do not necessarily have multimedia asset management as their core competence. Nor
can they simply keep adding new features to ever more complex applications and proclaim that
they have met the needs of a new market segment.
Even more significantly, some of the core content management requirements, such as, “How can I
scale to terabytes of data?” or, “How can I scale to 1 million people browsing my web site?” cannot
be solved by the application vendors alone. Instead, the platform vendors, the people who design
the file systems and databases that power content management systems, have a critical role to play
in addressing these requirements.
It’s not unreasonable, therefore, to push core content management capabilities down to the platform
level first, so that applications can build on these capabilities. Application developers can then
refine these capabilities to fit their specific markets. For example, nearly every content
management application needs content-based searching and extensible metadata. The type of
content to be searched, and the kinds of attributes to be added to these bits of content, will vary
widely from application to application. And platform vendors can continue to play a constructive
role providing scalability, reliability, security, and performance as needed.
In short, the ideal world looks something like this graphic.
• Scalability
• Performance
• Reliability
• Searchability
• Security
• Manageability
End-user
focus Partners Partners
Partners
Oracle9i
Database & Application Server
interMedia, Text, iSearch,
Internet File System, Portal,
Security, Spatial/E-Location
Infrastructure Services, Syndication/Dynamic
focus Services, XML, Wireless,
Workspaces
Document/ Internet/
Intranet focus e-commerce focus
Oracle9i Database
XML
• interMedia
– Audio, video, image, wireless BMP, IVR
• Text
– Powerful text search and indexing
• Ultra Search
– Unified search for data from anywhere on the Web
HTTP WebDAV
Browser
XML
IMAP4 SMTP
Other
data sources • Unified search across
diverse information
HTTP SQL ODBC stores
Crawler
• Leverage Oracle text
Oracle Ultra Search
– Index 150+ document
types
• Crawling
– Web pages
– Databases
– Mail
Oracle text • Query results
– Enter keywords or
Content phrases into dynamically
repository generated HTML pages
LDAP
SSL SSL directory
Internet Application
server
C-17 Copyright © Oracle Corporation, 2001. All rights reserved.
Blues music
Song A
Song B
Rock music
Metadata
Artist Song B
Track length
Discard
Branch
Merge
Self-Service Publishing
Finally, you need to deliver content. Oracle Portal provides an easy-to-use interface for publishing
content, and you can define different groups and group administrators responsible for particular
content areas.
Even more significant, however, is the portlet framework in Oracle Portal. This framework
provides the hooks needed for content providers to register the different types of content available
within the portal, to which users can then subscribe in their personalized portal. The portlet
framework also lets you create reports based on content stored in the database, and portlets provide
access to other Oracle9i components, such as the Oracle Internet File System, and Oracle
applications. In short, Oracle Portal provides a web-based desktop that lets you both publish your
content as well as subscribe to other content sources.
Perform routing
computations
in the database
Location-Enabled Content
In the process of delivering content, you may want to indicate the geographical region to which it
applies. Some content may appear on one regional version of your Web site, but not in others. An
instructional video may be designed for one region, but not for others. Geographic encoding, or
geocoding, of content in the database helps to provide this kind of location intelligence. Users can
then perform geographic searches on content that applies to a particular area.
1. Trigger Portal
an event Oracle
Low dynamic
inventory services
4. Sort results
HTML by price Wireless
2. Check prices
HTML HTML 3. Process the dynamic service
• Input price to current conversion
• Input company info. to translation
• Convert price and translate info.
Exchange
Web sites Currency Translation
conversion
Web site Web site
Aggregated Content
Oracle Dynamic Services is a programmatic framework for incorporating Internet services into
portals, wireless, and B2B applications. Dynamic services let you use many standard protocols,
such as SOAP and ICE, to help broadcast that this content is available and make it available for
subscription aggregation.
Intelligent aggregation is one of Dynamic Services’ important capabilities. For example, you can
query a variety of separate sources to find the best price on laptops for sale in Paris. If you are
traveling abroad, Dynamic Services can help aggregate retail, currency conversion, and consumer
reviews into a single query.
Syndicated Content
Aside from these kinds of one-off queries, Dynamic Services provides the framework for
subscribing to content sources. The Syndication Server, based on Dynamic Services, provides
subscription services that can push content out to portals, wireless devices, and other platforms for
delivering content.
The Syndication Server includes:
• Subscription Manager to manage subscriptions for customers, perform content updated (partial
or full), and track subscription activities
• Content Syndication Manager to coordinate syndication execution flow and manage affiliates
profiles, delivery policies, targeted offers
• Syndication Affiliate Profile Manager used to create, modify, and remove user accounts and
business-related information
• Syndication System Administrator to assist the administrator to supervise the system
It also provides a Performance Monitor to track down any performance-related issues, such as a
network bottleneck due to a large amount of full content updates.
The Syndication Server capabilities in Oracle9i support the Internet Content Exchange (ICE) 1.0
protocol, and includes adapters to allow for subscription and delivery from non-ICE compliant
providers and syndicators.
XSL
Repository