Module 1 Oracle Architecture Objectives These notes introduce the Oracle server architecture.

. The architecture includes physical components, memory components, processes, and logical structures.

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. 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 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.

Other key files as noted above include: Parameter file there are two types of parameter files.

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

Memory Structure The memory structures include two areas of memory: System Global Area (SGA) this is allocated when an Oracle Instance starts up. Program Global Area (PGA) this is allocated when a Server Process starts up.

System Global Area The SGA is an area in memory 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 filethis 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 Oracle 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 Oracle 8i and earlier versions of the Oracle Server 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 9i, 10g, and 11g use a Dynamic SGA. Memory configurations for the system global area can be made without shutting down the database instance. The advantage is obvious. This allows the DBA to 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_SIZE, LOG_BUFFER, SHARED_POOL_SIZE, LARGE_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 For additional information on the dynamic SGA sizing, enroll in Oracle's Oracle10g Database Performance Tuning course. Automatic Shared Memory Management Prior to Oracle 10G, a DBA had to manually specify SGA Component sizes through the initialization parameters, such as SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE, and LARGE_POOL_SIZE parameters. Automatic Shared Memory Management enables a DBA to specify the total SGA memory available through the SGA_TARGET initialization parameter. The Oracle Database automatically distributes this memory among various subcomponents to ensure most effective memory utilization. The DBORCL database SGA_TARGET is set in the initDBORCL.ora file: sga_target=1610612736 With automatic SGA memory management, the different SGA components are flexibly sized to adapt to the SGA available. 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. No out of memory errors are generated unless the system has actually run out of memory. No manual tuning effort is needed.

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 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, then the SGA_MAX_SIZE value is bumped up to accomodate SGA_TARGET. When you set a value for SGA_TARGET, Oracle Database 10g automatically sizes the most commonly configured components, 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. The DBA must specify the sizes of these components explicitly, if they are needed by an application. 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, n = {2, 4, 8, 16, 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. 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. SQL> select * from v$sgainfo; More... NAME BYTES RES -------------------------------- ---------- --Fixed SGA Size 2084296 No Redo Buffers 14692352 No Buffer Cache Size 587202560 Yes Shared Pool Size 956301312 Yes Large Pool Size 16777216 Yes Java Pool Size 33554432 Yes Streams Pool Size 0 Yes Granule Size 16777216 No Maximum SGA Size 1610612736 No Startup overhead in Shared Pool 67108864 No Free SGA Memory Available 0 11 rows selected.

Shared Pool The Shared Pool is a memory structure that is shared by all system users. It consists of both fixed and variable structures. The variable component grows and shrinks depending on the demands placed on memory size by system users and application programs. Memory can be allocated to the Shared Pool by the parameter SHARED_POOL_SIZE in the parameter file. The default value of this parameter is 8MB on 32-bit platforms and 64MB on 64-bit platforms. Increasing the value of this parameter increases the amount of memory reserved for the shared pool. You can alter the size of the shared pool dynamically with the ALTER SYSTEM SET command. An example command is shown in the figure below. 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), and since the Shared Pool is part of the SGA, you cannot exceed the maximum size of the SGA. It is recommended to let Oracle optimize the Shared Pool size. The Shared Pool stores the most recently executed SQL statements and used data definitions. 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. The Shared Pool includes the Library Cache and Data Dictionary Cache. Library Cache Memory is allocated to the Library Cache whenever an SQL statement is parsed or a program unit is called. This enables storage of the most recently used SQL and PL/SQL statements. If the Library Cache is too small, the Library Cache must purge statement definitions in order to have space to load new SQL and PL/SQL statements. Actual management of this memory structure is through a Least-Recently-Used (LRU) algorithm. 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. If a system user executes an identical statement, then the statement does not have to be parsed again in order to execute the statement. Shared PL/SQL Procedures and Packages: This stores/shares the most recently used PL/SQL statements such as functions, packages, and triggers. Data Dictionary Cache The Data Dictionary Cache is a memory structure that caches data dictionary information that has been recently used. This includes user account information, datafile names, table descriptions, user privileges, and other information.

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. If the size is too small, then the data dictionary tables that reside on disk must be queried often for information and this will slow down performance. Buffer Caches A number of buffer caches are maintained in memory in order to improve system response time. 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. 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. If the information is not in the Database Buffer Cache, the Server Process retrieves the information from disk and stores it to the cache. Keep in mind that information read from disk is read a block at a time, not a row at a time, because a database block is the smallest addressable storage space on disk. 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 buffers in the cache are organized in two lists: the write list and, the least recently used (LRU) list. The write list holds dirty buffers these are buffers that hold that data that has been modified, but the blocks have not been written back 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 currently being accessed. When an Oracle process accesses a buffer, 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. When an Oracle user process needs a data row, it searches for the data in the database buffer cache because memory can be searched more quickly than hard disk can be accessed. If the data row is already in the cache (a cache hit), the process reads the data from memory; otherwise a cache miss occurs and data must be read from hard disk into the database buffer cache. Before reading a data block into the cache, the process must first find a free buffer. The process searches the LRU list, starting at the LRU end of the list. The search continues until a free buffer is found or until the search reaches the threshold limit of buffers.

Each time a user process finds a dirty buffer as it searches the LRU, that buffer is moved to the write list and the search for a free buffer continues. When a user process finds a free buffer, it reads the data block from disk into the buffer and moves the buffer to the MRU end of the LRU list. 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. This frees up some buffers. The block size for a database is set when a database is created and is determined by the init.ora parameter file parameter named DB_BLOCK_SIZE. Typical block sizes are 2KB, 4KB, 8KB, 16KB, and 32KB. The size of blocks in the Database Buffer Cache matches the block size for the database. The DBORCL database uses a 8KB block size. Because tablespaces that store oracle tables can use different (non-standard) block sizes, 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. 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. 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; 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. This information is displayed from the V$DB_CACHE_ADVICE view. In order for statistics to be gathered, you can dynamically alter the system by using the ALTER SYSTEM SET DB_CACHE_ADVICE (OFF, ON, READY) command. However, gathering statistics on system performance always incurs some overhead that will slow down system performance.

KEEP Buffer Pool This pool retains blocks in memory (data from tables) that are likely to be reused throughout daily processing. An example might be a table containing user names and passwords or a validation table of some type. The DB_KEEP_CACHE_SIZE parameter sizes the KEEP Buffer Pool. 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. The DB_RECYCLE_CACHE_SIZE parameter sizes the Recycle Buffer Pool.

Redo Log Buffer

The Redo Log Buffer memory object stores images of all changes made to database blocks. As you know, 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, the image is stored. Changes include INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. Think of the Redo Log Buffer as a circular buffer that is reused over and over. As the buffer fills up, 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. The Large Pool is used for the following tasks if it is allocated: Allocating space for session memory requirements from the User Global Area (part of the Server Process) where a Shared Server is in use. Transactions that interact with more than one database, e.g., a distributed database scenario. Backup and restore operations by the Recovery Manager (RMAN) process. o RMAN uses this only if the BACKUP_DISK_IO = n and BACKUP_TAPE_IO_SLAVE = TRUE parameters are set. o If the Large Pool is too small, memory allocation for backup will fail and memory will be allocated from the Shared Pool. Parallel execution message buffers for parallel server operations. The PARALLEL_AUTOMATIC_TUNING = TRUE parameter must be set. The Large Pool size is set with the LARGE_POOL_SIZE parameter this is not a dynamic parameter. It does not use an LRU list to manage memory. Java Pool The Java Pool is an optional memory object, but is required if the database has Oracle Java installed and in use for Oracle JVM (Java Virtual Machine). The size is set with the JAVA_POOL_SIZE parameter that defaults to 24MB. The Java Pool is used for memory allocation to parse Java commands and to store data associated with Java commands. Storing Java code and data in the Java Pool is analogous to SQL and PL/SQL code cached in the Shared Pool. Streams Pool This cache is new to Oracle 10g. It is sized with the parameter STREAMS_POOL_SIZE.

This pool stores data and control structures to support the Oracle Streams feature of Oracle Enterprise Edition. Oracle Steams manages sharing of data and events in a distributed environment. If STEAMS_POOL_SIZE is not set or is zero, memory for Oracle Streams operations is allocated from up to 10% of the Shared Pool memory. Program Global Area 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 PGA stores data and control information for a single Server Process or a single Background Process. It is allocated when a process is created and the memory is scavenged by the operating system when the process terminates. This is NOT a shared part of memory one PGA to each process only. The content of the PGA varies, but generally includes the following: Private SQL Area: Data for binding variables and runtime memory allocations. 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. This often happens in OLTP environments where many users are executing and using the same application program. o Dedicated Server environment the Private SQL Area is located in the Program Global Area. o Shared Server environment the Private SQL Area is located in the System Global Area. Session Memory: Memory that holds session variables and other session information. SQL Work Area: Memory allocated for sort, hash-join, bitmap merge, and bitmap create types of operations. 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). However, the DBA can let Oracle 10g determine the appropriate amount of memory. o Oracle 8i and earlier required the DBA to set the following parameters to control SQL Work Area memory allocations: SORT_AREA_SIZE. HASH_AREA_SIZE. BITMAP_MERGE_AREA_SIZE. CREATE_BITMAP_AREA_SIZE.

Software Code Area Software code areas store Oracle executable files running as part of the Oracle instance. These code areas are static in nature and are located in privileged memory that is separate from other user programs.

The code can be installed sharable when multiple Oracle instances execute on the same server with the same software release level. Processes You need to understand three different types of Processes: User Process: Starts when a database user requests to connect to an Oracle Server. Server Process: Establishes the Connection to an Oracle Instance when a User Process requests connection makes the connection for the User Process. Background Processes: These start when an Oracle Instance is started up. User Process In order to use Oracle, you must obviously connect to the database. This must occur whether you're using SQLPlus, an Oracle tool such as Designer or Forms, or an application program. This generates a User Process (a memory object) that generates programmatic calls through your user interface (SQLPlus, Integrated Developer Suite, or application program) that creates a session and causes the generation of a Server Process that is either dedicated or shared. Server Process As you have seen, the Server Process is the go-between for a User Process and the Oracle Instance. In a Dedicated Server environment, there is a single Server Process to serve each User Process. In a Shared Server environment, a Server Process can serve several User Processes, although with some performance reduction. Allocation of server process in a dedicated environment versus a shared environment is covered in further detail in the Oracle10g Database Performance Tuning course offered by Oracle Education. Background Processes 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. CJQ0: Coordinator Job Queue This is the coordinator of job queue processes for an instance. 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. Dnnn: Dispatcher number "nnn", for example, D000 would be the first dispatcher process Dispatchers are optional background processes, present only when the shared server configuration is used. Shared server is discussed in your readings on the topic "Configuring Oracle for the Shared Server". RECO: Recoverer The Recoverer process is used to resolve distributed transactions that are pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to remote databases

and automatically complete the commit or rollback of the local portion of any pending distributed transactions. For information about this process and how to start it, see your readings on the topic "Managing Distributed Transactions". Of these, the ones you'll use most often are ARCn (archiver) when you automatically archive redo log file information (covered in a later module), and RECO for recovery where the database is distributed on two or more separate physical Oracle servers, perhaps a UNIX machine and an NT machine. 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. The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes. The purpose of DBWn is to improve system performance by caching writes of database blocks from the Database Buffer Cache back to datafiles. Blocks that have been modified and that need to be written back to disk are termed "dirty blocks." 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. Performance improves because by delaying writing changed database blocks back to disk, 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. LGWR The Log Writer (LGWR) writes contents from the Redo Log Buffer to the Redo Log File that is in use. These are sequential writes since the Redo Log Files record database modifications based on the actual time that the modification takes place. 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. The LGWR writes according to the events illustrated in the figure shown below. SMON The System Monitor (SMON) is responsible for instance recovery by applying entries in the online redo log files to the datafiles. It also performs other activities as outlined in the figure shown below. If an Oracle Instance fails, all information in memory not written to disk is lost. SMON is responsible for recovering the instance when the database is started up again. It does the following:

Rolls forward to recover data that was recorded in a Redo Log File, but that had not yet been recorded to a datafile by DBWn. SMON reads the Redo Log Files and applies the changes to the data blocks. This recovers all transactions that were committed because these were written to the Redo Log Files prior to system failure. Opens the database to allow system users to logon. Rolls back uncommitted transactions. SMON also does limited space management. It combines (coalesces) adjacent areas of free space in the database's datafiles for tablespaces that are dictionary managed. It also deallocates temporary segments to create free space in the datafiles. 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 abend of a user application program. It does the tasks shown in the figure below. CKPT The Checkpoint (CPT) process writes information to the database control files that identifies the point in time with regard to the Redo Log Files where instance recovery is to begin should it be necessary. This is done at a minimum, once every three seconds. Think of a checkpoint record as a starting point for recovery. DBWn will have completed writing all buffers from the Database Buffer Cache to disk prior to the checkpoint, thus those record 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. 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. Causes all committed data to be written to datafiles during database shutdown. 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), location of which Redo Log File is to be used for recovery, and other information. CKPT does not write data blocks or redo blocks to disk it calls DBWn and LGWR as necessary.

ARCn We cover the Archiver (ARCn) optional background process in more detail because it is almost always used for production systems storing mission critical information. 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. When a Redo Log File fills up, Oracle switches to the next Redo Log File. The DBA creates several of these and the details of creating them are covered in a later module. If all 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, once overwritten, is lost forever. If ARCn is in what is termed ARCHIVELOG mode, then as the Redo Log Files fill up, they are individually written to Archived Redo Log Files and LGWR does not overwrite a Redo Log File until archiving has completed. Thus, committed data is not lost forever and can be recovered in the event of a disk failure. Only the contents of the SGA will be lost if an Instance fails. In NOARCHIVELOG mode, the Redo Log Files are overwritten and not archived. Recovery can only be made to the last full backup of the database files. All committed transactions after the last full backup are lost, and you can see that this could cost the firm a lot of $$$. When running in ARCHIVELOG mode, 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, any Archived Redo Log Files for prior backups are deleted. 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 10g database must always consist of at least two tablespaces (SYSTEM and SYSAUX), although a typical Oracle database will multiple tablespaces tablespaces. A tablespace is a logical storage facility (a logical container) for storing objects such as tables, indexes, 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. A tablespace belongs to only one database. Tablespaces can be brought online and taken offline for purposes of backup and management, except for the SYSTEM tablespace that must always be online. Tablespaces can be in either read-only or read-write status. Datafile: Tablespaces are stored in datafiles which are physical disk objects. A datafile can only store objects for a single tablespace, 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. The DBA can change the size of a datafile to make it smaller or later. The file can also grow in size dynamically as the tablespace grows.

Segment: When logical storage objects are created within a tablespace, for example, an employee table, a segment is allocated to the object. Obviously a tablespace typically has many segments. A segment cannot span tablespaces but can span datafiles that belong to a single tablespace. Extent: Each object has one segment which is a physical collection of extents. Extents are simply collections of contiguous disk storage blocks. 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. As a table or index grows, additional extents are added to the segment. A DBA can add extents to segments in order to tune performance of the system. An extent cannot span a datafile. Block: The Oracle Server manages data at the smallest unit in what is termed a block or data block. Data are actually stored in blocks. 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, if larger than an operating system block, should be an even multiple of the operating system block size, e.g., if the Linux operating system block size is 2K or 4K, then the Oracle data block should be 2K, 4K, 8K, 16K, etc in size. This optimizes I/O. 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. The maximum data block size depends on the operating system. Thus, the Oracle database architecture includes both logical and physical structures as follows: Physical: Control files; Redo Log Files; Datafiles; Operating System Blocks. Logical: Tablespaces; Segments; Extents; Data Blocks. SQL Statement Processing SQL Statements are processed differently depending on whether the statement is a query, data manipulation language (DML) to update, insert, or delete a row, 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. o Check syntax, object names, and privileges. o Lock objects used during parse. o Create and store execution plan. Bind: Obtains values for variables. Execute: Process statement.

Fetch: Return rows to user process.

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

2. Databases Creation:

Creating the Database

This section presents the steps involved when you create a database manually. These steps should be followed in the order presented. The prerequisites described in the preceding section must already have been completed. That is, you have established the environment for creating your Oracle Database, including most operating system dependent environmental variables, as part of the Oracle software installation process. The examples shown in these steps create an example database mynewdb

Step 1: Decide on Your Instance Identifier (SID)

An instance is made up of the system global area (SGA) and the background processes of an Oracle Database. Decide on a unique Oracle system identifier (SID) for your instance and set the ORACLE_SID environment variable accordingly. This identifier is used to distinguish this instance

from other Oracle Database instances that you may create later and run concurrently on your system. The following example sets the SID for the instance and database we are about to create:
% setenv ORACLE_SID mynewdb

The value of the DB_NAME initialization parameter should match the SID setting.

Step 2: Establish the Database Administrator Authentication Method

You must be authenticated and granted appropriate system privileges in order to create a database. You can use the password file or operating system authentication method. Database administrator authentication and authorization is discussed in the following sections of this book:

"Database Administrator Security and Privileges" "Database Administrator Authentication" "Creating and Maintaining a Password File"

Step 3: Create the Initialization Parameter File

The instance for any Oracle Database is started using an initialization parameter file. One way to create the initialization parameter file is to edit a copy of the sample initialization parameter file that Oracle provides on the distribution media, or the sample presented in this book. For convenience, store your initialization parameter file in the Oracle Database default location, using the default name. Then when you start your database, it will not be necessary to specify the PFILE parameter of the STARTUP command, because Oracle Database automatically looks in the default location for the initialization parameter file. Default initialization parameter file locations are shown in the following table: Platform Default Name UNIX
init$ORACLE_HOME.ora

Default Location $ORACLE_HOME/dbs For example, the initialization parameter file for the mynewdb database is stored in the following location:
/u01/oracle/dbs/initmynewdb.ora ORACLE_BASE\admin\SID\pfile\init.ora

For example, the initialization parameter file for the mynewdb database is named:
initmynewdb.ora

Windows init.ora

The following is the initialization parameter file used to create the mynewdb database on a UNIX system. Sample Initialization Parameter File
control_files db_name db_domain = (/u0d/lcg03/control.001.dbf, /u0d/lcg03/control.002.dbf, /u0d/lcg03/control.003.dbf) = lcg03 = us.oracle.com

log_archive_dest_1 = "LOCATION=/net/fstlcg03/private/yaliu/testlog/log.lcg03.fstlcg03/lcg03/arch" log_archive_dest_state_1 = enable db_block_size pga_aggregate_target processes sessions open_cursors undo_management shared_servers remote_listener undo_tablespace compatible sga_target = 8192 = 2500M = 1000 = 1200 = 1024 = AUTO = 3 = tnsfstlcg03 = smu_nd1 = 10.1.0.0.0 = 1500M

nls_language = AMERICAN nls_territory = AMERICA db_recovery_file_dest = /net/fstlcg03/private/yaliu/testlog/log.lcg03.fstlcg03/lcg03/arch db_recovery_file_dest_size = 100G

Step 4: Connect to the Instance

Start SQL*Plus and connect to your Oracle Database instance AS SYSDBA.
$ SQLPLUS /nolog CONNECT SYS/password AS SYSDBA

Step 5: Create a Server Parameter File (Recommended)

Oracle recommends that you create a server parameter file as a dynamic means of maintaining initialization parameters. The server parameter file is discussed in "Managing Initialization Parameters Using a Server Parameter File".

The following script creates a server parameter file from the text initialization parameter file and writes it to the default location. The script can be executed before or after instance startup, but after you connect as SYSDBA. The database must be restarted before the server parameter file takes effect.
-- create the server parameter file CREATE SPFILE='/u01/oracle/dbs/spfilemynewdb.ora' FROM PFILE='/u01/oracle/admin/initmynewdb/scripts/init.ora'; SHUTDOWN -- the next startup will use the server parameter file EXIT

Step 6: Start the Instance

Start an instance without mounting a database. Typically, you do this only during database creation or while performing maintenance on the database. Use the STARTUP command with the NOMOUNT clause. In this example, because the server parameter file is stored in the default location, you are not required to specify the PFILE clause:
STARTUP NOMOUNT

At this point, the SGA is created and background processes are started in preparation for the creation of a new database. The database itself does not yet exist.

Step 7: Issue the CREATE DATABASE Statement

To create the new database, use the CREATE DATABASE statement. The following statement creates database mynewdb:
CREATE DATABASE mynewdb USER SYS IDENTIFIED BY pz6r58 USER SYSTEM IDENTIFIED BY y1tz5p LOGFILE GROUP 1 ('/u01/oracle/oradata/mynewdb/redo01.log') SIZE 100M, GROUP 2 ('/u01/oracle/oradata/mynewdb/redo02.log') SIZE 100M, GROUP 3 ('/u01/oracle/oradata/mynewdb/redo03.log') SIZE 100M MAXLOGFILES 5 MAXLOGMEMBERS 5 MAXLOGHISTORY 1 MAXDATAFILES 100 MAXINSTANCES 1 CHARACTER SET US7ASCII NATIONAL CHARACTER SET AL16UTF16 DATAFILE '/u01/oracle/oradata/mynewdb/system01.dbf' SIZE 325M REUSE EXTENT MANAGEMENT LOCAL SYSAUX DATAFILE '/u01/oracle/oradata/mynewdb/sysaux01.dbf' SIZE 325M REUSE DEFAULT TABLESPACE tbs_1 DEFAULT TEMPORARY TABLESPACE tempts1 TEMPFILE '/u01/oracle/oradata/mynewdb/temp01.dbf' SIZE 20M REUSE UNDO TABLESPACE undotbs

DATAFILE '/u01/oracle/oradata/mynewdb/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

A database is created with the following characteristics:

The database is named mynewdb. Its global database name is mynewdb.us.oracle.com. See "DB_NAME Initialization Parameter" and "DB_DOMAIN Initialization Parameter". Three control files are created as specified by the CONTROL_FILES initialization parameter, which was set before database creation in the initialization parameter file. See "Sample Initialization Parameter File " and "Specifying Control Files ". The password for user SYS is pz6r58 and the password for SYSTEM is y1tz5p. The two clauses that specify the passwords for SYS and SYSTEM are not mandatory in this release of Oracle Database. However, if you specify either clause, you must specify both clauses. For further information about the use of these clauses, see "Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM". The new database has three redo log files as specified in the LOGFILE clause. MAXLOGFILES, MAXLOGMEMBERS, and MAXLOGHISTORY define limits for the redo log. See Chapter 6, " Managing the Redo Log". MAXDATAFILES specifies the maximum number of datafiles that can be open in the database. This number affects the initial sizing of the control file. MAXINSTANCES specifies that only one instance can have this database mounted and open. The US7ASCII character set is used to store data in this database. The AL16UTF16 character set is specified as the NATIONAL CHARACTER SET, used to store data in columns specifically defined as NCHAR, NCLOB, or NVARCHAR2. The SYSTEM tablespace, consisting of the operating system file /u01/oracle/oradata/mynewdb/system01.dbf is created as specified by the DATAFILE clause. If a file with that name already exists, it is overwritten. The SYSTEM tablespace is a locally managed tablespace. See "Creating a Locally Managed SYSTEM Tablespace". A SYSAUX tablespace is created, consisting of the operating system file /u01/oracle/oradata/mynewdb/sysaux01.dbf as specified in the SYSAUX DATAFILE clause. See "Creating the SYSAUX Tablespace". The DEFAULT TABLESPACE clause creates and names a default permanent tablespace for this database. The DEFAULT TEMPORARY TABLESPACE clause creates and names a default temporary tablespace for this database. See "Creating a Default Temporary Tablespace". The UNDO TABLESPACE clause creates and names an undo tablespace that is used to store undo data for this database if you have specified UNDO_MANAGEMENT=AUTO in the initialization parameter file. See "Using Automatic Undo Management: Creating an Undo Tablespace". Redo log files will not initially be archived, because the ARCHIVELOG clause is not specified in this CREATE DATABASE statement. This is customary during database creation. You can later use an ALTER DATABASE statement to switch to ARCHIVELOG mode. The initialization parameters in the initialization parameter file for mynewdb relating to archiving are LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_FORMAT.

Step 8: Create Additional Tablespaces

To make the database functional, you need to create additional files and tablespaces for users. The following sample script creates some additional tablespaces:
CONNECT SYS/password AS SYSDBA -- create a user tablespace to be assigned as the default tablespace for users CREATE TABLESPACE users LOGGING DATAFILE '/u01/oracle/oradata/mynewdb/users01.dbf' SIZE 25M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL; -- create a tablespace for indexes, separate from user tablespace CREATE TABLESPACE indx LOGGING DATAFILE '/u01/oracle/oradata/mynewdb/indx01.dbf' SIZE 25M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL;

Step 9: Run Scripts to Build Data Dictionary Views

Run the scripts necessary to build views, synonyms, and PL/SQL packages:
CONNECT SYS/password AS SYSDBA @/u01/oracle/rdbms/admin/catalog.sql @/u01/oracle/rdbms/admin/catproc.sql EXIT

The following table contains descriptions of the scripts: Script

CATALOG.SQL CATPROC.SQL

Description Creates the views of the data dictionary tables, the dynamic performance views, and public synonyms for many of the views. Grants PUBLIC access to the synonyms. Runs all scripts required for or used with PL/SQL.

Step 10: Run Scripts to Install Additional Options (Optional) Step 11: Back Up the Database.
Take a full backup of the database to ensure that you have a complete set of files from which to recover if a media failure occurs.

Understanding the CREATE DATABASE Statement

When you execute a CREATE DATABASE statement, Oracle Database performs (at least) a number of operations. The actual operations performed depend on the clauses that you specify in the CREATE

statement and the initialization parameters that you have set. Oracle Database performs at least these operations:
DATABASE

Creates the datafiles for the database Creates the control files for the database Creates the redo log files for the database and establishes the ARCHIVELOG mode. Creates the SYSTEM tablespace and the SYSTEM rollback segment Creates the SYSAUX tablespace Creates the data dictionary Sets the character set that stores data in the database Sets the database time zone Mounts and opens the database for use

This section discusses several of the clauses of the CREATE DATABASE statement. It expands upon some of the clauses discussed in "Step 7: Issue the CREATE DATABASE Statement" and introduces additional ones. Many of the CREATE DATABASES clauses discussed here can be used to simplify the creation and management of your database. The following topics are contained in this section:

Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM Creating a Locally Managed SYSTEM Tablespace Creating the SYSAUX Tablespace Using Automatic Undo Management: Creating an Undo Tablespace Creating a Default Temporary Tablespace Specifying Oracle-Managed Files at Database Creation Supporting Bigfile Tablespaces During Database Creation Specifying the Database Time Zone and Time Zone File Specifying FORCE LOGGING Mode

Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM
The clauses of the CREATE DATABASE statement used for specifying the passwords for users SYS and SYSTEM are:
USER SYS IDENTIFIED BY password USER SYSTEM IDENTIFIED BY password

If you omit these clauses, these users are assigned the default passwords change_on_install and manager, respectively. A record is written to the alert file indicating that the default passwords were used. To protect your database, you should change these passwords using the ALTER USER statement immediately after database creation.

Oracle strongly recommends that you specify these clauses, even though they are optional in this release of Oracle Database. The default passwords are commonly known, and if you neglect to change them later, you leave database vulnerable to attack by malicious users.

Creating a Locally Managed SYSTEM Tablespace

When you specify the EXTENT MANAGEMENT LOCAL clause in the CREATE DATABASE statement, you cause Oracle Database to create a locally managed SYSTEM tablespace, which is a tablespace for which the database determines and manages extent sizes. The COMPATIBLE initialization parameter must be set to 9.2 or higher for this statement to be successful. If you do not specify the EXTENT MANAGEMENT LOCAL clause, by default the database creates a dictionary-managed SYSTEM tablespace. Locally managed tablespaces provide better performance and greater ease of management than dictionary-managed tablespaces. A locally managed SYSTEM tablespace is with AUTOALLOCATE enabled by default, which means that the system determines and controls the number and size of extents. You may notice an increase in the initial size of objects created in a locally managed SYSTEM tablespace because of the autoallocate policy. It is not possible to create a locally managed SYSTEM tablespace and specify UNIFORM extent size. When you create your database with a locally managed SYSTEM tablespace, ensure the following conditions are met:

A default temporary tablespace must exist, and that tablespace cannot be the SYSTEM tablespace. To meet this condition, you can specify the DEFAULT TEMPORARY TABLESPACE clause in the CREATE DATABASE statement, or you can omit the clause and let Oracle Database create the tablespace for you using a default name and in a default location.

You must not create rollback segments in dictionary-managed tablespaces. Attempts to create rollback segments in a dictionary-managed tablespace will fail if the SYSTEM tablespace is locally managed. You can meet this condition by using automatic undo management. Oracle has deprecated the use of rollback segments. You can include the UNDO TABLESPACE clause in the CREATE DATABASE statement to create a specific undo tablespace. If you omit that clause, Oracle Database creates a locally managed undo tablespace for you using the default name and in a default location.

When the SYSTEM tablespace is locally managed, the following additional restrictions apply to other tablespaces in the database:

You cannot create any dictionary-managed tablespaces in the database. You cannot migrate a locally managed tablespace to a dictionary-managed tablespace.

Preexisting dictionary-managed tablespaces can remain in the database, but only in readonly mode. They cannot be altered to read/write. You can transport dictionary-managed tablespaces into the database, but you cannot set them to read/write.

Oracle Database lets you migrate an existing dictionary-managed SYSTEM tablespace to a locally managed tablespace using the DBMS_SPACE_ADMIN package. However, there is no procedure for backward migration.

Creating the 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 and that you, as a DBA, must maintain. Other functionality or features that previously used the SYSTEM tablespace can now use the SYSAUX tablespace, thus reducing 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. The size of the SYSAUX tablespace is determined by the size of the database components that occupy SYSAUX. See Table 2-2 for a list of all SYSAUX occupants. Based on the initial sizes of these components, the SYSAUX tablespace needs to be at least 240 MB at the time of database creation. The space requirements of the SYSAUX tablespace will increase after the database is fully deployed, depending on the nature of its use and workload. For more information on how to manage the space consumption of the SYSAUX tablespace on an ongoing basis, please refer to the "Managing the SYSAUX Tablespace". If you include a DATAFILE clause for the SYSTEM tablespace, then you must specify the SYSAUX DATAFILE clause as well, or the CREATE DATABASE statement will fail. This requirement does not exist if the Oracle-managed files feature is enabled (see "Specifying Oracle-Managed Files at Database Creation"). If you issue the CREATE DATABASE statement with no other clauses, then the software creates a default database with datafiles for the SYSTEM and SYSAUX tablespaces stored in system-determined default locations, or where specified by an Oracle-managed files initialization parameter.

The SYSAUX tablespace has the same security attributes as the SYSTEM tablespace.

Specifying Oracle-Managed Files at Database Creation

You can minimize the number of clauses and parameters that you specify in your CREATE DATABASE statement by using the Oracle-managed files feature. You do this either by specifying a directory in which your files are created and managed by Oracle Database, or by using Automatic Storage Management. When you use Automatic Storage Management, you specify a disk group in which the database creates and manages your files, including file redundancy and striping. By including any of the initialization parameters DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n, or DB_RECOVERY_FILE_DEST in your initialization parameter file, you instruct Oracle Database to create and manage the underlying operating system files of your database. Oracle Database will automatically create and manage the operating system files for the following database structures, depending on which initialization parameters you specify and how you specify clauses in your CREATE DATABASE statement:

Tablespaces Temporary tablespaces Control files Redo log files Archive log files Flashback logs Block change tracking files RMAN backups

The following CREATE DATABASE statement shows briefly how the Oracle-managed files feature works, assuming you have specified required initialization parameters:
CREATE DATABASE rbdb1 USER SYS IDENTIFIED BY pz6r58 USER SYSTEM IDENTIFIED BY y1tz5p UNDO TABLESPACE undotbs DEFAULT TEMPORARY TABLESPACE tempts1;

No DATAFILE clause is specified, so the database creates an Oracle-managed datafile for the SYSTEM tablespace. No LOGFILE clauses are included, so the database creates two Oracle-managed redo log file groups. No SYSAUX DATAFILE is included, so the database creates an Oracle-managed datafile for the SYSAUX tablespace. No DATAFILE subclause is specified for the UNDO TABLESPACE clause, so the database creates an Oracle-managed datafile for the undo tablespace. No TEMPFILE subclause is specified for the DEFAULT TEMPORARY TABLESPACE clause, so the database creates an Oracle-managed tempfile.

If no CONTROL_FILES initialization parameter is specified in the initialization parameter file, then the database also creates an Oracle-managed control file. If you are using a server parameter file (see "Managing Initialization Parameters Using a Server Parameter File"), the database automatically sets the appropriate initialization parameters.

Supporting Bigfile Tablespaces During Database Creation

Oracle Database simplifies management of tablespaces and enables support for ultra-large databases by letting you create bigfile tablespaces. Bigfile tablespaces can contain only one file, but that file can have up to 4G blocks. The maximum number of datafiles in an Oracle Database is limited (usually to 64K files). Therefore, bigfile tablespaces can significantly enhance the storage capacity of an Oracle Database. This section discusses the clauses of the CREATE DATABASE statement that let you include support for bigfile tablespaces.

Specifying the Default Tablespace Type

The SET DEFAULT ... TABLESPACE clause of the CREATE DATABASE statement to determines the default type of tablespace for this database in subsequent CREATE TABLESPACE statements. Specify either SET DEFAULT BIGFILE TABLESPACE or SET DEFAULT SMALLFILE TABLESPACE. If you omit this clause, the default is a smallfile tablespace, which is the traditional type of Oracle Database tablespace. A smallfile tablespace can contain up to 1022 files with up to 4M blocks each. The use of bigfile tablespaces further enhances the Oracle-managed files feature, because bigfile tablespaces make datafiles completely transparent for users. SQL syntax for the ALTER TABLESPACE statement has been extended to allow you to perform operations on tablespaces, rather than the underlying datafiles. The CREATE DATABASE statement shown in "Specifying Oracle-Managed Files at Database Creation" can be modified as follows to specify that the default type of tablespace is a bigfile tablespace:
CREATE DATABASE rbdb1 USER SYS IDENTIFIED BY pz6r58 USER SYSTEM IDENTIFIED BY y1tz5p SET DEFAULT BIGFILE TABLESPACE UNDO TABLESPACE undotbs DEFAULT TEMPORARY TABLESPACE tempts1;

To dynamically change the default tablespace type after database creation, use the SET DEFAULT TABLESPACE clause of the ALTER DATABASE statement:
ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;

You can determine the current default tablespace type for the database by querying the DATABASE_PROPERTIES data dictionary view as follows:
SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME = 'DEFAULT_TBS_TYPE';

Overriding the Default Tablespace Type

The SYSTEM and SYSAUX tablespaces are always created with the default tablespace type. However, you can explicitly override the default tablespace type for the UNDO and DEFAULT TEMPORARY tablespace during the CREATE DATABASE operation. For example, you can create a bigfile UNDO tablespace in a database with the default tablespace type of smallfile as follows:
CREATE DATABASE rbdb1 ... BIGFILE UNDO TABLESPACE undotbs DATAFILE '/u01/oracle/oradata/mynewdb/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

You can create a smallfile DEFAULT TEMPORARY tablespace in a database with the default tablespace type of bigfile as follows:
CREATE DATABASE rbdb1 SET DEFAULT BIGFILE TABLSPACE ... SMALLFILE DEFAULT TEMPORARY TABLESPACE tempts1 TEMPFILE '/u01/oracle/oradata/mynewdb/temp01.dbf' SIZE 20M REUSE ...

Components and Granules in the SGA

The SGA comprises a number of memory components, which are pools of memory used to satisfy a particular class of memory allocation requests. Examples of memory components include the shared pool (used to allocate memory for SQL and PL/SQL execution), the java pool (used for java objects and other java execution memory), and the buffer cache (used for caching disk blocks). All SGA components allocate and deallocate space in units of granules. Oracle Database tracks SGA memory use in internal numbers of granules for each SGA component. The memory for dynamic components in the SGA is allocated in the unit of granules. Granule size is determined by total SGA size. Generally speaking, on most platforms, if the total SGA size is equal to or less than 1 GB, then granule size is 4 MB. For SGAs larger than 1 GB, granule size is 16 MB. Some platform dependencies may arise. For example, on 32-bit Windows NT, the granule

size is 8 MB for SGAs larger than 1 GB. Consult your operating system specific documentation for more details. You can query the V$SGAINFO view to see the granule size that is being used by an instance. The same granule size is used for all dynamic components in the SGA. If you specify a size for a component that is not a multiple of granule size, Oracle Database rounds the specified size up to the nearest multiple. For example, if the granule size is 4 MB and you specify DB_CACHE_SIZE as 10 MB, the database actually allocates 12 MB.

Limiting the Size of the SGA

The SGA_MAX_SIZE initialization parameter specifies the maximum size of the System Global Area for the lifetime of the instance. You can dynamically alter the initialization parameters affecting the size of the buffer caches, shared pool, large pool, Java pool, and streams pool but only to the extent that the sum of these sizes and the sizes of the other components of the SGA (fixed SGA, variable SGA, and redo log buffers) does not exceed the value specified by SGA_MAX_SIZE. If you do not specify SGA_MAX_SIZE, then Oracle Database selects a default value that is the sum of all components specified or defaulted at initialization time. If you do specify SGA_MAX_SIZE, and at the time the database is initialized the value is less than the sum of the memory allocated for all components, either explicitly in the parameter file or by default, then the database ignores the setting for SGA_MAX_SIZE.

Using Automatic Shared Memory Management

You enable the automatic shared memory management feature by setting the SGA_TARGET parameter. This parameter in effect replaces the parameters that control the memory allocated for a specific set of individual components, which are now automatically managed. In addition, you must ensure that the STATISTICS_LEVEL initialization parameter is set to TYPICAL (the default) or ALL. The SGA_TARGET initialization parameter reflects the total size of the SGA. Table 2-3 lists the SGA components for which SGA_TARGET includes memory and the initialization parameters corresponding to those components. Table 2-3 Automatically Sized SGA Components and Corresponding Parameters Initialization Parameter NA
SHARED_POOL_SIZE

SGA Component Fixed SGA and other internal allocations needed by the Oracle Database instance The shared pool

SGA Component The large pool The Java pool The buffer cache

Initialization Parameter
LARGE_POOL_SIZE JAVA_POOL_SIZE DB_CACHE_SIZE

When you are migrating from a manual management scheme, execute the following query on the instance running in manual mode to get a value for SGA_TARGET:
SELECT ( (SELECT SUM(value) FROM V$SGA) (SELECT CURRENT_SIZE FROM V$SGA_DYNAMIC_FREE_MEMORY) ) "SGA_TARGET" FROM DUAL;

You can then remove the parameters that formerly controlled memory for the now automatically sized components. For example, suppose you currently have the following configuration of parameters on a manual mode instance with SGA_MAX_SIZE set to 1200M:
SHARED_POOL_SIZE = 200M DB_CACHE_SIZE = 500M LARGE_POOL_SIZE=200M

Also assume that the result of the queries is as follows:

SELECT SUM(value) FROM V$SGA = 1200M SELECT CURRENT_VALUE FROM V$SGA_DYNAMIC_FREE_MEMORY = 208M

You can take advantage of automatic shared memory management by replacing the manually sized parameters (SHARED_POOL_SIZE, DB_CACHE_SIZE, LARGE_POOL_SIZE) with the following setting:
SGA_TARGET = 992M

where 992M = 1200M minus 208M. By default, when you set a value for SGA_TARGET, the value of the parameters corresponding to all the automatically sized SGA components is set to zero. However, you can still exercise some control over the size of the automatically sized components by specifying minimum values for the parameters corresponding to these components. Doing so can be useful if you know that an application cannot function properly without a minimum amount of memory in specific

components. You specify the minimum amount of SGA space for a component by setting a value for its corresponding initialization parameter. Here is an example configuration:
SGA_TARGET = 256M SHARED_POOL_SIZE = 32M DB_CACHE_SIZE = 100M

In this example, the shared pool and the default buffer pool will not be sized smaller than the specified values (32 M and 100M, respectively). The remaining 124M (256 minus 132) is available for use by all the manually and automatically sized components. The actual distribution of values among the SGA components might look like this:

Actual shared pool size = 64M Actual buffer cache size = 128M Actual Java pool size = 60M Actual large pool size = 4M

The parameter values determine the minimum amount of SGA space allocated. The fixed view V$SGA_DYNAMIC_COMPONENTS displays the current actual size of each SGA component. You can also see the current actual values of the SGA components in the Enterprise Manager memory configuration page. Manually limiting the minimum size of one or more automatically sized components reduces the total amount of memory available for dynamic adjustment. This reduction in turn limits the ability of the system to adapt to workload changes. Therefore, this practice is not recommended except in exceptional cases. The default automatic management behavior maximizes both system performance and the use of available resources. When the automatic shared memory management feature is enabled, the internal tuning algorithm tries to determine an optimal size for the shared pool based on the workload. It usually converges on this value by increasing in small increments over time. However, the internal tuning algorithm typically does not attempt to shrink the shared pool, because the presence of open cursors, pinned PL/SQL packages, and other SQL execution state in the shared pool make it impossible to find granules that can be freed. Therefore, the tuning algorithmn only tries to increase the shared pool in conservative increments, starting from a conservative size and stabilizing the shared pool at a size that produces the optimal performance benefit.

Dynamic Modification of SGA Parameters

You can modify the value of SGA_TARGET and the parameters controlling individual components dynamically using the ALTER SYSTEM statement, as described in the sections that follow.

Dynamic Modification of SGA_TARGET

The SGA_TARGET parameter can be increased up to the value specified for the SGA_MAX_SIZE parameter, and it can also be reduced. If you reduce the value of SGA_TARGET, the system identifies one or more automatically tuned components to release memory. You can reduce SGA_TARGET until one or more automatically tuned components reach their minimum size. Oracle Database determines the minimum allowable value for SGA_TARGET taking into account several factors, including values set for the automatically sized components, manually sized components that use SGA_TARGET space, and number of CPUs. The change in the amount of physical memory consumed when SGA_TARGET is modified depends on the operating system. On some UNIX platforms that do not support dynamic shared memory, the physical memory in use by the SGA is equal to the value of the SGA_MAX_SIZE parameter. On such platforms, there is no real benefit in setting SGA_TARGET to a value smaller than SGA_MAX_SIZE. Therefore, setting SGA_MAX_SIZE on those platforms is not recommended. On other platforms, such as Solaris and Windows, the physical memory consumed by the SGA is equal to the value of SGA_TARGET. When SGA_TARGET is resized, the only components affected are the automatically tuned components for which you have not set a minimum value in their corresponding initialization parameter. Any manually configured components remain unaffected. For example, suppose you have an environment with the following configuration:
SGA_MAX_SIZE = 1024M SGA_TARGET = 512M DB_8K_CACHE_SIZE = 128M

In this example, the value of SGA_TARGET can be resized up to 1024M and can also be reduced until one or more of the buffer cache, shared pool, large pool, or java pool reaches its minimum size. The exact value depends on environmental factors such as the number of CPUs on the system. However, the value of DB_8K_CACHE_SIZE remains fixed at all times at 128M When SGA_TARGET is reduced, if the values for any automatically tuned component sizes has been specified to limit their minimum sizes, then those components will not be reduced smaller than that minimum. Consider the following combination of parameters:
SGA_MAX_SIZE = 1024M SGA_TARGET = 512M DB_CACHE_SIZE = 96M DB_8K_CACHE_SIZE = 128M

As in the last example, if SGA_TARGET is reduced, the DB_8K_CACHE_SIZE parameter is permanently fixed at 128M. In addition, the primary buffer cache (determined by the DB_CACHE_SIZE parameter) will not be reduced smaller than 96M. Thus the amount that SGA_TARGET can be reduced is restricted.

Modifying Parameters for Automatically Managed Components

When SGA_TARGET is not set, the automatic shared memory management feature is not enabled. Therefore the rules governing resize for all component parameters are the same as in earlier releases. However, when automatic shared memory management is enabled, the manually specified sizes of automatically sized components serve as a lower bound for the size of the components. You can modify this limit dynamically by changing the values of the corresponding parameters. If the specified lower limit for the size of a given SGA component is less than its current size, there is no immediate change in the size of that component. The new setting only limits the automatic tuning algorithm to that reduced minimum size in the future. For example, consider the following configuration:
SGA_TARGET = 512M LARGE_POOL_SIZE = 256M

Current actual shared pool size = 284M

In this example, if you increase the value of LARGE_POOL_SIZE to a value greater than the actual current size of the component, the system expands the component to accommodate the increased minimum size. For example, if you increase the value of LARGE_POOL_SIZE to 300M, then the system increases the large pool until it reaches 300M. This resizing occurs at the expense of one or more automatically tuned components. If you decrease the value of LARGE_POOL_SIZE to 200, there is no immediate change in the size of that component. The new setting only limits the reduction of the large pool size to 200 M in the future.

Modifying Parameters for Manually Sized Components

Parameters for manually sized components can be dynamically altered as well. However, rather than setting a minimum size, the value of the parameter specifies the precise size of the corresponding component. When you increase the size of a manually sized component, extra memory is taken away from one or more automatically sized components. When you decrease the size of a manually sized component, the memory that is released is given to the automatically sized components. For example, consider this configuration:
SGA_TARGET = 512M DB_8K_CACHE_SIZE = 128M

In this example, increasing DB_8K_CACHE_SIZE by 16 M to 144M means that the 16M will be taken away from the automatically sized components. Likewise, reducing DB_8K_CACHE_SIZE by 16M to 112M means that the 16M will be given to the automatically sized components.

Using Manual Shared Memory Management

If you decide not to use automatic shared memory management by not setting the SGA_TARGET parameter, you must manually configure each component of the SGA. This section provides guidelines on setting the parameters that control the size of each SGA components.

Setting the Buffer Cache Initialization Parameters

The buffer cache initialization parameters determine the size of the buffer cache component of the SGA. You use them to specify the sizes of caches for the various block sizes used by the database. These initialization parameters are all dynamic. If you intend to use multiple block sizes in your database, you must have the DB_CACHE_SIZE and at least one DB_nK_CACHE_SIZE parameter set. Oracle Database assigns an appropriate default value to the DB_CACHE_SIZE parameter, but the DB_nK_CACHE_SIZE parameters default to 0, and no additional block size caches are configured. The size of a buffer cache affects performance. Larger cache sizes generally reduce the number of disk reads and writes. However, a large cache may take up too much memory and induce memory paging or swapping. DB_CACHE_SIZE Initialization Parameter The DB_CACHE_SIZE initialization parameter has replaced the DB_BLOCK_BUFFERS initialization parameter, which was used in earlier releases. The DB_CACHE_SIZE parameter specifies the size in bytes of the cache of standard block size buffers. Thus, to specify a value for DB_CACHE_SIZE, you would determine the number of buffers that you need and multiple that value times the block size specified in DB_BLOCK_SIZE. For backward compatibility, the DB_BLOCK_BUFFERS parameter still functions, but it remains a static parameter and cannot be combined with any of the dynamic sizing parameters. The DB_nK_CACHE_SIZE Initialization Parameters The sizes and numbers of nonstandard block size buffers are specified by the following initialization parameters:
DB_2K_CACHE_SIZE DB_4K_CACHE_SIZE DB_8K_CACHE_SIZE DB_16K_CACHE_SIZE DB_32K_CACHE_SIZE

Each parameter specifies the size of the buffer cache for the corresponding block size. For example:
DB_BLOCK_SIZE=4096 DB_CACHE_SIZE=12M DB_2K_CACHE_SIZE=8M DB_8K_CACHE_SIZE=4M

In this example, the parameters specify that the standard block size of the database is 4K. The size of the cache of standard block size buffers is 12M. Additionally, 2K and 8K caches will be configured with sizes of 8M and 4M respectively. To limit the number of users created in a database, set the LICENSE_MAX_USERS initialization parameter in the database initialization parameter file, as shown in the following example:
LICENSE_MAX_USERS = 200

Troubleshooting Database Creation

If database creation fails, you can look at the alert log to determine the reason for the failure and to determine corrective action. The alert log is discussed in "Monitoring the Operation of Your Database". You should shut down the instance and delete any files created by the CREATE DATABASE statement before you attempt to create it again. After correcting the error that caused the failure of the database creation, try re-creating the database.

Dropping a Database
Dropping a database involves removing its datafiles, redo log files, control files, and initialization parameter files. The DROP DATABASE statement deletes all control files and all other database files listed in the control file. To use the DROP DATABASE statement successfully, all of the following conditions must apply:

The database must be mounted and closed. The database must be mounted exclusively--not in shared mode. The database must be mounted as RESTRICTED.

An example of this statement is:

DROP DATABASE;

The DROP DATABASE statement has no effect on archived log files, nor does it have any effect on copies or backups of the database. It is best to use RMAN to delete such files. If the database is on raw disks, the actual raw disk special files are not deleted.

If you used the Database Configuration Assistant to create your database, you can use that tool to delete (drop) your database and remove the files.

Managing Initialization Parameters Using a Server Parameter File

Initialization parameters for the Oracle Database have traditionally been stored in a text initialization parameter file. For better manageability, you can choose to maintain initialization parameters in a binary server parameter file that is persistent across database startup and shutdown. This section introduces the server parameter file, and explains how to manage initialization parameters using either method of storing the parameters. The following topics are contained in this section.

What Is a Server Parameter File? Migrating to a Server Parameter File Creating a Server Parameter File The SPFILE Initialization Parameter Using ALTER SYSTEM to Change Initialization Parameter Values Exporting the Server Parameter File Backing Up the Server Parameter File Errors and Recovery for the Server Parameter File Viewing Parameter Settings

What Is a Server Parameter File?

A server parameter file (SPFILE) can be thought of as a repository for initialization parameters that is maintained on the machine running the Oracle Database server. It is, by design, a server-side initialization parameter file. Initialization parameters stored in a server parameter file are persistent, in that any changes made to the parameters while an instance is running can persist across instance shutdown and startup. This arrangement eliminates the need to manually update initialization parameters to make changes effected by ALTER SYSTEM statements persistent. It also provides a basis for self-tuning by the Oracle Database server. A server parameter file is initially built from a traditional text initialization parameter file using the CREATE SPFILE statement. It is a binary file that cannot be edited using a text editor. Oracle Database provides other interfaces for viewing and modifying parameter settings.

Caution: Although you can open the binary server parameter file with a text editor and view its text, do not manually edit it. Doing so will corrupt the file. You will not be able to start your instance, and if the instance is running, it could fail. At system startup, the default behavior of the STARTUP command is to read a server parameter file to obtain initialization parameter settings. The STARTUP command with no PFILE clause reads the

server parameter file from an operating system specific location. If you use a traditional text initialization parameter file, you must specify the PFILE clause when issuing the STARTUP command. Instructions for starting an instance using a server parameter file are contained in "Starting Up a Database".

Migrating to a Server Parameter File

If you are currently using a traditional initialization parameter file, use the following steps to migrate to a server parameter file. 1. If the initialization parameter file is located on a client machine, transfer the file (for example, FTP) from the client machine to the server machine. 1. Create a server parameter file using the CREATE SPFILE statement. This statement reads the initialization parameter file to create a server parameter file. The database does not have to be started to issue a CREATE SPFILE statement. 2. Start up the instance using the newly created server parameter file.

Creating a Server Parameter File

The server parameter file is initially created from a traditional text initialization parameter file. It must be created prior to its use in the STARTUP command. The CREATE SPFILE statement is used to create a server parameter file. You must have the SYSDBA or the SYSOPER system privilege to execute this statement. The following example creates a server parameter file from initialization parameter file /u01/oracle/dbs/init.ora. In this example no SPFILE name is specified, so the file is created in a platform-specific default location and is named spfile$ORACLE_SID.ora.
CREATE SPFILE FROM PFILE='/u01/oracle/dbs/init.ora';

Another example, which follows, illustrates creating a server parameter file and supplying a name.
CREATE SPFILE='/u01/oracle/dbs/test_spfile.ora' FROM PFILE='/u01/oracle/dbs/test_init.ora';

When you create a server parameter file from an initialization parameter file, comments specified on the same lines as a parameter setting in the initialization parameter file are maintained in the server parameter file. All other comments are ignored. The server parameter file is always created on the machine running the database server. If a server parameter file of the same name already exists on the server, it is overwritten with the new information.

Oracle recommends that you allow the database server to default the name and location of the server parameter file. This will ease administration of your database. For example, the STARTUP command assumes this default location to read the parameter file. The table that follows shows the default name and location of the server parameter file. The table assumes that the SPFILE is a file. If it is a raw device, the default name could be a logical volume name or partition device name, and the default location could differ. Platform Default Name UNIX Windows
spfiledbname.ora spfileSID.ora

Default Location $ORACLE_HOME/dbs or the same location as the datafiles ORACLE_BASE\ORACLE_HOME\database

If you create a server parameter file in a location other than the default location, then you must create a parameter file with the default parameter file name in the default location that points to the user-generated SPFILE. The parameter file would contain one line:
SPFILE = 'location'

The CREATE SPFILE statement can be executed before or after instance startup. However, if the instance has been started using a server parameter file, an error is raised if you attempt to re-create the same server parameter file that is currently being used by the instance.

Note: When you use the Database Configuration Assistant to create a database, it can automatically create a server parameter file for you.

The SPFILE Initialization Parameter

The SPFILE initialization parameter contains the name of the current server parameter file. When the default server parameter file is used by the server (that is, you issue a STARTUP command and do not specify a PFILE), the value of SPFILE is internally set by the server. The SQL*Plus command SHOW PARAMETERS SPFILE (or any other method of querying the value of a parameter) displays the name of the server parameter file that is currently in use. The SPFILE parameter can also be set in a traditional parameter file to indicate the server parameter file to use. You use the SPFILE parameter to specify a server parameter file located in a nondefault location. Do not use an IFILE initialization parameter within a traditional initialization parameter file to point to a server parameter file; instead, use the SPFILE parameter. See "Starting Up a Database" for details about:

Starting up a database that uses a server parameter file Using the SPFILE parameter to specify the name of a server parameter file to use at instance startup

Using ALTER SYSTEM to Change Initialization Parameter Values

The ALTER SYSTEM statement lets you set, change, or restore to default the values of initialization parameter. If you are using a traditional initialization parameter file, the ALTER SYSTEM statement changes the value of a parameter only for the current instance, because there is no mechanism for automatically updating initialization parameters on disk. You must update them manually to be passed to a future instance. Using a server parameter file overcomes this limitation.

Setting or Changing Initialization Parameter Values

Use the SET clause of the ALTER SYSTEM statement to set or change initialization parameter values. The optional SCOPE clause specifies the scope of a change as described in the following table: SCOPE Clause
SCOPE = SPFILE

Description The change is applied in the server parameter file only. The effect is as follows:

For dynamic parameters, the change is effective at the next startup and is persistent. For static parameters, the behavior is the same as for dynamic parameters. This is the only SCOPE specification allowed for static parameters.

SCOPE = MEMORY

The change is applied in memory only. The effect is as follows:

For dynamic parameters, the effect is immediate, but it is not persistent because the server parameter file is not updated. For static parameters, this specification is not allowed.

SCOPE = BOTH

The change is applied in both the server parameter file and memory. The effect is as follows:

For dynamic parameters, the effect is immediate and persistent. For static parameters, this specification is not allowed.

Exporting the Server Parameter File

You can use the CREATE PFILE statement to export a server parameter file to a traditional text initialization parameter file. Doing so might be necessary for several reasons:

To create backups of the server parameter file For diagnostic purposes, listing all of the parameter values currently used by an instance. This is analogous to the SQL*Plus SHOW PARAMETERS command or selecting from the V$PARAMETER or V$PARAMETER2 views. To modify the &spfile;server parameter file by first exporting it, editing the resulting text file, and then re-creating it using the CREATE SPFILE statement

The exported file can also be used to start up an instance using the PFILE clause. You must have the SYSDBA or the SYSOPER system privilege to execute the CREATE PFILE statement. The exported file is created on the database server machine. It contains any comments associated with the parameter in the same line as the parameter setting. The following example creates a text initialization parameter file from the server parameter file:
CREATE PFILE FROM SPFILE;

Because no names were specified for the files, the database creates an initialization parameter file with a platform-specific name, and it is created from the platform-specific default server parameter file. The following example creates a text initialization parameter file from a server parameter file, but in this example the names of the files are specified:
CREATE PFILE='/u01/oracle/dbs/test_init.ora' FROM SPFILE='/u01/oracle/dbs/test_spfile.ora';

Backing Up the Server Parameter File

You can create a backup of your server parameter file by exporting it, as described in "Exporting the Server Parameter File". If the backup and recovery strategy for your database is implemented using Recovery Manager (RMAN), then you can use RMAN to create a backup. The server parameter file is backed up automatically by RMAN when you back up your database, but RMAN also lets you specifically create a backup of the currently active server parameter file.

Starting Up a Database Using Recovery Manager

You can also use Recovery Manager (RMAN) to execute STARTUP and SHUTDOWN commands. You may prefer to do this if your are within the RMAN environment and do not want to invoke SQL*Plus.

Starting Up a Database Using Oracle Enterprise Manager

You can use Oracle Enterprise Manager (EM) to administer your database, including starting it up and shutting it down. Enterprise Manager is a separate Oracle product that combines a GUI console, agents, common services, and tools to provide an integrated and comprehensive systems management platform for managing Oracle products. EM enables you to perform the functions discussed in this book using a GUI interface, rather than command line operations.

Preparing to Start an Instance

You must perform some preliminary steps before attempting to start an instance of your database using SQL*Plus. 1. Start SQL*Plus without connecting to the database:
2. SQLPLUS /NOLOG 3.

4. Connect to Oracle Database as SYSDBA: 5. CONNECT username/password AS SYSDBA

6.

Now you are connected to the database and ready to start up an instance of your database.

Using SQL*Plus to Start Up a Database

You use the SQL*Plus STARTUP command to start up an Oracle Database instance. To start an instance, the database must read instance configuration parameters (the initialization parameters) from either a server parameter file or a traditional text initialization parameter file. When you issue the STARTUP command, by default, the database reads the initialization parameters from a server parameter file (SPFILE) in a platform-specific default location. If you have not created a server parameter file, or if you wish to use a traditional text parameter file instead, you must specify the PFILE clause of the STARTUP command to identify the initialization parameter file.

Note: For UNIX, the platform-specific default location (directory) for the server parameter file (or text initialization parameter file) is:
$ORACLE_HOME/dbs

For Windows NT and Windows 2000 the location is:

%ORACLE_HOME%\database

In the platform-specific default location, Oracle Database locates your initialization parameter file by examining filenames in the following order: 1. spfile$ORACLE_SID.ora
2. spfile.ora 3. init$ORACLE_SID.ora

Note: The spfile.ora file is included in this search path because in a Real Application Clusters environment one server parameter file is used to store the initialization parameter settings for all instances. There is no instance-specific location for storing a server parameter file. For more information about the server parameter file for a Real Application Clusters environment, see Oracle Real Application Clusters Administrator's Guide.

You can direct the database to read initialization parameters from a traditional text initialization parameter file, by using the PFILE clause of the STARTUP command. For example:
STARTUP PFILE = /u01/oracle/dbs/init.ora

It is not usually necessary to start an instance with a non default server parameter file. However, should such a need arise, you can use this PFILE clause to start an instance with a non default server parameter file as follows: 1. Create a one-line text initialization parameter file that contains only the SPFILE parameter. The value of the parameter is the non default server parameter file location. For example, create a text initialization parameter file /u01/oracle/dbs/spf_init.ora that contains only the following parameter:
SPFILE = /u01/oracle/dbs/test_spfile.ora

Note: You cannot use the IFILE initialization parameter within a text initialization

parameter file to point to a server parameter file. In this context, you must use the SPFILE initialization parameter.

2. Start up the instance pointing to this initialization parameter file.

3. STARTUP PFILE = /u01/oracle/dbs/spf_init.ora 4.

The server parameter file must reside on the machine running the database server. Therefore, the preceding method also provides a means for a client machine to start a database that uses a server parameter file. It also eliminates the need for a client machine to maintain a client-side initialization parameter file. When the client machine reads the initialization parameter file containing the SPFILE parameter, it passes the value to the server where the specified server parameter file is read. You can start an instance in various modes:

Start the instance without mounting a database. This does not allow access to the database and usually would be done only for database creation or the re-creation of control files. Start the instance and mount the database, but leave it closed. This state allows for certain DBA activities, but does not allow general access to the database. Start the instance, and mount and open the database. This can be done in unrestricted mode, allowing access to all users, or in restricted mode, allowing access for database administrators only.

Note: You cannot start a database instance if you are connected to the database through a shared server process.

In addition, you can force the instance to start, or start the instance and have complete media recovery begin immediately. The STARTUP command clauses that you specify to achieve these states are illustrated in the following section.

Starting an Instance, and Mounting and Opening a Database

Normal database operation means that an instance is started and the database is mounted and open. This mode allows any valid user to connect to the database and perform typical data access operations.

Start an instance, read the initialization parameters from the default server parameter file location, and then mount and open the database by using the STARTUP command by itself (you can, of course, optionally specify the PFILE clause):
STARTUP

Starting an Instance Without Mounting a Database

You can start an instance without mounting a database. Typically, you do so only during database creation. Use the STARTUP command with the NOMOUNT clause:
STARTUP NOMOUNT

Starting an Instance and Mounting a Database

You can start an instance and mount a database without opening it, allowing you to perform specific maintenance operations. For example, the database must be mounted but not open during the following tasks:

Enabling and disabling redo log archiving options. For more information, please refer to Chapter 7, " Managing Archived Redo Logs". Performing full database recovery. For more information, please refer to Oracle Database Backup and Recovery Basics

Start an instance and mount the database, but leave it closed by using the STARTUP command with the MOUNT clause:
STARTUP MOUNT

Restricting Access to an Instance at Startup

You can start an instance, and optionally mount and open a database, in restricted mode so that the instance is available only to administrative personnel (not general database users). Use this mode of instance startup when you need to accomplish one of the following tasks:

Perform an export or import of database data Perform a data load (with SQL*Loader) Temporarily prevent typical users from using data During certain migration and upgrade operations

Typically, all users with the CREATE SESSION system privilege can connect to an open database. Opening a database in restricted mode allows database access only to users with both the CREATE SESSION and RESTRICTED SESSION system privilege. Only database administrators should have the RESTRICTED SESSION system privilege. Further, when the instance is in restricted mode, a database administrator cannot access the instance remotely through an Oracle Net listener, but can only access the instance locally from the machine that the instance is running on.

Start an instance (and, optionally, mount and open the database) in restricted mode by using the STARTUP command with the RESTRICT clause:
STARTUP RESTRICT

Later, use the ALTER SYSTEM statement to disable the RESTRICTED SESSION feature:
ALTER SYSTEM DISABLE RESTRICTED SESSION;

Starting an Instance, Mounting a Database, and Starting Complete Media Recovery

If you know that media recovery is required, you can start an instance, mount a database to the instance, and have the recovery process automatically start by using the STARTUP command with the RECOVER clause:
STARTUP OPEN RECOVER

If you attempt to perform recovery when no recovery is required, Oracle Database issues an error message.

Automatic Database Startup at Operating System Start

Many sites use procedures to enable automatic startup of one or more Oracle Database instances and databases immediately following a system start. The procedures for performing this task are specific to each operating system. For information about automatic startup, see your operating system specific Oracle documentation.

Starting Remote Instances

If your local Oracle Database server is part of a distributed database, you might want to start a remote instance and database. Procedures for starting and stopping remote instances vary widely depending on communication protocol and operating system.

Shutting Down with the NORMAL Clause

To shut down a database in normal situations, use the SHUTDOWN command with the NORMAL clause:
SHUTDOWN NORMAL

Normal database shutdown proceeds with the following conditions:

No new connections are allowed after the statement is issued.

Before the database is shut down, the database waits for all currently connected users to disconnect from the database.

The next startup of the database will not require any instance recovery procedures.

Shutting Down with the IMMEDIATE Clause

Use immediate database shutdown only in the following situations:

To initiate an automated and unattended backup When a power shutdown is going to occur soon When the database or one of its applications is functioning irregularly and you cannot contact users to ask them to log off or they are unable to log off

To shut down a database immediately, use the SHUTDOWN command with the IMMEDIATE clause:
SHUTDOWN IMMEDIATE

Immediate database shutdown proceeds with the following conditions:

No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued. Any uncommitted transactions are rolled back. (If long uncommitted transactions exist, this method of shutdown might not complete quickly, despite its name.) Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly rolls back active transactions and disconnects all connected users.

The next startup of the database will not require any instance recovery procedures.

Shutting Down with the TRANSACTIONAL Clause

When you want to perform a planned shutdown of an instance while allowing active transactions to complete first, use the SHUTDOWN command with the TRANSACTIONAL clause:
SHUTDOWN TRANSACTIONAL

Transactional database shutdown proceeds with the following conditions:

No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued. After all transactions have completed, any client still connected to the instance is disconnected. At this point, the instance shuts down just as it would when a SHUTDOWN IMMEDIATE statement is submitted.

The next startup of the database will not require any instance recovery procedures. A transactional shutdown prevents clients from losing work, and at the same time, does not require all users to log off.

Shutting Down with the ABORT Clause

You can shut down a database instantaneously by aborting the database instance. If possible, perform this type of shutdown only in the following situations: The database or one of its applications is functioning irregularly and none of the other types of shutdown works.

You need to shut down the database instantaneously (for example, if you know a power shutdown is going to occur in one minute). You experience problems when starting a database instance.

When you must do a database shutdown by aborting transactions and user connections, issue the SHUTDOWN command with the ABORT clause:
SHUTDOWN ABORT

An aborted database shutdown proceeds with the following conditions:

No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued. Current client SQL statements being processed by Oracle Database are immediately terminated. Uncommitted transactions are not rolled back. Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly disconnects all connected users.

The next startup of the database will require instance recovery procedures.