Oracle Database Architecture

Oracle Database Architecture


Oracle Architecture :-
 
Oracle Architectural Components:
Objectives:
 
This is introduces the Oracle server architecture by examining the physical, memory,process, and logical structures involved in establishing a database connection, creating a session, and executing SQL commands.

Oracle is a Relational Database Management System (RDBMS), which uses Relational Data Model to store its database and SQL (commonly abbreviated as Structured Query Language) to process the stored data. The architecture of Oracle system can be best explained in terms of client/server paradigm. Thus, we will explain the architecture of Oracle server using the structure called instance..

An oracle instance is a complex set of memory structures and operating system processes. It is the Oracle instance, which manages all database activities, such as transaction processing, database recovery, form generation, and so on. The instance structure is loosely styled after UNIX's implementation of multitasking operating system. Discrete processes perform specialized tasks within the RDBMS that work together to accomplish the goals of the instance. Each process has a separate memory block that it uses to store local and private variables, address stacks and other runtime information. The processes use a common shared memory area for processing data concurrently. This memory block is called the System Global Area (SGA). Figure 1 illustrates the architecture of an instance.
















System Global Area (SGA)

The SGA is the primary memory component of the instance. It provides memory structure necessary for data manipulation, SQL statement parsing, and redo caching. The SGA is shared, which means that the multiple processes can access and modify the data contained in it in a synchronized manner. The SGA consists of the following components:
  • Shared Pool
  • Database buffer cache
  • Redo Log Buffer
Multithread server(MTS) structures.










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   This information includes both organizational data and control information used by the Oracle Server. 
o   The SGA is allocated in memory and virtual memory. 
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. 
 
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). 
 
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   Data Dictionary Cache
·        Other structures (for example, lock and latch management, 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 is a recent clip of the SGA for the DBORCL database at SIUE. 
·        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).
SQL> connect / as sysdba
Connected.
SQL> show sga
 
Total System Global Area 1610612736 bytes
Fixed Size                  2084296 bytes
Variable Size            1006633528 bytes
Database Buffers          587202560 bytes
Redo Buffers               14692352 bytes
 
Early versions of Oracle used a Static SGA.  This meant that if modifications to memory management were required, the database had to be shutdown, modifications were made to the init.ora parameter file, and then the database had to be restarted.  
 
Oracle 11g uses a Dynamic SGA.   Memory configurations for the system global area can be made without shutting down the database instance.  The DBA can resize the Database Buffer Cache and Shared Pool dynamically. 
 
Several initialization parameters are set that affect the amount of random access memory dedicated to the SGA of an Oracle Instance.  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 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, either explicitly in the parameter file or by default, at the time the instance is initialized, then the database ignores the setting for SGA_MAX_SIZE.  For optimal performance, the entire SGA should fit in real memory to eliminate paging to/from disk by the operating system.
·        DB_CACHE_SIZE:  This optional parameter is used to tune the amount memory allocated to the Database Buffer Cache in standard database blocks.  Block sizes vary among operating systems.  The DBORCL database uses 8 KB blocks.  The total blocks in the cache defaults to 48 MB on LINUX/UNIX and 52 MB on Windows operating systems.
·        LOG_BUFFER:   This optional parameter specifies the number of bytes allocated for the Redo Log Buffer. 
·        SHARED_POOL_SIZE:  This optional parameter specifies the number of bytes of memory allocated to shared SQL and PL/SQL.  The default is 16 MB.  If the operating system is based on a 64 bit configuration, then the default size is 64 MB.
·        LARGE_POOL_SIZE:  This is an optional memory object – the size of the Large Pool defaults to zero.  If the init.ora parameter PARALLEL_AUTOMATIC_TUNING is set to TRUE, then the default size is automatically calculated.
·        JAVA_POOL_SIZE:   This is another optional memory object.  The default is 24 MB of memory.
 
The size of the SGA cannot exceed the parameter SGA_MAX_SIZE minus the combination of the size of the additional parameters, DB_CACHE_SIZELOG_BUFFERSHARED_POOL_SIZELARGE_POOL_SIZE, and JAVA_POOL_SIZE.
 
Memory is allocated to the SGA as contiguous virtual memory in units termed granules.  Granule size depends on the estimated total size of the SGA, which as was noted above, depends on the SGA_MAX_SIZE parameter.  Granules are sized as follows:
·        If the SGA is less than 1 GB in total, each granule is 4 MB.
·        If the SGA is greater than 1 GB in total, each granule is 16 MB.
 
Granules are assigned to the Database Buffer Cache, Shared Pool, Java Pool, and other memory structures, and these memory components can dynamically grow and shrink.  Using contiguous memory improves system performance.  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 minimum is 3 granules:  one each for the fixed SGA, Database Buffer Cache, and Shared Pool.  In practice, you'll find the SGA is allocated much more memory than this.  The SELECT statement shown below shows a current_size of 1,152 granules.
 
SELECT name, block_size,current_size,prev_size,prev_buffers
FROM v$buffer_pool;

NAME     BLOCK_SIZE CURRENT_SIZE  PREV_SIZE PREV_BUFFERS
-------- ---------- ------------ ---------- ------------
DEFAULT  8192       560           576       71244 

Shared pool

The Oracle shared pool contains Oracle's library cache, which is responsible for collecting, parsing, interpreting, and executing all of the SQL statements that go against the Oracle database. Hence, the shared pool is a key component, so it's necessary for the Oracle database administrator to check for shared pool contention.
The shared pool is like a buffer for SQL statements.  Oracle's parsing algorithm ensures that identical SQL statements do not have to be parsed each time they're executed.  The shared pool  is used to store SQL statements, and it includes the following components:
Since it is not possible to dedicate separate regions of memory for the shared pool components, the shared pool is usually the second-largest SGA memory area (depending on the size of the db_cache_size parameter). The shared pool contains RAM memory regions that serve the following purposes:
 
• Library cache – The library cache contains the current SQL execution plan information. It also holds stored procedures and trigger code.

• Dictionary cache - The dictionary cache stores environmental information, which includes referential integrity, table definitions, indexing information, and other metadata stored within Oracle's internal tables.

• Session information – Systems that use SQL*Net version 2 with a multi-threaded server need this area to store session information. Beginning with Oracle, the v$session view contains information related to Oracle*Net users.
The following table lists the different areas stored in the shared pool and their purpose:
Shared SQL Area - The shared SQL area stores each SQL statement executed in the database. This area allows SQL execution plans to be reused by many users.
Private SQL Area - Private SQL areas are non-shared memory areas assigned to unique user sessions.
PL/SQL Area - Used to hold parsed and compiled PL/SQL program units, allowing the execution plans to be shared by many users.
Control Structures - Common control structure information, for example, lock information.

Database Buffer Cache
 
The database buffer cache holds copies of data blocks read from the data files. The term data block is used to describe a block containing table data, index data, clustered data, and so on. Basically, it is a block that contains data. All user processes concurrently connected to the instance share access to the database buffer cache. The database buffer cache is logically segmented into multiple sets. This reduces contention on multiprocessor systems.
This area of the SGA contains only the buffers themselves and not their control structures. For each buffer, there is a corresponding buffer header in the variable area of the SGA.
 
Program Global Area (PGA)

A Program Global Area (PGA) is a memory region that contains data and control information for a server process. It is a non-shared memory region created by Oracle when a server process is started. Access to the PGA is exclusive to that server process and it is read and written only by Oracle code acting on its behalf. It contains a private SQL area and a session memory area.
A private SQL area contains data such as bind information and runtime memory structures. Each session that issues a SQL statement has a private SQL area. Session memory is the memory allocated to hold a session’s variables (logon information) and other information related to the session. For a shared server, the session memory is shared and not private.
 
Buffer Cache Management
 
The database buffer cache is organized in two lists: the write list and the least-recently-used (LRU) list. The write list holds dirty buffers, which contain data that has been modified but has not yet been written to disk. The LRU list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the write list. Free buffers do not contain any useful data and are available for use. Pinned buffers are buffers that are currently being accessed.
When an Oracle process requires data, it searches the buffer cache, finds the data blocks, and then uses the data. This is known as a cache hit. If it cannot find the data, then it must be obtained from the data file. In this case, it finds a free buffer to accommodate the data block by scanning the LRU list, starting at the least-recently-used from the end of the list. The process searches either until it finds a free buffer or until it has searched the threshold limit of buffers.
When the user process is performing a full table scan, it reads the data blocks into buffers and places them on the LRU end instead of the MRU end of the LRU list. This is because a fully scanned table is usually needed only briefly and the blocks should be moved out quickly.

What Is a Dirty Block?

Whenever a server process changes or modifies a data block, it becomes a dirty block. Once a server process makes changes to the data block, the user may commit transactions, or transactions may not be committed for quite some time. In either case, the dirty block is not immediately written back to disk.
Writing dirty blocks to disk takes place under the following two conditions:
* When a server process cannot find a clean, reusable buffer after scanning a threshold number of buffers, then the database writer process writes the dirty blocks to disk.
* When the checkpoint takes place, the database writer process writes the dirty blocks to disk.

Large Pool 

Oracle Large Pool is an optional memory component of the oracle database SGA. This area is used for providing large memory allocations in many situations that arise during the operations of an oracle database instance.

1. Session memory for the a shared server and the Oracle XA Interface when distributed transactions are involved

2. I/O Server Processes

3. Parallel Query Buffers

4. Oracle Backup and Restore Operations using RMAN

Large Pool plays an important role in Oracle Database Tuning since the allocation of the
 memory for the above components otherwise is done from the shared pool. Also due to the large memory requirements for I/O and Rman operations, the large pool is better able to satisfy the requirements instead of depending on the Shared Pool Area.

Usage of a Large Pool Area allows the shared pool to primarily cache SQL and avoid the overhead casued by shrinking the SQL Cache Area
 
JAVA Pool

The JAVA Pool holds the JAVA execution code in a similar manner to the PL/SQL cache in the shared pool. The JAVA pool is used by many internal routines, such as import and export, and should be sized at approximately 60 megabytes if no other JAVA will be utilized in the user applications

The Redo Log Buffer
 
The redo log buffer is a RAM area (defined by the initialization parameter log_buffer) that works to save changes to data, in case something fails and Oracle has to put it back into its original state (a “rollback”).  When Oracle SQL updates a table (a process called Data Manipulation Language, or DML), redo images are created and stored in the redo log buffer. Since RAM is faster than disk, this makes the storage of redo very fast.
 
The Oracle redo log buffer provides the following functions within the Oracle SGA:
  • Serves for assistance with database recovery tasks
  • Records all changes made to database blocks
  • Places changes recorded to redo entries for redo logs
The database initialization parameter log_buffer defines the default size of the redo log buffer within Oracle 11g.
 
Redo log files:

Redo logs are transaction journals. Each transaction is recorded in the redo logs. Redo logs are used in a serial fashion with each transaction queuing up in the redo log buffers and being written one at a time into the redo logs. Redo logs as a general rule should switch about every thirty minutes. However, you may need to adjust the time up or down depending on the importance of your data. The rule of thumb is to size the redo logs such that you only loose the amount of data you can stand to loose should for some reason the online redo log become corrupt. With modern Oracle redo log mirroring and with disk array mirroring and various forms of online disk repair and replacement the occurrence of redo log corruptions has dropped to practically zero, so size based on the number of archive logs you want to apply should the database fail just before your next backup.
The LOG_BUFFER_SIZE and LOG_BUFFERS parameters control the redo log buffers. The LOG_BUFFER_SIZE should be set to reduce the number of writes required per redo log but not be so large that it results in an excessive IO wait time. Some studies have shown that sizing bigger than one megabyte rarely results in performance gains. Generally I size the LOG_BUFFER_SIZE such that it is equal to or results in an even divisor of the redo log size.
Monitor redo logs using the alert log, V$LOGHIST, V$LOGFILE, V$RECOVERY_LOG and V$LOG DPTs.
 
Control files
 
Control files are created when the database is created. Control file size is determined by a number of initialization parameters and really shouldn’t concern you. However, if you are using raw devices for control files make sure the raw partition is sized to allow the control file to grow in Oracle8 and Oracle8i databases as backup information is added. Each database instance must have at least one control file of it will not start. Loss of all control files will cause the database to crash. Have at least two copies on physically separate disk arrays or devices.
I suggest maintaining a script to rebuild your control files. The control file rebuild script should be recreated after each physical change to the database. The command CREATE CONTROLFILE is used to manually create a controlfile. However, the ALTER DATABASE BACKUP CONTROL FILE TO TRACE command is the preferred method to generate a script that can be used to rebuild the control file if it becomes damaged.
 
Initialization File
 
Although not normally discussed as a database file a database will not startup without a valid initialization parameter file. The file is only read at startup and contains the information required to set up the SGA, control file locations, trace and dump file locations and setup parameters for multi-threaded server, parallel query and Oracle Parallel Server. I suggest keeping a copy in a secure place incase yours ever becomes corrupted, deleted or damaged. The Oracle Reference, which is included in the Oracle8 and Oracle8i documentation set, provides descriptions of all initialization parameters. There are also undocumented initialization parameters that allow specialized behaviors to be configured. Both the documented and undocumented initialization parameters are covered in my book “ORACLE8i Administration and Management” from Wiley and Sons.
It should be obvious that the most important file regarding database setup and operation is probably the INIT.ORA, or initialization file. This file contains the assignments for the database initialization parameters.

 
NAME
VALUE
DESCRIPTION
O7_DICTIONARY_ACCESSIBILITY
TRUE
V7 Dictionary accessibility  Support (Migration only)
ALWAYS_ANTI_JOIN
NESTED_LOOPS
Always use this anti-join when possible
ALWAYS_SEMI_JOIN
standard
Always use this semi-join when possible
AQ_TM_PROCESSES
0
Number of AQ Time Managers to start
AUDIT_FILE_DEST
(PD)
Destination for audit files
AUDIT_TRAIL
NONE
Enable system auditing
BACKGROUND_CORE_DUMP
PARTIAL
Sets whether SGA is dumped with core file dump,   PARTIAL means don't dump SGA.
BACKGROUND_DUMP_DEST
(PD)
Detached process dump directory
BACKUP_TAPE_IO_SLAVES
FALSE
BACKUP Tape I/O slaves
BITMAP_MERGE_AREA_SIZE
1048576
Maximum memory allow for BITMAP MERGE
BLANK_TRIMMING
FALSE
Blank trimming semantics parameter
BUFFER_POOL_KEEP
0
Number of database blocks/latches in KEEP buffer pool             
BUFFER_POOL_RECYCLE
0
Number of database blocks/latches in recycle buffer pool
COMMIT_POINT_STRENGTH
1
Bias this node has toward not preparing in a two-phase commit
COMPATIBLE
8.1.0
 Database will be compatible with this software version
CONTROL_FILE_RECORD_KEEP_TIME
7
Control file record keep time in days
CONTROL_FILES
(PD)
Control file names list
CORE_DUMP_DEST
(PD)
Destination for core dump files.
CPU_COUNT
(PD)
Number of cpu's for this instance
CREATE_BITMAP_AREA_SIZE
8388608
Size of create bitmap buffer for bitmap index
CURSOR_SPACE_FOR_TIME
FALSE
Use more memory in order to get faster execution
DB_BLOCK_BUFFERS
8000
Number of database blocks  cached in memory
DB_BLOCK_CHECKING
TRUE
 Data and index block checking overrides events 10210 and 10211
DB_BLOCK_CHECKSUM
FALSE
Store checksum in db blocks and check during reads
DB_BLOCK_LRU_LATCHES
1|CPU_COUNT/2
Number of lru latches
DB_BLOCK_MAX_DIRTY_TARGET
DB_BLOCK_BUFFERS
Upper bound on modified buffers/recovery reads
DB_BLOCK_SIZE
(PD)
Size of database block in bytes
DB_DOMAIN
WORLD
Directory part of global database name stored with CREATE DATABASE
DB_FILE_DIRECT_IO_COUNT
64
Sequential I/O block count
DB_FILE_MULTIBLOCK_READ_COUNT
8
Db blocks read for each IO
DB_FILE_NAME_CONVERT
NULL
 Datafile name convert pattern and string for standby/clone database
DB_FILES
MAXDATAFILES
Max allowable # db files
DB_NAME
(PD)
Database name specified in CREATE DATABASE
DB_WRITER_PROCESSES
1
Number of background database writer processes to start
DBLINK_ENCRYPT_LOGIN
FALSE
Enforce password for distributed login always be encrypted
DBWR_IO_SLAVES
0
Number of DBWR I/O slaves
DELAYED_LOGGING_BLOCK_CLEANOUTS
TRUE
Turns delayed block cleanout on or off
DISK_ASYNCH_IO
TRUE
Use asynch I/O for random access devices
DISTRIBUTED_TRANSACTIONS
(PD)
Max. number of concurrent distributed transactions
DML_LOCKS
4*Trans.
Dml locks - one for each table modified in a transaction
ENQUEUE_RESOURCES
Derived
Resources for enqueues
EVENT
NULL
Debug event control
FIXED_DATE
NULL
Fixed SYSDATE value
FREEZE_DB_FOR_FAST_INSTANCE_RECOVERY
FALSE
Freeze database during instance recovery (OPS)
GC_DEFER_TIME
10
How long to defer down converts for hot buffers (DFS)(OPS)
GC_FILES_TO_LOCKS
NULL
Mapping between file numbers and lock buckets  (DFS)(OPS)
GC_RELEASABLE_LOCKS
0
Number of releasable locks (DFS)(OPS)
GC_ROLLBACK_LOCKS
20
Locks for the rollback segments (DFS)(OPS)
GLOBAL_NAMES
TRUE
Enforce that database links have same name as remote database
HASH_AREA_SIZE
2*SORT
Size of in-memory hash work area
HASH_JOIN_ENABLED
TRUE
Enable/disable hash join
HASH_MULTIBLOCK_IO_COUNT
1
Number of blocks hash join will read/write at once
HI_SHARED_MEMORY_ADDRESS
0
SGA starting address (high order 32-bits on 64-bit platforms)
HS_AUTOREGISTER
TRUE
Enable automatic server DD updates in HS agent self-registration
IFILE
NULL
Include file in init.ora
INSTANCE_GROUPS
NULL
List of instance group names
INSTANCE_NAME
NULL
Instance name supported by the instance



INSTANCE_NUMBER
0
Instance number
JAVA_POOL_SIZE
10000K
Size in bytes of the Java pool
JOB_QUEUE_INTERVAL
60
Wakeup interval in seconds for job queue processes
JOB_QUEUE_KEEP_CONNECTIONS
FALSE
Keep network connections between execution of jobs
JOB_QUEUE_PROCESSES
0
Number of job queue  processes to start
LARGE_POOL_SIZE
0
Size in bytes of the large allocation pool (auto set at 600k)
LICENSE_MAX_SESSIONS
0
Maximum number of non-system user sessions allowed
LICENSE_MAX_USERS
0
Maximum number of named users that can be created in the database
LICENSE_SESSIONS_WARNING
0
Warning level for number of non-system user sessions
LM_LOCKS
12000
Number of locks configured for the lock manager (OPS)
LM_PROCS
64
Number of client processes configured for the lock manager (OPS)
LM_RESS
6000
Number of resources configured for the lock manager (OPS)                                      
LOCAL_LISTENER
NULL
Local listener
LOCK_NAME_SPACE
NULL
Lock name space used for generating lock names for standby/clone database
LOCK_SGA
FALSE
Lock entire SGA in physical memory
Oracle Database Structure:

• A database is collection of data files plus programs that manipulate those data files.
• Two types of information are stored in an Oracle database
• User data, relevant to a particular application and
• System data, that the database needs to manage itself

Components:

• Database files – contain all database data
• Control files – contain info to access and manipulate the data
• Redo Logs – record all the transactions on the database
• Tablespaces – logical divisions of a database
• Segments – set of database blocks
• Extents – allocation of contiguous space on disk exp in bytes.
 
Database files:

• An Oracle database consists of one or more database files.
• These files contain data that can be accessed with the help of SQL.
• A file can be associated with one and only one tablespace.
• The database when created initially, has only one physical file.
• The maximum number of files that can be opened at a time are 32 by default.
• One or more physical files form a logical unit called Tablespace.

Control files:

• A database’s overall physical architecture is maintained by its control files.
• These record control information about all the files within the database.
• A control file is associated with a single database
• Control files are automatically modified by Oracle; a user cannot edit them.
• They are used to maintain internal consistency and guide recovery operations.

Redo Log files:

• A Redo Log contains all the transactions that have occurred against the database.
• No activity in the database can take place without being recorded in Redo Logs.
• The Redo Logs are necessary to protect against data loss.
• Redo Logs are also called transaction logs.
• Every database requires a minimum of two Redo Logs.
 
• These are used in recovery operations to restore lost or damaged files.

Oracle Processes:
 
The front-line support for Oracle backup and recovery is the Oracle architecture. One part
of this architecture is the processes related to the Oracle database. Although the Oracle
database has a number of processes, only a few really matter with respect to backup and
recovery and will be mentioned in this text. These processes are as follows:
 
SMON
PMON
CKPT
LGWR
DBWR
ARCH
User processes
 
Let’s discuss each of these processes next so you can better understand how they impact
database recovery.
 
SMON (System Monitor):
 
SMON (System MONitor) is an Oracle background process created when you start a database instance. The SMON process performs instance recovery, cleans up after dirty shutdowns and coalesces adjacent free extents into larger free extents.
When you startup your Oracle database, Oracle will perform several checks to see if the database is healthy. SMON manages your database for you!
If Oracle finds a problem at startup time, the System Monitor process (SMON) will perform recovery activities. SMON also performs certain types of database maintenance. These activities occur in the background and have no real impact on normal database operations.
 
Performs multiple maintenance tasks, including the following:
• Creates and manages the temporary tablespace metadata
• Reclaims space used by orphaned temp segments
• Maintains the undo tablespace by on-lining, off-lining, and shrinking undo segments based on undo space usage statistics
• Cleans up the data dictionary when in a transient and inconsistent state
• Maintains the SCN to time mapping table used to support Flashback
 
 PMON (Process Monitor):

Process Monitor process recovers failed process resources. If MTS (also called Shared Server Architecture) is being utilized, PMON monitors and restarts any failed dispatcher or server processes. In RAC, PMON’s role as service registration agent is particularly important.
• The Process Monitor is the janitor of the database, cleaning-up trash left-over from aborted user sessions (for instance, if a client abnormally disconnects from the database). If this should happen, it is the job of the Process Monitor (PMON) process to cleanup after that failure. PMON will cleanup memory areas and other database resources that were in use by that user process. PMON constantly checks the status of user and database processes. In some cases, failed database processes can be restarted by PMON.

LGWR Process

The log writer process (LGWR) is responsible for keeping the online redo logs up-to-date. The
job of the LGWR process is to move redo from the volatile (nonpersistent) redo log buffer in
the System (sometimes called Shared) Global Area (SGA) to the persistence of the online redo
logs. A number of different things cause LGWR to wake up and write the redo data, among
them commits and when the redo log buffer fills to a certain point.

DBWR Process

The database writer process DBWn is responsible for writing to the database datafiles.
This writing occurs during events called checkpoints. A database checkpoint may, in reality,
happen at just about any time while the database is running. DBWR has very little
to do with recovery of the database (other than to support it by writing to the datafiles)
because database datafile writes are often delayed and the blocks within the datafiles themselves
are not consistent with the current state of the data inside of the SGA.

ARCH Process

The archiver process ARCn is responsible for the creation of archived redo logs. In a later
section in this chapter on redo logs, we will discuss how redo logs are filled with redo. Once
the redo log file fills, a log switch occurs and Oracle will begin to write to the next online
redo log. If the database is in ARCHIVELOG mode (see the section “NOARCHIVELOG
and ARCHIVELOG Modes”), the ARCH process will be responsible for taking that filled
archived redo log and copying it to one or more backup locations.
In Oracle Database 11g, the ARCH process starts automatically. Oracle can also start
more than one ARCH process if multiple redo logs need to be archived. For ARCH to work
properly, you will need to configure the appropriate archiving locations (see “Configuring the
Database for Backup and Recovery” later in this chapter for more). The ARCH process is so
vital to backup and recovery of the database that if it cannot copy the archived redo logs to the
mandatory archived log destinations, the database will eventually stall until the problem
is corrected.

User Processes

At first glance, it might seem that the user processes are not all that important to backup and
recovery. As you will see, user processes are actually an integral part of backup and recovery
since you have to be able to connect to the database instance to actually do a database backup
or recovery.
 
Tablespaces:

• A database is divided into logical divisions called tablespaces
• A database may have one or more tablespaces
• Each logical tablespace corresponds to one or more physical database files.

•The typical tablespace present in an Oracle database are (11g) :

SYSTEM Tablespace:
 
• Every Oracle database contains a tablespace named SYSTEM, which Oracle creates automatically when the database is created. The SYSTEM tablespace is always online when the database is open.
To take advantage of the benefits of locally managed tablespaces, you can create a locally managed SYSTEM tablespace, or you can migrate an existing dictionary managed SYSTEM tablespace to a locally managed format.
 
In a database with a locally managed SYSTEM tablespace, dictionary tablespaces cannot be created. It is possible to plug in a dictionary managed tablespace using the transportable feature, but it cannot be made writable.
 
• The SYSTEM tablespace always contains the data dictionary tables for the entire database. The data dictionary tables are stored in datafile 1.
 
Note: Once a tablespace is locally managed, it cannot be reverted back to being dictionary managed.
 
SYSAUX Tablespace:

• The SYSAUX tablespace is always created at database creation. The SYSAUX tablespace serves as an auxiliary tablespace to the SYSTEM tablespace. Because it is the default tablespace for many Oracle Database features and products that previously required their own tablespaces, it reduces the number of tablespaces required by the database. It also reduces the load on the SYSTEM tablespace.
You can specify only datafile attributes for the SYSAUX tablespace, using the SYSAUX DATAFILE clause in the CREATE DATABASE statement. Mandatory attributes of the SYSAUX tablespace are set by Oracle Database and include:
  • PERMANENT
  • READ WRITE
  • EXTENT MANAGMENT LOCAL
  • SEGMENT SPACE MANAGMENT AUTO
You cannot alter these attributes with an ALTER TABLESPACE statement, and any attempt to do so will result in an error. You cannot drop or rename the SYSAUX tablespace.

Undo Tablespaces:

 Undo tablespaces are special tablespaces used solely for storing undo information. You cannot create any other segment types (for example, tables or indexes) in undo tablespaces. Each database contains zero or more undo tablespaces. In automatic undo management mode, each Oracle instance is assigned one (and only one) undo tablespace. Undo data is managed within an undo tablespace using undo segments that are automatically created and maintained by Oracle.
 
When the first DML operation is run within a transaction, the transaction is bound (assigned) to an undo segment (and therefore to a transaction table) in the current undo tablespace. In rare circumstances, if the instance does not have a designated undo tablespace, the transaction binds to the system undo segment.
 
• Each undo tablespace is composed of a set of undo files and is locally managed. Like other types of tablespaces, undo blocks are grouped in extents and the status of each extent is represented in the bitmap. At any point in time, an extent is either allocated to (and used by) a transaction table, or it is free.

Temporary Tablespace:
 
• When the SYSTEM tablespace is locally managed, you must define a default temporary tablespace when creating a database. A locally managed SYSTEM tablespace cannot be used for default temporary storage.
 
• If SYSTEM is dictionary managed and if you do not define a default temporary tablespace when creating the database, then SYSTEM is still used for default temporary storage. However, you will receive a warning inALERT.LOG saying that a default temporary tablespace is recommended and will be necessary in future releases.
 
USER Tablespace:  
 
• information about users is stored

No comments:

Post a Comment