Module 1 – Oracle Architecture

Primary Architecture Components

The figure shown above details the Oracle architecture.

Oracle server: An Oracle server includes an Oracle Instance and an Oracle database.  An Oracle database includes several different types of files: datafiles, control files, redo log files and archive redo log files. The Oracle server also accesses parameter files and password files. This set of files has several purposes. o One is to enable system users to process SQL statements. o Another is to improve system performance. o Still another is to ensure the database can be recovered if there is a software/hardware failure.    The database server must manage large amounts of data in a multi-user environment. The server must manage concurrent access to the same data. The server must deliver high performance. This generally means fast response times.

Oracle instance: An Oracle Instance consists of two different sets of components:  The first component set is the set of background processes (PMON, SMON, RECO, DBW0, LGWR, CKPT, D000 and others). o These will be covered later in detail – each background process is a computer program. o These processes perform input/output and monitor other Oracle processes to provide good performance and database reliability.  The second component set includes the memory structures that comprise the Oracle instance. o When an instance starts up, a memory structure called the System Global Area (SGA) is allocated.

o At this point the background processes also start.  An Oracle Instance provides access to one and only one Oracle database.

Oracle database: An Oracle database consists of files.  Sometimes these are referred to as operating system files, but they are actually database files that store the database information that a firm or organization needs in order to operate. The redo log files are used to recover the database in the event of application program failures, instance failures and other minor failures. The archived redo log files are used to recover the database if a disk fails. Other files not shown in the figure include: o The required parameter file that is used to specify parameters for configuring an Oracle instance when it starts up. o The optional password file authenticates special users of the database – these are termed privileged users and include database administrators. o Alert and Trace Log Files – these files store information about errors and actions taken that affect the configuration of the database.

  

User and server processes: The processes shown in the figure are called user and server processes. These processes are used to manage the execution of SQL statements.   A Shared Server Process can share memory and variable processing for multiple user processes. A Dedicated Server Process manages memory and variables for a single user process.

This figure from the Oracle Database Administration Guide provides another way of viewing the SGA.

Connecting to an Oracle Instance – Creating a Session

System users can connect to an Oracle database through SQLPlus or through an application program like the Internet Developer Suite (the program becomes the system user). This connection enables users to execute SQL statements.

The act of connecting creates a communication pathway between a user process and an Oracle Server. As is shown in the figure above, the User Process communicates with the Oracle Server through a Server Process. The User Process executes on the client computer. The Server Process executes on the server computer, and actually executes SQL statements submitted by the system user.

The figure shows a one-to-one correspondence between the User and Server Processes. This is called a Dedicated Server connection. An alternative configuration is to use a Shared Server where more than one User Process shares a Server Process.

Sessions: When a user connects to an Oracle server, this is termed a session. The User Global Area is session memory and these memory structures are described later in this document. The session starts when the Oracle server validates the user for connection. The session ends when the user logs out (disconnects) or if the connection terminates abnormally (network failure or client computer failure). A user can typically have more than one concurrent session, e.g., the user may connect using SQLPlus and also connect using Internet Developer Suite tools at the same time. The limit of concurrent session connections is controlled by the DBA. If a system users attempts to connect and the Oracle Server is not running, the system user receives the Oracle Not Available error message.

Physical Structure – Database Files
As was noted above, an Oracle database consists of physical files. The database itself has:    Datafiles – these contain the organization's actual data. Redo log files – these contain a chronological record of changes made to the database, and enable recovery when failures occur. Control files – these are used to synchronize all database activities and are covered in more detail in a later module.

  Password file – specifies which *special* users are authenticated to startup/shut down an Oracle Instance. some parameters will specify how to allocate memory to the various parts of the system global area.ora is a dynamic parameter file. transaction-processing environment in the event of a disk failure. It contains parameters that specify how the database instance is to start up. . For example. however.ora file (also called the PFILE) is a static parameter file.Other key files as noted above include:  Parameter file – there are two types of parameter files. its parameters can be modified while the database is running. It also stores parameters to specify how to startup a database. Archived redo log files – these are copies of the redo log files and are necessary for recovery in an online. o The init. o The spfile.

The SGA has the following mandatory memory structures:      Database Buffer Cache Redo Log Buffer Java Pool Streams Pool Shared Pool – includes two components: o Library Cache . o The SGA is allocated in memory and virtual memory. System Global Area The SGA is a read/write memory area that stores information shared by all database processes and by all users of the database (sometimes it is called the Shared Global Area). o The size of the SGA can be established by a DBA by assigning a value to the parameter SGA_MAX_SIZE in the parameter file—this is an optional parameter. o This information includes both organizational data and control information used by the Oracle Server. The SGA is allocated when an Oracle instance (database) is started up based on values specified in the initialization parameter file (either PFILE or SPFILE). User Global Area (UGA) – this is allocated when a user connects to create a session. Program Global Area (PGA) – this is allocated when a Server Process starts up.Memory Structure The memory structures include three areas of memory:    System Global Area (SGA) – this is allocated when an Oracle Instance starts up.

This meant that if modifications to memory management were required. modifications were made to the init. and then the database had to be restarted.o Data Dictionary Cache  Other structures (for example. In order to execute SHOW SGA you must be connected with the special privilege SYSDBA (which is only available to user accounts that are members of the DBA Linux group). The advantage is obvious. the database had to be shutdown. statistical data) Additional optional memory structures in the SGA include:  Large Pool The SHOW SGA SQL command will show you the SGA memory allocations. This allows the DBA to resize the Database Buffer Cache and Shared Pool dynamically. SQL> show sga Total System Global Area 1610612736 bytes Fixed Size Variable Size Database Buffers Redo Buffers 2084296 bytes 1006633528 bytes 587202560 bytes 14692352 bytes Early versions of Oracle used a Static SGA. Memory configurations for the system global area can be made without shutting down the database instance. . and 11g use a Dynamic SGA. This is a recent clip of the SGA for the DBORCL database at SIUE.ora parameter file. Oracle 9i. lock and latch management. SQL> connect / as sysdba Connected. 10g.

which as was noted above. LOG_BUFFER: This optional parameter specifies the number of bytes allocated for the Redo Log Buffer. SHARED_POOL_SIZE. either explicitly in the parameter file or by default. LARGE_POOL_SIZE. . Block sizes vary among operating systems. and JAVA_POOL_SIZE. each granule is 4 MB. Granule size depends on the estimated total size of the SGA. The total blocks in the cache defaults to 48 MB on LINUX/UNIX and 52 MB on Windows operating systems. LARGE_POOL_SIZE: This is an optional memory object – the size of the Large Pool defaults to zero. The default is 16 MB. Memory is allocated to the SGA as contiguous virtual memory in units termed granules. at the time the instance is initialized. DB_CACHE_SIZE. if the value for SGA_MAX_SIZE in the initialization parameter file or server parameter file is less than the sum the memory allocated for all components. then the database ignores the setting for SGA_MAX_SIZE. the entire SGA should fit in real memory to eliminate paging to/from disk by the operating system. depends on the SGA_MAX_SIZE parameter. then the default size is automatically calculated. For optimal performance. SHARED_POOL_SIZE: This optional parameter specifies the number of bytes of memory allocated to shared SQL and PL/SQL.      The size of the SGA cannot exceed the parameter SGA_MAX_SIZE minus the combination of the size of the additional parameters. DB_CACHE_SIZE: This optional parameter is used to tune the amount memory allocated to the Database Buffer Cache in standard database blocks. The DBORCL database uses 8 KB blocks. LOG_BUFFER. If the operating system is based on a 64 bit configuration. JAVA_POOL_SIZE: This is another optional memory object.ora parameter PARALLEL_AUTOMATIC_TUNING is set to TRUE. These are:  SGA_MAX_SIZE: This optional parameter is used to set a limit on the amount of virtual memory allocated to the SGA – a typical setting might be 1 GB. however. If the init. then the default size is 64 MB. The default is 24 MB of memory.Several initialization parameters are set that affect the amount of random access memory dedicated to the SGA of an Oracle Instance. Granules are sized as follows:  If the SGA is less than 1 GB in total.

Database Buffer Cache. prev_size.----------DEFAULT 71244 8192 560 576 Program Global Area . each granule is 16 MB. The SELECT statement shown below shows a current_size of 1. and Shared Pool. Using contiguous memory improves system performance. and these memory components can dynamically grow and shrink. If the SGA is greater than 1 GB in total. Java Pool. you'll find the SGA is allocated much more memory than this. SELECT name. current_size. and other memory structures.---------. In practice. block_size. prev_buffers FROM v$buffer_pool. Granules are assigned to the Database Buffer Cache. The minimum is 3 granules: one each for the fixed SGA.152 granules. NAME PREV_BUFFERS BLOCK_SIZE CURRENT_SIZE PREV_SIZE -------------------.---------. Shared Pool. The actual number of granules assigned to one of these memory components can be determined by querying the database view named V$BUFFER_POOL. Granules are allocated when the Oracle server starts a database instance in order to provide memory addressing space to meet the SGA_MAX_SIZE parameter.-----------.

.The Program Global Area is also termed the Process Global Area (PGA) and is a part of memory allocated that is outside of the Oracle Instance.

The content of the PGA varies. and bitmap create types of operations. A user session issuing SQL statements has a Private SQL Area that may be associated with a Shared SQL Area if the same SQL statement is being executed by more than one system user. o Shared Server environment – the Private SQL Area is located in the System Global Area. bitmap merge. . This often happens in OLTP environments where many users are executing and using the same application program. It is allocated when a process is created and the memory is scavenge by the operating system when the process terminates.  SQL Work Areas: Memory allocated for sort. generally includes the following:  Private SQL Area: Stores information for a parsed SQL statement – stores bind variable values and runtime memory allocations. o Dedicated Server environment – the Private SQL Area is located in the Program Global Area.  Session Memory: Memory that holds session variables and other session information. but as shown in the figure above. This is NOT a shared part of memory – one PGA to each process only. hash-join.  It stores data and control information for a single Server Process or a single Background Process.

A session that loads a PL/SQL package into memory has the package state stored to the UGA. package variables are unique to and persist for the life of the session. The page pool is allocated at the start of an OLAP session and released at the end of the session. The state changes as program code the variables. By default. However. Note: Oracle OLAP is a multidimensional analytic engine embedded in Oracle Database 11g. Oracle OLAP cubes deliver sophisticated . the DBA can let the Oracle DBMS determine the appropriate amount of memory. User Global Area The User Global Area is session memory. An OLAP session opens automatically whenever a user queries a dimensional object such as a cube. which are equivalent to data blocks.o Oracle 9i and later versions enable automatic sizing of the SQL Work Areas by setting the WORKAREA_SIZE_POLICY = AUTO parameter (this is the default!) and PGA_AGGREGATE_TARGET = n (where n is some amount of memory established by the DBA). This pool manages OLAP data pages. The package state is the set of values stored in all the package variables at a specific time. The OLAP page pool is also stored in the UGA.

The Oracle Database automatically distributes this memory among various subcomponents to ensure most effective memory utilization. DB_CACHE_SIZE.calculations using simple SQL queries . Setting a single parameter simplifies the administration task – the DBA only specifies the amount of SGA memory available to an instance – the DBA can forget about the sizes of individual components. Automatic Shared Memory Management enables a DBA to specify the total SGA memory available through the SGA_TARGET initialization parameter. a DBA had to manually specify SGA Component sizes through the initialization parameters. and LARGE_POOL_SIZE parameters. the different SGA components are flexibly sized to adapt to the SGA available. No out of memory errors are generated unless the system has actually run out of memory.producing results with speed of thought response times. The DBORCL database SGA_TARGET is set in the initDBORCL. the UGA cannot be stored in the PGA when using a shared server connection because PGA is specific to a single process. The UGA must be available to a database session for the life of the session. JAVA_POOL_SIZE. For this reason. The SGA_TARGET initialization parameter reflects the total size of the SGA and includes memory for the following components:   Fixed SGA and other internal allocations needed by the Oracle Database instance The log buffer . When using a dedicated server connection. Therefore. such as SHARED_POOL_SIZE. the UGA is stored in the SGA when using shared server connections. enabling any shared server process access to it. No manual tuning effort is needed. Automatic Shared Memory Management Prior to Oracle 10G. the UGA is stored in the PGA.ora file: sga_target=1610612736 With automatic SGA memory management.

--Fixed SGA Size 2084296 No . n = {2. 32}) Streams Pool (controlled by the new parameter STREAMS_POOL_SIZE) The granule size that is currently being used for the SGA for each component can be viewed in the view V$SGAINFO. if they are needed by an application. 4.. then the SGA_MAX_SIZE value is bumped up to accommodate SGA_TARGET.---------. NAME BYTES RES -------------------------------. Oracle Database 10g automatically sizes the most commonly configured components. SQL> select * from v$sgainfo. including:     The shared pool (for SQL and PL/SQL execution) The Java pool (for Java execution state) The large pool (for large allocations such as RMAN backup buffers) The buffer cache There are a few SGA components whose sizes are not automatically adjusted. More. Such components are:    Keep/Recycle buffer caches (controlled by DB_KEEP_CACHE_SIZE and DB_RECYCLE_CACHE_SIZE) Additional buffer caches for non-standard block sizes (controlled by DB_nK_CACHE_SIZE.      The shared pool The Java pool The buffer cache The keep and recycle buffer caches (if specified) Nonstandard block size buffer caches (if specified) The Streams Pool If SGA_TARGET is set to a value greater than SGA_MAX_SIZE at startup. 8. 16. When you set a value for SGA_TARGET. The DBA must specify the sizes of these components explicitly.. The size of each component and the time and type of the last resize operation performed on each component can be viewed in the view V$SGA_DYNAMIC_COMPONENTS.

14692352 No 587202560 Yes 956301312 Yes 16777216 Yes 33554432 Yes93 0 Yes 16777216 No 1610612736 No 67108864 No 0 Shared Pool .Redo Buffers Buffer Cache Size Shared Pool Size Large Pool Size Java Pool Size Streams Pool Size Granule Size Maximum SGA Size Startup overhead in Shared Pool Free SGA Memory Available 11 rows selected.

For example. if a user executes a SQL statement. and data dictionary information.The Shared Pool is a memory structure that is shared by all system users. . The variable component grows and shrinks depending on the demands placed on memory size by system users and application programs. then Oracle Database accesses the shared pool. For example. Memory can be allocated to the Shared Pool by the parameter SHARED_POOL_SIZE in the parameter file. system parameters.     It caches various types of program data. the shared pool stores parsed SQL. It consists of both fixed and variable structures. Increasing the value of this parameter increases the amount of memory reserved for the shared pool. The shared pool is involved in almost every operation that occurs in the database. PL/SQL code. The default value of this parameter is 8MB on 32-bit platforms and 64MB on 64bit platforms.

o This figure depicts two different client processes issuing the same SQL statement – the parsed solution is already in the Shared SQL Area. It is recommended to let Oracle optimize the Shared Pool size. Private SQL Area: With a shared server. Actual management of this memory structure is through a Least-Recently-Used (LRU) algorithm. If a system user executes an identical statement. o Each user that submits the same statement has a private SQL area pointing to the same shared SQL area. the Library Cache must purge statement definitions in order to have space to load new SQL and PL/SQL statements. The Shared Pool stores the most recently executed SQL statements and used data definitions.You can alter the size of the shared pool dynamically with the ALTER SYSTEM SET command. each session issuing a SQL statement has a private SQL area in its PGA. This enables storage of the most recently used SQL and PL/SQL statements. o Many private SQL areas in separate PGAs can be associated with the same shared SQL area. This means that the SQL and PL/SQL statements that are oldest and least recently used are purged when more storage space is needed.  . The Library Cache is composed of two memory subcomponents:  Shared SQL: This stores/shares the execution plan and parse tree for SQL statements. You must keep in mind that the total memory allocated to the SGA is set by the SGA_TARGET parameter (and may also be limited by the SGA_MAX_SIZE if it is set). The Shared Pool includes several cache areas described below. This is because some system users and application programs will tend to execute the same SQL statements often. Saving this information in memory can improve system performance. as well as PL/SQL statements such as functions. then the statement does not have to be parsed again in order to execute the statement. If the Library Cache is too small. packages. Library Cache Memory is allocated to the Library Cache whenever an SQL statement is parsed or a program unit is called. and triggers. you cannot exceed the maximum size of the SGA. An example command is shown in the figure below. and since the Shared Pool is part of the SGA.

Information accessed includes user account information. datafile names.Data Dictionary Cache The Data Dictionary Cache is a memory structure that caches data dictionary information that has been recently used. and other information.   This cache is necessary because the data dictionary is accessed so often. table descriptions. . user privileges.

If the size is too small. then the database returns them immediately. Buffer Caches A number of buffer caches are maintained in memory in order to improve system response time.The database server manages the size of the Data Dictionary Cache internally and the size depends on the size of the Shared Pool in which the Data Dictionary Cache resides. For example.  PL/SQL function code can specify that results be cached.  With caching. . In this way.    Using the cache results for future queries tends to improve performance. The server result cache contains the SQL query result cache and PL/SQL function result cache. If the results are cached. PL/SQL Function Result Cache The PL/SQL Function Result Cache stores function result sets. the database avoids the expensive operation of rereading blocks and recomputing results. Server Result Cache The Server Result Cache holds result sets and not data blocks. which share the same infrastructure. SQL Query Result Cache This cache stores the results of queries and query fragments. suppose an application runs the same SELECT statement repeatedly.  Without caching. then the data dictionary tables that reside on disk must be queried often for information and this will slow down performance. 1000 calls of a function at 1 second per call would take 1000 seconds. 1000 function calls with the same inputs could take 1 second total.  Good candidates for result caching are frequently invoked functions that depend on relatively static data.

If the information is not in the Database Buffer Cache. Pinned buffers are currently being accessed. because a database block is the smallest addressable storage space on disk. Free buffers do not contain any useful data and are available for use. Before reading a data block into the cache. When an Oracle process accesses a buffer. the process must first find a free buffer. Keep in mind that information read from disk is read a block at a time. the Server Process retrieves the information from disk and stores it to the cache. pinned buffers. and dirty buffers that have not yet been moved to the write list. otherwise a cache miss occurs and data must be read from hard disk into the database buffer cache. the process reads the data from memory. the process moves the buffer to the most recently used (MRU) end of the LRU list – this causes dirty buffers to age toward the LRU end of the LRU list. . not a row at a time. The process searches the LRU list. Database blocks are kept in the Database Buffer Cache according to a Least Recently Used (LRU) algorithm and are aged out of memory if a buffer cache block is not used in order to provide space for the insertion of newly needed database blocks. The LRU list holds free buffers. the least recently used (LRU) list. The buffers in the cache are organized in two lists:   the write list and. The search continues until a free buffer is found or until the search reaches the threshold limit of buffers. The write list holds dirty buffers – these are buffers that hold that data that has been modified. If the data row is already in the cache (a cache hit). it searches for the data in the database buffer cache because memory can be searched more quickly than hard disk can be accessed. A query causes a Server Process to first look in the Database Buffer Cache to determine if the requested information happens to already be located in memory – thus the information would not need to be retrieved from disk and this would speed up performance. starting at the LRU end of the list. but the blocks have not been written back to disk. When an Oracle user process needs a data row.Database Buffer Cache The Database Buffer Cache is a fairly large memory object that stores the actual data blocks that are retrieved from datafiles by system queries and other data manipulation language commands.

If an Oracle user process searches the threshold limit of buffers without finding a free buffer. the process stops searching the LRU list and signals the DBWn background process to write some of the dirty buffers to disk. 16KB.     Typical block sizes are 2KB. that buffer is moved to the write list and the search for a free buffer continues. The block size for a database is set when a database is created and is determined by the init. This frees up some buffers. 4KB.ora parameter file parameter named DB_BLOCK_SIZE. it reads the data block from disk into the buffer and moves the buffer to the MRU end of the LRU list. This figure shows that the use of non-standard block sizes results in multiple database buffer cache memory allocations. . and 32KB. The size of blocks in the Database Buffer Cache matches the block size for the database. 8KB. The DBORCL database uses an 8KB block size.Each time a user process finds a dirty buffer as it searches the LRU. When a user process finds a free buffer.

SQL> ALTER SYSTEM SET db_cache_advice = ON. You can have the Oracle Server gather statistics about the Database Buffer Cache to help you size it to achieve an optimal workload for the memory allocation. there can be more than one Database Buffer Cache allocated to match block sizes in the cache with the block sizes in the non-standard tablespaces.Because tablespaces that store oracle tables can use different (non-standard) block sizes.------------ . gathering statistics on system performance always incurs some overhead that will slow down system performance. System altered. However. Name ID NAME BLOCK_SIZE ADVICE_STATUS SIZE_FOR_ESTIMATE SIZE_FACTOR BUFFERS_FOR_ESTIMATE ESTD_PHYSICAL_READ_FACTOR NUMBER VARCHAR2(20) NUMBER VARCHAR2(3) NUMBER NUMBER NUMBER NUMBER Null? Type ----------------------------------------.-------. This information is displayed from the V$DB_CACHE_ADVICE view. In order for statistics to be gathered. The size of the Database Buffer Caches can be controlled by the parameters DB_CACHE_SIZE and DB_nK_CACHE_SIZE to dynamically change the memory allocated to the caches without restarting the Oracle instance. READY) command. ON. you can dynamically alter the system by using the ALTER SYSTEM SET DB_CACHE_ADVICE (OFF. You can dynamically change the size of the Database Buffer Cache with the ALTER SYSTEM command like the one shown here: ALTER SYSTEM SET DB_CACHE_SIZE = 96M. SQL> DESC V$DB_cache_advice.

An example might be a table containing user names and passwords or a validation table of some type.---------. RECYCLE Buffer Pool This pool is used to store table data that is unlikely to be reused throughout daily processing – thus the data blocks are quickly removed from memory when not needed. NAME BLOCK_SIZE ADV -------------------.ESTD_PHYSICAL_READS ESTD_PHYSICAL_READ_TIME ESTD_PCT_OF_DB_TIME_FOR_READS ESTD_CLUSTER_READS ESTD_CLUSTER_READ_TIME NUMBER NUMBER NUMBER NUMBER NUMBER SQL> SELECT name. System altered. SQL> ALTER SYSTEM SET db_cache_advice = OFF.--DEFAULT <more rows will display> 21 rows selected. The DB_KEEP_CACHE_SIZE parameter sizes the KEEP Buffer Pool. The DB_RECYCLE_CACHE_SIZE parameter sizes the Recycle Buffer Pool. advice_status FROM v$db_cache_advice. block_size. . 8192 ON KEEP Buffer Pool This pool retains blocks in memory (data from tables) that are likely to be reused throughout daily processing.

Redo Log Buffer The Redo Log Buffer memory object stores images of all changes made to database blocks.  Database blocks typically store several table rows of organizational data. This means that if a single column value from one row in a block is changed. ALTER. or DROP. Changes include INSERT. CREATE. . UPDATE. DELETE. the block image is stored.

o RMAN uses this only if the BACKUP_DISK_IO = n and BACKUP_TAPE_IO_SLAVE = TRUE parameters are set. It does not use an LRU list to manage memory..g. The Redo Log Buffer as a circular buffer that is reused over and over. o If the Large Pool is too small. e. The PARALLEL_AUTOMATIC_TUNING = TRUE parameter must be set. LGWR writes redo sequentially to disk while DBWn performs scattered writes of data blocks to disk.  Parallel execution message buffers for parallel server operations. o Scattered writes tend to be much slower than sequential writes. the database delivers better performance. o Because LGWR enable users to avoid waiting for DBWn to complete its slow writes. copies of the images are stored to the Redo Log Files that are covered in more detail in a later module. Large Pool The Large Pool is an optional memory structure that primarily relieves the memory burden placed on the Shared Pool. Transactions that interact with more than one database. As the buffer fills up. The Large Pool size is set with the LARGE_POOL_SIZE parameter – this is not a dynamic parameter. Backup and restore operations by the Recovery Manager (RMAN) process. The Large Pool is used for the following tasks if it is allocated:    Allocating space for session memory requirements from the User Global Area where a Shared Server is in use. Java Pool . a distributed database scenario. memory allocation for backup will fail and memory will be allocated from the Shared Pool.

the size of the pool grows dynamically.    Oracle Steams manages sharing of data and events in a distributed environment. If STEAMS_POOL_SIZE is not set or is zero. Storing Java code and data in the Java Pool is analogous to SQL and PL/SQL code cached in the Shared Pool.The Java Pool is an optional memory object. Streams Pool This pool stores data and control structures to support the Oracle Streams feature of Oracle Enterprise Edition. Processes You need to understand three different types of Processes:    User Process: Starts when a database user requests to connect to an Oracle Server. but is required if the database has Oracle Java installed and in use for Oracle JVM (Java Virtual Machine). Background Processes: These start when an Oracle Instance is started up. Server Process: Establishes the Connection to an Oracle Instance when a User Process requests connection – makes the connection for the User Process.    The size is set with the JAVA_POOL_SIZE parameter that defaults to 24MB. Client Process . The Java Pool is used for memory allocation to parse Java commands and to store data associated with Java commands. It is sized with the parameter STREAMS_POOL_SIZE.

This must occur whether you're using SQLPlus. Integrated Developer Suite. This generates a User Process (a memory object) that generates programmatic calls through your user interface (SQLPlus. or application program) that creates a session and causes the generation of a Server Process that is either dedicated or shared. The client process is also termed the user process in some Oracle documentation.In order to use Oracle. you must obviously connect to the database. . an Oracle tool such as Designer or Forms. or an application program.

although with some performance reduction. Background Processes . Shared Server environment – a Server Process can serve several User Processes. Allocation of server process in a dedicated environment versus a shared environment is covered in further detail in the Oracle11g Database Performance Tuning course offered by Oracle Education.    Dedicated Server environment – there is a single Server Process to serve each Client Process.Server Process A Server Process is the go-between for a Client Process and the Oracle Instance.

present only when the shared server configuration is used. These background processes serve all system users. for example. Shared server is discussed in your readings on the topic "Configuring Oracle for the Shared Server". We will cover mandatory process in detail. It monitors the JOB$ table (table of jobs in the job queue) and starts job queue processes (Jnnn) as needed to execute jobs The Jnnn processes execute job requests created by the DBMS_JOBS package.  . D000 would be the first dispatcher process – Dispatchers are optional background processes. Dnnn: Dispatcher number "nnn". there are both mandatory and optional background processes that are started whenever an Oracle Instance starts up. Mandatory Background Processes        Process Monitor Process (PMON) System Monitor Process (SMON) Database Writer Process (DBWn) Log Writer Process (LGWR) Checkpoint Process (CKPT) Manageability Monitor Processes (MMON and MMNL) Recover Process (RECO) Optional Processes     Archiver Process (ARCn) Coordinator Job Queue (CJQ0) Dispatcher (number “nnn”) (Dnnn) Others Optional Background Process Definition:   ARCn: Archiver – One or more archiver processes copy the online redo log files to archival storage when they are full or a log switch occurs.As is shown here. CJQ0: Coordinator Job Queue – This is the coordinator of job queue processes for an instance.

It does the tasks shown in the figure below. PMON The Process Monitor (PMON) is a cleanup type of process that cleans up after failed processes such as the dropping of a user connection due to a network failure or the abnormal termination (ABEND) of a user application program. . It also performs other activities as outlined in the figure shown below.Of these. you will most often use ARCn (archiver) when you automatically archive redo log file information (covered in a later module). SMON The System Monitor (SMON) is responsible for instance recovery by applying entries in the online redo log files to the datafiles.

but that had not yet been recorded to a datafile by DBWn. . It combines (coalesces) adjacent areas of free space in the database's datafiles for tablespaces that are dictionary managed. Opens the database to allow system users to logon.   SMON also does limited space management. It also deallocates temporary segments to create free space in the datafiles. SMON reads the Redo Log Files and applies the changes to the data blocks. It does the following:  Rolls forward to recover data that was recorded in a Redo Log File. SMON is responsible for recovering the instance when the database is started up again.If an Oracle Instance fails. Rolls back uncommitted transactions. This recovers all transactions that were committed because these were written to the Redo Log Files prior to system failure. all information in memory not written to disk is lost.

Blocks that have been modified and that need to be written back to disk are termed "dirty blocks. a Server Process may find the data that is needed to meet a User Process request already residing in memory! DBWn writes to datafiles when one of these events occurs that is illustrated in the figure below. The purpose of DBWn is to improve system performance by caching writes of database blocks from the Database Buffer Cache back to datafiles. Performance improves because by delaying writing changed database blocks back to disk." The DBWn also ensures that there are enough free buffers in the Database Buffer Cache to service Server Processes that may be reading data from datafiles into the Database Buffer Cache. The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes.DBWn (also called DBWR in earlier Oracle Versions) The Database Writer writes modified blocks from the database buffer cache to the datafiles. Although one database writer process (DBW0) is sufficient for most systems. you can configure up to 20 DBWn processes (DBW0 through DBW9 and DBWa through DBWj) in order to improve write performance for a system that modifies data heavily. .


.LGWR The Log Writer (LGWR) writes contents from the Redo Log Buffer to the Redo Log File that is in use. The LGWR writes according to the events illustrated in the figure shown below. LGWR actually writes before the DBWn writes and only confirms that a COMMIT operation has succeeded when the Redo Log Buffer contents are successfully written to disk. LGWR can also call the DBWn to write contents of the Database Buffer Cache to disk. These are sequential writes since the Redo Log Files record database modifications based on the actual time that the modification takes place.

. Reduces Instance Recovery time by minimizing the amount of work needed for recovery since only Redo Log File entries processed since the last checkpoint require recovery. This is done at a minimum.CKPT The Checkpoint (CPT) process writes information to update the database control files and headers of datafiles to identify the point in time with regard to the Redo Log Files where instance recovery is to begin should it be necessary. Causes all committed data to be written to datafiles during database shutdown. DBWn will have completed writing all buffers from the Database Buffer Cache to disk prior to the checkpoint. once every three seconds. Think of a checkpoint record as a starting point for recovery. thus those records will not require recovery. This does the following:    Ensures modified data blocks in memory are regularly written to disk – CKPT can call the DBWn process in order to ensure this and does so when writing a checkpoint record.

CKPT does not write data blocks or redo blocks to disk – it calls DBWn and LGWR as necessary. location of which Redo Log File is to be used for recovery.If a Redo Log File fills up and a switch is made to a new Redo Log File (this is covered in more detail in a later module). the CKPT process also writes checkpoint information into the headers of the datafiles. . Checkpoint information written to control files includes the system change number (the SCN is a number stored in the control file and in the headers of the database files that are used to ensure that all files in the system are synchronized). and other information.

and capturing statistics value for recently modified SQL objects. taking snapshots. MMNL writes to disk when the ASH buffer is full. .MMON and MMNL The Manageability Monitor Process (MMNO) performs tasks related to the Automatic Workload Repository (AWR) – a repository of statistical data in the SYSAUX tablespace (see figure below) – for example. The information stored by these processes is used for performance tuning – we survey performance tuning in a later module. The Manageability Monitor Lite Process (MMNL) writes statistics from the Active Session History (ASH) buffer in the SGA to disk. MMON writes when a metric violates its threshold value.

The ARCn process must be used to recover from loss of a physical disk drive for systems that are "busy" with lots of transactions being completed. The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction. ARCn While the Archiver (ARCn) is an optional background process. the database may be distributed on servers of two different operating systems. e. . we cover it in more detail because it is almost always used for production systems storing mission critical information. removing from each database's pending transaction table any rows that correspond to the resolved transactions.     Consider a database that is distributed on two servers – one in St. it automatically resolves all indoubt transactions. LINUX and Windows. Further. Louis and one in Chicago.g.RECO The Recoverer Process (RECO) is used to resolve failures of distributed transactions in a distributed database. When RECO reestablishes a connection between the databases.

the Redo Log Files are overwritten and not archived. is lost forever. If all Redo Log Files fill up. In NOARCHIVELOG mode. any Archived Redo Log Files for prior backups are deleted. and you can see that this could cost the firm a lot of $$$. All committed transactions after the last full backup are lost. committed data is not lost forever and can be recovered in the event of a disk failure.When a Redo Log File fills up. they are individually written to Archived Redo Log Files and LGWR does not overwrite a Redo Log File until archiving has completed. When running in ARCHIVELOG mode. Oracle switches to the next Redo Log File. Recovery can only be made to the last full backup of the database files. If ARCn is in what is termed ARCHIVELOG mode. once overwritten. then as the Redo Log Files fill up. then Oracle switches back to the first one and uses them in a round-robin fashion by overwriting ones that have already been used – it should be obvious that the information stored on the files. the DBA is responsible to ensure that the Archived Redo Log Files do not consume all available disk space! Usually after two complete backups are made. The DBA creates several of these and the details of creating them are covered in a later module. Thus. Only the contents of the SGA will be lost if an Instance fails. .

sequences. clusters. and other database objects. Each tablespace has at least one physical datafile that actually stores the tablespace at the operating system level. A large tablespace may have more than one datafile allocated for storing objects assigned to that tablespace. .Logical Structure It is helpful to understand how an Oracle database is organized in terms of a logical structure that is used to organize physical objects. Tablespace: An Oracle database must always consist of at least two tablespaces (SYSTEM and SYSAUX). although a typical Oracle database will multiple tablespaces. indexes.   A tablespace is a logical storage facility (a logical container) for storing objects such as tables.

 A datafile can only store objects for a single tablespace. a segment is allocated to the object.   A tablespace belongs to only one database. for example. Tablespaces can be in either read-only or read-write status. The DBA can change the size of a datafile to make it smaller or later. A segment cannot span tablespaces but can span datafiles that belong to a single tablespace.   Obviously a tablespace typically has many segments. An extent cannot span a datafile.  Segment: When logical storage objects are created within a tablespace.  Extents are simply collections of contiguous disk storage blocks. The file can also grow in size dynamically as the tablespace grows. As a table or index grows. Datafile: Tablespaces are stored in datafiles which are physical disk objects.    . Tablespaces can be brought online and taken offline for purposes of backup and management. additional extents are added to the segment. an employee table. except for the SYSTEM tablespace that must always be online. Extent: Each object has one segment which is a physical collection of extents. A logical storage object such as a table or index always consists of at least one extent – ideally the initial extent allocated to an object will be large enough to store all data that is initially loaded. A DBA can add extents to segments in order to tune performance of the system. but a tablespace may have more than one datafile – this happens when a disk drive device fills up and a tablespace needs to be expanded. then it is expanded to a new disk drive.

4K. A physical block is the smallest addressable location on a disk drive for read/write operations. An Oracle data block consists of one or more physical blocks (operating system blocks) so the data block. etc in size. if larger than an operating system block. Operating System Blocks. then the Oracle data block should be 2K. 16K. The maximum data block size depends on the operating system. if the Linux operating system block size is 2K or 4K. Redo Log Files. Extents.Block: The Oracle Server manages data at the smallest unit in what is termed a block or data block. 8K. The data block size is set at the time the database is created and cannot be changed. It is set with the DB_BLOCK_SIZE parameter. should be an even multiple of the operating system block size. Segments. Logical: Tablespaces. This optimizes I/O.. Data are actually stored in blocks. Datafiles. Thus. e.g. . Data Blocks. the Oracle database architecture includes both logical and physical structures as follows:   Physical: Control files.

. o Lock objects used during parse.  Bind: Obtains values for variables. o Create and store execution plan.SQL Statement Processing SQL Statements are processed differently depending on whether the statement is a query. object names. or data definition language (DDL) to write information to the data dictionary. Processing a query:  Parse: o Search for identical statement in the Shared SQL Area. and privileges. data manipulation language (DML) to update. insert. or delete a row. o Check syntax.

Both of these changes are made in the Database Buffer Cache. o The processing of a DELETE or INSERT command uses similar steps. the server process reads them from the datafiles into the Database Buffer Cache. Processing a DML statement:    Parse: Same as the parse phase used for processing a query. data dictionary lookup. Fetch: Return rows to user process. and the before image of an INSERT contains the row location information. buffers that are not the same as the corresponding blocks on the disk. Bind: Same as the bind phase used for processing a query. so that the DML statements can be rolled back if necessary. For these statements. because the success of a DDL statement requires write access to the data dictionary. To re-execute them. simply perform another execute. Any changed blocks in the Database Buffer Cache are marked as dirty buffers. and system management SQL statements are processed using the parse and execute stages. session management. o The data blocks record the new values of the data. o The server process records the before image to the undo block and updates the data block. o The server process places locks on the rows that are to be modified. and execution.  Execute: Process statement. parsing actually includes parsing. The undo block is used to store the before image of the data. The before image for a DELETE contains the column values in the deleted row. Transaction management. Processing a DDL statement:  The execution of DDL (Data Definition Language) statements differs from the execution of DML (Data Manipulation Language) statements and queries.  . That is. Execute: o If the data and undo blocks are not already in the Database Buffer Cache.

lab coordinator or assignment writeup for the correct settings to the variables below: setenv ORACLE_HOME /usr/gwynne3/oracle (or ``setenv ORACLE\_HOME ~oracle'') setenv ORACLE_SID crs setenv T2KDEV sun (or xsun) setenv TWO_TASK crs setenv TERM sun (or xsun) ORACLE_HOME is set to the home directory of the ``oracle'' user.Starting ORACLE and Setting Environment Variables This section will provide a basic understanding of how to start ORACLE and some environment variables that may be of use.. gwm or sunview on UNIX platforms. it has been tested from the openwindows shelltool environment and seems to work better from this environment. sun if you are using openwindows. . This section will be kept as general as possible and specific information. SQL*FORMS . ORACLE_SID is the name of the database instance that you are using.). xsun if you are using X windows. Each tool that is available for your use will be explained in the following chapters. or assignment writeup. SQL*PLUS. such as the name of the database instance. For example. You must evaluate the available tools and select those that are most appropriate for your application. twm. lab. If you are running ORACLE from an xterm. you can use ORACLE from openwindows. you MUST set a few environment variables allowing you to identify yourself to ORACLE. the database instance you want to use and the location where ORACLE binaries can be found. See your TA. ORACLE can be used from many different platforms and on each platform it can be used in many different environments. will be provided in the lecture. you need to bring up xterm with the ``sf'' option. The variables below may or may not indicate the correct settings and may change from time to time. You should source the script ``/usr/local/bin/coraenv'' (``source /usr/local/bin/coraenv'') for csh shell users and ``/usr/local/bin/oraenv'' for sh users.e. Although ORACLE can be used from many environments. ORACLE is a relational database management system and as such has many development and production tools (i. from your lab machines to help you set the necessary variable parameters. T2KDEV is set to the type of terminal you are using. Before you can use any of the tools. olwm. SQL*MENU.

% oerr facility error Facility is identified by the three-letter prefix in the error string. setenv EDITOR /usr/ucb/vi Online Error Messages Use the online error message facility ``oerr'' to find out the descriptive error messages that are associated with the error codes that ORACLE produces. Starting ORACLE If you are not given an ORACLE user ID or PASSWORD. with TWO_TASK variable set with password identified by the system and SQL*NET installed. This variable helps simplify the command line for starting ORACLE tools. TWO_TASK is set to the location where ORACLE server can be found and will normally be the name of the database instance. Note: If you are using openwindows. then your user ID will be the same as your system login ID and your password will be verified by the system login. ``gwynne'' is the name of the database instance server and crs is the name of the database instance. you may have to redefine the variable TERM to sun (instead of cmd-sun) and you should execute ORACLE from a shelltool. call to ORACLE without TWO_TASK and SQL*NET sqlplus scott/tiger@T:gwynne:cr call to ORACLE without TWO_TASK but with SQL*NET sqlplus scott/tiger@crs call to ORACLE with TWO_TASK and SQL*NET sqlplus scott/tiger Note: T above stands for the protocol name (tcp/ip in this case). type: sqlplus / Setting Up Your Preferred Editor You may prefer to use your own editor when using the ORACLE tools instead of the default system editor (ed . so you should type ``oerr ora 7300''. For example.TERM is set to the type of terminal you are using. ``ora'' is the facility and ``7300'' is the error. type ``oerr lcd 111'' and so on. So to start an ORACLE tool SQL*PLUS.type ``q'' to quit). This can be done by setting the environment variable EDITOR to the editor of your choice. An Introduction to the Data Dictionary . if you get ORA7300. If you get LCD-111.

The views of the data dictionary serve as a reference for all database users. a set consists of three views containing similar information and distinguished from each other by their prefixes: USER ALL DBA user's view (what is in the user's schema) expanded user's view (what the user can access) database administrator's view (what all users can access) The views most likely to be of interest to typical users are those with the prefix USER. which provides information about its associated database. just like other database data. while others are intended for administrators only. including information about objects created by the user. views. except that the column OWNER is implied (the current user) return a subset of the information in the ALL_views    For example. users can only issue queries (SELECT statement) against the tables and views of the data dictionary. a data dictionary can provide the following information:       names of ORACLE users privileges and roles each user has been granted names of schema objects (tables.One of the most important parts of an ORACLE database is its data dictionary. synonyms) information about integrity constraints default values for columns how much space has been allocated for. you use SQL (see SQL*Plus). and so on display only rows pertinent to the user have identical columns to the other views. For example. the objects in a database The data dictionary is structured in tables and views. grants made by the user. These views:  refer to user's own private environment in the database. the following query returns all the objects contained in your schema: SELECT * FROM user_objects. Certain views are accessible to all ORACLE users. The data dictionary consists of sets of views. and is currently used by. indexes. To access the data dictionary. Because the data dictionary is read-only. In many cases. The data dictionary is a set of tables to be used as a read-only reference. You can obtain a list of all possible views by querying the data dictionary itself: .

It is important that you read through this section to familiarize yourself with the concepts and terminology to be used throughout this manual. see the file ``/etc/motd'' for the method of reporting problems. see page 1-15 of ``ORACLE7 Server Concepts Manual. you must have a basic understanding of the architecture of ORACLE to help you start thinking about an ORACLE database in the correct conceptual manner. ORACLE Architecture and Terminology This section will provide a basic understanding of ORACLE including the concepts and terminology of the ORACLE Server. Reporting Problems If you have any valid suggestions on improving this manual. Figure 1 illustrates a typical variation of ORACLE's memory and process structures. lab coordinator or send a message to the user ``oracle''. you should see your TA.'' . Most of the information contained in this section is DIRECTLY extracted from ``ORACLE7 Server Concepts Manual'' and all credit should be attributed to ORACLE. If you encounter any problems using ORACLE. For system problems or other ORACLE problems which require immediate attention.SELECT * FROM dict. you should send a message to the user ``oracle''. Before you can begin to use ORACLE. For more information on these memory structures and processes. some of the memory structures and processes in this diagram are discussed in the following section.

ORACLE Architecture Memory Structures and Processes The mechanisms of ORACLE execute by using memory structures and processes. . and the shared pool) and the program global area. Memory Structures ORACLE creates and uses memory structures to complete several jobs. All memory structures exist in the main memory of the computers that constitute the database system. Several basic memory structures are associated with ORACLE: the system global area (which includes the database and redo log buffers. For example.Figure 1. memory is used to store program code being executed and data that is shared among users. Processes are jobs or tasks that work in the memory of these computers.

The operations on a database must adhere to a pre-defined set of integrity rules. Integrity rules protect the data and the structures of a database. Integrity Rule Integrity rules are the laws that govern which operations are allowed on the data and structures of a database. The SGA is allocated when an instance starts and deallocated when the instance shuts down. ORACLE creates a server process to handle requests from connected user processes. An ORACLE database system has two general types of processes: user processes and ORACLE processes. The Program Global Area (PGA) is a memory buffer that contains data and control information for a server process. An ORACLE instance contains the SGA and the background processes.System Global Area (SGA) is a shared memory region allocated by ORACLE that contains data and control information for one ORACLE instance. 1-19). Database Structures The relational model has three major aspects: Structures Structures are well-defined objects that store the data of a database. Operations Operations are clearly defined actions that allow users to manipulate the data and structures of a database. ORACLE processes are called by other processes to perform functions on behalf of the invoking process. Structures and the data contained within them can be manipulated by operations. The information in a PGA depends on the configuration of ORACLE. ORACLE also creates a set of background processes for each instance (see ``ORACLE7 Server Concepts Manual'' pages 1-18. Processes A process is a ``thread of control'' or a mechanism in an operating system that can execute a series of steps. A user process is created and maintained to execute the software code of an application program (such as a PRO*C program) or an ORACLE tool (such as SQL*PLUS). The user process also manages the communication with the server processes. User processes communicate with the server processes through the program interface. . A PGA is created by ORACLE when a server process is started. Some operating systems use the terms job or task. Each instance that is started has its own SGA.

Tablespaces and Data Files Tablespaces are the primary logical storage structures of any ORACLE database. A tablespace's data files physically store the associated database data on disk. sequences.. tables. data files. and segments are closely related. views. indexes. The schema objects and the relationships among them form the relational design of a database. By separating physical and logical database structure. they have important differences: databases and tablespaces An ORACLE database is comprised of one or more logical storage units called tablespaces. tablespaces and data files Each tablespace in an ORACLE database is comprised of one or more operating system files called data files. The database's data is collectively stored in the database's tablespaces. Figure 2 illustrates this relationship. segments. tablespaces. The usable data of an ORACLE database is logically stored in the tablespaces and physically stored in the data files associated with the corresponding tablespace. each comprised of two data files (for a total of six data files). databases and data files A database's data is collectively stored in the data files that constitute each tablespace of the database. For example. and extents.g. Although databases. the physical storage of data can be managed without affecting the access to logical storage structures.An ORACLE database has both a physical and a logical structure. Logical Database Structure An ORACLE database's logical structure is determined by:   one or more tablespaces. A more complicated database might have three tablespaces. schema objects. stored procedures). including tablespaces. its segment is created within a designated tablespace in the database. segments. and tablespaces When a schema object such as a table or index is created. the simplest ORACLE database would have one tablespace. with one data file. suppose a table is created in a specific tablespace using the CREATE TABLE command with the TABLESPACE . the database's schema objects (e. The logical storage structures. dictate how the physical space of a database is used. For example. clusters.

Data Files and Tablespaces A database is divided into one or more logical storage units called tablespaces. Assign specific space quotas for database users. A database administrator can use tablespaces to do the following:      Control disk space allocation for database data. Control availability of data by taking individual tablespaces online or offline. The SYSTEM tablespace always contains the data dictionary tables for the entire database. Figure 2. You can query these data dictionary tables to obtain pertinent information . An object's segment allocates space in only one tablespace of a database. which is automatically created when the database is created. Allocate data storage across devices to improve performance. Perform partial database backup or recovery operations. Every ORACLE database contains a tablespace named SYSTEM.option. The space for this table's data segment is allocated in one or more of the data files that constitute the specified tablespace.

however. an ORACLE database's data is stored in data blocks (also called logical cannot store any other program's data. and segments. Extents The next level of logical database space is called an extent. An ORACLE database uses and allocates free database space in ORACLE data blocks. Therefore. index segments. or pages). Segments The level of logical database storage above an extent is called a segment. After a data file is initially created. ORACLE allocates another extent for that segment. See Chapter 3 for more information on how to access data dictionary tables. for example. the names of the tables that are owned by you or ones to which you have access. an object can ``span'' one or more data files. ORACLE allocates space for segments in extents. The data in the segments of objects (data segments. For example. a data file is a repository for the data of any object within a specific tablespace. rather. ORACLE uses the free space in the associated data files to allocate extents for the segment. Note that a schema object does not correspond to a specific data file. A segment is a set of extents which have been allocated for a specific type of data structure. The database administrator and end-users cannot control which data file stores an object. Data Blocks. Extents. the allocated disk space does not contain any data. therefore. each table's data is stored in its own data segment. while each index's data is stored in its own index segment. One or more datafiles form a logical unit of database storage called a tablespace. and so on) in a tablespace are physically stored in one or more of the data files that constitute the tablespace. rollback segments.about the database. The units of logical database allocations are data blocks. A data file can be associated with only one tablespace. ORACLE blocks. An extent is a specific number of contiguous data blocks that are allocated for storing a specific type of information. Data Blocks At the finest level of granularity. and Segments ORACLE allocates database space for all data in a database. extents. the space is reserved to hold only the data for future segments of the associated tablespace . Figure 4 illustrates a typical ORACLE data block. Because extents are allocated as . and only one database. and all are stored in the same tablespace. Figure 3 illustrates the relationships between these data structures. As a segment (such as the data segment for a table) is created and grows in a tablespace. Data files associated with a tablespace store all the database data in that tablespace. The extents of a single segment can be allocated in one or more data files of a tablespace (see Figure 3). when the existing extents of a segment are full.

Extents and Data Blocks ORACLE manages the storage space in the data files of a database in units called data blocks. This block size can differ from the standard I/O block size of the operating system that executes ORACLE. The ORACLE block format is similar regardless of whether the data block contains table. though. index. An extent cannot span files. the extents of a segment may or may not be contiguous on disk. . A data block corresponds to a block of physical bytes on disk. equal to the ORACLE data block size (specifically set when the database is created . and may or may not span files. Figure 3.2048). Figure 4 shows the format of a data block. or clustered data.needed. The Relationship Among Segments. A data block is the smallest unit of I/O used by a database.

or rollback. Rows can span blocks. While some block overhead is fixed in size (about 107 bytes). Once the space has been allocated in the row directory of a block's header. this space is not reclaimed when the row is deleted. segment type. index. the total block overhead size is variable. . Table Directory The table directory portion of the block contains information about the tables having rows in this block. Row Data This portion of the block contains table or index data. Data Block Format Header (Common and Variable) The header contains general block information. Row Directory This portion of the block contains row information about the actual rows in the block (including addresses for each row piece in the row data area).Figure 4. such as data. such as block address.

allow a developer to control the use of free space for inserts of and updates to the rows in data blocks.Free Space Free space is used to insert new rows and for updates to rows that require additional space (e. the block is not considered for the insertion of new rows until the percentage of the block being used falls below the parameter PCTUSED. For example. If the data blocks of a segment's initial extent become full and more space is required to hold new data. Both of these parameters can only be specified when creating or altering tables and clusters (data segments). Space Used for Transaction Entries Data blocks allocated for the data segment of a table. In addition. After a data block becomes full. each segment in a database is created with at least one extent to hold its data.g. Two space management parameters. a data block used for this table's data segment is not considered for the insertion of any new rows until the amount of used space in the blocks falls to 39\% or less (assuming that the block's used space has previously reached PCTFREE). the free space of the data block can only be used for updates to rows already contained in the data block. cluster. PCTFREE and PCTUSED. The PCTFREE parameter is used to set the percentage of a block to be reserved (kept free) for possible updates to rows that already are contained in that block. ORACLE automatically allocates an incremental extent for that segment. assume that you specify the following parameter within a CREATE TABLE statement: pctfree 20 This states that 20\% of each data block used for this table's data segment will be kept free and available for possible updates to the existing rows already within each block. Whether issued insertions actually occur in a given data block is a function of the value for the space management parameter PCTFREE and the amount of current free space in that data block. No matter what type. when a trailing null is updated to a non-null value). . as determined by PCTFREE. or the index segment of an index can also use free space for transaction entries. the storage parameter PCTFREE can also be specified when creating or altering indicies (index segments). For example. This extent is called the segment's initial extent. Before this value is achieved. An incremental extent is a subsequent extent of the same or incremented size of the previous extent in that segment.. assume that you specify the following parameter within a CREATE TABLE statement: pctused 40 In this case.

see ``ORACLE7 Server Concepts Manual. For more information on these physical storage files. The files of a database provide the actual physical storage for database information. The data segment for a table is indirectly created via the CREATE TABLE/SNAPSHOT command. For more information on Data Blocks. and one or more control files.Every non-clustered table in an ORACLE database has a single data segment to hold all of its data. Segments and Extents. Setting these storage parameters directly via the CREATE TABLE/SNAPSHOT/CLUSTER or ALTER TABLE/SNAPSHOT/CLUSTER commands affects the efficiency of data retrieval and storage for that data segment. Storage parameters for a table. Each ORACLE database is comprised of these types of files: one or more data files. see ``ORACLE7 Server Concepts Manual.'' Physical Database Structure An ORACLE database's physical structure is determined by the operating system files that constitute the database. or cluster control the way that a data segment's extents are allocated. snapshot. two or more redo log files.'' .

Loads EMP records from first 23 characters -.for each employee .Figure 5. -. Loading Data into Multiple Tables CONTROL FILE .The control file for this example.Creates and loads PROJ records for each PROJNO listed -. Maintaining the Free Space of Data Blocks with PCTFREE and PCTUSED Example 1.

SQLLOAD / CONTROL=ULCASE5.1st proj -. -.. c.CTL LOG=ULCASE5.3rd proj -------------------------------------------------------------- NOTES: (a) REPLACE indicates that if there is data in the tables to be loaded (EMP and PROJ).dat' BADFILE 'ulcase5. REPLACE INTO TABLE emp (empno POSITION(1:4) INTEGER EXTERNAL. Multiple INTO clauses are used to load two tables. deptno POSITION(17:18) CHAR.Part of the data file follows.dsc' a. mgr POSITION(20:23) INTEGER EXTERNAL) INTO TABLE proj -. that data should be deleted before new rows are loaded. rows are inserted into PROJ only if there is a value in those columns. b. b. (c) WHEN is used to load only rows with non-blank project numbers. DATA FILE . c. to load table PROJ. projno POSITION(29:31) INTEGER EXTERNAL) INTO TABLE proj WHEN projno != ' ' (empno POSITION(1:4) INTEGER EXTERNAL.LOAD DATA INFILE 'ulcase5. projno POSITION(25:27) INTEGER EXTERNAL) INTO TABLE proj WHEN projno != ' ' (empno POSITION(1:4) INTEGER EXTERNAL. The same set of records (b) is processed three times using different combinations of columns each time. ename POSITION(6:15) CHAR. When PROJNO is defined as columns 25. both not null: EMPNO and PROJNO WHEN projno != ' ' (empno POSITION(1:4) INTEGER EXTERNAL. projno POSITION(33:35) INTEGER EXTERNAL) b.2nd proj b.LOG .The command line for this example.PROJ has two columns. EMP and PROJ.27.bad' DISCARDFILE 'ulcase5. -. 1234 BAKER 1234 JOKER 2664 YOUNG 10 9999 101 102 103 10 9999 777 888 999 20 2893 425 abc 102 INVOKING SQL*LOADER .

delimited and enclosed data format a. d. hiredate DATE "DD-Month-YYYY". This (e) function finds the current maximum value in column LOADSEQ and adds the increment (1) to it to obtain the value for LOADSEQ for each row inserted. 2572.The command line for this example. Free-Format File CONTROL FILE . e. c." OPTIONALLY ENCLOSED BY '"' (empno.1)) BEGINDATA 7782. The default terminator for the data fields is a comma. f. .The control file for this example. mgr.Example 2 Loading a Delimited.00. (d) The data to be loaded into column HIREDATE appears in the format DD-Month-YYYY. 10:102 -------------------------------------------------------------- NOTES: (a) INFILE * signifies the data is found at the end of the control file. loadseq SEQUENCE(MAX. the table need not be empty. sal. "President". ename. 09-June-1981. deptno CHAR TERMINATED BY ':'. "King".Variable-length. b. projno. (b) (c) APPEND indicates that data may be loaded even if the table already contains rows. LOAD DATA INFILE * APPEND INTO TABLE emp FIELDS TERMINATED BY ". and some fields may be enclosed by a double quote. 10:101 7839. "Manager".LOG Control File Syntax . SQLLOAD / CONTROL=ULCASE3.CTL LOG=ULCASE3. 17-January-1982. (f) BEGINDATA signifies the end of the control information and the beginning of the data. The SEQUENCE function is used to generate a unique value in the column LOADSEQ. job. -. comm. "CLARK". 920. 7839.50. INVOKING SQL*LOADER .

followed by several phrases that describe the data to be loaded.Number of logical records to load (DEFAULT all) -. until the end of line. Only a subset of the syntax will be explained below. For a complete control file syntax diagram see Appendix C in this manual. All text to the right of the double dash is ignored.Number of errors to allow (DEFAULT 50) -. Comments Comments may appear anywhere in the command section of the file. but they should not appear in the data. Comments are preceded with a double dash.Number of rows in conventional path bind array (DEFAULT 64) .Number of logical records to skip (DEFAULT 0) -. see chapter 6 of ``ORACLE7 Server Utilities Users Guide''. or when the command line and all its arguments becomes very long. The OPTIONS Clause The OPTIONS clause is useful when you usually invoke a control file with the same set of options.The control file usually begins with the phase LOAD DATA. SKIP = n LOAD = n ERRORS = n ROWS = n -. This clause allows you to specify runtime arguments in the control file rather than on the command line. Only comments or the OPTIONS phrase can precede the LOAD DATA phase. which may appear anywhere on a line. For a complete explanation of the above syntax.

If the tables you are loading already contain data. Continuing Interrupted Loads If SQL*Loader runs out of space for data rows or index entries. Loading into Non-Empty Database Tables SQL*Loader does not update existing records. and the tables are left in a valid state. Use this information to resume the load where it left off. the table might reach its maximum number of extents. With this precedence. the filename defaults to the control filename with an extension or filetype of DAT. For example: SQLLOAD / CONTROL=FAST1.BINDSIZE = n -.CTL SKIP=345 CONTINUE\_LOAD DATA statement is used to continue a discontinued direct path load involving multiple tables with a varying number of records to skip. When a load is discontinued. For more information on this command. SILENT=(ERRORS. the OPTIONS keyword in the control file established default values that are easily changed from the command line. (For example. SQL*Loader's log file tells you the state of the tables and indexes and the number of logical records already read from the input data file. any data already loaded remains in the tables. see chapter 6 of ``ORACLE7 Server Utilities Users Guide''. use the INFILE or INDDN keyword. the load is discontinued. FEEDBACK) ) Values specified on the command line override values specified in the control file.Suppress messages during run For example: OPTIONS (BINDSIZE=10000. Identifying Data Files To specify the file containing the data to be loaded.Size of conventional path bind array in bytes SILENT = {HEADER | FEEDBACK | ERROR | DISCARDS | ALL } -. you have three choices for how SQL*Loader should proceed: . followed by the filename. If no filename is specified.) Discontinued loads can be continued after more space is made available. even if they have null columns. A filename specified on the command line overrides the first INFILE or INDDN statement in the control file.

Loading Logical Records into Tables The INTO TABLE clause allows you to tell which table you want to load data into. SQL*Loader appends the new rows to it.If data already exists in the table. Then the WHEN clause is evaluated.INSERT . if data doesn't already exist.This is the default option. For example. APPEND. The INTO TABLE clause may continue with some options for loading that table. you would include one INTO TABLE clause for each table you wish to load. REPLACE . For example. SQL*Loader terminates with an error if the table contains rows. This option requires DELETE privileges on the table. To load multiple tables. you may specify different options (INSERT. When the control file specifies more fields for a record than are present in the record. For example: WHEN (DEPTNO = '10') AND (JOB = 'SALES') To evaluate the WHEN clause. if the following data 10 Accounting is read with the following control file . For example. A row is inserted into the table only if the WHEN clause is true. SQL*Loader must determine whether the remaining (specified) columns should be considered null. It requires the table to be empty before loading. You can create one logical record from multiple physical records using CONCATENATE and CONTINUEIF. See chapter 6 of ``ORACLE7 Server Utilities Users Guide''. TRAILING NULLCOLS clause tells SQL*Loader to treat any relatively positioned columns that are not present in the record as null columns. SQL*Loader first determines the values of all the fields in the record. the new rows are simply loaded. REPLACE) for each table in order to tell SQL*Loader what to do if data already exists in the table. Parentheses are optional but should be used for clarity with multiple comparisons joined by AND. APPEND .All rows in the table are deleted and the new data is loaded. or whether an error should be generated. the following clause indicates that any record with the value ``q'' in the fifth column position should be loaded: WHEN (5) = 'q' A WHEN clause can contain several comparisons as long as each is preceded by AND. The WHEN clause appears after the table name and is followed by one or more field conditions.

and can have lengths (or maximum lengths) specified in the control file. dname CHAR TERMINATED BY WHITESPACE. an error would be generated. These fields can be delimited. loc CHAR TERMINATED BY WHITESPACE ) and the record ends after DNAME. DATE. and the numeric EXTERNAL datatypes (INTEGER and DECIMAL). These non-character datatypes are the native datatypes: INTEGER ZONED SMALLINT VARCHAR FLOAT GRAPHIC DOUBLE GRAPHIC EXTERNAL BYTEINT VARGRAPHIC (packed) DECIMAL RAW These datatypes will not be discussed as most of the datatypes that you will be using will be character datatypes. SQL*Loader then sends the field to the server to be stored in the appropriate column. For more information on SQL*Loader datatypes. Without the TRAILING NULLCOLS clause. ORACLE automatically performs conversions . or contain binary data in their implementation. SQL*Loader does not contain datatype specifications for ORACLE internal datatypes like NUMBER or VARCHAR2.INTO TABLE dept TRAILING NULLCOLS ( deptno CHAR TERMINATED BY " ". . see page 6-52 of ``ORACLE7 SERVER Utilities User's Guide''. guided by the datatype specification in the control file. The server does any data conversion necessary to store the data in the proper internal format. SQL*Loader extracts data from a field in the input file. The server defines the datatypes for the columns in the database. SQL*Loader's datatypes describe data that can be produced with text editors (character datatypes) and with standard programming languages (native datatypes). due to missing data. Native Datatypes Some datatypes consist entirely of binary data. Specifying Datatypes The datatype specification in the control file tells SQL*Loader how to interpret the information in the data file. then the remaining LOC field is set to null. Character Datatypes The character datatypes are CHAR. The datatype of the data in the file does not necessarily have to be the same as the datatype of the column in the ORACLE table.but you need to ensure that the conversion makes sense and does not generate errors.

This data field contains character data. . this length overrides the length in the POSITION specification. CHAR data is assumed to have a length of 1.The numeric external datatypes are the numeric datatypes (INTEGER. An explicit length specification. the default ORACLE date mask of ``dd-mon-yy'' is used. The mask may be any valid ORACLE date mask. FLOAT. unless a varying-length data mask is specified. The length is optional. With a specification like: DATE "Month dd. If you omit the mask. Numeric EXTERNAL .a field length is required any time the length of the date string could exceed the length of the mask. a length is required for any Julian dates (date mask ``J'') . or with the POSITION keyword.This data is character data that should be converted to an ORACLE date using the specified date mask. This guarantees that a large enough buffer is allocated for the value. a length must be specified. while the length of a field like September 31. If no length is given. 1991 is 18 characters. if present. overrides the length in the POSITION clause.CHAR . In this case. DECIMAL. To Load LONG Data: If the column in the database table is defined as LONG. and ZONED) specified with the EXTERNAL keyword along with optional length and delimiter specifications. See Chapter 6 for the Oracle date masks. and is taken from the POSITION specification if it is not present here. DATE . character form of numeric data. you must explicitly specify a maximum length either with a length-specifier on the CHAR keyword. If present. Similarly. YYYY" the date mask is 14 characters. and is necessary even if the data is delimited or enclosed. The length specification is optional. These datatypes are the human-readable. A field of datatype CHAR may also be variable-length delimited or enclosed. Either of these overrides the length derived from the mask.

If you want the default to be null. use CHAR. For example. Delimited data can be TERMINATED or ENCLOSED. Introduction to Physical Storage Structures One characteristic of an RDBMS is the independence of logical data structures such as tables. views. or numeric EXTERNAL fields may also be marked by specific delimiter characters contained in the input data record. with one exception: the use of DEFAULTIF.The data is a number in character form (not binary representation). if you want it to be zero. As such. renaming a database file does not rename the tables stored in it. 11 Physical Storage Structures This chapter describes the primary physical database structures of an Oracle database. use EXTERNAL. Physical structures are viewable at the operating system level.The boundaries of CHAR. DATE. . and indexes from physical storage structures. these datatypes are identical to CHAR and are treated identically. you can manage physical storage of data without affecting access to logical structures. Because physical and logical structures are separate. You indicate how the field is delimited by using a delimiter specification after specifying the datatype. >>----INTEGER ---EXTERNAL------------------------------------|___FLOAT___| _| |___DECIMAL_| |___ZONED___| |_ ( length ) _| |_ delimiter_spec delimiter_spec .

An Oracle database is a set of files that store Oracle data in persistent disk storage. Figure 11-1 shows the relationship between the instance and the files that it manages. "Oracle Automatic Storage Management (Oracle ASM)" describes Oracle ASM.  Operating system file system . Figure 11-1 Database Instance and Database Files Description of "Figure 11-1 Database Instance and Database Files" Mechanisms for Storing Database Files Several mechanisms are available for allocating and managing the storage of these files. The data is written to these files in an Oracle proprietary format that cannot be read by other programs. This section discusses the database files generated when you issue a CREATE DATABASE statement:  Data files and temp files A data file is a physical file on disk that was created by Oracle Database and contains data structures such as tables and indexes.  Online redo log files The online redo log is a set of files containing records of changes made to data. The most common mechanisms include:  Oracle Automatic Storage Management (Oracle ASM) Oracle ASM includes a file system designed exclusively for use by Oracle Database.  Control files A control file is a root file that tracks the physical components of the database. A database instance is a set of memory structures that manage database files. A temp file is a data file that belongs to a temporary tablespace.

a cluster file system makes shared storage appears as a file system shared by many computers in a clustered environment. A file system is commonly built on top of a logical volume constructed by a software package called a logical volume manager (LVM). raw devices were the only means of implementing direct I/O. Oracle ASM is a volume manager and provides a file system designed exclusively for use by the database. write.  Cluster file system A cluster file system is software that enables multiple computers to share file storage while maintaining consistent space allocation and file content. In an Oracle RAC environment. In direct I/O. A database employs a combination of the preceding storage mechanisms. The primary benefit of raw devices is the ability to perform direct I/O and to write larger buffers. resize. ease-of-management storage solution for Oracle Database files. read. A file system enables disk space to be allocated to many files. Historically. then the file system is unavailable. The database can create. The LVM enables pieces of multiple physical disks to be combined into a single contiguous address space that appears as one disk to higher layers of software. . For example. bypassing the operating system buffer cache. applications write to and read from the storage device directly. In an operating system file system. which is a data structure built inside a contiguous disk address space. some user data files on raw partitions. Each file has a name and is made to appear as a contiguous address space to applications such as Oracle Database. and delete files. the failure of a computer in the cluster does not make the file system unavailable.  Raw device Raw devices are disk partitions or logical volumes not formatted with a file system. the remaining data files in Oracle ASM.Most Oracle databases store files in a file system. Oracle Automatic Storage Management (Oracle ASM) Oracle ASM is a high-performance. Note: Many file systems now support direct I/O for databases and other applications that manage their own caches. and archived the redo log files to a cluster file system. however. With a cluster file system. if a computer sharing files through NFS or other means fails. All operating systems have file managers that allocate and deallocate disk space into files within a file system. a database could store the control files and online redo log files in a traditional file system.

you can increase the size of the disk for the database or move parts of the database to new devices without having to shut down the database. Oracle ASM Storage Components Oracle Database can store a data file as an Oracle ASM file in an Oracle ASM disk group. Within a disk group. Figure 11-2 shows the relationships between storage components in a database that uses Oracle ASM. Figure 11-2 Oracle ASM Components Description of "Figure 11-2 Oracle ASM Components" Figure 11-2 illustrates the following Oracle ASM concepts:  Oracle ASM Disks . you allocate partitioned disks for Oracle Database with preferences for striping and mirroring. The crow's foot notation represents a one-to-many relationship. Oracle ASM manages the disk space.Oracle ASM provides several advantages over conventional file systems and storage managers. distributing the I/O load across all available resources to optimize performance while removing the need for manual I/O tuning. For example. The diagram depicts the relationship between an Oracle ASM file and a data file. which is a collection of disks that Oracle ASM manages as a unit. Oracle ASM exposes a file system interface for database files. including the following:    Simplifies storage-related tasks such as creating and laying out databases and managing disk space Distributes data across physical disks to eliminate hot spots and to provide uniform performance across the disks Rebalances data automatically after storage configuration changes To use Oracle ASM. although Oracle ASM can store other types of files.

Oracle ASM disks can be added or dropped from a disk group while the database is running. Oracle Database communicates with Oracle ASM in terms of files. An Oracle ASM disk can be a physical disk or partition.  Oracle ASM Disk Groups An Oracle ASM disk group is a collection of Oracle ASM disks managed as a logical unit. When you add a disk to a disk group. to eliminate hot spots and to provide uniform performance across the disks. a Logical Unit Number (LUN) from a storage array. a logical volume. The content of files that are stored in a disk group are evenly distributed. and other types of files as Oracle ASM files. This capability simplifies the integration of Oracle ASM into pre-existing environments.  Oracle ASM Extents An Oracle ASM extent is the raw storage used to hold the contents of an Oracle ASM file. control files. Oracle ASM exposes a file system interface for Oracle database files. When requested by the database. Each Oracle ASM extent consists of one or more allocation units on a specific disk.  Oracle ASM Allocation Units . online redo log files. Note: Oracle ASM files can coexist with other storage management options such as raw disks and third-party file systems. The performance is comparable to the performance of raw devices. An Oracle ASM file consists of one or more file extents. The data structures in a disk group are self-contained and consume some disk space in a disk group. Within a disk group. you either assign a disk name or the disk is given an Oracle ASM disk name automatically.  Oracle ASM Files An Oracle ASM file is a file stored in an Oracle ASM disk group. Note: An Oracle ASM extent is different from the extent used to store data in a segment. or a network-attached file. The database can store data files. Oracle ASM creates an Oracle ASM file and assigns it a fully qualified name beginning with a plus sign (+) followed by a disk group name. as in +DISK1. or striped.An Oracle ASM disk is a storage device that is provisioned to an Oracle ASM disk group.

an ASM instance has a system global area (SGA) and background processes that are similar to those of a database instance. The ASM instance manages the metadata and provides space allocation for the ASM files storing the data for the two databases. For example. Database instances direct I/O to ASM disks without going through an ASM instance. An ASM instance is built on the same technology as a database instance. One or more allocation units form an Oracle ASM extent. ASM instances manage the metadata of the disk group and provide file layout information to the database instances.An allocation unit is the fundamental unit of allocation within a disk group. See Also:   Oracle Database 2 Day DBA to learn how to administer Oracle ASM disks with Oracle Enterprise Manager (Enterprise Manager) Oracle Automatic Storage Management Administrator's Guide to learn more about Oracle ASM Oracle ASM Instances An Oracle ASM instance is a special Oracle instance that manages Oracle ASM disks. each associated with a different single-instance database. an ASM instance cannot mount a database and performs fewer tasks than a database instance. However. An allocation unit is the smallest contiguous disk space that Oracle ASM allocates. Figure 11-3 Oracle ASM Instance and Database Instances . Both the ASM and the database instances require shared access to the disks in an ASM disk group. One ASM disk group has four ASM disks and the other has two disks. Figure 11-3 shows a single-node configuration with one Oracle ASM instance and two database instances. Both database instances can access the disk groups.

In this way. you can create a tablespace without specifying the names of its data files. For example.Description of "Figure 11-3 Oracle ASM Instance and Database Instances " See Also:   Oracle Database 2 Day DBA to learn how to administer Oracle ASM disks with Oracle Enterprise Manager (Enterprise Manager) Oracle Automatic Storage Management Administrator's Guide to learn more about Oracle ASM Oracle Managed Files and User-Managed Files Oracle Managed Files is a file naming strategy that enables you to specify operations in terms of database objects rather than file names. Oracle Managed Files eliminates the need for administrators to directly manage the operating system files in a database. Oracle ASM requires Oracle Managed Files. Note: .

Use of Data Files Part I. Each nonpartitioned schema object and each partition of an object is stored in its own segment. Through initialization parameters. See Also: Oracle Database Administrator's Guide to learn how to use Oracle Managed Files Overview of Data Files At the operating system level. The Oracle Managed Files feature ensures that the database creates a unique file and deletes it when no longer needed. You can create new files while manually administering old files. For example. A segment can span one or more data files. You make the decisions regarding file structure and naming.This feature does not affect the creation or naming of administrative files such as trace files. Oracle Database stores database data in data files. Thus. The data for a database is collectively stored in the data files located in each tablespace of the database. Oracle Database physically stores tablespace data in data files. The database internally uses standard file system interfaces to create and delete files for data files and temp files. which like segments are logical storage structures. Each segment belongs to only one tablespace. the most important of which are tables. With user-managed files. . "Oracle Relational Data Structures" explains the logical structures in which users store data. Oracle Database allocates space for user data in tablespaces. Oracle Managed Files does not eliminate existing functionality. you directly manage the operating system files in the database. Tablespaces and data files are closely related. which conform to the operating system in which Oracle Database is running. and recovery-related files stored in the fast recovery area. but have important differences:    Each tablespace consists of one or more data files. which is turn is stored in one tablespace. the data for a nonpartitioned table is stored in a single segment. audit files. and alert logs (see "Overview of Diagnostic Files"). a database can have a mixture of Oracle Managed Files and user-managed files. when you create a tablespace you set the name and path of the tablespace data files. you specify the file system directory for a specific type of file. but it cannot span multiple tablespaces. For example. control files. Every database must have at least one data file. For ease of administration.

 A database must have the SYSTEM and SYSAUX tablespaces. The SYSTEM tablespace contains the data dictionary. data files. and segments. a set of tables that contains database metadata. . Typically. a database also has an undo tablespace and a temporary tablespace (usually named TEMP). Figure 11-4 Data Files and Tablespaces Description of "Figure 11-4 Data Files and Tablespaces" See Also:   "Overview of Tablespaces" Oracle Database Administrator's Guide and Oracle Database 2 Day DBA to learn how to manage data files Permanent and Temporary Data Files A permanent tablespace contains persistent schema objects. Objects in permanent tablespaces are stored in data files. Figure 11-4 shows the relationship between tablespaces. Oracle Database automatically allocates the first data files of any database for the SYSTEM tablespace during database creation.

which are special files designed to store data in hash. Administrators may take data files offline for many reasons. You can alter the availability of individual data files or temp files by taking them offline or bringing them online. which means that they never have redo generated for them. Offline data files cannot be accessed until they are brought back online. sort. a tablespace itself is offline or online. Locally managed temporary tablespaces have temporary files (temp files). however. but not in DBA_DATA_FILES or the V$DATAFILE view. including performing offline backups.  Temp file information is shown in the data dictionary view DBA_TEMP_FILES and the dynamic performance view V$TEMPFILE. Temp files are similar to permanent data files. You cannot create a temp file with the ALTER DATABASE statement. Online and Offline Data Files Every data file is either online (available) or offline (unavailable). In this case. with the following exceptions:      Permanent database objects such as tables are never stored in temp files.A temporary tablespace contains schema objects only for the duration of a session. Like a data file. or block corruption. temp files are created as sparse files. When you take a data file offline in an online tablespace. On file systems such as Linux and UNIX. they are not always guaranteed allocation of disk space for the file size specified. Media recovery does not recognize temp files. Caution: Sparse files enable fast temp file creation and resizing. but as the blocks are accessed for the first time. Temp files also store result set data when insufficient space exists in memory. renaming a data file. disk blocks are allocated not at file creation or resizing. and other operations. The database takes a data file offline automatically if the database cannot write to it. Temp files are always set to NOLOGGING mode. the disk could run out of space later when the temp files are accessed. the tablespace itself remains online. When you create or resize temp files. You cannot make a temp file read-only. You can make all data files of a tablespace temporarily unavailable by taking the tablespace itself offline See Also:   "Online and Offline Tablespaces" Oracle Database Administrator's Guide to learn how to alter data file availability Data File Structure .

updates and deletions of objects within a tablespace can create pockets of empty space that individually are not large enough to be reused for new data. The absolute file number uniquely identifies the data file within the database. The data file header contains metadata about the data file such as its size and checkpoint SCN. Each database has one unique control file. As the data grows in a tablespace. However. Over time. although it may maintain identical copies of it. or free. Figure 11-5 illustrates the different types of space in a data file. A control file contains information such as the following: . When Oracle Database first creates a data file.Oracle Database creates a data file for a tablespace by allocating the specified amount of disk space plus the overhead for the data file header. which means they contain segment data. the database reserves the space to hold the data for future segments of the associated tablespace. Each header contains an absolute file number and a relative file number. Use of Control Files The control file is the root file that Oracle Database uses to find database files and to manage the state of the database generally. The relative file number uniquely identifies a data file within a tablespace. which means they are available for reuse. the allocated disk space is formatted but contains no user data. Extents are either used. Figure 11-5 Space in a Data File Description of "Figure 11-5 Space in a Data File" Overview of Control Files The database control file is a small binary file associated with only one database. This type of empty space is referred to as fragmented free space. Oracle Database uses the free space in the data files to allocate extents for the segment. The operating system under which Oracle Database runs is responsible for clearing old information and authorizations from a file before allocating it to the database.

When other current control file copies exist. when an administrator adds. update the information stored in the control file. The control file tracks structural changes to the database. or drops a data file or online redo log file. online redo log files. identical control files to be open concurrently and written for the same database. Multiple Control Files Oracle Database enables multiple. and archived redo log files Tablespace information RMAN backups The control file serves the following purposes:  It contains information about data files. Oracle Database reads and writes to the control file continuously during database use and must be available for writing whenever the database is open. however. the database can be remounted and opened without media recovery. each on a different disk. including checkpoints. If all control files of a database are lost. Media recovery is not straightforward if an older backup of a control file must be used because a current copy is not available. By multiplexing a control file on different disks.     The database name and database unique identifier (DBID) The time stamp of database creation Information about data files. the database updates the control file to reflect this change. For example. Note: Oracle recommends that you maintain multiple control file copies. Other operations. then the instance fails and media recovery is required.  It contains metadata that must be accessible when the database is not open. then the database instance fails when it attempts to access the damaged control file. If a control file becomes unusable. online redo log files. For example. recovering a database involves reading from the control file the names of all the data files contained in the database. Every committed change before a checkpoint SCN is guaranteed to be saved on disk in the data files. See Also: . and so on that are required to open the database. the control file contains information required to recover the database. the database can achieve redundancy and thereby avoid a single point of failure. For example. such as adding a data file. A checkpoint indicates the SCN in the redo stream where instance recovery would be required to begin (see "Overview of Instance Recovery"). At least every three seconds the checkpoint process records information in the control file about the checkpoint position in the online redo log. renames.

also known as V$ views. Reading and writing the control file blocks is different from reading and writing data blocks. Each section is a set of records about an aspect of the database. However. As explained in "Overview of the Dynamic Performance Views". When all available record slots are full. one section in the control file tracks data files and contains a set of records. the database either expands the control file to make room for a new record or overwrites the oldest record. See Also:   Oracle Database Reference to learn about the V$CONTROLFILE_RECORD_SECTION view Oracle Database Reference to learn about the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter Overview of the Online Redo Log . Oracle Database reads and writes directly from the disk to the program global area (PGA). Examples include records about archived redo log files and RMAN backups. one for each data file. The control file contains the following types of records:  Circular reuse records These records contain noncritical information that is eligible to be overwritten if needed. online redo log files.  Oracle Database Administrator's Guide to learn how to maintain multiple control files Oracle Database Backup and Recovery User's Guide to learn how to back up and restore control files Control File Structure Information about the database is stored in different sections of the control file. Each section is stored in multiple logical control file blocks. you can query V$DATABASE to obtain the database name and DBID. For example. only the database can modify the information in the control file. For the control file. and redo threads. data files. to view the information stored in the control file. you can query the dynamic performance views. Each process allocates a certain amount of its PGA memory for control file blocks. For example.  Noncircular reuse records These records contain critical information that does not change often and cannot be overwritten. Oracle Database never reuses these records unless the corresponding object is dropped from the tablespace. Examples of information include tablespaces. Records can span blocks within a section.

A separate redo thread for each instance avoids contention for a single set of online redo log files. so only one redo thread is present. How Oracle Database Writes to the Online Redo Log The online redo log for a database instance is called a redo thread. Specifically. which consists of two or more preallocated files that store changes to the database as they occur. See Also: Oracle Database 2 Day + Real Application Clusters Guide and Oracle Real Application Clusters Administration and Deployment Guide to learn about online redo log groups in Oracle RAC Online Redo Log Switches Oracle Database uses only one online redo log file at a time to store records written from the redo log buffer. An online redo log consists of two or more online redo log files. The online redo log records changes to the data files. you can configure log switches to occur at regular intervals. Redo log files are a useful source of historical information about database activity. and force log switches manually. However. In an Oracle Real Application Clusters (Oracle RAC) configuration. after an instance failure the online redo log files enable Oracle Database to recover committed data not yet written to the data files. and schema and object management statements.The most crucial structure for recovery is the online redo log. two or more instances concurrently access a database. Use of the Online Redo Log The database maintains online redo log files to protect against data loss. . A log switch occurs when the database stops writing to one online redo log file and begins writing to another. with each instance having its own redo thread. The contents of the log include uncommitted transactions. regardless of whether the current online redo log file is filled. however. Oracle Database uses the online redo log only for recovery. However. The online redo log file to which the log writer (LGWR) process is actively writing is called the current online redo log file. administrators can query online redo log files through a SQL interface in the Oracle LogMiner utility (see "Oracle LogMiner"). Oracle Database writes every transaction synchronously to the redo log buffer. undo data. In single-instance configurations. a switch occurs when the current online redo log file is full and writing must continue. Normally. Oracle Database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). only one instance accesses a database. which is then written to the online redo logs.

When log writer fills the last available online redo log file. then a filled online redo log file is available after the changes recorded in it have been checkpointed (written) to disk by database writer (DBWn). restarting the cycle. In some circumstances. which means that the database is in NOARCHIVELOG mode. For example. Filled online redo log files are available for reuse depending on the archiving mode:   If archiving is disabled. Figure 11-6 Reuse of Online Redo Log Files Description of "Figure 11-6 Reuse of Online Redo Log Files" The numbers in Figure 11-6 shows the sequence in which LGWR writes to each online redo log file.Log writer writes to online redo log files circularly. an online redo log file may be active (required for instance recovery) rather . Figure 11-6 illustrates the circular writing of the redo log. this file receives the next available log sequence number. then a filled online redo log file is available to log writer after the changes have been written to the data files and the file has been archived. When the database reuses an online redo log file. log writer may be prevented from reusing an existing online redo log file. which means that the database is in ARCHIVELOG mode. If archiving is enabled. the process writes to the first log file. The database assigns each file a new log sequence number when a log switches and log writers begins writing to it.

See Also:   "Overview of Background Processes" Oracle Database 2 Day DBA and Oracle Database Administrator's Guide to learn how to manage the online redo log Multiple Copies of Online Redo Log Files Oracle Database can automatically maintain two or more identical copies of the online redo log in separate locations. A_LOG1 and B_LOG1 are identical members of group 1. Each group is defined by a number. Also. then writes concurrently to group 2 (members A_LOG2 and B_LOG2). while A_LOG2 and B_LOG2 are identical members of group 2. Ideally. LGWR never writes concurrently to members of different groups. the locations of the members should be on separate disks so that the failure of one disk does not cause the loss of the entire online redo log. such as group 1. In Figure 11-7. group 2. Maintaining multiple members of an online redo log group protects against the loss of the redo log. Each member in a group must be the same size. LGWR writes concurrently to group 1 (members A_LOG1 and B_LOG1). An online redo log group consists of an online redo log file and its redundant copies. an online redo log file may be in the process of being cleared. and so on. then writes to group 1. and so on. Figure 11-7 Multiple Copies of Online Redo Log Files . Each identical copy is a member of the online redo log group.than inactive (not required for instance recovery).

the database must increase the amount of I/O it performs.Description of "Figure 11-7 Multiple Copies of Online Redo Log Files" Note: Oracle recommends that you multiplex the online redo log. You can use archived redo log files to:   Recover a database backup Update a standby database (see "Computer Failures") . When you multiplex the online redo log. this additional I/O may impact overall database performance. Depending on your system. but is an offline copy of an online redo log file created by the database and written to a user-specified location. The loss of log files can be catastrophic if recovery is required. Archived redo log files are a crucial part of a backup and recovery strategy. This file is not considered part of the database. See Also: Oracle Database Administrator's Guide to learn how to maintain multiple copies of the online redo log files Archived Redo Log Files An archived redo log file is a copy of a filled member of an online redo log group.

In Figure 11-7. Introduction to Logical Storage Structures Oracle Database allocates logical space for all data in the database. then the archiver process (ARCn) will archive one of these files. The redo records have all relevant metadata for the change. each of which describes a change to a data block. an update to a salary in the employees table generates a redo record that describes changes to the data segment block for the table. If the database is in ARCHIVELOG mode. A redo record is made up of a group of change vectors. Archiving is either automatic or manual and is only possible when the database is in ARCHIVELOG mode. If A_LOG1 is corrupted. including the following:      SCN and time stamp of the change Transaction ID of the transaction that generated the change SCN and time stamp when the transaction committed (if it committed) Type of operation that made the change Name and type of the modified data segment 12 Logical Storage Structures This chapter describes the nature of and relationships among logical storage structures. then the process can archive B_LOG1. and if automatic archiving is enabled. and the transaction table of the undo segments. At a physical level. and tablespaces. The archived redo log contains a copy of every group created since you enabled archiving. extents. the data . the undo segment data block. segments. Obtain information about the history of a database using the LogMiner utility (see "Oracle LogMiner") Archiving is the operation of generating an archived redo log file. These structures are created and recognized by Oracle Database and are not known to the operating system. See Also:   "Data File Recovery" Oracle Database Administrator's Guide to learn how to manage the archived redo log Structure of the Online Redo Log Online redo log files contain redo records. For example. An archived redo log file includes the redo entries and the log sequence number of the identical member of the online redo log group. files A_LOG1 and B_LOG1 are identical members of Group 1. The logical units of database space allocation are data blocks.

Figure 12-1 Logical and Physical Storage Description of "Figure 12-1 Logical and Physical Storage" Logical Storage Hierarchy Figure 12-2 shows the relationships among data blocks. a segment has two extents stored in different data files. and Data Blocks Within a Tablespace . Figure 12-2 Segments. Figure 12-1 is an entity-relationship diagram for physical and logical storage. and segments within a tablespace. The crow's foot notation represents a one-to-many relationship. In this example. extents. "Physical Storage Structures"). The data in the data files is stored in operating system stored in data files on disk (see Chapter 11. Extents.

A segment is a set of extents allocated for a specific database object. all extents for a segment are stored in the same tablespace. Thus. the 24 KB extent has 12 data blocks. Oracle Database stores data in data blocks. See Also: "Overview of Data Files" Logical Space Management Oracle Database must use logical space management to track and allocate the extents in a tablespace. Extents. the data for the employees table is stored in its own data segment. When a database object requires an extent. whereas each index for employees is stored in its own index segment. while the 72 KB extent has 36 data blocks. Data blocks are the smallest units of storage that Oracle Database can use or allocate. An extent is a set of logically contiguous data blocks allocated for storing a specific type of information.Description of "Figure 12-2 Segments. One logical data block corresponds to a specific number of bytes of physical disk space. as shown in Figure 12-2. A single extent can never span data files. and Data Blocks Within a Tablespace" At the finest level of granularity.dbf. For example. Within a tablespace. while another is stored in users02. For example. In Figure 12-2. a segment can include extents from multiple data files. for example. the database must have a method of .dbf. 2 KB. Each segment belongs to one and only one tablespace. one extent for a segment may be stored in users01. such as a table. Every database object that consumes storage consists of a single segment.

Each bit corresponds to a group of blocks. Figure 12-3 shows the alternatives for logical space management in a tablespace. Oracle Database manages space within a tablespace based on the type that you create. the database must have a method of making the free extent available. You can create either of the following types of tablespaces:  Locally managed tablespaces (default) The database uses bitmaps in the tablespaces themselves to manage extents. Figure 12-3 Logical Space Management Description of "Figure 12-3 Logical Space Management" Locally Managed Tablespaces A locally managed tablespace maintains a bitmap in the data file header to track free and used space in the data file body. the database can manage segments with automatic segment space management (ASSM) or manual segment space management (MSSM). A 1 in the header refers to used space. .finding and providing it.  Dictionary-managed tablespaces The database uses the data dictionary to manage extents (see "Overview of the Data Dictionary"). Similarly. whereas a 0 refers to free space. locally managed tablespaces have a part of the tablespace set aside for a bitmap. When space is allocated or freed. Thus. when an object no longer requires an extent. Oracle Database changes the bitmap values to reflect the new status of the blocks. The following graphic is a conceptual representation of bitmap-managed storage. Within a tablespace.

Segment space management is an attribute inherited from the tablespace that contains the segment.Description of the illustration cncpt332.  Determines the size of locally managed extents automatically Alternatively.  Tracks adjacent free space automatically In this way. the database can manage segments automatically . Note: Oracle strongly recommends the use of locally managed tablespaces with Automatic Segment Space Management.gif A locally managed tablespace has the following advantages:  Avoids using the data dictionary to manage extents Recursive operations can occur in dictionary-managed tablespaces if consuming or releasing space in an extent results in another operation that consumes or releases space in a data dictionary table or undo segment. Within a locally managed tablespace. all extents can have the same size in a locally managed tablespace and override object storage options. the database eliminates the need to coalesce free extents.

Manual Segment Space Management The legacy MSSM method uses a linked list called a free list to manage free space in the segment. As blocks are used. Only one crucial SQL parameter controls space allocation: PCTFREE. This parameter specifies the percentage of space to be reserved in a block for future updates (see "Percentage of Free Space in Data Blocks"). thereby reducing contention and waits. and FREELIST GROUPS. MSSM requires you to control space allocation with SQL parameters such as PCTUSED. As an illustration. For many standard workloads. locally managed tablespaces. The database checks a free list of the table for the first available block. if you set PCTUSED to 40 in a CREATE TABLE statement. For example. the database puts blocks on or removes blocks from the free list as needed. PCTUSED sets the percentage of free space that must exist in a currently used block for the database to put it on the free list. application performance with ASSM is better than the performance of a well-tuned application that uses MSSM. segments in tablespace users can be managed automatically while segments in tablespace tools are managed manually. and if the used space in the block is greater than or equal to PCTUSED. If the row cannot fit in the block. then you cannot insert rows into a block in the segment until less than 40% of the block space is used. then the database takes the block off the list and . a free list keeps track of blocks under the high water mark (HWM). In addition to PCTFREE. Bitmaps provide the following advantages:  Simplified administration ASSM avoids the need to manually determine correct settings for many storage parameters.  Dynamic affinity of space to instances in an Oracle Real Application Clusters (Oracle RAC) environment ASSM is more efficient and is the default for permanent. Automatic Segment Space Management The ASSM method uses bitmaps to manage space.or manually. Note: This chapter assumes the use of ASSM in all of its discussions of logical storage space. suppose you insert a row into a table. FREELISTS. which is the dividing line between segment space that is used and not yet used. For a database object that has free space. For example.  Increased concurrency Multiple transactions can search separate lists of free data blocks.

For example. if every used block in a segment is half full. Each group has a master free list that manages the individual process free lists in the group. and if PCTUSED is 40. If you delete rows from the block. As shown in Figure 12-4. can be significant. Oracle strongly recommends ASSM. especially for free list groups. Because of the difficulty of fine-tuning space allocation parameters. you can also create an object with one or more free list groups. then the database does not permit inserts into any of these blocks. Figure 12-4 Free List Groups Description of "Figure 12-4 Free List Groups" Managing segment space manually can be complex. In ASSM. You must adjust PCTFREE and PCTUSED to reduce row migration (see "Chained and Migrated Rows") and avoid wasting space. which can reduce contention.searches for another block. Each database session uses only one free list for the duration of its session. then the database places the block at the beginning of the free list. If so. PCTFREE determines whether a new row can be inserted into a block. which are collections of free lists. but it does not use free lists and ignores PCTUSED. In this way. then the database checks whether used space in the block is now less than PCTUSED. See Also:   Oracle Database Administrator's Guide to learn about locally managed tablespaces Oracle Database 2 Day DBA and Oracle Database Administrator's Guide to learn more about automatic segment space management . An object may have multiple free lists. Space overhead for free lists. multiple sessions performing DML on a table can use different lists.

not operating system blocks. An operating system block is the minimum unit of data that the operating system can read or write. and searches for free extents. Figure 12-5 shows that operating system blocks may differ in size from data blocks. In contrast. Locally managed tablespaces. Oracle Database updates tables in the data dictionary whenever an extent is allocated or freed for reuse. Figure 12-5 Data Blocks and Operating System Blocks . when a table needs an extent. Data Blocks and Operating System Blocks At the physical level. database data is stored in disk files made up of operating system blocks. The SQL that the database executes in the background to obtain space for database objects is recursive SQL. an Oracle block is a logical storage structure whose size and structure are not known to the operating system. For example. See Also: Oracle Database Administrator's Guide to learn how to migrate tablespaces from dictionary-managed to locally managed Overview of Data Blocks Oracle Database manages the logical storage space in the data files of a database in units called data blocks. Frequent use of recursive SQL can have a negative impact on performance because updates to the data dictionary must be serialized. avoid this performance problem. In this way. Oracle Database SQL Language Reference to learn about storage parameters such as PCTFREE and PCTUSED Dictionary-Managed Tablespaces A dictionary-managed tablespace uses the data dictionary to manage its extents. the database queries the data dictionary tables. which are the default. A data block is the minimum unit of database I/O. then it modifies one data dictionary table and inserts a row into another. If the database finds space. The database requests data in multiples of data blocks. also called Oracle blocks or pages. the database manages space by modifying and moving data.

The standard data block size for a database is 4 KB or 8 KB. If the size differs for data blocks and operating system blocks. If DB_BLOCK_SIZE is not set. The database block size cannot be changed except by re-creating the database. The logical separation of data blocks from operating system blocks has the following implications:   Applications do not need to determine the physical addresses of data on disk. . The size is set for the SYSTEM and SYSAUX tablespaces and is the default for all other tablespaces. then the default data block size is operating system-specific. The DB_BLOCK_SIZE initialization parameter sets the data block size for a database when it is created. then the data block size must be a multiple of the operating system block size. See Also:   Oracle Database Reference to learn about the DB_BLOCK_SIZE initialization parameter Oracle Database Administrator's Guide and Oracle Database Performance Tuning Guide to learn how to choose block sizes Tablespace Block Size You can create individual tablespaces whose block size differs from the DB_BLOCK_SIZE setting.Description of "Figure 12-5 Data Blocks and Operating System Blocks" When the database requests a data block. Database data can be striped or mirrored on multiple physical disks. Database Block Size Every database has a database block size. A nonstandard block size can be useful when moving a transportable tablespace to a different platform. the operating system translates this operation into a requests for data in permanent storage.

index. or table cluster data. the block overhead includes the following parts:  Block header This part contains general information about the block. Figure 12-6 shows the format of an uncompressed data block (see "Data Block Compression" to learn about compressed blocks). As shown in Figure 12-6. including disk address and segment type. The block overhead is not available to store user data. Figure 12-6 Data Block Format Description of "Figure 12-6 Data Block Format" Data Block Overhead Oracle Database uses the block overhead to manage the block itself. This format is similar whether the data block contains table. the block header contains active and historical transaction information. . For blocks that are transaction-managed.See Also: Oracle Database Administrator's Guide to learn how to specify a nonstandard block size for a tablespace Data Block Format Every data block has a format or internal structure that enables the database to track the data and free space in the block.

Some parts of the block overhead are fixed in size. On average. Multiple tables can store rows in the same block. a block that is currently empty but formerly had up to 50 rows continues to have 100 bytes allocated for the row directory. free space can also hold transaction entries when the header space is depleted.  Row directory For a heap-organized table. In data blocks allocated to segments that support transactional changes. The space required for transaction entries is operating system dependent.  Table directory For a heap-organized table. Each row piece has a row header and column data. However. Row Format The row data part of the block contains the actual data. A row is contained in one or more row pieces. Figure 12-7 The Format of a Row Piece . Oracle Database initially reserves space in the block header for transaction entries. every row has a row format that enables the database to track the data in the row. Figure 12-7 shows the format of a row.A transaction entry is required for every transaction that updates the block. such as table rows or index key entries. Just as every data block has an internal format. the block overhead totals 84 to 107 bytes. Oracle Database stores rows as variable-length records. this directory describes the location of rows in the data portion of the block. After space has been allocated in the row directory. the database does not reclaim this space after row deletion. this directory contains metadata about tables whose rows are stored in this block. The database reuses this space only when new rows are inserted in the block. but the total size is variable. Thus. transaction entries in most operating systems require approximately 23 bytes.

columns of type LONG are created last. For example.  Cluster keys for table clusters (see "Overview of Table Clusters") A row fully contained in one block has at least 3 bytes of row header. . then Oracle Database stores the row as one row piece. Column Data After the row header.Description of "Figure 12-7 The Format of a Row Piece" Row Header Oracle Database uses the row header to manage the row piece stored in the block. the column data section stores the actual data in the row. The row piece usually stores columns in the order listed in the CREATE TABLE statement. but this order is not guaranteed. A data block usually contains only one row piece per row. However. The row header contains information such as the following:   Columns in the row piece Pieces of the row located in other data blocks If an entire row can be inserted into a single data block. if all of the row data cannot be inserted into a single block or an update causes an existing row to outgrow its block. then the database stores the row in multiple row pieces (see "Chained and Migrated Rows").

then the space required to hold a value can grow and shrink with updates to the data. OOOOOOFFFBBBBBBRRR. Each row has a slot in the row directory of the data block header. Example 12-1 queries the ROWID pseudocolumn to show the extended rowid of the row in the employees table for employee 100. but is inferred from the file and block on which the data is stored. with the format divided into the following components:  OOOOOO . If the data type of a column is variable length. See Also: "Table Storage" and "Index Storage" Rowid Format Oracle Database uses a rowid to uniquely identify a row. and /. Internally. for each column in a row piece. Figure 12-8 ROWID Format Description of "Figure 12-8 ROWID Format" An extended rowid is displayed in a four-piece format. The encoding characters are A-Z. The slot points to the beginning of the row. +. An extended rowid includes a data object number. the rowid is a structure that holds information that the database needs to access a row. The space required depends on the data type. Example 12-1 ROWID Pseudocolumn SQL> SELECT ROWID FROM employees WHERE employee_id = 100. ROWID -----------------AAAPecAAFAAAABSAAA Figure 12-8 illustrates the format of an extended rowid. a-z. A rowid is not physically stored in the database. This rowid type uses a base 64 encoding of the physical address for each row.As shown in Figure 12-7. Oracle Database stores the column length and data separately. 0-9.

Assume that the rows in Example 12-2 are stored in a data block for the seven-column sales table. row movement is considered an update. If row movement is disabled.The data object number identifies the segment (data object AAAPec in Example 12-1). This section describes the format of data blocks that use compression. However.  BBBBBB The data block number identifies the block that contains the row (block AAAABS in Example 12-1).  FFF The tablespace-relative data file number identifies the data file that contains the row (file AAF in Example 12-1). have the same data object number. the database performs row movement as if the row were physically deleted and reinserted. two rows with identical block numbers could reside in different data files of the same tablespace. Note: Internally. Flashback Table operations. such as a table cluster. The format of a data block that uses basic and OLTP table compression is essentially the same as an uncompressed block. then a rowid can change if the row is exported and imported using Oracle Database utilities. The database replaces occurrences of these values with a short reference to the symbol table. A data object number is assigned to every database segment. Data Block Compression The database can use table compression to eliminate duplicate values in a data block (see "Table Compression"). shrink table operations. and so on. Schema objects in the same segment. The difference is that a symbol table at the beginning of the block stores duplicate values for the rows and columns. Block numbers are relative to their data file. Example 12-2 Rows in sales Table . the rowid can change in special circumstances. For example. After a rowid is assigned to a row piece. then the rowid can change because of partition key updates.  RRR The row number identifies the row in the block (row AAA in Example 12-1). not their tablespace. Thus. which has implications for triggers. if row movement is enabled.

the amount of free space between the row data and the block header decreases.1450 34005.23.2190.13770.25.%.15720.P.44.S.46750.%. Example 12-3 is a conceptual representation of the compression in which the symbol * replaces 29-NOV-00 and % replaces 9999.44.S.11. .120760.I.P.23.*. This free space can also shrink during updates.2376 9425. Thus.15720. Percentage of Free Space in Data Blocks The PCTFREE storage parameter is essential to how the database manages free space. This SQL parameter sets the minimum percentage of a data block reserved as free space for updates to existing rows. Example 12-3 OLTP Compressed Rows in sales Table 2190. as when changing a trailing null to a nonnull value. the database replaces duplicate values with a symbol reference.25-NOV-00.28-NOV-00. The database manages free space in the data block to optimize performance and avoid wasted space.1121 When basic or OLTP table compression is applied to this table.161 2225.9999.%.%. Note: This section assumes the use of automatic segment space management.29-NOV-00.1450 34005.29-NOV-00.13770.979 1675.161 2225. PCTFREE is important for preventing row migration and avoiding wasted space.4750.I.9999.19.1121 Table 12-1 conceptually represents the symbol table that maps symbols to values.S.*.25.25-NOV-00.2376 9425.S.4750.S.120760.979 1675.S.46750. Table 12-1 Symbol Table Symbol Value Column Rows * % 29-NOV-00 9999 3 5 958-960 956-960 Space Management in Data Blocks As the database fills a data block from the bottom up.9999.%.19.9999.29-NOV-00.*.28-NOV-00.9999.11.

leaving only 10% free. which is itself expanding downward toward the row data. Figure 12-9 PCTFREE Description of "Figure 12-9 PCTFREE" Note: This discussion does not apply to LOB data types. Figure 12-9 shows how a PCTFREE setting of 20 affects space management. The database adds rows to the block over time. You specify the PCTFREE parameter within a CREATE TABLE statement as follows: CREATE TABLE test_table (n NUMBER) PCTFREE 20. See "Overview of LOBs". The PCTFREE setting ensures that at least 20% of the data block is free. See Also: Oracle Database SQL Language Reference for the syntax and semantics of the PCTFREE parameter . the database prevents an INSERT statement from filling the block so that the row data and header occupy a combined 90% of the total block space.For example. For example. which do not use the PCTFREE storage parameter or free lists. assume that you create a table that will require only occasional updates. causing the row data to grow upwards toward the block header. most of which will not increase the size of the existing data.

Optimization of Free Space in Data Blocks While the percentage of free space cannot be less than PCTFREE. The space released is available for INSERT statements under the following conditions:   If the INSERT statement is in the same transaction and after the statement that frees space. but permits 50% of the block to be free space. Figure 12-10 Data Block with Fragmented Space . which may result in the block having more free space. the amount of free space can be greater. as shown in Figure 12-10. then the statement can use the space made available only after the other transaction commits and only if the space is needed. then the database invokes block compression. If the INSERT statement is in a separate transaction from the statement that frees space (perhaps run by another user). a PCTFREE setting of 20% prevents the total amount of free space from dropping to 5% of the block. The following SQL statements can increase free space:    DELETE UPDATE statements statements that either update existing values to smaller values or increase existing values and force a row to migrate INSERT statements on a table that uses OLTP compression If inserts fill a block with data. then the statement can use the space. Noncontiguous free space is called fragmented space. For example. See Also: Oracle Database Administrator's Guide to learn about OLTP compression Coalescing Fragmented Space Released space may or may not be contiguous with the main area of free space in a data block.

The free space is fragmented so that the row piece cannot be inserted in a contiguous section of the block. Figure 12-11 shows a data block after space has been coalesced.Description of "Figure 12-10 Data Block with Fragmented Space" Oracle Database automatically and transparently coalesces the free space of a data block only when the following conditions are true:   An INSERT or UPDATE statement attempts to use a block that contains sufficient free space to contain a new row piece. Figure 12-11 Data Block After Coalescing Free Space . but the space is now contiguous. the amount of free space is identical to the amount before the operation. After coalescing.

Description of "Figure 12-11 Data Block After Coalescing Free Space"

Oracle Database performs coalescing only in the preceding situations because otherwise performance would decrease because of the continuous coalescing of the free space in data blocks.
Reuse of Index Space

The database can reuse space within an index block. For example, if you insert a value into a column and delete it, and if an index exists on this column, then the database can reuse the index slot when a row requires it. The database can reuse an index block itself. Unlike a table block, an index block only becomes free when it is empty. The database places the empty block on the free list of the index structure and makes it eligible for reuse. However, Oracle Database does not automatically compact the index: an ALTER INDEX REBUILD or COALESCE statement is required. Figure 12-12 represents an index of the employees.department_id column before the index is coalesced. The first three leaf blocks are only partially full, as indicated by the gray fill lines. Figure 12-12 Index Before Coalescing

Description of "Figure 12-12 Index Before Coalescing"

Figure 12-13 shows the index in Figure 12-12 after the index has been coalesced. The first two leaf blocks are now full, as indicated by the gray fill lines, and the third leaf block has been freed. Figure 12-13 Index After Coalescing

Description of "Figure 12-13 Index After Coalescing"

See Also:
 

Oracle Database Administrator's Guide to learn how to coalesce and rebuild indexes Oracle Database SQL Language Reference to learn about the COALESCE statement

Chained and Migrated Rows

Oracle Database must manage rows that are too large to fit into a single block. The following situations are possible:

The row is too large to fit into one data block when it is first inserted. In row chaining, Oracle Database stores the data for the row in a chain of one or more data blocks reserved for the segment. Row chaining most often occurs with large rows. Examples include rows that contain a column of data type LONG or LONG RAW, a VARCHAR2(4000) column in a 2 KB block, or a row with a huge number of columns. Row chaining in these cases is unavoidable.

if you insert a row into a table that has 1000 columns.  A row has more than 255 columns. assuming the row can fit in a new block. Oracle Database can only store 255 columns in a row piece. then the database creates 4 row pieces. The original row piece of a migrated row contains a pointer or "forwarding address" to the new block containing the migrated row. The row is too large for the left block. typically chained over multiple blocks. Figure 12-14 depicts shows the insertion of a large row in a data block. Figure 12-14 Row Chaining Description of "Figure 12-14 Row Chaining" Figure 12-15. but insufficient free space exists to hold the updated row. Figure 12-15 Row Migration . The rowid of a migrated row does not change. 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. Thus. A row that originally fit into one data block is updated so that the overall row length increases. 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. In row migration. Oracle Database moves the entire row to a new data block.

the I/O needed to retrieve the data increases. For example. is an Oracle Database component that identifies segments that have space available for reclamation. This situation results because Oracle Database must scan multiple blocks to retrieve the information for the row. See Also:    "Row Storage" and "Rowids of Row Pieces" Oracle Database 2 Day DBA and Oracle Database Administrator's Guide to learn how to reclaim wasted space Oracle Database Performance Tuning Guide to learn about reducing chained and migrated rows Overview of Extents An extent is a logical unit of database storage space allocation made up of contiguous data blocks. Allocation of Extents . which can be run both manually and automatically. The Segment Advisor. The advisor can offer advice about objects that have significant free space or too many chained rows.Description of "Figure 12-15 Row Migration" When a row is chained or migrated. then an additional I/O is required to obtain the data for a migrated row. if the database performs one I/O to read an index and one I/O to read a nonmigrated table row. Data blocks in an extent are logically contiguous but can be physically spread out on disk because of RAID striping and file system implementations.

Extents for a segment are always in the same tablespace but may be in different data files.dbf. and if more space is required.dbf. then the database looks in another data file. For example. An extent is always contained in one data file. In the locally managed case. Figure 12-16 shows the initial extent in a segment in a data file that previously contained no data. The first data block of every segment contains a directory of the extents in the segment. Although no data has been added to the segment. An incremental extent is a subsequent extent created for the segment.By default.dbf. Figure 12-16 Initial Extent of a Segment Description of "Figure 12-16 Initial Extent of a Segment" If the initial extent become full. the segment can allocate the initial extent in users01. the database allocates an initial extent for a data segment when the segment is created. Figure 12-17 shows that the database can allocate extents for a segment in any data file in the tablespace. and allocate the next extent in users01. Figure 12-17 Incremental Extent of a Segment . the data blocks in the initial extent are reserved for this segment exclusively. The allocation algorithm depends on whether the tablespace is locally managed or dictionarymanaged. the database searches the bitmap of a data file for adjacent free blocks. then the database automatically allocates an incremental extent for this segment. allocate the first incremental extent in users02. If the data file has insufficient space.

In some circumstances. Oracle Database formats the blocks of a newly allocated extent when it starts using the extent. The Oracle Segment Advisor helps determine whether an object has space available for reclamation based on the level of fragmentation in the object. although they were free. which entail multiple server processes. Deallocation of Extents In general. you can also drop the segment using the DBMS_SPACE_ADMIN package. may not be empty of old data.2. Note: In an undo segment. but only as needed (see "Segment Space and the High Water Mark").2). Extents are allocated differently in parallel SQL statements. if you delete all rows in a table. In ASSM. The following techniques can free extents: . the extents of a user segment do not return to the tablespace unless you drop the object using a DROP command. Note: This section applies to serial operations. For example. In Oracle Database 11g Release 2 (11. in which one server process parses and runs a statement.0. you can manually deallocate space. then the database does not reclaim the data blocks for use by other objects in the tablespace. Oracle Database periodically deallocates one or more extents if it has the OPTIMAL size specified or if the database is in automatic undo management mode (see "Undo Tablespaces").Description of "Figure 12-17 Incremental Extent of a Segment" The blocks of a newly allocated extent.

Tablespace storage clause 3. Segment shrink is an online. For automatically allocated extents. You can rebuild or coalesce the index (see "Reuse of Index Space"). You can deallocate unused space. Oracle Database default A locally managed tablespace can have either uniform extent sizes or variable extent sizes determined automatically by the system:   For uniform extents. These parameters control how Oracle Database allocates free space for a segment. Segment storage clause 2. data compaction leads to better cache utilization and requires fewer blocks to be read in a full table scan. Oracle Database determines the optimal size of additional extents. . you can also use TRUNCATE with the DROP ALL STORAGE option to drop entire segments. Locally managed temporary tablespaces can only use this type of allocation.2. You can move the data of a nonpartitioned table or table partition into a new segment. However. Oracle Database modifies the bitmap in the data file for locally managed tablespaces to reflect the regained extents as available space.0. you can specify these parameters at the segment level. In this case.     You can use an online segment shrink to reclaim fragmented space in a segment. All extents in the tablespace are of this size.2). When extents are freed. The storage settings are determined in the following order of precedence. you can specify an extent size or use the default size of 1 MB. some storage parameters cannot be specified at the tablespace level. In Oracle Database 11g Release 2 (11. Any data in the blocks of freed extents becomes inaccessible. You can truncate a table or table cluster. which frees the unused space at the high water mark end of the database segment and makes the space available for other segments in the tablespace (see "Segment Space and the High Water Mark"). which removes all rows. and optionally into a different tablespace for which you have quota. Internal algorithms determine the subsequent size of each extent. In general. Storage Parameters for Extents Every segment is defined by storage parameters expressed in terms of extents. Oracle Database deallocates all space used by the removed rows except that specified by the MINEXTENTS storage parameter. By default. in-place operation. the databases uses all parameters together to compute the initial size of the segment. with setting higher on the list overriding settings lower on the list: 1. For locally managed tablespaces.

Sign up to vote on this title
UsefulNot useful