Oracle Database Concepts

ORACLE
CONCEPTS
Oracle Database
PROBLEM SOLVING
METHODOLOGY
Oracle Database
YOUR SITUATION
You are not an actual DBA, but a Support Analyst
The Server where the issue occurs is most often not
known to you.
The problem is reported by someone who has poor
technical skills or none whatsoever.
The problem is often new or unfamiliar.
Oracle Database Concepts

Oracle
Database
DONT
Panic.
Jump into conclusions or solutions.
Blindly apply solutions taken from the internet.
Go for trial and error this is a source of confusion.

Oracle
Database
THE PROPER APPROACH

Define the problem and the circumstances under
which it has occurred.
Gather relevant information about the error.
Document yourself.
Determine the cause of the problem.
Determine the solution(s) for the problem.

Oracle
Database
PROBLEM DEFINITION
If you dont understand what the actual problem is,
more than likely you cannot find a solution.
The person reporting the issue may not have the
appropriate skills and may confuse you if you dont
go into the details with him. Contact him
(phone/mail) and make sure you understand the
situation and the circumstances under which it has
occurred.
The situation must make sense. If there are
contradicting facts, you are not on the right track.

Oracle
Database
DOCUMENTATION IS YOUR BEST FRIEND

Dont hesitate to take your time and read about the
error and the database feature that generates the
error.
If possible, run several quick tests to understand
what the feature is about or to familiarize yourself
with the syntax.

Oracle
Database
ISSUE FORENSICS
Just like a detective, you have to gather the facts
about the problem. Gather all relevant information:
Alert log.
Trace and incident files.
OS logs.
Clusterware logs.
Application logs.
Generate additional trace files if the problem is
reproducible or occurring regularly.

Oracle
Database
RESEARCH
It is perfectly allowed to benefit from the experience
of others.
The Oracle Support Site: MOS should help you both
improve your knowledge and determine potential
causes for your issue.
Additional information sources (Google search) are
very useful, as long as they are not a source for trial
and error attempts.
Make sure every information you collect is properly
justified. Dont rely on out of the blue solutions.

Oracle
Database
CAUSE DETERMINATION
This is the most critical step of the analysis.
It is a combination of technical skills, sound logical reasoning
and experience.
The proper understanding of the situation, a proper knowledge
on the feature plus the forensics should always help you pin
point the cause with accuracy.
This step should always materialize in a clear statement and its
justification:
The 1031 error was issued because the OS user was not
part of the DBA group.
The 4030 error was issued because the data segment for
the oracle user was set too small (200MB).
The 7445 error was caused by bug XXXX and note YYYY
from MOS confirmed this, as we have identical
errorstacks.
DETERMINE AND IMPLEMENT THE SOLUTION

Once the cause is determined, finding the solution is
relatively easy.
Several examples:
Improper or invalid settings should be corrected
based on documentation or on the current load.
Bugs are corrected by installing the fix or by
implementing the workaround.
Crashed services are restarted.
Space problems are solved by adding more
space or cleaning up the data.
Memory and Processes

What is a Process?
A process is an instance of a program running in Unix memory.

Edit:
#include<stdio.h>
int main(void)
{
printf("\n Hello World\n");
// Wait 200000 cycles
for(i=0; i<200000; i++);
return 0;
}
Compile, execute, then check the process existence:

$ gcc -Wall hello_world.c -o hello_world
$ ./hello_world
$ ps -aef | grep hello_world
oracle 1234 1222 pts/0 00:00:13 ./hello_world
Process Identifiers: PID, UID, GID
A process has (among others), the following identifiers:

UID
root
root
root
root
root
PID
3
6
7
8
10
PPID C STIME TTY

TIME CMD
2 0 Nov19 ?
00:00:00 [ksoftirqd/0]
2 0 Nov19 ?
00:00:00 [migration/0]
2 0 Nov19 ?
00:00:01 [watchdog/0]
2 0 Nov19 ?
00:00:00 [migration/1]
2 0 Nov19 ?
00:00:00 [ksoftirqd/1]
Process identifier (PID): Each process has a unique identifier

associated with it known as process ID. This ID remains unique
across the system.
Parent process identifier (PPID): parent process identifier, the PID of
the process that started the current process.
In Linux every process has a parent process. There is a process known as
'init' that is the very first process that Unix kernel creates after system boots
up. All the process there-on are children of this process either directly or
indirectly. The init process has special privileges in the sense that it cannot
be killed. The only time it terminates is when the Linux system is shut down.
The init process always has process ID 1 associated with it.
Real vs Effective User. Who am I?
User and group Identifiers (UID and GID)

The category of identifiers associated with a process is the user and group
identifiers. The user and group ID can further be classified into
Real user ID and real group ID
These identifiers give information about the user and group to which a
process belongs. Any process inherits these identifiers from its parent
process.
Effective user ID, effective group ID and supplementary group ID
Usually the effective user ID is same as real user ID but in case its
different then it means that process is running with different privileges
then what it has by default (ie inherited from its parent). This is the
case of the oracle process.
Check the permissions of the $ORACLE_HOME/bin/oracle
executable and note the setuid (suid), setgid (sgid) bits are set.
Real vs Effective User. Who am I?
The distinction between a real and an effective user id is made because you may
have the need to temporarily take another user's to perform operations for which the
real user has no privileges. If you only had one user id, then there would be no way of
changing back to your original user id afterwards.
So, the real user id is who you really are (the one who owns the process), and the
effective user id is what the operating system looks at to make a decision whether or
not you are allowed to do something.
When you log in, the login shell sets both the real and effective user id to the same
value (your real user id) as supplied by the password file (/etc/passwd).
Now, it also happens that you execute a setuid program, and besides running as
another user (e.g. root) the setuid program is also supposed to do something on your
behalf. How does this work?
After executing the setuid program, it will have your real id (since you're the process
owner) and the effective user id of the file owner (for example oracle) since setuid is
set.
Zombie and Orphan Processes

Suppose there are two processes. One is parent process while the other is child process.
There can be two scenarios we can imagine of a process being lost:
The parent dies or gets killed before the child.

The child process becomes the orphan process (as it has lost its parent). In Linux,
the init process comes to the rescue of the orphan processes and adopts them. This
means after a child has lost its parent, the init process becomes its new parent
process.
The child dies and parent does not perform wait() immediately.
Whenever the child is terminated, the termination status of the child is available to the
parent through the wait() family of calls. So, the kernel does waits for parent to
retrieve the termination status of the child before its completely wipes out the child
process. Now, In a case where parent is not able to immediately perform the wait() (in
order to fetch the termination status), the terminated child process becomes zombie
process. A zombie process is one that is waiting for its parent to fetch its termination
status. Although the kernel releases all the resources that the zombie process
was holding before it got killed, some information like its termination status, its
process ID etc are still stored by the kernel. Once the parent performs the wait()
operation, kernel clears off this information too.
Memory Layout of a Process
A process can be defined into following segments :

Stack
Stack contains all the data that is local to a function like variables, pointers etc. Each
function has its own stack. Stack memory is dynamic in the sense that it grows with
each function being called.
Heap
Heap segment contains memory that is dynamically requested by the programs for
their usage.
Data
All the global and static members become part of this segment.
Text
All the program instructions, hard-coded strings, constant values are a part of this
memory area.
Process Anatomy
Machine Memory Management

Rough definition
What hardware and OSes do allow a program to
manage its data independent of what other running
programs are doing
Generally implemented using a virtual memory model
Each process (instance of a running program) believes
it is accessing a contiguous chunk of memory
OS and CPU hide the fact that the real memory
referenced is actually fragmented and/or swapped out
to disk
Ideal OS design packs as many processes into
memory as possible while caching files too
Generic MM Model
Basic View
This shows that a virtual
memory address may actually
reference some different
address of RAM (primary
storage) or block on disk (swap
area or secondary storage).
Pieces of a virtual memory
address space may be
redirected to swap if the process
grows larger than the amount of
memory on the machine or if the
machine itself is under memory
pressure and a lot of other
processes have more immediate
need to access their pieces of
memory.
Generic Memory Management Model

The OS maintains page
More Detail
tables for each process

that map the process
virtual address to a
physical address. The
page size determines how
many page tables entries
are needed for each
process and the size of
each entry. Mapping
happens quite a bit so
much of the OS code tries
to leverage CPU
capabilities via its memory
management unit (MMU).
A good OS will make sure
frequently accessed
process memory and
filesystem files reside in
memory as much as
theoretically possible
Generic Model
Each process has a virtual memory address space
OS maps virtual memory addresses to physical
ones via page tables
32-bit processors can only natively support virtual
memory addressing from 0 to 2^32 (4GB) while
64-bit processors can, of course, address much
more
Large Page Support

Conserves kernel memory by shrinking the size of
process page tables
Each PTE maps to a larger chunk of physical memory
or swap
Instead of 4K each, 1MB or larger for example
Disadvantages
A process asking for just 1 byte of private memory
gets exclusive access to the 1MB page
Swap bigger pages to / from memory
Some advanced OS allow variable/multiple page sizes
Conserving Physical Memory Usage

If two processes are executing the same program, then
share memory occupied by read-only portions of the
compiled program code
Page table entries point to same physical address
Copy on write: share read-write sections of a program
until a process changes that page
Allow shared libraries for common code referenced by
different programs
Allow developers to create and use shared memory
across processes for their programs (e.g. the Oracle
SGA)
Only keep subset of the process page tables in
memory if needed or allow large page support
Conserving Physical Memory Usage
Oracle SGA
Contains any data structures whose contents are
shared across Oracle processes to achieve better
performance
Memory is allocated at instance startup and
released at shutdown
Concurrent read / write access is coordinated via
locking mechanisms and protocols (e.g. latches)
Those structures also reside in the SGA
Topics
Oracle Database Architecture
Data Blocks, Extents, and Segments

Tablespaces, Datafiles, and Control Files
Transaction Management
Schema Objects
The Data Dictionary
Memory Architecture
Process Architecture
Application and Networking Architecture
Oracle Utilities
Oracle Database Instance
The Relationships Among Segments, Extents,

and Data Blocks
The Relationships Among Segments, Extents,

and Data Blocks
Data Block Format
Row Piece Format
ROWID
Use DBMS_ROWID to obtain information about ROWIDs from PL/SQL

programs and SQL statements. You can find the data block number, the
object number, and other ROWID components without writing code to
interpret the base-64 character external ROWID.
Data Block Format

Common and Variable Header
The header contains general block information,
such as the block address and the type of segment
(for example, data or index).
Table Directory
This portion of the data block contains information
about the table having rows in this block.
Row Directory
This portion of the data block contains information
about the actual rows in the block (including
addresses for each row piece in the row data area).

Oracle
Database
Data Block Format

Free Space
Free space is allocated for insertion of new rows and for
updates to rows that require additional space (for
example, when a trailing null is updated to a nonnull
value).
Row Data
This portion of the data block contains table or index
data. Rows can span blocks.
Migration/Chaining when do these occur?
Parameter that determines the block size. When is this
parameter set? Can it be changed? What if I need to
create segments with another block size?

Oracle
Database
Free Space Management

Free space can be managed automatically or manually.
Free space can be managed automatically inside database
segments.
The in-segment free/used space is tracked using bitmaps, as
opposed to free lists.
Automatic segment-space management offers the following benefits:
Ease of use
Better space utilization, especially for the objects with highly
varying row sizes
Better run-time adjustment to variations in concurrent access
Better multi-instance behavior in terms of performance/space
utilization

Oracle
Database
PCTFREE, PCTUSED
PCTFREE, PCTUSED
PCTFREE, PCTUSED
ROW CHAINING
The row is too large for the left block, so the database chains the row by placing the first row
piece in the left block and the second row piece in the right block.
ROW MIGRATION
The left block contains a row that is updated so that the row is now too large for the block. The
database moves the entire row to the right block and leaves a pointer to the migrated row in the
left block. What is the impact of chaining and migration? How can this situation be solved?
Overview of Extents
An extent is a logical unit of database storage space
allocation made up of a number of contiguous data
blocks.
One or more extents in turn make up a segment.
When the existing space in a segment is completely
used, Oracle allocates a new extent for the segment.
Oracle Database
Overview of Segments
A segment is a set of extents that contains all the data
for a specific logical storage structure within a
tablespace.
Types of segments: examples.
Oracle creates this data segment when you create the
object with the CREATE statement.
DEFERRED_SEGMENT_CREATION
CREATE IMMEDIATE/DEFERRED.
Oracle Database
Overview of Segments
Segment types:
Table Segments (Partitioned Table Segments)
Index Segments (Partitioned Index Segments)
LOB Segments (Partitioned LOB Segments)
LOB Index
Temporary Segments
Undo Segments
Segment Space and the High Water Mark

The high water mark (HWM) is the point in a segment
beyond which data blocks are unformatted and have
never been used.
Manual segment space management (MSSM )
Uses free lists to manage segment space.
Blocks are preformatted in groups.
FTS reads all blocks below HWM
Automatic Segment Space Management
Uses bitmaps instead of free lists to manage
segment space.
Less concurrency
At table creation, the HWM is at the

beginning of the segment on the left.
Because no data has been inserted yet, all
blocks in the segment are unformatted and
never used.
When a transaction inserts rows into the

segment. The database must allocate a group
of blocks to hold the rows. The allocated blocks
fall below the HWM. The database formats a
bitmap block in this group to hold the metadata,
but does not preformat the remaining blocks in
the group.
The low high water mark (low HWM) marks the
point below which all blocks are known to be
formatted because they either contain data or
formerly contained data.
The database chooses a block between the HWM and low HWM and writes to it. The
database could have just as easily chosen any other block between the HWM and low
HWM, or any block below the low HWM that had available space. The blocks to either
side of the newly filled block are unformatted.
The low HWM is important in a full table scan.. For this reason, the database reads the
bitmap block to obtain the location of the low HWM. The database reads all blocks up to
the low HWM because they are known to be formatted, and then carefully reads only the
formatted blocks between the low HWM and the HWM.
Data Dictionary Parameters and Views

Parameters:
DB_BLOCK_SIZE
Views:
DBA_SEGMENTS
DBA_EXTENTS
DBA_FREE_SPACE
DBA_UNDO_EXTENTS
V$TEMPSEG_USAGE
LABORATORY
Use the dictionary views to determine the size of the SH
schema objects.
Use the dictionary views to determine the total size of
the example schemas on a per schema basis.
Use the dictionary views to determine the available free
space.
Use the dictionary views to check the undo space usage.
Use DBMS_ROWID.
Topics

Tablespaces, Datafiles, Redo Logs and Control Files
Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Oracle Database
Overview of Control Files

The database control file is a small binary file necessary
for the database to start and operate successfully.
A control file is updated continuously by Oracle during
database use, so all the copies must be available for
writing whenever the database is open.
The controlfile locations are specified by the
CONTROL_FILES parameter.
If one copy of the CF copies becomes unavailable, the
database shuts down (how?).
Overview of Control Files

Among other things, a control file contains information such as:
database name
timestamp of database creation
names and locations of associated datafiles and redo log files
tablespace information
datafile offline ranges
log history
archived log information
backup set and backup piece information
backup datafile and redo log information
datafile copy information
current log sequence number
checkpoint information
Recommendations regarding Control Files

Management
Multiplex the controlfile on multiple disks (recommended copies: 3).
Even when the underlying storage is provided with redundancy (Ex:
ASM High Redundancy) and thus ensuring a good level of hardware
failure protection, the Controlfiles Should still be logically
multiplexed. Why?
Backup the controlfile, especially after a structural change in the
database. Name structural changes that would have a significant
impact on the CF content. Name two methods of backup for the
controlfile.
Recreate the CF when lost using the CREATE CONTROLFILE
command.
Data Dictionary Parameters and Views

Parameters:
CONTROL_FILES
CONTROL_FILE_RECORD_KEEP_TIME
Views:
V$DATABASE
V$CONTROLFILE
V$CONTROLFILE_RECORD_SECTION
Overview of Redo Logs

The most crucial structure for recovery operations is the redo log,
which consists of two or more preallocated files that store all
changes made to the database as they occur.
Redo log files are filled with redo records. A redo record, also called
a redo entry, is made up of a group of change vectors, each of
which is a description of a change made to a single block in the
database.
Redo entries record data that you can use to reconstruct all changes
made to the database, including the undo segments. Therefore, the
redo log also protects rollback data. When you recover the database
using redo data, the database reads the change vectors in the redo
records and applies the changes to the relevant blocks.
Redo records are buffered in a circular fashion in the redo log buffer
of the SGA.

Redo records are written to one of the redo log
files by the Log Writer (LGWR) database
background process.
Redo records are written into the log files
when:
A transaction commits.
When the redo log buffer fills.
Every 3 seconds.
The redo log files are written in circular
fashion
Each log switch generates a new LOG
SEQUENCE NUMBER, used to uniquely
identify the archive logs.
Question: Specify what is the impact on the
database when a log switch cannot be
performed. Name possible causes.

A log file can have the following statuses:
UNUSED: never written to (new).
CURRENT: currently in use.
ACTIVE: active, but not current. Needed in case of crash
recovery.
INACTIVE: no longer needed for crash recovery.
CLEARING: recreated following a ALTER DATABASE
CLEAR LOGFILE. Once completed -> UNUSED.
Question: An ACTIVE redo log cannot be reused. How is this
status cleared into INACTIVE?
Multiplexing the Redo Logs

Multiplexing is implemented by creating groups of redo log files. A
group consists of a redo log file and its multiplexed copies.
The copies should be located on different storage devices.
Even when the underlying storage is provided with redundancy
(Ex: ASM High Redundancy) and thus ensuring a good level of
hardware failure protection, the Redo Logs Should still be logically
multiplexed. Why?
Responding to Redo Log Failure

The loss of the log file data can be catastrophic if recovery is
required.
Whenever LGWR cannot write to a member of a group, the
database marks that member as INVALID and writes an error
message to the LGWR trace file and to the database alert log to
indicate the problem with the inaccessible files.
Responding to Redo Log Failure

Scenario
Reaction
LGWR can successfully write to at

least one member in a group
Writing proceeds as normal. LGWR

writes to the available members of a
group and ignores the unavailable
members.
LGWR cannot access the next group at Database operation temporarily halts
a log switch because the group must
until the group becomes available or
be archived
until the group is archived.
All members of the next group are
inaccessible to LGWR at a log switch
because of media failure
Oracle Database returns an error, and

the database instance shuts down.
Media Recovery probably required.
All members of a group suddenly

become inaccessible to LGWR while it
is writing to them.
Oracle Database returns an error and

the database instance immediately
shuts down. Media Recovery required
in case of hardware failure.
Planning the size of the redo log files
All group file members should have the same size.

It is recommended that all log file have equal size.
The log switches should occur with a frequency of 3-5/hour.
Multiple sets of redo logs can be employed in case of non-standard
load.
The redo log file size can be set using the
V$INSTANCE_RECOVERY.OPTIMAL_LOGFILE_SIZE column.
Requires setting the FAST_START_MTTR_TARGET parameter.
It is generally recommended to have 3-5 log file groups.
Exceptions to this rule of thumb tend to be rather rare.
Log file block size is 512. It can be specified at log file group
creation in case of too much redo wastage.
Managing the Redo Logs

Create:
ALTER DATABASE ADD LOGFILE GROUP
Drop:
ALTER DATABASE DROP LOGFILE GROUP
Log switch:
ALTER SYSTEM SWITCH LOGFILE
Clear:
ALTER DATABASE CLEAR LOGFILE GROUP
Data Dictionary Views

Views:
V$LOG
V$LOGFILE
V$INSTANCE_RECOVERY
V$LOG_HISTORY
The Archive Logs

The archive logs are the collection of filled groups of redo log files
after being saved to one or more offline destinations.
Includes the redo entries and the unique log sequence number of
the identical member of the redo log group.
When in ARCHIVELOG mode, the background process ARCn
automates the archiving operations, if the database runs in
AUTOMATIC archive log mode.
Purpose of the archive logs:
Recover a database
Update a standby database
Get information about the history of a database using the
LogMiner utility
Archiving Parameters and Views

Parameters:
LOG_ARCHIVE_DEST_n (LOG_ARCHIVE_DEST and
LOG_ARCHIVE_DUPLEX_DEST).
LOG_ARCHIVE_DEST_STATE_n
LOG_ARCHIVE_FORMAT
LOG_ARCHIVE_MIN_SUCCEED_DEST
LOG_ARCHIVE_TRACE
Views:
V$DATABASE
V$ARCHIVED_LOG
V$ARCHIVE_DEST
V$ARCHIVE_PROCESSES
V$BACKUP_REDOLOG
Datafiles and Tablespaces
Question: Can an object span multiple tablespaces? When?
Tablespaces
A tablespace is a database storage unit that groups related logical

structures together. The database data files are stored in tablespaces.
Using tablespaces allows you to:
Separate user data from data dictionary data to reduce I/O
contention.
Separate data of one application from the data of another to prevent
multiple applications from being affected if a tablespace must be
taken offline.
Store the data files of different tablespaces on different disk drives to
reduce I/O contention.
Take individual tablespaces offline while others remain online,
providing better overall availability.
Optimizing tablespace use by reserving a tablespace for a particular
type of database use, such as high update activity, read-only activity,
or temporary segment storage.
Back up individual tablespaces.
Oracle Database
Types of Tablespaces
Locally Managed Tablespaces

Bigfile Tablespaces
Compressed Tablespaces
Encrypted Tablespaces
Temporary Tablespaces
Multiple Temporary Tablespaces: Using Tablespace Groups
Locally managed tablespaces

Locally managed tablespaces track all extent information in the tablespace
itself by using bitmaps, resulting in the following benefits:
Fast, concurrent space operations. Space allocations and deallocations

modify locally managed resources (bitmaps stored in header files).
Enhanced performance
Readable standby databases are allowed, because locally managed

temporary tablespaces do not generate any undo or redo (Active Data
Guard).
Space allocation is simplified, because when the AUTOALLOCATE clause

is specified, the database automatically selects the appropriate extent size.
User reliance on the data dictionary is reduced, because the necessary

information is stored in file headers and bitmap blocks.
Coalescing free extents is unnecessary for locally managed tablespaces.
Bigfile tablespaces
A bigfile tablespace is a tablespace with a single, but potentially very large (up
to 4G blocks vs 4M blocks for a small file tablespace) data file. Traditional
smallfile tablespaces, in contrast, can contain multiple data files, but the files
cannot be as large. The benefits of bigfile tablespaces are the following:
Bigfile tablespaces can significantly enhance the storage capacity of an
Oracle Database.
Bigfile tablespaces can reduce the number of data files needed for a
database and reduce the amount of SGA space required for data file
information and the size of the control file.
Bigfile tablespaces simplify database management by providing data file
transparency. SQL syntax for the ALTER TABLESPACE statement lets you
perform operations on tablespaces, rather than the underlying individual
data files.
Temporary tablespaces
A temporary tablespace contains transient data that persists only for the
duration of the session.
Intermediate sort results
Temporary tables and temporary indexes
Temporary LOBs
Temporary B-trees
Each database has a default temporary tablespace. Why?
Can be grouped in Temporary Tablespace Groups.
Tablespaces with non Standard Block Size

You can create tablespaces with block sizes different from the standard
database block size, which is specified by the DB_BLOCK_SIZE initialization
parameter. This feature lets you transport tablespaces with unlike block sizes
between databases.
Use the BLOCKSIZE clause of the CREATE TABLESPACE command.
A memory area with block size corresponding to te block size of the
tablespace must have been defined beforehand (use the
DB_nK_CACHE_SIZE parameters).
Tablespace Status
A tablespace can be:
Read Write
Read Only
Offline
Name specific situations when the tablespaces should be in the above
situations or when it would be recommended to have them in such a
circumstance.
Altering and Maintaing Tablespaces

Tablespace Operations:
Increase the size of the datafiles/tablespaces
Adding more datafiles
Question: when it is recommended to add datafiles over increase the size of
the existing?
Change its status: Read Only/Offline/Read Write/Online
Shrink the size of the datafiles/tablespaces.
Rename the tablespace.
Drop the tablespace.
Parameters and Views
Views:
V$TABLESPACE
DBA_TABLESPACES
DBA_FREE_SPACE
V$ENCRYPTED_TABLESPACES
Tablespaces and Datafiles

Oracle Database assigns each data file two associated file numbers,
an absolute file number and a relative file number, that are used to
uniquely identify it.
Type of File Number
Description
Absolute
Uniquely identifies a data file in the database. This file number can be
used in many SQL statements that reference data files in place of
using the file name. The absolute file number can be found in the
FILE# column of the V$DATAFILE or V$TEMPFILE view, or in the
FILE_ID column of the DBA_DATA_FILES or DBA_TEMP_FILES
view.
Relative
Uniquely identifies a data file within a tablespace. For small and

medium size databases, relative file numbers usually have the same
value as the absolute file number. However, when the number of data
files in a database exceeds a threshold (typically 1023), the relative
file number differs from the absolute file number. In a bigfile
tablespace, the relative file number is always 1024 (4096 on OS/390
platform).
Data Files Limitations
Operating systems impose a limit on the number of files a process can open
simultaneously. More data files cannot be created when the operating
system limit of open files is reached. Where is this limitation set?
Operating systems impose limits on the number and size of data files.
You cannot exceed the number of data files specified by the DB_FILES
initialization parameter.
When you issue CREATE DATABASE or CREATE CONTROLFILE
statements, the MAXDATAFILES parameter specifies an initial size of the
data file portion of the control file. However, if you attempt to add a new file
whose number is greater than MAXDATAFILES, but less than or equal to
DB_FILES, the control file will expand automatically so that the data files
section can accommodate more files.
Smallfile tablespaces are limited to 4M blocks while bigfile tablespaces to
4G blocks.
Data Files Management
Extend/Shrink
Online/Offline
Rename/Relocate MOVE/RENAME
Drop
Oracle-Managed Files
Oracle-managed files eliminate the need for you, the
DBA, to directly manage the operating system files
comprising an Oracle database.
You specify operations in terms of database objects
rather than filenames.
Oracle internally uses standard file system interfaces to
create and delete files as needed for the following
database structures:
Tablespaces
Redo log files
Control files
Oracle Database
Data File Views

Parameters:
DB_CREATE_FILE_DEST
DB_CREATE_ONLINE_LOG_DEST_n
DB_RECOVERY_FILE_DEST
Views:
DBA_DATA_FILES
DBA_FREE_SPACE
V$DATAFILE
V$DATAFILE_HEADER
LABORATORY
Generate the Controlfile in Text format (BACKUP
CONTROLFILE TO TRACE).
Generate a copy of the controlfile on the File System in
the folder:
$ORACLE_BASE/admin/$ORACLE_UNQNAME/cfile.
Multiplex and Drop the Control File.
Simulate the loss of a Control File. Perform a full
analysis of the situation. Fix the problem.
Recreate the redo log groups making sure they are
multiplexed with 2 members/group.
Simulate the loss of a group member . Perform a full
analysis of the situation. Fix the problem.
LABORATORY
Switch the database archivelog mode on and off.
Employ:USE_DB_RECOVERY_FILE_DEST.
Simulate a log switch hang and solve it.
Create a locally managed, ASSM tablespace.
Create a bigfile tablespace.
Create a temporary tablespace group and assign it as default
temporary tablespace.
Write a query to determine the free space (absolute and %)
for each of the existing tablespaces.
Drop all the created tablespaces.
LABORATORY
Move a datafile from ASM to the file system and reverse.
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Oracle Database
Introduction to Transactions
A transaction is a logical unit of work that contains one
or more SQL statements.
A transaction is an atomic unit. The effects of all the SQL
statements in a transaction can be either all committed
(applied to the database) or all rolled back (undone
from the database).
A transaction begins with the first executable SQL
statement.
A transaction ends when it is committed or rolled back,
either explicitly with a COMMIT or ROLLBACK statement
or implicitly when a DDL statement is issued.
Oracle Database
Introduction to Transactions
All Oracle transactions obey the basic properties of a
database transaction, known as ACID properties. ACID
is an acronym for the following:
Atomicity: All tasks of a transaction are performed or
none of them are. There are no partial transactions.
Consistency: The transaction takes the database
from one consistent state to another consistent
state.
Isolation: The effect of a transaction is not visible to
other transactions until the transaction is committed.
Durability: Changes made by committed
transactions are permanent.
System Change Number (SCN)
A system change number (SCN) is a logical, internal time stamp used by Oracle Database. SCNs
order events that occur within the database, which is necessary to satisfy the ACID properties of a
transaction. Oracle Database uses SCNs to mark the SCN before which all changes are known to
be on disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to
mark the point at which no redo exists for a set of data so that recovery can stop.
SCNs occur in a monotonically increasing sequence. Oracle Database can use an SCN like a
clock because an observed SCN indicates a logical point in time, and repeated observations
return equal or greater values. If one event has a lower SCN than another event, then it occurred
at an earlier time in the database. Several events may share the same SCN, which means that
they occurred at the same time in the database.
Every transaction has an SCN. For example, if a transaction updates a row, then the database
records the SCN at which this update occurred. Other modifications in this transaction have the
same SCN. When a transaction commits, the database records an SCN for this commit.
Oracle Database increments SCNs in the system global area (SGA). When a transaction modifies
data, the database writes a new SCN to the undo data segment assigned to the transaction. The
log writer process then writes the commit record of the transaction immediately to the online redo
log. The commit record has the unique SCN of the transaction. Oracle Database also uses SCNs
as part of its instance recovery and media recovery mechanisms.
A Banking Transaction
Overview of Transaction Management

A transaction in Oracle begins when the first executable SQL
statement is encountered.
A transaction ends when any of the following occurs:
a user issues a COMMIT or ROLLBACK statement without a
SAVEPOINT clause.
a user runs a DDL statement such as CREATE, DROP,
RENAME, or ALTER. If the current transaction contains any
DML statements, Oracle first commits the transaction, and
then runs and commits the DDL statement as a new, single
statement transaction.
a user disconnects from Oracle. The current transaction is
committed.
a user process terminates abnormally. The current transaction
is rolled back.
After one transaction ends, the next executable SQL statement
automatically starts the following transaction.
Oracle Database
Commit Transactions
Committing a transaction means making permanent the changes
performed by the SQL statements within the transaction.
Before a transaction that modifies data is committed, the following
has occurred:
Oracle has generated undo information. The undo information
contains the old data values changed by the SQL statements
of the transaction.
Oracle has generated redo log entries in the redo log buffer of
the SGA. The redo log record contains the change to the data
block and the change to the rollback block. These changes
may go to disk before a transaction is committed.
The changes have been made to the database buffers of the
SGA. These changes may go to disk before a transaction is
committed.
Oracle Database
Commit Transactions
When a transaction is committed, the following occurs:
The internal transaction table for the associated undo

tablespace records that the transaction has committed, and
the corresponding unique system change number (SCN) of
the transaction is assigned and recorded in the table.
The log writer process (LGWR) writes redo log entries in the
SGAs redo log buffers to the redo log file. It also writes the
transactions SCN to the redo log file. This atomic event
constitutes the commit of the transaction.
Oracle releases locks held on rows and tables.
Oracle marks the transaction complete.
Oracle Database
Rollback of Transactions
Rolling back means undoing any changes to data that have been
performed by SQL statements within an uncommitted transaction.
Oracle uses undo tablespaces (or rollback segments) to store old
values.
In rolling back an entire transaction, without referencing any
savepoints, the following occurs:
Oracle undoes all changes made by all the SQL statements in
the transaction by using the corresponding undo tablespace.
Oracle releases all the transactions locks of data.
The transaction ends.
Oracle Database
Savepoints In Transactions
You can declare intermediate markers called savepoints
within the context of a transaction.
Savepoints divide a long transaction into smaller parts.
Using savepoints, you can arbitrarily mark your work at
any point within a long transaction.
You then have the option later of rolling back work
performed before the current point in the transaction but
after a declared savepoint within the transaction.
Oracle Database
Savepoints In Transactions
When a transaction is rolled back to a savepoint, the
following occurs:
Oracle rolls back only the statements run after the
savepoint.
Oracle preserves the specified savepoint, but all
savepoints that were established after the specified
one are lost.
Oracle releases all table and row locks acquired
since that savepoint but retains all data locks
acquired previous to the savepoint.
Oracle Database
The Two-Phase Commit Mechanism

A distributed transaction is a transaction that includes
one or more statements that update data on two or more
distinct nodes of a distributed database.
A two-phase commit mechanism guarantees that all
database servers participating in a distributed
transaction either all commit or all undo the statements
in the transaction.
The Oracle two-phase commit mechanism is completely
transparent to users who issue distributed transactions.
A COMMIT statement denoting the end of a transaction
automatically triggers the two-phase commit mechanism
to commit the transaction.
Oracle Database
Autonomous Transactions
An autonomous transaction is an independent transaction that can be called

from another transaction, which is the main transaction. You can suspend
the calling transaction, perform SQL operations and commit or undo them in
the autonomous transaction, and then resum
Autonomous transactions have the following characteristics:
The autonomous transaction does not see uncommitted changes
made by the main transaction and does not share locks or resources
with the main transaction.
Changes in an autonomous transaction are visible to other
transactions upon commit of the autonomous transactions. Thus,
users can access the updated information without having to wait for
the main transaction to commit.
Autonomous transactions can start other autonomous transactions.
There are no limits, other than resource limits, on how many levels of
autonomous transactions can be called.
Give an example of autonomous transaction.
LABORATORY
Write a trigger that would perform, as an autonomous transaction,
the backup of overwritten values in case of an UPDATE.
Example:
http://docs.oracle.com/database/121/LNPLS/static.htm#LNPLS622
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Introduction to Schema Objects

A schema is a collection of logical structures of data, or
schema objects.
A schema is owned by a database user and has the
same name as that user. Each user owns a single
schema.
Schema objects are logical data storage structures.
Schema objects do not have a one-to-one
correspondence to physical files on disk that store their
information.
Schema Objects, Tablespaces, and Datafiles
Overview of Tables
Tables are the basic unit of data storage in an Oracle database.
Data is stored in rows and columns.
Table data is not structured (heap).
How Table Data Is Stored

When you create a table, Oracle automatically allocates
a data segment in a tablespace to hold the tables future
data.
A tables data segment (or cluster data segment, when
dealing with a clustered table) is created in either the
table owners default tablespace or in a tablespace
specifically named in the CREATE TABLE statement.
Temporary Tables
Oracle can create temporary tables to hold sessionprivate data that exists only for the duration of a
transaction or session.
For transaction-specific temporary tables, data exists for
the duration of the transaction.
For session-specific temporary tables, data exists for the
duration of the session.
Data in a temporary table is private to the session. Each
session can only see and modify its own data.
Indexes created on temporary tables are also temporary,
and the data in the index has the same session or
transaction scope as the data in the temporary table.
External Tables
External tables access data in external sources as if it
were in a table in the database.
An external table does not describe any data that is
stored in the database, nor does it describe how data is
stored in the external source.
Instead, it describes how the external table layer needs
to present the data to the server. It is the responsibility of
the access driver and the external table layer to do the
necessary transformations required on the data in the
datafile so that it matches the external table definition.
External tables are read only; therefore, no DML
operations are possible, and no index can be created on
them.
Data Loading with External Tables

The main use for external tables is to use them as a row
source for loading data into an actual table in the
database.
After you create an external table, you can then use a
CREATE TABLE AS SELECT or INSERT INTO ... AS
SELECT statement, using the external table as the
source of the SELECT clause.
When you access the external table through a SQL
statement, the fields of the external table can be used
just like any other field in a regular table.
Overview of Views
A view is a tailored presentation of the data contained in
one or more tables or other views.
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.
An Example of a View
How Views are Used

Provide an additional level of table security by restricting
access to a predetermined set of rows or columns of a
table
Hide data complexity
Simplify statements for the user
Present the data in a different perspective from that of
the base table
Isolate applications from changes in definitions of base
tables
Express a query that cannot be expressed without using
a view
Save complex queries
Oracle Database
Overview of Materialized Views

Materialized views are schema objects that can be used
to summarize, compute, replicate, and distribute data.
They are suitable in various computing environments
such as data warehousing, decision support, and
distributed or mobile computing.
Oracle Database
Overview of Materialized Views

Materialized views characteristics.
They consume storage space.
They must be refreshed when the data in their
master tables changes.
They improve the performance of SQL execution
when they are used for query rewrites.
Their existence is transparent to SQL applications
and users.
Can be partitioned.
Overview of Sequence Generator

The sequence generator provides a sequential series of numbers.
The sequence generator is especially useful in multi-user
environments for generating unique sequential numbers without the
overhead of disk I/O or transaction locking.
Sequence numbers are Oracle integers of up to 38 digits defined in
the database.
A sequence definition indicates general information, such as the
following:
The name of the sequence
Whether the sequence ascends or descends
The interval between numbers
Whether Oracle should cache sets of generated sequence
numbers in memory
Oracle Database
Overview of Synonyms
A synonym is an alias for any table, view, materialized view,
sequence, procedure, function, package, type, Java class schema
object, user-defined object type, or another synonym.
Because a synonym is simply an alias, it requires no storage other
than its definition in the data dictionary.
Synonyms are often used for security and convenience. For
example, they can do the following:
Mask the name and owner of an object
Provide location transparency for remote objects of a
distributed database
Simplify SQL statements for database users
Enable restricted access similar to specialized views when
exercising fine-grained access control
Oracle Database
Overview of 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.
An index provides a faster access path to table data.
Indexes are the primary means of reducing disk I/O
when properly used.
Oracle Database
Overview of Indexes
Oracle provides several indexing schemes, which
provide complementary performance functionality:
B-tree indexes
B-tree cluster indexes
Hash cluster indexes
Reverse key indexes
Bitmap indexes
Bitmap join indexes
Oracle Database
Internal Structure of a B-tree Index
Oracle Database
Overview of Index-Organized Tables

An index-organized table has a storage organization that
is a variant of a primary B-tree.
Unlike an ordinary (heap-organized) table whose data is
stored as an unordered collection (heap), data for an
index-organized table is stored in a B-tree index
structure in a primary key sorted manner.
Oracle Database
Structure of a Regular Table Compared with an

Index-Organized Table
Oracle Database
Overview of Database Links

A database link is a connection between two physical
database servers that allows a client to access them as
one logical database.
A database link is a pointer that defines a one-way
communication path from an Oracle Database server to
another database server.
Database links are either private or public. If they are
private, then only the user who created the link has
access; if they are public, then all database users have
access.
Overview of Database Links

Type of Link
Description
Connected user link
Users connect as themselves, which means that they must have an

account on the remote database with the same user name and password
as their account on the local database.
Fixed user link
Users connect using the user name and password referenced in the link.
For example, if Jane uses a fixed user link that connects to the hq
database with the user name and password scott/password, then she
connects as scott, Jane has all the privileges in hq granted to scott directly,
and all the default roles that scott has been granted in the hq database.
Current user link
A user connects as a global user. A local user can connect as a global user
in the context of a stored procedure, without storing the global user's
password in a link definition. For example, Jane can access a procedure
that Scott wrote, accessing Scott's account and Scott's schema on the hq
database.
Overview of 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.
Because clusters store related rows of different tables
together in the same data blocks, properly used clusters
offers these benefits:
Disk I/O is reduced for joins of clustered tables.
Access time improves for joins of clustered tables.
Oracle Database
Managing Space for Schema Objects
Managing Tablespace Alerts

Managing Resumable Space Allocation
Reclaiming Unused Space
Understanding Space Usage of Data Types
Displaying Information About Space Usage for Schema
Objects
Capacity Planning for Database Objects

Proactive help in managing disk space for tablespaces
by alerting you when available space is running low.
Two alert thresholds are defined by default: warning and
critical.
Can be defined for relative (%) or absolute(KB) values.
Implemented using GUI (OEM) or CLI
(DBMS_SERVER_ALERT)

Example:
BEGIN
DBMS_SERVER_ALERT.SET_THRESHOLD(
metrics_id => DBMS_SERVER_ALERT.TABLESPACE_BYT_FREE,
warning_operator => DBMS_SERVER_ALERT.OPERATOR_LE,
warning_value => '10240',
critical_operator => DBMS_SERVER_ALERT.OPERATOR_LE,
critical_value => '2048', o
bservation_period => 1,
consecutive_occurrences => 1,
instance_name => NULL,
object_type => DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,
object_name => 'USERS');
END;
Resumable Space Allocation

A means for suspending, and later resuming, the execution of large
database operations in the event of space allocation failures.
Therefore, you can take corrective action instead of the Oracle
Database server returning an error to the user. After the error
condition is corrected, the suspended operation automatically
resumes.
A resumable statement is suspended when one of the following
conditions occur :
Out of space condition
Maximum extents reached condition
Space quota exceeded condition.

The error is reported in the alert log.

A means for suspending, and later resuming, the execution of large
database operations in the event of space allocation failures.
Therefore, you can take corrective action instead of the Oracle
Database server returning an error to the user. After the error
condition is corrected, the suspended operation automatically
resumes.
A resumable statement is suspended when one of the following
conditions occur :
Out of space condition
Maximum extents reached condition
Space quota exceeded condition.

Resumable operations:
Queries: when running out of temporary space for sort/hash
join operations.
Any DML: INSERT, UPDATE, DELETE
Utilities: SQL*Loader, export/import, expdp/impdp
DDL.
Enabling and Disabling

Resumable Space Allocation.
Resumable space allocation is only possible when statements are
executed within a session that has resumable mode enabled.
Requires:
ALTER SESSION ENABLE RESUMABLE statement is
executed in the session.
RESUMABLE_TIMEOUT initialization parameter is set to a
non-zero value for the session.
RSA is disabled
by default.
if previously enabled and ALTER SESSION DISABLE
RESUMABLE is executed.
When RESUMABLE_TIMEOUT is set to 0.

Parameters:
RESUMABLE_TIMEOUT
Views:
DBA_RESUMABLE
V$SESSION_WAIT, EVENT column displays: statement
suspended, wait error to be cleared
PLSQL Interface:
DBMS_RESUMABLE, can be used to automatically manage
RSA situations.

Segment Advisor
The Segment Advisor identifies segments that have space available
for reclamation. It performs its analysis by examining usage and
growth statistics in the Automatic Workload Repository (AWR), and
by sampling the data in the segment.
The Automatic Segment Advisor examines database statistics,
samples segment data, and then selects the following objects to
analyze:
Tablespaces that have exceeded a critical or warning space
threshold
Segments that have the most activity
Segments that have the highest growth rate
The Segment Advisor can be run from GUI (OEM) or CLI
It can be run manually or automatically.

Shrinking Database Segments Online
Used to reclaim fragmented free space below the high water mark.
Main benefits:
Compaction of data leads to better cache utilization, which in turn leads to

better online transaction processing (OLTP) performance.
The compacted data requires fewer blocks to be scanned in full table scans,
which in turns leads to better decision support system (DSS) performance.
Examples/elaborate.
Available space in segment can be determined using Segment Advisor or
DBMS_SPACE.
In shrink operations the database compacts the segment, adjusts the high water
mark, and releases the reclaimed space.
Prerequisite:
ALTER TABLE ... ENABLE ROW MOVEMENT
can be performed only on segments in locally managed tablespaces with

automatic segment space management (ASSM).
Command: ALTER TABLE SHRINK SPACE.

Deallocating Unused Space
The database frees the unused space at the unused (high water mark) end
of the database segment and makes the space available for other segments
in the tablespace.
Available space in segment can be determined using

DBMS_SPACE.
Command: ALTER TABLE DEALLOCATE UNUSED.

Displaying Information About Space Usage for
Schema Objects
Package and Procedure/Function
Description
DBMS_SPACE.UNUSED_SPACE
Returns information about unused

space in an object (table, index, or
cluster).
DBMS_SPACE.FREE_BLOCKS
Returns information about free data

blocks in an object (table, index, or
cluster) whose segment free space is
managed by free lists (segment space
management is MANUAL).
DBMS_SPACE.SPACE_USAGE
Returns information about free data

blocks in an object (table, index, or
cluster) whose segment space
management is AUTO.

Schema Objects Space Usage Data Dictionary
Views
DBA_SEGMENTS
DBA_EXTENTS
DBA_FREE_SPACE
Capacity Planning for Database Objects

Use the DBMS_SPACE package:
Estimate the space usage of a table:
CREATE_TABLE_COST procedure estimate the
space use cost of creating a table.
Estimate the space usage of an index:
CREATE_INDEX_COST procedure estimate the
space use cost of creating an index on an existing
table
Object Growth Trends:
OBJECT_GROWTH_TREND function produces a
table of one or more rows, where each row
describes the space use of the object at a specific
time.
LABORATORY
Set an alert to generate a warning when the USERS
tablespace has 25% of free space left and a critical alert when
has 10% of free space.
Create a scenario Resumable Space Allocation. Use quota on
a tablespace to restrict the space and generate table data to
fill in this quota. Analyze the situation and fix the issue.
Delete 1000 records in the largest table in the SH schema.
Estimate the available space below the HWM. Shrink the
segment to recover the available space.
Use DBMS_SPACE to estimate the size of a table of choice,
of an index on that table and determine the growth pattern.
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Introduction to the Data Dictionary

One of the most important parts of an Oracle database is its data
dictionary, which is a read-only set of tables that provides
information about the database.
A data dictionary contains:
The definitions of all schema objects in the database (tables,
views, indexes, clusters, synonyms, sequences, procedures,
functions, packages, triggers, and so on)
How much space has been allocated for, and is currently used
by, the schema objects
Default values for columns
Integrity constraint information
The names of Oracle users
Privileges and roles each user has been granted
Auditing information, such as who has accessed or updated
various schema objects
Other general database information
Introduction to the Data Dictionary

The data dictionary is structured in tables and views, just
like other database data.
All the data dictionary tables and views for a given
database are stored in that databases SYSTEM
tablespace.
Structure of the Data Dictionary

The data dictionary consists of the following:
Base Tables
The underlying tables that store information
about the associated database.
Only Oracle should write to and read these
tables.
Users rarely access them directly because they
are normalized, and most of the data is stored in
a cryptic format.
Structure of the Data Dictionary

The data dictionary consists of the following:
User-Accessible Views
The views that summarize and display the
information stored in the base tables of the data
dictionary.
These views decode the base table data into
useful information, such as user or table names,
using joins and WHERE clauses to simplify the
information.
Most users are given access to the views rather
than the base tables.
SYS, Owner of the Data Dictionary

The Oracle user SYS owns all base tables and useraccessible views of the data dictionary.
No Oracle user should ever alter (UPDATE, DELETE, or
INSERT) any rows or schema objects contained in the
SYS schema, because such activity can compromise
data integrity.
The security administrator must keep strict control of this
central account.
Dynamic Performance Tables

Dynamic performance tables are not true tables, and
they should not be accessed by most users.
Database administrators can query and create views on
the tables and grant access to those views to other
users.
These views are sometimes called fixed views because
they cannot be altered or removed by the database
administrator.
SYS owns the dynamic performance tables; their names
all begin with V_$.
Views are created on these tables, and then public
synonyms are created for the views.
The synonym names begin with V$.
Dynamic Performance Tables

Prefix
DBA_
ALL_
USER_
User Access
Contents
Notes
Database
administrators
All objects
Some DBA_ views have

additional columns containing
information useful to the
administrator.
All users
Objects to
which user
has privileges
Includes objects owned by user.

These views obey the current
set of enabled roles.
Objects
owned by
user
Views with the prefix USER_

usually exclude the column
OWNER. This column is implied
in the USER_ views to be the
user issuing the query.
All users
LABORATORY
Use the DICTIONARY view to determine the dictionary views
related to database files.
Determine the number of dictionary views that exist for each
category (DBA, ALL, USER,V$,OTHERS).
Determine the SID and the process ID of the currently logged
session.
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Oracle Database
Oracle Memory Structures
Overview of the System Global Area

A system global area (SGA) is a group of shared
memory structures that contain data and control
information for one Oracle database instance.
An SGA and Oracle processes constitute an Oracle
instance.
Oracle automatically allocates memory for an SGA when
you start an instance, and the operating system reclaims
the memory when you shut down the instance.
Oracle Database Memory Management

Oracle Database manages memory based on the settings of memory-related
initialization parameters. The basic options for memory management are as
follows:
Automatic memory management (AMM): You specify the target size for the
database instance memory. The instance automatically tunes to the target
memory size, redistributing memory as needed between the SGA and the
instance PGA.
Automatic shared memory management(ASMM): This management mode
is partially automated. You set a target size for the SGA and then have the
option of setting an aggregate target size for the PGA or managing PGA
work areas individually.
Manual memory management: Instead of setting the total memory size, you
set many initialization parameters to manage components of the SGA and
instance PGA individually.
Oracle Database Memory Management

Test: Specify the
parameters to use for
each of the
configurations on the
left.
Automatic Memory Management

The simplest way to manage instance memory is to allow the Oracle
Database instance to automatically manage and tune it for you. To
do so (on most platforms), you set only a target memory size
initialization parameter (MEMORY_TARGET) and optionally a
maximum memory size initialization parameter
(MEMORY_MAX_TARGET). The total memory that the instance
uses remains relatively constant, based on the value of
MEMORY_TARGET, and the instance automatically distributes
memory between the system global area (SGA) and the instance
program global area (instance PGA). As memory requirements
change, the instance dynamically redistributes memory between the
SGA and instance PGA.
When automatic memory management is not enabled, you must
size both the SGA and instance PGA manually.

Because the MEMORY_TARGET initialization parameter is dynamic,
you can change MEMORY_TARGET at any time without restarting the
database. MEMORY_MAX_TARGET, which is not dynamic, serves as
an upper limit so that you cannot accidentally set MEMORY_TARGET
too high, and so that enough memory is set aside for the database
instance in case you do want to increase total instance memory in the
future. Because certain SGA components either cannot easily shrink or
must remain at a minimum size, the instance also prevents you from
setting MEMORY_TARGET too low.
With MEMORY_TARGET set, the SGA_TARGET setting becomes the
minimum size of the SGA and the PGA_AGGREGATE_TARGET
setting becomes the minimum size of the instance PGA. By setting both
of these to zero as shown, there are no minimums, and the SGA and
instance PGA can grow as needed as long as their sum is less than or
equal to the MEMORY_TARGET setting. The sizing of SQL work areas
remains automatic.
Automatic Shared Memory Management

Automatic Shared Memory Management simplifies SGA memory
management. You specify the total amount of SGA memory
available to an instance using the SGA_TARGET initialization
parameter and Oracle Database automatically distributes this
memory among the various SGA components to ensure the most
effective memory utilization.
When automatic shared memory management is enabled, the sizes
of the different SGA components are flexible and can adapt to the
needs of a workload without requiring any additional configuration.
The database automatically distributes the available memory among
the various components as required, allowing the system to
maximize the use of all available SGA memory.
Automatic Shared Memory Management

If you are using a server parameter file (SPFILE), the database
remembers the sizes of the automatically tuned SGA components
across instance shutdowns. As a result, the database instance does
not need to learn the characteristics of the workload again each time
the instance is started. The instance can begin with information from
the previous instance and continue evaluating workload where it left
off at the last shutdown.
The current size of each component can be found using the
V$SGA_DYNAMIC_COMPONENTS.
Components and Granules in the SGA

The SGA comprises several memory components, which are pools
of memory used to satisfy a particular class of memory allocation
requests. Examples of memory components include the shared pool
(used to allocate memory for SQL and PL/SQL execution), the java
pool (used for java objects and other java execution memory), and
the buffer cache (used for caching disk blocks). All SGA
components allocate and deallocate space in units of granules.
Oracle Database tracks SGA memory use in internal numbers of
granules for each SGA component.
The memory for dynamic components in the SGA is allocated in the
unit of granules. The granule size is determined by the amount of
SGA memory requested when the instance starts. Specifically, the
granule size is based on the value of the SGA_MAX_SIZE
initialization parameter.
Components and Granules in the SGA
SGA Memory Amount
Granule Size
Less than or equal to 1 GB
4 MB
Greater than 1 GB and less than or equal to 8 GB
16 MB
32 MB
64 MB
128 MB
256 MB
Greater than 128 GB
512 MB
Query the V$SGAINFO view to see the granule size that is being used
by an instance.
If you specify a size for a component that is not a multiple of granule
size, Oracle Database rounds the specified size up to the nearest
multiple. For example, if the granule size is 4 MB and you specify
DB_CACHE_SIZE as 10 MB, the database actually allocates 12 MB.
Manual Shared Memory Management

There is no initialization parameter that in itself enables
manual shared memory management. You effectively
enable manual shared memory management by
disabling both automatic memory management and
automatic shared memory management.
To enable manual shared memory management:
Set the MEMORY_TARGET initialization parameter
to 0.
Set the SGA_TARGET initialization parameter to 0.
You must then set values for the various SGA
components,
Manual Shared Memory Management

There is no initialization parameter that in itself enables
manual shared memory management. You effectively
enable manual shared memory management by
disabling both automatic memory management and
automatic shared memory management.
To enable manual shared memory management:
Set the MEMORY_TARGET initialization parameter
to 0.
Set the SGA_TARGET initialization parameter to 0.
You must then set values for the various SGA
components,
SGA Memory Structures

Database Buffer Cache
The database buffer cache, also called the buffer cache, is the memory
area that stores copies of data blocks read from data files. A buffer is a
main memory address in which the buffer manager temporarily caches a
currently or recently used data block. All users concurrently connected to a
database instance share access to the buffer cache.
Oracle Database uses the buffer cache to achieve the following goals:
Optimize physical I/O: The database updates data blocks in the
cache and stores metadata about the changes in the redo log buffer.
After a COMMIT, the database writes the redo buffers to the online
redo log but does not immediately write data blocks to the data files.
Instead, database writer (DBW) performs lazy writes in the
background.
Keep frequently accessed blocks in the buffer cache and write
infrequently accessed blocks to disk
Buffer Cache Initialization Parameters
The buffer cache initialization parameters determine the size of the buffer
cache component of the SGA. You use them to specify the sizes of caches
for the various block sizes used by the database. These initialization
parameters are all dynamic.
Oracle Database supports multiple block sizes in a database. If you create
tablespaces with non-standard block sizes, you must configure nonstandard block size buffers to accommodate these tablespaces. The
standard block size is used for the SYSTEM tablespace. You specify the
standard block size by setting the initialization parameter
DB_BLOCK_SIZE. Legitimate values are from 2K to 32K.
The sizes and numbers of non-standard block size buffers are specified by
the following parameters:
DB_2K_CACHE_SIZE
DB_4K_CACHE_SIZE
DB_8K_CACHE_SIZE
DB_16K_CACHE_SIZE
DB_32K_CACHE_SIZE
Buffer Cache Initialization Parameters

Multiple Buffer Pools
You can configure the database buffer cache with separate buffer pools that
either keep data in the buffer cache or make the buffers available for new data
immediately after using the data blocks. Particular schema objects (tables,
clusters, indexes, and partitions) can then be assigned to the appropriate buffer
pool to control the way their data blocks age out of the cache.
The KEEP buffer pool retains the schema object's data blocks in memory.
The RECYCLE buffer pool eliminates data blocks from memory as soon
as they are no longer needed.
The DEFAULT buffer pool contains data blocks from schema objects that
are not assigned to any buffer pool, as well as schema objects that are
explicitly assigned to the DEFAULT pool.
The initialization parameters that configure the KEEP and RECYCLE

buffer pools are DB_KEEP_CACHE_SIZE and
DB_RECYCLE_CACHE_SIZE.

Shared Pool

Shared Pool
The shared pool caches various types of program data. For example, the shared pool
stores parsed SQL, PL/SQL code, system parameters, and data dictionary
information.
The shared pool is divided into several subcomponents:
Library Cache: The library cache is a shared pool memory structure that
stores executable SQL and PL/SQL code. This cache contains the shared
SQL and PL/SQL areas and control structures such as locks and library cache
handles.
Data Dictionary Cache: The data dictionary is a collection of database tables

and views containing reference information about the database, its structures,
and its users. Oracle Database accesses the data dictionary frequently during
SQL statement parsing.
Server Result Cache: The server result cache is a memory pool within the
shared pool. Unlike the buffer pools, the server result cache holds result sets
and not data blocks. The server result cache contains the SQL query result
cache and PL/SQL function result cache, which share the same infrastructure.
Reserved Pool: The reserved pool is a memory area in the shared pool that
Oracle Database can use to allocate large contiguous chunks of memory.

Large Pool
The large pool is an optional memory area intended for memory
allocations that are larger than is appropriate for the shared pool.
The large pool can provide large memory allocations for the
following:
UGA for the shared server and the Oracle XA interface (used
where transactions interact with multiple databases)
Message buffers used in the parallel execution of statements
Buffers for Recovery Manager (RMAN) I/O slaves

Sizing Parameters
The SHARED_POOL_SIZE initialization parameter is a
dynamic parameter that lets you specify or adjust the
size of the shared pool component of the SGA.
The LARGE_POOL_SIZE initialization parameter is a
size of the large pool component of the SGA.
The JAVA_POOL_SIZE initialization parameter is a
size of the java pool component of the SGA.
The STREAMS_POOL_SIZE initialization parameter is a
size of the Streams Pool component of the SGA.

Sizing Parameters
The RESULT_CACHE_MAX_SIZE initialization
parameter is a dynamic parameter that enables you to
specify the maximum size of the result cache component
of the SGA.
The result cache takes its memory from the shared pool,
so if you increase the maximum result cache size,
consider also increasing the shared pool size.

Redo Log Buffer

Redo Log Buffer
The redo log buffer is a circular buffer in the SGA that stores redo entries
describing changes made to the database. A redo record is a data structure that
contains the information necessary to reconstruct, or redo, changes made to the
database by DML or DDL operations. Database recovery applies redo entries to
data files to reconstruct lost changes.
The database processes copy redo entries from the user memory space to the
redo log buffer in the SGA. The redo entries take up continuous, sequential
space in the buffer. The background process log writer process (LGWR) writes
the redo log buffer to the active online redo log group on disk.
LGWR writes redo sequentially to disk while DBW performs scattered writes of
data blocks to disk. Scattered writes tend to be much slower than sequential
writes. Because LGWR enable users to avoid waiting for DBW to complete its
slow writes, the database delivers better performance.
The LOG_BUFFER initialization parameter specifies the amount of memory that
Oracle Database uses when buffering redo entries. Unlike other SGA
components, the redo log buffer and fixed SGA buffer do not divide memory into
granules.
Overview of the Program Global Areas

A program global area (PGA) is a memory region that
contains data and control information for a server
process.
It is a non-shared memory created by Oracle when a
server process is started.
Access to it is exclusive to that server process and is
read and written only by Oracle code acting on behalf of
it.
The total PGA memory allocated by each server process
attached to an Oracle instance is also referred to as the
aggregated PGA memory allocated by the instance.
Content of the PGA
A private SQL area holds information about a parsed SQL statement and other sessionspecific information for processing. When a server process executes SQL or PL/SQL
code, the process uses the private SQL area to store bind variable values, query
execution state information, and query execution work areas.
A private SQL area is divided into the following areas:
The run-time area: This area contains query execution state information. For
example, the run-time area tracks the number of rows retrieved so far in a full
table scan.
The persistent area: This area contains bind variable values. A bind variable
value is supplied to a SQL statement at run time when the statement is
executed.
Content of the PGA
SQL Work Areas: A work area is a private allocation of PGA memory used for
memory-intensive operations. For example, a sort operator uses the sort area
to sort a set of rows. Similarly, a hash join operator uses a hash area to build
a hash table from its left input, whereas a bitmap merge uses the bitmap
merge area to merge data retrieved from scans of multiple bitmap indexes.
Memory Management Dictionary Views
V$SGA
V$SGAINFO
V$SGASTAT
V$PGASTAT
V$MEMORY_DYNAMIC_COMPONENTS
V$SGA_DYNAMIC_COMPONENTS
V$SGA_DYNAMIC_FREE_MEMORY
V$MEMORY_CURRENT_RESIZE_OPS
V$SGA_CURRENT_RESIZE_OPS
V$MEMORY_RESIZE_OPS
V$SGA_RESIZE_OPS
V$MEMORY_TARGET_ADVICE
V$SGA_TARGET_ADVICE
V$PGA_TARGET_ADVICE
LABORATORY
Check the granule size of your database.
Verify if the current size of the memory components are
multiples of the granule size.
Verify the sizes of the dynamically sized components.
Switch the AMM into ASMM and into MSMM.
Verify the sizes of the dynamically sized components.
Switch back.
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Oracle Database
What is a Process?
A process is a mechanism in an operating system that can run a
series of steps. The process execution architecture depends on the
operating system. For example, on Windows an Oracle background
process is a thread of execution within a process. On Linux and
UNIX, an Oracle process is either an operating system process or a
thread within an operating system process.
Processes run code modules. All connected Oracle Database users
must run the following modules to access a database instance:
Application or Oracle Database utility: A database user runs a
database application, such as a precompiler program or a
database tool such as SQL*Plus, that issues SQL statements
to a database.
Oracle database code: Each user has Oracle database code
executing on his or her behalf that interprets and processes
the application's SQL statements.
Types of processes
A database instance contains or interacts with the following types of processes:
A client process runs the application or Oracle tool code.
An Oracle process is a unit of execution that runs the Oracle database
code. In the multithreaded architecture, an Oracle process can be an
operating system process or a thread within an operating system process.
Oracle processes include the following subtypes:
A background process starts with the database instance and perform
maintenance tasks such as performing instance recovery, cleaning up
processes, writing redo buffers to disk, and so on.
A server process performs work based on a client request: these
processes parse SQL queries, place them in the shared pool, create
and execute a query plan for each query, and read buffers from the
database buffer cache or from disk.
A slave process performs additional tasks for a background or server
process.
An Oracle
Instance
Overview of ClientProcesses
When a user runs an application program (such as a Pro*C
program) or an Oracle tool (such as Enterprise Manager or
SQL*Plus), Oracle creates a user process to run the users
application.
Connection and session are closely related to user process but are
very different in meaning.
A connection is a communication pathway between a user
process and an Oracle instance. A communication pathway is
established using available inter-process communication
mechanisms (on a computer that runs both the user process
and Oracle) or network software (when different computers run
the database application and Oracle, and communicate
through a network)
A session is a specific connection of a user to an Oracle
instance through a user process.
Overview of Oracle Processes

Oracle creates server processes to handle the requests of
user processes connected to the instance.
Server processes created on behalf of each users application
can perform one or more of the following:
Parse and run SQL statements issued through the
application, including creating and executing the query
plan (see "Stages of SQL Processing")
Execute PL/SQL code
Read data blocks from data files into the database buffer
cache (the DBW background process has the task of
writing modified blocks back to disk)
Return results in such a way that the application can
process the information
Background Processes
Background processes are additional processes used by a
multiprocess Oracle database. The background processes perform
maintenance tasks required to operate the database and to
maximize performance for multiple users.
Each background process has a separate task, but works with the
other processes. For example, the LGWR process writes data from
the redo log buffer to the online redo log. When a filled redo log file
is ready to be archived, LGWR signals another process to archive
the redo log file.
Oracle Database creates background processes automatically when
a database instance starts. An instance can have many background
processes, not all of which always exist in every database
configuration.
Name several background processes.
Background Processes
Shared Server Architecture

Shared server architecture eliminates the need for a dedicated
server process for each connection.
A dispatcher directs multiple incoming network session requests to a
pool of shared server processes.
An idle shared server process from a shared pool of server
processes picks up a request from a common queue, which means
a small number of shared servers can perform the same amount of
processing as many dedicated servers.
A number of different processes are needed in a shared server
system:
A network listener process that connects the user processes to
dispatchers or dedicated servers
One or more dispatcher processes
One or more shared server processes
The Shared Server Configuration and

Processes
Dedicated Server Configuration

In this configuration, a user process runs the database
application on one computer, and a server process runs
the associated Oracle database server on another
computer.
Slave Processes
Slave processes are background processes that perform work on
behalf of other processes.
I/O Slave Processes: I/O slave processes (Innn) simulate
asynchronous I/O for systems and devices that do not support
it.
Parallel Execution (PX) Server Processes: In parallel
execution or parallel processing, multiple processes work
together simultaneously to run a single SQL statement. By
dividing the work among multiple processes, Oracle Database
can run the statement more quickly. For example, four
processes handle four different quarters in a year instead of
one process handling all four quarters by itself.
Terminating a Session
Sometimes it is necessary to terminate current user sessions. For
example, an outstanding blocker holding everyone in hang.
You terminate a current session using the SQL statement ALTER
SYSTEM KILL SESSION.
A session marked to be terminated is indicated in V$SESSION with
a status of KILLED and a server that is something other than
PSEUDO.
An active session , when terminated, receives the ORA-00028: your
session has been killed
For an inactive session , ORA-00028 message is not returned
immediately. The message is not returned until the user
subsequently attempts to use the terminated session.
Data Dictionary Views related to Processes

V$PROCESS
V$BGPROCESS
V$SESSION
LABORATORY
List all the background processes.
Create a sqlplus session and get its session SID and
SERIAL#, as well as the OS process PID.
Terminate the sqlplus session using the ALTER SYSTEM
KILL SESSION command.
Check the session/proces status in the V$ views as well as in
the SGA. Elaborate/Questions.
Completely clean up the remains of the session.
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Oracle Database
The Client/Server Architecture
Multi-tier Architecture Environment
Multi-tier Architecture Environment

Clients: A client initiates a request for an operation to be
performed on the database server. The client can be a
Web browser or other end-user program. In a multitier
architecture, the client connects to the database server
through one or more application servers.
Application Servers: An application server provides
access to the data for the client. It serves as an interface
between the client and one or more database servers,
and hosts the applications.
Database Servers: A database server provides the data
requested by an application server on behalf of a client.
The database performs the query processing.
Overview of Oracle Net Services

Oracle Net Services enables a network session from an application
to a database instance and a database instance to another
database instance.
Oracle Net Services uses the communication protocols or
application programmatic interfaces (APIs) supported by a wide
range of networks to provide a distributed database and distributed
processing for Oracle.
A communication protocol is a set of rules that determine how
applications access the network and how data is subdivided
into packets for transmission across the network.
An API is a set of subroutines that provide, in the case of
networks, a means to establish remote process-to-process
communication through a communication protocol.
Overview of Oracle Net Services

After a network session is established, Oracle Net
Services acts as a data courier for the client application
and the database server.
It is responsible for establishing and maintaining the
connection between the client application and database
server, as well as exchanging messages between them.
Oracle Net Services is able to perform these jobs
because it is located on each computer in the network.
Oracle Net Services provides location transparency,
centralized configuration and management, and quick
out-of-the-box installation and configuration.
The Oracle Net Listener

The Oracle Net Listener (the listener) is a server-side process
that listens for incoming client connection requests and
manages traffic to the database. When a database instance
starts, and at various times during its life, the instance
contacts a listener and establishes a communication pathway
to this instance.
Service registration enables the listener to determine whether
a database service and its service handlers are available. A
service handler is a dedicated server process or dispatcher
that acts as a connection point to a database. During
registration, the LREG(12c)/PMON (previous to 12c) process
provides the listener with the instance name, database
service names, and the type and addresses of service
handlers. This information enables the listener to start a
service handler when a client request arrives.

The basic steps by which a client
establishes a connection through a
listener are:
1. A client process or another
database requests a connection.
2. The listener selects an appropriate
service handler to service the
client request and forwards the
request to the handler.
3. The client process connects
directly to the service handler. The
listener is no longer involved in
the communication.
Service Names
A service name is a logical representation of a
service used for client connections. When a client
connects to a listener, it requests a connection to
a service. When a database instance starts, it
registers itself with a listener as providing one or
more services by name. Thus, the listener acts as
a mediator between the client and instances and
routes the connection request to the right place.
A single service, as known by a listener, can
identify one or more database instances. Also, a
single database instance can register one or
more services with a listener. Clients connecting
to a service need not specify which instance they
require.
The services enable the same database to be
identified differently by different clients. A
database administrator can limit or reserve
system resources, permitting better resource
allocation to clients requesting one of these
services.
Service Registration
In Oracle Net, service registration is a feature by which the LREG process dynamically
registers instance information with a listener. This information enables the listener to
forward client connection requests to the appropriate service handler. LREG provides
the listener with information about the following:
Names of the database services provided by the database
Name of the database instance associated with the services and its current and
maximum load
Service handlers (dispatchers and dedicated servers) available for the instance,
including their type, protocol addresses, and current and maximum load
Service registration is dynamic and does not require configuration in the listener.ora
file. Dynamic registration reduces administrative overhead for multiple databases or
instances.
The initialization parameter SERVICE_NAMES lists the services an instance belongs
to. On startup, each instance registers with the listeners of other instances belonging to
the same services. During database operations, the instances of each service pass
information about CPU use and current connection counts to all listeners in the same
services. This communication enables dynamic load balancing and connection failover.
Manual Service Registration

To manually register a database with a listener:
Set LOCAL_LISTENER and/ora REMOTE_LISTENER
parameters
Run:
ALTER SYSTEM REGISTER;
If not specified as a connect descriptor, the LOCAL_LISTENER
and REMOTE_LISTENER must point to valid entries in the
tnsnames.ora file of the database.
Network Configuration Files

File
Usage
tnsnames.ora
Client file, this file contains network service names mapped to connect
descriptors.
sqlnet.ora
Used in both database and client configuration, may include:

Client domain to append to unqualified service names or network
service names
Order of naming methods the client should use when resolving a name
Logging and tracing features to use
Route of connections
External naming parameters
Oracle security parameters
Database access control parameters
listener.ora
Database server file, this is the configuration file for the listener and may
include the following:
Protocol addresses it is accepting connection requests on
Database and nondatabase services it is listening for
Control parameters used by the listener
Configure the Local Naming Method

The tnsnames.ora file is a configuration file that contains network
service names mapped to connect descriptors for the local naming
method, or net service names mapped to listener protocol addresses.
A net service name is an alias mapped to a database network
address contained in a connect descriptor. A connect descriptor
contains the location of the listener through a protocol address and the
service name of the database to which to connect. Clients and
database servers (that are clients of other database servers) use the
net service name when making a connection with an application.
By default, the tnsnames.ora file is located in the
ORACLE_HOME/network/admin directory.
Configure the Local Naming Method

Example of tnsnames.ora file entry:
test1 =
(DESCRIPTION=
(ADDRESS_LIST=
(FAILOVER=on)
(LOAD_BALANCE=off)
(ADDRESS=(PROTOCOL=tcp)(HOST=host1.example.com)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=host2.example.com)(PORT=1522)))
(ADDRESS=(PROTOCOL=tcp)(HOST=host3.example.com)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=test.example.com)))
Explain this connect descriptor.
Configure the Listener

Oracle Net Listener is a separate process that runs on the database
server. It receives incoming client connection requests and manages
the traffic of these requests to the database server.
Example:
listener_name=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=host1.example.com)(PORT=1521))))
Explain the listener configuration.
Configure the Listener

Static listener registration:
LISTENER=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=test-server.example.com)(PORT=1521))
(ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(GLOBAL_DBNAME=test.example.com)
(ORACLE_HOME=/oracle)
(SID_NAME=sales))
(SID_DESC=
(SID_NAME=plsextproc)
(ORACLE_HOME=/oracle)
(PROGRAM=extproc)))
Network troubleshooting
Potential tests
Client Side:
Check the location of the tnsnames.ora file. Verify the value of
TNS_ADMIN environment variable.
Verify the tnsnames.ora file content.
Check the listener availability using the tnsping utility.
Check if the listener host is responding to ping.
Generate Oracle Network Trace files.
Generate OS Network Trace files (Wireshark).
Potential tests
Server Side:
Check if the listener is up and running using either srvctl or lsnrctl
srvctl status listener l listener_name
lsnrctl status
Check the services registered with the listener using the lsnrctl
utility:
lsnrctl status
lsnrctl services
Check the configuration files:
listener.ora and sqlnet.ora for the listener
sqlnet.ora for the database
Potential tests
Server Side:
Check the environment variables that are set in the OS user profile
that starts the listener/database or in the Oracle Cluster Registry, if
used.
Enable Database tracing (sqlnet.ora of the database).
Enable Listener tracing (sqlnet.ora of the listener).
Enable OS Tracing (Wireshark)
Tracing Parameters:
CLIENT SQLNET.ORA
trace_level_client = 16
trace_file_client = cli
trace_directory_client = <some directory available to the oracle user>
diag_adr_enabled=off
DATABASE SERVER SQLNET.ORA

trace_level_server = 16
trace_file_server = svr
trace_directory_server = <some directory available to the oracle user>
diag_adr_enabled=off
LABORATORY
Where is the location of the client sqlnet files? Explain.
Create a new listener using static configuration and use it to
stop and start the database
Enable client/server tracing. Create a new database session
and analyze the trace files.
Try to connect using
sqlplus sys/test@invalid_entry
Fix the situation so that this connection eventually succeeds.
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities
Overview of Data Pump Export and Import

Oracle Data Pump technology enables very high-speed
movement of data and metadata from one database to
another.
This technology is the basis for Oracle's data movement
utilities, Data Pump Export and Data Pump Import.
Data Pump enables you to specify whether a job should
move a subset of the data and metadata.
This is done using data filters and metadata filters, which
are implemented through Export and Import parameters.
Overview of SQL*Loader
SQL*Loader loads data from external files into tables of
an Oracle database.
It has a powerful data parsing engine that puts little
limitation on the format of the data in the datafile.
A typical SQL*Loader session takes as input a control
file, which controls the behavior of SQL*Loader, and one
or more datafiles.
The output of SQL*Loader is an Oracle database (where
the data is loaded), a log file, a bad file, and potentially, a
discard file.
Overview of External Tables

The external tables feature is a complement to existing
SQL*Loader functionality.
It lets you access data in external sources as if it were in
a table in the database.
Neither data manipulation language (DML) operations
nor index creation are allowed on an external table.
To use the external tables feature, you must have some
knowledge of the file format and record format of the
datafiles on your platform.
Overview of LogMiner
Oracle LogMiner enables you to query redo log files
through a SQL interface.
All changes made to user data or to the database
dictionary are recorded in the Oracle redo log files.
Therefore, redo log files contain all the necessary
information to perform recovery operations.
LogMiner functionality is available through a commandline interface or through the Oracle LogMiner Viewer
graphical user interface (GUI).
The LogMiner Viewer is a part of Oracle Enterprise
Manager.
Overview of DBVERIFY
DBVERIFY is an external command-line utility that
performs a physical data structure integrity check.
It can be used on offline or online databases, as well on
backup files.
You use DBVERIFY primarily when you need to ensure
that a backup database (or datafile) is valid before it is
restored or as a diagnostic aid when you have
encountered data corruption problems.
Because DBVERIFY can be run against an offline
database, integrity checks are significantly faster.
Overview of DBNEWID
DBNEWID is a database utility that can change the
internal, unique database identifier (DBID) and the
database name (DBNAME) for an operational database.
Therefore, you can manually create a copy of a
database and give it a new DBNAME and DBID by recreating the control file, and you can register a seed
database and a manually copied database together in
the same RMAN repository.
The DBNEWID utility lets you change any of the
following:
Only the DBID of a database
Only the DBNAME of a database
Both the DBNAME and DBID of a database
LABORATORY
Create an external table using the oracle datapump driver.
Run dbverify to check the consistency of a datafile.
Create an export of the SH schema.
Topics

Schema Objects
The Data Dictionary
Memory Architecture
Oracle Utilities

A database instance is a set of memory structures that
manage database files.
The instance manages its associated data and serves the
users of the database.
When an instance is started, Oracle Database allocates a
memory area called the system global area (SGA) and starts
the background processes.
Oracle System Identifier (SID) is a unique name for an Oracle
database instance on a specific host. On UNIX and Linux,
Oracle Database uses the SID and Oracle home values to
create a key to shared memory. Also, Oracle Database uses
the SID by default to locate the initialization parameter file,
which locates relevant files such as the database control files.
Overview of Instance and Database Startup

The three steps to starting an Oracle database and
making it available for system wide use are:
Start an instance.
Mount the database.
Open the database.
A database administrator can perform these steps using
the SQL*Plus STARTUP statement, Enterprise Manager
or the srvctl utility.
Overview of Instance and Database Startup
How an Instance is Started

When Oracle starts an instance, it reads the server
parameter file (SPFILE) or initialization parameter file to
determine the values of initialization parameters.
Then, it allocates an SGA, which is a shared area of
memory used for database information, and creates
background processes.
At this point, no database is associated with these
memory structures and processes.
How a Database is Mounted

The instance mounts a database to associate the
database with that instance.
To mount the database, the instance finds the database
control files and opens them.
Oracle then reads the control files to get the names of
the databases datafiles and redo log files.
At this point, the database is still closed and is
accessible only to the database administrator.
The database administrator can keep the database
closed while completing specific maintenance
operations. However, the database is not yet available
for normal operations.
What Happens When You Open a Database

Opening a mounted database makes it available for
normal database operations.
Any valid user can connect to an open database and
access its information.
When you open the database, Oracle opens the online
datafiles and redo log files.
Overview of Database and Instance Shutdown

The three steps to shutting down a database and its
associated instance are:
Close the database.
Unmount the database.
Shut down the instance.
A database administrator can perform these steps using
SQL*Plus, Enterprise Manager or srvctl utility.
Oracle automatically performs all three steps whenever
an instance is shut down.

Shutdown Modes
Database Behavior
ABORT
IMMEDIATE
TRANSACTIONAL
NORMAL
Permits new user

connections
No
No
No
No
Waits until current

sessions end
No
No
No
Yes
Waits until current

transactions end
No
No
Yes
Yes
Performs a
checkpoint and
closes open files
No
Yes
Yes
Yes

When you close a database, Oracle writes all database data
and recovery data in the SGA to the datafiles and redo log
files, respectively. Next, Oracle closes all online datafiles and
redo log files. At this point, the database is closed and
inaccessible for normal operations. The control files remain
open after a database is closed but still mounted.
After the database is closed, Oracle unmounts the database
to disassociate it from the instance. At this point, the instance
remains in the memory of your computer. After a database is
unmounted, Oracle closes the control files of the database.
When you shut down an instance, the SGA is removed from
memory and the background processes are terminated.
Overview of Checkpoints
A checkpoint is a crucial mechanism in consistent database
shutdowns, instance recovery, and Oracle Database
operation generally. The term checkpoint has the following
related meanings:
A data structure that indicates the checkpoint position,
which is the SCN in the redo stream where instance
recovery must begin
The checkpoint position is determined by the oldest dirty
buffer in the database buffer cache. The checkpoint
position acts as a pointer to the redo stream and is
stored in the control file and in each data file header.
The writing of modified database buffers in the database
buffer cache to disk
Overview of Checkpoints
Oracle Database uses checkpoints to achieve the following
goals:
Reduce the time required for recovery in case of an
instance or media failure
Ensure that the database regularly writes dirty buffers in
the buffer cache to disk
Ensure that the database writes all committed data to
disk during a consistent shutdown
When Oracle Database Initiates Checkpoints

The checkpoint process (CKPT) is responsible for writing
checkpoints to the data file headers and control file.
Thread checkpoints: The database writes to disk all buffers
modified by redo in a specific thread before a certain target.
The set of thread checkpoints on all instances in a database
is a database checkpoint. Thread checkpoints occur in the
following situations:
Consistent database shutdown
ALTER SYSTEM CHECKPOINT statement
Online redo log switch
ALTER DATABASE BEGIN BACKUP statement
When Oracle Database Initiates Checkpoints

Tablespace and data file checkpoints: The database writes to
disk all buffers modified by redo before a specific target. A
tablespace checkpoint is a set of data file checkpoints, one for
each data file in the tablespace. These checkpoints occur,
among others, when making a tablespace read-only or taking
it offline normal, shrinking a data file, or executing ALTER
TABLESPACE BEGIN BACKUP.
Incremental checkpoints: An incremental checkpoint is a
type of thread checkpoint partly intended to avoid writing large
numbers of blocks at online redo log switches. DBW checks
at least every three seconds to determine whether it has work
to do. When DBW writes dirty buffers, it advances the
checkpoint position, causing CKPT to write the checkpoint
position to the control file, but not to the data file headers.
Overview of Instance Recovery

Instance recovery is the process of applying records in the online
redo log to data files to reconstruct changes made after the most
recent checkpoint. Instance recovery occurs automatically when an
administrator attempts to open a database that was previously shut
down inconsistently.
Instance recovery ensures that the database is in a consistent state
after an instance failure. The files of a database can be left in an
inconsistent state because of how Oracle Database manages
database changes.
When a transaction is committed, log writer process (LGWR) writes
both the remaining redo entries in memory and the transaction SCN
to the online redo log. However, the database writer (DBW) process
writes modified data blocks to the data files whenever it is most
efficient. For this reason, uncommitted changes may temporarily
exist in the data files while committed changes do not yet exist in the
data files.
Overview of Instance Recovery

If an instance of an open database fails, either because of a
SHUTDOWN ABORT statement or abnormal termination, then the
following situations can result:
Data blocks committed by a transaction are not written to the
data files and appear only in the online redo log. These
changes must be reapplied to the data files.
The data files contains changes that had not been committed
when the instance failed. These changes must be rolled back
to ensure transactional consistency.
The SMON background process performs instance recovery,
applying online redo automatically. No user intervention is required.
Useful Views
V$TRANSACTION
V$FAST_START_SERVERS
V$FAST_START_TRANSACTIONS
LABORATORY
Use the dictionary views to determine the state of the database.
Run: alter system set
audit_trail=/u01/app/oracle/admin/$ORACLE_SID/admp
scope=spfile; Make sure to replace the $ORACLE_SID with your
actual instance name.
Shutdown
Restart. Explain.
Make a large update on the SH.SALES table. Check the status of
the transaction in v$transaction. Identify the SQL in V$SQL.
Shutdown abort the database.
Startup and verify the recovery in the alert log and in the
v$fast_start* views.
Topics
Oracle Database Features
Data Concurrency and Consistency

Manageability
Backup and Recovery
Business Intelligence
High Availability
Partitioned Tables and Indexes
Content Management
Database Security
Data Integrity
Triggers
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Transactions and Undo
When a
transaction is
executing, it
generates undo.
Each transaction
is allocated to an
undo where the
information
required to revert
to the previous
image is written.
The mechanism used by Oracle to rollback is as below:

Each block header that is modified by a transaction holds the
information regarding the transaction and the undo segment that has
been employed by the transaction, for example:
Itl
Xid
Uba
Flag Lck
Scn/Fsc
0x01 0x0009.019.0000392b 0x00800c73.014d.2b --U- 10 fsc
0x0000.ce7634e6
The XID is uniquely identifying a transaction and is made of 3 fields:
1. undo segment number (0009)
2. transaction table slot number (019)
3. sequence number specific to transaction table slot (0000392b)
Each undo segment holds a "transaction table", in which the metadata

of the transaction is written, which is the place in the undo where the
actual transaction change is to be found, together with the SCN (and
the corresponding timestamp) and the transaction status (committed
or active). The transaction table is part of the undo segment header
and, as such, has a relatively small size. Each time a new transaction
is getting a record in this table, the sequence that is specific to this
particular record/slot is increased by 1. This means that each XID of a
transaction is unique for the lifetime of a database.
Donc, le Uba (undo block address) permet de trouver le undo

segment et le XID de trouver le record (slot) de la transaction table ou
rside l'adresse ou on trouve les informations undo de la transaction.
Consequently, the
UBA Uba (undo
block address)
allows the
consisetency
mechanims to find
the undo segment
and the XID to find
the record (slot) of
the transaction table
where is the
address (pointer) to
the undo segment
where the
transaction actual
undo data is found.
As such, this triple redirection: data block -> undo header -> undo
transaction table -> undo data, allows Oracle to find the information
required for the process named read consistency, which means rebuilding
a previous block v
As indicated, number of slots of the transaction table are limited. Under the
pressure of new transactions, the data regarding older transactions would
be overwritten. In order to retain this information for the duration specified
by undo_retention, Oracle writes the older images of the transaction table in
the same undo segment. There is no metadata regarding the undo
transaction table. Equally, this information is not indexed. As such, to
recreate the older images of the transaction tables, Oracle must recreate
the previous versions of the undo header simply by retreiving all the
previous images of the transaction tables until it finds the transaction it is
looking for. If this information is buried under a large number of
transactions, this can mean a long time and significant resources.
Delayed Commit Cleanout
Oracle makes lazy cleanouts, which means that a transaction T1 can change a block
data, but it doesnt necessarily return to do what we call a cleanout it does not
revisit all the blocks to mark the transaction as committed. The following session
reading the block would perform this job instead. A second transaction that would run
a DML on the same records as T1 would check the transaction table of the undo and,
if it finds it overwritten, it would not go further to check the undo data it needs just to
overwrite this data and has no interest in building previous images of the block.
A transaction T2 that runs a SELECT, might require additional data, because if its
starting SCN S2 is inferior to the SCN of T1 (S1), it has recreate the image of the
block that existed at the time of S2. If it does not, then it would still have to mark
transaction T1 as committed in the data block, so that the forthcoming transaction
would not have to go through the same process.
Not all transactions leave behind this kind of non committed data. They appear when
the number of blocks touched by a transaction is very large, when the blocks are
already flushed on disk and are no longer present in the buffer cache or if the block is
already cleaned out by another transaction.
Preventable Phenomena and Transaction

Isolation Levels
The ANSI/ISO SQL standard (SQL92) defines four levels of
transaction isolation with differing degrees of impact on transaction
processing throughput.
These isolation levels are defined in terms of three phenomena that
must be prevented between concurrently executing transactions.
The three preventable phenomena are:
Dirty reads: A transaction reads data that has been written by
another transaction that has not been committed yet.
Nonrepeatable (fuzzy) reads: A transaction rereads data it has
previously read and finds that another committed transaction
has modified or deleted the data.
Phantom reads (or phantoms): A transaction re-runs a query
returning a set of rows that satisfies a search condition and
finds that another committed transaction has inserted
additional rows that satisfy the condition.
Preventable Phenomena and Transaction

Isolation Levels
SQL92 defines four levels of isolation in terms of the
phenomena a transaction running at a particular isolation
level is permitted to experience.
Oracle offers the read committed and serializable
isolation levels, as well as a read-only mode that is not
part of SQL92. Read committed is the default.
Multiversion Concurrency Control

Oracle automatically provides read consistency to a
query so that all the data that the query sees comes from
a single point in time (statement-level read consistency).
Oracle can also provide read consistency to all of the
queries in a transaction (transaction-level read
consistency).
Oracle uses the information maintained in its rollback
segments to provide these consistent views.
The rollback segments contain the old values of data
that have been changed by uncommitted or recently
committed transactions.
Transactions and Read Consistency
Oracle Isolation Levels
Oracle Database
Comparison of Read Committed and

Serializable Isolation
Oracle gives the application developer a choice of two
transaction isolation levels with different characteristics.
Both the read committed and serializable isolation levels
provide a high degree of consistency and concurrency.
Transactions and Data Concurrency

Oracle provides data concurrency and integrity between
transactions using its locking mechanisms.
Because the locking mechanisms of Oracle are tied closely to
transaction control, application designers need only define
transactions properly, and Oracle automatically manages locking.
Oracle locking is fully automatic and requires no user action.
Implicit locking occurs for all SQL statements so that database users
never need to lock any resource explicitly.
Oracles default locking mechanisms lock data at the lowest level of
restrictiveness to guarantee data integrity while allowing the highest
degree of data concurrency.
Modes of Locking
Oracle uses two modes of locking in a multi-user
database:
Exclusive lock mode prevents the associates
resource from being shared. This lock mode is
obtained to modify data. The first transaction to lock
a resource exclusively is the only transaction that
can alter the resource until the exclusive lock is
released.
Share lock mode allows the associated resource to
be shared, depending on the operations involved.
Multiple users reading data can share the data,
holding share locks to prevent concurrent access by
a writer (who needs an exclusive lock). Several
transactions can acquire share locks on the same
resource.
Types of Locks
Oracle automatically uses different types of locks to
control concurrent access to data and to prevent
destructive interaction between users.
Oracle automatically locks a resource on behalf of a
transaction to prevent other transactions from doing
something also requiring exclusive access to the same
resource.
The lock is released automatically when some event
occurs so that the transaction no longer requires the
resource.
Throughout its operation, Oracle automatically acquires
different types of locks at different levels of
restrictiveness depending on the resource being locked
and the operation being performed.
Types of Locks
Oracle locks fall into one of three general categories.
Explicit (Manual) Data Locking

Oracle always performs locking automatically to ensure
data concurrency, data integrity, and statement-level
read consistency.
However, you can override the Oracle default locking
mechanisms. Overriding the default locking is useful in
situations such as these:
Applications require transaction-level read
consistency or repeatable reads.
Applications require that a transaction have
exclusive access to a resource so that the
transaction does not have to wait for other
transactions to complete.
Deadlocks
A deadlock is a situation in which two or more users are
waiting for data locked by each other. Deadlocks prevent
some transactions from continuing to work.
Oracle Database automatically detects deadlocks and
resolves them by rolling back one statement involved in
the deadlock, releasing one set of the conflicting row
locks. The database returns a corresponding message to
the transaction that undergoes statement-level rollback.
The statement rolled back belongs to the transaction that
detects the deadlock. Usually, the signalled transaction
should be rolled back explicitly, but it can retry the rolledback statement after waiting.
Overview of Oracle Flashback Query

Oracle Flashback Query lets you view and repair
historical data.
You can perform queries on the database as of a certain
wall clock time or user-specified system change number
(SCN).
Flashback Query uses Oracle's multi-version readconsistency capabilities to restore data by applying undo
as needed.
Using Flashback Query, you can query the database as
it existed in the past, as long as it remains in the undo
segments.
Views related to locking mechanisms
V$LOCK
V$SESSION_WAIT
V$SESSION
V$LOCKED_OBJECT
LABORATORY
Generate a deadlock on a table of choice. Note the error being
issued. Look into the alert log for the generated trace file and
analyze it.
In 2 different sessions, update the same records of a table. Use the
V$ views to analyze the situation.
Manually terminate the locking session.
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Installing Oracle and Getting Started

The Oracle Universal Installer (OUI) is a GUI tool for installing
Oracle software.
It automates all installation tasks, performs comprehensive
prerequisite checks (such as operating system version,
software patches, and capacity), installs selected software
components, and performs all post-install configuration.
The Enterprise Manager Database Management Console is
automatically configured to let you to get started with
database administrative tasks without any manual
configuration.
The Enterprise Manager Database Console provides all
essential functionality for managing a single database,
including alert notification, job scheduling, and software
management.
Simplified Database Creation

The Database Creation Assistant (DBCA) is a GUI tool
for database creation.
It lets you create all possible configurations of the
database, be it a standalone database, a Real
Application Cluster database, or a standby database.
During the database creation process, the DBCA guides
you in setting up an automated disk-based backup and
registering the database with a LDAP server, if available.
A database created using the DBCA is fully setup and
ready to use in all respects.
Upgrades
With the Database Upgrade Assistant (DBUA), you can
upgrade any database configuration, including RAC and
standby, just by answering a few simple questions.
It automatically checks that adequate resources are
available, ensures adherence to the best practices
such as backing up the database before beginning the
upgrade process, replacing the obsolete and deprecate
initialization parameters, and so on and, verifies the
successful completion of the operation.
The upgrade process is restartable, allowing it to
automatically resume from the point of interruption.
You can also get a time estimation of how long the
upgrade process is likely to take.
Intelligent Infrastructure
Oracle Database has a sophisticated self-management
infrastructure that allows the database to learn about
itself and use this information to adapt to workload
variations or to automatically remedy any potential
problem.
The self-management infrastructure includes the
following:
Automatic Workload Repository
Automatic Maintenance Tasks
Server-Generated Alerts
Advisor Framework
Automatic Workload Repository

Automatic Workload Repository (AWR) is a built-in
repository in every Oracle Database.
At regular intervals, the Oracle Database makes a
snapshot of all its vital statistics and workload
information and stores them in AWR.
By default, the snapshots are made every 60 minutes,
but you can change this frequency.
The snapshots are stored in the AWR for a certain
period of time (seven days by default) after which they
are automatically purged.
The captured data allows both system level and user
level analysis to be performed, again reducing the
requirement to repeat the workload in order to diagnose
problems.
Automatic Maintenance Tasks

By analyzing the information stored in AWR, the
database can identify the need to perform routine
maintenance tasks, such as optimizer statistics refresh.
The automated maintenance tasks infrastructure enables
the Oracle Database to automatically perform such
operations.
It uses the Scheduler to run such tasks in a pre-defined
"maintenance window".
Server-Generated Alerts
For problems that cannot be resolved automatically and require
administrators to be notified, such as running out of space, the
Oracle Database provides server-generated alerts.
The Oracle Database can monitor itself and send out alerts to notify
you of any problem in an efficient and timely manner.
Monitoring activities take place as the database performs its regular
operation.
This ensures that the database is aware of problems the moment
they arise.
The alerts produced by the Oracle Database not only notify the
problem, they also provide recommendations on how the reported
problem can be resolved.
This ensures quick problem resolution and helps prevent potential
failures.
Oracle Database
Advisor Framework
The Oracle Database includes a number of advisors for different
sub-systems in the database to automatically determine how the
operation of the corresponding subcomponents could be further
optimized.
The SQL Tuning Advisor and the SQL Access Advisor provide
recommendations for running SQL statements faster.
Memory advisors help size the various memory components
without resorting to trial-and-error techniques.
The Segment Advisor handles space-related issues, such as
recommending wasted-space reclamation and analyzing
growth trends, while the
Undo Advisor guides you in sizing the undo tablespace
correctly.
Oracle Database
Performance Diagnostic and Troubleshooting

Automatic Database Diagnostic Monitor (ADDM) lets the
Oracle Database diagnose its own performance and
determine how identified problems could be resolved.
ADDM runs automatically after each AWR statistics
capture, making the performance diagnostic data readily
available.
ADDM examines data captured in AWR and performs
analysis to determine the major issues on the system on
a proactive basis.
In many cases, it recommends solutions and quantifies
expected benefits.
Oracle Database
Performance Diagnostic and Troubleshooting

ADDM identifies those areas of the system that are
consuming the most time.
ADDM drills down to identify the root cause of problems,
rather than just the symptoms, and reports the impact
that the problem is having on the system overall.
If a recommendation is made, it reports the benefits that
can be expected in terms of time.
The use of time throughout allows the impact of several
problems or recommendations to be compared.
Oracle Database
Application and SQL Tuning

The Oracle Database completely automates the SQL
tuning process.
ADDM identifies SQL statements consuming unusually
high system resources and therefore causing
performance problems.
Top SQL statements in terms of CPU and shared
memory consumption are automatically captured in
AWR.
The identification of high load SQL statements happens
automatically in the Oracle Database and requires no
intervention.
Oracle Database
Application and SQL Tuning

After identifying the top resource-consuming SQL
statements, the Oracle Database can automatically
analyze them and recommend solutions using the
Automatic Tuning Optimizer.
Automatic SQL Tuning is exposed with an advisor, called
the SQL Tuning Advisor.
The SQL Tuning Advisor takes one or more SQL
statements as input and produces well-tuned plans along
with tuning advice.
You do not need to do anything other than invoke the
SQL Tuning Advisor.
Oracle Database
Memory Management
The System Global Area (SGA) is a shared memory
region that contains data and control information for one
Oracle instance.
Automatic Shared Memory management automates the
management of SGA used by an Oracle Database
instance.
The Oracle Database then automatically distributes the
available memory among various components as
required.
Oracle provides dynamic memory management that
allows for resizing of the Oracle shared memory
components dynamically.
Oracle Database
Memory Management
Oracle provides the following advisors to help size the memory
allocation for optimal database performance.
The Shared Pool Advisor determines the optimal shared pool
size by tracking its use by the library cache.
The Buffer Cache Advisor determines the optimal size of the
buffer cache.
The Java Pool Advisor provides information about library
cache memory used for Java and predicts how changes in the
size of the Java pool can affect the parse rate.
The Streams Pool Advisor determines the optimal size of the
Streams pool.
The Program Global Area (PGA) Advisor tunes PGA memory
allocated to individual server processes.
Oracle Database
Space Management
Automatic undo management eliminates the
complexities of managing rollback segments and lets
you exert control over how long undo is retained before
being overwritten.
Oracle strongly recommends that you use undo
tablespace to manage undo rather than rollback
segments.
With Oracle-managed files, you do not need to directly
manage the files comprising an Oracle database.
Oracle uses standard file system interfaces to
create and delete files as needed.
This automates the routine task of creation and
deletion of database files.
Oracle Database
Space Management
Oracle allows for managing free space within a table with
bitmaps, as well as traditional dictionary based space
management.
The bitmapped implementation eliminates much spacerelated tuning of tables, while providing improved
performance during peak loads.
Oracle provides automatic extension of data files, so the
files can grow automatically based on the amount of data
in the files.
Database administrators do not need to manually
track and reorganize the space usage in all the
database files.
Oracle Database
Space Management
Oracle Database introduces a non-intrusive and timely
check for space utilization monitoring.
It automatically monitors space utilization during normal
space allocation and de-allocation operations and alerts
you if the free space availability falls below the predefined thresholds.
Space monitoring functionality is set up out of box,
causes no performance impact, and is uniformly
available across all tablespace types.
Because the monitoring is performed at the same time
as space is allocated and freed up in the database, this
guarantees immediate availability of space usage
information whenever you need it.
Oracle Database
Space Management
The Oracle Database can predict the size of a given
table based on its structure and estimated number of
rows.
This is a powerful "what if" tool that allows
estimation of the size of an object before it is
created or rebuilt.
The growth trend report takes you to the next step of
capacity planning planning for growth.
The Oracle Database tracks historical space
utilization in the AWR and uses this information to
predict the future resource requirements.
Oracle Database
Space Management
The Oracle Database provides in-place reorganization of data for
optimal space utilization by shrinking it.
Shrinking of a segment makes unused space available to other
segments in the tablespace and may improve the performance
of queries and DML operations.
The segment shrink functionality both compacts the space
used in a segment and then de-allocates it from the segment.
The deallocated space is returned to the tablespace and is
available to other objects in the tablespace.
Sparsely populated tables may cause a performance problem
for full table scans. By performing shrink, data in the table is
compacted and the high water mark of the segment is pushed
down. This makes full table scans read less blocks run faster.
Oracle Database
Configurations Management
Enterprise Manager has several powerful configuration
management facilities that help detect configuration
changes and differences and enforce best practice
configuration parameter settings.
These capabilities also encompass the underlying hosts
and operating systems.
Enterprise Manager continuously monitors the
configuration of all Oracle systems for such things as
best practice parameter settings, security set-up, storage
and file space conditions, and recommended feature
usage.
Non-conforming systems are automatically flagged with
a detailed explanation of the specific-system
configuration issue.
Oracle Database
Workload Management
The Database Resource Manager provides the ability to
prioritize work within the Oracle system.
You can specify the maximum number of concurrently
active sessions for each consumer group.
When this limit is reached, the Database Resource
Manager queues all subsequent requests and runs them
only after existing active sessions complete.
Oracle Database
Workload Management
Services represent groups of applications with common
attributes, service level thresholds, and priorities.
Application functions can be divided into workloads
identified by services.
A service can span one or more instances of an Oracle
database or multiple databases in a global cluster, and a
single instance can support multiple services.
Oracle Database
Automatic Storage Management

Automatic Storage Management is a vertical integration of both the
file system and the volume manager built specifically for Oracle
database files.
It extends the concept of stripe and mirror everything (SAME) to
optimize performance, while removing the need for manual I/O
tuning (distributing the datafile layout to avoid hotspots).
Automatic Storage Management helps manage a dynamic database
environment by letting you grow the database size without shutting
down the database to adjust the storage allocation.
Automatic Storage Management also enables low cost modular
storage to deliver higher performance and greater availability by
supporting mirroring as well as striping.
Oracle Database
Job Scheduler
Oracle Database includes a full-featured job scheduler.
You can schedule one-time jobs or repeating jobs at a
designated day, date, and time, or upon the occurrence
of a designated event.
The Scheduler provides comprehensive job logging in
Enterprise Manager and in a variety of views available
from SQL*Plus.
The Scheduler is integrated with the Database Resource
Manager.
Oracle Database
LABORATORY
Generate an AWR report.
Change the snapshot intervals of the AWR to 30 minutes.
Change the retention of AWRs to 2 weeks.
(use the dbms_workload_repository package for this purpose).
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Introduction to Backup
A backup is a copy of data.
A backup is a safeguard against unexpected data loss
and application errors.
Backups are divided into physical backups and logical
backups.
Physical backups are copies of physical database
files.
Logical backups contain logical data (for example,
tables and stored procedures) extracted with an
Oracle utility and stored in a binary file. You can use
logical backups to supplement physical backups.
Introduction to Backup
There are two ways to perform Oracle backup and
recovery:
Recovery Manager (RMAN) is an Oracle utility that
can back up, restore, and recover database files. It
is a feature of the Oracle database server and does
not require separate installation.
You can also use operating system commands for
backups and SQL*Plus for recovery.
This method, also called user-managed backup and
recovery, is fully supported by Oracle, although use
of RMAN is highly recommended because it is more
robust and greatly simplifies administration.
Introduction to Recovery
To restore a physical backup of a datafile or control file is
to reconstruct it and make it available to the Oracle
database server.
To recover a restored datafile is to update it by applying
archived redo logs and online redo logs, that is, records
of changes made to the database after the backup was
taken.
After the necessary files are restored, media recovery
must be initiated by the user.
Media recovery involves various operations to
restore, roll forward, and roll back a backup of
database files.
Media Recovery
Basic Recovery Steps:

Rolling Forward and Rolling Back
Flash Recovery Area

The flash recovery area is an Oracle-managed directory, file system,
or Automatic Storage Management disk group that provides a
centralized disk location for backup and recovery files.
Oracle creates archived logs in the flash recovery area.
RMAN can store its backups in the flash recovery area, and it uses it
when restoring files during media recovery.
The flash recovery area also acts as a disk cache for tape.
Oracle recovery components interact with the flash recovery area
ensuring that the database is completely recoverable using files in
flash recovery area.
All files necessary to recover the database following a media failure
are part of flash recovery area.
LABORATORY
Check the RMAN settings (show all) and change them to meet your
backup purposes.
Use RMAN to create a database backup.
Verify the RMAN backup.
Topics

Manageability
Backup and Recovery
Data Compression
High Availability
Content Management
Database Security
Data Integrity
Triggers
Compression by release(< 12c)

Index compression
Table compression
Basic
OLTP*
RMAN backup compression*
SecureFile (LOB) compression*
Data Pump export compression*
Data Guard redo transport
compression*
Hybrid Columnar compression*
Oracle8i
Oracle9i
Oracle10g
Oracle11gR1
Oracle11gR2
* Advanced Compression Option
* Exadata / ZFS / Pillar storage only
Oracle Segment Compression

Table / Partition Compression
CREATE TABLE SCHEMA.TABLE_NAME ()
COMPRESS [ FOR DIRECT_LOAD OPERATIONS | BASIC ]
COMPRESS FOR ALL OPERATIONS | COMPRESS FOR OLTP *
COMPRESS FOR QUERY [ LOW | HIGH ] *
COMPRESS FOR ARCHIVE [ LOW | HIGH ] *
Oracle9i+
Oracle11gR1
Oracle11gR2
* Advanced Compression Option

* Exadata / ZFS / Pillar storage only
Table Compression
BASIC vs OLTP
Mode BASIC
Only for operations type DIRECT PATH Insert
(SQL*Loader direct, CTAS, Parallel INSERT, INSERT +
hint APPEND ...)
Mode OLTP
Available for DML (Compression triggered when the block
is full)
Compression still done for Migrated rows(and not for
Chained)
Compression Unit: Database Block
Table Compression
Algorythm
Concept similar to standard compression algorythms(LZ)
Distinct values are stored in a dictionary (named
as well symbols table)
The column data values are replaced by a pointer to
the dictionary value.
Compression is done at block level.
The block values are autonomous (no outside
reference).
The concept relies on deduplication (referencing a local
block value).
Table Compression
Performance Impact
While the compression takes plance
Only the transaction that triggers the compression is
affected (CPU + Redo)
Compression is made in batch mode, which minimizes
the overall impact.
After the compression:
Better SELECT performances because:
Less IO.
There is no need to decompress the data at read time. The
data is stored in more compact mode in the buffer cache.
Each nodes data is autonomous.

Index Compression
Index compression uses de-duplication technique
You decide which columns should be de-duplicated.
The de-duplication mechanism is only applied to a
specified leading subset of columns for every single index
entry
The de-duplication is maintained in real time all the time.
Index is compressed at the database block level
Compression index
Example
Hypothesys :
Index on 3 columns (col1, col2, col3)
The key has 3 values(col1, col2, col3)
Prefix = (col1, col2) : repeating values
Suffix = (col3) : discriminating values
Inside of a leaf block
Sample values: (1,2,3), (1,2,4), (1,2,7), (1,3,5), (1,3,4),
(1,4,4)
The values (1,2), (1,3) can be compressed (only 1
occurrence is saved in the block)
Index Compression
Syntax
ALTER INDEX <index_name> REBUILD COMPRESS
<n>;
ALTER INDEX <index_name> REBUILD NOCOMPRESS;
Value <n>
Number of columns to compress
Default for unique index = # columns 1
Default for non unique Index = # columns in index
ANALYZE INDEX ... VALIDATE STRUCTURE can be used to
determine the columns to compress.

Other type of compression
Secure files (LOB) compression - ACO
LONG & LOB need to be converted to SecureFile
Benefits of OLTP Table Compression

Reduce storage space for table data
Improve Overall performance
Initial Growth Rate
Initial Compression Rate
Growth Rate after Compression
Compress
Reduce Storage Space Consumption by a factor of 2x to 4x
Estimate the Compression Ratio

Procesure dbms_compression.get_compression_ratio
The procedure is overloaded for all compressible objects
declare
v_blkcnt_cmp pls_integer;
v_blkcnt_uncmp pls_integer;
v_row_cmp pls_integer;
v_row_uncmp pls_integer;
v_cmp_ratio number;
v_comptype_str varchar2(60);
begin
dbms_compression.get_compression_ratio(
scratchtbsname => upper('TC'), -- *
ownname => 'SCOTT',
tabname => upper('OBJ'),
partname => NULL,
comptype => dbms_compression.COMP_FOR_OLTP,
blkcnt_cmp => v_blkcnt_cmp,
blkcnt_uncmp => v_blkcnt_uncmp,
row_cmp => v_row_cmp,
row_uncmp => v_row_uncmp,
cmp_ratio => v_cmp_ratio,
comptype_str => v_comptype_str);
dbms_output.put_line(
'Estimated Compression Ratio:
'||to_char(v_cmp_ratio));
'Blocks used by compressed sample:
'||to_char(v_blkcnt_cmp));
'Blocks used by uncompressed sample:
'||to_char(v_blkcnt_uncmp));
end;
/
Estimated Compression Ratio: 3
Blocks used by compressed sample: 670
(IDL ou CTAS)
Blocks used by uncompressed sample: 2060
Compression Dictionary views:

DBA_TABLES / DBA_TAB_PARTITIONS
ColumnCOMPRESSION
Column COMPRESS_FOR
SELECT TABLE_NAME, COMPRESSION, COMPRESS_FOR FROM
USER_TABLES;
TABLE_NAME
----------T1
T2
T3
COMPRESS
-------DISABLED
ENABLED
ENABLED
COMPRESS_FOR
-----------BASIC
OLTP
LABORATORY
Verify a table for compression potential.

Check the current size of a table.
Compress the table.
Verify again the size of the table and compare with the results that
have been obtained in #1.
Topics

Manageability
Backup and Recovery
Data Compression
High Availability
Content Management
Database Security
Data Integrity
Triggers
Oracle Database
Introduction to Data Warehousing

and Business Intelligence
A data warehouse is a relational database that is designed for query
and analysis rather than for transaction processing.
It usually contains historical data derived from transaction data, but it
can include data from other sources.
It separates analysis workload from transaction workload and
enables an organization to consolidate data from several sources.
In addition to a relational database, a data warehouse environment
includes
an extraction, transportation, transformation, and loading (ETL)
solution
an online analytical processing (OLAP) engine
client analysis tools
other applications that manage the process of gathering data
and delivering it to business users.
Oracle Database
Architecture of a Data Warehouse
Oracle Database

(with Staging Area)
Oracle Database

(with Staging Area and Data Marts)
Oracle Database
Overview of Extraction, Transformation, and

Loading (ETL)
The process of extracting data from source systems and
bringing it into the data warehouse is commonly called ETL,
which stands for extraction, transformation, and loading.
What happens during the ETL process?
During extraction, the desired data is identified and
extracted from many different sources, including
database systems and applications.
After extracting data, it has to be physically transported
to the target system or an intermediate system for further
processing. Depending on the chosen way of
transportation, some transformations can be done during
this process, too.
Then the data is loaded.
Oracle Database
Transportable Tablespaces
Transportable tablespaces are the fastest way for
moving large volumes of data between two Oracle
databases.
You can transport tablespaces between different
computer architectures and operating systems.
The most common applications of transportable
tablespaces in data warehouses are in moving data from
a staging database to a data warehouse, or in moving
data from a data warehouse to a data mart.
Oracle Database
External Tables
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 further processing inside the database,
such as comparison or transformation.
Oracle Database
Table Compression
To reduce disk use and memory use (specifically, the
buffer cache), you can store tables and partitioned tables
in a compressed format inside the database.
This often leads to a better scale-up for read-only
operations.
Table compression can also speed up query execution.
There is, however, a slight cost in CPU overhead.
Table compression should be used with highly redundant
data, such as tables with many foreign keys. You should
avoid compressing tables with much update or other
DML activity.
Oracle Database
Overview of Materialized Views for Data

Warehouses
Summaries are special kinds of aggregate views that improve query
execution times by pre-calculating expensive joins and aggregation
operations prior to execution and storing the results in a table in the
database.
The summaries or aggregates on data warehouses are created in
Oracle using a schema object called a materialized view.
Materialized views can perform a number of roles, such as
improving query performance or providing replicated data.
The end user queries the tables and views at the detail data level.
The query rewrite mechanism in the Oracle database server
automatically rewrites the SQL query to use the summary tables.
Oracle Database
Overview of Bitmap Indexes in Data

Warehousing
Bitmap indexes are widely used in data warehousing
environments.
For Data Warehouses, bitmap indexing provides:
Reduced response time for large classes of ad hoc
queries
Reduced storage requirements compared to other
indexing techniques
Dramatic performance gains even on hardware with
a relatively small number of CPUs or a small
amount of memory
Efficient maintenance during parallel DML and loads
Oracle Database
Overview of Parallel Execution

When Oracle runs SQL statements in parallel, multiple
processes work together simultaneously to run a single
SQL statement.
By dividing the work necessary to run a statement
among multiple processes, Oracle can run the statement
more quickly than if only a single process ran it.
This is called parallel execution or parallel processing.
Parallel execution dramatically reduces response time
for data-intensive operations on large databases typically
associated with decision support systems (DSS) and
data warehouses.
Oracle Database
Serial Full Table Scans
Oracle Database
Parallel Full Table Scans
Oracle Database
Overview of Analytic SQL

Oracle has introduced many SQL operations for
performing analytic operations in the database.
These operations include:
ranking
moving averages
cumulative sums
ratio-to-reports
period-over-period comparisons.
Oracle Database
SQL for Aggregation

Aggregation is a fundamental part of data warehousing.
To improve aggregation performance in your warehouse,
Oracle provides extensions to the GROUP BY clause to
make querying and reporting easier and faster.
Some of these extensions enable you to:
Aggregate at increasing levels of aggregation, from
the most detailed up to a grand total
Calculate all possible combinations of aggregations
with a single statement
Generate the information needed in cross-tabulation
reports with a single query
Oracle Database
SQL for Analysis

Oracle has advanced SQL analytical processing capabilities using a
family of analytic SQL functions.
These analytic functions enable you to calculate:
Rankings and percentiles
Moving window calculations
Lag/lead analysis
First/last analysis
Linear regression statistics
To enhance performance, analytic functions can be parallelized:
multiple processes can simultaneously run all of these
statements.
These capabilities make calculations easier and more efficient,
thereby enhancing database performance, scalability, and simplicity.
Oracle Database
SQL for Modeling

Oracles MODEL clause brings a new level of power and
flexibility to SQL calculations.
With the MODEL clause, you can create a
multidimensional array from query results and then apply
formulas to this array to calculate new values.
The formulas can range from basic arithmetic to
simultaneous equations using recursion.
For some applications, the MODEL clause can replace
PC-based spreadsheets.
Models in SQL leverage Oracles strengths in scalability,
manageability, collaboration, and security.
Oracle Database
Overview of OLAP Capabilities

Oracle OLAP provides the query performance and
calculation capability previously found only in
multidimensional databases to Oracles relational
platform.
Unlike other combinations of OLAP and RDBMS
technology, Oracle OLAP is not a multidimensional
database using bridges to move data from the relational
data store to a multidimensional data store.
Instead, it is truly an OLAP-enabled relational database.
As a result, Oracle provides the benefits of a
multidimensional database along with the scalability,
accessibility, security, manageability, and high
availability of the Oracle database.
Oracle Database
Overview of Data Mining

Oracle Data Mining (ODM) embeds data mining within
the Oracle Database.
The data never leaves the database the data, data
preparation, model building, and model scoring results
all remain in the database.
By eliminating the need for extracting data into
specialized tools and then importing the results back into
the database, you can save significant amounts of time.
By having the data and the data model in the same
location (an Oracle database), there is no need to export
the model as code.
Oracle Database
Overview of Data Mining

Oracle Data Mining supports the following algorithms:
For classification, Naive Bayes, Adaptive Bayes
Networks, and Support Vector Machines (SVM)
For regression, Support Vector Machines
For clustering, k-means and O-Cluster
For feature extraction, Non-Negative Matrix
Factorization (NMF)
For sequence matching and annotation, BLAST
Oracle Database
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Oracle Database
Oracle Solutions to System Failures

Fast-Start Fault Recovery
Reduces the time required for cache recovery and makes the
recovery bounded and predictable.
Limits the number of dirty buffers and the number of redo
records generated between the most recent redo record and
the last checkpoint.
With fast-start fault recovery, the Oracle database is opened
for access by applications without having to wait for the undo,
or rollback, phase to be completed.
Real Application Clusters
Real Application Clusters (RAC) databases are inherently high
availability systems.
The clusters that are typical of RAC environments can provide
continuous service for both planned and unplanned outages.
Oracle Database
Oracle Solutions for Data Failures

Backup and Recovery Features for HA
Recovery Manager (RMAN) is Oracles utility to manage the
backup and recovery of the database. It determines the most
efficient method of running the requested backup, restore, or
recovery operation.
Flashback Database lets you quickly recover an Oracle
database to a previous time to correct problems caused by
logical data corruptions or user errors.
Flashback Query lets you view data at a point-in-time in the
past.
Backup information can be stored in an independent flash
recovery area. This increases the resilience of the information,
and allows easy querying of backup information.
Oracle Database

Backup and Recovery Features for HA
When performing a point in time recovery, you can
query the database without terminating recovery.
With Oracles block-level media recovery, if only a
single block is damaged, then only that block needs
to be recovered. The rest of the file, and thus the
table containing the block, remains online and
accessible.
LogMiner lets a DBA find and correct unwanted
changes. LogMiner provides SQL statements
needed to undo the erroneous operation
Oracle Database

Partitioning
Partitioning addresses key issues in supporting very
large tables and indexes by letting you decompose
them into smaller and more manageable pieces
called partitions.
DDL statements can access and manipulate
individuals partitions rather than entire tables or
indexes.
Partitioning is entirely transparent to applications.
Oracle Database

Transparent Application Failover
Transparent Application Failover enables an
application user to automatically reconnect to a
database if the connection fails.
Active transactions roll back, but the new database
connection, made by way of a different node, is
identical to the original.
With Transparent Application Failover, a client
notices no loss of connection as long as there is one
instance left serving the application.
This works best with Real Application Clusters
(RAC): If one node dies, then you can quickly
reconnect to another node in the cluster.
Oracle Database
Oracle Solutions for Disasters

Data Guard
Oracle Data Guard maintains up to nine standby databases,
each of which is a real-time copy of the production database,
to protect against all threats - corruptions, data failures, human
errors, and disasters.
If a failure occurs on the production (primary) database, then
you can fail over to one of the standby databases to become
the new primary database.
In addition, planned downtime for maintenance can be
reduced, because you can quickly and easily move (switch
over) production processing from the current primary database
to a standby database, and then back again.
Oracle Database

Data Guard (Physical Standby Database)
A physical standby database is physically identical
to the primary database.
While the primary database is open and active, a
physical standby database is either performing
recovery (by applying logs), or open for reporting
access.
A physical standby database can be queried read
only when not performing recovery while the
production database continues to ship redo data to
the physical standby site.
Oracle Database

Data Guard (Logical Standby Database)
A logical standby database takes standard Oracle
archived redo logs, transforms the redo records they
contain into SQL transactions, and then applies
them to an open standby database.
The database tables can have different indexes and
physical characteristics from their primary database
peers, but must maintain logical consistency from
an application access perspective, to fulfill their role
as a standby data source.
Oracle Database
Oracle Solutions for Human Errors

Oracle Flashback Features
Flashback Database lets you quickly bring your
database to a prior point in time by undoing all the
changes that have taken place since that time. This
operation is fast, because you do not need to
restore the backups. This in turn results in much
less downtime following data corruption or human
error.
Flashback Table lets you quickly recover a table to
a point in time in the past without restoring a
backup.
Flashback Drop provides a way to restore
accidentally dropped tables.
Oracle Database
Oracle Solutions for Human Errors

Oracle Flashback Features
Flashback Query lets you view data at a point-in-time in the
past. This can be used to view and reconstruct lost data that
was deleted or changed by accident. Developers can use this
feature to build self-service error correction into their
applications, empowering end-users to undo and correct their
errors.
Flashback Version Query uses undo data stored in the
database to view the changes to one or more rows along with
all the metadata of the changes.
Flashback Transaction Query lets you examine changes to the
database at the transaction level. As a result, you can
diagnose problems, perform analysis, and audit transactions.
Oracle Database
System Maintenance
Oracle provides a high degree of self-management - automating
routine DBA tasks and reducing complexity of space, memory, and
resource administration. These include the following:
Automatic undo managementdatabase administrators do not
need to plan or tune the number and sizes of rollback
segments or consider how to strategically assign transactions
to a particular rollback segment.
Dynamic memory management to resize the Oracle shared
memory components dynamically. Oracle also provides
advisories to help administrators size the memory allocation
for optimal database performance.
Oracle-managed files to automatically create and delete files
as needed
Free space management within a table with bitmaps.
Data Guard for hardware and operating system maintenance
Oracle Database
Data Maintenance
Database administrators can perform a variety of online operations
to table definitions, including online reorganization of heaporganized tables.
This online architecture provides the following capabilities:
Any physical attribute of the table can be changed online.
Many logical attributes can also be changed.
Online creation and rebuilding of secondary indexes on indexorganized tables (IOTs).
Indexes can be created online and analyzed at the same time.
Fix the physical guess component of logical rowids stored in
secondary indexes on IOTs. This allows online repair of invalid
physical guesses
Oracle Database
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Oracle Database
Introduction to Partitioning
Partitioning addresses key issues in supporting very
large tables and indexes by letting you decompose them
into smaller and more manageable pieces called
partitions.
Each partition of a table or index must have the same
logical attributes, such as column names, datatypes, and
constraints, but each partition can have separate
physical attributes such as pctfree, pctused, and
tablespaces.
OLTP systems often benefit from improvements in
manageability and availability, while data warehousing
systems benefit from performance and manageability.
Oracle Database
Partitioned Tables
Oracle Database
Partitioning Methods
Oracle Database
Partitioning Methods
Oracle Database
Local Partitioned Indexes
Oracle Database
Global Partitioned Indexes
Oracle Database
Global Non-partitioned Indexes
Oracle Database
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Oracle Database
Introduction to Content Management

Oracle Database includes datatypes to handle all the types of rich
Internet content such as:
relational data
object-relational data
XML
Text
Audio
Video
Image
spatial
These datatypes appear as native types in the database.
They can all be queried using SQL. A single SQL statement can
include data belonging to any or all of these datatypes.
Oracle Database
Overview of XML in Oracle

Oracle XML DB treats XML as a native datatype in the
database.
Oracle XML DB is not a separate server.
The XML data model encompasses both unstructured
content and structured data.
Applications can use standard SQL and XML operators
to generate complex XML documents from SQL queries
and to store XML documents.
Oracle XML DB provides a native XMLType, support for
XML Schema, XPath, XSLT, DOM, and so on. The dataoriented access is typically more query-intensive.
Oracle Database
Overview of LOBs
The large object (LOB) datatypes BLOB, CLOB, NCLOB,
and BFILE enable you to store and manipulate large
blocks of unstructured data (such as text, graphic
images, video clips, and sound waveforms) in binary or
character format.
They provide efficient, random, piece-wise access to the
data.
With the growth of the internet and content-rich
applications, it has become imperative that databases
support a datatype that fulfills the following:
Can store unstructured data
Is optimized for large amounts of such data
Provides a uniform way of accessing large
unstructured data within the database or outside
Oracle Database
Overview of Oracle Text

Oracle Text indexes any document or textual content to
add fast, accurate retrieval of information to:
internet content management applications
e-Business catalogs
news services
job postings
Oracle Text allows text searches to be combined with
regular database searches in a single SQL statement.
It can find documents based on their textual content,
metadata, or attributes.
It can index content stored in file systems, databases, or
on the Web.
Oracle Database
Overview of Oracle Ultra Search

Oracle Ultra Search is built on the Oracle database server and
Oracle Text technology that provides uniform search-and-locate
capabilities over multiple repositories:
Oracle databases
other ODBC compliant databases
IMAP mail servers
HTML documents served up by a Web server
files on disk
and more
Ultra Search uses a crawler to index documents; the documents
stay in their own repositories, and the crawled information is used to
build an index that stays within your firewall in a designated Oracle
database.
Oracle Database
Overview of Oracle InterMedia

Oracle interMedia is a feature that enables Oracle Database to
store, manage, and retrieve images, audio, and video data in an
integrated fashion with other enterprise information.
interMedia manages media content by providing the following:
Storage and retrieval of media data in the database to
synchronize the media data with the associated business data
Support for popular image, audio, and video formats
Extraction of format and application metadata into XML
documents
Full object and relational interfaces to interMedia services
Access through traditional and Web interfaces Querying using
associated relational data, extracted metadata, and media
content with optional specialized indexing
Image processing, such as thumbnail generation
Delivery through RealNetworks and Windows Media
Streaming Servers
Oracle Database
Overview of Oracle Spatial

Oracle Spatial is designed to make spatial data management easier
and more natural to users of location-enabled applications and
geographic information system (GIS) applications.
When spatial data is stored in an Oracle database, it can be easily
manipulated, retrieved, and related to all other data stored in the
database.
Spatial consists of the following:
A schema (MDSYS) that prescribes the storage, syntax, and
semantics of supported geometric data types
A spatial indexing mechanism
Operators, functions, and procedures for performing area-ofinterest queries, spatial join queries, and other spatial analysis
operations
Functions and procedures for utility and tuning operations
Topology data model for working with data about nodes,
edges, and faces in a topology.
Oracle Database
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Oracle Database
Database Security
Installation options
User Authentication
User Authorization
Encryption
Access Control
Auditing
Oracle Database
Installation and Configuration

As much as possible, install the latest software release.
Oracle software vulnerabilities and fixes
Always be uptodate with the latest PSU. Latest PSU
you can find in document: Oracle Recommended
Patches -- Oracle Database (Doc ID 756671.1)
Oracle Database

Installation options:
11.1 and before: Install just the options required
by the database.
11.2 use chopt to enable/disable options
12c use chopt to enable/disable options (reduced
number of options compared to 11.2)
Run orachk
Once the installation and database configuration
is complete, run orachk to verify possible issues
with the installation. ORAchk - Health Checks for
the Oracle Stack (Doc ID 1268927.2)
Oracle Database
OS groups (Separation of Duties at OS level):

Standard: oinstall, dba, oper
Grid: asmadmin, asmdba,asmoper
12c new: backupdba,dgdba,kmdba
Have separate administrators for the SYS* privileges:

SYSDBA This privilege provides full control over all database objects
in the database.
SYSOPER This privilege provides delegated administration of
database startup, shutdown, initialization file management, database
open, database mount, and database backup and recovery.
SYSBACKUP (12c new)This privilege provides delegated
administration of database backup and recovery capabilities using
Oracle Recovery Manager (RMAN) and/or SQL*Plus.
SYSDG (12c new) This privilege provides delegated administration of
database offsite fail-over with the Oracle Data Guard (DG) using the
DG Broker or DG Manager command line interface (dgmgrl).
Oracle Database
SYSKM (12c new) This privilege provides key management (KM) and
delegated administration of Oracle Wallets (encryption keystores) used by
Oracle Transparent Data Encryption (TDE).
SYSASM (11g new) This privilege provides for separation of duty in the
administration of the Oracle Grid Infrastructure (GI) installation and
Automated Storage Management (ASM) instance. With this privilege one
can separate the administration of GI and ASM (storage) from accounts that
have the SYSDBA privilege. This privilege is not associated to an account in
the standard Oracle database instance and is only applicable in an Oracle
ASM instance. Oracle ASM is a special database used for managing disk
storage that is shared across multiple, standard Oracle databases.
Oracle Database

Database Configuration:
Run DBCA in Custom mode to choose suitable DB
options
Database template are time saving, easy editing,
easy sharing. By creating a template containing
your database settings, you can easily create a
duplicate database without specifying the same
options at each installation. Administrators mistakes
are minimized if using templates.
Do not install sample schemas
Oracle Database

Database Configuration:
Run DBCA in Custom mode to choose suitable DB
options
Database template are time saving, easy editing,
easy sharing. By creating a template containing
your database settings, you can easily create a
duplicate database without specifying the same
options at each installation. Administrators mistakes
are minimized if using templates.
Do not install sample schemas
Oracle Database
User Authentication
Verify the default/system schema accounts. All should
be EXPIRED AND LOCKED except SYS, SYSTEM; if
OEM is used, DBSNMP and SYSMAN should also be
available.
Change default passwords, especially for power users
(SYSDBA/DBA)
Verify users with default username and passwords in
DBA_USERS_WITH_DEFPWD
Oracle Database
User Authentication
Enforce password rules using profiles:
Password expiration/renewal policy using
PASSWORD_REUSE_TIME
PASSWORD_LOCK_TIME
PASSWORD_REUSE_MAX
PASSWORD_GRACE_TIME
PASSWORD_LIFE_TIME
Improper password usage should be restricted using:
FAILED_LOGIN_ATTEMPTS
Password complexity with PASSWORD_VERIFY_FUNCTION
Templates for password verification functions provided by Oracle
12c - verify_function_11g, ora12c_verify_function,
ora12c_strong_verify_function
Template located in
$ORACLE_HOME/rdbms/admin/utlpwdmg.sql
Oracle Database
User Authentication
Enforce password rules using profiles:
Password expiration/renewal policy using
PASSWORD_REUSE_TIME
PASSWORD_LOCK_TIME
PASSWORD_REUSE_MAX
PASSWORD_GRACE_TIME
PASSWORD_LIFE_TIME
Improper password usage should be restricted using:
FAILED_LOGIN_ATTEMPTS
Password complexity with PASSWORD_VERIFY_FUNCTION
Templates for password verification functions provided by Oracle
12c - verify_function_11g, ora12c_verify_function,
ora12c_strong_verify_function
Template located in
$ORACLE_HOME/rdbms/admin/utlpwdmg.sql
Oracle Database
User Authentication
The Secure Password Store.

Storing database password credentials in a client-side Oracle wallet eliminates
the need to embed usernames and passwords in application code, batch jobs,
or scripts. This reduces the risk of exposing passwords in the clear in scripts
and application code, and simplifies maintenance because you need not change
your code each time usernames and passwords change. In addition, not having
to change application code also makes it easier to enforce password
management policies for these user accounts.
Main features:
Username and passwords are no longer exposed at OS level.
User credentials are stored securely in Oracle wallets.
Very useful for scripts/tasks/jobs that run at OS level.

Best practices:
Being an Oracle client feature, the Secure Password Store should never
be configured using a database sqlnet.ora file, given such a configuration
can lead to authentication errors for critical background processes.
Oracle Database
User Authentication
Strong Authentication
Kerberos is a trusted third-party authentication system that relies on
shared secrets. It presumes that the third party is secure, and
provides single sign-on capabilities, centralized password storage,
database link authentication, and enhanced PC security. It does this
through a Kerberos authentication server.
RADIUS is a client/server security protocol widely used to enable
remote authentication and access. Oracle Database uses this
industry standard in a client/server network environment.
The SSL has a dual nature, being used for both authentication and
encryption . The authentication part is always accompanied by
encryption, while the encryption can be used without authentication.
For this reason, the SSL authentication incurs a certain performance
overhead.
Oracle Database
User Authentication
Enterprise User Security
Enable administrators to address administrative and security
challenges for a large number of enterprise database users.
Enterprise users are those users that are defined in a directory.
Their identity remains constant throughout the enterprise. Enterprise
User Security relies on Oracle Identity Management infrastructure,
which in turn uses an LDAP-compliant directory service to centrally
store and manage users.
Oracle Database
User Authorization
Separation of duty:
privileges
SYSDBA/SYSOPER/SYSASM(+11g)/SYSKM(+12c)/SYSBACKUP(+
12c)/SYSDG(+12c) should be granted to different persons.
Only certain predefined administrative users or users who have been
added to the password file may connect with these privileges
If using Database Vault, the DBA should be a different person than
the DV Admin. The DV account manager should be yet another
person.
If using TDE in 12c, the Key Manager (SYSKM) should not be the
same person as the DBA.
It would be recommended to have at least two database
administrators/database DBAs responsibilities must be shared
Each administrator should use a separate account. The accounts
should never be shared, especially the DBA accounts.
Oracle Database
User Authorization
Practice the principle of least privileged:
Grant only necessary privileges only. Main focus is
on:
SYSTEM and OBJECT privileges granted
directly to users.
Who is allowed to use the SYS* accounts
Who has *ANY* privileges
Who has *CATALOG* privileges
Do not grant *ALL* object privileges
Who is allowed to CREATE/MODIFY/DROP
database objects
Review other powerful privileges
Oracle Database
User Authorization
AUTHORIZATION TO DO DATABASE OPERATIONS SHOULD BE DONE VIA
ROLES.
As much as possible, System and Object Privileges should be granted to
roles only.
Avoid using simple roles, if possible, as these are too easy to activate. Use
password protected roles or, even better, secure application roles.
The non-privileged users should have just the CREATE SESSION privilege.
All other privilege should be available through roles only, preferable via
secure application roles.
Restrict the data dictionary access to database administrators only. Nobody
else should be granted the SELECT ANY DICTIONARY privilege.
Create privilege captures to find excessively granted privileges (12c, DV
feature). Revoke excessively granted privileges.
You grant privileges to users so they can accomplish tasks required for their
jobs. You should grant a privilege only to a user who requires that privilege
to accomplish the necessary work. Excessive granting of unnecessary
privileges can compromise security
Oracle Database
User Authorization
No custom user should have SYSTEM or SYSAUX as default tablespaces.

Parameters related to user authorization:
O7_DICTIONARY_ACCESSIBILITY (parameter restricting the
dictionary access) should always be set on FALSE.
UTL_FILE_DIR: should not be set.
UTL_FILE_DIR lets you specify one or more directories that Oracle
should use for PL/SQL file I/O. Oracle directories should be used
instead.
Oracle Database
Access Control
Oracle Virtual Private Database (VPD) allows the creation of security

policies to control the access at the row and column level. These security
policies are enforced by the database rather than an application, which
means that use of a different application will not bypass the security policy.
Oracle adds dynamically and transparently a WHERE clause( predicate ) to
a SQL statement that is executed against the object (table, view or
synonym) to which a VPD policy was applied. The predicate (WHERE
clause) is returned by a custom function which implements the security
policy. It is your responsability to write correctly this function so that it will
return the expected predicates in various scenarios.
Oracle Database
Access Control
VPD allows to create policies that can be applied in order to:

Restrict row access
Restrict column access
Obfuscate the column values using NULLs.
Application contexts can be employed to enhance the VPD functions flexibility
and improve the overall sessions performance.
The VPD policies can be:
Dynamic - runs the policy function each time a user accesses the Virtual
Private Database-protected database objects.
Context Sensitive/Shared Context Sensitive - Context-sensitive policies
are designed for situations in which different predicates must apply
depending on which user is executing the query. The shared type can be
shared between multiple objects
Static/Shared Static - nforces the same predicate for all users in the
instance. Oracle Database stores static policy predicates in SGA, so
policy functions do not rerun for each query. This results in faster
performance. The shared type can be shared between multiple objects.
The VPD policies can be applied on tables, views or synonyms.
The privilege EXEMPT ACCESS POLICY can be used to circumvent the VPD
policies
Oracle Database
Database Vault
Oracle Database Vault enables organizations to
transparently increase security without making changes
to their application code. Oracle Database Vault provides
real time preventive controls by restricting access to
application data from highly privileged users. Oracle
Database Vault helps organizations address regulatory
compliance, industrial espionage and insider threats
while at the same time enabling the flexibility to deploy IT
systems in a cost effective manner through consolidation
and or off shoring.
Oracle Database
Database Vault
Main features:
Restricts access to application data from highly
privileged users.
Can be integrated with the application code or it can
be implemented as a transparent security layer.
It can be used to implement the separation of duty
requirements.
Patching is done without disabling the DV setup.
Very low impact on database performance.
It can be easy integrated with many Oracle
[Security] Features: EUS, TDE, OLS, Data Guard
Oracle Database
Database Vault
Allows the creation of the following objects that help implement the security policies:
Realms: are used to protect database objects. It is a zone of protection for

specific database objects.
Rule Sets: use rule sets to group a set of rules together.
Rules: The rules are criteria that are used to determine whether a user can
perform specific actions (DDL/connect/access objects and so on).
Command Rules: You can create command rules to protect DDL and DML
statements. Oracle Database Vault provides a set of default command rules.
Factors: A factor is a named variable or attribute, such as a user location,

database IP address, or session user, that Oracle Database Vault can
recognize.
Secure Application Roles: In Oracle Database Vault, one can create a secure
application role that can be enabled with an Oracle Database Vault rule set.
Regular Oracle Database secure application roles are enabled by custom
PL/SQL procedures. You use secure application roles to prevent users from
accessing data from outside an application. This forces users to work within
the framework of the application privileges that have been granted to the role.
Oracle Database
Database Vault
Best practices:
Create specific realms for each group of objects that requires
protection from power users.
Disallow access to DDL using rule sets and command rules.
Do not allow the users to logon to the database from outside
the application, using custom tools such as sqlplus or TOAD.
Disallow database access outside business hours using rule
sets and command rules.
Integrate the secure application roles into the application
security, so that even users logging using the application do
not have more privileges than granted through these roles.
Audit all DV management and changes.
Oracle Database
Data Redaction
Oracle Data Redaction enables you to mask (redact) data that is returned
from queries issued by applications.
Main features:
Introduced in 11.2.0.4 and higher releases.
5 types of data redaction:
Full: redact all of the contents of the column data
Partial: redact a portion of the column data.
RegExp: use regular expressions to look for patterns of data to
redact.
Random: use random generated values.
None: use for testing purposes.
The data is redacted transparently, at runtime.
No changes performed in the actual data, not even in memory.
The privilege EXEMPT REDACTION POLICY can be used to
circumvent the Data Redaction policies.
DDLs that would workaround the DR policies (CTAS) would fail with
ORA-28001.
Oracle Database
Data Encryption
Do not use Data Encryption in place of Access Control! It
might appear as a good method to restrict privileged
user access to sensitive information, but this method is
more expensive from the implementation and
performance perspective and weaker when it comes to
the actual security.
Oracle Database
Transparent Data Encryption

To protect the data from being stolen and meet
regulatory standards, the solution is Transparent Data
Encryption. Oracle Database uses authentication,
authorization, and auditing mechanisms to secure data
in the database, but not in the operating system data
files where data is stored. To protect these data files,
Oracle Database provides Transparent Data Encryption
(TDE). TDE encrypts sensitive data stored in data files.
To prevent unauthorized decryption, TDE stores the
encryption keys in a security module external to the
database, called a keystore. The keystore can be a local
file (wallet) or can be a remote application, also known
as Hardware Security Module, provided by a third party
or by Oracle through Oracle Key Vault.
Oracle Database

Main features:
It is transparent to the end user: the data is not
encrypted when queried by a user who has the
proper privileges to access the data.
Data is decrypted only in memory. Any disk related
operation that requires disk access (sorts requiring
temporary tablespace, undo segments, redo logs or
archive logs) also implies encrypting this data.
It can be enabled at column or tablespace level.
TDE is seamlessly integrated with the Database
Kernel and it offers the best performance possible.
Requires ASO license.
Oracle Database

Main features:
It is transparent to the end user: the data is not
encrypted when queried by a user who has the
proper privileges to access the data.
Data is decrypted only in memory. Any disk related
operation that requires disk access (sorts requiring
temporary tablespace, undo segments, redo logs or
archive logs) also implies encrypting this data.
It can be enabled at column or tablespace level.
TDE is seamlessly integrated with the Database
Kernel and it offers the best performance possible.
Requires ASO license.
Oracle Database
Best practices:
Encrypt just the data that requires protection. This is important from at least
two perspectives: it simplifies the administration and reduces the performance
impact of TDE.
If using local wallets, make sure the wallet password is known only by the TDE
administrator or that the auto login wallet is created with auto_login_local.
Determining the precise location of the wallet can be a challenge in a complex

environment. Make sure to understand the available options before setting up
customized wallet directories (See Note: 1240824.1)
Oracle recommends using the Oracle Key Vault to manage the master
encryption keys of the TDE.
Use the Hardware Acceleration for Tablespace Encryption.
Implement the Separation of Duties. The TDE administrator should not be the
same person as the Database Administrator. Please note that in 12c have
been introduced new privileges for TDE Administration: ADMINISTER KEY
MANAGEMENT or SYSKM.
Combine TDE with Database Vault to maximize the data protection, restricting
both SQL data access and OS data access in the dame time.
Oracle Database

Performance impact:
TDE has a significant performance impact on the Oracle
Database, especially for tablespace encryption (see Note
1303412.1).
To alleviate this performance impact, it is recommended to use
the Hardware Acceleration for Tablespace Encryption (See
Note 1365021.1).
Column encryption restricts specific operations.
Column encryption does not work well with third party HSM,
because each table access requires a HSM roundtrip in order
to decrypt the table encryption key. This restriction does not
apply to tablespace encryption. As well, this restriction does
not apply to OKV, because after the first OKV access, the OKV
is stored in obfuscated format in the instance SGA.
Thorough testing is needed before implementing TDE in
production.
Oracle Database
Network configuration/encryption
Listener configuration:
The listener should be started from the Grid Home and not the RDBMS Home
(separation of duties).
Do not use a listener password. Remote listener administration is disabled when the
password is not set. Listener protected password is obsolete.
Prevent online administration of the listener:
ADMIN_RESTRICTIONS_LISTENER=ON
Make sure the first protocol in the list of protocols on which the listener is enabled is
either IPC or TCPS, to disable the remote administration by unsecured users.
Set INBOUND_CONNECT_TIMEOUT to limit the amount of time allowed for a
connection to be created.
Set up COST restrictions so that only verified instances are allowed to register to the
listener.
DYNAMIC_REGISTRATION_listener_name = ON
SECURE_CONTROL_listener_name = TCPS,IPC
SECURE_PROTOCOL_listener_name = TCPS,IPC
SECURE_REGISTER_listener_name = TCPS,IPC
Oracle Database
Network configuration/encryption
Databaseconfiguration:
Best practices:
Enforce the usage of strong password verifiers, by setting

SQLNET.ALLOWED_LOGON_VERSION (pre 12c)
SQLNET.ALLOWED_LOGON_VERSION_SERVER and
SQLNET.ALLOWED_LOGON_VERSION_CLIENT (12c)
Restrict access to the database using (sqlnet settings):

TCP.VALIDNODE_CHECKING = YES
TCP.EXCLUDED_NODES = {list of IP addresses}
TCP.INVITED_NODES = {list of IP addresses}
Restrict unauthorized access to database through the database parameters:

SEC_MAX_FAILED_LOGIN_ATTEMPTS limit the amount of failed
logins/session.
SEC_PROTOCOL_ERROR_TRACE_ACTION,
SEC_PROTOCOL_ERROR_FURTHER_ACTION to prevent denial-ofservice attacks
SEC_RETURN_SERVER_RELEASE_BANNER avoid disclosure of
database release and options.
Oracle Database
Network encryption
Oracle Native Encryption
Main features:
Symmetric encryption; the same key is used both for
encryption and decryption of the same data.
Oracle provides the Advanced Encryption Standard (AES),
DES, 3DES, and RC4 symmetric cryptosystems for protecting
the confidentiality of Oracle Net Services traffic.
Oracle uses the Diffie-Hellman key negotiation algorithm to
perform secure key distribution for both encryption and data
integrity.
Performance impact:
reduced. There are no known issues when employing this
encryption method. However, some CPU overhead is to be
expected.
Oracle Database
Network encryption
Secure Sockets Layer (SSL)

Main features:
industry standard protocol designed for securing network connections.
SSL uses RSA public key cryptography in conjunction with symmetric key
cryptography to provide authentication, encryption, and data integrity.
Relies on Public Key Cryptography mechanism.
PKI Certificates are stored in local wallets or third party Hardware Security
Modules.
It is a very secure encryption mechanism, especially if using a Trusted

Certification Authority.
Restrictions:
Relatively difficult to setup: each client requires its specific configuration.
Implies additional costs if using a Trusted Certification Authority.
Multi-threaded clients currently cannot use SSL.

Performance impact:
Significant. It is slower than the Native Encryption and a relatively important

CPU overhead can be expected.
Oracle Database
Database auditing (standard and unified)

Auditing is the ability to track changes that users make in the
database. Starting the 12c release, you can use unified auditing to
centralize all audit records in one place.
Can be configured for successful or failed activities.
Can be configured for different users.
It can be standard (until 11gR2) or unified (from 12c).
Sysdba connect, startup and shutdown are always audited.
Standard audit can be stored in the database(aud$, fga_log$), OS
files or XML files.
Standard audit can be redirected to the SYSLOG OS audit trail, local
or remote.
Oracle Database
Starting release 12c, it is recommended to use unified auditing.

Set up the audit strategy. It is important to audit everything that is required by the
company policies and, in the same time, to avoid overwhelming the audit trail with
unnecessary audit data.
Regularly archive the audit entries and purge the audit trail (use
DBMS_AUDIT_MGMT to setup the purge policy).
Remember that in standard auditing, mandatory audit entries for SYS users are sent
into the AUDIT_FILE_DEST directory. Create the appropriate policy to verify and
purge these files.
Protect the audit trail (AUD$ and FGA_LOG$) when using standard auditing.
Audit the SYSDBA operations by setting the AUDIT_SYS_OPERATIONS=TRUE
Set the audit parameter AUDIT_TRAIL (DB_EXTENDED=recommended value).
If using standard audit, it is recommended to move the audit tables (AUD$ and
FGA_LOG$). to a dedicated tablespace using DBMS_AUDIT_MGMT.
When the audit trail is to be protected from DBA tampering and unified auditing is not
an option, use SYSLOG auditing. Note this type of audit is limited as compared to
DB/XML auditing. Alternative: AUDIT VAULT
Other types of audit: Fine Grained Audit/Custom/Log Miner (Audit Vault).
Oracle Database

Performance impact:
Significant. Of course, the overall impact depends on the amount of
audit that is generated. This is why it is recommended to audit only
what is necessary, following a well balanced plan.
It is recommended to move the audit trail to a dedicated tablespace
when using standard auditing.
Oracle Database
Overview of Authentication Methods

Authentication means verifying the identity of someone
(a user, device, or other entity) who wants to use data,
resources, or applications.
To validate the identity of database users and prevent
unauthorized use of a database user name, you can
authenticate using any combination of the following
methods:
Authentication by the Operating System
Authentication by the Network
Authentication by the Oracle Database
Multi-tier Authentication and Authorization
Authentication by the Secure Socket Layer Protocol
Authentication of Database Administrators
Oracle Database
Overview of Authorization
Authorization primarily includes two processes:
Permitting only certain users to access, process, or
alter data
Applying varying limitations on users access or
actions. The limitations placed on (or removed from)
users can apply to objects, such as schemas,
tables, or rows; or to resources, such as time (CPU,
connect, or idle times).
Oracle Database
User Resource Limits and Profiles

You can set limits on the amount of various system
resources available to each user as part of a users
security domain.
By doing so, you can prevent the uncontrolled
consumption of valuable system resources such as CPU
time.
Manage a users resource limits and password
management preferences with his or her profile - a
named set of resource limits that you can assign to that
user.
The security administrator can enable or disable the
enforcement of profile resource limits universally.
Oracle Database
Introduction to Privileges
A privilege is a right to run a particular type of SQL
statement or to access another users object.
Grant privileges to users so that they can accomplish
tasks required for their job.
Grant privileges only to users who absolutely require
them. Excessive granting of unnecessary privileges can
compromise security.
A user can receive a privilege in two different ways:
You can grant privileges to users explicitly.
You can grant privileges to a role (a named group of
privileges), and then grant the role to one or more
users.
Oracle Database
Introduction to Roles
Managing and controlling privileges is made easier by using roles,
which are named groups of related privileges that you grant, as a
group, to users or other roles.
Roles ease the administration of end-user system and schema
object privileges.
Oracle Database
Secure Application Roles

Oracle provides secure application roles, which are roles
that can only be enabled by authorized PL/SQL
packages.
This mechanism restricts the enabling of such roles to
the invoking application.
Package identity is used to determine whether privileges
are sufficient to enable the roles.
Before enabling the role, the application can perform
authentication and customized authorization, such as
checking whether the user has connected through a
proxy.
Oracle Database
Fine-Grained Access Control

Fine-grained access control lets you use functions to implement
security policies and to associate those security policies with tables,
views, or synonyms.
The database server automatically enforces your security policies,
no matter how the data is accessed
You can:
Use different policies for SELECT, INSERT, UPDATE, and
DELETE.
Use security policies only where you need them (for example,
on salary information).
Use more than one policy for each table, including building on
top of base policies in packaged applications.
Distinguish policies between different applications, by using
policy groups.
Oracle Database
Application Context
Application context helps you apply fine-grained access
control because you can associate your function-based
security policies with applications.
Each application has its own application-specific context,
which users cannot arbitrarily change (for example,
through SQL*Plus).
Context attributes are accessible to the functions
implementing your security policies.
Application contexts thus permit flexible, parameterbased access control using attributes of interest to an
application.
Oracle Database
Fine-Grained Auditing
Fine-grained auditing allows the monitoring of data
access based on content.
Fine-grained auditing policy is based on simple userdefined SQL predicates on table objects as conditions
for selective auditing.
Fine-grained auditing can be implemented in user
applications using the DBMS_FGA package or by using
database triggers.
Oracle Database
Overview of Database Auditing

Auditing is the monitoring and recording of selected user
database actions.
Security policies can cause auditing when specified
elements in an Oracle database are accessed or altered,
including content.
Auditing is generally used to:
Enable future accountability for current actions
taken in a particular schema, table, or row, or
affecting specific content.
Investigate suspicious activity.
Monitor and gather data about specific database
activities.
Oracle Database
Overview of Database Auditing

Auditing is the monitoring and recording of selected user
database actions.
Security policies can cause auditing when specified
elements in an Oracle database are accessed or altered,
including content.
Auditing is generally used to:
Enable future accountability for current actions
taken in a particular schema, table, or row, or
affecting specific content.
Investigate suspicious activity.
Monitor and gather data about specific database
activities.
Oracle Database
Types of Auditing
Oracle Database
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Oracle Database
Introduction to Data Integrity

It is important that data adhere to a predefined set of
rules, as determined by the database administrator or
application developer.
Oracle Database
Types of Data Integrity

A null rule 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.
A unique value rule 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).
A primary key value rule 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.
A referential integrity rule is 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).
Oracle Database
How Oracle Enforces Data Integrity

An integrity constraint is a declarative method of defining
a rule for a column of a table. Oracle supports the
following integrity constraints:
NOT NULL constraints for the rules associated with
nulls in a column
UNIQUE key constraints for the rule associated with
unique column values
PRIMARY KEY constraints for the rule associated
with primary identification values
FOREIGN KEY constraints for the rules associated
with referential integrity
CHECK constraints for complex integrity rules
Oracle Database
Overview of Integrity Constraints

Oracle uses integrity constraints to prevent invalid data
entry into the base tables of the database.
You can define integrity constraints to enforce the
business rules you want to associate with the information
in a database.
If any of the results of a DML statement execution violate
an integrity constraint, then Oracle rolls back the
statement and returns an error.
The integrity constraints implemented in Oracle fully
comply with ANSI X3.135-1989 and ISO 9075-1989
standards.
Oracle Database
Not Null Integrity Constraints
Oracle Database
Unique Key Constraints
Oracle Database
Primary Key Constraints
Oracle Database
Referential Integrity Constraints
Oracle Database
Topics

Manageability
Backup and Recovery
High Availability
Content Management
Database Security
Data Integrity
Triggers
Oracle Database
Introduction to Triggers
Triggers are procedures stored in PL/SQL or Java that run (fire)
implicitly whenever a table or view is modified or when some user
actions or database system actions occur.
You can write triggers that fire whenever one of the following
operations occurs:
DML statements (INSERT, UPDATE, DELETE) on a particular
table or view, issued by any user
DDL statements (CREATE or ALTER primarily) issued either
by a particular schema/user or by any schema/user in the
database
Database events, such as logon/logoff, errors, or
startup/shutdown, also issued either by a particular
schema/user or by any schema/user in the database
Oracle Database
Trigger Example
Oracle Database
Types of Triggers
A row trigger is fired each time the table is affected by the triggering
statement.
A statement trigger is fired once on behalf of the triggering
statement, regardless of the number of rows in the table that the
triggering statement affects, even if no rows are affected.
BEFORE triggers run the trigger action before the triggering
statement is run.
AFTER triggers run the trigger action after the triggering statement
is run.
INSTEAD OF triggers provide a transparent way of modifying views
that cannot be modified directly through DML statements. These
triggers are called INSTEAD OF triggers because, unlike other types
of triggers, Oracle fires the trigger instead of executing the triggering
statement.
You can use triggers to publish information about database events
to subscribers.
Oracle Database
Trigger Execution
Oracle runs a trigger internally using the same steps
used for procedure execution.
The only subtle difference is that a user has the right to
fire a trigger if he or she has the privilege to run the
triggering statement.
Other than this, triggers are validated and run the same
way as stored procedures.
Oracle Database
Topics
Oracle Database Application Development
Information Integration
SQL, PL/SQL, and Java
Overview of Application Development Languages
Native Datatypes
Object Datatypes and Object Views
Oracle Database
Topics
Native Datatypes
Oracle Database
Federated Access
Distributed SQL enables applications and users to
simultaneously access or modify the data in several
databases as easily as they access or modify a single
database.
An Oracle distributed database system can be
transparent to users, making it appear as though it is a
single Oracle database.
Oracle uses database links to enable users on one
database to access objects in a remote database.
An Oracle distributed database system lets application
developers and administrators hide the physical location
of database objects from applications and users.
Oracle Database
SQL and COMMIT Transparency

Oracle ensures the integrity of data in a distributed
transaction using the two-phase commit mechanism.
In the prepare phase, the initiating node in the
transaction tasks the other participating nodes to
promise to commit or undo the transaction.
During the commit phase, the initiating node asks all
participating nodes to commit the transaction. If this
outcome is not possible, then all nodes undo.
The two-phase commit mechanism is completely
transparent, requiring no complex programming or other
special operations to provide distributed transaction
control.
Oracle Database
Information Sharing
Replication is the maintenance of database objects in
two or more databases.
It provides a solution to the scalability, availability, and
performance issues facing many companies.
For loose application coupling, Oracle offers Oracle
Streams Advanced Queuing, which is built on top of the
flexible Oracle Streams infrastructure.
Oracle Streams Advanced Queuing provides a unified
framework for processing events.
Oracle Database
Oracle Streams
Oracle Streams enables the propagation and
management of data, transactions, and events in a data
stream either within a database, or from one database to
another.
The stream routes published information to subscribed
destinations.
Oracle Streams satisfies the information sharing
requirements for a variety of usage scenarios.
Oracle Streams Advanced Queuing provides the
database-integrated message queuing and event
management capabilities.
Oracle Database
Replication with Oracle Streams

Oracle Streams is an information sharing technology that
automatically determines what information is relevant
and shares that information with those who need it.
This active sharing of information includes capturing and
managing events in the database including DML and
DDL changes and propagating those events to other
databases and applications.
Data changes can be applied directly to the replica
database or can call a user-defined procedure to perform
alternative work at the destination database.
Oracle Database
Oracle Streams Configuration
Oracle Database
Materialized Views
Oracle Streams is fully inter-operational with materialized
views, or snapshots, which can be used to maintain
updatable or read-only, point-in-time copies of data.
They can be defined to contain a full copy of a table or a
defined subset of the rows in the master table that satisfy
a value-based selection criterion.
Because materialized views do not require a dedicated
connection, they are ideal for disconnected computing.
Oracle Database
Integrating Non-Oracle Systems

Oracle provides two solutions for integrating the Oracle
database server with non-Oracle databases--Generic
Connectivity and Transparent Gateways.
These solutions enable Oracle clients to access nonOracle data stores.
They translate third party SQL dialects, data dictionaries,
and datatypes into Oracle formats, thus making the nonOracle data store appear as a remote Oracle database.
These technologies enable companies to integrate
seamlessly the different systems and provide a
consolidated view of the company as a whole.
Oracle Database
Generic Connectivity
Generic Connectivity is a generic solution that uses an
ODBC or OLEDB driver to access any ODBC or OLEDB
compliant non-Oracle system.
It provides data access to many data stores for which
Oracle does not have a gateway solution.
This enables transparent connectivity using industry
standards, such as ODBC and OLEDB.
Generic connectivity makes it possible to access low-end
data stores, such as Foxpro, Access, dBase, and nonrelational targets like Excel.
Oracle Database
Oracle Transparent Gateways

Oracle Transparent Gateways are tailored solutions,
specifically coded for the non-Oracle system.
They provide an optimized solution, with more
functionality and better performance than Generic
Connectivity.
Generic Connectivity relies on industry standards,
whereas Oracle Transparent Gateways accesses the
non-Oracle systems using their native interface.
The Transparent Gateways are also end-to-end certified.
Oracle has Transparent Gateways to many sources,
including Sybase, DB2, Informix, and Microsoft SQL
Server.
Oracle Database
Topics
Native Datatypes
Oracle Database
Overview of SQL
SQL is a database access, nonprocedural language.
Users describe in SQL what they want done, and the
SQL language compiler automatically generates a
procedure to navigate the database and perform the
desired task.
Oracle SQL includes many extensions to the ANSI/ISO
standard SQL language, and Oracle tools and
applications provide additional statements.
The Oracle tools SQL*Plus and Oracle Enterprise
Manager let you run any ANSI/ISO standard SQL
statement against an Oracle database, as well as
additional statements or functions that are available for
those tools.
Oracle Database
Shared SQL
Oracle automatically notices when applications send
similar SQL statements to the database.
The SQL area used to process the first occurrence of the
statement is sharedthat is, used for processing
subsequent occurrences of that same statement.
Therefore, only one shared SQL area exists for a unique
statement.
Because shared SQL areas are shared memory areas,
any Oracle process can use a shared SQL area.
The sharing of SQL areas reduces memory use on the
database server, thereby increasing system throughput.
Oracle Database
Stages in Processing a SQL Statement
Oracle Database
Overview of the Optimizer

All SQL statements use the optimizer, a part of Oracle
that determines the most efficient means of accessing
the specified data.
The procedure Oracle uses to run a statement can
greatly affect how quickly the statement runs.
The optimizer considers many factors among alternative
access paths.
The combination of the steps Oracle uses to run a
statement is called an execution plan.
An execution plan includes an access method for each
table that the statement accesses and an ordering of the
tables (the join order).
Oracle Database
Overview of PL/SQL
PL/SQL is Oracles procedural language extension to SQL.
It provides a server-side, stored procedural language that is easy-touse, seamless with SQL, robust, portable, and secure.
PL/SQL enables you to mix SQL statements with procedural
constructs.
With PL/SQL, you can define and run PL/SQL program units such
as procedures, functions, and packages.
An anonymous block is a PL/SQL block that appears in your
application and is not named or stored in the database.
A stored procedure is a PL/SQL block that Oracle stores in the
database and can be called by name from an application.
Oracle Database
The PL/SQL Engine and the Oracle Database

Server
Oracle Database
Stored Procedures
Oracle Database
Stored Package
Oracle Database
Oracles Java Application Strategy

Oracle furnishes enterprise application developers with
an end-to-end Java solution for creating, deploying, and
managing Java applications.
The total solution consists of client-side and server-side
programmatic interfaces, tools to support Java
development, and a Java Virtual Machine integrated with
the Oracle database server.
All these products are compatible with Java standards.
Oracle Database
Oracles Java Application Strategy

In addition to the Oracle JVM, the Java programming
environment consists of the following:
Java stored procedures as the Java equivalent and
companion for PL/SQL. Java stored procedures are
tightly integrated with PL/SQL. You can call a Java
stored procedure from a PL/SQL package; you can
call PL/SQL procedures from a Java stored
procedure.
SQL data can be accessed through the JDBC
programming interface.
Tools and scripts used in assisting in development,
class loading, and class management.
Oracle Database
Java Stored Procedures

A Java stored procedure is a program you write in Java
to run in the server, exactly as a PL/SQL stored
procedure.
You invoke it directly with products like SQL*Plus, or
indirectly with a trigger. You can access it from any
Oracle Net clientOCI, precompiler, or JDBC.
In addition, you can use Java to develop powerful
programs independently of PL/SQL.
Oracle provides a fully-compliant implementation of the
Java programming language and JVM.
Oracle Database
JDBC
Java database connectivity (JDBC) is an application
programming interface (API) for Java developers to
access SQL data.
It is available on client and server, so you can deploy the
same code in either place.
Oracles JDBC allows access to objects and collection
types defined in the database from Java programs
through dynamic SQL.
Oracle Database
SQLJ
SQLJ allows developers to use object datatypes in Java
programs.
Developers can use JPublisher to map Oracle object and
collection types into Java classes to be used in the
application.
SQLJ provides access to server objects using SQL
statements embedded in the Java code.
SQLJ provides compile-time type checking of object
types and collections in the SQL statements.
The syntax is based on an ANSI standard (SQLJ
Consortium)
Oracle Database
JPublisher
Java Publisher (JPublisher) is a utility, written entirely in
Java, that generates Java classes to represent the
following user-defined database entities in your Java
program:
SQL object types
Object reference types ("REF types")
SQL collection types (VARRAY types or nested
table types)
PL/SQL packages
JPublisher lets you to specify and customize the
mapping of these entities to Java classes in a strongly
typed paradigm.
Oracle Database
Java Messaging Service

JMS provides a standard-based API to enable
asynchronous exchange of business events within the
enterprise, as well as with customers and partners.
JMS facilitates reliable communication between loosely
coupled components in a distributed environment,
significantly simplifying the effort required for enterprise
integration.
The combination of Java technology with enterprise
messaging enables development of portable
applications.
Oracle Database
Topics
Native Datatypes
Oracle Database
Overview of Oracle Call Interface (OCI)

The Oracle Call Interface (OCI) is an application programming
interface (API) that lets you 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 lets you manipulate data and schemas in an Oracle database
using a host programming language, such as C.
It provides a library of standard database access and retrieval
functions in the form of a dynamic runtime library (OCI library) that
can be linked in an application at runtime.
This eliminates the need to embed SQL or PL/SQL within 3GL
programs.
Oracle Database
Overview of Oracle Call Interface (OCI)

OCI provides the following:
Improved performance and scalability through the
use of system memory and network connectivity.
Consistent interfaces for dynamic session and
transaction management in a two-tier client/server
or multitier environment.
N-tiered authentication.
Comprehensive support for application development
using Oracle objects.
Access to external databases.
Applications that can service an increasing number
of users and requests without additional hardware
investments.
Oracle Database
Overview of Oracle C++ Call Interface (OCCI)

The Oracle C++ Call Interface (OCCI) is a C++ API that
lets you use the object-oriented features, native classes,
and methods of the C++ programing language to access
the Oracle database.
The OCCI interface is modeled on the JDBC interface
and, like the JDBC interface, is easy to use.
OCCI is built on top of OCI and provides the power and
performance of OCI using an object-oriented paradigm.
OCCI provides a simpler, object-oriented interface to the
functionality of OCI.
Oracle Database
Overview of Pro*C/C++ Precompiler

An Oracle precompiler is a programming tool that lets you embed
SQL statements in a high-level source program.
The precompiler accepts the host program as input, translates the
embedded SQL statements into standard Oracle run-time library
calls, and generates a source program that you can compile, link,
and run in the usual way.
The Oracle Pro*C/C++ Precompiler lets you embed SQL statements
in a C or C++ source file.
Pro*C/C++ reads the source file as input and outputs a C or C++
source file that replaces the embedded SQL statements with Oracle
runtime library calls, and is then compiled by the C or C++ compiler.
Oracle Database
Overview of Microsoft Programming

Languages
Oracle offers a variety of data access methods from
COM-based programming languages, such as Visual
Basic and Active Server Pages.
These include Oracle Objects for OLE (OO40) and the
Oracle Provider for OLE DB. The latter can be used with
Microsoft's ActiveX Data Objects (ADO).
Server-side programming to COM Automation servers,
such as Microsoft Office, is available through the COM
Automation Feature.
Oracle Database
Overview of Microsoft Programming

Languages
Traditional ODBC access is available through Oracle's
ODBC Driver. C/C++ applications can also use the
Oracle Call Interface (OCI).
Oracle also provides optimum .NET data access support
through the Oracle Data Provider for .NET, allowing
.NET to access advanced Oracle features.
Oracle also support OLE DB .NET and ODBC .NET.
Oracle Database
Overview of Legacy Languages

The Pro*COBOL Precompiler is a programming tool that
lets you embed SQL statements in a host COBOL
program.
Pro*COBOL reads the source file as input and outputs a
COBOL source file that replaces the embedded SQL
statements with Oracle runtime library calls, and is then
compiled by the COBOL compiler.
The Oracle Pro*FORTRAN Precompiler lets you embed
SQL in a host FORTRAN program.
Pro*FORTRAN is not supported on Windows.
Oracle Database
Topics
Native Datatypes
Oracle Database
Native Datatypes
CHAR Datatype
The CHAR datatype stores fixed-length character strings.
When you create a table with a CHAR column, you must
specify a string length (in bytes or characters) between 1 and
2000 bytes for the CHAR column width.
Oracle compares CHAR values using blank-padded
comparison semantics.
VARCHAR2 Datatype
The VARCHAR2 datatype stores variable-length character
strings.
When you create a table with a VARCHAR2 column, you
specify a maximum string length (in bytes or characters)
between 1 and 4000 bytes for the VARCHAR2 column.
For each row, Oracle stores each value in the column as a
variable-length field unless a value exceeds the columns
maximum length, in which case Oracle returns an error.
Using VARCHAR2 saves on space used by the table.
Oracle Database
Native Datatypes
NCHAR and NVARCHAR2 Datatypes
NCHAR and NVARCHAR2 are Unicode datatypes that store
Unicode character data.
The character set of NCHAR and NVARCHAR2 datatypes can
only be either AL16UTF16 or UTF8 and is specified at
database creation time as the national character set.
AL16UTF16 and UTF8 are both Unicode encoding.
The NCHAR datatype stores fixed-length character strings that
correspond to the national character set.
The NVARCHAR2 datatype stores variable length character
strings.
LOB Character Datatypes
The LOB datatypes for character data are CLOB and NCLOB.
They can store up to 8 terabytes of character data (CLOB) or
national character set data (NCLOB).
Oracle Database
Native Datatypes
NUMBER Datatype
The NUMBER datatype stores fixed and floating-point
numbers.
Numbers of virtually any magnitude can be stored and are
guaranteed portable among different systems operating
Oracle, up to 38 digits of precision.
DATE Datatype
The DATE datatype stores point-in-time values (dates and
times) in a table.
The DATE datatype stores the year, the month, the day, the
hours, the minutes, and the seconds (after midnight).
Oracle can store dates in the Julian era, ranging from January
1, 4712 BCE through December 31, 4712 CE (Common Era,
or 'AD').
Date data is stored in fixed-length fields of seven bytes each,
corresponding to century, year, month, day, hour, minute, and
second.
Oracle Database
Native Datatypes
BLOB Datatype
The BLOB datatype stores unstructured binary data in the
database. BLOBs can store up to 8 terabytes of binary data.
BFILE Datatype
The BFILE datatype stores unstructured binary data in
operating-system files outside the database.
A BFILE column or attribute stores a file locator that points to
an external file containing the data.
BFILEs can store up to 8 terabytes of data.
BFILEs are read only; you cannot modify them.
They support only random (not sequential) reads, and they do
not participate in transactions.
Oracle Database
Native Datatypes
ROWID and UROWID Datatypes
Oracle uses a ROWID datatype to store the address
(rowid) of every row in the database.
Physical rowids store the addresses of rows in
ordinary tables (excluding index-organized tables),
clustered tables, table partitions and subpartitions,
indexes, and index partitions and subpartitions.
Logical rowids store the addresses of rows in indexorganized tables.
A single datatype called the universal rowid, or

UROWID, supports both logical and physical rowids,
as well as rowids of foreign tables such as nonOracle tables accessed through a gateway.
Oracle Database
Overview of ANSI, DB2, and SQL/DS Datatypes

SQL statements that create tables and clusters can also
use ANSI datatypes and datatypes from IBMs products
SQL/DS and DB2.
Oracle recognizes the ANSI or IBM datatype name that
differs from the Oracle datatype name, records it as the
name of the datatype of the column, and then stores the
columns data in an Oracle datatype based on the
conversions.
Oracle Database
XMLType Datatype
XMLType can be used like any other user-defined type.
XMLType can be used as the datatype of columns in
tables and views.
Variables of XMLType can be used in PL/SQL stored
procedures as parameters, return values, and so on.
You can also use XMLType in PL/SQL, SQL and Java,
and through JDBC and OCI.
Oracle Database
Topics
Native Datatypes
Oracle Database
Introduction to Object Datatypes

Oracle object technology is a layer of abstraction built on
Oracle's relational technology.
New object types can be created from any built-in
database types or any previously created object types,
object references, and collection types.
Metadata for user-defined types is stored in a schema
available to SQL, PL/SQL, Java, and other published
interfaces.
Object datatypes make it easier to work with complex
data, such as images, audio, and video.
Oracle Database

An object type differs from native SQL datatypes in that it
is user-defined, and it specifies both the underlying
persistent data (attributes) and the related behaviors
(methods).
Object types are abstractions of the real-world entities.
Object types store structured business data in its natural
form and allow applications to retrieve it that way.
Object types and related object-oriented features, such
as variable-length arrays and nested tables, provide
higher-level ways to organize and access data in the
database.
Oracle Database

Underneath the object layer, data is still stored in
columns and tables, but you can work with the data in
terms of the real-world entities--customers and purchase
orders, for example--that make the data meaningful.
Instead of thinking in terms of columns and tables when
you query the database, you can simply select a
customer.
Oracle Database
Introduction to Object Views

Just as a view is a virtual table, an object view is a
virtual object table.
Oracle provides object views as an extension of the
basic relational view mechanism.
By using object views, you can create virtual object
tables from dataof either built-in or user-defined
typesstored in the columns of relational or object
tables in the database.
Object views provide the ability to offer specialized or
restricted access to the data and objects in a database.
Oracle Database
Introduction to Object Views

Object views allow the use of relational data in objectoriented applications. They let users:
Try object-oriented programming techniques without
converting existing tables
Convert data gradually and transparently from
relational tables to object-relational tables
Use legacy RDBMS data with existing objectoriented applications
Oracle Database

Oracle Database Concepts

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Oracle Database Concepts

Загружено:

Авторское право:

Доступные форматы

ORACLE