CHAPTER - 1

Oracle Architecture – Module 1 

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. You'll notice that the database includes several different types of files: datafiles, control files, and redo log files. The Oracle server also access parameter files and password files. This set of files has several purposes. One is to enable system users to process SQL statements. Another is to improve system performance. 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. 

1

Oracle instance: An Oracle Instance consists of two different sets of components:        The first is the set of background processes (PMON, SMON, DBWR, LGWR, CKPT and others). These will be covered later in detail, but basically each background process is a computer program. These processes perform input/output and monitor other Oracle processes to provide good performance and database reliability.         The second are the memory structures that comprise the Oracle instance. When an instance starts up, a memory structure called the System Global Area (SGA) is allocated. At this point the background processes also start.         The Oracle Instance provides access to an Oracle database. An Oracle Instance opens one and only one 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.         Other files that are required include the parameter file that is used to specify parameters for configuring an Oracle instance when it starts up. The password file authenticates special users of the database – these are termed privileged users and include database administrators. The archived log files are used to recover the database if a disk fails.  User and server processes: The process circles shown in the figure are called user and server processes. These processes are used to manage the execution of SQL statements.  

Connecting to an Oracle Instance – Creating a Session 

  System users can connect to an Oracle database through SQL*Plus 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. 

2

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 SQL*Plus 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 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 – this is called the init.ora 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.        Password file – specifies which users are authenticated to startup/shut down an Oracle Instance.

3

        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 (also called the shared global area) has the following mandatory memory structures:        Shared Pool        Database Buffer Cache        Redo Log Buffer        Other structures (for example, lock and latch management, statistical data) Additional optional memory structures in the SGA include:        Large Pool        Java Pool The SGA is an area in memory that stores information shared by all database processes. This information includes both organizational data and control information used by the Oracle Server. The SGA is allocated in virtual memory. The size of the SGA is established by the parameter SGA_MAX_SIZE in the init.ora parameter file.  The following SQL command will show you the SGA memory allocations. This is a recent clip of the SGA for the Oracle database at SIUE. SHOW SGATotal System Global Area 184976376 bytesFixed Size 279544 bytesVariable Size 134217728 bytesDatabase Buffers 50331648 bytesRedo Buffers 147456 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 uses 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.

4

These are:         DB_CACHE_SIZE: This is the size of the Database Buffer Cache in database blocks. Blocks are generally 4KB each. The total blocks in the cache defaults to 48 MB on UNIX and 52 MB on NT operating systems.

        LOG_BUFFER: This is the number of bytes allocated for the Redo Log Buffer.         SHARED_POOL_SIZE: This is 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: Since 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 128MB in total, each granule is 4MB.        if the SGA is greater than 128MB in total, each granule is 16MB. Granules are assigned to the Database Buffer Cache and Shared Pool, and these two 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 48 granules. select name, block_size, current_size, prev_size, prev_buffersfrom v$buffer_pool; NAME BLOCK_SIZE CURRENT_SIZE PREV_SIZE PREV_BUFFERS--------- ---------- ------------ --------- ------------DEFAULT 4096 48 0 0 

Shared Pool

5

 

 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 is allocated to the Shared Pool by the parameter SHARED_POOL_SIZE in the init.ora parameter file. 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_MAX_SIZE parameter and since the Shared Pool is part of the SGA, you cannot exceed the maximum size of the SGA. 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.  

6

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

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

7

in the cache (a cache hit), the process reads the data from meory; 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 the 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 the 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 DBW0 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 2K, 4K, 8K, 16K, and 32K. The size of blocks in the Database Buffer Cache matches the block size for the database. The Database Buffer Cache includes three sub-caches:        DB_CACHE_SIZE – sizes the default buffer cache. This cache always exists and cannot be zero sized.        DB_KEEP_CACHE_SIZE – sizes the keep buffer cache which retains blocks in memory that are likely to be reused.        DB_RECYCLE_CACHE_SIZE – sizes the recycle buffer cache which eliminates blocks from memory that have little chance of being reused. 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. 

Redo Log Buffer 

8

 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.         Space for I/O Server Processes.         Backup and restore operations by the Recovery Manager (RMAN) process.o o       RMAN uses this only if the BACKUP_DISK_IO = n and BACKUP_TAPE_IO_SLAVE = TRUE parameters are set. 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 

9

The Java Pool is an optional memory object, but is required if the database has Oracle Java installed and in use. 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.  

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 enables 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 9i 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:

10

        SORT_AREA_SIZE.        HASH_AREA_SIZE.        BITMAP_MERGE_AREA_SIZE.        CREATE_BITMAP_AREA_SIZE.  

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 SQL*Plus, 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 (SQL*Plus, Oracle Tool, or application program) that creates a session and causes the generation of a Server Process that is either dedicated or shared.

Server Process 

11

 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 Oracle9i Database Performance Tuning course offered by Oracle Education.  

Background Processes As is shown here, there are both mandatory and optional background processes that are started whenever an Oracle Instance starts up. These background processes serve all system users. We will cover mandatory process in detail.  

Optional Background Process Definition:

12

        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" -- Dispatchers are optional background processes, present only when the shared server configuration is used. Shared server is discussed in "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 "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 additional processes (DBW1 through DBW9) 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. 

13

  

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. 

14

SMON The System Monitor (SMON) is responsible for instance recovery and 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. It also deallocates temporary segments to create free space in the datafiles. 

15

 PMON The Process Monitor (PMON) is a cleanup type of process that cleans up after failed processes. 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.  

 

16

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 Buffer fills up and a switch is made to a new Redo Log Buffer (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.  

17

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 database must always consist of at least one tablespace, although an Oracle database will almost always have several or even many tablespaces.         A tablespace is simply a logical storage facility (a logical container) for storing tables, indexes, sequences, clusters, and other database objects.         Each tablespace has at least one datafile and 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. 

18

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,

19

e.g., if the UNIX operating system block size is 2K or 4K, then the Oracle data block should be 2K, 4K, 8K, 12K, 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.

20

        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.

  END OF CHAPTER – 1

21

CHAPTER – 2

Oracle Server – Module 2 

Objectives These notes familiarize you with database administration software used by a DBA including Oracle Universal Installer, SQL*Plus, and the Oracle Enterprise Manager software. 

Database Administration Software  The table shown here details the Oracle Database Administration Software.  

DBA Software Software DescriptionOracle Universal InstallerThis software is the standard software used to install, modify (upgrade), and remove

Oracle software components for all Oracle products.Oracle Database Configuration Assistant

This is a GUI tool that can be used to create, delete, or modify databases; however, it does not provide a lot of control on the database creation process.

SQL*Plus Used by the DBA and system users to access data in an Oracle database.Oracle Enterprise ManagerA GUI tool for administering one or more databases.

 

Oracle Universal Installer The Installation Manual for the Oracle Universal Installer (OUI) is available on CD-ROM with the Oracle Enterprise Server software CD-ROM bundle. It is also available by download from the web at: http://docs.oracle.com The OUI is Java-based and enables installation for all Java-enabled operating system platforms – this makes the installation process common across platforms. The OUI performs the following tasks:Detects currently installed components including dependencies among the components and installs software as appropriate.Enables installation remotely over HTTP.Is used to remove installed products – use this instead of the Windows Operating System Software Install/Uninstall.Keeps an inventory of products on the client including product names, versions, and the names of the Oracle Home directory where software is installed.Can be used in either interactive or non-interactive mode using a response file. Startup: On a UNIX server, the installation program is runInstaller on the INSTALL\install\solaris directory of the CD-ROM. The command to install Oracle is: $ ./runInstaller On Windows NT or 2000, the installation program is setup.exe on the install/win32 directory of the CD-ROM. The command to install Oracle is:

22

 D:\> setup.exe If a response file approach is desired, file templates are available for UNIX in the stage/response directory and for Windows in the Response directory. The commands to install using a response file for UNIX and Windows are: $ ./runInstaller –responsefile filename [-silent] [-nowelcome]D:\> setup.exe –responsefile filename [-silent] where filename = the name of the response file; silent runs the installer in silent mode without feedback; and nowelcome means the Welcome window does not display. A sample response file set of commands for UNIX is shown here.  

Oracle Database Configuration Assistant This assistant is covered in more detail in a later lesson. It allows you to:        Create a database        Configure database options        Delete a database        Manage templates used for these tasks.  

Special Database Administrative Users Database administrators require extra privileges in order to administer an Oracle database. In a UNIX and Windows environment, some of these privileges are granted by assigning user accounts to special groups. On our UNIX server, you'll find that your account is assigned to the DBA group. There are two special database user accounts named SYS and SYSTEM that are always created automatically whenever an Oracle database is created. These accounts are granted the role DBA which is a special role that is predefined with every database and has all of the system privileges needed to perform DBA activities.  SYS:         The user SYS is identified initially with the password change_on_install.        SYS is the owner of the data dictionary.        When you connect to a database as sys, it will be by specifying that the connection is made as either SYSDBA or SYSOPER. These are two special privilege classifications used to identify DBAs and privileged connections are enabled through use of a password file that is discussed in detail in a later module.        Here is a sample connection script for a connection to the Oracle database at SIUE by the user SYS using SQL*Plus. Note that when queried for the ORACLE_SID (Oracle system identifier that identifies the name of the database), that user350 responded with oracle. <invoke a telnet window from MS Windows by executing Run telnet oracle.siue.edu>SunOS 5.6 

23

login: user350Password:Last login: Fri Jun 7 16:45:45 from dbock.fh.siue.edSun Microsystems Inc. SunOS 5.6 Generic August 1997You have mail.ORACLE_SID = [user350] ? oracle$ sqlplus /nolog SQL*Plus: Release 9.0.1.0.0 - Production on Sat Jun 8 18:20:44 2002 (c) Copyright 2001 Oracle Corporation. All rights reserved. SQL> connect sys as sysdbaEnter password:Connected.SQL> SYSTEM:        The user SYSTEM is identified initially by the password manager.        Tables and views created/owned by the user SYSTEM contain administrative information used by Oracle tools such as designer. Additional DBA accounts may be created for a database to perform routine day-to-day administrative duties. The passwords for SYS and SYSTEM should be immediately changed for the Oracle database.  

SQL*Plus As you saw above, you can connect to SQL*Plus in order to do the following:        Work with a database.        Startup and shutdown a database.        Create and run queries, modify row data, add rows, etc. SQL*Plus includes standard SQL plus additional add-on commands, such as the DESCribe command that Oracle provides to make working with databases easier.  When you use SQL*Plus for startup and shutdown of a database, you will connect using /nolog mode, then connect as sysdba. The following sequence also works where the user account/password is not provided for your specially identified accounts. $ sqlplus /nolog SQL*Plus: Release 9.0.1.0.0 - Production on Sat Jun 8 18:26:12 2002 (c) Copyright 2001 Oracle Corporation. All rights reserved. SQL> connect / as sysdbaConnected.SQL>  

Oracle Enterprise Manager

24

 The Oracle Enterprise Manager (OEM) is a GUI, Java-based console product that enables you to manage a number of Oracle tools and services, and the network of management servers and intelligent agents used to track Oracle databases. With OEM, you can manage multiple databases from a single client platform. OEM has common services including batch job scheduling, event management, and database discovery and management. OEM includes integrated applications with the following optional packages that can be installed:        Diagnostics Pack        Tuning Pack        Change Management Pack        Oracle Net Manager        Spatial Index Advisor        Text Manager Information that OEM needs in order for a DBA to manage databases is stored in the OEM repository. The OEM repository is a database itself of information about databases. You can install OEM as a separate database on a server, or as a tablespace within an existing database. This latter approach is taken at SIUE. 

  The three-tier architecture shown in the figure above is used by OEM.  First Tier: The first tier includes client computers that provide a graphical user interface for DBAs.  Second Tier: The second tier includes the Oracle Management Server (OMS) and the accompanying database repository. The Oracle Management Server is a program that executes on the server where the OEM repository/database is located. OMS is started on our UNIX machine as shown in these commands. In order to stop OMS, you must be a privileged owner of the OEM repository (which you as students are not). $ oemctlUsage: oemctl start oms oemctl stop oms <EM Username>/<EM Password>

25

oemctl status oms <EM Username>/<EM Password>[@<OMS-hostname>] Third Tier: Ann Intelligent agent software package is installed on each node to monitor services provided by that node in an organizational network and these agents execute tasks from the Management Server. The ID for the intelligent agent is dbsnmp. OEM also enables a two-tier architecture that connects directly to a database to allow a single person to manage an application without using OMS. The figures shown below first give the screen used to connect to OEM, then display the Console. Here the connection is made to the OMS as opposed to launching standalone. 

 This is the main Console screen. It shows that a single database named Oracle has been discovered and added to the Console from the network. This Console image shows the Oracle database expanded. The storage manager option is displaying the tablespaces that comprise the Oracle database at SIUE.

26

  

 

END OF CHAPTER - 2

27

CHAPTER – 3

Database Startup – Module 3 

Objectives  These notes cover the use of environment variables and Oracle naming conventions for files. You will learn to create and understand initialization parameter files and several of the specified parameters. You will also learn to startup and shutdown an Oracle Instance, and to use diagnostic files.  

Environment Variables UNIX Variables Oracle makes use of environment variables on the server and client computers in both UNIX and Windows operating systems in order (1) establish standard locations for files, and (2) make it easier for you to use Oracle.  On UNIX, environment variables values can be displayed by typing the command env at the $ prompt. The following environment variables in a UNIX environment are used for the server. HOMECommand: HOME=/u01/faculty/dbockUse: Stores the location of the home directory for your files for your assigned UNIX account. You can always easily change directories to your HOME by typing the command: cd $HOME Note: The $ is used as the first character of the environment variable so that UNIX uses the value of the variable as opposed to the actual variable name. LD_LIBRARY_PATHCommand: LD_LIBRARY_PATH=/u07/app/oracle/product/9.0.1/lib:/usr/openwin/lib:/usr/dt/libUse: Stores the path to the library products used most commonly by you. Here the first entry in the path points to the library products for Oracle that are located in the directory /u07/app/oracle/product/9.0.1/lib. Path entries are separated by a colon. 

ORACLE_BASECommand: ORACLE_BASE=/u07/app/oracleUse: Stores the base directory for the installation of Oracle products. Useful if more than one version of Oracle is loaded on a server. Other than that, this variable does not have much use. ORACLE_HOMECommand: ORACLE_HOME=/u07/app/oracle/product/9.0.1Use: Enables easy changing to the home directory for Oracle products. All directories that you will use are hierarchically below this one. The most commonly used subdirectories are named dbs and rdbms.

28

 ORACLE_SIDCommand: ORACLE_SID=oracleUse: Tells the operating system the system identifier for the database. At SIUE we have elected to name the database oracle because that makes it easier to remember. When you create your own databases, you will use your account logon name as the system identifier for your database. ORACLE_TERMCommand: ORACLE_TERM=vt100Use: In UNIX, this specifies the terminal emulation type. The vt100 is a very old type of emulation for keyboard character input. PATHCommand: PATH=.:/u07/app/oracle/product/9.0.1/bin:/opt/bin:/bin:/usr/bin:/usr/ccs/bin:/etc:/opt/SUNWspro/bin:/opt/SUNWspro/SC4.0/include/CCUse: This specifies path pointers to the most commonly used binary files. A critical entry for using Oracle is the /u07/app/oracle/product/9.0.1/bin entry that points to the Oracle binaries. If you upgrade to a new version of Oracle, you will need to upgrade this path entry to point to the new binaries. Environment variable values can be changed at the UNIX prompt by entering a new value and using the UNIX export command. An example is shown here: $ ORACLE_SID=user350; export ORACLE_SID 

Windows Variables In a Windows operating system environment, environment variables are established by storing entries into the system registry. Your concern here is primarily with the installation of Oracle tools software on a client computer.  Windows and Oracle allows and recommends the creation of more than one ORACLE_HOME directory (folder) on a Windows client computer. This is explained in more detail in the installation manuals for the various Oracle software products. Basically, you should use one folder as an Oracle Home for Oracle Enterprise Manager software and a different folder as an Oracle Home for Oracle's Internet Developer Suite – this suite of software includes Oracle's Forms, Reports, Designer, and other tools for developing internet-based applications.  

Initialization Parameter Files When an Oracle Instance is started, the characteristics of the Instance are established by parameters specified within the initialization parameter file that is read during startup. In the figure shown below, the initialization parameter file is named spfiledb01.ora; however, you can select any name for the parameter file.  

29

 There are two types of initialization parameter files: ·        Static parameter file: This has always existed and is known as the PFILE and is commonly referred to as the init.ora file. The actual naming convention used is to name the file initSID.ora where SID is the system identifier (database name) assigned to the database. ·        Persistent parameter file: This is the SPFILE and is commonly referred to as the spfileSID.ora.  There are two types of parameters:·        Explicit parameters. These have entries in the parameter file.·        Implicit parameters. These have no entries in the parameter file and Oracle uses default values. Initialization parameter files include the following:·        Instance parameters.·        A parameter to name the database associated with the file.·        SGA memory allocation parameters.·        Instructions for handling online redo log files.·        Names and locations of control files.·        Undo segment information.  PFILE This is a plain text file. I usually maintain this file either by editing it with the UNIX vi editor or by FTPing it to my client computer, using Notepad, and then FTPing it back to the Oracle server. The file is only read during database startup so any modifications take effect the next time the database is started up. This is an obvious limitation since shutting down and starting up an Oracle database is not desirable in a 24/7 operating environment. 

30

 The naming convention followed is to name the file initSID.ora where SID is the system identifier. For example, the PFILE for the ORACLE database is named initoracle.ora. When Oracle software is installed, a sample init.ora file is created. You can create one for your database by simply copying the init.ora sample file and renaming it. The sample command shown here creates an init.ora file for a database named user350. The file is created in the user's HOME directory and is named inituser350.ora. $ cp $ORACLE_HOME/dbs/init.ora $HOME/inituser350.ora You can also create an init.ora file by typing commands into a plain text file using an editor such as notepad.  

 ·        The example above shows the format for specifying values: keyword = value.·        Each parameter has a default value that is often operating system dependent. ·        Generally parameters can be specified in any order.·        Comment lines are indicated with the # symbol at the beginning of the comment.·        Enclose parameters in double quotation marks to include literals.·        Usually operating systems such as UNIX are case sensitive so remember this in specifying file names.  

SPFILE The SPFILE is a binary file that is new to Oracle 9i. You should not manually modify the file and it must always reside on the server. After the file is created, it is maintained by the Oracle server. The SPFILE enables you to make changes that are termed persistent across startup and shutdown operations. You can make dynamic changes to Oracle while the database is running and this is the main advantage of using this file.  The default location is in the $ORACLE_HOME/dbs directory with a default name of spfileSID.ora.  

31

 As is shown in the figure above, you can create an SPFILE from an existing PFILE by typing in the command shown while using SQL*Plus. Note that the filenames are enclosed in single-quote marks.  

Recreating a PFILE You can also create a PFILE from an SPFILE by exporting the contents through use of the CREATE command. You do not have to specify file names as Oracle will use the spfile associated with the ORACLE_SID for the database to which you are connected.  CREATE PFILE FROM SPFILE; You would then edit the PFILE and use the CREATE command to create a new SPFILE from the edited PFILE.  

The STARTUP Command The STARTUP command is used to startup an Oracle database. We've seen two different initialization parameter files. There is a precedence to which initialization parameter file is read when an Oracle database starts up as only one of them is used.  ·        First Priority: the spfileSID.ora on the server side is used to start up the instance. ·        Second Priority: If the spfileSID.ora is not found, the default SPFILE on the server side is used to start the instance. ·        Third Priority: If the default SPFILE is not found, the initSID.ora on the server side will be used to start the instance. A specified PFILE can override the use of the default SPFILE to start the instance. For example: STARTUP PFILE = $ORACLE_HOME/dbs/inituser350.ora A PFILE can optionally contain a definition to indicate use of an SPFILE. This is the onlyway to start the instance with an SPFILE in a non-default location. To start the database with an SPFILE not in the default location, SPFILE=<full path and filename> mustbe placed in the PFILE. Example PFILE parameter:

32

SPFILE=$HOME/ADMIN/PFILE/$ORACLE_SID.ora Modifying SPFILE Parameters Earlier you read that an advantage of the SPFILE is that certain dynamic parameters can be changed without shutting down the Oracle database. These changes are made as shown in the figure below by using the ALTER SYSTEM command. Modifications made in this way change the contents of the SPFILE. If you shutdown the database and startup again, the modifications you previously made will take effect because the SPFILE was modified.

 The ALTER SYSTEM SET command is used to change the value of instance parameters and has a number of different options as shown here. ALTER SYSTEM SET parameter_name = parameter_value[COMMENT 'text'] [SCOPE = MEMORY|SPFILE|BOTH][SID= 'sid'|'*'] where ·        parameter_name: Name of the parameter to be changed·        parameter_value: Value the parameter is being changed to·        COMMENT: A comment to be added into the SPFILE next to the parameter being altered·        SCOPE: Determines if change should be made in memory, SPFILE, or in both areas·        MEMORY: Changes the parameter value only in the currently running instance·        SPFILE: Changes the parameter value in the SPFILE only·        BOTH: Changes the parameter value in the currently running instance and the SPFILE·        SID: Identifies the ORACLE_SID for the SPFILE being used·        'sid': Specific SID to be used in altering the SPFILE·        '*': Uses the default SPFILE Here is an example coding script within SQL*Plus that demonstrates how to display current parameter values and to alter these values.  SQL> SHOW PARAMETERS undo_suppress_errors 

33

NAME TYPE VALUE------------------------------------ ----------- -----undo_suppress_errors boolean TRUESQL> ALTER SYSTEM SET undo_suppress_errors = FALSE 2 COMMENT = 'temporary setting' SCOPE=BOTH 3 SID='oracle'; System altered. SQL> SHOW PARAMETERS undo_suppress_errors NAME TYPE VALUE------------------------------------ ----------- -----undo_suppress_errors boolean FALSE You can also use the ALTER SYSTEM RESET command to delete a parameter setting or revert to a default value for a parameter. SQL> ALTER SYSTEM RESET undo_suppress_errors 2 SCOPE=BOTH 3 SID='oracle'; System altered. SQL> SHOW PARAMETERS undo_suppress_errors; NAME TYPE VALUE------------------------------------ ----------- -----undo_suppress_errors boolean FALSE  

Starting Up a Database 

Instance Stages Databases can be started up in various states or stages. The diagram shown below illustrates the stages through which a database passes during startup and shutdown. 

34

  NOMOUNT: This stage is only used when first creating a database or when it is necessary to recreate a database's control files. Startup includes the following tasks. ·        Read the spfileSID.ora or spfile.ora or initSID.ora. ·        Allocate the SGA. ·        Startup the background processes. ·        Open a log file named alertSID.log and any trace files specified in the initialization parameter file. ·        Example startup commands for creating the Oracle database and for the database belonging to USER350 are shown here. SQL> STARTUP NOMOUNT PFILE=$ORACLE_HOME/dbs/initoracle.oraSQL> STARTUP NOMOUNT PFILE=$HOME/inituser350.ora MOUNT: This stage is used for specific maintenance operations. The database is mounted, but not open. You can use this option if you need to:·        Rename datafiles.·        Enable/disable redo log archiving options.·        Perform full database recovery.·        When a database is mounted it o       is associated with the instance that was started during NOMOUNT stage.o       locates and opens the control files specified in the parameter file.o       reads the control file to obtain the names/status of datafiles and redo log files, but it does not check to verify the existence of these files.·        Example startup commands for maintaining the Oracle database and for the database belonging to USER350 are shown here. byeSQL> STARTUP MOUNT PFILE=$ORACLE_HOME/dbs/initoracle.oraSQL> STARTUP MOUNT PFILE=$HOME/inituser350.ora OPEN: This stage is used for normal database operations. Any valid user can connect to the database. Opening the database includes opening datafiles and redo log files. If any of these files are missing, Oracle will return an error. If errors occurred during the previous database shutdown, the SMON background process will initiate instance recovery. An example command to startup the database in OPEN stage is shown here.

35

 SQL> STARTUP PFILE=$ORACLE_HOME/dbs/initoracle.oraSQL> STARTUP PFILE=$HOME/inituser350.ora If the database initialization parameter file is in the default location at $ORACLE_HOME/dbs, then you can simply type the command STARTUP and the database associated with the current value of ORACLE_SID will startup. Startup Command Options: You can force a restart of a running database that aborts the current Instance and starts a new normal instance with the FORCE option. SQL> STARTUP FORCE PFILE=$HOME/inituser350.ora Sometimes you will want to startup the database, but restrict connection to users with the RESTRICTED SESSION privilege so that you can perform certain maintenance activities such as exporting or importing part of the database.  SQL> STARTUP RESTRICT PFILE=$HOME/inituser350.ora You may also want to begin media recovery when a database starts where your system has suffered a disk crash. SQL> STARTUP RECOVER PFILE=$HOME/inituser350.ora On a UNIX server, you can automate startup/shutdown of an Oracle database by making entries in a special operating system file named oratab located in the /var/opt/oracle directory.  IMPORTANT NOTE: If an error occurs during a STARTUP command, you must issue a SHUTDOWN command prior to issuing another STARTUP command.

 ALTER DATABASE Command You can change the stage of a database. This example changes the database from MOUNT to OPEN. SQL> startup mount pfile=$HOME/inituser350.oraORACLE instance started. Total System Global Area 25535380 bytesFixed Size 279444 bytesVariable Size 20971520 bytesDatabase Buffers 4194304 bytesRedo Buffers 90112 bytesDatabase mounted.SQL> ALTER DATABASE user350 OPEN READ ONLY; Database altered. 

36

 Restricted Mode Earlier you learned to startup the database in a restricted mode with the RESTRICT option. If the database is open, you can change to a restricted mode with the ALTER SYSTEM command as shown here. The first command restricts logon to users with restricted privileges. The second command enables all users to connect. SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION; One of the tasks you may perform during restricted session is to kill current user sessions prior to performing a task such as the export of objects (tables, indexes, etc.). The ALTER SYSTEM KILL SESSION 'integer1, integer2' command is used to do this. The values of integer1 and integer2 are obtained from the SID and SERIAL# columns in the V$SESSION view. The first six SID values shown below are for background processes and should be left alone! Notice that the users SYS and USER350 are connected. We can kill the session for USER350. SQL> SELECT sid, serial#, username FROM v$session;  SID SERIAL# USERNAME---------- ---------- ---------------------------- 1 1 2 1 3 1 4 1 5 1 6 1 7 3 SYS 9 9 USER350 SQL> ALTER SYSTEM KILL SESSION '9,9'; System altered. Now when USER350 attempts to select data, the following message is received. SQL> SELECT * FROM My_Table;SELECT * FROM My_Table*ERROR at line 1:ORA-00028: your session has been killed When a session is killed, PMON will rollback the user's current transaction and release all table and row locks held and free all resources reserved for the user. 

37

READ ONLY Mode You can open a database as read-only provided it is not already open in read-write mode. This is useful when you have a standby database that you want to use to enable system users to execute queries while the production database is being maintained.  

Database Shutdown The SHUTDOWN command is used to shutdown a database instance. You must be connected as either SYSOPER or SYSDBA to shutdown a database.  Shutdown Normal: This is the default shutdown mode. ·        No new connections are allowed.·        The server waits for all users to disconnect before completing the shutdown.·        Database and redo buffers are written to disk.·        The SGA memory allocation is released and background processes terminate.·        The database is closed and dismounted.·        The shutdown command is: Shutdown orShutdown Normal

 Shutdown Transactional: This prevents client computers from losing work.·        No new connections are allowed.·        No connected client can start a new transaction.·        Clients are disconnected as soon as the current transaction ends.·        Shutdown proceeds when all transactions are finished.·        The shutdown command is: Shutdown Transactional Shutdown Immediate: This can cause client computers to lose work.·        No new connections are allowed.·        Connected clients are disconnected and SQL statements in process are not completed.·        Oracle rolls back active transactions.·        Oracle closes/dismounts the database.·        The shutdown command is: Shutdown Immediate Shutdown Abort: This is used if the normal or transactional or immediate options fail. This is the LEAST favored option because the next startup will require instance recovery and you CANNOT backup a database that has been shutdown with the ABORT option.·        Current SQL statements are immediately terminated.·        Users are disconnected.·        Database and redo buffers are NOT written to disk.·        Uncommitted transactions are NT rolled back.·        The Instance is terminated without closing files.

38

·        The database is not closed or dismounted.·        Database recovery by SMON must occur on the next startup.·        The shutdown command is: Shutdown Abort  

Diagnostic Files These files are used to store information about database activities and are useful tools for troubleshooting and managing a database. There are several types of diagnostic files. ·        The alertSID.log file is created and the default location is the $ORACLE_HOME/rdbms/log directory, although a different location can be specified in the initialization parameter file by the BACKGROUND_DUMP_DEST parameter.o       Each Oracle instance generates an alertSID.log file. As the DBA you need to monitor it on a daily basis.o       The log will grow in size over time as new information is written to it. You will periodically need to delete the file – a new one will be automatically generated.o       This file stores information about when the database was started, shutdown, all non-default initialization parameters, the thread being used by an Instance, the log sequence number for LGWR, information on log switches, the creation of tablespaces and undo segments, the results of all ALTER statements, and other error messages.·        Background trace files are generated by background processes such as SMON and PMON when problems occur.o       The naming conventions is: sid_processname_PID.trc. o       The location is specified by the BACKGROUND_DUMP_DEST parameter.o       Delete these files after you have solved the problem logged by the background process.·        User trace files store information about fatal user errors.o       The naming convention is: sid_ora_PID.trc.o       The location is specified by the USER_DUMP_DEST parameter.o       Delete these files after you have solved the problem generated by the system user.o       You can enable or disable user tracing with the ALTER SESSION command as shown here.  ALTER SESSION SET SQL_TRACE = TRUE o       You can also set the SQL_TRACE = TRUE parameter in the initialization parameter files.  END OF CHAPTER - 3

39