Oracle Back End

globsyn technologies
 Overview of primary
Components
• Oracle Architecture consists of:
– Oracle Server : Consists of an Oracle instance and
Oracle database.
• Oracle Instance: Consists of background processes and
memory structures.
• Oracle Database:Consists of Operating System Files, also
known as data files that provide the actual physical storage
for database information.The database files ensures that data
is kept consistent and can be recovered in the event of a
failure.
 Oracle Server
• Oracle Server is a database management
system that provides an open
comprehensive integrated approach to
information management.
• Consists of an Oracle Instance and an
Oracle database.
 Oracle Instance
• Allows Access to an Oracle database.
• Always opens one and only one database.
• Consists of memory structures and
background processes.
 Establishing a Connection and
Creating a Session
• Connecting to an Oracle instance:
• Establishing a user connection
• Creating a session.
 Oracle Database
• Collection of data that is treated as a unit.
• It consists of three kind of files:
– Data Files: containing the actual data in the
database.
– Redo Log Files: Containing a record of
changes made to the database to enable
recovery.
– Control files containing information necessary
to maintain and verify databases.
 Other Key Files
• Parameter File: Defines the characteristics
of an Oracle Instance.
• Password File: Authenticates users
privileges to start up and shut down the
Oracle instance.
• Archived Redo Log Files: Offline copies
of redo log files that may be necessary to
recover from media failures
 Physical Structure of an Oracle
Database
• The physical structure of an Oracle
database consists of three kinds of files
namely:
– Control Files
– Data Files
– Redo Log Files
 Memory Structure
• Oracle’s memory structure consists of the
following two memory areas:
– System Global Area (SGA): Allocated at
instance startup, and is a fundamental
component of Oracle instance.
– Program Global Area (PGA): Allocated when
the server process is started.
 System Global Area (SGA)
• The SGA consists of several memory structures:
– Shared Pool
– Database Buffer Cache
– Redo Log Buffer
• There can be two additional memory structures
that can be configured within the SGA:
– Large Pool
– Java Pool
 Dynamic SGA
• Oracle 9i has introduced the concept of dynamic
SGA.
• SGA configurations can be changed without
shutting down the instance.
• In particular, Database Buffer Cache and Shared
Pool can be resized without shutting down the
instance.
• The SGA (DB Buffer Cache and Shared Pool)
can grow upto a maximum of SGA_MAX_SIZE.
 Parameter affecting the size of
SGA
• DB_CACHE_SIZE: The size of the cache of
standard blocks. Default is 48 MB on UNIX and
52 MB on Windows.
• LOG_BUFFER: The number of bytes allocated to
the Redo Log Buffer.
• SHARED_POOL_SIZE: The size in bytes
allocated to Shared Pool, Default is 16 MB and 64
MB for 64 bit.
• JAVA_POOL_SIZE: The size of the Java Pool.
Default is 24 MB.
 Shared Pool
• Used to store:
– Most recently executed SQL statements.
– Most recently used data definitions
• It is further divided into two structures:
– Library Cache
– Data Dictionary Cache
• Sized by the parameter
SHARED_POOL_SIZE.
 More on Shared Pool
• The Shared Pool environment contains both fixed
and variable memory structures.
• The fixed structure remains relatively the same
size, whereas variable structures grow and shrink
based on user and program requirements.
• The actual sizing of the fixed and variable
structures is based on the initialization parameter
and the work of an Oracle internal algorithm.
 Sizing the Shared Pool
• Memory allocation of the Shared Pool is
determined by the SHARED_POOL_SIZE
initialization parameter.
• It can be dynamically resized by using the
ALTER SYSTEM SET command.
• However, the total SGA cannot exceed
SGA_MAX_SIZE.
 Library Cache
• Stores information about the most recently used
SQL and PL/SQL statements.
• Enables the sharing of commonly used statements.
• Is managed by a least recently used (LRU)
algorithm.
• Consists of two structures:
– Shared SQL area
– Shared PL/SQL area
• Size determined by the Shared Pool sizing.
 Data Dictionary Cache
• A collection of most recently used definitions in the
database.
• Includes information about database files, tables, indexes,
columns, users, privileges, and other database objects.
• During the parse phase, the server process looks at the
data dictionary for information to resolve object names
and validate access.
• Caching data dictionary information into memory
improves response time on queries and DML.
• Size determined by Shared Pool Sizing.
 Sizing the Data Dictionary
Cache
• The overall size is determined on the size
of the Shared Pool size and is managed
internally by the database.
 Database Buffer Cache
• Stores copies of data blocks that have been
retrieved from the datafiles.
• Enables great performance gains when
data is to be retrieved or updated.
• Managed through an LRU algorithm.
• DB_BLOCK_SIZE determines primary
block size.
 Sizing the Database Buffer
Cache
• The size of the Database Buffer Cache is
specified by the size of an Oracle block and it is
specified by DB_BLOCK_SIZE parameter.
• The Database Buffer Cache consists of
independent subcaches for buffer pools and for
multiple block size.
• The parameter DB_BLOCK_SIZE determines
the primary block size, which is used by the
SYSTEM tablespace.
 More on sizing the Database
Buffer Cache
• The following three parameters affect the size of
Database Buffer Cache:
– DB_CACHE_SIZE: Sizes the default buffer cache
only. It always exists and cannot be set to zero.
– DB_KEEP_CACHE_SIZE: Sizes the Keep Buffer
Cache, which is used to retain blocks in memory and
are likely to be reused.
– DB_RECYCLE_CACHE_SIZE: Sizes the recycle
buffer cache, which is used to eliminate blocks from
memory that have little chance of being reused.
 Buffer Cache Advisory
• Enables and disables statistics gathering for prediciting behavior with
different cache sizes.
• The information provided by these statistics enables determination of
the size of Database Buffer Cache optimally for a given workload.
• The Buffer cache Advisory information is collected and displayed
through the V$DB_CACHE_ADVICE data dictionary view.
• The Buffer Cache Advisory is enabled by a dynamic initialization
parameter DB_CACHE_ADVICE.
• This parameter can have the following three values:
– OFF
– ON
– READY
 DB_CACHE_ADVICE
parameter values
• OFF: Advisory is turned off and the
memory for the advisory is not allocated.
• ON: Advisory is turned on and both CPU
and memory overhead is incurred.
• READY: Advisory is turned off but the
memory for the advisory remains
allocated.
 Redo Log Buffer
• Records all changes made to the database
data blocks.
• Primary purpose is recovery.
• Changes recorded within are called redo
entries.
• Redo entries contain information to
reconstruct or redo changes.
• Size defined by REDO_LOG_BUFFER.
 Large Pool
• An optional area of memory in the SGA.
• Relives the burden placed on the Shared Pool.
• Used for:
– Session memory (UGA) for the Shared Server.
– I/O server processes.
– Backup and restore operations for RMAN.
– Parallel execution message buffers
• PARALLEL_AUTOMATIC_TUNING set to TRUE.
• Does not use an LRU list
• Sized by LARGE_POOL_SIZE.
 Java Pool
• Services parsing requirements for Java
commands.
• Required if installing and using Java.
• Sized by JAVA_POOL_SIZE parameter.
• Default size is 24 MB.
 Program Global Area
• Memory reserved for each user process
connecting to an Oracle database.
• Allocated when a process is created.
• Deallocated when a process is terminated.
• Used by only one process.
 Contents of PGA
• The content of PGA memory varies, depending
upon whether the instance is running in
Dedicated Server or Shared Server
Configuration.
• Generally, it contains the following components:
– Private SQL Area
– Session Memory
– SQL Work Area
 Process Structure
• Oracle takes advantage of various types of
processes:
– User Process: Started at the time the database
user requests connection to the Oracle Server.
– Server Process: Connects to the Oracle
instance and is started when a user establishes
a session.
– Background Process: Started when an Oracle
instance is started.
 User Process
• A program that requests interaction with
the Oracle server,
• Must first establish a connection.
• Does not interact directly with the Oracle
server.
 Sever process
• A program that directly interacts with the
Oracle Server.
• Fulfills calls generated and returns results.
• Can be Dedicated or Shared Server.
 Background Processes
• Maintains and enforces relationships
between physical and memory structures.
• Mandatory background processes:
– DBWn
– LGWR
– PMON
– SMON
– CKPT
 Database Writer (DBWn)
• DBWn writes when
– Checkpoint occurs
– Dirty Buffers reach threshold
– There are no free buffers
– Timeout occurs
– RAC ping request is made.
– Tablespace OFFLINE.
– Tablespace READ ONLY.
– Table DROP or TRUNCATE.
– Tablespace BEGIN BACKUP.
 Log Writer (LGWR)
• LGWR performs sequential writes from the Redo Log
Buffer to the redo log file under the following
circumstances:
– When a transaction commits
– When the Redo Log Buffer is one-third full.
– When there is more than 1 MB of changes recorded in the Redo
Log Buffer.
– Before DBWn writes modified blocks in the Database Buffer
cache to the datafiles.
– Every three seconds.
 System Monitor (SMON)
• Responsibilities:
– Instance recovery:
• Rolls forward changes in Redo Logs
• Opens database for user access.
• Rolls back uncommitted changes
– Coalesces free space
– Deallocates temporary segments
 Process Monitor (PMON)
• PMON cleans up after failed processes by:
– Rolling back the user’s current transactions.
– Releasing all currently held table or row locks.
– Freeing other resources currently reserved by
the user.
– Restarts dead despatchers.
 Checkpoint (CKPT_)
• This process is responsible for the
following:
– Signaling the DBWn at checkpoints
– Updating datafile headers with checkpoint
information.
– Updating control files with checkpoint
information
 Archiver (ARCn)
• Optional Background Process
• Automatically archives online Redo Logs
when ARCHIVELOG mode is set.
• Preserves the record of all changes made to
the database.
 Processing a SQL Query
• Parse
– Search for identical statements
– Check syntax, object names and privileges
– Lock objects used during parse
– Create and store execution plan.
• Bind:Obtain values for variables
• Execute:Process Statement
• Fetch:Return Rows to the user.
 Processing a DML statement
• Parse: Same as the parse phase used for
processing a query.
• Bind: Same as the bind phase for
processing a query.
 Execute Phase of a DML
statement
• If the data and undo blocks are not already in the Database Buffer
Cache, the server process reads them from the datafiles into the
Database Buffer Cache.
• The server process places locks on rows that are to be modified.
• The undo block block is used to store before image of the data for
roll back.
• The data blocks record the new values of data.
• The server processes records the before image in the undo block and
updates the data block.
• The processing of DELETE or INSERT statement uses similar steps.
The before image of the for a DELETE contains the column values
in the deleted row. For INSERT, it is the row location information.
 Initialization parameter files
• To start an instance Oracle server reads the
initialization parameter file.
• Two types of Initialization Parameter files
exist:
– Static Parameter File, PFILE commonly
referred to as initSID.ora
– Persistent parameter file, SPFILE, commonly
referred to as spfileSID.ora.
 Initialization parameter File
• A list of instance parameters.
• The name of the database the instance is
associated with.
• Allocation for memory structures of the SGA.
• What to do with with filled online redo log files.
• The names and locations of control files.
• Information of undo segments.
 PFILE
initSID.ora
• Text file.
• Modified with an operating system editor.
• Modifications are made manually.
• Changes take effect on the next startup.
• Only opened during instance startup.
• Default location in $ORACLE_HOME/dbs
 Creating a PFILE
• Created from a sample init.ora file
• Copy sample using operating system copy
command.
• Copy sample using operating system copy
command.
• Uniquely identify database SID.
 SPFILE
spfileSID.ora
• Binary file
• Maintained by the Oracle Server.
• Ability to make changes persistent across startup
and shutdown
• Can self-tune parameter values.
• Can have Can have Recovery Manager support
backing upto the initialization parameter file.
• Default location is $ORACLE_HOME\dbs
directory
 Creating a SPFILE
• Crated from PFILE file
• Can be executed before or after instance
startup.
• Contents of SPFILE can be viewed
through the V$SPPARAMETER data
dictionary view.
STARTUP Command Behavior
• Order of precedence
– spfileSID.ora
– Default SPFILE
– initSID.ora
– Default PFILE
• Specified PFILE can override precedence.
• PFILE can indicate to use SPFILE
 Starting up an instance
• Starting an instance includes the following tasks:
– Reading the initialization file
– Allocating the SGA
– Starting the background process.
– Opening the alertSID.log file and trace files
• An instance would be started in a NOMOUNT
state only during database creation or creation of
datafiles.
 Mounting a database
• Mounting a database includes the following
tasks:
– Associating a database with a previously started
instance.
– Locating and opening the control files specified in the
parameter file.
– Reading the control files to obtain the names and
status of the datafiles and the redo log files. However,
no checks are performed to verify the existence of the
datafiles and online redo log files at this time.
 Cases for mounting a database
• A database must be opened and not opened
in the following circumstances:
– Renaming datafiles
– Enabling and disabling redo log archiving
options.
– Performing full database recovery.
 Opening up a database
• Opening the online datafiles.
• Opening the online redo log files.
• If any of the datafiles or online redo log files are
not present when you attempt to open the
database, the Oracle server returns an error.
• During this stage, the oracle server verifies that all
the datafiles and online redo log files can be
opened and checks the consistency of the database.
If necessary, the SMON process initiates instance
recovery.
 Opening a database in Read-
Only Mode
• A database opened in a read-only mode
can be used to:
– Execute queries.
– Executing disk-sorts using locally managed
tablespaces.
– Takes datafiles offline and online, but not
tablespaces.
– Perform recovery of offline datafiles and
tablespaces.
 Shutting down a database in the
normal mode
• No new connections can be made.
• The Oracle server waits for all users to disconnect
before completing the shutdown.
• Database and redo buffers are written to the disk.
• Background processes are terminated and SGA is
removed from memory.
• Oracle closes and dismounts the database before
shutting down the instance.
• The next startup does not require an instance
recovery.
 Shutting down the database in
the transactional mode
• No clients can start a new transaction on
this particular instance.
• A client is disconnected when the client
ends the transaction that is in progress.
• When all transactions have finished, a
shutdown immediately occurs.
• The next startup does not require an
instance recovery.
 Shutdown immediate
• Current SQL statements being processed by Oracle are
not completed.
• The Oracle server does not wait for the users, who are
currently connected to the database to disconnect.
• Oracle rolls back active transactions and disconnects all
connected users.
• Oracle closes and dismounts the database before shutting
down the instance.
• The next startup does not require an instance recovery.
 Shutdown Abort
• Current SQL statements being processed by the Oracle
server are immediately terminated.
• Oracle does not wait for all users currently connected to
the database to disconnect.
• Database and redo buffers are not written to the disk.
• Uncommitted transactions are not rolled back.
• The instance is terminated without closing the files.The
database is not closed or dismounted.
• The next startup requires an instance recovery which
occurs automatically.
 Monitoring an Instance Using
diagnostics files
• Diagnostic files are a means to capture
information about the database’s activities.
• They are useful tools while managing an
instance.
• Several types of diagnostic files exist.
• The type of diagnostic file depends upon
the problem that has occurred and the
information that is required.
 Types of diagnostic files
• alertSID.log file
• Background trace files
• User Trace files
 Alert Log file
• Contains the following:
– Records the commands
– Records results of major events
– Used for day-today operational information.
– Used for diagnostic database errors.
• Each entry has a timestamp associated with it.
• Location defined by
BACKGROUND_DUMP_DEST parameter.
 Background Trace Files
• Used for logging errors encountered by a background
process.
• These files exist only if there is an error that requires
writing to the trace files.
• A background trace file contains header information
about the version number of the data server and the
operating system.
• Naming convention: sid_processname_PID.trc.
• Location defined by the BACKGROUND_DUMP_DEST
initialization parameter.
 User Trace Files
• Contains statistics for traced SQL statements,
which are useful for SQL tuning.
• Also contains user error messages.
• Naming convention: sid_ora_PID.trc.
• Location defined by USER_DUMP_DEST
initialization parameter.
• Size defined by MAX_DUMP_FILE_SIZE
parameter.
 Enabling or Disabling User
Tracing
• Session Level
– Using the ALTER SESSION command.
– Executing the DBMS procedure
• dbms_system.SET_SQL_TRACE_IN_SESSION.
• Instance level
– Setting the initialization parameter
SQL_TRACE = TRUE
 Built-in Database Objects
• Data Dictionary: Contains description of the objects in the
database.
• Dynamic Performance Tables: Contains information used by
the database administrator to monitor and tune the database
and the instance.
• PL/SQL Packages:Program units adding functionality to the
database. These packages are created when the catproc.sql
script is run after the CREATE DATABASE command.
• Database event Triggers: Executed implicitly when a table
or view is created/modified or when some user actions or
database system actions occur.
 Data Dictionary
• Central to every Oracle Database.
• Describes the database and its objects.
• Contains read-only tables and views.
• Stored in the SYSTEM tablespace.
• Owned by the user SYS.
• Maintained by the Oracle server.
• Accessed with SELECT statements.
 Data Dictionary Objects
• The data dictionary contains descriptions
of the objects in the database.
• There are two types of objects:
– Base Tables
– Data Dictionary Views
 Base Tables
• Underlying tables which store information about the
database.
• First objects created in a Oracle database.
• Created when Oracle server runs the sql.bsq script at
the time the database is created.
• Can be modified only by the Oracle server.
• Rarely accessed because the data is stored in a
cryptic format.
• Example IND$. This table contains information
about the indexes in a database.
 Data Dictionary Views
• Base table summaries.
• Provides a more useful display of base
table information.
• Created by executing the catalog.sql script
that is run after the CREATE DATABASE
command.
 Scripts required for creating
Data Dictionary Views
Script Purpose

catalog.sql Creates commonly used

data dictionary views
and synonyms
catproc.sql Runs scripts required for
server-side PL/SQL
 Data Dictionary Contents
• The definition of all schema objects in the database.
• 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 accessed or updated
the various schema objects.
 How Oracle Server uses Data
Dictionary
• Data in the base tables of the data dictionary are
necessary for the Oracle Server to function.
• Base table information can only be changed by the
Oracle Server.
• During database operation, Oracle server accesses
the base tables to ascertain the existence of the
schema objects and user privileges on such schema
objects.
• The Oracle Server continuously updates the base
tables to reflect changes in the database structures.
 How users and Database
Administrators use the Data
dictionary
• The views created on the base tables serve
as a reference for all the database users.
• Some views are accessible to all Oracle
users while other are intended only for
database administrators.
 Data Dictionary View
Categories
• Three sets of static views.
• Distinguished by their scope:
– DBA: What is in all the schemas.
– ALL: What the user can access
– USER: What is in the user’s schema.
 Views with DBA prefix
• Displays a global view of the entire
database.
• Can be queried only by the database
administrators.
• Any user, who has been granted the
privilege SELECT ANY TABLE can
query the DBA prefixed views of the data
dictionary.
 Views with ALL prefix
• Refers to the user’s overall perspective of
the database.
• These views return information about
schema objects to which users have access.
 Views with USER prefix
• Views which are of interest to a typical database
user.
• Contains the following information:
– Refers to the user’s own private environment in the
database.
– Refer to objects owned by the current user.
– Have column identical to to other views, except the
column OWNER is implied to be the current user.
– Return a subset of information in the ALL views.
 Data Dictionary Examples
• General Overview
– DICTIONARY, DICT_COLUMNS
– Schema Objects
• DBA_TABLES, DBA_INDEXS,
DBA_TAB_COLUMNS, DBA_CONSTRAINTS
– Space allocation
• DBA_SEGMENTS, DBA_EXTENTS
– Database Structures
• DBA_TABLESPACES, DBA_DATA_FILES
 Dynamic Performance Tables
• Virtual tables
• Exists in memory only when the database is running
• Reflects real-time condition of the database operation.
• Information is accessed from memory and control files.
• Database Administrators can query, grant SELECT privilege and create
views on these views.
• Known as fixed views since they cannot be altered and dropped by the
administrators.
• Owned by SYS and names begin with V$.
• Views are created on these tables and public synonyms are created on these
views.
• Synonym names begin with V$.
• V$FIXED_TABLE view contains information about all dynamic
performance views and tables in the database.
 Dynamic Performance Views
Example
• V$CONTROLFILE: Lists the names of control files.
• V$DATABASE:Contains Database information from the control files.
• V$DATAFILE: Contains datafile information from the control file.
• V$INSTANCE: Displays status about the current instance.
• V$PARAMETER: Lists parameter and values currently in effect for the
session.
• V$SESSION: Contains session information for the current session.
• V$SGA: Contains summary information about the SGA.
• V$SPPARAMETER: Lists the contents of the SPFILE.
• V$TABLESPACE: Displays tablespace information from the control
file.
• V$Version: Version number of the core library components in the
Oracle Server.
 Administrative Scripts Naming
Conventions
Convention Description
cat*.sql Catalog and data
dictionary information
Dbms*.sql Database package
specifications.
Utl*.sql Views and tables for
database utilities
 Control File
• Small binary file necessary for the database to start and operate
successfully.
• Each control file is associated with only one Oracle database.
• Before a database is opened, control file is read to determine if the
database is in a valid state to use.
• A control file is continuously updated by the Oracle server when the
database is in use.
• Control files can be modified only by the Oracle server and not by
DBA or end users.
• Database does not function properly is control file is not accessible.
• If all copies of control file is lost, then the database must be recovered
before ir can be opened.
 Control file Contents
• Database name
• Database identifier.
• Timestamp of database creation.
• Names and locations of datafiles and online redo log files.
• Tablespace names
• Redo log History
• Location and status of archived logs.
• Location and status of backups.
• Current log sequence number
• Checkpoint information.
 Sections of Control Files
• A control file consists of two sections:
– Reusable
– Not Reusable
• Reusable sections store Recovery Manager
information such as backup datafile names
and backup redo log file names.
• They are used in a circular manner and can
be reused by the Recovery Manager.
 Multiplexing control files
• To safeguard against failure of a control file,
control files must be multiplexed.
• Each copy of the control file must be stored in a
separate disk.
• If a control file is lost then the multiplexed copy
of the control file can be used to restart the
instance without database recovery.
• Control files can be multiplexed upto eight times.
Methods of multiplexing Control
Files
• Either of the following:
– Creating multiple control files when the
database is created by including the control
names and full path in the CONTROL_FILES.
– Adding the control file after the database has
been created.
 Backing up the control file
• Since, control files records the physical
structure of the database, a backup of the
control file should be taken immediately
after making changes to the physical
structure of the database.
 Multiplexing control files when
using SPFILE
• Alter the SPFILE: Using the ALTER SYSTEM
SET command.
• Shutdown the database.
• Create additional control files: Using the operating
system copy command and verify that the files
have been created in the appropriate directories.
• Start the database: When the database is started the
SPFILE will be read and the Oracle server will
maintain all the control files listed in the
CONTROL_FILES parameter.
 Multiplexing the Control Files
when using PFILE
• Shut down the database.
• Create additional control files.
• Add control file names to PFILE
• Start the database.
 Obtaining Control file
Information
• V$CONTROLFILE: Lists the name and status of
all control files associated with the instance.
• V$PARAMETER: Lists the status and location
of all the parameters.
• V$CONTROLFILE_RECORD_SECTION:
Provides information about the control file record
sections.
• SHOW PARAMETR CONTROL_FILES: Lists
the status and location of the control files.
 Using Redo Log Files
• Redo Log Files have the following
characteristics:
– Records all changes made to data.
– Provide a recovery mechanism
– Can be organized into groups
– At least two groups are required.
 Online Redo Log File Groups
• A set of identical copies of online redo log
files is called an online redo log file group.
• The LGWR background process
continually writes the same information to
all online redo log files in a group.
• The Oracle server needs a minimum of two
online redo log file groups for the normal
operation of the database.
 Online redo log file members
• Each online redo log file in a group is called a
member.
• Each member in a group has identical log
sequence numbers and are of the same size.
• The log sequence number is assigned each time
that the Oracle Server writes to a log group.
• The current log sequence number is stored in the
control file and in the header of all datafiles.
 Creating initial redo log files
• The initial set of online redo log files
groups and members are created during
database creation.
• The following parameters in the CREATE
DATABASE command limits the number
of online redo log files:
– MAXLOGFILES
– MAXLOGMEMBERS
 How Redo log files Work
• Redo Log Files are used in a cyclical
fashion.
• When a redo log file is full, LGWR, will
move to the next log group.
– Called a log switch
– Checkpoint operation also occurs
– Information written to the control file.
 Forcing Log Switches and
Checkpoints
• Forcing a log switch:
ALTER SYSTEM SWITCH LOGFILE;
• Checkpoint can be forced by using:
– Setting FAST_START_MTTR_TARGET
parameter:
FAST_START_MTTR_TARGET = 60
– ALTER SYSTEM CHECKPOINT command
ALTER SYSTEM CHECKPOINT;
 Adding Online Redo Log File
Groups
ALTER DATABASE ADD LOGFILE
GROUP 2
(‘$HOME\ORADATA\u01\log3a.log’,
‘$HOME\ORADATA\u01\log3b.log’)
SIZE 1M;
 Adding Online Redo Log
Members
ALTER DATABASE ADD LOGFILE
MEMBER
‘$HOME\ORADATA\u01\log1c.log’ TO
GROUP 1,
‘$HOME\ORADATA\u01\log2c.log’ TO
GROUP 2,
‘$HOME\ORADATA\u01\log3c.log’ TO
GROUP 3;
Dropping Online Redo Log File
Groups

ALTER DATABASE DROP LOGFILE

GROUP 3;
Dropping Online Redo Log File
Members
ALTER DATABASE DROP LOGFILE
MEMBER
‘$HOME\ORADATA\u04\log3c.log’;
 Relocating or Renaming Online
Redo Log Files
• Relocate or rename online redo log files in one of
the following two ways:
• ALTER DATABASE CLEAR LOGFILE
command
– Copy the online redo log files to the new location.
– Execute the command
ALTER DATABASE CLEAR LOGFILE
‘$HOME\ORADATA\u01\log2a.log’;
• Add new members and drop old members
 Obtaining Group and Member
Information
• Information about a group and its members
can be obtained by querying the following
views:
– V$LOG
– V$LOGFILE
 Archived Redo Log Files
• Filled online redo log files can be archived.
• There are two advantages in running the database in
ARCHIVELOG mode and archiving redo log files:
– Recovery: A database backup together with online and
archived redo log files can guarantee recovery of all
committed transactions.
– Backup: This can be performed while the database is
open.
• By default, the database is created in
NOARCHIVELOG mode.
 More on Archived Redo Log
Files
• Accomplished automatically by ARCn.
• Accomplished manually through SQL statements.
• When successfully archived:
– An entry in the control file is made.
– Records archive log name, log sequence number and high and
low system change number (SCN).
• Filled redo log file cannot be reused until:
– A checkpoint has taken place.
– File has been archived by ARCn.
• Can be multiplexed
• Maintained by DBA
 Managing Tablespaces and
Datafiles
• Oracle stores data logically in Tablespaces and
physically in Datafiles.
• Tablespaces:
– Can belong to only one database at a time.
– Consist of one or more datafiles.
– Are further divided into logical units of storage.
• Datafiles:
– Can belong to only tablespace and one database.
– Are a repository of schema object data,
 Types of Tablespaces
• System Tablespace
– Created with the database
– Contains the data dictionary
– Contains the SYSTEM undo segment
• Non-System tablespace
– Separate segments
– Eases space administration
– Controls amount of space allocated to a user
 Creating Tablespaces
• A tablespace is created by using the
CREATE TABLESPACE command:
CREATE TABLESPACE userdata
DATAFILE ‘/u01/oradata/oradata01.dbf’
SIZE 100M AUTOEXTEND ON NEXT
5M MAXSIZE 200M;
 Space Management in
Tablespaces
• Locally Managed Tablespace:
– Free extents managed in tablespace
– Bitmap is used to record free extents
– Each bit corresponds to a block or group of blocks
– Bit value indicates free or used
• Dictionary-managed tablespace:
– Free extents are managed by the data dictionary
– Appropriate tables are updated when extents are
allocated or deallocated
 Locally Managed Tablespaces
• Reduced contention on data dictionary
tables.
• No undo generated when space allocation
or deallocation occurs.
• No coalescing required
 Dictionary Managed
Tablespaces
• Extents are managed in the data dictionary
• Each segment stored in the tablespace can
have a different storage clause.
• Coalescing required.
 Undo tablespace
• Used to store undo segments
• Cannot contain any other objects.
• Extents are locally managed
• Can only use the DATAFILE and
EXTENT MANAGEMENT clauses
 Temporary Tablespaces
• Used for sort operations
• Cannot contain any permanent objects
• Locally managed extents recommended
Default Temporary Tablespaces
• Specifies a database-wide default
temporary tablespace
• Eliminated using SYSTEM tablespace for
storing temporary data.
• Can be created by using:
– CREATE DATABASE
– ALTER DATABASE
 Restrictions on Default
Temporary Tablespace
• Default Temporary Tablespaces cannot be:
– Dropped until after a new default is made
available
– Taken offline
– Altered to a permanent tablespace
 Read Only Tablespaces
• Use the following command to place a
tablespace in read only mode
ALTER TABLESPACE userdata read only;
• Causes a checkpoint
• Data available only for read operations
• Objects can be dropped from tablespace
 Taking a Tablespace Offline
• Not available for data access
• The Tablespaces that cannot be taken
offline are:
– SYSTEM tablespace
– Tablespaces with active undo segments
– Default Temporary Tablespaces
 Changing Storage Settings
• Storage Settings for a tablespace can be
changed by using the ALTER
TABLESPACE command
• Storage settings for locally managed
tablespace cannot be altered.
 Resizing a Tablespace
• A tablespace can be resized by:
– Changing the size of a datafile
• Automatically using AUTOEXTEND
• Manually using ALTER TABLESPACE
– Adding a datafile using ALTER
TABLESPACE
 Manually Resizing a Datafile
• Manually increase or decrease a datafile
size using ALTER DATABASE
• Resizing a datafile adds more space
without adding more datafiles
• Manual resizing a datafile reclaims space
in database
Adding datafiles to a Tablespace
• Increases the space allocated to a
tablespace by adding additional datafiles.
• ADD DATAFILE clause is used to add a
datafile
 Methods for moving Datafiles
• ALTER TABLESPACE
– Tablespace must be offline
– Target datafiles must exist
• Steps to rename a datafile:
– Take the tablespace offline
– Use an OS command to move or copy the file
– Execute the ALTER TABLESPACE RENAME
DATAFILE command
– Bring the tablespace online
– Use the OS command to delete the file, if necessary.
Methods for moving datafile using the
ALTER DATABASE COMMAND

• ALTER DATABASE
– Database must be mounted
– Target datafile must exist
 Dropping Tablespaces
• Cannot drop a tablespace if it:
– Is the SYSTEM tablespace
– Has active segments
• INCLUDING CONTENTS drops the segments
• INCLUDING CONTENTS AND DATAFILES
deletes datafiles
• CASCADE CONSTARINTS drops all referential
integrity constraints
 Obtaining Tablespace
Information
• Tablespaces
– DBA_TABLESPACES
– V$TABLESPACE
• Datafile information
– DBA_DATA_FILES
– V$DATAFILE
• Temp file information
– DBA_TEMP_FILES
– V$TEMPFILE
 Segments
• Segments are space-occupying objects in a
database.
• They use space in the data files of a
database.
 Types of Segments
• Table
• Table Partition
• Cluster
• Index
• Index-Organized Tables
• Index Partition
• Undo Segment
• Temporary Segment
• LOB Segment
• Nested Table
• Bootstrap Segment
 Extents
• An extent is a chunk of space used by a segment
within a tablespace.
• An extent is allocated when the segment is:
– Created
– Extended
– Altered
• An extent is deallocated when the segment is:
– Dropped
– Altered
– Truncated
 Database Block
• Minimum unit of I/o
• Consists of one or more Operating System
blocks
• Set at tablespace creation
• DB_BLOCK_SIZE is the default block
size.
 Multiple Block Sizing Rules
• All partitions of a partitioned object must reside
in tablespaces of the same block size.
• All temporary tablespaces must be of the
standard block-size.
• Index-organized table overflow and out-of-line
LOB segments can be stored in a tablespace with
a block size different from the base table.
 Standard Block Size
• Set at database creation using the
DB_BLOCK_SIZE parameter.
• Cannot be altered.
• Used for SYSTEM and TEMPORARY
tablespaces.
• DB_CACHE_SIZE specifies the size of the
DEFAULT buffer cache for standard block size:
– Minimum size = one granule (4 MB or 16 MB)
– Default value = 48 MB
 Nonstandard Block Size
• Configure additional caches with the following
dynamic parameters:
– DB_2k_CACHE_SIZE for 2 KB blocks
– DB_4k_CACHE_SIZE for 4 KB blocks
– DB_8k_CACHE_SIZE for 4 KB blocks
– DB_16k_CACHE_SIZE for 16 KB blocks
– DB_32k_CACHE_SIZE for 32 KB blocks
• DB_nK_CACHE_SIZE is not allowed if nK is the
standard block size.
• Minimum size for each cache: one granule
 Creating Nonstandard Block
Size Tablespace
CREATE TABLESPACE tbs_1
DATAFILE ‘tbs_1.dbf’
SIZE 10M BLOCKSIZE 4k
 Multiple Block Size Support
• A database can be created with a standard
block size and up to four non-standard
block sizes.
• Block sizes can have any power-of-two
value between 2 KB and 32 KB.
 Database Block Contents
• Block Header
• Data space
• Free Space
 Block Utilization Parameters
• INITRANS
• MAXTRANS
• PCTFREE
• PCTUSED
 Data Block Management
• Automatic Segment-Space Management
• Manual Management
 Automatic Segment-Space
Management
• It is a method of managing free space inside database
segments
• Tracking in-segment free space and used space in done
using bitmaps as opposed to using free lists.
• This method provides:
– Ease of management
– Better space utilization
– Better performance for concurrent INSERT operations.
• Restriction: Cannot be used for tablespaces that will
contain LOBs
 Automatic Segment-Space
Management
• Bitmap segments contain a bitmap that describes
the status of each block in the segment with
respect to its available space.
• The map is contained in a separate set of blocks
referred to as bitmapped blocks (BMBs).
• When inserting a new row, the server searches
the map for block with sufficient space.
• As the amount of space available in a block
changes, its new state is reflected in the bitmaps.
 Configuring Automatic
Segment-space Management
• Automatic segment-space management can be
enabled at the tablespace level only, for locally
managed tablespaces.
CREATE TABLESPACE data02
DATAFILE ‘data02.dbf’ SIZE 5m
EXTENT MANAGEMENT LOCAL UNIFORM
SIZE 64k
SEGMENT SPACE MANAGEMENT AUTO
• After a tablespace is created, the specifications apply
to all segments created in the tablespace.
 Manual Data Block
Management
• Enables configuration of data blocks
manually using parameters such as:
– PCTFREE
– PCTUSED
– FREELIS
• Only method available in previous Oracle
versions.
 Obtaining Storage Information
• Information about storage can be obtained
by querying the following views:
– DBA_EXTENTS
– DBA_SEGMENTS
– DBA_TABLESPACES
– DBA_DATA_FILES
– DBA_FREE_SPACE
 Managing Undo Data
• There are two methods of managing undo
data:
– Automatic Undo Management
– Manual Undo Management
• The term undo was known as rollback in
previous versions.
 Undo Segment
• An undo segment is used to save the old value
when a process changes the data in the database.
• The header of an undo segment contains a
transaction table where information about the
current transactions using the undo segment is
stored.
• A serial transaction uses only one undo segment to
store all of its undo data.
• Many concurrent transactions can write to one
undo segment.
 Purposes of Undo Segment
• Transaction Rollback
• Transaction Recovery
• Read Consistency
 Types of Undo Segments
• SYSTEM: Used for object in the SYSYEM
tablespace
• Non-SYSTEM: Used for objects in other
tablespaces.
– Auto Mode:Requires an UNDO tablespace
– Manual Mode:
• Private: Acquired by a single instance
• Public: Acquired by any instance
– Deferred: Used when tablespaces are taken offline.
 Automatic Undo Management
Concepts
• Undo data managed using an UNDO
tablespace.
• One UNDO tablespace per instance is
allocated with enough space for the
workload of the instance.
• The Oracle server automatically maintains
undo data within the UNDO tablespace.
 Configuration of Automatic
Undo Management
• Configure two parameters in the
initialization file:
– UNDO_MANAGEMENT
– UNDO_TABLESPACE
• Create at least one UNDO tablespace
 Automatic Undo Management
Initialization Parameters
• UNDO_MANAGEMENT: Specifies
whether the system should use AUTO or
MANUAL mode
• UNDO_TABLESPACE: Specifies a
particular UNDO tablespace to be used.
 Altering an UNDO tablespace
• The ALTER TABLESPACE command
can make changes to UNDO tablespaces.
 Switching UNDO tablespace
• It is possible to switch from one UNDO
tablespace to another.
• Only one UNDO tablespace can be assigned to a
database at a time.
• More that one UNDO tablespace may exist
within an instance, but only one can be active.
• ALTER SYSTEM SET UNDO_TABLESPACE
= UNDOTBS2;
Dropping an UNDO Tablespace
• DROP TABLESPACE UNDOTBS2;
• An UNDO tablespace can only be dropped
if it is currently not in use by any instance.
• To drop an active UNDO tablespace:
– Switch to a new UNDO tablespace
– Drop the tablespace after all current
transactions are complete.
 Other UNDO Management
Parameters
• UNDO_SUPPRESS_ERRORS
• UNDO_RETENTION
 Sizing an UNDO tablespace
• Undospace = [UR * (UPS * DBS)] +
(DBS * 24)
– (UR) UNDO_RETENTION in seconds
– (UPS) Number of undo data blocks generated
per second
– (DBS) Overhead based on extent and file size
(db_block_size)
 Undo Quota
• Long transactions and improperly written transactions
can consume variable resources.
• With undo quota, users can be grouped and a maximum
undo space limit can be assigned to the group.
• UNDO_POOL, a Resource Managed Directive, defines
the amount of space allowed for a resource group.
• When a group exceeds its limit, no new transactions are
possible for the group, until undo space is freed by
current transactions which are either completing or
aborting.
 Obtaining Undo Segment
Information
• Information about undo segments can be
obtained by querying the following views:
– DBA_ROLLBACK_SEGS
• Dynamic Performance Views:
– V$ROLLNAME
– V$ROLLSTAT
– V$UNDOSTAT
– V$SESSION
– V$TRANSACTION
 Storing User Data
• There are several methods of storing user
data in an Oracle database:
– Regular Tables
– Partitioned Tables
– Index-Organized Tables
– Clustered Tables
 ROWID Format
• Extended ROWID Format:
– 000000: Data Object Number
– FFF: Relative File Number
– BBBBBB: Block Number
– RRR: Row Number
• Restricted ROWID Format:
– BBBBBBBB: Block Number
– RRRR: Row Number
– FFFF: File Number
 Structure of a Row
• Row Header
• Row Data
 Guidelines for Creating a Table
• Place tables in separate tablespaces.
• Use locally-managed tablespaces to avoid
fragmentation.
• Use few standard extent sizes for tables to
reduce tablespace fragmentation.
 Creating Temporary Tables
• Created using the GLOBAL Temporary
clause
• Tables retain data only for the duration of a
transaction or session.
• DML locks are not acquired on the data.
• Can create indexes, views, and triggers on
temporary tables.
 Setting PCTFREE and
PCTUSED
• Compute PCTFREE:
(Average Row Size – Initial Row Size) *
100/Average Row Size
• Compute PCTUSED:
100 – PCTFREE- Average Row Size *
100/Available Data Space
 Changing Storage and Block
Utilization Parameters
ALTER TABLE hr.employees
PCTFREE 30
PCTUSED 50
STORAGE (NEXT 50K MINEXTENT 2
MAXEXTENTS 100);
 Manually Allocating Extents
ALTER TABLE hr.EMPLOYEES
ALLOCATE EXTENT (SIZE 500k
DATAFILE ‘d:\oradata\DATA01.DBF’);
 Nonpartitioned Table
Reorganization
• When a nonpartitioned table is
reorganized, its structure is kept, but not its
contents.
• Used to move a table to a different
tablespace or reorganize extents.
ALTER TABLE hr.EMPLOYEES
MOVE TABLESPACE data1;
 Truncating a Table
• Truncating a table deletes all rows in a
table and releases used space.
• Corresponding indexes are truncated.
• TRUNCATE TABLE hr.employees;
 Dropping a Table
DROP TABLE hr.DEPARTMENT
CASCADE CONSTRAINTS;
 Dropping a Column
• Removing a column from a table:
ALTER TABLE hr.employees
DROP COLUMN comments
CASCADE CONSTRAINTS
• Removes the column length and data from
each row, freeing space in the data block.
• Dropping a column in a large table takes a
considerable amount of time.
 Using the Unused Option
• Mark the column as unused:
ALTER TABLE hr.employees
SET UNUSED COLUMN comments CASCADE
CONSTRAINTS
• Drop unused columns:
ALTER TABLE hr.employees
DROP UNUSED COLUMNS CHECKPOINT 1000;
• Continue to drop column operation:
ALTER TABLE hr.employees
DROP COLUMNS CONTINUE CHECKPOINT 1000;
 Obtaining Table Information
• DBA_TABLES
• DBA_OBJECTS
 Classification of Indexes
• Logical
– Single column or concatenated
– Unique or non-unique
– Function-based
– Domain
• Physical
– Partitioned or non-partitioned
– B-Tree
• Normal or reverse key
– Bitmap
 Comparing B-Tree and Bitmap
Indexes
• B-Tree • Bitmap
– Suitable for high- – Suitable for low-
cardinality columns cardinality columns
– Updates on keys – Updates to key
relatively inexpensive columns very
– Inefficient for queries expensive
using OR predicate – Efficient for queries
– Useful for OLTP using OR predicate
– Useful for Data
Warehousing
Creating Normal B-Tree Indexes
CREATE INDEX hr.employees_last_name_idx
ON hr.employees (last_name)
PCTFREE 30
STORAGE
(INITIAL 200K NEXT 200K PCTINCREASE 0
MAXEXTENTS 50)
TABLESPACE indx
 Guidelines for creating Indexes
• Balance query and DML needs
• Place in separate tablespace
• Use uniform extent sizes
• Consider NOLOGGING for large indexes
• INITRANS should generally be higher on
indexes than on the corresponding tables.
 Creating Bitmap Indexes
CREATE BITMAP INDEX
orders_region_id_idx
ON orders (region_id)
PCTFREE 30
STORAGE (INITIAL 200k NEXT 200k
PCTINCREASE 0 MAXEXTENTS 50)
TABLESPACE indx;
Changing storage parameters for
Indexes
ALTER INDEX employees_last_name_idx
STORAGE (NEXT 400k
MAXEXTENTS 100);
 Allocating and Deallocating
Index Space
• Allocating Index Space
ALLOCATE INDEX region_id_idx
ALLOCATE EXTENT (SIZE 200K
DATAFILE ‘index01.dbf’);
• Deallocating Index Space
ALTER INDEX orders_id_idx
DEALLOCATE UNUSED;
 Rebuilding Indexes
• Use the ALTER INDEX command to:
– Move an index to a different tablespace
– Improves space utilization by removing
deleted entries
ALTER INDEX orders_region_id_idx
REBUILD TABLESPACE indx02;
 Rebuilding Indexes Online
• Indexes can be rebuilt with minimal table
locking.
ALTER INDEX orders_id_idx REBUILD
ONLINE;
• Restrictions
– It is not possible to rebuild an index on a
temporary table.
– An entire partitioned index cannot be rebuilt.
 Coalescing Indexes
ALTER INDEX orders_id_idx COALESCE;
 Checking Indexes and Their
Validity
ALTER INDEX orders_region_id_idx
VALIDATE STRUCTURE;
 Dropping Indexes
• Drop and recreate index before bulk loads.
• Drop indexes that are infrequently needed
and build them when necessary.
• Drop and recreate invalid indexes.
DROP INDEX hr.departments_name_idx;
 Identifying Unused Indexes
• To start monitoring the usage of an index:
ALTER INDEX hr.DEPT_ID_IDX
MONITORING USAGE;
• To stop monitoring the usage of an index:
ALTER INDEX hr.DEPT_ID_IDX
NOMONITORING USAGE;
 Obtaining Index Information
• DBA_INDEXES
• DBA_IND_COLUMNS
• V$OBJECT_USAGE
 Types of Constraints
• NOT NULL
• UNIQUE
• PRIMARY KEY
• FOREIGN KEY
• CHECK
 Constraint States
• DISABLE NOVALIDATE
• DISABLE VALIDATE
• ENABLE NOVALIDATE
• ENABLE VALIDATE
 Constraint Checking
• Nondeffered or immediate constraints:
Enforced at the end of every DML
statement.
• Deferred constraints: Checked only when
the transaction is committed.
 Defining Constraints
• Using the SET CONSTRAINTS statement.
• Using the ALTER SESSION statement.
 Foreign Key Considerations
Desired Action Appropriate Solution

Drop Parent Table Cascade Constraints

Truncate Parent table Use the CASCADE

CONSTRAINTS clause
Perform DML on child Ensure that the
table tablespace containing the
parent key is online.
 Guidelines for Defining
Constraints
• Primary and unique Constraints:
– Place indexes in a separate tablespace
– Use nonunique indexes if bulk loads are
frequent.
• Self-referencing foreign keys:
– Define or enable foreign keys after the initial
load
– Defer constraint checking
 Enabling Constraints –
ENABLE NOVALIDATE
• No locks on table
• Primary and unique keys must use
nonunique indexes.
 Enabling Constraints –
ENABLE VALIDATE
• Locks the table
• Can use unique or nonunique indexes
• Needs valid table data.
 Using the Exceptions Table
• Create the Exceptions table by running the
utlexcptl.sql script
• Execute the ALTER TABLE statement
with the EXCEPTIONS option.
• Use subquery on EXCEPTIONS to locate
rows with invalid data.
• Reexecute ALTER TABLE to enable the
constraint.
 Obtaining Constraint
Information
• DBA_CONSTRAINTS
• DBA_CONS_COLUMNS
 Profiles
• A profile is a named set of password and
resource limits.
• Profiles are assigned to users by the
CREATE USER or ALTER USER
command.
• Profiles can be enabled or disabled.
Enabling password Management
• Set up password management by using
profiles and assigning them to users.
• Lock, unlock and expire accounts using the
CREATE USER or ALTER USER
command.
• Password limits are always enforced.
• To enable password management, run the
utlpwdmg.sql as user SYS.
 Password Account Locking
Parameter Description

FAILED_LOGIN_ATTEMPTS Number of failed login

attempts before lockout of
account.

PASSWORD_LOCK_TIME Number of days the

account is locked after the
specified number of failed
login attempts
Password Expiration and Aging
Parameter Description

PASSWORD_LIFE_TIME Lifetime of the password

in days after which the
password expires.

PASSWORD_GRACE_TIME Grace period in days for

changing the password
after the first successful
after the password has
expired
 Password History
Parameter Description

PASSWORD_REUSE_T Number of days before a

IME password can be reused

PASSWORD_REUSE_ Maximum number of

MAX times a password can be
reused
 Password Verification
Parameter Description

PASSWORD_VERIFY_ PL/SQL function that

FUNCTION performs a password
complexity check before
a password is assigned
Password Verification Function:
VERIFY_FUNCTION
• Minimum length is four characters
• Password should not be equal to username
• Password should have at least one
alphabetic, one numeric, and one special
character.
• Password should differ from the previous
password by at least three letters.
 Creating a Profile: Password
Settings
CREATE PROFILE grace_5 LIMIT
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_LIFE_TIME 30
PASSWORD_REUSE_TIME 30
PASSWORD_VERIFY_FUNCTION
verify_function
PASSWORD_GRACE_TIME 5;
 Altering a Profile: Password
Settings
ALTER PROFILE default LIMIT
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LIFE_TIME 60
PASSWORD_GRACE_TIME 10;
 Dropping a Profile: Password
Settings
• Drop the profile using the DROP
PROFILE command.
• DEFAULT profile cannot be dropped.
• CASCADE revokes the profile from user
to whom assigned.
• DROP PROFILE developer_prof;
• DROP PROFILE developer_prof
CASCADE;
 Resource Management
• Resource Management limits can be
enforced at the session level, the call level,
or both.
• Limits can be defined by profiles using the
CREATE PROFILE command.
• Enable resource limits with the:
– RESOURCE_LIMIT initialization parameter.
– ALTER SYSTEM command
 Enabling Resource Limits
• Set the initialization parameter
RESOURCE_LIMIT to TRUE.
• Enforce the resource limits by enabling the
parameter with the ALTER SYSTEM
command.
• ALTER SYSTEM SET
RESOURCE_LIMIT = TRUE;
 Setting Resource Limits at
Session Levels
Resource Description

CPU_PER_SESSION Total CPU time measured in

hundredths of seconds.
SESSIONS_PER_USER Number of concurrent sessions

CONNECT_TIME Elapsed connect time measured

in seconds.
IDLE_TIME Periods of inactive time
measured in minutes.

LOGICAL_READS_PER_ Number of data blocks (physical

and logical reads)
SESSION
 Setting Resource Limits at
Session Levels
Resource Description

PRIVATE_SGA Private space in the SGA measured

in bytes (for Shared Sever only)
CPU_PER_CALL CPU time per call in hundredths of
seconds
LOGICAL_READS_PER_ Number of data blocks that can be
read per call
CALL
 Creating a Profile: Resource
Limit
CREATE PROFILE developer_prof LIMIT
SESSIONS_PER_USER 2
CPU_PER_SESSION 10000
IDLE_TIME 60
CONNECT_TIME 480;
 Measuring Resources Using the
Database Resource manager
• Provides the Oracle server with more control over
resource management decisions.
• Elements of the Database Resource Manager:
– Resource consumer group
– Resource plan
– Resource allocation method
– Resource plan directives
– Uses the DBMS_RESOURCE_MANAGER package to create
and maintain elements.
• Requires ADMINISTER_RESOURCE_MANAGER
privilege.
 Managing Resources Using the
Database Resource Manager
• Resource plans specify the resource
consumer groups belonging to the plan.
• Resource plans contains directives for how
resources are to be collected among
consumer groups.
 Resource Plan Directives
• The Database Resource Manager provides
several means of allocating resources:
– CPU method
– Active session pool and queuing
– Degree of parallelism unit
– Automatic consumer group switching
– Maximum estimated execution time.
– Undo quota
 Obtaining Password and
Resource Limit Information
• DBA_USERS
• DBA_PROFILES