Database Administration & Management · 1.3.2. Oracle Database Configuration Assistant Oracle Database Configuration Assistant (DBCA) is a utility that creates a database from templates

Prepared By:

Lecturer CS/IT

MCS, M.Phil (CS)

Database Administration &

Management IT- 3441

Database Administration & Management IT- 3441

`

By: Muhammad Shahid Azeem M Phil.

www.risingeducation.com Page 2

Dedication

All glories praises and gratitude to Almighty Allah Pak, who blessed

us with a super, unequalled processor! Brain…

I dedicate all of my efforts to my students who gave me an urge and

inspiration to work more.

I also dedicate this piece of effort to my family members who always

support me to move on. Especially, my father (Ch. Ali Muhammad)

who pushed me ever and makes me to stand at this position today.

Muhammad Shahid Azeem

Author


`



Course Outline 1. Installation; SQL* Plus; Oracle Enterprise Manager; DBA Tools. Oracle Architectural Components: Oracle Server; Oracle Instance.

2. Physical Structure; SGA; Shared Pool; Library Cache; Data Dictionary Cache; Large Pool;

User Process; Server Process; Background Processes.

3. Managing an Oracle Instance: Parameter File; Creating SPFILE; Oracle Managed Files; Startup and Shutdown Database; Alert Log File; Background Trace File; User Trace File. 4. Creating Database and Data dictionary.

5. Managing Control Files and Redo Log Files.

6. Managing Table spaces, Operations with Table spaces.

7. Data File Management, Segments, Block.

8. Managing Undo Data, Undo Data Statistics: Managing Tables and Users:

9. Indexes Management, Maintaining Data Integrity, Constraints. Managing Privileges.

10. Basic Oracle Net Architecture: Types of Networks, Oracle Net Services, Oracle Shared Server, Connection Manager, Oracle Net Connections.

11. Server Side Configuration: The Listener Process; Configuring Listener, Sessions, Creating and Managing Listener.

12. Client Side Configuration: Host Naming Method, Local Naming Method, Net Assistant, Configurations. Usage and Configuration of Oracle Shared Server.

13. Backup and Recovery, Instance and Media Recovery, Configuration of Archive log mode, User Managed Complete Recovery, Loading Data into Database, Tuning Tools, Sizing Shared Pool, Sizing Buffer Cache, I/O Issues.

14. Tuning Rollback Segments, Latches, Rollback Segment Tuning Shared Servers, Types of Locks, Block Efficiency, Storage hierarchy, Avoiding Dynamic allocation, Statistics, PCTFREE and PCTUSED, Monitoring Index Usage.

Textbook(s):

• Oracle Database 11g DBA Handbook by Bob Bryla and Kevin Loney, McGraw-Hill Osborne Media; 1st Edition (December 6, 2007). ISBN-10: 0071496637

• Database Administration: The Complete Guide to DBA Practices and Procedures by Craig S. Mullins, Addison-Wesley Professional; 2nd Edition (October 21, 2012). ISBN-10: 0321822943


`



This page is left blank intentionally


`



Chapter 01

Physical Structure

1.1. Introduction:

1.1.1. Database:

A database is a collection of data on disk in one or more files on a database server that collects and maintains related information. The database consists of various physical and logical structures, the table being the most important logical structure in the database. A table consists of rows and columns containing related data. At a minimum, a database must have at least tables to store useful information. Figure 1.1 shows a sample table containing four rows and three columns. The data in each row of the table is related: Each row contains information about a particular employee in the company.

Figure 1.1: a sample database table of employees

In addition, a database provides a level of security to prevent unauthorized access to the data. Oracle Database 11g provides many mechanisms to facilitate the security necessary to keep confidential data confidential.

Files composing a database fall into two broad categories: database files and non-database files. The distinction lies in what kind of data is stored in each. Database files contain data and metadata; non-database files contain initialization parameters, logging information, and so forth. Database files are critical to the ongoing operation of the database on a moment-by-moment basis.

1.1.2. Instance

The main components of a typical enterprise server are one or more CPUs, disk space, and memory. Whereas the Oracle database is stored on a server’s disk, an Oracle instance exists in the server’s memory. An Oracle instance is composed of a large block of memory allocated in an area called the System Global Area (SGA), along with a number of background processes that interact between the SGA and the database files on disk.

In an Oracle Real Application Cluster (RAC), more than one instance will use the same database. Although the instances that share the database can be on the same server, most likely the instances will be on separate servers that are connected by a high-speed interconnect and access a database that resides on a specialized RAID-enabled disk subsystem.


`



1.1.3. Oracle Database

Oracle Database is a relational database with object and Extensible Markup Language (XML) capabilities. In a relational database, all data is stored in two-dimensional tables that are composed of rows and columns. Oracle Database enables you to store data, update it, and efficiently retrieve it, with a high degree of performance, reliability, and scalability. Oracle Database is composed of the following elements:

The Oracle software that you install on your host computer The database, which is a collection of physical files on one or more disks

The database contains user data, metadata, and control structures. Metadata, or data about the data, is the collection of information on disk that permits

Oracle software to manage user data. An example of metadata is the data dictionary. Control structures (such as the control file and online redo log files) ensure the integrity, availability, and recoverability of user data. The Oracle instance, which is composed of the following:

1. The background processes, which are the operating system processes or threads that perform the work of accessing, storing, monitoring, and recovering user data, metadata, and control files associated with the database. The shared memory areas used by the background processes

2. Server processes that perform work on behalf of connected users and applications, and the memory and temporary storage used by these processes. Server processes parse and execute SQL statements, and retrieve and return results to the user or application.

3. Oracle Net, which is a software layer that enables client applications and Oracle Database to communicate over a network, and the Oracle Net listener, which is a process that listens for connection requests from the network.

1.2. Common Oracle DBA Tasks

As an Oracle DBA, one can expect to be involved in the following tasks: Installing Oracle software. Creating Oracle databases. Performing upgrades of the database and software to new release levels. Starting and shutting down the database instance. Managing the storage structures of the database. Managing users and security. Managing database objects, such as tables, indexes, and views Backing up the database and performing recovery operations when necessary Monitoring the state of the database and taking preventive or corrective action as

required Monitoring and tuning database performance Diagnosing and reporting critical errors to Oracle Support Services

In a small to medium-sized database environment, DBA might be the sole person performing all of these tasks. In large enterprise environments, the job is often divided among several DBAs, each of whom has a specialty, such as database security or database tuning.

1.3. Tools for Administering the Database

The following are some products, tools, and utilities a DBA can use to achieve his goals as a database administrator:


`



1.3.1. Oracle Universal Installer

Oracle Universal Installer (OUI) is a utility that installs your Oracle software and options. It can automatically start Oracle Database Configuration Assistant to install a database.

1.3.2. Oracle Database Configuration Assistant

Oracle Database Configuration Assistant (DBCA) is a utility that creates a database from templates that are supplied by Oracle, or you can create your own. It enables you to copy a preconfigured seed database, thus saving the time and effort of generating and customizing a new database.

1.3.3. Database Upgrade Assistant

The Database Upgrade Assistant is a tool that guides you through the upgrade of your existing database to a new Oracle Database release.

1.3.4. Net Configuration Assistant

Net Configuration Assistant (NETCA) is a utility that enables you to configure listeners and naming methods, which are critical components of the Oracle Database network.

1.3.5. Oracle Enterprise Manager Database Control

The primary product for managing your database is Oracle Enterprise Manager Database Control (Database Control), a Web-based interface. After you have installed the Oracle Database software, created or upgraded a database, and configured the network, you can use Database Control to manage your database. Database Control also provides an interface for performance advisors and for Oracle utilities such as SQL*Loader and Recovery Manager (RMAN). Oracle also offers separately licensed Oracle Enterprise Manager management packs,

management plug-ins, and other products you can purchase to enhance the capabilities of Oracle Enterprise Manager in specific environments.

1.4. Oracle Architectural Components:

The Oracle architecture includes a number of primary components. These are as follow:

1.4.1. Oracle Server:

An oracle server is a database management system that provides an open, comprehensive, integrated approach to information management. An oracle server reliably manages a large amount of data in a multiuser environment. It ensures that multiple users can share the same data concurrently. It also ensures the high performance. It also provides security and backup and recovery facilities. There are several files, processes and memory structures in an oracle server. All of these components are not used during the processing of a SQL Statement. Some of them are used to improve the performance of database, to ensure that the database can be recovered in the case of software or hardware error, or to perform other tasks necessary to maintain database. The Oracle server consists of an Oracle server and an oracle database.


`



Figure 1.2: Oracle Architectural Components.

1.4.2. Oracle Instance:

An Oracle instance (also known as a database instance) contains the set of Oracle Database background processes that operate on the stored data and the shared allocated memory that those processes use to do their work.

Each instance has an instance ID, also known as a system ID (SID). Because there can be multiple Oracle databases on a host computer, each with its own set of data files, you must identify the instance to which you want to connect. For a local connection, you identify the instance by setting operating system environment variables ORACLE_SID and ORACLE_HOME. For a remote connection, you identify the instance by specifying a network address and a database service name.

An Oracle instance must be started to read and write information to the database. The Oracle instance creates the database upon receipt of instructions from the Oracle Database Configuration Assistant (DBCA) utility or the CREATE DATABASE SQL statement.

When the Oracle instance is not available, data is safe in the database, but it cannot be accessed by any user or application.

The properties of an Oracle instance are specified using instance initialization parameters. When the instance is started, an initialization parameter file is read, and the instance is configured accordingly.

Every time an instance is started, a System Global Area (SGA) is allocated and Oracle background processes are stated. Background processes perform various functions on the behalf of invoking processes.

Figure 1.3: Oracle Instance


`



1.5. Oracle Logical Storage Structures:

The data-files in an Oracle database are grouped together into one or more tablespaces. Within each tablespace, the logical database structures, such as tables and indexes, are segments that are further subdivided into extents and blocks. This logical subdivision of storage allows Oracle to have more efficient control over disk space usage.

Figure 1.4: Oracle logical storage structures

1.5.1. Tablespaces

An Oracle tablespace consists of one or more datafiles; a datafile can be a part of one and only one tablespace. For an installation of Oracle 11g, a minimum of two tablespaces are created: the SYSTEM tablespace and the SYSAUX tablespace; a default installation of Oracle 11g creates six Tablespaces. Tablespaces can be either dictionary managed or locally

managed. In a dictionary managed tablespace, extent management is recorded in data dictionary tables. Therefore, even if all application tables are in the USERS tablespace, the SYSTEM tablespace will still be accessed for managing DML on application tables. Because all users and applications must use the SYSTEM tablespace for extent management, this creates a potential bottleneck for write intensive applications. In a locally managed tablespace, Oracle maintains a bitmap in each data file of the tablespace to track space availability.

1.5.2. Blocks

A database block is the smallest unit of storage in the Oracle database. The size of a block is a specific number of bytes of storage within a given tablespace within the database.

A block is usually a multiple of the operating system block size to facilitate efficient disk I/O. The default block size is specified by the Oracle initialization parameter DB_BLOCK_SIZE. As many as four other block sizes may be defined for other tablespaces in the database, although the blocks in the SYSTEM, SYSAUX, and any temporary tablespaces must be of the size DB_BLOCK_SIZE.

1.5.3. Extents

The extent is the next level of logical grouping in the database. An extent consists of one or more database blocks. When you enlarge a database object, the space added to the object is allocated as an extent.

1.5.4. Segments

The next level of logical grouping in a database is the segment. A segment is a group of extents typically the smallest unit of storage that an end user of the database will deal with.


`



Four types of segments are found in an Oracle database: data segments, index segments, temporary segments, and rollback segments.

1.5.4.1.Data Segment

Every table in the database resides in a single data segment, consisting of one or more extents; Oracle allocates more than one segment for a table if it is a partitioned table or a clustered table. Data segments include LOB (large object) segments that store LOB data referenced by a LOB locator column in a table segment (if the LOB is not stored inline in the table).

1.5.4.2.Index Segment

Each index is stored in its own index segment. As with partitioned tables, each partition of a partitioned index is stored in its own segment. Included in this category are LOB index segments; a table’s non LOB columns, a table’s LOB columns, and the LOBs’ associated indexes can all reside in their own tablespace to improve performance.

1.5.4.3.Temporary Segment

When a user’s SQL statement needs disk space to complete an operation, such as a sorting operation that cannot fit in memory, Oracle allocates a temporary segment. Temporary segments exist only for the duration of the SQL statement.

1.5.4.4.Rollback Segment

Automatic Undo Management handles the automatic allocation and management of rollback segments within an undo tablespace. Within an undo tablespace, the undo segments are structured similarly to rollback segments.

1.6. Oracle Physical Storage Structures:

The Oracle database uses a number of physical storage structures on disk to hold and manage the data from user transactions. Some of these storage structures, such as the datafiles, redo log files, and archived redo log files, hold actual user data; other structures, such as control files, maintain the state of the database objects, and text-based alert and trace files contain logging information for both routine events and error conditions in the database. Figure 1.5 shows the relationship between these physical structures and the logical storage structures.

1.6.1. Datafiles

Every Oracle database must contain at least one datafile. One Oracle datafile corresponds to one physical operating system file on disk. Each datafile in an Oracle database is a member of one and only one tablespace; a tablespace, however, can consist of many datafiles. (A BIGFILE tablespace consists of exactly one datafile.)

An Oracle datafile may automatically expand when it runs out of space, if the DBA created the datafile with the AUTOEXTEND parameter. The DBA can also limit the amount of expansion for a given datafile by using the MAXSIZE parameter. In any case, the size of the datafile is ultimately limited by the disk volume on which it resides. The datafile is the ultimate resting place for all data in the database. Frequently accessed blocks in a datafile are cached in memory; similarly, new data blocks are not immediately written out to the datafile but rather are written to the datafile depending on when the database writer process is active. Before a user’s transaction is considered complete, however, the transaction’s changes are written to the redo log files.

1.6.2. Redo Log Files

Whenever data is added, removed, or changed in a table, index, or other Oracle object, an entry is written to the current redo log file. Every Oracle database must have at least two redo log files, because Oracle reuses redo log files in a circular fashion. When one


`



redo log file is filled with redo log entries, the current log file is marked as ACTIVE, if it is still needed for instance recovery, or INACTIVE, if it is not needed for instance recovery; the next log file in the sequence is reused from the beginning of the file and is marked as CURRENT.

Ideally, the information in a redo log file is never used. However, when a power failure occurs, or some other server failure causes the Oracle instance to fail, the new or updated data blocks in the database buffer cache may not yet have been written to the datafiles. When the Oracle instance is restarted, the entries in the redo log file are applied to the database datafiles in a roll forward operation, to restore the state of the database up to the point where the failure occurred.

To be able to recover from the loss of one redo log file within a redo log group, multiple copies of a redo log file can exist on different physical disks. Later in this chapter, you will see how redo log files, archived log files, and control files can be multiplexed to ensure the availability and data integrity of the Oracle database.

1.6.3. Control Files

Every Oracle database has at least one control file that maintains the metadata of the database (in other words, data about the physical structure of the database itself). Among other things, it contains the name of the database, when the database was created, and the names and locations of all datafiles and redo log files. In addition, the control file maintains information used by Recovery Manager (RMAN), such as the persistent RMAN settings and the types of backups that have been performed on the database. Whenever any changes are made to the structure of the database, the information about the changes is immediately reflected in the control file.

Because the control file is so critical to the operation of the database, it can also be multiplexed. However, no matter how many copies of the control file are associated with an instance, only one of the control files is designated as primary for purposes of retrieving database metadata. The alter database backup controlfile to trace command is another way to back up the control file. It produces a SQL script that you can use to re-create the database control file in case all multiplexed binary versions of the control file are lost due to a catastrophic failure. This trace file can also be used, for example, to re-create a control file if the database needs to be renamed, or to change various database limits that could not otherwise be changed without re-creating the entire database.

1.6.4. Archived Log Files

An Oracle database can operate in one of two modes: archivelog or noarchivelog

mode. When the database is in noarchivelog mode, the circular reuse of the redo log files (also known as the online redo log files) means that redo entries (the contents of previous transactions) are no longer available in case of a failure to a disk drive or another media-related failure. Operating in noarchivelog mode does protect the integrity of the database in the event of an instance failure or system crash, because all transactions that are committed but not yet written to the datafiles are available in the online redo log files.

In contrast, archivelog mode sends a filled redo log file to one or more specified destinations and can be available to reconstruct the database at any given point in time in the event that a database media failure occurs. For example, if the disk drive containing the datafiles crashes, the contents of the database can be recovered to a point in time before the crash, given a recent backup of the datafiles and the redo log files that were generated since the backup occurred. The use of multiple archived log destinations for filled redo log files is critical for one of Oracle’s high-availability features known as Oracle Data Guard, formerly known as Oracle Standby Database.


`



1.6.5. Initialization Parameter Files

When a database instance starts, the memory for the Oracle instance is allocated, and one of two types of initialization parameter files is opened: either a text-based file called init<SID>.ora (known generically as init.ora or a PFILE) or a server parameter file (otherwise known as an SPFILE). The instance first looks for an SPFILE in the default location for the operating system ($ORACLE_HOME/dbs on Unix, for example) as either spfile<SID>.ora or spfile.ora. If neither of these files exists, the instance looks for a PFILE with the name init<SID>.ora. Alternatively, the startup command can explicitly specify a PFILE to use for startup.

Initialization parameter files, regardless of the format, specify file locations for trace files, control files, filled redo log files, and so forth. They also set limits on the sizes of the various structures in the System Global Area (SGA) as well as how many users can connect to the database simultaneously.

Until Oracle9i, using the init.ora file was the only way to specify initialization parameters for the instance. Although it is easy to edit with a text editor, it has some drawbacks. If a dynamic system parameter is changed at the command line with the alter system command, the DBA must remember to change the init.ora file so that the new parameter value will be in effect the next time the instance is restarted.

An SPFILE makes parameter management easier and more effective for the DBA. If an SPFILE is in use for the running instance, any alter system command that changes an initialization parameter can change the initialization parameter automatically in the SPFILE, change it only for the running instance, or both. No editing of the SPFILE is necessary, or even possible without corrupting the SPFILE itself.

Although you cannot mirror a parameter file or SPFILE per se, you can back up an SPFILE to an init.ora file, and both the init.ora and the SPFILE for the Oracle instance should be backed up using conventional operating system commands or using Recovery Manager in the case of an SPFILE. When the DBCA is used to create a database, an SPFILE is created by default.

1.6.6. Alert and Trace Log Files

When things go wrong, Oracle can and often does write messages to the alert log and, in the case of background processes or user sessions, trace log files. The alert log file, located in the directory specified by the initialization parameter BACKGROUND_DUMP_DEST, contains both routine status messages as well as error conditions. When the database is started up or shut down, a message is recorded in the alert log, along with a list of initialization parameters that are different from their default values. In addition, any alter database or alter system commands issued by the DBA are recorded. Operations involving tablespaces and their datafiles are recorded here, too, such as adding a tablespace, dropping a tablespace, and adding a datafile to a tablespace. Error conditions, such as tablespaces running out of space, corrupted redo logs, and so forth, are also recorded here.

The trace files for the Oracle instance background processes are also located in BACKGROUND_DUMP_DEST. For example, the trace files for PMON and SMON contain an entry when an error occurs or when SMON needs to perform instance recovery; the trace files for QMON contain informational messages when it spawns a new process. Trace files are also created for individual user sessions or connections to the database. These trace files are located in the directory specified by the initialization parameter USER_DUMP_ DEST. Trace files for user processes are created in two situations: The first is when some type of


`



error occurs in a user session because of a privilege problem, running out of space, and so forth.

In the second situation, a trace file can be created explicitly with the command alter session set sql_trace=true. Trace information is generated for each SQL statement that the user

executes, which can be helpful when tuning a user’s SQL statement. The alert log file can be deleted or renamed at any time; it is re-created the next time an alert log message is

generated. The DBA will often set up a daily batch job (either through an operating system mechanism or using Oracle Enterprise Manager’s scheduler) to rename and archive the alert

log on a daily basis.

Figure 1.5: Oracle physical storage structures

1.6.7. Backup Files

Backup files can originate from a number of sources, such as operating system copy commands or Oracle Recovery Manager (RMAN). If the DBA performs a “cold” backup (see the section titled “Backup/Recovery Overview” for more details on backup types), the backup files are simply operating system copies of the datafiles, redo log files, control files, archived redo log files, and so forth. In addition to bit-for-bit image copies of datafiles (the default in RMAN), RMAN can generate full and incremental backups of datafiles, control files, archived redo log files, and SPFILEs that are in a special format, called backupsets, only readable by RMAN. RMAN backupset backups are generally smaller than the original datafiles because RMAN does not back up unused blocks.

1.6.8. Oracle Managed Files


`



Oracle Managed Files (OMF), introduced in Oracle version 9i, makes the DBA’s job easier by automating the creation and removal of the datafiles that make up the logical structures in the database.

Without OMF, a DBA might drop a tablespace and forget to remove the underlying operating system files. This makes inefficient use of disk resources, and it unnecessarily increases backup time for datafiles that are no longer needed by the database. OMF is well suited for small databases with a low number of users and a part-time DBA, where optimal configuration of a production database is not necessary.

1.6.9. Password Files

An Oracle password file is a file within the Oracle administrative or software directory structure on disk used to authenticate Oracle system administrators for tasks such as creating a database or starting up and shutting down the database. The privileges granted through this file are the SYSDBA and SYSOPER privileges. Authenticating any other type of user is done within the database itself; because the database may be shut down or not mounted, another form of administrator authentication is necessary in these cases.

The Oracle command-line utility orapwd creates a password file if one does not exist or is damaged. Because of the extremely high privileges granted via this file, it should be stored in a secure directory location that is not available to anyone except for DBAs and operating system administrators. Once this file is created, the initialization parameter REMOTE_LOGIN_ PASSWORDFILE should be set to EXCLUSIVE to allow users other than SYS to use the password file.

1.7. Oracle Memory Structures

Oracle uses the server’s physical memory to hold many things for an Oracle instance: the Oracle executable code itself, session information, individual processes associated with the database, and information shared between processes (such as locks on database objects). In addition, the memory structures contain user and data dictionary SQL statements, along with cached information that is eventually permanently stored on disk, such as data blocks from database segments and information about completed transactions in the database. The data area allocated for an Oracle instance is called the System Global Area (SGA). The Oracle executables reside in the software code area. In addition, an area called the Program Global Area (PGA) is private to each server and background process; one PGA is allocated for each process. Figure 1.6 shows the relationships between these Oracle memory structures.

1.7.1. System Global Area

The System Global Area is a group of shared memory structures for an Oracle instance, shared by the users of the database instance. When an Oracle instance is started, memory is allocated for the SGA based on the values specified in the initialization parameter file or hard-coded in the Oracle software. Many of the parameters that control the size of the various parts of the SGA are dynamic; however, if the parameter SGA_MAX_SIZE is specified, the total size of all SGA areas must not exceed the value of SGA_MAX_SIZE. If SGA_MAX_SIZE is not specified, but the parameter SGA_TARGET is specified, Oracle automatically adjusts the sizes of the SGA components so that the total amount of memory allocated is equal to SGA_TARGET. SGA_TARGET is a dynamic parameter; it can be changed while the instance is running. The parameter MEMORY_TARGET, new to Oracle 11g, balances all memory available to Oracle between the SGA and the Program Global Area to optimize performance.

Memory in the SGA is allocated in units of granules. A granule can be either 4MB or 16MB, depending on the total size of the SGA. If the SGA is less than or equal to 128MB, a


`



granule is 4MB; otherwise, it is 16MB. In the next few subsections, we will cover the highlights of how Oracle uses each section in the SGA.

1.7.1.1.Buffer Caches

The database buffer cache holds blocks of data from disk that have been recently read to satisfy a select statement or that contain modified blocks that have been changed or added from a DML statement. As of Oracle9i, the memory area in the SGA that holds these data blocks is dynamic. This is a good thing, considering that there may be tablespaces in the database with block sizes other than the default block size; tablespaces with up to five different block sizes (one block size for the default, and up to four others) require their own buffer cache. As the processing and transactional needs change during the day or during the week, the values of DB_CACHE_SIZE and DB_nK_CACHE_SIZE can be dynamically changed without restarting the instance to enhance performance for a tablespace with a given block size.

Oracle can use two additional caches with the same block size as the default (DB_CACHE_SIZE) block size: the KEEP buffer pool and the RECYCLE buffer pool. As of Oracle9i, both of these pools allocate memory independently of other caches in the SGA.

When a table is created, you can specify the pool where the table’s data blocks will reside by using the BUFFER_POOL KEEP or BUFFER_POOL_RECYCLE clause in the STORAGE clause. For tables that you use frequently throughout the day, it would be advantageous to place this table into the KEEP buffer pool to minimize the I/O needed to retrieve blocks in the table.


`



Figure 1.6: Oracle logical memory structure

1.7.1.2.Shared Pool

The shared pool contains two major sub caches: the library cache and the data dictionary cache. The shared pool is sized by the SHARED_POOL_SIZE initialization parameter. This is another dynamic parameter that can be resized as long as the total SGA size is less than SGA_MAX_SIZE or SGA_TARGET.

Library Cache The library cache holds information about SQL and PL/SQL statements that are run against the database. In the library cache, because it is shared by all users, many different database users can potentially share the same SQL statement. Along with the SQL statement itself, the execution plan and parse tree of the SQL statement are stored in the library cache. The second time an identical SQL statement is run, by the same user or a different user, the execution plan and parse tree are already computed, improving the execution time of the query or DML statement. If the library cache is sized too small, the execution plans and parse trees are flushed out of the cache, requiring frequent reloads of SQL statements into the library cache. Data Dictionary Cache The data dictionary is a collection of database tables, owned by the SYS and SYSTEM schemas, that contain the metadata about the database, its structures, and the privileges and roles of database users. The data dictionary cache

holds a subset of the columns from data dictionary tables after first being read into the buffer cache. Data blocks from tables in the data dictionary are used continually to assist in processing user queries and other DML commands. If the data dictionary cache is too small, requests for information from the data dictionary will cause extra I/O to occur; these I/O-bound data dictionary requests are called recursive calls and should be avoided by sizing the data dictionary cache correctly.

1.7.1.3.Redo Log Buffer

The redo log buffer holds the most recent changes to the data blocks in the datafiles. When the redo log buffer is one-third full, or every three seconds, Oracle writes redo log records to the redo log files. As of Oracle Database 10g, the LGWR process will write the redo log records to the redo log files when 1MB of redo is stored in the redo log buffer. The entries in the redo log buffer, once written to the redo log files, are critical to database recovery if the instance crashes before the changed data blocks are written from the buffer cache to the datafiles. A user’s committed transaction is not considered complete until the redo log entries have been successfully written to the redo log files.

1.7.1.4.Large Pool

The large pool is an optional area of the SGA. It is used for transactions that interact with more than one database, message buffers for processes performing parallel queries, and RMAN parallel backup and restore operations. As the name implies, the large pool makes available large blocks of memory for operations that need to allocate large blocks of memory at a time. The initialization parameter LARGE_POOL_SIZE controls the size of the large pool and is a dynamic parameter as of Oracle9i release 2.

1.7.1.5.Java Pool


`



The Java pool is used by the Oracle JVM (Java Virtual Machine) for all Java code and data within a user session. Storing Java code and data in the Java pool is analogous to SQL and PL/SQL code cached in the shared pool.

1.7.1.6.Streams Pool

New to Oracle 10g, the streams pool is sized by using the initialization parameter STREAMS_POOL_SIZE. The streams pool holds data and control structures to support the Oracle Streams feature of Oracle Enterprise Edition. Oracle Streams manages the sharing of data and events in a distributed environment. If the initialization parameter STREAMS_POOL_SIZE is uninitialized or set to zero, the memory used for Streams operations is allocated from the shared pool and may use up to 10 percent of the shared pool.

1.7.2. Program Global Area

The Program Global Area is an area of memory allocated and private for one process. The configuration of the PGA depends on the connection configuration of the Oracle database: either shared server or dedicated.

In a shared server configuration, multiple users share a connection to the database, minimizing memory usage on the server, but potentially affecting response time for user requests. In a shared server environment, the SGA holds the session information for a user instead of the PGA. Shared server environments are ideal for a large number of simultaneous connections to the database with infrequent or short-lived requests.

In a dedicated server environment, each user process gets its own connection to the database; the PGA contains the session memory for this configuration. The PGA also includes a sort area. The sort area is used whenever a user request requires a sort, bitmap merge, or hash join operation.

As of Oracle9i, the PGA_AGGREGATE_TARGET parameter, in conjunction with the WORKAREA_SIZE_POLICY initialization parameter, can ease system administration by allowing the DBA to choose a total size for all work areas and let Oracle manage and allocate the memory between all user processes. The parameter MEMORY_TARGET manages the PGA and SGA memory as a whole to optimize performance.

1.7.2.1.Software Code Area

Software code areas store the Oracle executable files that are running as part of an Oracle instance. These code areas are static in nature and only change when a new release of the software is installed. Typically, the Oracle software code areas are located in a privileged memory area separate from other user programs. Oracle software code is strictly read-only and can be installed either shared or non-shared.

Installing Oracle software code as sharable saves memory when multiple Oracle instances are running on the same server at the same software release level.

1.8. Process:

A process is a mechanism in an operating system that can run a series of steps. Some operating systems use the terms job, task, or thread. For the purpose of this discussion, a thread is equivalent to a process. All connected Oracle users must run two modules of code to access an Oracle database instance.

Application or Oracle tool: A database user runs a database application (such as a

pre-compiler program) or an Oracle tool (such as SQL*Plus), which issues SQL

statements to an Oracle database.

Oracle server code: Each user has some Oracle server code executing on his or

her behalf, which interprets and processes the application's SQL statements.


`



These code modules are run by processes. A process is a "thread of control" or a mechanism in an operating system that can run a series of steps. (Some operating systems use the terms job or task.) A process normally has its own private memory area in which it runs.

Multiple-process Oracle (also called multiuser Oracle) uses several processes to run different parts of the Oracle code and additional processes for the users--either one process for each connected user or one or more processes shared by multiple users. Most database systems are multiuser, because one of the primary benefits of a database is managing data needed by multiple users at the same time.

Each process in an Oracle instance performs a specific job. By dividing the work of Oracle and database applications into several processes, multiple users and applications can connect to a single database instance simultaneously while the system maintains excellent performance.

1.8.1. Types of Processes

The processes in an Oracle system can be categorized into two major groups:

1. User Process

2. Oracle Process

1.8.2. User Processes:

These processes are created and maintained to run the software code of an application program or an Oracle tool. Most environments have separate computers for client processes. When a user runs an application program (such as a Pro*C program) or an Oracle tool (such as Enterprise Manager or SQL*Plus), Oracle creates a user process to run the user's application.

1.8.3. Oracle Processes:

Oracle processes run the Oracle server code. They include server processes and

background processes.

1.8.3.1.Server Processes

Oracle creates server processes to handle the requests of user processes connected to the instance. In some situations when the application and Oracle operate on the same machine, it is possible to combine the user process and corresponding server process into a single process to reduce system overhead. However, when the application and Oracle operate on different machines, a user process always communicates with Oracle through a separate server process.

Server processes (or the server portion of combined user/server processes) created on behalf of each user's application can perform one or more of the following:

Parse and run SQL statements issued through the application

Read necessary data blocks from datafiles on disk into the shared database buffers of

the SGA, if the blocks are not already present in the SGA

Return results in such a way that the application can process the information

1.8.3.2.Background Processes

When an Oracle instance starts, multiple background processes start. A background

process is a block of executable code designed to perform a specific task. Figure 1-6 shows the relationship between the background processes, the database, and the Oracle SGA. In contrast to a foreground process, such as a SQL*Plus session or a web browser, a background


`



process works behind the scenes. Together, the SGA and the background processes compose an Oracle instance.

1.8.4. SMON

SMON is the System Monitor process. In the case of a system crash or instance failure, due to a power outage or CPU failure, the SMON process performs crash recovery by applying the entries in the online redo log files to the datafiles. In addition, temporary segments in all tablespaces are purged during system restart. One of SMON’s routine tasks is to coalesce the free space in tablespaces on a regular basis if the tablespace is dictionary managed.

1.8.5. PMON

If a user connection is dropped, or a user process otherwise fails, PMON, also known as the Process Monitor, does the cleanup work. It cleans up the database buffer cache along with any other resources that the user connection was using. For example, a user session may be updating some rows in a table, placing a lock on one or more of the rows. A thunderstorm knocks out the power at the user’s desk, and the SQL*Plus session disappears when the workstation is powered off. Within moments, PMON will detect that the connection no longer exists and perform the following tasks:

Roll back the transaction that was in progress when the power went out. Mark the transaction’s blocks as available in the buffer cache. Remove the locks on the affected rows in the table. Remove the process ID of the disconnected process from the list of active processes.

PMON will also interact with the listeners by providing information about the status of the instance for incoming connection requests.

1.8.6. DBWn

The database writer process, known as DBWR in older versions of Oracle, writes new or changed data blocks (known as dirty blocks) in the buffer cache to the datafiles. Using an LRU algorithm, DBWn writes the oldest, least active blocks first. As a result, the most commonly requested blocks, even if they are dirty blocks, are in memory. Up to 20 DBWn processes can be started, DBW0 through DBW9 and DBWa through DBWj. The number of DBWn processes is controlled by the DB_WRITER_PROCESSES parameter.

1.8.7. LGWR

LGWR, or Log Writer, is in charge of redo log buffer management. LGWR is one of the most active processes in an instance with heavy DML activity. A transaction is not considered complete until LGWR successfully writes the redo information, including the commit record, to the redo log files. In addition, the dirty buffers in the buffer cache cannot be written to the datafiles by DBWn until LGWR has written the redo information.

If the redo log files are grouped, and one of the multiplexed redo log files in a group is damaged, LGWR writes to the remaining members of the group and records an error in the alert log file. If all members of a group are unusable, the LGWR process fails and the entire instance hangs until the problem can be corrected.

1.8.8. ARCn

If the database is in ARCHIVELOG mode, then the archiver process, or ARCn, copies redo logs to one or more destination directories, devices, or network locations whenever a redo log fills up and redo information starts to fill the next redo log in sequence. Optimally, the archive process finishes before the filled redo log is needed again; otherwise, serious performance problems occur—users cannot complete their transactions until the


`



entries are written to the redo log files, and the redo log file is not ready to accept new entries because it is still being written to the archive location. There are at least three potential solutions to this problem: make the redo log files larger, increase the number of redo log groups, and increase the number of ARCn processes. Up to ten ARCn processes can be started for each instance by increasing the value of the LOG_ARCHIVE_MAX_PROCESSES initialization parameter.

1.8.9. CKPT

The checkpoint process, or CKPT, helps to reduce the amount of time required for instance recovery. During a checkpoint, CKPT updates the header of the control file and the datafiles to reflect the last successful SCN (System Change Number). A checkpoint occurs automatically every time a redo log file switch occurs. The DBWn processes routinely write dirty buffers to advance the checkpoint from where instance recovery can begin, thus reducing the Mean Time to Recovery (MTTR).

1.8.10. RECO

The RECO, or recoverer process, handles failures of distributed transactions (that is, transactions that include changes to tables in more than one database). If a table in the CCTR database is changed along with a table in the WHSE database, and the network connection between the databases fails before the table in the WHSE database can be updated, RECO will roll back the failed transaction.


`



Chapter 02

Managing Database 2.1. Getting to home base

On systems where Oracle is installed, an important part of managing the Oracle installation is understanding environment variables. Environment variables tell

The OS what software to run Oracle where to store certain files Oracle what database you want to connect to

The four most important variables are ORACLE_BASE ORACLE_HOME ORACLE_SID PATH

2.1.1. ORACLE_BASE

ORACLE_BASE is the top directory where all Oracle files on the machine are going to exist.

2.1.2. ORACLE_HOME

ORACLE_HOME is where Oracle is installed. It also tells the session which Oracle installation you want to use.

2.1.3. ORACLE_SID

ORACLE_SID is the name of the database that user want to connect to. If the database doesn’t exist, set it to the name of the database user about to create.

2.1.4. PATH

The PATH variable is typically already set for all sessions on the system. However, when user is using Oracle, he must add the path and put ORACLE_HOME/bin in front of path.

2.2. Installation of Oracle 11g Software

Oracle Universal Installer (OUI) is used to install Oracle software. The OUI is a GUI tool that enables user to view the Oracle software that is installed on machine, install new Oracle software, and delete Oracle software that no longer is intended to use. There are two methods to install the Oracle software: basic and advanced. basic installation method is used to quickly install the software with minimal user input. The advanced installation method enables user to perform a custom installation.

2.2.1. Basic Installation

Following steps are used to install the Oracle software and create a database using the basic installation method.

1. Log onto computer as a member of the administrative group that is authorized to

install Oracle software and create and run the database.


`



2. Insert the distribution CD for the database into your CD drive. The Autorun window

will appear automatically.

3. At the Configure Security Updates window, enter your e-mail address and Oracle

Support password and click Next.

If you choose to not supply your email address and Oracle Support password, uncheck the check box, leave both text boxes empty, then click Next. When prompted, click Yes.

4. At the Installation Option window, select Create and configure a database and click Next.


`



5. At the System Class window, select Server Class and click Next.


`



6. At the Grid Options window, select Single instance database installation and click Next.

7. At the Install Type window, select Typical install and click Next.


`



8. At the Typical Installation window, enter an Administrative Password. Enter it a second

time to confirm the password and click Next.

Note that the password is evaluated to make sure that it conforms to Oracle recommended

standards. If it is not, you will receive an error window asking if you would like to proceed.


`



9. At the Summary window, click Finish.

10. A progress window will appear. Oracle installation is started


`



11. After the software is installed, the Database Configuration Assistant will begin and create your database.

12. Click on password management.


`



13. Enter Password for SYS and SYSTEM and click OK

14. Your installation and database creation completed successfully. click Close.


`



2.2.2. Advanced Installation

Follow the steps below to install the Oracle software and create a database using the

advanced installation method.

Note: If you performed the Basic Installation steps, you do not need to complete this

section.

1. Log onto computer as a member of the administrative group that is authorized

to install Oracle software and create and run the database.

2. Insert the distribution CD for the database into your CD drive. The Autorun

window will appear automatically.

3. At the Configure Security Updates window, enter your e-mail address and

Oracle Support password and click Next.

If you choose to not supply your email address and Oracle Support password, uncheck the

check box, leave both text boxes empty, and then click Next. When prompted, click Yes.


`



4. At the Installation Option window, select Create and configure a database and click Next.

5. At the System Class window, select Server Class and click Next.


`



6. At the Grid Options window, select Single instance database installation and click Next.

7. At the Install Type Window, select Advanced install and click Next.


`



8. At the Product Languages window, select the Move All button to select all the languages.

9. Click Next.


`



10. At the Database Edition window, select Enterprise Edition and click Next.

11. At the Installation Location window, accept the defaults and click Next.


`



12. At the Configuration Type window, make sure the type of database is set to General

Purpose / Transaction Processing and click Next.


`



13. At the Database Identifier window, accept the defaults and click Next.

14. At the Configuration Options window, for the memory tab, you will accept the defaults.

Click the Character sets tab.


`



15. Change the setting to Use Unicode (AL32UTF8) and click the Security tab.

16. Accept the default and click the Sample Schema tab.


`



17. Select the Create database with sample schema check box and click Next.

18. At the Management Options window, accept the defaults and click Next.


`



19. At the Database Storage window, accept the defaults and click Next.

20. At the Backup and Recovery window, accept the defaults and click Next.


`



21. At the Schema Passwords window, select Use the same password for all accounts and enter

an Oracle Recommended password and confirm password and click Next.

22. At the Summary window, click Finish.


`



23. A progress window will appear.

24. After the software is installed, the Database Configuration Assistant will begin and create


`



your database.

25. The database was created successfully. Click Close.


`



26. Your installation and database creation completed successfully. click Close.

2.3. Create New Database

2.3.1. Create New Database Using DBCA

If you choose to install software only and later create a database, or if you want to create

additional databases using the software that you just installed, you can do so by using the

Database Configuration Assistant (DBCA).

Note: If you created a database as part of the Basic Installation or Advanced Installation, you

do not need to complete this section.

Follow the steps below to create a new database or a second database if you created a

database as part of the software installation:

1. Log onto your computer as a member of the administrative group that is authorized to

install Oracle software and create and manage the database.

2. Launch the DBCA for Start Menu or open command prompt and write command: dbca


`



3. The Welcome window appears. Click Next.

4. Select Create a Database in the Operations window to begin a process that enables you to

configure and create a database. Click Next.


`



5. On the Database Templates window, select the type of database template to be used in

creating the database. You can click Show Details to see the configuration for each type

of database. Choose the template suited to the type of workload your database will

support. If you are not sure, select the default General Purpose or Transaction Processing

template. Click Next.

6. On the Database Identification window, enter a Global Database Name and SID. Click

Next.

Note: If you created a database as part of your installation of the Oracle software and

you are creating a second database with DBCA, you must choose a different global

database name and SID for your second database.


`



7. The Management Options window appears. To use Enterprise Manager, select Configure

Enterprise Manager. Select Configure Database Control for local management to manage

your database locally as appropriate to your configuration. Click Next.

8. On the Database Credentials window, you can choose to use different administrative

passwords or use the same password for all accounts. Select one of the options and enter

your password data. Click Next.


`



9. For storage options, select File System, Automatic Storage Management, or Raw Devices

as appropriate to your environment. Click Next.

10. Select Specify Flash Recovery Area and enter a directory location and size. You may also

choose to Enable Archiving to place your database in ARCHIVELOG mode. Click Next.


`



11. Select Sample Schemas if you want to include the Sample Schemas (EXAMPLE)

tablespace in your database. Click Next.

12. The Memory window appears. Select Typical and enter a Memory Size (SGA and PGA).

Click the Sizing tab.


`



13. The Sizing window appears. Specify the smallest block size and the maximum number of

operating system user processes that can simultaneously connect to the database.

Note: You cannot specify the block size if you are using a template.

Click the Character Sets tab.

14. The Character Sets window appears. Select the character set for your database. Click the

Connection Mode tab.


`



15. The Connection Mode window appears. Select Dedicated Server Mode or Shared Server

Mode as appropriate for your environment. Click Next.

16. On the Database Storage window, you can specify storage parameters for the database

creation. Accept the default values. Click Next.


`



17. On the Creation Options window, select Create Database to create your database. You

can also select Save as a Database Template to save your configuration. Click Finish.

18. At the Confirmation window, confirm the options that will be installed and click OK.


`



19. Your database is now being created.

20. After the database is created, you can change or unlock your passwords or click OK.

2.3.2. Creating a Database with the CREATE DATABASE Statement

Using the CREATE DATABASE SQL statement is a more manual approach to creating a database. One advantage of using this statement over using DBCA is that you can create databases from within scripts.

If you use the CREATE DATABASE statement, you must complete additional actions before you have an operational database. These actions include building views on the data dictionary tables and installing standard PL/SQL packages. You perform these actions by running the supplied scripts.

If you have existing scripts for creating your database, consider editing those scripts to take advantage of new Oracle Database features.

Steps:

Step 1: Specify an Instance Identifier (SID).


`



Step 2: Ensure That the Required Environment Variables Are Set. Step 3: Choose a Database Administrator Authentication Method. Step 4: Create the Initialization Parameter File. Step 5: (Windows Only) Create an Instance . Step 6: Connect to the Instance. Step 7: Create a Server Parameter File. Step 8: Start the Instance. Step 9: Issue the CREATE DATABASE Statement. Step 10: Create Additional Tablespaces. Step 11: Run Scripts to Build Data Dictionary Views. Step 12: (Optional) Run Scripts to Install Additional Options. Step 13: Back Up the Database. Step 14: (Optional) Enable Automatic Instance Startup.

Step 1: Specify an Instance Identifier (SID) Decide on a unique Oracle system identifier (SID) for your instance, open a command

window, and set the ORACLE_SID environment variable. Use this command window for the subsequent steps. ORACLE_SID is used to distinguish this instance from other Oracle Database instances that you may create later and run concurrently on the same host computer. Restrictions related to the valid characters in an ORACLE_SID are platform-specific. On some platforms, the SID is case-sensitive. Note: It is common practice to set the SID to be equal to the database name. The maximum number of characters for the database name is eight.

The following example for UNIX and Linux operating systems sets the SID for the instance that you will connect to in Step 6: Connect to the Instance.

Bourne, Bash, or Korn shell:

ORACLE_SID=mynewdb export ORACLE_SID

C shell:

setenv ORACLE_SID mynewdb

Windows operating system: set ORACLE_SID=mynewdb

Step 2: Ensure That the Required Environment Variables Are Set Depending on platform, before you can start SQL*Plus (as required in Step 6:

Connect to the Instance For example, on most platforms, ORACLE_SID and

ORACLE_HOME must be set. In addition, it is advisable to set the PATH variable to

include the ORACLE_HOME/bin directory. On the Windows platform, OUI automatically

assigns values to ORACLE_HOME and ORACLE_SID in the Windows registry. If you did

not create a database upon installation, OUI does not set ORACLE_SID in the registry, and you will have to set the ORACLE_SID environment variable when you create your database later.

Step 3: Choose a Database Administrator Authentication Method You must be authenticated and granted appropriate system privileges in order to

create a database. You can be authenticated as an administrator with the required privileges in the following ways:

With a password file With operating system authentication


`



In this step, you decide on an authentication method. To be authenticated with a password file, create the password file as described in "Creating and Maintaining a Password File". To be authenticated with operating system authentication, ensure that you log in to the host computer with a user account that is a member of the appropriate operating system user group. On the UNIX and Linux platforms, for example, this is typically the dba user group. On the Windows platform, the user installing the Oracle software is automatically placed in the required user group.

Step 4: Create the Initialization Parameter File When an Oracle instance starts, it reads an initialization parameter file. This file can

be a text file, which can be created and modified with a text editor, or a binary file, which is created and dynamically modified by the database. The binary file, which is preferred, is called a server parameter file. In this step, you create a text initialization parameter file. In a later step, you create a server parameter file from the text file.

One way to create the text initialization parameter file is to edit the sample presented in "Sample Initialization Parameter File".

Step 5: (Windows Only) Create an Instance On the Windows platform, before you can connect to an instance, you must manually

create it if it does not already exist. The ORADIM command creates an Oracle instance by creating a new Windows service. To create an instance: Enter the following command at a Windows command prompt:

oradim -NEW -SID sid -STARTMODE MANUAL -PFILE pfile

where sid is the desired SID (for example mynewdb) and pfile is the full path to the text initialization parameter file. This command creates the instance but does not start it.

Step 6: Connect to the Instance Start SQL*Plus and connect to your Oracle Database instance with the SYSDBA

system privilege. To authenticate with a password file, enter the following commands, and

then enter the SYS password when prompted: $ sqlplus /nolog SQL> CONNECT SYS AS SYSDBA

To authenticate with operating system authentication, enter the following commands: $ sqlplus /nolog SQL> CONNECT / AS SYSDBA

SQL*Plus outputs the following message: Connected to an idle instance.

Step 7: Create a Server Parameter File The server parameter file enables you to change initialization parameters with the

ALTER SYSTEM command and persist the changes across a database shutdown and startup. You create the server parameter file from your edited text initialization file.

The following SQL*Plus command reads the text initialization parameter file (PFILE) with the default name from the default location, creates a server parameter file (SPFILE) from the text initialization parameter file, and writes the SPFILE to the default location with the default SPFILE name.

CREATE SPFILE FROM PFILE;

User can also supply the file name and path for both the PFILE and SPFILE if not using default names and locations. The database must be restarted before the server parameter file takes effect.

Step 8: 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 initialization parameter


`



file or server parameter file is stored in the default location, you are not required to specify the PFILE clause:

STARTUP NOMOUNT

At this point, the instance memory is allocated and its processes are started. The database itself does not yet exist.

Step 9: Issue the CREATE DATABASE Statement To create the new database, use the CREATE DATABASE statement.

Step 10: Create Additional Tablespaces To make the database functional, you must create additional tablespaces for your

application data. The following sample script creates some additional tablespaces:

CREATE TABLESPACE apps_tbs LOGGING DATAFILE '/u01/app/oracle/oradata/mynewdb /apps01.dbf' SIZE 500M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED

EXTENT MANAGEMENT LOCAL; -- create a tablespace for indexes, separate from user tablespace (optional) CREATE TABLESPACE indx_tbs LOGGING DATAFILE '/u01/app/oracle/oradata/mynewdb /indx01.dbf' SIZE 100M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL;

Step 11: Run Scripts to Build Data Dictionary Views Run the scripts necessary to build data dictionary views, synonyms, and PL/SQL

packages, and to support proper functioning of SQL*Plus. In SQL*Plus, connect to your Oracle Database instance with the SYSDBA

administrative privilege: @?/rdbms/admin/catalog.sql @?/rdbms/admin/catproc.sql @?/rdbms/admin/utlrp.sql

In SQL*Plus, connect to your Oracle Database instance as SYSTEM user: @?/sqlplus/admin/pupbld.sql

The at-sign (@) is shorthand for the command that runs a SQL*Plus script. The question mark (?) is a SQL*Plus variable indicating the Oracle home directory. The following table contains descriptions of the scripts:

Script Description

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

CATPROC.SQL Runs all scripts required for or used with PL/SQL.

UTLRP.SQL

Recompiles all PL/SQL modules that are in an invalid state, including packages, procedures, and types.

PUPBLD.SQL

Required for SQL*Plus. Enables SQL*Plus to disable commands by user.

Step 12: (Optional) Run Scripts to Install Additional Options You may want to run other scripts. The scripts that you run are determined by the

features and options you choose to use or install. If you plan to install other Oracle products to work with this database, then see the

installation instructions for those products. Some products require you to create additional data dictionary tables. Usually, command files are provided to create and load these tables into the database data dictionary.

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

Step 14: (Optional) Enable Automatic Instance Startup You might want to configure the Oracle instance to start automatically when its host

computer restarts. See your operating system documentation for instructions. For example, on


`



Windows, use the following command to configure the database service to start the instance upon computer restart:

ORADIM -EDIT -SID sid -STARTMODE AUTO -SRVCSTART SYSTEM [-SPFILE]

You must use the -SPFILE argument if you want the instance to read an SPFILE upon automatic restart.

2.4. Startup and shutdown a Database

After installation, the Oracle instance is started, and the database is open for access by users with database accounts. At some point, user may want to shut down and restart the instance.

To start or shut down the Oracle instance, you must connect to the instance with a special connection privilege. There are two of these privileges: SYSDBA for fully empowered database administrators and SYSOPER for users who start and shut down the database, but have no privileges to access user objects.

When you create an Oracle database, there are two primary administrative user accounts that are automatically created: SYS and SYSTEM. Both of these users have full database administration privileges, but initially, only user SYS or SYSTEM can connect with the SYSOPER privilege. Therefore, until you grant the SYSOPER privilege to other users, you must connect to the Oracle instance as user SYS or SYSTEM to start and shut down the instance. When connecting (logging in) as user SYS, you must always specify that you are connecting AS SYSDBA.

2.4.1. Startup a Database:

When an Oracle instance is started, it typically state of the database is OPEN and ready for user connections. However, there are situations in which user may want to start the instance with the database in the MOUNTED state, but not OPEN. An instance can also be started without the database either mounted or open. Thus, there are three stages to starting an instance: 1. You start the instance using one of the following methods:

Using Oracle Enterprise Manager.

Using the SQL*Plus STARTUP command

On Microsoft Windows, using the Services program in Control Panel to start the Oracle Database services.

The instance reads the initialization parameter file, allocates SGA memory, and starts the background processes.

2. If you mount the database, then the Oracle instance opens the control file for the database, but does not open the data files. The database is now considered to be in the MOUNT state. This state enables you to perform certain administrative functions that cannot be performed when other users are accessing the database. An example of such a function is enabling or disabling the archiving of online redo log files. See "About Archived Redo Log Files" for information about online redo log file archiving.

3. If you open the database, then, after reading the parameter file and control file, the online redo log files and data files for the database are also opened. The state of the database is now OPEN and user access to the data is available.

The default startup mode for the database (OPEN) completes the three stages in

sequence. The instance is started, the database is mounted, and then the database is opened.

2.4.1.1. Using Oracle Enterprise Manager:

1. Open database home Page

2. Click startup to start the database.

3. The Startup/Shutdown credentials page will appear.


`



4. Enter the credentials and click OK.

5. A confirmation page will appear. Click Yes.

The startup page will appear, indicating that he database is being started. .when

startup is completed, the login page will appear.

6. Login to database, database home page will appear, indicating that database is

started up.

2.4.1.2. Using the Services program in Control Panel:

Following steps must be followed to start or stop an oracle instance using windows services. 1. Click Start Button and Control Panel. 2. The Control Panel window opens. 3. Double-click the Administrative Tools icon, and then double-click the Services icon. 4. The Services window opens, displaying all Windows services that are available on

your system. 5. Locate the Oracle Database services listed at the beginning of this section. For

example, if your SID is orcl, then locate the following services:

a. OracleServiceORCL b. OracleOraDb11g_home1TNSListener c. OracleDBConsoleorcl

6. Start or stop all three services, using the following steps for each service: a. Select the service name. b. In the Action menu, click Start or Stop.

2.4.2. Stop a Database:

1. Go to the Database Home page.

2. In the General section of the Database Home page, click Shutdown.


`



3. The Startup/Shutdown Credentials page appears.

4. Enter credentials as follows:

Enter the host computer credentials of the user who installed Oracle

Database, or of any user who is authorized to use SQL*Plus.

Enter the database credentials consisting of the user name SYS and the

password that you assigned to SYS during the installation.

In the Connect As list, choose the value SYSOPER.

5. (Optional) Select the Save as Preferred Credential option if you want these

credentials to be automatically filled in for you the next time that this page

appears.

6. Click OK.

A confirmation page appears.

7. Click Yes to start the SHUTDOWN IMMEDIATE operation on the database.

8. The Startup/Shutdown: Activity Information page appears, informing you that the

database is being shut down.

9. After a short period (approximately 2 minutes), click Refresh to be returned to the

Database Home page.

10. The Database Home page indicates that the database instance status is Down.


`



Chapter 03

Managing Control Files and Redo Log Files

3.1. Control File:

Control file maintains the metadata of the database, in other words, data about the physical structure of the database itself. Every Oracle Database has a control file, which is a small binary file that records the physical structure of the database. The control file includes:

The database name Names and locations of associated data files and redo log files The timestamp of the database creation The current log sequence number Checkpoint information

The control file must be available for writing by the Oracle Database server whenever the database is open. Without the control file, the database cannot be mounted and recovery is difficult. The control file of an Oracle Database is created at the same time as the database. By default, at least one copy of the control file is created during database creation. On some operating systems the default is to create multiple copies. You should create two or more copies of the control file during database creation. You can also create control files later, if you lose control files or want to change particular settings in the control files.

3.1.1. Managing Control Files

3.1.1.1. Provide Filenames for the Control Files:

Control file names are specified using the CONTROL_FILES initialization parameter

in the database initialization parameter file. The instance recognizes and opens all the listed file during startup and the instance writes to and maintains all listed control files during database operation.

If files for CONTROL_FILES are not specified before database creation: If you are not using Oracle Managed Files, then the database creates a control file and

uses a default filename. The default name is operating system specific. If you are using Oracle Managed Files, then the initialization parameters you set to

enable that feature determine the name and location of the control files. If you are using Oracle Automatic Storage Management (Oracle ASM), you can place

incomplete Oracle ASM filenames in the DB_CREATE_FILE_DEST and

DB_RECOVERY_FILE_DEST initialization parameters. Oracle ASM then

automatically creates control files in the appropriate places.

3.1.1.2. Multiplex Control Files on Different Disks


`



Every Oracle Database should have at least two control files, each stored on a different physical disk. If a control file is damaged due to a disk failure, the associated instance must be shut down. Once the disk drive is repaired, the damaged control file can be restored using the intact copy of the control file from the other disk and the instance can be restarted. In this case, no media recovery is required. The behavior of multiplexed control files is this:

The database writes to all filenames listed for the initialization parameter

CONTROL_FILES in the database initialization parameter file.

The database reads only the first file listed in the CONTROL_FILES parameter

during database operation. If any of the control files become unavailable during database operation, the instance

becomes inoperable and should be aborted. One way to multiplex control files is to store a control file copy on every disk drive

that stores members of redo log groups, if the redo log is multiplexed. By storing control files in these locations, you minimize the risk that all control files and all groups of the redo log will be lost in a single disk failure.

3.1.1.3. Back Up Control Files:

It is very important that you back up your control files. This is true initially, and every time you change the physical structure of your database. Such structural changes include:

Adding, dropping, or renaming data files Adding or dropping a tablespace, or altering the read/write state of the tablespace Adding or dropping redo log files or groups

3.1.1.4. Manage the Size of Control Files

The main determinants of the size of a control file are the values set for the

AXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY, and

MAXINSTANCES parameters in the CREATE DATABASE statement that created the

associated database. Increasing the values of these parameters increases the size of a control file of the associated database.

3.1.2. Creating Control Files There are following topic in creating a control file.

1. Creating Initial Control Files

2. Creating Additional Copies, Renaming, and Relocating Control Files 3. Creating New Control Files

3.1.2.1. Creating Initial Control Files:

The initial control files of an Oracle Database are created by issuing CREATE

DATABASE statement. The names of the control files are specified by the CONTROL_FILES

parameter in the initialization parameter file used during database creation. The filenames

specified in CONTROL_FILES should be fully specified and are operating system specific.

The following is an example of a CONTROL_FILES initialization parameter:

CONTROL_FILES = (/u01/oracle/prod/control01.ctl, /u02/oracle/prod/control02.ctl, /u03/oracle/prod/control03.ctl)

If files with the specified names currently exist at the time of database creation,

CONTROLFILE REUSE clause must be specified in the CREATE DATABASE statement, or else an error occurs. Also, if the size of the old control file differs from the SIZE parameter

of the new one, you cannot use the REUSE clause.


`



The size of the control file changes between some releases of Oracle Database, as well as when the number of files specified in the control file changes. Configuration

parameters such as MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY,

MAXDATAFILES, and MAXINSTANCES affect control file size.

The value of the CONTROL_FILES initialization parameter can be changed to add more control files or to change the names or locations of existing control files.

3.1.2.2. Creating Additional Copies, Renaming, and Relocating Control Files

Additional control file copy can be created for multiplexing by copying an existing control file to a new location and adding the file name to the list of control files. Similarly, you rename an existing control file by copying the file to its new name or location, and changing the file name in the control file list. In both cases, to guarantee that control files do not change during the procedure, shut down the database before copying the control file.

To add a multiplexed copy of the current control file or to rename a control file: 1. Shut down the database.

2. Copy an existing control file to a new location, using operating system commands.

3. Edit the CONTROL_FILES parameter in the database initialization parameter file to add the new control file name, or to change the existing control filename.

4. Restart the database.

1. Creating New Control Files

It is necessary for you to create new control files in the following situations:

All control files for the database have been permanently damaged and you do not have a control file backup.

You want to change the database name. The compatibility level is set to a value that is earlier than 10.2.0, and you must make

a change to an area of database configuration that relates to any of the following parameters

from the CREATE DATABASE or CREATE CONTROLFILE commands:

MAXLOGFILES, MAXLOGMEMBERS,MAXLOGHISTORY, and MAXINSTANCES. If compatibility is 10.2.0 or later, you do not have to create new control files when you make such a change; the control files automatically expand, if necessary, to accommodate the new configuration information.

You can create a new control file for a database using the CREATE CONTROLFILE

statement. The following statement creates a new control file for the prod database (a database that formerly used a different database name):

CREATE CONTROLFILE SET DATABASE prod LOGFILE GROUP 1 ('/u01/oracle/prod/redo01_01.log', '/u01/oracle/prod/redo01_02.log'), GROUP 2 ('/u01/oracle/prod/redo02_01.log', '/u01/oracle/prod/redo02_02.log'), GROUP 3 ('/u01/oracle/prod/redo03_01.log', '/u01/oracle/prod/redo03_02.log') RESETLOGS DATAFILE '/u01/oracle/prod/system01.dbf' SIZE 3M, '/u01/oracle/prod/rbs01.dbs' SIZE 5M, '/u01/oracle/prod/users01.dbs' SIZE 5M, '/u01/oracle/prod/temp01.dbs' SIZE 5M MAXLOGFILES 50 MAXLOGMEMBERS 3 MAXLOGHISTORY 400


`



MAXDATAFILES 200 MAXINSTANCES 6 ARCHIVELOG;

Steps for Creating New Control Files Complete the following steps to create a new control file.

1. Make a list of all data files and redo log files of the database.

If you follow recommendations for control file backups as discussed in "Backing Up Control Files”, you will already have a list of data files and redo log files that reflect the current structure of the database. However, if you have no such list, executing the following statements will produce one.

SELECT MEMBER FROM V$LOGFILE;

SELECT NAME FROM V$DATAFILE;

SELECT VALUE FROM V$PARAMETER WHERE NAME = 'control_files';

If you have no such lists and your control file has been damaged so that the database cannot be opened, try to locate all of the data files and redo log files that constitute the database. Any files not specified in step 5 are not recoverable once a new control file has

been created. Moreover, if you omit any of the files that comprise the SYSTEM table

space, you might not be able to recover the database.

2. Shut down the database.

If the database is open, shut down the database normally if possible. Use the

IMMEDIATE or ABORT clauses only as a last resort.

3. Back up all data files and redo log files of the database.

4. Start up a new instance, but do not mount or open the database:

5. STARTUP NOMOUNT

6. Create a new control file for the database using the CREATE CONTROLFILE statement.

When creating a new control file, specify the RESETLOGS clause if you have lost any redo log groups in addition to control files. In this case, you will need to recover from the

loss of the redo logs (step 8). You must specify the RESETLOGS clause if you have

renamed the database. Otherwise, select the NORESETLOGS clause.

7. Store a backup of the new control file on an offline storage device. See "Backing Up Control Files" for instructions for creating a backup.

8. Edit the CONTROL_FILES initialization parameter for the database to indicate all of the control files now part of your database as created in step 5 (not including the backup

control file). If you are renaming the database, edit the DB_NAME parameter in your

instance parameter file to specify the new name.

9. Recover the database if necessary. If you are not recovering the database, skip to step 9.

If you are creating the control file as part of recovery, recover the database. If the new

control file was created using the NORESETLOGS clause (step 5), you can recover the database with complete, closed database recovery.


`



If the new control file was created using the RESETLOGS clause, you must specify

USING BACKUP CONTROL FILE. If you have lost online or archived redo logs or

data files, use the procedures for recovering those files.

10. Open the database using one of the following methods:

If you did not perform recovery, or you performed complete, closed database recovery in step 8, open the database normally.

ALTER DATABASE OPEN;

If you specified RESETLOGS when creating the control file, use the ALTER

DATABASE statement, indicating RESETLOGS.

ALTER DATABASE OPEN RESETLOGS;

The database is now open and available for use.

2. Troubleshooting After Creating Control Files

After issuing the CREATE CONTROLFILE statement, you may encounter some

errors. This section describes the most common control file errors:

Checking for Missing or Extra Files Handling Errors During CREATE CONTROLFILE

Checking for Missing or Extra Files

After creating a new control file and using it to open the database, check the alert log to see if the database has detected inconsistencies between the data dictionary and the control file, such as a data file in the data dictionary includes that the control file does not list.

If a data file exists in the data dictionary but not in the new control file, the database creates a

placeholder entry in the control file under the name MISSING nnnn, where nnnn is the file number in

decimal. MISSING nnnn is flagged in the control file as being offline and requiring media recovery.

If the actual data file corresponding to MISSING nnnn is read-only or offline normal, then you

can make the data file accessible by renaming MISSING nnnn to the name of the actual data file. If

MISSING nnnn corresponds to a data file that was not read-only or offline normal, then you cannot use the rename operation to make the data file accessible, because the data file requires media recovery that is

precluded by the results ofRESETLOGS. In this case, you must drop the table space containing the data file. Conversely, if a data file listed in the control file is not present in the data dictionary, then the

database removes references to it from the new control file. In both cases, the database includes an explanatory message in the alert log to let you know what was found.

Handling Errors During CREATE CONTROLFILE If Oracle Database sends you an error when you attempt to mount and open the database after

creating a new control file, the most likely cause is that you omitted a file from the CREATE

CONTROLFILE statement or included one that should not have been listed. In this case, you should restore

the files you backed up in step 3 and repeat the procedure from step 4, using the correct filenames.

3.1.3. Backing up Control Files

Use the ALTER DATABASE BACKUP CONTROLFILE statement to back up your control files.

You have two options:

1. Back up the control file to a binary file (duplicate of existing control file) using the following statement: ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/backup / control. bkp';

2. Produce SQL statements that can later be used to re-create your control file: ALTER DATABASE BACKUP CONTROLFILE TO TRACE; This command writes a SQL script to a trace file where it can be captured and edited to reproduce the

control file. View the alert log to determine the name and location of the trace file.

3.1.4. Recovering a Control File Using a Current Copy


`



There are various ways to recover control file from a current backup or from a multiplexed copy.

3.1.4.1. Recovering from Control File Corruption Using a Control File Copy

This procedure assumes that one of the control files specified in the

CONTROL_FILES parameter is corrupted, that the control file directory is still accessible, and that you have a multiplexed copy of the control file. 1. With the instance shut down, use an operating system command to overwrite the bad control file with a good copy: % cp /u03/oracle/prod/control03.ctl /u02/oracle/prod/control02.ctl

2. Start SQL*Plus and open the database: SQL> STARTUP

3.1.4.2. Recovering from Permanent Media Failure Using a Control File Copy

This procedure assumes that one of the control files specified in the CONTROL_FILES parameter is inaccessible due to a permanent media failure and that you have a multiplexed copy of the control file.

1. With the instance shut down, use an operating system command to copy the current copy of the control file to a new, accessible location:

% cp /u01/oracle/prod/control01.ctl /u04/oracle/prod/control03.ctl

2. Edit the CONTROL_FILES parameter in the initialization parameter file to replace the

bad location with the new location: CONTROL_FILES = (/u01/oracle/prod/control01.ctl, /u02/oracle/prod/control02.ctl, /u04/oracle/prod/control03.ctl) 3. Start SQL*Plus and open the database: SQL> STARTUP

If you have multiplexed control files, you can get the database started up quickly by

editing the CONTROL_FILES initialization parameter. Remove the bad control file from

CONTROL_FILES setting and you can restart the database immediately. Then you can

perform the reconstruction of the bad control file and at some later time shut down and restart

the database after editing the CONTROL_FILES initialization parameter to include the recovered control file.

3.1.5. Dropping Control Files

You want to drop control files from the database, for example, if the location of a control file is no longer appropriate. Remember that the database should have at least two control files at all times.

1. Shut down the database.

2. Edit the CONTROL_FILES parameter in the database initialization parameter file to delete the old control file name. 3. Restart the database.

3.2. Redo Log:

Redo log is the most crucial structure for recovery operations. it consists of two or more pre-allocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.

3.2.1. Redo Threads:

When speaking in the context of multiple database instances, the redo log for each database instance is also referred to as a redo thread. In typical configurations, only one database instance accesses an Oracle Database, so only one thread is present. In an Oracle Real Application Clusters environment, however, two or more instances concurrently access


`



a single database and each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo log files, thereby eliminating a potential performance bottleneck. This chapter describes how to configure and manage the redo log on a standard single-instance Oracle Database. The thread number can be assumed to be 1 in all discussions and examples of statements.

3.2.2. Redo Log Contents

Redo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to the data segment block for the table, the undo segment data block, and the transaction table of the undo segments.

Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.

Redo records are buffered in a circular fashion in the redo log buffer of the SGA and are written to one of the redo log files by the Log Writer (LGWR) database background process. Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.

Figure 3.1: Reuse of Redo Log Files by LGWR Redo records can also be written to a Redolog file before the corresponding

transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed. If necessary, the database can roll back these changes.

3.2.3. How Oracle Database Writes to the Redo Log The redo log of a database consists of two or more redo log files. The database

requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode).

LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure 12–1 illustrates the circular writing of the redo log file. The numbers next to each line indicate the sequence in which LGWR writes to each redo log file.

Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.


`



If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the data files.

If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file is available to LGWR after the changes recorded in it have been written to the data files and the file has been archived.

3.2.4. Active (Current) and Inactive Redo Log Files

Oracle Database uses only one redo log file at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current

redo log file. Redo log files that are required for instance recovery are called active redo log files.

Redo log files that are no longer required for instance recovery are called inactive redo log files.

If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARCn) has archived its contents. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the next log file in the sequence when it becomes inactive.

3.2.5. Log Switches and Log Sequence Numbers

A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.

Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.

Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.

3.3. Planning the Redo Log This section provides guidelines you should consider when configuring a database

instance redo log and contains the following topics: Multiplexing Redo Log Files Placing Redo Log Members on Different Disks Planning the Size of Redo Log Files Planning the Block Size of Redo Log Files Choosing the Number of Redo Log Files Controlling Archive Lag

3.3.1. Multiplexing Redo Log Files

To protect against a failure involving the redo log itself, Oracle Database allows a multiplexed redo log, meaning that two or more identical copies of the redo log can be automatically maintained in separate locations. For the most benefit, these locations should be on separate disks. Even if all copies of the redo log are on the same disk, however, the redundancy can help protect against I/O errors, file corruption, and so on. When redo log files


`



are multiplexed, LGWR concurrently writes the same redo log information to multiple identical redo log files, thereby eliminating a single point of redo log failure.

Multiplexing is implemented by creating groups of redo log files. A group consists of a redo log file and its multiplexed copies. Each identical copy is said to be a member of the group. Each redo log group is defined by a number, such as group 1, group 2, and so on.

Figure 3.2: Multiplexed Redo Log Files

In Figure 3.2, A_LOG1 and B_LOG1 are both members of Group 1, A_LOG2 and

B_LOG2 are both members of Group 2, and so forth. Each member in a group must be the same size. Each member of a log file group is concurrently active—that is, concurrently written to by LGWR—as indicated by the identical log sequence numbers assigned by

LGWR. In Figure 3.2, first LGWR writes concurrently to both A_LOG1 and B_LOG1. Then

it writes concurrently to both A_LOG2 and B_LOG2, and so on. LGWR never writes

concurrently to members of different groups (for example, to A_LOG1 and B_LOG2).

3.3.1.1. Responding to Redo Log Failure

Whenever LGWR cannot write to a member of a group, the database marks that

member as INVALID and writes an error message to the LGWR trace file and to the database alert log to indicate the problem with the inaccessible files. The specific reaction of LGWR when a redo log member is unavailable depends on the reason for the lack of availability, as summarized in the table that follows.

3.3.1.2. Legal and Illegal Configurations

In most cases, a multiplexed redo log should be symmetrical: all groups of the redo log should have the same number of members. However, the database does not require that a multiplexed redo log be symmetrical. For example, one group can have only one member, and other groups can have two members. This configuration protects against disk failures that temporarily affect some redo log members but leave others intact.

The only requirement for an instance redo log is that it has at least two groups. Figure 3.3 shows legal and illegal multiplexed redo log configurations. The second configuration is illegal because it has only one group.


`



Figure 3.3; Legal and Illegal Multiplexed Redo Log Configuration

3.3.2. Placing Redo Log Members on Different Disks

When setting up a multiplexed redo log, place members of a group on different physical disks. If a single disk fails, then only one member of a group becomes unavailable to LGWR and other members remain accessible to LGWR, so the instance can continue to function.

If you archive the redo log, spread redo log members across disks to eliminate contention between the LGWR and ARCn background processes. For example, if you have two groups of multiplexed redo log members (a duplexed redo log), place each member on a different disk and set your archiving destination to a fifth disk. Doing so will avoid contention between LGWR (writing to the members) and ARCn (reading the members).

3.3.3. Planning the Size of Redo Log Files

When setting the size of redo log files, consider whether you will be archiving the redo log. Redo log files should be sized so that a filled group can be archived to a single unit of offline storage media (such as a tape or disk), with the least amount of space on the medium left unused. For example, suppose only one filled redo log group can fit on a tape and 49% of the tape storage capacity remains unused. In this case, it is better to decrease the size of the redo log files slightly, so that two log groups could be archived on each tape.

All members of the same multiplexed redo log group must be the same size. Members of different groups can have different sizes. However, there is no advantage in varying file size between groups. If checkpoints are not set to occur between log switches, make all groups the same size to guarantee that checkpoints occur at regular intervals. The minimum size permitted for a redo log file is 4 MB.

3.3.4. Planning the Block Size of Redo Log Files


`



Unlike the database block size, which can be between 2K and 32K, redo log files always default to a block size that is equal to the physical sector size of the disk. Historically, this has typically been 512 bytes (512B).

Some newer high-capacity disk drives offer 4K byte (4K) sector sizes for both increased ECC capability and improved format efficiency. Most Oracle Database platforms are able to detect this larger sector size. The database then automatically creates redo log files with a 4K block size on those disks.

However, with a block size of 4K, there is increased redo wastage. In fact, the amount of redo wastage in 4K blocks versus 512B blocks is significant. You can determine the

amount of redo wastage by viewing the statistics stored in the V$SESSTAT and

V$SYSSTAT views. SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo wastage'; NAME VALUE -------------------------------- ---------- redo wastage 17941684

To avoid the additional redo wastage, if you are using emulation-mode disks—4K sector size disk drives that emulate a 512B sector size at the disk interface—you can override the default 4K block size for redo logs by specifying a 512B block size or, for some platforms, a 1K block size. However, you will incur significant performance degradation when a redo log write is not aligned with the beginning of the 4K physical sector. Because seven out of eight 512B slots in a 4K physical sector are not aligned, performance degradation typically does occur. Thus, you must evaluate the trade-off between performance and disk wastage when planning the redo log block size on 4K sector size emulation-mode disks.

Beginning with Oracle Database 11g Release 2, you can specify the block size of

online redo log files with the BLOCKSIZE keyword in the CREATE DATABASE, ALTER

DATABASE, and CREATE CONTROLFILE statements. The permissible block sizes are

512, 1024, and 4096. The following statement adds a redo log file group with a block size of 512B. The

BLOCKSIZE 512 clause is valid but not required for 512B sector size disks. For 4K sector

size emulation-mode disks, the BLOCKSIZE 512 clause overrides the default 4K size. ALTER DATABASE orcl ADD LOGFILE GROUP 4 ('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log') SIZE 100M BLOCKSIZE 512 REUSE;

To ascertain the redo log file block size, run the following query: SQL> SELECT BLOCKSIZE FROM V$LOG; BLOCKSIZE --------- 512

3.3.5. Choosing the Number of Redo Log Files

The best way to determine the appropriate number of redo log files for a database instance is to test different configurations. The optimum configuration has the fewest groups possible without hampering LGWR from writing redo log information. In some cases, a database instance may require only two groups. In other situations, a database instance may require additional groups to guarantee that a recycled group is always available to LGWR. During testing, the easiest way to determine whether the current redo log configuration is satisfactory is to examine the contents of the LGWR trace file and the database alert log. If messages indicate that LGWR frequently has to wait for a group because a checkpoint has not completed or a group has not been archived, add groups.


`



Consider the parameters that can limit the number of redo log files before setting up or altering the configuration of an instance redo log. The following parameters limit the number of redo log files that you can add to a database:

The MAXLOGFILES parameter used in the CREATE DATABASE statement determines the maximum number of groups of redo log files for each database.

Group values can range from 1 to MAXLOGFILES. When the compatibility level is set earlier than 10.2.0, the only way to override this upper limit is to re-create the database or its control file. Therefore, it is important to consider this limit before creating a database. When compatibility is set to 10.2.0 or later, you can

exceed the MAXLOGFILES limit, and the control files expand as needed. If

MAXLOGFILES is not specified for the CREATE DATABASE statement, then

the database uses an operating system specific default value.

The MAXLOGMEMBERS parameter used in the CREATE DATABASE statement

determines the maximum number of members for each group. As with

MAXLOGFILES, the only way to override this upper limit is to re-create the database or control file. Therefore, it is important to consider this limit before

creating a database. If no MAXLOGMEMBERS parameter is specified for the

CREATE DATABASE statement, then the database uses an operating system

default value.

3.4. Creating Redo Log Groups and Members

Plan the redo log of a database and create all required groups and members of redo log files during database creation. However, there are situations where you might want to create additional groups or members. For example, adding groups to a redo log can correct redo log group availability problems.

To create new redo log groups and members, you must have the ALTER DATABASE

system privilege. A database can have up to MAXLOGFILES groups.

3.4.1. Creating Redo Log Groups

To create a new group of redo log files, use the SQL statement ALTER DATABASE

with the ADD LOGFILE clause. The following statement adds a new group of redo logs to the database:

ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 100M;

You can also specify the number that identifies the group using the GROUP clause: ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 100M BLOCKSIZE 512;

Using group numbers can make administering redo log groups easier. However, the

group number must be between 1 and MAXLOGFILES. Do not skip redo log file group numbers (that is, do not number your groups 10, 20, 30, and so on), or you will consume unnecessary space in the control files of the database. In the preceding statement, the

BLOCKSIZE clause is optional.

3.4.2. Creating Redo Log Members

In some cases, it might not be necessary to create a complete group of redo log files. A group could already exist, but not be complete because one or more members of the group were dropped (for example, because of a disk failure). In this case, you can add new members to an existing group.


`



To create new redo log members for an existing group, use the SQL statement ALTER

DATABASE with the ADD LOGFILE MEMBER clause. The following statement adds a

new redo log member to redo log group number 2: ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

Notice that filenames must be specified, but sizes need not be. The size of the new members is determined from the size of the existing members of the group. When using the

ALTER DATABASE statement, you can alternatively identify the target group by specifying

all of the other members of the group in the TO clause, as shown in the following example: ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

3.4.3. Relocating and Renaming Redo Log Members

You can use operating system commands to relocate redo logs, then use the ALTER

DATABASE statement to make their new names (locations) known to the database. This procedure is necessary, for example, if the disk currently used for some redo log files is going to be removed, or if data files and several redo log files are stored on the same disk and should be separated to reduce contention.

To rename redo log members, you must have the ALTER DATABASE system privilege. Additionally, you might also need operating system privileges to copy files to the desired location and privileges to open and back up the database. Before relocating your redo logs, or making any other structural changes to the database, completely back up the database in case you experience problems while performing the operation. As a precaution, after renaming or relocating a set of redo log files, immediately back up the database control file.

Use the following steps for relocating redo logs. The example used to illustrate these steps assumes:

The log files are located on two disks: diska and diskb.

The redo log is duplexed: one group consists of the members/diska/logs/log1a.rdo and

/diskb/logs/log1b.rdo, and the second group consists of the members

/diska/logs/log2a.rdo and /diskb/logs/log2b.rdo.

■ The redo log files located on diska must be relocated to diskc. The new filenames will reflect

the new location: /diskc/logs/log1c.rdo and /diskc/logs/log2c.rdo.

3.4.3.1.Steps for Renaming Redo Log Members

1. Shut down the database. SHUTDOWN 2. Copy the redo log files to the new location. Operating system files, such as redo log members, must be copied using the appropriate operating system commands. 3. Startup the database, mount, but do not open it. CONNECT / as SYSDBA STARTUP MOUNT 4. Rename the redo log members. Uses the ALTER DATABASE statements with the RENAME FILE clause to rename the database redo log files. ALTER DATABASE RENAME FILE '/diska/logs/log1a.rdo', '/diska/logs/log2a.rdo' TO '/diskc/logs/log1c.rdo', '/diskc/logs/log2c.rdo'; 5. Open the database for normal operation. The redo log alterations take effect when the database is opened. ALTER DATABASE OPEN;

3.5. Dropping Redo Log Groups and Members


`



In some cases, you may want to drop an entire group of redo log members. For example, you want to reduce the number of groups in an instance redo log. In a different case, you may want to drop one or more specific redo log members. For example, if a disk failure occurs, you may need to drop all the redo log files on the failed disk so that the database does not try to write to the inaccessible files. In other situations, particular redo log files become unnecessary. For example, a file might be stored in an inappropriate location.

3.5.1. Dropping Log Groups

To drop a redo log group, you must have the ALTER DATABASE system privilege. Before dropping a redo log group, consider the following restrictions and precautions:

■ An instance requires at least two groups of redo log files, regardless of the number of

members in the groups. (A group comprises one or more members.)

■ You can drop a redo log group only if it is inactive. If you must drop the current group,

then first force a log switch to occur.

■ Make sure a redo log group is archived (if archiving is enabled) before dropping it. To see

whether this has happened, use the V$LOG view. SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG; GROUP# ARC STATUS --------- --- ---------------- 1 YES ACTIVE 2 NO CURRENT 3 YES INACTIVE 4 YES INACTIVE

Drop a redo log group with the SQL statement ALTER DATABASE with the DROP LOGFILE clause. The following statement drops redo log group number 3: ALTER DATABASE DROP LOGFILE GROUP 3;

When a redo log group is dropped from the database, and you are not using the Oracle Managed Files feature, the operating system files are not deleted from disk. Rather, the control files of the associated database are updated to drop the members of the group from the database structure. After dropping a redo log group, ensure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log files. When using Oracle Managed Files, the cleanup of operating systems files is done automatically for you.

3.5.2. Dropping Redo Log Members

To drop a redo log member, you must have the ALTER DATABASE system privilege. Consider the following restrictions and precautions before dropping individual redo log members:

It is permissible to drop redo log files so that a multiplexed redo log becomes temporarily asymmetric. For example, if you use duplexed groups of redo log files, you can drop one member of one group, even though all other groups have two members each. However, you should rectify this situation immediately so that all groups have at least two members, and thereby eliminate the single point of failure possible for the redo log.

An instance always requires at least two valid groups of redo log files, regardless of the number of members in the groups. (A group comprises one or more members.) If the member you want to drop is the last valid member of the group, you cannot drop the member until the other members become valid. To see a redo log file status, use


`



the V$LOGFILE view. A redo log file becomes INVALID if the database cannot

access it. It becomes STALE if the database suspects that it is not complete or

correct. A stale log file becomes valid again the next time its group is made the active group.

You can drop a redo log member only if it is not part of an active or current group. To drop a member of an active group, first force a log switch to occur.

Make sure the group to which a redo log member belongs is archived (if archiving is enabled) before dropping the member. To see whether this has happened, use the

V$LOG view.

To drop specific inactive redo log members, use the ALTER DATABASE statement

with the DROP LOGFILE MEMBER clause. The following statement drops the redo

log /oracle/dbs/log3c.rdo: ALTER DATABASE DROP LOGFILE MEMBER

'/oracle/dbs/log3c.rdo'; When a redo log member is dropped from the database, the operating system file is not deleted from disk. Rather, the control files of the associated database are updated to drop the member from the database structure. After dropping a redo log file, ensure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log file. To drop a member of an active group, you must first force a log switch.

3.6. Forcing Log Switches A log switch occurs when LGWR stops writing to one redo log group and starts

writing to another. By default, a log switch occurs automatically when the current redo log file group fills.

You can force a log switch to make the currently active group inactive and available for redo log maintenance operations. For example, you want to drop the currently active group, but are not able to do so until the group is inactive. You may also want to force a log switch if the currently active group must be archived at a specific time before the members of the group are completely filled. This option is useful in configurations with large redo log files that take a long time to fill.

To force a log switch, you must have the ALTER SYSTEM privilege. Use the

ALTER SYSTEM statement with the SWITCH LOGFILE clause.

The following statement forces a log switch: ALTER SYSTEM SWITCH LOGFILE;

3.7. Verifying Blocks in Redo Log Files You can configure the database to use checksums to verify blocks in the redo log files. If you set the

initialization parameter DB_BLOCK_CHECKSUM to TYPICAL (the default), the database computes a

checksum for each database block when it is written to disk, including each redo log block as it is being written to the current log. The checksum is stored the header of the block.

Oracle Database uses the checksum to detect corruption in a redo log block. The database verifies the redo log block when the block is read from an archived log during recovery and when it writes the block to an archive log file. An error is raised and written to the alert log if corruption is detected.

If corruption is detected in a redo log block while trying to archive it, the system attempts to read the

block from another member in the group. If the block is corrupted in all members of the redo log group, then

archiving cannot proceed. The value of the DB_BLOCK_CHECKSUM parameter can be changed dynamically

using the

ALTER SYSTEM statement.

3.8. Clearing a Redo Log File

A redo log file might become corrupted while the database is open, and ultimately

stop database activity because archiving cannot continue. In this situation the ALTER


`



DATABASE CLEAR LOGFILE statement can be used to reinitialize the file without shutting down the database.

The following statement clears the log files in redo log group number 3: ALTER DATABASE CLEAR LOGFILE GROUP 3; This statement overcomes two situations where dropping redo logs is not possible:

If there are only two log groups The corrupt redo log file belongs to the current group

If the corrupt redo log file has not been archived, use the UNARCHIVED keyword in the statement.

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3; This statement clears the corrupted redo logs and avoids archiving them. The cleared

redo logs are available for use even though they were not archived. If you clear a log file that is needed for recovery of a backup, then you can no longer recover from that backup. The database writes a message in the alert log describing the backups from which you cannot recover.

To clear an un-archived redo log that is needed to bring an offline tablespace online,

use the UNRECOVERABLE DATAFILE clause in the ALTER DATABASE CLEAR

LOGFILE statement.

If you clear a redo log needed to bring an offline tablespace online, you will not be able to bring the tablespace online again. You will have to drop the tablespace or perform an incomplete recovery. Note that tablespaces taken offline normal do not require recovery.

Chapter 04

Managing Tablespaces and Operations

4.1. Tablespaces

A tablespace is a database storage unit that groups related logical structures together. The database data files are stored in tablespaces. Before working with tablespaces of an Oracle Database, familiarize yourself with the guidelines: ■ Using Multiple Tablespaces ■ Assigning Tablespace Quotas to Users

4.2. Using Multiple Tablespaces

Using multiple tablespaces allows you more flexibility in performing database operations. When a database has multiple tablespaces, you can:

Separate user data from data dictionary data to reduce I/O contention. Separate data of one application from the data of another to prevent multiple

applications from being affected if a tablespace must be taken offline. Store the data files of different tablespaces on different disk drives to reduce I/O

contention. Take individual tablespaces offline while others remain online, providing better

overall availability.


`



Optimizing tablespace use by reserving a tablespace for a particular type of database use, such as high update activity, read-only activity, or temporary segment storage.

Back up individual tablespaces. Some operating systems set a limit on the number of files that can be open

simultaneously. Such limits can affect the number of tablespaces that can be simultaneously online. To avoid exceeding your operating system limit, plan your tablespaces efficiently. Create only enough tablespaces to fulfill your needs, and create these tablespaces with as few files as possible. If you must increase the size of a tablespace, then add one or two large data files, or create data files with auto extension enabled, rather than creating many small data files.

Review your data in light of these factors and decide how many tablespaces you need for your database design.

4.3. Creating Tablespaces

Before you can create a tablespace, you must create a database to contain it. The

primary tablespace in any database is the SYSTEM tablespace, which contains information basic to the functioning of the database server, such as the data dictionary and the system

rollback segment. The SYSTEM tablespace is the first tablespace created at database

creation. It is managed as any other tablespace, but requires a higher level of privilege and is

restricted in some ways. For example, you cannot rename or drop the SYSTEM tablespace or

take it offline.

The SYSAUX tablespace, which acts as an auxiliary tablespace to the SYSTEM tablespace, is also always created when you create a database. It contains the schemas used by various Oracle products and features, so that those products do not require their own

tablespaces. As for the SYSTEM tablespace, management of the SYSAUX tablespace requires a higher level of security and you cannot rename or drop it.

The steps for creating tablespaces vary by operating system, but the first step is always to use your operating system to create a directory structure in which your data files will be allocated. On most operating systems, you specify the size and fully specified filenames of data files when you create a new tablespace or alter an existing tablespace by adding data files. Whether you are creating a new tablespace or modifying an existing one, the database automatically allocates and formats the data files as specified.

To create a new tablespace, use the SQL statement CREATE TABLESPACE or

CREATE TEMPORARY TABLESPACE. You must have the CREATE TABLESPACE

system privilege to create a tablespace. Later, you can use the ALTER TABLESPACE or

ALTER DATABASE statements to alter the tablespace. You must have the ALTER

TABLESPACE or ALTER DATABASE system privilege, correspondingly.

You can also use the CREATE UNDO TABLESPACE statement to create a special type of tablespace called an undo tablespace, which is specifically designed to contain undo records. These are records generated by the database that are used to roll back, or undo,

changes to the database for recovery, read consistency, or as requested by a ROLLBACK statement.

4.4. Tablespace Architecture

A prerequisite to competently setting up the tablespaces in your database is understanding the different types of tablespaces and how they are used in an Oracle database. In this section, we’ll review the different types of tablespaces and give some examples of how they are managed.

In addition, we’ll provide an overview of Oracle’s Optimal Flexible Architecture and how it provides a framework for storing tablespace datafiles as well as Oracle executables


`



and other Oracle components, such as redo log files, control files, and so forth. We’ll also review the types of tablespaces by category—SYSTEM tablespaces, the SYSAUX tablespace, temporary tablespaces, undo tablespaces, and bigfile tablespaces—and describe their function.

4.4.1. Tablespace Types

The primary types of tablespaces in an Oracle database are permanent, undo, and temporary. Permanent tablespaces contain segments that persist beyond the duration of a session or a transaction. Although the undo tablespace may have segments that are retained beyond the end of a session or a transaction, it provides read consistency for select statements that access tables being modified as well as provides undo data for a number of the flashback features of the database. Primarily, however, undo segments store the previous values of columns being updated or deleted, or to provide an indication that the row did not exist for an insert so that if a user’s session fails before the user issues a commit or a rollback, the updates, inserts, and deletes will be removed. Undo segments are never directly accessible by a user session, and undo tablespaces may only have undo segments.

As the name implies, temporary tablespaces contain transient data that exists only for the duration of the session, such as space to complete a sort operation that will not fit in memory. Bigfile tablespaces can be used for any of these three types of tablespaces, and they simplify tablespace management by moving the maintenance point from the datafile to the tablespace. Bigfile tablespaces consist of one and only one datafile.

4.4.1.1. Permanent

The SYSTEM and SYSAUX tablespaces are two examples of permanent tablespaces. In addition, any segments that need to be retained by a user or an application beyond the boundaries of a session or transaction should be stored in a permanent tablespace

SYSTEM Tablespace:

User segments should never reside in the SYSTEM tablespace, period. As of Oracle 10g, you can specify a default permanent tablespace in addition to the ability to specify a default temporary tablespace in Oracle9i.

If you use the Oracle Universal Installer (OUI) to create a database for you, a separate tablespace other than SYSTEM is created for both permanent and temporary segments. If you create a database manually, be sure to specify both a default permanent tablespace and a default temporary tablespace, as in the sample create database command that follows. CREATE DATABASE rjbdb USER SYS IDENTIFIED BY kshelt25 USER SYSTEM IDENTIFIED BY mgrab45 LOGFILE GROUP 1 ('/u02/oracle11g/oradata/rjbdb/redo01.log') SIZE 100M, GROUP 2 ('/u04/oracle11g/oradata/rjbdb/redo02.log') SIZE 100M, GROUP 3 ('/u06/oracle11g/oradata/rjbdb/redo03.log') SIZE 100M MAXLOGFILES 5 MAXLOGMEMBERS 5 MAXLOGHISTORY 1 MAXDATAFILES 100 MAXINSTANCES 1 CHARACTER SET US7ASCII NATIONAL CHARACTER SET AL16UTF16 DATAFILE '/u01/oracle11g/oradata/rjbdb/system01.dbf' SIZE 325M REUSE EXTENT MANAGEMENT LOCAL


`



SYSAUX DATAFILE '/u01/oracle11g/oradata/rjbdb/sysaux01.dbf' SIZE 325M REUSE DEFAULT TABLESPACE USERS DATAFILE '/u03/oracle11g/oradata/rjbdb/users01.dbf' SIZE 50M REUSE DEFAULT TEMPORARY TABLESPACE tempts1 TEMPFILE '/u01/oracle11g/oradata/rjbdb/temp01.dbf' SIZE 20M REUSE UNDO TABLESPACE undotbs DATAFILE '/u02/oracle11g/oradata/rjbdb/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

As of Oracle 10g, the SYSTEM tablespace is locally managed by default; in other words, all space usage is managed by a bitmap segment in the first part of the first datafile for the tablespace. In a database where the SYSTEM tablespace is locally managed, the other tablespaces in the database must also be locally managed or they must be read-only. Using locally managed tablespaces takes some of the contention off the SYSTEM tablespace because space allocation and de-allocation operations for a tablespace do not need to use data dictionary tables.

SYSAUX Tablespace:

Like the SYSTEM tablespace, the SYSAUX tablespace should not have any user segments. The contents of the SYSAUX tablespace, broken down by application, can be reviewed using EM Database Control. You can edit the SYSAUX tablespace by clicking the Tablespaces link under the Server tab and clicking the SYSAUX link. Figure 4.1 shows a graphical representation of the space usage within SYSAUX.

Figure 4.1: EM Database Control SYSAUX tablespace contents If the space usage for a particular application that resides in the SYSAUX tablespace

becomes too high or creates an I/O bottleneck through high contention with other applications that use the SYSAUX tablespace, you can move one or more of these applications to a different tablespace. Below the pie chart in Figure 4.1, we can click the Change Tablespace link of a SYSAUX occupant and move it to another tablespace.

The SYSAUX tablespace can be monitored just like any other tablespace; Undo Multiple undo tablespaces can exist in a database, but only one undo tablespace can

be active at any given time. Undo tablespaces are used for rolling back transactions, for providing read consistency for select statements that run concurrently with DML statements on the same table or set of tables, and for supporting a number of Oracle Flashback features, such as Flashback Query. The undo tablespace needs to be sized correctly to prevent


`



“Snapshot too old” errors and to provide enough space to support initialization parameters such as UNDO_RETENTION.

4.4.1.2. Temporary

More than one temporary tablespace can be online and active in the database, but until Oracle 10g, multiple sessions by the same user would use the same temporary tablespace because only one default temporary tablespace could be assigned to a user. To solve this potential performance bottleneck, Oracle supports temporary tablespace groups. A temporary tablespace group is a synonym for a list of temporary tablespaces.

A temporary tablespace group must consist of at least one temporary tablespace; it cannot be empty. Once a temporary tablespace group has no members, it no longer exists. One of the big advantages of using temporary tablespace groups is to provide a single user with multiple sessions with the ability to use a different actual temporary tablespace for each session.

Instead of a single temporary tablespace being assigned to a user, the temporary tablespace group is assigned; in this example, the temporary tablespace group TEMPGRP has been assigned to OE. However, because there are three actual temporary tablespaces within the TEMPGRP temporary tablespace group, the first OE session may use temporary tablespace TEMP1, and the select statement executed by the second OE session may use the other two temporary tablespaces, TEMP2 and TEMP3, in parallel. Before Oracle 10g, both sessions would use the same temporary tablespace, potentially causing a performance issue. Creating a temporary tablespace group is very straightforward. After creating the individual tablespaces TEMP1, TEMP2, and TEMP3, we can create a temporary tablespace group named TEMPGRP as follows: SQL> alter tablespace temp1 tablespace group tempgrp; Tablespace altered. SQL> alter tablespace temp2 tablespace group tempgrp; Tablespace altered. SQL> alter tablespace temp3 tablespace group tempgrp; Tablespace altered.

Changing the database’s default temporary tablespace to TEMPGRP uses the same command as assigning an actual temporary tablespace as the default; temporary tablespace groups are treated logically the same as a temporary tablespace: SQL> alter database default temporary tablespace tempgrp; Database altered.

To drop a tablespace group, we must first drop all its members. Dropping a member of a tablespace group is accomplished by assigning the temporary tablespace to a group with an empty string (in other words, removing the tablespace from the group): SQL> alter tablespace temp3 tablespace group ''; Tablespace altered.

As you might expect, assigning a temporary tablespace group to a user is identical to assigning a temporary tablespace to a user; this assignment can happen either when the user is created or at some point in the future. In the following example, the new user JENWEB is assigned the temporary tablespace TEMPGRP: SQL> create user jenweb identified by pi4001 2 default tablespace users 3 temporary tablespace tempgrp;


`



User created. If we did not assign the tablespace during user creation, the user JENWEB would still

be assigned TEMPGRP as the temporary tablespace because it is the database default from our previous create database example. A couple of changes have been made to the data dictionary views in Oracle Database 10g and Oracle Database 11g to support temporary tablespace groups. The data dictionary view DBA_USERS still has the column TEMPORARY_TABLESPACE, as in previous versions of Oracle, but this column may now contain either the name of the temporary tablespace assigned to the user, or the name of a temporary tablespace group. SQL> select username, default_tablespace, temporary_tablespace 2 from dba_users where username = 'JENWEB'; USERNAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE -------------------- ------------------ -------------------- JENWEB USERS TEMPGRP 1 row selected. The new data dictionary view DBA_TABLESPACE_GROUPS shows the members of each temporary tablespace group: SQL> select group_name, tablespace_name from dba_tablespace_groups; GROUP_NAME TABLESPACE_NAME ---------------------------- ---------------------------- TEMPGRP TEMP1 TEMPGRP TEMP2 TEMPGRP TEMP3 3 rows selected.

As with most every other feature of Oracle that can be accomplished with the command line, assigning members to temporary tablespace groups or removing members from temporary tablespace groups can be performed using EM Database Control

4.4.1.3. Bigfile

A bigfile tablespace eases database administration because it consists of only one datafile. The single datafile can be up to 128TB (terabytes) in size if the tablespace block size is 32KB. Many of the commands previously available only for maintaining datafiles can now be used at the tablespace level if the tablespace is a bigfile tablespace. The maintenance convenience of bigfile tablepsaces can be offset by some potential disadvantages. Because a bigfile tablespace is a single datafile, a full backup of a single large datafile will take significantly longer than a full backup of several smaller datafiles (with the same total size as the single bigfile tablespace) because Oracle only uses one slave process per datafile and therefore cannot back up different parts of a bigfile tablespace using parallel processes. If your bigfile tablespaces are read-only or only changed blocks are backed up on a regular basis, the backup issue may not be critical in your environment.

4.5. Optimal Flexible Architecture

Oracle’s Optimal Flexible Architecture (OFA) provides guidelines to ease the maintenance of the Oracle software and database files as well as improve the performance of the database by placing the database files such that I/O bottlenecks are minimized.

Although using OFA is not strictly enforced when you’re installing or maintaining an Oracle environment, using OFA makes it easy for someone to understand how your database is organized on disk, preventing that phone call in the middle of the night during the week you’re on vacation! OFA is slightly different depending on the type of storage options you


`



use—either an Automatic Storage Management (ASM) environment or a standard operating system file system that may or may not be using a third-party logical volume manager or RAID-enabled disk subsystem. Non-ASM Environment

In a non-ASM environment on a Unix server, at least three file systems on separate physical devices are required to implement OFA recommendations. Starting at the top, the recommended format for a mount point is /<string const><numeric key>, where <string const> can be one or several letters and <numeric key> is either two or three digits. For example, on one system we may have mount points /u01, /u02, /u03, and /u04, with room to expand to an additional 96 mount points without changing the file-naming convention. Figure 3-5 shows a typical Unix file system layout with an OFA-compliant Oracle directory structure. There are two instances on this server: an ASM instance to manage disk groups and a standard RDBMS instance (dw).

Software Executables The software executables for each distinct product name reside in the directory /<string const><numeric key>/<directory type>/<product owner>, where <string const> and <numeric key> are defined previously, <directory type> implies the type of files installed in this directory, and <product owner> is the name of the user that owns and installs the files in this directory. For example, /u01/app/oracle would contain application-related files (executables) installed by the user oracle on the server. The directory /u01/app/apache would contain the executables for the middleware web server installed from a previous version of Oracle. As of Oracle 10g, the OFA standard makes it easy for the DBA to install multiple versions of the database and client software within the same high-level directory. The OFA-compliant Oracle home path, corresponding to the environment variable ORACLE_HOME, contains a suffix that corresponds to the type and incarnation of the installation. For example, one installation of Oracle 11g, two different installations of Oracle 10g, and one installation of Oracle9i may reside in the following three directories: /u01/app/oracle/product/9.2.0.1 /u01/app/oracle/product/10.1.0/db_1 /u01/app/oracle/product/10.1.0/db_2 /u01/app/oracle/product/11.1.0/db_1

At the same time, the Oracle client executables and configuration may be stored in the same parent directory as the database executables: /u01/app/oracle/product/10.1.0/client_1

Some installation directories will never have more than one instance for a given product; for example, Oracle Cluster Ready Services (CRS) will be installed in the following directory given the previous installations: /u01/app/oracle/product/11.1.0/crs

Because CRS can only be installed once on a system, it does not have an incrementing numeric suffix.

Database Files Any non-ASM Oracle datafiles reside in /<mount point>/oradata/<database name>, where <mount point> is one of the mount points we discussed earlier, and <database name> is the value of the initialization parameter DB_NAME. For example, /u02/oradata/rac0 and /u03/oradata/rac0 would contain the non-ASM control files, redo log files, and datafiles for the instance rac0, whereas /u05/oradata/dev1 would contain the same files for the dev1 instance on the same server.

tablespace names eight characters or less in a Unix environment. Because portable Unix filenames are restricted to 14 characters, and the suffix of an OFA datafile name is <n>.dbf, where n is two digits, a total of six characters are needed for the suffix in the file system. This leaves eight characters for the tablespace name itself.


`



Only control files, redo log files, and datafiles associated with the database <database name> should be stored in the directory /<mount point>/oradata/<database name>. For the database ord managed without ASM, the datafile names are as follows: SQL> select file#, name from v$datafile; FILE# NAME ---------- ----------------------------------- 1 /u05/oradata/ord/system01.dbf 2 /u05/oradata/ord/undotbs01.dbf 3 /u05/oradata/ord/sysaux01.dbf 4 /u05/oradata/ord/users01.dbf 5 /u09/oradata/ord/example01.dbf 6 /u09/oradata/ord/oe_trans01.dbf 7 /u05/oradata/ord/users02.dbf 8 /u06/oradata/ord/logmnr_rep01.dbf 9 /u09/oradata/ord/big_users.dbf 10 /u08/oradata/ord/idx01.dbf 11 /u08/oradata/ord/idx02.dbf 12 /u08/oradata/ord/idx03.dbf 13 /u08/oradata/ord/idx04.dbf 14 /u08/oradata/ord/idx05.dbf 15 /u08/oradata/ord/idx06.dbf 16 /u08/oradata/ord/idx07.dbf 17 /u08/oradata/ord/idx08.dbf 17 rows selected.

Other than file numbers 8 and 9, all the datafiles in the ord database are OFA compliant and are spread out over four different mount points. The tablespace name in file number 8 is too long, and file number 9 does not have a numeric two-digit counter to represent new datafiles for the same tablespace. ASM Environment

In an ASM environment, the executables are stored in the directory structure presented previously; however, if you browsed the directory /u02/oradata in Figure 3-5, you would see no files. All the control files, redo log files, and datafiles for the instance dw are managed by the ASM instance +ASM on this server.

The actual datafile names are not needed for most administrative functions because ASM files are all Oracle Managed Files (OMF). This eases the overall administrative effort required for the database.

Within the ASM storage structure, an OFA-like syntax is used to subdivide the file types even further: SQL> select file#, name from v$datafile; FILE# NAME ---------- ---------------------------------------- 1 +DATA/dw/datafile/system.256.622426913 2 +DATA/dw/datafile/sysaux.257.622426915 3 +DATA/dw/datafile/undotbs1.258.622426919 4 +DATA/dw/datafile/users.259.622426921 5 +DATA/dw/datafile/example.265.622427181 5 rows selected. SQL> select name from v$controlfile; NAME ----------------------------------------


`



+DATA/dw/controlfile/current.260.622427059 +RECOV/dw/controlfile/current.256.622427123 2 rows selected. SQL> select member from v$logfile; MEMBER ---------------------------------------- +DATA/dw/onlinelog/group_3.263.622427143 +RECOV/dw/onlinelog/group_3.259.622427145 +DATA/dw/onlinelog/group_2.262.622427135 +RECOV/dw/onlinelog/group_2.258.622427137 +DATA/dw/onlinelog/group_1.261.622427127 +RECOV/dw/onlinelog/group_1.257.622427131 6 rows selected.

Within the disk groups +DATA and +RECOV, we see that each of the database file types, such as datafiles, control files, and online log files, has its own directory. Fully qualified ASM filenames have the format +<group>/<dbname>/<file type>/<tag>.<file>.<incarnation>

where <group> is the disk group name, <dbname> is the database to which the file belongs, <file type> is the Oracle file type, <tag> is information specific to the file type, and the pair <file>.<incarnation> ensures uniqueness within the disk group.

4.6. Oracle Installation Tablespaces

Tablespaces created with a standard Oracle installation using the Oracle Universal Installer (OUI) are as follow; the EXAMPLE tablespace is optional; it is installed if you specify that you want the sample schemas created during the installation dialogue.

4.6.1. SYSTEM

No user segments should ever be stored in the SYSTEM tablespace. The new clause default tablespace in the create database command helps to prevent this occurrence by automatically assigning a permanent tablespace for all users that have not explicitly been assigned a permanent tablespace. An Oracle installation performed using the Oracle Universal Installer will automatically assign the USERS tablespace as the default permanent tablespace.

The SYSTEM tablespace will grow more quickly the more you use procedural objects such as functions, procedures, triggers, and so forth, because these objects must reside in the data dictionary. This also applies to abstract data types and Oracle’s other object-oriented features.

4.6.2. SYSAUX

As with the SYSTEM tablespace, user segments should never be stored in the SYSAUX tablespace. If one particular occupant of the SYSAUX tablespace takes up too much of the available space or significantly affects the performance of other applications that use the SYSAUX tablespace, you should consider moving the occupant to another tablespace.

4.6.3. TEMP

Instead of one very large temporary tablespace, consider using several smaller temporary tablespaces and creating a temporary tablespace group to hold them. This can improve the response time for applications that create many sessions with the same username.

4.6.4. UNDOTBS1 Even though a database may have more than one undo tablespace, only one undo

tablespace can be active at any given time. If more space is needed for an undo tablespace, and AUTOEXTEND is not enabled, another datafile can be added. One undo tablespace must


`



be available for each node in a Real Application Clusters (RAC) environment because each instance manages its own undo.

4.6.5. USERS

The USERS tablespace is intended for miscellaneous segments created by each database user, and it’s not appropriate for any production applications. A separate tablespace should be created for each application and segment type.

4.6.6. EXAMPLE In a production environment, the EXAMPLE tablespace should be dropped; it takes

up 100MB of disk space and has examples of all types of Oracle segments and data structures. A separate database should be created for training purposes with these sample schemas; for an existing training database, the sample schemas can be installed into the tablespace of your choice by using the scripts in $ORACLE_HOME/demo/schema.

4.7. Segment Segregation

As a general rule of thumb, you want to divide segments into different tablespaces based on their type, size, and frequency of access. Furthermore, each of these tablespaces would benefit from being on its own disk group or disk device; in practice, however, most shops will not have the luxury of storing each tablespace on its own device. The following bulleted points identify some of the conditions you might use to determine how segments should be segregated among tablespaces. They are not prioritized here because the priority depends on your particular environment. Using Automatic Storage Management (ASM) eliminates many of the contention issues listed with no additional effort by the DBA.

Big segments and small segments should be in separate tablespaces. Table segments and their corresponding index segments should be in separate tablespaces.

A separate tablespace should be used for each application. Segments with low usage and segments with high usage should be in different tablespaces. Static segments should be separated from high DML segments. Read-only tables should be in their own tablespace. Staging tables for a data warehouse should be in their own tablespace.

Big segments and small segments should be in separate tablespaces. Table segments and their corresponding index segments should be in separate

tablespaces. A separate tablespace should be used for each application. Segments with low usage and segments with high usage should be in different

tablespaces. Static segments should be separated from high DML segments. Read-only tables should be in their own tablespace. Staging tables for a data warehouse should be in their own tablespace. Tablespaces should be created with the appropriate block size, depending on whether

segments are accessed row by row or in full table scans. Materialized views should be in a separate tablespace from the base table. For partitioned tables and indexes, each partition should be in its own tablespace.


`



Chapter 05

Managing Data Files

5.1. Data Files

Data files are physical files of the operating system that store the data of all logical structures in the database. They must be explicitly created for each tablespace. Oracle Database assigns each data file two associated file numbers, an absolute file number and a relative file number, that are used to uniquely identify it. These numbers are described below:

Type of File

Number Description

Absolute Uniquely identifies a data file in the database. This file number can be used in many SQL statements that reference data files in place of using

the file name. The absolute file number can be found in the FILE#

column of the V$DATAFILE or V$TEMPFILE view, or in the

FILE_ID column of the DBA_DATA_FILES or DBA_

TEMP_FILES view.

Relative Uniquely identifies a data file within a tablespace. For small and


`



medium size databases, relative file numbers usually have the same value as the absolute file number. However, when the number of data files in a database exceeds a threshold (typically 1023), the relative file number differs from the absolute file number. In a bigfile tablespace, the relative file number is always 1024 (4096 on OS/390 platform).

5.2. Determine the Number of Data Files

At least one data file is required for the SYSTEM and SYSAUX tablespaces of a database. Your database should contain several other tablespaces with their associated data files or temp files. The number of data files that you anticipate creating for your database can

affect the settings of initialization parameters and the specification of CREATE DATABASE statement clauses.

Be aware that your operating system might impose limits on the number of data files contained in your Oracle Database. Also consider that the number of data files, and how and where they are allocated can affect the performance of your database. Consider the following guidelines when determining the number of data files for your database.

5.2.1. Determine a Value for the DB_FILES Initialization Parameter

When starting an Oracle Database instance, the DB_FILES initialization parameter

indicates the amount of SGA space to reserve for data file information and thus, the maximum number of data files that can be created for the instance. This limit applies for the

life of the instance. You can change the value of DB_FILES (by changing the initialization

parameter setting), but the new value does not take effect until you shut down and restart the instance.

When determining a value for DB_FILES, take the following into consideration:

If the value of DB_FILES is too low, you cannot add data files beyond the

DB_FILES limit without first shutting down the database.

If the value of DB_FILES is too high, memory is unnecessarily consumed.

5.2.2. Consider Possible Limitations When Adding Data Files to a Tablespace

You can add data files to traditional smallfile tablespaces, subject to the following limitations:

Operating systems often impose a limit on the number of files a process can open simultaneously. More data files cannot be created when the operating system limit of open files is reached.

Operating systems impose limits on the number and size of data files. The database imposes a maximum limit on the number of data files for any Oracle

Database opened by any instance. This limit is operating system specific.

You cannot exceed the number of data files specified by the DB_FILES initialization parameter.

When you issue CREATE DATABASE or CREATE CONTROLFILE statements,

the MAXDATAFILES parameter specifies an initial size of the data file portion of the

control file. However, if you attempt to add a new file whose number is greater than

MAXDATAFILES, but less than or equal to DB_FILES, the control file will expand automatically so that the data files section can accommodate more files.

5.2.3. Consider the Performance Impact


`



The number of data files contained in a tablespace, and ultimately the database, can have an impact upon performance. Oracle Database allows more data files in the database than the operating system defined limit. The database DBWn processes can open all online data files. Oracle Database is capable of treating open file descriptors as a cache, automatically closing files when the number of open file descriptors reaches the operating system-defined limit. This can have a negative performance impact. When possible, adjust the operating system limit on open file descriptors so that it is larger than the number of online data files in the database.

5.3. Determine the Size of Data Files

When creating a tablespace, you should estimate the potential size of database objects and create sufficient data files. Later, if needed, you can create additional data files and add them to a tablespace to increase the total amount of disk space allocated to it, and consequently the database. Preferably, place data files on multiple devices to ensure that data is spread evenly across all devices.

5.4. Place Data Files Appropriately

Tablespace location is determined by the physical location of the data files that constitute that tablespace. Use the hardware resources of your computer appropriately. For example, if several disk drives are available to store the database, consider placing potentially contending data files on separate disks. This way, when users query information, both disk drives can work simultaneously, retrieving data at the same time.

5.5. Store Data Files Separate from Redo Log Files

Data files should not be stored on the same disk drive that stores the database redo log files. If the data files and redo log files are stored on the same disk drive and that disk drive fails, the files cannot be used in your database recovery procedures. If you multiplex your redo log files, then the likelihood of losing all of your redo log files is low, so you can store data files on the same drive as some redo log files.

5.6. Creating Data Files and Adding Data Files to a Tablespace

You can create data files and associate them with a tablespace using any of the statements listed in the following table. In all cases, you can either specify the file specifications for the data files being created, or you can use the Oracle Managed Files feature to create files that are created and managed by the database server. The table includes a brief description of the statement, as used to create data files, and references the section of this book where use of the statement is specifically described: SQL Statement Description CREATE TABLESPACE Creates a tablespace and the data files that

comprise it CREATE TEMPORARY TABLESPACE Creates a locally-managed temporary tablespace

and the temp files (temp files are a special kind of data file) that comprise it

ALTER TABLESPACE ... ADD DATAFILE Creates and adds a data file to a Tablespace ALTER TABLESPACE ... ADD TEMPFILE Creates and adds a temp file to a temporary

tablespace CREATE DATABASE Creates a database and associated data files ALTER DATABASE ... CREATE Creates a new empty data file in place of an old


`



DATAFILE one--useful to re-create a data file that was lost with no backup.

If you add new data files to a tablespace and do not fully specify the filenames, the database creates the data files in the default database directory or the current directory, depending upon your operating system. Oracle recommends you always specify a fully qualified name for a data file. Unless you want to reuse existing files, make sure the new filenames do not conflict with other files. Old files that have been previously dropped will be overwritten.

If a statement that creates a data file fails, the database removes any created operating system files. However, because of the large number of potential errors that can occur with file systems and storage subsystems, there can be situations where you must manually remove the files using operating system commands.

5.7. Changing Data File Size

There are various ways to alter the size of a data file, and contains the following topics:

Enabling and Disabling Automatic Extension for a Data File Manually Resizing a Data File

5.7.1. Enabling and Disabling Automatic Extension for a Data File

You can create data files or alter existing data files so that they automatically increase in size when more space is needed in the database. The file size increases in specified increments up to a specified maximum. Setting your data files to extend automatically provides these advantages:

Reduces the need for immediate intervention when a tablespace runs out of space Ensures applications will not halt or be suspended because of failures to allocate

extents

To determine whether a data file is auto-extensible, query the DBA_DATA_FILES

view and examine the AUTOEXTENSIBLE column. You can specify automatic file

extension by specifying an AUTOEXTEND ON clause when you create data files using the following SQL statements:

CREATE DATABASE

ALTER DATABASE

CREATE TABLESPACE

ALTER TABLESPACE You can enable or disable automatic file extension for existing data files, or manually

resize a data file, using the ALTER DATABASE statement. For a bigfile tablespace, you are

able to perform these operations using the ALTER TABLESPACE statement. The following

example enables automatic extension for a data file added to the users tablespace: ALTER TABLESPACE users ADD DATAFILE '/u02/oracle/rbdb1/users03.dbf' SIZE 10M AUTOEXTEND ON NEXT 512K MAXSIZE 250M;

The value of NEXT is the minimum size of the increments added to the file when it

extends. The value of MAXSIZE is the maximum size to which the file can automatically

extend. The next example disables the automatic extension for the data file. ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/users03.dbf'


`



AUTOEXTEND OFF;

5.7.2. Manually Resizing a Data File

You can manually increase or decrease the size of a data file using the ALTER

DATABASE statement. Therefore, you can add more space to your database without adding

more data files. This is beneficial if you are concerned about reaching the maximum number of data files allowed in your database.

For a bigfile tablespace you can use the ALTER TABLESPACE statement to resize a data file. You are not allowed to add a data file to a bigfile tablespace. Manually reducing the sizes of data files enables you to reclaim unused space in the database. This is useful for correcting errors in estimates of space requirements. In the next example, assume that the

data file /u02/oracle/rbdb1/stuff01.dbf has extended up to 250M. However, because its tablespace now stores smaller objects, the data file can be reduced in size.

The following statement decreases the size of data file /u02/oracle/rbdb1/

stuff01.dbf: ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' RESIZE 100M;

5.8. Altering Data File Availability

You can alter the availability of individual data files or temp files by taking them offline or bringing them online. Offline data files are unavailable to the database and cannot be accessed until they are brought back online. Reasons for altering data file availability include the following:

You want to perform an offline backup of a data file. You want to rename or relocate a data file. You must first take it offline or take the

tablespace offline. The database has problems writing to a data file and automatically takes the data file

offline. Later, after resolving the problem, you can bring the data file back online manually.

A data file becomes missing or corrupted. You must take it offline before you can open the database. The data files of a read-only tablespace can be taken offline or brought online, but

bringing a file online does not affect the read-only status of the tablespace. You cannot write to the data file until the tablespace is returned to the read/write state.

To take a data file offline or bring it online, you must have the ALTER DATABASE

system privilege. To take all data files or temp files offline using the ALTER TABLESPACE

statement, you must have the ALTER TABLESPACE or MANAGE TABLESPACE system

privilege. In an Oracle Real Application Clusters environment, the database must be open in exclusive mode.

There are three ways to alter data file availability, and contains the following topics: 1. Bringing Data Files Online or Taking Offline in ARCHIVELOG Mode 2. Taking Data Files Offline in NOARCHIVELOG Mode 3. Altering the Availability of All Data Files or Temp Files in a Tablespace

5.8.1. Bringing Data Files Online or Taking Offline in ARCHIVELOG Mode

To bring an individual data file online, issue the ALTER DATABASE statement and

include the DATAFILE clause. The following statement brings the specified data file online:


`



ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' ONLINE;

To take the same file offline, issue the following statement: ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' OFFLINE;

5.8.2. Taking Data Files Offline in NOARCHIVELOG Mode

To take a data file offline when the database is in NOARCHIVELOG mode, use the

ALTER DATABASE statement with both the DATAFILE and OFFLINE FOR DROP clauses.

The OFFLINE keyword causes the database to mark the data file OFFLINE, whether

or not it is corrupted, so that you can open the database.

The FOR DROP keywords mark the data file for subsequent dropping. Such a data file can no longer be brought back online.

The following statement takes the specified data file offline and marks it to be dropped: ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/users03.dbf' OFFLINE FOR DROP;

5.8.3. Altering the Availability of All Data Files or Temp Files in a Tablespace

Clauses of the ALTER TABLESPACE statement allow you to change the online or

offline status of all of the data files or temp files within a tablespace. Specifically, the statements that affect online/offline status are:

ALTER TABLESPACE ... DATAFILE {ONLINE|OFFLINE}

ALTER TABLESPACE ... TEMPFILE {ONLINE|OFFLINE} You are required only to enter the tablespace name, not the individual data files or

temp files. All of the data files or temp files are affected, but the online/offline status of the tablespace itself is not changed.

In most cases the preceding ALTER TABLESPACE statements can be issued whenever the database is mounted, even if it is not open. However, the database must not be

open if the tablespace is the SYSTEM tablespace, an undo tablespace, or the default

temporary tablespace. The ALTER DATABASE DATAFILE and ALTER DATABASE

TEMPFILE statements also have ONLINE/OFFLINE clauses, however in those statements you must enter all of the filenames for the tablespace.

The syntax is different from the ALTER TABLESPACE...ONLINE|OFFLINE

statement that alters tablespace availability, because that is a different operation. The ALTER

TABLESPACE statement takes data files offline as well as the tablespace, but it cannot be used to alter the status of a temporary tablespace or its temp file(s).

5.9. Renaming and Relocating Data Files

You can rename data files to either change their names or relocate them. Some possible procedures for doing this are described in the following sections:

Procedures for Renaming and Relocating Data Files in a Single Tablespace Procedure for Renaming and Relocating Data Files in Multiple Tablespaces

When you rename and relocate data files with these procedures, only the pointers to the data files, as recorded in the database control file, are changed. The procedures do not physically rename any operating system files, nor do they copy files at the operating system level. Renaming and relocating data files involves several steps.

5.9.1. Procedures for Renaming and Relocating Data Files in a Single Tablespace

The section suggests some procedures for renaming and relocating data files that can

be used for a single tablespace. You must have ALTER TABLESPACE system privileges.


`



5.9.1.1. Procedure for Renaming Data Files in a Single Tablespace

To rename data files in a single tablespace, complete the following steps: 1. Take the tablespace that contains the data files offline. The database must be open. For example: ALTER TABLESPACE users OFFLINE NORMAL; 2. Rename the data files using the operating system.

3. Use the ALTER TABLESPACE statement with the RENAME DATAFILE clause to

change the filenames within the database. For example, the following statement renames the data files

/u02/oracle/rbdb1/user1.dbf and /u02/oracle/rbdb1/user2.dbf

to/u02/oracle/rbdb1/users01.dbf and

/u02/oracle/rbdb1/users02.dbf,

respectively: ALTER TABLESPACE users RENAME DATAFILE '/u02/oracle/rbdb1/user1.dbf', '/u02/oracle/rbdb1/user2.dbf' TO '/u02/oracle/rbdb1/users01.dbf', '/u02/oracle/rbdb1/users02.dbf'; Always provide complete filenames (including their paths) to properly identify the old and new data files. In particular, specify the old data file name exactly as it appears in the

DBA_DATA_FILES view of the data dictionary.

4. Back up the database. After making any structural changes to a database, always perform an immediate and complete backup.

5. Bring the tablespace back online using an ALTER TABLESPACE statement with the

ONLINE clause: ALTER TABLESPACE users ONLINE

5.9.1.2. Procedure for Relocating Data Files in a Single Tablespace

Here is a sample procedure for relocating a data file. Assume the following conditions:

An open database has a tablespace named users that is made up of data files all located on the same disk.

The data files of the users tablespace are to be relocated to different and separate

disk drives. You are currently connected with administrator privileges to the open database.

You have a current backup of the database. Complete the following steps: 1. If you do not know the specific file names or sizes, you can obtain this information

by issuing the following query of the data dictionary view DBA_DATA_FILES: SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES 2> WHERE TABLESPACE_NAME = 'USERS'; FILE_NAME BYTES ------------------------------------------ ---------------- /u02/oracle/rbdb1/users01.dbf 102400000 /u02/oracle/rbdb1/users02.dbf 102400000 2. Take the tablespace containing the data files offline: ALTER TABLESPACE users OFFLINE NORMAL; 3. Copy the data files to their new locations and rename them using the operating


`



system. You can copy the files using the DBMS_FILE_TRANSFER package.

4. Rename the data files within the database.

The data file pointers for the files that comprise the users tablespace, recorded in the control file of the associated database, must now be changed from the old names to the new names.

Use the ALTER TABLESPACE...RENAME DATAFILE statement. ALTER TABLESPACE users RENAME DATAFILE '/u02/oracle/rbdb1/users01.dbf', '/u02/oracle/rbdb1/users02.dbf' TO '/u03/oracle/rbdb1/users01.dbf', '/u04/oracle/rbdb1/users02.dbf'; 5. Back up the database. After making any structural changes to a database, always perform an immediate and complete backup.

6. Bring the tablespace back online using an ALTER TABLESPACE statement with the

ONLINE clause: ALTER TABLESPACE users ONLINE

5.9.2. Procedure for Renaming and Relocating Data Files in Multiple Tablespaces

You can rename and relocate data files in one or more tablespaces using the ALTER

DATABASE RENAME FILE statement. This method is the only choice if you want to

rename or relocate data files of several tablespaces in one operation. You must have

the ALTER DATABASE system privilege. To rename data files in multiple tablespaces, follow these steps. 1. Ensure that the database is mounted but closed. 2. Copy the data files to be renamed to their new locations and new names, using the

operating system. You can copy the files using the DBMS_FILE_TRANSFER package.

3. Use ALTER DATABASE to rename the file pointers in the database control file.

For example, the following statement renames the data

files/u02/oracle/rbdb1/sort01.dbf and /u02/oracle/rbdb1/user3.dbf to

/u02/oracle/rbdb1/temp01.dbf and /u02/oracle/rbdb1/users03.dbf,

respectively: ALTER DATABASE RENAME FILE '/u02/oracle/rbdb1/sort01.dbf', '/u02/oracle/rbdb1/user3.dbf' TO '/u02/oracle/rbdb1/temp01.dbf', '/u02/oracle/rbdb1/users03.dbf'; Always provide complete filenames (including their paths) to properly identify the old and new data files. In particular, specify the old data file names exactly as they appear in the

DBA_DATA_FILES view.

4. Back up the database. After making any structural changes to a database, always perform an immediate and complete backup.

5.10. Dropping Data Files

You use the DROP DATAFILE and DROP TEMPFILE clauses of the ALTER

TABLESPACE command to drop a single data file or temp file. The data file must be empty. (A data file is considered to be empty when no extents remain allocated from it.) When you


`



drop a data file or temp file, references to the data file or temp file are removed from the data dictionary and control files, and the physical file is deleted from the file system or Oracle Automatic Storage Management (Oracle ASM) disk group.

The following example drops the data file identified by the alias example_df3.f

in the Oracle ASM disk group DGROUP1. The data file belongs to the example tablespace. ALTER TABLESPACE example DROP DATAFILE '+DGROUP1/example_df3.f';

The next example drops the temp file lmtemp02.dbf, which belongs to the lmtemp tablespace. ALTER TABLESPACE lmtemp DROP TEMPFILE '/u02/oracle/data/lmtemp02.dbf';

This is equivalent to the following statement: ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' DROP INCLUDING DATAFILES; Restrictions for Dropping Data Files

The following are restrictions for dropping data files and temp files: The database must be open. If a data file is not empty, it cannot be dropped. If you must remove a data file that is

not empty and that cannot be made empty by dropping schema objects, you must drop the tablespace that contains the data file.

You cannot drop the first or only data file in a tablespace. Therefore, DROP

DATAFILE cannot be used with a bigfile tablespace. You cannot drop data files in a read-only tablespace that was migrated from

dictionary managed to locally managed. Dropping a data file from all other read-only tablespaces is supported.

You cannot drop data files in the SYSTEM tablespace. If a data file in a locally managed tablespace is offline, it cannot be dropped.

5.11. Verifying Data Blocks in Data Files

To configure the database to use checksums to verify data blocks, set the initialization

parameter DB_BLOCK_CHECKSUM to TYPICAL (the default). This causes the DBWn

process and the direct loader to calculate a checksum for each block and to store the checksum in the block header when writing the block to disk.

The checksum is verified when the block is read, but only if DB_BLOCK_CHECKSUM

is TRUE and the last write of the block stored a checksum. If corruption is detected, the

database returns message ORA-01578 and writes information about the corruption to the alert log.

The value of the DB_BLOCK_CHECKSUM parameter can be changed dynamically

using the ALTER SYSTEM statement. Regardless of the setting of this parameter,

checksums are always used to verify data blocks in the SYSTEM tablespace.

.

Documents

Database Administration & Management · 1.3.2. Oracle Database Configuration Assistant Oracle Database Configuration Assistant (DBCA) is a utility that creates a database from templates